تأطير مهمة لوكيل برمجي

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

المشكلة ليست في طول الموجِّه (prompt)، بل في غياب شرط النجاح فيه. الوكيل يتجه نحو إشارة معيّنة؛ فإذا لم تمنحه أي إشارة، عاد إلى «إنتاج شيء يشبه ما طُلب»، وهذه أسوأ النتائج: مقنعة بما يكفي ألّا تُرفض من النظرة الأولى، وعشوائية بما يكفي ألّا يُعتمد عليها. تأطير المهمة يعني تقديم ثلاثة أشياء: حالة نهائية يمكن ملاحظتها، وطريقة ملاحظتها، وحدود ما يُسمح بلمسه. أما الباقي، من نبرة وتهذيب وعبارات «من فضلك»، فلا أثر قابلًا للقياس له.

هدف قابل للتحقق، لا مجرد اتجاه

قارن بين صياغتين للطلب نفسه.

ما يفشل:

حسّن معالجة الأخطاء في وحدة الدفع.

ما ينجح:

في src/paiement/client.py، تترك الدالة capturer() الاستثناءات
httpx.TimeoutException تمرّ كما هي، مما يؤدي إلى خطأ 500 لدى
المستدعي.

الحالة النهائية المطلوبة:
- تلتقط capturer() الاستثناء httpx.TimeoutException وتُطلق PaiementIndisponible
  (المعرَّف أصلًا في src/paiement/erreurs.py)، مع الاحتفاظ بالاستثناء
  الأصلي بوصفه السبب.
- لا يُلتقط أي نوع آخر من الاستثناءات.
- اختبار في tests/test_client.py يحاكي انتهاء المهلة ويتحقق من النوع المُطلَق
  ومن وجود السبب.

القيود: لا تبعية جديدة، ولا منطق لإعادة المحاولة، ولا لمس للدوال الأخرى في الملف.