DWP v5: वादे, अब गारंटीकृत

आज हम Deep Work Plan v5 जारी कर रहे हैं। यह कोई फिर से लिखा गया संस्करण नहीं है: यह महीनों के वास्तविक उपयोग का नतीजा है — जिसमें 108 वास्तविक योजनाओं का सीधा ऑडिट भी शामिल है — जिसने कमी-दर-कमी यह उजागर किया कि पद्धति के वादे और एजेंट का वास्तविक व्यवहार कहाँ अलग हो सकते थे। इस रिलीज़ का ईमानदार सारांश: यह पद्धति यह सब पहले से ही वादा करती थी — अब यह इसकी गारंटी देती है। v5 से पहले, दस्तावेज़ का अक्षरशः पालन करने वाला एजेंट भी वास्तविक विफलता परिदृश्यों में पहुँच सकता था; इस उपयोग और फीडबैक के ज़रिए पहचाना गया ऐसा हर परिदृश्य अब बंद किया गया है और एक निष्पादनयोग्य परीक्षण से पिन किया गया है, न कि और अधिक गद्य से ढका गया है। इस चक्र में स्किल का अनुबंध सूट 132 से बढ़कर 258 परीक्षणों तक पहुँचा, और नीचे की हर गारंटी जारी टैग के विरुद्ध लाइव मान्य की गई — एक साफ रिपॉज़िटरी में इंस्टॉल करके उसके अपने ही प्रवाहों से गुज़ारा गया, तभी यह प्रविष्टि लिखी गई।

ऐसा सत्यापनकर्ता जो कभी असत्यापित सफलता का दावा नहीं करता। अनुरूपता जाँचें पहले चुपचाप घटिया हो जाती थीं: सक्षम इंटरप्रेटर के बिना वे हर सत्यापन छोड़ देती थीं और फिर भी अनुरूप निर्णय छाप देती थीं, और किसी फ़ील्ड के भीतर का बोल्ड टेक्स्ट गायब फ़ील्ड समझा जा सकता था। अब सत्यापनकर्ता जब भी सच में सत्यापित नहीं कर पाता, स्पष्ट UNVERIFIED निर्णय के साथ समाप्त होता है। सत्यापनकर्ता कभी उस सफलता की रिपोर्ट नहीं करता जिसकी उसने जाँच नहीं की — गेट्स पर भरोसा ही पूरा प्रस्ताव है, और वह गेट जो अपनी ही जाँच छोड़ सकता है, वह भरोसे की श्रृंखला तोड़ देता है।

Lite योजनाओं के लिए एकमात्र स्वीकृति अनुबंध। “क्या यह योजना शुरू करना उसके वर्तमान दायरे को स्वीकृति देता है?” — इस प्रश्न का उत्तर तीन सतहें तीन तरह से देती थीं, और एजेंट सबसे खतरनाक सीमा पर ही गतिरोध में फँस सकता था या बिना प्राधिकरण के चल सकता था। v5 हर जगह एक अनुबंध स्थापित करता है: स्पष्ट execute या resume वर्तमान ready दायरे को स्वीकृति देता है और किसी भी काम से पहले वह स्वीकृति दर्ज करता है; लंबित प्रस्ताव अकेले कुछ भी प्राधिकृत नहीं करता; बाधित प्रमोशन को किसी भी प्रोडक्ट काम के चलने से पहले पुनर्प्राप्त किया जाता है।

बहु-रिपॉज़िटरी ऑर्केस्ट्रेशन जो भ्रष्ट नहीं कर सकता। ऑर्केस्ट्रेटर हब का पर्यावरण ओवरराइड पहले उसकी चाइल्ड रिपॉज़िटरी में रिस जाता था — एक चाइल्ड हब के अपने फ़ोल्डरों में योजना-स्थिति लिख सकता था। ऑर्केस्ट्रेटर टेम्पलेट FAIL छापकर भी सफलता के साथ बाहर निकलते थे, और केवल स्थिति-स्ट्रिंग grep करने वाली पूर्णता जाँच एक पूर्ण कार्य को पूर्ण योजना पढ़ सकती थी। अब हब की जड़ सब-रिपॉज़िटरी में जाने से पहले सहेजी जाती है, हर चाइल्ड अपना .dwp/ पृथक् रूप से हल करता है, विफलता की हर शाखा त्रुटि के साथ बाहर निकलती है, पूर्णता योजना की शीर्ष-स्तरीय स्थिति से पार्स होती है, और devcontainer एंट्रीपॉइंट कुछ भी मिटाने से पहले कॉपी त्रुटियों को आगे बढ़ाता है।

ऐड-ऑन के लिए एकमात्र सहमति मैट्रिक्स। कौन-सा ऐड-ऑन डिफ़ॉल्ट रूप से इंस्टॉल होता है, कौन-सा केवल प्रस्तावित होता है, और कौन-सी समीक्षा अनिवार्य है — पहले की सतहें अलग-अलग उत्तर देती थीं। v5 एक मैट्रिक्स घोषित करता है: AI Diff Reviewer स्थानीय समीक्षा के लिए अनिवार्य है, सत्यापित रिलीज़ पर पिन किया गया है, और CI समीक्षा एक स्पष्ट opt-in है जो कभी खुद को इंस्टॉल नहीं करता; design-system ऐड-ऑन UI काम का पता चलने पर अनिवार्य प्रस्ताव है, पर इंस्टॉल केवल स्पष्ट स्वीकृति से होता है; dependency-upgrade ऐड-ऑन लगभग-डिफ़ॉल्ट निष्क्रिय डेलिगेटर के रूप में आता है, सटीक स्नैपशॉट रोलबैक के साथ; dailybot केवल वहीं रिपोर्ट करता है जहाँ अधिकृत हो। खाली diff अब पूर्ण समीक्षा नहीं गिना जाता।

लंबी योजनाओं के लिए वास्तविक तंत्र। 108 वास्तविक योजनाओं के ऑडिट से पता चला कि समानांतर-योग्य काम आम था, पर अनुक्रमिक निर्णय लगभग कभी घोषित नहीं होता था, और स्टेज गेट केवल तदर्थ अभ्यास के रूप में विद्यमान थे। v5 निष्पादन निर्णय को हमेशा घोषित करवाता है — जब समानांतरकरण उचित नहीं होता तो अंकित कारण के साथ अनुक्रमिक — बीस या अधिक कार्यों की योजनाओं के लिए वैकल्पिक Stage Gates जोड़ता है, और Plan Variables को कठोरता स्तर, साक्ष्य-सीमा और निषिद्ध क्रियाओं से समृद्ध करता है। यह सब प्रगतिशील रूप से लोड होता है और कभी Lite योजना पर भार नहीं डालता।

Context अनिवार्य, प्रति कार्य एक ही उद्देश्य। योजनाएँ संदर्भ-रहित कार्य-सूचियों में खिसक सकती थीं, और एक कार्य एक हरे गेट के पीछे तीन उद्देश्य बाँध सकता था। v5 योजना-स्तर पर Goal और Context की जोड़ी अनिवार्य करता है, हर नए रिकॉर्ड पर प्रति-कार्य Context — जो एक नया सत्र उस कार्य को अकेले शुरू करने के लिए चाहता है — (पूर्ण रिकॉर्ड जैसे लिखे गए वैसे ही रहते हैं) अनिवार्य करता है, और प्रति कार्य एक उद्देश्य को क्षय-रोधी रक्षा के साथ मानक नियम बनाता है।

सुरक्षित अपग्रेड पथ। /dwp-upgrade नया है। इसका जाँच चरण केवल-पठन है और कुछ भी इंस्टॉल नहीं करता; अपग्रेड केवल स्पष्ट स्वीकृति से शुरू होता है, कुछ भी अधिलेखित करने से पहले स्थानीय अनुकूलनों को diff कर प्रदर्शित किया जाता है; इंस्टॉलेशन सटीक टैग को लक्षित करता है और स्वयं को सत्यापित करता है; ऑनबोर्डिंग एक ताज़े init की तरह फिर चलता है। अपग्रेड कभी .dwp/ को नहीं छूता — कोई योजना, स्थिति फ़ाइल, गेट रिकॉर्ड या साक्ष्य स्थानांतरित, पुनर्लिखित या अमान्य नहीं किया जाता।

ईमानदार, मापने योग्य साक्ष्य। दक्षता के दावे अब तीन बेसलाइनों — v3.0.0, v4.0.3 और अंतिम ट्री — पर फिर से मापे जाते हैं, और मापन स्क्रिप्ट रिपॉज़िटरी में कमिट है। परिणाम फ़ाइलसिस्टम बाइट्स में रिपोर्ट होते हैं और कभी उन टोकन या लागत संख्याओं में बदले नहीं जाते जिनका समर्थन हम नहीं कर सकते; हर असत्यापनीय दावा मूल्यांकन रिकॉर्ड में ऐसे ही क्वारंटीन किया जाता है।

एक संस्करणबद्ध, प्रकाशित अनुबंध। ऊपर का हर वादा केवल गद्य से नहीं, बल्कि ऐसे डेटा से समर्थित है जिसे अन्य टूल पढ़ सकते हैं: plan-manifest और plan-state प्रारूप अब v5 स्कीमा लाइन के रूप में संस्करणबद्ध हैं — plan-manifest/v5.json और plan-state/v5.json — ताकि कोई योजना, कोई सत्यापनकर्ता, या कोई तीसरे पक्ष का टूल दस्तावेज़ के एक पैराग्राफ के बजाय एक प्रकाशित, मशीन-पठनीय अनुबंध के विरुद्ध अनुरूपता जाँच सके। v5 लाइन में v2 की तुलना में आकार कुछ भी नहीं बदलता: v1 या v2 स्कीमा का संदर्भ देने वाली मौजूदा योजनाएँ वैध बनी रहती हैं और कभी फिर से नहीं लिखी जातीं।

Deep Work Plan v5, DWP मानक 5.0.0 का पालन करता है। मानक विनिर्देश पढ़ें, स्किल रिपॉज़िटरी देखें, या /init से अपनाना शुरू करें।

अपडेट — 2026-09-17 · स्किल v5.4.0

v5 शृंखला की पहली पॉइंट रिलीज़ उस अंतिम रास्ते को बंद करती है जिससे कोई योजना ऐसे काम पर समाप्त हो सकती थी जिसकी कभी सचमुच जाँच ही नहीं हुई, और यह तय करती है कि योजना का अपना प्रमाण कहाँ रहेगा। DWP संस्करण 5.0.0 अपरिवर्तित है: यह ऐड-ऑन अनुबंध और दस्तावेज़ीकरण की रिलीज़ है, स्कीमा परिवर्तन नहीं।

जो समीक्षा कभी चली ही नहीं, वह अब साफ़ समीक्षा से अभिन्न नहीं रही। Final Review की सुरक्षा-जाँच पहले से ही अनुपस्थित समीक्षक — जो निष्कर्ष के रूप में दर्ज होता है — और विफल आह्वान, जो एक बार चेतावनी देकर आगे बढ़ जाता है, में अंतर करती थी। ऊपरी धारा के समीक्षक ने एक तीसरा अंत जोड़ा: वह चालन जो शुरू होता है और फिर एक भी निष्कर्ष लिखे बिना समाप्त हो जाता है। नाम न होने पर वह “जाँच पूरी हुई और कुछ नहीं मिला” में घुल जाता था, जिससे ऐसी समीक्षा के आधार पर योजना बंद की जा सकती थी जो हुई ही नहीं। अब वह अपने आप में एक स्थिति है: अधूरी समीक्षा के रूप में दर्ज, परिवर्तन-समुच्चय के साफ़ होने का प्रमाण कभी नहीं, और Final Review बंद करने का कारण कभी नहीं। तीन अलग अंत — और इनमें से कोई यह नहीं कहता कि diff पढ़ा गया और साफ़ निकला।

किसी योजना का प्रमाण उसी योजना का है। मानक पहले से ही विश्लेषण-अभिलेख, skills बही, सुरक्षा समीक्षा और गेट लॉग को योजना के अपने analysis_results/ में रखता था, पर उस अनन्यता को कभी नियम के रूप में नहीं कहा था। इसीलिए रिपॉज़िटरी का अपना ऑडिट उपकरण, जिसकी रिपोर्ट का पथ डिफ़ॉल्ट रूप से कार्यशील निर्देशिका होता है, किसी योजना का प्रमाण रिपॉज़िटरी की जड़ में लिख सकता था और किसी प्रवाह को पता तक न चलता। विनिर्देश अब इसकी माँग करता है: कोई प्रवाह किसी योजना के बारे में जो भी बनाता है वह उसी योजना के फ़ोल्डर में जाता है, और जिस उपकरण का डिफ़ॉल्ट आउटपुट कार्यशील निर्देशिका है उसे उसका स्पष्ट आउटपुट विकल्प देना होगा। जो प्रमाण वहाँ नहीं है जहाँ योजना कहती है, वह खो चुका प्रमाण है — यही इस नियम का व्यावहारिक कारण है, कोई फ़ाइलिंग पसंद नहीं।

AI Diff Reviewer का पिन v2.3.0 हो गया। अनिवार्य स्थानीय समीक्षा अब ऐसा समीक्षक स्थापित करती है जो runner को backend से अलग करता है: इसलिए वही समीक्षा किसी भी संगत endpoint पर चल सकती है, बिना यह बदले कि DWP किस पर निर्भर है — तटस्थता की गारंटी ढीली नहीं, मज़बूत होती है। साथ में चेकसम से सत्यापित इंस्टॉलर, अनुमान के बजाय मापे गए डिफ़ॉल्ट खर्च, और ऐसी अनुवर्ती राउंड जो लंबित निष्कर्षों को आगे ले जाते हुए असली नए diff की समीक्षा करती हैं। अंतिम बात का एक अनुबंधगत परिणाम है जिसे साफ़ कहना चाहिए: किसी मॉडल का यह दावा कि निष्कर्ष हल हो गया, उसे वापस नहीं लेता — उसे अनुरक्षक वापस लेता है।

कार्य-सिद्धांत अब harness के साथ ही आते हैं। उसी दिन आई v5.5.0 के बाद ऑनबोर्डिंग किसी रिपॉज़िटरी के agents को केवल यह नहीं बताती कि उसमें क्या है, बल्कि यह भी सिखाती है कि कैसे काम करना है: दस संक्षिप्त व्यवहार — परिणाम की ज़िम्मेदारी लेना, पूछने से पहले जाँच करना, नित्य निर्णय स्वतंत्र रूप से लेना, जब विवेक या अधिकार वास्तव में न हो तब ऊपर ले जाना, और पूर्ण होने का दावा करने से पहले सत्यापित करना, इत्यादि — AGENTS.md में इनलाइन लिखे जाते हैं, जहाँ केवल प्रवेश-बिंदु पढ़ने वाला agent भी उन्हें पा लेगा। ये किसी अनुरोध के भीतर के डिफ़ॉल्ट हैं, नया अधिकार नहीं: ये होस्ट की अनुमतियों, संकरे दायरे, किसी योजना के गेट, या रिपॉज़िटरी के अपने अनुमोदन-नियमों को नहीं लाँघ सकते। अपग्रेड इन्हें कीवर्ड से नहीं, अर्थ से मिलाता है, इसलिए फ़ाइल में पहले से मौजूद समतुल्य नियम दोबारा लिखे जाने के बजाय बनाए रखे जाते हैं।

AI Diff Reviewer का पिन v2.3.1 हो गया। स्किल v5.5.1 वह समीक्षक स्थापित करती है जिसके check, समीक्षा-पाठ और ट्रैकिंग टिप्पणी मेल खाते हैं। Recommendation: approve कहने वाला पाठ इस बात का प्रमाण नहीं कि check पास हुआ — ट्रैकिंग चिह्न के Check status खंड को पढ़ें। advisory के तहत, एक पुष्ट सुधार उस निष्कर्ष को वापस ले सकता है जिसका थ्रेड पहले से संकुचित है, इसलिए अटकी PR वास्तविक सुधार के बाद हरी हो सकती है।

नियामक पाठ के लिए विनिर्देश, समीक्षक अब क्या करता है इसके लिए ऐड-ऑन संदर्भ, और स्रोत के लिए v5.5.1 रिलीज़ देखें।

अपडेट — 2026-09-25 · skill v5.5.3 + reviewer v3.1.1

AI Diff Reviewer ऐड-ऑन अब reviewer की v3 लाइन को दस्तावेज़ित और इंस्टॉल करता है — 2026-09-24 को रिलीज़ (v3.0.0 → v3.1.1, मूविंग पिन @v3)। skill v5.5.2 ने ऐड-ऑन के नॉर्मेटिव दस्तावेज़, onboarding हुक और इंटीग्रेशन टेम्पलेट को v3 reviewer के वास्तविक व्यवहार के अनुसार फिर से लिखा, और v5.5.3 ने CI पक्ष शिप किया। tag v3.1.1 पर रिलीज़ किए गए reviewer के विरुद्ध सत्यापित सबसे महत्वपूर्ण बदलाव:

एक critical तभी गेट करता है जब सत्यापित हो। v3 से, मॉडल द्वारा की गई हर गंभीर दावा — साथ में चेतावनियों का 30 % नमूना — एक अलग मॉडल कॉल द्वारा दूसरी छोटी कोड-आधारित जाँच पाता है (प्रति सत्यापित निष्कर्ष ≈ 3 k टोकन, 10 सेकंड और $0.009)। कोई critical तभी प्रकाशित होता है — और Final Review को ब्लॉक करता है — जब वह सत्यापनकर्ता उसे पुष्टि करता है; खंडन की गई दावें एनोटेटेड चेतावनियों के रूप में दृश्य रहती हैं और संरचित आउटपुट में सूचीबद्ध होती हैं, कभी इनलाइन पोस्ट नहीं होतीं। अपनी टर्न सीमा (incomplete) या दीवार-घड़ी (timeout) पूरी कर चुकी समीक्षा अवरोधक कठोरता में लाल है: “कोई निष्कर्ष नहीं” अब हमेशा यही मायने रखता है कि समीक्षक ने देखा और कुछ नहीं पाया।

बजट जोखिम-स्तर का पालन करता है। समीक्षा बजट परिवर्तन के निश्चित जोखिम-स्तर से व्युत्पन्न होता है — low से critical तक 8/20/30/40 टर्न — और कोई कोड न बदलने वाला push −93 % लागत पर केवल-सत्यापनकर्ता राउंड चलाता है। budget-profile: fixed संक्रमण काल में v3-पूर्व स्थिरांक बहाल करता है; वृद्धिशील राउंड इनपुट टोकन 62–76 % काटते हैं।

छह sub-skills, उनमें एक लूप। राउटर को address-review मिलता है (v3.1.1 में नया): एक ही आह्वान शाखा के खुले PR ढूँढता है, जाँचता है कि समीक्षा वर्तमान head के लिए ताज़ा है, निष्कर्ष लागू/स्थगित/छोड़ें योजना के साथ प्रस्तुत करता है, फिर — एक हाँ पर — लागू करता है, छोटे Conventional Commits बैचों में कमिट करता है, पुश करता है, और रिपॉज़िटरी के ट्रिगर तरीके के अनुसार समीक्षक को फिर से सक्रिय करता है। apply-review केवल-पठन बना रहता है; संरचित आउटपुट (review-output/3.0) किसी भी ऑटोमेशन का मशीन-मार्ग है। @v2 लाइन release/v2 पर छह महीने की सुरक्षा और कैटलॉग देखभाल के साथ फ़्रीज़ रहती है — v3 अनुशंसा है, कभी ज़बरदस्ती माइग्रेशन नहीं।

reviewer अब अपने घरों की समीक्षा करता है। skill रिपॉज़िटरी और यह वेबसाइट दोनों लेबल-गेटेड CI स्वयं-समीक्षा चलाते हैं — DailybotHQ/ai-diff-reviewer@v3 द्वारा एक एकल grok लेग, ready लेबल के प्रत्येक अनुप्रयोग पर एक बार ट्रिगर (फिर से चलाने के लिए लेबल हटाएँ और दोबारा लगाएँ), प्रदाता secret के अभाव में ईमानदार स्किप के साथ। यह वेबसाइट v3.1.1 reviewer को भी vendorize करती है, इसलिए स्थानीय Final Review और दस्तावेज़ीकरण अब एक ही अनुबंध सिखाते हैं।

स्पेसिफिकेशन, पूर्ण v3 क्षमता सूची के लिए ऐड-ऑन संदर्भ, स्रोत के लिए v5.5.3 रिलीज़, या upstream बदलावों के लिए reviewer v3.1.1 रिलीज़ पढ़ें।