wizz-method 1.16.1 → 1.18.0

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/premium-landing-ui-researcher/references/source-first-protocol.md

@@ -35,7 +35,7 @@ Antes de qualquer rede ou MCP, inspecionar o que o usuário já tem:
 
 1. **Pasta `modelos lp/` (ou equivalente)**: rodar `find ~ -maxdepth 6 -type d -iname "modelos*lp*"` para localizar. Listar subpastas, ler package.json e README.md de cada projeto promissor. Identificar quais já tem Lenis, GSAP, R3F, OGL, Embla, Framer Motion, shaders prontos.
 2. **Projeto atual do usuário**: se houver, listar dependências instaladas (`cat package.json`) e componentes/utilities existentes que podem ser reaproveitados.
-3. **Cérebro / vault do usuário**: usar grep nos arquivos do vault (`projetos/`, `_learnings/`) para achar padrões técnicos já documentados em projetos anteriores.
+3. **Cérebro / vault do usuário**: usar grep nos arquivos do vault (`projetos/`, `_decisions/`) para achar padrões técnicos já documentados em projetos anteriores.
 
 Saída desta fase: lista de **componentes, libs e padrões reaproveitáveis** com path absoluto.
 

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 |
 

package/src/skills-lib/{taste-redesign → taste-skill}/references/design-audit.md

@@ -1,74 +1,64 @@
-# Design audit — full checklist
+> taste-skill reference file. Loaded on demand from the SKILL.md index.
+> Cross-references like "Section N" map to sibling files via the index table in ../SKILL.md.
 
-Load this file during the Diagnose step. Full audit checklist across 9 categories — Typography, Color and Surfaces, Layout, Interactivity and States, Content, Component Patterns, Iconography, Code Quality, Strategic Omissions (what AI typically forgets) — each with the generic pattern to spot and the fix.
+## 11.G REDESIGN AUDIT CHECKLIST (detail)
 
-## Design Audit
+Full checklist for the Audit Before Touching step (Section 11.B). Scan the project against every category below and list every match found, feeding the "Patterns to retire" list in 11.B. Where a finding is already governed by an always-on directive elsewhere in this skill, the item below points to that section instead of repeating the fix, so there is one source of truth for the actual rule.
 
 ### Typography
 
-Check for these problems and fix them:
-
-- **Browser default fonts or Inter everywhere.** Replace with a font that has character. Good options: `Geist`, `Outfit`, `Cabinet Grotesk`, `Satoshi`. For editorial/creative projects, pair a serif header with a sans-serif body.
+- **Browser default fonts or Inter everywhere.** Replace per the approved font list and pairings in Section 4.1.
 - **Headlines lack presence.** Increase size for display text, tighten letter-spacing, reduce line-height. Headlines should feel heavy and intentional.
-- **Body text too wide.** Limit paragraph width to roughly 65 characters. Increase line-height for readability.
+- **Body text too wide.** Cap paragraph width per Section 4.1 (`max-w-[65ch]`) and increase line-height for readability.
 - **Only Regular (400) and Bold (700) weights used.** Introduce Medium (500) and SemiBold (600) for more subtle hierarchy.
 - **Numbers in proportional font.** Use a monospace font or enable tabular figures (`font-variant-numeric: tabular-nums`) for data-heavy interfaces.
 - **Missing letter-spacing adjustments.** Use negative tracking for large headers, positive tracking for small caps or labels.
-- **All-caps subheaders everywhere.** Try lowercase italics, sentence case, or small-caps instead.
+- **All-caps subheaders everywhere.** Try lowercase italics, sentence case, or small-caps instead. (Distinct from the eyebrow-frequency rule in Section 4.7: this is about styling, that is about how often an eyebrow appears at all.)
 - **Orphaned words.** Single words sitting alone on the last line. Fix with `text-wrap: balance` or `text-wrap: pretty`.
 
 ### Color and Surfaces
 
-- **Pure `#000000` background.** Replace with off-black, dark charcoal, or tinted dark (`#0a0a0a`, `#121212`, or a dark navy).
-- **Oversaturated accent colors.** Keep saturation below 80%. Desaturate accents so they blend with neutrals instead of screaming.
-- **More than one accent color.** Pick one. Remove the rest. Consistency beats variety.
-- **Mixing warm and cool grays.** Stick to one gray family. Tint all grays with a consistent hue (warm or cool, not both).
-- **Purple/blue "AI gradient" aesthetic.** This is the most common AI design fingerprint. Replace with neutral bases and a single, considered accent.
-- **Generic `box-shadow`.** Tint shadows to match the background hue. Use colored shadows (e.g., dark blue shadow on a blue background) instead of pure black at low opacity.
-- **Flat design with zero texture.** Add subtle noise, grain, or micro-patterns to backgrounds. Pure flat vectors feel sterile.
+- **Pure `#000000` background or oversaturated / multi-accent colors.** Governed by the Lila Rule and saturation cap in Section 4.2, and the Section 9.A bans. Flag any instance found on the existing site.
+- **Mixing warm and cool grays.** Governed by Section 4.2 ("one palette per project"). Flag any inconsistency found.
+- **Generic `box-shadow`.** Governed by Section 4.4 (tint shadows to the background hue). Flag any pure-black, untinted shadow found.
+- **Flat design with zero texture.** Add subtle noise, grain, or micro-patterns to backgrounds to break digital flatness. Apply per the DOM-cost rule in Section 6.E (fixed, `pointer-events-none` layer only, never on scrolling containers).
 - **Perfectly even gradients.** Break the uniformity with radial gradients, noise overlays, or mesh gradients instead of standard linear 45-degree fades.
 - **Inconsistent lighting direction.** Audit all shadows to ensure they suggest a single, consistent light source.
-- **Random dark sections in a light mode page (or vice versa).** A single dark-background section breaking an otherwise light page looks like a copy-paste accident. Either commit to a full dark mode or keep a consistent background tone throughout. If contrast is needed, use a slightly darker shade of the same palette — not a sudden jump to `#111` in the middle of a cream page.
-- **Empty, flat sections with no visual depth.** Sections that are just text on a plain background feel unfinished. Add high-quality background imagery (blurred, overlaid, or masked), subtle patterns, or ambient gradients. Use reliable placeholder sources like `https://picsum.photos/seed/{name}/1920/1080` when real assets are not available. Experiment with background images behind hero sections, feature blocks, or CTAs — even a subtle full-width photo at low opacity adds presence.
+- **Random dark section in an otherwise light page (or vice versa).** Governed by the Page Theme Lock in Section 4.11. Flag it as a redesign finding; fix by committing to one theme for the whole page.
+- **Empty, flat sections with no visual depth.** Sections that are just text on a plain background feel unfinished. Add background imagery, a pattern, or an ambient gradient, sourced per the priority order in Section 4.8.
 
 ### Layout
 
-- **Everything centered and symmetrical.** Break symmetry with offset margins, mixed aspect ratios, or left-aligned headers over centered content.
-- **Three equal card columns as feature row.** This is the most generic AI layout. Replace with a 2-column zig-zag, asymmetric grid, horizontal scroll, or masonry layout.
-- **Using `height: 100vh` for full-screen sections.** Replace with `min-height: 100dvh` to prevent layout jumping on mobile browsers (iOS Safari viewport bug).
+- **Everything centered and symmetrical.** Governed by the anti-center-bias rule in Section 4.3. Flag it as a finding on redesigns; the override there still applies for editorial/manifesto briefs.
+- **Three equal card columns as a feature row.** Banned outright per Section 9.C. Replace with a 2-column zig-zag, asymmetric grid, or horizontal scroll.
+- **Using `height: 100vh` for full-screen sections.** Replace with `min-height: 100dvh` to prevent layout jumping on mobile browsers (iOS Safari viewport bug). See the viewport-stability check in the pre-flight matrix (Section 14).
 - **Complex flexbox percentage math.** Replace with CSS Grid for reliable multi-column structures.
-- **No max-width container.** Add a container constraint (around 1200-1440px) with auto margins so content doesn't stretch edge-to-edge on wide screens.
+- **No max-width container.** Add a container constraint (around 1200-1440px) with auto margins so content does not stretch edge-to-edge on wide screens.
 - **Cards of equal height forced by flexbox.** Allow variable heights or use masonry when content varies in length.
-- **Uniform border-radius on everything.** Vary the radius: tighter on inner elements, softer on containers.
+- **Uniform border-radius on everything, with no documented rule.** Section 4.4's Shape Consistency Lock allows variation only when there is a documented rule (e.g. "buttons full-pill, cards 16px, inputs 8px") followed everywhere. An existing site with radius applied at random, with no rule at all, is the audit finding here.
 - **No overlap or depth.** Elements sit flat next to each other. Use negative margins to create layering and visual depth.
-- **Symmetrical vertical padding.** Top and bottom padding are always identical. Adjust optically — bottom padding often needs to be slightly larger.
+- **Symmetrical vertical padding.** Top and bottom padding are always identical. Adjust optically; bottom padding often needs to be slightly larger.
 - **Dashboard always has a left sidebar.** Try top navigation, a floating command menu, or a collapsible panel instead.
 - **Missing whitespace.** Double the spacing. Let the design breathe. Dense layouts work for data dashboards, not for marketing pages.
 - **Buttons not bottom-aligned in card groups.** When cards have different content lengths, CTAs end up at random heights. Pin buttons to the bottom of each card so they form a clean horizontal line regardless of content above.
 - **Feature lists starting at different vertical positions.** In pricing tables or comparison cards, the list of features should start at the same Y position across all columns. Use consistent spacing above the list or fixed-height title/price blocks.
 - **Inconsistent vertical rhythm in side-by-side elements.** When placing cards, columns, or panels next to each other, align shared elements (titles, descriptions, prices, buttons) across all items. Misaligned baselines make the layout look broken.
-- **Mathematical alignment that looks optically wrong.** Centering by the math doesn't always look centered to the eye. Icons next to text, play buttons in circles, or text in buttons often need 1-2px optical adjustments to feel right.
+- **Mathematical alignment that looks optically wrong.** Centering by the math does not always look centered to the eye. Icons next to text, play buttons in circles, or text in buttons often need 1-2px optical adjustments to feel right.
 
 ### Interactivity and States
 
-- **No hover states on buttons.** Add background shift, slight scale, or translate on hover.
-- **No active/pressed feedback.** Add a subtle `scale(0.98)` or `translateY(1px)` on press to simulate a physical click.
+- **No hover states, no active/pressed feedback, no loading or empty states.** Governed by Section 4.5 (Interactive UI States: skeletal loaders, composed empty states, `-translate-y-[1px]` / `scale-[0.98]` on press). Flag every missing state found on the existing site as a redesign fix.
+- **No error states, or errors handled with `window.alert()`.** Add clear, inline error messages for forms per Section 4.5. `window.alert()` specifically is banned; it is a jarring, unstyled browser dialog.
 - **Instant transitions with zero duration.** Add smooth transitions (200-300ms) to all interactive elements.
 - **Missing focus ring.** Ensure visible focus indicators for keyboard navigation. This is an accessibility requirement, not optional.
-- **No loading states.** Replace generic circular spinners with skeleton loaders that match the layout shape.
-- **No empty states.** An empty dashboard showing nothing is a missed opportunity. Design a composed "getting started" view.
-- **No error states.** Add clear, inline error messages for forms. Do not use `window.alert()`.
 - **Dead links.** Buttons that link to `#`. Either link to real destinations or visually disable them.
 - **No indication of current page in navigation.** Style the active nav link differently so users know where they are.
 - **Scroll jumping.** Anchor clicks jump instantly. Add `scroll-behavior: smooth`.
-- **Animations using `top`, `left`, `width`, `height`.** Switch to `transform` and `opacity` for GPU-accelerated, smooth animation.
+- **Animations using `top`, `left`, `width`, `height`.** Governed by Section 6.A: animate only `transform` and `opacity`.
 
 ### Content
 
-- **Generic names like "John Doe" or "Jane Smith".** Use diverse, realistic-sounding names.
-- **Fake round numbers like `99.99%`, `50%`, `$100.00`.** Use organic, messy data: `47.2%`, `$99.00`, `+1 (312) 847-1928`.
-- **Placeholder company names like "Acme Corp", "Nexus", "SmartFlow".** Invent contextual, believable brand names.
-- **AI copywriting cliches.** Never use "Elevate", "Seamless", "Unleash", "Next-Gen", "Game-changer", "Delve", "Tapestry", or "In the world of...". Write plain, specific language.
+- **Generic names, fake-perfect numbers, placeholder brand names, AI copywriting cliches.** Governed by Section 9.D. Flag every instance found on the existing site; do not repeat the banned-word list here, see that section.
 - **Exclamation marks in success messages.** Remove them. Be confident, not loud.
 - **"Oops!" error messages.** Be direct: "Connection failed. Please try again."
 - **Passive voice.** Use active voice: "We couldn't save your changes" instead of "Mistakes were made."
@@ -79,20 +69,20 @@ Check for these problems and fix them:
 
 ### Component Patterns
 
-- **Generic card look (border + shadow + white background).** Remove the border, or use only background color, or use only spacing. Cards should exist only when elevation communicates hierarchy.
+- **Generic card look (border + shadow + white background) with no elevation purpose.** Governed by Section 4.4: use cards only when elevation communicates hierarchy.
 - **Always one filled button + one ghost button.** Add text links or tertiary styles to reduce visual noise.
 - **Pill-shaped "New" and "Beta" badges.** Try square badges, flags, or plain text labels.
 - **Accordion FAQ sections.** Use a side-by-side list, searchable help, or inline progressive disclosure.
-- **3-card carousel testimonials with dots.** Replace with a masonry wall, embedded social posts, or a single rotating quote.
+- **3-card carousel testimonials with dots.** Replace with a masonry wall, embedded social posts, or a single rotating quote. See Section 4.10 for quote length and attribution rules once the format is fixed.
 - **Pricing table with 3 towers.** Highlight the recommended tier with color and emphasis, not just extra height.
 - **Modals for everything.** Use inline editing, slide-over panels, or expandable sections instead of popups for simple actions.
 - **Avatar circles exclusively.** Try squircles or rounded squares for a less generic look.
-- **Light/dark toggle always a sun/moon switch.** Use a dropdown, system preference detection, or integrate it into settings.
+- **Light/dark toggle always a sun/moon switch.** Use a dropdown, system preference detection, or integrate it into settings. See Section 8.C for when a manual toggle is warranted at all.
 - **Footer link farm with 4 columns.** Simplify. Focus on main navigational paths and legally required links.
 
 ### Iconography
 
-- **Lucide or Feather icons exclusively.** These are the "default" AI icon choice. Use Phosphor, Heroicons, or a custom set for differentiation.
+- **Lucide or Feather icons exclusively.** Governed by Section 9.E: use Phosphor, HugeIcons, Radix, or Tabler instead.
 - **Rocketship for "Launch", shield for "Security".** Replace cliche metaphors with less obvious icons (bolt, fingerprint, spark, vault).
 - **Inconsistent stroke widths across icons.** Audit all icons and standardize to one stroke weight.
 - **Missing favicon.** Always include a branded favicon.
@@ -104,12 +94,12 @@ Check for these problems and fix them:
 - **Inline styles mixed with CSS classes.** Move all styling to the project's styling system.
 - **Hardcoded pixel widths.** Use relative units (`%`, `rem`, `em`, `max-width`) for flexible layouts.
 - **Missing alt text on images.** Describe image content for screen readers. Never leave `alt=""` or `alt="image"` on meaningful images.
-- **Arbitrary z-index values like `9999`.** Establish a clean z-index scale in the theme/variables.
+- **Arbitrary z-index values like `9999`.** Governed by Section 6.F: establish a documented z-index scale instead.
 - **Commented-out dead code.** Remove all debug artifacts before shipping.
 - **Import hallucinations.** Check that every import actually exists in `package.json` or the project dependencies.
 - **Missing meta tags.** Add proper `<title>`, `description`, `og:image`, and social sharing meta tags.
 
-### Strategic Omissions (What AI Typically Forgets)
+### Strategic Omissions (what AI typically forgets)
 
 - **No legal links.** Add privacy policy and terms of service links in the footer.
 - **No "back" navigation.** Dead ends in user flows. Every page needs a way back.
@@ -117,4 +107,3 @@ Check for these problems and fix them:
 - **No form validation.** Add client-side validation for emails, required fields, and format checks.
 - **No "skip to content" link.** Essential for keyboard users. Add a hidden skip-link.
 - **No cookie consent.** If required by jurisdiction, add a compliant consent banner.
-