Abertura de Turma do MRZ Online ao Vivo (setup técnico)

Objetivo

Toda venda de MRZ online é de uma turma online ao vivo. Não existe mais venda de MRZ3 Gold Vitalício "solto" (decisão do Hugo, 2026-09-25).

Por quê: a aluna já entra numa turma com data, e a equipe tem 1 mês para atribuir o líder de GC antes da transmissão. A data real também dá urgência verdadeira para anúncio e closer.

Este procedimento cobre o setup técnico: produto, edição, checkout e validação. Como abrir e conduzir o GC está em procedimento-abertura-turma-mrz-tutorado.md.

Quando executar

• Abrir a turma pelo menos 1 mês antes da transmissão.
• A turma online transmite um MRZPR presencial escolhido pelo Hugo. Nem todo presencial tem versão online. O ideal é uma por mês, mas isso não é regra.
• Na assistência do presencial, o ASSISTENTE4 cuida do online.

Variáveis da turma

Passo a passo

A turma só funciona com três coisas amarradas: produto, edição e checkout. Se faltar uma, a venda cai no lugar errado ou a página não mostra a turma.

1. Produto (aba products, skill icdb-webapp-products)
   • slug = mrz3-online-br-{YYYYMM}, parent = mrz3, access_time = -1, showcase = 0, ativo.
   • O parent = mrz3 é o que libera o curso: o WebApp resolve o acesso pelo parent (inc_globals.php).
   • Checkout: não duplicar oferta na Eduzz. Mover o eduzz_id do checkout atual do slug anterior (turma passada ou mrz3-gold-vitalicio) para o slug novo. Quem comprar a partir daí cai na turma nova.
   • Tractor Pay (futuro): o externalReference da cobrança é o product_slug da turma. Não precisa mexer em eduzz_id.
   • Rodar o sync: POST /api/v1/sync {"type":"products"}.
2. Edição (aba editions, skill edition-update)
   • project_slug = mrzpr, is_online = 1, is_active = TRUE, datas da transmissão, checkout online e webapp_slugs = {slug}.
   • Rodar o sync: POST /api/v1/sync {"type":"editions"}.
   • Com a edição online ativa, a /mrz/online mostra a próxima turma sozinha (useMrzOnlineEdition no reorganize-site). Sem edição, a página cai no modo "próxima turma em breve".
3. Grupo do GC: criar o grupo e preencher participants_whatsapp_group na edição (ver o procedimento do GC).
4. Pixel (Eduzz): conferir no Órbita. A API não mostra o pixel, então isso é manual.
5. Anúncios: receita mrz-online em rz-cmo/agents/media-buyer-PAUL/prompts/recipes/. Por turma, só mudam o nome [MRZ-ONLINE-BR-{YYYYMM}], o end_time, o link e o excluded_cities. A cidade do presencial transmitido é excluída porque ela tem campanha própria. Nenhum criativo sobe sem aprovação do Hugo.
6. Botão nas PVs de cidade: /mrz/{cidade} tem um botão "faça online ao vivo" que leva para /mrz/online. Não repetir a oferta completa na página da cidade.

Quem executa

Gemini escreve as linhas na planilha com os valores exatos → Haiku confere → JOSHUA roda os syncs (ver kb/operations/delegacao/README.md).

Validação antes de ligar anúncio (obrigatória)

Usar a lógica do icdb-edition-checkup com a PV do MRZ:

• [ ] PV (/mrz/online e /mrz/{cidade}) → botão → checkout responde 200.
• [ ] O checkout é o eduzz_id (ou product_slug no Tractor) do slug da turma vigente, e mais nenhum slug tem esse eduzz_id.
• [ ] editions.webapp_slugs = slug da turma, que existe em products com parent = mrz3.
• [ ] A 1ª venda real matricula no slug certo: GET /api/v1/person?product_slug={slug}.

A mesma validação vale para as PVs de MRZPR por cidade (BH, Brasília, POA) quando recebem tráfego direto, e para a troca da Eduzz pelo Tractor Pay.

O que não fazer

• Não vender MRZ online sem turma e sem data.
• Não criar oferta nova na Eduzz por turma. O link é o mesmo e só a associação muda.
• Não deixar o mesmo eduzz_id em dois slugs ativos: a venda cai no primeiro que casar.
• Não ligar anúncio antes da validação acima.