Claude Code सत्यापन रसीद: build, public URL, CTA और screenshots से AI बदलाव साबित करें

सत्यापन रसीद क्यों जरूरी है

Claude Code लेख, landing page, link और code example बहुत तेजी से बदल सकता है। असली जोखिम यह नहीं है कि file बदल गई। जोखिम यह है कि diff देखने में सही लगे और हम मान लें कि काम publish करने लायक हो गया। Public article या revenue page में local build सिर्फ एक संकेत है। Public URL पुराना हो सकता है, CTA गलत Gumroad product पर जा सकता है, और mobile screenshot में लंबा translated button टूट सकता है।

यहाँ “सत्यापन रसीद” काम आती है। यह payment receipt नहीं है, बल्कि बदलाव का evidence note है। इसमें लिखा जाता है कि कौन सी files बदलीं, क्यों बदलीं, कौन सा command चला, कौन सा public URL खोला, free PDF, Gumroad और consultation link सही हैं या नहीं, screenshots में layout ठीक है या नहीं, और कौन सा risk बाकी है। इससे अगले दिन काम memory पर नहीं, evidence पर आगे बढ़ता है।

इसे build error triage, review workflow checklist और permission audit checklist के साथ पढ़ना उपयोगी है। Build fail हो तो पहला लेख, review standard चाहिए तो दूसरा, और agent permission सीमित रखनी हो तो तीसरा लेख मदद करेगा।

सत्यापन रसीद का template

इस template को PR comment, work log या Claude Code के final prompt में paste करें। नियम सीधा है: feeling नहीं, evidence लिखें। “ठीक लग रहा है” कमजोर है। “npm.cmd run build सफल रहा”, “public h1 expected title से match हुआ” और “CTA Gumroad product खोलता है” मजबूत evidence है।

Verification Receipt

Scope:
- changed files:
- user-facing behavior:
- out of scope:

Diff summary:
- what changed:
- why it changed:
- what should not change:

Proof commands:
- git status --short:
- git diff --stat:
- npm.cmd run build:

Public URL checks:
- article URL:
- expected h1:
- canonical:
- no fallback page:

Revenue and CTA checks:
- free PDF CTA:
- Gumroad product link:
- consultation link:
- thanks page or next step:

Screenshot checks:
- desktop screenshot:
- mobile screenshot:
- visible CTA:
- text overflow or broken layout:

Remaining risk:
- risk 1:
- risk 2:
- risk 3:

out of scope लिखने से Claude Code आसपास की unrelated files बदलने से रुकता है। Article improvement में article ही बदले, package update या navigation cleanup अलग task रहे। what should not change में slug, canonical, author, publish date, product link और consultation route लिखें।

build, public URL, CTA और screenshot की जाँच

सबसे पहले local proof लें। देखें कि सिर्फ expected files बदली हैं, diff कितना बड़ा है, फिर site build करें। Windows में npm.cmd ज्यादा predictable रहता है।

git status --short
git diff --stat
cd site
npm.cmd run build

इसके बाद public URL जाँचें। केवल HTTP 200 काफी नहीं है, क्योंकि fallback page भी 200 दे सकता है। Page-specific h1, article phrase और CTA या product text खोजें।

const checks = [
  {
    url: "https://claudecode-lab.com/hi/blog/claude-code-verification-receipt-workflow/",
    mustInclude: ["Claude Code सत्यापन रसीद", "सत्यापन रसीद का template", "Gumroad"],
  },
  {
    url: "https://claudecode-lab.com/en/products/",
    mustInclude: ["Claude Code", "Products"],
  },
  {
    url: "https://claudecode-lab.com/hi/training/",
    mustInclude: ["consultation"],
  },
];

for (const check of checks) {
  const res = await fetch(check.url, { redirect: "follow" });
  const html = await res.text();
  const missing = check.mustInclude.filter((text) => !html.includes(text));
  console.log(check.url, res.status, missing.length === 0 ? "ok" : `missing: ${missing.join(", ")}`);
}

अब visual proof लें। Text मौजूद हो सकता है, फिर भी mobile पर button टूट सकता है या code block screen से बाहर जा सकता है। Playwright हो तो desktop और mobile screenshot बचाएँ।

import { chromium } from "playwright";
import { mkdir } from "node:fs/promises";

const outDir = "tmp-verification/claude-code-verification-receipt-workflow";
await mkdir(outDir, { recursive: true });

const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1440, height: 1100 } });
await page.goto("https://claudecode-lab.com/hi/blog/claude-code-verification-receipt-workflow/", {
  waitUntil: "networkidle",
});
await page.screenshot({ path: `${outDir}/desktop-hi.png`, fullPage: true });

await page.setViewportSize({ width: 390, height: 1200 });
await page.screenshot({ path: `${outDir}/mobile-hi.png`, fullPage: true });

await browser.close();
console.log(`screenshots saved to ${outDir}`);

Screenshot देखते समय first viewport, पहला code block, बीच का template section और final CTA देखें। Hindi में English technical terms मिलाना सामान्य है, लेकिन बहुत लंबे button या unclear mix reader को रोक सकते हैं।

उदाहरण 1: पतले article को मजबूत बनाना

जब article thin हो, लक्ष्य सिर्फ word count बढ़ाना नहीं है। Reader को काम की चीज मिलनी चाहिए: verification receipt की सरल परिभाषा, copy-paste template, build command, public URL check, CTA check, screenshot check और concrete failure examples।

ऐसे change की receipt में लिखें कि कौन से sections जोड़े गए, internal links और external links हैं या नहीं, code block triple backtick में हैं या नहीं, updatedDate और heroImage सुरक्षित हैं या नहीं। अगर article में product path है, तो उसे natural रखें: पहले free PDF से habit, फिर Gumroad guide से repeatable templates, फिर team process के लिए consultation।

उदाहरण 2: CTA या product link बदलना

CTA छोटा change लगता है, पर download, purchase और consultation पर असर डालता है। Receipt में सिर्फ “CTA बदला” न लिखें। Button text, href, destination page title और next action लिखें। Free PDF में देखें कि reader को क्या मिलेगा यह साफ है या नहीं। Gumroad में product name और description article promise से match करते हैं या नहीं। Consultation में देखें कि context naturally वहाँ पहुँचता है या नहीं।

उदाहरण 3: multi-language publish करना

Multi-language article में English version देखकर रुकना गलत है। “Verification receipt” को Hindi में “सत्यापन रसीद” कहना ठीक है, लेकिन पहली बार समझाना जरूरी है कि यह evidence note है। दूसरे languages में CTA लंबा हो सकता है, mobile layout टूट सकता है, और product link wrong locale पर जा सकता है। हर language के opening, template, failure examples, resource path और screenshots जाँचें।

सामान्य गलतियाँ और बचाव

पहली गलती है HTTP 200 को publish मान लेना। h1, canonical और article-specific phrase भी देखें।

दूसरी गलती है build success पर रुक जाना। Build source compile होने का proof है, public site update होने का नहीं।

तीसरी गलती है link existence को CTA check मान लेना। Destination page भी खोलना होगा।

चौथी गलती है screenshots न बचाना। Screenshot नहीं होगा तो mobile check memory पर निर्भर रहेगा।

पाँचवीं गलती है Claude Code से बस “verify this” कहना। Template दें और command, URL, CTA, screenshot, remaining risk माँगें।

सीखने की सामग्री और consultation path

अकेले काम कर रहे हैं तो free Claude Code cheatsheet से daily commands और safe prompts तय करें। Workflow repeat होने लगे तो 50 prompt templates और Setup Guide से CLAUDE.md, hooks और permissions को reusable बनाएँ।

Team में public articles, landing pages, Gumroad products या consultation form चलते हैं तो verification एक operating rule बनता है। कौन public URL देखेगा, screenshots कहाँ रहेंगे, कौन से CTAs revenue path हैं, कौन सी failure publish रोकती है, यह पहले तय करना बेहतर है। ऐसी स्थिति में consultation natural next step है।

• Free Claude Code Cheatsheet
• 50 Claude Code Prompt Templates
• Claude Code Setup Guide
• Products
• Consultation

इस article में क्या verify किया गया

इस article में diff check, build, public URL, CTA और screenshots को एक receipt workflow में जोड़ा गया। Practical फायदा यह है कि omission तुरंत दिखता है: build हुआ पर public URL नहीं देखा, CTA देखा पर consultation link नहीं खोला, desktop screenshot है पर mobile नहीं। Claude Code की speed तभी सुरक्षित बनती है जब उसके साथ evidence भी उतनी ही जल्दी record हो।