wizz-method 1.18.3 → 1.19.0

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.