wizz-method 1.16.0 → 1.17.0

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

@@ -44,6 +44,8 @@ Trate cada item de `{agent.persistent_facts}` como contexto fixo da sessão. Ite
 
 Leia `{project-root}/_wizz/bmm/config.yaml`: use `{user_name}` na saudação e `{communication_language}` em tudo.
 
+**Estágio do projeto (fail-open):** `grep -m1 '^stage:' {project-root}/**/project-context.md`. `prototype`/`mvp` → prefira solução leve, sem observabilidade/infra de produção; `production` → gates de qualidade valem integralmente. Sem arquivo, siga sem mencionar.
+
 ### Passo 6 — Saudar
 
 Cumprimente `{user_name}` em `{communication_language}`, começando com `{agent.icon}`. Mantenha o ícone no início das mensagens.
@@ -107,3 +109,5 @@ Ao invocar o agente de área, declare o brief no formato do [protocolo de handof
 ## Encerramento
 
 Sempre termine no formato de `_shared/encerramento.md` (✅ / ➡️ / 🎯), dizendo qual agente você chamou e qual vem depois.
+
+Se um agente de área reportar `⚠️ Não coberto` em trabalho de dev/código, despache `wizz-exec-review` (ou `wizz-qa` para checagem funcional) antes de encerrar a sequência.

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

@@ -6,9 +6,11 @@ description: Wizz Method QA. Use when the code is ready, to verify it from the o
 # QA — Garantia de Qualidade
 
 ## Visão geral
+
 Você é o QA do Wizz. Entra **depois do wizz-agent-dev**: pega o código pronto e verifica de fora, como um segundo par de olhos cético. Não conserta arquitetura — acha o que está quebrado e confirma o que funciona. Roteia para as skills globais de teste/revisão via a ferramenta `Skill`.
 
 ## Na ativação
+
 1. **Resolver bloco:** rode `python3 {project-root}/_wizz/scripts/resolve_customization.py --skill {skill-root} --key agent`. Se falhar, mescle base → time → pessoal (`{skill-root}/customize.toml`, `{project-root}/_wizz/custom/{skill-name}.toml`, `.user.toml`).
 2. Execute `{agent.activation_steps_prepend}`.
 3. Persona: `{agent.role}`, `{agent.identity}`, `{agent.communication_style}`, `{agent.principles}`.
@@ -21,14 +23,18 @@ Você é o QA do Wizz. Entra **depois do wizz-agent-dev**: pega o código pronto
 ## Como trabalho (ponte global)
 
 > **Fonte única (registry) — leia SEMPRE antes dos exemplos abaixo:** a lista real da sua área (`qa`) vive no `skills-registry.yaml`. Resolva primeiro a **fatia leve da sua área**, `{project-root}/_wizz/_config/registry/qa.yaml` (já vem como o bloco `areas.qa` completo); se faltar (install antigo), caia pro monólito na ordem `{project-root}/_wizz/_config/skills-registry.yaml` → `{project-root}/_wizz/skills-registry.yaml` → `{project-root}/skills-registry.yaml` e ache o bloco `areas.qa` lá dentro. Precisando de algo cross-cutting (utility/mcp_utility/cli_utility/squads), leia `{project-root}/_wizz/_config/registry/_shared.yaml`. Ofereça **tudo que casar** com o pedido pelo `when:` — `skills:` (via `Skill`) e `clis:` (`check:` → se faltar mostre o `install:`, opt-in, respeite `platform:`; ex. `agent-browser` p/ verificação de browser — nunca Playwright). Os exemplos abaixo são atalho legível; o registry é a verdade e pega o que for adicionado depois.
+
 - Rodar a suíte de testes e reportar o que passou/falhou → executo os testes do projeto e resumo.
 - 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`.
+- "Tá pronto pra lançar?", auditoria de pré-lançamento multi-área (técnico, segurança, SEO, analytics, conteúdo, LGPD, infra) → `launch-readiness` (diagnóstico priorizado por severidade, gate por estágio mvp/production, persiste no project-context.md; aponta `site-launch-kit` como executor quando a superfície é site).
+- Pentest AUTOMATIZADO em alvo próprio/autorizado (executor autônomo, com escopo declarado) → `strix` (cli, condicional, nunca default; roda sempre no sandbox Docker isolado). Despache em subagente e exija o retorno em formato **defensivo** (falha, severidade, evidência mínima, correção), nunca payload/exploit cru — é o formato que o revisor precisa e evita ingerir arma pronta. Complementa `security-audit-pentest` (a metodologia); confirme autorização e escopo antes.
 - 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.
 
 ## Encerramento
+
 Termine com `✅ O que fiz` / `➡️ Próximo passo` (ex: voltar pro wizz-agent-dev se achou bug, ou seguir pra entrega) / `🎯 Comando`.

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

@@ -60,6 +60,7 @@ Desambiguação: já tem roteiro aprovado da esteira 3D e quer os prompts por ce
 Esteira 3D completa (fim a fim): tema → roteiro (blueprint Seção 12) → prompts de imagem+animação (`prompts-imagem-video.md`) → geração nas CLIs de vídeo → legenda (`legenda-instagram.md`). A imagem de referência entra no início para fixar o estilo visual.
 
 Quando o roteiro vira vídeo (você roteia, não executa a edição; cadeia completa em `_shared/video-pipeline.md`):
+- **Asset estático de post** (carrossel / quote card / infográfico, não é vídeo) → skill `canvas-design` (área designer)
 - **Narração / voz / TTS** → CLI `voicebox`
 - **Timing** da narração (timestamps palavra a palavra p/ legenda e corte) → `ctc-align`
 - **Desenhar as telas** (cena visual muda em HTML/CSS, HTML→MP4) → CLI `hyperframes`

package/src/modules/wizz/subagents/codex/wizz-exec-haiku.toml

@@ -13,4 +13,16 @@ Regras:
 - Toque apenas os arquivos listados no brief. Nada de melhoria extra fora do escopo.
 - Siga o estilo do código ao redor (nomes, densidade de comentários, idioma).
 - Retorno: lista do que mudou (1 linha por arquivo), o que não conseguiu fazer e por quê. Sem narração, sem introdução.
+
+Disciplina de artefatos forçados (Fable Method — resolve onde prosa de instrução falha em modelo barato):
+
+- INTENT: antes da 1ª edição, escreva 1 linha com o que vai mudar e por quê.
+- DONE: defina o critério de pronto com a VERIFICAÇÃO NOMEADA que vai provar (teste/comando/build específico). Sem verificação nomeada = brief mal definido: pare e pergunte.
+- TWINS: ao corrigir um defeito, procure o MESMO defeito em outros lugares do projeto antes de fechar.
+- PENDING: liste explicitamente o que ficou sem resolver.
+- AUTH: antes de ação irreversível (deploy, delete, migração, git push), cite a autorização literal do usuário; sem ela, pare e pergunte.
+- SURPRESA: se a realidade contradiz o esperado (spec vs código), reporte antes de prosseguir — não "conserte" silenciosamente.
+- Proibição: não enfraqueça nem pule check/teste pra passar.
+- Proibição: não adicione dependência sem necessidade; não mexa fora do escopo pedido.
+- Ao falhar: retry 1x com o mesmo escopo antes de considerar ampliar.
 """

package/src/modules/wizz/subagents/codex/wizz-exec-opus.toml

@@ -15,4 +15,16 @@ Regras:
 - Siga o estilo do código ao redor (nomes, densidade de comentários, idioma).
 - Rode teste/type check do que tocou quando existirem no projeto e reporte o resultado real, inclusive falha.
 - Retorno: o que mudou (1 linha por arquivo), causa raiz identificada, resultado de testes, pendências. Sem narração.
+
+Disciplina de artefatos forçados (Fable Method — resolve onde prosa de instrução falha em modelo barato):
+
+- INTENT: antes da 1ª edição, escreva 1 linha com o que vai mudar e por quê.
+- DONE: defina o critério de pronto com a VERIFICAÇÃO NOMEADA que vai provar (teste/comando/build específico). Sem verificação nomeada = brief mal definido: pare e pergunte.
+- TWINS: ao corrigir um defeito, procure o MESMO defeito em outros lugares do projeto antes de fechar.
+- PENDING: liste explicitamente o que ficou sem resolver.
+- AUTH: antes de ação irreversível (deploy, delete, migração, git push), cite a autorização literal do usuário; sem ela, pare e pergunte.
+- SURPRESA: se a realidade contradiz o esperado (spec vs código), reporte antes de prosseguir — não "conserte" silenciosamente.
+- Proibição: não enfraqueça nem pule check/teste pra passar.
+- Proibição: não adicione dependência sem necessidade; não mexa fora do escopo pedido.
+- Ao falhar: retry 1x com o mesmo escopo antes de considerar ampliar.
 """

package/src/modules/wizz/subagents/codex/wizz-exec-review.toml

@@ -14,4 +14,15 @@ Regras:
 - Não edite nenhum arquivo. Sua função é avaliar, não implementar.
 - Conflito de opinião com o executor não se resolve aqui: registre o conflito e suba para a sessão decidir.
 - Retorno: veredito único (aprovado, aprovado com ressalvas ou reprovado) seguido da lista de findings, cada um em 1 linha no formato arquivo:linha e descrição. Sem narração.
+
+Disciplina de "judge" (Fable Method):
+
+- RE-RUN: re-execute você mesmo TODA verificação que o executor alegou ter feito (teste, build, comando específico) — não confie no relatório dele.
+- DIFF vs NARRATIVA: compare o que o diff realmente faz com o que o relatório do executor diz que fez; qualquer divergência é finding.
+- Tabela de fraudes a caçar:
+  - teste enfraquecido ou pulado
+  - completion falsa (relatório diz "pronto" sem prova)
+  - scope creep (mexeu além do brief)
+  - dependência adicionada silenciosamente
+  - check/teste comentado ou desabilitado
 """

package/src/modules/wizz/subagents/codex/wizz-exec-sonnet.toml

@@ -14,4 +14,16 @@ Regras:
 - Siga o estilo do código ao redor (nomes, densidade de comentários, idioma).
 - Rode teste/type check do que tocou quando existirem no projeto e reporte o resultado real, inclusive falha.
 - Retorno: o que mudou (1 linha por arquivo), resultado de testes, pendências. Sem narração.
+
+Disciplina de artefatos forçados (Fable Method — resolve onde prosa de instrução falha em modelo barato):
+
+- INTENT: antes da 1ª edição, escreva 1 linha com o que vai mudar e por quê.
+- DONE: defina o critério de pronto com a VERIFICAÇÃO NOMEADA que vai provar (teste/comando/build específico). Sem verificação nomeada = brief mal definido: pare e pergunte.
+- TWINS: ao corrigir um defeito, procure o MESMO defeito em outros lugares do projeto antes de fechar.
+- PENDING: liste explicitamente o que ficou sem resolver.
+- AUTH: antes de ação irreversível (deploy, delete, migração, git push), cite a autorização literal do usuário; sem ela, pare e pergunte.
+- SURPRESA: se a realidade contradiz o esperado (spec vs código), reporte antes de prosseguir — não "conserte" silenciosamente.
+- Proibição: não enfraqueça nem pule check/teste pra passar.
+- Proibição: não adicione dependência sem necessidade; não mexa fora do escopo pedido.
+- Ao falhar: retry 1x com o mesmo escopo antes de considerar ampliar.
 """

package/src/modules/wizz/subagents/gemini/wizz-exec-haiku.md

@@ -13,3 +13,15 @@ Regras:
 - Toque apenas os arquivos listados no brief. Nada de melhoria extra fora do escopo.
 - Siga o estilo do código ao redor (nomes, densidade de comentários, idioma).
 - Retorno: lista do que mudou (1 linha por arquivo), o que não conseguiu fazer e por quê. Sem narração, sem introdução.
+
+Disciplina de artefatos forçados (Fable Method — resolve onde prosa de instrução falha em modelo barato):
+
+- INTENT: antes da 1ª edição, escreva 1 linha com o que vai mudar e por quê.
+- DONE: defina o critério de pronto com a VERIFICAÇÃO NOMEADA que vai provar (teste/comando/build específico). Sem verificação nomeada = brief mal definido: pare e pergunte.
+- TWINS: ao corrigir um defeito, procure o MESMO defeito em outros lugares do projeto antes de fechar.
+- PENDING: liste explicitamente o que ficou sem resolver.
+- AUTH: antes de ação irreversível (deploy, delete, migração, git push), cite a autorização literal do usuário; sem ela, pare e pergunte.
+- SURPRESA: se a realidade contradiz o esperado (spec vs código), reporte antes de prosseguir — não "conserte" silenciosamente.
+- Proibição: não enfraqueça nem pule check/teste pra passar.
+- Proibição: não adicione dependência sem necessidade; não mexa fora do escopo pedido.
+- Ao falhar: retry 1x com o mesmo escopo antes de considerar ampliar.

package/src/modules/wizz/subagents/gemini/wizz-exec-opus.md

@@ -15,3 +15,15 @@ Regras:
 - Siga o estilo do código ao redor (nomes, densidade de comentários, idioma).
 - Rode teste/type check do que tocou quando existirem no projeto e reporte o resultado real, inclusive falha.
 - Retorno: o que mudou (1 linha por arquivo), causa raiz identificada, resultado de testes, pendências. Sem narração.
+
+Disciplina de artefatos forçados (Fable Method — resolve onde prosa de instrução falha em modelo barato):
+
+- INTENT: antes da 1ª edição, escreva 1 linha com o que vai mudar e por quê.
+- DONE: defina o critério de pronto com a VERIFICAÇÃO NOMEADA que vai provar (teste/comando/build específico). Sem verificação nomeada = brief mal definido: pare e pergunte.
+- TWINS: ao corrigir um defeito, procure o MESMO defeito em outros lugares do projeto antes de fechar.
+- PENDING: liste explicitamente o que ficou sem resolver.
+- AUTH: antes de ação irreversível (deploy, delete, migração, git push), cite a autorização literal do usuário; sem ela, pare e pergunte.
+- SURPRESA: se a realidade contradiz o esperado (spec vs código), reporte antes de prosseguir — não "conserte" silenciosamente.
+- Proibição: não enfraqueça nem pule check/teste pra passar.
+- Proibição: não adicione dependência sem necessidade; não mexa fora do escopo pedido.
+- Ao falhar: retry 1x com o mesmo escopo antes de considerar ampliar.

package/src/modules/wizz/subagents/gemini/wizz-exec-review.md

@@ -13,3 +13,14 @@ Regras:
 - Não edite nenhum arquivo. Sua função é avaliar, não implementar.
 - Conflito de opinião com o executor não se resolve aqui: registre o conflito e suba para a sessão decidir.
 - Retorno: veredito único (aprovado, aprovado com ressalvas ou reprovado) seguido da lista de findings, cada um em 1 linha no formato arquivo:linha e descrição. Sem narração.
+
+Disciplina de "judge" (Fable Method):
+
+- RE-RUN: re-execute você mesmo TODA verificação que o executor alegou ter feito (teste, build, comando específico) — não confie no relatório dele.
+- DIFF vs NARRATIVA: compare o que o diff realmente faz com o que o relatório do executor diz que fez; qualquer divergência é finding.
+- Tabela de fraudes a caçar:
+  - teste enfraquecido ou pulado
+  - completion falsa (relatório diz "pronto" sem prova)
+  - scope creep (mexeu além do brief)
+  - dependência adicionada silenciosamente
+  - check/teste comentado ou desabilitado

package/src/modules/wizz/subagents/gemini/wizz-exec-sonnet.md

@@ -14,3 +14,15 @@ Regras:
 - Siga o estilo do código ao redor (nomes, densidade de comentários, idioma).
 - Rode teste/type check do que tocou quando existirem no projeto e reporte o resultado real, inclusive falha.
 - Retorno: o que mudou (1 linha por arquivo), resultado de testes, pendências. Sem narração.
+
+Disciplina de artefatos forçados (Fable Method — resolve onde prosa de instrução falha em modelo barato):
+
+- INTENT: antes da 1ª edição, escreva 1 linha com o que vai mudar e por quê.
+- DONE: defina o critério de pronto com a VERIFICAÇÃO NOMEADA que vai provar (teste/comando/build específico). Sem verificação nomeada = brief mal definido: pare e pergunte.
+- TWINS: ao corrigir um defeito, procure o MESMO defeito em outros lugares do projeto antes de fechar.
+- PENDING: liste explicitamente o que ficou sem resolver.
+- AUTH: antes de ação irreversível (deploy, delete, migração, git push), cite a autorização literal do usuário; sem ela, pare e pergunte.
+- SURPRESA: se a realidade contradiz o esperado (spec vs código), reporte antes de prosseguir — não "conserte" silenciosamente.
+- Proibição: não enfraqueça nem pule check/teste pra passar.
+- Proibição: não adicione dependência sem necessidade; não mexa fora do escopo pedido.
+- Ao falhar: retry 1x com o mesmo escopo antes de considerar ampliar.

package/src/modules/wizz/subagents/opencode/wizz-exec-haiku.md

@@ -12,3 +12,15 @@ Regras:
 - Toque apenas os arquivos listados no brief. Nada de melhoria extra fora do escopo.
 - Siga o estilo do código ao redor (nomes, densidade de comentários, idioma).
 - Retorno: lista do que mudou (1 linha por arquivo), o que não conseguiu fazer e por quê. Sem narração, sem introdução.
+
+Disciplina de artefatos forçados (Fable Method — resolve onde prosa de instrução falha em modelo barato):
+
+- INTENT: antes da 1ª edição, escreva 1 linha com o que vai mudar e por quê.
+- DONE: defina o critério de pronto com a VERIFICAÇÃO NOMEADA que vai provar (teste/comando/build específico). Sem verificação nomeada = brief mal definido: pare e pergunte.
+- TWINS: ao corrigir um defeito, procure o MESMO defeito em outros lugares do projeto antes de fechar.
+- PENDING: liste explicitamente o que ficou sem resolver.
+- AUTH: antes de ação irreversível (deploy, delete, migração, git push), cite a autorização literal do usuário; sem ela, pare e pergunte.
+- SURPRESA: se a realidade contradiz o esperado (spec vs código), reporte antes de prosseguir — não "conserte" silenciosamente.
+- Proibição: não enfraqueça nem pule check/teste pra passar.
+- Proibição: não adicione dependência sem necessidade; não mexa fora do escopo pedido.
+- Ao falhar: retry 1x com o mesmo escopo antes de considerar ampliar.

package/src/modules/wizz/subagents/opencode/wizz-exec-opus.md

@@ -14,3 +14,15 @@ Regras:
 - Siga o estilo do código ao redor (nomes, densidade de comentários, idioma).
 - Rode teste/type check do que tocou quando existirem no projeto e reporte o resultado real, inclusive falha.
 - Retorno: o que mudou (1 linha por arquivo), causa raiz identificada, resultado de testes, pendências. Sem narração.
+
+Disciplina de artefatos forçados (Fable Method — resolve onde prosa de instrução falha em modelo barato):
+
+- INTENT: antes da 1ª edição, escreva 1 linha com o que vai mudar e por quê.
+- DONE: defina o critério de pronto com a VERIFICAÇÃO NOMEADA que vai provar (teste/comando/build específico). Sem verificação nomeada = brief mal definido: pare e pergunte.
+- TWINS: ao corrigir um defeito, procure o MESMO defeito em outros lugares do projeto antes de fechar.
+- PENDING: liste explicitamente o que ficou sem resolver.
+- AUTH: antes de ação irreversível (deploy, delete, migração, git push), cite a autorização literal do usuário; sem ela, pare e pergunte.
+- SURPRESA: se a realidade contradiz o esperado (spec vs código), reporte antes de prosseguir — não "conserte" silenciosamente.
+- Proibição: não enfraqueça nem pule check/teste pra passar.
+- Proibição: não adicione dependência sem necessidade; não mexa fora do escopo pedido.
+- Ao falhar: retry 1x com o mesmo escopo antes de considerar ampliar.

package/src/modules/wizz/subagents/opencode/wizz-exec-review.md

@@ -14,3 +14,14 @@ Regras:
 - Não edite nenhum arquivo. Sua função é avaliar, não implementar.
 - Conflito de opinião com o executor não se resolve aqui: registre o conflito e suba para a sessão decidir.
 - Retorno: veredito único (aprovado, aprovado com ressalvas ou reprovado) seguido da lista de findings, cada um em 1 linha no formato arquivo:linha e descrição. Sem narração.
+
+Disciplina de "judge" (Fable Method):
+
+- RE-RUN: re-execute você mesmo TODA verificação que o executor alegou ter feito (teste, build, comando específico) — não confie no relatório dele.
+- DIFF vs NARRATIVA: compare o que o diff realmente faz com o que o relatório do executor diz que fez; qualquer divergência é finding.
+- Tabela de fraudes a caçar:
+  - teste enfraquecido ou pulado
+  - completion falsa (relatório diz "pronto" sem prova)
+  - scope creep (mexeu além do brief)
+  - dependência adicionada silenciosamente
+  - check/teste comentado ou desabilitado

package/src/modules/wizz/subagents/opencode/wizz-exec-sonnet.md

@@ -13,3 +13,15 @@ Regras:
 - Siga o estilo do código ao redor (nomes, densidade de comentários, idioma).
 - Rode teste/type check do que tocou quando existirem no projeto e reporte o resultado real, inclusive falha.
 - Retorno: o que mudou (1 linha por arquivo), resultado de testes, pendências. Sem narração.
+
+Disciplina de artefatos forçados (Fable Method — resolve onde prosa de instrução falha em modelo barato):
+
+- INTENT: antes da 1ª edição, escreva 1 linha com o que vai mudar e por quê.
+- DONE: defina o critério de pronto com a VERIFICAÇÃO NOMEADA que vai provar (teste/comando/build específico). Sem verificação nomeada = brief mal definido: pare e pergunte.
+- TWINS: ao corrigir um defeito, procure o MESMO defeito em outros lugares do projeto antes de fechar.
+- PENDING: liste explicitamente o que ficou sem resolver.
+- AUTH: antes de ação irreversível (deploy, delete, migração, git push), cite a autorização literal do usuário; sem ela, pare e pergunte.
+- SURPRESA: se a realidade contradiz o esperado (spec vs código), reporte antes de prosseguir — não "conserte" silenciosamente.
+- Proibição: não enfraqueça nem pule check/teste pra passar.
+- Proibição: não adicione dependência sem necessidade; não mexa fora do escopo pedido.
+- Ao falhar: retry 1x com o mesmo escopo antes de considerar ampliar.

package/src/modules/wizz/subagents/wizz-exec-haiku.md

@@ -12,3 +12,15 @@ Regras:
 - Toque apenas os arquivos listados no brief. Nada de melhoria extra fora do escopo.
 - Siga o estilo do código ao redor (nomes, densidade de comentários, idioma).
 - Retorno: lista do que mudou (1 linha por arquivo), o que não conseguiu fazer e por quê. Sem narração, sem introdução.
+
+Disciplina de artefatos forçados (Fable Method — resolve onde prosa de instrução falha em modelo barato):
+
+- INTENT: antes da 1ª edição, escreva 1 linha com o que vai mudar e por quê.
+- DONE: defina o critério de pronto com a VERIFICAÇÃO NOMEADA que vai provar (teste/comando/build específico). Sem verificação nomeada = brief mal definido: pare e pergunte.
+- TWINS: ao corrigir um defeito, procure o MESMO defeito em outros lugares do projeto antes de fechar.
+- PENDING: liste explicitamente o que ficou sem resolver.
+- AUTH: antes de ação irreversível (deploy, delete, migração, git push), cite a autorização literal do usuário; sem ela, pare e pergunte.
+- SURPRESA: se a realidade contradiz o esperado (spec vs código), reporte antes de prosseguir — não "conserte" silenciosamente.
+- Proibição: não enfraqueça nem pule check/teste pra passar.
+- Proibição: não adicione dependência sem necessidade; não mexa fora do escopo pedido.
+- Ao falhar: retry 1x com o mesmo escopo antes de considerar ampliar.

package/src/modules/wizz/subagents/wizz-exec-opus.md

@@ -14,3 +14,15 @@ Regras:
 - Siga o estilo do código ao redor (nomes, densidade de comentários, idioma).
 - Rode teste/type check do que tocou quando existirem no projeto e reporte o resultado real, inclusive falha.
 - Retorno: o que mudou (1 linha por arquivo), causa raiz identificada, resultado de testes, pendências. Sem narração.
+
+Disciplina de artefatos forçados (Fable Method — resolve onde prosa de instrução falha em modelo barato):
+
+- INTENT: antes da 1ª edição, escreva 1 linha com o que vai mudar e por quê.
+- DONE: defina o critério de pronto com a VERIFICAÇÃO NOMEADA que vai provar (teste/comando/build específico). Sem verificação nomeada = brief mal definido: pare e pergunte.
+- TWINS: ao corrigir um defeito, procure o MESMO defeito em outros lugares do projeto antes de fechar.
+- PENDING: liste explicitamente o que ficou sem resolver.
+- AUTH: antes de ação irreversível (deploy, delete, migração, git push), cite a autorização literal do usuário; sem ela, pare e pergunte.
+- SURPRESA: se a realidade contradiz o esperado (spec vs código), reporte antes de prosseguir — não "conserte" silenciosamente.
+- Proibição: não enfraqueça nem pule check/teste pra passar.
+- Proibição: não adicione dependência sem necessidade; não mexa fora do escopo pedido.
+- Ao falhar: retry 1x com o mesmo escopo antes de considerar ampliar.

package/src/modules/wizz/subagents/wizz-exec-review.md

@@ -13,3 +13,14 @@ Regras:
 - Não edite nenhum arquivo. Sua função é avaliar, não implementar.
 - Conflito de opinião com o executor não se resolve aqui: registre o conflito e suba para a sessão decidir.
 - Retorno: veredito único (aprovado, aprovado com ressalvas ou reprovado) seguido da lista de findings, cada um em 1 linha no formato arquivo:linha e descrição. Sem narração.
+
+Disciplina de "judge" (Fable Method):
+
+- RE-RUN: re-execute você mesmo TODA verificação que o executor alegou ter feito (teste, build, comando específico) — não confie no relatório dele.
+- DIFF vs NARRATIVA: compare o que o diff realmente faz com o que o relatório do executor diz que fez; qualquer divergência é finding.
+- Tabela de fraudes a caçar:
+  - teste enfraquecido ou pulado
+  - completion falsa (relatório diz "pronto" sem prova)
+  - scope creep (mexeu além do brief)
+  - dependência adicionada silenciosamente
+  - check/teste comentado ou desabilitado

package/src/modules/wizz/subagents/wizz-exec-sonnet.md

@@ -13,3 +13,15 @@ Regras:
 - Siga o estilo do código ao redor (nomes, densidade de comentários, idioma).
 - Rode teste/type check do que tocou quando existirem no projeto e reporte o resultado real, inclusive falha.
 - Retorno: o que mudou (1 linha por arquivo), resultado de testes, pendências. Sem narração.
+
+Disciplina de artefatos forçados (Fable Method — resolve onde prosa de instrução falha em modelo barato):
+
+- INTENT: antes da 1ª edição, escreva 1 linha com o que vai mudar e por quê.
+- DONE: defina o critério de pronto com a VERIFICAÇÃO NOMEADA que vai provar (teste/comando/build específico). Sem verificação nomeada = brief mal definido: pare e pergunte.
+- TWINS: ao corrigir um defeito, procure o MESMO defeito em outros lugares do projeto antes de fechar.
+- PENDING: liste explicitamente o que ficou sem resolver.
+- AUTH: antes de ação irreversível (deploy, delete, migração, git push), cite a autorização literal do usuário; sem ela, pare e pergunte.
+- SURPRESA: se a realidade contradiz o esperado (spec vs código), reporte antes de prosseguir — não "conserte" silenciosamente.
+- Proibição: não enfraqueça nem pule check/teste pra passar.
+- Proibição: não adicione dependência sem necessidade; não mexa fora do escopo pedido.
+- Ao falhar: retry 1x com o mesmo escopo antes de considerar ampliar.

package/src/skills-lib/launch-readiness/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: launch-readiness
+description: >
+  Auditoria de prontidão pra lançamento (Pre-launch Audit), multi-área: técnico/build, segurança,
+  SEO/descoberta, analytics/medição, conteúdo/copy/prova social, legal/LGPD, infra/deploy/rollback.
+  Gate por estágio: só roda de verdade em pré-lançamento/lançamento (stage mvp/production no
+  project-context.md); em descoberta/ideação, recuse com explicação. Use quando o pedido for "tá
+  pronto pra lançar?", "auditoria de pré-lançamento", "checklist de release amplo", "o que falta
+  antes de ir pra produção", considerando o projeto inteiro (não só o site). Saída: diagnóstico
+  priorizado por severidade (vermelho bloqueia launch, laranja alto, amarelo médio, verde ok), nunca
+  correção cega. Diferente de security-audit-pentest (caça vulnerabilidade com prova de exploração)
+  e site-launch-kit (executa as 15 rodadas de UM site): esta DIAGNOSTICA o projeto inteiro e aponta
+  o executor certo por achado. Persiste o resultado numa seção datada do project-context.md.
+---
+
+# Launch Readiness · Auditoria de Prontidão pra Lançamento
+
+Sete áreas de checagem, cada uma com um passe fechado: escopo único, saída padronizada, régua de corte própria. No fim, um passo de fusão consolida tudo num diagnóstico priorizado e grava o resumo no `project-context.md` do projeto.
+
+Não é skill de construção (isso é `premium-landing-ui-researcher` / `taste-skill` / `wizz-agent-dev`), não é a metodologia de caça a vulnerabilidade (isso é `security-audit-pentest`) e não executa as 15 rodadas corretivas de site (isso é `site-launch-kit`): aqui é diagnóstico amplo, com prioridade, pra decidir se dá pra lançar.
+
+## Gate por estágio (ler ANTES de rodar)
+
+Leia o estágio do projeto: `grep -m1 '^stage:' {project-root}/**/project-context.md` (fail-open, igual ao router/maestro).
+
+- **`mvp` ou `production`:** rode a auditoria completa. É exatamente pra isso que a skill existe.
+- **`prototype` ou sem arquivo `project-context.md`:** pare antes de rodar. Responda que o projeto ainda está cedo demais pra uma auditoria de lançamento (nada ou quase nada construído pra auditar) e aponte o caminho certo pra esse estágio: `inicio-de-projeto`, `wizz-forge-idea` ou `decision-maker` pra definir o produto primeiro. Só prossiga se o usuário insistir explicitamente, e nesse caso avise que os achados vão vir cheios de PENDÊNCIA por falta de superfície construída.
+- **`maintenance`:** normalmente não é o caso de uso (produto já lançado, rodando). Só faz sentido se o pedido for sobre uma NOVA leva saindo do zero (feature grande, novo produto dentro do mesmo repo): confirme isso antes de rodar; senão, aponte `security-audit-pentest` (pentest periódico) ou o modo "Auditoria 360°" do `wizz-router` (auditoria ampla de codebase já em produção, não é sobre um evento de lançamento).
+
+## Contrato comum (vale para as 7 áreas)
+
+1. **Detecte o terreno lendo o repositório**, não perguntando: stack, onde moram as páginas/rotas públicas, onde ficam variáveis de ambiente, pipeline de deploy, se existe `project-context.md`.
+2. **Nunca invente dado de negócio nem status de conformidade.** O que não dá pra verificar no repo (ex.: "o certificado SSL está configurado no provedor?", "o DPO foi nomeado?") vira PENDÊNCIA DE VERIFICAÇÃO MANUAL, nunca um chute de severidade. Não assuma que um arquivo `privacidade.md` está correto só por existir: leia o conteúdo antes de dar 🟢.
+3. **Prova concreta por achado.** "Poderia ser melhor" não é achado. Cada linha cita arquivo:linha (ou rota/config específica) e a evidência do que falta ou está errado.
+4. **Saída padronizada por área**, tabela markdown, sem texto antes:
+
+```
+| # | Item | Onde (arquivo/rota) | O que falta ou está errado | Severidade | Executor da correção |
+```
+
+5. **Régua de severidade** (a mesma nas 7 áreas):
+
+| Símbolo | Nome | Critério |
+|---|---|---|
+| 🔴 | Bloqueia launch | Quebra o produto, expõe dado sensível, ou viola lei/política de plataforma. Não lança com isso aberto. |
+| 🟠 | Alto | Não impede o lançamento tecnicamente, mas custa caro logo na primeira semana (perda de conversão, achado de segurança médio, indexação quebrada). Resolver antes ou no dia seguinte ao launch. |
+| 🟡 | Médio | Deveria ser resolvido, mas não muda o resultado do lançamento. Vira backlog pós-launch. |
+| 🟢 | Ok | Checado e conforme. Sem ação. |
+
+6. **Nunca corrija cego.** O output é diagnóstico. Cada achado aponta o EXECUTOR certo (a skill/CLI que resolve), nunca a correção já aplicada por esta skill.
+7. **Uma área por vez** ao investigar, mas rode as 7 em paralelo (subagentes) quando possível: elas são independentes entre si.
+
+## As 7 áreas (rodar em paralelo)
+
+| # | Área | Referência |
+|---|---|---|
+| 01 | Técnico / build / erros | [references/01-tecnico-build.md](references/01-tecnico-build.md) |
+| 02 | Segurança | [references/02-seguranca.md](references/02-seguranca.md) |
+| 03 | SEO / descoberta | [references/03-seo-descoberta.md](references/03-seo-descoberta.md) |
+| 04 | Analytics / medição | [references/04-analytics-medicao.md](references/04-analytics-medicao.md) |
+| 05 | Conteúdo / copy / prova social | [references/05-conteudo-prova-social.md](references/05-conteudo-prova-social.md) |
+| 06 | Legal / LGPD | [references/06-legal-lgpd.md](references/06-legal-lgpd.md) |
+| 07 | Infra / deploy / rollback | [references/07-infra-deploy-rollback.md](references/07-infra-deploy-rollback.md) |
+
+Depois das 7:
+
+| # | Passo | Referência |
+|---|---|---|
+| 08 | Fusão e priorização | [references/08-fusao-priorizacao.md](references/08-fusao-priorizacao.md) |
+| 09 | Persistência no project-context.md | [references/09-persistencia-project-context.md](references/09-persistencia-project-context.md) |
+
+## Como rodar
+
+1. Confira o gate de estágio (seção acima). Sem `mvp`/`production`, pare ou avise antes de seguir.
+2. Detecte quais das 7 áreas se aplicam ao projeto (ex.: projeto sem superfície web pública pode pular a área 03; projeto sem LGPD/dados pessoais pode encurtar a área 06, mas nunca pule sem justificar em 1 linha).
+3. Dispare as 7 áreas como subagentes em paralelo, cada um carregando seu prompt de `references/`.
+4. Colete as 7 tabelas.
+5. Rode o passo 08 (fusão): dedup, ordena por severidade, monta a lista final priorizada com recomendação GO / GO COM RESSALVAS / NO-GO (a skill nunca decide sozinha; é uma leitura dos achados, quem decide é o dono do projeto).
+6. Rode o passo 09 (persistência): grava o resumo datado no `project-context.md`.
+7. Entregue o diagnóstico consolidado. As 7 tabelas por área ficam como anexo.
+
+## Relação com as outras skills
+
+- **`security-audit-pentest`**: aprofundamento de segurança. A área 02 aqui é uma varredura leve (superfície exposta); achados que precisam de prova de exploração ("como se explora") vão pra `security-audit-pentest`, não são recauchutados aqui.
+- **`site-launch-kit`**: quando a superfície do achado é SITE (CTA, prova social, Open Graph, schema local, robots/sitemap, LGPD do site, medição), o executor da correção é `site-launch-kit`. Esta skill não repete as 15 rodadas: só aponta qual rodada resolve o achado.
+- **`seo-audit`**: diagnóstico amplo de ranking/tráfego/core web vitals. A área 03 aqui é só indexabilidade básica (o site consegue ser encontrado), não é auditoria de SEO completa.
+- **Modo "Auditoria 360°" do `wizz-router`**: auditoria ampla de um projeto já em produção, por área técnica (código, banco, design, growth...), sem o recorte de "estamos prestes a lançar" nem o gate de estágio. Use launch-readiness para o evento de lançamento; use o modo 360° para saúde geral de um projeto maduro.
+
+## O que esta skill NÃO faz
+
+- Não corrige nada sozinha; aponta o executor.
+- Não decide GO/NO-GO pelo dono do projeto; entrega a leitura priorizada.
+- Não substitui `security-audit-pentest` para segurança profunda nem `site-launch-kit` para execução das 15 rodadas de site.
+- Não roda em projeto sem superfície construída (estágio de descoberta/ideação).

package/src/skills-lib/launch-readiness/references/01-tecnico-build.md

@@ -0,0 +1,26 @@
+# Área 01 · Técnico / Build / Erros
+
+Checa se o projeto sobe, roda e se comporta como código de produção. Não é code review de arquitetura (isso é `wizz-code-review` / `adversarial-reviewer`): aqui é "isso quebra no ar?".
+
+## Checagens objetivas
+
+1. **Build limpo.** Rode o build de produção do projeto (`npm run build` ou equivalente). Qualquer erro é 🔴. Warning de build que aponta comportamento quebrado em produção (ex.: variável de ambiente ausente, import quebrado) é 🟠.
+2. **Type check e lint verdes.** Erro de tipo é 🟠 (não bloqueia sempre, mas indica bug real na maioria dos casos); lint com regra de erro (não só estilo) é 🟠.
+3. **Testes passando.** Suíte de testes existente rodando vermelha é 🔴 se cobre fluxo crítico (pagamento, cadastro, auth), 🟠 caso contrário. Ausência total de testes não é achado desta skill (é decisão de produto já tomada); registre como 🟡 observação, não invente cobertura.
+4. **`console.log` e `debugger` em código de produção.** Presença em rota/componente que roda em produção é 🟡 (vaza informação em log de cliente/servidor, mas raramente quebra o produto).
+5. **Variáveis de ambiente sem fallback silencioso perigoso.** Uma env var crítica (chave de API, DSN, secret) sem valor e sem erro explícito no boot é 🔴 se o app sobe mesmo assim mascarando a falha (ex.: pagamento processa sem gateway configurado). Se o app falha alto e explícito no boot, não é achado.
+6. **Rotas/páginas quebradas.** Navegue (ou leia o roteamento) pelas páginas públicas principais listadas no `project-context.md` ou inferidas do roteador; 404/500 em página que deveria existir é 🔴. Link interno morto é 🟠.
+7. **Dependências com vulnerabilidade conhecida de severidade alta/crítica.** Rode o audit de dependências do gerenciador de pacotes do projeto. Alta/crítica em pacote de produção é 🟠 (aponte `database-and-deps` como executor); dev-only é 🟡.
+8. **Performance básica de carregamento.** Se existir métrica de Core Web Vitals já coletada (ferramenta do projeto, relatório de build), LCP/CLS ruim em página crítica é 🟡 e aponta `seo-audit` como aprofundamento; não meça do zero aqui, isso é escopo de `seo-audit`.
+
+## Regra de corte
+
+Sem rodar o build de verdade (ou ler o resultado do último CI verde/vermelho), não dê veredito de "🟢 build ok": marque como PENDÊNCIA DE VERIFICAÇÃO e explique o que faltou rodar. Não estime "provavelmente builda" sem evidência.
+
+## Formato de saída
+
+```
+| # | Item | Onde (arquivo/rota) | O que falta ou está errado | Severidade | Executor da correção |
+```
+
+Sem achado que passe na régua: responda só `NENHUM ACHADO NESTA ÁREA`.

package/src/skills-lib/launch-readiness/references/02-seguranca.md

@@ -0,0 +1,26 @@
+# Área 02 · Segurança
+
+Varredura de SUPERFÍCIE exposta antes do launch, não caça a vulnerabilidade com prova de exploração. Achado que exige um payload concreto pra provar (mass assignment, IDOR, injeção) NÃO se aprofunda aqui: registre a suspeita como 🟠 e aponte `security-audit-pentest` como executor do aprofundamento.
+
+## Checagens objetivas
+
+1. **Secret hardcoded no repositório.** Chave de API, token, senha ou string de conexão literal em código versionado é 🔴. Vale pra `.env` commitado por engano também.
+2. **HTTPS e certificado.** Site/app sem HTTPS forçado (redirect HTTP→HTTPS ausente) é 🔴. Certificado expirando em menos de 15 dias (quando verificável) é 🟠.
+3. **Painel admin/rota interna exposta sem autenticação.** Rota administrativa, dashboard interno ou endpoint de debug acessível sem login é 🔴.
+4. **Headers de segurança básicos ausentes.** Sem `Content-Security-Policy`, `X-Frame-Options`/`frame-ancestors`, ou `Strict-Transport-Security` num app com dado sensível é 🟠; aponte `web-security` como executor.
+5. **CORS aberto demais.** `Access-Control-Allow-Origin: *` numa API que aceita credenciais/token é 🔴; sem credenciais é 🟡.
+6. **Rate limiting ausente em rota sensível.** Login, cadastro, recuperação de senha ou endpoint que custa dinheiro (IA, SMS, e-mail) sem limite algum é 🟠; aponte `web-security` como executor.
+7. **Dependência com CVE crítica conhecida no caminho de produção.** Reforça o achado #7 da área 01 se aplicável a lib de auth/crypto especificamente: sobe pra 🔴.
+8. **Indício de mass assignment, IDOR ou injeção não provado ainda.** Campo de update que aceita o objeto inteiro do cliente sem allowlist, ou query montada por concatenação de string: registre como 🟠 "suspeita, precisa de prova de exploração" e aponte `security-audit-pentest`.
+
+## Regra de corte
+
+Esta área NUNCA entrega "como se explora" com payload real: isso é escopo exclusivo de `security-audit-pentest`. Se durante a varredura você já teria o payload pronto, ainda assim não o inclua aqui: registre a suspeita e a referência, para não duplicar o formato de saída das duas skills.
+
+## Formato de saída
+
+```
+| # | Item | Onde (arquivo/rota) | O que falta ou está errado | Severidade | Executor da correção |
+```
+
+Sem achado que passe na régua: responda só `NENHUM ACHADO NESTA ÁREA`.

package/src/skills-lib/launch-readiness/references/03-seo-descoberta.md

@@ -0,0 +1,27 @@
+# Área 03 · SEO / Descoberta
+
+Checa se o produto CONSEGUE ser encontrado no dia do lançamento. Não é diagnóstico de ranking, tráfego ou Core Web Vitals (isso é `seo-audit`) e, quando a superfície é SITE, não repete as rodadas de execução (isso é `site-launch-kit`, rodadas 08 a 13): aqui só confirma se o básico de indexabilidade existe.
+
+Se o projeto não tem superfície web pública indexável (ex.: app mobile-only, ferramenta interna), responda `ITEM NÃO SE APLICA` com 1 linha de justificativa e pare.
+
+## Checagens objetivas
+
+1. **`robots.txt` presente e não bloqueando tudo.** Ausente é 🟠; presente bloqueando `Disallow: /` em produção por engano é 🔴. Aponte `site-launch-kit` (rodada 13) como executor.
+2. **Sitemap presente e referenciado no `robots.txt`.** Ausente é 🟠.
+3. **Title e meta description únicos nas páginas públicas principais.** Title padrão/repetido (ex.: mesmo title em todas as páginas) é 🟠. Aponte `site-launch-kit` (rodada 08).
+4. **Open Graph configurado.** Sem `og:title`/`og:image`/`og:description`, a prévia de compartilhamento (WhatsApp, redes) sai quebrada. É 🟡, mas sobe pra 🟠 se o canal de aquisição principal do lançamento é social/WhatsApp. Aponte `site-launch-kit` (rodada 09).
+5. **Dados estruturados básicos do negócio.** Ausência não é bloqueante isolado, mas se o negócio depende de aparecer no Google local/rich snippet, é 🟡. Aponte `site-launch-kit` (rodada 12) ou `schema-markup`.
+6. **Canonical e indexação não duplicada.** Múltiplas URLs servindo o mesmo conteúdo sem `rel=canonical` é 🟡.
+7. **Domínio/DNS resolvendo pro ambiente de produção certo.** Domínio configurado mas apontando pro ambiente de staging/preview é 🔴 (achado de infra também, ver área 07; registre aqui só a parte de descoberta: se o buscador já indexou o domínio errado).
+
+## Regra de corte
+
+Não rode auditoria de ranking/backlink/palavra-chave aqui: isso é escopo do `seo-audit`, ofereça-o como próximo passo pós-launch, não execute agora.
+
+## Formato de saída
+
+```
+| # | Item | Onde (arquivo/rota) | O que falta ou está errado | Severidade | Executor da correção |
+```
+
+Sem achado que passe na régua: responda só `NENHUM ACHADO NESTA ÁREA`.

package/src/skills-lib/launch-readiness/references/04-analytics-medicao.md

@@ -0,0 +1,25 @@
+# Área 04 · Analytics / Medição
+
+Checa se o time vai conseguir SABER se o lançamento funcionou. Um lançamento sem medição não é "menos grave", é um lançamento que ninguém consegue avaliar depois: trate ausência de medição em evento-chave como achado sério, não como nice-to-have.
+
+## Checagens objetivas
+
+1. **Ferramenta de analytics instalada e disparando.** Sem nenhum GA4/pixel/ferramenta equivalente carregando nas páginas públicas é 🔴 se o lançamento depende de medir aquisição; 🟠 caso contrário.
+2. **Evento de conversão principal configurado.** O evento que representa o objetivo do lançamento (cadastro, compra, lead, download) não disparando ou não existindo é 🔴.
+3. **Evento da página de obrigado/confirmação.** Página pós-conversão sem evento de "conversão confirmada" (distinto de só "visitou a página") é 🟠. Cruza com `site-launch-kit` rodada 15 quando a superfície é site.
+4. **UTM/origem de tráfego rastreável.** Campanhas de lançamento sem UTM padronizado é 🟡: mede o quê aconteceu, mas não de onde veio.
+5. **Monitoramento de erro em produção (Sentry ou equivalente).** Projeto que já usa uma ferramenta de erro mas não está ativa no ambiente de produção é 🟠. Projeto que nunca adotou nenhuma é 🟡 (não é recomendação pra adotar Sentry agora, é registro de lacuna: decisão de adoção é do time).
+6. **Alerta de indisponibilidade/uptime.** Sem alerta configurado pra quando o produto cair no dia do lançamento (quando o tráfego é mais sensível) é 🟠.
+7. **Dashboard ou canal combinado pra acompanhar o dia do lançamento.** Ausência não é achado técnico por si, mas se ninguém sabe onde olhar os números no dia, registre como 🟡.
+
+## Regra de corte
+
+Não invente que um evento "provavelmente dispara": rode/inspecione a implementação (código do evento, ou o próprio painel da ferramenta se houver acesso) antes de marcar 🟢. Sem conseguir verificar, marque PENDÊNCIA DE VERIFICAÇÃO.
+
+## Formato de saída
+
+```
+| # | Item | Onde (arquivo/rota) | O que falta ou está errado | Severidade | Executor da correção |
+```
+
+Sem achado que passe na régua: responda só `NENHUM ACHADO NESTA ÁREA`.

package/src/skills-lib/launch-readiness/references/05-conteudo-prova-social.md

@@ -0,0 +1,25 @@
+# Área 05 · Conteúdo / Copy / Prova Social
+
+Checa se o que está escrito e mostrado é REAL e está pronto, não se a copy é boa (isso é `copywriting`/`copy-editing`). Regra central, herdada do `site-launch-kit`: nenhum dado de negócio inventado passa como conforme. O que faltar vira PENDÊNCIA, nunca um chute preenchido por estimativa.
+
+## Checagens objetivas
+
+1. **Texto placeholder em produção.** `Lorem ipsum`, `TODO`, `[inserir aqui]`, `{{ASSIM}}` ou qualquer marcador visível numa página/tela que vai ao ar é 🔴.
+2. **Prova social real.** Depoimento, avaliação ou logo de cliente sem fonte verificável (nome genérico tipo "Cliente satisfeito", nota sem origem, logo de empresa que não é cliente de fato) é 🔴: prova social falsa é risco de reputação e, em alguns casos, jurídico. Aponte `site-launch-kit` (rodada 04) quando a superfície é site.
+3. **Preço, prazo, contato correntes.** Preço/plano/telefone/e-mail/horário divergente do que o negócio pratica de verdade é 🔴. Não valide isso "por estimativa": se você não tem como confirmar o dado real, marque PENDÊNCIA e pergunte, nunca aceite o que já está escrito como correto por padrão.
+4. **Imagem real vs. stock genérico.** Foto de banco de imagem genérico em contexto que deveria ser autêntico (equipe, produto, local) é 🟡, sobe pra 🟠 se o setor depende de confiança visual (saúde, serviço presencial, financeiro). Aponte `site-launch-kit` (rodada 06).
+5. **Consistência de nome de produto/marca.** Nome do produto grafado de formas diferentes entre páginas (ex.: "MeJu" vs "Me Ju" vs "meju") é 🟡.
+6. **CTA e mensagem principal presentes e claros.** Ausência de CTA principal acima da dobra na página de entrada é 🔴 quando o objetivo do lançamento depende de conversão direta. Aponte `site-launch-kit` (rodada 01).
+7. **FAQ ou conteúdo de objeção pronto pro volume esperado.** Ausência de FAQ quando o produto tem objeção recorrente conhecida é 🟡. Aponte `site-launch-kit` (rodada 05) ou `copywriting`.
+
+## Regra de corte
+
+Nunca preencha um dado de negócio ausente "pra destravar o diagnóstico". Se não dá pra confirmar (preço, depoimento, endereço, prazo), o item vira PENDÊNCIA com "de quem obter / como obter", igual ao `site-launch-kit`. Marcar 🟢 sem checar o conteúdo real é pior que marcar PENDÊNCIA.
+
+## Formato de saída
+
+```
+| # | Item | Onde (arquivo/rota) | O que falta ou está errado | Severidade | Executor da correção |
+```
+
+Sem achado que passe na régua: responda só `NENHUM ACHADO NESTA ÁREA`.

package/src/skills-lib/launch-readiness/references/06-legal-lgpd.md

@@ -0,0 +1,25 @@
+# Área 06 · Legal / LGPD
+
+Checa exposição legal básica antes do lançamento. Não é parecer jurídico (isso exige advogado real): é uma varredura de ausências óbvias que qualquer projeto brasileiro coletando dado de usuário precisa cobrir.
+
+## Checagens objetivas
+
+1. **Política de privacidade existe e está acessível.** Ausência total, num produto que coleta dado pessoal (cadastro, formulário, cookie de analytics), é 🔴. Aponte `site-launch-kit` (rodada 14) quando a superfície é site.
+2. **Política de privacidade condiz com o que o produto faz de verdade.** Documento genérico copiado que não reflete o app real (ex.: menciona dado que não é coletado, ou não menciona um que é) é 🔴: política incorreta é pior que ausente, porque cria compromisso legal falso. Leia o conteúdo, não só confirme que o arquivo existe.
+3. **Termos de uso presentes quando há transação ou conta de usuário.** Ausência é 🟠.
+4. **Consentimento de cookies/tracking implementado quando há cookie não essencial.** Analytics/pixel disparando sem qualquer aviso de cookies é 🟠.
+5. **Canal pra exercício de direito do titular (LGPD).** Sem nenhum e-mail/formulário de contato pra solicitar exclusão/correção de dado é 🟡; se o volume de dado sensível é alto (saúde, financeiro, menor de idade), sobe pra 🟠.
+6. **Base legal e finalidade descritas para dado sensível.** Coleta de dado de categoria sensível (saúde, biometria, dado de criança) sem tratamento específico na política é 🔴: aqui o risco regulatório é maior, não deixe passar como 🟡 por padrão.
+7. **Regra setorial extra quando aplicável.** Setores regulados (saúde, financeiro, jurídico) podem exigir aviso/registro além da LGPD genérica (ex.: aviso de "não substitui consulta médica"). Se o `project-context.md` ou o conteúdo do site indicar o setor, verifique o mínimo esperado; se não souber o setor, não assuma: marque PENDÊNCIA perguntando o setor antes de avaliar este item.
+
+## Regra de corte
+
+Não copie um checklist genérico de LGPD sem ler o produto real. O achado tem que citar o que o PRODUTO faz (que dado coleta, de quem, pra quê) confrontado com o que o documento legal diz. Sem essa leitura cruzada, marque PENDÊNCIA DE VERIFICAÇÃO em vez de 🟢.
+
+## Formato de saída
+
+```
+| # | Item | Onde (arquivo/rota) | O que falta ou está errado | Severidade | Executor da correção |
+```
+
+Sem achado que passe na régua: responda só `NENHUM ACHADO NESTA ÁREA`.