المنفّذون عن بُعد

امنح الوكيل حاسوبًا حقيقيًا يعمل عليه، على Linux أو macOS أو Windows.

ما هو المنفّذ عن بُعد

لا يملك الوكيل في Nessie جهاز حاسوب. يستطيع قراءة ما هو موجود في Nessie، والتحدث مع الأشخاص، واستدعاء الأدوات المتصلة عبر الشبكة، لكنه لا يستطيع فتح ملف على جهاز محمول، أو تشغيل أمر، أو الاطلاع على صفحة لا توجد إلا خلف تسجيل دخول شخص ما. المنفّذ عن بُعد هو الطريقة التي تمنح بها الوكيل جهازاً يعمل عليه.

المنفّذ برنامج خلفي صغير تثبّته على جهاز تتحكم فيه. يتصل بمثيل Nessie الخاص بك من الخارج، ويثبت أي جهاز هو باستخدام مفتاح لا يغادر الجهاز أبداً، ثم يقدّم مجموعة ثابتة ومسمّاة من العمليات، ولا شيء غيرها. تصل الأعمال على شكل أوامر موقّعة منفصلة، وتعود النتائج على شكل إيصالات محدودة ومنظّمة. ولا يقبل الجهاز أي اتصال وارد من Nessie.

من المهم أن نكون دقيقين في ما لا يكون عليه المنفّذ، لأن معظم أدوات الوصول عن بُعد تكون واحدة من هذه الأشياء، والمنفّذ يستبعدها عمداً. لا يوجد SSH، ولا صدفة (shell) عامة عن بُعد، ولا ربط بجلسة طرفية مفتوحة لديك، ولا إدخال قياسي من السحابة، ولا وكيل شبكة محلية عام. وهو ليس خادم MCP، وليس حاوية ولا بيئة تنفيذ سحابية، فلدى Nessie هذه بالفعل، وهي شيء مختلف. المنفّذ نقطة نهاية تحمل صلاحيات، بقائمة مغلقة من العمليات، وهذه القائمة هي السطح كله.

لمن ينتمي المنفّذ

يُنشأ كل منفّذ بنطاق واحد بالضبط، ولا يمكن تغيير هذا النطاق لاحقاً. وهو يحدد من يحق له استدعاء المنفّذ ومن يحق له إدارته.

يجب أن يكون لدى المنفّذ الخاص مسؤول بشري نشط واحد على الأقل دائماً. إزالة آخر مسؤول تفشل مباشرة؛ وإذا كانت عملية إنهاء ارتباط شخص ما ستترك المنفّذ بلا مسؤول، فإنه يتوقف عن قبول أي عمل جديد، وينهي ما لديه، ثم يلغي نفسه. ولمالك المؤسسة مسار إلغاء طارئ فقط، يُنهي به منفّذاً لا يديره، دون أن يطّلع على قائمة الأشخاص الخاصة به أو جلساته أو محتواه. فالوصول الخاص لا يُنقل بصمت إلى شخص آخر أبداً.

ما الذي يستطيع الوكيل فعله فعلاً بالمنفّذ

مفردات العمليات ثابتة في الشيفرة، ولا تُضبط حسب كل نشر. وتنقسم إلى قسمين، وهذا التقسيم يحدد ما ينبغي تثبيته: بعض العمليات يقدّمها البرنامج الخلفي من مجلده المؤقت الخاص دون أي جهاز افتراضي، والباقي يحتاج إلى جهاز افتراضي ضيف لكل جلسة على المضيف.

العمليات التي لا تحتاج إلى جهاز ضيف هي حزمة مساحة العمل. والمضيف الذي لا يستطيع تشغيل جهاز ضيف ليس منفّذاً معطلاً؛ بل يُقرن بشكل طبيعي، ويبلّغ أن خلفية الحماية لديه هي none، ولا يعلن إلا عن حزمة مساحة العمل دون غيرها. وهذه هي الحالة التي ينتهي إليها إصدار Windows بلا Hyper-V، أو جهاز Linux لا يستطيع مستخدمه الوصول إلى /dev/kvm، وتسمّيها الواجهة بوضوح بدلاً من أن تفشل بطريقة غامضة.

لا يبدأ الوكيل عمل المتصفح من تلقاء نفسه أبداً. فمسار الربط العادي لعملية واحدة يرفض browser.open وbrowser.observe رفضاً قاطعاً. ويُشغَّل المتصفح من قِبل شخص من داخل قناة، كحزمة من أربع عمليات في تشغيل جديد، ولا يمكن إضافة أي ربط آخر إليها بعد ذلك. وتسير جلسات البرمجة المُدارة بالطريقة نفسها.

توجد في الشيفرة مجموعتان إضافيتان، وهما متاحتان عمداً. فالعمليات الخاصة بالتحكم في تبويب Chrome سبق أن سجّل فيه المستخدم دخوله تملك تنفيذاً محلياً كاملاً وإضافة للرسائل الأصلية (native messaging)، لكن خادم التحكم لا يعرضها إلا بعد أن يستطيع الخادم إثبات أن المحادثة الأصلية كانت خاصة، وأن يسجّل من أفصح عن أي معلومات. فالأساس غير مفعّل عن قصد، والإضافة غير مشحونة في أي من المثبّتين. كما أن عدداً من عمليات البرمجة، وهي الإرفاق والإرسال والمقاطعة والإغلاق، مذكورة في المخطط لكنها بلا تنفيذ، فلا يمكن منحها.

كيف يعمل

الاتصال صادر دائماً

يُجري البرنامج الخلفي اتصالات HTTPS وWSS صادرة نحو واجهة Nessie البرمجية (API) الخاصة بك، ولا يتصل بأي شيء آخر. ولا تتصل Nessie بالحاسوب المحمول أبداً، ولا تحفظ له عنواناً، ولا تعامل أي نقطة نهاية في الكتالوج كوسيلة نقل إلى الجهاز. ولهذا يعمل المنفّذ من شبكة منزلية، أو خلف NAT، أو عبر VPN للشركة، دون أي توجيه للمنافذ ودون أي قاعدة جدار ناري واردة. ولهذا أيضاً فإن إيقاف البرنامج الخلفي يعني قطع الاتصال كاملاً وفورياً.

يجب أن يكون أصل واجهة البرمجة عبر HTTPS. والاستثناء الوحيد هو عنوان loopback للأشخاص الذين يشغّلون Nessie على أجهزتهم الخاصة، وذلك عبر متغير بيئة خاص به. ولا يوجد أي خيار عادي يحوّل أصل إنتاج إلى HTTP غير مشفّر.

يُثبت الإقران هوية الجهاز، ويؤكدها شخص

الإقران إثبات من طرفين. يُنشئ شخص مخوَّل المنفّذ في Nessie بنطاقه، فتصدر Nessie تسجيلاً: تحدٍّ عشوائي بطول 256 بت لا يخزّن منه سوى مُتحقِّق SHA-256، وصالح لمدة 10 دقائق ولاستخدام واحد فقط.

على الجهاز، يُنشئ البرنامج الخلفي زوج مفاتيح Ed25519، ويخزّنه في تخزين محمي بنظام التشغيل لصاحبه وحده، ويكتب الطلب الموقّع بالضبط على القرص قبل أي استدعاء للشبكة. فإذا ضاعت الاستجابة يمكن إعادة المحاولة بالمفتاح المُعدّ نفسه، بدلاً من الإقران مرتين بصمت. ثم يرسل معرّف التسجيل والتحدي ومفتاحه العام وتوقيع الإثبات. وتخزّن Nessie المفتاح العام وبصمته، ولا تخزّن المفتاح الخاص أبداً.

تعرض Nessie بعد ذلك بصمة المفتاح على شخص ليؤكدها. وإلى أن يتم هذا التأكيد وإثبات الحيازة اللاحق، يبقى المنفّذ غير متصل. ولا يمكن إكمال الإقران من نص دردشة أو من سجل طرفية؛ بل يتطلب إجراءً بشرياً مقصوداً في واجهة الويب أو في تطبيق سطح المكتب.

الجهاز الذي يفقد مفتاحه لا يستطيع استرداد سجل المنفّذ الخاص به. فيُلغى ذلك السجل، ويُسجَّل المنفّذ من جديد كمنفّذ جديد. أما تدوير المفتاح فعلى العكس، إذ هو معاملة واحدة موقّعة بالمفتاح القديم والمفتاح الجديد معاً.

الواصف هو الإقرار الموقَّع للجهاز عن نفسه

يُصدر البرنامج الخلفي المقترن واصفاً: بياناً موقّعاً ومُراجَعاً بشكل متزايد، يتضمن حقائق بنيوية فقط، أي مخططات العمليات التي يدعمها، وحدود الموارد والشبكة، والمنصة، وتجزئة لسياسته المحلية. ولا يحمل أي مسارات للمضيف، ولا يُنشئ أي صلاحية في السحابة.

لا تُفعَّل أي مراجعة جديدة فور وصولها. بل تُخزَّن بانتظار المراجعة، ويجب أن يطّلع عليها شخص مخوَّل ويؤكدها قبل أن تؤثر في ما هو متاح. وهذا ما يمنع تحديث القدرات من منح صلاحيات جديدة بصمت، فكل عملية جديدة معلَنة تبدأ مرفوضة.

كن واضحاً بشأن ما يثبته التوقيع. فالواصف الموقَّع بمفتاح منفّذ مقترن يثبت أن هذا المفتاح هو من أصدر الإقرار. لكنه لا يثبت أن المضيف سليم من الاختراق، ويجب أن تقول الواجهة ذلك صراحة.

الإرسال: مرشّح، ثم ربط، ثم أمر، ثم إيصال

لا يسمّي الوكيل المنفّذ أبداً. قبل أن يستطيع التشغيل استخدامه، تحوّل Nessie العملية المنطقية إلى مرشّح توفّر غير شفاف وقصير الأجل. ولا تحتوي الاستجابة على معرّف للمنفّذ، وتحتفظ قاعدة البيانات بتجزئة للمقبض فقط، مع من ولأي شيء حُلّ المقبض. فالنماذج والعملاء يتلقون مقبضاً، لا جهازاً يمكن اختياره.

التوفّر يمرّ عبر محلّل واحد، تستخدمه الواجهة البرمجية والعامل (worker) والواجهة والمساعد بالطريقة نفسها:

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

عند استهلاك المرشّح يُنشأ ربط تحت قفل في قاعدة البيانات، يعيد فحص كل تلك البوابات مرة ثانية ويرفع حاجزاً تسلسلياً متزايداً. ثم يعيد الإرسال فحصها مرة ثالثة. والنتيجة أن الإذن المسحوب، أو السياسة المضيّقة، أو المنفّذ الملغى بين خطوتين، يوقف العمل بدلاً من أن يُلاحَظ لاحقاً. ولا يمكن لمحاولة إعادة أن تصل إلى جهاز غير الجهاز الذي ارتبط به التشغيل.

يسير الأمر نفسه عبر طابور Nessie العادي ودورة حياة استدعاء الأدوات، لا عبر طابور خاص به. ويستطلع البرنامج الخلفي العمل عبر قناة التحكم الموثّقة، ولا يُدفع إليه أي شيء أبداً. ولا يمر الأمر إلا عبر أربعة إيصالات، لا غير:

leased → accepted → started → result-acknowledged

تربط كل إطار معرّفَ الأمر، ومصدر التشغيل، وحاجز الربط، ومراجعة القدرة، وتاريخ انتهاء الصلاحية، ومفتاح عدم التكرار (idempotency)، وتجزئات الوسائط والحمولة. ويرفض البرنامج الخلفي أي عدم تطابق، أو سياسة قديمة، أو إعادة تشغيل، أو نتيجة ثانية لأمر أنهاه مسبقاً. وتُشفَّر الوسائط والنتائج النهائية بـ AES-256-GCM عند التخزين، وتحتفظ قاعدة البيانات بنص مشفّر محدود وتجزئات قانونية، لا بالمحتوى نفسه.

إذا فُقد الإقرار بالاستلام، لا تفترض Nessie النجاح. يُسجَّل الأمر بنتيجة مجهولة، ويسلك التشغيل مسار الاسترداد المعتاد. والبرنامج الخلفي، الذي يسجّل كل أمر مُسلَّم محلياً قبل أن يبدأ العمل، لن يكرر الأثر الجانبي. ويمكن لإيصال متأخر أن يحسم الالتباس بصدق.

حدود الثقة

تثبيت المنفّذ وإقرانه

ثبّت واجهة سطر الأوامر على macOS عبر Homebrew، وتطبيقات macOS عبر casks الخاصة بـ Homebrew، وواجهة سطر الأوامر على Linux عبر APT أو DNF، أو منفّذ Windows عبر WinGet. ولكل فريق مقرون صلاحياته المنفصلة المخزَّنة على الحاسوب. وتتحكم Nessie في الوصول داخل الفريق، لكنها لا تستطيع تغيير الموارد المحلية.

يتضمن دليل التثبيت والإقران الأوامر الدقيقة، وتدفق الرمز المكوّن من 8 أرقام من الطرفين، والإعدادات المحلية، والتشغيل، والتحديثات، والإزالة.

مدى ما أُثبت فعلياً على كل منصة

تختلف حالة الأجهزة الضيفة الثلاثة للحماية، والفرق مهم. فنظام macOS هو الخلفية التي يعمل فيها مسار الجهاز الضيف ويُختبر فعلياً. أما خلفية Firecracker على Linux وخلفية Hyper-V على Windows فمنفّذتان ومشمولتان باختبارات على جانب المضيف، تغطي مسار التشغيل وصور الأقراص ونقل التحكم والخروج وبروتوكول المسودات. لكن لم يُشغَّل أي جهاز ضيف بعد على عتاد حقيقي في التكامل المستمر لهذا المشروع، لأن ذلك يتطلب جهازاً يملك KVM أو Hyper-V، والمهام التي كانت ستثبت ذلك لم يتوفر لها جهاز كهذا أبداً. أما حزمة مساحة العمل، التي لا تحتاج إلى جهاز ضيف، فتُختبر من البداية إلى النهاية على Windows مقابل حلقة تحكم حقيقية. عامِل العمليات الضيفة على Linux وWindows على أنها غير مُثبتة حتى تُثبتها على عتادك الخاص. وتقول شاشة الإقران في Nessie الشيء نفسه بكلماتها.

الأمان والاحتواء

جذر واحد لمساحة العمل، ومساره يبقى على الجهاز

يختار الإقران جذراً واحداً قانونياً لمساحة العمل: مجلد واحد، لا مجموعة مجلدات، ولا أقرب أب مشترك لها. وتُبلَّغ Nessie باسم المجلد الأساسي للجذر، ليتعرّف الشخص على الحدود في الواجهة. أما المسار الكامل فيبقى في حالة الجهاز المحمية لصاحبه وحده، ولا يُرفع أبداً. ويمكن تغيير الجذر، لكن فقط بعد إزالة كل المسودات والبيئات المعزولة المحلية، ويُنتج ذلك مراجعة جديدة للواصف تمر بالمراجعة البشرية نفسها التي تمر بها أي تغيير في السياسة. ولا يمكن أن يتّسع إلى مجلد أب بصمت.

تقبل عمليات الملفات مسارات نسبية فقط. وترفض الاجتياز وكل مكوّن رابط رمزي (symbolic link)، وتتحقق من أن الجذر المضبوط ما زال مجلداً عادياً، وتعيد نتائج منظّمة ومحدودة لا تحتوي على أي مسار للمضيف.

تذهب الكتابات إلى نسخة، ولا يطبّقها إلا شخص

لا يكتب الوكيل في ملفاتك أبداً. فـ file.write ينشئ شجرة نسخ عند الكتابة محدودة الحجم في مجلد الحالة الخاص بالبرنامج الخلفي، مرتبطة بالتشغيل، وتشاهد القراءات والقوائم اللاحقة لذلك التشغيل المسودةَ. ويستخدم عمل الجهاز الضيف، بما فيه جلسات البرمجة، المساحةَ المؤقتة نفسها بنظام النسخ عند الكتابة.

تطبيق مسودة على مساحة العمل الحقيقية عملية واحدة، هي workspace.promote، وهي الكتابة الوحيدة على المضيف في النظام كله. ولا يوجد لها أي مخطط موجّه للنموذج أصلاً: لا وكيل ولا مساعد ولا مسار يحدده المتصل يمكنه تحويل مسودة إلى كتابة على المضيف. وبدلاً من ذلك يفتح الشخص مسوداتك المُراجَعة، ويضغط مراجعة التطبيق، ويؤكد بكلمة المرور الحالية. ثم يتحقق الخادم من تجزئة المراجعة المعترف بها، وتجزئة البيان، والتشغيل والوكيل والمستخدم الذي أنشأها، ومراجعة التفويض، وإذن العملية، والسياسة المحلية النشطة، قبل أن ينشئ الأمر. وعلى الجهاز يعيد البرنامج الخلفي بناء البيان بنفسه، ويرفض أي تجزئة تغيّرت، فلا يمكن لتعديل أُجري بعد المراجعة أن يمر بموافقة المراجعة.

يعتمد التطبيق نفسه على الواصفات، ويُسجَّل في يومية (journal). فالمساعد الأصلي يتلقى جذر مساحة العمل والمسودة كواصفات ملفات مفتوحة بالفعل، لا كمسارات. ويتحقق من كل مكوّن بعمليات لا تتبع الروابط، ويرفض الروابط الرمزية والصلبة والملفات الخاصة وتجاوز نقاط التركيب، ويحتفظ بيومية «الكل أو الاسترداد»، بحيث يُكمل الانهيار البيان المتحقَّق منه أو يعيد الأصل قبل أن يعمل أي شيء آخر.

الجهاز الضيف بلا شبكة، والخروج يُفرض إجبارياً

حين تحتاج عملية إلى جهاز ضيف، فهو جهاز افتراضي مصغّر لـ Linux لكل جلسة، بلا مجلد منزل للمضيف، ولا مقبس Docker، ولا وكيل SSH، ولا بيئة موروثة، ولا أي تركيب للمضيف غير مشاركة مساحة العمل. ويكون المسار القابل للتنفيذ مركّباً للقراءة فقط، أما مسار مساحة العمل القابلة للكتابة فيمنع التنفيذ، فكل ما يعمل يأتي من حمولة التشغيل المتحقَّق منها لا من شيء كتبه وكيل. ويتخلى الجهاز الضيف عن امتيازاته قبل أن يفتح أي مقبس، ويُفشل الإقلاع إذا كانت مشاركة مساحة العمل مملوكة للجذر، بدلاً من ترك حمل عمل ممتاز قيد التشغيل.

والأهم أن الجهاز الضيف لا يملك أي واجهة شبكة. ففي Linux لا تُهيَّأ أي واجهة عمداً، ولا يُنشأ جهاز TAP أبداً؛ وفي Windows تُزال محوّلة الشبكة الافتراضية التي يضيفها Hyper-V افتراضياً أثناء الإعداد. ومسار الخروج الوحيد للجهاز الضيف من الجهاز هو وكيل محلي (loopback) داخله، يُنقل عبر مقبس افتراضي إلى جسر على المضيف، الذي يسلّم البايتات إلى البوابة الخاصة بالبرنامج الخلفي. وهذه البوابة مقبس محلي للمالك وحده، بلا أي مستمع TCP وبلا أي وضع لإعادة التوجيه العام. وفي تلك البوابة تُفرض سياسات HTTP وCONNECT وWebSocket وإعادة التوجيه والأصل والتنزيل والرفع، باستخدام آلية الجلب المثبَّت (pinned-fetch) القائمة في Nessie، بدلاً من تنفيذ ثانٍ للقواعد نفسها. ولا يوجد جسر NAT ولا محلّل DNS مباشر، فـ DNS البديل، وTCP الخام، وQUIC، وتجاوز الوكيل، كلها مرفوضة.

قائمة الأصول التي تفرضها تلك البوابة مضبوطة على الجهاز من مالكه، ولا تُرفع أبداً عن قصد. وتعترف الواجهة بهذا الغياب بدلاً من أن تدّعي أن Nessie محرِّر لسياسة الأصول. ولمعرفة ما يستطيع منفّذ المتصفح الوصول إليه، اسأل الشخص الذي يملك الجهاز.

بيانات الاعتماد

لا يُركَّب أي مخزن بيانات اعتماد للمضيف داخل الجهاز الضيف أبداً. لا سلسلة المفاتيح، ولا ~/.codex أو ~/.claude، ولا رمز CLI عام، ولا متغير بيئة يحمل مفتاح API. وتسجيل الدخول الوحيد المدعوم لجلسة برمجة مُدارة هو ملف مصادقة خاص بالمالك، لا تقرأ محتوياته إلا أداة بناء initrd التي يتحكم فيها المالك. ولا تقرؤه Nessie ولا الواصف ولا سجل ولا وسيط أمر. وينتقل الملف مرة واحدة إلى منزل خاص داخل الجهاز الضيف، ويُدمَّر مع الجهاز الافتراضي. ولا يستطيع ذلك الجهاز الضيف الوصول إلا إلى أصل واحد بالضبط.

منفّذ المتصفح أشد صرامة، فكل جلسة تحصل على ملف تعريف متصفح خاص جديد، وترفض ملفاً أعدّته مساحة العمل، فتبدأ بلا ملفات تعريف ارتباط ولا إضافات ولا أي حالة تسجيل دخول موروثة.

لا تصل البيانات المحلية الخام إلى مزوّد نموذج إلا داخل تشغيل صريح ومحدود. وما تحفظه Nessie هو بيانات وصفية منقّحة، وتجزئات الوسائط والسياسات، وتجزئات النتائج، وحالة منظّمة. ويُمنع حفظ محتويات الملفات، ومخرجات الطرفية، ومحتوى DOM للمتصفح، وبيانات الاعتماد، وعوامل المصادقة في سجلات قاعدة البيانات، أو في تدقيق الأحداث، أو السجلات، أو الأحداث الفورية، أو تقارير الأخطاء.

ما يمنحه المشغّل، وكيف يستعيده

الإذن باستخدام منفّذ ليس مفتاحاً واحداً. لا يستطيع الوكيل استدعاء عملية إلا إذا كان يملك إذناً لـذلك المنفّذ بعينه وتلك العملية بعينها، و تسمح بها سياسة الأداة المنطقية المعتادة، و يتطابق نطاق التشغيل، و تسمح بها السياسة المحلية للجهاز نفسه. فمنح منفّذ عملية واحدة لا يصرّح بشيء على منفّذ آخر، ولا يستطيع تحديث القدرات أن يوسّع أي شيء، لأن العمليات الجديدة تصل مرفوضة.

يسري وصول الوكيل والمشاركة فوراً في الصفحة نفسها، دون استمرار بالموافقة أو مطالبة بكلمة المرور أو خطوة مصادقة جديدة. ففي تبويب الوكلاء للمنفّذ، يفعّل المدير وصول الوكيل إلى الجهاز أو يوقفه مباشرة. وفي المشاركة يمنح شخصاً صلاحية «يمكنه الاستخدام» أو «مسؤول»، أو يوسّع الاستخدام إلى مشروع أو إلى الجميع في الفريق الحالي بالطريقة نفسها. أما في محادثة المساعد الشخصي الخاصة بك، وفي تلك المحادثة فقط، لا في قناة مشتركة أو مهمة مجدولة أو تشغيل وكيل آخر، فيمكن للمساعد أن يُعدّ بدلاً من ذلك تغييراً في وصول الوكيل أو في التكليف، فيرسل بطاقة تأكيد في تلك المحادثة. ولا يتغير شيء حتى تضغط «السماح بالوصول» على تلك البطاقة، ونص الدردشة لا يُعد تأكيداً أبداً.

ما زالت ثلاثة تغييرات تتطلب منك إعادة إدخال كلمة مرورك الحالية لحظة التأكيد: تفعيل مراجعة واصف؛ وتكليف يعدّه المساعد ويمنح شخصاً، لا وكيلاً، حق الوصول إلى الجهاز؛ وسياسة دائمة تسمح لزملاء بتشغيل أوامر عليه بصفتهم مالكه، وهي سياسة العمل على التذاكر دون إشراف. أما فصل جهاز أو حذفه فلا يطلب أيٌّ منهما كلمة المرور عمداً، لأن مفتاح الإيقاف الطارئ لا يجب أن يكون أصعب وصولاً من الشيء الذي يوقفه. أما تطبيق مسودة مُراجَعة فيطلبها دائماً. ويسجّل سجل التدقيق الشخصَ الفاعل ومشاركةَ المساعد، كلاً على حدة.

يمرّ المنفّذ بمجموعة صغيرة وصريحة من الحالات:

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

تُعدّ قائمة الجهاز في الترويسة المكان الذي يُعدّ فيه المدير كل تغيير في دورة الحياة: إيقاف مؤقت، أو استئناف بعد الإيقاف المؤقت، أو قطع الاتصال، أو الحذف. والإيقاف المؤقت يُبقي المنفّذ متصلاً، لكنه يوقف قبوله للأوامر. وقطع الاتصال يُبطل شهادات العميل الخاصة به وكل مقابض المرشحين المعلّقة، ولا يمكن التراجع عنه، فالمنفّذ المقطوع يُقرن من جديد كمنفّذ جديد. والحذف يفعل الشيء نفسه ويزيله أيضاً من القائمة. وعلى عكس قطع الاتصال، يُعرض الحذف أياً كانت حالة المنفّذ، بما فيها الإقران المعلّق والمقطوع أصلاً، لأنه الطريق الوحيد لمغادرة القائمة. والتفريغ، أي إنهاء العمل الذي لديه قبل أن يتوقف عن قبول المزيد، حالة ثالثة حقيقية في البروتوكول، ويمكن للواجهة أن تعرض جهازاً فيها، لكن لا شيء هنا يبدأها، إذ لا يبدأها إلا استدعاء مباشر للواجهة البرمجية. وكل تغيير مؤكَّد في الوصول، ومراجعة واصف، وانتقال في دورة الحياة، بما فيه التفريغ، يرفع أيضاً رقم عصر الاتصال (connection epoch) للبرنامج الخلفي، فيفشل استطلاعه التالي للتحكم، خلال ثانية على الأكثر، بشكل مغلق، ويوقف كل جهاز ضيف حي قبل أن يتمكن من إعادة الاتصال. فالإلغاء ليس طلباً يستطيع الجهاز تجاهله.

تشغيل المنفّذ

التحقق من أنه سليم

إجابة Nessie نفسها هي إشارة الحياة. يوقّع البرنامج الخلفي نبضة، وأي منفّذ مرّ أكثر من 60 ثانية على آخر نشاط موثّق له يُوسم فوراً وبشكل دائم بأنه غير متصل، قبل أن يصبح مدرجاً أو محدداً أو مرسلاً إليه العمل. والمنفّذ الذي يظهر متصلاً أثبت نفسه خلال الدقيقة الأخيرة.

لا توجد نقطة فحص للصحة على الجهاز، فالبرنامج الخلفي لا يستمع على أي منفذ موجَّه للمشغّل، وهذا مقصود. وفي macOS وLinux، اسأل واجهة سطر الأوامر مباشرة:

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

على macOS، تُبلّغ الحالة عن وكيل launchd الخاص بكل فريق. أمر systemctl خاص بـ Linux فقط. وعلى Windows، أيقونة الصينية (tray) هي الإجابة السريعة، وقائمتها تسمّي السبب، وسجل الخدمة يحمل التفاصيل. وعلى المنصتين، يعرض تبويب نظرة عامة للمنفّذ في Nessie الملفات الشخصية المعتمدة له، وحدود بياناته، ووقت آخر ظهور له، وأي اقتراح سياسة محلي معلّق بانتظار المراجعة.

السجلات

كل رفض يستطيع الشخص التصرف بشأنه يُكتب هناك: برنامج تشغيل غير موقَّع أو معبوث به، أو مجلد حالة لا يمكن تأمينه، أو منفّذ لم يبدأ عند الإقلاع. ولا يُكتب هناك أبداً تحدي إقران، ولا مفتاح، ولا مخرجات عملية فرعية. ولا يوجد إعداد لمستوى السجل لرفعه، لأنه لا يوجد شيء أكثر تفصيلاً لتشغيله.

تكتب واجهة سطر الأوامر على macOS سجل خدمة كل فريق في ~/Library/Logs/NessieExecutor/<executorId>.log.

الترقية

رقِّ واجهة سطر الأوامر عبر Homebrew أو APT أو DNF، ثم أعد تشغيل خدمة كل فريق بتنفيذ disable متبوعاً بـ enable. وتُرقّي WinGet منفّذ Windows. وتعرض مثبّتات Nessie Desktop المباشرة تحديثات موقَّعة داخل التطبيق، أما تثبيتات MSI وDebian فتستخدم مدير الحزم الخاص بها. وتبقى الإقرانات والصلاحيات المحلية بعد الترقيات.

الإيقاف والإزالة

الإيقاف مسار رشيق يملكه البرنامج الخلفي نفسه، وليس قتلاً قسرياً. فهو يتلقى إشارة إنهاء، ويوقف كل جلسة ضيف، ويحرر حجزه، ثم يخرج. وفي Linux تنتظر الوحدة 15 ثانية لميزانية تفكيك مدتها 10 ثوانٍ، ولا تصعّد أبداً إلى قتل لا يمكن اعتراضه، لأن البرنامج الخلفي إذا قُتل أثناء التفكيك يترك جهازاً افتراضياً مصغّراً وطبقة مساحة عمل بلا أي عملية باقية لتنظيفهما. ولذلك فالإيقاف المعلّق يظهر في systemctl --user status بدلاً من أن يمر بصمت، والتصعيد قرار بشري صريح.

لإزالة حزمة 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 الخدمة ويزيلها، مع سجلات التسجيل الخاصة بها ومدخل بدء التشغيل في الصينية. وعلى المنصتين، تُترك حالة الإقران عمداً: ~/.local/state/nessie-executor/ على Linux و%ProgramData%\Nessie Executor على Windows. فالإقران مفتاح للجهاز وتنقيحة سياسة موقّعة، وإلغاء تثبيت برنامج ليس طلباً لتدميرهما، وعند إعادة التثبيت يجدهما الجهاز في مكانهما. احذف المجلد يدوياً لنسيان الإقران، وألغِ المنفّذ في Nessie لإنهائه من الطرف الآخر.

تعرض صينية Windows والمرافق المكمّل لسطح المكتب كلاهما إجراء نسيان الإقران على هذا الجهاز كإجراء من الدرجة الأولى. فهو يوقف البرنامج الخلفي المحلي، ويزيل مفتاح الجهاز واختيار المجلد، ويحذف نهائياً نسخ المسودات المحلية بعد تأكيد أصلي واحد، بينما يترك المنفّذ على الخادم وسجل تدقيقه للمالك ليحتفظ بهما أو يلغيهما.

الأعطال الشائعة