دمج الوكيل في العمل الجماعي

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

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

ملف الاتفاقيات أصل مشترك للفريق

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

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

## ما يفعله هذا المشروع بطريقة مختلفة

- ترث الاستثناءات الخاصة بالمجال من `ErreurMetier`، ولا ترث أبدًا من `Exception` مباشرة.
  يحوّلها المعالج العام إلى استجابات HTTP؛ أما الاستثناء المجرّد
  فينتج خطأ 500 وتنبيهًا إلى المناوب.
- لا يجوز أي استدعاء شبكي داخل دالة خدمة: تمر الاستدعاءات عبر
  العملاء الموجودين في `infra/clients/`، وهم من يتولون المهل وإعادة المحاولة.
- الترحيلات غير قابلة للتراجع في الإنتاج. كل عمود يُضاف يكون
  قابلًا للقيمة الفارغة عند الإنشاء، ثم تملؤه معالجة منفصلة، ثم يُقيَّد
  في ترحيل لاحق.

## ما يجب عدم فعله

- لا تعدّل `schema/legacy_*.py`: هذه الجداول يكتبها
  نظام خارجي لا نتحكم فيه.
- لا تضف اعتمادية (dependency) دون نقاش: زمن بناء
  الصورة بلغ أصلًا أقصى حدّ مقبول.