Skip to content
Deep Work Plan आज Product Hunt पर है अपवोट करें
← सभी अपडेट
v5 · परीक्षणों द्वारा गारंटीकृत

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

Deep Work Plan 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 से अपनाना शुरू करें।