دليل القرار والاستخدام الأول لـ codeArbiter: إضافة حوكمة الكود عبر بوابات إلزامية إلى Claude Code وCodex CLI وPi

لمن هذا الأداة

• للمطورين والفرق الذين يعملون داخل Claude Code أو Codex CLI أو Pi ويريدون أن يمر كل تغيير بفحص إلزامي قبل أن يدخل قاعدة الكود: codeArbiter طبقة حوكمة (governance layer) مصممة لهذه المضيفين الثلاثة، وعنوان المستودع الرسمي يلخّص الدافع: «When you can't trust yourself with your code base, trust Arbiter.» (حين لا تثق بنفسك مع قاعدة كودك، ثق بـ Arbiter).
• بعد التمكين، كل نية تُعبَّر عنها للوكيل (agent) تُوجَّه إلى gated skill أو reviewer agent، ولا يُجرى أي commit قبل أن تكون جميع البوابات خضراء، وتمر القرارات عبر SMARTS، وسجل التدقيق append-only أي يقبل الإضافة فقط. يعمل على مستوى المستودع: موضوع الـ opt in هو مستودع بعينه. من يحتاج بوابات إلزامية قبل الـ commit وسجلات قرار قابلة للتتبع فهو الجمهور المستهدف بالضبط. ومعنى append-only أن سجل التدقيق يقبل الإضافة فقط، ولا يقبل الحذف أو التعديل.
• يناسب المستخدمين الحذرين الذين يفضلون النظر قبل التحرك: توضح الوثائق الرسمية أن الإضافة تبقى ساكنة بعد التثبيت ولا تفعل شيئًا تجاه مستودع ما قبل أن تُدرجه صراحةً عبر opt in؛ والنص الأصلي يقول «That silence is intentional.» (هذا الصمت مقصود). التثبيت بحد ذاته لا يغيّر فورًا السلوك القائم للمستودع.
• الحالات غير المناسبة: سير العمل التي لا تريد عملية ببوابات، ومهام تحليل الكود أو إعادة كتابته لمرة واحدة، والأجهزة التي لا يستوفي بيئتها متطلبات القسم التالي. لغات البرمجة وأنواع المشاريع التي يدعمها غير مذكورة في الوثائق الرسمية، وهذا مجهول يؤثر مباشرة في قرار اختياره من عدمه.
• دعم مضيفي وكلاء آخرين غير Claude Code وCodex CLI وPi غير مذكور في الأدلة، وهو مجهول.

أول تجربة في 3 دقائق

• المتطلبات المسبقة: Windows أو macOS أو Linux؛ والمطلوب رسميًا Pi 0.80.10 وNode.js 22.19 أو أحدث وPython 3 وGit، دون حساب أو بيانات نموذجية. إن نقص أيٌّ منها فأكمل البيئة أولًا ثم ثبّت.
• مكان التثبيت: مسار التثبيت الرسمي هو plugin marketplace الخاص بـ Claude Code. نفّذ في Claude Code الأمرين التاليين بالترتيب؛ الأول يضيف arbiterForge/codeArbiter كمصدر للـ marketplace، والثاني يثبّت من هذا المصدر الإضافة المسماة ca:

/plugin marketplace add arbiterForge/codeArbiter
/plugin install ca@codearbiter

• إشارة النجاح بعد التثبيت: تُحمَّل hooks وcommands وagents وتوصيلات statusline تلقائيًا، وتُحلّ جميع الأوامر تحت مساحة الأسماء /ca:؛ أي أنك لا تحتاج إلى توصيل يدوي بعد التثبيت، ومن المفترض أن تُتعرَّف على الأوامر التي تبدأ بالبادئة /ca:. تبقى الإضافة في هذه اللحظة ساكنة، وهذا سلوك متوقع لا يعني فشل التثبيت.
• نقطة التأكيد الجوهرية: لا يدخل المستودع سير الحوكمة إلا بعد opt in صريح له؛ اكتمال التثبيت لا يساوي بدء العمل. أمر الـ opt in المحدد لا يظهر في الوثائق الرسمية، وطريقة تنفيذ هذه الخطوة مجهولة؛ فلتكن تعليمات المستودع الرسمي هي المرجع، ولا تخمّن الأوامر من عندك.
• المهمة الأولى: بعد الـ opt in، عبّر للوكيل عن نية عادية لتحليل الكود أو تعديله، ثم راقب أمرين: هل تُوجَّه النية إلى gated skill أو reviewer agent؟ وهل يبقى كل شيء بلا commit قبل أن تخضر جميع البوابات؟ إن لم تُوجَّه النية، أو جرى commit وبعض البوابات ما تزال حمراء، فإن سير الحوكمة لا يعمل كما وُصف رسميًا. أما الأوامر المحددة الموجودة تحت /ca: فلم تُذكر في الأدلة، ولا يمكن نقلها نصًا.

حالات الاستخدام

• الحالة 1: تمكين commits ذات بوابات في مستودع شخصي. السيناريو: تريد أن يمر كل تغيير بفحص تلقائي قبل الـ commit. الطريقة: نفّذ أمرَي التثبيت أعلاه في Claude Code لتثبيت الإضافة ca، وتأكد من أن hooks وcommands وagents وstatusline حُمّلت تلقائيًا وأن أوامر /ca: تُحلّ، ثم أدرج المستودع عبر opt in، ثم عبّر للوكيل عن نية تغيير. المتوقع: تُوجَّه النية إلى gated skill أو reviewer agent، ولا يُجرى commit قبل خضورة جميع البوابات، وتُسجَّل القرارات عبر SMARTS، ويقبل سجل التدقيق الإضافة فقط. ولأن الإضافة ساكنة بعد التثبيت، فإن كل آثار هذه الحالة تبدأ من خطوة الـ opt in، وأمرا التثبيت بحد ذاتهما لا يطلقان أي إجراء حوكمة. ومن أراد أولًا رؤية شكل الأداة بعد التثبيت فقط، فيمكنه التوقف عند «تحميل تلقائي وحلّ أوامر /ca:» والملاحظة دون استعجال الـ opt in.
• الحالة 2: جعل قرارات التغيير لدى الفريق قابلة للتتبع. السيناريو: في العمل الجماعي تريد أن يبقى لكل قرار تغيير سند وأن التاريخ لا يُعاد كتابته. الطريقة: في مستودع أُدرج سابقًا عبر opt in، عبّر للوكيل عن نية تغيير وامشِ سير البوابات نفسه. المتوقع: تُسجَّل القرارات عبر SMARTS، وسجل التدقيق append-only، وما كُتب من سجلات لا تكتب فوقه العمليات اللاحقة. أما كيفية التفاعل مع SMARTS تحديدًا وأين تُشاهد السجلات فغير مذكور في الأدلة، والنطاق المؤكد ينتهي هنا.

حدود الاستخدام

• الآثار الجانبية ونقاط التأكيد: عند التثبيت تُحمَّل hooks وcommands وagents وتوصيلات statusline تلقائيًا، وهذا سلوك تصفه الوثائق الرسمية بأنه يقع مع التثبيت. الحالة الابتدائية سكون؛ وقبل إدراج مستودع ما عبر opt in صريح لا تفعل الإضافة تجاهه شيئًا، ومن ثَمّ لا يمكن التحقق من أثر الحوكمة دون opt in. وهل يمكن التراجع عن الـ opt in وكيف، غير مذكور في الأدلة وهو مجهول؛ فمن يهمّه كلفة التراجع فليتأكد من هذه النقطة قبل الـ opt in.
• الملفات والأوامر والشبكة: هل يقرأ ملفاتك ويكتب فيها، وما الأوامر التي ينفذها، وهل يصل إلى الشبكة — لا شيء من هذا مذكور في الوثائق الرسمية وهو مجهول؛ ولا يجوز الاستدلال بهذا الصمت على غياب أي سلوك من هذا النوع. قبل ربطه بمستودع مهم، جرّب الـ opt in في بيئة يمكن التخلي عنها.
• فروق المنصات والعملاء: مسار التثبيت الوحيد المذكور حرفيًا في الوثائق الرسمية هو plugin marketplace الخاص بـ Claude Code؛ أما Codex CLI وPi فقد ذُكرا كمضيفين تخدمهما طبقة الحوكمة، لكن طريقة تثبيتهما عليهما غير مذكورة في الوثائق الرسمية، وهو مجهول.
• المعلومات الجوهرية غير المؤكدة بعد: أمر الـ opt in المحدد، والقائمة الكاملة للأوامر تحت مساحة الأسماء /ca:، وكيفية التفاعل مع SMARTS، ولغات البرمجة وأنواع المشاريع المدعومة، والدعم خارج Windows وmacOS وLinux، وطريقة إزالة التثبيت أو التعطيل المؤقت — لا شيء منها ورد في الأدلة. قبل التبني، تحقق من كل بند في المستودع الرسمي.