Spettro مساعد برمجي صغير مفتوح المصدر، يتمحور حول سير عمل ظاهر عمدًا. يعمل داخل الطرفية، ويفصل التخطيط عن التنفيذ، ويعرض الوكيل النشط ووضع الصلاحيات، ويحتفظ بقدر كافٍ من الحالة لاستئناف المهمة لاحقًا. كُتب المشروع بلغة Go، ويستخدم واجهة طرفية مبنية على Bubble Tea، وصدر بترخيص GPL-3.0. كان مستودعه يعرض 37 نجمة وستة تفرعات عند التحقق، بينما كان أحدث إصدار موسوم هو v2.8.2 بتاريخ 4 أكتوبر 2026. لهذه الأرقام دلالة: نحن أمام مشروع مبكر يستحق التقييم، لا أمام أساس راسخ لعملية تطوير على مستوى شركة.

رسم توضيحي تحريري لوكيل برمجي في الطرفية مع إظهار الخطة والموافقة واستدعاءات الأدوات وحدود الصلاحيات.

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

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

ما الذي يضيفه Spettro فعلًا

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

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

التفاعل الافتراضي أكثر إجرائية عمدًا من صندوق محادثة واحد. يطلب Spettro من المستخدم الوثوق بمجلد مشروع، وربط مزود نموذج، واختيار نموذج، والبدء بوكيل التخطيط. يوثق الملف التمهيدي أوامر مثل /plan و/approve و/permission و/models و/skills و/compact و/resume. وتوضح هذه المفردات كيف يتوقع المطورون استخدام الأداة: الجلسة بيئة عمل، والخطة كائن قابل للمراجعة، ووضع الصلاحيات جزء من المهمة لا تفصيل خفي في التنفيذ.

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

الصلاحيات هي القصة الرئيسية

أقوى جوانب Spettro مفتوحة المصدر هي محاولته وضع حد الصلاحيات قريبًا من طبقة التنفيذ. يقول موقعه إن الأوامر المعزولة يمكن تقييدها باستخدام Seatbelt على macOS، وLandlock على Linux، وMandatory Integrity Control على Windows. كما يوثق أوضاعًا لنظام الملفات مثل off وworkspace-write وread-only، إلى جانب سياسات شبكة تشمل all وlocalhost وnone أو قائمة صريحة بالمنافذ.

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

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

لذلك ينبغي أن يكون الاختبار الأول مملًا عمدًا:

1. أنشئ مستودعًا مؤقتًا لا يحتوي على بيانات اعتماد.
2. شغّل Spettro في وضع القراءة فقط أو وضع السؤال أولًا.
3. اطلب خطة تصف تغييرًا صغيرًا فحسب.
4. افحص استدعاءات الأدوات والمسارات المقترحة.
5. وافق على تغيير له اختبار واضح وسهولة في التراجع عنه.
6. كرر الاختبار مع تعطيل الوصول إلى الشبكة.

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

بوابة الموافقة مفيدة، لكنها ليست بديلًا عن المراجعة

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

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

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

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

تعدد الوكلاء لا يعني تلقائيًا نتائج أفضل

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

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

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

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

مرونة المزود مفيدة، لكنها تنقل المسؤولية إلى المشغل

يوثق المشروع دعم Anthropic وواجهات API المتوافقة مع OpenAI ونقاط النهاية المحلية مثل LM Studio أو Ollama. كما يعلن توجيه المزودين، وفهرسًا للنماذج، ومستويات تفكير موحدة. هذا مفيد للتجربة: يستطيع المطور مقارنة نموذج مستضاف بآخر محلي، أو استخدام نموذج أرخص لاستكشاف المستودع، أو إبقاء قاعدة شيفرة حساسة على نقطة نهاية داخلية إذا كانت موثوقة بما يكفي.

الاستقلال عن المزود لا يساوي الاستقلال عن النموذج. تفسر النماذج المختلفة الأدوات، وحدود السياق، والمخرجات المنظمة، وتعليمات الموافقة بطرق مختلفة. قد تنتج مطالبة خطة دقيقة مع مزود، لكنها تعطي ملخصًا سطحيًا مع آخر. وقد يتعامل نموذج جيد مع تغيير قصير في Go، لكنه يواجه صعوبة مع مستودع ضخم متعدد المشاريع. يستطيع وقت التشغيل توحيد أمر مثل /thinking high، لكنه لا يستطيع جعل النماذج الأساسية متكافئة.

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

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

يجعل ACP من Spettro أكثر من مجرد أداة طرفية

يمكن لـ Spettro العمل كوكيل Agent Client Protocol عبر الإدخال والإخراج القياسيين. وتقول وثائق ACP الخاصة به إن المحررات مثل Zed وإضافات Neovim تستطيع تشغيله من واجهة وكيل أصلية، مع إعادة استخدام إعدادات المزود والنموذج والصلاحيات والبيان والعزل الموجودة. هذا اختيار تصميم عملي. فهو يتيح للمطور إبقاء سياسة التنفيذ في وقت تشغيل واحد، مع تغيير الواجهة الأمامية.

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

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

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

التحكم عن بعد وTelegram يستحقان حذرًا إضافيًا

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

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

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

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

ترخيص GPL-3.0 خيار ذو دلالة

يحدد مستودع Spettro المشروع بأنه مرخص بموجب GPL-3.0. وهذا يختلف جوهريًا عن التراخيص المتساهلة المستخدمة في كثير من مكتبات المطورين. يستطيع المطورون تشغيل البرنامج ودراسته وتعديله ومشاركته وفق شروط GPL، لكن على المؤسسات التي تخطط لدمجه في منتج موزع مملوك مراجعة قانونية لكيفية جمع الشيفرة وتوزيعها.

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

لا تستنتج من الترخيص أكثر مما يقول. لا يضمن GPL-3.0 الدعم، أو أزمنة الاستجابة الأمنية، أو بناءات قابلة لإعادة الإنتاج، أو واجهة برمجة مستقرة. تلك أسئلة تتعلق بإدارة المشروع وهندسة الإصدارات. عرضت أحدث صفحة إصدار النسخة v2.8.2، بينما يوثق الملف التمهيدي Go 1.26.1 أو أحدث للبناء من المصدر. وهذا يكفي لإثبات أن المشروع نشط وسريع التغير، لكنه لا يكفي لإثبات التوافق طويل الأمد.

سجل الإصدارات يقول «جرّبه»، لا «اعتمده معيارًا»

أحدث إصدار موسوم مدرج على GitHub، وهو v2.8.2، نُشر في 4 أكتوبر 2026. أضاف الإصدار السابق v2.8.1 شعارًا طرفيًا متحركًا، بينما نُشر v2.8.0 في 28 سبتمبر. يشير هذا الإيقاع الظاهر إلى مشروع يتحرك بسرعة عبر تغييرات الواجهة وسير العمل. قد يكون ذلك جيدًا للمتبني المبكر الذي يريد وصول التحسينات بسرعة. لكنه قد يزعج الفرق التي تحتاج إلى سلوك مستقر بين الأجهزة.

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

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

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

من ينبغي له تجربة Spettro الآن

يناسب Spettro مجموعات محددة.

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

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

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

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

خطة عملية للتقييم

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

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

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

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

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

ما ينبغي مراقبته لاحقًا

الاختبارات المهمة التالية لـ Spettro ليست قائمة أخرى من الأوامر، بل الاستقرار والأدلة. هل يستطيع المشروع الحفاظ على اتساق دلالات الصلاحيات مع إضافة ميزات؟ هل يمكنه جعل حالة الجلسة قابلة للفحص والنقل؟ هل يستطيع تكامل ACP الحفاظ على ضمانات الموافقة نفسها الموجودة في واجهة الطرفية؟ هل يستطيع المشرفون توثيق كيفية تخزين بيانات الاعتماد والمطالبات ومخرجات الأدوات والمرحّلات البعيدة؟ وهل يستطيع المساهم إعادة إنتاج إصدار من المصدر وفهم التغييرات التي تؤثر في سلوك الوكيل؟

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

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

المصادر