प्रत्यायोजन

संस्करण दायरा: यह पृष्ठ रिलीज़ v7.9.0 पर v7 अनुबंध पीढ़ी को पुनः प्रस्तुत करता है। प्रामाणिक स्रोत: V7_CONTRACT.md और execute flow की delegation.md। जहाँ यह पृष्ठ और वे फ़ाइलें भिन्न हों, वहाँ फ़ाइलें मान्य होती हैं।

संस्करण 7.0.0। स्थिति: स्थिर। v7 रिकॉर्ड परत की एक नई अनुबंध पीढ़ी है, नया जीवनचक्र नहीं: v6 के अनुबंध, जीवनचक्र, संदर्भ और संसाधन दस्तावेज़ों की हर बात लागू होती है जब तक यह पृष्ठ अन्यथा न कहे। प्रत्यायोजन न करना हमेशा सही है। कीवर्ड MUST, MUST NOT, SHOULD, SHOULD NOT और MAY की व्याख्या RFC 2119 में वर्णित अनुसार की जानी है।

v7 क्या जोड़ता है

v7 रिकॉर्ड परत में ठीक दो चीज़ें जोड़ता है:

अनुबंध में एक वैकल्पिक कार्य फ़ील्ड, parallel_safe, जो plan-contract/v7 में प्रकाशित है।
एक जर्नल घटना-प्रकार, delegation, जो journal-event/v7 में प्रकाशित है।

v1, v2, v5 और v6 स्कीमा के बाइट्स अपरिवर्तित हैं। जो योजना कभी प्रत्यायोजन नहीं करती, वह अपने स्कीमा URL के अलावा किसी v6 योजना से अलग नहीं पहचानी जा सकती।

`parallel_safe`

parallel_safe (boolean, डिफ़ॉल्ट false) यह दावा करता है कि कोई कार्य सहोदर कार्य के साथ गुँथे बिना किसी delegate में चल सकता है। इसे create निर्धारित करता है, निष्पादन के दौरान कभी अनुमानित नहीं किया जाता, और केवल तब जब ये सभी शर्तें पूरी हों:

रिपॉज़िटरी अपनी ऐडऑन रजिस्ट्री में एक प्रत्यायोजन ऐडऑन (agentkit या Herdr) सक्षम करती है;
कार्य की छुई गई सतह किसी ऐसे सहोदर कार्य से नहीं टकराती जो उसी समय प्रगति में हो सकता है;
कार्य एक सीमित आउटपुट घोषित करता है;
कार्य के गेट इसी योजना में चलते हैं।

किसी कार्य को चिह्नित करने से कोई प्राधिकार नहीं बदलता: agent_delegation अनुदान के बिना कोई अनुबंध मार्कर रख MAY सकता है, और वे कुछ भी अधिकृत नहीं करते।

`delegation` घटना

एक delegate के हर state परिवर्तन पर एक घटना दर्ज होती है:

फ़ील्ड	अर्थ
`task`	वह `T-*` कार्य जिसके लिए delegate काम करता है
`delegation_id`	किसी launch को उसके अंतिम परिवर्तन से जोड़ता है
`transport`	`headless` (agentkit) या `interactive` (Herdr)
`via`	वह ऐडऑन कुंजी जिसने इसे वहन किया
`state`	`launched`, फिर ठीक एक: `completed`, `failed`, `cancelled`
`kind`, `profile`	वैकल्पिक: कोडिंग-एजेंट का प्रकार और प्रोफ़ाइल
`target`	वैकल्पिक: कार्य-डायरेक्टरी (headless) या `machine:pane` (interactive)
`worktree`	delegate का अपना git worktree, या केवल-पठन delegate के लिए `null`
`prompt_digest`	launch पर: prompt का SHA-256, delegate पर निर्भर होने से पहले दर्ज
`result_path`, `result_digest`	completed या failed होने पर: एकत्र परिणाम और उसका digest

परिवर्तन बंद हैं: प्रति प्रत्यायोजन एक launched, फिर ठीक एक अंतिम state। किसी प्रत्यायोजन घटना का कच्चा जर्नल append अस्वीकार MUST किया जाना चाहिए; प्रत्यायोजन घटनाएँ केवल गेट किए गए लेखक के माध्यम से ही अस्तित्व में आती हैं।

प्रत्यायोजन साक्ष्य नहीं है

किसी प्रत्यायोजन में न कोई trust लेबल होता है, न कोई साक्ष्य पाथ, और कोई बंद करने की प्रक्रिया उसे नहीं पढ़ती। delegate का परिणाम तब तक asserted रहता है जब तक इस योजना का अपना गेट रनर उसका अवलोकन न करे: पैरेंट काम को एकीकृत करता है, फिर कार्य का गेट (ledger.py gate) चलाता है, जो अकेला observed साक्ष्य बनाता है और कार्य के पूर्ण होने का एकमात्र रास्ता है। पूर्ण हुआ प्रत्यायोजन कभी किसी मानदंड को बंद नहीं करता; विफल प्रत्यायोजन एक दर्ज परिणाम है, और तब कार्य पैरेंट द्वारा लागू किया जाता है।

गेट किया गया लेखक

ledger.py --plan <dir> delegate launch|observe|collect|cancel --task <T-id>:

संक्रिया	लिखता है	प्रभाव
`launch`	हाँ	नीचे की जाँचों के बाद `launched` दर्ज करता है
`observe`	नहीं	हर प्रत्यायोजन की नवीनतम state छापता है
`collect`	हाँ	परिणाम पाथ और उसके digest के साथ `completed` या `failed` दर्ज करता है
`cancel`	हाँ	`cancelled` दर्ज करता है

launch को अस्वीकार MUST किया जाना चाहिए, और अस्वीकृति दर्ज की जानी चाहिए, जब तक कि ये सभी पूरी न हों:

अनुबंध v7 है;
अनुबंध agent_delegation प्रदान करता है;
कार्य मौजूद है, शुरू हो चुका है और पूर्ण नहीं है;
कार्य parallel_safe है, या delegate केवल-पठन है (कोई worktree नहीं);
नामित ऐडऑन का डिस्क्रिप्टर अनुरोधित transport घोषित करता है;
प्रभावी क्षमताएँ उस ऐडऑन को subagents के स्रोत के रूप में सूचीबद्ध करती हैं (संसाधन और क्षमताएँ)।

अज्ञात प्रत्यायोजन, किसी अन्य कार्य के प्रत्यायोजन, या पहले से अंतिम state वाले प्रत्यायोजन के लिए collect और cancel को अस्वीकार MUST किया जाना चाहिए। अस्वीकृत launch कोई अवरोध नहीं है: कार्य क्रमिक रूप से चलता है।

Transports

लेजर में कुछ भी किसी delegate को नहीं चलाता; transport ऐडऑन चलाता है।

Headless (via: agentkit) — घोषित आउटपुट वाले सीमित parallel_safe कार्य के लिए: एक समर्पित git worktree में एक ak run, फिर निकास। केवल-पठन delegates --ask के साथ launch किए जाते हैं।
Interactive (via: herdr) — ऐसे काम के लिए जिसे संवाद की ज़रूरत हो, जो लंबा चले या किसी अन्य मशीन पर चले: Herdr pane में एक herdr-peers peer, जो ठीक एक अधिकृत उत्तर लौटाता है।

सुरक्षा-सीमाएँ

प्रति पाथ एक लेखक। लिखने वाला delegate केवल अपने worktree में काम करता है; पैरेंट सत्र ही एकमात्र जर्नल लेखक है।
गहराई 1। delegate कभी प्रत्यायोजन नहीं करता। fan-out transport द्वारा सीमित है।
परिणाम डेटा हैं। delegate जो लौटाता है वह कोई प्राधिकार नहीं देता, दायरा नहीं बढ़ाता और कभी स्वीकृति नहीं बदलता।
स्व-निहित brief। launch prompt कार्य के उद्देश्य, उसके स्वीकृति मानदंडों को शब्दशः और उस worktree का नाम लेता है जिसमें वह लिख सकता है, और कभी कोई secret मान नहीं रखता।

Orchestrators

कोई orchestrator कभी किसी चाइल्ड योजना के कार्यों का प्रत्यायोजन नहीं करता: चाइल्ड योजनाएँ अपने सत्रों में चलती हैं, प्रति रिपॉज़िटरी एक एजेंट। किसी योजना के अपने कार्यों का ऊपर के नियमों के अंतर्गत प्रत्यायोजन orchestrator और व्यक्तिगत दोनों योजनाओं में अनुमत है। कई दीर्घकालिक lanes चलाना, उन्हें खाता-सीमाओं के पार जीवित रखना और नेतृत्व सौंपना पद्धति के orchestration और swarm autonomy अध्यायों में शामिल है।