DWP विनिर्देश

संस्करण 4.0.0. स्थिति: स्थिर। यह दस्तावेज़ Deep Work Plan (DWP) पद्धति का मानक विनिर्देश है। कीवर्ड MUST, MUST NOT, SHOULD, SHOULD NOT और MAY की व्याख्या RFC 2119 में वर्णित अनुसार की जानी है।

2.4.0 में योगात्मक, कोई breaking changes नहीं। (1) Touched Surface खंड — कोई कार्य क्या बदलता है और क्या सत्यापित होना चाहिए, इन दोनों के बीच का अनुबंध, जोखिम वर्ग के अनुसार गेट चयन के साथ (पृथक / सीम / साझा-कोर / अज्ञात); (2) पूर्ण सत्यापन एक अंतिम-स्थिति आवश्यकता बन जाता है जो योजना के एकमात्र अनिवार्य Final Review में चलती है, स्पष्ट साक्ष्य-पुनः-उपयोग नियमों के साथ; (3) कार्य-स्थानीय स्किल्स निर्णय स्वामी कार्य में चले जाते हैं, और Executive Report वैकल्पिक, अनुरोध पर हो जाता है; (4) एक मोड-जागरूक create प्रवाह — trust mode सीधे materialize करता है पर विश्लेषण और गुणवत्ता जाँचें बनाए रखता है; (5) Lite-प्रथम योजना मैटेरियलाइज़ेशन — guided create एक गैर-निष्पादन-योग्य ड्राफ़्ट के बजाय सीधे एक निष्पादन-योग्य Lite योजना बनाता है, जिसे किसी भी बिंदु पर Full योजना में प्रोन्नत किया जा सकता है (देखें Lite योजनाएँ); और (6) एक स्पष्ट संगतता मैट्रिक्स: पूर्व संस्करणों की योजनाएँ और रिपॉज़िटरीज़ अनुरूप बनी रहती हैं।

मानक 4.0.0. संस्करण-छलांग मानक की संख्या को उत्पाद-पंक्ति के साथ संरेखित करती है — 2.x ऐतिहासिक है और कोई 3.x मानक नहीं है — और 2.4.0 से कोई आवश्यकता नहीं बदलती। पुराने संस्करणों की योजनाएँ और रिपॉज़िटरी अनुरूप बनी रहती हैं।

परिभाषा

एक Deep Work Plan एक संरचित, केवल-markdown आर्टिफ़ैक्ट है जो एक जटिल इंजीनियरिंग कार्य का वर्णन करता है, जिसे क्रमिक, समीक्षा योग्य काम की इकाइयों में विघटित किया गया है, और जिसे स्वायत्त रूप से काम करने वाले AI कोडिंग एजेंट्स द्वारा बनाने, निष्पादित करने और बनाए रखने के लिए डिज़ाइन किया गया है।

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

Create प्रवाह — एकल चरण, मोड-जागरूक

create प्रवाह उद्देश्य, कॉन्टेक्स्ट, बाधाओं और कार्य-रूपरेखा को एक बार एकत्र करता है, अपना आवश्यकता-विश्लेषण करता है (दायरा, कार्यों के बीच निर्भरता-क्रम, Touched Surface से सत्यापन चयन, आनुपातिक-कठोरता स्तर), और फिर उस मोड के अनुसार materialize करता है जिसे डेवलपर ने चुना:

• Guided mode (डिफ़ॉल्ट)। प्रवाह सीधे एक Lite योजना materialize करता है — इनलाइन {#task-N} कार्य-रिकॉर्ड्स के साथ एक कॉम्पैक्ट, पहले से निष्पादन-योग्य प्रस्ताव, एक ही पास में समीक्षा योग्य — और डेवलपर से पूछता है कि वह इसे Lite के रूप में रखे, इसे Full योजना में प्रोन्नत करे, परिवर्तन-अनुरोध करे, या रुक जाए। कोई मध्यवर्ती गैर-निष्पादन-योग्य ड्राफ़्ट उत्पन्न नहीं होता।
• Trust mode (trust / auto)। प्रवाह चुने गए प्रतिनिधित्व को (Lite, या Lite के तुरंत बाद Full में प्रोन्नति) सीधे materialize करता है, बिना किसी समीक्षा चरण के — डेवलपर ने इसे छोड़ दिया है। आवश्यकता-विश्लेषण, निर्भरता-क्रम, और एक योजना-गुणवत्ता जाँच फिर भी चलते हैं: trust समीक्षा छोड़ता है, विश्लेषण नहीं। एक trust-mode योजना अनुपस्थित निष्पादन के लिए पूर्व-अनुमोदित दर्ज होती है।

दोनों मोड उसी आवश्यकता-विश्लेषण के भाग के रूप में योजना का प्रारूप (Lite या Full) तय करते हैं, कभी बाद की सोच के रूप में नहीं। योजना के पूर्ण प्रतिनिधित्व, निर्माण-और-चयन, और प्रोन्नति जीवनचक्र के लिए देखें Lite योजनाएँ।

योजना संरचना

एक योजना .dwp/plans/ के अंतर्गत PLAN_<slug>/ नाम की एक डायरेक्टरी MUST होनी चाहिए, दो प्रतिनिधित्वों में से एक में:

• Full. डायरेक्टरी में README.md (योजना अवलोकन, लक्ष्य, कार्य-तालिका और स्थिति), प्रति कार्य एक फ़ाइल जिसका नाम <n>.task_<slug>.md है, और PROGRESS.md (निष्पादन का एक चालू लॉग) MUST होने चाहिए।
• Lite. कॉम्पैक्ट, पूर्ण रूप से निष्पादन-योग्य कार्य-रिकॉर्ड्स अलग कार्य-फ़ाइलों के बजाय स्थिर {#task-N} एंकरों के पीछे README.md में इनलाइन रहते हैं — हर रिकॉर्ड फिर भी एक लक्ष्य, Touched Surface, स्वीकृति मानदंड, सत्यापन, और पूर्णता लॉग रखता है। PROGRESS.md फिर भी REQUIRED है। एक Lite योजना को किसी भी समय Full में प्रोन्नत किया जा MAY। पूर्ण जीवनचक्र के लिए देखें Lite योजनाएँ, यहाँ दोहराने के बजाय।

एक योजना MAY अतिरिक्त रूप से मशीन-पठनीय स्थिति परत भी रख सकती है: manifest.json (स्थिर पहचान, मैटेरियलाइज़ेशन पर एक बार लिखी जाती है) और state.json (सजीव प्रति-कार्य निष्पादन स्थिति)। स्थिति परत नई योजनाओं के लिए RECOMMENDED है और अनुपस्थित निष्पादन तथा git के बिना एजेंट कार्यस्थलों के लिए REQUIRED है। देखें योजना-स्थिति।

कार्य-संरचना

कार्य फ़ाइल

1. 01 Title
2. 02 Context
3. 03 Read Before Starting
4. 04 Goal
5. 05 Touched Surface
6. 06 Instructions
7. 07 Acceptance Criteria
8. 08 Outputs
9. 09 Validation
10. 10 Execution Checklist + Completion & Log

हर कार्य फ़ाइल में ये दस खंड क्रम में MUST होने चाहिए:

1. Goal — एक अनुच्छेद का कथन कि कार्य क्या हासिल करता है।
2. Context — पृष्ठभूमि, लिंक, और यह कार्य क्यों मौजूद है।
3. Touched Surface — कार्य जो बदलता है और जो सत्यापित होना चाहिए, इन दोनों के बीच का अनुबंध।
4. Steps — करने के लिए क्रमबद्ध, ठोस क्रियाएँ।
5. Acceptance criteria — उन शर्तों की एक चेकलिस्ट जो पूर्णता को परिभाषित करती हैं।
6. Validation — सत्यापन के लिए चलाई जाने वाली कमांड्स या परीक्षण, Touched Surface से चुनी गई।
7. Files — बनाई या संशोधित किए जाने की अपेक्षित पाथ।
8. Dependencies — अन्य कार्य या बाहरी पूर्वापेक्षाएँ।
9. Risks — क्या गलत हो सकता है, और शमन-उपाय।
10. Completion & Log — एक स्थिति-चिह्न और कालानुक्रमिक टिप्पणियाँ।

एक कार्य MAY अतिरिक्त रूप से एक Delta खंड (brownfield व्यवहार परिवर्तनों के लिए RECOMMENDED — नीचे देखें) और एक Rollback खंड (माइग्रेशन, अवसंरचना परिवर्तन, या deployment के लिए RECOMMENDED) भी शामिल कर सकता है।

Touched Surface

Touched Surface कार्य जो बदलता है और जो सत्यापित होना चाहिए, इन दोनों के बीच का अनुबंध है। यह इसलिए मौजूद है ताकि सत्यापन प्रभाव देखकर चुना जाए, आदत से नहीं, और ताकि बाद का कोई पाठक देख सके कि कोई गेट क्यों चुना गया। एक व्यवहार-बदलने वाले कार्य को दर्ज करना MUST:

• योजनाबद्ध सतह — वे पाथ, मॉड्यूल, पैकेज या कॉन्फ़िगरेशन जिन्हें कार्य बदलने का इरादा रखता है, संपादन से पहले लिखे गए।
• वास्तविक सतह — संपादन के बाद पुनर्मेलित सूची, वास्तविक diff से ली गई। एजेंट को गेट चुनने से पहले योजनाबद्ध और वास्तविक सतहों का पुनर्मेल करना MUST।
• प्रभावित उपभोक्ता — वे मॉड्यूल, पैकेज या सेवाएँ जो वास्तविक सतह पर निर्भर हैं, जहाँ तक रिपॉज़िटरी का प्रलेखित मैपिंग स्थापित कर सके। जहाँ नहीं कर सकता, प्रविष्टि को ऐसा कहना MUST।
• जोखिम वर्ग — इनमें से एक: पृथक (एक मॉड्यूल और उसके परीक्षणों तक सीमित); सीम (सहयोगियों के बीच एक अनुबंध, persistence, routing, serialization, auth, या framework wiring बदलता है); साझा/कोर (व्यापक रूप से import किया गया, या कोई dependency, migration, build/test config, schema, या toolchain परिवर्तन); अज्ञात (मैपिंग अनुपस्थित, पुराना, या असत्यापित)।
• प्रयुक्त परीक्षण-मैपिंग — किस प्रलेखित मैपिंग या टूल ने चयन उत्पन्न किया।
• चुना गया गेट और कारण — सटीक कमांड्स और क्यों वे वास्तविक सतह को कवर करती हैं।

कॉन्फ़िगरेशन फ़ाइलें, schemas, dependency manifests, templates, fixtures, migrations, और एजेंट-निर्देश फ़ाइलें व्यवहार बदल सकती हैं और उन्हें उनके प्रभाव के आधार पर वर्गीकृत किया जाना MUST, कभी फ़ाइल एक्सटेंशन से नहीं। कोई कार्य जो केवल गद्य, टिप्पणियाँ, या शोध आर्टिफ़ैक्ट बदलता है, सतह को लागू-नहीं घोषित कर MAY और फिर भी रिपॉज़िटरी की non-runtime जाँचें चलाता है।

Delta खंड (brownfield परिवर्तन)

अधिकांश वास्तविक काम नया व्यवहार बनाने के बजाय मौजूदा व्यवहार को बदलता है। एक कार्य जो किसी मौजूदा सिस्टम के व्यवहार को बदलता है, उसे SHOULD तीन सूची शीर्षकों का उपयोग करते हुए परिवर्तन को एक स्पष्ट before/after अनुबंध के रूप में वर्णित करते हुए एक Delta खंड रखना चाहिए:

• ADDED — वह व्यवहार जो कार्य के बाद अस्तित्व में है और पहले नहीं था।
• MODIFIED — वह व्यवहार जो दोनों में अस्तित्व में है, was: … → now: … के रूप में कहा गया।
• REMOVED — वह व्यवहार जो पहले अस्तित्व में था और जानबूझकर बाद में चला गया।

प्रत्येक प्रविष्टि MUST एक observable व्यवहार होनी चाहिए — किसी endpoint की प्रतिक्रिया, एक CLI फ़्लैग, एक UI स्थिति, एक default मान — न कि कोई implementation detail। Delta खंड व्यवहार स्तर पर reviewer का diff है: acceptance criteria ADDED/MODIFIED प्रविष्टियों को सत्यापित करती हैं, और REMOVED प्रविष्टियाँ हटाने का स्पष्ट लाइसेंस हैं। REMOVED के रूप में सूचीबद्ध नहीं कुछ भी MUST काम करता रहना चाहिए।

सत्यापन-गेट — जोखिम वर्ग के अनुसार चुने गए

सत्यापन वह गेट है जो पूर्णता के दावे को उसके प्रमाण में बदल देता है: किसी कार्य को तब तक पूर्ण अंकित MUST NOT किया जाए जब तक उसके Validation खंड की हर कमांड चल न ली हो और पास न हो गई हो। किसी व्यवहार-बदलने वाले कार्य का गेट उसकी पुनर्मेलित Touched Surface से, जोखिम वर्ग के अनुसार चुना जाता है:

एक व्यवहार-परिवर्तन को एक गैर-रिक्त, प्रासंगिक परीक्षण चयन उत्पन्न करना MUST — एक अमान्य selector या शून्य परीक्षण चुनने वाला runner कवरेज नहीं है। जहाँ रिपॉज़िटरी का परीक्षण-मैपिंग पुराना हो, सही invocation निकाला जाता है और मैपिंग अद्यतन दर्ज किया जाता है; एक छोटी छूटी हुई कमांड के लिए कभी पूर्ण ऑनबोर्डिंग रन की आवश्यकता नहीं होती। जहाँ कोई scoped invocation मौजूद न हो, पूर्ण लागू सूट लागू होती है — legacy व्यवहार, कभी त्रुटि नहीं।

जब कोई कार्य नई मूल कार्यक्षमता जोड़ता है या मौजूदा व्यवहार को सारभूत रूप से बदलता है, उसके स्वीकृति मानदंडों में नए या बदले गए व्यवहार के लिए स्वचालित परीक्षण कवरेज शामिल होना MUST, और उसका सत्यापन रिपॉज़िटरी के परीक्षणों को lint, type-check और format जाँचों के साथ चलाता है — न कि अकेले build। मौजूदा परीक्षण हरे बने रहने MUST।

अंतिम-स्थिति सत्यापन

प्रति-कार्य गेट वही सत्यापित करते हैं जो हर कार्य छूता है; वे योजना-समग्र सत्यापन का स्थान नहीं लेते। किसी योजना के पूर्ण होने से पहले, रिपॉज़िटरी का पूर्ण लागू सत्यापन अंतिम प्रासंगिक स्थिति पर, अंतिम सारभूत परिवर्तन के बाद — Final Review में — चलना और पास होना MUST। पहले आने वाले व्यापक रन integration सीमाओं पर या साझा/कोर परिवर्तनों के बाद होते हैं, किसी कार्य-गिनती अनुसूची पर नहीं। एक पास परिणाम को केवल तभी पुनः उपयोग किया जा MAY जब साक्ष्य हो कि प्रासंगिक इनपुट समतुल्य हैं; अन्यथा उसे दोबारा चलाया जाता है। हर गेट रन एक संक्षिप्त रिकॉर्ड छोड़ता है: कमांड, दायरा, revision, परिणाम, और एक साक्ष्य पाथ।

सुरक्षा अनुशासन

सुरक्षा ठीक उसी तरह प्रथम-श्रेणी है जैसे परीक्षण हैं, और यह उसी दो-परत मॉडल का अनुसरण करती है: काम के होते समय प्रति-कार्य अनुशासन, साथ ही अंत में पूरे change set पर Final Review की सुरक्षा-जाँच। जब भी कोई कार्य प्रमाणीकरण या प्राधिकरण, input handling, secrets या कॉन्फ़िगरेशन, network, file, या shell सतह, या dependencies को छूता है:

• उसके स्वीकृति मानदंडों में परिवर्तन की सुरक्षा अपेक्षाएँ बताई जानी MUST — input validated और escaped हो, कोड या fixtures में कोई गुप्त सामग्री न हो, auth जाँचें संरक्षित या सुदृढ़ हों — docs/SECURITY.md के अनुरूप।
• हर commit के land होने से पहले उसे secrets या credentials से मुक्त होने की पुष्टि की जानी MUST, test fixtures और दस्तावेज़ीकरण उदाहरण समेत। किसी push किए गए commit में मौजूद secret को लीक हुआ माना और rotate किया जाना MUST, केवल हटाया नहीं।
• जहाँ सुरक्षा-संवेदनशील काम सारभूत हो, वहाँ एक समर्पित hardening कार्य implementation कार्यों के ठीक बाद और comprehensive-tests कार्य से पहले रखा जाना SHOULD, ताकि परीक्षण के व्यवहार को कोड करने से पहले निष्कर्ष ठीक कर लिए जाएँ और हर निष्कर्ष पुनः-काम के बजाय एक regression मामला बन जाए।

यह प्रति-कार्य अनुशासन Final Review की सुरक्षा-जाँच का स्थान नहीं लेता: प्रति-कार्य जाँचें उस commit में समस्याएँ पकड़ती हैं जहाँ वे जन्म लेती हैं, जबकि अंतिम गेट पूरी योजना का ऑडिट करता है — परीक्षण और दस्तावेज़ीकरण कार्यों सहित।

योजना जीवनचक्र — Final Review

इस संस्करण के अंतर्गत लिखी गई हर अनुरूप योजना ठीक एक अनिवार्य कार्य के साथ समाप्त होती है: Final Review (कार्य N)। दो ज़िम्मेदारियाँ जो पूर्व संस्करण अलग-अलग समापन कार्यों में रखते थे, पुनर्स्थापित की जाती हैं: स्किल्स निर्णय उस कार्य में चले जाते हैं जिसने पैटर्न उत्पन्न किया, और Executive Report एक वैकल्पिक, अनुरोध-पर आर्टिफ़ैक्ट बन जाता है। सुरक्षा-जाँच में से कुछ भी शिथिल नहीं किया गया है।

Final Review को क्रम में ये करने MUST:

(a) सुरक्षा-जाँच — योजना के पूरे संचित change set को hardcoded secrets, injection जोखिमों, नई आक्रमण-सतह, कमज़ोर किए गए auth, और logs या दस्तावेज़ों में संवेदनशील डेटा के लिए रूबरू करें; प्रस्तुत dependencies का ऑडिट करें; सत्यापित करें कि docs/SECURITY.md अब भी वास्तविकता दर्शाता है; साफ़ होने पर भी सुरक्षा समीक्षा रिपोर्ट लिखें। एक गंभीर निष्कर्ष योजना के पूर्ण होने से पहले ठीक किया जाता है — या उपयोगकर्ता द्वारा स्पष्ट रूप से स्वीकार।

(b) अंतिम-स्थिति सत्यापन — रिपॉज़िटरी का पूर्ण लागू सत्यापन अंतिम प्रासंगिक स्थिति पर चलता और पास होता है।

(c) स्किल्स समाधान — हर कार्य एक स्किल्स निपटान साथ रखता है और हर दर्ज उम्मीदवार का एक निपटान है; कोई दूसरी discovery रिपोर्ट नहीं।

(d) पूर्णता — deliverables, सत्यापन साक्ष्य और सीमाओं के साथ पूर्णता रिपोर्ट करें; Executive Report एक बार प्रस्तावित करें। योजना पूर्ण होती है, प्रस्ताव का उत्तर मिले या न मिले।

Final Review बाकी सभी कार्यों के बाद क्रमिक रूप से चलता है और कभी किसी समानांतर समूह में नहीं रखा जाता।

कार्य-स्थानीय स्किल्स निर्णय

“क्या इस काम ने कोई ऐसा पुनः-प्रयोज्य पैटर्न बनाया जो एक skill या agent के लायक हो?” — यह प्रश्न उसी कार्य के भीतर उत्तर दिया जाता है जिसने पैटर्न उत्पन्न किया, जब उसका साक्ष्य कॉन्टेक्स्ट में ताज़ा है। हर कार्य का Completion & Log एक स्किल्स निपटान साथ रखता है: कुछ नहीं, किसी मौजूदा skill का अद्यतन, एक नामित आर्टिफ़ैक्ट का निर्माण, या कारण सहित एक स्थगन। सार्थक लेखन उसी कार्य के भीतर, उसके सत्यापन-गेट और commit से पहले, मौजूदा कैटलॉग से डुप्लिकेट-जाँच के बाद होता है।

कार्यकारी रिपोर्ट — वैकल्पिक, अनुरोध पर

Executive Report अब कोई अनिवार्य कार्य नहीं है। पूर्णता पर एजेंट इसे एक बार प्रस्तावित करता है; यह केवल स्पष्ट अनुरोध पर उत्पन्न होता है, योजना को replay किए बिना टिकाऊ साक्ष्य से पूरा किया जाता है। कोई उत्तर न होना या एक अनुपस्थित रन योजना को बिना रिपोर्ट उत्पन्न किए पूर्ण छोड़ देता है।

कार्य-पूर्णता प्रोटोकॉल

सत्यापन पार करने के बाद और अगले कार्य पर जाने से पहले, एजेंट को क्रम में MUST: (1) योजना README में कार्य को [x] चिह्नित करें; (2) योजना स्थिति गिनती बढ़ाएँ; (3) कार्य के Completion & Log को बिना placeholder मानों के भरें; (4) PROGRESS.md में 3–5 bullet प्रविष्टि जोड़ें; (5) जहाँ योजना कमिट करती है, {type}({scope}): {description} — Task {N} of PLAN_{name} प्रारूप के साथ कमिट करें; (6) जहाँ योजना स्थिति परत रखती है, state.json परमाणु रूप से पुनर्लिखें — कार्य completed, गेट रिकॉर्ड, परिणाम रिकॉर्ड, commit hash।

छह चरण एक तार्किक लेनदेन बनाते हैं। प्रोटोकॉल के बीच में बाधित एजेंट को MUST NOT अगला कार्य शुरू करना चाहिए — उसे पहले आंशिक पूर्णता पूरी या वापस लेनी होगी।

DWP Resume Protocol

रिज्यूम MUST केवल योजना की फ़ाइलों और git लॉग से संभव होना चाहिए, बिना किसी बाहरी स्थिति के। git के बिना एक कार्यस्थल में — देखें आर्किटाइप §3 — योजना का state.json REQUIRED है और git लॉग की जगह लेता है।

एक रिज्यूम करने वाला एजेंट — एक नया सत्र, एक अलग एजेंट, एक अनुसूचित डेमन turn, या एक क्लाउड सत्र जागना — क्रम में यह अनुष्ठान MUST करना चाहिए:

1. पुनः-लंगर डालें। योजना README पढ़ें: लक्ष्य, वैश्विक दिशानिर्देश, कार्य सूची।
2. चेकपॉइंट खोजें। README में पहला अचिह्नित कार्य खोजें; git लॉग और git status (या जहाँ git अनुपस्थित हो state.json का checkpoint) पढ़ें।
3. स्थिति का पुनर्मेल करें। जहाँ state.json मौजूद हो, इसे README चेकबॉक्सों से तुलना करें; desync पर, जारी रखने से पहले markdown से इसे पुनर्जनित करें।
4. Seam का निरीक्षण करें। रिज्यूम-बिंदु कार्य का Completion & Log और अंतिम PROGRESS.md प्रविष्टि पढ़ें — पिछले सत्र की अंतिम सत्यापित भूमि।
5. Smoke-test। यह पुष्टि करने के लिए कि उस पर बनाने से पहले दुनिया अभी भी काम करती है, रिपॉज़िटरी का सबसे सस्ता standing validation चलाएँ। एक विफल smoke test पहले जाँचा जाता है, उस पर बनाया नहीं जाता।
6. परमाणु रूप से जारी रखें। ठीक अगला कार्य निष्पादित करें; आगे batch न करें।

एजेंट को पूर्ण ([x]) चिह्नों पर MUST भरोसा करना चाहिए और MUST NOT पूर्ण किए गए कार्यों को पुनः-सत्यापित करना चाहिए जब तक उपयोगकर्ता इसे स्पष्ट रूप से अनुरोध न करे, या smoke test किसी पूर्ण कार्य को प्रभावित करने वाले तरीके से विफल न हो।

निष्पादन लूप

DWP पाँच संक्रियाएँ परिभाषित करता है:

• create — एक लक्ष्य से एक नई योजना तैयार करें।
• execute — योजना को कार्य-दर-कार्य निष्पादित करें।
• refine — एक मौजूदा योजना को संशोधित करें।
• resume — एक बाधित योजना को फिर से शुरू करें।
• status — बिना निष्पादन के योजना की स्थिति की रिपोर्ट दें।

आउटपुट कार्यस्थल

आउटपुट कार्यक्षेत्र

• .dwp/ git द्वारा अनदेखा · हटाने योग्य
• plans/
• PLAN_<name>/
• README.md
• PROGRESS.md
• <n>.task_<slug>.md
• analysis_results/ रिपोर्ट
• SECURITY_REVIEW.md सुरक्षा समीक्षा
• EXECUTIVE_REPORT.md कार्यकारी रिपोर्ट

सभी DWP आर्टिफ़ैक्ट रिपॉज़िटरी रूट पर एक gitignored .dwp/ डायरेक्टरी के अंतर्गत MUST रहने चाहिए।

मशीन-पठनीय योजना स्थिति

एक योजना MAY मशीन-पठनीय स्थिति परत रख सकती है — manifest.json (स्थिर पहचान) और state.json (सजीव प्रति-कार्य स्थिति, सत्यापन-गेट रिकॉर्ड, परिणाम रिकॉर्ड, चेकपॉइंट, अवरुद्ध स्थिति)। markdown योजना सत्य का स्रोत बनी रहती है; JSON परत एक व्युत्पन्न प्रक्षेपण है, प्रोटोकॉल बिंदुओं पर पुनर्जनित और रिज्यूम पर पुनर्मेलित।

स्थिति परत नई योजनाओं के लिए RECOMMENDED है, अनुपस्थित निष्पादन के लिए REQUIRED है, और git के बिना एजेंट कार्यस्थलों के लिए REQUIRED है। पूर्ण मानक परिभाषा देखें योजना-स्थिति में।

आनुपातिक कठोरता

कठोरता काम के अनुपात में MUST होनी चाहिए। तुच्छ परिवर्तनों पर अनुष्ठान एक पद्धति विफलता है, अतिरिक्त सुरक्षा नहीं। काम का हर टुकड़ा ठीक एक स्तर में आता है:

micro-tier काम के लिए योजना बनाने के लिए कहे गए एजेंट को MUST कहना चाहिए कि एक योजना अनुपातहीन है और इसके बजाय inline रूप प्रस्तावित करना चाहिए। एक तुच्छ single-file परिवर्तन के लिए plan folder MUST NOT बनाया जाना चाहिए।

Micro-tier काम अभी भी non-negotiables बनाए रखता है: एक स्पष्ट लक्ष्य, एक सत्यापन गेट जो चलता और पास होता है, और व्यवहार परिवर्तनों के लिए परीक्षण अनुशासन। स्तर पैकेजिंग बदलता है, कभी गेट नहीं।

जब scope mid-flight बढ़ता है — एक micro कार्य वास्तविक scope उजागर करता है, एक standard योजना में sub-repositories निकलती हैं — एजेंट को MUST रुकना और काम को अगले स्तर पर प्रोन्नत करना चाहिए बजाय वर्तमान को खींचने के।

संगतता

पूर्व संस्करणों की योजनाएँ और रिपॉज़िटरी अनुरूप बनी रहती हैं, और एक अनुरूपता जाँचकर्ता को एक ज्ञात legacy आर्टिफ़ैक्ट (स्वीकृत) को उस आर्टिफ़ैक्ट से अलग करना MUST जो इस संस्करण की घोषणा करता हो और उसके अंतर्गत वस्तुनिष्ठ रूप से अमान्य हो (अस्वीकृत):

संस्करण-निर्धारण

यह विनिर्देश सिमैंटिक वर्शनिंग का अनुसरण करता है।