wizz-method 1.16.1 → 1.17.0

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

package/src/skills-lib/launch-readiness/references/07-infra-deploy-rollback.md

@@ -0,0 +1,26 @@
+# Área 07 · Infra / Deploy / Rollback
+
+Checa se, quando (não "se") algo der errado no dia do lançamento, o time consegue reverter ou recuperar rápido. Ausência de plano de rollback é o achado mais caro desta área: um bug em produção sem caminho de volta vira incidente longo.
+
+## Checagens objetivas
+
+1. **Pipeline de deploy existe e é repetível.** Deploy manual/artesanal sem script/CI para o ambiente de produção é 🟠.
+2. **Rollback possível e testado.** Sem nenhuma forma de voltar pra versão anterior (revert de deploy, versionamento de release, feature flag) é 🔴 pra lançamento de risco alto (migração de banco, troca de fluxo de pagamento); 🟠 nos demais casos.
+3. **Migração de banco reversível.** Migration que altera/apaga coluna sem plano de reversão, rodando junto do lançamento, é 🔴.
+4. **Backup recente e testado.** Sem backup do banco de produção, ou backup nunca restaurado uma vez sequer pra validar que funciona, é 🔴 quando há dado de usuário real em jogo.
+5. **Domínio/DNS/SSL apontando pro ambiente certo.** Confirma o achado #7 da área 03 pelo lado de infra: domínio configurado mas TTL alto sem plano de propagação a tempo do lançamento é 🟠.
+6. **Paridade de ambiente (staging vs. produção).** Diferença conhecida entre o que foi testado em staging e o que vai pra produção (env var, versão de dependência, feature flag) é 🟠.
+7. **Plano de quem responde no dia.** Sem ninguém definido pra monitorar/responder no horário do lançamento (mesmo que informal) é 🟡; sobe pra 🟠 se o lançamento é fora do horário comercial normal do time.
+8. **Rate limiting / proteção contra pico na camada de infra.** Ausência de qualquer proteção (CDN, rate limit de borda) num lançamento com pico de tráfego esperado (campanha paga, imprensa) é 🟠.
+
+## Regra de corte
+
+"Rollback existe" só conta se alguém já testou o caminho de volta pelo menos uma vez, não só "em teoria dá pra reverter". Sem essa confirmação, 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`.

package/src/skills-lib/launch-readiness/references/08-fusao-priorizacao.md

@@ -0,0 +1,33 @@
+# Passo 08 · Fusão e Priorização
+
+Recebe as 7 tabelas das áreas (01 a 07) e funde num diagnóstico único. Não é uma nova rodada de investigação: é organização do que já foi levantado.
+
+## Como fundir
+
+1. **Cole as 7 tabelas** (ou as que rodaram, se alguma foi marcada `ITEM NÃO SE APLICA`).
+2. **Dedup por origem cruzada.** O mesmo problema pode aparecer em duas áreas (ex.: domínio apontando pro ambiente errado aparece na área 03 e na área 07). Mantenha uma linha só, citando as duas áreas de origem.
+3. **Ordene por severidade primeiro** (🔴 no topo, 🟢 no fim), e dentro da mesma severidade, pelo esforço estimado de correção (menor esforço primeiro): resolve mais rápido o que está mais perto do go-live.
+4. **Agrupe por executor.** Vários achados 🔴 que vão pro mesmo executor (ex.: 3 achados de `site-launch-kit`) formam um bloco só na entrega, pra virar um único despacho.
+5. **Conte pendências separadamente.** PENDÊNCIA DE VERIFICAÇÃO MANUAL não é severidade: é "não dá pra saber ainda". Liste à parte, com o que falta pra virar um veredito real.
+
+## Tabela final
+
+```
+| # | Área | Item | Severidade | Executor | Esforço estimado |
+```
+
+Seguida de:
+
+**Bloqueantes de hoje (🔴):** lista curta, só o que impede literalmente o go-live. Se a lista tiver mais de 5 itens, isso já é sinal pro dono do projeto de que o lançamento provavelmente precisa adiar, diga isso explicitamente.
+
+**Recomendação:** uma de três, nunca decidida pela skill sozinha, é leitura dos números:
+
+- **GO:** zero 🔴, poucos 🟠 documentados como aceitáveis pelo dono do projeto.
+- **GO COM RESSALVAS:** 🔴 zero, mas 🟠 relevante o suficiente pra avisar explicitamente antes do dono decidir.
+- **NO-GO:** qualquer 🔴 aberto.
+
+A recomendação é uma leitura objetiva da tabela (contagem de severidade), não um palpite. Explique o critério usado (ex.: "NO-GO porque há 2 achados 🔴 abertos: X e Y") em vez de só declarar o rótulo.
+
+## Regra de corte
+
+Não amenize a contagem pra chegar num "GO" mais confortável. Se há 🔴 aberto, a recomendação é NO-GO, mesmo que o prazo de lançamento esteja apertado: apertar o prazo é decisão do dono do projeto, não da skill.

package/src/skills-lib/launch-readiness/references/09-persistencia-project-context.md

@@ -0,0 +1,48 @@
+# Passo 09 · Persistência no project-context.md
+
+O resultado da auditoria não fica só na conversa: um resumo persiste no `project-context.md` do projeto, pra qualquer agente (ou humano) que abrir o projeto depois saber, sem re-perguntar, se ele já passou por uma auditoria de lançamento e como ficou.
+
+## Localizar o arquivo
+
+Mesmo padrão fail-open usado pelo router e pelo maestro: `grep -m1 '^stage:' {project-root}/**/project-context.md`.
+
+- **Achou o arquivo:** siga pra "Gravar a seção" abaixo.
+- **Não achou:** não bloqueie a entrega do diagnóstico por causa disso. Avise que não existe `project-context.md` pra persistir o resultado, ofereça rodar `wizz-generate-project-context` primeiro (cria o arquivo e o campo `stage:`), e entregue o diagnóstico normalmente mesmo sem persistir.
+
+## Gravar a seção
+
+A seção vive sob o cabeçalho `## Auditoria de Prontidão pra Lançamento`. Ela é SUBSTITUÍDA a cada nova rodada, não é um changelog acumulado: `project-context.md` existe pra ficar enxuto ("lean, LLM-optimized" é o objetivo declarado do próprio template), então o que importa pra um agente lendo depois é o estado ATUAL, não o histórico de rodadas antigas. Se encontrar uma seção com esse cabeçalho já existente, apague o conteúdo antigo e escreva o novo no lugar; não acumule.
+
+Template exato da seção:
+
+```markdown
+## Auditoria de Prontidão pra Lançamento
+
+Última rodada: {{YYYY-MM-DD}}. Resultado da skill `launch-readiness`; substitui a rodada anterior (não é histórico).
+
+**Resumo:** 🔴 {{n_bloqueante}} bloqueante(s) · 🟠 {{n_alto}} alto(s) · 🟡 {{n_medio}} médio(s) · 🟢 {{n_ok}} ok
+
+**Recomendação:** {{GO | GO COM RESSALVAS | NO-GO}}
+
+**Bloqueantes abertos (🔴):**
+- {{item 1, uma linha}}
+- {{item 2, uma linha}}
+
+_Sem bloqueante aberto, escreva "Nenhum bloqueante aberto." em vez da lista._
+
+**Diagnóstico completo** (as 7 tabelas por área) foi entregue na sessão de {{YYYY-MM-DD}}; esta seção é o resumo persistido, não a íntegra.
+```
+
+Insira a seção depois de `## Estado do Projeto` e antes de `## Technology Stack & Versions`, seguindo a ordem já usada pelo template (`project-context-template.md`). Se o arquivo tiver uma ordem diferente por já ter sido editado à mão, insira logo após `## Estado do Projeto`.
+
+## Atualizar o estágio (stage:)
+
+O campo `stage:` no frontmatter (`prototype|mvp|production|maintenance`) reflete o momento real do projeto, e a auditoria pode revelar que ele está desatualizado:
+
+- **Recomendação GO ou GO COM RESSALVAS, e o usuário confirma que vai lançar agora:** proponha atualizar `stage: mvp` → `stage: production` no frontmatter. Proponha, não edite sozinho: pergunte antes ("atualizo o stage do projeto pra `production`?"), porque esse campo direciona o comportamento de outros agentes (router, maestro) e mudar sem avisar é uma mutação silenciosa de configuração compartilhada.
+- **Recomendação NO-GO:** não sugira mudar o `stage:`. O projeto continua no estágio que já estava.
+- **Estágio já é `production`:** não mexa; a auditoria está sendo usada pra uma nova leva/feature, não pra estreia do projeto (ver gate de estágio no `SKILL.md`).
+
+## Regra de corte
+
+Não grave a seção com números inventados. O resumo tem que bater exatamente com a tabela final do passo 08 (fusão): mesma contagem, mesma recomendação. Se o passo 08 não rodou (ex.: usuário pediu só uma área isolada), não grave a seção completa: registre só o achado daquela área com a mesma data, deixando claro que não é uma rodada completa das 7 áreas.

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

@@ -46,7 +46,7 @@ description: "Checklist operacional de pré-lançamento de site em 15 rodadas co
 
 ## O que esta skill NÃO faz
 
-- Não redesenha layout, paleta ou conteúdo de seções (use `taste-redesign` / `impeccable`).
+- Não redesenha layout, paleta ou conteúdo de seções (use `taste-skill` / `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/taste-skill/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: taste-skill
-description: Anti-slop frontend skill for landing pages, portfolios, and redesigns. The agent reads the brief, infers the right design direction, and ships interfaces that do not look templated. Real design systems when applicable, audit-first on redesigns, strict pre-flight check. Use when building or redesigning a landing page, portfolio, or marketing site that must not look AI-generated. Detailed rules live in references/, loaded on demand.
+description: Anti-slop frontend skill for landing pages, portfolios, and redesigns or audits of existing sites and apps. The agent reads the brief, infers the right design direction, and ships interfaces that do not look templated. On an existing project it audits the current design first, identifies generic AI patterns, lists every problem found, and prioritizes fixes without breaking functionality, working with any CSS framework or vanilla CSS. Real design systems when applicable, audit-first on redesigns, strict pre-flight check. Use when building, redesigning, or auditing a landing page, portfolio, or marketing site, or when upgrading an existing site or app that looks generic or AI-generated. Detailed rules live in references/, loaded on demand.
 ---
 
 # tasteskill: Anti-Slop Frontend Skill
@@ -14,7 +14,7 @@ This file is the index. The full rulebook is split into `references/*.md`, one f
 
 1. **Read the brief, not your defaults.** Infer page kind, vibe, audience, constraints. Output a one-line "Design Read" before any code. If genuinely ambiguous, ask exactly one question.
 2. **Set the three dials** (`DESIGN_VARIANCE / MOTION_INTENSITY / VISUAL_DENSITY`, baseline `8 / 6 / 4`) from the design read. Steps 1-2 protocol and tables: [brief-and-dials](references/brief-and-dials.md).
-3. **Redesign?** Detect the mode first (preserve vs overhaul) and audit before touching anything: [redesign-protocol](references/redesign-protocol.md).
+3. **Redesign or audit of an existing project?** Detect the mode first (preserve vs overhaul) and audit before touching anything: [redesign-protocol](references/redesign-protocol.md) for mode detection and preservation rules, [design-audit](references/design-audit.md) for the full audit checklist, and [upgrade-techniques](references/upgrade-techniques.md) for the fix techniques once the audit is done.
 4. **Pick the foundation.** Real design system (official package) vs honest aesthetic build: [design-systems](references/design-systems.md).
 5. **Build with the default stack and conventions** ([architecture-conventions](references/architecture-conventions.md)) and apply the bias-correction directives for typography, color, layout, images, copy ([design-directives](references/design-directives.md)).
 6. **Add motion only when motivated:** [motion-patterns](references/motion-patterns.md).
@@ -44,6 +44,8 @@ These apply to every task, no exceptions, before reading anything else:
 | [anti-slop-tells.md](references/anti-slop-tells.md) | Forbidden AI-tell patterns, production-test tells, em-dash ban | 9 |
 | [pattern-vocabulary.md](references/pattern-vocabulary.md) | Named patterns: heroes, nav, grids, cards, scroll, text, libraries | 10 |
 | [redesign-protocol.md](references/redesign-protocol.md) | Mode detection, audit-first, preservation, modernisation levers | 11 |
+| [design-audit.md](references/design-audit.md) | Full audit checklist for existing projects: typography, color, layout, interactivity, content, components, iconography, code quality, strategic omissions | 11.G |
+| [upgrade-techniques.md](references/upgrade-techniques.md) | High-impact fix techniques for redesigns: typography, layout, motion, surface upgrades | 11.H |
 | [block-library.md](references/block-library.md) | Block Library contract and file schema | 12 |
 | [preflight-checklist.md](references/preflight-checklist.md) | Final pre-flight check matrix (mandatory gate) | 14 |