Claude Opus 5.5 कोड ऑडिट चेकलिस्ट: merge से पहले हर finding को verify करें

आप Claude Opus 5.5 को कई घंटों तक repository audit करने देते हैं और बदले में दर्जनों “high-risk” findings तथा एक बड़ा patch मिलता है। असली कठिनाई उसके बाद शुरू होती है: कौन-सी समस्या वास्तव में मौजूद है, कौन-सा बदलाव मौजूदा architecture को तोड़ेगा, और कौन-सा fix सुरक्षित रूप से merge किया जा सकता है?

यह workflow model output को निष्कर्ष नहीं, बल्कि साक्ष्य माँगने वाली audit hypotheses मानता है। पहले एक reproducible baseline freeze करें। फिर हर स्वीकार्य finding को reproduction, risk, architecture, fix और regression gates से गुजरना चाहिए।

Opus 5.5 से audit का दायरा बढ़ाएँ, merge की मंज़ूरी न दिलाएँ

यह बड़े और लंबे audits के लिए उपयोगी उम्मीदवार है, लेकिन independent reviewer नहीं है। Anthropic ने 22 सितंबर 2026 की घोषणा में repository-wide migrations और audits को Opus 5.5 की strengths में रखा तथा internal tests और early testers के परिणाम बताए। Vendor के ये परिणाम आपके repository में वही outcome सुनिश्चित नहीं करते। Anthropic की Opus 5.5 घोषणा पढ़ें।

Kent C. Dodds ने security, performance, accessibility, maintainability, scalability, architecture, documentation, testing और automation को कवर करने वाला audit prompt साझा किया। उन्होंने कहा कि Opus 5.5 ने एक महत्वपूर्ण security issue पकड़ा जिसे दूसरे models ने छोड़ा था। लेकिन post में flaw, reproduction steps या controlled comparison नहीं दिया गया। यह workflow आज़माने का कारण है, verification हटाने का नहीं। Public post देखें।

इसलिए लक्ष्य अधिकतम warnings बनाना नहीं, बल्कि अधिकतम reproducible, graded और independently reviewable findings बनाना होना चाहिए।

Audit शुरू होने से पहले success को commands में परिभाषित करें

Clean baseline के बिना आप नहीं जान पाएँगे कि बाद की failure पहले से थी या model के बदलाव से आई। Current commit, environment, महत्वपूर्ण dependency versions, exact commands और उनके exit codes दर्ज करें।

इन placeholders को project के वास्तविक commands से बदलें। कोई gate लागू न हो तो उसे “not applicable” लिखें; केवल checklist पूरी करने के लिए नकली command न जोड़ें।

git status --short
<install-command>
<lint-command>
<type-check-command>
<unit-test-command>
<integration-test-command>
<build-command>

Baseline में कम-से-कम यह रखें:

• commit SHA, runtime, package manager और महत्वपूर्ण dependency versions;
• exact command, working directory, exit code और failure summary;
• known failures, flaky tests और temporary exemptions;
• in-scope directories तथा वे files जिन्हें model नहीं बदलेगा, जैसे generated code, historical migrations, lockfiles या vendored sources;
• authentication, authorization, billing, data migration और external API contracts जैसे critical paths।

यदि baseline पहले से fail है, तो audit से पहले उसे fix, isolate या known issue के रूप में register करें। पुराने failure को नई discovery बनने न दें।

पहली pass में “audit only, no code changes” कहें

Investigation और remediation अलग phases होने चाहिए। यदि model जाँचते-जाँचते edit करता है, तो अगली failure original code, पहले patch या कई patches की interaction में से कहीं से भी आ सकती है।

यह शुरुआती prompt उपयोग करें और repository-specific सीमाएँ जोड़ें:

इस repository का long-running code audit करें। इस phase में केवल investigate और report करें; files modify न करें।

Scope: <directories, services, languages, critical business flows>
Exclusions: <generated files, third-party code, historical migrations, inaccessible systems>
Baseline: <already-run commands, exit codes, known failures>

Audit areas:
1. security और authorization boundaries
2. correctness, concurrency, transactions और error handling
3. performance और resource usage
4. जहाँ लागू हो वहाँ accessibility
5. maintainability और scalability
6. architecture और module boundaries
7. documentation, testing और automation gaps

हर finding के लिए दें:
- unique ID और short title
- severity तथा impact rationale
- affected files, symbols और exact lines
- trigger, expected behavior और actual behavior
- reproducible command या minimal test
- output summary और exit code
- plausible false-positive explanation
- smallest remediation direction
- fix के बाद आवश्यक verification commands
- confidence: high, medium या low

Rules:
- जो command नहीं चलाया उसे NOT RUN लिखें।
- जिसे reproduce नहीं कर सकें उसे UNVERIFIED लिखें।
- green result के लिए tests delete, skip या weaken न करें।
- credentials, services या dependencies कम हों तो रुकें और gap लिखें।
- हर phase के अंत में status table update करें और review की प्रतीक्षा करें।

Prompt compliance की guarantee नहीं देता। Terminal history, diffs और वास्तविक test output आपको फिर भी जाँचना होगा। इसका काम vague “यह risky लगता है” को सीधे fix queue में जाने से रोकना है।

Long task को चार controlled phases में बाँटें

Long-running session का अर्थ unlimited scope या permissions नहीं है। हर phase boundary पर model को रोकें और evidence review करें।

Phase 1: system map बनाएँ

Model code, configuration, tests और architecture documents पढ़े। Output में entry points, trust boundaries, data flows, external dependencies और high-impact paths हों। इस stage पर bug count target या file edits न हों।

Phase 2: candidate findings बनाएँ

हर candidate concrete code और trigger से जुड़ा हो। Location या condition के बिना सामान्य suggestion improvement list में जाए, defect count में नहीं।

Phase 3: एक बार में एक finding reproduce करें

High-impact और low-cost-to-test items से शुरू करें। एक experiment एक hypothesis को test करे। Raw output और environment details सुरक्षित रखें।

Phase 4: remediation plan बनाएँ

सिर्फ reproduced defects fix plan में जाएँ। हर plan में minimum change, compatibility impact, migration risk, rollback और required gates हों। Architecture विवाद पहले code owner के पास जाएँ।

Status को audit-plan.md या ticket table में रखें:

ID	Status	Risk	Reproduction evidence	Architecture decision	Fix branch	Approver
AUD-001	Awaiting reproduction	High	अभी नहीं	Not reviewed	—	—

Status केवल इस path पर आगे बढ़े: candidate → awaiting reproduction → reproduced → architecture reviewed → fixed → accepted। Model का confident tone evidence की जगह नहीं लेता।

Risk gate: severity और confidence अलग रखें

Severity संभावित नुकसान बताती है; confidence evidence की quality। संभावित authorization bypass high severity और low confidence हो सकता है। एक reproducible log typo low severity और high confidence हो सकता है।

Severity	कब उपयोग करें	Fix से पहले minimum evidence
Critical	Broad privilege escalation, sensitive-data exposure, irreversible corruption या core-service outage संभव हो	Controlled reproduction, स्पष्ट blast radius, immediate owner review
High	Critical business flow प्रभावित हो या realistic input failure को स्थिर रूप से trigger करे	Minimal reproduction, failing test या command output, code-owner confirmation
Medium	Impact सीमित हो, workaround हो या unusual conditions चाहिए हों	Repeatable evidence और priority decision
Low	Local quality, documentation, maintainability या non-critical performance issue	Concrete code evidence और regression risk से अधिक benefit

Model code path trace कर सकता है, लेकिन data sensitivity, customer commitments, acceptable downtime और compatibility policy स्वयं नहीं जानता। Business impact responsible owner तय करे।

Reproduction gate: finding को failing check में बदलें

Suspicious code पर्याप्त नहीं है। ऐसा check चाहिए जो fix से पहले fail और fix के बाद pass हो। हर finding के लिए पूछें:

1. यह किस commit और environment में दिखती है?
2. सबसे छोटा triggering input क्या है?
3. Expected behavior test, specification, interface contract या business rule में कहाँ परिभाषित है?
4. Actual result क्या था और raw output कहाँ है?
5. Existing tests ने इसे क्यों छोड़ा?
6. क्या valid design choice या environment difference इसे समझा सकती है?

सबसे अच्छा evidence minimal regression test है। Automation संभव न हो तो deterministic manual steps, expected observation और cleanup लिखें। Security finding केवल अपने या स्पष्ट रूप से authorized local, isolated या pre-production environment में reproduce करें।

यदि model कहे कि उसने command चलाया, तो full command, working directory, exit code और relevant output देखें। Prose summary execution evidence नहीं है।

Architecture gate: बदलने से पहले समझें कि पुराना code क्यों है

Cleaner दिखने वाला बदलाव compatibility, deployment order या deliberate boundary तोड़ सकता है। Broad refactor से पहले ADRs, design docs, API contracts, migration constraints और history देखें।

Git history उपलब्ध हो तो model इन commands से मदद कर सकता है:

git log -- <path>
git blame -L <start>,<end> <file>
git show <commit> -- <path>

फिर उससे इन प्रश्नों के उत्तर लें:

• Current design कौन-सी constraint बचाता है?
• कौन-से callers, data formats या deployment steps इस पर निर्भर हैं?
• प्रस्ताव defect fix करता है या product behavior बदलता है?
• क्या छोटा local change पर्याप्त है?
• Rollback में code, configuration या data में से क्या restore करना होगा?

History संकेत देती है, intent का पूर्ण record नहीं। Rationale न मिले तो “architecture intent unknown” लिखें और maintainer से पूछें।

Fix gate: एक reproduced defect के लिए एक छोटा patch

कई unrelated findings वाला mega-patch स्वीकार न करें। पहले ऐसा regression test जोड़ें जो पुराने code पर स्थिर रूप से fail हो, फिर सबसे छोटा fix करें।

Gate	Requirement	Fail होने पर
Scope	Diff केवल approved finding को address करे	Unrelated changes अलग करें
Regression test	Fix से पहले fail, बाद में pass	Test सुधारें या finding दोबारा जाँचें
Static checks	Format, lint और type checks pass हों	Broad exemption से नए errors न छिपाएँ
Project tests	Relevant unit, integration और build pass हों	अगला patch जोड़ने से पहले पहली नई failure जाँचें
Architecture	Owner boundaries और compatibility confirm करे	Scope घटाएँ या design review खोलें
Human diff review	Error handling, permissions, data changes और deletions जाँचे जाएँ	हर suspicious change समझाएँ

Fake pass अस्वीकार करें: assertions हटाना, tests skip करना, exceptions swallow करना, validation कमजोर करना, race छिपाने के लिए retries बढ़ाना या इतना बड़ा refactor करना कि original defect trace न हो सके।

Regression gate: model-selected tests ही नहीं, project-owned gates चलाएँ

Final acceptance existing scripts या CI से आए। Full pre-audit baseline और post-fix result की तुलना करें तथा पुष्टि करें कि नया regression test unpatched revision पर fail होता है।

Lockfiles, database migrations, public APIs और configuration defaults में unintended changes देखें। Performance claim समान environment और input के before/after data पर आधारित हो। Flaky test को green आने तक rerun न करें; failure pattern दर्ज करें और जाँचें कि patch ने instability बढ़ाई तो नहीं।

इन संकेतों में से कोई हो तो finding reject करें

• Exact code location, trigger या inspectable evidence नहीं है।
• Unexecuted command को passing बताया गया है।
• Severity के साथ impact path नहीं दिया गया।
• Patch approved scope से बाहर है या बिना अनुमति architecture बदलता है।
• Tests delete, skip या weaken किए गए हैं, या errors छिपाए गए हैं।
• Change ADR, contract या migration policy से टकराती है और owner approval नहीं है।
• केवल final summary है, reviewable commands और diff नहीं।
• Security claim का आधार केवल दूसरे model की सहमति है।

दूसरा model counterexamples ढूँढने में मदद कर सकता है, लेकिन model consensus independent evidence नहीं है। Independent validation tests, runtime output, history, specifications और accountable human judgment से आती है।

Merge से पहले final acceptance checklist

• Scope, exclusions और baseline commit freeze हैं।
• Baseline commands और exit codes सुरक्षित हैं।
• हर accepted finding का unique ID और exact code location है।
• Severity और confidence अलग-अलग दर्ज हैं।
• Defect test या deterministic procedure से reproduce हुआ है।
• Architecture intent, compatibility और rollback review हुए हैं।
• हर finding एक छोटे, reviewable patch से जुड़ी है।
• Regression test fix से पहले fail और बाद में pass होता है।
• Full project gates existing scripts या CI से चले हैं।
• Code owner ने final diff review करके स्पष्ट approval दिया है।

Public reports Opus 5.5 को व्यापक, लंबे audits के लिए credible candidate बनाते हैं और संकेत देते हैं कि यह दूसरे reviews से छूटी समस्याएँ उठा सकता है। वे verification की आवश्यकता खत्म नहीं करते। सबसे छोटा अगला कदम model को तुरंत edit करने देना नहीं, बल्कि clean baseline बचाना और “audit only, no modifications” phase चलाना है।