किसी एजेंट द्वारा लिखे गए कोड को प्रोडक्शन में शिप करने से पहले निम्नलिखित शर्तों का पूरा होना अनिवार्य है: टेस्ट सूट सफलतापूर्वक पास हो, लिंट और टाइप चेक में कोई त्रुटि न हो, कोड का diff ठीक उसी आकार और दायरे का हो जो योजना में तय किया गया था, प्रोजेक्ट पूरी तरह बिल्ड हो, सुरक्षा स्कैन किसी नए खतरे की सूचना न दे, और एक मानव इंजीनियर ने diff को ध्यानपूर्वक पढ़कर मंजूरी दी हो। इनमें से प्रत्येक चरण एक सत्यापन द्वार (Verification gate) है: एक ऐसी अनिवार्य जांच जिसे कार्य को अगले चरण में ले जाने से पहले पास करना ही होगा। कोई भी कोड लिखे जाने से पहले एक और द्वार काम करता है: योजना (Plan) की मानवीय स्वीकृति। यह द्वार सबसे अधिक वित्तीय बचत करता है, क्योंकि एक अस्वीकृत योजना को निष्पादित करने में शून्य खर्च होता है। यह लेख सत्यापन द्वारों को परिभाषित करता है, एजेंट कोड के लिए आवश्यक द्वारों को सूचीबद्ध करता है, और बताता है कि Ivy Tendril उन्हें कैसे संचालित करता है।

सत्यापन द्वार (Gate) क्या है

एक द्वार किसी चरण परिवर्तन (stage transition) से जुड़ी एक अनिवार्य शर्त है। चरण N का कार्य तब तक चरण N+1 में प्रवेश नहीं कर सकता जब तक कि वह शर्त पूरी न हो जाए। इस शर्त का हर बार एक ही तरीके से मूल्यांकन किया जाना चाहिए, और परिणाम को ऑडिट के लिए दर्ज किया जाना चाहिए।

तीन प्रमुख गुण एक द्वार को मात्र सुझाव से अलग करते हैं:

यह अवरोधक (Blocking) होता है। एक असफल द्वार प्रक्रिया को तुरंत रोक देता है। एक ऐसी जांच जिसकी विफलता केवल सलाहकारी हो, वह एक रिपोर्ट है, द्वार नहीं।
यह स्वचालित या स्पष्ट होता है। या तो कोई प्रोग्राम इसका निष्पक्ष मूल्यांकन करता है (टेस्ट, लिंट, बिल्ड) या कोई नामित व्यक्ति लिखित निर्णय लेता है (कोड समीक्षा)। "संभवतः किसी ने इसे देखा होगा" इनमें से कुछ भी नहीं है।
इसका एक परिभाषित विफलता मार्ग होता है। जब द्वार विफल होता है, तो कार्य किसी विशिष्ट गंतव्य पर जाता है: वापस एजेंट के पास, वापस योजना पर, या किसी मानव इंजीनियर के पास। जो कार्य किसी द्वार पर विफल होकर अधर में लटक जाता है, वही एजेंट आउटपुट के खो जाने का सबसे आम कारण बनता है।

इंसानों द्वारा लिखा गया कोड भी द्वारों से होकर गुजरता है: सतत एकीकरण (CI) और पुल रिक्वेस्ट समीक्षा। एजेंट आउटपुट में मुख्य अंतर वॉल्यूम का है। जब एक अकेला डेवलपर दिन में बीस पुल रिक्वेस्ट खोल सकता है, तो समीक्षा सबसे धीमा कदम बन जाती है। इसलिए समीक्षा से पहले के द्वारों को एक व्यक्ति द्वारा diff पढ़ने से पहले जितना संभव हो सके कमियों को स्वचालित रूप से हटाना होगा। कोडिंग एजेंटों के लिए एजेंट ऑर्केस्ट्रेशन पैटर्न में बताया गया है कि सत्यापन कतारबद्धता, अलगाव और लागत नियंत्रण के साथ कैसे तालमेल बैठाता है।

एजेंट आउटपुट के लिए महत्वपूर्ण सत्यापन द्वार

द्वार	यह क्या जांचता है	विफलता का आमतौर पर क्या अर्थ है
योजना स्वीकृति	एक मानव ने योजना पढ़ी है और दृष्टिकोण व दायरे से सहमत है	कार्य अधूरा निर्दिष्ट था या तकनीकी दृष्टिकोण गलत है
टेस्ट्स (Tests)	मौजूदा टेस्ट पास होते हैं; नए व्यवहार के लिए टेस्ट मौजूद हैं	एजेंट ने कुछ पुराना तोड़ दिया या अपने बदलावों को टेस्ट में कवर नहीं किया
लिंट और टाइप चेक	कोड प्रोजेक्ट के नियमों के अनुरूप है और संकलित (compile) होता है	नियमों का उल्लंघन, अप्रयुक्त कोड, या टेस्ट पास कराने के चक्कर में पैदा हुई टाइप त्रुटियां
Diff का आकार और दायरा	बदली गई फाइलें योजना से मेल खाती हैं; diff समीक्षा योग्य है	एजेंट ने योजना से बाहर की फाइलें बदल दीं या असंबंधित कोड को रीफैक्टर कर दिया
बिल्ड (Build)	पूरी परियोजना शाखा से सफलतापूर्वक बिल्ड होती है	कोई चीज़ अलगाव में तो काम करती है लेकिन पूरे सिस्टम में जुड़ने पर टूट जाती है
सुरक्षा स्कैन	कोई नया सीक्रेट, संवेदनशील निर्भरता (dependency) या असुरक्षित पैटर्न नहीं	एजेंट ने क्रेडेंशियल, असुरक्षित लाइब्रेरी या असुरक्षित कॉल जोड़ दी
Diff स्वीकृति	एक मानव ने कोड diff को पढ़ा है और उसे मंजूरी दी है	वह सब जिसे स्वचालित द्वार नहीं आंक सकते: वास्तविक इरादा, नामकरण, उत्पाद अनुकूलता

पहले छह द्वार किसी मानव के शामिल होने से पहले चलते हैं: योजना द्वार निष्पादन से पहले चलता है और बाकी एजेंट के Worktree के भीतर निष्पादन के बाद चलते हैं। इनमें से दो विशेष ध्यान देने योग्य हैं।

मॉडल-जनरेटेड कोड के लिए विशिष्ट जोखिम — जैसे असुरक्षित आउटपुट प्रबंधन, सप्लाई-चेन में दुर्भावनापूर्ण पैकेज जोड़ना, लीक हुए क्रेडेंशियल — OWASP Top 10 for LLM Applications में सूचीबद्ध हैं, जो सुरक्षा द्वार के लिए एक बेहतरीन चेकलिस्ट है।

Diff का आकार और दायरा (scope) वह द्वार है जिसे टीमें अक्सर छोड़ देती हैं, जबकि यह इंसानों की तुलना में एजेंटों के लिए अधिक महत्वपूर्ण है। यदि किसी एजेंट को केवल एक नल-चेक (null check) ठीक करने के लिए कहा जाए, तो वह कभी-कभी पूरी फाइल को रीफॉर्मेट कर देता है, वेरिएबल का नाम बदल देता है और तीन कॉल साइट्स को अपडेट कर देता है। ये सब मिलकर 10-लाइन की त्वरित समीक्षा को 300-लाइन के जटिल diff में बदल देते हैं। एक स्कोप गेट छुई गई फाइलों और मॉड्यूल की योजना से तुलना करता है और अंतर की रिपोर्ट करता है।

सुरक्षा स्कैन सीक्रेट्स, निर्भरता कमजोरियों और जोखिम भरे कोड पैटर्न्स को रोकता है। एजेंट आसपास के कोड से पैटर्न कॉपी करते हैं, इसलिए जिस रिपॉजिटरी में एक असुरक्षित पैटर्न होता है, उसमें एजेंट द्वारा और अधिक असुरक्षित कोड जोड़ने की प्रवृत्ति होती है।

योजना चेकपॉइंट निष्पादन की बर्बादी को क्यों रोकता है

निष्पादन के बाद आने वाले सभी द्वारों में एक समान खामी होती है: जब तक वे विफल होते हैं, टोकन और पैसे खर्च हो चुके होते हैं। टेस्ट, लिंट, बिल्ड और स्कैन केवल यह बताते हैं कि निष्पादन गलत हो गया। केवल योजना द्वार ही आपको लागत लगने से पहले सचेत करता है।

गौर करें कि बाद के द्वार क्या पकड़ते हैं: टेस्ट की विफलता क्योंकि एजेंट आवश्यकता को गलत समझ बैठा — यह एक योजना की समस्या है। स्कोप की विफलता क्योंकि एजेंट ने उन मॉड्यूल को छुआ जिनका टास्क में कोई उल्लेख नहीं था — यह एक योजना की समस्या है। बिल्ड विफलता क्योंकि योजना ने निर्भरताओं पर विचार किए बिना एक पैकेज में बदलाव की मांग की थी — यह भी एक योजना की समस्या है। इनमें से प्रत्येक मामले में, दो मिनट तक लिखित योजना पढ़ने वाला एक समीक्षक शून्य निष्पादन लागत पर इसे आसानी से पकड़ लेता।

यही कारण है कि सॉफ्टवेयर फैक्ट्री वर्कफ़्लो — योजना बनाने, निष्पादित करने, सत्यापित करने और समीक्षा करने के दोहराए जाने वाले क्रम के लिए Ivy का नाम — में ठीक दो मानवीय चेकपॉइंट हैं और उनमें से एक को किसी भी कोड के अस्तित्व में आने से पहले रखा गया है। योजना चेकपॉइंट पर दायरा, दृष्टिकोण और क्रम तय किया जाता है। Diff चेकपॉइंट पर शुद्धता की पुष्टि की जाती है। उनके बीच की हर चीज़ पूरी तरह से स्वचालित होती है।

Ivy Tendril सत्यापन द्वार कैसे संचालित करता है

Ivy Tendril एक लोकल-फर्स्ट डेस्कटॉप एप्लिकेशन (macOS, Windows, Linux) है जो किसी कार्य को योजना से लेकर समीक्षा किए गए पुल रिक्वेस्ट तक ले जाता है। दो मानवीय चेकपॉइंट और उनके बीच के स्वचालित द्वार इसके जीवनचक्र में मूल रूप से अंतर्निहित हैं। इंटरफ़ेस के लिए Review ऐप दस्तावेज़ देखें।

योजना द्वार (Plan gate): एक योजना ड्राफ्ट के रूप में शुरू होती है। एक इंसान इसे पढ़ता है और इसे विस्तृत (Expand), विभाजित (Split), या अपडेट (Update) कर सकता है, या ड्राफ्ट पर इनलाइन टिप्पणी करके योजना को फिर से लिखवा सकता है। योजना स्वीकृत होने तक कोड निष्पादन शुरू नहीं होता है।
अलगाव में निष्पादन: प्रत्येक योजना अपनी शाखा पर अपने स्वयं के git worktree में निष्पादित होती है, इसलिए सत्यापन ठीक उसी योजना के परिवर्तनों के विरुद्ध चलता है और किसी अन्य चीज़ के नहीं। समानांतर AI एजेंटों के लिए Git वर्क-ट्री में बताया गया है कि अलगाव ही द्वारों को विश्वसनीय बनाता है।
सत्यापन टैब: निष्पादन के बाद, Review ऐप परीक्षण, लिंट और diff को अलग-अलग टैब के रूप में दिखाता है, ताकि समीक्षक निर्णय लेने से पहले तीनों को देख सके।
Pro पर CI आयात: जिन टीमों के द्वार CI में चलते हैं — GitHub Actions या कोई अन्य CI टूल — वे उन परिणामों को Pro प्लान पर सीधे Review ऐप में आयात कर सकते हैं, जिससे समीक्षक को दूसरा टूल नहीं खोलना पड़ता।
विफलता का मार्ग: जब कोई सत्यापन विफल होता है, तो कार्य विफलता आउटपुट के साथ वापस एजेंट के पास जाता है। एजेंट को वास्तविक टेस्ट या लिंट आउटपुट मिलता है, न कि कोई संक्षिप्त सारांश, और वह उसी worktree में पुनः प्रयास करता है। Jobs स्क्रीन इस दौरान एजेंट के आउटपुट और टूल कॉल को लाइव स्ट्रीम करती है।
Diff द्वार: सत्यापन पास होने और एक मानव द्वारा diff को मंजूरी देने के बाद ही Tendril पुल रिक्वेस्ट खोलता है। दोनों अनुमोदनों के बिना कुछ भी शिप नहीं होता है।

लागत को प्रति योजना और प्रति कार्य ट्रैक किया जाता है, इसलिए जिस योजना को पास होने से पहले तीन बार सत्यापन में विफलता मिली, वह दिखाती है कि पुनः प्रयासों में कितनी लागत आई। यह तय करने के लिए ठोस डेटा देता है कि क्या योजना द्वार को शुरुआत में ही अधिक सख्त होना चाहिए था।

शुरुआत कैसे करें

अपने वर्तमान द्वारों को सूचीबद्ध करें: अधिकांश टीमों को पता चलता है कि उनके पास टेस्ट और समीक्षा तो है, और लिंट कहीं चल रहा है लेकिन कोई नहीं जानता कि क्या वह बिल्ड को रोकता है।
Tendril इंस्टॉल करें: curl -sSf https://cdn.ivy.app/install-tendril.sh | sh (macOS, Linux) या irm https://cdn.ivy.app/install-tendril.ps1 | iex (Windows)। निर्देश इंस्टॉलेशन पर देखें।
संपूर्ण जीवनचक्र के माध्यम से एक योजना चलाएं और diff पढ़ने से पहले टेस्ट और लिंट टैब देखें। ध्यान दें कि केवल diff पढ़कर आप क्या चूक जाते।
अपनी योजना समीक्षा में एक स्कोप चेक जोड़ें: क्या एजेंट जिन फाइलों को छू सकता है उनकी सूची योजना से मेल खाती है?

Tendril मुफ़्त है और Functional Source License के तहत इसका सोर्स कोड उपलब्ध है। CI सत्यापन आयात, टीम सुविधाएँ, ऑन-प्रिमाइसेस होस्टिंग और SSO Pro और Enterprise योजनाओं पर उपलब्ध हैं।

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

क्या सत्यापन द्वारों को स्वचालित रूप से ब्लॉक करना चाहिए या केवल समीक्षक को सूचित करना चाहिए?

परीक्षण, लिंट, टाइप चेक और बिल्ड को अनिवार्य रूप से ब्लॉक करना चाहिए; किसी भी समीक्षक को ऐसे diff पर समय बर्बाद नहीं करना चाहिए जो संकलित (compile) भी नहीं होता। स्कोप और सुरक्षा चेतावनियों को स्वीकार करने के विकल्प के साथ समीक्षक को दिखाया जाना चाहिए, क्योंकि दोनों में कभी-कभी वैध अपवाद हो सकते हैं।

सत्यापन विफल होने पर एजेंट को कितने पुनः प्रयास मिलने चाहिए?

एक स्पष्ट सीमा निर्धारित करें और इसे रिकॉर्ड करें। बार-बार सत्यापन विफलता आमतौर पर योजना की समस्या होती है, निष्पादन की नहीं; पांचवें प्रयास के लिए पैसे खर्च करने के बजाय योजना को फिर से योजना चरण में भेजना बेहतर है। प्रति-कार्य लागत ट्रैकिंग पुनः प्रयास की लागत को पारदर्शी बनाती है।

यदि सभी स्वचालित द्वार पास हो जाते हैं तो क्या diff की मानवीय समीक्षा अभी भी मायने रखती है?

हाँ, बिल्कुल। स्वचालित द्वार केवल उसी चीज़ की जांच करते हैं जिसे पहले से कोड में निर्दिष्ट किया जा सकता है। वे यह जांच नहीं करते कि क्या परिवर्तन टिकट के वास्तविक उद्देश्य को पूरा करता है, क्या दृष्टिकोण भविष्य में बनाए रखने योग्य होगा, या क्या योजना स्वयं सही थी। इसीलिए diff चेकपॉइंट दो अनिवार्य मानवीय द्वारों में से एक है।

Ivy Tendril के साथ शुरुआत करें

क्या आप डेवलपर-स्तरीय समानांतर एजेंट ऑर्केस्ट्रेशन के लिए तैयार हैं?

कोड एक्सप्लोर करें: GitHub पर Ivy Tendril देखें (ओपन सोर्स)।
दस्तावेज़ पढ़ें: tendril.ivy.app पर इंटीग्रेशन गाइड पढ़ें।
आर्किटेक्चर सत्र शेड्यूल करें: 30 मिनट के तकनीकी परामर्श के लिए renco@ivy.app पर संपर्क करें।

सत्यापन द्वार: एजेंट कोड शिप होने से पहले क्या सच होना चाहिए