wizz-method 1.16.1 → 1.18.0

package/src/modules/lowticket/skills/lowticket-minerador/references/rubrica.md

@@ -0,0 +1,75 @@
+# Rubrica, tabelas e réguas da mineração
+
+> A fonte canônica é `12-mineracao-ofertas.md` (§12.1-12.4) e `12a-mineracao-veredito.md` (§12.5) de `lowticket-metodologia`. Esta página é o fallback e a consulta rápida.
+
+## Veredito
+
+`DIAMANTE` · `OURO` · `MÉDIA` · `DESCARTAR`, sempre com uma frase dizendo por quê.
+
+## Sinais de longevidade
+
+| Tempo no ar | Leitura |
+|---|---|
+| menos de 14 dias | evidência insuficiente. Não modelar como comprovada |
+| 30+ dias | validação inicial |
+| 60+ dias | sinal forte |
+| 90+ dias | sinal muito forte |
+
+Quando a oferta é nova demais: *"Ainda não tem evidência suficiente para modelar. Eu aguardaria sinais de permanência ou buscaria uma segunda referência."*
+
+Volume de anúncios não se lê sozinho:
+
+- poucos anúncios por muito tempo → possível escala por orçamento
+- muitos anúncios parecidos → possível duplicação
+- vários ângulos distintos → possível expansão de criativos
+
+Cruzar sempre: **tempo + volume + repetição + estrutura + monetização.**
+
+## Reposicionamento de ticket
+
+Hipótese de teste, não regra mecânica:
+
+| Preço de origem | Vender a |
+|---|---|
+| R$67 | R$19-27 |
+| R$97 | R$27-37 |
+| R$147 | R$37-47 |
+| R$297 | ~R$97 |
+
+> Existe uma segunda régua na metodologia (valor fixo por faixa, teto em R$37) que diverge desta acima de R$97. Ver ponto em aberto 24 em `pontos-em-aberto.md`. Acima de R$97, esta tabela costuma deixar menos dinheiro na mesa.
+
+## Tabela de comparação
+
+| Critério | Oferta 1 | Oferta 2 | Oferta 3 |
+|---|---|---|---|
+| Tempo aparente | | | |
+| Volume de anúncios | | | |
+| Ticket | | | |
+| Entregável | | | |
+| Mecanismo | | | |
+| Plataforma | | | |
+| Order bump | | | |
+| Upsell | | | |
+| Cross-sell | | | |
+| Sinais de escala | | | |
+
+Fecha com **RECOMENDAÇÃO**: uma oferta escolhida, e três pontos: por que ela tem mais potencial, o que aproveitar, o que mudar.
+
+## Estrutura de entregável (hipótese)
+
+Para low ticket, uma composição que costuma funcionar: **4 entregáveis principais + 1 bônus liberado depois.** Não é regra universal; adaptar ao mercado.
+
+## Perguntas do corte fino
+
+- Onde o concorrente está deixando dinheiro?
+- O que parece desnecessariamente complexo?
+- O que poderia ser entregue de forma mais simples?
+- Existe diferença entre preço percebido e preço cobrado?
+- O order bump está ausente?
+- Cabe uma oferta complementar?
+- O entregável poderia ser empacotado melhor?
+- A promessa poderia ser mais específica?
+- Existe dor secundária que vira monetização?
+- O checkout está deixando conversão na mesa?
+
+A resposta prioriza a oportunidade **menos óbvia**.

package/src/modules/lowticket/skills/lowticket-pagina/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: lowticket-pagina
+description: Performance engineering for a low ticket direct-response sales page served to Meta traffic on mobile - fixes connect rate by cutting redirects, ordering the pixel, and hitting hard LCP, TTFB, CLS and page-weight targets, then reports before/after. Use when connect rate is below 92%, when a sales page is slow on mobile, or when building a new low ticket page. Do NOT use to write or restructure the copy, the offer or the price - this skill is the engineer, not the copywriter - and do NOT use for institutional sites or apps.
+---
+
+# Low Ticket Sales Page Engineering
+
+A direct-response page for Meta traffic is almost always opened on a phone, on a Brazilian mobile network, **inside the Instagram in-app browser**, which is slower than native Chrome or Safari. Every decision here follows from that.
+
+## The metric
+
+```
+connect rate = visualizações da página de destino ÷ cliques no link
+```
+
+**The technical fact that drives everything:** a landing page view is counted when the Meta pixel's `PageView` event fires. So connect rate measures **the moment the pixel can speak**, not the moment the person sees the offer.
+
+That creates two clocks, and both have to be optimized:
+
+| Clock | What it is | What it governs |
+|---|---|---|
+| Time to pixel | when `fbq('track','PageView')` executes | the connect rate in the ads manager |
+| Time to hero | LCP: when the largest visible element paints | the actual sale |
+
+**Integrity rule.** You can raise connect rate by moving the pixel to the top of `<head>` without making the page any faster. That is metric makeup. **Never do only that.** Move the pixel *and* fix the page. If only one is possible, say so explicitly in the final report.
+
+## Honest boundary, say it early
+
+Speed fixes the leak between the click and the page. It does not fix a bad offer, a bad creative or a bad checkout. **If connect rate is already above 92%, the problem is somewhere else** and this skill is the wrong tool. Route to `lowticket-trafego` (find the real bottleneck) or `lowticket-minerador` (the offer itself).
+
+## Source of truth
+
+Read the Cérebro state first (via the `cerebro` skill). If `lowticket-metodologia` is installed, read `knowledge/INDEX.md` + `knowledge/guardrails.md` and shard `06-pagina-vendas.md`, especially §6.3-6.4. Page structure and copy blocks live in that shard and in `12b-fabrica-de-ofertas.md` §12.7-A; conversion-side reasoning is `page-cro`. Where a generic skill contradicts the shard, the shard wins and you say so.
+
+This skill has **no memory of its own**.
+
+## Acceptance targets
+
+The job is done when all of these are met, measured **on mobile with 4G throttling**, never on desktop. Full measurement instructions in `references/metas-e-medicao.md`.
+
+| Metric | Target |
+|---|---|
+| Redirects between ad link and page | **0** |
+| TTFB | **< 200 ms** |
+| LCP | **< 2.0 s** (ideal < 1.5 s) |
+| CLS | **< 0.1** |
+| Time to `PageView` | **< 800 ms** |
+| Compressed HTML | **< 50 KB** |
+| Total weight above the fold | **< 250 KB** |
+| Own blocking JavaScript | **0 KB** |
+
+## Execution order
+
+Ordered by return on effort, not by technical elegance. Stop and report if a step blocks.
+
+1. **Diagnose.** Check redirects on the exact ad link. Measure LCP, TTFB and CLS on mobile. Find where the pixel sits in the HTML. These numbers are the "before" column.
+2. **The road.** Zero redirects. One host. Direct `https`. No shortener, no pre-sell page that only redirects.
+3. **Where the page lives.** Static HTML built ahead of time and served from a CDN. Configure cache headers.
+4. **Pixel.** First script in `<head>`. Remove the tag manager from the critical path.
+5. **Images.** Resize, then convert. `Picture` with avif+webp on the hero, lazy on everything below the fold.
+6. **Font and CSS.** System font, or a subsetted self-hosted woff2. Inline the critical CSS. Drop what is unused.
+7. **Player.** Static cover as a facade, respecting the autoplay answer.
+8. **Secondary scripts.** Defer all of them.
+9. **Re-measure.** Repeat step 1 and build the before/after table.
+
+Code patterns for steps 4 to 8 are in `references/padroes-de-codigo.md`.
+
+## Non-negotiable rules
+
+### Never
+
+- A redirect between the ad link and the page. Not a shortener, not `http→https`, not `www→no www`, not a pre-sell page that only redirects.
+- The Meta pixel inside a web worker. It improves the Lighthouse score and delays or breaks `PageView`, which **is** the connect rate. Bad trade.
+- The pixel after the CSS, after the title, or at the end of `<body>`.
+- `loading="lazy"` on the hero image, or its absence below the fold.
+- A font served from a third-party domain. It costs a DNS lookup, a TLS handshake and a new connection.
+- The VSL player script in the critical rendering path.
+- An image delivered wider than the box it renders in.
+- **Rewriting the copy, the headline, the prices, the testimonials or the offer structure.** On this task you are a performance engineer. Notice a copy problem, mention it in the report, change nothing.
+
+### Always
+
+- Static HTML, generated at build time, served from a CDN.
+- The pixel as the first script in `<head>`.
+- Explicit `width`/`height` or `aspect-ratio` on every image and video, so CLS stays at zero.
+- `preconnect` for the third-party domains that are unavoidable: player, the Meta connect domain, checkout.
+- Test with 4G throttling, never on the local network.
+- Preserve existing conversion behavior: buttons, anchors, UTM parameters on the checkout URL, CTA reveal delays synced to the video.
+
+## Asking for what is missing
+
+At most **five questions, all in one round**, and only when something essential is genuinely missing. If nothing essential is missing, ask nothing and execute. Priority:
+
+1. What is the **exact** link inside the ad? (the ad's link, not the page URL)
+2. Is there access to the code, or is it a closed page builder?
+3. Does the VSL need autoplay to work?
+4. Is a consent banner blocking scripts?
+5. What is the pixel ID?
+
+**If the page is on a closed builder**, apply everything the platform allows (pixel order, image conversion, player facade, script removal, redirect removal) and state plainly in the report which targets became unreachable and why.
+
+## The final report is mandatory
+
+Always end with the before/after table from `references/metas-e-medicao.md`, in plain Portuguese, written for someone who is not technical. Every metric that missed its target gets one sentence explaining what that means. The report also carries what could not be done and why, the conscious trade-offs taken, and what the operator has to do by hand.
+
+An optimization without the report is not finished work: the point is that the operator can see the movement and decide whether it was worth it.

package/src/modules/lowticket/skills/lowticket-pagina/references/metas-e-medicao.md

@@ -0,0 +1,70 @@
+# Metas, medição e relatório
+
+## Como medir cada meta
+
+Sempre em **mobile, com throttle de 4G**. Medir em desktop dá número bonito e diagnóstico errado.
+
+| Métrica | Alvo | Onde medir |
+|---|---|---|
+| Redirects entre anúncio e página | 0 | `curl -sIL` no link exato do anúncio |
+| TTFB | < 200 ms | DevTools → Network → primeira requisição |
+| LCP | < 2,0 s (ideal < 1,5 s) | PageSpeed Insights, aba Mobile |
+| CLS | < 0,1 | PageSpeed Insights, aba Mobile |
+| Tempo até o `PageView` | < 800 ms | DevTools → requisição para o endpoint de tracking da Meta |
+| HTML comprimido | < 50 KB | Network, coluna Size |
+| Peso acima da dobra | < 250 KB | Network, filtrado até o LCP |
+| JavaScript próprio bloqueante | 0 KB | nenhum `<script>` sem `async`/`defer` no caminho crítico |
+
+Checagem de redirects:
+
+```bash
+curl -sIL "https://link-exato-do-anuncio" -o /dev/null \
+  -w "%{num_connects} conexões · %{num_redirects} redirects · %{time_total}s\n"
+```
+
+`num_redirects` tem que dar **0**.
+
+## Armadilha de medição do player
+
+Player com autoplay inteligente confunde medidor de velocidade: o carregamento em segundo plano faz a ferramenta achar que a página nunca terminou. **Medir com o autoplay desligado e religar depois.**
+
+## Armadilha de medição do connect rate
+
+- A Meta passou a exibir que visualização da página de destino não exige mais o pixel. Ou seja, o número pode ser **estimado**, não contado: a plataforma infere se a página carregou observando quanto tempo a pessoa ficou fora do app.
+- Em auditoria com pixel corretamente instalado, campanha de **tráfego** otimizada para visualização de página mostrou número muito acima das sessões realmente medidas no analytics. Em campanha de **conversão**, os números bateram.
+- Consequência prática: rodar campanha otimizada por compra, e para medir connect rate com precisão criar uma **conversão personalizada baseada na URL da página**, que só dispara com a página realmente carregada.
+
+## Relatório final
+
+Formato fixo. Português claro, sem jargão. Quando um número não bateu a meta, uma frase explicando o que aquilo significa na prática.
+
+```
+RELATÓRIO DE PERFORMANCE
+
+| Métrica              | Antes | Depois | Meta    | Status |
+|----------------------|-------|--------|---------|--------|
+| Redirects            |       |        | 0       |        |
+| TTFB                 |       |        | < 200ms |        |
+| LCP (mobile 4G)      |       |        | < 2,0s  |        |
+| CLS                  |       |        | < 0,1   |        |
+| Tempo até o PageView |       |        | < 800ms |        |
+| HTML comprimido      |       |        | < 50KB  |        |
+| Peso acima da dobra  |       |        | < 250KB |        |
+
+O QUE FOI FEITO
+- lista curta, em português comum
+
+O QUE NÃO CONSEGUI FAZER E POR QUÊ
+- específico: limitação da plataforma, falta de acesso, ou decisão que depende do dono da página
+
+TROCAS CONSCIENTES
+- ex.: reduzi o atraso do player para preservar o autoplay, custando ~300ms de LCP
+
+O QUE PRECISA SER FEITO NA MÃO
+- ex.: trocar o link dentro do gerenciador de anúncios pela URL final
+
+O QUE VERIFICAR DEPOIS DE PUBLICAR
+- abrir a página no celular, com dados móveis, por dentro do Instagram
+- comparar cliques no link contra visualizações da página no gerenciador, por criativo
+- connect rate abaixo de 85% depois disso quase nunca é público ruim, é estrada
+```

package/src/modules/lowticket/skills/lowticket-pagina/references/padroes-de-codigo.md

@@ -0,0 +1,148 @@
+# Padrões de código
+
+## Pixel: primeiro item do `<head>`
+
+```html
+<head>
+  <meta charset="utf-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1">
+  <link rel="preconnect" href="https://connect.facebook.net" crossorigin>
+
+  <script>
+    /* o snippet do pixel exatamente como a plataforma entrega */
+    fbq('init', 'SEU_PIXEL_ID');
+    fbq('track', 'PageView');
+  </script>
+
+  <title>...</title>
+  <!-- CSS e o resto vêm depois -->
+</head>
+```
+
+Regras associadas:
+
+- Pixel **direto**, sem tag manager. Numa página única, o gerenciador de tags é uma camada inteira de latência para administrar duas tags.
+- `InitiateCheckout` no clique do botão de compra.
+- **Um pixel só.** Dois pixels disparando o mesmo evento geram duplicidade.
+- Recomendar a API de Conversões no servidor, para cobrir o que o navegador perde por bloqueador e limite de cookie.
+
+## Stack alvo
+
+Framework que gera HTML estático no build e envia zero JavaScript por padrão. **Astro é o padrão** por esse motivo: o servidor não monta nada em tempo de requisição.
+
+```
+public/                 favicon, robots.txt, headers. NÃO colocar imagem crítica aqui
+src/assets/             toda imagem que precisa ser otimizada
+src/components/         pedaços reaproveitados
+src/pages/index.astro   a página. Aceita HTML puro colado direto
+```
+
+```js
+// astro.config.mjs
+import { defineConfig } from 'astro/config';
+
+export default defineConfig({
+  site: 'https://SEU_DOMINIO',
+  image: {
+    layout: 'constrained',       // gera srcset e sizes automaticamente
+    responsiveStyles: true,      // sem isto as imagens não redimensionam
+    breakpoints: [360, 480, 640, 768, 1024, 1280],
+  },
+  build: { inlineStylesheets: 'always' },  // uma requisição bloqueante a menos
+});
+```
+
+> Com Tailwind 4, `responsiveStyles: true` pode conflitar com os utilitários. Havendo conflito, deixar `false` e escrever o CSS responsivo à mão. Testar antes de entregar.
+
+**Migração a partir de construtor:** um arquivo `.astro` aceita HTML puro. Colar o HTML exportado dentro de `index.astro` e ele já funciona. **Não reescrever a página do zero**: migrar o HTML existente e otimizar por cima. Componentizar é refinamento posterior.
+
+**Hospedagem:** qualquer CDN de borda com build estático serve. O que importa é HTML pronto servido da borda, não a marca.
+
+## Imagens
+
+Referência de decisão:
+
+| Formato | Ganho | Suporte |
+|---|---|---|
+| WebP vs JPEG | 25-35% menor | ~96% |
+| AVIF vs WebP | 20-30% menor | ~95% |
+| AVIF vs JPEG | ~50% menor | ~95% |
+
+Regra: **WebP como padrão, AVIF no herói com reserva.** AVIF custa mais CPU para codificar, mas isso acontece uma vez, no build.
+
+```astro
+---
+import { Image, Picture } from 'astro:assets';
+import heroi from '../assets/heroi.png';
+import prova from '../assets/prova.png';
+---
+<!-- herói: define o LCP. eager + fetchpriority tiram ele da fila -->
+<Picture src={heroi} formats={['avif','webp']} alt="descrição real"
+         layout="full-width" loading="eager" fetchpriority="high" />
+
+<!-- abaixo da dobra: lazy explícito -->
+<Image src={prova} alt="descrição real" layout="constrained"
+       width={720} loading="lazy" />
+```
+
+**Redimensionar antes de converter.** Trocar o formato não conserta imagem grande demais: um print de 3000px entregue numa tela de 390px é desperdício até em AVIF.
+
+Fora do Astro, o mesmo trabalho em lote com `sharp`: para cada arquivo, ler a largura original, e para cada largura alvo menor que ela gerar um `.webp` (qualidade ~78) e um `.avif` (qualidade ~55). Nunca aumentar a imagem.
+
+## Fonte
+
+Padrão de custo zero:
+
+```css
+body { font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
+                    "Helvetica Neue", Arial, sans-serif; }
+```
+
+Quando a marca exige fonte própria:
+
+```html
+<link rel="preload" as="font" type="font/woff2"
+      href="/fontes/NOME-700-latin.woff2" crossorigin>
+<style>
+@font-face{
+  font-family:"NOME";
+  src:url("/fontes/NOME-700-latin.woff2") format("woff2");
+  font-weight:700; font-style:normal; font-display:swap;
+  unicode-range:U+0000-00FF,U+0131,U+0152-0153,U+2000-206F,U+20AC;
+}
+</style>
+```
+
+Só `woff2`. Um ou dois pesos no máximo. Subset latino sempre. `preload` **apenas** na fonte que aparece acima da dobra.
+
+## Player de VSL: fachada
+
+A capa estática vira o LCP; o script do player entra depois, fora do caminho crítico. Um `<img>` com `width`/`height` e `aspect-ratio` reservados ocupa o espaço, e o script do player é injetado no primeiro `pointerenter` ou `click`, com um `requestIdleCallback` (timeout ~2,5s) como rede de segurança.
+
+**Troca consciente:** se o VSL precisa de autoplay, a fachada custa retenção nos primeiros segundos. Nesse caso, reduzir a rede de segurança para 600-1000 ms e adicionar `preconnect` para o domínio do player. **Declarar a troca no relatório.**
+
+## Rede: cache, prefetch e checkout
+
+```
+# headers da CDN
+/*
+  Cache-Control: public, max-age=0, must-revalidate
+
+/_astro/*
+  Cache-Control: public, max-age=31536000, immutable
+```
+
+```html
+<!-- prefetch só funciona dentro do próprio domínio -->
+<script type="speculationrules">
+{ "prefetch": [{ "where": { "href_matches": "/*" }, "eagerness": "moderate" }] }
+</script>
+
+<!-- checkout em outro domínio: prerender entre sites não existe.
+     preconnect é o máximo que dá -->
+<link rel="preconnect" href="https://SEU_CHECKOUT" crossorigin>
+```
+
+## Scripts que não são o pixel
+
+Chat, mapa de calor, gravador de sessão, pop-up de saída, contador de visitantes: nada disso precisa existir no primeiro segundo. Injetar todos no primeiro `pointerdown`, `keydown` ou `scroll` (listener `once` e `passive`), com um `setTimeout` de ~4s como rede de segurança.

package/src/modules/lowticket/skills/lowticket-trafego/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: lowticket-trafego
+description: Diagnoses a low ticket Meta Ads operation from campaign and funnel numbers, names the single bottleneck, and prescribes one action. Applies the bid-cap ruler, the 3x validation gate, the metric hierarchy and the funnel benchmarks instead of reacting to whichever number looks worst. Use when reading a Meta Ads or Utmify screenshot, deciding whether to pause an ad, deciding whether to scale, or answering "my ROAS dropped" for a low ticket offer. Do NOT use for Google Ads, brand campaigns, B2B lead gen, or to write copy and creatives - this skill reads numbers, it does not produce ads.
+---
+
+# Low Ticket Traffic Diagnosis
+
+Reads a paid-traffic operation and answers one question: **what is the single thing to change, and what should be left alone.**
+
+Most campaign damage is self-inflicted. An operator sees a bad number, changes three things at once, and loses the ability to attribute the result to anything. This skill exists to stop that.
+
+## Source of truth
+
+The numbers live in `lowticket-metodologia`, not here. On activation, read `knowledge/INDEX.md` and `knowledge/guardrails.md` from that skill, then the shard the request needs:
+
+- **`03-campanha-bidcap.md`**: campaign structure, bid cap ruler, pause rule, scale levers, cadence
+- **`02-diagnostico-funil.md`**: the funnel transitions and their benchmarks
+
+Where a generic paid-media skill (`paid-ads`, `analytics-tracking`) contradicts those shards, the shard wins and you say so. If `lowticket-metodologia` is not installed, the rules in `references/reguas.md` here are the fallback, and you say that too.
+
+Read the Cérebro state before answering (via the `cerebro` skill): the account's breakeven, ticket and current bid cap are state, not knowledge. This skill has **no memory of its own** and writes none.
+
+## The five gates, in order
+
+Run these before writing a single recommendation. The first one that trips decides the answer.
+
+### Gate 1: Is there enough sample?
+
+**A campaign that has spent less than 3x its bid cap is not judged.** Not the creative, not the page, not the checkout. Say how much more it has to spend, and stop:
+
+> Bid cap R$150 → the ruler is R$450 of accumulated spend. At R$200, there is nothing to diagnose yet.
+
+The only exception is an evident technical fault (pixel dead, page down, checkout erroring). A bad-looking ROAS is not a technical fault.
+
+### Gate 2: Did anything change in the last 72 hours?
+
+Ask it before anything else when performance dropped: checkout, pixel, CAPI, page, payment provider, events, campaign structure. A structural change breaks the purchase signal and costs 48 to 72 hours of recovery. During that window the numbers are not evidence, and stacking a second change on top makes it worse.
+
+### Gate 3: Where is the money leaking?
+
+Compute the four funnel transitions from Utmify, and **compute them yourself**: each rate is `next step ÷ previous step`. Never reuse a percentage the platform displays, because those are usually based on visits, not on the previous step.
+
+Attack order is fixed and runs backwards from the money:
+
+1. Venda Iniciada → Venda Aprovada (checkout, payment, Pix approval)
+2. Iniciar Checkout → Venda Iniciada (friction, fields, trust, mobile)
+3. Visitas → Iniciar Checkout (creative/page/offer mismatch)
+4. Cliques → Visitas (technical: speed, redirect, SSL, PageView)
+
+Checkout first, page second, creative last. Benchmarks per transition are in `references/reguas.md` and in shard `02`.
+
+### Gate 4: What does the metric hierarchy say?
+
+Read in this order and let the top of the list decide: **Vendas → Iniciar Checkout → CPC → Hook Rate → Hold Rate → CPM.**
+
+CPM never drives a diagnosis when there is sales data. CTR is never the deciding metric, and image CTR is not comparable to video CTR. Use the platform's own ROAS column; do not reconstruct ROAS by dividing result value by cost per result, because that is a different number.
+
+### Gate 5: Am I about to recommend more than one change?
+
+If yes, cut it down to one. Pick the bottleneck closest to the money, fix only that, give it time to measure, then re-evaluate. Two simultaneous changes destroy attribution, which costs more than the slower fix.
+
+## Flow
+
+1. **Identify the source** of whatever was pasted: which platform, which level (campaign / ad set / ad), which period. If the level or the period is missing, ask for it. Never infer it.
+2. **Extract every visible metric.** Never invent one. If a metric essential to the ruler is missing (spend, bid cap, sales, ROAS), name exactly which one and say the diagnosis is blocked on it.
+3. **Run the five gates** in order.
+4. **Answer in the fixed format**: `references/formato-do-diagnostico.md`. It is in Portuguese because it is emitted to the operator.
+5. **Set the next checkpoint** as a date, a time, or an objective spend threshold. An answer without a checkpoint invites a change tomorrow morning.
+
+## Standing rules
+
+- **Structure is 1 campaign, 1 ad set, X creatives**, CBO with bid cap, Advantage+ and no interests. Segmentation happens through the creative. ABO, interest stacking, campaign duplication and audience fragmentation are not recommended as the default.
+- **Scale is not budget.** The levers, in order: raise the bid cap, add validated creatives, inflate the budget while the bid cap holds the real ceiling. Raising the daily budget as the first move is the most common way to break a working campaign.
+- **Cadence is one new creative batch per week**, started at the top of Monday rather than mid-day. Around 15 days with no new batch is a structural problem, not a bad week.
+- **Frequency above 3 in 7 days** signals the start of saturation. It is a flag to cross-check against sales, ROAS, spend and delivery, never an automatic pause.
+- **Review the age breakdown every ~14 days.** Advantage+ hides differences in the aggregate. Use the account's own history; there is no universal age rule.
+- **If Meta stopped delivering an ad, do not force it.** Pausing then only confirms a decision the algorithm already made.
+- **A healthy campaign is left alone.** "Nothing to change" is a complete answer, and often the correct one.
+
+## What this skill does not do
+
+- **It does not write.** Copy, headline, script, offer, product: redirect to `copywriting`, `wizz-offer-forge` or `ad-creative`. It can read how a copy or an offer is affecting traffic metrics; it does not become the copywriter.
+- **It does not guess.** A cropped or unreadable screenshot gets a request for the missing number, not an estimate.
+- **It does not optimize for the sake of optimizing.** No invented problem where the data shows none.
+
+## Tone
+
+Portuguese (BR), short sentences, direct. No corporate language, no generic praise, no "excelente pergunta", no closing pleasantries, no em-dashes. Numbers and deadlines instead of adjectives.

package/src/modules/lowticket/skills/lowticket-trafego/references/formato-do-diagnostico.md

@@ -0,0 +1,56 @@
+# Formato do diagnóstico
+
+Este é o texto entregue ao operador, por isso está em português. Não improvisar outro formato: a repetição é o que faz a pessoa comparar dois diagnósticos ao longo do tempo.
+
+## Formato padrão
+
+```
+**Diagnóstico:** [uma frase, o problema principal]
+
+**Métricas relevantes:**
+- [só as que sustentam o diagnóstico]
+
+**Onde está o gargalo:** [transição ou peça específica]
+
+**O que fazer:**
+1. [a ação prioritária, uma só]
+2. [segunda, apenas se realmente necessária]
+
+**O que NÃO fazer agora:**
+- [o que a pessoa provavelmente ia mexer e não deve]
+
+**Próximo checkpoint:** [data, horário ou valor de gasto acumulado]
+```
+
+## Campanha ainda em validação
+
+Quando o gasto acumulado não chegou a 3x o bid cap, o diagnóstico é curto de propósito:
+
+```
+**Diagnóstico:** Campanha ainda em validação. Não julgar antes de 3x o bid cap.
+
+**Métricas relevantes:** [gasto acumulado, bid cap]
+
+**Onde está o gargalo:** Ainda não há amostra para determinar.
+
+**O que fazer:**
+1. Manter rodando.
+2. Não alterar a estrutura.
+
+**O que NÃO fazer agora:**
+- Pausar criativo, trocar página, trocar checkout ou mexer no orçamento para "salvar" a campanha.
+
+**Próximo checkpoint:** quando o gasto acumulado passar de R$[3x o bid cap].
+```
+
+## Quando falta informação
+
+Não estimar e não preencher lacuna. Nomear exatamente o que falta e por quê:
+
+> Preciso do gasto acumulado e do bid cap desse anúncio. Sem esses dois números não dá para aplicar a régua de 3x.
+
+## Quando o pedido é de copy ou oferta
+
+> Aqui o foco é a análise de métrica. Para copy ou oferta, é outro agente.
+
+Analisar o impacto de uma copy ou de uma oferta sobre as métricas, sim. Escrever a copy, não.

package/src/modules/lowticket/skills/lowticket-trafego/references/reguas.md

@@ -0,0 +1,72 @@
+# Réguas numéricas · diagnóstico de tráfego low ticket
+
+> Fallback. A fonte canônica é o shard `03-campanha-bidcap.md` e `02-diagnostico-funil.md` de `lowticket-metodologia`. Esta página existe para a skill continuar utilizável quando o módulo de conhecimento não está instalado, e para a consulta rápida de um número.
+
+## Bid cap
+
+**Pré-requisitos antes de recomendar bid cap:** breakeven calculado, pelo menos 1 criativo validado, Pixel funcionando, CAPI funcionando, volume de conversão suficiente.
+
+Sem isso, começar em Volume Mais Alto até acumular ~20 a 30 compras, e só então migrar. Não é convivência em paralelo, é sequência.
+
+| Postura | Cálculo |
+|---|---|
+| Base | bid cap = breakeven |
+| Agressivo | breakeven × 1,30 |
+| Agressivo (recomendação operacional atual) | breakeven × 1,50 |
+
+Exemplo: breakeven R$163 → bid cap agressivo R$244,50.
+
+Se a campanha não consegue gastar dentro do bid cap, não force a entrega artificialmente.
+
+## Régua de 3x
+
+**Gasto acumulado abaixo de 3x o bid cap = campanha não julgada.** Nem criativo, nem página, nem checkout, nem orçamento. Informe o valor exato que falta.
+
+Depois de 24h rodando E 3x o bid cap gasto, o pause é justificado quando: ROAS abaixo do breakeven, zero vendas, e nenhuma mudança estrutural recente explicando a queda.
+
+## Hierarquia de métricas
+
+`Vendas → Iniciar Checkout → CPC → Hook Rate → Hold Rate → CPM`
+
+- **Hook rate** = reproduções de 3s ÷ impressões
+- **Hold rate** = reproduções de 75% ÷ impressões
+- **ROAS** = a coluna de ROAS da plataforma. Não reconstruir dividindo valor de resultado por custo por resultado: é outro número.
+
+## Funil: as 4 transições e seus benchmarks
+
+Taxa real = etapa seguinte ÷ etapa anterior. **Nunca** usar a porcentagem exibida pela plataforma, que costuma ter Visitas como base.
+
+| Transição | Ruim | Médio | Saudável | Onde atacar |
+|---|---|---|---|---|
+| Cliques → Visitas | < 95% | (sem faixa média) | ≥ 95% | técnico: página lenta, redirect, SSL, mobile, PageView |
+| Visitas → Iniciar Checkout | < 10% | 10-25% | 25-40%+ | criativo, página e oferta: mismatch, CTA fraco, preço antes do valor |
+| Iniciar Checkout → Venda Iniciada | < 50% | 50-75% | 75-90% | checkout: campos, atrito, confiança, meio de pagamento, mobile |
+| Venda Iniciada → Venda Aprovada | < 50% | 50-75% | 75-90% | pagamento: aprovação Pix, cartão recusado, recuperação |
+
+**Ordem de ataque:** de trás para frente. Checkout e pagamento primeiro, página depois, criativo por último.
+
+## Aprovação de Pix
+
+- **abaixo de 70% = problema grave.** Para tudo e ataca checkout/pagamento antes de qualquer outra coisa.
+- **75% = meta** de operação saudável.
+
+Cruzar o número da plataforma de tráfego com o da plataforma de pagamento. Se a campanha caiu e a aprovação de Pix caiu junto, o criativo não é o culpado.
+
+## Escala
+
+Alavancas, nesta ordem: (1) subir o bid cap, (2) adicionar criativos validados, (3) orçamento inflado com o bid cap segurando o gasto real.
+
+**Nunca** como primeira alavanca: subir o orçamento diário. O orçamento dá permissão para gastar; o bid cap é o teto real de aquisição.
+
+Trava depois de mexer: **ressaca de 48 a 72h** após mudança estrutural, e a régua de 3x antes de julgar de novo.
+
+## Cadência e saturação
+
+- 1 lote novo de criativos por semana, iniciado na virada de segunda-feira.
+- ~15 dias sem lote novo = problema estrutural de cadência.
+- Frequência acima de 3 em 7 dias = início de saturação. É bandeira para cruzar com vendas, ROAS, gasto e entrega, não pause automático.
+- Detalhamento por idade a cada ~14 dias: o Advantage+ esconde diferença no agregado. Usar o histórico da própria conta, sem regra universal de faixa etária.
+
+## O que não recomendar como padrão
+
+ABO · interesses · segmentação excessiva · duplicação de campanha · vários conjuntos sem necessidade · aumento agressivo de orçamento diário · pause antes de 3x bid cap · decisão só por CPM · decisão só por CTR · troca simultânea de criativo, página e checkout.

package/src/modules/wizz/README.md

@@ -19,7 +19,7 @@ Os papéis de dev/produto reusam os agentes WIZZ (Mary, John, Winston, Amelia, S
 ## Camada Wizz (em todos os agentes)
 
 - **Encerramento** (`_shared/encerramento.md`): bloco ✅/➡️/🎯 ao terminar.
-- **Economia de token** (`_shared/token-economy.md`): graphify → cerebro → grep antes de ler arquivos; RTK reescreve shell; trabalho mecânico vira linha-fato na ativação de todo agente (2+ subagentes `wizz-exec-haiku`/`wizz-exec-sonnet` em paralelo, nunca na sessão principal), com `wizz-exec-opus` condicional e `wizz-exec-review` (inherit) nos degraus acima; escada completa em `_shared/model-ladder.md`.
+- **Economia de token** (`_shared/token-economy.md`): cerebro → grep antes de ler arquivos; RTK reescreve shell; trabalho mecânico vira linha-fato na ativação de todo agente (2+ subagentes `wizz-exec-haiku`/`wizz-exec-sonnet` em paralelo, nunca na sessão principal), com `wizz-exec-opus` condicional e `wizz-exec-review` (inherit) nos degraus acima; escada completa em `_shared/model-ladder.md`.
 - **Cerebro** (`_shared/cerebro.md`): auto-load leve na ativação, lembrete de salvar no fim.
 - **Idioma**: escolhido no `wizz-init` (padrão Português (BR)), gravado em `_wizz/bmm/config.yaml`.
 - **Encadeamento**: automático. O maestro anuncia a sequência e ela roda em ordem até o fim; pausa só em decisão de negócio ou risco irreversível.