कोई भी काम तब तक “पूरा” नहीं है जब तक आप एक ऐसा चेक न चला सकें — एक test, एक build exit
code, एक screenshot। Forge के verification gates प्रत्येक एक और catch जोड़ते हैं।
प्रति-task miss rate 1 − p और gate catch rate c के साथ, silent misses (1 − p)(1 − c)
तक गिर जाते हैं, और यहाँ हर gate एक और c है।
Verification घटाता है, प्रमाणित नहीं करता। Crew verifiers और hallucinated-symbol
flag review burden कम करते हैं; वे कोड को सही साबित नहीं करते। Tests और मानव सुधार
हमेशा जीतते हैं।
स्वतंत्र सत्यापन — forge verify
एक स्वतंत्र gate: यह repo के वास्तविक tests चलाता है, hallucinated symbols flag करता है, और
provenance जाँचता है।
--deep (v0.19+) एक multi-lens consensus तक escalate करता है: बदलाव को कई स्वतंत्र
verification lenses से गुज़रना पड़ता है, केवल एक से नहीं।
forge verify --deep एक binary pass/fail के बजाय एक चार-अवस्था वाला status रिपोर्ट करता है:
PASS — हर lens सहमत हुआ और core forge verify tests status भी PASS है। केवल
यही state verified मानी जाती है।FAIL — कम-से-कम एक lens ने वास्तविक failure रिपोर्ट किया।INCOMPLETE — कोई lens पूरा नहीं हो सका (timeout, crash, missing dependency)। कुछ भी
disprove नहीं हुआ, पर कुछ prove भी नहीं हुआ।NOT_CONFIGURED — इस repo के लिए कोई lenses wired नहीं हैं, इसलिए --deep के पास
check करने को कुछ नहीं था।
PASS-implies-base-PASS नियम जानबूझकर है: एक हरा deep consensus कभी भी एक लाल base run
से आगे नहीं निकल सकता, इसलिए base test lens पर INCOMPLETE या NOT_CONFIGURED deep
result को उसी के अनुरूप downgrade कर देता है।
Hallucinated-symbol flag — forge atlas has
forge atlas has <symbol> hallucination check है: यदि मॉडल किसी ऐसे symbol को call
करता है जो code graph में नहीं है, तो gate उसे flag करता है।
Atlas जानबूझकर plain JSON है — Codex, Cursor, Gemini, और Aider .forge/atlas.json
को CLI या plain jq के ज़रिए पढ़ते हैं, बिना किसी MCP dependency के।
Spec-as-contract — forge spec
व्यवहार को एक spec से pin करें और उससे drift पहचानें:
Skill-gate — forge scan
किसी skill या MCP server को install करने से पहले, उसे injection, RCE, या exfiltration
के लिए जाँचें:
Clean scan safety certification नहीं है। Built-in heuristic केवल known attack
shapes (critical) और कुछ high-severity patterns को पकड़ता है; pass का मतलब है “कोई
critical signature नहीं मिला”, “install करने के लिए सुरक्षित” नहीं। हमेशा source,
permissions, package provenance, और network behaviour ख़ुद review करें। एक
high-severity finding को safe के रूप में मार्क नहीं किया जाता, भले ही यह hard-block
न करे। External scanner opt-in है और जब तक आप उसे enable न करें, कोई network call
नहीं करता।
Hardening — forge harden
Secrets और unsafe changes को बाहर रखने वाले security controls को wire करें:
Commit-level gate — forge precommit
forge precommit (v0.19+) एक commit-level gate है — यह commit time पर verification
floor चलाता है ताकि आंशिक या unverified काम land होने से पहले पकड़ा जाए।
Completion gate — test evidence अनिवार्य
Stop-path completion gate (देखें
क्रॉस-सेशन मेमोरी) अब एजेंट के handoff को इस बात के
प्रमाण के रूप में स्वीकार नहीं करता कि code changes पूरे हो चुके हैं। किसी भी ऐसे सेशन के लिए
जिसने source code को छुआ है, gate वास्तविक test evidence माँगता है:
- सेशन के diff में बदली गई एक test file, या
- मौजूदा बदलावों के विरुद्ध रिकॉर्ड किया गया एक ताज़ा passing
forge verify।
अकेला forge handoff snapshot gate को संतुष्ट नहीं करता — यह intent रिकॉर्ड करता है,
verification नहीं। यदि दोनों में से कोई भी प्रमाण मौजूद नहीं है, तो gate एक बार एक repair
checklist के साथ ब्लॉक करता है:
Doc-only, config-only, और अन्य non-code सेशन प्रभावित नहीं होते — test-evidence अनिवार्यता
केवल तभी लागू होती है जब सेशन का diff वास्तव में code बदलता है।
UI checks — forge uicheck
Deterministic UI checks, पहले तीन lenses के लिए कोई LLM नहीं और कोई screenshots नहीं:
इसे forge taste के साथ जोड़ें ताकि एक visual direction चुनें (brutalist, corporate,
editorial, minimalist, playful) और design gate की thresholds को parameterize करें। 
