Capivara — o dia em que o painel parou de mentir (e as seções mortas caíram)

⚡ O painel estava mentindo

Todo dashboard tem um pecado silencioso: mostrar como verde uma coisa que está morta.

No Capivara, eram dois pontos vermelhos que eu via há dias e empurrava com a barriga — a seção Stripe e a seção Portifolio Staging. Até que no dia 08/08 eu finalmente olhei com atenção:

• A seção Stripe apontava pra um Supabase decommissionado — DNS morto, 500 em tudo.
• A seção Portifolio Staging mostrava a URL staging.samuelmedeiros.vercel.app — que não existia mais (o staging foi removido há semanas).

O dashboard estava me mostrando ruído. E pior: cada olhada naquele painel era um pequeno voto de confiança em dados que não refletiam a realidade.

🧠 O problema real: dados mortos viram decisões erradas

Não era só estética. Um dashboard com seções mortas ensina o cérebro a ignorar o painel — e aí, quando algo importante de fato quebrar, você não percebe.

A regra que ficou depois dessa sessão é simples:

Se a fonte não existe mais, a seção não deve existir.

Duas linhas de commit resolveram:

b209043 feat(admin): remove secao Stripe (Supabase decommissionado — 500 DNS morto)
a856ff3 feat(dashboard): remove secao Portifolio Staging (staging removido — URL morta, dot vermelho)

Remover não é perder informação. É parar de pagar custo de atenção por algo que não entrega valor.

⚡ E o rate limit que bloqueava o IP errado

No mesmo dia, outro sintoma: requests legítimos do dashboard caindo com 429, mesmo com a API key correta.

O rate limit do Capivara usava o IP do request pra montar o bucket. O problema? Em produção atrás do Cloudflare, todos os requests vinham do mesmo IP do Tunnel — ou pior, o bucket era montado de um header que nem sempre existia.

A correção foi documentada e direta:

ae08d24 fix(ratelimit): CF-Connecting-IP p/ bucket real + API key 120/min

Usar o header CF-Connecting-IP — o IP real do cliente, que o Cloudflare injeta de forma confiável — em vez de tentar adivinhar a partir da conexão. E dar à API key um bucket próprio com 120 req/min, separado do rate limit por IP.

🧠 A lição em três pontos

1. Painel que mente é pior que painel nenhum — seções mortas treinam você a ignorar o dashboard inteiro.
2. Rate limit é sobre identidade — limitar por IP atrás de proxy é limitar o proxy, não o usuário. Use o header que o proxy garante (CF-Connecting-IP).
3. Limpeza é feature — remover 2 seções mortas deixou o dashboard mais honesto em 10 minutos do que qualquer feature nova deixaria em uma semana.

🛠️ Detalhes técnicos

Item	Antes	Depois
Seção Stripe	500 DNS morto (Supabase decommissionado)	Removida
Seção Portifolio Staging	URL morta	Removida
Rate limit por IP	Bucket de IP do Tunnel (errado)	CF-Connecting-IP (IP real)
Rate limit por API key	Mesmo bucket do IP	Bucket próprio, 120 req/min

O Capivara segue como o painel central do ecossistema — mas agora, quando ele diz que algo está verde, é porque está.