iron-edge 2.1.0 → 2.3.0

package/skills/blindar-sistema/procedures/sandbox-dado-falso.md

@@ -0,0 +1,63 @@
+# Sandbox: um ambiente de teste com dado falso
+
+> Procedimento do pacote **blindar-sistema**. Cria um lugar seguro para testar
+> segurança e bug sem tocar em dado de gente real. É a TRAVA da etapa avançada
+> (o teste ao vivo): nada que faça requisição real roda fora daqui.
+
+## Por que isto existe
+
+A auditoria white-box (ler o código) é segura em qualquer lugar, não toca dado. Mas
+na hora de PROVAR uma falha ao vivo, ou rodar a ferramenta externa opcional, você
+precisa de um sistema que seja seu e onde, se algo vazar, vazou nome de mentira.
+Testar contra produção com cliente real é o erro que este passo elimina.
+
+## A regra única e inegociável
+
+> Só teste contra um sistema **seu**, em ambiente de **teste**, com **dado
+> sintético** (inventado). Nunca produção. Nunca dado de gente real. Nunca site de
+> terceiro. O teste ao vivo faz requisição real, por isso ele só roda aqui.
+
+## Como montar (escolha um caminho)
+
+### Caminho A: ambiente local (qualquer stack, é o padrão)
+
+1. Suba o sistema na sua máquina (localhost) apontando para um banco local ou de
+   teste, nunca para o banco de produção.
+2. Confirme, olhando a variável de ambiente ativa, que o banco NÃO é o de produção
+   antes de qualquer teste.
+3. Popule com dado sintético (Caminho C abaixo).
+
+### Caminho B: branch de teste do banco (se usa Supabase, requer plano pago)
+
+O Supabase tem "branch": uma cópia isolada do banco para desenvolvimento, separada
+da produção. ⚠️ Branching é recurso de plano pago, não existe no Free. Se você está
+no Free, use o Caminho A (local).
+
+1. No painel do Supabase, crie uma branch de desenvolvimento do projeto.
+2. Aponte o ambiente de teste do app para a branch (as variáveis de ambiente da
+   branch, não as de produção).
+3. Popule a branch com dado sintético, nunca com um dump de produção com dado real.
+
+### Caminho C: semear dado sintético
+
+Crie de 10 a 30 registros inventados, cobrindo os papéis que você quer testar (ex.:
+dois usuários comuns para provar IDOR entre contas, um admin, alguns pedidos).
+
+- Nomes, e-mails e telefones inventados (ex.: `teste1@exemplo.com`). Nunca reaproveite
+  dado de cliente de verdade "só para o teste".
+- Se precisar de volume, um script de seed que gera os registros. Guarde o script
+  junto do projeto para recriar o sandbox quando quiser.
+
+## Checklist antes de testar ao vivo
+
+- [ ] O alvo é um sistema meu (não de terceiro)
+- [ ] O ambiente é de teste (local ou branch), confirmado pela variável de ambiente
+- [ ] O banco tem SÓ dado sintético, nenhum registro de cliente real
+- [ ] A URL do teste não é a de produção
+
+## Depois do teste
+
+- Não deixe o sandbox exposto na internet com um proxy ligado.
+- Se criou branch, apague ou pause quando terminar.
+- O achado que você provou aqui vale para produção: leve o CONSERTO para produção,
+  nunca o teste.

package/skills/blindar-sistema/procedures/secret-hygiene.md

@@ -0,0 +1,72 @@
+# Tirar segredo do histórico do Git
+
+> Procedimento do pacote **blindar-sistema**. Conduza uma etapa de cada vez,
+> esperando o usuário terminar. Só se aplica a um repositório do próprio usuário.
+
+## Por que apagar o arquivo NÃO basta
+
+Se uma chave foi commitada uma vez, ela continua no **histórico** do Git e em
+qualquer clone ou fork, mesmo depois de você apagar o arquivo. A auditoria (veja
+`kb/secrets.md`) aponta que vazou; tirar do passado é este procedimento.
+
+## Ordem certa (não inverta)
+
+### Passo 1: REVOGAR e gerar a chave de novo (PRIMEIRO, sempre)
+
+Este é o passo que realmente protege. Enquanto a chave antiga for válida, ela está
+comprometida, esteja no histórico ou não.
+
+- Chave da API de IA (Claude/OpenAI): no painel do provedor, revogue a chave e gere
+  outra.
+- Gateway de pagamento (Stripe/Mercado Pago): rotacione a chave secreta.
+- Banco (Supabase service_role, senha do Postgres): rotacione no painel.
+- Depois de gerar a nova, atualize a variável de ambiente no servidor e no deploy
+  (Vercel/host) ANTES de derrubar a antiga em produção, para não quebrar o sistema.
+
+Se você não consegue gerar outra chave, resolva isso antes: uma chave que você não
+sabe revogar é um risco em aberto.
+
+### Passo 2: Limpar o histórico
+
+Só depois de revogada, remova o arquivo do histórico inteiro.
+
+Ferramenta recomendada: `git filter-repo`.
+
+**Instalar (escolha o seu sistema):**
+- macOS: `brew install git-filter-repo`
+- Windows: `pip install git-filter-repo`  (precisa de Python)
+- Alternativa oficial: veja docs.github.com, "Removing sensitive data".
+
+**Rodar (uma linha por comando, vale para PowerShell também):**
+```
+git filter-repo --invert-paths --path CAMINHO/DO/ARQUIVO-COM-SEGREDO
+```
+Troque `CAMINHO/DO/ARQUIVO-COM-SEGREDO` pelo arquivo real (ex.: `.env`).
+
+**Se não der para instalar o filter-repo** (máquina travada, sem Python, sem brew):
+- Alternativa: **BFG Repo-Cleaner** (`bfg --delete-files .env`), precisa de Java.
+- Se nada disso rodar agora, NÃO trave: o Passo 1 (revogar) já neutralizou a chave.
+  Marque o Passo 2 como tarefa e siga o guia oficial do GitHub depois. Chave
+  revogada no histórico é um registro morto, não um risco ativo.
+
+### Passo 3: Subir e avisar
+
+⚠️ O `git filter-repo` **remove o remote `origin` de propósito** (é uma trava de
+segurança dele). Por isso um `git push` simples falha com "No configured push
+destination". Religue o remote e suba tudo (uma linha por comando):
+```
+git remote add origin URL-DO-SEU-REPOSITORIO
+git push origin --force --all
+git push origin --force --tags
+```
+O `--all` e o `--tags` garantem que o segredo saia de todos os branches e tags, não
+só do atual. Avise quem tem clone do repo para reclonar (o histórico mudou). Daí em
+diante: **segredo só em variável de ambiente**, nunca no código, nunca no front-end.
+
+## Checklist
+
+- [ ] Chave revogada e nova chave gerada
+- [ ] Variável de ambiente atualizada no servidor/deploy
+- [ ] Histórico limpo (ou tarefa marcada, se a ferramenta não rodou agora)
+- [ ] Remote religado e `push --force --all --tags` feito, quem tem clone avisado
+- [ ] `.env` no `.gitignore` para não repetir

package/skills/gate/SKILL.md

@@ -171,6 +171,12 @@ Mandar junto **só a lista de âncoras que vale** para o tipo da peça (seção
 - ★ **DADOS**: números conferidos contra a fonte crua (export, API, planilha); as somas fecham; períodos corretos.
 - **CLAREZA**: quem lê entende sem tradução?; a decisão recomendada está explícita?; zero jargão vazio.
 
+⚠️ **Relatório de tráfego pago: a medição desce ao nível do anúncio, sempre.** Auditar no nível da campanha deixa passar o defeito mais caro que existe nesse tipo de peça. Três regras, todas medidas contra a API, nunca contra o status:
+1. **Toda peça que o relatório diz estar "no ar" precisa ter impressão > 0 no período.** `effective_status = ACTIVE` não prova veiculação — em 02/09/2026, quatro anúncios ativados no dia anterior estavam todos ACTIVE e só dois entregavam. Campo ausente na resposta da API significa zero, não "não medido". **E a janela da consulta faz parte da medição:** `date_preset: "last_7d"` exclui o dia corrente e faz peça que está entregando aparecer com zero — foi assim que uma auditoria acusou como parado um anúncio com 63 impressões.
+2. **Toda data citada no relatório bate com a data vigente da ficha do cliente** (bloco "Informação que vence"). Data futura não é sinônimo de data válida: a vaga pode ter fechado antes.
+3. **O período do relatório é o mesmo em todos os blocos**, ou a divergência está escrita na peça. Mídia por ciclo de veiculação e negócio por mês-calendário podem conviver — desde que o leitor saiba.
+Caso que originou a regra: um painel de cliente afirmava "anúncios novos no ar" enquanto as quatro peças novas tinham R$ 0,00 e zero impressão, e R$ 918,59 do mês haviam sido gastos com a arte da data anterior. Três lentes aprovaram o texto; quem pegou foi a medição por anúncio.
+
 ### DOCUMENTO (PDF, proposta, contrato, apostila) — âncoras lista A
 - ★ **FATOS**: todo número, preço, nome, data e promessa conferido contra a fonte (contrato, sistema, memória do projeto).
 - **FORMA**: fundo e identidade corretos (do cliente, não de quem produziu); anti-vícios de IA (travessão, "não é X, é Y", negação dramática); ortografia; paginação (rodapé que vira página órfã).