wizz-method 1.16.1 → 1.18.0

package/src/skills-lib/taste-skill/references/redesign-protocol.md

@@ -18,7 +18,7 @@ Document the current state before proposing changes:
 * **Information architecture** - page tree, primary nav, key conversion paths.
 * **Content blocks** - what exists, what's doing work, what's filler.
 * **Patterns to preserve** - signature interactions, recognisable hero, copy voice.
-* **Patterns to retire** - AI-slop tells, broken layouts, dead links, generic stock imagery, perf traps.
+* **Patterns to retire** - AI-slop tells, broken layouts, dead links, generic stock imagery, perf traps. Run the full checklist in [design-audit.md](design-audit.md) (Section 11.G) against the project and list every match here.
 * **Dial reading of the existing site** - infer current `DESIGN_VARIANCE` / `MOTION_INTENSITY` / `VISUAL_DENSITY`. That's your starting point, not the baseline.
 * **SEO baseline** - current ranking pages, meta titles, structured data, OG cards. **SEO migration is the #1 redesign risk.**
 
@@ -30,7 +30,7 @@ Document the current state before proposing changes:
 * **Respect existing analytics events.** Do not rename buttons, form fields, section IDs that downstream tracking depends on.
 
 ### 11.D Modernisation Levers (priority order)
-Apply in order - stop when the brief is satisfied:
+Apply in order - stop when the brief is satisfied. Concrete techniques for each lever live in [upgrade-techniques.md](upgrade-techniques.md) (Section 11.H).
 1. **Typography refresh** - biggest visual lift per unit of risk.
 2. **Spacing & rhythm** - increase section padding, fix vertical rhythm.
 3. **Color recalibration** - desaturate, unify neutrals, keep brand accent.

package/src/skills-lib/taste-skill/references/upgrade-techniques.md

@@ -0,0 +1,33 @@
+> 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.
+
+## 11.H MODERNISATION TECHNIQUES (detail)
+
+High-impact techniques for the Modernisation Levers in Section 11.D, once the audit checklist (Section 11.G) has identified which categories need work. Grouped by Typography, Layout, and Motion/Surface. Where a technique already has a canonical skeleton or named pattern elsewhere in this skill, this file points there instead of restating it, so there is one implementation to maintain.
+
+### Typography Upgrades
+
+- **Variable font animation.** Interpolate weight or width on scroll or hover for text that feels alive.
+- **Outlined-to-fill transitions.** Text starts as a stroke outline and fills with color on scroll entry or interaction. Named pattern: "Gradient Stroke Animation" in Section 10.
+- **Text mask reveals.** Large typography acting as a window to video or animated imagery behind it. Named pattern: "Text Mask Reveal" in Section 10; use that vocabulary entry when scoping the work.
+
+### Layout Upgrades
+
+- **Broken grid / asymmetry.** Elements that deliberately ignore column structure: overlapping, bleeding off-screen, or offset with calculated randomness. Reach for this beyond the baseline anti-center-bias rule in Section 4.3 when the brief wants a stronger break from the grid.
+- **Whitespace maximization.** Aggressive use of negative space to force focus on a single element.
+- **Parallax card stacks.** Sections that stick and physically stack over each other during scroll. Implement with the canonical Sticky-Stack skeleton in Section 5.A; named pattern "Sticky Scroll Stack" in Section 10.
+- **Split-screen scroll.** Two halves of the screen sliding in opposite directions. Named pattern "Split-Screen Scroll" in Section 10.
+
+### Motion Upgrades
+
+- **Smooth scroll with inertia.** Decouple scrolling from browser defaults for a heavier, cinematic feel.
+- **Staggered entry.** Elements cascade in with slight delays, combining Y-axis translation with opacity fade. Never mount everything at once. Implement with the Scroll-Reveal Stagger skeleton in Section 5.C, or `staggerChildren` per Section 5.D.
+- **Spring physics.** Replace linear easing with spring-based motion for a natural, weighty feel on all interactive elements. Parameters and when to use them: Section 5 (Perpetual Micro-Interactions).
+- **Scroll-driven reveals.** Content entering through expanding masks, wipes, or draw-on SVG paths tied to scroll progress. Distinct from the simple enter-on-scroll stagger in Section 5.C: this is for a deliberate reveal choreography, not a generic list-item fade-in.
+
+### Surface Upgrades
+
+- **True glassmorphism.** Go beyond `backdrop-filter: blur`. Full technique (1px inner border, inset shadow, reduced-transparency fallback) and the honest Apple Liquid Glass distinction live in Section 5 (Liquid Glass / Glassmorphism) and design-systems.md Appendix C.
+- **Spotlight borders.** Card borders that illuminate dynamically under the cursor. Named pattern "Spotlight Border Card" in Section 10.
+- **Grain and noise overlays.** A fixed, `pointer-events-none` overlay with subtle noise to break digital flatness. Apply per the DOM-cost rule in Section 6.E: fixed layer only, never on a scrolling container.
+- **Colored, tinted shadows.** Shadows that carry the hue of the background rather than using generic black. Full rule in Section 4.4.

package/src/skills-lib/tracking-audit/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: tracking-audit
+description: Auditoria e diagnóstico de rastreamento de resposta direta em dois modos. Modo implantação valida pixel, CAPI, domínio verificado, eventos priorizados, template de UTM com ID, repasse do parâmetro nativo pelo checkout, higiene de nomenclatura e compra-teste por caminho. Modo diagnóstico lê as transições do funil contra a régua, separa problema de medição de problema de conversão e diz qual transição está furando. Use quando alguém perguntar "por que a venda não bate com o gerenciador", "onde está furando o funil", "meu pixel está certo?", "as UTMs estão corretas?", "o tráfego orgânico está inflado", "qual dado falta pra eu decidir", ou antes de subir campanha nova. NÃO use para desenhar plano de medição de SaaS/produto (use analytics-tracking), para decidir bid e orçamento (use paid-ads) nem para criar a oferta (use wizz-offer-forge).
+---
+
+# Tracking Audit
+
+Auditoria de rastreamento para oferta de resposta direta. Uma hora aqui evita 30 dias de campanha medida errado.
+
+A skill faz duas coisas e nada além: **valida o que foi instalado** e **diz onde o funil está furando**. Ela não cria oferta, não decide bid e não escreve copy.
+
+## Passo 0 — Achar a régua (obrigatório, sempre)
+
+Benchmark sem origem é chute. Antes de qualquer análise, resolva de onde vêm os números, nesta ordem:
+
+1. **Skill `lowticket-metodologia` instalada?** Se sim, ela tem precedência. Leia a entrada de diagnóstico de funil no INDEX dela e use os benchmarks de lá. Declare na resposta: "régua: metodologia low ticket".
+2. **O projeto tem histórico próprio?** Trinta dias de dados reais do mesmo público valem mais que qualquer benchmark de mercado. Use a mediana do próprio histórico como linha de base.
+3. **Nenhum dos dois?** Peça ao usuário. Não invente faixa, não use número de memória, não cite benchmark sem dizer de onde saiu.
+
+> Regra anti-invenção: todo número que aparecer no relatório tem fonte declarada, ou vira PENDÊNCIA. Um relatório com faixa inventada é pior que nenhum relatório, porque parece medido.
+
+## Escolher o modo
+
+| O pedido é... | Modo | Referência |
+|---|---|---|
+| Vou subir campanha, está tudo instalado? | implantação | `references/modo-implantacao.md` |
+| Está rodando e o número não fecha | diagnóstico | `references/modo-diagnostico.md` |
+| A venda não bate com o gerenciador | diagnóstico, começando por atribuição | `references/utm-e-atribuicao.md` |
+| Como monto as UTMs desta conta | implantação, só a parte de tags | `references/utm-e-atribuicao.md` |
+
+Em dúvida entre os dois: se existe dado rodando, é diagnóstico. Implantação é para o que ainda não subiu.
+
+## Os princípios que decidem no empate
+
+- **O banco próprio é a fonte de verdade.** Gerenciador e Analytics perdem venda (bloqueador, iOS, cookie recusado). O número oficial vem do banco alimentado por webhook da plataforma de pagamento. Quando as duas fontes divergem, a divergência é o achado, não um erro de leitura.
+- **O pixel mede o pixel.** Connect rate é o instante em que o `PageView` dispara, não o instante em que a pessoa vê a oferta. Subir o pixel sem consertar a página é maquiagem de métrica.
+- **Atribuir por ID, não por nome.** A UTM carrega nome e ID. Renomear campanha não pode quebrar a atribuição.
+- **Orgânico não é canal, é ausência de UTM.** O balde "organic" é destaque sem tag, direct e recompra. Taguear tudo e ver o orgânico cair é a prova da origem real.
+- **Higiene de nomenclatura é infraestrutura.** Nome de campanha sujo não se conserta depois: a plataforma continua servindo o nome antigo em cache para o que já foi entregue.
+- **Diagnóstico é do fim para o começo.** Sempre. Recuperar venda iniciada é dinheiro que já era seu; mexer em criativo com checkout furando é desperdício.
+
+## Entradas que a auditoria precisa
+
+Peça de uma vez, não uma por uma:
+
+- URL da página de vendas e da página de checkout
+- Plataforma de checkout e de pagamento
+- Print ou export do gerenciador com: cliques no link, visitas à página, checkouts iniciados, compras, valor gasto, valor atribuído
+- Acesso (ou print) do painel de atribuição, quando existir
+- O template de UTM que está colado hoje no campo de parâmetros de URL
+
+Faltou item: siga com o que dá e liste o que falta em PENDÊNCIAS. Nunca preencha buraco de dado com estimativa.
+
+## Saída
+
+Um relatório em markdown, sempre com estas quatro partes:
+
+1. **Achados por severidade.** `CRÍTICO` (o dado está errado e a decisão em cima dele também), `ALTO` (perde venda ou perde atribuição), `MÉDIO` (higiene, vai doer depois), `BAIXO` (melhoria).
+2. **A transição que está furando**, com a taxa real calculada e a régua ao lado, sempre com a fonte da régua.
+3. **O que consertar, em ordem**, seguindo a hierarquia do modo diagnóstico. Um item por linha, com quem resolve (dev, checkout, criativo, página).
+4. **Plano de tags pronto para colar**, quando o modo for implantação ou quando a auditoria encontrar UTM errada.
+
+Feche com **PENDÊNCIAS**: o que não deu para verificar e o que precisa de acesso ou de dado que não veio.
+
+## Ferramentas
+
+- Inspeção de página: CLI `agent-browser`. Nunca Playwright.
+- Nada mais é obrigatório. A auditoria funciona lendo print e página.
+
+## Quando delegar
+
+| Situação | Vai para |
+|---|---|
+| O furo é a página (LCP, mobile, blocos) | `page-cro` |
+| O furo é o criativo | `ad-creative` |
+| O furo é bid, orçamento ou estrutura de campanha | `paid-ads` |
+| Precisa desenhar medição de produto ou SaaS | `analytics-tracking` |
+| A oferta em si não fecha | `wizz-offer-forge` |

package/src/skills-lib/tracking-audit/references/modo-diagnostico.md

@@ -0,0 +1,72 @@
+# Modo diagnóstico
+
+Está rodando e o número não fecha. Este modo descobre **qual transição está furando** e separa problema de medição de problema de conversão.
+
+Régua: leia o Passo 0 do `SKILL.md`. Cada faixa citada no relatório declara de onde veio.
+
+## As 5 transições
+
+Base do funil é a visita à página, igual a 100%. A taxa real de cada transição é a etapa dividida pela **anterior**, nunca pela base.
+
+| # | Transição | O que ela revela |
+|---|---|---|
+| 1 | Cliques no anúncio → Visitas na página | Saúde técnica: velocidade, redirect, SSL, mobile, disparo do `PageView` |
+| 2 | Visitas → Checkout iniciado | Casamento entre criativo, página e oferta |
+| 3 | Checkout iniciado → Venda iniciada | Atrito de checkout: campos, meios de pagamento, frete, taxa surpresa |
+| 4 | Venda iniciada → Aprovada (PIX) | Recuperação: lembrete, prazo, instrução |
+| 5 | Venda iniciada → Aprovada (cartão) | Recusa: antifraude, parcelamento, emissor |
+
+Sempre diagnosticar **do fim para o começo**.
+
+## Hierarquia do que atacar primeiro
+
+Se dá para mexer em uma coisa só:
+
+1. **Venda iniciada → aprovada.** O ROI mais rápido do funil. Esse dinheiro já era seu.
+2. **Checkout iniciado → venda iniciada.** Ajuste barato, ganho grande.
+3. **Visitas → checkout.** Página e criativo. Mais lento e mais caro; só depois que o checkout está resolvido.
+4. **Cliques → visitas.** Técnico. Chama dev.
+
+Ordem de prioridade das métricas: vendas > checkout iniciado > CPC > hook rate > hold rate > CPM. Não se mexe em CPC se a página não converte. Não se mexe em CPA se o checkout está furando.
+
+## Medição contra conversão
+
+Antes de dizer "a conversão caiu", prove que a **medição** está de pé. As três perguntas:
+
+| Sintoma | Se for medição | Se for conversão |
+|---|---|---|
+| Cliques muito acima das visitas | `PageView` não dispara, ou dispara tarde | Página fora do ar, redirect quebrado |
+| Venda no banco e não no gerenciador | Falta CAPI, falta domínio verificado, iOS | Nada: a venda existe |
+| Venda no gerenciador e não no banco | Deduplicação ausente, evento duplicado | Nada: a venda não existe |
+| Orgânico subindo sozinho | Rota sem UTM | Recompra e boca a boca de verdade |
+| Atribuição some ao renomear campanha | Atribuição por nome, não por ID | Nada |
+
+Regra prática: se as duas fontes discordam, a discordância **é** o achado. Nunca escolha a fonte que confirma a tese.
+
+## Qual dado falta para decidir
+
+Parte do trabalho é dizer o que não dá para responder ainda. Formato:
+
+```
+PENDÊNCIA: não dá para separar atrito de checkout de desistência de preço.
+Falta: evento AddPaymentInfo.
+Custo de instalar: baixo.
+O que muda quando existir: a transição 3 vira duas, e o conserto deixa de ser chute.
+```
+
+Nunca invente o número que falta. Um "provavelmente uns 30%" contamina a decisão inteira.
+
+## ROI verdadeiro contra ROI falso
+
+- **ROI falso:** valor atribuído pelo gerenciador dividido pelo gasto do gerenciador. Conta venda que não entrou e ignora venda que entrou sem atribuição.
+- **ROI verdadeiro:** faturamento aprovado no banco próprio, menos taxa da plataforma e menos reembolso, dividido pelo gasto real do período.
+
+Sempre reporte os dois lado a lado. A diferença entre eles é o tamanho do buraco de medição.
+
+## Leitura de print do gerenciador
+
+Métricas que precisam aparecer no print para o diagnóstico rodar:
+
+cliques no link, visualizações da página, checkouts iniciados, compras (ou resultados quando a campanha otimiza para compra), valor gasto, valor atribuído.
+
+Faltou alguma: diga qual e o que ela impede de calcular. Não estime.

package/src/skills-lib/tracking-audit/references/modo-implantacao.md

@@ -0,0 +1,89 @@
+# Modo implantação
+
+Checklist executável para antes de subir campanha. Roda de cima para baixo. Cada item tem um jeito de verificar, não é declaração de fé.
+
+Régua: leia o Passo 0 do `SKILL.md` antes. Sem régua declarada, o relatório sai sem número.
+
+## 1. Página e carregamento
+
+| Verificar | Como | Reprova quando |
+|---|---|---|
+| Página abre no mobile real | `agent-browser` em viewport de celular | Layout quebra ou bloco some |
+| Tempo até o conteúdo principal | PageSpeed Insights, aba mobile | Fora da meta declarada pela régua do projeto |
+| Redirect | Abrir o link do anúncio sem encurtador no meio | Qualquer salto extra ou loop |
+| SSL | Cadeado e certificado válido no domínio final | Aviso do navegador |
+
+Furou aqui: é trabalho de dev. Não mexa em criativo antes de resolver.
+
+## 2. Pixel e servidor
+
+| Verificar | Como | Reprova quando |
+|---|---|---|
+| Pixel presente na página | Extensão de debug da plataforma ou console | Não dispara `PageView` |
+| Posição do disparo | Ver se o `PageView` sobe antes do conteúdo visível | Dispara em `onload` tardio: infla connect rate e mente sobre a visita |
+| Evento de conversão do lado do servidor (CAPI) | Painel de qualidade da plataforma | Só navegador, sem servidor |
+| Deduplicação | `event_id` igual entre navegador e servidor | Sem `event_id`: a mesma venda conta duas vezes |
+| Domínio verificado | Painel de negócio da plataforma | Não verificado: perde atribuição em iOS |
+
+> O pixel mede o pixel. Um connect rate bonito com página lenta é métrica maquiada, não conversão.
+
+## 3. Eventos priorizados
+
+Instale nesta ordem. Os quatro primeiros são obrigatórios; os outros entram quando o funil tiver a etapa.
+
+1. `PageView` — visita à página de vendas
+2. `ViewContent` — chegou ao bloco de oferta (não é o mesmo que abrir a página)
+3. `InitiateCheckout` — clicou para comprar
+4. `Purchase` — venda aprovada, com valor e moeda
+5. `AddPaymentInfo` — preencheu pagamento, separa atrito de checkout de desistência de preço
+6. `Lead` — captura, quando existir etapa de lead
+7. `Subscribe` ou evento de recorrência, quando existir
+8. Evento próprio de upsell ou order bump, quando existir
+
+Regra: evento sem valor monetário em `Purchase` inutiliza ROAS. Evento duplicado inutiliza tudo.
+
+## 4. Tags e atribuição
+
+Ver `utm-e-atribuicao.md` para os templates. O que a implantação precisa provar:
+
+- O template de UTM está colado no campo de parâmetros de URL do anúncio, não no destino do anúncio.
+- Cada parâmetro carrega nome **e** ID.
+- O parâmetro nativo da plataforma de checkout (quando existir) recebe a mesma informação empacotada, porque o checkout nem sempre repassa `utm_*`.
+- Nenhum nome de campanha, conjunto ou anúncio contém `|`, `#`, `&` ou `?`.
+- O padrão de nomenclatura está escrito em algum lugar que a próxima pessoa lê.
+
+## 5. Repasse pelo checkout
+
+Este é o item que mais falha e o mais fácil de esquecer.
+
+1. Abra a página com uma UTM de teste na URL.
+2. Clique para comprar.
+3. Na página de checkout, confirme que os parâmetros chegaram (URL, campo escondido ou painel da plataforma).
+4. Confirme que o webhook de venda entrega esses parâmetros para o destino final (banco, planilha, painel de atribuição).
+
+Quebrou entre 2 e 3: o checkout não repassa. Use o parâmetro nativo.
+Quebrou entre 3 e 4: o problema é a integração, não a tag.
+
+## 6. Compra-teste por caminho
+
+Cada rota de entrada recebe uma compra real de teste antes de investir:
+
+- anúncio
+- link da bio
+- story
+- destaque
+- direct ou conversa
+
+Para cada rota, registre: a venda apareceu no banco, apareceu no painel de atribuição, e apareceu com a origem certa. Rota que não passa nas três é rota cega.
+
+## 7. Fechamento
+
+Antes de liberar a subida, o relatório precisa responder sim para as cinco:
+
+1. A visita é medida no instante certo?
+2. A venda chega ao banco próprio?
+3. A venda sabe de qual anúncio veio, por ID?
+4. O orgânico é o que sobra depois de tudo taguear, e não um balde de preguiça?
+5. Existe pelo menos uma compra-teste aprovada por rota?
+
+Qualquer "não" vira achado `CRÍTICO` ou `ALTO`. Nada sobe com um `CRÍTICO` aberto.

package/src/skills-lib/tracking-audit/references/utm-e-atribuicao.md

@@ -0,0 +1,75 @@
+# UTM e atribuição
+
+O cimento de todo o resto. Se a tag está errada, o funil inteiro mede ficção.
+
+## A regra central
+
+Cada parâmetro carrega **nome e ID**, separados por um delimitador fixo. O nome existe para humano ler; o ID existe para a atribuição sobreviver a renomeação.
+
+```
+utm_campaign={{campaign.name}}|{{campaign.id}}
+utm_medium={{adset.name}}|{{adset.id}}
+utm_content={{ad.name}}|{{ad.id}}
+utm_term={{placement}}
+utm_source=<plataforma>
+```
+
+Cole no campo **parâmetros de URL** do anúncio, nunca no destino.
+
+## Redundância no parâmetro nativo
+
+Muito checkout não repassa `utm_*` para o webhook de venda. Quando a plataforma de checkout tem parâmetro próprio (por exemplo `xcod`, `src` ou `sck`), empacote a mesma informação lá também, com um separador longo e improvável:
+
+```
+xcod=<origem><SEP><campaign.name>|<campaign.id><SEP><adset.name>|<adset.id><SEP><ad.name>|<ad.id><SEP><placement>
+```
+
+O separador precisa ser uma string que nunca apareça em nome de campanha. Escolha uma vez e nunca mude: mudar quebra o histórico.
+
+## Delimitadores proibidos em nomes
+
+Nunca use `|`, `#`, `&` ou `?` em nome de campanha, conjunto ou anúncio. São delimitadores da própria string de tag.
+
+Violou: **recriar a campanha**. Renomear não resolve, porque a plataforma continua servindo o nome antigo em cache para as impressões já entregues.
+
+Padrão de nome que não dá problema: minúscula, sem acento, palavras separadas por hífen ou underscore, campos em ordem fixa. Escreva o padrão em algum lugar. Padrão que só existe na cabeça de alguém não é padrão.
+
+## Outras plataformas
+
+O formato é o mesmo em toda plataforma de mídia: macro nativa da plataforma preenchendo `utm_*`, mais o empacotamento no parâmetro nativo do checkout quando ele existir.
+
+| Plataforma | O que muda |
+|---|---|
+| Meta | Macros `{{campaign.name}}`, `{{campaign.id}}`, `{{adset.*}}`, `{{ad.*}}`, `{{placement}}` |
+| Google | Macros entre chaves simples, mais `{lpurl}?` na frente e `keyword`, `device`, `network` |
+| TikTok, Kwai, Taboola | Mesma estrutura, nomes de macro próprios da plataforma |
+
+Antes de escrever o template de uma plataforma, confirme o nome exato da macro na documentação dela. Macro errada entrega a string literal `{{campaign.id}}` na URL, e ninguém percebe até a primeira venda.
+
+Existe variação a mais quando há cloaker na frente do checkout: um conector extra para não quebrar a string. Confirme com quem instalou o cloaker.
+
+## O balde do orgânico
+
+"Orgânico" não é canal. É tudo que chegou sem tag: destaque do Instagram sem UTM, link na bio sem UTM, direct, recompra, boca a boca.
+
+Diagnóstico: tague **todas** as rotas próprias (bio, destaque, story, direct, e-mail, grupo) e observe o orgânico cair. O que sobrar depois disso é orgânico de verdade. O tamanho da queda é a prova de quanto o balde estava mentindo.
+
+Padrão sugerido para rota própria:
+
+```
+utm_source=instagram&utm_medium=<bio|destaque|story|direct>&utm_campaign=<nome-do-destaque-ou-post>
+```
+
+## Primeiro toque
+
+Último clique é o padrão de quase toda ferramenta, e ele esconde qual anúncio **apresentou** a oferta. Guarde o primeiro toque no seu banco (primeira UTM vista pelo visitante, com data) e compare com o último. Multi-toque simples, dois campos, resolve a maior parte das decisões de criativo.
+
+## Conferência rápida
+
+Cinco checagens que pegam quase todo erro de tag:
+
+1. Abra o anúncio em preview e leia a URL final: tem macro literal sobrando?
+2. A UTM sobrevive ao redirect até o checkout?
+3. O webhook de venda entrega os campos ao banco?
+4. Dois anúncios diferentes geram `utm_content` diferentes?
+5. Renomear um anúncio quebra a atribuição? Se quebrar, está atribuindo por nome.

package/src/skills-lib/wizz-offer-forge/SKILL.md

@@ -16,6 +16,7 @@ Um artefato mestre `OFFER-SPEC.md` contendo:
 4. **Ancoragem de Preço, Modelagem de Planos & Order Bumps / Upsells**.
 5. **Garantia Reversa / Inversão de Risco** (Risco Zero ou Ganho Duplo).
 6. **Ponte de Tráfego: Matriz de Hooks e Ângulos de Criativos**.
+7. **Plano de Medição** (eventos mínimos, padrão de UTM, metas por transição, hipótese e número que reprova).
 
 ## Princípios de Forja de Oferta
 
@@ -28,11 +29,21 @@ Um artefato mestre `OFFER-SPEC.md` contendo:
 
 ### Passo 0 — Coleta de Insumos & Ambição
 
-Consulte o contexto existente ou pergunte ao usuário:
+**Antes de perguntar qualquer coisa, leia o que já existe.** Oferta boa nasce do resultado da anterior, não de página em branco.
+
+Se a skill `cerebro` estiver instalada, rode `/cerebro ver` do projeto e faça um grep por tema em `_decisions/`. Procure especificamente: oferta anterior do mesmo público, preço que já foi testado, garantia que já foi usada, e decisão registrada que proíba algum caminho. Traga o que achou como insumo e diga na resposta de onde veio. Sem a skill instalada, pule este bloco e siga com as perguntas abaixo.
+
+Depois, consulte o contexto existente ou pergunte ao usuário:
 1. **Pesquisa de Público Prévia:** Existe um relatório da skill `pesquisa-de-publico-do-piva` ou notas de VoC? Se sim, importe como insumo primário. Se não, defina Avatar, Dor Latente e Nível de Consciência inicial.
 2. **Modelo de Negócio:** Low-ticket (R$ 10 a R$ 97), Front-end médio (R$ 197 a R$ 497) ou High-ticket / Mentoria (R$ 1.000 a R$ 10.000+)?
 3. **Veículo de Entrega:** Curso gravado, comunidade, templates/ferramentas, mentoria ao vivo, SaaS ou híbrido?
 
+### Passo 0.5 — Régua local tem precedência
+
+Se a skill `lowticket-metodologia` estiver instalada neste projeto, leia as entradas de **oferta, preço e garantia** do INDEX dela e use esses valores como régua acima dos padrões desta skill (faixas de preço, múltiplo de upsell, prazo de garantia). Declare na resposta qual régua está valendo. Onde a régua local contradisser esta skill, **a régua local vence**.
+
+Sem essa skill instalada, siga com os padrões desta skill. Nada muda.
+
 ### Passo 1 — Destilação do Mecanismo Único
 
 Consulte `references/mecanismo-unico.md`:
@@ -49,8 +60,9 @@ Formule a Promessa Primária em 1 frase de alto impacto:
 Consulte `references/empilhamento-valor.md`:
 - **Produto Principal:** O caminho mais rápido e direto ao resultado.
 - **Bônus 1 (Velocidade):** Templates, atalhos, checklists prontos que encurtam a execução.
-- **Bônus 2 (Segurança):** Como evitar o erro mais comum ou o que fazer em caso de dúvida.
-- **Bônus 3 (Próximo Passo):** O que fazer depois de atingir o primeiro marco.
+- **Bônus 2 (Quebra de Objeção):** Elimina a maior desculpa para não comprar.
+- **Bônus 3 (Blindagem / Segurança):** Como evitar o erro mais comum ou o que fazer em caso de imprevisto.
+- **Bônus 4 (Próximo Nível):** O que fazer depois de atingir o primeiro marco.
 - **Order Bump Estratégico:** Complemento impulsivo de alta margem (30-50% de take rate).
 
 ### Passo 4 — Ancoragem de Preço & Garantia Reversa
@@ -69,6 +81,20 @@ Consulte `references/ponte-trafego.md`:
   3. *Gancho da Demonstração do Mecanismo*
   4. *Gancho da História de Transformação / Case*
 
-### Passo 6 — Compilação e Entrega
+### Passo 6 — Plano de Medição
+
+Consulte `references/plano-de-medicao.md`.
+
+Uma oferta sem definição de sucesso não pode ser diagnosticada depois: quando ela não converte, ninguém sabe se o furo foi criativo, página, checkout ou a oferta em si. Este passo fecha esse buraco enquanto a promessa ainda está fresca.
+
+Derive da própria oferta, sem inventar número:
+- **Eventos mínimos** que precisam existir para medir esta promessa.
+- **Padrão de UTM** por canal de entrada.
+- **Metas por transição do funil**, calibradas para este ticket, com a fonte da régua declarada.
+- **A hipótese principal** em uma frase, e o **número que reprova a oferta**.
+
+Se a skill `tracking-audit` estiver instalada, delegue a implantação e a conferência para ela: aqui se declara o que precisa ser verdade, lá se prova que é.
+
+### Passo 7 — Compilação e Entrega
 
 Grave o artefato final em `{output_folder}/offers/OFFER-[NOME_SLUG].md` e apresente um resumo executivo com os 4 pontos de decisão para validação imediata do usuário.

package/src/skills-lib/wizz-offer-forge/references/plano-de-medicao.md

@@ -0,0 +1,74 @@
+# Plano de Medição da Oferta
+
+O sétimo bloco do `OFFER-SPEC.md`. Não é arquivo separado, é uma seção do artefato.
+
+Serve para uma coisa só: quando a oferta não converter, saber **onde** ela não converteu. Sem isso o diagnóstico vira arqueologia.
+
+Regra que atravessa tudo: **nada de número inventado**. Toda meta tem fonte declarada (régua da metodologia local, histórico do próprio projeto, ou combinado com o usuário). O que não tiver fonte fica escrito como pendência.
+
+## 1. Eventos mínimos
+
+Derive da promessa, não de uma lista pronta. A pergunta é: qual é o instante em que esta oferta foi aceita?
+
+Base para quase toda oferta de resposta direta:
+
+| Evento | Marca | Obrigatório |
+|---|---|---|
+| `PageView` | chegou à página | sim |
+| `ViewContent` | chegou ao bloco da oferta | sim |
+| `InitiateCheckout` | clicou para comprar | sim |
+| `Purchase` (com valor e moeda) | venda aprovada | sim |
+| `AddPaymentInfo` | preencheu pagamento | quando o checkout tiver a etapa |
+| evento do order bump | aceitou o bump | quando houver bump |
+| evento do upsell | aceitou o upsell | quando houver upsell |
+
+`Purchase` sem valor monetário inutiliza qualquer cálculo de retorno. Evento duplicado inutiliza todos.
+
+## 2. Padrão de UTM por canal
+
+Uma linha por rota de entrada que esta oferta vai usar. Toda rota, inclusive as próprias:
+
+```
+anúncio    utm_source=<plataforma>&utm_campaign=<nome>|<id>&utm_medium=<conjunto>|<id>&utm_content=<anúncio>|<id>
+bio        utm_source=instagram&utm_medium=bio&utm_campaign=<oferta>
+destaque   utm_source=instagram&utm_medium=destaque&utm_campaign=<nome-do-destaque>
+story      utm_source=instagram&utm_medium=story&utm_campaign=<oferta>
+e-mail     utm_source=email&utm_medium=<sequência>&utm_campaign=<oferta>
+```
+
+Rota sem UTM cai no balde do orgânico e some da análise. Se a skill `tracking-audit` estiver instalada, ela é a dona da implantação e da conferência disso.
+
+## 3. Metas por transição
+
+As cinco transições do funil, com a meta calibrada para **este** ticket e a fonte ao lado:
+
+| Transição | Meta | Fonte da meta |
+|---|---|---|
+| Cliques → visitas | | |
+| Visitas → checkout iniciado | | |
+| Checkout iniciado → venda iniciada | | |
+| Venda iniciada → aprovada (PIX) | | |
+| Venda iniciada → aprovada (cartão) | | |
+
+Preencher com régua declarada. Célula sem fonte fica vazia e vira pendência, nunca chute.
+
+## 4. Hipótese e número que reprova
+
+Duas frases, e elas são o coração do bloco:
+
+```
+Hipótese: <público> compra <promessa> a <preço> porque <mecanismo>,
+          e isso aparece como <métrica> acima de <número>.
+
+Reprova:  se depois de <volume mínimo de dados> a <métrica> ficar abaixo de <número>,
+          a oferta está errada e o próximo passo é <mudar promessa | mudar preço | mudar público>.
+```
+
+O volume mínimo importa tanto quanto o número. "Não converteu" com 40 visitas não é informação.
+
+## 5. Ponte com o tracking
+
+Este bloco **declara** o que precisa ser verdade. Ele não instala nada e não confere nada.
+
+- Com `tracking-audit` instalada: o passo seguinte é rodar o modo implantação dela usando este bloco como entrada.
+- Sem ela: entregue o bloco como checklist manual e diga que a conferência não foi feita.

package/src/skills-lib/wizz-router/SKILL.md

@@ -10,7 +10,7 @@ description: "OBRIGATÓRIO: invoque ANTES de agir em qualquer pedido não-trivia
 
 Invoque esta skill ANTES de agir em pedidos não-triviais (feature, bug, design, marketing, SEO, infra, refactor, audit, review, integração, configuração — amplo OU específico).
 
-**Exceção única:** edições de 1 linha (typo, rename) e conversa pura.
+**Exceção única:** edições de 1 linha (typo, rename) e conversa pura. **Critério objetivo (TRIVIALITY GATE):** pedido que toca ≤1 arquivo, ~≤10 linhas, sem comportamento novo, mudança de tipo conhecido → executa direto, sem acionar router/maestro.
 
 **Fora do Plan Mode:** liste candidatas via `AskUserQuestion` e aguarde confirmação ANTES de disparar. Nunca auto-dispare fora do Plan Mode.
 **Dentro do Plan Mode:** auto-dispare todas as relevantes para enriquecer o plano.
@@ -20,10 +20,12 @@ Você é o **Diretor / porta de entrada** — não o orquestrador (esse é o `wi
 
 **Nota de escopo de instalação:** esta é a única skill do catálogo onde instalação **global** (`~/.claude/skills/wizz-router`) é o padrão operacionalmente correto, não uma exceção à regra "prefer local" (`skills-registry.yaml`, Doutrina de Instalação, regra 1) — sua razão de existir é rotear mesmo fora de um projeto Wizz. Fica sincronizada com o hook global `wizz-router-enforce.js` via `npm run sync:global`.
 
-**Economia de tokens:** o hook `rtk-rewrite.sh` já cuida do RTK automaticamente (não rode `rtk --version` a cada roteamento). Antes de ler arquivos crus, prefira `/graphify query`, `/cerebro ver`, ou `grep` específico.
+**Economia de tokens:** o hook `rtk-rewrite.sh` já cuida do RTK automaticamente (não rode `rtk --version` a cada roteamento). Antes de ler arquivos crus, prefira `/cerebro ver` ou `grep` específico.
 
 ## Triagem e delegação (o coração do Diretor)
 
+**Estágio do projeto (fail-open):** `grep -m1 '^stage:' {project-root}/**/project-context.md` (ex: `_wizz-output/project-context.md`, path configurável via `output_folder`). Se achar `prototype`/`mvp`, prefira solução leve e não recomende observabilidade/infra de produção; `production`, gates de qualidade valem integralmente. Sem arquivo: siga sem mencionar estágio.
+
 Descubra o contexto: **existe `{project-root}/_wizz/`?**
 
 ### A) Dentro de projeto Wizz — você DELEGA, nunca executa
@@ -42,6 +44,8 @@ Avalie a **Área**: quantas áreas o pedido toca (design, dev, copy, seo, growth
 
 > Um agente de área só cobre a área dele. 2+ áreas exigem coordenação = trabalho do maestro; a cláusula de área decide sozinha, sem somar com mais nada.
 
+**Descoberta de capacidade (índice, não atalho de delegação):** a [tabela de roteamento flat](references/routing-table-flat.md) também pode ser consultada aqui, dentro de projeto Wizz, quando o pedido não nomeia a capacidade certa (ex.: "quero um carrossel" → índice aponta `canvas-design`). Ela só serve pra achar o nome da capacidade; a entrega continua pelo dispatch normal acima (agente da área / maestro) — nunca dispare a skill direto a partir da tabela dentro de projeto Wizz.
+
 **Exemplos calibrados de borda** (do dataset de evals, `evals/routing/dataset.json`):
 
 - *Trivial → direto (sem router):* `t07` ("trocar 'envie' por 'enviar' na linha 42"): edição de 1 linha.
@@ -55,6 +59,8 @@ Ao delegar (pro maestro ou pro agente de área), declare o brief no formato do [
 
 Não há agentes wizz nem maestro. Você é a porta de descoberta global. Fluxo: analise a intenção (pode ter várias dimensões) → mapeie candidatas pela **[tabela de roteamento](references/routing-table-flat.md)** → fora do Plan Mode, apresente via `AskUserQuestion` e confirme → dispare as aprovadas via `Skill` (em paralelo quando independentes). Se nada cobrir, use o protocolo de **skill/MCP faltante** (no fim da mesma tabela).
 
+**Ao encerrar o modo flat**, emita 1 linha máquina-legível de decision-trace — telemetria de decisão coletada por hook — no formato exato: `🧭 {"rota":"flat:<skill>","sel":["id",...],"desc":[["id_descartado","motivo≤6 palavras"]],"gate":"n/a","repetiria":true}`
+
 ## Modo Auditoria 360°
 
 Ao detectar "auditoria completa / revisa tudo / 360 / análise geral", siga **[references/auditoria-360.md](references/auditoria-360.md)**.

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

@@ -1,6 +1,6 @@
 # Tabela de Roteamento — Modo Flat
 
-Use esta tabela **só fora de projeto Wizz** (sem `_wizz/`), quando o router mapeia skills/CLIs/MCPs direto. Dentro de projeto Wizz a delegação é decidida pela regra de dispatch no SKILL.md (maestro vs agente de área) e esta tabela não é necessária.
+Use esta tabela pra mapear skills/CLIs/MCPs direto **fora de projeto Wizz** (sem `_wizz/`) — aí o router dispara a skill sozinho. **Dentro de projeto Wizz** ela também pode ser consultada como ÍNDICE DE CAPACIDADES, pra descobrir uma capacidade relevante que o usuário não nomeou (ex.: "quero um carrossel" → `canvas-design`); mas a delegação continua sendo feita pelo dispatch normal do SKILL.md (agente da área / maestro) — a tabela nunca dispara a skill direto dentro de projeto Wizz.
 
 **Verificação de existência:** antes de oferecer qualquer skill, confirme que ela existe no ambiente (catálogo de skills da sessão ou `ls ~/.claude/skills`); se não existir, não ofereça: use o protocolo de skill faltante (`find-skills`).
 
@@ -16,6 +16,7 @@ Use esta tabela **só fora de projeto Wizz** (sem `_wizz/`), quando o router map
 | Dependências, packages, vulnerabilidades, npm audit | `database-and-deps` | 2 |
 | Segurança, XSS, CSRF, SQLi, IDOR, OWASP, rate limit, CORS, clickjacking, PII na resposta, enumeração de usuário, headers | `web-security` + `auth-and-secrets` | 1 |
 | Auditoria/pentest de segurança do app inteiro, "auditar segurança", "pentest", "encontrar vulnerabilidades", varredura antes de release | `security-audit-pentest` | 1 |
+| Auditoria de prontidão pra lançamento, "tá pronto pra lançar?", checklist de release amplo (técnico, segurança, SEO, analytics, conteúdo, legal, infra), "o que falta antes de ir pra produção" | `launch-readiness` | 1 |
 | Desktop, Electron, contextIsolation, code signing | `desktop-security` | 2 |
 
 ## Área Técnica — Código e Qualidade
@@ -60,6 +61,7 @@ Use esta tabela **só fora de projeto Wizz** (sem `_wizz/`), quando o router map
 | Ideias de marketing, estratégia de marketing, posicionamento | `marketing-ideas` + `marketing-psychology` + `product-marketing-context` | 1 |
 | Paid ads, anúncios, Google Ads, Meta Ads, TikTok Ads, mídia paga | `paid-ads` + `ad-creative` + `analytics-tracking` + **MCP meta-ads** | 1 |
 | Gestão de campanha Meta/Facebook/Instagram via API real | **MCP meta-ads** (`mcp-meta-ads`) direto | 1 |
+| Pixel/UTM/atribuição erradas, "a venda não bate com o gerenciador", "onde está furando o funil", tráfego orgânico inflado, conferir tracking antes de subir campanha | `tracking-audit` (+ `analytics-tracking` se for SaaS/produto) | 1 |
 | Lançamento de feature, lançamento de produto, go-to-market | `launch-strategy` + `social-content` + `email-sequence` | 1 |
 | Site pronto pra subir, pré-lançamento de SITE, "revisa antes do deploy", checklist de go-live, ou item pontual pré-lançamento (og:image/prévia de link, FAQ com schema, robots.txt, LGPD, alt text) | `site-launch-kit` | 1 |
 | Preço, planos, pricing, monetização | `pricing-strategy` + `paywall-upgrade-cro` | 1 |
@@ -77,14 +79,13 @@ Use esta tabela **só fora de projeto Wizz** (sem `_wizz/`), quando o router map
 | Copywriting, copy, persuasão, texto de venda | `copywriting` + `humanizer` | 1 |
 | Pesquisa de público de oferta, VoC, matriz de ângulos, léxico de infoproduto | `pesquisa-de-publico-do-piva` | 1 |
 | Forjar oferta, criar oferta irresistível, mecanismo único, bônus, garantia | `wizz-offer-forge` + `pricing-strategy` | 1 |
-| Pesquisa de mercado, inteligência competitiva | `deep-research` | 2 |
+| Pesquisa de mercado, inteligência competitiva | `deep-research` (plugin externo — só se instalado) | 2 |
 
 ## Contexto e Memória
 
 | Intenção / palavras-chave | Skills a oferecer | Prioridade |
 |---|---|---|
 | O que foi decidido, contexto passado, aprendizados, histórico | `cerebro` (/ver ou /dia) | 1 |
-| Entender o codebase, mapear estrutura do projeto | `/graphify query` (antes de ler arquivos) | 1 |
 
 ---
 

package/tools/fetch-assets.mjs

@@ -4,8 +4,9 @@
 // Por que existe: `huashu-design/assets/**/*.mp3` (~30MB) e
 // `canvas-design/canvas-fonts/**/*.ttf` (~5.5MB) inflavam o pacote npm em
 // ~73%, mas só são necessários no primeiro uso real de export de vídeo
-// (BGM/SFX) ou de uma variante de fonte específica. Os arquivos continuam no
-// git (fonte de verdade); só saem do tarball publicado. Este script baixa o
+// (BGM/SFX) ou de uma variante de fonte específica. Fonte de verdade dos BGM
+// é o GitHub Release assets-v1 (fora do git e do tarball desde o P2 da
+// auditoria 360°); os SFX pequenos e as fontes seguem no git. Este script baixa o
 // bundle certo, no lugar certo, verificando sha256 (mesmo espírito do pin
 // com checksum do rtk — nunca extrai um bundle adulterado).
 //