रिपॉज़िटरी आर्किटाइप

कोड की एक भी पंक्ति बदलने से पहले, एजेंट एक ऐसा निर्णय लेता है जो बाद की हर बात को आकार देता है: यह रिपॉज़िटरी किस प्रकार की है? जो आर्किटाइप वह अनुमानित करता है, वह उस सीमा को निर्धारित करता है जिसके भीतर वह पूरे कार्य-काल में तर्क करेगा — वह कैसे ऑनबोर्ड करता है, एक योजना कितनी दूर तक पहुँचती है, और स्थिति कहाँ संग्रहीत होती है। गलती करें और एजेंट गलत सतह पर काम का दायरा बाँध देता है — यह दीर्घकालिक कार्यों में विचलन का सबसे सामान्य कारण है। सही करें और वह घंटों स्वायत्त रूप से काम कर सकता है, क्योंकि योजनाएँ, ऑनबोर्डिंग और स्थिति सभी कोड की वास्तविक संरचना के अनुरूप होती हैं।

DWP तीन आर्किटाइप पहचानता है। अधिकांश रिपॉज़िटरीज़ पहले प्रकार की हैं; दूसरा उन टीमों के लिए है जो कई रिपॉज़िटरीज़ का समन्वय करती हैं; तीसरा स्वायत्त एजेंट्स के दीर्घकालिक कार्यस्थलों को कवर करता है।

व्यक्तिगत रिपॉज़िटरी

एक आत्मनिर्भर कोडबेस

ऑर्केस्ट्रेटर हब

उप-रिपॉज़िटरियों का समन्वय करता है

स्वतंत्र रिपॉज़िटरी

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

विशेषताएँ:

• एक एकल सुसंगत कोडबेस।
• योजनाएँ इस रिपॉज़िटरी की फ़ाइलें संशोधित करती हैं।
• .dwp/ कार्यस्थल रिपॉज़िटरी रूट पर रहता है।

ऑर्केस्ट्रेटर हब

समन्वय का मामला: एक रिपॉज़िटरी जिसका काम अन्य रिपॉज़िटरीज़ का प्रबंधन करना है। यहाँ कार्य की इकाई कोई फ़ाइल नहीं बल्कि एक चाइल्ड रिपॉज़िटरी है, इसलिए योजनाएँ सब-रिपॉज़िटरीज़ में चाइल्ड योजनाएँ उत्पन्न कर सकती हैं, और ऑनबोर्डिंग एकल कोडबेस के बजाय प्रबंधित रिपॉज़िटरीज़ की हब की रजिस्ट्री पढ़ती है। एजेंट सीमाओं और हैंडऑफ़ के बारे में तर्क करता है — कौन-सी रिपॉज़िटरी कौन-से काम की स्वामी है, और उनकी स्थिति संगत कैसे रहती है।

विशेषताएँ:

• कई सब-रिपॉज़िटरीज़ का समन्वय करती है।
• योजनाएँ चाइल्ड योजनाओं को सौंप सकती हैं।
• प्रबंधित रिपॉज़िटरीज़ की एक रजिस्ट्री बनाए रखती है।
• हब रूट पर .dwp/ कार्यस्थल क्रॉस-रिपॉज़िटरी स्थिति को ट्रैक करता है।

एजेंट कार्यस्थल

v2.2 में जोड़ा गया तीसरा आर्किटाइप कुछ ऐसा वर्णन करता है जो एक रिपॉज़िटरी से पहले एक कार्यस्थल है: एक स्वायत्त एजेंट का दीर्घकालिक घर। एक OpenClaw workspace, एक Hermes service directory, एक personal-assistant daemon की data directory, एक cloud agent का persistent volume — प्रत्येक के पास निष्पादित करने के लिए योजनाएँ हैं, उपयोग करने के लिए tools हैं, और बनाए रखने के लिए memory है, लेकिन ship करने के लिए कोई codebase नहीं हो सकता।

मुख्य अंतर्दृष्टि यह है कि हार्नेस एक कार्यस्थल है, विशेष रूप से एक रिपॉज़िटरी नहीं। DWP एक रिपॉज़िटरी में जो हर तत्व स्थापित करता है — AGENTS.md, docs/, .agents/, .dwp/ — उसका एक सीधा कार्यस्थल समकक्ष है। पद्धति की सतह cleanly मैप होती है: standing-context फ़ाइलें रूट AGENTS.md की जगह लेती हैं, एक प्लेटफ़ॉर्म skill directory .agents/ की जगह लेती है, और workspace रूट पर .dwp/ फ़ोल्डर अपरिवर्तित रहता है। जो बदलता है वह git की भूमिका है। एक रिपॉज़िटरी में, git log state वहन करता है और योजनाओं को सत्रों के पार फिर से शुरू करने योग्य बनाता है। git के बिना एक workspace में, state.json वह काम करता है — इसीलिए एजेंट कार्यस्थलों के लिए मशीन-पठनीय स्थिति परत आवश्यक है।

व्यावहारिक परिणाम रात भर के अनुपस्थित योजनाएँ हैं। OpenClaw-class प्लेटफ़ॉर्म पर, एक heartbeat या cron turn एजेंट को जगाता है, DWP resume protocol चलाता है, अगला परमाणु कार्य निष्पादित करता है, state.json अद्यतन करता है, और yield करता है। योजना — सत्र नहीं — निरंतरता की इकाई है। एक बहु-दिवसीय योजना रीस्टार्ट, model swaps, और सत्र सीमाओं से बचती है क्योंकि अगले turn को जो कुछ चाहिए वह सब plan फ़ाइलों में है: लक्ष्य, चिह्नित प्रगति, गेट रिकॉर्ड, और वर्तमान कार्य के भीतर सटीक चेकपॉइंट।

विशेषताएँ:

• एक स्वायत्त एजेंट प्लेटफ़ॉर्म की कार्यशील directory।
• workspace रूट पर AGENTS.md, .agents/, और .dwp/।
• Git recommended है, required नहीं।
• state.json तब required है जब git अनुपस्थित हो, और किसी भी अनुपस्थित run के लिए।
• योजनाएँ आमतौर पर अनुपस्थित चलती हैं, एक अनुसूचित heartbeat या cron द्वारा संचालित।

वर्गीकरण अनुमान-नियम

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

रिपॉज़िटरी

? क्या कई नेस्टेड रिपॉज़िटरी हैं या एक हब रजिस्ट्री है?

नहीं

व्यक्तिगत रिपॉज़िटरी

• एकल कोडबेस
• योजनाएँ स्थानीय फ़ाइलों को संशोधित करती हैं
• .dwp/ रिपॉज़िटरी की जड़ में

हाँ

ऑर्केस्ट्रेटर हब

• उप-रिपॉज़िटरियों का समन्वय करता है
• योजनाएँ चाइल्ड योजनाओं को सौंपती हैं
• रिपॉज़िटरियों के बीच .dwp/ स्थिति

एजेंट को पहले एजेंट-workspace संकेत खोजने चाहिए: एक प्लेटफ़ॉर्म पहचान फ़ाइल (जैसे OpenClaw की SOUL.md या HEARTBEAT.md), कोई प्राथमिक application stack नहीं, और सामग्री जो मुख्यतः एजेंट की अपनी state है। यदि वे अनुपस्थित हों, तो orchestrator संकेत खोजता है: कई नेस्टेड git रिपॉज़िटरीज़ या submodules, प्रबंधित रिपॉज़िटरीज़ की एक registry या manifest, या बाहरी रिपॉज़िटरीज़ की ओर इंगित करती configuration। दोनों की अनुपस्थिति में, यह लक्ष्य को स्वतंत्र रिपॉज़िटरी मानता है — सुरक्षित डिफ़ॉल्ट, क्योंकि उन सीमाओं के पार योजना का अत्यधिक-दायरा बाँधना जो अस्तित्व में ही नहीं हैं, उस एक सीमा के भीतर काम करने से बुरा है जो वास्तव में है।

ऑनबोर्डिंग कैसे भिन्न होती है

आर्किटाइप एक सजावटी लेबल नहीं है; यह बदल देता है कि एजेंट क्या पढ़ता है, एक योजना क्या छू सकती है, और स्थिति कहाँ दर्ज होती है।

व्यावहारिक प्रभाव यह है कि एक स्वतंत्र-रिपॉज़िटरी एजेंट एक कोडबेस पर आद्योपांत तर्क करता है, एक ऑर्केस्ट्रेटर एजेंट रिपॉज़िटरीज़ के पार समन्वय पर तर्क करता है, और एक एजेंट-workspace एजेंट सत्रों के पार निरंतरता पर तर्क करता है — क्या योजनाबद्ध था, क्या चला, क्या अवरुद्ध है, और आगे क्या है।

यही वह बात है जो एजेंट को बिना निगरानी घंटों स्वायत्त रूप से काम करने देती है: पहले आर्किटाइप को निश्चित करके, यह योजनाओं, ऑनबोर्डिंग और स्थिति का दायरा सही सीमा तक बाँधता है, ताकि पहले से लेकर अंतिम कार्य तक हर काम सही सतह पर हो।