रिमोट एक्ज़ीक्यूटर

किसी एजेंट को असली कंप्यूटर दें जिस पर वह काम कर सके: Linux, macOS या Windows पर।

रिमोट एक्ज़ीक्यूटर क्या है

Nessie में एजेंट के पास कोई कंप्यूटर नहीं होता। वह Nessie में मौजूद जानकारी पढ़ सकता है, लोगों से बात कर सकता है और नेटवर्क के ज़रिए जुड़े टूल चला सकता है — लेकिन वह लैपटॉप पर कोई फ़ाइल नहीं खोल सकता, कोई कमांड नहीं चला सकता, या ऐसे पेज को नहीं देख सकता जो किसी के लॉगिन के पीछे ही मौजूद हो। रिमोट एक्ज़ीक्यूटर वह तरीका है, जिससे आप किसी एजेंट को काम करने के लिए एक मशीन दे सकते हैं।

एक्ज़ीक्यूटर एक छोटा daemon है, जिसे आप अपने नियंत्रण वाले कंप्यूटर पर इंस्टॉल करते हैं। यह आपके Nessie इंस्टेंस से बाहर की ओर पेयर होता है, एक ऐसी key से साबित करता है कि यह कौन-सी मशीन है, जो होस्ट से कभी बाहर नहीं जाती, और फिर केवल operations का एक तय, नामित सेट देता है — और कुछ नहीं। काम अलग-अलग signed commands के रूप में आता है; नतीजे सीमित, संरचित receipts के रूप में वापस जाते हैं। मशीन Nessie से आने वाले किसी भी inbound कनेक्शन को कभी स्वीकार नहीं करती।

यह समझना ज़रूरी है कि एक्ज़ीक्यूटर क्या नहीं है, क्योंकि ज़्यादातर रिमोट-एक्सेस टूल इन्हीं में से कोई एक होते हैं, और एक्ज़ीक्यूटर जानबूझकर इनमें से कोई भी नहीं है। इसमें SSH नहीं है, कोई खुला रिमोट shell नहीं है, आपके पहले से खुले किसी terminal multiplexer से जुड़ने की सुविधा नहीं है, क्लाउड की ओर से standard input नहीं है और कोई सामान्य लोकल-नेटवर्क प्रॉक्सी नहीं है। यह MCP सर्वर नहीं है, और न ही कोई कंटेनर या क्लाउड execution environment है — वह सब Nessie में पहले से मौजूद है और वह अलग चीज़ है। एक्ज़ीक्यूटर एक ऐसा एंडपॉइंट है जिसके पास सीमित क्षमताएँ हैं, जिसकी operations की सूची बंद है, और वही सूची इसकी पूरी सतह है।

एक्ज़ीक्यूटर किसका होता है

हर एक्ज़ीक्यूटर एक ही स्कोप के साथ बनाया जाता है, और उसे बाद में बदला नहीं जा सकता। यही तय करता है कि एक्ज़ीक्यूटर को कौन चला सकता है और उसका प्रबंधन कौन कर सकता है।

निजी एक्ज़ीक्यूटर के पास हमेशा कम से कम एक सक्रिय मानव एडमिनिस्ट्रेटर होना चाहिए। आखिरी एडमिनिस्ट्रेटर को सीधे हटाने की कोशिश विफल हो जाती है; अगर offboarding की किसी प्रक्रिया के बाद कोई एडमिनिस्ट्रेटर नहीं बचता, तो एक्ज़ीक्यूटर नया काम लेना बंद कर देता है, अपना बचा हुआ काम पूरा करता है और खुद को revoke कर देता है। संगठन के owner के पास एक break-glass रास्ता है, जो केवल revoke करता है: इससे वह ऐसे एक्ज़ीक्यूटर को बंद कर सकता है जिसका वह सामान्य तौर पर प्रबंधन नहीं करता, और इसके लिए उसे उसकी निजी सूची, सेशन या सामग्री नहीं दिखाई जाती — निजी पहुँच कभी चुपचाप किसी और को नहीं सौंपी जाती।

एजेंट इससे असल में क्या कर सकता है

operations की शब्दावली कोड में तय है, हर डिप्लॉयमेंट में अलग से कॉन्फ़िगर नहीं होती। यह दो हिस्सों में बँटी है, और यही बँटवारा तय करता है कि आपको क्या इंस्टॉल करना है: कुछ operations daemon अपनी scratch directory से देता है, बिना किसी virtual machine के; बाकी को होस्ट पर हर सेशन के लिए एक guest VM चाहिए।

जिन operations को guest की ज़रूरत नहीं होती, वे workspace bundle हैं। जो होस्ट guest शुरू नहीं कर सकता, वह खराब एक्ज़ीक्यूटर नहीं है: वह सामान्य रूप से पेयर होता है, अपना sandbox backend none बताता है, और केवल workspace bundle का विज्ञापन करता है। यही वह स्थिति है जिसमें वह Windows संस्करण पहुँचता है जिसमें Hyper-V नहीं है, या वह Linux मशीन जिसके उपयोगकर्ता /dev/kvm का उपयोग नहीं कर सकते; इंटरफ़ेस इसे साफ़ नाम देता है, बिना किसी अस्पष्ट विफलता के।

ब्राउज़र का काम कोई एजेंट अपनी पहल पर कभी शुरू नहीं करता। सामान्य एकल-operation binding रास्ता browser.open और browser.observe को सीधे मना कर देता है; browser run एक व्यक्ति चैनल से शुरू करता है, एक नए run पर चार operations के एक bundle के रूप में, और उसके बाद उसमें कोई और binding नहीं जोड़ा जा सकता। Managed coding sessions भी इसी तरह काम करते हैं।

कोड में दो और समूह मौजूद हैं, जो जानबूझकर उपलब्ध नहीं हैं। उस Chrome tab को चलाने के operations, जिसमें आप पहले से साइन इन हैं, का पूरा स्थानीय implementation और एक native-messaging extension है, लेकिन control plane इनका विज्ञापन तब तक नहीं करता जब तक सर्वर यह साबित न कर सके कि शुरुआती बातचीत निजी थी और यह दर्ज हो कि किसने क्या बताया — यह आधार जानबूझकर निष्क्रिय है, और यह extension दोनों installers में से किसी में भी शामिल नहीं है। और कई coding operations — attach, prompt, interrupt और close — schema में नामित हैं, लेकिन उनका कोई implementation नहीं है, इसलिए उन्हें दिया नहीं जा सकता।

यह कैसे काम करता है

कनेक्शन हमेशा बाहर की ओर होता है

daemon आपके Nessie API से केवल बाहर की ओर HTTPS और WSS कनेक्शन बनाता है, और किसी से नहीं। Nessie कभी किसी लैपटॉप को dial नहीं करता, उसका कोई पता नहीं रखता, और किसी catalogue endpoint को मशीन transport नहीं मानता। इसी वजह से एक्ज़ीक्यूटर घर के नेटवर्क से, NAT के पीछे, कॉर्पोरेट VPN पर, बिना port forward और बिना inbound firewall नियम के काम करता है — और इसी वजह से daemon रोकना पूरी और तुरंत disconnection है।

API ओरिजिन HTTPS होना चाहिए। इसका एकमात्र अपवाद loopback address है, उन लोगों के लिए जो Nessie अपनी मशीन पर चलाते हैं, और यह अपने अलग environment variable के पीछे है; कोई सामान्य flag production origin को सादे HTTP में नहीं बदलता।

पेयरिंग मशीन को साबित करती है, और एक व्यक्ति उसकी पुष्टि करता है

पेयरिंग दोतरफ़ा प्रमाण है। अधिकार वाला व्यक्ति अपने स्कोप के साथ Nessie में एक्ज़ीक्यूटर बनाता है, और Nessie एक enrolment जारी करता है: 256-बिट का random challenge, जिसका वह केवल SHA-256 verifier रखता है; यह दस मिनट तक वैध रहता है और एक बार ही इस्तेमाल हो सकता है।

मशीन पर daemon एक Ed25519 key pair बनाता है, उसे केवल मालिक के लिए, OS-सुरक्षित स्टोरेज में रखता है, और कोई भी network call करने से पहले ठीक वही signed request disk पर लिख देता है — ताकि खोया हुआ response उसी तैयार key से दोबारा भेजा जा सके, चुपचाप दो बार पेयर होने के बजाय। फिर वह enrolment id, challenge, अपनी public key और एक proof signature भेजता है। Nessie public key और उसका fingerprint रखता है। वह private key कभी नहीं रखता।

इसके बाद Nessie वह fingerprint एक व्यक्ति को दिखाता है, जो उसकी पुष्टि करता है। उस पुष्टि और उसके बाद के possession proof तक एक्ज़ीक्यूटर offline रहता है। पेयरिंग कभी चैट के text या terminal transcript से पूरी नहीं हो सकती: इसके लिए वेब या desktop इंटरफ़ेस में एक जानबूझकर किया गया मानवीय कदम ज़रूरी है।

जो मशीन अपनी key खो देती है, वह अपना एक्ज़ीक्यूटर record वापस नहीं ले सकती। उसे revoke करके नए एक्ज़ीक्यूटर के रूप में फिर से enroll किया जाता है। इसके उलट, key rotation एक ही transaction है, जिस पर पुरानी और नई दोनों keys से signature होता है।

descriptor मशीन का अपने बारे में signed दावा है

पेयर किया गया daemon एक descriptor प्रकाशित करता है: केवल संरचनात्मक तथ्यों का एक signed, हमेशा आगे बढ़ते revision वाला कथन — वह कौन-से operation schemas सपोर्ट करता है, उसकी resource और network सीमाएँ, उसका platform, और उसकी local policy का digest। इसमें होस्ट के path नहीं होते और क्लाउड में कोई अधिकार नहीं बनता।

नया revision आते ही कभी सक्रिय नहीं होता। वह review के लिए लंबित रखा जाता है, और अधिकार वाले व्यक्ति को उसे देखकर पुष्टि करनी होती है, उसके बाद ही वह उपलब्ध चीज़ों को प्रभावित कर सकता है। इसी से रोका जाता है कि capability refresh चुपचाप नई शक्ति न दे दे: नया विज्ञापित operation पहले से denied शुरू होता है।

स्पष्ट रहें कि signature क्या साबित करता है। किसी पेयर किए गए एक्ज़ीक्यूटर key से signed descriptor यह साबित करता है कि उस key ने यह दावा किया। यह यह साबित नहीं करता कि होस्ट सुरक्षित है, और इंटरफ़ेस को यह बात कहना ज़रूरी है।

Dispatch: उम्मीदवार, binding, command, receipt

एजेंट कभी एक्ज़ीक्यूटर का नाम नहीं लेता। किसी run के उसका उपयोग करने से पहले, Nessie तार्किक operation को एक अपारदर्शी, अल्पकालिक availability candidate में बदलता है। प्रतिक्रिया में कोई एक्ज़ीक्यूटर id नहीं होती; डेटाबेस केवल handle का digest रखता है, साथ में यह कि वह किसके और किस काम के लिए हल हुआ था। मॉडल और क्लाइंट को एक handle मिलता है, चुनने योग्य मशीन नहीं।

उपलब्धता के लिए एक ही resolver है, जिसे API, वर्कर, UI और असिस्टेंट सब एक जैसे इस्तेमाल करते हैं:

available(operation, human, agent, immutableRunContext) =
  human may discover executor
  ∩ exact executor-agent-operation grant allows operation
  ∩ stable logical tool grant allows operation
  ∩ scope matches immutable run context
  ∩ executor is online and descriptor is approved
  ∩ local policy permits operation

candidate का उपयोग एक database lock के अंतर्गत एक binding बनाता है, जो उन सभी gates की दोबारा जाँच करता है और एक monotonic fence को आगे बढ़ाता है। Dispatch उन्हें फिर से जाँचता है। नतीजा यह है कि दो चरणों के बीच हटाया गया अधिकार, सीमित की गई policy या revoke किया गया एक्ज़ीक्यूटर काम को बाद में पता चलने के बजाय तुरंत रोक देता है — और retry कभी उस मशीन से अलग मशीन पर नहीं पहुँच सकती, जिससे run बाउंड था।

कमांड खुद Nessie के सामान्य queue job और tool-call lifecycle पर चलता है, अपना दूसरा lifecycle बनाने के बजाय। daemon अपने प्रमाणित control channel पर काम के लिए poll करता है; उसे कभी push नहीं किया जाता। एक कमांड केवल चार receipts से होकर गुज़रता है, और इनके अलावा कोई नहीं:

leased → accepted → started → result-acknowledged

हर frame command id, run की provenance, binding fence, capability revision, expiry, idempotency key और arguments व payload दोनों के digests को बाँधता है। daemon किसी असंगति, पुरानी policy, replay, या ऐसे कमांड के दूसरे नतीजे को ठुकराता है जो वह पहले ही पूरा कर चुका है। Arguments और अंतिम नतीजे स्टोरेज में रखे समय AES-256-GCM से encrypted होते हैं; डेटाबेस में सीमित ciphertext और canonical digests रहते हैं, सामग्री नहीं।

अगर acknowledgement खो जाए, तो Nessie सफलता नहीं मान लेता। कमांड को अज्ञात नतीजे के रूप में दर्ज किया जाता है और run सामान्य recovery रास्ता अपनाता है; daemon, जो काम शुरू करने से पहले हर delivered command को स्थानीय रूप से journal में लिखता है, उसके side effect को दोबारा नहीं दोहराएगा। देर से आई receipt अब भी इस अस्पष्टता को ईमानदारी से हल कर सकती है।

भरोसे की सीमा

एक्ज़ीक्यूटर इंस्टॉल करना और पेयर करना

Mac CLI को Homebrew से, Mac apps को Homebrew casks से, Linux CLI को APT या DNF से, या Windows एक्ज़ीक्यूटर को WinGet से इंस्टॉल करें। हर पेयर की गई टीम की अलग permissions होती हैं, जो कंप्यूटर पर सहेजी जाती हैं। Nessie टीम के भीतर पहुँच नियंत्रित करता है; वह स्थानीय संसाधन नहीं बदल सकता।

इंस्टॉलेशन और पेयरिंग गाइड में सटीक कमांड, दोतरफ़ा आठ-अंकों के code का flow, स्थानीय settings, startup, updates और removal की जानकारी है।

हर platform कितना सत्यापित हुआ है

तीनों guest sandboxes की स्थिति अलग है, और यह फ़र्क मायने रखता है। macOS वह backend है जिसका काम करने वाला, परखा गया guest रास्ता है। Linux पर Firecracker backend और Windows पर Hyper-V backend लागू हैं और होस्ट-साइड tests से ढके हैं — launch sequence, disk images, control और egress transports, draft protocol — लेकिन इस प्रोजेक्ट के continuous integration में अभी तक असली हार्डवेयर पर कोई guest boot नहीं हुआ है, क्योंकि उसके लिए KVM या Hyper-V वाली मशीन चाहिए, और उसे साबित करने वाले jobs के पास ऐसी मशीन कभी नहीं रही। workspace bundle, जिसे guest की ज़रूरत नहीं, असली control loop के साथ Windows पर पूरी तरह परखा गया है। Linux और Windows पर guest-backed operations को तब तक अप्रमाणित मानें, जब तक आप उन्हें अपने हार्डवेयर पर साबित न कर लें। Nessie की पेयरिंग स्क्रीन भी अपने शब्दों में यही बात कहती है।

सुरक्षा और containment

एक workspace root, और उसका path मशीन पर ही रहता है

पेयरिंग ठीक एक canonical workspace root चुनती है: एक directory, फ़ोल्डरों का समूह नहीं, और कभी उनका निकटतम साझा parent नहीं। Nessie को root का basename बताया जाता है, ताकि व्यक्ति इंटरफ़ेस में सीमा पहचान सके; पूरा path केवल मालिक के लिए बनी मशीन की state में रहता है और कभी अपलोड नहीं होता। root बदला जा सकता है, लेकिन केवल तब जब हर स्थानीय ड्राफ़्ट और sandbox हटा दिए गए हों, और इससे एक नया descriptor revision बनता है, जो बाकी किसी भी policy बदलाव की तरह उसी मानवीय review से गुज़रता है। यह चुपचाप parent directory तक कभी नहीं फैल सकता।

फ़ाइल operations केवल relative paths स्वीकार करते हैं। वे traversal और हर symbolic-link component को ठुकराते हैं, दोबारा जाँचते हैं कि कॉन्फ़िगर किया गया root अब भी एक सामान्य directory है, और सीमित संरचित नतीजे लौटाते हैं, जिनमें होस्ट का कोई path नहीं होता।

लिखने का काम एक copy में जाता है, और उसे केवल एक व्यक्ति promote करता है

एजेंट आपकी फ़ाइलों पर कभी नहीं लिखता। file.write daemon की अपनी state directory के अंतर्गत, run के साथ जुड़ा, एक सीमित copy-on-write tree बनाता है, और उस run के बाद के reads व listings उसी ड्राफ़्ट को देखते हैं। guest का काम, coding sessions सहित, वही copy-on-write scratch इस्तेमाल करता है।

ड्राफ़्ट को असली वर्कस्पेस पर लागू करना एक ही operation है — workspace.promote — और सिस्टम में होस्ट पर लिखने का यही एकमात्र तरीका है। इसकी model-facing schema बिल्कुल नहीं है: कोई एजेंट, कोई असिस्टेंट और कोई caller-दिया गया path ड्राफ़्ट को होस्ट पर लिखे जाने वाले बदलाव में नहीं बदल सकता। इसके बजाय एक व्यक्ति Your reviewed drafts खोलता है, Review promotion दबाता है, और अपना मौजूदा पासवर्ड डालकर पुष्टि करता है। इसके बाद सर्वर कमांड बनाने से पहले मंज़ूर review digest, manifest digest, मूल run, उपयोगकर्ता और एजेंट, authorisation revision, operation grant और सक्रिय स्थानीय policy की दोबारा जाँच करता है। मशीन पर daemon manifest को खुद दोबारा बनाता है और बदला हुआ digest ठुकरा देता है — इसलिए review के बाद किया गया संपादन review की मंज़ूरी के साथ नहीं निकल सकता।

लागू करना खुद descriptor-आधारित और journal में दर्ज होता है। native helper workspace root और ड्राफ़्ट को पहले से खुले directory descriptors के रूप में लेता है, कभी paths के रूप में नहीं; वह हर component को no-follow operations से जाँचता है, symbolic links, hard links, special files और mount crossings को मना करता है, और एक all-or-recover journal रखता है, ताकि crash होने पर या तो सत्यापित manifest पूरा हो या कुछ और चलने से पहले मूल स्थिति बहाल हो जाए।

guest के पास कोई नेटवर्क नहीं है, और egress पर ज़बरदस्ती नियंत्रण है

जब किसी operation को guest चाहिए, तो वह हर सेशन के लिए एक Linux micro-VM होता है, जिसमें होस्ट का home नहीं होता, Docker socket नहीं होता, SSH एजेंट नहीं होता, कोई विरासत में मिला environment नहीं होता, और workspace share के अलावा कोई होस्ट mount नहीं होता। executable runtime mount केवल-पढ़ने योग्य है; लिखने योग्य workspace mount पर execution प्रतिबंधित है, इसलिए जो भी चलता है वह सत्यापित runtime payload से आता है, न कि एजेंट के लिखी किसी चीज़ से। guest कोई socket खोलने से पहले unprivileged identity पर आ जाता है, और root के स्वामित्व वाला share boot को विफल कर देता है, न कि privileged workload को चलता छोड़ देता है।

सबसे अहम बात, guest के पास कोई network interface नहीं है। Linux पर launch sequence जानबूझकर कोई interface कॉन्फ़िगर नहीं करता और कोई TAP device नहीं बनता; Windows पर Hyper-V द्वारा डिफ़ॉल्ट रूप से जोड़ा गया virtual network adapter setup के दौरान हटा दिया जाता है। मशीन से बाहर निकलने का guest का एकमात्र रास्ता उसके भीतर का एक loopback proxy है, जो एक virtual socket के ज़रिए होस्ट पर एक bridge तक tunnel होता है, और वह bridge bytes को daemon के अपने gateway को सौंपता है — एक ऐसा owner-only local socket listener, जिसमें कोई TCP listener नहीं और कोई सामान्य forwarding mode नहीं है। इसी gateway पर HTTP, CONNECT, WebSocket, redirect, origin, download और upload की policy लागू होती है, और इसके लिए Nessie की मौजूदा pinned-fetch व्यवस्था इस्तेमाल होती है, उन्हीं नियमों का दूसरा implementation नहीं। यहाँ कोई NAT bridge नहीं है और कोई सीधा DNS resolver नहीं है: वैकल्पिक DNS, raw TCP, QUIC और proxy bypass — सब कुछ मना है।

जो origin list यह gateway लागू करता है, वह मशीन के मालिक द्वारा मशीन पर कॉन्फ़िगर होती है, और जानबूझकर कभी अपलोड नहीं होती। इंटरफ़ेस इस कमी को साफ़ नाम देता है, यह दिखावा नहीं करता कि Nessie origin-policy का editor है: यह जानने के लिए कि ब्राउज़र एक्ज़ीक्यूटर किन जगहों तक पहुँच सकता है, उस व्यक्ति से पूछें जिसके पास मशीन है।

क्रेडेंशियल्स

होस्ट का कोई credential store कभी guest में mount नहीं होता। न keychain, न ~/.codex या ~/.claude, न कोई global CLI टोकन, न API key वाला environment variable। managed coding session के लिए एकमात्र समर्थित login एक owner-private authentication file है, जिसकी सामग्री केवल मालिक के नियंत्रण वाला initrd builder पढ़ता है — कभी Nessie नहीं, कभी descriptor नहीं, कभी कोई log या command argument नहीं — और उसे एक बार guest के भीतर एक निजी home में ले जाया जाता है, जो VM के साथ नष्ट हो जाता है। वह guest ठीक एक ओरिजिन तक पहुँच सकता है।

ब्राउज़र एक्ज़ीक्यूटर और भी सख्त है: हर सेशन को एक नया निजी browser profile मिलता है और वह वर्कस्पेस द्वारा तैयार किए गए profile को ठुकराता है, इसलिए वह बिना cookies, बिना extensions और बिना किसी पहले से साइन-इन स्थिति के शुरू होता है।

कच्चा स्थानीय डेटा केवल एक स्पष्ट, सीमित run के भीतर ही मॉडल प्रोवाइडर तक पहुँच सकता है। Nessie जो स्थायी रूप से रखता है, वह है redacted manifests, arguments और policy के digests, नतीजों के digests और संरचित status। फ़ाइलों की सामग्री, terminal output, browser DOM, क्रेडेंशियल और प्रमाणीकरण के कारक (authentication factors) database records, audit entries, logs, realtime events और error reports में नहीं रखे जा सकते।

operator क्या अनुमति देता है, और उसे कैसे वापस लेता है

एक्ज़ीक्यूटर इस्तेमाल करने की अनुमति कोई एक switch नहीं है। एजेंट कोई operation तभी चला सकता है जब उसके पास ठीक उसी एक्ज़ीक्यूटर और ठीक उसी operation की grant हो, और सामान्य logical tool policy उसकी अनुमति दे, और run का स्कोप मेल खाए, और मशीन की अपनी स्थानीय policy उसकी अनुमति दे। इसलिए एक एक्ज़ीक्यूटर पर operation की grant दूसरे पर कुछ भी अधिकृत नहीं करती, और capability refresh कुछ भी दायरा नहीं बढ़ा सकता, क्योंकि नए operations denied आते हैं।

एजेंट की पहुँच और sharing, दोनों उसी पेज पर तुरंत लागू होते हैं, बिना किसी approval continuation, password prompt या नए authentication चरण के। एक्ज़ीक्यूटर के Agents tab पर एक manager सीधे किसी एजेंट की मशीन तक पहुँच चालू या बंद करता है; Sharing पर वे किसी व्यक्ति को Can use या Admin दे सकते हैं, या उपयोग को किसी प्रोजेक्ट तक, या मौजूदा टीम के सभी लोगों तक, उसी तरीके से बढ़ा सकते हैं। आपकी अपनी असिस्टेंट बातचीत में — केवल वहीं, किसी साझा channel, scheduled job या किसी दूसरे एजेंट के run में कभी नहीं — असिस्टेंट इसके बजाय एजेंट-पहुँच या assignment बदलाव तैयार कर सकता है, जो उस बातचीत में एक पुष्टि card भेजता है; आप उस पर Allow access दबाने तक कुछ नहीं बदलता, और चैट का text कभी पुष्टि नहीं होता।

तीन बदलावों के लिए पुष्टि के समय आपको अब भी अपना मौजूदा पासवर्ड दोबारा डालना होता है: descriptor revision सक्रिय करना; असिस्टेंट द्वारा तैयार की गई वह assignment जो एजेंट के बजाय किसी व्यक्ति को मशीन देती है; और वह स्थायी policy जो सहकर्मियों को मालिक के रूप में उस पर कमांड शुरू करने देती है — unattended ticket-work policy। मशीन को disconnect या delete करने के लिए जानबूझकर इनमें से कुछ नहीं माँगा जाता, क्योंकि kill switch उस चीज़ से ज़्यादा मुश्किल कभी नहीं होना चाहिए जिसे वह रोकता है। review किए गए ड्राफ़्ट का promotion हमेशा पासवर्ड माँगता है। audit trail कार्य करने वाले व्यक्ति और असिस्टेंट की भागीदारी को अलग-अलग दर्ज करता है।

एक्ज़ीक्यूटर कुछ सीमित, स्पष्ट states से होकर गुज़रता है:

pending_pairing → online ↔ offline
        │             ↓
        └──────────→ draining → revoked
                         ↓
                       error

हेडर के Computer menu से manager हर lifecycle बदलाव तैयार करता है: उसे pause करना, pause होने के बाद resume करना, disconnect करना, या delete करना। Pause करने पर एक्ज़ीक्यूटर online रहता है, पर कमांड लेना बंद कर देता है। Disconnect करने पर उसके client certificates और बाकी सभी लंबित candidate handles अमान्य हो जाते हैं, और इसे वापस नहीं लिया जा सकता — disconnect हुए एक्ज़ीक्यूटर को नए एक्ज़ीक्यूटर के रूप में फिर से पेयर किया जाता है। Delete भी यही करता है और एक्ज़ीक्यूटर को सूची से भी हटा देता है; disconnect के उलट, यह एक्ज़ीक्यूटर की हर स्थिति में उपलब्ध है, यहाँ तक कि पेयरिंग लंबित हो या पहले से disconnect हो, क्योंकि सूची से निकलने का यही एकमात्र तरीका है। Draining — यानी नए काम लेने से पहले अपने पास का काम पूरा करना — protocol में एक असली तीसरी state है, और इंटरफ़ेस किसी मशीन को इस state में दिखा सकता है, लेकिन यहाँ से कोई इसे शुरू नहीं करता: यह केवल API की सीधी call से होता है। हर पुष्टि किया गया access बदलाव, descriptor review और lifecycle transition, drain सहित, daemon के connection epoch को भी आगे बढ़ाता है, ताकि उसका अगला control poll — अधिक से अधिक एक सेकंड बाद — विफल होकर बंद हो जाए, और जीवित guests को फिर से जुड़ने से पहले रोक दे। Revocation ऐसा अनुरोध नहीं है जिसे मशीन अनदेखा कर सके।

एक्ज़ीक्यूटर चलाना

जाँचना कि यह ठीक चल रहा है

Nessie का अपना उत्तर liveness है। daemon एक heartbeat पर signature करता है, और जिस एक्ज़ीक्यूटर की आख़िरी प्रमाणित गतिविधि साठ सेकंड से पुरानी है, उसे सूची में आने, चुने जाने या उसे काम भेजे जाने से पहले स्थायी रूप से offline चिह्नित कर दिया जाता है। जो एक्ज़ीक्यूटर online दिखता है, उसने पिछले एक मिनट के भीतर अपने होने का प्रमाण दिया है।

मशीन पर कोई health endpoint नहीं है — daemon डिज़ाइन के अनुसार किसी भी operator-facing port पर सुनता ही नहीं। macOS और Linux पर सीधे CLI से पूछें:

nessie-executor status                # every paired executor, plus linger state
nessie-executor status <executorId>
systemctl --user status nessie-executor@<executorId>

macOS पर status हर टीम का launchd agent दिखाता है। systemctl कमांड केवल Linux के लिए है। Windows पर tray icon एक नज़र में उत्तर देता है, उसका menu कारण बताता है, और service log विवरण रखता है। दोनों में से किसी भी platform पर, Nessie में एक्ज़ीक्यूटर का Overview tab उसके मंज़ूर profiles, उसकी data boundary, उसे आख़िरी बार कब देखा गया, और review की प्रतीक्षा कर रहा कोई भी लंबित स्थानीय policy प्रस्ताव दिखाता है।

Logs

हर ऐसी अस्वीकृति, जिस पर व्यक्ति कदम उठा सके, वहीं दर्ज होती है: बिना signature या छेड़छाड़ किया गया runtime, वह state directory जो सुरक्षित न हो सके, वह एक्ज़ीक्यूटर जो boot पर शुरू नहीं हुआ। वहाँ कभी पेयरिंग challenge, कोई key, या child process का output नहीं जाता। कोई log-level सेटिंग नहीं है जिसे बढ़ाया जा सके, क्योंकि चालू करने के लिए इससे ज़्यादा verbose कुछ नहीं है।

Mac CLI हर टीम का service log ~/Library/Logs/NessieExecutor/<executorId>.log में लिखता है।

अपग्रेड करना

CLI को Homebrew, APT या DNF से अपग्रेड करें, फिर हर टीम की service को disable और उसके बाद enable से restart करें। WinGet Windows एक्ज़ीक्यूटर को अपग्रेड करता है। सीधे Nessie Desktop installers signed in-app updates देते हैं; MSI और Debian इंस्टॉल अपने package manager का उपयोग करते हैं। पेयरिंग और स्थानीय permissions अपग्रेड के बाद भी बनी रहती हैं।

रोकना और हटाना

रोकना daemon का अपना सुचारु (graceful) रास्ता है, kill नहीं। वह termination signal लेता है, हर guest session रोकता है, अपना lease छोड़ता है और बाहर निकल जाता है। Linux पर unit दस सेकंड के teardown budget के लिए पंद्रह सेकंड इंतज़ार करता है और जानबूझकर कभी ऐसे uncatchable kill तक नहीं जाता — क्योंकि teardown के बीच में मारा गया daemon एक micro-VM और एक workspace overlay को इस तरह छोड़ देता है कि उन्हें साफ़ करने वाली कोई प्रक्रिया नहीं बचती। अटका हुआ stop इसलिए systemctl --user status में चुपचाप नहीं, दिखाई देता है, और उसे kill करना एक स्पष्ट मानवीय निर्णय है।

Linux पैकेज हटाने के लिए:

nessie-executor disable <executorId>   # stops and disables the service
sudo apt remove nessie-executor
loginctl disable-linger                # only if your user manager should stop running at boot too

Windows पर, msiexec /x service, उसकी registry entries और tray की startup entry को रोकता और हटाता है। दोनों platforms पर पेयर की हुई state जानबूझकर पीछे छोड़ी जाती है — Linux पर ~/.local/state/nessie-executor/ और Windows पर %ProgramData%\Nessie Executor। पेयरिंग एक मशीन key और एक signed policy revision है, और किसी प्रोग्राम को uninstall करना उन्हें नष्ट करने का अनुरोध नहीं है; दोबारा इंस्टॉल करने पर वे वहीं मिल जाती हैं जहाँ थीं। पेयरिंग भूलने के लिए directory हाथ से हटाएँ, और दूसरी ओर से उसे खत्म करने के लिए Nessie में एक्ज़ीक्यूटर revoke करें।

Windows tray और desktop companion दोनों Forget pairing on this computer को एक मुख्य कार्रवाई के रूप में देते हैं: यह स्थानीय daemon को रोकता है, मशीन की key और folder चयन हटाता है, और एक native पुष्टि के बाद स्थानीय ड्राफ़्ट की प्रतियाँ स्थायी रूप से मिटा देता है — जबकि सर्वर-साइड एक्ज़ीक्यूटर और उसका audit इतिहास मालिक के लिए रखने या revoke करने हेतु छोड़ देता है।

आम विफलताएँ