दस्तावेज़ीकरण मानक

संस्करण 5.0.0. यह मानक परिभाषित करता है कि Deep Work Plans अपनी संरचना, कार्यों और प्रगति का दस्तावेज़ीकरण कैसे करती हैं, और एक रिपॉज़िटरी स्वयं का दस्तावेज़ीकरण कैसे करे ताकि कोई एजेंट सुरक्षित रूप से कार्य कर सके। यह DWP पद्धति के अंतर्गत बनाई गई हर योजना पर लागू होता है। यह संस्करण दस्तावेज़ के अपने संस्करण को उस DWP मानक के साथ संरेखित करता है जिसके साथ यह जुड़ा है — किसी मौजूदा आवश्यकता में कोई परिवर्तन नहीं — और नीचे वर्णित lean-index बजट प्रवर्तन तथा feature स्तर जोड़ता है। कीवर्ड MUST, SHOULD और MAY का उपयोग RFC 2119 में परिभाषित अनुसार किया जाता है।

AGENTS.md एक कॉम्पैक्ट प्रवेश-बिंदु के रूप में

रूट AGENTS.md फ़ाइल को SHOULD 150–500 पंक्तियों के बजट के भीतर रहना चाहिए। जब उत्पन्न या harness-अनुरक्षित सामग्री इसे पार कर जाए, एजेंट को MUST विवरण को उस docs/ गाइड (या module/feature दस्तावेज़) में स्थानांतरित करना चाहिए जो उसका स्वामी है और उसे index से लिंक करना चाहिए — कुछ भी हटाया नहीं जाता, केवल पुनर्स्थापित होता है, और index को MUST हर उस दस्तावेज़ को लिंक करना चाहिए जिसे विस्थापित सामग्री मिली। बजट से अधिक कोई मौजूदा हस्तलिखित AGENTS.md कभी चुपचाप फिर से नहीं लिखा जाता: एजेंट एक ठोस माइग्रेशन प्रस्ताव देता है (क्या कहाँ जाता है, कौन से लिंक जुड़ते हैं) और डेवलपर की सहमति मिलने पर ही उसे लागू करता है। एक अनुरूपता जाँचकर्ता इस बजट को सलाहकारी मानता है, क्योंकि पंक्ति-गणना वस्तुनिष्ठ है पर लेखकत्व नहीं — यह MUST उस harness को बाँधता है जो फ़ाइल उत्पन्न या अद्यतन करता है, न कि किसी जाँचकर्ता के इस अनुमान को कि इसे किसने लिखा। AGENTS.md को MUST NOT किसी ऐसी docs/ फ़ाइल को लिंक नहीं करना चाहिए जो मौजूद ही न हो।

प्रति-module दस्तावेज़ स्तर (नीचे) के ऊपर एक feature स्तर है: एक प्रमुख क्षमता क्षेत्र — एक module से बड़ा — अपने कोड के बगल में अपना ही docs/ फ़ोल्डर पाता है, जिसमें अपने ही README.md से प्रवेश होता है। कोई क्षेत्र तब योग्य होता है जब वह दो या अधिक प्रमुख modules तक फैला हो, एक स्व-निहित सब-ऐप या subsystem डायरेक्टरी रखता हो, या अपने ऐसे अनुबंध वहन करता हो (API सतह, event या schema अनुबंध) जिन पर कई उपभोक्ता निर्भर हों। एक बार जब किसी क्षेत्र को प्रमुख के रूप में दर्ज कर लिया जाता है, उसका feature docs/ SHOULD अस्तित्व में होना चाहिए, और उसकी सबसे महत्वपूर्ण प्रविष्टियाँ SHOULD उन modules से लिंक होनी चाहिए जिन तक वह फैला है और रूट AGENTS.md index से, ठीक प्रति-module दस्तावेज़ों की तरह। जानबूझकर बिना दस्तावेज़ के छोड़ा गया क्षेत्र एक दर्ज कारण रखता है — एक निर्णय, कोई चूक नहीं।

योजना README

हर योजना के पास एक README.md MUST हो जिसमें शामिल हो:

शीर्षक — # Deep Work Plan: <name>।
लक्ष्य — योजना के उद्देश्य का एक गद्य कथन।
स्रोत-सामग्री — विहित इनपुट के लिंक या पाथ (वैकल्पिक)।
कार्य — कार्य संख्या, नाम, और एक स्थिति चेकबॉक्स वाली एक markdown तालिका।
स्थिति — <n>/<total> tasks complete रूप में एक पंक्ति।

कार्य फ़ाइलें

हर कार्य फ़ाइल का नाम <n>.task_<slug>.md MUST हो और इसमें दस-खंड संरचना हो — नौ क्लासिक खंड साथ ही Touched Surface: कार्य जो क्या बदलता है और क्या सत्यापित होना चाहिए, इन दोनों के बीच का अनुबंध (योजनाबद्ध बनाम वास्तविक सतह, प्रभावित उपभोक्ता, पृथक, सीम, साझा/कोर या अज्ञात में से एक जोखिम वर्ग, प्रयुक्त परीक्षण-मैपिंग, और कारण सहित चुना गया गेट)।

PROGRESS.md

PROGRESS.md एक केवल-जोड़ने योग्य निष्पादन लॉग है। हर प्रविष्टि को MUST दर्ज करना चाहिए:

एक ISO 8601 टाइमस्टैम्प।
कार्य संख्या और नाम।
क्या किया गया।
कोई विचलन या छोड़ने के कारण।

स्थिति-चिह्न

[ ] — शुरू नहीं हुआ।
[~] — प्रगति में।
[x] — पूर्ण।
[!] — अवरुद्ध।

शीर्षक

सभी शीर्षक वाक्य-केस का उपयोग MUST करें। दस्तावेज़ विपणन भाषा और विस्मयादिबोधक चिह्नों से बचें SHOULD।

Final Review, कार्य-स्थानीय स्किल्स निर्णय, और वैकल्पिक रिपोर्ट

इस संस्करण के अंतर्गत लिखी गई हर योजना ठीक एक अनिवार्य कार्य के साथ समाप्त होनी MUST: Final Review — योजना के पूरे परिवर्तन-सेट पर सुरक्षा-जाँच, अंतिम प्रासंगिक स्थिति पर अंतिम-स्थिति सत्यापन, और स्किल्स निर्णयों का समाधान। एक गंभीर सुरक्षा खोज पूर्णता को अवरुद्ध करती है।

कार्य-स्थानीय स्किल्स निर्णय। हर कार्य का Completion & Log एक स्किल्स निपटान साथ रखता है — कुछ नहीं, किसी मौजूदा स्किल या एजेंट का अद्यतन, एक नामित निर्माण, या कारण और स्वामी सहित एक स्थगन। सार्थक लेखन .agents/ कैटलॉग से डुप्लिकेट-जाँच के बाद, अपने सत्यापन-गेट से पहले, स्वामी कार्य के भीतर ही होता है; सार्थक प्रविष्टियाँ योजना की स्किल्स-उम्मीदवार बही (T{task}-{seq}) में स्थिर उम्मीदवारों के रूप में दर्ज होती हैं।
Executive Report वैकल्पिक है, अनुरोध पर। पूर्णता पर एक बार प्रस्तावित; केवल स्पष्ट अनुरोध पर, टिकाऊ साक्ष्य से उत्पन्न। कोई उत्तर न होना या एक अनुपस्थित रन योजना को इसके बिना ही पूर्ण छोड़ देता है।
Legacy योजनाएँ। पूर्व संस्करणों के अंतर्गत लिखी गई योजनाएँ तीन अनिवार्य अंतिम कार्यों के साथ समाप्त होती हैं और अनुरूप बनी रहती हैं — एक अनुरूपता जाँचकर्ता को वह आकार स्वीकार करना MUST।