wizz-method 1.18.2 → 1.19.0

package/src/modules/lowticket/skills/lowticket-metodologia/knowledge/guardrails.md

@@ -1,8 +1,8 @@
-# Guardrails · o que esta metodologia não faz
+# Guardrails · o que este projeto não faz
 
-> Carregado **sempre**, junto do [`INDEX.md`](INDEX.md). São três táticas que a fonte de origem ensina e que esta base registrou mas **não adotou**, porque violam termos de plataforma ou lei do consumidor.
+> Carregado **sempre**, junto do [`INDEX.md`](INDEX.md). São sete táticas que a fonte de origem ensina e que este projeto registrou mas **não adotou**, porque violam termos de plataforma, lei do consumidor ou direito de terceiro.
 >
-> **Enquanto não houver decisão explícita do dono da operação, nenhum agente usa nenhuma delas.** Se um shard ensinar a tática, a linha de bloqueio está inline lá também. Achou o material a favor sem achar este arquivo? Então o carregamento está errado: guardrails vem no degrau 0.
+> **Enquanto não houver decisão explícita do dono da operação, nenhum agente deste projeto usa nenhuma delas.** Se um shard ensinar a tática, a linha de bloqueio está inline lá também. Achou o material a favor sem achar este arquivo? Então o carregamento está errado: guardrails vem no degrau 0.
 
 ## 20 · Compra de engajamento (curtidas e comentários)
 
@@ -18,7 +18,7 @@
 
 **Por que não (sem confirmar antes).** Meta e Instagram exigem que conta representando pessoa fictícia seja identificável como tal, e a regra varia por formato e por país. O material de origem não trata disso. Em Portugal e na UE a régua de transparência é mais dura (§4.8 já registra o mesmo cuidado para promessa).
 
-**O que fazer.** Avatar de IA como recurso visual declarado, sim. Avatar de IA apresentado como pessoa real em anúncio, **não sem confirmar a política vigente do mercado alvo**. Vale também a regra de lip-sync do : nunca reaproveitar take de avatar cuja boca não corresponde 1:1 ao áudio da peça.
+**O que fazer.** Avatar de IA como recurso visual declarado, sim. Avatar de IA apresentado como pessoa real em anúncio, **não sem confirmar a política vigente do mercado alvo**. Vale também a regra de lip-sync: nunca reaproveitar take de avatar cuja boca não corresponde 1:1 ao áudio da peça.
 
 ## 23 · Depoimento sintético
 
@@ -26,7 +26,61 @@
 
 **Por que não.** É depoimento fabricado. Viola a política de anúncios da Meta e configura publicidade enganosa (CDC no Brasil; na UE a régua é mais dura ainda, e §4.8 já manda enquadrar todo depoimento como resultado individual). O risco não é só jurídico: prova social falsa que é descoberta destrói a oferta inteira.
 
-**O que fazer no lugar.** A própria metodologia já dá a alternativa: [`06a-instagram.md`](06a-instagram.md) §6A.4 trata destaque com feedback real de cliente, e a alternativa é gravar feedback em vídeo ou áudio quando existir cliente de verdade. Sem cliente ainda, a página vai sem bloco de depoimento, não com depoimento inventado.
+**O que fazer no lugar.** A própria metodologia já dá a alternativa: [`06a-instagram.md`](06a-instagram.md) §6A.4 trata destaque com feedback real de cliente, e a fonte de origem sugere gravar feedback em vídeo ou áudio quando existir cliente de verdade. Sem cliente ainda, a página vai sem bloco de depoimento, não com depoimento inventado.
+
+## 32 · Documento de identidade de terceiro para verificar o perfil
+
+**A tática.** O `Guia Prático para Escalar Mentoria` ensina a passar a verificação de perfil do Instagram usando "foto que combine com o documento", e dá o exemplo literal de pôr uma mulher no perfil e enviar o documento da mãe dela. A parte legítima da mesma fonte está registrada em [`06a-instagram.md`](06a-instagram.md).
+
+**Por que não.** É autenticar uma conta perante a plataforma com a identidade de outra pessoa. A Meta exige que o documento corresponda a quem está por trás da conta; fora isso, a distância entre "foto que combina com o documento" e personificação é curta, e o documento é de alguém que não é parte do negócio. O risco cai exatamente sobre o ativo que a fonte de origem quer proteger: o perfil e a BM.
+
+**O que fazer no lugar.** O resto da aula fica valendo e é o suficiente: categoria **"Comunidade"** (a mais fácil de verificar) e foto coerente com o documento **da própria pessoa** que opera a conta. O ganho relatado de CPA e CPM vem da categoria e da coerência, não de quem assina o documento.
+
+## 44 · Nome de pessoa real como prova emprestada
+
+**A tática.** A fonte de origem "Do desejo à oferta" (shard [`18`](18-copy-desejo-oferta.md) §18.2 e §18.13) mostra que a headline específica ganha da genérica porque carrega **prova emprestada**: "alguém que ela já admira e quer ser". O exemplo literal do deck é uma headline de emagrecimento que cita **nominalmente uma influenciadora brasileira**, sem qualquer relação com a oferta.
+
+**Por que não.** Citar pessoa real em anúncio sem autorização é uso não autorizado de nome e imagem: no Brasil cai no art. 20 do Código Civil e no CDC (publicidade que induz a associação inexistente); na UE a régua é mais dura ainda. A política de anúncios da Meta também proíbe sugerir endosso de figura pública sem autorização, e a penalidade cai na conta e na BM. O risco é duplo: notificação do titular e reprovação/banimento, e chega justamente quando o criativo escala.
+
+**O que fazer no lugar.** A prova emprestada continua valendo; o que muda é de onde ela vem:
+
+- **Referência descritiva, não nominal:** "corpo de quem treina há 10 anos", "rotina de quem trabalha 12h por dia". Entrega a mesma imagem mental sem nomear ninguém.
+- **Arquétipo ou papel:** "mãe de dois que voltou a caber na roupa de antes": é o estágio 5 de sofisticação (§18.4), que vende identidade, e não depende de terceiro.
+- **Prova própria:** os degraus de §18.7 que a operação realmente tem: número específico, demonstração, volume.
+- **Nome de terceiro só com autorização escrita** (contrato de publicidade ou parceria de co-produção, seção 9).
+
+A trava que o próprio deck já dá continua valendo por cima: *"específico não é inventado: se você não entrega, o específico vira reembolso e bloqueio de conta."*
+
+**Decidido em 2026-09-09 (decisão do dono da operação): fica bloqueado.** A única porta aberta é contratual: influenciador que seja **co-produtor** da oferta (seção 9, com contrato) pode ser nomeado, porque aí existe autorização e existe relação real com o produto. Fora disso, nome de terceiro não entra em anúncio.
+
+> A troca é honesta: perde-se alguma força ao sair do nome próprio. Recupera-se com linguagem de **identidade** ("pra mãe de 2 filhos que já tentou de tudo"), que é o estágio 5 de sofisticação em [`18`](18-copy-desejo-oferta.md) §18.4. O caminho legal é também o mais sofisticado.
+
+## 45 · Vídeo de terceiro baixado do TikTok como criativo próprio
+
+**A tática.** O `Guia Prático de Ferramentas para Criação de Criativos e Áudios` (registrado em [`04a-criativos-ia.md`](04a-criativos-ia.md) §4.15) ensina a usar um navegador com descarregador embutido para baixar vídeos do TikTok **sem marca d'água** e usá-los como B-roll e ilustração do criativo. A mesma aula sugere usar imagem de pessoa de outro país "para testar a aceitação do público" antes de produzir para o mercado local, e apresenta isso como forma de reduzir risco de apuração no Meta Ads.
+
+**Por que não.** São três problemas de uma vez. **Direito autoral e de imagem:** o vídeo é obra de outra pessoa e a pessoa filmada não autorizou aparecer num anúncio; remover a marca d'água é justamente apagar a atribuição. **Termos de plataforma:** os Termos do TikTok proíbem extrair conteúdo para uso comercial fora da plataforma, e a política da Meta exige direito de uso sobre todo material de anúncio. **Motivação errada:** o argumento de "evitar apuração" é evasão de detecção, não conformidade: se a tática precisa não ser vista para funcionar, ela já é o problema.
+
+**O que fazer no lugar.** A parte útil da aula sobrevive inteira:
+
+- **TikTok como referência, não como estoque.** Observar o que está a correr, classificar o formato (§4.11-B) e **refazer** com material próprio é modelagem legítima, é o que a metodologia já manda em 4.12 e 12.
+- **Bancos com licença** para B-roll e ilustração: Pexels e equivalentes, que a mesma aula cita e que existem exatamente para isso.
+- **Material próprio ou gerado**, pela stack de [`04a`](04a-criativos-ia.md) §4.6, §4.9, §4.13 e §4.14, respeitando [guardrails 21](guardrails.md) quando envolver avatar.
+- **Testar aceitação** com criativo próprio no orgânico (§4.12), que é o filtro que a metodologia já adotou e não depende de material de ninguém.
+
+**Decidido em 2026-09-09 (decisão do dono da operação): fica bloqueado, sem exceção.** O custo de cumprir é quase zero: o pipeline de [`04a`](04a-criativos-ia.md) §4.14 (um cenário, várias falas) já resolve B-roll barato com material próprio, e os bancos com licença cobrem o resto. O único uso que fica mesmo de fora é testar de graça a reação de público estrangeiro, e o substituto é olhar em vez de extrair: o swipe file de 155 peças ([`04b`](04b-criativos-formatos.md) §4.10) e a Biblioteca de Anúncios.
+
+## 48 · Preço de referência riscado que nunca foi cobrado
+
+**A tática.** A anatomia de página de origem (shard [`12c`](12c-anatomia-low-ticket.md) bloco 06, e a §6.1 de [`06-pagina-vendas.md`](06-pagina-vendas.md)) manda mostrar "valor cheio riscado, entrada destacada". Na prática das ofertas de low ticket, o valor cheio é a **soma do valor atribuído aos materiais**, não um preço que alguém tenha pago.
+
+**Por que não (no mercado europeu).** A Diretiva Omnibus (UE 2019/2161, em vigor em Portugal) exige que qualquer preço de referência anunciado numa redução seja **o preço mais baixo praticado nos 30 dias anteriores**. Somar itens até 134€ e riscar esse número apresenta como preço anterior uma quantia que nunca foi cobrada. Já custou acordos de dezenas de milhões a grandes retalhistas, e em Portugal cai na alçada da ASAE e do DL 57/2008.
+
+**O que fazer no lugar.** A ancoragem por valor continua permitida, desde que não se disfarce de desconto: dizer **"134€ em materiais · hoje 14,90€"**, com a soma item a item visível no bloco de valor, e **nunca riscar o número**. O efeito de ancoragem mantém-se, a afirmação é verificável, e a página não promete um desconto que não existiu. Aplicado numa página PT de um cliente em 2026-09-05.
+
+> 🔢 **Este guardrail era o número 33 até 2026-09-09.** Foi aberto em 2026-09-05 reutilizando um número que já pertencia à barra de progresso do player em [`pontos-em-aberto.md`](pontos-em-aberto.md), e os dois assuntos ficaram a partilhar o mesmo identificador. Renumerado para 48, o primeiro livre. Quem encontrar "guardrail 33" em material antigo está a falar deste.
+
+---
 
 ---
 

package/src/modules/lowticket/skills/lowticket-metodologia/knowledge/pontos-em-aberto.md

@@ -1,33 +1,36 @@
 # Pontos em aberto — Metodologia Low Ticket
 
-Contradições e lacunas encontradas ao destilar esta metodologia, extraídas para este arquivo separado para manter os shards enxutos. **Confirmar com o dono da operação, ou com a fonte de origem, antes de decidir qualquer um destes pontos.** Os pontos 20, 21 e 23 são risco legal ou de banimento: moram em [`guardrails.md`](guardrails.md), que é carregado sempre. Os shards em `knowledge/` referenciam este arquivo pelo número do ponto (ex.: "Ver Ponto em aberto 20").
+Contradições e lacunas encontradas ao destilar esta metodologia, extraídas para este arquivo separado para manter os shards enxutos. **Confirmar com o dono da operação, ou com a fonte de origem, antes de decidir qualquer um destes pontos.** Os pontos 20, 21, 23, 32, 44, 45 e 48 são risco legal ou de banimento: moram em [`guardrails.md`](guardrails.md), que é carregado sempre. Os shards em `knowledge/` referenciam este arquivo pelo número do ponto (ex.: "Ver Ponto em aberto 20").
 
 ---
 
 1. **Prazo de garantia fora do Brasil.** O mesmo arquivo cita "28 dias globalmente" em um ponto e "padrão da Europa é 14" em outro. Provavelmente Europa 14 e demais mercados 28, mas não está explícito.
-2. ~~**BidCap substitui o BO ou convive com ele?**~~ **RESOLVIDO (2026-08-22).** O fixa os pré-requisitos: Bid Cap exige breakeven calculado, ≥1 criativo validado, Pixel e CAPI ok. **Sem isso, começar em Volume Mais Alto até ~20-30 compras** e só então migrar para Bid Cap. Não é "convive em paralelo": é sequência. Ver 3.7.
+2. ~~**BidCap substitui o BO ou convive com ele?**~~ **RESOLVIDO (2026-08-22).** A fonte mais recente fixa os pré-requisitos: Bid Cap exige breakeven calculado, ≥1 criativo validado, Pixel e CAPI ok. **Sem isso, começar em Volume Mais Alto até ~20-30 compras** e só então migrar para Bid Cap. Não é "convive em paralelo": é sequência. Ver 3.7.
 3. **Onde o VSL entra.** Aparece como bloco da página de vendas, como ferramenta de qualificação antes do WhatsApp, e no upsell. A leitura adotada é que ele aparece em vários pontos do funil, com função diferente em cada um.
-4. ~~**Percentuais esperados por etapa do funil de upsell.**~~ **RESOLVIDO (2026-08-22).** O traz a cascata completa: U1 15-25%, U2 20-35% (entre compradores do U1), Downsell 20-35%, Oferta Final 18-28%, com ticket total de 1,5x a 2,3x o front. Ver 7.4.
+4. ~~**Percentuais esperados por etapa do funil de upsell.**~~ **RESOLVIDO (2026-08-22).** A fonte mais recente traz a cascata completa: U1 15-25%, U2 20-35% (entre compradores do U1), Downsell 20-35%, Oferta Final 18-28%, com ticket total de 1,5x a 2,3x o front. Ver 7.4.
+5. **Registro interno de processamento incompleto.** Contabilidade sobre seções de um material de origem que ainda não haviam sido totalmente processadas na destilação. Sem conteúdo publicável.
+6. **Registro interno sobre contrato de parceria.** Nota de acompanhamento sobre um contrato-modelo de co-produção ainda não incorporado à destilação; o que já foi adotado sobre parcerias está na seção 9. Sem conteúdo publicável.
 7. **Headline: produto ou promessa?** A fonte de origem de mecanismo único (2026-08-13) diz que "a headline é basicamente a promessa principal" (transformação), com o mecanismo detalhado na VSL. Já a seção 6.2 diz que em low ticket a headline foca no produto. Leitura adotada: em low ticket o produto É a promessa (nome + resultado), então não há conflito prático, mas confirmar com a fonte de origem.
-8. **Order bump: onde e quantos?** A seção 5.3 manda order bump **apenas no plano premium** (removê-lo do básico sobe conversão de entrada); o checklist do ROI (seção 11.4) manda **3-5 bumps ativos sempre**. O benchmark público de VSL registra a divergência no mercado e aponta a variável decisiva: meio de pagamento dominante (Pix favorece bumps; cartão favorece upsell one-click). Confirmar com a fonte de origem qual regra vale para cada oferta.
-9. ~~**Estrutura de campanha: BidCap+ABO ou CBO+Advantage?**~~ **RESOLVIDO (2026-08-22).** O (material mais recente e mais explícito) fixa a estrutura padrão: **1 campanha, 1 conjunto, X criativos — CBO + Bid Cap + Advantage+, sem interesses**, com a segmentação feita pelo criativo. O prompt **proíbe ABO como padrão**, junto com interesses, segmentação excessiva e duplicação de campanhas. A seção 3.1 (BidCap + ABO secundária) é material mais antigo e fica **superada** neste ponto. Ver 3.7.
-10. ~~**Regra de escala — o conflito era falso.**~~ **RESOLVIDO (2026-08-25).** O (2026-08-22) reenquadra tudo: **nunca subir orçamento diário como primeira alavanca.** As alavancas certas, na ordem, são (1) subir o Bid Cap, (2) adicionar criativos validados, (3) orçamento inflado com o Bid Cap controlando o gasto real. Os "+30%" e "+50%" que pareciam divergir são coisas diferentes: **+50% é o Bid Cap sobre o breakeven** (recomendação operacional atual), e **+30% em 30% é o orçamento** do radar de ofertas. Não competem — são alavancas distintas. O que continua valendo como trava: **régua de 3x** (não mexer antes de 3x o Bid Cap em gasto) e **ressaca de 48-72h** após mudança estrutural. Ver 3.7.
+8. ~~**Order bump: onde e quantos?**~~ **REGRA ADOTADA (2026-08-28, por leitura do material; não confirmada com a fonte de origem.)** As duas regras não se contradizem: respondem perguntas diferentes. **Onde:** o checkout do plano básico fica limpo, o bump vive no premium (5.3): tirar o bump do básico sobe a conversão de entrada. **Quantos:** no checkout que tem bump, 3 a 5 ativos, cada um medido, mata e troca no mesmo dia abaixo de 10% (11.4). **Ajuste pelo meio de pagamento** (13): Pix dominante puxa para o topo da faixa (5 bumps); cartão dominante puxa para o piso (3) e joga o peso no upsell one-click. Em página de preço único (ver ponto 25, ticket até R$37) só existe um checkout, então a faixa de 3 a 5 vale direto.
+9. ~~**Estrutura de campanha: BidCap+ABO ou CBO+Advantage?**~~ **RESOLVIDO (2026-08-22).** O material mais recente e mais explícito fixa a estrutura padrão: **1 campanha, 1 conjunto, X criativos — CBO + Bid Cap + Advantage+, sem interesses**, com a segmentação feita pelo criativo. O prompt **proíbe ABO como padrão**, junto com interesses, segmentação excessiva e duplicação de campanhas. A seção 3.1 (BidCap + ABO secundária) é material mais antigo e fica **superada** neste ponto. Ver 3.7.
+10. ~~**Regra de escala — o conflito era falso.**~~ **RESOLVIDO (2026-08-25).** O material de 2026-08-22 reenquadra tudo: **nunca subir orçamento diário como primeira alavanca.** As alavancas certas, na ordem, são (1) subir o Bid Cap, (2) adicionar criativos validados, (3) orçamento inflado com o Bid Cap controlando o gasto real. Os "+30%" e "+50%" que pareciam divergir são coisas diferentes: **+50% é o Bid Cap sobre o breakeven** (recomendação operacional atual), e **+30% em 30% é o orçamento** do radar de ofertas. Não competem — são alavancas distintas. O que continua valendo como trava: **régua de 3x** (não mexer antes de 3x o Bid Cap em gasto) e **ressaca de 48-72h** após mudança estrutural. Ver 3.7.
 11. **Duração de criativo.** Seção 4.2: 40-60s ideal (máx 90s). Checklist do ROI: VSL de low ticket 90s-2min (objeto diferente: é a VSL, não o criativo). benchmark público de VSL: criativos que mais escalam rodam 1min30-2min, e low ticket direto 15-60s. Leitura adotada: 40-60s segue como padrão de criativo desta base; a faixa maior é benchmark de mercado por nicho.
-12. ~~**Aprovação de Pix — duas réguas, funções diferentes.**~~ **RESOLVIDO (2026-08-25).** O (2026-08-22) fixa **abaixo de 70% = problema grave**, que manda atacar checkout e pagamento antes de qualquer outra coisa. O checklist do ROI põe **>75%** como meta. Leitura adotada: **70% é o alarme** (abaixo disso, para tudo e conserta o checkout) e **75% é a meta** de operação saudável. Não é conflito.
+12. ~~**Aprovação de Pix — duas réguas, funções diferentes.**~~ **RESOLVIDO (2026-08-25).** O material de 2026-08-22 fixa **abaixo de 70% = problema grave**, que manda atacar checkout e pagamento antes de qualquer outra coisa. O checklist do ROI põe **>75%** como meta. Leitura adotada: **70% é o alarme** (abaixo disso, para tudo e conserta o checkout) e **75% é a meta** de operação saudável. Não é conflito.
+13. **Registro histórico sobre mapas mentais de origem.** Contabilidade sobre a tentativa de capturar mapas mentais de apoio que não trouxeram conteúdo novo à metodologia; nenhum conteúdo desses mapas entrou no documento. Sem conteúdo publicável.
 14. **Quantos entregáveis tem a oferta principal?** A fonte de origem sobre Instagram diz, no resumo, "um nicho e cinco entregáveis consistentes" e, nas decisões, "pelo menos 10 entregáveis comuns". A leitura adotada em 6A.8 foi ~10 entregáveis na oferta principal e 5 ofertas rodando ao mesmo tempo, mas o material é ambíguo.
 15. **Quanto do funil o Instagram carrega?** A fonte de origem de Instagram afirma em um ponto que "a maioria das vendas não vem do anúncio (apenas 11%)" e em outro que "aproximadamente 90% das vendas vêm desse fluxo". São a mesma estatística vista pelos dois lados (11% direto, 89% via perfil), e foi assim que entrou em 6A.1 — mas o número de 89-90% é de duas operações específicas, não benchmark de origem. **Não tratar como meta.**
 16. **VSL na página: ajuda ou atrapalha?** A seção 11.3 manda VSL de 90s a 2min no low ticket e a 6.2 manda VSL logo após a headline. Já o dado de funil em 6A.9 mostra a página **sem** VSL entregando melhor (87→35 contra 75→32). Leitura provável: o VSL ajuda quando a oferta precisa de explicação e atrapalha quando o produto se explica sozinho. Confirmar com a fonte de origem.
 17. **"Mais lucrativo": formar expert ou fechar co-produção?** A fonte de origem de Instagram diz que formar um expert é o mais lucrativo (sem audiência prévia, sem barganha); diz que a co-produção é o modelo mais lucrativo e sustentável. Os dois materiais comparam contra bases diferentes: a co-produção ganha **de rodar sozinho**, e formar ganha **da co-produção**, porque não divide o lucro. Leitura adotada na seção 9.2: formar > parceria > sozinho, com a parceria ganhando em velocidade de execução. Nenhum dos dois materiais compara os três lado a lado, então confirmar com a fonte de origem.
-18. **Duração da VSL: 90s-2min ou 7-9 minutos?** A seção 11.3 (checklist do ROI) manda VSL de low ticket entre 90s e 2min, argumentando que o público de low ticket não aguenta VSL longa. A fonte de origem do checklist de alta conversão (2026-08-18) apresenta uma estrutura de 6 blocos calibrada para **7 a 9 minutos**. Não é a mesma coisa que o ponto 11 (aquele era criativo vs. VSL; este é VSL vs. VSL). Leitura provável: os 90s-2min valem para produto que se explica sozinho (showrun de tela), e os 7-9 min para oferta que precisa construir autoridade e mecanismo antes do preço. A estrutura de 6 blocos vale nos dois casos, mudando só o tempo de cada bloco. **Confirmar com a fonte de origem qual régua usar por tipo de oferta.**
+18. ~~**Duração da VSL: 90s-2min ou 7-9 minutos?**~~ **REGRA ADOTADA (2026-08-28, por leitura do material; não confirmada com a fonte de origem.)** O que decide é **o que a VSL precisa provar**, não o ticket sozinho. Produto que se prova na tela (showrun, gravação abrindo o produto por dentro, 11.3): **90s a 2min**. Oferta que precisa construir mecanismo e autoridade antes de chegar ao preço: **7 a 9 min**, na estrutura de 6 blocos (4.7). A estrutura de 6 blocos vale nos dois casos: muda o tempo de cada bloco, não a ordem nem a função deles. **No empate, comece curto:** alongar uma VSL curta que reteve é mais barato que salvar uma longa que ninguém assistiu.
 19. **Gancho: 3 ou 5 segundos?** A seção 4.1 e a fonte de origem nova falam em **3 segundos**; a seção 11.6 (checklist do ROI) fala em **5 segundos**. Prática: escrever para 3, tolerar até 5. Não é conflito operacional real, mas os números divergem no material.
 20. **Compra de engajamento (ferramenta de compra de engajamento) — registrado, não adotado.** Texto completo, motivo e alternativa em [`guardrails.md`](guardrails.md#20--compra-de-engajamento-curtidas-e-comentários). **Decidir com o dono da operação se entra.**
 21. **Perfil realista de IA e política de plataforma.** Texto completo, motivo e alternativa em [`guardrails.md`](guardrails.md#21--avatar-de-ia-passando-por-pessoa-real). **Confirmar a política do mercado alvo antes de usar avatar de IA como pessoa real.**
 
 22. **Gancho: nomear o público ou perguntar?** A seção 4.5 manda nomear o público no primeiro segundo ("você que é lojista..."), e o material de origem trata isso como a alavanca de identificação e filtro. Já o swipe file de 155 peças (4.10) faz isso em **3 de 86** criativos com fala: o que domina é a **pergunta** (29%) e a **curiosidade/segredo** (19%). Leitura provável: os dois filtram, mas por caminhos diferentes — nomear filtra por identidade ("sou lojista"), perguntar filtra por desejo ("quero isso"). A pergunta pode ganhar em plataforma de entretenimento (o Instagram da 4.4, onde soar comercial cedo demais mata o alcance) e o nomear ganhar em oferta de subnicho estreito. **Não há dado de performance no swipe file para decidir isso** — confirmar com a fonte de origem, e testar os dois ângulos no mesmo conjunto quando houver dúvida.
 23. **Depoimento sintético (aula da fábrica de ofertas) — registrado, não adotado.** Texto completo, motivo e alternativa em [`guardrails.md`](guardrails.md#23--depoimento-sintético). **Enquanto não houver decisão explícita do dono da operação, nada aqui usa a tática.**
-24. **Duas tabelas de reposicionamento de preço.** A régua do minerador (12.5) trabalha com faixas: R$67 → R$19-27, R$97 → R$27-37, R$147 → R$37-47, R$297 → ~R$97. A fábrica de ofertas (12.7) usa valor **fixo** por faixa de origem: 47-67 → R$19,90, 67-97 → R$27, 97+ → R$37. As duas concordam até uma origem de R$97; acima disso divergem de verdade — numa origem de R$297 o minerador manda ~R$97 e a Fábrica manda R$37. Leitura provável: são réguas para usos diferentes. A da Fábrica é fixa porque um agente automatizado precisa de número fechado, e o teto de R$37 reflete o piso de low ticket puro; a do minerador é faixa porque pressupõe julgamento humano e cobre ofertas mais caras. **Na prática:** usar a tabela da Fábrica quando o agente estiver rodando sozinho, e a do minerador quando você estiver decidindo o preço à mão — principalmente acima de R$97, onde a da Fábrica deixa dinheiro na mesa. Confirmar com a fonte de origem.
+24. ~~**Duas tabelas de reposicionamento de preço.**~~ **REGRA ADOTADA (2026-08-28, por leitura do material; não confirmada com a fonte de origem.)** O próprio 12.5 se declara "hipótese de trabalho, não regra mecânica", e isso resolve: **tabela fixa da Fábrica (12.7) quando o agente roda sozinho** e precisa de número fechado; **faixas de 12.5 quando é você decidindo à mão**. Acima de uma origem de R$97 a tabela da Fábrica sai de escopo: o teto de R$37 dela é o piso do low ticket puro, não uma regra de reposicionamento. Numa origem de R$297, a régua é a de 12.5 (~R$97), e mandar R$37 ali é deixar dinheiro na mesa.
 
-25. **UM preço só ou dois planos?** A fábrica de ofertas (12.7-A) é categórica: bloco 06 da anatomia diz "UM preço", e a lista do que não pôr numa página de R$19,90 diz "três planos: isso é página de software. Você tem 1 entrada, 1 bump, 1 upsell". Contra isso estão **três lugares já escritos**: 5.3 ("modelo de dois planos, não preço único"), 11.3 ("página com dois planos, básico isca e premium venda, mais pop-up no clique do básico") e o exemplo de página analisado em 6.1 (três opções). E o **próprio autor** contradiz-se: o mapa dos 5 E (12.9), da mesma origem, manda "página, dois planos e pop-up de cross-sell no básico". Leitura provável: a régua muda com o ticket. Abaixo de ~R$40 a decisão é de impulso e uma segunda opção só dá ao comprador a hipótese de não comprar; acima disso o plano decoy paga-se. **É a contradição mais forte do lote e vale confirmar com a fonte de origem**, porque decide a estrutura da página inteira.
+25. ~~**UM preço só ou dois planos?**~~ **REGRA ADOTADA (2026-08-28, por leitura do material; não confirmada com a fonte de origem.)** O eixo é o **ticket**, e o corte é o teto da própria Fábrica: **até R$37, UM preço** (1 entrada, 1 bump, 1 upsell); **de R$47 para cima, dois planos** (básico isca, premium venda) com pop-up no clique do básico. A contradição some quando se olha o escopo declarado de cada fonte: 12.7-A é, pelo próprio cabeçalho, a anatomia da página de **low ticket puro (R$19,90-37)**; o exemplo de 5.3 é Portugal a $790 e $1490, ou seja outra faixa. Sobra 11.3, que fala de "low ticket" genérico e manda dois planos: como no material "low ticket" vai até R$97, ele cai do lado de cima do corte e deixa de conflitar. O exemplo de três opções (amostra de mercado, 6.1) não é régua. **Motivo de fundo:** abaixo de R$40 a compra é de impulso e uma segunda opção só oferece a hipótese de não comprar; acima disso o plano decoy se paga.
 
 26. **Garantia: 7 ou 14 dias?** A seção 5.4 fixa 14 dias no Brasil e 14 a 28 fora. A anatomia da Fábrica (12.7-A, bloco 08) fixa **7 dias incondicional**, e trabalha em reais, ou seja é claramente mercado brasileiro. Note que o CDC obriga a 7 dias no mínimo para compra fora do estabelecimento: a Fábrica está no piso legal, e os 14 dias de 5.4 são escolha comercial, não obrigação. Leitura provável: 7 dias é o mínimo que passa; 14 dias reduz a fricção da compra e aumenta o reembolso. **Uma vez publicada, a garantia não se encurta sem decisão explícita: encurtar prazo depois da venda é o tipo de mudança que gera disputa.**
 
@@ -39,4 +42,62 @@ Contradições e lacunas encontradas ao destilar esta metodologia, extraídas pa
 
 30. **Qual modelo roda a Fábrica: Opus ou Pro?** A fonte de origem gravada (12.7) diz "modelo: Opus" e desaconselha o modelo mais caro do topo da linha por não se pagar nesta tarefa. O guia impresso da mesma origem (12.7-A) lista como requisito apenas "assinatura paga do Claude, o Pro já serve". Não é conflito de facto: "Pro" é o plano e "Opus" é o modelo, e o plano Pro dá acesso a modelos fortes. Leitura adotada: **plano pago basta; escolher o modelo mais forte que o plano permitir, e não pagar por Fable para isto.** Registado porque lido à letra parecem instruções diferentes.
 
-31. **Quantos criativos por conjunto?** O checklist da Fábrica (12.7-A) pede "pelo menos 6 criativos no mesmo conjunto, de preferência 10". A seção 4.12.3 fixa "um conjunto por ângulo, até 5 criativos dentro". Os dois números medem coisas diferentes (um é o conjunto de anúncios do gerenciador, o outro é o conjunto criativo por ângulo de teste), mas na prática colidem se cada ângulo virar um conjunto: 5 é menos que o mínimo de 6. Leitura provável: 5 por ângulo é a régua de **produção** e 6 a 10 é a régua de **entrega no gerenciador**, o que se resolve pondo mais de um ângulo no mesmo conjunto ou completando com variações. **Confirmar antes de montar a campanha**, se a operação estiver desenhada com 5 por ângulo.
+31. **Quantos criativos por conjunto?** O checklist da Fábrica (12.7-A) pede "pelo menos 6 criativos no mesmo conjunto, de preferência 10". A seção 4.12.3 fixa "um conjunto por ângulo, até 5 criativos dentro". Os dois números medem coisas diferentes (um é o conjunto de anúncios do gerenciador, o outro é o conjunto criativo por ângulo de teste), mas na prática colidem se cada ângulo virar um conjunto: 5 é menos que o mínimo de 6. Leitura provável: 5 por ângulo é a régua de **produção** e 6 a 10 a régua de **entrega no gerenciador**, o que se resolve pondo mais de um ângulo no mesmo conjunto ou completando com variações. **Confirmar antes de montar a campanha**, se a operação estiver desenhada com 5 por ângulo.
+
+32. **Documento de identidade de terceiro para verificar o perfil — registrado, não adotado.** Um material sobre crescimento de mentoria ensina, para passar a verificação de perfil do Instagram, a usar "foto que combine com o documento" e dá o exemplo literal de pôr uma pessoa no perfil e enviar o documento de outra pessoa da família dela. **Risco de banimento e de personificação: mora em [`guardrails.md`](guardrails.md#32--documento-de-identidade-de-terceiro-para-verificar-o-perfil).** A parte legítima da mesma fonte (categoria "Comunidade" é a mais fácil de verificar, foto coerente com o documento **da própria pessoa**) foi adotada e está em 6-A.
+
+33. ~~**Barra de progresso adiantada de propósito no player de VSL.**~~ **REGRA ADOTADA (2026-09-04, decisão do dono da operação.)** O player de VSL não reflete o tempo real do vídeo: a barra avança mais rápido (fator de 1,05 a 1,25), com platôs de 200-800ms, e só alinha com o tempo real perto dos 90% do vídeo. **A barra fica assim mesmo, e a regra vale inteira.** Razão da decisão: é comportamento padrão de player de VSL no nicho, não viola termo de plataforma nenhum e não expõe conta nem BM. Fica registrado como padrão escuro **assumido**, não como tática proibida. Se algum dia a operação for para mercado com régua de práticas comerciais mais dura, é este o item a rever primeiro. Ver 6B.1.
+
+34. ~~**Comprar a oferta do concorrente e pedir reembolso para extrair o entregável.**~~ **FECHADO (2026-09-04, decisão do dono da operação.)** Uma aula de mineração de ofertas ensina comprar, baixar o material, estudar a estrutura e pedir reembolso no prazo, tratando o valor como custo de pesquisa. **É o que a fonte ensina, não é prática desta metodologia.** Fica registrado como o que a fonte ensina, sem virar passo de processo: não se usa, e ninguém precisa decidir volume nem limite. Ver 12.5.
+
+35. ~~**Os 5 ângulos de criativo: autoridade e urgência, ou prova e objeção?**~~ **REGRA ADOTADA (2026-09-04, decisão do dono da operação.)** Os dois conjuntos entram: são **7 ângulos ao todo** (curiosidade, dor, antes/depois, prova, objeção, autoridade, urgência) e **escolhem-se 5 por oferta**. O conflito era falso porque os pares atacam coisas diferentes: prova e objeção atacam a **descrença** (não acredito que funciona), autoridade e urgência atacam a **inércia** (acredito, mas não agora). Qual par usar sai do diagnóstico da oferta: público que já conhece o mecanismo e não compra pede autoridade e urgência; público que nunca viu aquilo pede prova e objeção. Ver 12.7-A.
+
+36. ~~**Formato do criativo da Fábrica: 1:1 ou 4:5?**~~ **REGRA ADOTADA (2026-09-04, decisão do dono da operação.)** Fica **4:5 retrato**, como já estava em 12.7-A. Ocupa mais área no feed e é o padrão atual da Meta para imagem. O formato 1:1 de uma versão mais antiga do prompt de mineração é para ignorar: quem copiar o prompt cru tem de trocar o formato à mão.
+
+37. ~~**Prompt de imagem: texto sobreposto na geração ou só depois?**~~ **REGRA ADOTADA (2026-09-04, decisão do dono da operação.)** Não se fixa regra estática, porque a capacidade dos geradores muda depressa: **pesquisar, na hora, qual gerador está melhor a compor texto em português e decidir por aí.** O default continua a ser o de 12.7-A (imagem sem texto, headline entra depois no Canva), porque é o que nunca falha. Quem quiser texto na geração tem de validar antes, naquele gerador, naquela semana, e conferir a ortografia peça a peça. A regra permanente é a verificação, não o formato.
+
+38. **Pixel direto no `<head>` ou pixel dentro do GTM?** A régua de connect rate (6.3-6.4) é explícita: pixel como **primeiro script do `<head>`, chamado direto, sem GTM**, um pixel só, e nunca em web worker, porque o connect rate mede o instante em que o `PageView` consegue falar. O material de rastreamento (seção 17) faz o oposto: o pixel vira uma tag dentro do container web do GTM, atrás da Tag do Google e do acionador DOM Ready. **Não é conflito de opinião, é troca de moeda:** GTM atrasa o `PageView` (e portanto derruba o connect rate medido) em troca de container de servidor, API de Conversões e resistência a bloqueador de anúncio, que sobem a qualidade de correspondência e o volume de compras atribuídas. As duas fontes estão certas dentro do próprio objetivo e nenhuma cita a outra. **Leitura provável:** página de venda direta que vive de connect rate fica com o pixel no `<head>`; operação de negócio local ou de funil com formulário, que vive de matching, fica com o GTM. Híbrido (pixel no `<head>` **e** GTM só para os demais eventos) é possível e nenhuma das duas fontes discute. **Confirmar antes de montar rastreamento em página de venda direta.**
+
+39. **"Day trade" contra a régua de 3x.** Uma fonte externa (transcrição automática, com qualidade de áudio instável) trata a campanha como day trade: escalar agressivo enquanto há lucro, parar no instante em que o resultado cai. A régua de 3.7 diz o contrário: não julgar, não pausar e não alterar nada antes de acumular gasto de 3x o Bid Cap, e 3.2 dá até 10 dias para o algoritmo readquirir inteligência. Como a fonte externa é transcrição automática danificada, **a régua de 3x continua valendo por padrão** até haver confirmação da gravação original. Registrado porque as duas leituras levam a decisões opostas no mesmo dia de campanha.
+
+40. **Uma campanha só ou separar quando o desempenho diverge?** A seção 3.7 fixa 1 campanha, 1 conjunto, X criativos, e **proíbe duplicação de campanhas** como padrão. A mesma fonte externa do ponto 39 recomenda começar com 3 a 5 anúncios numa campanha única e **separar em campanhas individuais** se o desempenho divergir muito. Pode não ser conflito real (separar por divergência é exceção, não padrão), mas a régua de 3.7 não abre essa exceção em lugar nenhum. **Confirmar antes de duplicar campanha de uma oferta em produção.**
+
+41. **Duas configurações que o áudio do material de rastreamento não fecha.** (a) No passo "Gerenciar detecção automática de eventos" do GA4, o áudio de origem fica ambíguo entre "desmarcar tudo" e "marcar tudo". A lógica do resto do material (só o GTM dispara evento, para não duplicar) aponta para manter desativado, que foi o que se fez em produção. (b) Em outro passo, o parâmetro `send_page_view` é adicionado na Tag do Google mas o valor atribuído não é dito no áudio. O valor que faz sentido é `false`, para a Tag do Google não disparar um `page_view` automático em cima do `page_view` que a tag dedicada já manda. **Nos dois casos a leitura provável é a mesma (evitar duplicidade), e nos dois o custo de errar é evento contado duas vezes.** Conferir na gravação original antes de replicar o container. Ver 17.2 e 17.4.
+
+42. **Autoplay mudo contra clicar para tocar na VSL.** O shard [`06b-player-vsl.md`](06b-player-vsl.md) §6B.1 manda o player arrancar em autoplay mudo com o aviso "Clica para ouvir". Pesquisa externa de 2026 dá o contrário: um teste do Vmaker mediu **41,2% de conversão com click-to-play e capa forte contra 9,7% com autoplay**, e o consenso do nicho moveu-se na mesma direção à medida que os navegadores apertaram as regras de autoplay. **Regra do projeto mantida: o shard vence**, e uma página em produção foi construída com autoplay mudo; a troca custa um atributo no HTML. Fechar com teste A/B assim que houver tráfego. Aberto em 2026-09-05.
+
+43. **FAQ com 13 perguntas contra as 5 do shard 12c.** O bloco 09 da anatomia de [`12c`](12c-anatomia-low-ticket.md) pede 5 perguntas, cobrindo as objeções da ficha mais reembolso e acesso. A copy de uma oferta em produção traz 13, e as 13 ficaram na página, em acordeão fechado, porque essa copy é canônica e cada resposta é curta. **Não foi decidido por regra, foi decidido por omissão:** perguntar ao dono da operação se corta para 5. Aberto em 2026-09-05.
+
+44. **Nome de pessoa real como prova emprestada — registrado, bloqueado.** Uma fonte sobre a jornada do desejo à oferta usa, como exemplo de headline vencedora, uma promessa que cita nominalmente uma influenciadora sem relação com a oferta. **Risco de direito de imagem, CDC e política da Meta: mora em [`guardrails.md`](guardrails.md#44--nome-de-pessoa-real-como-prova-emprestada).** **DECIDIDO (2026-09-09, decisão do dono da operação): fica bloqueado.** O conceito de prova emprestada (§18.2) foi adotado; o que ficou de fora é nomear terceiro sem autorização escrita. **A exceção é contratual:** influenciador que seja co-produtor da oferta (seção 9) pode ser nomeado.
+
+45. **Vídeo de terceiro do TikTok como criativo próprio — registrado, bloqueado.** Um material sobre ferramentas de criação de criativos e áudios ensina a baixar vídeo do TikTok sem marca d'água para usar como B-roll, e a usar imagem de pessoa de outro país para "testar aceitação". **Risco de direito autoral, de imagem e de termos de plataforma: mora em [`guardrails.md`](guardrails.md#45--vídeo-de-terceiro-baixado-do-tiktok-como-criativo-próprio).** **DECIDIDO (2026-09-09, decisão do dono da operação): fica bloqueado, sem exceção.** O resto do material (bancos com licença, alternativa gratuita de voz, TikTok como referência de formato) foi adotado e está em 4.15.
+
+46. ~~**A headline carrega o mecanismo, ou só a promessa?**~~ **REGRA ADOTADA (2026-09-09, decisão do dono da operação.)** O conflito era de vocabulário. A 5.5 proíbe a **explicação** do mecanismo na headline ("a *explicação* do mecanismo fica na VSL"); a §18.13 exige que ele seja **nomeado**. Nomear leva 3 palavras, explicar leva uma VSL: são operações diferentes e as duas linhas ficam de pé. **A headline nomeia, a VSL explica.**
+
+    | Superfície | O que a headline carrega |
+    |---|---|
+    | **Página de vendas** | destino + sacrifício + **mecanismo com nome** |
+    | **Gancho de criativo** | destino + sacrifício. O mecanismo entra nos primeiros 5 segundos, não na primeira linha (o teste dos 3 segundos de §18.2 não sobrevive a headline longa) |
+    | **VSL** | inalterado: o mecanismo é o bloco `Tese` (§18.6 e §18.8) |
+
+    **Desempate quando houver dúvida: o estágio de sofisticação de §18.4.** Mercado em estágio 1 ou 2, a promessa sozinha basta e o mecanismo atrapalha; de 3 para cima o mecanismo é o único diferencial e ficar de fora da headline entrega uma promessa igual à de todos os concorrentes. Como §18.4 fixa que quase todo nicho grande de low ticket brasileiro já está em 4 ou 5, **o default do projeto passa a ser mecanismo na headline**, o inverso do que 5.5 dizia sozinha. Cruza com o ponto 7 (headline de produto contra headline de promessa), que continua aberto.
+
+47. ~~**Sete blocos de copy contra os seis blocos da VSL.**~~ **REGRA ADOTADA (2026-09-09, por leitura do material; não confirmada com a fonte de origem.)** A §4.7 fixa a VSL em 6 blocos (Lead, História, Produto, Oferta, CTA, Perguntas); a §18.8 fixa a copy em 7 (Lead, Quem fala, História, Tese, Build-up, Oferta, Fechamento). Não competem: os 7 são a versão fina dos 6, e o mapa é direto.
+
+    | 7 blocos (§18.8) | 6 blocos (§4.7) |
+    |---|---|
+    | 1 Lead | 1 Lead |
+    | 2 Quem fala | dentro de 2 História |
+    | 3 História | 2 História |
+    | **4 Tese** | **não nomeado** (cai entre 2 e 3) |
+    | 5 Build-up | 3 Produto |
+    | 6 Oferta | 4 Oferta |
+    | 7 Fechamento | 5 CTA + 6 Perguntas |
+
+    **A lista de 7 é a de trabalho** (é ela que diz onde estão os 80% do resultado: blocos 1 e 4) e **a de 6 continua válida como checagem rápida de VSL**. O que a de 6 esconde é justamente o bloco `Tese`, o mecanismo, que a §18.8 aponta como um dos dois que mais vendem. Quem monta VSL pela lista de 6 tem de garantir que a tese está lá dentro, com nome ou sem.
+
+48. **Preço de referência riscado que nunca foi cobrado — registrado, bloqueado.** A anatomia de página (12c bloco 06 e §6.1) manda mostrar "valor cheio riscado, entrada destacada", mas em low ticket esse valor cheio é a **soma do valor atribuído aos materiais**, não um preço que alguém tenha pago. **Risco sob a Diretiva Omnibus e o DL 57/2008: mora em [`guardrails.md`](guardrails.md#48--preço-de-referência-riscado-que-nunca-foi-cobrado).** A ancoragem por valor continua permitida, desde que não se disfarce de desconto e sem riscar o número.
+
+---
+
+**Contagem (2026-09-09):** 48 pontos ao todo: 22 em aberto, 16 resolvidos ou adotados, 7 bloqueados em guardrails (20, 21, 23, 32, 44, 45, 48), e 3 sem conteúdo publicável por serem contabilidade local (5, 6, 13), com o número preservado só para não quebrar link de outro shard.

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

@@ -17,7 +17,7 @@ Someone who already runs traffic, reads metrics and has mined offers before. Do
 
 Read the Cérebro state first (via the `cerebro` skill). If `lowticket-metodologia` is installed, read `knowledge/INDEX.md` + `knowledge/guardrails.md`, then:
 
-- **`12-mineracao-ofertas.md`**: the price trick, the 0-10 rubric with a cut at 6, the three safety rules
+- **`12-mineracao-ofertas.md`**: the price trick, the Ad Library filter checklist and keyword taxonomy, the 0-10 rubric with a cut at 6, the three safety rules
 - **`12a-mineracao-veredito.md`**: §12.5, the scoring ruler and what disqualifies
 
 Where a generic skill contradicts those shards, the shard wins and you say so. This skill has **no memory of its own**.
@@ -45,15 +45,15 @@ Deliver terms in five buckets, in one copyable block:
 4. **Mecanismo**: método, protocolo, sistema, técnica, desafio, plano, estratégia
 5. **Hype**: terms and mechanisms gaining traction right now in that market
 
-Then offer the crossings: mechanism × pain × price anchor.
+Lead with the crossing that actually cuts noise: price anchor × niche trigger. Offer mechanism × pain as secondary coverage. Before they search, remind them of the Ad Library filter checklist in `12-mineracao-ofertas.md` §12.1: single country, all media types, widest date range, active status, price keyword in exact phrase.
 
 ## B. Verdict on one offer
 
 Four sections, in this order.
 
-**VEREDITO**: one of `DIAMANTE` · `OURO` · `MÉDIA` · `DESCARTAR`, plus one sentence saying why.
+**VEREDITO**: one of `DIAMANTE` · `OURO` · `MÉDIA` · `DESCARTAR`, plus one sentence saying why. Criteria per level are in `references/rubrica.md`.
 
-**FARO**: the signals: apparent time running, number of ads, creative variety, scale indicators, campaign repetition, domain structure, operational maturity. Longevity reference: 30+ days is initial validation, 60+ is a strong signal, 90+ is very strong, **under 14 days is insufficient evidence and is not modeled as proven**.
+**FARO**: a 60-second read, checked in order, stop at the first rejection: time running, number of active ads, its own domain (a bare checkout URL is a weak signal, an owned domain reads as a serious operation), a coherent page. Then the slower signals for the full analysis: creative variety, scale indicators, campaign repetition, operational maturity. Longevity reference: 30+ days is initial validation, 60+ is a strong signal, 90+ is very strong, **under 14 days is insufficient evidence and is not modeled as proven**. Counter-intuitive read: a weak page still running 30+ days is a *stronger* signal, not weaker - demand survives despite bad execution.
 
 **ANÁLISE TÉCNICA**: page architecture, promise, mechanism, price, anchoring, checkout, order bump, upsell, cross-sell, likely deliverable, platform, monetization structure, sophistication. Label every line as **observação** (actually visible) or **inferência** (probable from the signals). An inference presented as a fact is the failure mode of this whole exercise.
 
@@ -61,7 +61,7 @@ Four sections, in this order.
 
 Then reposition: *if I turned this into my own operation, what would I change?* Price, promise, name, mechanism, deliverable, bonus, order bump, checkout, post-purchase, domain, monetization. The logic is **capture the existing demand without copying the offer.**
 
-Ticket repositioning is a working hypothesis, never applied mechanically. The table is in `references/rubrica.md`, and shard `12a` flags that the offer-factory shard uses a different one above R$97 (open point 24).
+Ticket repositioning is a working hypothesis, never applied mechanically: 60-80% below origin, floor at R$9. The table is in `references/rubrica.md`; per the 2026-08-28 rule in `12a`, it also wins above R$97 - the offer-factory's fixed R$37 cap is the low-ticket-puro price floor, not a repositioning table (open point 24).
 
 ## C. Comparison
 
@@ -102,7 +102,7 @@ The reverse-engineering read order is fixed: **Demanda → Hook → Promessa →
 
 ## Platform and margin
 
-When the platform is identifiable, weigh it by **preço × taxa × custo fixo por transação × volume × margem**. What matters is the net received per sale, not the platform's popularity. Only use fee numbers that are actually available, and label estimates as estimates.
+Identify the platform by clicking through to the competitor's checkout and reading its domain - that alone gets you fee range, margin and available features (bump, one-click upsell). Weigh it by **preço × taxa × custo fixo por transação × volume × margem**. What matters is the net received per sale, not the platform's popularity. Fee profile table in `references/rubrica.md`. Only use fee numbers that are actually available, and label estimates as estimates.
 
 ## Out of scope
 

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

@@ -6,6 +6,17 @@
 
 `DIAMANTE` · `OURO` · `MÉDIA` · `DESCARTAR`, sempre com uma frase dizendo por quê.
 
+**Critérios por nível** (fonte: `12a-mineracao-veredito.md` §12.5):
+
+| Nível | Critério | Ação |
+|---|---|---|
+| Diamante | 90+ dias no ar, domínio próprio, funil completo (bump + upsell), entregável replicável | modela hoje |
+| Ouro | 60+ dias, domínio próprio, pelo menos 1 order bump | modela nesta semana |
+| Média | 30 dias, sinais mistos, entregável pesado | revisita em 15 dias |
+| Descartar | menos de 14 dias, poucos anúncios, entregável que depende de vídeo, ou nicho sem autoridade | descarta |
+
+**Faro em 60 segundos** (checklist, para na primeira reprovação): tempo no ar → número de anúncios ativos → domínio próprio (URL de checkout direta é sinal fraco; domínio próprio é sinal de operação séria) → página coerente.
+
 ## Sinais de longevidade
 
 | Tempo no ar | Leitura |
@@ -22,12 +33,13 @@ 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
+- página de vendas ruim + anúncio há 30+ dias no ar → sinal MAIS forte, não mais fraco (há demanda apesar do material fraco)
 
 Cruzar sempre: **tempo + volume + repetição + estrutura + monetização.**
 
 ## Reposicionamento de ticket
 
-Hipótese de teste, não regra mecânica:
+Hipótese de teste, não regra mecânica. Proporção geral: **60% a 80% abaixo do preço original.** Piso de preço: **abaixo de R$9 o produto "vira lixo mental"** (não valoriza, não consome, reclama mais).
 
 | Preço de origem | Vender a |
 |---|---|
@@ -36,7 +48,7 @@ Hipótese de teste, não regra mecânica:
 | 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.
+> Existe uma segunda régua na metodologia (valor fixo por faixa, teto em R$37), usada pela fábrica de ofertas quando o agente roda sozinho. **Regra adotada em 2026-08-28**: a tabela acima é a de decisão humana e é ela que vale acima de uma origem de R$97; o teto de R$37 da outra é o piso de preço do low ticket puro, não uma regra de reposicionamento. Ver ponto em aberto 24 em `pontos-em-aberto.md`.
 
 ## Tabela de comparação
 
@@ -59,6 +71,19 @@ Fecha com **RECOMENDAÇÃO**: uma oferta escolhida, e três pontos: por que ela
 
 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.
 
+## Plataforma por margem
+
+Identificar a plataforma clicando no botão de compra do concorrente e lendo o domínio do checkout; daí se infere taxa, margem e recursos disponíveis (bump, upsell de 1 clique). Decidir pelo **valor líquido recebido**, não pela popularidade da marca.
+
+| Perfil | Taxa | Onde usar |
+|---|---|---|
+| Marketplace consolidada | ~10% + taxa fixa | ticket acima de R$97 |
+| Intermediária | ~9% + taxa fixa de alguns reais | R$47-147 |
+| Focada em conversão | 4-6% + taxa fixa baixa | - |
+| Gateway próprio integrado | menos de 5% | low ticket R$9-27 |
+
+Sem compra de 1 clique pós-checkout, trocar de plataforma ANTES de montar o funil.
+
 ## Perguntas do corte fino
 
 - Onde o concorrente está deixando dinheiro?

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

@@ -30,7 +30,9 @@ Speed fixes the leak between the click and the page. It does not fix a bad offer
 
 ## 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.
+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 for a pure low-ticket page live in `12c-anatomia-low-ticket.md` (the 11-block anatomy, not `12b` anymore); VSL player behavior (autoplay, progress bar, weight) is `06b-player-vsl.md`; conversion-side reasoning is `page-cro`. Where a generic skill contradicts the shard, the shard wins and you say so.
+
+**Open conflict, do not resolve it alone.** §6.3-6.4 (this skill's rule) fires the pixel direct, first in `<head>`, no tag manager. `17-rastreamento.md` installs that same pixel *inside* GTM, as part of the full GA4 + Meta + server-container stack. This is ponto 38 of `pontos-em-aberto.md` in `lowticket-metodologia`, and it is unresolved. If the page already runs tracking through GTM, do not rip the pixel out of the container to chase the speed target: ask which rule wins before touching it.
 
 This skill has **no memory of its own**.
 
@@ -56,7 +58,7 @@ Ordered by return on effort, not by technical elegance. Stop and report if a ste
 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.
+4. **Pixel.** First script in `<head>`, direct call, no tag manager: that is §6.3-6.4's rule. **Except:** if the page already runs tracking through GTM (the full stack in `17-rastreamento.md`), pulling the pixel out of the container is the open conflict above (ponto 38); ask before doing it.
 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.
@@ -95,7 +97,7 @@ At most **five questions, all in one round**, and only when something essential
 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?
+5. What is the pixel ID, and is tracking already running through GTM? If so, that is the open conflict on pixel placement (ponto 38, `17-rastreamento.md` vs. §6.3-6.4): flag it and ask which rule wins before touching the container.
 
 **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.
 

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

@@ -33,6 +33,7 @@ Player com autoplay inteligente confunde medidor de velocidade: o carregamento e
 - 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.
+- Cruzar com a Utmify antes de decidir qualquer coisa: o gerenciador de anúncios arredonda pra cima.
 
 ## Relatório final
 

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

@@ -26,6 +26,8 @@ Regras associadas:
 - **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.
 
+**Conflito em aberto:** esta regra (pixel direto, sem GTM) vale para a régua de connect rate de §6.3-6.4. O shard `17-rastreamento.md` instala o pixel **dentro** do GTM, como parte da stack completa (GA4 + Meta + container de servidor), ponto 38 de `pontos-em-aberto.md`, não resolvido. Página que já roda essa stack: não arrancar o pixel do container sozinho, perguntar antes.
+
 ## 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.
@@ -121,6 +123,8 @@ A capa estática vira o LCP; o script do player entra depois, fora do caminho cr
 
 **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.**
 
+O comportamento do player em si (autoplay mudo, bloqueio de pause/seek, barra de progresso) está especificado em `06b-player-vsl.md` §6B.1-6B.3; aqui fica só o que muda peso e carregamento.
+
 ## Rede: cache, prefetch e checkout
 
 ```

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

@@ -49,6 +49,8 @@ Attack order is fixed and runs backwards from the money:
 
 Checkout first, page second, creative last. Benchmarks per transition are in `references/reguas.md` and in shard `02`.
 
+A rate that cannot exist (over 100%, a step converting better than the one before it, zero sales while checkout is clearly working) is not a funnel problem to attack: it is dirty tracking. A duplicated event, a missing Purchase or a UTM that never arrived produces exactly this. Send it to `17-rastreamento.md` instead of prescribing a page or creative fix.
+
 ### 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.**

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

@@ -32,16 +32,17 @@ Depois de 24h rodando E 3x o bid cap gasto, o pause é justificado quando: ROAS
 - **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
+## Funil: as 5 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 |
+| Cliques → Visitas | < 70% | 70-90% | ≥ 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 |
+| Venda Iniciada → Venda Aprovada (Pix) | < 50% | 60-75% | 75-90% | pagamento: aprovação Pix, recuperação de pendente |
+| Venda Iniciada → Venda Aprovada (Cartão) | < 60% | 60-75% | 75-90% | pagamento: cartão recusado, retry |
 
 **Ordem de ataque:** de trás para frente. Checkout e pagamento primeiro, página depois, criativo por último.
 

package/src/modules/wizz/README.md

@@ -11,7 +11,7 @@ Personalização do WIZZ para a Wizz: linguagem fácil e resumida, cada agente t
 | `wizz-copy` | ✍️ | Copy, e-mail, headlines | copywriting, email-sequence, humanizer, copy-editing |
 | `wizz-seo` | 🔍 | SEO tradicional e de IA | seo-audit, ai-seo, schema-markup, programmatic-seo, site-architecture |
 | `wizz-growth` | 📈 | Marketing, CRO, lançamento, preço, churn | marketing-ideas, page-cro, launch-strategy, pricing-strategy, churn-prevention |
-| `wizz-ads` | 📢 | Mídia paga | paid-ads, ad-creative, analytics-tracking, MCP meta-ads |
+| `wizz-ads` | 📢 | Mídia paga | paid-ads, ad-creative, analytics-tracking |
 | `wizz-memoria` | 🧠 | Memória do projeto | cerebro |
 
 Os papéis de dev/produto reusam os agentes WIZZ (Mary, John, Winston, Amelia, Sally, Paige), personalizados em PT-BR pelos overrides em `overrides/`.

package/src/modules/wizz/_shared/model-ladder.md

@@ -14,6 +14,8 @@ O modelo da sessão principal é o chefe: orquestra, arbitra conflito entre exec
 
 Como saber quem é o chefe em Claude Code: o system prompt declara o modelo da sessão ("You are powered by the model named ..."). Fable e Mythos ficam acima de Opus.
 
+A mesma lógica vale em toda plataforma, trocando os nomes pelos da tabela abaixo. Em Codex: sessão num modelo acima de gpt-5.6 (ex.: astra) → `wizz-exec-opus` (gpt-5.6, effort high) é o destino padrão do difícil e `wizz-exec-review` roda nele; sessão já em gpt-5.6 → o chefe absorve o degrau Forte. Em OpenCode e Gemini CLI, idem com claude-opus-5 e gemini-3-pro-preview.
+
 ## Tabela de degraus
 
 | Degrau | Subagente | Uso | Claude Code | Codex | OpenCode | Gemini CLI |

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

@@ -1,12 +1,12 @@
 ---
 name: wizz-ads
-description: Wizz Method Paid Media Agent. Use when you need ad campaigns (Google, Meta, TikTok, LinkedIn), ad creatives, and tracking. Routes to paid-ads, ad-creative and analytics-tracking, and uses the meta-ads MCP for real management on Meta.
+description: Wizz Method Paid Media Agent. Use when you need ad campaigns (Google, Meta, TikTok, LinkedIn), ad creatives, and tracking. Routes to paid-ads, ad-creative and analytics-tracking.
 ---
 
 # Ads — Mídia Paga
 
 ## Visão geral
-Você é o Ads do Wizz. Planeja campanhas, gera variações de criativo e acompanha métricas. Roteia para as skills globais via a ferramenta `Skill` e usa o MCP `meta-ads` quando for gestão real de campanhas Meta.
+Você é o Ads do Wizz. Planeja campanhas, gera variações de criativo e acompanha métricas. Roteia para as skills globais 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`).
@@ -20,13 +20,10 @@ Você é o Ads do Wizz. Planeja campanhas, gera variações de criativo e acompa
 
 ## Como trabalho (ponte global)
 
-> **Fonte única (registry) — leia SEMPRE antes dos exemplos abaixo:** a lista real da sua área (`ads`) vive no `skills-registry.yaml`. Resolva primeiro a **fatia leve da sua área**, `{project-root}/_wizz/_config/registry/ads.yaml` (já vem como o bloco `areas.ads` 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.ads` 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`), `clis:` (`check:` → se faltar mostre o `install:`, opt-in, respeite `platform:`) e `mcps:` (`claude mcp add <id>` com o bloco `server`, ex. `meta-ads`). Os exemplos abaixo são atalho legível; o registry é a verdade e pega novidades automático (ex. `arcads` p/ gerar vídeo-ad).
+> **Fonte única (registry) — leia SEMPRE antes dos exemplos abaixo:** a lista real da sua área (`ads`) vive no `skills-registry.yaml`. Resolva primeiro a **fatia leve da sua área**, `{project-root}/_wizz/_config/registry/ads.yaml` (já vem como o bloco `areas.ads` 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.ads` 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`), `clis:` (`check:` → se faltar mostre o `install:`, opt-in, respeite `platform:`) e `mcps:` (`claude mcp add <id>` com o bloco `server`). Os exemplos abaixo são atalho legível; o registry é a verdade e pega novidades automático (ex. `arcads` p/ gerar vídeo-ad).
 - Estratégia de campanha, segmentação, lances, ROAS → `paid-ads`
 - Variações de criativo, headlines, copy de anúncio → `ad-creative`
 - Tracking, conversões, UTMs, pixel → `analytics-tracking`
-- Gestão real de campanha Meta (criar/editar/medir) → MCP `meta-ads`
-
-Nunca exponha o `META_ACCESS_TOKEN` em log ou código.
 
 ## Encerramento
 Termine com `✅ O que fiz` / `➡️ Próximo passo` / `🎯 Comando`.

package/src/modules/wizz/agents/wizz-ads/customize.toml

@@ -21,12 +21,10 @@ activation_steps_append = [
 
 persistent_facts = [
   "Gate de planejamento: pedido de execução com complexidade alta e sem PRD/story/brief correspondente → pergunto 1x se crio o artefato antes (recomendado) ou pulo; nunca 2x na mesma cadeia. Regras completas: ler _shared/planning-gate.md do módulo wizz SÓ quando o gate disparar.",
-  "Nunca exponho o META_ACCESS_TOKEN em log, código ou commit.",
-  "Para gestão real de Meta uso o MCP meta-ads; para estratégia uso a skill paid-ads.",
   "Falo PT-BR fácil. Toda campanha precisa de tracking antes de subir.",
 ]
 
-role = "Planejar e gerenciar mídia paga (estratégia, criativo, tracking) roteando para as skills globais e para o MCP meta-ads."
+role = "Planejar e gerenciar mídia paga (estratégia, criativo, tracking) roteando para as skills globais."
 identity = "Gestor de tráfego orientado a ROAS: testa criativos, corta o que não performa, escala o que funciona."
 communication_style = "Direto e numérico, em PT-BR fácil. Fala em CPA, ROAS e próximos testes."
 
@@ -51,8 +49,3 @@ prompt = "Invoque a skill GLOBAL 'ad-creative' via a ferramenta Skill para gerar
 code = "TR"
 description = "Tracking, conversões, UTMs, pixel"
 prompt = "Invoque a skill GLOBAL 'analytics-tracking' via a ferramenta Skill."
-
-[[agent.menu]]
-code = "ME"
-description = "Gestão real de campanha Meta (criar/editar/medir)"
-prompt = "Use o MCP 'meta-ads' (via ToolSearch para carregar as ferramentas) para gerenciar campanhas reais no Meta. Nunca exponha o token."

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

@@ -75,7 +75,7 @@ O Diretor (`wizz-router`) já fez a triagem e te entregou porque é complexo. Se
 2. **Enriquecimento = o `skills-registry.yaml`**. Para a área escolhida, ele diz O QUE o agente puxa:
    - `areas:` — `agent` (deve casar com o do menu) e `skills:` (cada uma com `id` + `when` curto). Instrua o agente a invocar a(s) skill(s) global(is) cujo `when` casa com o pedido.
    - `utility:` — skills cross-cutting (find-skills, enhance-prompt, wizz-router). Ofereça quando couber.
-   - `mcps:` (por área) e `mcp_utility:` (cross-cutting) — MCP servers que a área usa pra AGIR de verdade (ex: architect→supabase, ads→meta-ads, analyst→exa, util→context7; qa NÃO usa MCP de browser — é agent-browser via CLI). Se o pedido precisa de acesso real à ferramenta e o MCP não está ativo (`claude mcp list`), proponha `claude mcp add <id> -- <command>` usando o bloco `server` do registry (secrets via env/placeholder).
+   - `mcps:` (por área) e `mcp_utility:` (cross-cutting) — MCP servers que a área usa pra AGIR de verdade (ex: architect→supabase, analyst→exa, util→context7; qa NÃO usa MCP de browser — é agent-browser via CLI). Se o pedido precisa de acesso real à ferramenta e o MCP não está ativo (`claude mcp list`), proponha `claude mcp add <id> -- <command>` usando o bloco `server` do registry (secrets via env/placeholder).
    - `clis:` (por área) e `cli_utility:` (cross-cutting) — ferramentas de linha de comando que o agente chama direto (não são skill nem MCP): ex. qa→agent-browser; designer→hyperframes/claude-video/buttercut/voicebox (vídeo); ads→arcads; growth→scrapling; seo→distribb. Quando o `when:` casar com o pedido, ofereça a tool: rode o `check:` pra ver se já está instalada; se não, mostre o `install:` (opt-in, nunca auto-rode sem confirmar). Respeite o campo `platform:` — se presente e não casar com o OS/arch atual, NÃO ofereça (ex.: `buttercut` é `darwin-arm64`, só Apple Silicon). Clone-and-run (buttercut/voicebox/arcads) instala no projeto; avise sobre deps pesadas.
    - `squads:` — painéis consultivos (rodam via `wizz-party-mode`). Quando o pedido pedir validação/estratégia de um `domain`, rode o squad ANTES do agente em `advises` executar.
 

package/src/modules/wizz/module.yaml

@@ -114,7 +114,7 @@ agents:
     title: Mídia Paga
     icon: "📢"
     team: wizz
-    description: "Gerencia anúncios pagos roteando para paid-ads, ad-creative e analytics-tracking (e o MCP meta-ads). Cria variações de criativo e acompanha métricas."
+    description: "Gerencia anúncios pagos roteando para paid-ads, ad-creative e analytics-tracking. Cria variações de criativo e acompanha métricas."
 
   - code: wizz-memoria
     name: Memória

package/src/skills-lib/ad-creative/SKILL.md

@@ -335,7 +335,7 @@ For pulling performance data and managing campaigns, see the [tools registry](..
 | Platform | Pull Performance Data | Manage Campaigns | Guide |
 |----------|:---------------------:|:----------------:|-------|
 | **Google Ads** | `google-ads campaigns list`, `google-ads reports get` | `google-ads campaigns create` | [google-ads.md](../../tools/integrations/google-ads.md) |
-| **Meta Ads** | `meta-ads insights get` | `meta-ads campaigns list` | [meta-ads.md](../../tools/integrations/meta-ads.md) |
+| **Meta Ads** | - | - | - |
 | **LinkedIn Ads** | `linkedin-ads analytics get` | `linkedin-ads campaigns list` | [linkedin-ads.md](../../tools/integrations/linkedin-ads.md) |
 | **TikTok Ads** | `tiktok-ads reports get` | `tiktok-ads campaigns list` | [tiktok-ads.md](../../tools/integrations/tiktok-ads.md) |
 

package/src/skills-lib/paid-ads/SKILL.md

@@ -298,7 +298,7 @@ For implementation, see the [tools registry](../../tools/REGISTRY.md). Key adver
 | Platform | Best For | MCP | Guide |
 |----------|----------|:---:|-------|
 | **Google Ads** | Search intent, high-intent traffic | ✓ | [google-ads.md](../../tools/integrations/google-ads.md) |
-| **Meta Ads** | Demand gen, visual products, B2C | - | [meta-ads.md](../../tools/integrations/meta-ads.md) |
+| **Meta Ads** | Demand gen, visual products, B2C | - | - |
 | **LinkedIn Ads** | B2B, job title targeting | - | [linkedin-ads.md](../../tools/integrations/linkedin-ads.md) |
 | **TikTok Ads** | Younger demographics, video | - | [tiktok-ads.md](../../tools/integrations/tiktok-ads.md) |