Ivy Tendril में, एक GitHub इश्यू चरणों के एक निश्चित क्रम के माध्यम से एक पुल रिक्वेस्ट (PR) में परिवर्तित हो जाता है: इश्यू वेबहुक द्वारा Inbox में आता है, एक एजेंट एक प्लान का ड्राफ्ट तैयार करता है, एक डेवलपर प्लान की समीक्षा करता है और उसे मंजूरी देता है, एक एजेंट इसे एक पृथक git worktree में निष्पादित करता है, स्वचालित सत्यापन चलता है, डेवलपर diff की समीक्षा करता है, और एक एजेंट पुल रिक्वेस्ट खोलता है। मनुष्य ठीक दो बिंदुओं पर हस्तक्षेप करते हैं: प्लान पर और diff पर। बाकी सब कुछ एजेंटों द्वारा किया जाता है, और एक ही समय में कई टिकट इस क्रम से आगे बढ़ते हैं। यह लेख एक टिकट के प्रत्येक चरण का अनुसरण करता है।
जीवन चक्र पर एक नज़र
Ivy इस वर्कफ़्लो को एक सॉफ्टवेयर फैक्ट्री (software factory) कहता है: चरणों का एक निश्चित क्रम जिसमें एजेंट काम करते हैं और मनुष्य निर्धारित बिंदुओं पर आउटपुट का निरीक्षण करते हैं। चरण, कौन कार्य करता है, और प्रत्येक चरण को समाप्त करने वाली शर्तें नीचे सूचीबद्ध हैं। पूर्ण संदर्भ लाइफसाइकिल दस्तावेज़ में उपलब्ध है।
| चरण | कर्ता | समाप्ति शर्त |
|---|---|---|
| Inbox | एजेंट (वेबहुक) | इश्यू अपने शीर्षक, विवरण, लेबल और लिंक के साथ संग्रहीत होता है |
| Draft plan | एजेंट (CreatePlan) | लक्ष्य, दायरे, फ़ाइलों और सत्यापन चरणों वाला एक ड्राफ्ट मौजूद होता है |
| Plan review (चेकपॉइंट 1) | मानव | डेवलपर किसी भी एनोटेशन और पुनर्लेखन के बाद प्लान को मंजूरी देता है |
| Execute | एजेंट (ExecutePlan) | एजेंट अपने worktree में प्लान के पूरा होने की रिपोर्ट करता है |
| Verify | एजेंट | टेस्ट और लिंट चल चुके हैं और diff समीक्षा के लिए तैयार है (सत्यापन गेट्स) |
| Diff review (चेकपॉइंट 2) | मानव | डेवलपर diff को मंजूरी देता है |
| Pull request | एजेंट (CreatePr) | Pull Requests REST API के माध्यम से प्लान की शाखा के लिए GitHub पर एक पुल रिक्वेस्ट मौजूद होता है |
| मर्ज और सफ़ाई | मानव मर्ज करता है, एजेंट सफ़ाई करता है | worktree हटा दिया जाता है और सीखों को मेमोरी में लिखा जाता है |
इश्यू से स्वीकृत प्लान तक
इश्यू का आगमन
एक उपयोगकर्ता रिपॉजिटरी में इश्यू #418 दर्ज करता है: "Export to CSV drops rows with commas in the description field." GitHub एकीकरण इसे वेबहुक द्वारा Tendril के Inbox में वितरित करता है। अभी कुछ भी निष्पादित नहीं होता है। Inbox आने वाले कार्यों की एक सूची है, और एक डेवलपर तय करता है कि उनमें से कौन से प्लान बनेंगे। jam.dev से आने वाली बग रिपोर्टें भी इसी तरह पहुँचती हैं।
CreatePlan एक ड्राफ्ट प्लान तैयार करता है
डेवलपर इश्यू का चयन करता है और Create plan चुनता है। CreatePlan promptware इश्यू, रिपॉजिटरी की अपनी मेमोरी और प्रासंगिक कोड को पढ़ता है, और एक ड्राफ्ट लिखता है। एक सामान्य ड्राफ्ट लक्ष्य, उन फ़ाइलों को जिन्हें बदलने की उम्मीद है (src/export/csv.ts और इसकी टेस्ट फ़ाइल), दृष्टिकोण (RFC 4180 के बाद डिलीमीटर वाले फ़ील्ड को कोट करना), और सत्यापन चरणों (विवरण में कॉमा के साथ एक टेस्ट जोड़ना, मौजूदा निर्यात टेस्ट चलाना) का विवरण देता है। ड्राफ्ट Drafts अनुभाग में दिखाई देता है।
चेकपॉइंट 1: डेवलपर प्लान की समीक्षा करता है
यह दो मानवीय चेकपॉइंट्स में से पहला है। डेवलपर ड्राफ्ट पढ़ता है और एक समस्या पाता है: प्लान केवल विवरण फ़ील्ड को कोट करने का प्रस्ताव करता है, लेकिन वही बग प्रत्येक फ़्री-टेक्स्ट कॉलम को प्रभावित करता है। हाथ से प्लान को दोबारा लिखने के बजाय, डेवलपर उस पैराग्राफ का चयन करता है और एक एनोटेशन जोड़ता है: "Apply the quoting to all string columns, not just description." UpdatePlan promptware एनोटेशन लागू करके प्लान को फिर से लिखता है, और संशोधित ड्राफ्ट एक और नज़र के लिए वापस आता है।
यदि ड्राफ्ट में विवरण की कमी है, तो डेवलपर ExpandPlan चला सकता है। यदि एनोटेशन दिखाते हैं कि टिकट वास्तव में दो कार्य हैं, उदाहरण के लिए एक सुधार और निर्यात मॉड्यूल का एक साझा CSV लाइब्रेरी में अलग माइग्रेशन, तो SplitPlan इसे दो स्वतंत्र प्लान्स में विभाजित करता है। जब डेवलपर संतुष्ट हो जाता है, तो वह स्वीकृति देता है। प्लान अब निष्पादन के लिए बाध्यकारी विनिर्देश बन जाता है, और एजेंट से मूल इश्यू की दोबारा व्याख्या करने के लिए नहीं कहा जाता है।
निष्पादन और सत्यापन
ExecutePlan एक पृथक worktree में चलता है
अनुमोदन मिलने पर, Tendril अपनी शाखा पर प्लान के लिए एक git worktree बनाता है और उसके अंदर चुने गए एजेंट को शुरू करता है। डेवलपर प्रति प्लान एजेंट चुनता है: Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode, या कोई अन्य CLI एजेंट। जो भी एजेंट चुना जाए, वर्कफ़्लो समान रहता है।
Worktree महत्वपूर्ण है क्योंकि अन्य प्लान उसी समय चल रहे होते हैं। प्रत्येक की अपनी कार्यशील निर्देशिका और शाखा होती है, इसलिए एक प्लान में अधूरा परिवर्तन दूसरे को प्रभावित नहीं कर सकता है, और मुख्य शाखा (main) समीक्षा तक अछूती रहती है। इस डिज़ाइन के कारण समानांतर AI एजेंटों के लिए git worktrees में शामिल हैं।
जब एजेंट काम करता है, तो Jobs इंटरफ़ेस इसके आउटपुट और टूल कॉल को स्ट्रीम करता है: पढ़ी गई फ़ाइलें, चलाए गए कमांड, निष्पादित परीक्षण, और अब तक खपत किए गए टोकन और लागत। डेवलपर देख सकता है, या किसी अन्य प्लान की समीक्षा कर सकता है और वापस आ सकता है। Cloudflare Quick Tunnel सक्षम होने पर, वही स्ट्रीम फ़ोन पर उपलब्ध होती है।
सत्यापन प्रक्रिया
जब एजेंट प्लान पूरा होने की रिपोर्ट करता है, तो worktree में सत्यापन चलता है: टेस्ट सुइट और लिंटर, जिसके परिणामस्वरूप उत्पन्न diff को समीक्षा के लिए एकत्र किया जाता है। परिणाम Review इंटरफ़ेस में तीन टैब के तहत दिखाए जाते हैं: tests, lint और diff। किसी भी इंसान द्वारा कोड पढ़ने में समय बिताने से पहले एक असफल टेस्ट या लिंट त्रुटि दिखाई दे जाती है। Pro और Enterprise प्लान CI से सत्यापन परिणाम भी आयात कर सकते हैं। सत्यापन को केवल एक सुझाव के बजाय एक द्वार (gate) के रूप में मानने का तर्क AI-जनरेटेड कोड के लिए सत्यापन गेट्स में दिया गया है।
समीक्षा, पुल रिक्वेस्ट और सफ़ाई
चेकपॉइंट 2: डेवलपर diff की समीक्षा करता है
यह दूसरा मानवीय चेकपॉइंट है। Review में, डेवलपर प्लान और सत्यापन परिणामों के साथ diff को पढ़ता है। इश्यू #418 के लिए, diff src/export/csv.ts को संशोधित करता है, एक कोटिंग हेल्पर जोड़ता है, और तीन मामलों के साथ टेस्ट फ़ाइल का विस्तार करता है: एक कॉमा, एक उद्धरण, और फ़ील्ड के अंदर एक नई पंक्ति। सभी परीक्षण पास हो जाते हैं और लिंट पूरी तरह साफ़ है। डेवलपर diff को मंजूरी देता है।
यदि diff स्वीकार्य नहीं है, तो डेवलपर अनुमोदन रोक देता है, प्लान को लापता आवश्यकताओं के साथ अपडेट करता है, और फिर से निष्पादित करता है। इस अनुमोदन के बिना कुछ भी GitHub तक नहीं पहुँचता है।
CreatePr पुल रिक्वेस्ट खोलता है
CreatePr promptware प्लान की शाखा से पुल रिक्वेस्ट खोलता है। यहाँ से, GitHub पर टीम की सामान्य समीक्षा और मर्ज प्रक्रिया लागू होती है। Tendril का Pull Requests इंटरफ़ेस इस तरह से बनाए गए प्रत्येक खुले PR की स्थिति को ट्रैक करता है।
मर्ज के बाद
जब PR मर्ज हो जाता है, तो Tendril worktree को हटा देता है। ExecutePlan promptware तब सीखे गए पाठों को मेमोरी में लिखता है। इस टिकट के लिए, एक प्रविष्टि जैसे "The export module has an integration test that needs the fixtures in test/fixtures/export/; run it with pnpm test:export" दर्ज की जाती है, और अगला प्लान जो निर्यात मॉड्यूल को छूता है, शुरू होने से पहले इसे पढ़ता है।
इस आकार के टिकट के लिए पूरा क्रम एजेंट समय के कुछ मिनट और मानव समय की दो छोटी समीक्षाएं लेता है। Ivy रिपोर्ट करता है कि इस वर्कफ़्लो को अपनाने के बाद, दोनों चेकपॉइंट्स को अपरिवर्तित रखते हुए, उसकी अपनी टीम लगभग 10 से बढ़कर प्रति दिन 100 से अधिक पुल रिक्वेस्ट तक पहुँच गई।
शुरुआत कैसे करें
Tendril इंस्टॉल करें, GitHub एकीकरण कनेक्ट करें ताकि इश्यू Inbox में आएं, और योजनाओं को समानांतर में चलाने से पहले एकल एजेंट के साथ इस क्रम के माध्यम से एक टिकट चलाएं।
curl -sSf https://cdn.ivy.app/install-tendril.sh | sh
Windows पर, irm https://cdn.ivy.app/install-tendril.ps1 | iex का उपयोग करें। मुफ़्त संस्करण, Functional Source License के तहत सोर्स-उपलब्ध, पूर्ण जीवन चक्र शामिल करता है। Pro और Enterprise टीम सुविधाएँ, CI से सत्यापन आयात, और ऑन-प्रिमाइसेस होस्टिंग जोड़ते हैं।
अक्सर पूछे जाने वाले प्रश्न
क्या परिवर्तन छोटा होने पर एजेंट चेकपॉइंट छोड़ सकता है?
नहीं। दो चेकपॉइंट हर प्लान पर लागू होते हैं। एक-पंक्ति का फिक्स किसी भी अन्य प्लान की तरह प्लान अनुमोदन और diff अनुमोदन से होकर गुजरता है। छोटे प्लान्स की समीक्षा में कम समय लगता है।
क्या होता है जब दो समानांतर प्लान एक ही फ़ाइल को बदलते हैं?
प्रत्येक प्लान अपने स्वयं के worktree और शाखा में काम करता है, इसलिए निष्पादन के दौरान कोई टकराव नहीं दिखाई देता है। यह तब प्रकट होता है जब दूसरे पुल रिक्वेस्ट को रीबेस या मर्ज किया जाता है, और इसे सामान्य git तरीके से हल किया जाता है। मॉड्यूल द्वारा प्लान्स को विभाजित करने से ऐसा होने की आवृत्ति कम हो जाती है।
क्या इश्यू का GitHub से आना अनिवार्य है?
नहीं। प्लान एक टाइप किए गए विचार, jam.dev बग रिपोर्ट, CLI, REST API या MCP सर्वर से शुरू हो सकते हैं। GitHub वेबहुक Inbox का केवल एक प्रवेश बिंदु है।
Ivy Tendril के साथ शुरुआत करें
क्या आप डेवलपर-स्तरीय समानांतर एजेंट ऑर्केस्ट्रेशन के लिए तैयार हैं?
- कोड एक्सप्लोर करें: GitHub पर Ivy Tendril देखें (ओपन सोर्स)।
- दस्तावेज़ पढ़ें: tendril.ivy.app पर इंटीग्रेशन गाइड पढ़ें।
- आर्किटेक्चर सत्र शेड्यूल करें: 30 मिनट के तकनीकी परामर्श के लिए renco@ivy.app पर संपर्क करें।