Comunicado Semanal de Aula

Objetivo

Gerar o comunicado semanal de aula/encontro ao vivo de uma comunidade, sempre a partir do template registrado no KB do produto — nunca inventando texto novo.

Fonte de verdade (templates por produto)

• Diretora: kb/products/comunidade-diretoras-aula-semanal.md
• MRZ: kb/products/comunidade-mrz-aula-semanal.md

Fluxo (rodar toda semana, um produto por vez)

1. Achar a próxima data de aula do produto: próxima quarta (MRZ) ou próxima quinta (Diretora) a partir de hoje.
2. Checar se já tem campanha real pra essa data (evitar duplicar): chamar GET https://app.reorganize.com.br/api/v1/campaigns/{campaign_slug} (header Authorization: Bearer <token>, mesmo token do /api/v1/audience — .secrets/reorganize_api_credentials.json ou REORGANIZE_API_TOKEN) com o campaign_slug esperado (mrz-aula-semanal-{data} / diretora-aula-semanal-{data}, data em AAAAMMDD). 404 = não existe, pode seguir. Se existir e status não for canceled, não recriar — só reportar o que já está agendado (dá pra conferir visualmente também em admin_comunicados_queue.php).
   • Esse endpoint (api/v1/campaigns.php, registrado em api/router.php) existe porque o host MySQL (mysql2.reorganize.com.br) só é alcançável de dentro da VPS — uma tentativa de conectar direto do Mac local dá Connection refused. Antes disso só dava pra checar duplicidade via SSH rodando SELECT na VPS; agora dá pra checar via HTTPS, do mesmo jeito que a audiência já é resolvida.
3. Calcular o tema da semana pela âncora do ciclo de 12 semanas registrada no KB do produto ("MRZ" / "Diretora") — contar semanas a partir da data-âncora, ciclo fecha em 12 e reinicia. Se a âncora estiver velha (~13+ semanas sem confirmação), perguntar a Hugo em vez de confiar cegamente no cálculo.
4. Montar assunto e corpo a partir do template de email do produto, preenchendo {tema}, {horario}, {link_zoom}, {link_agenda} — nunca inventar texto novo fora do template.
5. Dry-run via enviar-comunicado-email-skill (comunicado_email_cli.php sem --commit) pra confirmar contagem de audiência.
6. Conferir os checks (sem campanha duplicada pra data, âncora do ciclo fresca, audiência na faixa esperada — MRZ ~2.900, Diretora ~365). Se algum falhar, parar e mostrar pra Hugo antes do --commit.
7. Commit com --scheduled-at às 09:00 do dia da aula (não no horário da aula — decisão de Hugo em 2026-08-21, registrada também nos dois KBs de produto).
8. Avisar a equipe no Telegram [RZ] CS (chat_id -1004318153907, via rz-coo/agents/operations-JOSHUA/tools/telegram_send.py) — resumo curto: data, tema, audiência e link de acompanhamento em admin_comunicados_queue.php?campaign_slug=.... Substituiu o email pra cs@/financeiro@ (decisão de Hugo em 2026-09-07).
9. Devolver pra Hugo os links de acompanhamento de cada campanha agendada.

Regra de governança

Desde 2026-09-07 este fluxo é autopilot: com os checks do passo 6 passando, o agente roda o --commit real sem esperar OK no chat e reporta no Telegram [RZ] CS (passo 8). Hugo decidiu isso depois de semanas de execução correta com confirmação manual (desde 2026-08-20).

Vale só para o comunicado semanal de aula (MRZ/Diretora). Qualquer outro comunicado segue a regra geral de procedimento-envio-comunicados-por-ia.md: autorização explícita no chat, por envio.

Parâmetros do CLI específicos da aula semanal

Mecanismo de envio (script, dry-run, --commit, agendamento) é o genérico de enviar-comunicado-email. Aqui só muda:

• --product=<product_slug do produto> (diretora, mrz, ...)
• --campaign-slug=comunicado-<produto>-YYYYMMDD
• --subject="Aula de hoje: <tema>"
• --sender-name="Priscila Sabóia" (é a voz da aula, diferente do default "Reorganize")
• message_type fica no default academica (não passar --message-type)

Canal decidido em 2026-08-20: email pelo sistema de comunicados do WebApp, audiência person do produto (não WhatsApp em grupo).

Erros a evitar

• Não criar cronograma de temas novo para produto que ainda não tem um definido — decisão do Hugo/Priscila, não da automação.
• Não reintroduzir templates de "anúncio de mudança de estrutura" — foram removidos de propósito do KB da Diretora; o comunicado semanal é evergreen.
• Não usar /private/tmp ou scripts descartáveis — o script fica versionado em reorganize-webapp.

Status

MVP testado em produção em 2026-08-20 (comunicado Diretora, 366 destinatários, 0 erros). Em 2026-08-21, primeiro ciclo completo rodado ponta a ponta pra semana seguinte de ambos os produtos: MRZ (2.883 destinatários, agendado 26/08 09h) e Diretora (366 destinatários, agendado 27/08 09h), com aviso interno enviado. Cobre Diretora e MRZ. Academia fica para depois.

Em 2026-08-25, a checagem de duplicidade (passo 2) passou a usar o endpoint GET /api/v1/campaigns/{campaign_slug} em vez de exigir acesso direto ao banco — a execução automática de segunda (24/08) travou tentando conectar em mysql2.reorganize.com.br direto da máquina local, que não é alcançável de fora da VPS.