एजेंसी में Codex Desktop: diff review, PR और release check की व्यावहारिक गाइड

Web agency में release से पहले diff view, PR, staging URL और client approval note अक्सर अलग-अलग tabs में खुले रहते हैं। ऐसे में Codex से “सब कुछ review कर दो” कहना खराब release को नहीं रोकता। टीम को diff review, PR में बदलाव और production approval को अलग चरणों में बाँटना पड़ता है।

इस लेख में “Codex Desktop” एजेंसी के काम की सुविधा के लिए इस्तेमाल किया गया नाम है, किसी एक official product name का दावा नहीं। वास्तविक working surfaces ChatGPT desktop app, उसका review pane, Codex CLI, IDE extension और /review हैं। उद्देश्य साफ़ है: Codex कौन-से सबूत तैयार करे और account owner, director या duty engineer कौन-से release निर्णय अपने पास रखे।

एजेंसी में Codex का उपयोग कहाँ बिगड़ता है

• Codex Desktop को ChatGPT desktop app, review pane, CLI और IDE extension में होने वाले Codex काम के लिए व्यावहारिक नाम मानें।
• diff review, PR feedback, staging URL की जाँच और production approval को एक ही chat में न मिलाएँ।
• Codex को diff का सार, /review, जोखिम सूची और fix draft बनाने दें; client approval, pricing, legal copy, publish timing और production approval इंसान के पास रखें।
• AGENTS.md में agency के वास्तविक release gates लिखें: mobile width, form submit, CTA, OGP, tracking tag और rollback note।
• AI द्वारा बदली गई lines नहीं, बल्कि दोबारा काम, release incident, form failure और client review में लगा समय देखें।

इस लेख का आधार OpenAI के ChatGPT desktop app, Code review, AGENTS.md, Subagents, Best practices और Agent approvals and security दस्तावेज़ हैं। इससे जुड़े release workflow के लिए एजेंसी Azure DevOps release लेख भी देखें।

Codex क्या करे और इंसान क्या तय करे

Codex को स्पष्ट diff scope, base branch, staging URL, PR URL, changed files, human checks और rollback note दें। उसे pricing, legal copy, client acceptance, publish timing या production release मंज़ूर करने का अधिकार न दें। तकनीकी रूप से साफ़ बदलाव भी client की मंज़ूरी, campaign timing या तय scope के विरुद्ध हो सकता है।

व्यावसायिक निर्णय इंसान के पास रहता है; Codex review के सबूत तैयार करता है। यही agency work की उपयोगी approval boundary है। किसी finding को पहले gate से दूसरे gate तक ले जाया जा सकता है, लेकिन वह तीसरे gate में human approval को पार करके सीधे production तक नहीं पहुँच सकती।

Gate	Codex कौन-से सबूत तैयार कर सकता है	इंसान का निर्णय
Diff और PR	changed files, जोखिम के क्रम में findings, test output, unresolved comments	बदलाव agreed scope में है या नहीं
Staging	viewport checks, form result, links, metadata, screenshots	copy, design, tracking और client feedback स्वीकार्य हैं या नहीं
Production	blockers, rollback steps, owner, सुझाया गया publish time	client acceptance और अंतिम go/no-go

एजेंसी के तीन उपयोग के मामले

उपयोग मामला 1: Campaign landing page का PR review

Input: PR URL, base branch, changed files, staging URL, change request और client note। Output: code review, staging review और client approval की तीन-column table। Human review: pricing, ad copy, publish timing, client OK और production release।

यह workflow तब उपयोगी है जब campaign page implementation review पार कर चुका हो, लेकिन उसमें business-sensitive copy हो। Codex से हर finding की file और line माँगें, फिर client wording और release timing को अलग “human decision” column में रखें। सही output “approved” नहीं, बल्कि वह छोटी evidence list है जिसे director स्वीकार या अस्वीकार कर सके।

उपयोग मामला 2: कई reviewers के PR comments संभालना

Input: PR comments, target files, touched lines, जिन files को नहीं छूना है उनकी सूची और validation command। Output: हर comment का अलग fix plan, changed files, verification result और बचा हुआ decision note। Human review: client scope, design change, estimate पर असर और launch date।

जब designer, developer और account manager अलग-अलग review comments भेजें, तब एक समय में एक comment लें। Edit शुरू करने से पहले Codex से allowed files लिखवाएँ। जो request agreed layout, estimate या client-approved message बदलती है, उसे technical fix में चुपचाप शामिल करने के बजाय blocker बनाएँ।

उपयोग मामला 3: Staging से production handoff

इनपुट: staging URL, screen की चौड़ाइयाँ, जाँच के लिए काल्पनिक form, मुख्य CTA, tracking tag, rollback note और reviewer। नतीजा: desktop और mobile की जाँच सूची, form का नतीजा, links की सूची, screenshots और launch रोकने वाले कारण। Live page पर कार्रवाई तभी करें जब Browser capability configured हो, staging access मिला हो और form submit जैसे sensitive action से पहले आवश्यक approval लिया गया हो; वरना इंसान browser evidence दे। इंसानी जाँच: client approval, ad timing, contact address और production go/no-go।

PR तकनीकी रूप से तैयार होने के बाद staging pass में tested route और viewport, submission की expected success state तथा खोले गए links दर्ज करें। Prompt में वास्तविक customer data न डालें; काल्पनिक नाम, पता और inquiry text इस्तेमाल करें। Destination mailbox और production analytics property की पुष्टि human reviewer करे।

कॉपी-पेस्ट prompt

आप Codex Desktop इस्तेमाल करने से पहले web agency workflow का review कर रहे हैं।
Inputs: PR URL, base branch, staging URL, changed files, client approval note, release checklist और rollback note।
Output:
1. Codex के काम: diff summary, /review, risk list, fix draft, verification command।
2. इंसान के निर्णय: pricing, ad copy, legal wording, client OK, publish timing, production approval।
3. तीन-column table: PR fixes, staging checks, production blockers।
4. इस agency के लिए छोटी AGENTS.md rules।
5. पहला action जिसे 30 minutes में पूरा किया जा सके।
Rules: review findings को production approval न मानें। स्पष्ट review के बिना client-approved copy दोबारा न लिखें।

चलने वाला release check code

const releaseReview = {
  project: "campaign-lp",
  headBranch: "feature/lp-copy",
  baseBranch: "main",
  diffScope: "feature/lp-copy vs main",
  reviewCommand: "codex review --base main",
  stagingUrl: "https://staging.example.com/campaign",
  pullRequestUrl: "https://github.com/example/site/pull/42",
  filesChanged: ["src/pages/campaign.astro", "src/components/LeadForm.tsx"],
  humanChecks: ["mobile layout", "form submit", "tracking tag", "client approval", "rollback note"],
  productionRequirements: ["client approval", "rollback note", "analytics check"],
  clientApprovalReference: "approval-example-001",
  rollbackPlan: "Redeploy the previous production commit, then rerun form and analytics checks.",
  releaseOwner: "human release owner",
  codexCanDo: ["summarize diff", "run review", "list risks", "draft fix prompts"],
  humanMustDecide: ["publish timing", "legal wording", "pricing claim", "production approval"]
};

const hasText = (value) => typeof value === "string" && value.trim().length > 0;
const hasChecklist = (value) =>
  Array.isArray(value) && value.length > 0 && value.every(hasText);
const expectedDiffScope = `${releaseReview.headBranch} vs ${releaseReview.baseBranch}`;
const expectedReviewCommand = `codex review --base ${releaseReview.baseBranch}`;

const required = [
  ["head branch", hasText(releaseReview.headBranch)],
  ["base branch", hasText(releaseReview.baseBranch)],
  ["diff scope matches branches", releaseReview.diffScope === expectedDiffScope],
  ["review command matches base branch", releaseReview.reviewCommand === expectedReviewCommand],
  ["staging URL", hasText(releaseReview.stagingUrl)],
  ["pull request URL", hasText(releaseReview.pullRequestUrl)],
  ["changed files", hasChecklist(releaseReview.filesChanged)],
  ["human checks", hasChecklist(releaseReview.humanChecks)],
  ["production requirements", hasChecklist(releaseReview.productionRequirements)],
  ["client approval reference", hasText(releaseReview.clientApprovalReference)],
  ["rollback plan", hasText(releaseReview.rollbackPlan)],
  ["release owner", hasText(releaseReview.releaseOwner)],
  ["production approval stays human", hasChecklist(releaseReview.humanMustDecide) && releaseReview.humanMustDecide.includes("production approval")]
];

const findings = required
  .filter(([, ok]) => !ok)
  .map(([item]) => ({ item, fix: "add this before using Codex for release review" }));

console.table(findings);
if (findings.length > 0) process.exitCode = 1;

इस snippet को release-review-check.mjs नाम से चलाने का command node release-review-check.mjs है। खाली table और exit code 0 का अर्थ केवल यह है कि न्यूनतम review inputs मौजूद हैं; इसका अर्थ production approval नहीं है। Failure path जाँचने के लिए rollbackPlan को खाली string करें: script missing item दिखाकर non-zero exit code देगा।

Output को PR में जोड़ने से पहले वे तथ्य भी लिखें जिन्हें code खुद नहीं जान सकता: reviewer का नाम, client approval reference, planned release window और rollback चलाने वाला व्यक्ति। इससे सामान्य AI summary ऐसी release record बनती है जिसे अगला reviewer जाँच सके।

जोखिम और उनके सुधार

जोखिम 1: /review को production approval मान लेना

पहला कारण /review के output को final approval समझना है। सुधार के लिए output का नाम “diff findings” रखें और go/no-go का निर्णय किसी नामित इंसान के पास रखें। PR साफ़ दिखने पर भी client acceptance और publish timing अलग से दर्ज हों।

जोखिम 2: AGENTS.md में अस्पष्ट निर्देश

दूसरा कारण “अच्छी तरह review करें” जैसे अस्पष्ट AGENTS.md निर्देश हैं। सुधार के लिए mobile width, form submit, CTA, OGP, tracking tag और rollback note जैसे agency gates लिखें। हर gate के साथ expected evidence और human owner भी जोड़ें।

जोखिम 3: एक page पर parallel editing

तीसरा कारण एक ही page को कई agents या tasks में साथ-साथ edit करना है। सुधार के लिए links, logs और summaries जैसे read-heavy checks बाँटें, लेकिन सभी edits एक main task में वापस लाकर diff review कराएँ। इससे client-approved copy अनजाने में overwrite होने का जोखिम घटता है।

जोखिम 4: staging URL छोड़ देना

चौथा कारण केवल PR diff देखकर staging URL की जाँच छोड़ना है। सुधार के लिए PR diff, staging URL, screenshots, form result और rollback note को एक release table में रखें। बिना staging evidence के production gate को blocked ही रहने दें।

अक्सर पूछे जाने वाले सवाल

सवाल: क्या Codex Desktop official product name है?

जवाब: Official docs मुख्य रूप से ChatGPT desktop app, Codex CLI, IDE extension और review pane कहते हैं। यह लेख इन working surfaces के लिए Codex Desktop को agency का व्यावहारिक label मानता है।

सवाल: Agency को desktop app से शुरू करना चाहिए या CLI से?

जवाब: Director या reviewer अक्सर desktop app के review pane से शुरुआत कर सकता है। Local verification और implementation करने वाला developer CLI या IDE extension चुन सकता है। चुनाव role और repository workflow पर निर्भर है।

सवाल: क्या release से पहले /review पर्याप्त है?

जवाब: नहीं। यह diff review में मदद करता है। Client approval, ad timing, pricing और production approval human decision ही रहते हैं।

सवाल: क्या agencies को Subagents इस्तेमाल करने चाहिए?

जवाब: Links, logs और summaries जैसे read-heavy checks के लिए कर सकते हैं। उसी landing page पर concurrent edits से बचें और final diff एक मुख्य reviewer से जँचवाएँ।

मुख्य अगला कदम: Training और consultation

Agency के लिए लाभ केवल तेज़ edits नहीं, बल्कि review evidence और approval ownership को दोहराने योग्य बनाना है। हाल का PR, staging URL, AGENTS.md और release checklist लेकर Claude Code training और consultation पर जाएँ। वहाँ टीम अपने PR, staging URL और release gates को एक repeatable review workflow में बदलने पर चर्चा कर सकती है।

वास्तव में आज़माने के परिणाम

इस लेख के लिए OpenAI के Codex manual, ChatGPT desktop app, Code review, AGENTS.md, Subagents और Agent approvals and security links की जाँच की गई। JavaScript checklist को valid data और missing rollback, दोनों paths में चलाया गया: valid input पर empty table और exit code 0 मिला, जबकि rollbackPlan को खाली करने पर missing item और non-zero exit code मिला। Localized internal links, CTA, frontmatter और slug भी targeted checks में जाँचे गए। पहला व्यावहारिक कदम diff review, PR follow-up और release approval को तीन columns में बाँटना है।