स्थिति
प्रस्ताव, संशोधन 3। कार्यान्वित नहीं। दिशा पर 2026-07 में सहमति हुई; संशोधन 2 में प्रतिकूल समीक्षा के निष्कर्ष शामिल किए गए (समर्पित वर्कर प्रोटोकॉल, प्लेसमेंट/एनवायरनमेंट स्टेट मशीनें, git-जागरूक इनबाउंड सिंक, एकतरफ़ा v1 हैंडऑफ़, नियंत्रित-इग्रेस सुरक्षा शब्दावली)। संशोधन 3 सिंक स्वामित्व मॉडल को अंतिम रूप देता है (वर्कर कमिट बनाता है, Gateway उन्हें अपनाता और प्रकाशित करता है), बिना-git वाला सामान्य सिंक मोड जोड़ता है, वर्कर exec को बॉक्स के भीतर पूर्ण पहुँच पर ठीक करता है, इंटरनेट नीति को प्रोविज़न समय पर ले जाता है, और एजेंट डिस्पैच को माइलस्टोन 3 में पुनर्स्थापित करता है।समस्या
OpenClaw एजेंट सेशन अपना लूप, टूल और इन्फ़रेंस एक मशीन पर Gateway प्रोसेस के भीतर चलाते हैं। कंप्यूट उस मशीन की क्षमता तक सीमित रहता है, लंबे कार्य उसे व्यस्त रखते हैं, और समानांतर कार्य उसके संसाधनों के लिए प्रतिस्पर्धा करते हैं। होस्टेड उत्पाद (Cursor क्लाउड एजेंट, वेब पर Claude Code, Codex क्लाउड) प्रत्येक कार्य के लिए अस्थायी क्लाउड सैंडबॉक्स से इसे हल करते हैं, लेकिन उनके लिए विक्रेता इन्फ़्रास्ट्रक्चर और विक्रेता पर भरोसा आवश्यक होता है। जिन ऑपरेटरों के पास पहले से अतिरिक्त मशीनें हैं (या जो उन्हें कम लागत पर लीज़ कर सकते हैं), उनके पास यह कहने का कोई तरीका नहीं है: इस सेशन को वहाँ चलाएँ, इसे किसी अन्य सेशन की तरह मेरी साइडबार में दिखाएँ, और बाद में मशीन को नष्ट कर दें।लक्ष्य
- एक पूर्ण एजेंट सेशन (लूप + टूल) को एक अस्थायी रिमोट मशीन (“क्लाउड वर्कर”) पर चलाना, जबकि सेशन Control UI में बिल्कुल स्थानीय सेशन की तरह दिखाई दे और स्ट्रीम हो।
- वर्कर पर कोई स्थायी क्रेडेंशियल नहीं (न प्रोवाइडर प्रमाणीकरण, न फ़ोर्ज टोकन) और कोई प्रत्यक्ष नेटवर्क इग्रेस नहीं; बॉक्स को केवल पहुँच-योग्य sshd चाहिए।
- प्रोविज़न, सिंक, रन, संग्रह, नष्ट करना — पूर्णतः स्वचालित, प्रोवाइडर-प्लगेबल (पहला प्रोवाइडर: Crabbox-शैली लीज़ CLI)।
- ट्रांसक्रिप्ट, सेशन पहचान या (जब अनुरोध बाइट समतुल्य रहें) प्रोवाइडर कैश संबद्धता खोए बिना, किसी टर्न सीमा पर Gateway से चल रहे कार्य को वर्कर पर डिस्पैच करना; परिणाम सुरक्षित रूप से वापस खींचना।
- मनुष्य (UI) और एजेंट (टूल), दोनों कार्य को क्लाउड वर्कर पर डिस्पैच कर सकते हैं।
- कई दिनों तक चलने वाले सेशन का समर्थन; जीवनकाल एक नीति है, हार्ड-कोडेड सीमा नहीं।
गैर-लक्ष्य (v1)
- वर्कर पर कोई बाहरी कोडिंग हार्नेस (Claude Code, Codex CLI) नहीं। वर्कर सेशन केवल OpenClaw का एम्बेडेड रनर चलाते हैं। हार्नेस समर्थन v2 में ऑप्ट-इन है, क्योंकि हार्नेस अपने क्रेडेंशियल से स्वयं इन्फ़रेंस करते हैं।
- कोई best-of-N / समानांतर प्रयास फ़ैन-आउट नहीं।
- कोई VPN/टेलनेट निर्भरता नहीं। ट्रांसपोर्ट केवल SSH है।
- कोई नया सैंडबॉक्स रनटाइम नहीं। वर्कर मशीन ही आइसोलेशन सीमा है; बॉक्स के भीतर OS सैंडबॉक्सिंग बाद में परत के रूप में जोड़ी जा सकती है।
- v1 में कोई सममित लाइव माइग्रेशन नहीं: डिस्पैच स्थानीय → वर्कर है; वर्कर → स्थानीय के लिए रुका हुआ सेशन और पूर्ण वर्कस्पेस समन्वयन आवश्यक है। लाइव द्विदिश हैंडऑफ़ बाद में इसी बैरियर तंत्र पर निर्मित होगा।
- Gateway पर कोई JSON साइड-स्टेट नहीं; एनवायरनमेंट, प्लेसमेंट, कर्सर और ग्रांट स्थिति SQLite में रहती है।
पूर्व कला (हम क्या अपनाते हैं, क्या उलटते हैं)
- Cursor क्लाउड एजेंट: एजेंट लूप उनके क्लाउड में चलता है; VM टूल-निष्पादन लक्ष्य है; केवल-जोड़ने योग्य वार्तालाप स्टोर सभी क्लाइंट को स्ट्रीम किया जाता है; इंस्टॉल के बाद स्नैपशॉट से वार्म स्टार्ट; स्वयं-होस्टेड वर्कर केवल आउटबाउंड वर्कर प्रोसेस हैं। हम “वार्तालाप का सत्य-स्रोत ऑर्केस्ट्रेटर पर रहता है” और स्ट्रीमिंग मॉडल अपनाते हैं; हम लूप प्लेसमेंट को उलटते हैं (नीचे निर्णय देखें)।
- Codex क्लाउड: दो-चरणीय रनटाइम — नेटवर्कयुक्त सेटअप चरण, फिर सीक्रेट हटाकर ऑफ़लाइन एजेंट चरण; तेज़ फ़ॉलो-अप के लिए कंटेनर-स्टेट कैश। हम चरण विभाजन को अपनी इग्रेस व्यवस्था के रूप में और कैश विचार को v2 वार्म इमेज के लिए अपनाते हैं।
- वेब पर Claude Code: प्रति-सेशन VM; क्रेडेंशियल-पृथक करने वाला git प्रॉक्सी (वास्तविक टोकन कभी सैंडबॉक्स में प्रवेश नहीं करते, पुश केवल सेशन ब्रांच तक सीमित रहता है); सेटअप के बाद फ़ाइलसिस्टम स्नैपशॉट; टेलीपोर्ट हैंडऑफ़ = पुश की गई ब्रांच + पुनः चलाया गया इतिहास। हम क्रेडेंशियल आइसोलेशन और हैंडऑफ़ संरचना अपनाते हैं, लेकिन आउटबाउंड सिंक Gateway से rsync है, ताकि डर्टी वर्किंग ट्री काम करें और बॉक्स के आसपास कहीं भी कोई फ़ोर्ज टोकन न हो।
- Copilot कोडिंग एजेंट: पैकेज-रजिस्ट्री अनुमतिसूची के साथ डिफ़ॉल्ट-अस्वीकृत इग्रेस। हमारी स्थिर-अवस्था डिफ़ॉल्ट अधिक कठोर है (कोई प्रत्यक्ष इग्रेस नहीं), क्योंकि इन्फ़रेंस और वेब खोज SSH टनल के माध्यम से आते हैं — लेकिन यह “शून्य इग्रेस” के बजाय “नियंत्रित इग्रेस” क्यों है, इसके लिए सुरक्षा अनुभाग देखें।
आर्किटेक्चर निर्णय: लूप वर्कर पर, इन्फ़रेंस Gateway के माध्यम से
तीन प्लेसमेंट पर विचार किया गया:- लूप Gateway पर रहता है, वर्कर टूल निष्पादित करता है (Cursor मॉडल)। सबसे सुरक्षित विफलता डोमेन (ट्रांसक्रिप्ट, इन्फ़रेंस, अनुमोदन और रीस्टार्ट रिकवरी सभी स्थानीय रहते हैं) और समीक्षकों द्वारा पसंदीदा पहला माइलस्टोन। उत्पाद आर्किटेक्चर के रूप में अस्वीकृत: OpenClaw के गैर-exec टूल इन-प्रोसेस फ़ाइलसिस्टम ऑपरेशन हैं, इसलिए हर फ़ाइल पढ़ना/संपादित करना/grep करना या तो नेटवर्क राउंड ट्रिप बन जाता है या मोटे वर्कस्पेस RPC में बड़े टूल-सतह रीफ़ैक्टर की आवश्यकता होती है; रनटाइम व्यवहार बहुत अधिक संवादात्मक और विलंबता-सीमित है। जहाँ इसकी भावना पहले से निर्मित है (Node पर exec ऑफ़लोड), वहाँ हम इसका पुनः उपयोग करते हैं, लेकिन टूल-रिमोटिंग परत नहीं बनाते।
- लूप और इन्फ़रेंस दोनों वर्कर पर। सबसे सरल विफलता डोमेन, लेकिन मॉडल क्रेडेंशियल (OAuth प्रोफ़ाइल सहित) अस्थायी मशीनों पर भेजने होंगे, Gateway नीति/रूटिंग/ऑडिट नियंत्रण खो देता है, और माइग्रेशन प्रोवाइडर को कॉल करने वाली पहचान बदल देता है, जिससे प्रोवाइडर कैश अमान्य हो जाते हैं।
- लूप + टूल वर्कर पर, मॉडल कॉल Gateway के माध्यम से प्रॉक्सी किए जाते हैं। चयनित। प्रति टूल कॉल के बजाय प्रति मॉडल टर्न एक राउंड ट्रिप; टूल कोड के पास चलते हैं; Gateway प्रमाणीकरण प्रोफ़ाइल, प्रोवाइडर रूटिंग और नीति का एकमात्र स्वामी बना रहता है; वर्कर के पास कोई सीक्रेट नहीं होता।
- टर्न के बीच Gateway खोने पर सक्रिय प्रोवाइडर कॉल विफल हो जाती है। टर्न को विफल चिह्नित किया जाता है और पुनः कनेक्ट होने के बाद नए टर्न के रूप में दोबारा प्रयास किया जाता है; चल रही प्रोवाइडर स्ट्रीम का पारदर्शी पुनःप्रयोग नहीं होता (दोहरा-बिलिंग/दोहरा-टूल-कॉल जोखिम)।
- प्रत्येक वर्कर↔Gateway ऑपरेशन टिकाऊ पहचान वहन करता है (वर्कर प्रोटोकॉल देखें), ताकि पुनः कनेक्शन लंबित रहने के बजाय फिर से शुरू हों या कैश किए गए अंतिम परिणाम प्राप्त करें।
- Gateway एक क्षमता-प्रबंधित घटक है: समवर्ती-वर्कर सीमाएँ, प्रवाह नियंत्रण और लोड शेडिंग v1 के दायरे में हैं (क्षमता देखें)।
घटक
1. एनवायरनमेंट स्टेट मशीन + प्रोवाइडर अनुबंध
environments.* Gateway प्रोटोकॉल में वर्तमान में केवल-स्थिति प्रक्षेपण है। टिकाऊ कोर SQLite-स्वामित्व वाला एनवायरनमेंट रिकॉर्ड और स्टेट मशीन है, जिसे RPC संरचनाओं से पहले डिज़ाइन किया गया है:
requested → provisioning → bootstrapping → ready → (attached|idle) → draining → destroying → destroyed | failed | orphaned
- प्रोविज़निंग क्रैश-सुरक्षित है: प्रोवाइडर कॉल से पहले आशय पंक्ति एक निर्धारक ऑपरेशन id के साथ स्थायी की जाती है, ताकि Gateway रीस्टार्ट किसी चल रही लीज़ को दोबारा प्रोविज़न करने या सशुल्क मशीन को अनाथ छोड़ने के बजाय अपना सके।
- रीस्टार्ट समन्वयन और ऑर्फ़न स्वीपर (प्रोवाइडर
inspectबनाम स्थानीय रिकॉर्ड) v1 की आवश्यकताएँ हैं, केवल हार्डनिंग नहीं।
environments.create, environments.destroy, विस्तारित environments.list/status (प्रोवाइडर, लीज़ id, स्थिति, आयु, निष्क्रिय समय, संलग्न सेशन)। पहले प्रोवाइडर: Crabbox-आकार लीज़ CLI रैपर (उत्पाद पथ) और केवल-विकास चिह्नित स्थिर-SSH-होस्ट प्रोवाइडर — साझा होस्ट पर वर्कर असंबंधित होस्ट डेटा पढ़ सकता है, इसलिए स्थिर होस्ट सुविधा विकास के लिए हैं, डिफ़ॉल्ट व्यवस्था के लिए नहीं।
2. वर्कर बूटस्ट्रैप: बॉक्स पर OpenClaw इंस्टॉल करना
कोई विशेष वर्कर आर्टिफ़ैक्ट नहीं, और npm उपलब्धता पर कोई निर्भरता नहीं:- सभी मोड के लिए कैनोनिकल इंस्टॉल: Gateway द्वारा निर्मित, सामग्री-हैशयुक्त वर्कर बंडल (टारबॉल के रूप में पैक किया गया Gateway का अपना बिल्ड आउटपुट), जिसे SSH पर पुश करके बॉक्स पर इंस्टॉल किया जाता है। यह संरचनात्मक रूप से डेवलपमेंट बिल्ड और अप्रकाशित कमिट को समाहित करता है।
npm i -g openclaw@<exact gateway version>तब एक अनुकूलन है जब Gateway कोई जारी किया गया संस्करण चला रहा हो; कभी भीlatestनहीं।- बूटस्ट्रैप आइडेम्पोटेंट है; मेल खाते बंडल हैश वाली वार्म लीज़ इंस्टॉल छोड़ देती है। कच्ची मशीनों को नेटवर्कयुक्त टूलचेन चरण (Node रनटाइम) की आवश्यकता हो सकती है — यह सेटअप चरण का हिस्सा है और बाद में बंद कर दिया जाता है।
- हैंडशेक वर्कर बिल्ड हैश, प्रोटोकॉल सुविधा सेट और रनटाइम संगतता सत्यापित करता है। मौजूदा Gateway संस्करण/प्रोटोकॉल जाँच इसके लिए अपर्याप्त हैं (SSH-टनल वाले Node को सटीक-संस्करण अस्वीकृति से छूट है), इसलिए वर्कर प्रवेश अपनी सटीक-बिल्ड जाँच करता है।
openclaw worker) कोई फ़ोर्क नहीं, बल्कि एक प्रवेश बिंदु है: कनेक्शन प्रबंधन और एम्बेडेड एजेंट रनर, जिसमें सेशन स्थायित्व और मॉडल कॉल Gateway RPC द्वारा समर्थित हैं। इसे Gateway सतहें शुरू नहीं करनी चाहिए: कोई चैनल नहीं, सेशन टूलसेट से परे कोई Plugin ऑटो-स्टार्ट नहीं, अस्थायी स्टेट डायरेक्टरी, कोई स्थानीय प्रमाणीकरण प्रोफ़ाइल नहीं।
3. ट्रांसपोर्ट: सब कुछ SSH पर
कनेक्टिविटी का स्वामी Gateway है; वर्कर को sshd के अतिरिक्त कुछ नहीं चाहिए:- Gateway वर्कर के लिए SSH खोलता है (प्रोवाइडर लीज़ से क्रेडेंशियल, प्रोविज़निंग आउटपुट से पिन की गई होस्ट कुंजी — कोई
StrictHostKeyChecking=noनहीं) और एक रिवर्स टनल स्थापित करता है, जो वर्कर-स्थानीय सॉकेट को Gateway के WS एंडपॉइंट पर फ़ॉरवर्ड करती है। - कंट्रोल/मॉडल ट्रैफ़िक और वर्कस्पेस स्थानांतरण समान पिन की गई ट्रस्ट सामग्री के साथ अलग-अलग SSH कनेक्शन उपयोग करते हैं, ताकि rsync टोकन स्ट्रीम को हेड-ऑफ़-लाइन ब्लॉक न कर सके।
- टनल जीवनचक्र (कीपअलाइव, बैकऑफ़ के साथ पुनः कनेक्शन) Gateway पर एनवायरनमेंट रनटाइम के स्वामित्व में है। टनल में क्षणिक व्यवधान सेशन स्तर पर अदृश्य रहता है: टिकाऊ प्रोटोकॉल स्थिति (नीचे) वर्कर को पुनः संलग्न होकर फिर से शुरू करने देती है।
4. वर्कर प्रोटोकॉल (समर्पित; Node प्रोटोकॉल नहीं)
वर्तमान Node सीमों की प्रतिकूल समीक्षा ने सामान्य पुनः उपयोग को खारिज कर दिया: लंबित Node इनवोक प्रक्रिया-स्थानीय Promise हैं जो कनेक्शन के साथ समाप्त हो जाते हैं, Node आइडेम्पोटेंसी कुंजियाँ पार्स होती हैं लेकिन डीडुप्लिकेट नहीं होतीं, और — निर्णायक रूप से — कनेक्टेड Node सामान्य Node इवेंट (एजेंट-रन अनुरोध सहित) उत्सर्जित कर सकता है, इसलिए “Node प्रकार + क्षमता सीमा” इनग्रेस सुरक्षा सीमा नहीं है। इसलिए वर्कर को बंद, संस्करणित RPC/इवेंट अनुमतिसूची के साथ प्रमाणितworker भूमिका मिलती है; वर्कर कनेक्शन किसी पुराने Node इवेंट हैंडलर तक नहीं पहुँच सकते।
पहचान और क्रेडेंशियल: प्रोविज़निंग एक अल्पकालिक वर्कर क्रेडेंशियल जारी करती है, जो एनवायरनमेंट id, वर्कर कुंजी, बंडल हैश, एकमात्र अनुमत सेशन, अनुमत RPC सेट और समाप्ति से बंधा होता है। SSH-सत्यापित पेयरिंग अभी भी लागू होती है (हमने बॉक्स प्रोविज़न किया और कुंजी हमारे पास है), लेकिन प्राधिकरण जारी किए गए क्रेडेंशियल से आता है, घोषित Node सतह से नहीं।
टिकाऊ ऑपरेशन सिमेंटिक्स (संरचना मौजूदा ACP रनटाइम और उसके इवेंट लेजर से ली गई है — स्थिर हैंडल, प्रति-सेशन क्रमांकन, टिकाऊ (session, seq) पुनःप्रयोग):
- हर संचालन का दायरा
(sessionId, lifecycleRevision, runId, ownerEpoch, streamKind, seq)होता है। - स्वामित्व युग पुराने वर्करों को सीमाबद्ध करते हैं: प्रतिस्थापन वर्कर युग को आगे बढ़ाता है; पुराने युग से देर से आने वाले परिणाम नियतात्मक रूप से अस्वीकार कर दिए जाते हैं।
- SQLite में स्थायी ACK कर्सर और कैश किए गए अंतिम परिणामों के साथ कम-से-कम-एक-बार डिलीवरी; डीडुप्लीकेशन नियतात्मक है। ठीक-एक-बार की कोई गारंटी नहीं।
- रद्द करने, बंद करने, फिर से शुरू करने और अंतिम परिणामों के लिए स्पष्ट फ़्रेम; स्ट्रीम पर क्रेडिट/विंडो-आधारित प्रवाह नियंत्रण।
- प्रोटोकॉल सुविधा नेगोशिएशन सामान्य Node प्रोटोकॉल संस्करण से स्वतंत्र है।
5. सेशन बैकएंड RPC
दो अलग-अलग अनुबंध — वर्तमान कोडबेस टिकाऊ ट्रांसक्रिप्ट परिवर्तनों (सेशन-मैनेजर के स्वामित्व वाला, पैरेंट/लीफ़ स्थिति सहित JSONL ट्री) को प्रक्रिया-स्थानीय लाइव इवेंट (स्ट्रीमिंग डेल्टा, टूल जीवनचक्र, अनुमोदन) से अलग रखता है, और वर्कर प्रोटोकॉल को यह विभाजन बनाए रखना चाहिए:- टिकाऊ ट्रांसक्रिप्ट कमिट: वर्कर
runEpoch+ बेस-लीफ़ तुलना-और-स्वैप के साथ अर्थपूर्ण ऐपेंड बैच सबमिट करता है; Gateway सेशन मैनेजर एंट्री आईडी और पैरेंट आईडी जनरेट करता है। वर्कर कभी भी विश्वसनीय ट्रांसक्रिप्ट पंक्तियाँ, एंट्री आईडी, पैरेंट आईडी या बाहरी सेशन आईडी नहीं दे सकता। - रीप्ले किए जा सकने वाले लाइव इवेंट: वर्कर अनुक्रम संख्याओं, Gateway ACK, सीमित प्रतिधारण और देर से आने वाले इवेंट की सीमाबंदी वाला एक टाइप्ड इवेंट यूनियन, जो मौजूदा एजेंट-इवेंट फ़ैनआउट को फ़ीड करता है ताकि चैट दृश्य, टूल पंक्तियाँ और अपठित/स्थिति लॉजिक स्थानीय सेशन के समान व्यवहार करें।
src/agents/runtime/proxy.ts) की इवेंट शब्दावली का पुनः उपयोग करें, लेकिन विश्वास सीमा को स्थानांतरित करें। वर्कर केवल सेशन/रन पहचान, एक अनुमोदित मॉडल संदर्भ, संदर्भ और सीमित जनरेशन विकल्प भेजता है; Gateway अपने कैटलॉग से प्रोवाइडर, एंडपॉइंट, प्रमाणीकरण, हेडर, रूटिंग और लागत नीति का समाधान करता है। वर्कर द्वारा दिया गया मॉडल ऑब्जेक्ट (जैसे हमलावर-नियंत्रित baseUrl) अस्वीकार कर दिया जाता है। अनुरोध-आकार सीमाएँ, रद्दीकरण, ऑडिट और अंतिम-परिणाम रीप्ले लागू होते हैं। Gateway-स्थित टूल (websearch) Gateway पर निष्पादित होते हैं और उसी चैनल पर परिणाम लौटाते हैं।
6. वर्कस्पेस सिंक
सिंक एंकर अनन्य प्लेसमेंट स्वामित्व वाला Gateway-स्थानीय वर्कस्पेस है: git वर्कस्पेस के लिए, एक समर्पित प्रबंधित वर्कट्री (मौजूदा प्रबंधित-वर्कट्री मेटाडेटा — ब्रांच, बेस, स्नैपशॉट स्वामित्व — आधार है); गैर-git वर्कस्पेस के लिए, Gateway-स्वामित्व वाली लक्ष्य डायरेक्टरी। उपयोगकर्ता का लाइव चेकआउट कभी नहीं। सेशन के दूरस्थ रूप से प्लेस रहने के दौरान अनन्य स्वामित्व ही इनबाउंड सिंक को संरचनात्मक रूप से संघर्ष-मुक्त बनाता है। स्वामित्व विभाजन — कमिट बनाम प्रकाशन:- वर्कर-साइड एजेंट अपनी कॉपी में सामान्य रूप से कमिट लिखता है (
git commitएक स्थानीय, क्रेडेंशियल-मुक्त संचालन है; लेखक पहचान Gateway कॉन्फ़िगरेशन से प्रक्षेपित होती है)। जब तक Gateway उन्हें अपनाता नहीं, वे कमिट निष्क्रिय ऑब्जेक्ट रहते हैं। - Gateway विश्वास की आवश्यकता वाला हर कार्य करता है: यह सत्यापित करना कि इनबाउंड कमिट रिकॉर्ड किए गए बेस पर बने हैं, स्थानीय वर्कट्री को फ़ास्ट-फ़ॉरवर्ड करना, पुश, PR निर्माण और वैकल्पिक साइनिंग/पुनः-साइनिंग — सभी Gateway-स्थानीय क्रेडेंशियल के साथ। वर्कर के पास कभी भी git या फ़ोर्ज क्रेडेंशियल नहीं होते और वह कभी किसी रिमोट को नहीं छूता।
- Git मोड। आउटबाउंड: टनल की SSH पहचान के माध्यम से वर्कट्री को rsync करें (अकमिटेड और पात्र अनट्रैक्ड फ़ाइलें शामिल; crabbox-शैली include/exclude,
.worktreeincludeका पालन किया जाता है), जिसे अपरिवर्तनीय बेस मैनिफ़ेस्ट (कंटेंट हैश + बेस कमिट) के रूप में रिकॉर्ड किया जाता है। इनबाउंड: नए कमिट रिकॉर्ड किए गए बेस के विरुद्ध git बंडल या अस्थायी रेफ़ के रूप में लौटते हैं; अनट्रैक्ड आर्टिफ़ैक्ट आकार/प्रकार/सिमलिंक-कंटेनमेंट जाँच वाले स्पष्ट मैनिफ़ेस्ट के माध्यम से लौटते हैं। अपनाने की प्रक्रिया बेस वंशावली सत्यापित करती है और विचलन पर रुक जाती है — कोई भी चीज़ चुपचाप किसी भी पक्ष को ओवरराइट नहीं करती। हटाना, नाम बदलना, सबमॉड्यूल और सिमलिंक एस्केप rsync अनुमान के बजाय मैनिफ़ेस्ट नियमों द्वारा संभाले जाते हैं। - प्लेन मोड (कोई git नहीं — जैसे बॉक्स पर शुरुआत से कोई प्रोजेक्ट बनाना)। आउटबाउंड वही rsync + बेस मैनिफ़ेस्ट है। इनबाउंड, हटाने के प्रसार के साथ Gateway-स्वामित्व वाली लक्ष्य डायरेक्टरी में मैनिफ़ेस्ट-अंतरित मिरर है। यह git मोड वाले उसी कारण से सुरक्षित है: अनन्य स्वामित्व का अर्थ है कि संघर्ष के लिए कोई समवर्ती स्थानीय संपादन मौजूद नहीं है; बेस मैनिफ़ेस्ट फिर भी अप्रत्याशित स्थानीय विचलन का पता लगाता है और ओवरराइट करने के बजाय रुक जाता है।
7. प्लेसमेंट स्टेट मशीन, सेशन और UI
रनटाइम प्लेसमेंट, सेशन से संबद्ध SQLite-स्वामित्व वाली स्टेट मशीन है, न कि दो असंबद्ध पंक्ति फ़ील्ड:local → requested → provisioning → syncing → starting → active(worker) → draining → reconciling → local | reclaimed | failed
यह एनवायरनमेंट आईडी, ट्रांज़िशन जनरेशन, सक्रिय स्वामी युग, वर्कस्पेस बेस मैनिफ़ेस्ट, वर्कर बंडल हैश और अंतिम ACK कर्सर को स्थायी रूप से संग्रहीत करता है। दोनों में से किसी लूप द्वारा टर्न शुरू करने से पहले टर्न प्रवेश परमाण्विक रूप से प्लेसमेंट का दावा करता है, इसलिए पुराने स्नैपशॉट के विरुद्ध स्वीकार किया गया स्थानीय संदेश कभी वर्कर टर्न के साथ रेस नहीं कर सकता — किसी भी समय ठीक एक लूप सेशन का स्वामी होता है।
UI:
- वर्कर सेशन एक सामान्य सेशन पंक्ति और प्लेसमेंट मेटाडेटा है। यह सामान्य स्टोर में रहता है,
sessions.listके माध्यम से सूचीबद्ध होता है, मौजूदा सब्सक्रिप्शन के माध्यम से स्ट्रीम होता है — साइडबार और चैट को किसी नए डेटा पथ की आवश्यकता नहीं, केवल प्रस्तुति की: एक वर्कर बैज और प्लेसमेंट/एनवायरनमेंट स्थिति (provisioning / syncing / running / idle / reconciling / reclaimed)। - निर्माण UX: सेशन लक्ष्य बार (सेशन साइडबार का नया डिज़ाइन) में Gateway और Node के साथ क्लाउड वर्कर गंतव्य जोड़ा जाता है। कॉन्फ़िगर की गई प्रोवाइडर प्रोफ़ाइल आवश्यक है; कॉन्फ़िगर होने तक सुविधा अदृश्य रहती है।
- एजेंट डिस्पैच: एक सेशन टूल एजेंट को उसी तरह कार्य क्लाउड वर्कर को सौंपने देता है जैसे कोई व्यक्ति करता है (वर्कर-समर्थित उप-सेशन, सबएजेंट-शैली)। यह मानव डिस्पैच वाले समान माइलस्टोन में शिप होता है और उसी ऑप्ट-इन प्रोवाइडर कॉन्फ़िगरेशन द्वारा नियंत्रित होता है। पुनरावर्तन संरचनात्मक रूप से सीमित है (v1 में वर्कर सेशन स्वयं वर्कर डिस्पैच नहीं कर सकते); व्यय नियंत्रण प्रति-एनवायरनमेंट लेखांकन/ऑडिट है, कोटा तंत्र नहीं।
डिस्पैच और हैंडऑफ़
v1 जानबूझकर असममित है:- स्थानीय → वर्कर (डिस्पैच): नीचे दी गई माइग्रेशन बाधा पार करें, वर्कर प्रोविज़न करें या पुनः उपयोग करें, सिंक करें, प्लेसमेंट बदलें, अगला टर्न दूरस्थ रूप से निष्पादित होता है।
- वर्कर → स्थानीय (वापस खींचना): सेशन रोकें (उसी बाधा के अनुसार वर्कर को ड्रेन करें), इनबाउंड मिलान पूरा करें, प्लेसमेंट को स्थानीय पर बदलें। यह लाइव माइग्रेशन नहीं है।
- सममित लाइव हैंडऑफ़ (सक्रिय रूप से कार्यरत सेशन को बिना रोके दोनों दिशाओं में ले जाना) उसी बाधा और मिलान तंत्र का पुनः उपयोग करता है और फ़ॉल्ट-इंजेक्शन परीक्षणों द्वारा बाधा सिद्ध होने के बाद शिप होता है।
- नए टर्न का प्रवेश रोकें (प्लेसमेंट दावा)।
- सक्रिय रन रद्द करें या ड्रेन करें।
- लंबित निष्पादन अनुमोदन और निष्पादन अनुदान निरस्त करें।
- ट्रांसक्रिप्ट साइड-राइट और लाइव-इवेंट ACK ड्रेन करें।
- वर्कर चाइल्ड प्रक्रियाएँ समाप्त करें।
- स्वामी युग को आगे बढ़ाकर पुराने स्वामी को सीमाबद्ध करें।
- वर्कस्पेस का मिलान करें (इनबाउंड, संघर्ष-सचेत)।
- नए स्वामी को सक्रिय करें।
सुरक्षा मॉडल
सटीक रूप से कहा जाए तो: वर्कर के पास प्रत्यक्ष नेटवर्क एग्रेस और स्थायी प्रोवाइडर/फ़ोर्ज क्रेडेंशियल नहीं हैं। यह “शून्य एग्रेस” नहीं है — इन्फ़रेंस और Gateway-निष्पादित टूल नियंत्रित एग्रेस चैनल हैं (प्रॉम्प्ट-इंजेक्टेड वर्कर फिर भी वर्कस्पेस बाइट को मॉडल संदर्भ या websearch क्वेरी में डाल सकता है)। तदनुसार:- नियंत्रित-एग्रेस लेखांकन: इन्फ़रेंस प्रॉक्सी और Gateway टूल पर प्रति-एनवायरनमेंट ऑडिट और ऑपरेटर-दृश्य लेखांकन। दर/बाइट सीमाएँ प्रोटोकॉल प्रवाह नियंत्रण (क्षमता) के रूप में मौजूद हैं, व्यय-कोटा तंत्र के रूप में नहीं।
- Gateway में वर्कर प्रवेश बंद वर्कर-प्रोटोकॉल अनुमति-सूची है; ट्रांसक्रिप्ट लेखन संरचनात्मक रूप से सीमित हैं (Gateway-जनरेटेड आईडी, एकल संबद्ध सेशन)।
- वर्कर निष्पादन बॉक्स के भीतर पूर्ण-अनुमति वाला है। बॉक्स डिस्पोज़ेबल और क्रेडेंशियल-मुक्त है, इसलिए प्रति-कमांड अनुमोदन बिना किसी सुरक्षा के घर्षण जोड़ता है; संरक्षित सीमा इनबाउंड मिलान और ऑडिट है। निष्पादन कभी Gateway Node-अनुमोदन पथ से नहीं गुजरता।
- इंटरनेट नीति प्रोविज़न-समय का प्रोवाइडर निर्णय है: एनवायरनमेंट प्रोफ़ाइल बॉक्स निर्माण के समय निर्णय लेती है (फ़ायरवॉल/सुरक्षा समूह/नो-एग्रेस नेटवर्क), वैकल्पिक रूप से एक नेटवर्कयुक्त सेटअप चरण के साथ जिसे प्रोवाइडर एजेंट चरण से पहले बंद कर देता है। कोर रनटाइम नेटवर्क टॉगल लागू नहीं करता।
- प्रोविज़न समय पर बॉक्स स्वच्छता: क्लाउड मेटाडेटा एंडपॉइंट अवरुद्ध या अनुपस्थित होना सत्यापित, कोई इंस्टेंस प्रोफ़ाइल नहीं, कोई विरासत में मिला SSH एजेंट नहीं, कोई Docker सॉकेट नहीं, स्वच्छ env/home। SSH होस्ट कुंजियाँ प्रोविज़निंग आउटपुट से पिन की जाती हैं।
- Gateway-साइड किसी भी चीज़ (पुश, PR, प्रोवाइडर कॉल) के अनुमोदन और नीति Gateway पर चलना जारी रखते हैं।
क्षमता
Gateway N वर्करों के प्रत्येक प्रॉम्प्ट और टोकन स्ट्रीम को रिले करता है, इसलिए v1 इसे उत्पादन में खोजने के बजाय क्षमता मॉडल बताता है: प्रति Gateway समवर्ती-वर्कर सीमाएँ, प्रति-स्ट्रीम क्रेडिट विंडो (वर्तमान इवेंट स्ट्रीम कतार असीमित है और Node सॉकेट बफ़र सीमा धीमे उपभोक्ताओं को बलपूर्वक बंद करती है — दोनों बिना संशोधन के अनुपयुक्त हैं), बर्स्ट के लिए सीमित डिस्क स्पूलिंग और UI में दृश्यमान बैकप्रेशर स्थितियों के साथ लोड शेडिंग। वर्कस्पेस स्थानांतरण अपने अलग SSH चैनल पर रहता है।जीवनचक्र
- निष्क्रिय ऑटो-स्टॉप और TTL प्रोवाइडर-प्रोफ़ाइल नीति हैं, निश्चित स्थिरांक नहीं। स्पष्ट कीप-अलाइव के साथ डिफ़ॉल्ट उदार हैं; कई दिनों का कार्य प्रथम-श्रेणी है (लीज़-आधारित बैकएंड के लिए प्रोवाइडर
renewमौजूद है); चालू टर्न या हाल की गतिविधि वाला सेशन कभी पुनः प्राप्त नहीं किया जाता। - वर्कर की मृत्यु या पुनः प्राप्ति पर: प्लेसमेंट
reclaimedमें चला जाता है, सेशन पंक्ति बनी रहती है, अगला संदेश नया वर्कर प्रोविज़न करता है और अंतिम चेकपॉइंट से पुनः सिंक करता है। वार्तालाप कभी नहीं खोता (Gateway-साइड स्टोर); अंतिम चेकपॉइंट के बाद के वर्कस्पेस परिवर्तन खो जाते हैं और UI ऐसा स्पष्ट रूप से बताता है। - पहले दिन से वार्म-लीज़ पुनः उपयोग (इसका समर्थन करने वाले प्रोवाइडर); बूटस्ट्रैप के बाद इमेज स्नैपशॉट v2 का तेज़-प्रारंभ पथ है।
कॉन्फ़िगरेशन सतह
न्यूनतम और ऑप्ट-इन: एक प्रोवाइडर प्रोफ़ाइल ब्लॉक (प्रोवाइडर आईडी, क्रेडेंशियल/CLI संदर्भ, सिंक नियम, जीवनकाल नीति, बजट, वैकल्पिक सेटअप चरण) और प्रति-सेशन प्लेसमेंट चयन। कोई नया एनवायरनमेंट वेरिएबल नहीं। बिना कॉन्फ़िगरेशन वाले इंस्टॉल में कुछ नहीं दिखाई देता।माइलस्टोन
कार्यान्वयन छोटे, स्वतंत्र रूप से मर्ज किए जा सकने वाले PR के रूप में आता है; नीचे दिया गया प्रत्येक माइलस्टोन एक PR शृंखला है, एक परिवर्तन नहीं।- आधार: परिवेश स्थिति मशीन + प्रदाता अनुबंध + crabbox-आकार प्रदाता (विकास हार्नेस के रूप में static-SSH), वर्कर बंडल बूटस्ट्रैप + प्रवेश हैंडशेक, SSH टनल + होस्ट-कुंजी पिनिंग, प्रबंधित-वर्कट्री स्नैपशॉट + आउटबाउंड सिंक (git + प्लेन मोड)। अनाथ संसाधन सफ़ाई + पुनः आरंभ पर अंगीकरण।
- वर्कर प्रोटोकॉल + वर्कर लूप: प्रमाणित वर्कर भूमिका, टिकाऊ ऑपरेशन/युग/ACK कर्सर, ट्रांसक्रिप्ट कमिट + लाइव इवेंट अनुबंध, Gateway द्वारा रिज़ॉल्व किए गए मॉडलों वाला इन्फ़रेंस प्रॉक्सी, प्रवाह नियंत्रण। एक प्रदाता, केवल नए सत्रों का मानव प्रेषण, कोई हैंडऑफ़ नहीं। दोष-अंतःक्षेपण परीक्षण (टनल विभाजन, Gateway पुनः आरंभ, वर्कर की समाप्ति) निकास को गेट करते हैं।
- प्रेषण + वापस खींचना + एजेंट प्रेषण: माइग्रेशन अवरोध, UI लक्ष्य बार से जुड़ी प्लेसमेंट स्थिति मशीन, इनबाउंड पुनर्समाधान + चेकपॉइंट, प्रति-परिवेश ऑडिट, क्षमता सीमाएँ, एजेंट प्रेषण टूल (वर्कर सत्र पुनरावर्ती प्रेषण नहीं कर सकते)। प्रॉम्प्ट-कैश बाइट-समतुल्यता परीक्षण।
- माइलस्टोन-3 दोष-अंतःक्षेपण प्रमाण के बाद सममित लाइव हैंडऑफ़।
खुले प्रश्न
- वर्करों पर Plugin/स्किल की उपलब्धता: रिपॉज़िटरी में मौजूद स्किल बिना अतिरिक्त लागत के वर्कस्पेस के साथ सिंक होते हैं; Gateway द्वारा कॉन्फ़िगर किए गए एजेंट स्किल/Plugin के लिए स्पष्ट सिंक या बहिष्करण निर्णय आवश्यक है (किसी भी स्थिति में टूल/Plugin मैनिफ़ेस्ट प्रवेश हैंडशेक का हिस्सा है)।
- चेकपॉइंट आवृत्ति का डिफ़ॉल्ट: अत्यधिक संवाद वाले सत्रों के लिए टर्न-आधारित बनाम समय-आधारित।
- परिवेश प्रोफ़ाइल मल्टी-एजेंट रूटिंग के साथ कैसे अंतःक्रिया करती हैं (प्रति-एजेंट डिफ़ॉल्ट प्रोफ़ाइल बनाम केवल प्रति-सत्र चयन)।