सामान्य प्रश्न

Deep Work Plan किसी रिपॉज़िटरी को एक संरचित वातावरण में बदल देता है जहाँ कोडिंग एजेंट लंबे कार्य भरोसेमंद ढंग से निष्पादित कर सकता है। यह एक एजेंट स्किल के रूप में इंस्टॉल होता है, रिपॉज़िटरी को एक बार ऑनबोर्ड करता है (एक `AGENTS.md` इंडेक्स, एक `docs/` वृक्ष, स्किल्स और कमांड्स की एक `.agents/` किट, एक gitignored `.dwp/` आउटपुट क्षेत्र), और तब से कोई भी लक्ष्य एक योजना बन जाता है: परमाणु कार्य, हर एक के साथ स्वीकृति मानदंड और एक सत्यापन द्वार, एक-एक करके निष्पादित, पास होने पर कमिट, और डिस्क से किसी भी एजेंट के लिए पुनः शुरू करने योग्य। योजना एक Final Review के साथ बंद होती है जो सुरक्षा की ऑडिट करता है और अंतिम स्थिति को सत्यापित करता है। पद्धति MIT-लाइसेंस प्राप्त है और किसी भी कोडिंग एजेंट के साथ काम करती है जो रिपॉज़िटरी पढ़ता है।

पद्धति पढ़ें

उन डेवलपर्स और टीमों के लिए जो कोडिंग एजेंटों को वास्तविक, बहु-चरणीय कार्य सौंपते हैं और चाहते हैं कि वह पूरा हो। यह तब फ़िट बैठता है जब कोई कार्य एक सत्र से अधिक, एक फ़ाइल-परिवार से अधिक, या एक एजेंट से अधिक फैला हो; जब किसी सहयोगी को वहाँ से आगे बढ़ने में सक्षम होना चाहिए जहाँ एजेंट रुका था; या जब "पूर्ण" का अर्थ "सत्यापित" होना चाहिए, "एजेंट ने ऐसा कहा" नहीं। एक-पंक्ति का सुधार योजना की माँग नहीं करता, और पद्धति खुद यही कहती है: उसका आनुपातिक-कठोरता नियम उसके बदले एक इनलाइन लक्ष्य, मानदंड और द्वार की सिफ़ारिश करता है।

त्वरित शुरुआत

यह एक प्रस्तुति-विकल्प है, कठोरता का समझौता नहीं। योजनाएँ डिफ़ॉल्ट रूप से Lite होती हैं: anchored कार्य-रिकॉर्ड्स वाला एक संक्षिप्त README जो पहले से ही निष्पादन योग्य है, कोई आंशिक ड्राफ्ट नहीं। यदि आप शुरू से ही एक Full योजना माँगते हैं, तो `create` सीधे Full कार्य फ़ाइलें लिखता है; और जब किसी कार्य का निर्देश-विवरण, निर्भरताएँ या अनुबंध किसी समीक्षा योग्य संक्षिप्त रिकॉर्ड में फ़िट न बैठें तो योजना को Full में विस्तारित कर देता है। बाद का उन्नयन प्रत्येक पूर्ण किए गए कार्य को बनाए रखता है। दोनों प्रारूप समान स्वीकृति मानदंड, सत्यापन द्वार, साक्ष्य और अनिवार्य Final Review ले जाते हैं।

पद्धति पढ़ें

एक पद्धति, जो इंस्टॉल करने योग्य स्किल के रूप में पैक की गई है। कोई सर्वर नहीं, कोई खाता नहीं, कोई स्वामित्व-प्रारूप नहीं, और आपके मौजूदा कोडिंग एजेंट के अलावा कोई रनटाइम नहीं। जो इंस्टॉल होता है वह है एजेंट द्वारा पढ़े जाने वाले निर्देश, संदर्भ-पहचान और अनुरूपता-जाँच के लिए शेल स्क्रिप्ट्स का एक छोटा समूह, और वे परंपराएँ जो आपकी रिपॉज़िटरी अपनाती है। योजना जो कुछ भी उत्पन्न करती है वह आपकी रिपॉज़िटरी में Markdown और JSON है, बिना किसी उपकरण के पठनीय।

विनिर्देश पढ़ें

कोई भी एजेंट जो रिपॉज़िटरी फ़ाइलें पढ़ता है। स्किल खुले Agent Skills मानक और `AGENTS.md` परंपरा का पालन करती है, इसलिए Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot और अन्य इसे अपनी सामान्य स्किल और निर्देश लोडिंग से उठा लेते हैं। पद्धति का अपना मूल्यांकन दिखाता है कि एक वेंडर के एजेंट द्वारा शुरू की गई योजना दूसरे वेंडर के एजेंट द्वारा दोनों दिशाओं में फिर से शुरू की जा सकती है। इंस्टॉलेशन कवरेज और व्यवहारिक साक्ष्य अनुकूलता मैट्रिक्स में प्रति-एजेंट सूचीबद्ध हैं, और दोनों को कभी एक नहीं मान लिया जाता।

किट देखें

तीन चरण। पहले, Deep Work Plan स्किल को अपने coding agent में इंस्टॉल करें — सबसे तेज़ रास्ता `npx skills add DailybotHQ/deepworkplan-skill` है (या skill repo क्लोन करें और `./setup.sh` चलाएँ)। दूसरे, रिपॉज़िटरी को एक बार onboard करें ताकि एजेंट `AGENTS.md`, `docs/`, `.agents/` किट और gitignore की गई `.dwp/` क्षेत्र को आपके stack के अनुसार ढाले: https://deepworkplan.com/init.md पर इशारा करें, या `/deepworkplan-onboard` चलाएँ। तीसरे, पतले commands से काम की योजना बनाएँ और चलाएँ: `/dwp-create <goal>` योजना बनाता है; `/dwp-execute` प्रत्येक gate के विरुद्ध कार्य-दर-कार्य चलाता है; `/dwp-refine` एक चल रही योजना को संपादित करता है (scope, कार्य, या किसी Lite योजना को Full में उन्नत करना); `/dwp-resume` रुकावट के बाद जारी रखता है; `/dwp-status` बिना निष्पादन प्रगति रिपोर्ट करता है; `/dwp-verify` एक वस्तुनिष्ठ अनुरूपता रिपोर्ट तैयार करता है; `/dwp-upgrade` इंस्टॉल की गई स्किल को मौजूदा योजनाओं को छुए बिना एक नए रिलीज़ पर ले जाता है। `/` को intercept करने वाले एजेंट अक्सर `#` का उपयोग करते हैं (उदाहरण `#dwp-execute`)। adoption endpoint और त्वरित शुरुआत उसी रास्ते को अधिक विस्तार से बताते हैं।

त्वरित शुरुआत

एजेंट स्किल वहीं इंस्टॉल होती है जहाँ आपका एजेंट प्रोजेक्ट या यूज़र स्किल्स लोड करता है। इसके बाद ऑनबोर्डिंग रिपॉज़िटरी को स्वयं ढालती है: यह `AGENTS.md`, `docs/`, `.agents/` और gitignored `.dwp/` कार्यक्षेत्र बनाती या सुलझाती है। स्किल एजेंट को पद्धति सिखाती है; रिपॉज़िटरी वह संदर्भ, किट और योजना-साक्ष्य रखती है जिनकी अन्य एजेंटों को जारी रखने के लिए आवश्यकता होती है।

अपनाने का प्रवाह देखें

रिपॉज़िटरी के लिए Git की सिफ़ारिश की जाती है क्योंकि उसका इतिहास पुनर्प्राप्ति और समीक्षा सतह का हिस्सा है, लेकिन पद्धति बिना Git रिपॉज़िटरी के भी किसी एजेंट कार्यक्षेत्र में चल सकती है। उस स्थिति में मशीन-पठनीय state परत — जिसमें `state.json` checkpoints और gate रिकॉर्ड शामिल हैं — आवश्यक होती है ताकि पुनर्प्राप्ति किसी चैट ट्रांसक्रिप्ट पर निर्भर न रहे।

रिपॉज़िटरी आर्किटाइप्स के बारे में पढ़ें

स्किल वर्णन करती है कि एजेंट कोई दोहराने योग्य प्रक्रिया कैसे निष्पादित करता है। एक DWP योजना scope, स्वीकृति मानदंड, सत्यापन द्वार और साक्ष्य के माध्यम से किसी ठोस बदलाव का वर्णन करती है। प्रोडक्ट विनिर्देश प्रोडक्ट के वर्तमान व्यवहार का वर्णन करता है और कार्यान्वयन के बाद deltas के माध्यम से विकसित होता है; स्किल्स और योजनाएँ भी विनिर्देश हैं, लेकिन वे उस विहित प्रोडक्ट-अनुबंध को बनाए रखने के बजाय प्रक्रियाओं और बदलावों का वर्णन करती हैं।

विनिर्देश पढ़ें

वे निष्पादन योग्य अभिकथन हैं जो एजेंट खुद चलाता है। मानवीय स्वीकृति रन के दोनों सिरों पर रहती है: एक व्यक्ति निष्पादन से पहले योजना को स्वीकृति देता है और pull-request के समय अंतिम diff की समीक्षा करता है; बीच का निष्पादन स्वायत्त होता है। हर कार्य ठोस कमांड्स नामित करता है, सामान्यतः रिपॉज़िटरी का अपना गुणवत्ता-द्वार, कार्य की छुई सतह से चुना गया: बदले गए व्यवहार और उसके उपभोक्ताओं की जाँचें, और जब बदलाव साझा हो या सीमाबद्ध न किया जा सके तो पूरे सूट तक विस्तारित। कार्य तभी पूर्ण चिह्नित होता है जब वे कमांड्स सफलतापूर्वक एग्ज़िट करें, और व्यवहार बदलने वाले कार्यों को जाँचें बढ़ानी होती हैं। विफलता पर एजेंट पहले उसे ठीक करता है जो कार्य के अपने दायरे में आता है और द्वार को फिर से चलाता है; जो विफलता उस दायरे में ठीक न हो सके, वह कार्य को अवरुद्ध चिह्नित छोड़ देती है और रन रुक जाता है।

मुख्य चक्र

तीन मोर्चों पर। कार्य व्यवहार के रूप में लिखे जाते हैं, संपादनों के रूप में नहीं: स्वीकृति मानदंड कहता है कि सिस्टम को क्या करना चाहिए, इसलिए पुनः नामित फ़ाइल या बदला गया कार्यान्वयन उसे अमान्य नहीं करता। हर द्वार रिपॉज़िटरी के वर्तमान रूप के विरुद्ध फिर से चलता है, इसलिए टूटी मान्यता चुपचाप भटकने के बजाय अगले रन पर ज़ोर से विफल होती है, और वही विफलता परिशोधन का संकेत है। और दस्तावेज़ीकरण को सिंक रखना काम का हिस्सा है: व्यवहार बदलने वाला कार्य उन docs और एजेंट-अभिमुख किट को भी अद्यतन करता है जो उसका वर्णन करते हैं, अपने ही द्वार के भीतर। हर रन रिपॉज़िटरी को उससे अधिक एजेंट-तैयार छोड़ना चाहिए जितना उसने पाया था।

पद्धति पढ़ें

हाँ; आंशिक रूप से निष्पादित योजना का परिशोधन एक प्रथम-श्रेणी कदम है। कार्य परिभाषाएँ और निष्पादन स्थिति अलग रखी जाती हैं: योजना डिस्क पर एक चेकलिस्ट और एक छोटी state फ़ाइल है, इसलिए जो पूर्ण है वह कार्य-पाठ से स्वतंत्र रूप से दर्ज रहता है। जब कोई कार्य ग़लत साबित होता है, तो एजेंट उसे अवरुद्ध चिह्नित करके रुक जाता है, ज़बरदस्ती आगे नहीं बढ़ता। फिर आप उन कार्यों को संपादित, पुनः क्रमित, विभाजित या हटा सकते हैं जो अभी नहीं चले, जबकि पूर्ण कार्य पूर्ण रहते हैं। पुनरारंभ डिस्क और वास्तविक रिपॉज़िटरी से स्थिति का पुनर्निर्माण करता है और जिन द्वारों का महत्व है उन्हें फिर से चलाता है, इसलिए नीचे जो कुछ खिसका वह चुपचाप नहीं निकलता।

मुख्य चक्र

योजना एक सतत जाँच है। एजेंट एक समय में एक छोटा कार्य करता है और आगे बढ़ने से पहले उसे सत्यापित करना होता है, इसलिए वह एक कदम भटक सकता है, तीन नहीं। हर कार्य स्वीकृति मानदंडों के साथ उन सटीक कमांड्स को भी ले जाता है जो उन्हें सिद्ध करते हैं, और प्रगति प्रति-कार्य स्थिति के साथ रिपॉज़िटरी में लिखी जाती रहती है, इसलिए भटकाव आपको, अगले सत्र को और अगले एजेंट को दिखाई देने लगता है। जब तक सब कुछ सत्यापित नहीं हो जाता — Final Review सहित — योजना पूरी नहीं होती। ईमानदार चेतावनी: पद्धति किसी एजेंट को पहली जगह कमज़ोर स्वीकृति मानदंड लिखने से नहीं रोक सकती; वह भटकाव को चुप के बजाय शोरदार बना देती है।

मुख्य चक्र

दोनों में से कोई नहीं। यह एक लक्ष्य से एक बार उत्पन्न होती है और फिर काम के हिस्से के रूप में अनुरक्षित होती है। योजना जानबूझकर code diffs से पुनः नहीं लिखी जाती, क्योंकि कोड का पीछा करने वाला विनिर्देश एक पिछड़ा आईना बन जाता है — वही भटकाव है जिसे समाप्त करने के लिए पद्धति अस्तित्व में है। यह जानबूझकर विकसित होती है: द्वार वर्तमान रिपॉज़िटरी के विरुद्ध फिर से चलते हैं, एक विफल द्वार परिशोधन को जन्म देता है, और एजेंट वह परिशोधन रन के दौरान करता है जबकि आप शुरू में स्वीकृति देते हैं और अंत में समीक्षा करते हैं। दस्तावेज़ीकरण और जाँचें निर्माण-से ही कोड के साथ विकसित होते हैं, क्योंकि उन्हें अद्यतन करना हर कार्य के द्वार के भीतर है।

पद्धति पढ़ें

प्रगति डिस्क पर रहती है, चैट में नहीं। README चेकबॉक्सेस, हर कार्य का लॉग, एक सीमाबद्ध कार्यशील इंडेक्स और एक मशीन-पठनीय state फ़ाइल हर कार्य-सीमा पर अद्यतन होते हैं, और state फ़ाइल किसी भी योजनाबद्ध ठहराव से पहले एक checkpoint दर्ज करती है। एक नया सत्र, या कोई भिन्न एजेंट, वह संक्षिप्त इंडेक्स पढ़ता है, उसे रिपॉज़िटरी और git इतिहास से सुलझाता है, और पूर्ण कार्य दोहराए बिना पहले अपूर्ण कार्य पर जारी रहता है। बाधित योजना-निर्माण भी पुनर्प्राप्त योग्य है: योजना की पहचान और अभीष्ट कार्य-सूची किसी भी कार्य फ़ाइल से पहले लिखी जाती है, इसलिए अधूरी योजना के बारे में अनुमान लगाने के बजाय उसे पूरा या त्यागा जा सकता है।

मुख्य चक्र

हर योजना का एकमात्र अनिवार्य समापन कार्य। क्रम से: योजना के पूरे संचित बदलाव-समुच्चय पर एक सुरक्षा-जाँच, जिसमें AI Diff Reviewer स्किल द्वारा diff की अनिवार्य स्थानीय समीक्षा शामिल है, और गंभीर निष्कर्ष सुधार या स्पष्ट स्वीकृति तक पूर्णता को अवरुद्ध करते हैं; अंतिम-स्थिति सत्यापन, यानी अंतिम कोड पर रिपॉज़िटरी के सभी लागू test, lint, type-check और format सूट; और हर कार्य द्वारा दर्ज स्किल्स निर्णयों का एक समाधान। इसके बाद एजेंट डिलिवरेबल्स, साक्ष्य और सीमाओं की रिपोर्ट देता है, और एक बार कार्यकारी रिपोर्ट का प्रस्ताव देता है — केवल आपके कहने पर उसे उत्पन्न करता है।

विनिर्देश

विफल द्वार सबसे पहले मरम्मत का संकेत है: एजेंट उसे ठीक करता है जो कार्य के अपने दायरे में आता है और द्वार को फिर से चलाता है। उस दायरे से बड़ी विफलता कार्य को अवरुद्ध दर्ज करती है, और एजेंट पूर्णता का दावा करने से पहले रुक जाता है। आप साक्ष्य का निरीक्षण कर सकते हैं, कोड की मरम्मत कर सकते हैं या कार्य को परिशोधित कर सकते हैं, फिर पुनरारंभ कर सकते हैं; एक विफल कमांड बेमेल को सुलझाने का संकेत है, द्वार को कमज़ोर करने की अनुमति नहीं।

एजेंट प्रोटोकॉल पढ़ें

यह इसे साफ़ कह देता है। परीक्षक exit code 2 और एक स्पष्ट `UNVERIFIED` निर्णय के साथ समाप्त होता है — यह कभी ऐसा “पास” नहीं छापता जिसे उसने वास्तव में सत्यापित नहीं किया। जब environment में सक्षम interpreter की कमी हो या कोई जाँच न चल सके, तो ईमानदार परिणाम “सत्यापित नहीं” है, “अनुरूप” नहीं; हरा परिणाम हमेशा यही माने कि हर जाँच चली और पास हुई। वही अनुशासन पूरी पद्धति में फैला है: कोई भी flow पूर्णता का दावा करने के लिए gate को कमज़ोर या जाली नहीं करता।

अनुरूपता अनुबंध

हाँ, जब योजना को पहले से स्वीकृति मिली हो, वह आवश्यक state परत रखती हो, और एजेंट को सीमाबद्ध अधिकार देती हो। बिना-निगरानी रन को रुककर एक अवरोधक दर्ज करना होगा जब वास्तविकता भटक जाए, कोई द्वार अपने नियोजित मरम्मत-दायरे से बाहर विफल हो जाए, या किसी नई स्वीकृति या क्रेडेंशियल की आवश्यकता हो।

बिना-निगरानी प्रोटोकॉल पढ़ें

हाँ — orchestrator-hub आर्किटाइप ठीक इसी के लिए मौजूद है। एक hub रिपॉज़िटरी समन्वय करने वाली योजना रखती है, और हर child रिपॉज़िटरी अपनी योजना अपने ही isolated `.dwp/` workspace में चलाती है, इसलिए child कभी hub की योजना-स्थिति में नहीं लिखता। child की पूर्णता हर योजना की अपनी top-level स्थिति से पढ़ी जाती है, उसके भीतर string-matching से नहीं, और hub कहीं भी जाने से पहले अपनी स्थिति दर्ज करता है। हर child एक साधारण DWP रिपॉज़िटरी बना रहता है, जिसे अकेले भी pilot किया जा सकता है।

रिपॉज़िटरी आर्किटाइप

वे आसन्न समस्याएँ सुलझाते हैं। स्पेक-ड्रिवन उपकरण यह पकड़ने में उत्कृष्ट हैं कि क्या बदलना चाहिए: विनिर्देश, आवश्यकताएँ और बदलाव-प्रस्ताव एक दोहराने योग्य आकार में। Deep Work Plan इस बारे में है कि एक एजेंट भटके बिना घंटों कैसे निष्पादित करे: ऑनबोर्डेड हार्नेस, छुई सतह से चुने गए प्रति-कार्य सत्यापन द्वार, डिस्क पर पुनरारंभ योग्य स्थिति, सुरक्षा-जाँच के साथ एक अनिवार्य Final Review, और रिपॉज़िटरी के लिए स्वयं एक अनुरूपता परीक्षक। दोनों को जोड़ा जा सकता है, एक विनिर्देश या बदलाव-प्रस्ताव योजना को आहार देते हुए। तुलना पृष्ठ क्षमताओं को साथ-साथ, हर उपकरण के अपने शब्दों में रखता है।

तुलना देखें

BMAD, Superpowers और Get Shit Done जैसे एजेंट वर्कफ़्लो फ्रेमवर्क मज़बूत कार्यशैलियाँ लाते हैं: भूमिकाएँ, सिद्धांत, टेस्ट-फर्स्ट चरण, सत्यापन की आदतें। Gentle-AI एक पड़ोसी श्रेणी में एजेंट इकोसिस्टम कॉन्फ़िगरेटर के रूप में बैठता है: यह उन कोडिंग एजेंट्स को, जिन्हें आप पहले से उपयोग कर रहे हैं, सेशन के बीच स्थायी मेमोरी (Engram), चुनी हुई skills, personas, MCP सर्वर, वैकल्पिक Spec-Driven Development और वैकल्पिक साक्ष्य-आधारित समीक्षा (Receipt-Driven Development) से लैस करता है, और हर एजेंट की कॉन्फ़िगरेशन डायरेक्टरी में लिखता है। Deep Work Plan दोनों से अलग है: यह इस पर ध्यान केंद्रित करता है कि रिपॉज़िटरी में क्या रहता है और क्या जाँचा जा सकता है — एक harness जिसे कोई भी एजेंट बिना पूर्व संदर्भ के पढ़ सके, स्वीकृति मानदंड और gates वाली task फ़ाइलें, वह state जो सेशन के बाद भी बचा रहे, CI-अनुकूल एग्ज़िट कोड वाला एक conformance checker, और यह प्रकाशित माप कि हर flow कितने instruction bytes लोड करता है। यह संरचना से tool-agnostic है और core loop में कोई सेवा, प्रदाता या secret नहीं जोड़ता। परतें साथ रह सकती हैं: फ्रेमवर्क और Gentle-AI यह तय करते हैं कि एजेंट कैसे काम करता है; Deep Work Plan लंबे काम को रिपॉज़िटरी के भीतर टिकाऊ और सत्यापन योग्य बनाता है। तुलना पेज दिखाता है कि हर दृष्टिकोण कहाँ built-in है, वैकल्पिक है, या दायरे से बाहर है।

तुलना देखें

अंतर्निहित प्लान मोड उपयोगी हैं और Deep Work Plan उसी आधार पर बनता है — `AGENTS.md` परंपरा और खुला Agent Skills मानक। अंतर यह है कि योजना कहाँ रहती है और उसे क्या लागू करता है। नेटिव योजनाएँ सामान्यतः रिपॉज़िटरी के बाहर रहती हैं और सत्र के साथ समाप्त हो जाती हैं; Deep Work Plan योजना, उसकी स्थिति और उसके साक्ष्य रिपॉज़िटरी में लिखता है, इसलिए कोई दूसरा एजेंट या सहयोगी उसे जारी रख सकता है, और हर कार्य एक निष्पादन योग्य द्वार और एक दर्ज लॉग ले जाता है। सोचने के लिए आप अपने एजेंट के प्लान मोड का उपयोग करते रहें; पद्धति टिकाऊ, सत्यापन योग्य निष्पादन चक्र जोड़ती है।

तुलना देखें

ऑनबोर्डिंग गैर-विनाशकारी है: यह मौजूदा `AGENTS.md`, `docs/`, `.agents/` या `CLAUDE.md` को पहचानती है, अधिलेखित करने के बजाय सुलझाती है, और कुछ भी बदलने से पहले पूछती है। यह वास्तविक कमांड्स वाला `AGENTS.md` इंडेक्स, एक तर्कपूर्ण `docs/` वृक्ष, प्रति-मॉड्यूल docs, पतले `dwp-*` कमांड्स वाली `.agents/` किट, एक gitignored `.dwp/` आउटपुट क्षेत्र, एक सत्यापित टेस्टिंग मैप, और अनिवार्य स्थानीय कोड समीक्षा (AI Diff Reviewer स्किल और रिपॉज़िटरी-अनुरूप समीक्षा एक्सटेंशन) लिखती है। फिर वह एक स्व-जाँच और अनुरूपता परीक्षक चलाती है ताकि आप देख सकें कि क्या बना। किसी पुराने मानक के तहत ऑनबोर्ड रिपॉज़िटरी को एक लक्षित harness अपग्रेड मिलता है जो केवल जो गायब या पुराना है उसे सुलझाता है।

अपनाने का endpoint

यहाँ दो अलग अपग्रेड शामिल हैं, और flow उन्हें अलग रखता है। रिपॉज़िटरी का harness — `AGENTS.md`, `docs/`, `.agents/` किट — onboarding दोबारा चलाकर सुलझाया जाता है, जो केवल गायब या पुराना हिस्सा भरता है। स्किल खुद `/dwp-upgrade` से आगे बढ़ती है: नवीनतम प्रकाशित रिलीज़ की read-only जाँच, आपके स्वीकार किए गए सटीक tag की सत्यापित इंस्टॉलेशन, और फिर onboarding को एक ताज़ा रन की तरह दोबारा चलाना। पूरा flow हर कदम पर स्पष्ट सहमति माँगता है, स्थानीय अनुकूलनों को overwrite करने के बजाय diff करके बचाया जाता है, और `.dwp/` कभी migrate नहीं होता — मौजूदा योजनाएँ अपना दर्ज रूप बनाए रखती हैं और चलती रहती हैं।

अपनाने का endpoint

हाँ। ऐडऑन ऑप्ट-इन परतें हैं, और शून्य ऐडऑन वाली रिपॉज़िटरी भी पूर्णतः DWP-अनुरूप होती है। devcontainer, Dailybot रिपोर्टिंग, dependency-upgrade, design-system समर्थन और वैकल्पिक CI समीक्षा तभी प्रस्तावित होते हैं जब वे आपकी रिपॉज़िटरी के अनुकूल हों और आप उन्हें स्पष्ट रूप से स्वीकार करें।

ऐडऑन ब्राउज़ करें

DWP टूलचेन की अनुपस्थिति को मुफ़्त छूट नहीं मानता। ऑनबोर्डिंग के दौरान एजेंट स्टैक-उपयुक्त सत्यापन सेटअप का प्रस्ताव देता है, कमांड्स को रिपॉज़िटरी दस्तावेज़ीकरण में दर्ज करता है, और भविष्य के द्वारों के लिए उन्हीं कमांड्स को लक्ष्य के रूप में उपयोग करता है; प्रस्ताव आपकी समीक्षा के लिए दृश्यमान रहता है।

एजेंट प्रोटोकॉल पढ़ें

पद्धति और स्किल MIT-लाइसेंस प्राप्त और निःशुल्क हैं; मुख्य flows में कोई सेवा नहीं, कोई API कुंजी नहीं और कोई टेलीमेट्री नहीं। दक्षता को हर flow द्वारा **प्रवेश पर** लोड किए जाने वाले instruction bytes की संख्या के रूप में रिपोर्ट किया जाता है — यानी सत्र की शुरुआत में इसका बंडल — जिसे नामित **एंड-टू-एंड पाथ** के साथ प्रकाशित किया जाता है, जो यह जोड़ते हैं कि वास्तविक कार्य आगे बढ़ने पर flow के अपने ट्रिगर क्या लोड करते हैं (उदाहरण के लिए, एक resume जो आगे execute तक चलता है, आमतौर पर अपने प्रवेश बंडल का कई गुना लोड करता है)। इनमें से कोई भी आँकड़ा किसी सत्र की सीमा तय नहीं करता: एक वास्तविक रन रिपॉज़िटरी की अपनी फ़ाइलें, टूल आउटपुट और प्लान की कार्यशील फ़ाइलें भी पढ़ता है, जिनमें से किसी की गिनती यह लेजर नहीं करता। दोनों आँकड़े स्किल के साथ कमिट की गई एक स्क्रिप्ट द्वारा मापे जाते हैं, हर रिलीज़ बेसलाइन पर दोबारा मापे जाते हैं और एक मूल्यांकन लेजर में प्रकाशित होते हैं, जिसमें वृद्धियाँ कमियों जितनी ही स्पष्टता से रिपोर्ट होती हैं। इसे टोकन प्रतिशत या लागत-बचत के रूप में रिपोर्ट नहीं किया जाता, क्योंकि बाइट्स का लेखा उनकी पुष्टि नहीं करता। एक जमी हुई प्रोटोकॉल के तहत नए एजेंटों के साथ एक सार्वजनिक मूल्यांकन अब चल चुका है: वही दो फ़ीचर साफ़ क्लोन से बनाए गए — बिना harness के, पिछले मेजर संस्करण के साथ और वर्तमान संस्करण के साथ। उसने पाया कि harness वाले ट्री पर काम करने वाले एजेंट दोनों कार्यों में कम बाइट्स पढ़ते हैं, और वर्तमान संस्करण के फ़ीचर सत्र दोनों कार्यों में पिछले मेजर संस्करण की तुलना में कम मॉडल इनपुट और आउटपुट खर्च करते हैं — जैसा harness ने रिपोर्ट किया, एक ही कार्यभार पर। उसने ईमानदार सीमाएँ भी सामने रखीं: onboarding एक बार का खर्च है जो केवल flows के उपयोग पर लौटता है; प्रति कार्यभार शुद्ध टोकन दिशा मिश्रित थी; किसी घड़ी-समय की बढ़त का दावा नहीं किया जाता; और नया एजेंट अपने आप flows में प्रवेश नहीं करता — flows वे कमांड हैं जो आप, या उन्हें बुलाना जानने वाला एजेंट, चलाता है।

भरोसा और प्रकटीकरण