wizz-method 1.8.0 → 1.10.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "wizz-method",
-  "version": "1.8.0",
+  "version": "1.10.0",
   "description": "Wizz Method — método de agência orientado por IA em PT-BR (fork independente do BMad Method)",
   "keywords": [
     "agile",

package/skills-registry.yaml

@@ -285,6 +285,8 @@ areas:
         when: "Montar A/B test / experimento de conversão."
       - id: analytics-tracking
         when: "Setar/auditar tracking e medição (GA4, GTM, eventos, UTM, atribuição)."
+      - id: site-launch-kit
+        when: "Site pronto ou quase pronto pra ir ao ar: revisão de pré-lançamento em 15 rodadas corretivas (CTA acima da dobra, barra fixa mobile, tempo de resposta, prova social real, FAQ+FAQPage, imagens reais, endereço, titles, Open Graph, breadcrumbs, alt text, schema local, robots/sitemap, LGPD, medição), com regra anti-invenção e PENDÊNCIAS. Gatilhos: 'vamos subir o site', 'checklist de lançamento', 'revisa antes do deploy', pré-go-live, ou um item isolado (og:image, FAQ com schema, robots.txt). Roda DEPOIS do site construído, ANTES do deploy."
     mcps:
       - id: scrapling
         when: "Scraping/crawl web para pesquisa de mercado, prospecção de leads e inteligência competitiva. Bypass anti-bot (Cloudflare), parsing adaptativo, spider concorrente. Requer: pip install 'scrapling[ai]' && scrapling install."

package/src/modules/wizz/agents/wizz-qa/SKILL.md

@@ -25,6 +25,7 @@ Você é o QA do Wizz. Entra **depois do wizz-agent-dev**: pega o código pronto
 - Gerar testes E2E e rodar fluxos críticos → `wizz-qa-generate-e2e-tests`; para browser real, use `agent-browser`.
 - Revisão adversarial caçando bugs (assumir que tem bug) → `adversarial-reviewer`.
 - Revisão de qualidade/segurança do código → `wizz-code-review`; para segurança web profunda, use `web-security`.
+- Auditoria/pentest de segurança do app inteiro (varredura adversarial antes de release, "auditar segurança") → `security-audit-pentest` (caça com prova de exploração + plano priorizado). Para corrigir uma falha isolada, use `web-security`/`auth-and-secrets`.
 - Conferir se entrega o que foi pedido → comparo com o que o wizz-pm/usuário definiu.
 
 Sempre reporte achados em ordem de gravidade (crítico primeiro). Se passou em tudo, diga claramente que está pronto pra entregar.

package/src/skills-lib/auth-and-secrets/SKILL.md

@@ -42,6 +42,7 @@ Evita que um atacante descubra quais e-mails existem na base (login, signup, res
 - Auth gerenciada pelo Clerk: nunca reimplementar flows de auth manualmente
 - Toda rota protegida, Server Action e route handler chama `auth()` do Clerk no servidor. Nunca confiar em estado de sessão vindo do cliente
 - Clerk webhook (`svix`) verificado por assinatura antes de processar: não confiar no body sem verificar
+- Webhook de pagamento/provedor externo: além de verificar a assinatura, **nunca confie em valor de status, dinheiro ou permissão que veio no corpo**. Confirme com o provedor de origem (ex: re-buscar a sessão no Stripe pelo id) antes de liberar acesso ou creditar saldo. Assinatura válida só prova que o evento veio do provedor, não que o payload não foi remontado num replay.
 - Supabase RLS: toda tabela de domínio deve ter RLS ativo; queries devem filtrar por `workspace_id`/`user_id`
 - `SUPABASE_SERVICE_ROLE_KEY` bypassa RLS: só em server-side (API routes, jobs), nunca exposta no frontend
 - `NEXT_PUBLIC_*` = seguro expor no cliente; tudo sem `NEXT_PUBLIC_` = server-only

package/src/skills-lib/security-audit-pentest/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: security-audit-pentest
+description: >
+  Auditoria de segurança adversarial em 5 estágios com saída padronizada (tabela markdown, régua de corte,
+  payload concreto por achado). Use quando o pedido for auditar/pentestar um app inteiro, revisar segurança
+  antes de release, "auditoria de segurança", "pentest", "encontrar vulnerabilidades", ou rodar uma varredura
+  completa de mass assignment, IDOR/RLS, injeção, rate limit/abuso por volume, e vazamento por resposta.
+  Diferente de web-security/auth-and-secrets (que corrigem): esta CAÇA, com prova de exploração, e no fim funde
+  os achados num plano priorizado ("as três de hoje"). Para corrigir uma falha isolada, use as skills
+  web-security e auth-and-secrets.
+---
+
+# Security Audit (Pentest adversarial)
+
+Cinco estágios independentes de caça a vulnerabilidade, cada um com **prova de exploração concreta** e **régua de corte** (sem payload real, a linha não entra). No fim, um sexto passo funde os cinco relatórios num plano único priorizado.
+
+Cada estágio é um agente com um prompt fechado em `references/`. Rode-os em paralelo (subagentes), um por estágio, e depois o passo de fusão sobre os cinco resultados.
+
+## Premissa comum a todos os estágios
+
+Validação no cliente não conta. O atacante fala direto com a API. Considere apenas verificação no servidor. O campo "Como se explora" de cada achado tem que conter o **payload concreto** que o atacante enviaria, não a categoria da vulnerabilidade. "Poderia ser melhor" e "considere adicionar" não são achados. Prefira dez linhas reais a cinquenta de boa prática. Sem achado que passe na régua num estágio: responda só `NENHUM ACHADO NESTA ETAPA`.
+
+Formato de saída de cada estágio, tabela markdown, sem texto antes ou depois:
+
+```
+| # | Risco | Onde (arquivo:linha) | Como se explora | O que impede | Gravidade |
+```
+
+Gravidade: CRÍTICO, ALTO, MÉDIO.
+
+## Os 5 estágios (rodar em paralelo)
+
+| Estágio | Caça | Prompt |
+|---|------|--------|
+| 1 | **Validação de entrada** — mass assignment (prioridade máxima), injeção SQL/NoSQL/shell, renderização insegura, schema ausente / texto sem limite | `references/stage-1-validacao-entrada.md` |
+| 2 | **Falha de autorização** — 3 camadas: app (identidade do cliente vs token; posse na query), banco (RLS, policy permissiva `USING(true)`, tabela nova sem policy), máquina (webhook sem assinatura, confia em status/dinheiro do body) | `references/stage-2-autorizacao.md` |
+| 3 | **Abuso por volume** — rate limit em auth (por IP **e** por conta), custo por chamada (IA/SMS/e-mail × 10k), extração por paginação, origem do IP atrás de proxy/CDN | `references/stage-3-abuso-volume.md` |
+| 4 | **Vazamento por resposta** — detalhe técnico em prod, divergência na auth (mensagem/status/tempo), existência de recurso (404 vs 403), secret em log | `references/stage-4-vazamento-resposta.md` |
+| 5 | **Fusão** — funde os 4 relatórios: dedup por origem cruzada, ordena por esforço÷gravidade, identifica cadeias, fecha com "as três de hoje" | `references/stage-5-fusao-plano.md` |
+
+> Estágios 1-4 são de caça e independentes. O estágio 5 recebe a saída dos outros quatro. (O prompt original tinha o estágio de validação duplicado; aqui é um só.)
+
+## Como rodar
+
+1. Dispare os estágios 1-4 como quatro subagentes em paralelo, cada um carregando seu prompt de `references/`.
+2. Colete as quatro tabelas.
+3. Rode o estágio 5 (fusão) colando as quatro tabelas onde o prompt indica.
+4. Entregue o plano de fusão como resultado. As tabelas por estágio ficam como anexo.
+
+## Relação com as outras skills de segurança
+
+- **Esta skill CAÇA** (encontra + prova). Saída = lista de achados + plano.
+- **`web-security` e `auth-and-secrets` CORRIGEM** (padrão certo + exemplo de código). Ao fechar um achado desta auditoria, abra a skill de correção correspondente citada na coluna "O que impede".

package/src/skills-lib/security-audit-pentest/references/stage-1-validacao-entrada.md

@@ -0,0 +1,50 @@
+# Estágio 1 — Validação de entrada
+
+Você é um analista de validação de entrada.
+
+Premissa: validação no cliente não conta. Um atacante fala
+direto com a API. Considere apenas verificação no servidor.
+
+Procure, nesta ordem de prioridade:
+
+1. ATRIBUIÇÃO EM MASSA — prioridade máxima
+   Todo endpoint de escrita onde o corpo da requisição é
+   repassado inteiro para o banco (spread do objeto, update
+   com o payload completo, create com todos os campos).
+   Para cada um: liste os campos da tabela que um atacante
+   conseguiria setar e que não estão no formulário.
+   Dê atenção especial a campos de papel, permissão, plano,
+   saldo, status de pagamento e id de dono.
+
+2. INJEÇÃO
+   Consultas montadas por concatenação ou template string
+   com valor vindo do usuário. Inclua SQL, NoSQL e comandos
+   de shell.
+
+3. RENDERIZAÇÃO INSEGURA
+   Conteúdo de usuário chegando em innerHTML,
+   dangerouslySetInnerHTML, v-html ou equivalente
+   sem sanitização no caminho.
+
+4. SCHEMA AUSENTE
+   Endpoints sem validação de tipo, formato ou tamanho.
+   Sinalize campos de texto sem limite máximo — são vetor
+   de exaustão de recurso.
+
+Para cada achado, o campo "Como se explora" deve conter
+o payload concreto que um atacante enviaria, não a categoria
+da vulnerabilidade.
+
+Formato de saída — tabela markdown, sem texto antes ou depois:
+
+| # | Risco | Onde (arquivo:linha) | Como se explora | O que impede | Gravidade |
+
+Gravidade: CRÍTICO, ALTO, MÉDIO.
+
+REGRA DE CORTE: se você não conseguir preencher "Como se explora"
+com uma ação concreta e específica, NÃO inclua a linha.
+"Poderia ser melhor" não é achado. "Considere adicionar" não é achado.
+Prefiro dez linhas reais a cinquenta linhas de boa prática.
+
+Se não houver nenhum achado que passe nessa régua, responda
+apenas: NENHUM ACHADO NESTA ETAPA.

package/src/skills-lib/security-audit-pentest/references/stage-2-autorizacao.md

@@ -0,0 +1,61 @@
+# Estágio 2 — Falha de autorização
+
+Você é um pentester especializado em falha de autorização.
+
+Distinção que governa toda essa análise:
+AUTENTICAÇÃO responde "quem é você". AUTORIZAÇÃO responde
+"você pode acessar ISSO". Estar logado não é permissão.
+
+Analise as três camadas.
+
+CAMADA 1 — APLICAÇÃO
+Para cada endpoint que lê ou escreve um recurso pertencente
+a um usuário, responda:
+  a) De onde vem a identidade de QUEM está pedindo?
+     Do token/sessão no servidor, ou de algo enviado pelo cliente
+     (body, query, header, param)?
+  b) A consulta ao banco amarra o id do recurso E o dono
+     na mesma condição?
+Marque CRÍTICO todo lugar onde um user_id, org_id, tenant_id
+ou equivalente é lido do que o cliente enviou e usado para
+determinar propriedade.
+
+CAMADA 2 — BANCO
+Leia os arquivos de migration, schema e policy.
+  a) Liste as tabelas e diga, para cada uma, se há RLS
+     habilitada nos arquivos versionados.
+  b) Marque CRÍTICO toda policy permissiva —
+     USING (true), WITH CHECK (true) ou equivalente.
+     Uma policy permissiva é PIOR que policy nenhuma,
+     porque o painel mostra a trava como ativa.
+  c) Sinalize qualquer tabela criada em migration recente
+     que não tenha policy correspondente.
+
+CAMADA 3 — MÁQUINA
+Para cada webhook e endpoint que recebe evento externo:
+  a) Há validação de assinatura ou token compartilhado?
+  b) O fluxo confia em valor de status, dinheiro ou permissão
+     vindo no corpo, sem confirmar com o provedor de origem?
+
+LIMITE DA SUA ANÁLISE — obrigatório:
+Você está lendo arquivos. RLS de verdade é estado do banco,
+não arquivo. Termine com uma seção "NÃO VERIFICÁVEL AQUI"
+listando tudo que precisa ser confirmado no banco ao vivo
+ou no painel do provedor. Não afirme que está seguro
+o que você não conseguiu ver.
+
+Formato de saída — tabela markdown, sem texto antes ou depois:
+
+| # | Risco | Onde (arquivo:linha) | Como se explora | O que impede | Gravidade |
+
+Gravidade: CRÍTICO, ALTO, MÉDIO.
+
+REGRA DE CORTE: se você não conseguir preencher "Como se explora"
+com uma ação concreta e específica, NÃO inclua a linha.
+"Poderia ser melhor" não é achado. "Considere adicionar" não é achado.
+Prefiro dez linhas reais a cinquenta linhas de boa prática.
+
+Se não houver nenhum achado que passe nessa régua, responda
+apenas: NENHUM ACHADO NESTA ETAPA.
+
+(Após a tabela, inclua a seção obrigatória "NÃO VERIFICÁVEL AQUI".)

package/src/skills-lib/security-audit-pentest/references/stage-3-abuso-volume.md

@@ -0,0 +1,49 @@
+# Estágio 3 — Abuso por volume
+
+Você é um analista de abuso por volume.
+
+Enumere TODA rota de entrada do sistema e classifique cada uma:
+TEM LIMITADOR / NÃO TEM LIMITADOR / NÃO DETERMINADO.
+
+Depois, marque as rotas nestas categorias:
+
+A) AUTENTICAÇÃO
+   Login, cadastro, recuperação de senha, verificação de código.
+   Sem limitador aqui significa força bruta e teste de
+   credenciais vazadas. Marque CRÍTICO.
+   Verifique também: o limitador conta por IP apenas, ou também
+   por conta alvo? Contagem só por IP é contornada distribuindo
+   o ataque.
+
+B) CUSTO POR CHAMADA
+   Rotas que gastam dinheiro real a cada execução:
+   chamada a modelo de linguagem, disparo de SMS, envio de e-mail,
+   processamento de arquivo, chamada a API paga de terceiro.
+   Para cada uma estime o custo unitário e o custo de
+   dez mil chamadas em loop.
+   Rota de agente de IA exposta sem limitador é CRÍTICO,
+   mesmo que não vaze nenhum dado.
+
+C) EXTRAÇÃO
+   Rotas que devolvem um registro por vez e que, chamadas em
+   sequência, entregam a base inteira.
+
+D) ORIGEM DO IP
+   Se o sistema roda atrás de proxy ou CDN, verifique de qual
+   cabeçalho o IP do cliente é lido. Se estiver lendo do
+   socket direto, o mundo inteiro conta como um IP só
+   e o limitador não existe na prática.
+
+Formato de saída — tabela markdown, sem texto antes ou depois:
+
+| # | Risco | Onde (arquivo:linha) | Como se explora | O que impede | Gravidade |
+
+Gravidade: CRÍTICO, ALTO, MÉDIO.
+
+REGRA DE CORTE: se você não conseguir preencher "Como se explora"
+com uma ação concreta e específica, NÃO inclua a linha.
+"Poderia ser melhor" não é achado. "Considere adicionar" não é achado.
+Prefiro dez linhas reais a cinquenta linhas de boa prática.
+
+Se não houver nenhum achado que passe nessa régua, responda
+apenas: NENHUM ACHADO NESTA ETAPA.

package/src/skills-lib/security-audit-pentest/references/stage-4-vazamento-resposta.md

@@ -0,0 +1,52 @@
+# Estágio 4 — Vazamento por resposta
+
+Você é um analista de vazamento por resposta.
+
+Premissa: toda resposta de erro é informação. Você está
+procurando o que o sistema conta a quem falhou.
+
+1. DETALHE TÉCNICO EM PRODUÇÃO
+   Stack trace, caminho de arquivo do servidor, nome e versão
+   de framework ou biblioteca, fragmento de consulta SQL,
+   nome de tabela ou coluna chegando na resposta ao cliente.
+   Confirme se existe separação real entre comportamento de
+   desenvolvimento e de produção, ou se é o mesmo caminho.
+
+2. DIVERGÊNCIA NA AUTENTICAÇÃO — prioridade máxima
+   Compare as respostas de: e-mail inexistente, e-mail existente
+   com senha errada, e conta bloqueada.
+   Divergem em mensagem? Em código de status? Em campo do corpo?
+   E divergem em TEMPO de resposta, porque o caminho do e-mail
+   existente executa a verificação de hash e o outro não?
+   Qualquer divergência transforma o login numa API de consulta
+   da base de clientes. Marque CRÍTICO.
+   O mesmo vale para cadastro ("e-mail já em uso") e recuperação
+   de senha.
+
+3. EXISTÊNCIA DE RECURSO
+   Quando o usuário pede um recurso que existe mas não é dele,
+   a resposta é diferente de quando o recurso não existe?
+   Se for, dá para mapear os ids válidos contando respostas.
+   O correto é responder "não encontrado" nos dois casos.
+
+4. LOG
+   Senha, token, cabeçalho de autorização, dado de cartão ou
+   documento sendo gravado em log.
+
+Para cada achado, o campo "Como se explora" deve conter
+o payload concreto que um atacante enviaria, não a categoria
+da vulnerabilidade.
+
+Formato de saída — tabela markdown, sem texto antes ou depois:
+
+| # | Risco | Onde (arquivo:linha) | Como se explora | O que impede | Gravidade |
+
+Gravidade: CRÍTICO, ALTO, MÉDIO.
+
+REGRA DE CORTE: se você não conseguir preencher "Como se explora"
+com uma ação concreta e específica, NÃO inclua a linha.
+"Poderia ser melhor" não é achado. "Considere adicionar" não é achado.
+Prefiro dez linhas reais a cinquenta linhas de boa prática.
+
+Se não houver nenhum achado que passe nessa régua, responda
+apenas: NENHUM ACHADO NESTA ETAPA.

package/src/skills-lib/security-audit-pentest/references/stage-5-fusao-plano.md

@@ -0,0 +1,27 @@
+# Estágio 5 — Fusão num plano único
+
+Vou colar abaixo os relatórios das quatro etapas de auditoria
+(validação de entrada, autorização, abuso por volume, vazamento
+por resposta).
+
+Funda os quatro num plano único de correção:
+
+1. Remova duplicatas. O mesmo problema aparece em mais de uma
+   etapa com nomes diferentes — por exemplo, uma chave vazada
+   aparece no MAPA e o efeito dela aparece no ACESSO.
+   Trate como um item só, citando as duas origens.
+
+2. Reordene por ESFORÇO DE CORREÇÃO dividido por GRAVIDADE.
+   Primeiro o que é crítico e se resolve em minutos.
+   Por último o que é médio e exige refatoração.
+
+3. Identifique CADEIAS: onde dois achados de gravidade média
+   se combinam num caminho crítico. Exemplo: enumeração de
+   usuário no login mais ausência de limitador na mesma rota
+   é uma cadeia, e vale mais que a soma das partes.
+
+4. Termine com "AS TRÊS DE HOJE": os três itens que devem ser
+   corrigidos antes de qualquer outra coisa, com a justificativa
+   em uma linha cada.
+
+[colar os 4 relatórios abaixo]

package/src/skills-lib/site-launch-kit/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: site-launch-kit
+description: "Checklist operacional de pré-lançamento de site em 15 rodadas corretivas: CTA principal acima da dobra, barra fixa mobile, promessa de tempo de resposta, prova social real, FAQ de decisão com FAQPage, imagens reais (não stock), endereço e como chegar, titles únicos, Open Graph, breadcrumbs, alt text, schema do negócio local, robots/sitemap, privacidade e termos LGPD, medição de eventos. Use quando o site estiver pronto ou quase pronto pra ir ao ar: 'vamos lançar', 'subir o site', 'revisar antes do deploy', 'checklist de lançamento', 'pré-go-live', 'o site tá pronto?', ou quando o pedido for um dos itens isolados (ex: 'arruma a prévia do WhatsApp', 'coloca FAQ com schema', 'confere robots.txt antes de subir'). Roda DEPOIS do site construído e ANTES do deploy. Regra central: nenhum dado de negócio inventado entra no site; o que faltar vira placeholder e entra em PENDÊNCIAS."
+---
+
+# Site Launch Kit · Revisão de Pré-Lançamento
+
+15 rodadas corretivas para rodar **depois que o site está construído e antes do deploy**. Cada rodada é um passe fechado: escopo único, saída padronizada, regra de corte própria. Não é skill de construção de página (isso é `premium-landing-ui-researcher` / `taste-skill`) nem de diagnóstico amplo de SEO (isso é `seo-audit`): aqui é conserto pontual pré-go-live.
+
+## Contrato comum (vale para TODAS as rodadas)
+
+1. **Detecte o terreno lendo o repositório**, não perguntando: framework, roteamento, onde moram as páginas públicas, onde ficam metadados e estilos.
+2. **Nenhum dado de negócio inventado entra no site**: preço, prazo, telefone, endereço, depoimento, nota, horário, CNPJ, domínio. O que faltar vira placeholder explícito (`{{ASSIM}}`) e entra em PENDÊNCIAS. Nunca preencha por estimativa.
+3. **Saída padronizada**: tabela markdown definida na rodada (sem texto antes dela) + seção **PENDÊNCIAS** no formato "o que falta · onde entra / de quem obter · como obter / o que destrava". Sem pendências, escreva "NENHUMA PENDÊNCIA".
+4. **Respeite a REGRA DE CORTE** de cada rodada: ela decide o empate entre "entregar bonito" e "entregar honesto". Honesto ganha sempre.
+5. **Rodadas condicionais** (07 endereço, 10 breadcrumbs): primeiro verifique se o item se aplica; se não, responda "ITEM NÃO SE APLICA" com uma linha de justificativa e pare.
+6. **Uma rodada por vez.** Não misture escopos no mesmo passe.
+
+## As 15 rodadas (ordem recomendada)
+
+| # | Rodada | Arquivo |
+|---|---|---|
+| 01 | CTA principal acima da dobra | [references/01-cta-principal.md](references/01-cta-principal.md) |
+| 02 | Barra de ação fixa no mobile | [references/02-barra-fixa-mobile.md](references/02-barra-fixa-mobile.md) |
+| 03 | Promessa de tempo de resposta | [references/03-tempo-de-resposta.md](references/03-tempo-de-resposta.md) |
+| 04 | Prova social real | [references/04-prova-social.md](references/04-prova-social.md) |
+| 05 | FAQ de decisão + FAQPage | [references/05-faq-decisao.md](references/05-faq-decisao.md) |
+| 06 | Imagens reais, não stock | [references/06-imagens-reais.md](references/06-imagens-reais.md) |
+| 07 | Endereço e como chegar | [references/07-endereco-como-chegar.md](references/07-endereco-como-chegar.md) |
+| 08 | Title próprio por página | [references/08-titles.md](references/08-titles.md) |
+| 09 | Prévia de link (Open Graph) | [references/09-open-graph.md](references/09-open-graph.md) |
+| 10 | Trilha de navegação (breadcrumbs) | [references/10-breadcrumbs.md](references/10-breadcrumbs.md) |
+| 11 | Texto alternativo correto | [references/11-alt-text.md](references/11-alt-text.md) |
+| 12 | Dados estruturados do negócio | [references/12-schema-local.md](references/12-schema-local.md) |
+| 13 | robots.txt e sitemap | [references/13-robots-sitemap.md](references/13-robots-sitemap.md) |
+| 14 | Privacidade e termos (LGPD) | [references/14-privacidade-termos.md](references/14-privacidade-termos.md) |
+| 15 | Medição de lançamento | [references/15-medicao.md](references/15-medicao.md) |
+
+**Dependências entre rodadas:** a 12 (schema) usa a mesma fonte de dados da 07 (endereço) e só inclui `aggregateRating` se a 04 (prova social) tiver deixado avaliação real no ar; a 02 (barra fixa) reaproveita o rótulo definido na 01 (CTA); a 15 (medição) marca a página de obrigado que a 03 (tempo de resposta) também toca. Rodando fora de ordem, leia antes a rodada da qual a atual depende.
+
+## Como executar
+
+- **Pedido genérico** ("revisa o site antes de subir", "checklist de lançamento"): rode na ordem 01→15, uma rodada por vez, entregando a tabela + PENDÊNCIAS de cada uma antes de abrir a próxima. Ao final, consolide todas as PENDÊNCIAS em uma lista única para o dono do site.
+- **Pedido pontual** ("arruma o og:image", "coloca FAQ"): rode só a rodada correspondente, com o mesmo contrato.
+- **Prioridade quando o tempo é curto:** 13 (robots/sitemap: o achado mais caro), 01 (CTA), 09 (Open Graph), 14 (LGPD), 15 (medição).
+
+## O que esta skill NÃO faz
+
+- Não redesenha layout, paleta ou conteúdo de seções (use `taste-redesign` / `impeccable`).
+- Não cria a página do zero (use `premium-landing-ui-researcher`).
+- Não faz diagnóstico amplo de ranking/tráfego (use `seo-audit`).
+- Não escreve copy de venda nova (use `copywriting`); aqui só se ajusta rótulo e microcopy de atrito com material que já existe no site.

package/src/skills-lib/site-launch-kit/references/01-cta-principal.md

@@ -0,0 +1,31 @@
+# Rodada 01 · CTA principal acima da dobra
+
+**Garante:** cada página pública pede UMA ação, visível sem rolar.
+**Rode quando:** antes de publicar ou revisar qualquer página pública do site.
+
+Você é um especialista em conversão trabalhando no repositório de um site que está prestes a ir ao ar. Sua única tarefa nesta rodada: fazer com que cada página pública peça UMA ação, e que essa ação esteja visível sem rolar.
+
+Antes de editar, detecte o terreno lendo o repositório, não pergunte: framework e roteamento (Next.js App Router ou Pages, React + Vite, Astro, HTML estático), onde moram as páginas públicas e qual é o componente de topo.
+
+NÃO redesenhe o layout. NÃO troque paleta, tipografia ou o conteúdo das seções. NÃO invente oferta, preço, prazo ou telefone.
+
+1. LEVANTE
+   Liste toda página pública (home, serviços, sobre, contato, landing). Para cada uma responda: qual é a ação principal, em que altura ela aparece pela primeira vez, e se está clicável sem rolagem em 390x670, 768x1024 e 1440x800. Vale como "abaixo da dobra" o CTA que exigir rolagem em QUALQUER um dos três tamanhos.
+
+2. CORRIJA, nesta ordem
+   a) Uma ação principal por página. Havendo duas com o mesmo peso visual, rebaixe a secundária para link de texto.
+   b) O CTA principal entra dentro dos primeiros 100vh: no herói, junto do título, sem depender de imagem carregar para aparecer.
+   c) O rótulo diz o que acontece depois do clique, na voz do visitante ("Pedir orçamento", "Falar no WhatsApp", "Ver preços"), nunca "Saiba mais", "Clique aqui" ou "Enviar".
+   d) Abaixo do botão, uma linha curta de redução de atrito usando informação QUE JÁ EXISTE no site (prazo de resposta, "sem compromisso", garantia). Não existindo, deixe a linha de fora e registre em PENDÊNCIAS.
+   e) O botão precisa ser alcançável por teclado, ter foco visível e área de toque de no mínimo 44x44 px no mobile.
+
+3. CONFIRA
+   Rode o build. Compare antes e depois em 390 e 1440 de largura: nenhuma página pode ter regressão de layout.
+
+Formato de saída: depois de aplicar as mudanças, responda com uma tabela markdown, sem texto antes:
+
+| Página | Ação principal | Onde estava | Onde está | Rótulo novo |
+
+Em seguida, a seção PENDÊNCIAS, uma linha por item, no formato "o que falta · onde entra · como obter". Sem pendências, escreva NENHUMA PENDÊNCIA.
+
+REGRA DE CORTE: nenhum texto inventado entra no site. É melhor a linha de atrito ficar faltando e aparecer em PENDÊNCIAS do que o site subir prometendo um prazo que ninguém combinou com o cliente.

package/src/skills-lib/site-launch-kit/references/02-barra-fixa-mobile.md

@@ -0,0 +1,35 @@
+# Rodada 02 · Barra de ação fixa no mobile
+
+**Garante:** barra fixa no rodapé do celular ligada à ação principal de cada página.
+**Rode quando:** depois da Rodada 01, ao preparar a experiência mobile para lançamento.
+
+Você é um desenvolvedor front-end focado em mobile. Sua única tarefa nesta rodada: criar uma barra de ação fixa no rodapé do celular, ligada à ação principal de cada página pública.
+
+Antes de editar, leia o repositório e descubra: framework e roteamento, qual é o CTA principal de cada página, se já existe algum elemento fixo (cookie banner, chat, botão de WhatsApp) e onde ficam os estilos globais.
+
+NÃO crie um segundo botão flutuante se já houver um widget de chat ou de WhatsApp fixo, nesse caso, integre os dois em uma barra só e diga o que fez. NÃO mostre a barra no desktop. NÃO invente número, link ou oferta.
+
+1. COMPONENTE
+   Uma barra fixa no rodapé, visível só abaixo de 768px, com:
+   - o rótulo da ação principal daquela página (o mesmo texto do CTA do herói, sem inventar variação);
+   - no máximo dois botões: o principal cheio e, se fizer sentido, um secundário discreto (ligar, WhatsApp, ver preços);
+   - altura enxuta, área de toque mínima de 44x44 px;
+   - padding-bottom com env(safe-area-inset-bottom), senão o iPhone come o botão com a barra de gestos;
+   - z-index abaixo de modal e de menu aberto, nunca por cima deles.
+
+2. REGRA DE EXIBIÇÃO
+   - Aparece depois que o herói sai da tela (IntersectionObserver no herói, não listener de scroll com número mágico).
+   - Some enquanto o formulário de contato ou o CTA final estiverem visíveis: dois botões idênticos na mesma tela viram ruído.
+   - Nunca cobre o rodapé, links legais ou o último campo do formulário. Se cobrir, some ou empurre o conteúdo com padding equivalente.
+   - Respeita prefers-reduced-motion: sem animação de entrada, só opacidade.
+
+3. RASTREIO
+   Se o site já tiver analytics instalado, dispare o mesmo evento do CTA principal, com um identificador que diferencie a origem (por exemplo, um parâmetro "sticky_mobile"). Se não tiver, não instale nada aqui e registre em PENDÊNCIAS.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Página | Ação da barra | Quando aparece | Quando some | Conflito resolvido |
+
+Em seguida, PENDÊNCIAS, uma linha por item no formato "o que falta · onde entra · como obter". Sem pendências, escreva NENHUMA PENDÊNCIA.
+
+REGRA DE CORTE: se em alguma página a barra atrapalharia mais do que ajuda (checkout, área logada, política de privacidade), não coloque, e explique em uma linha por que ficou de fora.

package/src/skills-lib/site-launch-kit/references/03-tempo-de-resposta.md

@@ -0,0 +1,33 @@
+# Rodada 03 · Promessa de tempo de resposta
+
+**Garante:** todo ponto de contato diz quanto tempo o visitante vai esperar.
+**Rode quando:** antes de publicar, após revisar CTAs e barra mobile.
+
+Você é um redator de conversão com acesso ao repositório deste site. Sua única tarefa nesta rodada: tornar explícito, em cada ponto de contato, quanto tempo o visitante vai esperar por uma resposta.
+
+Antes de escrever, leia o repositório: todo formulário, telefone, e-mail, link de WhatsApp e rodapé; e todo texto que já fale de prazo, horário de atendimento ou tempo de resposta.
+
+NÃO invente o prazo. NÃO escolha o número sozinho. Você levanta, aponta divergência e propõe, a decisão é de quem vai cumprir.
+
+1. INVENTÁRIO
+   Liste todo ponto de contato do site e o que cada um promete hoje (inclusive "entraremos em contato em breve", que não promete nada). Marque as divergências: prazos diferentes para o mesmo canal em páginas diferentes é o achado mais comum e o mais caro.
+
+2. PROPOSTA
+   Proponha UMA promessa por canal, no formato "respondemos em até X [horas úteis / dia útil]", junto do horário de atendimento e do que acontece fora dele. Baseie a proposta no que o site já diz. Se o site não disser nada em lugar nenhum, deixe o valor como placeholder explícito ({{PRAZO_RESPOSTA}}) e liste em PENDÊNCIAS, nunca escolha um número plausível por conta própria.
+
+3. IMPLEMENTAÇÃO
+   - Um componente ou parcial único, com o texto vindo de UM lugar só (constante, config ou CMS). Repetir a frase em oito arquivos garante que daqui a três meses eles não digam mais a mesma coisa.
+   - Aplique embaixo do botão de envio de cada formulário, ao lado do telefone e do WhatsApp, e no rodapé.
+   - Incluir o horário de atendimento e o comportamento fora dele ("fora desse horário, respondemos na manhã seguinte").
+   - Se o site tiver mensagem de sucesso ou página de obrigado, repita a mesma promessa lá, com o mesmo texto vindo da mesma fonte.
+
+4. CONFIRA
+   Faça uma busca no repositório por qualquer prazo remanescente escrito à mão. Nenhum pode sobreviver fora da fonte única.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Ponto de contato | Arquivo | O que prometia | O que promete agora |
+
+Em seguida, PENDÊNCIAS, uma linha por item no formato "o que falta · onde entra · como obter". Sem pendências, escreva NENHUMA PENDÊNCIA.
+
+REGRA DE CORTE: promessa que a empresa não consegue cumprir é pior do que promessa nenhuma, ela produz a primeira reclamação antes da primeira venda. Na dúvida entre dois prazos, proponha o mais folgado e explique.

package/src/skills-lib/site-launch-kit/references/04-prova-social.md

@@ -0,0 +1,33 @@
+# Rodada 04 · Prova social real
+
+**Garante:** só avaliação com origem verificável fica no ar.
+**Rode quando:** antes de publicar, depois de fechar CTAs, barra mobile e promessas de prazo.
+
+Você é o responsável pela prova social deste site, com acesso ao repositório. Sua única tarefa nesta rodada: deixar no ar apenas avaliação que existe de verdade.
+
+REGRA ZERO: você NÃO escreve depoimento, NÃO cria nome de cliente, NÃO inventa nota e NÃO gera foto de pessoa. Avaliação fabricada é propaganda enganosa, e no Brasil ela também é problema de Código de Defesa do Consumidor. Tudo que entrar aqui tem origem verificável.
+
+1. AUDITE O QUE JÁ ESTÁ NO AR
+   Procure no repositório todo depoimento, avaliação, estrela e contador de nota. Para cada um responda: veio de uma pessoa real? Tem nome completo ou primeiro nome com sobrenome abreviado, data e origem? Marque para REMOÇÃO tudo que for texto de template, avatar de banco de imagens, "Cliente Satisfeito", "Maria S." sem procedência, e nota agregada sem base ("4,9 de 5" sem dizer de quantas avaliações).
+
+2. PEÇA O MATERIAL REAL
+   Pergunte e espere a resposta:
+   - Existe perfil no Google Business, Instagram, Facebook ou marketplace com avaliação pública? Passe o link.
+   - Tem elogio em WhatsApp ou e-mail que possa ser citado? Print serve.
+   - Tem autorização para publicar nome e foto de cada pessoa?
+
+3. PUBLIQUE COM PROCEDÊNCIA
+   Cada avaliação vai ao ar com: texto na íntegra (sem edição que mude o sentido; corte de trecho marcado com reticências), nome como a pessoa autorizou, data, e a origem visível ("via Google", "via WhatsApp, publicado com autorização"). Sem foto real, use inicial ou monograma, nunca uma foto de banco de imagens ou gerada. Se houver perfil público com avaliações, prefira sempre um link para o perfil, ao lado das citações: verificável vale mais que bonito.
+
+4. QUANDO NÃO HOUVER NENHUMA
+   Não preencha. Implemente o componente, deixe a seção fora da página com um TODO, e entregue junto:
+   - o link direto de avaliação do Google Business (se houver perfil);
+   - uma mensagem curta e educada, pronta para o dono mandar aos últimos cinco clientes pedindo avaliação.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Avaliação | Origem | Data | Autorizada? | Ação (publicada/removida) |
+
+Em seguida, PENDÊNCIAS, uma linha por item no formato "o que falta · de quem obter · o que ele destrava".
+
+REGRA DE CORTE: três avaliações reais e datadas ganham de doze perfeitas. Se o resultado da auditoria for "nenhuma avaliação sobreviveu", entregue a seção vazia e diga isso com todas as letras.

package/src/skills-lib/site-launch-kit/references/05-faq-decisao.md

@@ -0,0 +1,39 @@
+# Rodada 05 · FAQ de decisão com dados estruturados
+
+**Garante:** cinco perguntas que resolvem dúvida de decisão, marcadas com FAQPage.
+**Rode quando:** por último, depois de CTAs, barra mobile, prazos de resposta e prova social estarem fechados.
+
+Você é responsável pelas objeções deste site, com acesso ao repositório. Sua única tarefa nesta rodada: publicar cinco perguntas frequentes que resolvam dúvida de decisão, e marcá-las com dados estruturados.
+
+Antes de escrever, leia o site inteiro e liste o que ele JÁ responde. Sua matéria-prima é essa; o que não estiver lá, você pergunta.
+
+NÃO invente preço, prazo, política de reembolso, área de cobertura ou condição comercial. Esses são exatamente os campos que o visitante vai cobrar depois.
+
+1. ESCOLHA AS CINCO
+   Priorize, nesta ordem, a pergunta que trava a decisão:
+   - quanto custa (ou como o preço é formado, se não houver tabela);
+   - quanto tempo demora;
+   - como funciona, passo a passo, do primeiro contato à entrega;
+   - para quem NÃO serve, ou o que não está incluso;
+   - o que acontece se der errado (garantia, suporte, revisão).
+   Adapte ao negócio, mas mantenha o critério: pergunta desconfortável entra, pergunta institucional ("quem somos?", "qual nossa missão?") fica de fora. Se o repositório tiver histórico de atendimento, chat ou e-mails, use a frequência real das perguntas em vez do seu palpite.
+
+2. ESCREVA AS RESPOSTAS
+   - Comece pela resposta, não pelo contexto. Primeira linha resolve.
+   - Duas a quatro frases. Resposta longa é resposta que ninguém lê.
+   - Sem "depende": diga de que depende e dê a faixa.
+   - Sem eufemismo: se o serviço não atende certa região ou porte, diga.
+   - Cada resposta que dependa de informação que você não tem vira placeholder explícito ({{PRAZO}}, {{FAIXA_DE_PRECO}}) e entra em PENDÊNCIAS. Nunca preencha por estimativa.
+
+3. IMPLEMENTE
+   - Acordeão acessível: <details>/<summary> ou botão com aria-expanded e aria-controls; navegável por teclado; a resposta precisa estar no HTML mesmo fechada, senão o Google não lê.
+   - JSON-LD de FAQPage com exatamente as mesmas perguntas e respostas que estão na tela. Divergir entre marcação e conteúdo visível é violação de diretriz e derruba o rich result.
+   - Ao final da seção, o CTA principal do site: quem chegou até aqui está decidindo.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| # | Pergunta | Fonte da resposta | Objeção que derruba |
+
+Em seguida, PENDÊNCIAS, uma linha por item no formato "o que falta · de quem obter · o que ele destrava". Liste também as perguntas que você considerou e descartou, com o motivo em três palavras.
+
+REGRA DE CORTE: cinco perguntas que doem valem mais que doze que enfeitam. Se só houver material honesto para três, publique três.

package/src/skills-lib/site-launch-kit/references/06-imagens-reais.md

@@ -0,0 +1,38 @@
+# Rodada 06 · Imagens reais, não stock
+
+**Garante:** nenhuma imagem fingindo ser gente da casa, com o lugar preparado para a foto real.
+**Rode quando:** o site tiver seção de equipe, escritório ou depoimento com foto.
+
+Você é o diretor de arte deste site, com acesso ao repositório. Sua única tarefa nesta rodada: tirar do ar toda imagem que finge ser gente da casa, e preparar o lugar da foto real.
+
+NÃO gere imagem de pessoa. NÃO substitua uma foto de banco de imagens por outra foto de banco de imagens. NÃO invente nome, cargo ou biografia.
+
+1. INVENTÁRIO
+   Percorra todas as imagens do projeto (pasta de assets, componentes, CMS, URLs externas) e classifique cada uma:
+   - REAL: é do negócio, do time, do produto ou do trabalho entregue;
+   - GENÉRICA: banco de imagens, ilustração de template, foto de modelo, escritório que não é o escritório;
+   - INDEFINIDA: não dá para saber sem perguntar.
+   Sinais de genérica: nome de arquivo com id numérico de banco de imagens, aperto de mão corporativo, operador de headset, sala de reunião com pessoas rindo de gráfico, foto perfeita em contexto de negócio pequeno.
+
+2. DECIDA POR IMAGEM
+   - Genérica em seção de equipe, escritório ou depoimento: remove.
+   - Genérica como fundo abstrato ou textura: pode ficar, se não afirmar nada sobre o negócio. Diga isso na tabela.
+   - Indefinida: pergunte antes de mexer.
+
+3. PREPARE O LUGAR DA FOTO REAL
+   - Componente de equipe com foto, nome e cargo (nunca só cargo).
+   - Proporção fixa com object-fit: cover, para foto de celular vertical não quebrar a grade quando chegar.
+   - Tamanho responsivo, carregamento preguiçoso fora da primeira tela e dimensões declaradas, para não pular layout.
+   - Texto alternativo descrevendo quem está na foto, não "foto da equipe".
+   - Enquanto a foto real não chegar: bloco fora da página com TODO. Um monograma com as iniciais é aceitável como provisório. Stock, não.
+
+4. ENTREGUE O BRIEFING DE FOTO
+   Cinco linhas, no tom de mensagem de WhatsApp, dizendo o que fotografar (equipe no local de trabalho, luz natural, sem pose corporativa), quantas fotos, orientação, resolução mínima e o que evitar.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Imagem | Onde aparece | Classificação | Ação | Substituta necessária |
+
+Em seguida, PENDÊNCIAS com as fotos que precisam ser tiradas, e o briefing de foto em bloco de citação.
+
+REGRA DE CORTE: seção de equipe vazia é melhor que seção de equipe falsa. Se a remoção esvaziar uma página inteira, diga isso e proponha o que colocar no lugar com material que já exista.

package/src/skills-lib/site-launch-kit/references/07-endereco-como-chegar.md

@@ -0,0 +1,37 @@
+# Rodada 07 · Endereço e como chegar
+
+**Garante:** qualquer pessoa descobre onde é e como chegar em menos de dez segundos.
+**Rode quando:** o negócio tiver endereço físico visível ao público.
+
+Você é um desenvolvedor front-end trabalhando no site de um negócio com endereço físico. Sua única tarefa nesta rodada: fazer com que qualquer pessoa descubra onde é e como chegar em menos de dez segundos.
+
+PRIMEIRO, VERIFIQUE SE ESTE ITEM SE APLICA. Procure endereço no repositório (rodapé, contato, schema, CMS). Se o negócio for totalmente remoto ou não tiver endereço público, PARE, responda "ITEM NÃO SE APLICA" com uma linha de justificativa, e não invente sede nenhuma.
+
+NÃO invente endereço, CEP, horário, telefone ou ponto de referência.
+
+1. INVENTÁRIO
+   Liste todo lugar onde o endereço aparece hoje e compare caractere a caractere: rodapé, página de contato, schema, textos soltos. Endereço divergente entre o site e o Google Business atrapalha a busca local além de confundir o cliente. Aponte cada divergência.
+
+2. BLOCO DE ENDEREÇO
+   Um componente único, alimentado por UMA fonte de dados, com:
+   - endereço completo em texto selecionável (para copiar e colar);
+   - botão "Como chegar" abrindo a rota no app de mapa do aparelho (link universal de mapa com o endereço codificado, não coordenadas escritas à mão);
+   - telefone e WhatsApp como link clicável (tel: e wa.me);
+   - horário de funcionamento;
+   - referências que só quem já foi conhece: estacionamento, andar, entrada, portaria, ponto de referência. Pergunte, não deduza.
+
+3. MAPA SEM DERRUBAR A PÁGINA
+   - Nada de iframe carregando junto com a página. Use imagem estática ou um bloco com aparência de mapa, e carregue o iframe só no clique ou quando ele entrar na tela.
+   - iframe com loading="lazy", title descritivo e dimensões declaradas.
+   - Se houver banner de cookies ou controle de consentimento, o mapa de terceiro respeita o consentimento antes de carregar.
+
+4. COERÊNCIA
+   Depois de implementar, o endereço precisa estar idêntico em todos os lugares e vir da mesma fonte. Anote para a rodada 12 (schema local) qual é essa fonte.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Onde | O que havia | O que há agora | Divergência corrigida |
+
+Em seguida, PENDÊNCIAS, uma linha por item no formato "o que falta · de quem obter · o que ele destrava".
+
+REGRA DE CORTE: ponto de referência inventado manda gente para o lugar errado. O que você não souber, pergunte; o que não for respondido, fica fora da página.

package/src/skills-lib/site-launch-kit/references/08-titles.md

@@ -0,0 +1,42 @@
+# Rodada 08 · Title próprio por página
+
+**Garante:** cada página com title próprio, descritivo e único.
+**Rode quando:** o site tiver mais de uma rota pública.
+
+Você é um especialista em SEO técnico com acesso ao repositório deste site. Sua única tarefa nesta rodada: garantir que cada página tenha um title próprio, descritivo e único.
+
+Antes de editar, detecte o terreno: framework e roteamento, onde os metadados são definidos (metadata do Next, react-helmet, tags no HTML, CMS) e se existe um title herdado do layout.
+
+NÃO mude conteúdo de página, H1 ou URL. Esta rodada é só de title.
+
+1. LEVANTE
+   Enumere TODA rota pública, inclusive páginas dinâmicas (produto, post, serviço) e as que só existem no build. Para cada uma, registre o title atual. Marque:
+   - vazio ou ausente;
+   - repetido em duas ou mais rotas;
+   - genérico ("Home", "Página inicial", "Untitled", nome do framework);
+   - herdado do layout sem sobrescrita;
+   - acima de 60 caracteres (será cortado no resultado de busca) ou abaixo de 20 (está desperdiçando espaço).
+
+2. ESCREVA OS NOVOS
+   Padrão: [o que a pessoa procura] + [diferencial ou lugar] + [marca].
+   - A palavra que a pessoa digita vem no começo, não no fim.
+   - Entre 50 e 60 caracteres, contando os separadores.
+   - Marca por último, só se couber; na home, a marca pode vir primeiro.
+   - Sem enfeite: "|", "-" ou "·" como separador, e só um deles.
+   - Sem repetir a mesma palavra três vezes.
+   - Negócio local: inclua a cidade quando ela fizer parte da busca.
+   Para rota dinâmica, escreva o template e mostre dois exemplos reais renderizados, com a contagem de caracteres de cada um.
+
+3. IMPLEMENTE
+   Um lugar só define o title de cada página, no mecanismo nativo do framework. Se houver título padrão de layout, ele fica apenas como rede de segurança, e toda página passa a sobrescrevê-lo. Página de obrigado, área logada e páginas de erro também recebem title próprio.
+
+4. CONFIRA
+   Rode o build e liste os titles renderizados. Nenhum repetido, nenhum vazio, nenhum acima de 60 caracteres.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Rota | Title antes | Title agora | Caracteres | Problema resolvido |
+
+Em seguida, PENDÊNCIAS com as páginas cujo título depende de decisão de posicionamento (qual palavra priorizar), uma linha por item.
+
+REGRA DE CORTE: título que promete o que a página não entrega gera clique e abandono, e isso é pior do que não ser clicado. Descreva a página que existe, não a que você gostaria que existisse.

package/src/skills-lib/site-launch-kit/references/09-open-graph.md

@@ -0,0 +1,35 @@
+# Rodada 09 · Prévia de link (Open Graph)
+
+**Garante:** o link rende prévia decente em qualquer lugar onde for colado.
+**Rode quando:** o site tiver domínio de produção definido.
+
+Você é um desenvolvedor front-end responsável pela primeira impressão deste site fora dele. Sua única tarefa nesta rodada: fazer o link render uma prévia decente em qualquer lugar onde for colado.
+
+Antes de editar, detecte: framework, onde os metadados são definidos, se existe domínio de produção configurado em algum lugar (variável de ambiente, config, sitemap) e se já há alguma imagem de marca no projeto.
+
+NÃO invente domínio. Sem domínio de produção definido, use a variável de ambiente correspondente e registre em PENDÊNCIAS.
+
+1. TAGS, EM TODA ROTA PÚBLICA
+   og:title, og:description, og:url (absoluta), og:type, og:site_name, og:locale (pt_BR), og:image, og:image:width, og:image:height, og:image:alt, twitter:card=summary_large_image, twitter:title, twitter:description, twitter:image.
+   Regras que decidem se funciona:
+   - toda URL absoluta, com protocolo e domínio. Caminho relativo é a causa número um de prévia vazia no WhatsApp;
+   - imagem em 1200x630, JPG ou PNG, abaixo de 1 MB (o WhatsApp corta acima disso; alguns clientes só carregam abaixo de 300 KB);
+   - sem WebP e sem SVG como og:image: nem toda plataforma lê;
+   - og:title pode diferir do title da página; aqui ele é chamada, não verbete.
+
+2. A IMAGEM
+   Se o framework suportar geração dinâmica de imagem de prévia, gere por rota, com o título da página, o nome da marca e o logotipo existente. Se não suportar, crie uma imagem estática por área do site (home, serviços, blog) com o logotipo e uma frase curta. Texto grande e centralizado, com margem de segurança: o WhatsApp corta as bordas em alguns formatos de conversa.
+
+3. FAVICON E ÍCONES
+   De passagem, confira favicon, apple-touch-icon e manifest. Ícone do framework padrão ainda no ar é o mesmo problema, no lugar mais visível.
+
+4. VALIDE
+   Liste as URLs de validação e o que conferir em cada uma (validador do Facebook, do LinkedIn, do X, e o teste real: colar o link em uma conversa consigo mesmo no WhatsApp). Explique como forçar a limpeza do cache de prévia depois de corrigir. As plataformas guardam a versão antiga por dias.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Rota | og:title | Imagem usada | Dimensão · peso | Absoluta? |
+
+Em seguida, PENDÊNCIAS e a lista de validadores.
+
+REGRA DE CORTE: prévia que você não testou colando o link em algum lugar não está pronta. Se não der para testar agora, diga explicitamente o que ficou por validar.

package/src/skills-lib/site-launch-kit/references/10-breadcrumbs.md

@@ -0,0 +1,35 @@
+# Rodada 10 · Trilha de navegação
+
+**Garante:** breadcrumbs nas páginas internas, com BreadcrumbList coerente.
+**Rode quando:** o site tiver hierarquia de páginas com mais de um nível.
+
+Você é um arquiteto de informação com acesso ao repositório deste site. Sua única tarefa nesta rodada: implementar a trilha de navegação nas páginas internas.
+
+PRIMEIRO, VERIFIQUE SE SE APLICA: se o site for de página única ou tiver todas as rotas no primeiro nível, responda "ITEM NÃO SE APLICA" com uma linha de justificativa e pare. Não invente hierarquia.
+
+NÃO mude URLs. NÃO reorganize o menu. A trilha reflete a hierarquia que existe; se ela estiver errada, você aponta, não conserta aqui.
+
+1. HIERARQUIA
+   Monte a árvore real do site a partir das rotas e da navegação. Aponte as divergências entre a URL e a navegação (a página que mora em /blog/post mas é alcançada pelo menu Serviços). A trilha precisa seguir UMA das duas, e a escolha tem que ser consciente.
+
+2. COMPONENTE
+   - <nav aria-label="Trilha de navegação"> com lista ordenada.
+   - O item atual não é link e leva aria-current="page".
+   - Início é sempre o primeiro item.
+   - No mobile, a trilha não pode quebrar em três linhas: encolha os níveis do meio (Início › … › Página atual) mantendo os extremos.
+   - Nome do nível igual ao que aparece na navegação, não ao slug.
+   - Sem separador dentro do texto do link: o separador é decorativo e fica em ::after, escondido de leitor de tela.
+
+3. DADOS ESTRUTURADOS
+   JSON-LD de BreadcrumbList por página, com position começando em 1, os mesmos nomes exibidos na tela e URLs absolutas. O último item pode ficar sem URL. A marcação precisa bater com o que está visível: divergir é violação de diretriz.
+
+4. ONDE ENTRA
+   Topo da página, abaixo do cabeçalho e acima do H1. Não entra na home. Página de erro e de obrigado também ficam de fora.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Rota | Trilha exibida | JSON-LD? | Divergência encontrada |
+
+Em seguida, a árvore do site em lista indentada, e PENDÊNCIAS com as divergências que precisam de decisão.
+
+REGRA DE CORTE: trilha que não corresponde à navegação real confunde mais do que ajuda. Se a hierarquia estiver ambígua, implemente o caminho mais usado, e liste a ambiguidade em vez de escondê-la.

package/src/skills-lib/site-launch-kit/references/11-alt-text.md

@@ -0,0 +1,40 @@
+# Rodada 11 · Texto alternativo correto
+
+**Garante:** cada imagem com o alt certo pela classificação.
+**Rode quando:** antes do lançamento, depois que as imagens finais do site estiverem no lugar.
+
+Você é um especialista em acessibilidade com acesso ao repositório deste site. Sua única tarefa nesta rodada: dar a cada imagem o texto alternativo correto.
+
+Antes de escrever, olhe as imagens de fato (abra os arquivos) e leia o contexto em que cada uma aparece. Alt escrito a partir do nome do arquivo é o mesmo problema com outra roupa.
+
+NÃO troque, corte ou gere imagens. NÃO escreva "imagem de" nem "foto de" no começo do alt: o leitor de tela já anuncia que é imagem.
+
+1. INVENTÁRIO E CLASSIFICAÇÃO
+   Liste toda imagem do projeto (tags img, componentes de imagem, imagem de fundo com conteúdo, SVG inline, ícones) e classifique:
+   - INFORMATIVA: acrescenta conteúdo;
+   - DECORATIVA: enfeite, textura, divisor;
+   - FUNCIONAL: dentro de link ou botão;
+   - COM TEXTO: tem palavras dentro da imagem;
+   - COMPLEXA: gráfico, tabela, infográfico.
+
+2. ESCREVA POR CLASSIFICAÇÃO
+   - INFORMATIVA: o que se vê e por que importa ali, em até 125 caracteres, sem repetir a legenda que já está no HTML.
+   - DECORATIVA: alt="" (vazio, presente). Atributo ausente faz o leitor ler o caminho do arquivo; alt vazio faz ele pular. São coisas diferentes.
+   - FUNCIONAL: descreve a AÇÃO ou o destino ("Ir para o WhatsApp"), não a figura ("logotipo do WhatsApp").
+   - COM TEXTO: transcreva o texto embutido, na íntegra.
+   - COMPLEXA: alt curto identificando o gráfico + descrição longa próxima, em texto de verdade na página.
+   Logotipo do próprio site no cabeçalho, quando é link para a home: "Página inicial · [nome da marca]".
+
+3. DE PASSAGEM, ANOTE (sem corrigir agora)
+   Imagem sem width e height declarados, imagem acima de 300 KB, formato antigo onde caberia WebP, e imagem de primeira tela com carregamento preguiçoso (que atrasa o conteúdo principal em vez de acelerar).
+
+4. CONFIRA
+   Nenhuma tag de imagem pode ficar sem atributo alt. Rode uma busca no repositório para provar isso e mostre o comando usado.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Arquivo/Componente | Onde aparece | Classificação | Alt agora |
+
+Em seguida, a seção OTIMIZAÇÃO PENDENTE com os problemas de carregamento anotados no passo 3, e PENDÊNCIAS com as imagens que você não conseguiu interpretar sem contexto do dono.
+
+REGRA DE CORTE: alt que descreve errado é pior que alt vazio, porque mente para quem não pode conferir. Sem entender a imagem, pergunte.

package/src/skills-lib/site-launch-kit/references/12-schema-local.md

@@ -0,0 +1,34 @@
+# Rodada 12 · Dados estruturados do negócio
+
+**Garante:** JSON-LD do negócio publicado, sem nenhum campo inventado.
+**Rode quando:** depois que endereço, horário e contato estiverem definitivos no site.
+
+Você é um especialista em SEO local com acesso ao repositório deste site. Sua única tarefa nesta rodada: publicar os dados estruturados do negócio.
+
+PRIMEIRO, DECIDA O TIPO. Leia o site e escolha o tipo mais específico que descreve o negócio (Restaurant, Dentist, HomeAndConstructionBusiness, ProfessionalService, Store...), caindo para LocalBusiness só quando nenhum couber. Negócio sem endereço físico mas com área de atendimento usa LocalBusiness com areaServed e sem address, ou Organization se não atender uma região definida. Diga qual escolheu e por quê.
+
+NÃO invente nenhum valor. Todo campo vem do que já está no site ou de resposta direta do dono. Campo sem fonte fica fora do JSON: objeto incompleto é aceitável, objeto inventado não.
+
+1. FONTE ÚNICA
+   Use a mesma fonte de dados do bloco de endereço (rodada 07). Se ela não existir, crie: um objeto de configuração de onde saem tanto o HTML visível quanto o JSON-LD. Duas cópias do endereço divergem em três meses, sempre.
+
+2. CAMPOS
+   name, image, url, telephone, address (com todos os subcampos, addressCountry BR), geo quando houver coordenada confiável, openingHoursSpecification, priceRange, areaServed, sameAs (perfis oficiais: Google Business, Instagram, LinkedIn), e o tipo escolhido.
+   Regras:
+   - o nome é o nome legal de fachada, igual ao do Google Business;
+   - horário no formato do schema, com feriado e horário especial se o site mencionar;
+   - aggregateRating e review SÓ se houver avaliação real no próprio site (ver rodada 04, prova social). Nota inventada aqui é violação de diretriz e motivo de penalidade. Na dúvida, deixe de fora.
+
+3. ONDE ENTRA
+   JSON-LD em script no head, na home e na página de contato. Uma entidade por página, sem repetir o mesmo negócio em três blocos. Se o site já tiver outro schema (Organization, WebSite), amarre-os por @id em vez de criar entidades soltas duplicadas.
+
+4. VALIDE
+   Confira campo a campo contra o que está visível na página. Liste as divergências entre site, schema e perfil do Google Business (se o link do perfil estiver disponível). Indique o validador de resultados ricos e o que esperar dele.
+
+Formato de saída: depois de aplicar, o JSON-LD final em bloco de código, seguido de uma tabela markdown:
+
+| Campo | Valor | Fonte | Confere com a página? |
+
+Em seguida, PENDÊNCIAS com os campos sem fonte, um por linha.
+
+REGRA DE CORTE: schema é declaração ao buscador. Campo preenchido por estimativa é uma afirmação falsa assinada pelo site. Deixe fora e liste como pendência.

package/src/skills-lib/site-launch-kit/references/13-robots-sitemap.md

@@ -0,0 +1,40 @@
+# Rodada 13 · robots.txt e sitemap
+
+**Garante:** buscadores entram, e entram só onde devem.
+**Rode quando:** antes do deploy final, com as rotas de produção já estáveis.
+
+Você é um especialista em SEO técnico com acesso ao repositório deste site. Sua única tarefa nesta rodada: garantir que os buscadores consigam entrar, e que entrem só onde devem.
+
+Antes de editar, detecte: framework, se há geração nativa de robots e sitemap, qual é o domínio de produção e se existe alguma configuração herdada de ambiente de teste.
+
+1. A CONFERÊNCIA QUE VEM PRIMEIRO
+   Procure, em TODO o projeto, qualquer bloqueio global de indexação:
+   - "Disallow: /" em robots.txt;
+   - meta robots noindex no layout, no head global ou em componente compartilhado;
+   - cabeçalho HTTP X-Robots-Tag: noindex em configuração de servidor, de host ou de middleware;
+   - variável de ambiente de "site privado" ligada em produção.
+   Este é o achado mais caro do kit inteiro: bloqueio de staging que sobe no deploy tira o site da busca inteira sem dar erro nenhum. Se encontrar, corrija e marque como CRÍTICO no relatório.
+
+2. ROBOTS.TXT
+   Gerado pelo mecanismo do framework quando houver, para não virar arquivo estático esquecido. Deve conter:
+   - permissão geral de rastreio;
+   - bloqueio apenas do que não é conteúdo (área logada, painel, rotas de API, busca interna com parâmetro, carrinho);
+   - a linha Sitemap: com a URL absoluta do sitemap.
+   Não use robots.txt para esconder página sensível: o arquivo é público e vira lista de sugestões. O que precisa ficar fora da busca leva noindex; o que precisa ficar fora do ar leva autenticação.
+
+3. SITEMAP.XML
+   Gerado a partir das rotas reais, contendo apenas URLs que devolvem 200, são canônicas e são indexáveis. Ficam de fora: página de obrigado, páginas com noindex, redirecionamentos, rotas de sistema. lastmod com data real de modificação do conteúdo. Se o site tiver muitas páginas dinâmicas, gere a partir da fonte de conteúdo.
+
+4. COERÊNCIA
+   Cruze as três listas: rotas existentes, sitemap e diretivas de indexação. Nenhuma URL pode estar no sitemap e bloqueada ao mesmo tempo. Confira também canonical e a convenção de barra final.
+
+5. DEPOIS DO DEPLOY
+   Escreva o passo a passo curto: verificar o domínio no Search Console, enviar o sitemap, e usar a inspeção de URL na home para confirmar que ela é indexável.
+
+Formato de saída: depois de aplicar, o conteúdo final de robots.txt em bloco de código, e uma tabela markdown:
+
+| Rota | No sitemap? | Indexável? | Coerente? |
+
+Em seguida, ACHADOS CRÍTICOS (se houver bloqueio herdado), PENDÊNCIAS e o passo a passo pós-deploy.
+
+REGRA DE CORTE: se você não tiver certeza de que uma rota deve ser indexada, deixe-a fora do sitemap e liste em PENDÊNCIAS. Sitemap é uma recomendação de prioridade, não um inventário de tudo que existe.

package/src/skills-lib/site-launch-kit/references/14-privacidade-termos.md

@@ -0,0 +1,39 @@
+# Rodada 14 · Privacidade e termos (LGPD)
+
+**Garante:** política e termos que descrevem o que ESTE site faz, gerados do inventário técnico.
+**Rode quando:** depois que todos os formulários, scripts e integrações estiverem definidos.
+
+Você é um desenvolvedor encarregado da conformidade básica deste site. Sua única tarefa nesta rodada: publicar a política de privacidade e os termos de uso que descrevem o que ESTE site faz.
+
+DECLARAÇÃO OBRIGATÓRIA NA ENTREGA: o texto produzido aqui é base técnica redigida a partir do código, não parecer jurídico. Escreva isso no relatório final e recomende revisão profissional antes de tratar dado sensível, dado de criança ou operação em outro país.
+
+NÃO copie política genérica. NÃO invente razão social, CNPJ, endereço, prazo de retenção ou nome de encarregado.
+
+1. INVENTÁRIO TÉCNICO (é daqui que sai o texto)
+   Percorra o repositório e levante:
+   - todo formulário: quais campos coleta, para onde envia, onde armazena, quem recebe notificação;
+   - todo script de terceiro: analytics, pixel de anúncio, mapa, chat, fonte externa, captcha, vídeo incorporado;
+   - todo cookie e armazenamento local criado, próprio ou de terceiro;
+   - integrações de backend: e-mail transacional, CRM, planilha, webhook, gateway de pagamento.
+   Essa lista é o esqueleto da política. Serviço que você não encontrar no código não entra no texto.
+
+2. A POLÍTICA DE PRIVACIDADE
+   Seções: quem é o controlador; quais dados são coletados e como; para que são usados; com quem são compartilhados (lista real do passo 1, nominal); por quanto tempo são guardados; cookies e para que servem; direitos do titular pela LGPD e como exercê-los; canal de contato; data da última atualização.
+   Linguagem direta, em português claro, sem parágrafo jurídico decorativo. Todo campo que depende do dono entra como marcador explícito ({{RAZAO_SOCIAL}}, {{CNPJ}}, {{EMAIL_ENCARREGADO}}) e vai para PENDÊNCIAS. Nunca preencha por estimativa.
+
+3. TERMOS DE USO
+   Versão curta e honesta: o que o site oferece, o que não garante, regras de uso, propriedade do conteúdo, limitação de responsabilidade, foro. Mesma regra de marcadores.
+
+4. AS LIGAÇÕES
+   - Links no rodapé de TODAS as páginas.
+   - Link ao lado de cada botão de envio de formulário, junto do aviso de consentimento.
+   - Se houver banner de cookies, ele precisa apontar para a política e a URL precisa existir. Se o banner apontar para lugar nenhum, conserte aqui e diga que estava quebrado.
+   - Se houver pixel ou analytics carregando ANTES do consentimento, aponte isso como achado: é o descompasso mais comum entre o que o banner promete e o que o código faz.
+
+Formato de saída: depois de aplicar, o inventário do passo 1 em tabela markdown:
+
+| Dado/Serviço | Onde é coletado | Para onde vai | Consta na política? |
+
+Em seguida, PENDÊNCIAS com todos os marcadores a preencher, a lista de achados de consentimento, e a declaração de que o texto é base técnica e não parecer jurídico.
+
+REGRA DE CORTE: política que descreve coleta que o site não faz é tão ruim quanto política que omite a que ele faz. O texto descreve o inventário, nada além dele.

package/src/skills-lib/site-launch-kit/references/15-medicao.md

@@ -0,0 +1,35 @@
+# Rodada 15 · Medição de lançamento
+
+**Garante:** cada ação que vale dinheiro registrada com nome que faz sentido daqui a três meses.
+**Rode quando:** na véspera ou no dia do lançamento, com os pontos de contato finais no site.
+
+Você é responsável pela medição deste site. Sua única tarefa nesta rodada: garantir que, no dia do lançamento, cada ação que vale dinheiro seja registrada com um nome que faça sentido daqui a três meses.
+
+Antes de editar, detecte: framework, se já existe alguma ferramenta de medição instalada (analytics, pixel, tag manager), se há banner de consentimento e quais são os pontos de contato do site.
+
+NÃO instale quatro ferramentas. NÃO envie dado pessoal como parâmetro de evento (nome, e-mail, telefone, CPF). NÃO invente conta nem identificador de medição: sem o identificador, deixe a variável de ambiente declarada e registre em PENDÊNCIAS.
+
+1. LEVANTAMENTO
+   Liste o que já está instalado e o que cada coisa mede hoje. Duplicação é comum: analytics carregado duas vezes conta cada visita em dobro. Liste também todo ponto de contato: formulários, WhatsApp, telefone, e-mail, download, agendamento, CTA principal e o da barra fixa.
+
+2. NOMENCLATURA (faça isto antes de escrever código)
+   Defina o padrão e escreva-o em um arquivo de documentação do projeto: objeto_ação em minúsculas com sublinhado (formulario_enviado, whatsapp_clique, telefone_clique, orcamento_iniciado). Parâmetros úteis: origem do clique (herói, barra fixa, rodapé), página e identificador do formulário. Nada de dado pessoal. Uma constante por evento, em um arquivo só: nome de evento digitado à mão em cada componente diverge em uma semana.
+
+3. IMPLEMENTAÇÃO
+   - Script carregado sem travar a renderização.
+   - Nada dispara antes do consentimento, se houver banner.
+   - Anonimização de IP quando a ferramenta permitir.
+   - Um disparo por ação, protegido contra clique duplo e contra recarregamento da página de obrigado.
+   - Página de obrigado como conversão principal, ligada à rodada 03 (tempo de resposta).
+   - Se houver pixel de anúncio, dispare o mesmo evento nele, com o mesmo nome, para os relatórios baterem.
+
+4. TESTE DE FUMAÇA
+   Em ambiente local ou de teste, execute cada ação e confirme o evento no depurador da ferramenta. Um evento não testado é um evento que não existe. Liste o que você conseguiu confirmar e o que ficou pendente.
+
+Formato de saída: depois de aplicar, uma tabela markdown, sem texto antes:
+
+| Evento | Gatilho (arquivo · elemento) | Parâmetros | Testado? |
+
+Em seguida, PENDÊNCIAS (identificadores de conta, acessos, eventos não testados) e o padrão de nomenclatura em bloco de código, pronto para entrar na documentação do projeto.
+
+REGRA DE CORTE: meça poucas coisas e meça direito. Vinte eventos mal nomeados produzem um painel que ninguém abre; quatro eventos certos respondem à única pergunta que importa, que é de onde veio o cliente.

package/src/skills-lib/web-security/SKILL.md

@@ -17,14 +17,21 @@ As que mais aparecem numa auditoria, com a correção direta. Use como triagem r
 |---|-------|-----------|----------|------|
 | 1 | SQL Injection | 🔴 Crítica (parada de linha) | Query parametrizada / query-builder, nunca interpolar string | `references/owasp-top5-detalhado.md` §3 |
 | 2 | IDOR (recurso por ID sem checar dono) | 🔴 Crítica (parada de linha) | Validar posse do recurso no servidor a cada request | `references/owasp-top5-detalhado.md` §1 |
-| 3 | Rate limit ausente (brute force grátis) | 🟠 Alta | Limite por IP **e** por conta + lockout/CAPTCHA no login | `references/headers-rate-limit-cors.md` |
-| 4 | CORS refletindo o `Origin` | 🟠 Alta | Allowlist de origens, nunca ecoar o `Origin` recebido | `references/headers-rate-limit-cors.md` |
-| 5 | PII/dado demais na resposta (até hash de senha) | 🟠 Alta | Retornar só os campos necessários (allowlist de saída) | `references/headers-rate-limit-cors.md` |
-| 6 | JWT na URL / token vivo pós-logout | 🟠 Alta | Token no header `Authorization` + revogar no logout | skill `auth-and-secrets` |
-| 7 | Enumeração de usuário (erro revela se e-mail existe) | 🟡 Média | Mensagem genérica + resposta em tempo constante | skill `auth-and-secrets` |
-| 8 | Clickjacking (sem header) | 🟡 Média (1 min) | `X-Frame-Options: DENY` + CSP `frame-ancestors 'none'` | `references/headers-rate-limit-cors.md` |
-
-> As duas primeiras (SQLi e IDOR) são **parada de linha**: apareceu, corrige antes de qualquer coisa.
+| 3 | Mass assignment (body inteiro vai pro banco) | 🔴 Crítica (parada de linha) | Allowlist de campos: só grave os campos do formulário, nunca `spread` do body | `references/owasp-top5-detalhado.md` §6 |
+| 4 | RLS permissiva (`USING(true)`) ou tabela sem policy | 🔴 Crítica | Policy que amarra `auth.uid()` ao dono; tabela nova sempre com policy | `references/owasp-top5-detalhado.md` §1 |
+| 5 | Rate limit ausente (brute force grátis) | 🟠 Alta | Limite por IP **e** por conta + lockout/CAPTCHA no login | `references/headers-rate-limit-cors.md` |
+| 6 | Origem do IP lida do socket atrás de CDN | 🟠 Alta | Ler IP do header certo (`x-forwarded-for` confiável do proxy), senão o rate limit não existe | `references/headers-rate-limit-cors.md` |
+| 7 | Custo por chamada sem limitador (IA/SMS/e-mail) | 🟠 Alta | Rate limit + quota por conta em toda rota que gasta dinheiro real | `references/headers-rate-limit-cors.md` |
+| 8 | Extração por paginação (base inteira registro a registro) | 🟠 Alta | Filtrar por dono na query + limite de página + detecção de varredura | `references/headers-rate-limit-cors.md` |
+| 9 | CORS refletindo o `Origin` | 🟠 Alta | Allowlist de origens, nunca ecoar o `Origin` recebido | `references/headers-rate-limit-cors.md` |
+| 10 | PII/dado demais na resposta (até hash de senha) | 🟠 Alta | Retornar só os campos necessários (allowlist de saída) | `references/headers-rate-limit-cors.md` |
+| 11 | JWT na URL / token vivo pós-logout | 🟠 Alta | Token no header `Authorization` + revogar no logout | skill `auth-and-secrets` |
+| 12 | Enumeração de usuário (erro revela se e-mail existe) | 🟡 Média | Mensagem genérica + resposta em tempo constante | skill `auth-and-secrets` |
+| 13 | Clickjacking (sem header) | 🟡 Média (1 min) | `X-Frame-Options: DENY` + CSP `frame-ancestors 'none'` | `references/headers-rate-limit-cors.md` |
+
+> As quatro primeiras (SQLi, IDOR, mass assignment e RLS permissiva) são **parada de linha**: apareceu, corrige antes de qualquer coisa.
+>
+> Para uma auditoria adversarial completa (caça com prova de exploração + plano priorizado), use a skill `security-audit-pentest`. Esta skill aqui é para **corrigir** uma falha específica da tabela.
 
 ## References (load on demand)
 

package/src/skills-lib/web-security/references/headers-rate-limit-cors.md

@@ -56,6 +56,17 @@ async headers() {
 - Comparações de token/secret: `crypto.timingSafeEqual`, nunca `!==` (detalhe em auth-and-secrets)
 - Sem rate limit = brute force de graça. Somar lockout/CAPTCHA após N falhas no login
 
+### Origem do IP atrás de proxy/CDN
+Se o app roda atrás de Vercel/Cloudflare/qualquer proxy, o IP do socket é o do proxy, não o do cliente. Ler o socket direto faz **o mundo inteiro contar como um IP só** e o rate limit deixa de existir na prática.
+- Vercel: use `x-forwarded-for` (ou `req.ip` no runtime que já resolve). Pegue o **primeiro** IP da lista, mas só confie na cadeia que vem do seu proxy.
+- Nunca confie em `x-forwarded-for` cru vindo de origem não-proxy (o cliente falsifica o header). Configure a lib de rate limit para o número certo de proxies à frente.
+
+### Custo por chamada (rota que gasta dinheiro real)
+Toda rota que chama modelo de linguagem, dispara SMS, envia e-mail, processa arquivo ou bate em API paga de terceiro precisa de rate limit **e** quota por conta. Rota de agente de IA exposta sem limitador é crítica mesmo sem vazar dado nenhum: 10.000 chamadas em loop viram conta de centenas a milhares de reais/dólares. Estime o custo unitário e multiplique por 10k ao avaliar a rota.
+
+### Extração por paginação
+Rota que devolve um registro por vez e, chamada em sequência, entrega a base inteira. Barre com: filtro por dono na query (o mesmo do IDOR), limite máximo de página, e detecção de varredura (muitos ids sequenciais do mesmo cliente).
+
 ## CORS
 - **Nunca reflita o header `Origin` recebido** de volta em `Access-Control-Allow-Origin` (isso libera qualquer site a chamar sua API com credenciais)
 - Use uma **allowlist explícita** de origens: compare o `Origin` recebido contra a lista e só então ecoe o valor exato daquela origem

package/src/skills-lib/web-security/references/owasp-top5-detalhado.md

@@ -28,6 +28,38 @@ export async function GET(req: Request, { params }: { params: Promise<{ id: stri
 }
 ```
 
+### RLS: policy permissiva é pior que policy nenhuma
+Ler os arquivos de migration/policy versionados e checar:
+- Toda tabela de domínio tem `ENABLE ROW LEVEL SECURITY`?
+- Nenhuma policy é permissiva: `USING (true)` ou `WITH CHECK (true)` libera geral, mas o painel do Supabase mostra a trava como "ativa". Amarre sempre ao dono: `USING (auth.uid() = user_id)`.
+- Tabela criada em migration recente **sem** policy correspondente = exposta.
+
+```sql
+-- ERRADO: mostra RLS ativo no painel, mas libera qualquer um
+create policy "read" on projects for select using (true);
+
+-- CERTO: amarra o dono
+alter table projects enable row level security;
+create policy "own rows" on projects
+  for select using (auth.uid() = user_id);
+```
+
+> RLS de verdade é estado do banco, não arquivo. O que está no repo é ponto de partida: confirme o estado real no dashboard/`\d+` do Postgres.
+
+## 6. Mass Assignment (atribuição em massa)
+O corpo da requisição inteiro repassado para o banco (`spread` do objeto, `update`/`create` com o payload completo) deixa o atacante setar qualquer coluna, mesmo as que não estão no formulário. Alvos clássicos: `role`, `is_admin`, `plan`, `balance`, `payment_status`, `user_id`/`owner_id`.
+
+```ts
+// ERRADO: o cliente manda { name: "x", role: "admin" } e vira admin
+await supabase.from("users").update({ ...body }).eq("id", userId)
+
+// CERTO: allowlist explícita, só os campos do formulário
+const { name, bio } = updateSchema.parse(body) // Zod com só os campos permitidos
+await supabase.from("users").update({ name, bio }).eq("id", userId)
+```
+
+Regra: **nunca** `...body` / `...req.body` num write. Sempre desestruture (ou valide com um schema que só contém os campos editáveis). Campos de papel, permissão, plano, saldo, status de pagamento e id de dono nunca vêm do cliente.
+
 ## 2. Cryptographic Failures
 - HTTPS em tudo, sem exceção
 - HSTS header com includeSubDomains

package/src/skills-lib/wizz-router/references/routing-table-flat.md

@@ -15,6 +15,7 @@ Use esta tabela **só fora de projeto Wizz** (sem `_wizz/`), quando o router map
 | Auth, secrets, tokens, OAuth, JWT, Clerk, permissões | `auth-and-secrets` + `web-security` | 1 |
 | Dependências, packages, vulnerabilidades, npm audit | `database-and-deps` | 2 |
 | Segurança, XSS, CSRF, SQLi, IDOR, OWASP, rate limit, CORS, clickjacking, PII na resposta, enumeração de usuário, headers | `web-security` + `auth-and-secrets` | 1 |
+| Auditoria/pentest de segurança do app inteiro, "auditar segurança", "pentest", "encontrar vulnerabilidades", varredura antes de release | `security-audit-pentest` | 1 |
 | Desktop, Electron, contextIsolation, code signing | `desktop-security` | 2 |
 
 ## Área Técnica — Código e Qualidade
@@ -58,6 +59,7 @@ Use esta tabela **só fora de projeto Wizz** (sem `_wizz/`), quando o router map
 | Paid ads, anúncios, Google Ads, Meta Ads, TikTok Ads, mídia paga | `paid-ads` + `ad-creative` + `analytics-tracking` + **MCP meta-ads** | 1 |
 | Gestão de campanha Meta/Facebook/Instagram via API real | **MCP meta-ads** (`mcp-meta-ads`) direto | 1 |
 | Lançamento de feature, lançamento de produto, go-to-market | `launch-strategy` + `social-content` + `email-sequence` | 1 |
+| Site pronto pra subir, pré-lançamento de SITE, "revisa antes do deploy", checklist de go-live, ou item pontual pré-lançamento (og:image/prévia de link, FAQ com schema, robots.txt, LGPD, alt text) | `site-launch-kit` | 1 |
 | Preço, planos, pricing, monetização | `pricing-strategy` + `paywall-upgrade-cro` | 1 |
 | Churn, retenção, cancelamento, NPS | `churn-prevention` + `revops` | 1 |
 | Conversão de página, CRO, otimização de funil | `page-cro` + `copywriting` + `form-cro` | 1 |