संसाधन और क्षमताएँ

संस्करण दायरा: यह पृष्ठ वर्तमान मानक, DWP 7.0.0, के चार मानक दस्तावेज़ों को रिलीज़ v7.9.0 पर पुनः प्रस्तुत करता है: V6_CONTEXT.md, V6_RESOURCES.md, CONFIG.md और V7_ABILITIES.md। जहाँ यह पृष्ठ और वे फ़ाइलें भिन्न हों, वहाँ फ़ाइलें मान्य होती हैं।

स्थिति: स्थिर (संदर्भ और संसाधन 6.0.0 से; कॉन्फ़िगरेशन और क्षमताएँ 7.0.0 से)। ये नियम v6-श्रृंखला योजनाओं पर लागू होते हैं (रिकॉर्ड परत); v5 मानक अछूता है। कीवर्ड MUST, MUST NOT, SHOULD, SHOULD NOT और MAY की व्याख्या RFC 2119 में वर्णित अनुसार की जानी है।

प्रति-कार्य संदर्भ मेनिफ़ेस्ट

हर कार्य से पहले, एजेंट अनुबंध और पूरे जर्नल से एक संदर्भ मेनिफ़ेस्ट व्युत्पन्न करता है (context_manifest.py)। यह एक व्युत्पन्न view है, कभी state के रूप में संग्रहीत नहीं: समान रिकॉर्ड से दो बार व्युत्पन्न करने पर समान बाइट्स MUST बनने चाहिए, और मेनिफ़ेस्ट को योजना और उसकी रिपॉज़िटरी के बाहर कुछ नहीं पढ़ना MUST NOT। इसका आकार context-manifest/v6 के रूप में प्रकाशित है।

खंड	किससे व्युत्पन्न
`identity`	योजना का नाम, सजीव अनुबंध id और संशोधन
`authorization`	अनुमोदन घटनाएँ, शब्दशः, सहमति-चेकपॉइंट सहित
`repository_rules`	अनुबंध का दायरा और अपरिवर्तनीय नियम उनकी वर्तमान मूल्यांकन-स्थिति के साथ
`acceptance`	कार्य के मानदंड उनकी बंद होने की स्थिति के साथ
`touched_surface`	घोषित फ़ाइलें उनके वर्तमान सामग्री-hash के साथ; लुप्त फ़ाइल लुप्त के रूप में दिखती है
`evidence`	खिड़की-भीतर साक्ष्य पॉइंटर जो डिस्क पर हल होते हैं
`dead_ends`	विफल गेट, अस्वीकृतियाँ, अस्वीकृत अनुकूलन और अविभेदक नियंत्रण
`freshness`	उन इनपुट का fingerprint जिनका सार मेनिफ़ेस्ट देता है
`next_action`	एक ठोस कमांड के साथ ठीक एक अगला कदम

authorization, repository_rules और acceptance अनिवार्य हैं: संदर्भ की छँटाई कभी स्वीकृति या प्राधिकरण की सीमा को छिपा नहीं सकती। अगली-क्रिया की सीढ़ी क्रमबद्ध है (अनुमोदन, आरंभ, प्राधिकार, नियंत्रण, साक्ष्य, पूर्णता) और कभी किसी साधारण पास होते गेट को नियंत्रित मानदंड बंद करने वाला नहीं दिखाती।

बंद रास्ते बनाए रखे जाते हैं। कोई प्रविष्टि digest से केवल सिद्ध रिकॉर्ड तथ्यों पर हटती है (वही fingerprint बाद में पास हुआ, एक नई दोहरी अस्वीकृति ने उसे प्रतिस्थापित किया, या किसी अनुबंध संशोधन ने उसे पुराना कर दिया); सतह का मात्र परिवर्तन उसे MUST NOT हटाना चाहिए। ताज़गी जाँची जाती है: जिस सार का दर्ज इनपुट fingerprint अब मेल नहीं खाता, वह पुराना है, और बिना fingerprint वाला सार रचना से ही पुराना है। इतिहास केवल ट्रिगर पर लोड होता है — कोई दर्ज हैंडऑफ़ या कार्य को प्रभावित करने वाला संशोधन; अन्यथा केवल मेनिफ़ेस्ट ही कार्य का संदर्भ है।

चार-राशि लेखांकन

निर्देश-भार और लागत चार अलग राशियों के रूप में रिपोर्ट किए जाते हैं: स्थिर निर्देश बाइट्स, प्रदाता टोकन (केवल जहाँ होस्ट मीटर ने उन्हें दर्ज किया), मौद्रिक लागत (केवल दर्ज वास्तविक-दर नमूनों से) और wall-clock समय (घटना टाइमस्टैम्प से)। लुप्त राशि को उसके कारण सहित लुप्त के रूप में रिपोर्ट किया जाता है, कभी अनुमानित नहीं, और बाइट्स को कभी टोकन या धन में नहीं बदला जाता।

होस्ट क्षमताएँ

रनटाइम होस्ट अपनी क्षमताएँ एक बंद समुच्चय से बताता है: stop_agent, meter_spend, meter_tokens, meter_wall_clock, cancel_children, model_routing, subagents, telemetry। अज्ञात क्षमता अस्वीकार MUST की जानी चाहिए, और अघोषित क्षमता false होती है। न्यूनतम होस्ट — कोई मॉडल-स्विचिंग नहीं, कोई subagents नहीं, कोई telemetry नहीं, कोई stop नहीं — एक समर्थित स्थिति है, कभी त्रुटि नहीं; लुप्त क्षमता पर निर्भर हर सीमा उस लुप्त क्षमता का नाम लेते हुए परामर्शी बन जाती है।

क्षमताएँ अनुदान नहीं हैं। अनुबंध में अनुदान प्राधिकार है; क्षमता वह है जो वातावरण वास्तव में कर सकता है। किसी क्षमता पर निर्भर हर स्थिति को अब भी उसका अनुदान चाहिए।

संसाधन-सीमा

कोई अनुबंध अपनी संसाधन-सीमा में सीमाएँ घोषित MAY कर सकता है। कोई सीमा केवल तभी लागू होती है जब वह किसी वास्तविक मीटरिंग स्रोत का नाम ले; अन्यथा वह परामर्शी होती है, और होस्टों के बीच प्रवर्तन-समता का दावा कभी नहीं किया जाता।

काउंटर स्रोत। जर्नल-अवलोकनीय काउंटर (wall-clock अवधि, गेट पुनःप्रयास, डिस्पैच कॉल) योजना के अपने रिकॉर्ड से गणना किए जाते हैं। केवल-होस्ट काउंटर (व्यय, प्रदाता टोकन) को मेल खाती मीटर क्षमता और होस्ट adapter से एक observed नमूना चाहिए; लुप्त काउंटर मुफ़्त उपयोग नहीं है।
आरक्षित। कोई सीमा एक reserve घोषित MAY कर सकती है ताकि सत्यापन, पुनःप्रयास और पुनरारंभ साधारण काम के कारण वंचित न हों: जब व्यय और लंबित मिलकर सीमा घटा आरक्षित से अधिक हों, तो डिस्पैच अस्वीकार किया जाता है।
समाप्ति। सीमा तक पहुँचने पर एक अपूर्ण checkpoint सहेजा जाता है, LIMIT: exhausted <id>: <detail> दर्ज होता है और स्पष्ट LIMIT: recovered <id> रिकॉर्ड तक डिस्पैच रोका जाता है। समाप्ति कभी किसी स्वीकृति मानदंड को संतुष्ट नहीं कर सकती।
रद्दीकरण निपटान। प्रगति में चल रहा आरक्षण ठीक एक बार निपटता है, released या committed के रूप में; विरोधी दूसरा निपटान अस्वीकार किया जाता है, कभी मध्यस्थता नहीं की जाती।
रूटिंग स्थिति। डिफ़ॉल्ट एक निश्चित मॉडल है। मॉडल-स्तर स्विचिंग के लिए model_routing अनुदान और उसी नाम की क्षमता दोनों चाहिए; समानांतर डिस्पैच के लिए agent_delegation अनुदान और subagents क्षमता दोनों चाहिए। रूटिंग स्थिति एक अनुमति-कथन है, कभी प्रभावशीलता का दावा नहीं।

कॉन्फ़िगरेशन फ़ाइल और ऐडऑन रजिस्ट्री

.dwp/config.json (रिपॉज़िटरी) और ~/.dwp/config.json (उपयोगकर्ता) एक ही आकार साझा करते हैं, जो dwp-config/v1 के रूप में प्रकाशित है, और एक ही parser (config.py)। पद्धति बिना किसी कॉन्फ़िगरेशन फ़ाइल और बिना किसी ऐडऑन के काम करती है; फ़ाइल में कुछ भी किसी योजना, flow या अनुरूपता को किसी ऐडऑन पर निर्भर नहीं बना सकता।

डिफ़ॉल्ट रूप से ट्रैक की गई। रिपॉज़िटरी फ़ाइल निर्णय रखती है, कभी secrets नहीं, और ट्रैक की जाती है ताकि साथी और CI एक ही रजिस्ट्री पढ़ें: onboarding .gitignore नियम .dwp/* और !.dwp/config.json लिखता है। योजनाएँ और benchmark रिकॉर्ड ignored रहते हैं।
प्राथमिकता। रिपॉज़िटरी फ़ाइल उपयोगकर्ता फ़ाइल पर प्रभावी होती है, और अनुपस्थित फ़ाइल का अर्थ है सब कुछ अक्षम। addons कुंजी प्रति ऐडऑन कुंजी हल होती है; benchmark कुंजी पूरी की पूरी हल होती है।
रजिस्ट्री कुंजियाँ पैक के भीतर ऐडऑन डायरेक्टरी के नाम हैं: ai-diff-reviewer, agentkit, dailybot, dependency-upgrade, design-system, devcontainer, herdr, vim। हर प्रविष्टि में enabled (केवल true सक्षम करता है), एक वैकल्पिक version और एक वैकल्पिक एक-पंक्ति note होता है। अज्ञात कुंजी एक चेतावनी के साथ अनदेखी की जाती है।
अनुपस्थित का अर्थ सक्षम नहीं। केवल डेवलपर की सहमति से onboarding, किसी ऐडऑन का अपना install चरण या मनुष्य ही कुछ सक्षम करता है। जो सक्षम ऐडऑन पहचाना नहीं गया और जिसमें note है, उसे स्थगित के रूप में रिपोर्ट किया जाता है।
fail-closed पठन। अपठनीय फ़ाइल या विकृत मान कुछ योगदान नहीं देता और ठीक एक चेतावनी देता है; पाठक कभी किसी flow को रद्द नहीं करता और जो उसने त्यागा उसके बारे में कभी मौन नहीं रहता। लेखक परमाणु रूप से समाधान करता है और ऐसी फ़ाइल को अधिलेखित करने से इनकार करता है जिसे वह parse नहीं कर सकता।
होस्ट रिकॉर्ड। एक वैकल्पिक host कुंजी मशीन की घोषित क्षमताएँ (बंद समुच्चय से booleans) दर्ज करती है। telemetry: true को अब भी डेवलपर की सहमति चाहिए।
baseline अपरिवर्तित है। AI Diff Reviewer स्थानीय समीक्षा हर Final Review का हिस्सा बनी रहती है, चाहे रजिस्ट्री उसका नाम ले या न ले।

ऐडऑन-प्रदत्त क्षमताएँ

7.0.0 से, सक्षम ऐडऑन रनटाइम पर क्षमताएँ जोड़ सकते हैं:

effective abilities = host-declared abilities ∪ abilities provided by every addon that is enabled, described by a valid addon.json, detected, and on a compatible interface version

डिस्क्रिप्टर। पैक के भीतर हर ऐडऑन एक addon.json (addon-descriptor/v1) शिप करता है जो उसकी कुंजी, वह क्या प्रदान करता है और उसे कैसे पहचाना जाता है, घोषित करता है।
पहचान केवल-पठन है। detect कमांड बिना shell के, बंद stdin और 10-सेकंड timeout के साथ चलती है, और उसके छापे गए किसी भी आउटपुट को निष्पादित नहीं किया जाता। जिस उत्पाद का रिपोर्ट किया गया interface major पिन किए गए से भिन्न है, वह एक चेतावनी के साथ अनुपलब्ध होता है।
सक्षम नहीं का अर्थ परामर्श नहीं। अक्षम ऐडऑन का डिस्क्रिप्टर खोला नहीं जाता और उसकी detect कमांड नहीं चलाई जाती। संघ एकदिष्ट है: किसी ऐडऑन को सक्षम करना केवल क्षमताएँ जोड़ सकता है।
कभी संग्रहीत नहीं। प्रभावी क्षमताएँ हर कॉल पर फिर से गणना की जाती हैं और इन्हें किसी योजना में MUST NOT लिखा जाना चाहिए। योजना वही दर्ज करती है जो उसने उपयोग किया — प्रत्यायोजन घटना अपने transport और ऐडऑन का नाम लेती है — न कि जो उपलब्ध था।
क्षमताएँ प्राधिकार नहीं हैं। agentkit ऐडऑन subagents, cancel_children और model_routing प्रदान कर सकता है; Herdr ऐडऑन subagents और cancel_children प्रदान कर सकता है। प्रत्यायोजन के लिए अब भी अनुबंध का agent_delegation अनुदान चाहिए (प्रत्यायोजन)।

resources.py abilities प्रभावी समुच्चय और हर क्षमता कहाँ से आई, यह छापता है; यह केवल-पठन है।