الخلاصة

  • يطلب مستودع Hackathon العام التابع لـLACNIC من الوكيل قراءة ai-harness مشتركة، وتحديثها في الوضع النشط قبل جلسة تغيّر حالة المشروع. غير أن شجرة Git لا تسجل تلك الحزمة إلا كرابط رمزي من 13 بايت إلى ../ai-harness.
  • يحدد التزام Hackathon ملف الدخول المحلي والمسار النسبي، لكنه لا يحدد عنوان المستودع الشقيق أو التزامه غير القابل للتغيير أو بصمة محتواه. إيصال للتعليمات الخارجية يسد هذه الفجوة من دون الادعاء بوقوع حادث أو استخدام إنتاجي أو نتيجة خاطئة.

قد تحمل ثلاثة عشر بايت سلطة تشغيلية أكبر من وثيقة طويلة. في الشجرة الحالية لمستودع LACNIC/hackathon يظهر المسار ai-harness بالنمط 120000، وهو تمثيل Git للرابط الرمزي. وعند فك محتوى الـblob المرتبط به لا نجد سوى ../ai-harness.

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

السؤال إذن ليس ما إذا كان الرابط الرمزي فكرة جيدة أو سيئة. السؤال هو: ما هو الإصدار الدقيق للسلطة الموجودة في الطرف الآخر عند تنفيذ جلسة بعينها؟ يستطيع التزام Hackathon إثبات نسخة AGENTS.md المحلية، ونمط الرابط وحجمه ووجهته النسبية. لكنه لا يستطيع وحده إثبات المستودع أو الالتزام الذي كان يشغل المجلد الشقيق حين قرأ الوكيل السطر الأول أو شغّل أداة التحديث أو اجتاز الفحص المسبق.

والمجلد الخارجي ليس مرجعاً اختيارياً. ينص AGENTS.md الصادر في سبتمبر على أن يقرأ الوكيل، قبل أي أمر، السطر الأول فقط من ai-harness/AGENTS.md ثم يطبق AI_HARNESS_MODE. في وضع maintenance لا يجوز تحديث الحزمة أو مزامنتها أو تشغيلها. وفي وضع active يجب تشغيل ./ai-harness/harness/framework/update-framework.sh، ثم قراءة الخريطة الكاملة، ثم المرور عبر git-preflight قبل جلسة جديدة تُحدث تغييرات.

وهكذا يسهم checkout الشقيق في ثلاثة قرارات: ما القواعد السارية، وهل يحدث تحديث، وما الشروط التي تسمح بالتغيير. وقد تحمل بيئتان الالتزام نفسه من Hackathon ثم تقرآن وضعين أو أداتي تحديث أو فحصين مختلفين إذا اختلفت نسختا ../ai-harness. لا تثبت المصادر أن هذا الاختلاف وقع فعلاً. ما تثبته أضيق: بصمة مشروع Hackathon وحدها لا تعيد بناء حالة التعليمات كاملة.

من اعتماد يوليو إلى ضوابط سبتمبر

في 12 يوليو 2026 أضاف الالتزام 16c37db9fe6e1c1b0bc7260b744ee7595a10de67، تحت الوصف “chore: adopt shared ai-harness”، ملف الدخول المحلي والرابط النسبي وقوالب خاصة بالمشروع. وكانت التعليمات منذ ذلك الوقت تطلب تحديث الإطار المشترك بلا تفاعل قبل الجلسة الجديدة، ثم قراءة خريطة قواعده.

وفي 8 سبتمبر وسّع الالتزام a68504f87dd5226238bb65b62b89d40419ed7c1f ذلك العقد. عرّف الوضعين، وضيّق القراءة والكتابة في maintenance، وشرح أن الفحص المسبق يتطلب checkout معيارياً ونظيفاً. ودُمج التغيير في الالتزام 6f9f60846acb30d4dcbf3969908743671c4a2921.

تربط شجرة الدمج AGENTS.md بالـblob 34e8fb06a0d71b939283dea4d77381ff029ad981. كما تربط ai-harness بالـblob 2244dfc17eaa1d54869e0bb3ff01ff258c6b0a0e ذي النمط الرمزي والحجم 13. وهذه هويات دقيقة للأجسام المحفوظة داخل مستودع Hackathon. لكن الجسم الثاني لا يشير إلى التزام في مستودع آخر؛ إنه يثبت المسار النسبي فقط.

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

التحديث المستمر لا يلغي إمكان إعادة البناء

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

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

تقدم ممارسة provenance في البرمجيات تشبيهاً محدوداً، لا التزاماً مفروضاً على LACNIC. تصف SLSA 1.2 المنشأ بأنه معلومات قابلة للتحقق تتبع الأثر عبر الأجزاء المتحركة في سلسلة معقدة حتى مكان إنتاجه وزمانه وكيفيته. قواعد الوكلاء ليست تلقائياً أثراً برمجياً مبنياً، ولا تقول LACNIC إنها تطبق SLSA هنا. لكن المبدأ المفيد بسيط: عندما تتحرك التبعية، تُحفظ هويتها المحلولة مع النتيجة.

إيصال أقصر من مجموعة القواعد

يمكن أن يكون الإيصال صغيراً جداً. يسجل التزام Hackathon وblob الرابط، وعنوان المستودع الشقيق والتزامه الثابت، وقيمة AI_HARNESS_MODE التي قُرئت، ونسخة الحزمة قبل update-framework.sh وبعدها، ونسخة git-preflight ونتيجته، وهوية checkout المعياري وworktree، والوقت، وهوية الشخص أو الأتمتة التي بدأت الجلسة.

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

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

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

المصادر