मूल लूप

DWP संक्रियाओं का एक छोटा समूह परिभाषित करता है जो एक योजना को लक्ष्य से पूर्ण, समीक्षा योग्य काम तक ले जाता है: create → execute → refine → resume → status, जिसमें verify वह अनुरूपता-जाँच है जो परिणाम की पुष्टि करती है। मिलकर वे वह लूप बनाते हैं जिसका एक एजेंट योजना के पूरे जीवन में अनुसरण करता है। एजेंट एक बार में एक कार्य निष्पादित करते हैं, आगे बढ़ने से पहले हर चरण को सत्यापित करते हुए।

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

संक्रियाएँ

• create — एक लक्ष्य से एक नई योजना तैयार करें। एजेंट लक्ष्य का विश्लेषण करता है, उसे क्रमिक कार्यों में विघटित करता है, और योजना फ़ाइलें लिखता है। लक्ष्य अस्पष्ट होने पर इसे लिखने से पहले स्पष्टीकरण प्रश्न पूछने चाहिए। Guided मोड में एजेंट सीधे एक Lite योजना को मैटेरियलाइज़ करता है — एक संक्षिप्त, पहले से ही निष्पादन-योग्य प्रस्ताव — और डेवलपर तय करता है कि इसे रखना है, कार्य-फ़ाइल आधारित Full योजना में प्रोन्नत करना है, संपादित करना है, या रुक जाना है; trust मोड में एजेंट चुने गए प्रतिनिधित्व (Lite या Full) को बिना किसी समीक्षा चरण के सीधे मैटेरियलाइज़ करता है। दोनों प्रतिनिधित्वों के लिए विनिर्देश देखें। आवश्यकता विश्लेषण और योजना-गुणवत्ता जाँच दोनों ही स्थितियों में चलती है।
• execute — योजना को कार्य-दर-कार्य चलाएँ। एजेंट हर कार्य के बाद प्रगति लॉग अद्यतन करता है और कार्य की पूर्णता स्थिति अंकित करता है। उसे कारण दर्ज किए बिना कार्य नहीं छोड़ने चाहिए।
• refine — एक मौजूदा योजना को संशोधित करें। एजेंट कार्य जोड़, हटा या पुनः-क्रमित कर सकता है, पर उसे पूर्ण किए गए काम को संरक्षित रखना चाहिए और कार्य-तालिका अद्यतन करनी चाहिए।
• resume — एक बाधित योजना को जारी रखें। एजेंट स्थिति का पुनर्निर्माण करने के लिए प्रगति लॉग और कार्य फ़ाइलें पढ़ता है, फिर पहले अधूरे कार्य से जारी रखता है।
• status — बिना निष्पादन के प्रगति की रिपोर्ट दें। एजेंट पूर्ण, प्रगति-शील और लंबित कार्यों का सारांश देता है और कुछ नहीं बदलता।
• verify — बिना कुछ बदले अनुरूपता जाँचें। एजेंट रिपोर्ट करता है कि रिपॉज़िटरी मानक पर खरी उतरती है या नहीं और योजना सुगठित है या नहीं — हर कार्य स्वीकृति मानदंड और एक सत्यापन-गेट साथ रखता हुआ। देखें विनिर्देश का अनुरूपता दस्तावेज़।

.dwp/ आउटपुट डायरेक्टरी

सभी DWP आर्टिफ़ैक्ट रिपॉज़िटरी रूट पर एक gitignored .dwp/ डायरेक्टरी के अंतर्गत रहते हैं। कार्यस्थल को संस्करण-नियंत्रण से बाहर रखने का अर्थ है कि किसी योजना की कार्यशील स्थिति कभी परियोजना के इतिहास को दूषित नहीं करती।

.dwp/
├── plans/
│   └── PLAN_<slug>/
│       ├── README.md
│       ├── PROGRESS.md
│       └── <n>.task_<slug>.md
└── config.yaml

दस-खंड कार्य-संरचना

कार्य फ़ाइल

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

हर कार्य फ़ाइल में ये दस खंड क्रम में होते हैं। यह संरचना सुनिश्चित करती है कि काम की हर इकाई स्व-निहित और समीक्षा योग्य हो:

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

सत्यापन, पूर्णता और पुनरारंभ

सत्यापन कार्य का हिस्सा है, बाद का विचार नहीं: हर कार्य उन कमांड्स या परीक्षणों का नाम लेता है जो सिद्ध करते हैं कि यह पूरा हो गया, और एजेंट पूर्णता अंकित करने से पहले उन्हें चलाता है। परीक्षण यहाँ प्रथम-श्रेणी हैं — एक कार्य जो नई कार्यक्षमता जोड़ता है या व्यवहार बदलता है, उसे उस व्यवहार के लिए स्वचालित परीक्षण जोड़ने या अद्यतन करने चाहिए और रिपॉज़िटरी की पूर्ण कोड-गुणवत्ता जाँच (परीक्षण साथ ही lint और type-check) चलानी चाहिए, न कि केवल यह पुष्टि करनी चाहिए कि build सफल होता है; मौजूदा परीक्षण हरे बने रहने चाहिए, छोड़े जाने के बजाय इच्छित व्यवहार के अनुरूप अद्यतन किए हुए। सुरक्षा ठीक उसी तरह प्रथम-श्रेणी है — कोई भी कार्य जो प्रमाणीकरण, input handling, secrets, network सतह, या dependencies को छूता है, उस परिवर्तन की सुरक्षा अपेक्षाएँ अपने स्वीकृति मानदंडों में रखता है और हर commit को secrets से मुक्त रखता है, और हर योजना Final Review के साथ समाप्त होती है — पूरे change set पर सुरक्षा-जाँच, अंतिम स्थिति पर पूर्ण सत्यापन, और स्किल्स निर्णयों का समाधान। पूर्णता को Completion & Log खंड में एक स्पष्ट स्थिति-चिह्न ([ ] शुरू नहीं हुआ, [~] प्रगति में, [x] पूर्ण, [!] अवरुद्ध) के साथ दर्ज किया जाता है। पुनरारंभ इन चिह्नों और प्रगति लॉग पर निर्भर करता है — एक एजेंट ठीक-ठीक पुनर्निर्माण कर सकता है कि योजना कहाँ रुकी और पूर्ण किए गए काम को दोहराए बिना पहले अधूरे कार्य से जारी रख सकता है।