यह AI Software Factory रिपॉज़िटरी उत्पाद के उद्देश्य और कार्य से Archon के बनाए पुल रिक्वेस्ट तक का रास्ता बताती है। इंस्टॉलेशन और वर्कफ़्लो जाँच केवल शुरुआत हैं। रखरखावकर्ता की पहले घंटे की मार्गदर्शिका कहती है कि वास्तविक शुरू-से-अंत तक सत्यापन अभी करना बाकी है। यह लेख फ़ैक्टरी कमिट 9e2d85298b45497031009597a6ae0811b66fe6d6 और उसमें निश्चित Archon रिविज़न fad09169ea1b43512bc7ee88470d47f960a3e0f8 पर आधारित है। यह दस्तावेज़ और कोड पढ़कर लिखा गया है; BIG CHANGE के इंस्टॉलेशन या चलाने की रिपोर्ट नहीं है।

यह प्रक्रिया उस टीम के लिए है जिसका ऐप रिपॉज़िटरी या PRD, GitHub अनुमतियों और मॉडल प्रदाता खाते पर नियंत्रण है। अनुरक्षक अपने रिपॉज़िटरी में फ़ैक्टरी क्लोन और इंस्टॉल करने की विधि स्पष्ट रूप से बताता है। निश्चित फ़ैक्टरी फ़ाइल-ट्री में लाइसेंस या नोटिस फ़ाइल नहीं है; यह मार्गदर्शिका व्यापक पुनः उपयोग या पुनर्वितरण अधिकार स्थापित नहीं करती। Archon का MIT लाइसेंस अलग Archon स्रोत पर लागू है। प्रदाता के गोपनीय विवरण कार्य, प्रॉम्प्ट, लॉग या समीक्षा रिकॉर्ड में न डालें।

बड़ा बदलाव

  • क्या बदला: यह कार्यान्वयन निश्चित Archon वर्कफ़्लो पैक से उत्पाद दायरा, कार्य योजना, प्रोग्रामिंग, स्वतंत्र समीक्षा और रनटाइम जाँच जोड़ता है। फ़ैक्टरी प्रोजेक्ट इनपुट और लॉन्चर देती है; साझा पैक में AI चरण हैं।
  • क्यों महत्वपूर्ण: टीम मर्ज के निर्णय से पहले प्रस्ताव को कार्य से खास अंतर, CI परिणाम और चलते उम्मीदवार तक देख सकती है। केवल इंस्टॉलेशन जाँच से यह कड़ी अधूरी है; रखरखावकर्ता वास्तविक एकीकरण का सत्यापन बाकी बताता है।
  • क्या देखें: पहला उपयोगी प्रमाण असली कार्य है जिसका दिया संस्करण सार्थक उपयोगकर्ता प्रक्रियाएँ और स्वतंत्र अलग टेस्ट पास करे, और टीम लागत व समीक्षा रिकॉर्ड देख सके। उसके बाद भी शेड्यूल और डिप्लॉयमेंट अलग निर्णय हैं।

1. रिपॉज़िटरी, अनुमतियाँ और निश्चित स्रोत जाँचें

रखरखावकर्ता के सेटअप निर्देश में Git, Python 3.10 या नया, प्रमाणित gh, जिसके पास workflow दायरा है, GitHub रिमोट, कोडिंग एजेंट, Bun और uv आवश्यक हैं। Git को वर्कफ़्लो फ़ाइलें पुश करना भी आना चाहिए (gh auth setup-git)। एजेंट चलाने से पहले ऐप के मौजूदा टेस्ट, स्टार्ट और CI कमांड, ब्रांच सुरक्षा, GitHub पहुँच, प्रदाता प्रमाणीकरण और मॉडल बिलिंग जाँचें। केवल आवश्यक रिपॉज़िटरी और वर्कफ़्लो अधिकार दें।

फ़ैक्टरी को ऐप रिपॉज़िटरी के बाहर क्लोन करें और बताए गए कमिट पर जाएँ। दस्तावेज़ के इंस्टॉलेशन कमांड ऐप की रूट डायरेक्टरी से चलते हैं:

Terminal
git clone https://github.com/coleam00/ai-software-factory ~/ai-software-factory
git -C ~/ai-software-factory checkout 9e2d85298b45497031009597a6ae0811b66fe6d6
python ~/ai-software-factory/bin/factory.py init

ज़रूरत पर python3 इस्तेमाल करें। इंस्टॉलर फ़ैक्टरी और प्रोजेक्ट टेम्पलेट कॉपी करके pack.json में बताए Archon स्रोत को इंस्टॉल करता है। इस कमिट के README और पैक, दोनों में fad09169ea1b43512bc7ee88470d47f960a3e0f8 है। इंस्टॉलर प्रदाता को प्रमाणित नहीं करता, मॉडल श्रेणियाँ नहीं चुनता और शेड्यूल शुरू नहीं करता। बदलाव स्वीकार करने से पहले बदली गई फ़ाइलें देखें।

इंस्टॉल किए Archon के कॉन्फ़िगरेशन निर्देशों से चुना प्रदाता और समर्थित मॉडल पहचानकर्ता सेट करें। प्रोजेक्ट के वास्तविक स्थिर जाँच और यूनिट टेस्ट कमांड harness/harness.config.json में डालें। GitHub ब्रांच सुरक्षा न बता पाए तो मर्ज के लिए आवश्यक CI जॉब required_checks में लिखें। protected_paths जाँचें ताकि उद्देश्य, जाँच ढाँचे और फ़ैक्टरी नीति में बदलाव के लिए मनुष्य आवश्यक हो। टेम्पलेट सामान्य जाँच कमांड और required_checks खाली रखता है; केवल कॉपी करने से उपयोगी स्वीकृति-द्वार नहीं बनता।

2. मौजूदा उत्पाद का उद्देश्य और जाँच लिखें

फ़ाइल MISSION.md में उत्पाद का उद्देश्य, सख्त सीमाएँ और दायरे से बाहर के संभावित अनुरोध लिखें। harness/END-TO-END.md में दो से पाँच उपयोगकर्ता प्रक्रियाएँ लिखें जिन्हें मौजूदा ऐप सच में पूरा करता है, साथ में उपयोगकर्ता को दिखने वाला लाभ। अभी न बनी सुविधा पर निर्भर प्रक्रिया पहली डिलीवरी रोक देगी। .factory/holdout/HOLDOUT.md में व्यवहारों के संयोजन या सीमांत स्थितियों के अलग केस लिखें। डायरेक्टरी का नाम उसी चेकआउट तक पहुँच रखने वाले डेवलपर से केस नहीं छिपाता; सचमुच निजी केस बाहर रखें और केवल सत्यापन पक्ष को दें।

केवल PRD वाले रिपॉज़िटरी के लिए README दस्तावेज़ से उद्देश्य, नियोजित उपयोगकर्ता प्रक्रियाएँ और जाँच कमांड निकालने को कहता है। पहला प्रस्तावित कार्य उत्पाद को चलने योग्य बनाए और स्टार्ट कमांड, स्वास्थ्य व बिल्ड पहचान पथ, टेस्ट और CI बताए। कार्य प्रकाशित करने की अनुमति देने से पहले प्रस्ताव जाँचें।

प्रक्रियाओं को Archon रनटाइम वर्कफ़्लो के अपेक्षित परिदृश्य इनपुट में बदलें। इंस्टॉल किए factory/RUNTIME_HOST.md के अनुसार दिए गए कमिट का ऐप स्नैपशॉट, नई स्थिति, स्वास्थ्य और बिल्ड पहचान जाँच, तथा अनुमत Python या Node लॉन्च कमांड तैयार करें। दस्तावेज़ का होस्ट दूरस्थ डेटाबेस, कंटेनर या क्लाउड संसाधनों को अपने प्रबंधित रनटाइम संसाधन नहीं मानता। उन्हें इस्तेमाल करने वाले ऐप के लिए अलग, तर्कसंगत सत्यापन व्यवस्था चाहिए; स्थानीय होस्ट की सफल जाँच उनका अलगाव सिद्ध नहीं करती।

मूल्यांकनकर्ता पर भरोसा करने से पहले वास्तविक उपयोगकर्ता लाभ जाँचने वाली सफल आधाररेखा बनाएँ, दिखाएँ कि प्रासंगिक जानबूझकर डाली गई खराबी असफल होती है, और गलत उम्मीदवार पहचान पर अनिर्णायक निष्कर्ष की पुष्टि करें। होस्ट मार्गदर्शिका में टेस्ट समूह के इनपुट और सटीक अपेक्षित फ़ील्ड हैं, जिनमें expectations_passed: true और baseline_verified: true शामिल हैं। वास्तविक मूल प्रतिक्रिया और उम्मीदवार पहचान सबूत के रूप में रखें। केवल पेज खुलना देखना या टेस्ट की अंतिम स्थिति सीधे तैयार करना अपर्याप्त है।

3. इंस्टॉलेशन जाँचें, फिर एक कार्य चुनें

ऐप की रूट डायरेक्टरी से चलाएँ:

Terminal
python factory/consumer.py doctor
python factory/consumer.py list

doctor निश्चित स्रोत, कमांड क्षमताएँ और उपलब्ध वर्कफ़्लो जाँचता है। list मिले वर्कफ़्लो दिखाता है। इनमें से कोई नहीं सिद्ध करता कि प्रदाता कार्य पूरा करेगा, CI पास होगी या ऐप चलेगा। डिलीवरी से पहले बताई गई त्रुटियाँ दूर करें; शेड्यूल बंद रखें।

मौजूदा कोडबेस के लिए स्पष्ट परिणाम और स्वीकृति जाँच वाला छोटा कार्य लिखें। README वर्गीकरण, डिलीवरी और समीक्षा से पुल रिक्वेस्ट तक पहुँचाने का यह कमांड देता है:

Terminal
python factory/consumer.py run archon-ship --input target=https://github.com/OWNER/REPO/issues/1 --input discovery_publication=preview --detach --json

कार्य URL की जगह अपने नियंत्रण वाला कार्य दें। स्पष्ट discovery_publication=preview समीक्षा के संबंधित निष्कर्षों को कार्य के रूप में प्रकाशित नहीं करता; निश्चित archon-ship का डिफ़ॉल्ट auto है। रनटाइम परिदृश्य और अलग रखे टेस्ट इनपुट तैयार होने के बाद ही archon-lifecycle लें। कार्य को target, संबंधित पथों को scenario और holdout में दें, साथ में merge_mode=approve और discovery_publication=preview। प्रोजेक्ट से स्वीकृत merge_method भी दें: merge, squash या rebase। उदाहरणतः merge_method=squash तभी लें जब रिपॉज़िटरी अनुमति दे। इस प्रक्रिया में रनटाइम और अलग केस की जाँच, सुधार और मर्ज-द्वार हैं। अप्रूवल मोड मर्ज से पहले मनुष्य का निर्णय बनाए रखता है; वर्कफ़्लो का तैयार होने का संकेत वह निर्णय नहीं है। फ़ैक्टरी होस्ट का दस्तावेज़ित --runtime-host केवल अग्रभूमि में चलता है और --detach या --resume के साथ नहीं चल सकता।

PRD के लिए दस्तावेज़ित बैकलॉग कमांड:

Terminal
python factory/consumer.py run archon-backlog --input 'prd=docs/PRD.md' --input publication=approve

उद्धरण चिह्नों वाले docs/PRD.md की जगह ऐप चेकआउट के सापेक्ष PRD का असली पथ दें। प्रकाशन से पहले प्रस्तावित कार्य और क्रम जाँचें। पहले कार्य में घोषित ऐप स्टार्ट और पहचान अनुबंध के अनुसार रनटाइम होस्ट जोड़ें, फिर तैयार प्रक्रियाओं और अलग टेस्ट से उसे archon-lifecycle में चलाएँ। पहला कार्य भी बाद के कार्य जितनी सावधानी से जाँचना चाहिए।

4. स्वीकृति से पहले अंतर और चलते परिणाम का मूल्यांकन करें

मिला रन ID रखें। नियंत्रण प्रोग्राम प्रगति और प्रमाण के लिए get <run-id> --json --events और status --all --json देता है। कार्य और योजना को MISSION.md से मिलाएँ; असली PR अंतर और नवीनतम रिविज़न की स्वतंत्र समीक्षा पढ़ें; आवश्यक CI परिणाम और सुरक्षित पथों की रिपोर्ट जाँचें। दिए गए संस्करण पर उत्पाद प्रक्रियाएँ चलाएँ और उम्मीदवार पहचान सहित मूल रनटाइम व अलग टेस्ट परिणाम देखें। देखा गया उपयोगकर्ता परिणाम स्वीकृति शर्तों से मिलाएँ। अपर्याप्त PR सुधार के लिए लौटाना चाहिए; README मर्ज कतार में रुकी डिलीवरी के लिए archon-deliver --adopt <run id> बताता है।

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

रखरखावकर्ता के लागत निर्देश प्रति रन निश्चित कीमत नहीं देते। वे पहले दिन से टोकन मापने और लूप चालू करने से पहले छोटे कार्य पर मॉडल कॉल देखने की सलाह देते हैं। शुल्क प्रदाता, मॉडल और खाते की शर्तों पर निर्भर हैं। BIG CHANGE ने इस फ़ैक्टरी का खर्च नहीं मापा है।

सक्रिय रन के लिए स्पष्ट रोकने का निर्णय भी चाहिए। नियंत्रण कोड में halt नए लॉन्च और आगे की प्रक्रिया रोकता है, जबकि cancel <run-id> सक्रिय काम को लक्षित करता है। pause टाइमर लॉन्च रोकता है, लेकिन जारी काम को जगाने देता है। कोई कमांड मौजूदा रन स्थिति और दूरस्थ रिपॉज़िटरी बदलाव की जाँच का विकल्प नहीं है।

स्रोत और आगे पढ़ने के लिए