अनुरूपता

संस्करण 1.3. स्थिति: स्थिर। यह दस्तावेज़ परिभाषित करता है कि किसी रिपॉज़िटरी का Deep Work Plan-अनुरूप होने का क्या अर्थ है — अर्थात्, AI-first और एजेंट-संचालन योग्य। कीवर्ड MUST, MUST NOT, SHOULD, SHOULD NOT और MAY की व्याख्या RFC 2119 में वर्णित अनुसार की जानी है।

अनुरूपता इसलिए मौजूद है ताकि “AI-first” एक प्रभाव के बजाय एक वस्तुनिष्ठ, जाँचने योग्य गुण हो। एक रिपॉज़िटरी या तो नीचे दिए मानदंडों पर खरी उतरती है या नहीं। verify सब-स्किल (/dwp-verify) उन्हें यांत्रिक रूप से जाँचती है।

एक अनुरूप रिपॉज़िटरी

एक DWP-अनुरूप रिपॉज़िटरी को निम्नलिखित सभी संतुष्ट करने MUST। हर आर्टिफ़ैक्ट को रिपॉज़िटरी के लिए तर्क-संगत होना MUST — उसकी वास्तविक भाषाओं, फ़्रेमवर्क और कमांड्स के अनुरूप ढाला हुआ। एक सामान्य स्टब, एक प्लेसहोल्डर, या किसी अन्य रिपॉज़िटरी से कॉपी की गई सामग्री किसी मानदंड को संतुष्ट नहीं करती।

1. रूट पर AGENTS.md। रिपॉज़िटरी में एक रूट AGENTS.md MUST होना चाहिए जिसमें (अ) दस्तावेज़ीकरण का एक इंडेक्स, (ब) रिपॉज़िटरी के लिए अनिवार्य नियम, और (स) एक Quick Commands ब्लॉक हो जिसकी कमांड्स इस रिपॉज़िटरी में वास्तविक और चलाने योग्य हों। प्लेसहोल्डर कमांड्स (उदाहरण के लिए, npm का उपयोग न करने वाली रिपॉज़िटरी में npm test) MUST NOT दिखाई दें। इंडेक्स को MUST NOT किसी ऐसी docs/ फ़ाइल को लिंक नहीं करना चाहिए जो मौजूद न हो, और फ़ाइल को SHOULD 150–500 पंक्तियों के बजट के भीतर रहना चाहिए, बिना सीमा बढ़ने के बजाय विवरण को docs/ में ले जाकर लिंक करते हुए।
2. CLAUDE.md, AGENTS.md तक हल होता है। एक CLAUDE.md MUST मौजूद हो और AGENTS.md तक हल हो (एक सिमलिंक, या एक समकक्ष जो सत्य के एक ही स्रोत की गारंटी देता हो)। दोनों MUST NOT अलग हों।
3. एक docs/ पदानुक्रम। रिपॉज़िटरी में एक docs/ डायरेक्टरी MUST हो जो मानक श्रेणियों (आर्किटेक्चर, मानक, परीक्षण, विकास कमांड्स, सुरक्षा, और एजेंट ऑनबोर्डिंग) को वास्तविक, रिपॉज़िटरी-विशिष्ट सामग्री के साथ कवर करती हो। जटिल मॉड्यूल अपना README.md साथ रखने SHOULD। परीक्षण मार्गदर्शिका को एक वास्तविक test, lint और type-check टूलचेन परिभाषित करना MUST — या, ऐसी रिपॉज़िटरी के लिए जिसके पास कोई न हो, ऑनबोर्डिंग के दौरान स्टैक से प्रस्तावित एक ठोस सेटअप। एक खाली परीक्षण मार्गदर्शिका या “कोई परीक्षण नहीं” इस मानदंड को संतुष्ट नहीं करती: व्यवहार सत्यापित करने के एक परिभाषित तरीके के बिना, किसी योजना के पास कोई वस्तुनिष्ठ सत्यापन-गेट नहीं होता।
4. एक .agents/ घर। रिपॉज़िटरी में एक .agents/ डायरेक्टरी MUST हो जिसमें agents/, commands/, और skills/ हों, साथ ही .agents/docs/ के अंतर्गत एक कैटलॉग जो डिस्क पर मौजूद चीज़ से मेल खाता हो। dwp-* कमांड्स को स्थापित स्किल के पतले डेलिगेटर MUST होना चाहिए। एक .claude पाथ .agents तक हल होना MUST।
5. एक gitignored .dwp/ कार्यस्थल। रिपॉज़िटरी में plans/ वाली एक .dwp/ डायरेक्टरी MUST हो, और .dwp/ को gitignored MUST होना चाहिए। एक tmp/ स्क्रैच स्थान मौजूद SHOULD और gitignored SHOULD।
6. पद्धति स्किल हल करने योग्य है। Deep Work Plan स्किल को इस प्रकार स्थापित या संदर्भित MUST किया जाए कि रिपॉज़िटरी में एक एजेंट उसके सब-स्किल्स आमंत्रित कर सके।

एक रिपॉज़िटरी शून्य वैकल्पिक ऐडऑन के साथ पूर्णतः अनुरूप होती है। वैकल्पिक ऐडऑन (devcontainer, Dailybot, dependency-upgrade, design-system) अनुरूपता के लिए आवश्यक MUST NOT। संस्करण 2.3.0 से AI Diff Reviewer स्थानीय समीक्षा (vendored skill + एक्सटेंशन फ़ाइल) baseline का हिस्सा है: 2.3.0 या नए की घोषणा करने वाली रिपॉज़िटरी के लिए इसकी अनुपस्थिति एक विफलता है, और legacy रिपॉज़िटरी के लिए एक harness-संस्करण खोज। इसकी CI सतह वैकल्पिक बनी रहती है।

एक सुगठित योजना

.dwp/plans/ में एक Deep Work Plan सुगठित होती है जब:

1. हर कार्य को एक स्पष्ट दायरा, स्वीकृति मानदंड, और कम से कम एक सत्यापन-गेट (एक कमांड या जाँच जो वस्तुनिष्ठ रूप से पास या फ़ेल होती है) घोषित करना MUST।
2. हर वह कार्य जो नई मूल कार्यक्षमता जोड़ता है या उत्पाद व्यवहार बदलता है, अपने स्वीकृति मानदंडों में उस व्यवहार के लिए स्वचालित परीक्षण कवरेज शामिल करना MUST, और अपने सत्यापन-गेट में रिपॉज़िटरी के परीक्षणों को उसकी lint और type-check जाँचों के साथ चलाना MUST — न कि अकेले build। मौजूदा परीक्षण हरे बने रहने MUST; एक व्यवहार-परिवर्तन जिस परीक्षण को तोड़े उसे हटाने या छोड़ने के बजाय अद्यतन करना MUST। केवल-दस्तावेज़ीकरण, कॉन्फ़िगरेशन, या शोध कार्य परीक्षण बनाने से छूट प्राप्त हैं पर फिर भी रिपॉज़िटरी का गेट चलाते हैं।
3. हर वह कार्य जो प्रमाणीकरण, इनपुट हैंडलिंग, रहस्यों या कॉन्फ़िगरेशन, नेटवर्क सतह, या निर्भरताओं को छूता है, अपने स्वीकृति मानदंडों में उस परिवर्तन की सुरक्षा अपेक्षाएँ साथ रखना MUST, और हर कमिट को रहस्य-सामग्री से मुक्त होना MUST।
4. योजना को प्रगति इस प्रकार स्थायी करनी MUST कि काम व्यवधान से बचे और एक भिन्न एजेंट द्वारा फिर से शुरू किया जा सके। किसी कार्य को completed MUST NOT दर्ज किया जाना चाहिए जब तक उसका कोई सत्यापन-गेट रिकॉर्ड अब भी विफल, अनसुलझा रन दिखाता हो, और किसी कार्य का अपना पूर्णता-लॉग MUST NOT उसकी दर्ज स्थिति के विपरीत होना चाहिए (उदाहरण के लिए एक completed कार्य जिसका लॉग अब भी “Status: pending” पढ़ता हो, एक पास नहीं बल्कि एक दोष है)।
5. योजना को उसे अपनी दर्ज अंतिम समीक्षा के साथ समाप्त होना MUST। इस संस्करण के अंतर्गत लिखी गई योजना को ठीक एक अनिवार्य Final Review — सुरक्षा-जाँच, अंतिम-स्थिति सत्यापन, और स्किल्स समाधान — के साथ समाप्त होना MUST। किसी पूर्व संस्करण के अंतर्गत लिखी गई योजना तीन अनिवार्य अंतिम कार्यों (Security Review, Skills & Agents Discovery, Executive Report) के साथ समाप्त होती है और अनुरूप बनी रहती है। एक गंभीर सुरक्षा खोज, ठीक किए जाने या स्पष्ट रूप से स्वीकार किए जाने तक पूर्णता को अवरुद्ध करती है। पूर्णता स्वयं एक साधारण स्थिति-परिवर्तन के बजाय एक सत्यापित, पुनर्प्राप्ति-योग्य लेनदेन है: अंतिम कार्य एक संरक्षित प्रकाशन-चरण के माध्यम से बंद होता है जो स्थिति लिखने से पहले पूर्ण योजना की कलाकृतियों को सत्यापित करता है और एक मशीन-जाँच-योग्य FINALIZATION.json रसीद छोड़ता है; एक बाधित प्रकाशन साक्ष्य से पुनर्प्राप्त किया जाता है, कभी चुपचाप पूर्ण घोषित नहीं किया जाता। किसी गेट-रिकॉर्ड द्वारा उद्धृत कोई भी साक्ष्य-पॉइंटर MUST योजना के अपने फ़ोल्डर के भीतर हल होना चाहिए — एक लटकता या दायरे से बाहर भागता पॉइंटर एक पास साक्ष्य नहीं बल्कि एक खोज है।
6. कार्यों को निष्पादन से पहले योजना के लक्ष्य से फिर जुड़ना SHOULD, ताकि एक लंबे क्षितिज पर भटकाव रोका जा सके।

अनुरूपता सत्यापित करना

अनुरूपता को निरीक्षण के बजाय यांत्रिक रूप से सत्यापित करना SHOULD। /dwp-verify चलाने से उपरोक्त मानदंडों के विरुद्ध एक पास/फ़ेल रिपोर्ट बनती है: AGENTS.md की उपस्थिति और वास्तविक-सामग्री, CLAUDE.md हल होना, docs/ श्रेणियाँ, .agents/ कैटलॉग-बनाम-डिस्क मेल, .dwp/ और tmp/ gitignore स्थिति, और — एक योजना के लिए — कि हर कार्य स्वीकृति मानदंड और एक सत्यापन-गेट साथ रखता है, व्यवहार-बदलने वाले कार्यों के लिए परीक्षण कवरेज और दर्ज अंतिम समीक्षा की उपस्थिति के साथ। एक योजना के लिए, यह यह भी जाँचता है कि योजना का markdown और उसकी मशीन-पठनीय स्थिति सहमत हैं (एक desynced README और state.json एक खोज है, कभी चुपचाप स्वीकृत पास नहीं), कि पूर्ण कार्य बिना विरोधाभास वाले गेट और लॉग साक्ष्य साथ रखते हैं, और — जहाँ कोई पूर्ण योजना उस बिंदु तक पहुँचती है — कि एक प्रकाशन-रसीद उस पूर्णता का समर्थन करती है जिसका वह दावा करती है। जाँचकर्ता संस्करण-जागरूक है: उसे एक legacy योजना (तीन अनिवार्य अंतिम कार्य, कोई Touched Surface नहीं) अनुरूप मानना MUST, और ऐसी योजना को अस्वीकार करना MUST जो इस संस्करण की घोषणा करती हो और उसके अंतर्गत वस्तुनिष्ठ रूप से अमान्य हो। वह एक अनुपस्थित या पुरानी DWP standard: उद्गम-पंक्ति को targeted harness upgrade को नाम देने वाली खोज के रूप में भी रिपोर्ट करता है। यांत्रिक परत अपनी सीमाओं के प्रति ईमानदार है: सक्षम इंटरप्रेटर (Python 3.9+) के बिना यह अपनी जाँचें छोड़ने के बजाय गैर-शून्य एग्जिट कोड और स्पष्ट UNVERIFIED निर्णय के साथ समाप्त होती है — कोई सत्यापनकर्ता उस परिणाम की रिपोर्ट नहीं करता जिसका उसने सत्यापन नहीं किया।

एक रिपॉज़िटरी को ऑनबोर्डिंग के बाद और हर पूर्ण योजना के बाद फिर से सत्यापित करना SHOULD, ताकि अनुरूपता एक बार दावा करने के बजाय बनाए रखी जाए।