Pular para conteúdo

Relatório semanal e entrega por WhatsApp

O Cadência consolida a última semana fechada de performance por conta e entrega um resumo curto ao owner pelo telefone informado no onboarding. A agregação DEV-1653 já está em produção; a entrega WhatsApp DEV-1654 permanece em rollout até o pairing e o E2E real do remetente.

O que entra no relatório

  • Score geral ou indicação explícita de histórico insuficiente.
  • Email medido pela coorte exata de envios da semana.
  • Instagram e LinkedIn a partir das análises sociais já persistidas.
  • Blog e TikTok como indisponíveis enquanto não houver integração analítica própria.
  • Período, cobertura, evidências, canais ausentes e ações de ativação.

Ausência de evidência nunca vira zero. O relatório usa uma janela de segunda a domingo em America/Sao_Paulo e não publica conteúdo social.

Mensagem por WhatsApp

A mensagem é determinística e curta:

  1. período da análise;
  2. score geral ou fallback de histórico insuficiente;
  3. até dois insights de Email, Instagram ou LinkedIn;
  4. link direto para /app/performance?week=YYYY-MM-DD.

O destinatário é users.phone do mesmo tenant e usuário do relatório. O remetente é uma instância central da Lara configurada pela plataforma. O rollout inicial pode usar o número comercial do Felipe; o futuro número oficial da Cadência o substitui sem mudança de código.

Garantia contra duplicata

Cada relatório tem no máximo uma entrega por canal. O lifecycle é:

  • pending: aguardando claim;
  • running: execução com token e lease;
  • sent: provider confirmou a mensagem, estado terminal;
  • failed: falha comprovadamente anterior ao provider, retry explícito permitido;
  • unknown: o provider pode ter aceitado a mensagem, estado terminal sem retry automático e sinalizado separadamente no resumo operacional.

O ledger não armazena o telefone completo: somente os quatro últimos dígitos para auditoria.

Segurança e isolamento

  • Owner lê somente relatórios e entregas da própria conta por RLS.
  • Escritas usam RPCs server-side.
  • O destinatário é filtrado simultaneamente por tenant e usuário.
  • O remetente central é configuração, não número hardcoded.
  • Chaves, telefone completo e tokens de execução não aparecem em logs nem documentação.

Situação em 24/08/2026

  • DEV-1653: migration, worker e cron validados em produção.
  • DEV-1654: código e testes locais concluídos; migration, deploy, pairing do remetente e envio real ainda não executados.
  • DEV-1655: poderá reutilizar o mesmo ledger para entrega por e-mail.

Referências