Onboarding a legacy service

उस पहले काम का एक उदाहरणात्मक विवरण जो अधिकांश टीमें करती हैं: एक मौजूदा, कम-दस्तावेज़ित रिपॉज़िटरी को लें और उसे agent-pilotable बनाएं — बिना उस चीज़ को बाधित किए जो पहले से काम करती है।

1. 01 Analyze →
2. 02 Reason →
3. 03 Onboard →
4. 04 Verify

reconcile, never overwrite

लक्ष्य

“इस पाँच-वर्षीय सेवा को AI-first बनाएं।” इसमें पहले से एक आंशिक README, कुछ बिखरे docs, और कोई AGENTS.md नहीं है।

निष्पादन

डेवलपर अपने एजेंट को एक पंक्ति सौंपता है — /init.md पढ़ें और उसका पालन करें — और ऑनबोर्डिंग प्रवाह:

1. टोह लेना। वास्तविक भाषा, package manager (मौजूद lockfile से), और वास्तविक build, test, तथा lint कमांड का पता लगाता है — रिपॉज़िटरी पढ़कर, अनुमान लगाकर नहीं।
2. एक योजना प्रस्तावित करता है और पूछता है। चूँकि आर्टिफ़ैक्ट पहले से मौजूद हैं, यह गैर-विनाशकारी है: यह सूचीबद्ध करता है कि यह क्या बनाएगा बनाम क्या समाधान करेगा, और आंशिक README या बिखरे docs को छूने से पहले अनुमोदन की प्रतीक्षा करता है।
3. harness उत्पन्न करता है। सेवा के वास्तविक Quick Commands वाली एक तर्कसंगत AGENTS.md, एक श्रेणीबद्ध docs/ ट्री जो मौजूदा नोट्स को दोहराने के बजाय आत्मसात करती है, प्रति-module READMEs, .agents/ किट, और एक gitignored .dwp/।
4. सत्यापित करता है। /dwp-verify अनुरूपता मानदंडों के विरुद्ध एक वस्तुनिष्ठ pass/fail रिपोर्ट लौटाता है।

परिणाम

legacy सेवा कुछ भी नष्ट किए बिना AI-first बन जाती है: मौजूदा काम विलय किया जाता है, अधिलेखित नहीं, और परिणाम जताया नहीं बल्कि जाँचा जा सकता है। यहाँ से टीम /dwp-create और /dwp-execute के साथ वास्तविक काम की योजना बनाती और निष्पादित करती है।