Claude Code Harness Smoke Test: एजेंट पर भरोसा करने से पहले 15 मिनट की जांच

Claude Code से वास्तविक काम शुरू करते समय बड़ी ऑटोमेशन की जरूरत नहीं होती। पहले छोटा smoke test चाहिए। कौन सी फाइल पढ़नी है, कौन सी बदलनी है, कौन सा हिस्सा बिल्कुल नहीं छूना है, और अंत का प्रमाण क्या होगा, यह पहले तय करें।

यह लेख उन लोगों के लिए है जो जानना चाहते हैं कि एजेंट को कितना काम दिया जा सकता है। राजस्व वाली साइट पर प्रमाण में मुफ्त PDF, Gumroad उत्पाद और परामर्श लिंक भी आने चाहिए, केवल local build नहीं।

संबंधित लेख: Claude Code harness engineering, first repo audit checklist, permission safety ladder.

यह तरीका क्यों काम करता है

harness smoke test यह साबित नहीं करता कि मॉडल हमेशा सुरक्षित है। यह साबित करता है कि काम की सीमा साफ है। छोटा लेख परिवर्तन भी PDF फॉर्म, product link या consultation path तोड़ सकता है।

15 मिनट की जांच रोज दोहराई जा सकती है। पहले read scope, छोटी edit, build, public URL और screenshot प्रमाण पास करें।

व्यावहारिक प्रक्रिया

लक्ष्य को एक वाक्य में लिखें और edit files तीन से कम रखें
secrets, billing, customer data और deploy settings को blocked areas में लिखें
edit से पहले build, diff, public URL और screenshot proof तय करें
लेख या landing page में free PDF, Gumroad और consultation CTA भी जांचें
run card बचाकर रखें ताकि अगला काम evidence से शुरू हो

स्थिति	सुरक्षित कदम	प्रमाण
नया लेख	केवल body और frontmatter बदलने दें; layout और API read-only रहें	build और public URL
product page	copy और card order बदलें; हर purchase URL मिलाएं	Gumroad link check
team rollout	पहले read-only audit, फिर कम जोखिम वाली एक edit	diff और screenshot

कॉपी करने योग्य प्रॉम्प्ट और कोड

इस repository के लिए 15 मिनट का harness smoke test चलाइए। अभी बड़ा edit मत कीजिए। goal, editable files, blocked areas, proof commands, public URL checks और free PDF/Gumroad/consultation CTA checks लौटाइए।

const runCard = {
  slug: "claude-code-harness-smoke-test-loop",
  goal: "publish one safe content change",
  allowedFiles: ["site/src/content/blog-en/example.mdx"],
  blockedAreas: [".env", "billing/", "cloudflare/"],
  proof: ["npm.cmd run build", "public URL screenshot"],
  ctas: ["free PDF", "Setup Guide", "consultation"]
};

function readyForAgent(card) {
  return card.allowedFiles.length > 0 &&
    card.blockedAreas.length > 0 &&
    card.proof.some((item) => item.includes("build")) &&
    card.ctas.length >= 3;
}

console.log(readyForAgent(runCard) ? "ready" : "tighten scope");

यह कोड अस्पष्ट agent request को run card में बदलता है। PR template, publishing checklist और consultation prep में यही रूप इस्तेमाल हो सकता है।

तीन वास्तविक उदाहरण

Astro लेख प्रकाशित करना

edit को body, heroImage और CTA तक रखें। build सफल हो फिर भी यदि production h1 या CTA दूसरी page का है तो काम अधूरा है।

छोटा UI बदलाव

button text बदलने पर भी mobile wrapping और tap area देखें। यदि button product पर जाता है तो URL भी जांचें।

पहली team adoption call

शुरुआत code से न करें। README, permissions, tests और blocked areas map करें। यही consultation agenda बनता है।

इन गलतियों से बचें

Claude Code से सब कुछ सुधारने को कहना scope बहुत बड़ा कर देता है।
local build पर रुकने से production fallback और पुराने CTA छूट जाते हैं।
Gumroad check न करने से beginner traffic गलत offer पर जा सकता है।

बहुभाषी प्रकाशन में slug सही हो सकता है लेकिन body और CTA पुराने रह सकते हैं। सार्वजनिक page देखें, केवल frontmatter नहीं।

मुफ्त PDF, Gumroad और परामर्श से जोड़ना

जिन्हें command fluency चाहिए वे मुफ्त cheatsheet से शुरू करें। permissions, CLAUDE.md, hooks, MCP या CI की समस्या हो तो Setup Guide बेहतर है।

बार-बार review और debug prompt लिखने वालों के लिए 50 Prompt Templates उपयोगी है। team rollout design के लिए consultation पर जाएं। विकल्प products पर देखें।

प्रकाशन से पहले और बाद में जांच

publish से पहले frontmatter, heroImage, internal links और Gumroad links देखें। publish के बाद mobile width में h1, opening body और CTA area देखें। HTTP 200 काफी नहीं यदि page fallback है।

आगे देखने वाली संख्याएँ

इस slug पर search traffic, PDF starts, Gumroad clicks, product visits और consultation visits देखें। PV बढ़े पर product click न बढ़े तो CTA stage गलत है।

30 मिनट की operations review

जब harness smoke test वास्तविक काम में जाता है, सबसे उपयोगी review अगले दिन होती है। run log पढ़कर allowed scope, बदली हुई files, proof commands और देखे गए public pages लिखें। केवल “checked” न लिखें। receipt साफ रखें: mobile h1, opening paragraph, CTA area, Gumroad link और consultation path।

फिर worker confidence और reader behavior अलग देखें। worker side पर blocked areas न छूना, build proof, वही public slug और translated pages में English body न रहना जरूरी है। reader side पर next step साफ होना चाहिए: command fluency के लिए free PDF, repeatable bottleneck के लिए Gumroad, workflow design के लिए consultation।

आखिर में review को अगली बार की एक rule बनाएं। हर समस्या पर दस rules न जोड़ें। एक rule जोड़ें: layout edit से पहले ask, production पर हर Gumroad URL click, या हर locale की opening body screenshot। रोज चलने वाला छोटा rule लंबी policy से मजबूत होता है।