Skip to content
← सभी अध्याय

अध्याय 03

योजना और कार्य टेम्पलेट

एक Deep Work Plan markdown फ़ाइलों की एक डायरेक्टरी है। उस डायरेक्टरी का आकार — और उसके भीतर हर फ़ाइल का — ही एक योजना को मनुष्यों और एजेंट्स, दोनों के लिए समीक्षा योग्य बनाता है।

योजना संरचना

एक योजना .dwp/plans/ के अंतर्गत PLAN_001_<slug>/ नाम की एक डायरेक्टरी है। इसमें शामिल है:

  • manifest.json — योजना की पहचान और उसके लाइव अनुबंध का सूचक, जो भौतिकीकरण के समय सबसे पहले लिखा जाता है।
  • contract.json — अपरिवर्तनीय, सामग्री-संबोधित परिणाम अनुबंध (स्वीकृति मानदंड, दायरा, अपरिवर्तनीय नियम)।
  • journal.ndjson — बहीखाता घटनाओं का केवल-जोड़ने योग्य निष्पादन लॉग।
  • state.json — journal से प्रक्षेपित एक स्नैपशॉट, जिसे कभी हाथ से संपादित नहीं किया जाता।
  • README.md — योजना का अवलोकन: लक्ष्य, स्रोत-सामग्री, कार्य-तालिका और स्थिति।
  • PROGRESS.md — मानव-पठनीय चालू निष्पादन लॉग।
  • 1.task_<slug>.md, 2.task_<slug>.md — व्यक्तिगत कार्य markdown फ़ाइलें।
  • analysis_results/ — कार्य कलाकृतियों, विश्लेषण रिपोर्टों, और गेट साक्ष्यों की डायरेक्टरी।

वर्तमान 7.x पैक डिफ़ॉल्ट रूप से 2–5 शब्दों वाले slug के साथ v7 प्लान बनाता है, जैसा v6 प्लान में होता है। संरक्षित v5 प्रवाह 2–4 शब्दों का उपयोग करता है क्योंकि इसके स्थिर स्कीमा संख्यात्मक ID को एक शब्द गिनते हैं। नई योजनाओं को कम-से-कम तीन अंकों वाली क्रमशः बढ़ती संख्यात्मक ID मिलती है (उदाहरण: PLAN_001_add_payment_webhooks/)। मौजूदा बिना नंबर वाले PLAN_<slug>/ फ़ोल्डर पढ़ने योग्य बने रहते हैं और उनका नाम कभी नहीं बदला जाता; मौजूदा योजनाओं को कभी भी अंतर्निहित रूप से माइग्रेट नहीं किया जाता। नंबर वाली योजनाएँ मौजूद होने पर latest सबसे बड़ी संख्यात्मक ID वाली योजना को दर्शाता है।

कार्य फ़ाइल संरचना

हर कार्य फ़ाइल का नाम <n>.task_<slug>.md होता है और यह स्थापित स्किल द्वारा परिभाषित दस मानक खंडों का अनुसरण करती है (कार्य संरचना के लिए मूल लूप देखें)। हर कार्य कार्य करने से पहले योजना के लक्ष्य से फिर जुड़ता है, जो एक एजेंट को एक लंबे, बहु-घंटे क्षितिज पर भटकने से रोकता है।

Final Review

हर योजना ठीक एक अनिवार्य कार्य के साथ समाप्त होनी चाहिए: Final Review। यह योजना को पाँच क्रमित चरणों में बंद करता है — सुरक्षा-जाँच या गेट्स में कुछ भी ढीला नहीं किया जाता:

  1. सुरक्षा-जाँच — योजना ने जो कुछ भी बदला उसका रहस्यों, इंजेक्शन जोखिमों और नई आक्रमण-सतह के लिए ऑडिट करें, docs/SECURITY.md को अद्यतन रखें, और योजना के पूरे दायरे में आवश्यक स्थानीय AI Diff Reviewer समीक्षा चलाएँ (समीक्षक के अनुपस्थित होने पर इसे local reviewer not installed खोज के रूप में दर्ज किया जाता है, कभी चुपचाप छोड़ा नहीं जाता)। एक गंभीर खोज पूर्णता को अवरुद्ध करती है।
  2. अंतिम-स्थिति सत्यापन — रिपॉज़िटरी का पूर्ण लागू परीक्षण, लिंट, और प्रकार-जाँच सुइट अंतिम स्थिति पर चलता है और उत्तीर्ण होता है। समीक्षा के दौरान किया गया कोई भी सुधार प्रभावित परिणामों को अमान्य करता है और पुन: चलाने का कारण बनता है।
  3. स्किल्स समाधान — सत्यापित करें कि हर कार्य ने अपनी कार्य-स्थानीय स्किल्स-स्थिति दर्ज की है और analysis_results/SKILLS_CANDIDATES.md में किसी भी वारंटेड लेखन का मिलान करें।
  4. दस्तावेज़ समाधान — व्यवहार बदलने वाले हर कार्य की स्पर्श की गई सतह की उन दस्तावेज़ों से तुलना करें जो इसे पंजीकृत करते हैं (docs/TESTING_GUIDE.md, आर्किटेक्चर दस्तावेज़, और AGENTS.md)।
  5. पूर्णता — योजना के रिकॉर्ड सहमत हैं (कार्य सूची, प्रगति लॉग और v6 तथा v7 योजनाओं में journal-व्युत्पन्न स्नैपशॉट व रसीद); डिलिवरेबल्स, साक्ष्य और सीमाओं की रिपोर्ट करें, और Executive Report एक बार प्रस्तुत करें।

README और PROGRESS परिपाटियाँ

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

PROGRESS.md एक केवल-जोड़ने योग्य निष्पादन लॉग है। हर प्रविष्टि एक ISO 8601 टाइमस्टैम्प, कार्य संख्या और नाम, क्या किया गया, और कोई विचलन या छोड़ने के कारण दर्ज करती है। क्योंकि यह केवल बढ़ता ही है, यह इस बात का एक भरोसेमंद इतिहास है कि योजना वास्तव में कैसे आगे बढ़ी।

शीर्षक और परस्पर-संदर्भ

सभी शीर्षक वाक्य-केस का उपयोग करते हैं, और दस्तावेज़ विपणन भाषा तथा विस्मयादिबोधक चिह्नों से बचते हैं। ये परिपाटियाँ योजनाओं को एजेंट्स के पार और समय के साथ संगत रखती हैं।