wizz-method 1.16.1 → 1.17.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "wizz-method",
-  "version": "1.16.1",
+  "version": "1.17.0",
   "description": "Wizz Method — método de agência orientado por IA em PT-BR (fork independente do BMad Method)",
   "keywords": [
     "agile",
@@ -61,9 +61,10 @@
     "rebundle": "node tools/installer/bundlers/bundle-web.js rebundle",
     "sync:check": "node tools/sync-check.mjs",
     "sync:global": "node tools/sync-global.mjs",
-    "test": "npm run test:refs && npm run test:install && npm run test:urls && npm run test:channels && npm run test:mcp && npm run test:env-vars && npm run test:cli && npm run test:deps && npm run test:dispatch-rule && npm run test:hooks && npm run test:quickupdate && npm run test:registry-schema && npm run test:module-registry && npm run test:method-refs-allowlist && npm run test:rtk-hook && npm run test:network-retry && npm run test:sync-check && npm run test:resolver && npm run test:fetch-assets && npm run test:install-smoke && npm run test:trace-report && npm run test:rehype-plugins && npm run test:workflow-path-regex && npm run test:preflight-tools-check && npm run lint && npm run lint:md && npm run format:check && npm run sync:check",
+    "test": "npm run test:refs && npm run test:install && npm run test:urls && npm run test:channels && npm run test:mcp && npm run test:env-vars && npm run test:cli && npm run test:deps && npm run test:dispatch-rule && npm run test:hooks && npm run test:decision-trace && npm run test:quickupdate && npm run test:registry-schema && npm run test:registry-lib-parity && npm run test:module-registry && npm run test:method-refs-allowlist && npm run test:rtk-hook && npm run test:network-retry && npm run test:sync-check && npm run test:resolver && npm run test:fetch-assets && npm run test:install-smoke && npm run test:trace-report && npm run test:rehype-plugins && npm run test:workflow-path-regex && npm run test:preflight-tools-check && npm run lint && npm run lint:md && npm run format:check && npm run sync:check",
     "test:channels": "node test/test-installer-channels.js",
     "test:cli": "node test/test-cli-config.js",
+    "test:decision-trace": "node test/test-decision-trace.js",
     "test:deps": "node test/test-deps-cache.js",
     "test:dispatch-rule": "node test/test-dispatch-rule-consistency.js",
     "test:env-vars": "node test/test-env-vars.js",
@@ -79,6 +80,7 @@
     "test:preflight-tools-check": "node test/test-preflight-tools-check.js",
     "test:quickupdate": "node test/test-quick-update-gate.js",
     "test:refs": "node test/test-file-refs-csv.js",
+    "test:registry-lib-parity": "node test/test-registry-lib-parity.js",
     "test:registry-schema": "node test/test-registry-schema.js",
     "test:rehype-plugins": "node test/test-rehype-plugins.mjs",
     "test:resolver": "node test/test-resolve-customization.js",

package/removals.txt

@@ -60,3 +60,9 @@ wizz-distillator
 # wizz-create-ux-design: renamed to wizz-ux (spine-based skill with separate
 # DESIGN.md and EXPERIENCE.md outputs).
 wizz-create-ux-design
+# taste-redesign: merged into taste-skill (P2 auditoria 360°, 2026-08-25).
+# The redesign audit checklist and upgrade techniques now live as
+# references/design-audit.md and references/upgrade-techniques.md inside
+# taste-skill; taste-skill's description and redesign-protocol.md cover
+# the same existing-project audit ground taste-redesign used to own.
+taste-redesign

package/skills-registry.yaml

@@ -80,9 +80,11 @@ areas:
         entry: true
         door: direcao
         when: "PORTA de direção: todo trabalho de decidir ANTES de construir. Brief visual inicial (6 decisões de estética + 3 lógicas) no kickoff. Puxa: taste-skill (direção anti-slop de brief novo) e motion-3d-director (decidir caminho motion/3D/vídeo)."
+        rel:
+          pairs_with: [taste-skill, motion-3d-director]
       - id: taste-skill
         door: direcao
-        when: "Anti-slop em briefs NOVOS: lê o brief, define a direção e audita contra defaults de AI."
+        when: "Anti-slop em briefs NOVOS: lê o brief, define a direção e audita contra defaults de AI. Também cobre projeto EXISTENTE: audita o código atual, lista problemas, prioriza fixes (protocolo de redesign)."
       - id: motion-3d-director
         door: direcao
         when: "Direção de motion/animação, 3D, WebGL, scroll cinematográfico, image-to-video. Decide o caminho ANTES de implementar."
@@ -91,7 +93,7 @@ areas:
       - id: ui-ux-pro-max
         entry: true
         door: construcao
-        when: "PORTA de construção: criar/melhorar UI (design system, paleta, tipografia, componente, página). Puxa: premium-landing-ui-researcher (landing premium greenfield), ui-component-curator (1 componente em projeto existente), impeccable (gate de polish/acessibilidade), taste-redesign (anti-slop em código existente), huashu-design (protótipo HTML hi-fi/variantes/review) e react-components (Stitch→React)."
+        when: "PORTA de construção: criar/melhorar UI (design system, paleta, tipografia, componente, página). Puxa: premium-landing-ui-researcher (landing premium greenfield), ui-component-curator (1 componente em projeto existente), impeccable (gate de polish/acessibilidade), taste-skill (anti-slop em código existente, protocolo de redesign), huashu-design (protótipo HTML hi-fi/variantes/review) e react-components (Stitch→React)."
       - id: premium-landing-ui-researcher
         door: construcao
         when: "Projeto NOVO (greenfield): cria landing premium do zero, hero, 3D high-end. Estratégia source-first."
@@ -101,9 +103,6 @@ areas:
       - id: impeccable
         door: construcao
         when: "Gate de polish/qualidade de frontend: hardening de UI, acessibilidade, anti-padrões. Refina o que já existe."
-      - id: taste-redesign
-        door: construcao
-        when: "Anti-slop em projeto EXISTENTE: audita o código atual, lista problemas, prioriza fixes."
       - id: huashu-design
         door: construcao
         when: "Direção visual + protótipo HTML hi-fi, exploração de variantes, review 5-dim, export MP4/GIF."
@@ -122,12 +121,17 @@ areas:
       - id: remotion-best-practices
         door: motion
         when: "MONTAR o filme: vídeo em React (Remotion) com áudio, SFX, legenda e timing com precisão de frame. No pipeline de vídeo é o Remotion que faz a montagem final; o hyperframes só desenha as telas mudas (regra: HyperFrames desenha, Remotion monta — ver _shared/video-pipeline.md do módulo wizz)."
+        rel:
+          after: [hyperframes]
       - id: canvas-design
         door: motion
         when: "Gerar PNG/PDF editável por código (carrossel, quote card, infográfico) com fonte/cor/logo sempre certos. Traz canvas-fonts."
       - id: algorithmic-art
         door: motion
         when: "Visual generativo por código (flow fields, ruído, partículas) para fundo/textura de hero, único a cada render, sem cara de banco de imagem."
+      - id: ctc-align
+        door: motion
+        when: "Timing por forced alignment: timestamps palavra a palavra de narração TTS para sincronizar legenda, corte de cena e animação com a fala. Fonte única de timing no pipeline de vídeo; substitui Whisper e estimativa manual."
     mcps:
       - id: magic
         when: "Gerar/refinar componentes prontos via 21st.dev (UI builder, inspiration, refiner)."
@@ -140,15 +144,23 @@ areas:
     clis:
       - id: 21st-cli
         when: "Fonte PAGA complementar (catálogos gratuitos como React Bits/Cult UI/Componentry vêm primeiro; gate de aprovação do usuário). Buscar, inspecionar, instalar e publicar componentes no 21st.dev via terminal (search/get/add/publish, registry do time @wizzdigitalagency). Complementa o Magic MCP (geração assistida); é o caminho de catálogo/registry e o fallback declarado quando o MCP está offline. O install traz também as skills oficiais 21st-cli-use, 21st-registry e 21st-design-sync. Login interativo: `21st login` (em CI usar env API_KEY_21ST)."
+        rel:
+          pairs_with: [magic]
         check: "command -v 21st"
         install: "npm i -g @21st-dev/cli && npx @21st-dev/cli install-skill"
       - id: hyperframes
         when: "DESENHAR telas de vídeo em HTML/CSS (HTML→MP4, agent-native, 20+ skills): cena isolada e MUDA — maqueta de WhatsApp/ChatGPT, gráfico animado, título, loop. NÃO usar para montagem com áudio/SFX/legenda sincronizada (posicionador de áudio falhou em produção, ~2,76s de drift; CSS vaza entre telas): a montagem final é do Remotion (regra: HyperFrames desenha, Remotion monta — ver _shared/video-pipeline.md do módulo wizz). Precisa ffmpeg + Node 22 + Chrome headless."
+        not_when: "Montagem com áudio/SFX/legenda sincronizada (posicionador de áudio falhou em produção, ~2,76s de drift; CSS vaza entre telas)."
+        rel:
+          before: [remotion-best-practices]
         platform: [darwin, linux]
         check: "test -d $HOME/.claude/skills/hyperframes"
         # Pin de supply chain (2026-08-23): clone temporário + checkout do SHA
         # + `skills add` do path local. Atualizar conscientemente.
-        install: 'd="$(mktemp -d)" && git clone https://github.com/heygen-com/hyperframes.git "$d" && git -C "$d" checkout 59a69a145bfbd0f10dee72246b68ee5d9bd71063 && npx skills add "$d" -g -y --copy && rm -rf "$d"'
+        # Neutraliza remotion-to-hyperframes: o bundle instala uma skill de
+        # migração Remotion→HyperFrames proibida pela regra do pipeline
+        # (_shared/video-pipeline.md: HyperFrames desenha, Remotion monta).
+        install: 'd="$(mktemp -d)" && git clone https://github.com/heygen-com/hyperframes.git "$d" && git -C "$d" checkout 59a69a145bfbd0f10dee72246b68ee5d9bd71063 && npx skills add "$d" -g -y --copy && rm -rf "$d" && rm -rf "$HOME/.claude/skills/remotion-to-hyperframes"'
       - id: claude-video
         when: "Analisar/entender vídeo EXISTENTE: baixa, extrai frames e transcreve para resumir, achar momentos ou diagnosticar footage. NÃO cria vídeo. Precisa ffmpeg + yt-dlp (+ Groq/OpenAI p/ transcrição sem legenda)."
         platform: [darwin, linux]
@@ -175,6 +187,12 @@ areas:
         check: "test -x ./tools/ctc-align/.venv/bin/ctc-forced-aligner"
         install: 'mkdir -p tools/ctc-align && uv venv --python 3.12 tools/ctc-align/.venv && uv pip install --python tools/ctc-align/.venv/bin/python "git+https://github.com/MahmoudAshraf97/ctc-forced-aligner.git"'
         verify: "command -v ffmpeg >/dev/null 2>&1 && command -v uv >/dev/null 2>&1"
+      - id: fal-video
+        when: "GERAR vídeo/imagem por IA (Veo/Kling/Wan e outros modelos via API da fal.ai), estilo UGC/ad-ready. Substitui o arcads: mesmo caso de uso (vídeo gerado por IA), custo 50-95% menor por vídeo, sem clone-and-run pesado. Precisa FAL_KEY em .env. Sem CLI binária oficial: usa o client Node oficial @fal-ai/client como dependência do projeto."
+        platform: [darwin, linux]
+        check: "test -f node_modules/@fal-ai/client/package.json"
+        # Pin de supply chain (2026-08-25): versão fixa (client oficial fal.ai); atualizar conscientemente.
+        install: "npm install @fal-ai/client@1.10.1"
     references:
       - "references/premium-agency-rules.md (regras $150k-tier, importadas por impeccable/huashu no modo high-end)"
 
@@ -306,14 +324,6 @@ areas:
           args: ["-y", "mcp-meta-ads@1.0.0"]
           env:
             META_ACCESS_TOKEN: "${META_ACCESS_TOKEN}"
-    clis:
-      - id: arcads
-        when: "GERAR vídeo-ad e imagem por IA (Seedance/Sora/Veo/Kling/OmniHuman + Nano Banana) e publicar como Meta ad. Clone-and-run no projeto: git clone + ./scripts/setup.sh; precisa Python 3.10+ e ARCADS API key em .env (META_ACCESS_TOKEN opcional p/ publicar)."
-        platform: [darwin, linux]
-        check: "test -d ./arcads-claude-code"
-        # Pin de supply chain (2026-08-23): checkout de SHA fixo; atualizar conscientemente.
-        install: "git clone https://github.com/krusemediallc/arcads-claude-code.git arcads-claude-code && git -C arcads-claude-code checkout 0bfafb256cfce3ff4447d7ea1611a37f0af536be"
-        verify: "command -v python3 >/dev/null 2>&1 && python3 -c 'import sys; sys.exit(0 if sys.version_info >= (3, 10) else 1)'"
 
   architect:
     agent: wizz-agent-architect
@@ -348,6 +358,15 @@ areas:
           args: ["-y", "@supabase/mcp-server-supabase@0.11.0", "--read-only", "--project-id", "${SUPABASE_PROJECT_REF}"]
           env:
             SUPABASE_ACCESS_TOKEN: "${SUPABASE_ACCESS_TOKEN}"
+    clis:
+      - id: sentry-cli
+        when: "CONDICIONAL — só ofereça se o projeto JÁ usa Sentry (existe SENTRY_DSN no env, sentry.properties, ou '@sentry/' no package.json) E o estágio é produção: subir release/sourcemaps, associar commits, monitorar erro em deploy. Nunca default e nunca sugerir ADOTAR Sentry só por causa desta CLI — é suporte a um Sentry que já existe, não uma recomendação de ferramenta."
+        not_when:
+          - "Projeto ainda não usa Sentry (sem SENTRY_DSN, sentry.properties ou '@sentry/' no package.json)."
+          - "Fora de estágio de produção."
+        check: "sentry-cli --version"
+        # Pin de supply chain (2026-08-25): versão fixa; atualizar conscientemente.
+        install: "npm install -g @sentry/cli@3.6.2"
 
   qa:
     agent: wizz-qa
@@ -355,6 +374,15 @@ areas:
     skills:
       - id: adversarial-reviewer
         when: "Passe único adversarial, ad hoc, fora de workflow — 'tear this apart' num trecho colado, sem contexto de projeto. Não confundir com wizz-review-adversarial-general (camada interna 'Blind Hunter' chamada só por wizz-code-review) nem com wizz-code-review (orquestrador bmm: 3 camadas paralelas + triagem, para review real de diff/PR)."
+      - id: security-audit-pentest
+        when: "Auditoria/pentest de segurança do app inteiro — 'auditar segurança', 'pentest', 'encontrar vulnerabilidades', varredura antes de release. Só para teste de segurança AUTORIZADO (seus sistemas ou de clientes com permissão): ferramenta dual-use, nunca usar contra alvo sem autorização."
+      - id: launch-readiness
+        when: "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. Gatilhos: 'tá pronto pra lançar?', 'auditoria de pré-lançamento', 'checklist de release amplo', 'o que falta antes de ir pra produção'. Gate por estágio: só roda de verdade em mvp/production, e recusa educadamente em estágio de descoberta/ideação. Diagnostica e prioriza por severidade (bloqueia/alto/médio/ok), nunca corrige cego: aponta security-audit-pentest pra aprofundar segurança com prova de exploração e site-launch-kit pra executar a correção quando a superfície do achado é site. Resultado persiste numa seção datada do project-context.md."
+        not_when:
+          - "Estágio de descoberta/ideação: projeto ainda sem superfície construída pra auditar (sem project-context.md, ou stage 'prototype' vazio)."
+          - "Correção de um achado isolado de site já identificado: nesse caso vá direto pra site-launch-kit."
+        rel:
+          pairs_with: [site-launch-kit, security-audit-pentest]
       - id: agent-browser
         when: "Verificação visual/browser, preencher forms, screenshots, testar UI no navegador. CLI já instalado (não é MCP); browser SEMPRE via agent-browser, nunca Playwright."
     clis:
@@ -363,6 +391,18 @@ areas:
         check: "agent-browser --version"
         # Pin de supply chain (2026-08-23): versão fixa; atualizar conscientemente.
         install: "npm install -g agent-browser@0.34.0"
+      - id: strix
+        when: "CONDICIONAL, nunca default — executor de pentest AUTÔNOMO e OFENSIVO (agentes de IA que rodam o app, exploram e VALIDAM vulnerabilidades com PoC real). Complementa security-audit-pentest: aquela skill é a metodologia/checklist humana; o Strix é o executor automatizado. Ferramenta dual-use: SÓ contra alvo próprio ou com AUTORIZAÇÃO ESCRITA do dono do sistema e ESCOPO definido — nunca contra alvo de terceiros sem permissão. Roda SEMPRE dentro do sandbox Docker isolado que a própria ferramenta provê (jamais direto no host). Gate condicional: ofereça apenas mediante confirmação explícita do usuário, com escopo e autorização declarados; jamais acione por padrão silencioso. RETORNO DEFENSIVO OBRIGATÓRIO: o executor (subagente) SEMPRE devolve o achado em formato defensivo — falha, severidade, evidência mínima e correção — nunca payload/exploit cru ou arma pronta; assim o revisor recebe conteúdo defensivo pra corrigir, não instrução de ataque. Precisa de Docker rodando e de uma LLM API key configurada."
+        not_when: "Sem alvo próprio ou sem autorização escrita e escopo definido do dono do sistema; nunca acionar por padrão silencioso."
+        rel:
+          pairs_with: [security-audit-pentest]
+        platform: [darwin, linux]
+        check: "command -v strix"
+        # Pin de supply chain (2026-08-25): versão fixa do pacote pip; o sandbox
+        # é a imagem pinada ghcr.io/usestrix/strix-sandbox:1.3.0, puxada no 1º run
+        # dentro do Docker isolado. Atualizar conscientemente.
+        install: "pipx install strix-agent==1.5.3"
+        verify: "command -v docker >/dev/null 2>&1 && docker info >/dev/null 2>&1"
 
   analyst:
     agent: wizz-agent-analyst
@@ -371,16 +411,7 @@ areas:
       - id: inicio-de-projeto
         when: "Kickoff LEVE de engenharia: stack, personas, glossário, princípios, estrutura de pastas, checklist. Atalho sem cerimônia de PRD."
       - id: implementation-planner
-        when: "Plano técnico de implementação de site/app premium pós-direção aprovada."
-    mcps:
-      - id: exa
-        when: "Pesquisa web/prior-art durante planejamento (web search, descoberta de fontes)."
-        server:
-          command: npx
-          # Pin de supply chain (2026-08-23): versão fixa; atualizar conscientemente.
-          args: ["-y", "exa-mcp-server@3.4.1"]
-          env:
-            EXA_API_KEY: "${EXA_API_KEY}"
+        when: "Plano técnico de implementação de site/app premium pós-direção aprovada. Pesquisa web/prior-art durante o planejamento usa a tool nativa WebSearch (sem custo/MCP metered — o MCP exa foi removido em 2026-08-25)."
 
   memoria:
     agent: wizz-memoria

package/src/bmm-skills/3-solutioning/wizz-generate-project-context/project-context-template.md

@@ -4,6 +4,7 @@ user_name: '{{user_name}}'
 date: '{{date}}'
 sections_completed: ['technology_stack']
 existing_patterns_found: { { number_of_patterns_discovered } }
+stage: '{{project_stage}}' # prototype|mvp|production|maintenance
 ---
 
 # Project Context for AI Agents
@@ -12,6 +13,10 @@ _This file contains critical rules and patterns that AI agents must follow when
 
 ---
 
+## Estado do Projeto
+
+_Documented after discovery phase (estágio atual, o que está no ar, o que falta)_
+
 ## Technology Stack & Versions
 
 _Documented after discovery phase_

package/src/bmm-skills/3-solutioning/wizz-generate-project-context/steps/step-01-discover.md

@@ -38,7 +38,18 @@ First, check if project context already exists:
 - If exists: Read complete file to understand existing rules
 - Present to user: "Found existing project context with {number_of_sections} sections. Would you like to update this or create a new one?"
 
-### 2. Discover Project Technology Stack
+### 2. Determine Project Stage
+
+Infer the project's lifecycle stage from repo signals before going deeper:
+
+- No deploy config, few commits, scaffolding only → likely `prototype`
+- Deployed but still shaping core flows, no monitoring/CI → likely `mvp`
+- CI/CD, monitoring, error tracking, real users → likely `production`
+- Low commit velocity, mostly fixes/deps → likely `maintenance`
+
+Present the inferred stage and confirm with the user: "Pelos sinais do repo, este projeto parece estar em **{{inferred_stage}}**. Confere?" Use the confirmed value for `stage:` in the frontmatter.
+
+### 3. Discover Project Technology Stack
 
 Load and analyze project files to identify technologies:
 
@@ -61,7 +72,7 @@ Load and analyze project files to identify technologies:
 - Linting and formatting configs (.eslintrc, .prettierrc, etc.)
 - Testing configurations (jest.config.js, vitest.config.ts, etc.)
 
-### 3. Identify Existing Code Patterns
+### 4. Identify Existing Code Patterns
 
 Search through existing codebase for patterns:
 
@@ -85,7 +96,7 @@ Search through existing codebase for patterns:
 - Documentation requirements
 - README and API doc patterns
 
-### 4. Extract Critical Implementation Rules
+### 5. Extract Critical Implementation Rules
 
 Look for rules that AI agents might miss:
 
@@ -117,7 +128,7 @@ Look for rules that AI agents might miss:
 - PR review requirements
 - Deployment procedures
 
-### 5. Initialize Project Context Document
+### 6. Initialize Project Context Document
 
 Based on discovery, create or update the context document:
 
@@ -131,7 +142,7 @@ Initialize frontmatter fields.
 Load existing context and prepare for updates
 Set frontmatter `sections_completed` to track what will be updated
 
-### 6. Present Discovery Summary
+### 7. Present Discovery Summary
 
 Report findings to user:
 

package/src/bmm-skills/3-solutioning/wizz-generate-project-context/steps/step-03-complete.md

@@ -77,6 +77,10 @@ _This file contains critical rules and patterns that AI agents must follow when
 
 ---
 
+## Estado do Projeto
+
+{{stage_and_current_status}}
+
 ## Technology Stack & Versions
 
 {{concise_technology_list}}
@@ -196,6 +200,7 @@ sections_completed:
 status: 'complete'
 rule_count: { { total_rules } }
 optimized_for_llm: true
+stage: '{{project_stage}}' # prototype|mvp|production|maintenance
 ---
 ```
 

package/src/bmm-skills/4-implementation/wizz-retrospective/customize.toml

@@ -30,7 +30,9 @@ activation_steps_append = []
 #   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
 #     (glob patterns are supported; the file's contents are loaded and treated as facts).
 
-persistent_facts = []
+persistent_facts = [
+  "file:{project-root}/**/project-context.md",
+]
 
 # Scalar: executed at the end of Phase 5 (Close), after the retrospective
 # document is saved and sprint-status is updated. Override wins.

package/src/bmm-skills/4-implementation/wizz-sprint-planning/customize.toml

@@ -30,7 +30,9 @@ activation_steps_append = []
 #   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
 #     (glob patterns are supported; the file's contents are loaded and treated as facts).
 
-persistent_facts = []
+persistent_facts = [
+  "file:{project-root}/**/project-context.md",
+]
 
 # Scalar: executed when the workflow reaches its final step,
 # after sprint-status.yaml is generated and validated. Override wins.

package/src/modules/wizz/_shared/encerramento.md

@@ -1,11 +1,15 @@
 # Protocolo de Encerramento Wizz
 
+**Antes de montar o bloco:** confira o entregável contra o brief original. Faltou algo? Liste em `⚠️ Não coberto`. Se está tudo coberto, não adicione essa linha.
+
 Toda vez que você terminar uma tarefa ou explicar um serviço, encerre **exatamente** neste formato. Linguagem fácil, frases curtas, em PT-BR. Sem jargão.
 
 ```
 ✅ O que fiz
 <1 a 2 frases simples, como se explicasse para um cliente>
 
+⚠️ Não coberto: <itens> (só quando houver diff contra o brief original)
+
 ➡️ Próximo passo
 <qual agente chamar OU o que fazer agora>
 
@@ -34,3 +38,21 @@ Se preferir já partir pro código, chame o wizz-agent-dev.
 🎯 Comando: /wizz:designer
 💾 Quer que eu salve a estrutura no cerebro?
 ```
+
+## Marcador de decisão (telemetria, opt-in)
+
+Em todo pedido **roteado** (não em conversa trivial), adicione **1 linha extra** no fim da resposta, depois do bloco acima:
+
+```
+🧭 {"rota":"agent:designer","sel":["canvas-design"],"desc":[["hyperframes","carrossel é estático não vídeo"]],"gate":"ok","repetiria":true}
+```
+
+Formato exato — objeto JSON plano numa única linha, sem quebras:
+
+- `rota`: `"agent:<area>"`, `"maestro"` ou `"flat:<skill>"` — quem de fato tratou o pedido.
+- `sel`: array com os ids das skills/agentes selecionados.
+- `desc`: array de `[id_descartado, "motivo em até 6 palavras"]` — o que você considerou e não usou, e por quê.
+- `gate`: string curta com o resultado do gate aplicado (ex: `"ok"`, `"pulado"`, `"bloqueado"`).
+- `repetiria`: bool — self-eval mínima: se recebesse este pedido de novo, faria a mesma escolha?
+
+Isso é telemetria de decisão: um hook de evento Stop lê o transcript e appenda o marcador num log local, opt-in via `WIZZ_TRACE=1` (sem isso, o hook nem toca em disco). Custo: ~30-60 tokens de output, 0 de input. Não emita em conversa trivial.

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

@@ -29,7 +29,7 @@ Você é o Designer do Wizz. Cria interfaces e landing pages de alto nível, mos
 
 Para cada tarefa, **entre pela porta certa via a ferramenta `Skill`** e traga o resultado em linguagem fácil:
 - Decidir ANTES de construir (brief, direção visual, caminho de motion/3D) → `decision-maker` (puxa taste-skill, motion-3d-director)
-- Criar/melhorar UI (landing, design system, componente, polish) → `ui-ux-pro-max` (puxa premium-landing-ui-researcher, ui-component-curator, impeccable, taste-redesign, huashu-design, react-components)
+- Criar/melhorar UI (landing, design system, componente, polish) → `ui-ux-pro-max` (puxa premium-landing-ui-researcher, ui-component-curator, impeccable, taste-skill, huashu-design, react-components)
 - Executar animação e gerar mídia → `animate` (puxa design-motion-principles, remotion-best-practices, canvas-design, algorithmic-art)
 
 Sempre **mostre o visual/plano antes do código**. Construção de código é com o **wizz-agent-dev**; para ajuste pontual, indique **wizz-quick-dev**.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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