BACKSTAGE — DISCOVERY v3: Especificação Detalhada de Cada Miniapp

Objetivo: Definir com riqueza de detalhes o estado ideal de cada miniapp do Backstage.
Este documento e a ESPECIFICACAO que a IA vai usar para gerar código.
Quanto mais detalhe, melhor o código gerado.

Campos marcados com [ PREENCHER ] devem ser preenchidos pelo time.
Tudo o mais já está pré-preenchido com base no PRD v9 e audit do monorepo.

Referência: Super PRD v9 — backstage-prd.md
Princípio 1: Inteligência Híbrida — concentrar TODA informação no Backstage para a IA operar.
Princípio 2: Internalização Máxima — substituir toda ferramenta externa que puder ser internalizada (HubSpot, Conta Azul, Notion, Slack, Todoist). Manter apenas integrações regulatórias (gateways de pagamento, bancos) com infra 100% agnóstica e plug-and-play.

Versão: 3.1 | Data: 2026-03-15
Status: ESPECIFICACAO EM CONSTRUÇÃO
Owner: Guilherme (VDC)
Time: Alex, JP, Duda, Giovanna, Clariny + AI como 7o membro

---

0. FRAMEWORK E INSTRUÇÕES

0.1 Como usar este documento

1. Para o TIME: Cada miniapp tem campos [ PREENCHER ] — são perguntas que só humanos podem responder (validação com stakeholders, regras de negócio, UX). Preencha com máximo detalhe.
2. Para a IA: As seções "Estado Ideal", "APIs", "Telas", "Comportamentos" são a spec de construção. Use diretamente para gerar código.
3. Para o PO (VDC): Use as "Métricas de Validação" para verificar se cada miniapp está entregue.

0.2 Framework de Maturidade

NIVEL 0: Não existe (nem schema)
NIVEL 1: Schema existe (tabelas definidas, sem API nem UI)
NIVEL 2: Schema + API (endpoints existem, retornam dados)
NIVEL 3: Schema + API + UI (pagina existe, mostra dados)
NIVEL 4: Funcional e2e (fluxo completo testável em produção)
NIVEL 5: Testado e validado (PO testou, dados reais, zero mock)

Alvo Fase 0: Todos os gates em Nível 5. Management OS em Nível 4+.

0.3 Estratégia de Dependências Externas

O Backstage deve ser auto-suficiente. Toda dependência externa é um risco de segurança, estabilidade e fragmentação de dados. A regra:

SUBSTITUIR — Ferramentas que podem ser 100% internalizadas:

Ferramenta	Módulo que substitui	Status	Impacto
HubSpot (CRM)	CRM Package nativo (v2_sales)	Em migração	Elimina API instável + custo de licença + dados fragmentados
Conta Azul (ERP/Contabilidade)	Financeiro nativo (v2_accounting, GL)	A FAZER	Elimina sync frágil + dados atrasados + dependência de API terceira
Notion (Wiki)	Wiki nativa (workspace_documents)	Em migração	Concentra conhecimento no Backstage
Slack + Discord (Chat)	Chat nativo (workspace_channels)	Em migração	Unifica comunicação humano + IA
Todoist/Trello (Tasks)	Tasks & Projetos nativos	A construir	Conecta tasks com gates e combinados
Google Sheets (Business Plan)	Business Plan nativo	Parcial	Elimina export manual e dados offline

MANTER AGNÓSTICO — Integrações regulatórias/de mercado (não podemos produzir o próprio):

Tipo	Exemplos	Princípio
Gateways de pagamento	Iugu, Stripe	Infra 100% agnóstica: trocar gateway = trocar config, zero mudança de código
Bancos	Banco Inter, Itaú, Bradesco, etc.	Sync inteligente bidirecional: toda operação bancária acontece DENTRO do Backstage, autorização PELO Backstage. Interface com banco = background/automático
Assinatura digital	ClickSign	Plug-and-play: trocar provider = trocar adapter
Ads	Google Ads, Meta Ads	Leitura via API, dados consolidados internamente
Telecom	Evolution API (WhatsApp)	Provider swappable

Princípios da infra agnóstica:
1. Adapter pattern: Cada integração regulatória tem um adapter. Trocar provider = trocar adapter, zero impacto no core
2. Dados sempre internos: O Backstage é o source of truth. Integrações externas são inputs/outputs, nunca o master
3. Autorização interna: Operações bancárias, pagamentos, cobranças — tudo autorizado de dentro do Backstage. O banco é apenas o executor
4. Sync inteligente: Reconciliação automática, detecção de divergência, alerta de falha. Nenhum sync silencioso

Bancos — Visão detalhada:
- O usuário nunca precisa abrir o internet banking. Toda operação (consulta de saldo, extrato, pagamento, transferência, cobrança) acontece via Backstage
- O Backstage deve integrar com TODOS os bancos que a Freelaw usa (Inter, Itaú, outros)
- A autorização de pagamentos acontece dentro do Backstage (com níveis de aprovação por valor)
- A reconciliação banco × GL é automática e diária
- Se um banco muda API ou sai do ar, o sistema detecta e alerta — nunca falha silenciosamente

Conta Azul — Plano de substituição (similar ao HubSpot):
1. Mapear TODOS os dados que vêm do Conta Azul (despesas, categorias, fornecedores, notas fiscais)
2. Verificar quais já existem no GL nativo (v2_accounting)
3. Construir o que falta nativamente
4. Período de transição: dual-write (Conta Azul + nativo) → validar → desligar Conta Azul
5. Meta: zero dependência de Conta Azul até fim da Fase 0

0.4 Mapa de Maturidade Consolidado

#	Miniapp	Gate	Nível Atual	Nível Alvo	Gap	Sprint
1	Financeiro (+Conta Azul replacement +Banking)	G1, G5	3-4	5	Grande	1-2
2	CRM (OS)	G3	3-4	5	Grande	3
3	Vendas	G3	3-4	5	Grande	3
4	Customer Success	G2	3-4	5	Médio	3
5	Suporte	G2, G7	3-4	5	Pequeno	3
6	WhatsApp	G7	3-4	5	Pequeno	3
7	Automações	G4	2	4	Grande	4
8	Dashboard Executivo	G5	3	5	Médio	2
9	AI Cockpit	MA-MGMT	0-1	4	Grande	2-3
10	Pulses	MA-MGMT	1	4	Grande	3
11	Weekly Reports	MA-MGMT	0	4	Grande	3
12	Combinados	MA-MGMT	0	4	Grande	3
13	Tasks & Projetos	MA-MGMT	1	4	Grande	3-4
14	Calendar/Meetings	MA-MGMT	1	3	Médio	4
15	Oitiva	—	3-4	4	Pequeno	2
16	Marketing	—	2-3	3	Médio	4
17	Prestadores	—	3-4	4	Pequeno	—
18	Pessoas/RH	MA9	2-3	3	Médio	4
19	Produto	—	3-4	4	Pequeno	—
20	Design System	—	4	4	Pequeno	1
21	Wiki	MA-MGMT	3-4	4	Pequeno	2
22	Chat	MA-MGMT	3	4	Médio	3
23	Social Media	—	2	2	—	Fase 1
24	Reports Builder	G5	2	3	Médio	Fase 1
25	Experiments	—	2	2	—	Fase 1
26	Recruitment	MA9	1	2	Médio	Fase 1
27	Aquisição	G3	2-3	4	Médio	3
28	LIA/IA	MA13	3	4	Médio	3-4

0.5 Dependências entre Miniapps

INFRAESTRUTURA (construir primeiro):
  CRM Package ────→ Vendas, CS, Prestadores, Aquisição, Marketing
  Design System ──→ TODAS as miniapps (componentes UI)
  Auth/RLS ───────→ TODAS (segurança)

FINANCEIRO (core — substituir Conta Azul + infra bancária agnóstica):
  Financeiro ←──── Billing (Iugu, Stripe — via adapter), Bancos (Inter, Itaú — via adapter), ~~Conta Azul~~ (SUBSTITUIR)
  Financeiro ────→ Dashboard, AI Cockpit, Weekly Reports

COMERCIAL (pipeline):
  Aquisição ────→ CRM (leads) ────→ Vendas (deals) ────→ CS (onboarding)
  Vendas ────→ Financeiro (faturamento)
  CRM ←──── HubSpot (migrar dados)

OPERACIONAL:
  CS ←──── Suporte (tickets), WhatsApp (msgs), Financeiro (inadimplência)
  CS ────→ Dashboard, AI Cockpit
  Prestadores ────→ Financeiro (pagamentos)

MANAGEMENT OS:
  AI Cockpit ←──── TODAS (dados de cada area para cockpit)
  Pulses ────→ Weekly Reports (contexto qualitativo)
  Weekly Reports ←──── KPIs (todas areas) + Pulses
  Combinados ←──── Weekly Reports (decisões viram combinados)
  Tasks ←──── Combinados (ação vira task)

COMUNICAÇÃO:
  Chat ←──── Slack + Discord (internalizar)
  Chat ────→ AI Cockpit (Freeclaw opera aqui)
  WhatsApp ────→ CS (histórico), Vendas (cadências)
  Wiki ←──── Notion (migrar conteúdo)

Miniapp	Consome de	Fornece para	Bloqueante?
CRM Package	HubSpot (migrar)	Vendas, CS, Prestadores, Aquisição	SIM — bloqueia G3 inteiro
Financeiro	Iugu (adapter), Stripe (adapter), ~~Conta Azul~~ (SUBSTITUIR), Bancos (adapter agnóstico)	Dashboard, AI Cockpit, Reports	SIM — bloqueia G1
Vendas	CRM Package	Financeiro (receita), CS (onboarding)	SIM — bloqueia G3
CS	CRM, Financeiro, Suporte, WhatsApp	Dashboard, AI Cockpit	SIM — bloqueia G2
Suporte	CS, WhatsApp, Blip	CS (health score)	Parcial
WhatsApp	Evolution API	CS, Vendas, Suporte	Parcial
Automações	CRM (sequences), Resend, Evolution	Vendas, Marketing	SIM — bloqueia G4
Dashboard	Financeiro, CS, Vendas, CRM	Líderanca	SIM — bloqueia G5
AI Cockpit	TODAS as areas	Usuários (home)	Não — pode ser incremental
Pulses	—	Weekly Reports, AI Cockpit	Não
Chat	Slack, Discord	AI Cockpit (Freeclaw)	Parcial

0.6 Ordem de Execução Sugerida

A lógica é: desbloquear de baixo para cima. Cada wave remove dependências externas e desbloqueia a wave seguinte.

Wave 0 (Sprint 1): Fundação — o que TUDO depende
1. Design System — componentes prontos (P pequeno, desbloqueia tudo)
2. Auth/RLS — permissões por cargo/área funcionando (desbloqueia cockpit e dados segregados)

Saída: todas as miniapps podem ser construídas com componentes padronizados e permissões corretas.

Wave 1 (Sprint 1-2): Internalizar ferramentas externas — eliminar dependências
3. CRM Package (G3) — substituir HubSpot. Motor de sequences. Dedup nativo. Zero dependência HubSpot
4. Financeiro (G1) — substituir Conta Azul. GL nativo como source of truth. Infra bancária agnóstica (Inter + todos os bancos). Recebimentos funcional. Business Plan sem Google Sheets
5. Wiki — substituir Notion. Migrar conteúdo prioritário

Saída: HubSpot desligado, Conta Azul desligado, Notion substituído. Backstage é o source of truth de CRM, financeiro e conhecimento.

Wave 2 (Sprint 2-3): Pipeline comercial + Cliente — o core do produto
6. Vendas (G3) — pipeline nativo, outbound sem HubSpot, commission validada
7. CS (G2) — health score validado, playbooks executáveis, retention offers
8. Aquisição (G3) — KPIs com dados reais, lead scoring funcional
9. Dashboard Executivo (G5) — /executive com todas as métricas unificadas
10. Suporte (G2) — inbox e2e, cliente 360 com dados reais
11. Oitiva — validar e integrar com scorecard vendedor

Saída: pipeline completo lead → deal → cliente → acompanhamento → renovação. Dashboard executivo funcional.

Wave 3 (Sprint 3-4): Comunicação + Gestão — operar o dia-a-dia dentro do Backstage
12. WhatsApp (G7) — histórico consolidado por cliente, envio/recebimento e2e
13. Chat — substituir Slack + Discord. Freeclaw operando no chat
14. AI Cockpit — home personalizada por role com dados reais
15. Automações (G4) — workflow execution funcional, eliminar Zapier/Make

Saída: toda comunicação e automação acontece dentro do Backstage. Slack, Discord, Zapier, Make desligados.

Wave 4 (Sprint 4+): Complementos — agregar valor incremental
16. Pulses — captura qualitativa diária/semanal
17. Weekly Reports — CEO AI gera automaticamente
18. Combinados — commitments com cobrança
19. Tasks & Projetos — substituir Todoist/Trello
20. Calendar/Meetings — Google Calendar bidirecional
21. Marketing — ads analytics consolidado
22. Pessoas/RH — funcionalidades mínimas

Saída: Management OS completo. Zero ferramenta externa para gestão do dia-a-dia.

Princípio entre waves: Só avançar para Wave N+1 quando Wave N estiver com gates em Nível 4+. Exceção: quick wins de Wave N+1 que não dependem de Wave N podem ser antecipados (ex: Oitiva, Wiki).

0.7 Framework de Priorização: O que Construir Primeiro?

Para decidir a ordem de construção, usamos 3 critérios. Bloqueio é rei — se uma miniapp bloqueia outras, ela vai primeiro independente do resto.

Critério	Peso	Descrição
Bloqueio	60%	A miniapp bloqueia outras? Bloqueia internalização de ferramenta externa? Se sim, prioridade máxima
Impacto no negócio	25%	Afeta receita, churn, eficiência operacional? Gate crítico? Elimina dependência externa?
Esforço relativo	15%	Quanto falta construir? (Gap P/M/G). Quick wins que desbloqueiam sobem

Regras de priorização:

1. Se bloqueia um gate inteiro → P0 (independente do resto)
2. Se elimina ferramenta externa → sobe 1 nível (internalização = segurança + estabilidade)
3. Se é quick win que desbloqueia P0 → faz primeiro (ex: Design System é P pequeno mas desbloqueia tudo)
4. Se Gap = Grande e não bloqueia ninguém → desce para P3 ou sai da Fase 0

Classificação resultante:

Prioridade	Miniapps	Justificativa
P0 — Bloqueante	CRM Package, Financeiro (+ Conta Azul replacement), Design System	CRM bloqueia G3 inteiro (Vendas, CS, Aquisição). Financeiro bloqueia G1 + Dashboard. Conta Azul precisa ser substituída como o HubSpot. Design System é rápido e desbloqueia tudo
P1 — Core	Vendas, CS, Dashboard Executivo, Aquisição, AI Cockpit	Pipeline comercial end-to-end. Dependem de P0 mas são o produto em si
P2 — Suporte	WhatsApp, Suporte, Chat, Wiki, Oitiva, Automações	Suportam P0/P1. Alguns já estão quase prontos (Oitiva, Wiki). Chat é estratégico (internaliza Slack)
P3 — Complementar	Pulses, Weekly Reports, Combinados, Tasks, Calendar, Marketing, RH, Prestadores, LIA	Agregam valor mas não bloqueiam. Podem ser construídas incrementalmente ou após Fase 0 core

Regra de ouro: Nunca começar uma miniapp P2/P3 se há trabalho pendente em P0/P1 do mesmo gate.

Decisão de "corte": Se uma miniapp tem Gap = Grande e Prioridade = P3, ela SAI da Fase 0 e vai para backlog.

---

1. MINIAPPS CORE (Gates da Fase 0)

---

1. FINANCEIRO /financeiro

Gate: G1 (Gestão financeira centralizada) + G5 (Dashboard) | Nível atual: 3-4 → Nível alvo: 5
Investigador: VDC + Clariny | Owner PRD: VDC
Páginas: 28 | API Routes: 50+ | Schemas: v2_billing (24+ tab), v2_accounting (10+ tab), sync.iugu_* (6 tab)

Estado Atual (audit código + PRD v9)

Funcional:
- GL (General Ledger): 85 contas hierárquicas, 5 posting engines (billing, payroll, manual, expense, transfer), double-entry enforced, reconciliation Iugu vs GL
- Budget Module: orçamento por centro de custo, comparação orçado vs realizado
- Business Plan: import/export Google Sheets, cenários, projeções
- Billing ETL: pipeline completo Iugu → GL
- 25 Vercel crons: billing sync, reconciliation, DRE refresh, unit economics, health check
- Receita: overview, assinaturas, faturamento, billing, novo-MRR
- Custos: despesas (Conta Azul sync — A SUBSTITUIR), prestadores, nova-sede
- Relatórios: DRE, balanço, DFC, KPIs, auditoria, relatório diário
- Análise: churn financeiro, inadimplência, unit economics (CAC/LTV/payback)
- Conciliação: Iugu vs GL com reconciliation engine

Parcial/Stub:
- ERP (Freelaw One) → PLACEHOLDER
- Recebimentos → STUB
- Estruturas organizacionais → STUB
- Close Management → NÃO EXISTE (padrão Campfire: period lock + checklist + flux analysis → reduz close de 15 para 3 dias)
- Dunning Automation → PARCIAL (collections.ts 335 linhas + dunning.ts D+0/3/7/30, mas sem automação de cobrança)
- AR Aging Report → NÃO EXISTE (invoices têm status tracking mas sem visão consolidada por buckets)
- AP Nativo → 15% (approval_requests table existe, falta CRUD + UI + payment execution)

Estado Ideal (Fase 0) — O que "ENTREGUE" significa

User Stories:
- Como CFO, quero ver MRR atual, churn rate e inadimplência numa única tela, para saber a saúde financeira
- Como Finance, quero gerar DRE mensal sem exportar para planilha
- Como Finance, quero editar o Business Plan dentro do Backstage, sem Google Sheets
- Como Finance, quero que a conciliação Iugu vs contabilidade funcione automáticamente
- Como Finance, quero registrar despesas nativamente no Backstage, sem depender do Conta Azul
- Como Finance, quero ver saldo e extrato de TODOS os bancos dentro do Backstage, sem abrir internet banking
- Como Finance, quero autorizar pagamentos e transferências pelo Backstage, com níveis de aprovação por valor

Telas que devem existir e funcionar com dados reais:

Tela	Rota	O que mostra	Dados fonte	Status
Overview Receita	/financeiro/receita	MRR, ARR, novo MRR, churn MRR, expansion	v2_billing.subscriptions	Funcional
Assinaturas	/financeiro/receita/assinaturas	Lista de assinaturas ativas	v2_billing.subscriptions	Funcional
Faturamento	/financeiro/receita/faturamento	Invoices emitidas e pagas	v2_billing.invoices	Funcional
Billing	/financeiro/receita/billing	Detalhes de cobrança	v2_billing.*	Funcional
Novo MRR	/financeiro/receita/novo-mrr	Breakdown novo MRR por fonte	mrrMovimentos	Funcional
Despesas	/financeiro/custos/despesas	Lista de despesas categorizadas	v2_accounting.expenses (nativo)	MIGRAR de Conta Azul
Prestadores	/financeiro/custos/prestadores	Custos com prestadores	providers.payments	Funcional
DRE	/financeiro/relatórios/dre	DRE mensal completa	v2_accounting.transactions	Funcional
Balanço	/financeiro/relatórios/balanço	Balanço patrimonial	v2_accounting.*	Funcional
DFC	/financeiro/relatórios/dfc	Fluxo de caixa	v2_accounting.*	Funcional
Unit Economics	/financeiro/análise/unit-economics	CAC, LTV, payback por cohort	calculado	Funcional
Churn Financeiro	/financeiro/análise/churn	Churn rate, MRR perdido	v2_billing.*	Funcional
Inadimplência	/financeiro/análise/inadimplência	Faturas em atraso	v2_billing.invoices	Funcional
Business Plan	/financeiro/planejamento/business-plan	Cenários, projeções, metas	budgetCenários	Funcional
Conciliação	/financeiro/relatórios/conciliação	GL vs gateway	v2_accounting + sync	Funcional
Recebimentos	/financeiro/receita/recebimentos	Entradas de caixa	v2_billing + sync	STUB
ERP	/financeiro/erp	Freelaw One	—	PLACEHOLDER
Estruturas	/financeiro/configurações/estruturas	Org chart financeiro	fin_estruturas	STUB
Banking Hub	/financeiro/banking	Saldo e extrato de TODOS os bancos	banking_adapter.*	NOVO
Pagamentos	/financeiro/banking/pagamentos	Autorizar pagamentos/transferências	banking_adapter.*	NOVO
Reconciliação Bancária	/financeiro/banking/reconciliação	Banco × GL automático	banking_adapter + v2_accounting	NOVO
Close Management	/financeiro/close	Checklist do close mensal, status, period lock	v2_accounting.close_periods + close_checklist_items	NOVO (Campfire)
AR Aging	/financeiro/receita/aging	Faturas por bucket: current, 30d, 60d, 90d, 120d+	v2_billing.invoices	NOVO (Campfire)
Audit Trail	/financeiro/audit	Log de todas as operações contábeis	v2_accounting.audit_log	NOVO
Dunning Dashboard	/financeiro/cobranca	Pipeline de cobrança automática por aging	collections + dunning	NOVO (Campfire)

APIs que devem funcionar:

Endpoint	Método	O que faz	Status
/api/financeiro/receita/overview	GET	MRR, ARR, métricas agregadas	Funcional
/api/financeiro/receita/mrr	GET	Breakdown MRR por tipo	Funcional
/api/financeiro/custos/despesas	GET	Lista despesas	Funcional
/api/financeiro/relatórios/dre	GET	DRE por período	Funcional
/api/financeiro/relatórios/balanço	GET	Balanço patrimonial	Funcional
/api/financeiro/relatórios/dfc	GET	DFC	Funcional
/api/financeiro/unit-economics	GET	CAC, LTV, payback	Funcional
/api/financeiro/business-plan/*	GET/POST	CRUD business plan	Funcional
/api/financeiro/conciliação	GET	Resultado conciliação	Funcional
/api/financeiro/recebimentos	GET	Entradas de caixa	FALTA
/api/financeiro/despesas	GET/POST	CRUD despesas nativas (sem Conta Azul)	FALTA
/api/financeiro/banking/saldo	GET	Saldo consolidado de todos os bancos	NOVO
/api/financeiro/banking/extrato	GET	Extrato por banco e período	NOVO
/api/financeiro/banking/pagamento	POST	Autorizar pagamento (com approval flow)	NOVO
/api/financeiro/banking/reconciliação	GET	Reconciliação banco × GL	NOVO
/api/financeiro/close	GET/POST	CRUD close periods + checklist	NOVO (Campfire)
/api/financeiro/close/[id]/lock	POST	Lock de período (irreversível sem C-level)	NOVO (Campfire)
/api/financeiro/close/[id]/checklist	GET/PATCH	Itens do checklist + status	NOVO (Campfire)
/api/financeiro/aging	GET	AR Aging por buckets (current/30/60/90/120+)	NOVO (Campfire)
/api/financeiro/dunning	GET/POST	Pipeline de cobrança automática	NOVO (Campfire)
/api/financeiro/flux-analysis	GET	Comparação DRE mês atual vs anterior com variações	NOVO (Campfire)

Comportamentos/Fluxos:
1. Stripe webhook → journal entry no GL → DRE atualizada automáticamente
2. Iugu sync (cron 15min) → journal entry no GL → reconciliação automática
3. ~~Conta Azul sync~~ → SUBSTITUIR: despesas registradas nativamente no GL → DRE reflete custos → Conta Azul desligado
4. Business Plan: editar meta → salvar → comparar com realizado → alerta se desvio > 10%
5. Relatório diário: cron gera automáticamente → disponível na UI
6. Banking agnóstico: adapter conecta com banco (Inter, Itaú, outros) → puxa saldo/extrato → exibe no Backstage → reconcilia com GL automáticamente
7. Pagamento autorizado: usuário solicita pagamento → approval flow (por valor: < R$1k auto, < R$10k líder, > R$10k C-level) → adapter executa no banco → registra no GL
8. Reconciliação bancária: cron diário → compara extrato banco × transactions GL → alerta divergências → zero falha silenciosa
9. Close Management (padrão Campfire): 1º dia útil → Close Prep agent pré-preenche checklist (12 itens) → Finance executa item a item → CEO IA faz flux analysis (DRE atual vs anterior) → period lock → relatórios finais
10. Period Lock: ao trancar período, TODAS as posting APIs rejeitam writes para aquele período. Destrancar requer aprovação C-level + audit log
11. Dunning automático: fatura vencida D+0 → lembrete email → D+3 → WhatsApp → D+7 → ligação → D+30 → escala para jurídico. collections.ts + dunning.ts como base
12. AR Aging: dashboard com buckets (current, 30, 60, 90, 120+ dias), valor total por bucket, tendência, ação sugerida por IA

Infra de gateways e bancos — Adapter Pattern:

BankingAdapter (interface)
  ├── InterAdapter (Banco Inter API)
  ├── ItauAdapter (Itaú API)
  ├── BradescoAdapter (Bradesco API)
  └── ... (qualquer banco novo = novo adapter, zero mudança no core)

PaymentGatewayAdapter (interface)
  ├── IuguAdapter (billing, subscriptions)
  ├── StripeAdapter (payments, webhooks)
  └── ... (trocar gateway = trocar adapter config)

Princípio: o core financeiro NUNCA sabe qual banco/gateway está por trás. Tudo via adapter.

Referência visual: Dashboard financeiro com cards de MRR, churn, runway no topo. Gráficos de tendência. Tabelas detalhadas com filtro por período.

Gap (Atual → Ideal)

1. SUBSTITUIR CONTA AZUL (P0): Despesas hoje vêm de sync.contaazul. Precisa de CRUD nativo de despesas no GL. Migrar dados históricos. Desligar sync. Mesma estratégia do HubSpot
2. INFRA BANCÁRIA AGNÓSTICA (P0): Banking Hub não existe. Precisa de adapter pattern para todos os bancos (Inter + outros). Saldo, extrato, pagamentos, reconciliação — tudo pelo Backstage
3. Recebimentos: tela STUB, precisa de API + UI com dados reais de Iugu/Stripe
4. Business Plan sem Google Sheets: dependência externa. Precisa ser 100% editável na UI
5. Estruturas organizacionais: STUB. CRUD mínimo funcional necessário
6. Gateway agnóstico: Iugu e Stripe funcionam mas são hardcoded. Precisa de adapter para trocar gateway = trocar config
7. GL formalização: GL existe e é maduro, mas precisa ser documentado como hub central
8. Validação em produção: DRE, balanço, DFC — verificar com dados reais que batem
9. Close Management (P1, Campfire): NÃO EXISTE. Schemas close_periods + close_checklist_items precisam ser criados. Period lock no posting layer. Checklist de 12 itens. Flux analysis via CEO IA
10. Dunning Automation (P1, Campfire): PARCIAL. collections.ts (335 linhas) e dunning.ts existem mas sem automação de envio (WhatsApp/email). Conectar com cron-service
11. AR Aging Report (P2): FALTA. Invoices têm status tracking mas sem visão consolidada por buckets (current/30/60/90/120+)
12. Audit Trail UI (P2): v2_accounting.audit_log existe mas sem página de visualização

O que o time precisa documentar [ PREENCHER ]

• [ ] VDC: Conta Azul — TODOS os dados que vêm do Conta Azul hoje (despesas, categorias, fornecedores, NFs). Quais já existem no GL nativo? Quais faltam?
• [ ] VDC: Conta Azul — plano de migração: dual-write → validar → desligar. Timeline?
• [ ] VDC: Bancos — listar TODOS os bancos que a Freelaw usa (Inter, Itaú, Bradesco, outros?)
• [ ] VDC: Bancos — para cada banco: quais operações fazemos? (saldo, extrato, pagamento, transferência, cobrança?)
• [ ] VDC: Bancos — approval flow de pagamentos: quais níveis por valor? Quem aprova?
• [ ] VDC: Google Sheets pode ser eliminado na Fase 0 ou precisa de fallback?
• [ ] VDC: ERP (Freelaw One) entra na Fase 0? Qual o escopo mínimo?
• [ ] Clariny: Recebimentos — quais dados devem aparecer? (Iugu, Stripe, manual?)
• [ ] VDC: Os 25 crons estão todos saudáveis? Listar os que falham silenciosamente
• [ ] VDC: Quais relatórios o CFO usa DIARIAMENTE vs semanalmente?
• [ ] Clariny: Estruturas organizacionais — qual o escopo mínimo de CRUD?

Dependências

• Consome de: Iugu (sync, adapter), Stripe (webhooks, adapter), ~~Conta Azul~~ (A SUBSTITUIR → nativo), Bancos (adapter agnóstico: Inter, Itaú, outros)
• Fornece para: Dashboard Executivo (MRR, receita, despesas), AI Cockpit (alertas financeiros), Weekly Reports (KPIs), CS (inadimplência → health score)
• Integrações externas (regulatórias, via adapter): Iugu, Stripe, Banco Inter, Itaú, outros bancos
• Ferramentas a SUBSTITUIR: Conta Azul (→ GL nativo), Google Sheets (→ Business Plan nativo)

Métricas de Validação

• [ ] Conta Azul sync DESLIGADO (zero chamadas à API do Conta Azul por 7 dias)
• [ ] Despesas registradas e consultadas nativamente no GL (CRUD funcional)
• [ ] Banking Hub: saldo de TODOS os bancos visível no Backstage (zero internet banking)
• [ ] Pagamento autorizado pelo Backstage → executado no banco → registrado no GL
• [ ] Reconciliação bancária automática (banco × GL, cron diário, zero divergência)
• [ ] DRE gerada a partir do GL bate com DRE manual (variação < 1%)
• [ ] MRR calculado = soma de subscriptions ativas (auditável)
• [ ] Conciliação Iugu vs GL com zero divergências em 7 dias consecutivos
• [ ] Business Plan editável sem Google Sheets
• [ ] Unit Economics atualizado com defasagem < 24h
• [ ] Relatório diário gerado automáticamente e visível às 8AM
• [ ] Gateway adapter: trocar Iugu por outro gateway = trocar config (testável)
• [ ] Close Management: checklist com ≥10 itens, período trancável, flux analysis gerado pela CEO IA
• [ ] Period Lock: posting APIs rejeitam writes para períodos trancados (testável)
• [ ] Dunning Automation: cron envia lembretes WhatsApp/email por aging (D+0/3/7/30)
• [ ] AR Aging: dashboard com buckets (current, 30, 60, 90, 120+) e valor total
• [ ] Audit Trail: /financeiro/audit exibe log de operações com filtros

Esforço: G (Grande — 18-22 dias, inclui Conta Azul replacement + infra bancária + close management) | Prioridade: Sprint 1-2 (P0)

---

2. CRM (Operating System) /crm

Gate: G3 (Pipeline e CRM unificados) | Nível atual: 3-4 → Nível alvo: 5
Investigador: Alex | Owner PRD: VDC
Páginas: 12 | API Routes: 35+ | Schemas: v2_sales (20+ tab)

Estado Atual (audit código + PRD v9)

Funcional:
- Entities: contacts, companies, deals, activities — CRUD completo
- Pipeline kanban com estágios configuráveis e drag-and-drop
- Golden Record: entity resolution para dedup
- Analytics: CRM analytics, churn cohort, form analysis
- Testes: suite extensiva de testes

Parcial:
- Sequences: UI existe, schema COMPLETO (sequences, steps, enrollments, executions), mas SEM motor de execução
- HubSpot: sync ainda ativo para contacts, companies, deals. Outbound dedup usa HubSpot API. Escrita usa hubspotWrite()

Estado Ideal (Fase 0) — O que "ENTREGUE" significa

User Stories:
- Como Closer, quero gerênciar meu pipeline de deals no Backstage, sem abrir HubSpot
- Como BDR, quero prospectar leads no outbound sem que o sistema precise do HubSpot para dedup
- Como SDR, quero criar e executar cadências de email nativamente no Backstage
- Como VP Comercial, quero ver métricas de conversão por estágio do pipeline em tempo real

Telas que devem existir:

Tela	Rota	O que mostra	Dados fonte	Status
Dashboard CRM	/crm	Métricas agregadas, pipeline summary	v2_sales.deals	Funcional
Pipeline Kanban	/crm/pipeline	Deals por estágio, drag-and-drop	v2_sales.deals + stages	Funcional
Contacts	/crm/contacts	Lista de contatos com filtros	v2_sales.contacts	Funcional
Companies	/crm/companies	Lista de empresas com filtros	v2_sales.companies	Funcional
Deals	/crm/deals	Lista de deals com filtros	v2_sales.deals	Funcional
Deal Detail	/crm/deals/[id]	Detalhe do deal + timeline	v2_sales.deals + activities	Funcional
Sequences	/crm/sequences	Lista de cadências	v2_sales.sequences	UI sem motor
Sequence Detail	/crm/sequences/[id]	Steps, enrollments, métricas	v2_sales.sequence_*	UI sem motor
Analytics	/crm/analytics	Conversão por estágio, ciclo	v2_sales.*	Funcional

APIs críticas que devem funcionar:

Endpoint	Método	O que faz	Status
/api/crm/contacts	GET/POST	CRUD contatos	Funcional
/api/crm/companies	GET/POST	CRUD empresas	Funcional
/api/crm/deals	GET/POST/PUT	CRUD deals	Funcional
/api/crm/pipelines	GET	Listar pipelines + stages	Funcional
/api/crm/activities	GET/POST	CRUD atividades	Funcional
/api/crm/sequences	GET/POST	CRUD sequences	Funcional
/api/crm/sequences/[id]/enroll	POST	Enrollar contato em sequence	FALTA motor
/api/crm/sequences/process	POST (cron)	Processar enrollments e enviar	FALTA
/api/crm/dedup	POST	Dedup nativo por domain/email/phone	FALTA (usa HubSpot)
/api/crm/golden-record/merge	POST	Merge entidades duplicadas	Funcional

Schemas que devem ter dados reais:
- v2_sales.contacts — com lifecycle tracking (lead → customer → churned)
- v2_sales.companies — com type (prospect, customer, partner)
- v2_sales.deals — com pipeline_id, stage_id, valor, status
- v2_sales.activities — TODOS os touchpoints (calls, emails, meetings, demos)
- v2_sales.sequences — com steps e enrollment logic
- v2_sales.sequence_enrollments — status tracking
- v2_sales.step_executions — email sent/delivered/opened/clicked/replied

Comportamentos/Fluxos críticos:
1. Criar lead → dedup nativo (consulta companies.domain + contacts.email) → criar ou merge
2. Enrollar em sequence → cron processa a cada 5min → envia email via Resend → registra step_execution → atualiza status
3. Deal fechado (won) → trigger automático: criar subscription (billing) + iniciar onboarding (CS)
4. Reply recebida → webhook Resend → atualiza step_execution → exit sequence se configurado
5. Pipeline view → kanban com drag-and-drop → atualiza stage_id → recalcula probability

Gap (Atual → Ideal)

1. Motor de sequences: Schema COMPLETO mas não existe cron que processa enrollments e envia emails. CRÍTICO.
2. Dedup nativo: Ainda usa dedupHubspot() — precisa de dedup por v2_sales.companies.domain + contacts.email + phone
3. HubSpot desligamento: Crons de sync ainda ativos. Precisa desabilitar após migrar dados
4. Migrar dados HubSpot: Contacts, companies, deals históricos — decisão pendente
5. Tracking opens/clicks/replies: Schema existe (step_executions) mas webhook processing não implementado
6. 3 pipelines configuráveis: vendas (MA2), prestadores (MA11), CS (MA4) — hoje só vendas
7. API de package documentada: Como outras areas consomem o CRM

O que o time precisa documentar [ PREENCHER ]

• [ ] Alex: Dados históricos HubSpot — migrar todos ou só últimos 12 meses?
• [ ] Alex: Quais campos do HubSpot NÃO existem no v2_sales? Listar gaps
• [ ] Alex: Provider onboarding: como funciona sem HubSpot? Fluxo step-by-step
• [ ] Alex: Sequences: quais templates de cadência o time de vendas usa hoje?
• [ ] Alex: Golden Record: regras de merge estão corretas? Conflitos?
• [ ] Didico: Quais métricas CRM são consultadas diariamente?

Dependências

• Consome de: HubSpot (dados a migrar), Resend (envio emails), Evolution (WhatsApp), Clicksign (contratos)
• Fornece para: Vendas (pipeline), CS (onboarding), Prestadores (provider pipeline), Aquisição (leads), Financeiro (faturamento pos-deal)
• Integrações externas: HubSpot (a desligar), Resend, Evolution, Clicksign, Golden Record

Métricas de Validação

• [ ] HubSpot sync desligado (cron desabilitado, HUBSPOT_ACCESS_TOKEN removido)
• [ ] Contacts, companies, deals criados nativamente em v2_sales
• [ ] Dedup nativo funciona sem HubSpot (testável com lead duplicado)
• [ ] Sequence: criar → enrollar → email enviado → open trackado (fluxo e2e)
• [ ] 3 pipelines configurados: vendas, prestadores, CS
• [ ] Zero operações no HubSpot por 7 dias consecutivos

Esforço: G (Grande — 10-15 dias) | Prioridade: Sprint 2-3 | GATE MAIS CRÍTICO

---

3. VENDAS /vendas

Gate: G3 | Nível atual: 3-4 → Nível alvo: 5
Investigador: Alex | Owner PRD: Alex
Páginas: 31 | API Routes: ~40 | Schemas: v2_sales.* (reusa CRM)

Estado Atual (audit código + PRD v9)

Funcional: Pipeline kanban, deals CRUD, leads, sales people, commission (BDR 1%, Closer 5%), commission forecast, goals, tactical planning, performance analytics (CRM, churn cohort, form analysis, plan mix), ClickSign contracts.
Parcial: Outbound automation (DEPENDENTE HubSpot), Closer seção, Oitiva não integrada.

Estado Ideal (Fase 0)

User Stories:
- Como Closer, quero ver meu pipeline com forecast de receita
- Como BDR, quero prospectar sem sair do Backstage
- Como VP Comercial, quero ver win rate, ciclo médio, conversão por estágio

Telas críticas:

Tela	Rota	Status
Pipeline	/vendas/pipeline	Funcional
Deals	/vendas/negócios	Funcional
Leads	/vendas/leads	Funcional
Outbound	/vendas/outbound	Dependente HubSpot
Commission	/vendas/commission	Funcional
Goals	/vendas/metas	Funcional
Analytics	/vendas/analytics/*	Funcional
Proposals	/vendas/propostas	Funcional
Oitiva	/oitiva/*	Em dev

Comportamentos/Fluxos críticos:
1. BDR descobre lead (Lead Hunter) → qualifica → passa para SDR/Closer
2. Closer recebe deal → demo → negocia → fecha → ClickSign → subscription criada
3. Deal fechado → trigger: onboarding CS + faturamento Financeiro
4. Commission: deal fechado → calcula BDR 1% + Closer 5% → forecast atualizado
5. Oitiva: ligação gravada → transcrita → avaliada por IA → score no ranking vendedor

Gap

1. Outbound sem HubSpot: dedup + escrita nativos (depende CRM #2)
2. Motor de sequences: depende CRM #2
3. Oitiva integrada: métricas de Oitiva no scorecard do vendedor
4. Commission forecast validado: time de vendas precisa confirmar modelo
5. Deal fechado → trigger: onboarding CS automático não existe

O que o time precisa documentar [ PREENCHER ]

• [ ] Alex: Quais analytics são realmente usados pelo time vs ignorados?
• [ ] Alex: Commission forecast: modelo BDR 1% + Closer 5% está correto?
• [ ] Didico: Outbound: qual o fluxo ideal de prospecção? Canais usados?
• [ ] Alex: ClickSign: contratos fluem corretamente em produção?
• [ ] Alex: Tactical planning: e usado pelo time? Se não, remover?

Dependências

• Consome de: CRM Package (contacts, deals, pipeline), Oitiva (avaliações)
• Fornece para: Financeiro (receita), CS (onboarding post-deal)

Métricas de Validação

• [ ] Pipeline 100% no Backstage (zero HubSpot)
• [ ] Proposta: draft → sent → viewed → accepted (fluxo e2e)
• [ ] Commission forecast validado pelo time de vendas
• [ ] Deal fechado → subscription criada + onboarding CS iniciado
• [ ] Analytics: ciclo vendas, win rate, conversão por estágio com dados reais

Esforço: G (Grande) | Prioridade: Sprint 3

---

4. CUSTOMER SUCCESS /cs

Gate: G2 | Nível atual: 3-4 → Nível alvo: 5
Investigador: Giovanna + Carol | Owner PRD: Giovanna
Páginas: 9 | API Routes: 20+ | Schemas: crm.* (5+ tab)

Estado Atual

Funcional: Dashboard (total clientes, health score médio, at-risk, renovações), Health Scores (5 componentes, daily cron 6AM), Churn Predictions (weekly ML cron), NPS (campaigns, respostas, score), Renovações (pipeline com status), Journey (7 estágios), Clientes 360 (timeline completa), Playbooks (CRUD implementado), Retention Offers (schema completo).

Estado Ideal (Fase 0)

User Stories:
- Como CS Manager, quero ver health score de todos os clientes numa lista ordenável
- Como CS Manager, quero receber alerta quando cliente cai para critical (< 40)
- Como CSM, quero ver todas as interações de um cliente numa timeline unificada
- Como CS Manager, quero ativar playbook de "cliente em risco" que cria tarefas automáticas
- Como CSM, quero ver pipeline de renovações com data, valor e probabilidade
- Como CS Manager, quero calcular retention offers quando cliente quer cancelar

Telas críticas:

Tela	Rota	Status
Dashboard CS	/cs	Funcional
Health Scores	/cs/health	Funcional
Cliente 360	/suporte/cliente/[orgId]	Funcional
NPS	/cs/nps	Funcional
Renovações	/cs/renewals	Funcional
Churn Alerts	/cs/churn-alerts	Funcional
Playbooks	/cs/playbooks	CRUD mas sem execução

Comportamentos/Fluxos críticos:
1. Health score recalculado diariamente (cron 6AM) → 5 componentes ponderados → status (healthy/at_risk/critical)
2. Score < 40 → alerta automático Slack → CSM avisado → playbook ativado
3. Playbook "cliente em risco" → tarefas criadas para CSM → follow-ups automáticos
4. Cliente quer cancelar → calcular retention offer baseada em risco + LTV + tempo de contrato
5. NPS enviado → resposta coletada → detractors priorizados para ação

Gap

1. Playbooks: CRUD existe mas execução real (criar tasks, enviar emails) não funciona
2. Retention offers wired: schema existe mas NÃO conectado a UI de cancelamento
3. Health score validado: pesos dos 5 componentes NÃO foram validados por Carol
4. Timeline unificada: mistura dados reais e mock em produção
5. Dados de uso Studio: depende time Migração (Juju)
6. Alerta Slack → Backstage: migrar alertas de Slack para notificação interna

O que o time precisa documentar [ PREENCHER ]

• [ ] Carol: Health score — os 5 componentes e pesos estão corretos? Validar cada um
• [ ] Carol: Quais playbooks são CRÍTICOS para Fase 0? Descrever step-by-step
• [ ] Carol: Retention offers — quais tipos usar? (desconto %, meses gratis, upgrade?)
• [ ] Giovanna: Timeline: quais informações são ESSENCIAIS vs nice-to-have?
• [ ] Giovanna: NPS: frequência de envio? Quem responde? Ações por resultado?
• [ ] Carol: Quais clientes são prioritários para onboarding vs self-service?

Dependências

• Consome de: CRM (contacts, companies), Financeiro (inadimplência, MRR), Suporte (tickets), WhatsApp (mensagens), Studio (dados de uso)
• Fornece para: Dashboard (health score médio), AI Cockpit (clientes em risco), Financeiro (churn impact)

Métricas de Validação

• [ ] /suporte/cliente/[orgId] carrega para qualquer cliente ativo com dados reais
• [ ] Health score calculado para 100% dos clientes ativos (cron rodando)
• [ ] Alerta automático quando score < 40 (testável)
• [ ] Timeline unificada com dados reais (zero mock)
• [ ] 3 playbooks operando (onboarding, cliente em risco, NPS detractor)
• [ ] Retention offer calculavel via API

Esforço: M (Médio) | Prioridade: Sprint 3

---

5. SUPORTE /suporte

Gate: G2 + G7 | Nível atual: 3-4 → Nível alvo: 5
Investigador: Giovanna + Carol | Owner PRD: Giovanna
Páginas: 13

Estado Atual

Funcional: Dashboard hub, Cliente 360 (4 tabs), Inbox unificado (complexo), Health dashboard, NPS dashboard, Churn Alerts, Renovações pipeline, Onboarding tracker, Conversas LIA, Chatbot config, Knowledge Base, Feedback admin, Performance métricas.

Estado Ideal (Fase 0)

Telas críticas: Todas existem e funcionam. O gap e mais de DADOS do que de UI.

Comportamentos/Fluxos:
1. Ticket aberto (email/whatsapp/chat) → aparece no Inbox → CSM atende → resolve → histórico registrado
2. Cliente 360: abrir → ver 4 tabs (saúde, interações, financeiro, uso) → tudo com dados reais

Gap

1. Inbox: verificar se funciona end-to-end com dados reais em produção
2. Chatbot: verificar se está operando com regras corretas
3. Knowledge Base: verificar se está atualizada
4. Performance: verificar se métricas são usadas

O que o time precisa documentar [ PREENCHER ]

• [ ] Carol: Inbox e o canal principal de atendimento? Funciona bem?
• [ ] Carol: Chatbot está em produção? Com quais regras?
• [ ] Giovanna: Knowledge Base está atualizada? Quem mantém?

Dependências

• Consome de: CS (health score), WhatsApp (mensagens), Chat (conversas)
• Fornece para: CS (tickets → health score)

Métricas de Validação

• [ ] Inbox funciona e2e (ticket recebido → atendido → resolvido)
• [ ] Cliente 360 carrega com dados reais para qualquer cliente
• [ ] Chatbot respondendo em produção

Esforço: P (Pequeno) | Prioridade: Sprint 3

---

6. WHATSAPP /interno/whatsapp

Gate: G7 | Nível atual: 3-4 → Nível alvo: 5
Investigador: JP | Owner PRD: JP
Páginas: 7

Estado Atual

Funcional: Hub, Inbox, Conexões (Evolution API), Cloud API Webhook, Evolution API Sync, Team Conversations, Envio direto via API.

Estado Ideal (Fase 0)

User Stories:
- Como CSM, quero enviar WhatsApp para um cliente direto do Backstage
- Como vendedor, quero que emails/whatsapp de cadências sejam enviados automáticamente
- Como CS Manager, quero ver TODAS as mensagens de um cliente numa timeline

Comportamentos/Fluxos:
1. Mensagem recebida (webhook Evolution) → registrada em v2_comms.messages → aparece no Inbox
2. Envio: selecionar contato → escrever → enviar via Evolution API → registrar em messages
3. Timeline: dado um cliente, listar TODAS as msgs WhatsApp + email + suporte ordenadas

Gap

1. Histórico consolidado por cliente: msgs existem em v2_comms.conversations mas não linkadas ao Customer 360 de forma unificada
2. SMS: stub (sem provedor configurado)
3. Templates avançados: UI de gerênciamento não validada

O que o time precisa documentar [ PREENCHER ]

• [ ] JP: WhatsApp e usado para quais fluxos? (vendas? suporte? onboarding?)
• [ ] JP: Evolution API vs Cloud API: qual o padrão? Manter os dois?
• [ ] JP: Templates: quais são necessários? Quem define conteúdo?
• [ ] JP: Automação de mensagens: entra na Fase 0?

Dependências

• Consome de: Evolution API, CRM (contacts)
• Fornece para: CS (histórico interações), Vendas (cadências), Suporte (inbox)

Métricas de Validação

• [ ] Envio e recebimento funcionando (testável com número real)
• [ ] Histórico consolidado por cliente (timeline unificada)
• [ ] Templates gerênciaveis pela UI
• [ ] Webhook de respostas processando

Esforço: P (Pequeno) | Prioridade: Sprint 3

---

7. AUTOMACOES

Gate: G4 | Nível atual: 2 → Nível alvo: 4
Investigador: JP | Owner PRD: JP

Estado Atual

• Workflow Builder: tipos e executor definidos → EXECUÇÃO E STUB
• Marketing Automations: CRUD + cron 5min + enrollment → PARCIAL
• Ações funcionais: send_email, send_whatsapp, set_property, create_task
• Ações stub: send_sms, create_deal, webhook, internal_notification
• Lead Scoring: schema existe → SEM PROCESSADOR
• Sequences: schema completo → SEM MOTOR (coberto em CRM #2)
• Cron jobs: 25 definidos → maioria funcional

Estado Ideal (Fase 0)

User Stories:
- Como Operações, quero ver todas as automações com status e logs
- Como Marketing, quero que leads que atingem score entrem numa cadência automáticamente
- Como vendedor, quero que tasks sejam criadas quando um deal muda de estágio
- Como Finance, quero que agents contínuos monitorem anomalias 24/7 e alertem automaticamente
- Como líder, quero configurar confidence thresholds para cada tipo de ação automática

Comportamentos/Fluxos:
1. Marketing automation: trigger (lead score > X) → ação (enrollar em sequence) → log
2. Lead scoring: cron calcula score baseado em regras configuráveis → atualiza lead.score
3. Workflow: trigger (deal mudou stage) → ação (criar task para owner) → notificação

Arquitetura de Agents — Continuous + On-Demand (padrão Campfire Ember Agents):

Os AI agents do Backstage seguem dois padrões complementares:

Continuous Agents (cron-service, interval 5-15min, monitoramento 24/7):

Agent	Função	Base existente	Status
Financial Guardian	Detecta anomalias em transactions, alerta desvios >10%	cost-alerts.ts	Expandir
Reconciliation Auto	Auto-match extrato × GL com confidence scoring	reconciliation-matcher.ts	Expandir
Dunning Processor	Escala cobrança por aging (D+0/3/7/30)	collections.ts, dunning.ts	Conectar envio
Health Score Monitor	Recalcula scores, detecta drops bruscos	Cron health scores	Adicionar alertas RT
Churn Signal Detector	Cruza billing + usage + NPS para prever churn	churn-prediction cron	Evoluir modelo

On-Demand Agents (scheduled/event-triggered):

Agent	Função	Trigger	Status
Close Prep	Pré-preenche checklist do close mensal	1º dia útil do mês	A construir
Weekly Report	CEO IA gera report semanal	Domingo 20h	Agendar (ceo-ia-agent.ts)
Commission Calc	Calcula comissões BDR/Closer	Deal won event	Falta trigger
Flux Analyst	Compara DRE mês atual vs anterior	Close de período	A construir
Metric Snapshot	Snapshot diário de KPIs para trending	Diário 23h59	A construir

Confidence Thresholds (padrão Campfire):

Confidence	Comportamento	Exemplo
>95%	Auto-execute + log	Reconciliation match com 98% certainty
70-95%	Sugere + review humano obrigatório	Categorização de despesa com 82%
<70%	Flag + routing para especialista	Transação não reconhecida

Código existente: agent-orchestrator.ts já tem confidence no WorkerOutput.metadata. Falta: (1) confidence_configs table, (2) UI de configuração, (3) dashboard de agent runs.

Nota: 10 billing crons em cron-service/src/routes/billing/ são STUBS — precisam ser migrados para os agents contínuos ou implementados.

Gap

1. Workflow execution e STUB: não executa ações reais
2. Lead scoring processador: não existe cron que calcula scores
3. 4 ações stub: send_sms, create_deal, webhook, internal_notification
4. UI de monitoramento: sem dashboard de automações (logs, falhas, re-runs)
5. Inventário de automações externas: Zapier, Make não mapeados
6. Continuous Agents (Campfire): nenhum agent contínuo configurado com cron 5-15min
7. On-Demand Agents (Campfire): nenhum agent agendado (weekly report, close prep, etc.)
8. Confidence Thresholds (Campfire): config table não existe, UI não existe
9. Agent Dashboard: sem visão de agent runs, success rate, actions taken/flagged
10. 10 billing crons STUB: não migrados de cron-service para agents

O que o time precisa documentar [ PREENCHER ]

• [ ] JP: Quais automações rodam FORA do Backstage hoje? (Zapier, Make, scripts?)
• [ ] JP: Quais são CRITICAS? (sem elas, o que para?)
• [ ] JP: Workflow builder visual: necessário para Fase 0 ou basta config?
• [ ] JP: Lead scoring: quais regras? (quem define o modelo?)

Dependências

• Consome de: CRM (sequences, leads), Resend (email), Evolution (WhatsApp)
• Fornece para: Vendas (cadências), Marketing (lead nurturing)

Métricas de Validação

• [ ] Marketing automations: TODAS as ações funcionais (zero stubs em uso)
• [ ] Lead scoring processador: cron calcula scores para 100% dos leads
• [ ] UI mostra automações ativas, logs de execução, falhas
• [ ] Ferramentas externas de automação mapeadas com plano de migração
• [ ] ≥3 Continuous Agents rodando (Financial Guardian, Reconciliation Auto, Health Score Monitor)
• [ ] ≥2 On-Demand Agents agendados (Weekly Report, Close Prep)
• [ ] Confidence thresholds configuráveis por tipo de ação (UI)
• [ ] Agent Dashboard: runs, success rate, actions taken/flagged
• [ ] 10 billing crons migrados de stub para funcional

Esforço: G (Grande — 15-18 dias, inclui agent architecture) | Prioridade: Sprint 3-4

---

8. DASHBOARD EXECUTIVO /executive, /dashboard

Gate: G5 | Nível atual: 3 → Nível alvo: 5
Investigador: VDC | Owner PRD: VDC

Estado Atual

• Dashboard hub: links para módulos → Funcional
• Métricas financeiras: em /financeiro/* → Funcional
• Métricas vendas: em /vendas/analytics → Funcional
• Métricas CS: em /cs → Funcional
• Dashboard executivo UNIFICADO: NÃO EXISTE

Estado Ideal (Fase 0)

User Stories:
- Como CEO, quero abrir o Backstage e ver MRR, churn, novos clientes, NPS, health score médio — tudo numa tela
- Como Gerente Aquisição, quero filtrar métricas por período, plano e cohort
- Como Diretor Financeiro, quero ver receita vs despesas e unit economics atualizados

Telas:

Tela	Rota	O que mostra
Executive	/executive	MRR, churn rate, novos clientes, receita, despesas, health score médio, pipeline
Dashboard Hub	/dashboard	Links e resumos por módulo

Métricas que devem aparecer no /executive:

Metrica	Fonte	Atualização
MRR	v2_billing.subscriptions	Real-time
Churn Raté	v2_billing.subscriptions	Diário
Novos Clientes	v2_sales.deals (won)	Real-time
Receita Total	v2_accounting.transactions	Diário
Despesas Total	v2_accounting.transactions	Diário
Health Score Médio	crm.customer_health_scores	Diário (cron 6AM)
Pipeline Valor	v2_sales.deals (open)	Real-time
NPS Score	crm.nps_responses	Semanal
CAC	calculado	Mensal
LTV	calculado	Mensal

Filtros: período, plano, cohort (mes aquisição), ICP

Padrões Campfire aplicáveis ao dashboard:
- Flux Analysis: cada métrica mostra variação vs período anterior + explicação da IA (CEO IA tool flux-analysis). Ex: "MRR +12% vs mês anterior — 3 upgrades + 1 novo enterprise"
- Drill-down universal: cada card é clicável → leva ao módulo de origem com filtros preservados. Ex: clicar em "MRR" → /financeiro/receita
- Source Attribution: cada métrica mostra de onde vem (schema + última atualização). Ex: "MRR | v2_billing.subscriptions | atualizado há 3min"
- Alertas contextuais: IA destaca anomalias diretamente no dashboard (desvio >10% vs meta, churn spike, etc.)

Gap

1. Pagina /executive não existe: precisa ser criada do zero
2. Consolidação de métricas: dados existem espalhados, falta view unificada
3. Aquisição KPIs mostrando zeros: falta data binding
4. Flux Analysis (Campfire): explicação de variações por IA não implementada
5. Drill-down: métricas não linkam para módulos de origem
6. Source attribution: sem indicação de fonte de dados ou freshness

O que o time precisa documentar [ PREENCHER ]

• [ ] VDC: Quais métricas Ju/VDC querem ver ao abrir o Backstage? Priorizar
• [ ] VDC: Frequência de atualização: real-time? Diário? Aceitável?
• [ ] VDC: Quem mais usa além de líderanca? (gerentes? ICs?)

Dependências

• Consome de: Financeiro (MRR, receita, despesas), CS (health score, NPS), CRM/Vendas (pipeline, novos clientes)
• Fornece para: Líderanca (decisões), AI Cockpit (north star metric)

Métricas de Validação

• [ ] /executive carrega com dados reais (zero zeros, zero mock)
• [ ] Filtros por período funcionam
• [ ] Dados atualizados (< 24h defasagem)
• [ ] Aprovado por Ju e VDC
• [ ] Flux analysis: cada métrica com variação % + explicação IA
• [ ] Drill-down: clicar em métrica navega para módulo de origem
• [ ] Source attribution: cada card mostra schema + timestamp de última atualização

Esforço: M-G (Médio-Grande com flux analysis) | Prioridade: Sprint 2

---

27. AQUISIÇÃO /aquisição

Gate: G3 | Nível atual: 2-3 → Nível alvo: 4
Investigador: Alex | Owner PRD: Alex
Páginas: 6

Estado Atual

• Lead Hunter: prospecção B2B com Google Places + Exa enrichment → Funcional
• Lista de leads com filtros → Funcional
• KPIs diários → PARCIAL (tela existe mas dados VAZIOS)
• Lead scoring schema → SCHEMA PRONTO, SEM PROCESSADOR
• Meta/Google Ads analytics → Funcional
• UTM tracking e conversion events → SCHEMA PRONTO

Estado Ideal (Fase 0)

User Stories:
- Como BDR, quero ver KPIs diários: leads trabalhados, demos agendadas, conversão
- Como gerente, quero ver qual canal gera mais leads qualificados

Comportamentos/Fluxos:
1. Lead descoberto (qualquer canal) → registrado com acquisition_channel + first_touch_source
2. Lead scoring: cron calcula score baseado em regras → lead priorizado
3. Lead qualificado → passa para pipeline CRM como deal

Gap

1. KPIs diários vazios: falta data binding (telas existem, dados não)
2. Lead scoring processador: não existe
3. Cadências outbound: depende motor sequences (CRM #2)
4. Atribuição de canal: rastrear de qual canal cada lead veio
5. Dedup nativo: depende CRM #2

O que o time precisa documentar [ PREENCHER ]

• [ ] Alex: Lead Hunter: e usado ativamente? Por quem?
• [ ] Alex: KPIs diários: quais métricas o time consulta?
• [ ] Didico: Quais canais de aquisição são prioritários?
• [ ] Alex: Lead scoring: quais regras definem um lead qualificado?

Dependências

• Consome de: CRM (pipeline, dedup), Google Places, Exa.ai, Meta/Google Ads
• Fornece para: CRM (leads), Vendas (deals qualificados)

Métricas de Validação

• [ ] KPIs diários com dados reais (zero zeros)
• [ ] Lead scoring cron ativo calculando scores
• [ ] Atribuição de canal: every lead tem acquisition_channel
• [ ] Dashboard aquisição: leads por canal, conversão por estágio

Esforço: M (Médio) | Prioridade: Sprint 3

---

2. MANAGEMENT OS (MA-MGMT)

Todas as miniapps abaixo são NOVAS ou estão em Nível 0-1. Schema pode existir, mas não ha funcionalidade.

---

9. AI COCKPIT (Home Personalizada)

Gate: MA-MGMT | Nível atual: 0-1 → Nível alvo: 4
Investigador: VDC + Clariny | Owner PRD: VDC

Estado Atual

• Dashboard hub (/dashboard) com links para módulos → Funcional
• Mastra AI agents (CEO IA, Backstage Assistant) → Funcional
• Cockpit personalizado por role → NÃO EXISTE

Estado Ideal (Fase 0)

Tela principal: A HOME do Backstage muda completamente dependendo do cargo/area do usuário (ver principio 1.5 do PRD).

Componentes mínimos na home por role:

1. Top priorities (hoje): 3-7 cards com "por que", "proximo passo", "botoes de ação"
2. Metas e progresso: targets + tendência + gap
3. Alertas: anomalias e riscos (com explicação da IA)
4. Chat com IA: com ferramentas (gerar email, resumo, plano, checklist)
5. Combinados: proximos vencimentos e atrasos

Cockpit por role:

Role	Top Section	Métricas	Ações Rapidas
Vendas	Top 5 contas para atacar	Pipeline, forecast, win rate	Ligar, enviar email, criar proposta
CS	5 clientes priorizados	Health score médio, churn risk, renovações	Enviar msg, criar plano, abrir ticket
Marketing	Experimentos ativos	Budget, CAC por canal, leads semana	Criar campanha, analisar
Financeiro	Alertas de desvio	Caixa D+0, MRR trend, inadimplência	Cobrar, aprovar, analisar
Executivo	Decisões pendentes	North star, top 3 riscos	Aprovar, delegar, agendar

APIs necessárias:

Endpoint	O que faz
/api/cockpit/priorities	Retorna prioridades personalizadas por role
/api/cockpit/metrics	Retorna métricas relevantes por role
/api/cockpit/alerts	Retorna alertas ativos
/api/cockpit/commitments	Retorna combinados pendentes
/api/assistente/chat	Chat com IA contextualizado

Comportamentos:
1. Usuário abre Backstage → sistema identifica role (via hr.hrColaboradores.cargo) → carrega cockpit personalizado
2. Cockpit carrega prioridades do dia baseadas em: KPIs, alertas, combinados, agenda
3. Chat com IA: usuário faz pergunta → IA acessa dados de todas as areas → responde contextualizado
4. CEO IA com ferramentas financeiras expandidas (padrão Campfire Ember): 13 tools em 3 categorias

CEO IA — Financial Tools (benchmark Campfire):

Categoria	Tool	O que faz	Código base existente
Read	fetch-mrr-breakdown	MRR por plano, cohort, período	fetch-financial-data.ts
Read	fetch-ar-aging	Faturas por bucket (current/30/60/90/120+)	v2_billing.invoices
Read	fetch-cashflow-forecast	Projeção de caixa D+30/60/90	dre-builder.ts + unit-economics-calc.ts
Read	fetch-vendor-spend	Gastos por fornecedor e categoria	v2_accounting.vendors + transactions
Read	fetch-budget-variance	Orçado vs realizado com desvios	gl-queries.ts (29KB)
Analysis	flux-analysis	Compara DRE atual vs anterior, explica variações	dre-builder.ts
Analysis	churn-risk-financial	Correlação inadimplência × churn × usage	collections.ts + churn-prediction cron
Analysis	unit-economics-deep	CAC/LTV/payback por cohort com tendência	unit-economics-calc.ts
Analysis	runway-calculator	Meses de runway com cenários (base/otimista/pessimista)	business-plan scenarios
Write	create-journal-entry	Lançamento manual no GL (com review)	finance-posting.ts
Write	approve-payment	Aprovar pagamento pendente	approval_requests table
Write	trigger-dunning	Iniciar cobrança para cliente específico	collections.ts + dunning.ts
Write	lock-period	Trancar período contábil (requer confirmação)	A construir (close_periods)

Confidence thresholds por ferramenta:
- Read tools: auto-execute (sem risco)
- Analysis tools: auto-execute com source attribution obrigatória
- Write tools: >95% confidence = sugere com 1-click approve, 70-95% = review obrigatório, <70% = flagged para humano

Gap

1. Tudo: cockpit personalizado não existe. Precisa ser construido do zero
2. Role detection: lógica de identificar role do usuário e mapear para cockpit
3. Priority engine: lógica que rankeia prioridades por role
4. API de métricas por role: filtrar KPIs relevantes por cargo/area
5. CEO IA financial tools: apenas fetch-financial-data.ts existe (3 tools). Faltam 10 tools (benchmark Campfire)
6. Confidence thresholds UI: configuração de thresholds por ação não existe

O que o time precisa documentar [ PREENCHER ]

• [ ] VDC: Para cada role, listar as 5 métricas mais importantes
• [ ] VDC: Prioridades: como rankear? (urgência x impacto x deadline?)
• [ ] Clariny: Role detection: como mapear cargo → cockpit? (tabela de mapeamento)
• [ ] VDC: Chat IA: quais ferramentas o chat precisa ter? (gerar email, resumo, plano, etc.)

Dependências

• Consome de: TODAS as miniapps (métricas de cada area)
• Fornece para: Usuários (home do Backstage)

Métricas de Validação

• [ ] 4 cockpits funcionais (Vendas, CS, Marketing, Financeiro)
• [ ] Cada cockpit carrega com dados reais (zero placeholder)
• [ ] Chat IA responde perguntas contextualizadas
• [ ] Testável em produção pelo PO para cada role
• [ ] CEO IA com ≥8 financial tools operacionais (read + analysis)
• [ ] Confidence thresholds: write tools requerem confirmação humana
• [ ] Source attribution: cada resposta da IA indica de onde veio o dado

Esforço: G (Grande) | Prioridade: Sprint 2-3

---

10. PULSES

Gate: MA-MGMT | Nível atual: 1 → Nível alvo: 4
Investigador: VDC + Clariny | Owner PRD: VDC
Schemas existentes: workspace_pulse_templates, campaigns, responses, insights, reminders (5 tabelas)

Estado Atual

• Schema completo (5 tabelas) → Nível 1
• Nenhuma API
• Nenhuma UI

Estado Ideal (Fase 0)

User Stories:
- Como IC, quero preencher um pulse diário em 30-60 segundos
- Como líder, quero ver o resumo dos pulses do meu time
- Como CEO AI, quero usar pulses para explicar o "por que" atras dos números

Telas:

Tela	Rota	O que mostra
Pulse Modal	(modal na home)	Template do dia com campos para preencher
Pulse History	/pulses	Histórico de pulses (pessoais e do time)
Pulse Summary	/pulses/summary	Resumo semanal gerado pela IA

APIs:

Endpoint	Método	O que faz
/api/pulses/templates	GET	Templates por area
/api/pulses/respond	POST	Submeter resposta do pulse
/api/pulses/team/[areaId]	GET	Pulses do time
/api/pulses/summary	GET	Resumo IA dos pulses

Tipos de pulse:

Tipo	Cadência	Duração	Template
Daily	Diário	30-60s	"Qual o maior desafio hoje? O que você vai destravar?"
Weekly	Semanal	2-4min	"Top 3 vitórias, top 3 riscos, pedidos de ajuda"
Incident	Ad hoc	Variável	Trigger: IA detecta sinal anômalo

Formatos: texto curto + opção de audio (transcrição automática via Whisper) + tags (cliente, tema, area)

Comportamentos:
1. 9AM: notificação "Pulse diário" → usuário abre modal → preenche → submit
2. Sexta 15h: notificação "Pulse semanal" → template mais longo → submit
3. IA detecta anomalia (churn risk subiu) → Incident Pulse para CSM responsável
4. Final da semana: IA sumariza todos os pulses do time → gera "tema da semana"

Gap

• Tudo após schema: APIs, UI, notificações, templates, audio, transcrição, resumo IA

O que o time precisa documentar [ PREENCHER ]

• [ ] VDC: Templates de daily pulse por area (Vendas, CS, Marketing, Financeiro)
• [ ] VDC: Templates de weekly pulse por area
• [ ] VDC: Audio: necessário para Fase 0 ou MVP só texto?
• [ ] VDC: Cadência: diário para todos ou só para líderes?
• [ ] VDC: Incident pulse: quais anomalias disparam?

Dependências

• Consome de: Auth (user role), KPIs (para incident pulse triggers)
• Fornece para: Weekly Reports (contexto qualitativo), AI Cockpit (temas)

Métricas de Validação

• [ ] Daily pulse funcional: preencher em < 60s
• [ ] Weekly pulse funcional: preencher em < 4min
• [ ] IA sumariza pulses do time
• [ ] Taxa de conclusão > 70%

Esforço: G (Grande) | Prioridade: Sprint 3

---

11. WEEKLY REPORTS

Gate: MA-MGMT | Nível atual: 0 → Nível alvo: 4
Investigador: VDC | Owner PRD: VDC

Estado Atual

• Nenhum schema, nenhuma API, nenhuma UI
• CEO IA agent existe mas não gera reports automáticos

Estado Ideal (Fase 0)

User Stories:
- Como líderanca, quero receber weekly report automático toda segunda
- Como CEO, quero que o report inclua decisões sugeridas com owners

Seções do report:

Seção	Conteúdo
Resumo executivo	O que aconteceu e por que (quant + qual)
Riscos & oportunidades	Priorização (impacto x urgência)
Decisões sugeridas	3-7 decisões "high leverage"
Plano de ação	Tarefas, owners, prazos, evidências
Perguntas pendentes	O que humanos precisam responder

APIs:

Endpoint	Método	O que faz
/api/reports/weekly/generate	POST	Gerar report da semana
/api/reports/weekly/[id]	GET	Ler report
/api/reports/weekly/[id]/approve	POST	Aprovar decisão
/api/reports/weekly/[id]/comment	POST	Comentar

Comportamentos:
1. Domingo 20h: cron dispara CEO AI → coleta KPIs de todas areas + pulses da semana → gera report
2. Segunda 8AM: report disponível para líderanca → notificação
3. Líderanca le → aprova/recusa decisões sugeridas → decisões aprovadas viram Combinados
4. Sistema rastreia: quem leu, o que foi aceito/recusado, o que virou execução

Gap

• Tudo: schema, API, UI, cron, template, lógica de geração

O que o time precisa documentar [ PREENCHER ]

• [ ] VDC: Template de weekly report executivo — quais seções são obrigatórias?
• [ ] VDC: Template de weekly report por area — difere do executivo?
• [ ] VDC: Quem revisa/aprova? Workflow de aprovação?
• [ ] VDC: Dia/hora de geração: quando? (domingo noite? segunda de manha?)

Dependências

• Consome de: KPIs (todas areas), Pulses (contexto), CEO AI agent
• Fornece para: Combinados (decisões → commitments), AI Cockpit (resumo semanal)

Métricas de Validação

• [ ] Report gerado automáticamente toda semana
• [ ] Report referência dados reais (KPI X caiu Y% em período Z)
• [ ] Inclui >= 3 decisões propostas
• [ ] Decisões aprovadas criam Combinados automáticamente

Esforço: G (Grande) | Prioridade: Sprint 3

---

12. COMBINADOS (Commitments)

Gate: MA-MGMT | Nível atual: 0 → Nível alvo: 4
Investigador: VDC | Owner PRD: VDC

Estado Atual

• Nenhum schema, nenhuma API, nenhuma UI

Estado Ideal (Fase 0)

Objeto:

Commitment {
  título, descrição
  owner (user)
  deadline
  escopo (time/cliente)
  KPI relacionado
  evidência esperada (link, screenshot, documento, número)
  status: open | in_progress | at_risk | done | waived
  logs automáticos (o que mudou, por quem, baseado em quais dados)
}

Telas:

Tela	Rota	O que mostra
Lista	/combinados	Combinados ativos, por status
Detalhe	/combinados/[id]	Detalhe + timeline + evidências
Meus	/combinados/meus	Combinados do usuário logado

APIs:

Endpoint	Método	O que faz
/api/commitments	GET/POST	CRUD combinados
/api/commitments/[id]	GET/PUT	Detalhe + atualizar
/api/commitments/[id]/evidence	POST	Anexar evidência
/api/commitments/overdue	GET	Combinados atrasados

Comportamentos:
1. Decisão aprovada no Weekly Report → cria Commitment com owner e deadline
2. Diariamente: IA verifica progresso → se at_risk, notifica owner
3. No deadline: IA cobra evidência → owner anexa → status = done
4. Se atrasado: IA sugere renegociação → registra justificativa

Gap

• Tudo: schema, API, UI, lógica de cobrança

O que o time precisa documentar [ PREENCHER ]

• [ ] VDC: Quais tipos de combinados existem? (meta, tarefa, decisão?)
• [ ] VDC: Workflow de cobrança: como funciona? (notificação? escala?)
• [ ] VDC: Evidência: quais formatos aceitar?

Dependências

• Consome de: Weekly Reports (decisões), Tasks (ações)
• Fornece para: AI Cockpit (combinados pendentes), Weekly Reports (follow-up)

Métricas de Validação

• [ ] CRUD funcional: criar, atribuir, acompanhar, fechar com evidência
• [ ] Combinado criado na segunda → acompanhado diariamente → cobrado na sexta
• [ ] Alertas de atraso funcionando

Esforço: M (Médio) | Prioridade: Sprint 3

---

13. TASKS & PROJETOS

Gate: MA-MGMT | Nível atual: 1 → Nível alvo: 4
Investigador: VDC + Clariny | Owner PRD: VDC

Estado Atual

• Schema parcial
• Nenhuma UI funcional
• Time usa Todoist/Trello externamente

Estado Ideal (Fase 0)

User Stories:
- Como qualquer pessoa, quero ver minhas tasks num board kanban
- Como líder, quero ver progresso do time por sprint/gate
- Como PO, quero vincular tasks a gates e combinados

Telas:

Tela	Rota	O que mostra
Minhas Tasks	/tasks	Board kanban pessoal
Board do Time	/tasks/team/[teamId]	Tasks do time por sprint
Projeto	/projetos/[id]	Board do projeto com milestones

APIs:

Endpoint	Método	O que faz
/api/tasks	GET/POST	CRUD tasks
/api/tasks/[id]	GET/PUT/DELETE	Detalhe task
/api/projects	GET/POST	CRUD projetos
/api/projects/[id]/board	GET	Board do projeto

Task object:

Task {
  título, descrição
  owner, assignees
  status: backlog | todo | in_progress | review | done
  prioridade: low | medium | high | urgent
  deadline
  tags: [gate, MA, sprint]
  vinculado_a: commitment_id | project_id
}

Gap

• Quase tudo: UI funcional, board kanban, sprint management, vinculação com gates

O que o time precisa documentar [ PREENCHER ]

• [ ] VDC: Board kanban: quais colunas? (backlog, todo, in_progress, review, done?)
• [ ] VDC: Sprints: como funcionam? Duração? Quem planeja?
• [ ] Clariny: Migração Todoist: quais tasks migrar?
• [ ] VDC: Vinculação com gates: como? (tag? campo dedicado?)

Dependências

• Consome de: Combinados (ações viram tasks)
• Fornece para: AI Cockpit (tasks do dia), Combinados (evidência de execução)

Métricas de Validação

• [ ] Board kanban funcional por pessoa e por time
• [ ] Tasks vinculáveis a gates e combinados
• [ ] Zero uso de Todoist/Trello pelo time

Esforço: G (Grande) | Prioridade: Sprint 3-4

---

14. CALENDAR/MEETINGS

Gate: MA-MGMT | Nível atual: 1 → Nível alvo: 3
Investigador: VDC | Owner PRD: VDC
Schemas existentes: workspace_meetings, action_items, notes, participants (4 tabelas)

Estado Atual

• Schema completo (4 tabelas) com suporte a Google/Outlook calendar sync
• Nenhuma API, nenhuma UI

Estado Ideal (Fase 0)

Integração bidirecional Google Calendar:
- Leitura: ver agenda de todas as pessoas (com permissão por cargo — ver 1.5)
- Escrita: gestores podem agendar, mover, cancelar reuniões de subordinados
- Cockpit: agenda do dia visível na home

Permissóes:
- IC: ve apenas sua agenda
- Líder de area: ve e gerência agenda do time
- C-level: ve agenda de todos

APIs:

Endpoint	Método	O que faz
/api/calendar/events	GET	Eventos do usuário (ou time se líder)
/api/calendar/events/create	POST	Criar evento (Google Calendar)
/api/calendar/events/[id]/move	PUT	Mover evento
/api/calendar/team/[teamId]	GET	Agenda do time

Gap

• APIs: nenhuma existe
• Google Calendar OAuth: precisa de integração
• Permissóes por hierarquia: lógica não implementada

O que o time precisa documentar [ PREENCHER ]

• [ ] VDC: Quais informações da agenda são relevantes para o cockpit?
• [ ] VDC: Permissóes: líder ve TODAS as reuniões ou só as do time?
• [ ] VDC: Escrita: gestores podem criar reuniões ou só ver?

Dependências

• Consome de: Google Calendar API, HR (hierarquia para permissóes)
• Fornece para: AI Cockpit (agenda do dia), CEO AI (contexto de disponibilidade)

Métricas de Validação

• [ ] Agenda pessoal visível no cockpit
• [ ] Líder ve agenda do time
• [ ] Eventos sincronizados com Google Calendar

Esforço: M (Médio) | Prioridade: Sprint 4

---

3. MINIAPPS DE SUPORTE

---

15. OITIVA /oitiva

Nível atual: 3-4 → Nível alvo: 4
Investigador: JP | Páginas: 8

Estado Atual

Funcional: QA de ligações com scorecards, transcrições, avaliações, rankings. 4 crons ativos (sync-calls 10min, sync-evaluations 15min, process-transcriptions 5min, cleanup semanal). AI Evaluation Agent. Scorecards CRUD com testes.

Gap

• Integração com scorecard do vendedor (MA2)
• Validação: scorecards com critérios atualizados?

O que o time precisa documentar [ PREENCHER ]

• [ ] JP: Oitiva e usado ativamente? Por quem?
• [ ] JP: Scorecards: critérios atualizados?
• [ ] JP: AI Evaluation: qualidade das avaliações e boa?

Métricas de Validação

• [ ] Avaliações automáticas rodando para novas ligações
• [ ] Rankings atualizados e consultáveis

Esforço: P (Pequeno) | Prioridade: Sprint 2

---

16. MARKETING /marketing

Nível atual: 2-3 → Nível alvo: 3
Investigador: Alex | Páginas: 4

Estado Atual

Funcional: Ads analytics (Google + Meta), campanhas. Parcial: Meta Ads integração.

Gap

• Pipeline de conteúdo não existe
• SEO com IA não existe
• Ferramentas externas de marketing não mapeadas

O que o time precisa documentar [ PREENCHER ]

• [ ] Alex: Time de marketing usa o Backstage para que?
• [ ] Alex: Quais ferramentas de marketing são usadas fora do Backstage?
• [ ] Alex: Pipeline de conteúdo: Fase 0 ou depois?

Métricas de Validação

• [ ] Ads analytics com dados atualizados (Google + Meta)
• [ ] Dashboard marketing consultável pelo time

Esforço: P-M | Prioridade: Sprint 4

---

17. PRESTÁDORES /prestadores

Nível atual: 3-4 → Nível alvo: 4
Investigador: Duda | Páginas: 14

Estado Atual

Funcional: Provider 360, KPIs, ranking, saturação, capacity, governance, qualification, work orders, incident tracking, carteirização, Maria AI, knowledge base, funil.

Gap

Pequeno — módulo mais completo do Backstage. Verificar se dados são reais e consistentes.

O que o time precisa documentar [ PREENCHER ]

• [ ] Duda: Quais funcionalidades são usadas no dia a dia?
• [ ] Duda: Ranking: como e calculado? Válido?
• [ ] Duda: Maria AI: insights são úteis?
• [ ] Duda: Consome CRM para dados de provider?

Métricas de Validação

• [ ] Provider 360 carrega com dados reais
• [ ] Rankings atualizados
• [ ] Saturação/capacity reflete realidade

Esforço: P (Pequeno) | Prioridade: Sem gate direto

---

18. PESSOAS/RH /rh

Nível atual: 2-3 → Nível alvo: 3
Investigador: Clariny | Páginas: 3 | Packages: @freelaw/hr-core, @freelaw/hr-sdk

Estado Atual

Funcional: Org Chart (CRUD + API), Payroll (hooks dados reais), People Analytics, Colaboradores, Ausências, hr-core, hr-sdk.

Gap

• Verificar se funcionalidades são usadas
• Performance/PDI: ativo?
• Recrutamento: pipeline ativo?

O que o time precisa documentar [ PREENCHER ]

• [ ] Clariny: Quais funções de RH são usadas hoje?
• [ ] Clariny: Payroll integrado com sistema externo?
• [ ] Clariny: Performance/PDI: ativo ou parado?
• [ ] Clariny: hr-core e hr-sdk estão sendo consumidos por outras areas?

Métricas de Validação

• [ ] Org Chart reflete estrutura real da empresa
• [ ] Colaboradores com dados atualizados

Esforço: P-M | Prioridade: Sprint 4

---

19. PRODUTO /produto

Nível atual: 3-4 → Nível alvo: 4
Investigador: VDC | Páginas: 112

Estado Atual

Funcional: Usuários, Organizações, Permissions, Audit Logs, Content/Academy, AI Agents, Feature Flags, Coupons, Announcements, Performance, Wiki (integrada), Chat (integrado).

O que o time precisa documentar [ PREENCHER ]

• [ ] VDC: Quais sub-módulos são usados ativamente?
• [ ] VDC: AI Agents: métricas de uso? Custos?
• [ ] VDC: Feature flags: quantas ativas? Limpeza necessária?

Esforço: P (Pequeno) | Prioridade: Sem gate direto

---

20. DESIGN SYSTEM /produto/design-system

Nível atual: 4 → Nível alvo: 4
Investigador: Duda | Componentes: 80+ | Doc pages: 70+

Estado Atual

Funcional: 80+ componentes, 70+ páginas doc, tokens, tema dark/light. Parcial: acessibilidade. Não existe: Designer's Bible.

O que o time precisa documentar [ PREENCHER ]

• [ ] Duda: Componentes usados consistentemente?
• [ ] Duda: Componentes faltantes que bloqueiam alguma miniapp?
• [ ] Duda: Designer's Bible: Fase 0 ou Fase 1?
• [ ] Duda: Tokens sincronizados com Figma?

Métricas de Validação

• [ ] Todas as miniapps de Fase 0 usam componentes do Design System
• [ ] Zero componentes ad-hoc criados fora do DS

Esforço: P (Pequeno) | Prioridade: Sprint 1

---

21. WIKI /wiki

Nível atual: 3-4 → Nível alvo: 4
Investigador: Clariny | Páginas: 5
Schemas: workspace_documents (14 tabelas)

Estado Atual

Funcional: Spaces, Documents, Search full-text, Templates, Notion Import.

Gap

• Migração de conteúdo prioritário do Notion
• Validar se busca funciona bem com volume real

O que o time precisa documentar [ PREENCHER ]

• [ ] Clariny: Wiki e usada? Por quem?
• [ ] Clariny: Notion import: migrar todo conteúdo ou selecionar?
• [ ] Clariny: Quais spaces/categorias criar?

Métricas de Validação

• [ ] Conteúdo prioritário migrado do Notion
• [ ] Busca retorna resultados relevantes
• [ ] Time usando Wiki ao invés de Notion

Esforço: P (Pequeno) | Prioridade: Sprint 2

---

22. CHAT /chat

Nível atual: 3 → Nível alvo: 4
Investigador: JP | Páginas: 4
Schemas: workspace_channels, messages, reactions, presence (12 tabelas)

Estado Atual

Funcional: Channels, DMs, Threads, Reactions, File Upload, Typing Indicators, Presence, Slack Import.

Estado Ideal (Fase 0)

Substituir Slack (humanos) + Discord (humanos + Freeclaw) pelo Chat interno. Humanos e IA operam no mesmo ambiente.

Gap

1. Notificações push: verificar se funcionam
2. Freeclaw no chat: integrar Freeclaw/OpenClaw como participante
3. Feature parity com Slack: alertas críticos, menções, canais por area
4. Migração: Slack import já existe, Discord import não

O que o time precisa documentar [ PREENCHER ]

• [ ] JP: Chat interno e usado? Por alguém?
• [ ] JP: Notificações push funcionam?
• [ ] JP: Slack import: migrar histórico completo ou começar do zero?
• [ ] JP: Quais canais criar? (por area? por projeto? por gate?)

Dependências

• Consome de: Slack (migrar), Discord (migrar), Freeclaw/OpenClaw
• Fornece para: AI Cockpit (Freeclaw opera aqui), Todos (comunicação interna)

Métricas de Validação

• [ ] Canais por area funcionando
• [ ] DMs funcionando
• [ ] Notificações funcionando
• [ ] Freeclaw operando no chat (responde mensagens)

Esforço: M (Médio) | Prioridade: Sprint 3

---

28. LIA/IA (MA13)

Nível atual: 3 → Nível alvo: 4
Investigador: VDC

Estado Atual

Funcional: 18+ agents (ver PRD v9 seção 3.4), 60+ tools, Oitiva, Maria AI, CEO IA, Backstage Assistant, churn prediction. Infraestrutura: model router, memory, RAG, HITL, guardrails, cost tracking.

Gap

• Documentação de capabilities, custos, limitações por agent
• AI Credits billing rastreavel por cliente e agent
• Consólidar ou separar infra IA (D16)

O que o time precisa documentar [ PREENCHER ]

• [ ] VDC: Custos de API: quanto gastamos com OpenAI/Anthropic/Google?
• [ ] VDC: Quais agents estão em produção vs experimentais?
• [ ] VDC: Guardrails: quais limites existem?
• [ ] VDC: D16: compartilhar ou separar infra IA?

Métricas de Validação

• [ ] AI Credits rastreaveis por cliente e agent
• [ ] Documentação de todos os agents atualizada
• [ ] Custos monitoreados

Esforço: M (Médio) | Prioridade: Sprint 3-4

---

4. MINIAPPS NOVAS (PRD v9 — Fase 1+)

Estas miniapps tem schema e/ou API mas não são prioridade da Fase 0.
Documentar brevemente para referência futura.

---

23. SOCIAL MEDIA | Nível: 2 | Fase 1+

Schema completo, 5 endpoints, sem UI. Gestão de redes sociais (agendamento, analytics).
O que falta: UI completa, integração com plataformas sociais.

24. REPORTS BUILDER | Nível: 2 | Fase 1+

Schema completo, 4 endpoints, sem UI. Builder de relatórios customizáveis.
O que falta: UI de criação de reports, templates, export.

25. EXPERIMENTS/A-B | Nível: 2 | Fase 1+

Schema completo, API parcial. Framework de experimentação e testes A/B.
O que falta: UI, integração com PostHog feature flags.

26. RECRUITMENT | Nível: 1 | Fase 1+

Schema existe. Pipeline de recrutamento.
O que falta: APIs, UI, integração com processó de contratação.

---

5. MINIAPPS UTILITÁRIAS (fora da Fase 0)

#	Miniapp	Rota	Nível	Notas
—	Cultura	/cultura	2	Verificar se usado
—	Analytics	/analytics	2	Verificar se usado
—	Meu Espaço	/meu-espaco	3	Provavelmente ok
—	Assistente IA	/assistente	3	Funcional
—	Features (flags)	/features	3	Funcional
—	Projetos	/projetos	1	Absorvido por Tasks & Projetos (#13)
—	Planejamento/OKRs	/planejamento	2-3	Absorvido por Management OS

---

6. PÓS-DISCOVERY

Quando todas as miniapps estiverem com [ PREENCHER ] preenchido:

1. VDC consolida todos os gaps e decisões
2. VDC + Ju priorizam o que entra vs backlog
3. Time estima esforço real baseado nos gaps
4. Sprint planning com tarefas concretas
5. IA gera código baseado nas specs deste documento

---

ATRIBUIÇÃO DE INVESTIGAÇÃO

Resumo por pessoa

Investigador	Miniapps	Prazo	Total de [ PREENCHER ]
VDC + Clariny	Financeiro, AI Cockpit, Pulses, Weekly Reports, Combinados, Tasks, Calendar, Dashboard, Produto, LIA	16/mar	~35 itens
Alex	CRM, Vendas, Aquisição, Marketing	16/mar	~18 itens
JP	WhatsApp, Chat, Automações, Oitiva	16/mar	~16 itens
Giovanna + Carol	CS, Suporte	16/mar	~12 itens
Duda	Prestadores, Design System	16/mar	~8 itens
Clariny	Wiki, Pessoas/RH	16/mar	~7 itens

O que cada pessoa deve trazer

Formato de entrega: Preencher os campos [ PREENCHER ] diretamente neste documento (ou no Google Doc compartilhado). Cada resposta deve ser específica e acionável — não vale "funciona bem" sem evidência. A IA vai usar suas respostas para gerar código.

---

Alex — CRM, Vendas, Aquisição, Marketing

Objetivo: Garantir que o pipeline comercial funciona end-to-end no Backstage sem HubSpot.

O que investigar e trazer:

1. CRM — Desligamento HubSpot (MAIS CRÍTICO)
2. Listar TODOS os campos do HubSpot que o time usa → verificar quais existem em v2_sales → listar os que faltam
3. Decidir: migrar dados históricos (todos ou últimos 12 meses)?
4. Testar: criar um lead no Backstage → acompanhar fluxo até virar deal → verificar se funciona sem HubSpot

5. Documentar: quais crons de sync HubSpot ainda rodam? Quais podem ser desligados?

6. CRM — Sequences (BLOQUEANTE para vendas)

7. Listar as cadências de email que o time de vendas usa hoje (templates, frequência, triggers)
8. Definir: quantas cadências precisam funcionar no MVP?

9. Validar: Golden Record — regras de merge estão corretas? Testou com duplicatas reais?

10. Vendas — Analytics e Commission

11. Abrir cada tela de analytics e anotar: funciona com dados reais? Mostra zeros? Quais são consultadas semanalmente?
12. Commission: modelo BDR 1% + Closer 5% está correto? Time de vendas confirma?
13. ClickSign: contratos fluem em produção? Testar um fluxo real

14. Tactical planning: é usado? Se não, recomendar remoção

15. Aquisição — KPIs e Lead Scoring

16. Abrir /aquisicao e listar quais KPIs mostram dados vs quais mostram zero
17. Lead Hunter: é usado ativamente? Por quem? Com que frequência?
18. Lead scoring: propor regras de qualificação (quais critérios definem um MQL?)

19. Consultar Didico: quais canais de aquisição são prioritários?

20. Marketing

21. Listar ferramentas de marketing usadas FORA do Backstage (HubSpot Marketing, Mailchimp, etc.)
22. Ads analytics (Google + Meta): dados estão atualizados? Testar
23. Pipeline de conteúdo: entra na Fase 0 ou é Fase 1?

Entregável: Documento com respostas para os ~18 [ PREENCHER ] das miniapps CRM, Vendas, Aquisição, Marketing. Incluir screenshots de telas que funcionam vs que não funcionam.

---

JP — WhatsApp, Chat, Automações, Oitiva

Objetivo: Garantir que comunicação e automações funcionam end-to-end.

O que investigar e trazer:

1. WhatsApp — Consolidação
2. Mapear: WhatsApp é usado para quais fluxos hoje? (vendas? suporte? onboarding? todos?)
3. Evolution API vs Cloud API: qual é o padrão? Manter os dois ou migrar para um?
4. Templates: listar os que existem, quais são necessários, quem define conteúdo
5. Testar: enviar e receber msg pelo Backstage → verificar se aparece no histórico do cliente

6. Automação de mensagens: entra na Fase 0?

7. Chat — Internalização Slack/Discord

8. Testar: chat interno funciona? Alguém usa? Notificações push funcionam?
9. Decidir: migrar histórico do Slack (import já existe) ou começar do zero?
10. Decidir: migrar Discord? (import NÃO existe — precisa ser construído?)
11. Listar canais necessários: por área? por projeto? por gate?

12. Freeclaw: como integrar como participante no chat?

13. Automações — Inventário Completo

14. CRÍTICO: Listar TODAS as automações que rodam FORA do Backstage (Zapier, Make, scripts, crons manuais)
15. Para cada uma: o que faz, criticidade (sem ela o que para?), pode ser migrada para Backstage?
16. Workflow builder: necessário visual para Fase 0 ou basta configuração por código?
17. Lead scoring: quem define as regras? Propor modelo inicial

18. Testar: marketing automations — quais ações funcionam vs quais são stub?

19. Oitiva — Validação

20. Oitiva é usado ativamente? Por quem? Qual a frequência?
21. Scorecards: critérios estão atualizados? Quem definiu?
22. AI Evaluation Agent: qualidade das avaliações é boa? Comparar com avaliação manual
23. 4 crons (sync-calls, sync-evaluations, process-transcriptions, cleanup): todos rodando?

Entregável: Documento com respostas para os ~16 [ PREENCHER ]. Incluir inventário completo de automações externas (planilha: nome, ferramenta, criticidade, migrável?).

---

Giovanna + Carol — CS, Suporte

Objetivo: Garantir que acompanhamento de clientes funciona com dados reais e playbooks executáveis.

O que investigar e trazer:

1. CS — Health Score (VALIDAÇÃO CRÍTICA)
2. Os 5 componentes do health score estão corretos? Listar cada um com peso atual
3. Para cada componente: o dado fonte é confiável? É atualizado automaticamente?
4. Score < 40 dispara alerta? Onde? (Slack? Email? Backstage?)

5. Carol precisa VALIDAR pessoalmente os pesos e propor ajustes se necessário

6. CS — Playbooks

7. Listar os playbooks CRÍTICOS para Fase 0 (onboarding, cliente em risco, NPS detractor)
8. Para cada playbook: descrever step-by-step (trigger → ação 1 → ação 2 → resultado esperado)

9. Testar: CRUD de playbook funciona? Criar um playbook de teste e verificar

10. CS — Retention Offers

11. Quais tipos de retention offer usar? (desconto %, meses grátis, upgrade, etc.)
12. Como calcular? (baseado em risco + LTV + tempo de contrato?)

13. Quem aprova a offer? Workflow de aprovação?

14. CS — Timeline e NPS

15. Giovanna: abrir /suporte/cliente/[orgId] para 5 clientes reais → anotar o que funciona vs o que mostra mock/vazio
16. Quais informações são ESSENCIAIS na timeline vs nice-to-have?

17. NPS: frequência de envio? Quem responde? Quais ações por resultado (promoter, passive, detractor)?

18. Suporte — Validação de Produção

19. Inbox: é o canal principal de atendimento? Funciona bem em produção?
20. Chatbot: está em produção? Com quais regras? É útil?
21. Knowledge Base: está atualizada? Quem mantém?

22. Performance: métricas de atendimento são consultadas?

23. CS — Clientes e Onboarding

24. Quais clientes são prioritários para onboarding guiado vs self-service?
25. Como funciona o onboarding hoje? (manual? automático? mix?)

Entregável: Documento com respostas para os ~12 [ PREENCHER ]. Health score validado por Carol com pesos aprovados. 3 playbooks descritos step-by-step.

---

Duda — Prestadores, Design System

Objetivo: Garantir que o módulo mais completo do Backstage continua saudável e que o Design System suporta todas as miniapps.

O que investigar e trazer:

1. Prestadores — Uso Real
2. Listar quais funcionalidades são usadas no dia a dia (Provider 360, KPIs, ranking, etc.)
3. Ranking: como é calculado? O algoritmo está válido?
4. Maria AI: insights são úteis para o time? Exemplos de uso
5. Verificar: dados são reais e consistentes? Ou há mock/placeholder?

6. Consome CRM para dados de provider? Qual a dependência?

7. Design System — Cobertura

8. Listar componentes usados consistentemente pelas miniapps de Fase 0
9. Listar componentes FALTANTES que bloqueiam alguma miniapp (se houver)
10. Designer's Bible: necessária na Fase 0 ou Fase 1?
11. Tokens sincronizados com Figma? Se não, o que falta?
12. Verificar: alguma miniapp cria componentes ad-hoc fora do DS?

Entregável: Documento com respostas para os ~8 [ PREENCHER ]. Lista de componentes faltantes (se houver).

---

Clariny — Wiki, Pessoas/RH + suporte em Financeiro, AI Cockpit, Pulses, Tasks

Objetivo: Garantir módulos de suporte e auxiliar VDC nas miniapps de Management OS.

O que investigar e trazer:

1. Wiki — Migração Notion
2. Wiki é usada por alguém hoje? Quem?
3. Notion import: migrar todo conteúdo ou selecionar os mais importantes?
4. Quais spaces/categorias criar? Propor estrutura inicial

5. Testar: busca full-text funciona com conteúdo real?

6. Pessoas/RH — Funcionalidades

7. Quais funções de RH são usadas hoje? (Org Chart? Payroll? Colaboradores?)
8. Payroll integrado com sistema externo? Qual?
9. Performance/PDI: está ativo ou parado?

10. hr-core e hr-sdk: são consumidos por outras áreas? Quais?

11. Suporte ao VDC — Management OS

12. Financeiro: Recebimentos — quais dados devem aparecer? (Iugu, Stripe, manual?)
13. Financeiro: Estruturas organizacionais — qual o escopo mínimo de CRUD?
14. AI Cockpit: Role detection — como mapear cargo → cockpit? Propor tabela de mapeamento
15. Tasks: Migração Todoist — quais tasks migrar? Listar

Entregável: Documento com respostas para os ~7 [ PREENCHER ] próprios + ~4 de suporte ao VDC.

---

VDC (Guilherme) — Financeiro, Dashboard, AI Cockpit, Pulses, Weekly Reports, Combinados, Tasks, Calendar, Produto, LIA

Objetivo: Definir regras de negócio, validar métricas e tomar decisões pendentes do Management OS.

O que trazer (decisões que só o PO pode tomar):

1. Decisões Bloqueantes:
2. Conta Azul replacement: Listar TODOS os dados vindos do Conta Azul. Mapear o que já existe no GL nativo. Planejar migração dual-write → desligar
3. Bancos: Listar TODOS os bancos da Freelaw. Para cada um: operações usadas, viabilidade de API, quem autoriza pagamentos
4. Approval flow de pagamentos: Definir níveis por valor (< R$1k, < R$10k, > R$10k)
5. Google Sheets pode ser eliminado do Business Plan na Fase 0?
6. ERP (Freelaw One): entra na Fase 0? Se sim, qual escopo mínimo?

7. D16: compartilhar ou separar infra IA entre Backstage e Studio?

8. Templates e Regras:

9. Templates de daily pulse por área (Vendas, CS, Marketing, Financeiro)
10. Templates de weekly pulse por área
11. Template de weekly report executivo (seções obrigatórias)
12. Tipos de combinados (meta, tarefa, decisão?)

13. Workflow de cobrança de combinados

14. Métricas e Prioridades por Role:

15. Para cada role (Vendas, CS, Marketing, Financeiro, Executivo): listar as 5 métricas mais importantes
16. Prioridades: como rankear? (urgência × impacto × deadline?)

17. Quais métricas Ju/VDC querem ver ao abrir o Backstage?

18. Validações:

19. Os 25 crons estão todos saudáveis? Listar os que falham
20. Quais relatórios o CFO usa DIARIAMENTE vs semanalmente?
21. Quais sub-módulos de /produto são usados ativamente?
22. AI Agents: métricas de uso e custos?

Entregável: Decisões documentadas para todas as miniapps de Management OS. Templates definidos. Métricas priorizadas por role.

---

CHANGELOG

Data	Versão	Alteração	Autor
2026-03-09	v1	Documento criado com estado atual pré-preenchido	Guilherme + Claude
2026-03-09	v2	Atualizado com PRD v6 audit. Macro-areas. CRM como MA-CRM. Design System, LIA/IA. Template expandido.	Guilherme + Claude
2026-03-11	v2.1	Atualizado para PRD v8. Time atribuído. Ju R Líder Studio.	Guilherme + Claude
2026-03-12	v3	Reestruturação completa: Especificação detalhada para geração de código por IA. Framework maturidade (Nível 0-5) aplicado a todas miniapps. 28 miniapps documentadas (vs 19 anteriores). +Management OS (AI Cockpit, Pulses, Weekly Reports, Combinados, Tasks, Calendar). +Aquisição, LIA/IA, Social Media, Reports Builder, Experiments, Recruitment. Dependências mapeadas. Ordem de execução sugerida (4 waves). Métricas de validação por miniapp. User stories e specs de API/UI detalhadas. Campos [ PREENCHER ] para o time. Alinhado com PRD v9.	VDC + Claude
2026-03-12	v3.1	Correção de acentos. Framework de priorização P0-P3. Atribuição de investigação expandida por pessoa.	VDC + Claude
2026-03-12	v3.2	Princípio de Internalização Máxima: substituir toda ferramenta externa que puder (HubSpot, Conta Azul, Notion, Slack, Todoist). Seção 0.3 nova: Estratégia de Dependências Externas com tabelas SUBSTITUIR vs MANTER AGNÓSTICO. Conta Azul → substituir (mesma estratégia HubSpot). Infra bancária agnóstica: adapter pattern para todos os bancos, toda operação pelo Backstage, zero internet banking. Banking Hub, pagamentos com approval flow, reconciliação automática. Framework de priorização: bloqueio = 60% do peso. Waves reestruturadas por dependência real (Wave 0 fundação → Wave 1 internalizar ferramentas → Wave 2 pipeline comercial → Wave 3 comunicação+gestão → Wave 4 complementos). Financeiro reclassificado como P0/Grande.	VDC + Claude

BACKSTAGE FREELAW — Super PRD v10

O QUE construir e POR QUÊ.
Toda decisão, construção e priorização deve estar ancorada aqui.
Se não está neste documento, não existe.

Para COMO e QUANDO construir, consulte o Plano de Trabalho.
Para o estado ideal de cada miniapp, consulte o Discovery.
Para arquitetura, dados, Design System e CI/CD, consulte o Sistema.

Última atualização: 2026-03-13
Owner: Guilherme (VDC), Diretor Financeiro
Time: Alex, JP, Duda, Giovanna, Clariny + AI como 7º membro
Prazo hard: Fim de Abril 2026
URL produção: backstage.freelaw.ai
Docs online: backstage-docs.vercel.app (atualizado automaticamente a cada hora)
GOLDEN RULE: Nada se constrói sem antes estar documentado aqui. Ver PARTE 1, seção 1.7.

---

NAVEGAÇÃO RÁPIDA

Parte	Conteúdo	Muda quando?
PARTE 1: FUNDAMENTOS	Tese, princípios, personas, governança	Raramente
PARTE 2: ORGANIZAÇÃO	Time, stakeholders, riscos	Por sprint
PARTE 3: OS 7 GATES	Specs de produto — cada gate é um mini-PRD	Por sprint
PARTE 4: REFERÊNCIA TÉCNICA	Inventário, schemas, integrações, IA, débito	Sob demanda
PARTE 5: TRACKING & OPERAÇÃO	Decisões, forma de trabalho, métricas	Toda semana
APÊNDICES	MAs sem gate, visão futura, changelog	Sob demanda

MAPA POR PESSOA

"Onde eu começo?" — vá direto às seções que você é responsável.

Pessoa	Gates que lidera	Seções-chave	Cross-cutting
VDC (Guilherme)	G1, G5	PARTE 1 (princípios), PARTE 2 (time), G1, G5, Apêndice A (MA-MGMT)	Auth, Data Architecture, Management OS
Alex	G3	G3 (CRM + Vendas + Aquisição), G5 (dashboard), Apêndice A (MA10 Marketing, MA13 LIA)	Taxonomia, LIA
JP	G4, G6, G7	G4 (automações), G6 (integrações), G7 (mensageria)	Workflows, n8n
Duda	—	Apêndice A (MA11 Prestadores, MA12 Design System)	Design System
Giovanna	G2	G2 (CS + Health Score + Retenção)	—
Clariny	—	G1 (financeiro, par do VDC), Apêndice A (MA9 RH)	RH

---

PARTE 1: FUNDAMENTOS

Conteúdo durável — muda raramente. Princípios, visão e governança.

1.1 A tese da Freelaw

A Freelaw é uma legaltech B2B SaaS para escritórios de advocacia brasileiros (2-15 advogados). O produto principal — o Studio — concentra 25+ funcionalidades jurídicas numa plataforma única: publicações, prazos, tarefas, documentos, processos, cálculos, consultas, CRM, IA.

A Onda Zero (2026) é uma refundação da empresa. A tese: o mercado jurídico de PMEs no Brasil é enorme, fragmentado, e mal atendido por ferramentas genéricas. A Freelaw quer ser o sistema operacional do escritório de advocacia — e para isso precisa de uma operação interna que funcione tão bem quanto o produto que vende.

1.2 O que é o Backstage

O Backstage é a plataforma interna da Freelaw. Enquanto o Studio Offices atende o contratante e o Studio Providers atende o prestador, o Backstage conecta todas as pontas internas:

STUDIO OFFICES (cliente)     BACKSTAGE (operação)      STUDIO PROVIDERS (prestador)
       ↕                           ↕                           ↕
  Usa o produto    ←→    Vende, monitora,     ←→    Executa serviços
                         cobra, suporta,
                         retém, expande

O Backstage centraliza gestão comercial (vendas, CRM, pipeline), gestão financeira (receita, custos, DRE, billing), gestão de clientes (CS, health score, NPS, churn), mensageria (WhatsApp, email), automações (workflows, cadências) e inteligência (dashboards, IA, analytics).

A visão da Freelaw é ser uma empresa powered by AI — a CEO da Freelaw é uma IA. Humanos representam a IA por enquanto. Cada pessoa que abre o Backstage encontra um AI Cockpit personalizado para o seu papel: o que é mais importante para ela naquele dia, quais decisões tomar, quais compromissos cobrar. O Management OS é o sistema operacional da gestão em si — pulses, weekly reports, combinados, e a IA que orquestra tudo.

1.3 O problema: fragmentação operacional

Hoje a operação da Freelaw depende de:
- HubSpot para CRM e pipeline de vendas
- Google Sheets para business plan e planejamento financeiro
- Conta Azul para contabilidade
- Notion para documentação e knowledge base
- Slack para comunicação interna
- Ferramentas externas para automações (Zapier, Make, scripts avulsos)
- Processos manuais para acompanhamento de clientes
- gestao.freelaw.ai para gestão de RH e produtividade (nota: gestao.freelaw.ai É o Backstage — mesmo deploy Vercel, não é app separado)

Isso gera: dados duplicados, decisões baseadas em informação incompleta, dependência de ferramentas caras, e incapacidade de automatizar fluxos end-to-end.

1.4 Princípios

Inteligência Híbrida

O Backstage existe para concentrar TODA a informação da Freelaw num único lugar. Cada ferramenta externa é um ponto cego para a IA. O objetivo não é "ter um dashboard" — é dar à IA contexto máximo para operar como sistema nervoso da empresa. Quando a IA pode ler toda conversa, toda métrica, toda decisão e todo resultado, ela deixa de ser assistente e vira operadora.

A fragmentação atual — Slack (humanos) + Discord (humanos + Freeclaw) + Notion (documentação) + Todoist (tarefas) + HubSpot (CRM) — é a demonstração viva de que a inteligência híbrida ainda não foi construída. O Backstage resolve isso: humanos e IA passam a operar no mesmo ambiente, com contexto compartilhado.

Acesso segregado por cargo/área

O Backstage personaliza TUDO por role — não apenas o cockpit, mas dados, KPIs, agendas, e ações disponíveis.

Isso inclui:
- KPIs: Cada pessoa vê apenas os KPIs relevantes ao seu cargo/área
- Dados: RLS por organization_id + filtro por área/departamento
- Agenda: Visibilidade e poder de ação sobre agendas alheias depende da hierarquia
- Ações: Botões de ação (aprovar, cancelar, mover) aparecem ou não por permissão
- Cockpit: A home é completamente diferente para um BDR vs CFO vs CS Manager

Schema existente: core.permissions + core.userPermissions + core.permissionDelegations, hr.hrColaboradores (cargo, área, departamento), hr.hrAreas + hr.hrEstruturas (hierarquia organizacional), ColaboradorAreas no area-mapping.ts.

O que falta: Unificar as 3 taxonomias (routes, sidebar, ColaboradorArea) — decisão D21. Implementar filtro de KPIs por cargo. Calendar permissions por hierarquia. Feature flags por role/área.

IA permeia, não é bolted-on

A IA não é um chatbot no canto da tela — ela está embutida em cada workflow.

Inspirado no padrão Campfire.ai (ERP AI-native, $100M funding): a CEO IA e os agents devem ser acessíveis em CADA página, com context da tela atual. Qualquer ação pode ser feita via UI clássica OU via chat natural (point-and-click + chat). Toda resposta da IA cita a fonte dos dados (source attribution obrigatório). Ações de escrita pedem confirmação antes de executar (review before post).

Código existente que suporta: @freelaw/ai com Model Router (Google → Anthropic → OpenAI fallback), guardrails com scoring 70-100 (guardrails.ts), budget manager atômico (budget-manager.ts), cost alerts em 4 thresholds (cost-alerts.ts). CEO IA em ceo-ia-agent.ts (816 linhas, 16 etapas). Falta: tools financeiros avançados e component <AICockpitSidebar /> global.

Real-time, não batch

Métricas atualizadas por eventos, não por cron overnight.

Padrão Campfire: métricas financeiras atualizadas em segundos após cada transação. Implementação: webhooks de Stripe/Iugu → posting engine → GL atualizado → outbox event → dashboard atualizado. O outbox pattern (infra.outbox) já existe. Os 3 posting engines (finance-posting.ts 49.6KB, contaazul-posting.ts, inter-posting.ts) já postam no GL. Gap: conectar o fluxo end-to-end via eventos.

Princípio operacional

"Isso ajuda a fechar o gate da Fase 0?" — Se não, vai para o backlog.

Ciclo de vida completo

Todo cliente deve ser rastreável do ABSOLUTO início ao fim.

O Backstage deve registrar cada touchpoint desde o primeiro contato (clique num ad, preenchimento de formulário, ligação fria) até o offboarding (churn, exclusão de dados). O ciclo completo:

Aquisição → Qualificação → Deal → Onboarding → Ativo → Risco → Renovação/Churn → Offboarding

Cada transição gera dados. Cada dado alimenta decisões. Nenhum touchpoint pode ser perdido.

1.5 Framework de Referência: Ciclo de Vida SaaS

Etapa SaaS	O que cobre	Módulo Backstage	Gate	Investigador
Acquisition	Como atraímos clientes	Marketing, Aquisição, Outbound	G3	Alex
Distribution	Onde distribuímos	Marketing, Integrações	G6	Alex
Conversion	Como vendemos	Vendas, Pipeline, CRM, Propostas	G3	Alex
Revenue	Como cobramos	Financeiro, Billing, MRR, Assinaturas	G1	VDC + Clariny
Analytics	Como medimos	Dashboard Executivo, Analytics	G5	VDC
Retention	Como retemos	CS, Health Score, Playbooks, Suporte	G2	Giovanna
Growth	Como crescemos	— (Fase 1+)	—	—
Infrastructure	Como operamos	Integrações, Automações, Auth	G4, G6	JP
Gestão Interna	Como nos organizamos	Management OS, Wiki, Chat, Tasks	MA-MGMT	VDC + Clariny

Insight: O Backstage já cobre ~80% do ciclo. Gaps: Growth (PLG, referral — Fase 1+) e Gestão Interna (tasks/projetos — precisa substituir Notion/Todoist/Trello).

1.6 Personas e Jobs-to-be-Done

BDR / SDR (Aquisição de Clientes)

Quem: Time de prospecção outbound (BDR) e qualificação inbound (SDR).

O que deveria fazer no Backstage:
- Ver KPIs diários: leads trabalhados, demos agendadas, conversão
- Gerenciar lista de leads com score e priorização
- Executar cadências de email/WhatsApp (sequences) sem sair do sistema
- Ver metas vs realizado em tempo real

Módulos: /aquisicao, /vendas/outbound, /crm/sequences, /vendas/leads

Dores atuais: Outbound depende do HubSpot para dedup e escrita. Sequences sem motor de execução. KPIs diários vazios.

Closer (Vendas)

Quem: Vendedores seniores que fecham deals.

O que deveria fazer no Backstage:
- Ver pipeline de deals por estágio (visualização kanban)
- Gerenciar deals: valor, plano, desconto, contrato assinado, pós-venda
- Acompanhar comissão (BDR 1%, Closer 5%) e forecast
- Ver analytics: ciclo de vendas, win rate, ticket médio

Módulos: /vendas/deals, /vendas/pipeline, /vendas/commission, /crm

Dores atuais: Métricas de Oitiva não integradas. Forecast de comissão precisa validação.

CS Manager (Customer Success)

Quem: Gestores de sucesso do cliente. Responsáveis por retenção e expansão.

O que deveria fazer no Backstage:
- Ver dashboard com todos os clientes: score, trend, risk signals
- Receber alertas automáticos quando cliente fica critical
- Abrir ficha 360 de qualquer cliente (uso, saúde, interações, financeiro)
- Executar playbooks pré-definidos (onboarding, risco, recovery)
- Calcular e oferecer retention offers quando cliente quer cancelar

Módulos: /cs, /suporte/cliente/[orgId], /cs/health, /cs/renewals, /cs/playbooks

Dores atuais: Health score com pesos não validados. Playbooks 0% implementado. Retention offers sem UI. Timeline mistura dados reais e mock.

Finance (Financeiro)

Quem: CFO, time financeiro. Responsáveis por receita, custos, planejamento.

O que deveria fazer no Backstage:
- Ver tudo numa tela: receita, custos, MRR, churn, inadimplência
- Gerar relatórios sem planilhas externas
- Business plan editável na UI (sem Google Sheets)
- Conciliação automática entre gateways e contabilidade

Módulos: /financeiro/* (28 páginas, 30+ API routes)

Dores atuais: Módulo mais avançado em código, ~25% funcional e2e. Google Sheets para Business Plan. ERP placeholder. Recebimentos/estruturas são stubs.

Operações (Automações e Integrações)

Quem: Time técnico/operacional que mantém os sistemas rodando.

O que deveria fazer no Backstage:
- Dashboard de status de todas as integrações
- Monitorar automações: quais rodaram, falharam, logs
- Criar workflows via UI (trigger → condição → ação)
- Gerenciar templates de mensagem (WhatsApp, email)

Módulos: /produto/workflows, /interno/whatsapp, integrações

Dores atuais: Workflow builder STUB. Ações de automação vazias. Lead scoring sem processador. 25 crons sem monitoramento centralizado.

Liderança (Ju, Gab, VDC, Carol, Didico)

Quem: CEO (Ju), CPO e Líder dos Squads (Gab), Diretor Financeiro (VDC/Guilherme), Gerente de CS (Carol), Gerente de Aquisição (Didico).

O que faz hoje:
- Toma decisões estratégicas baseadas em métricas
- Acompanha performance da empresa e dos times
- Gab: aprova visão, escopo e features; ponte entre squads Backstage e Migração

O que deveria fazer no Backstage:
- Abrir UMA tela e ver: MRR, churn rate, novos clientes, receita, despesas, health score médio, pipeline
- Filtrar por período, plano, cohort, ICP
- Drill-down em qualquer métrica
- Gab: ver progresso por gate, blockers cruzados entre squads, status das dependências com Migração

Módulos: /dashboard, /executive

Dores atuais: Dashboard não unifica todas as métricas. Analytics espalhados. Falta visão executiva consolidada.

Produto / Dev

Quem: Time de produto e engenharia.

O que deveria fazer no Backstage:
- Gerenciar design system atualizado
- Consultar audit logs para debugging
- Configurar e monitorar AI agents
- Usar wiki como base de conhecimento

Módulos: /produto/* (112 páginas), /wiki, /chat

Dores atuais: Funcional mas não é prioridade para Fase 0. Não bloqueia nenhum gate.

1.7 Governança

Regra de ouro (GOLDEN RULE — Fase 0)

NADA se constrói sem antes estar documentado no Super PRD.

Se alguém do time (humano ou agente IA) quer construir algo que não está neste documento, a resposta é:
"Documenta no PRD primeiro, aprova com o owner, e aí a gente faz."

Isso vale para: features, refactors, integrações, páginas, API routes, schemas, componentes.

Por que essa regra existe:
- Evita escopo descontrolado (scope creep)
- Garante que toda construção tem justificativa rastreável
- Permite que a IA tenha contexto máximo do que foi decidido e por quê
- Facilita auditoria: se não está no PRD, não deveria existir
- Protege o time de retrabalho

Fluxo obrigatório:
1. Identificar necessidade → 2. Documentar no PRD → 3. Aprovar com owner (VDC) → 4. PLAN → BUILD → SHIP

Validação em produção

Todos os elementos marcados como "FUNCIONAL" neste PRD precisam ser verificados com testes em produção.
Status funcional sem validação em produção é hipótese, não fato.
O PO deve testar cada critério de aceite em produção antes de considerar um gate fechado.

Regras de desenvolvimento (do AGENTS.md)

• Workflow obrigatório: PLAN → CLARIFY → BUILD → VALIDATE → PRESENT → SHIP
• PRs ≤ 500 linhas
• Screenshots obrigatórios para mudanças de UI
• Bun como runtime (nunca npm/yarn/pnpm)
• Sem @ts-nocheck ou as any novo
• Auth (RLS) obrigatório em novas rotas
• Conventional commits
• Zero construção no legado — toda energia no monorepo

---

PARTE 2: ORGANIZAÇÃO

Time, stakeholders e riscos. Muda por sprint.
Para rituais, timeline e forma de trabalho, ver PARTE 5, seção 5.3.

2.1 Time

Dupla Core + 4 Domínios

Dupla Core: VDC + Clariny → Liderança, Finance & Data (Líder de Projeto, Financeiro, GL, Data Architecture, RH)
- VDC (Guilherme): Senior Finance, Good Tech/Dev. Líder do projeto, especifica lógica financeira, arquiteta schemas, code review, decisões críticas
- Clariny: Junior, do financeiro. Par do VDC. Implementa com AI, organização e onboarding

Domínio 1: JP → Workflows & Automações (n8n, Automações internas, Mensageria, Integrações)

Domínio 2: Duda → Operations (Jurídico, Prestadores, Design System)

Domínio 3: Giovanna → CS (Customer Success, Health Score, Retenção)

Domínio 4: Alex → CRM & Revenue (CRM OS, Aquisição, Marketing, Vendas)

Cross-cutting Guardians

Responsabilidade	Guardian
Auth & Permissões	VDC
Taxonomia	Alex
Data Architecture	VDC
Design System	Duda
LIA	Alex
Management OS	VDC
Workflows & n8n	JP
RH	Clariny

AI como 7º membro do time

• Gera testes automaticamente para cada PR
• Valida schemas contra o GL (double-entry balance)
• Checa consistência de Design System tokens
• Flagga PRs que tocam taxonomia sem atualizar o mapa

2.2 Stakeholders

Tier 1 — Decisão:

Stakeholder	Papel	Classificação	Comunicação
Ju R (Ju Resende)	Líder Studio	Sponsor — Decide conflitos entre projetos	Weekly report async
VDC	Diretor Financeiro, Líder Backstage	Driver — Lidera, decide, executa. Dono do PRD.	Daily + contínuo
Gab	Líder Migração	Parceiro crítico — Backstage depende da Migração	Sync semanal

Tier 2 — Execução:

Stakeholder	Papel	Classificação	Comunicação
Alex	CRM & Revenue	Executor — Guardian de Taxonomia e LIA	Daily report
JP	Workflows & Automações	Executor — Responsável n8n e automações	Daily report
Clariny	Finance & Data	Executora — Par do VDC	Daily report
Duda	Operations	Executora — Guardian de Design System e RH	Daily report
Giovanna	CS	Executora — Representante de Customer Success	Daily report

Tier 3 — Consumo & Input:

Stakeholder	Papel	Classificação	Comunicação
Didico	Gerente Aquisição	Consumidor — Precisa do CRM e dashboards	Demo bi-weekly
Carol	Gerente CS	Consumidora — Precisa do módulo CS funcional	Demo bi-weekly
Time Migração	Humberto, Rik	Dependência de dados — Sync semanal quinta 13:30	Via Gab

Matriz Poder x Interesse:
- Alto Poder + Alto Interesse: VDC, Ju, Gab → Gerenciar de perto
- Médio Poder + Alto Interesse: Didico, Carol, Alex → Manter informados
- Alto Interesse: JP, Duda, Giovanna, Clariny → Apoiar e empoderar
- Baixo Poder + Médio Interesse: Time Migração → Monitorar via sync semanal

2.3 Riscos

#	Risco	Prob.	Impacto	Mitigação
R1	VDC como gargalo — PO + Dev + Líder + Guardian de 3 cross-cuttings	Alta	Crítico	Clariny assume tasks financeiras. Dailies detectam sobrecarga cedo.
R2	Ramp-up com projeto novo — Time entrando em projeto grande e complexo	Alta	Alto	Foundation Sprint dedicado. Clariny organiza onboarding. PRD centralizado.
R3	Escopo vs tempo — 14 MAs em 8 semanas com ~8% pronto	Alta	Alto	Priorização brutal: cortar scope, não prazo.
R4	Dependência do projeto Migração — Backstage depende de dados do Studio	Média	Crítico	Sync semanal com Gab. Foundation Sprint cria schemas independente.
R5	AI-first workflow nunca testado — Pode haver resistência ou curva	Média	Alto	Sprint 1 como piloto. Ajustar conforme feedback.
R6	Decisões pendentes bloqueiam progresso — 25 decisões abertas	Média	Alto	Top 6 decisões na semana 1. VDC + Ju decidem.
R7	Golden Record indefinido — Sem modelo unificado de entidades	Média	Crítico	Alex define Golden Record no Foundation Sprint.
R8	Qualidade do código gerado por AI — Lógica de negócio errada	Média	Médio	Seniors revisam TODA lógica de negócio.
R9	Burnout — 8 semanas intensas	Baixa	Alto	Monitorar nos Pulses. Sprint 2→3 tem folga natural.
R10	Integrações frágeis — 17 APIs externas, breaking changes	Baixa	Médio	JP monitora. G6 é gate explícito.

---

PARTE 3: OS 7 GATES

Cada gate é um marco de capacidade que cruza uma ou mais macro-áreas.
Gates são a unidade de entrega da Fase 0. Cada gate absorve as macro-áreas relevantes e inclui as perguntas de discovery pendentes.
Template padronizado: Declaração → User Stories → Estado Atual → Gaps → Critérios de Aceite → Deps Técnicas → Discovery Pendente → Riscos.

3.0 Overview

Gate	Descrição	MAs absorvidas	Funcional e2e	Sprint	Responsável
G1	Gestão financeira centralizada	MA1 (Financeiro)	~25%	Sprint 2	VDC + Clariny
G2	Acompanhar Cliente v1	MA4 (CS)	~5%	Sprint 3	Giovanna
G3	Pipeline e CRM unificados (matar HubSpot)	MA-CRM + MA2 (Vendas) + MA3 (Aquisição)	~8%	Sprint 3	Alex
G4	Automações internas	MA6 (Automações)	~2%	Sprint 4	JP
G5	Dashboard unificado de métricas	MA8 (Dashboard)	~8%	Sprint 2	Alex
G6	Integrações estabilizadas	MA7 (Integrações)	~10%	Sprint 2	JP
G7	Mensageria no monorepo	MA5 (Mensageria)	~5%	Sprint 3	JP

Nota sobre percentuais: Medem completude funcional end-to-end, avaliada em 5 dimensões (Modelo de Dados 20%, Backend 25%, Frontend 20%, Integração 20%, Qualidade 15%). Código existente ≠ funcionalidade pronta. Scoreboard atualizado toda quinta na sync com Migração.

Arquitetura: CRM e Management OS como packages transversais

Decisão arquitetural: O CRM não é um módulo isolado. Ele é uma camada de infraestrutura (package) que roda por dentro de múltiplas áreas. Marketing + Vendas = CRM, mas a mesma estrutura (contacts, companies, deals, activities, pipelines) é reutilizada para outros domínios: pipeline de prestadores, pipeline de CS, pipeline de investidores, etc.

O Management OS segue a mesma lógica transversal: AI Cockpit + CEO AI + Pulses + Weekly Reports + Combinados rodam por dentro de todas as áreas. Cada pessoa abre o Backstage e encontra uma home personalizada pelo seu papel.

Conexões cross-área:
- Financeiro ↔ Prestadores: pagamento a prestadores alimenta custos e DRE
- Financeiro ↔ CS: recebimentos ligados a health score e inadimplência
- Financeiro ↔ Billing: faturamento → receita → MRR → business plan
- Vendas ↔ CS: deal fechado → onboarding → health score → renovação
- Aquisição ↔ Vendas: lead qualificado → deal no pipeline
- Mensageria ↔ Todos: WhatsApp/email como canal transversal
- Management OS ↔ Todos: pulses, reports e combinados permeiam todas as MAs

Alerta: Desalinhamento Domínios vs Macro-Áreas

Auditoria do código (2026-03-09) revelou 3 taxonomias independentes:

1. 29 route domains no filesystem (cresceram organicamente)
2. 11 sidebar sections na UI (curadoria manual)
3. 10 ColaboradorAreas no DB de RH (org chart)

Problemas: 10 rotas órfãs sem sidebar, 3 sidebar sections sem ColaboradorArea, relações many-to-one complexas.

Decisão necessária (D21): Unificar sob as macro-áreas do PRD. Arquivos-chave: app-sidebar.tsx, area-mapping.ts, permissions.ts

Conexões Cross-Área

    ┌───────────────────────────────────────────────────────────────────┐
    │                  Management OS (MA-MGMT)                         │
    │  AI Cockpit · CEO AI · Pulses · Weekly Reports · Combinados      │
    │  (transversal — personalizado por role, permeia todas as áreas)  │
    └──────────┬──────────┬──────────┬──────────┬──────────┬───────────┘
               │          │          │          │          │
    ┌──────────▼──────────▼──────────▼──────────▼──────────▼───────────┐
    │                CRM (Operating System)                            │
    │  contacts · companies · deals · pipelines                        │
    │  activities · sequences · scoring                                │
    └──────┬──────────┬──────────┬──────────┬──────────┬───────────────┘
           │          │          │          │          │
           ▼          ▼          ▼          ▼          ▼
      ┌─────────┐ ┌─────────┐ ┌────────┐ ┌──────────┐ ┌──────────┐
      │ Vendas  │ │Marketing│ │  CS    │ │Prestador.│ │Aquisição │
      │  (MA2)  │ │ (MA10)  │ │ (MA4)  │ │  (MA11)  │ │  (MA3)   │
      └────┬────┘ └─────────┘ └───┬────┘ └─────┬────┘ └──────────┘
           │                      │             │
           ▼                      ▼             ▼
      ┌───────────────────────────────────────────────┐
      │              Financeiro (MA1)                 │
      │  receita · custos · billing · recebimentos    │
      │  pagto prestadores · DRE · business plan      │
      │  General Ledger · plano de contas             │
      └────────────────────┬──────────────────────────┘
                           │
                           ▼
      ┌───────────────────────────────────────────────┐
      │            IA & Produção (MA13)               │
      │  LIA · AI agents · Oitiva · insights          │
      └───────────────────────────────────────────────┘

Conexão	De → Para	Dados que fluem	Status
Venda → Onboarding	Vendas → CS	Deal fechado dispara onboarding CS	A mapear
CS → Renovação	CS → Vendas	Health score alimenta pipeline renovação	A mapear
CS → Financeiro	CS → Financeiro	Inadimplência, churn → impacto MRR	A mapear
Vendas → Financeiro	Vendas → Financeiro	Deal fechado → faturamento → receita → GL	A mapear
Prestadores → Financeiro	Prestadores → Financeiro	Pagamento a prestadores → custos/DRE/GL	A mapear
Aquisição → Vendas	Aquisição → Vendas	Lead qualificado → deal no pipeline CRM	A mapear
Marketing → Aquisição	Marketing → Aquisição	Campanhas → leads	A mapear
Financeiro → Dashboard	Financeiro → Dashboard	MRR, receita, despesas, unit economics	A mapear
CS → Dashboard	CS → Dashboard	Health score médio, NPS, clientes em risco	A mapear
Mensageria → Todos	Mensageria → *	WhatsApp/email como canal transversal	A mapear
Management OS → Todas	MA-MGMT ↔ *	Pulses, reports, combinados	A mapear

---

3.1 G1: Gestão financeira centralizada

Declaração: Toda operação financeira da Freelaw é consultável, analisável e planejável dentro do Backstage, sem dependência de planilhas externas.

Responsável: VDC + Clariny | Sprint: 2 | Completude e2e: ~25%

Macro-áreas: MA1 (Financeiro & Billing)

Escopo: Toda gestão financeira — receita, custos, MRR, DRE, billing, conciliação, unit economics, business plan. Inclui contabilidade nativa (substituindo Conta Azul) e General Ledger.

Módulos: /financeiro/* (28 páginas, 30+ API routes)

User Stories

• Como CFO, quero ver MRR atual, churn rate e inadimplência numa única tela, para saber a saúde financeira da empresa.
• Como Finance, quero gerar DRE mensal sem exportar para planilha, para fechar o mês mais rápido.
• Como Finance, quero editar o Business Plan dentro do Backstage, sem precisar do Google Sheets.
• Como Finance, quero que a conciliação Iugu vs contabilidade funcione automaticamente, para identificar divergências.

Estado atual (evidência do código)

• Receita: overview, assinaturas, faturamento, billing, novo-MRR → FUNCIONAL
• Custos: despesas (sync Conta Azul), prestadores, nova-sede → FUNCIONAL
• Relatórios: DRE, balanço, DFC, KPIs, auditoria, relatório diário → FUNCIONAL
• Análise: churn, inadimplência, unit economics (CAC/LTV/payback), analytics → FUNCIONAL
• Planejamento: business plan com import/export Google Sheets, estratégico → FUNCIONAL
• Configurações: categorias (vendor_category_mapping), centros de custo (fin_centros_custo), estruturas (fin_estruturas) → FUNCIONAL
• Conciliação: Iugu vs GL → FUNCIONAL
• Schemas: v2_billing com 24+ tabelas (customers, plans, subscriptions, invoices, invoice_items, ai_credits, subscription_events, retention_offer_configs, promotional_coupons, cancellation_tracking)
• Sync: sync.iugu_customers, sync.iugu_subscriptions, sync.iugu_invoices, sync.iugu_financial_transactions, sync.iugu_receivables

Gaps

• ERP (Freelaw One) → PLACEHOLDER ("em construção") — D9 pendente
• Recebimentos → STUB
• Estruturas organizacionais → STUB ("em breve")
• Google Sheets como dependência externa para Business Plan
• General Ledger: precisa ser formalizado como hub central de todas as transações
• Close Management → NÃO EXISTE: sem close_periods, sem period_lock, sem close_checklist_items. Referência: Campfire.ai reduz close de 15→3 dias com checklist + flux analysis + period lock. Schemas propostos no benchmark (campfire-benchmark-freelaw-one.md seção 3.3).
• Dunning Automation → PARCIAL: collections.ts (335 linhas) tem tracking com stages (30_60d, 60_90d, 90_plus) e dunning pipeline em studio-offices/src/lib/billing/dunning.ts (D+0/3/7/30). Falta: automação de envio de reminders (WhatsApp/email) e escalation rules engine.
• AR Aging Report → PARCIAL: v2_billing.invoices tem status tracking, mas sem view consolidada com buckets (current, 30, 60, 90, 120+ dias)
• AP Nativo → 15%: approval_requests table existe (status: pending/approved/rejected/escalated, amount, requester, approver). Falta: CRUD UI, regras automáticas por valor/CC (D-BANK-2: R$10k C-level)

Critérios de aceite

• [ ] Toda operação financeira consultável no Backstage (nenhum dado só em planilha)
• [ ] Business Plan editável 100% na UI (import/export CSV como fallback)
• [ ] Sync Iugu + Conta Azul estável (7 dias sem falha)
• [ ] DRE, KPIs, Unit Economics com dados reais e atualizados
• [ ] Zero dependência de Google Sheets para dados financeiros
• [ ] General Ledger recebendo transações de todos os gateways
• [ ] Todas as transações Iugu e Stripe → journal entries automáticos
• [ ] Despesas Conta Azul → journal entries (sync mantido, GL como fonte de verdade)
• [ ] DRE gerada a partir do GL (não de queries avulsas)
• [ ] Recebimentos: tela funcional com dados reais do Iugu/Stripe
• [ ] Estruturas organizacionais: CRUD mínimo funcional
• [ ] Conciliação automática: GL ↔ gateway com alerta de divergências
• [ ] Unit Economics com dados atualizados (< 24h defasagem)
• [ ] Relatório diário automático funcionando
• [ ] ERP (Freelaw One): decisão tomada e documentada (D9)
• [ ] Banco Inter: decisão sobre ativação (D12)
• [ ] Close Management: checklist mensal com ≥10 items (reconciliações, classificações, provisões, DRE draft, flux analysis, aprovação, lock). Schema: v2_accounting.close_periods + close_checklist_items
• [ ] Period Lock: períodos fechados impedem alterações em v2_accounting.transactions (write check em todas as APIs de posting)
• [ ] Dunning Automation: cron que processa stages de collections_tracking + envia reminders automáticos (WhatsApp via Evolution + email via Resend). Evolução do dunning.ts existente (D+0/3/7/30)
• [ ] AR Aging Report: view consolidada com buckets (current, 1-30, 31-60, 61-90, 90+ dias) a partir de v2_billing.invoices
• [ ] AP Nativo: CRUD de contas a pagar + approval workflow (usando approval_requests existente) + agendamento de pagamento via Inter/Itaú API
• [ ] Vendor Management UI: CRUD sobre v2_accounting.vendors (nome, CPF/CNPJ, bank info, payment terms, categoria)
• [ ] Audit Trail UI: página /financeiro/audit com filtros por período, conta, tipo, user — sobre v2_accounting.audit_log existente

Dependências técnicas

• Tabelas: v2_billing., sync.iugu_, budgetCenarios, budgetDespesas, budgetMetas, mrrMovimentos, unitEconomicsSnapshots, vendor_category_mapping, fin_estruturas, fin_centros_custo
• APIs: /api/financeiro/* (30+ routes)
• Externas: Iugu (sync), Stripe (webhooks), Conta Azul (sync)

Discovery pendente

VDC:
- [x] D-FIN-1: Google Sheets eliminado dos workflows core. Usado apenas para análises pontuais pós-exportação.
- [x] D-FIN-2: ERP entra na Fase 0. Escopo: AP nativo (contas a pagar + approval + PIX Inter), AR consolidado, conciliação bancária UI, vendor management, NFS-e, lançamentos manuais. Objetivo: desligar Conta Azul.
- [x] D-FIN-3: AUDITADO — 25 crons ativos, 73% saudáveis. Issues: (1) ads-insights-report fora do vercel.json; (2) lead-scoring/hubspot-sync sem advisory lock; (3) Meta token precisa System User Token; (4) sem health check agregado.
- [x] D-FIN-4: DIÁRIO: posição de caixa, recebimentos/pagamentos, compromissos vencidos/a vencer, 13-week cash projection. SEMANAL: DRE gerencial, MRR waterfall, unit economics.
- [x] D-FIN-5: Banco Inter E Itaú — ambos ativos na Fase 0. Dados: saldo, extrato, PIX in/out, TED, boletos.

Clariny:
- [ ] D-FIN-C1: Recebimentos — quais dados devem aparecer? (Iugu, Stripe, manual?)
- [ ] D-FIN-C2: Estruturas organizacionais — qual o escopo mínimo de CRUD?

Riscos

• Google Sheets elimination pode afetar workflow do CFO — validar antes de remover

---

3.2 G2: Acompanhar Cliente v1

Declaração: O time de CS consegue acompanhar a saúde de qualquer cliente ativo numa única tela, receber alertas quando algo piora, e agir com playbooks pré-definidos.

Responsável: Giovanna | Sprint: 3 | Completude e2e: ~5%

Macro-áreas: MA4 (Customer Success) + parte de MA-MGMT (CS cockpit)

Escopo: Gestão completa do ciclo de vida do cliente pós-venda. Foco em confiabilidade operacional — toda ação de CS deve gerar dados confiáveis e auditáveis.

Módulos: /cs/* (9 páginas), /suporte/cliente/[orgId] (15 páginas)

Áreas operacionais: (1) Onboarding (2) Atendimento/Suporte (3) Monitoramento proativo (4) Renovações e expansão (5) Gestão de churn

Conexões profundas:
- Aquisição/Vendas → CS: onboarding começa IMEDIATAMENTE após deal close
- CS → Financeiro: health score impacta decisões de billing. Inadimplência alimenta risk signals.
- CS → Suporte (Mensageria): tickets alimentam support score do health score
- CS → Produto: dados de uso do Studio alimentam product usage score

User Stories

• Como CS Manager, quero ver o health score de todos os clientes numa lista ordenável, para priorizar quem precisa de atenção.
• Como CS Manager, quero receber alerta no Slack quando um cliente cai para "critical" (score < 40), para agir imediatamente.
• Como CSM, quero ver todas as interações (WhatsApp, email, suporte, NPS) de um cliente numa timeline unificada.
• Como CS Manager, quero ativar um playbook de "cliente em risco" que cria tarefas automáticas para o CSM.
• Como CSM, quero ver o pipeline de renovações com data, valor e probabilidade, para planejar meu mês.
• Como CS Manager, quero calcular retention offers automaticamente quando um cliente quer cancelar.

Estado atual (evidência do código)

• Health Score: tabela crm.customer_health_scores com 5 componentes:
• productUsageScore (0-100) — inputs: DAU, WAU, MAU, featureAdoption, lastLoginAt
• engagementScore (0-100) — inputs: emailOpenRate, meetingsAttended, trainingCompleted
• supportScore (0-100) — inputs: ticketsLast30Days, avgResolutionTime, csatScore
• financialScore (0-100) — inputs: mrr, paymentStatus, invoicesOverdue
• advocacyScore (0-100) — inputs: npsScore, referralsGiven, caseStudyParticipant
• Status: healthy (≥70), at_risk (40-69), critical (<40)
• Trend: improving | stable | declining
• Risk signals: array de {type, severity, description, detectedAt}
• Opportunities: array de {type (upsell/cross_sell/expansion), product, estimatedValue, confidence}
• Customer 360 API: agrega 9 fontes — CRM, billing, health, support, WhatsApp, AI, onboarding, churn predictions, NPS
• NPS: surveys + respostas + score (promoter 9-10, passive 7-8, detractor 0-6)
• Renovações: pipeline (upcoming, in_negotiation, renewed, churned, downgraded, upgraded)
• Journey: 7 estágios (onboarding → adoption → value_realization → expansion → advocacy → at_risk → churned)
• Churn Predictions: predições com risk score, fatores, ações recomendadas → FUNCIONAL
• Playbooks: → VAZIO (0% implementado)
• Retention Offers: schema existe (discount_percentage, discount_fixed, upgrade_discount, free_months, custom) mas NÃO conectado à UI

Gaps

• Playbooks CS: 0% implementado — precisa de 3 mínimos (onboarding, cliente em risco, NPS detractor)
• Wiring de retention offers à UI (engine existe, falta conectar)
• Validar pesos do health score com time de CS (D3)
• Timeline de interações com dados 100% reais (hoje mistura real + mock)
• Dados de uso do Studio: depende time Migração (risco externo)
• Onboarding automático: trigger de deal close → tarefas de onboarding criadas
• Support score wiring: tickets resolvidos → atualização automática do health score

Critérios de aceite

• [ ] /suporte/cliente/[orgId] carrega para qualquer cliente ativo com dados reais
• [ ] Health score calculado para 100% dos clientes ativos (cron diário)
• [ ] Pesos do health score validados com time de CS (D3 resolvido)
• [ ] Alerta automático no Slack/Chat quando score < 40
• [ ] Timeline de interações unificada (WhatsApp + email + suporte + NPS) com dados reais
• [ ] 3 playbooks CS operando: onboarding (4-6 tarefas auto), cliente em risco (alerta + ações), NPS detractor (follow-up)
• [ ] Retention offers conectadas à UI: CS Manager calcula offer em 2 cliques
• [ ] Customer 360 carrega em < 3 segundos
• [ ] Onboarding automático: deal fechado → playbook dispara
• [ ] Renovações: pipeline com alertas 60/30/15 dias antes do vencimento
• [ ] Integração suporte → health score: tickets atualizam support score
• [ ] NPS: survey automático a cada 90 dias para clientes ativos
• [ ] Dados de uso do Studio integrados (se time Migração entregar)

Dependências técnicas

• Tabelas: crm.customer_health_scores, crm.nps_responses, crm.renewal_tracking, crm.customer_journey
• APIs: /api/customer-360/[id], /api/customer-success/health, /api/customer-success/retention-offers
• Externas: dados de uso do Studio (depende time Migração), Slack (alertas)

Discovery pendente

Carol:
- [ ] D-CS-1: Health score — os 5 componentes e pesos estão corretos? Validar cada um
- [ ] D-CS-2: Quais playbooks são CRÍTICOS para Fase 0? Descrever step-by-step
- [ ] D-CS-3: Retention offers — quais tipos usar? (desconto %, meses grátis, upgrade?)
- [ ] D-CS-4: Quais clientes são prioritários para onboarding vs self-service?

Suporte (Carol):
- [ ] D-SUP-1: Inbox é o canal principal de atendimento? Funciona bem?
- [ ] D-SUP-2: Chatbot está em produção? Com quais regras?
- [ ] D-SUP-3: Knowledge Base está atualizada? Quem mantém?

Giovanna:
- [ ] D-CS-G1: Timeline CS: quais informações são ESSENCIAIS vs nice-to-have?
- [ ] D-CS-G2: NPS: frequência de envio? Quem responde? Ações por resultado?
- [ ] D-GIO-ONBOARD-1: Onboarding playbook — quais tarefas/milestones? O que automatizar vs manual?
- [ ] D-GIO-CHURN-1: Churn prediction — quando health score cai, quais ações o sistema dispara? (alerta, playbook, escalação, oferta?)
- [ ] D-GIO-ALERTS-1: CS alerts — de onde vêm hoje? Estado de migração para Backstage?

Riscos

• Dados de uso do Studio podem não estar disponíveis a tempo (dep. Migração)
• Pesos do health score precisam ser validados com o CS antes de produzir
• Sem playbooks, o CS não tem ação padronizada para clientes em risco

---

3.3 G3: Pipeline e CRM unificados (matar HubSpot)

Declaração: Todo o funil de vendas — da prospecção ao fechamento — opera dentro do Backstage, com CRM nativo e zero dependência do HubSpot como fonte de verdade.

Responsável: Alex | Sprint: 3 | Completude e2e: ~8%

Macro-áreas: MA-CRM (CRM OS) + MA2 (Vendas & Pipeline) + MA3 (Aquisição Multicanal)

GATE MAIS CRÍTICO — Mudança de processo + código. O time de vendas precisa ser treinado.

3.3.1 CRM como Operating System (MA-CRM)

Escopo: Camada de infraestrutura que fornece contacts, companies, deals, pipelines, activities, sequences e scoring para todas as áreas que precisam gerenciar relacionamentos. Inclui pipeline de investidores (Fase 1+).

Módulos: /crm/* (12 páginas) — lógica roda como package consumido por MA2, MA3, MA4, MA10, MA11

O que existe:
- Entities: contacts, companies, deals, activities → FUNCIONAL
- Pipeline kanban com estágios configuráveis → FUNCIONAL
- Sequences: schema pronto, motor de execução stub
- Golden Record: entity resolution para dedup → FUNCIONAL
- Analytics: CRM analytics, churn cohort, form analysis → FUNCIONAL

O que falta:
- Desligar HubSpot como fonte de verdade (D4)
- Motor de execução de sequences funcional
- Dedup nativo sem HubSpot
- Configuração de pipelines por domínio (vendas, prestadores, CS, investidores)
- Documentar API de package para áreas consumidoras

Pipeline de Investidores (Fase 1+): A arquitetura de pipelines configuráveis DEVE suportar extensão para relações com investidores. Mesma infraestrutura: contacts (tipo: investor), companies (tipo: fund), deals (pipeline: fundraising).

3.3.2 Vendas & Pipeline (MA2)

Escopo: Pipeline de deals, comissões, propostas, metas, oitiva. Consome o CRM package.

Módulos: /vendas/* (31 páginas), /oitiva/* (8 páginas)

O que existe:
- Pipeline kanban com deals por estágio → FUNCIONAL
- Propostas: draft → sent → viewed → accepted/rejected → FUNCIONAL
- Metas de vendas (sales_targets) por pessoa e período → FUNCIONAL
- Oitiva: scorecards com critérios ponderados, transcrições, avaliações → EM DEV
- Analytics: CRM analytics, churn cohort, form analysis, plan mix → FUNCIONAL
- Comissão: BDR 1%, Closer 5% → PARCIAL (forecast não validado)

O que falta:
- Motor de execução de sequences (schema pronto, sem cron)
- Dedup nativo sem HubSpot
- Integrar métricas de Oitiva ao pipeline e scorecards
- Validar forecast de comissão com vendas
- Tracking opens/clicks/replies (webhooks Resend)
- Conexão com CS: deal fechado → trigger automático de onboarding

3.3.3 Aquisição Multicanal (MA3)

Escopo: Toda estratégia de aquisição, independente do canal. Responde "como trazemos clientes?"

Módulos: /aquisicao/* (6 páginas), /vendas/outbound, /vendas/leads

Canais suportados (estrutura agnóstica ao canal):
- Outbound (Lead Hunter, telefone, email, LinkedIn)
- Inbound (site, blog, landing pages, formulários)
- Paid (Meta Ads, Google Ads)
- Organic (SEO, conteúdo, redes sociais)
- Referral (indicação de clientes, parceiros)
- Events, Partnerships, Community

O que existe:
- Lead Hunter: prospecção B2B com Google Places + Exa enrichment → FUNCIONAL
- Lista de leads com filtros por localidade e segmento → FUNCIONAL
- KPIs diários de aquisição → PARCIAL (dados vazios)
- Lead scoring (lead_scoring_rules) → SCHEMA PRONTO
- Meta/Google Ads com analytics e CAPI → FUNCIONAL
- UTM tracking e conversion events → SCHEMA PRONTO

O que falta:
- KPIs diários com data binding real
- Lead scoring processor (cron agnóstico ao canal)
- Cadências outbound (depende motor de sequences)
- Atribuição de canal (first-touch + last-touch)
- Conversão por canal
- Referral tracking

User Stories (consolidadas G3)

• Como Closer, quero gerenciar meu pipeline de deals no Backstage, sem precisar abrir o HubSpot.
• Como BDR, quero prospectar leads no outbound sem que o sistema precise do HubSpot para dedup.
• Como SDR, quero criar e executar cadências de email (sequences) nativamente.
• Como VP Comercial, quero ver métricas de conversão por estágio do pipeline em tempo real.
• Como vendedor, quero ver o histórico completo de interações com um lead/empresa numa timeline.

Estado atual do CRM nativo (v2_sales)

Schema completo com:
- leads (status: new → contacted → qualified → unqualified → nurturing → converted → lost)
- contacts (lifecycle: subscriber → lead → mql → sql → opportunity → customer → evangelist)
- companies (type: prospect, customer, partner, competitor; enrichment via Google Places + Exa)
- deals (status: open, won, lost; com pipeline_id e stage_id)
- pipelines (types: sales, support, onboarding, provider_acquisition)
- stages (com probability, daysInStage, isWon, isClosed)
- activities (types: call, email, meeting, demo, task, note, follow_up)
- proposals (status: draft → sent → viewed → accepted/rejected/expired)
- sales_targets (metas por pessoa, time, período)
- Sequences (v2_sales): Schema COMPLETO mas sem motor de execução:
- sequences (status: draft, active, paused, archived)
- sequence_steps (types: email, call, linkedin_connect, linkedin_message, whatsapp, sms, manual_task)
- sequence_enrollments (status: active, paused, completed, replied, bounced, unsubscribed, opted_out, meeting_booked)
- step_executions (status: pending → scheduled → sent → delivered → opened → clicked → replied → bounced → failed → skipped)
- HubSpot sync ainda ativo: sync de dados, outbound dedup (dedupHubspot()), escrita (hubspotWrite()), provider onboarding

Critérios de aceite

CRM:
- [ ] HubSpot sync desligado (cron desabilitado, HUBSPOT_ACCESS_TOKEN removido)
- [ ] Contacts, companies, deals criados nativamente em v2_sales
- [ ] Outbound pipeline funciona sem HubSpot (dedup consulta v2_sales.companies por domain)
- [ ] Provider onboarding funciona sem HubSpot
- [ ] Sequences: criar, enrollar, enviar email (via Resend), trackear opens/clicks/replies
- [ ] Pipeline de vendas 100% no Backstage (zero operação no HubSpot)
- [ ] Migração completa de dados históricos HubSpot → v2_sales
- [ ] 3 pipelines configurados: vendas, prestadores, CS
- [ ] API de package documentada
- [ ] Golden Record integrado ao fluxo de criação
- [ ] Contacts com lifecycle tracking completo (lead → customer → churned)
- [ ] Activities registrando TODOS os touchpoints

Vendas:
- [ ] Propostas: fluxo completo draft → sent → viewed → accepted com notificação
- [ ] Comissão: forecast validado com time de vendas (BDR 1%, Closer 5%)
- [ ] Oitiva: avaliação de ligações integrada ao scorecard
- [ ] Analytics: ciclo de vendas, win rate, ticket médio, conversão por estágio
- [ ] Metas vs realizado: dashboard com progresso em tempo real
- [ ] Deal fechado → trigger automático: criar subscription + iniciar onboarding CS

Aquisição:
- [ ] KPIs diários com dados reais (leads trabalhados, demos agendadas, conversão)
- [ ] Lead scoring processor ativo (cron que calcula score por regras configuráveis)
- [ ] Score agnóstico ao canal
- [ ] Atribuição de canal: every lead tem acquisition_channel e first_touch_source
- [ ] Cadências outbound: BDR executa sequence sem HubSpot
- [ ] Dedup nativo: verificação por domain + email + telefone
- [ ] Dashboard de aquisição: leads por canal, conversão por estágio, CAC por canal
- [ ] UTM tracking funcional
- [ ] Referral: campo para registrar "indicado por"

Dependências técnicas

• Tabelas: v2_sales.* (leads, contacts, companies, deals, pipelines, stages, activities, sequences, sequence_steps, sequence_enrollments, step_executions, proposals, sales_targets)
• APIs: /api/crm/, /api/vendas/, /api/crm/sequences
• Externas: Resend (emails), Clicksign (contratos), Golden Record (dedup)

Discovery pendente

Alex — CRM:
- [ ] D-CRM-1: Dados históricos HubSpot — migrar todos ou só últimos 12 meses?
- [ ] D-CRM-2: Quais campos do HubSpot NÃO existem no v2_sales? Listar gaps
- [ ] D-CRM-3: Provider onboarding: como funciona sem HubSpot? Fluxo step-by-step
- [ ] D-CRM-4: Sequences: quais templates de cadência o time de vendas usa hoje?
- [ ] D-CRM-5: Golden Record: regras de merge estão corretas? Conflitos?
- [ ] D-CRM-6: Quais métricas CRM são consultadas diariamente? (com Didico)

Alex — Vendas:
- [ ] D-VEND-1: Quais analytics são realmente usados pelo time vs ignorados?
- [ ] D-VEND-2: Commission forecast: modelo BDR 1% + Closer 5% está correto?
- [ ] D-VEND-3: Outbound: qual o fluxo ideal de prospecção? Canais usados? (com Didico)
- [ ] D-VEND-4: ClickSign: contratos fluem corretamente em produção?
- [ ] D-VEND-5: Tactical planning: é usado pelo time? Se não, remover?

Alex — Aquisição:
- [ ] D-ACQ-1: Lead Hunter: é usado ativamente? Por quem?
- [ ] D-ACQ-2: KPIs diários: quais métricas o time consulta?
- [ ] D-ACQ-3: Lead scoring: quais regras definem um lead qualificado?
- [ ] D-ACQ-4: Quais canais de aquisição são prioritários? (com Didico)

JP — Oitiva:
- [ ] D-OIT-1: Oitiva é usado ativamente? Por quem?
- [ ] D-OIT-2: Scorecards: critérios atualizados?

Riscos

• GATE MAIS CRÍTICO. Migração HubSpot é mudança de processo, não só de código.
• Dados históricos do HubSpot: se perder, perde contexto de vendas passadas
• Sequence engine precisa ser construída do zero (schema pronto, execução não)
• Time de vendas precisa ser treinado na nova ferramenta

---

3.4 G4: Automações internas

Declaração: Todas as automações críticas da operação rodam dentro do Backstage, com monitoramento, logs, e UI para gerenciamento.

Responsável: JP | Sprint: 4 | Completude e2e: ~2%

Macro-áreas: MA6 (Automações & Workflows)

Escopo: Workflow builder, marketing automations, lead scoring engine, cron jobs, edge functions, automações de processo.

Módulos: /produto/workflows, crons, 58 edge functions (Deno)

User Stories

• Como Operações, quero ver todas as automações rodando no Backstage com status e logs.
• Como Marketing, quero criar cadências automáticas (email + WhatsApp) sem depender de dev.
• Como Vendas, quero que lead scoring rode automaticamente e marque leads para follow-up.

Arquitetura de Agents (padrão Campfire: Continuous + On-Demand)

Referência: Campfire.ai usa 2 tipos de AI agents — Continuous (rodam 24/7 em background) e On-Demand (disparados por calendário/evento). Cada ação logada, com source attribution, reviewable antes de postar. Confidence thresholds configuráveis.

Continuous Agents (via cron-service, interval 5-15min):
| Agent | O que faz | Código existente | A construir |
|-------|-----------|-----------------|-------------|
| Financial Guardian | Verifica balance double-entry, duplicatas, anomalias | v2_accounting.transactions + audit_log | Cron + regras de validação |
| Reconciliation Auto | Auto-match bank ↔ GL (confidence > 95%) | reconciliation-matcher.ts (confidence scoring existe) | Evoluir matcher com AI |
| Dunning Processor | Processa stages de cobrança + envia reminders | collections.ts (335 linhas, 3 stages) + dunning.ts (D+0/3/7/30) | Automação de envio |
| Health Score Monitor | Recalcula scores, gera alertas em queda brusca | crm.customer_health_scores (5 componentes) | Cron + alertas |
| Churn Signal Detector | Cruza inadimplência + uso + tickets | churn_predictions + collections_tracking + health scores | Cron cross-domain |

On-Demand Agents (scheduled, disparados por evento):
| Agent | O que faz | Código existente | A construir |
|-------|-----------|-----------------|-------------|
| Close Prep | Gera checklist de close, identifica pendências | GL queries (gl-queries.ts 29KB) | Cron mensal + schema close_periods |
| Weekly Report | Gera report por área + executivo (D-WEEK-1) | Planejado no MA-MGMT | Cron sexta 9h |
| Commission Calc | Calcula comissões BDR 1% + Closer 5% | v2_sales.deals (won) | Cron mensal |
| Flux Analyst | Gera análise period-over-period com commentary | DRE builder (dre-builder.ts) | Tool CEO IA + cron mensal |
| Metric Snapshot | Snapshota KPIs para histórico | MetricaSnapshot (planejado G5) | Cron diário 6h |

Estado atual (evidência do código)

• Workflow Builder: tipos (trigger → condição → ação) e executor definidos → STUB (simula, não executa)
• Marketing Automations: CRUD + cron 5min + enrollment engine → PARCIAL
• Funcionais: send_email (Resend), send_whatsapp (Evolution), set_contact_property, create_task
• Stub: send_sms, create_deal, webhook, internal_notification
• 25 Cron Jobs: maioria funcional, mas sem monitoramento centralizado
• 58 Edge Functions (Deno): separadas do monorepo, rodando no Supabase
• Cron-service billing stubs: 10 endpoints definidos mas NÃO migrados (/renewals, /credits, /retries, /expiration, /auto-reload, /dunning, /card-expiry, /usage, /auto-resume, /collections)

Gaps

• Workflow execution real (substituir stub por execução)
• Lead scoring processor (cron que calcula scores e dispara ações)
• Completar 4 ações de automação (SMS, deal, webhook, notification)
• UI de monitoramento de automações (logs, falhas, re-runs)
• Inventário de automações externas (Zapier, Make) para migrar (D1)
• Monitoramento centralizado dos 25 crons

Critérios de aceite

• [ ] Marketing automations: TODAS as 8 ações funcionais (incluir create_deal, webhook, internal_notification)
• [ ] Lead scoring processor: cron ativo que calcula scores e marca leads
• [ ] Monitoramento de crons: dashboard com status, última execução, falhas
• [ ] Inventário completo de automações externas com plano de migração
• [ ] Workflow builder: pelo menos 3 workflows simples executando (ex: deal stage change → task, health score < 40 → alert, lead score > 80 → notify)
• [ ] Logs de execução acessíveis na UI para debugging
• [ ] Edge functions: inventário com status e documentação mínima
• [ ] Alerta automático quando cron falha (Slack/Chat/Sentry)
• [ ] Continuous Agents: ≥3 agents rodando em cron-service (financial guardian, dunning processor, health score monitor)
• [ ] On-Demand Agents: ≥2 agents scheduled (close prep mensal, metric snapshot diário)
• [ ] Confidence Thresholds: configuração por tipo de ação AI (auto-execute >95%, review 70-95%, flag-only <70%). Usar pattern do agent-orchestrator.ts que já tem confidence metadata nos WorkerOutputs.
• [ ] Agent Dashboard: UI mostrando agents ativos, última execução, ações tomadas. Dados: agent_executions table (já existe em cost tracking)
• [ ] 10 billing crons migrados: os 10 stubs em /cron-service/src/routes/billing/ implementados (dunning, renewals, credits, retries, collections, etc.)

Dependências técnicas

• Tabelas: marketing_automations, lead_scoring_rules, workflow definitions
• APIs: /api/automations/, /api/workflows/
• Externas: Resend, Evolution, Sentry

Discovery pendente

JP:
- [ ] D-AUTO-1: Quais automações rodam FORA do Backstage hoje? (Zapier, Make, scripts?)
- [ ] D-AUTO-2: Quais são CRÍTICAS? (sem elas, o que para?)
- [ ] D-AUTO-3: Workflow builder visual: necessário para Fase 0 ou basta config?
- [ ] D-AUTO-4: Lead scoring: quais regras? (quem define o modelo?)

Riscos

• Automações externas podem ter dependências não documentadas
• Edge functions no Supabase operam fora do monorepo (blast radius limitado mas visibilidade baixa)

---

3.5 G5: Dashboard unificado de métricas

Declaração: A liderança abre UMA tela e vê a saúde completa da empresa com métricas atualizadas, filtráveis e drill-down-áveis.

Responsável: Alex | Sprint: 2 | Completude e2e: ~8%

Macro-áreas: MA8 (Dashboard & Analytics Executivo)

Escopo: Dashboard unificado para liderança, métricas consolidadas, filtros transversais, visão executiva.

Módulos: /dashboard (existente), /executive (a criar)

User Stories

• Como Liderança, quero abrir UMA tela e ver: MRR, churn rate, novos clientes, receita, despesas, health score médio, pipeline.
• Como CFO, quero filtrar por período, plano e cohort para entender tendências.
• Como qualquer pessoa, quero clicar em qualquer métrica e ver drill-down no módulo correspondente.

Estado atual (evidência do código)

• /dashboard: hub principal com links para todos os módulos → FUNCIONAL
• Analytics espalhados por módulo: financeiro (DRE, MRR, churn), vendas (pipeline, conversão), CS (health) → FUNCIONAL
• PostHog integrado para analytics de produto → FUNCIONAL
• Churn cohort, unit economics, form analysis → FUNCIONAL

Gaps

• UMA página /executive que consolide: MRR, churn rate, novos clientes, receita, despesas, health score médio, pipeline
• Filtros transversais: período, plano, cohort, ICP
• Binding de dados em /aquisicao/kpis-diarios (hoje mostra zeros)
• Métricas de CS no dashboard (health score médio, clientes em risco, NPS)
• MetricaSnapshot: tabela para snapshots históricos + cron diário

Critérios de aceite

• [ ] /executive page: MRR, churn rate, novos clientes, receita, despesas, health score médio, pipeline — tudo numa tela
• [ ] Filtros transversais: período (mês, trimestre, ano), plano, ICP
• [ ] MetricaSnapshot: cron diário que snapshota métricas-chave para histórico
• [ ] Comparativo mês a mês: MRR atual vs anterior, churn trend, pipeline trend
• [ ] KPIs de aquisição com dados reais (binding funcional)
• [ ] Métricas de CS: health score médio, # clientes em risco, NPS score
• [ ] Drill-down: clicar em qualquer métrica leva ao módulo correspondente
• [ ] Aprovação formal por Ju e VDC (PO sign-off)
• [ ] Cohort básico: filtrar métricas por mês de aquisição do cliente
• [ ] Flux Analysis AI: comparativo automático mês a mês com commentary gerado pela CEO IA. Usa dre-builder.ts para gerar DREs e fetchFinancialDataTool para dados. Tool novo: flux_analysis(period_a, period_b) retorna variações + commentary
• [ ] Drill-down universal: CADA métrica no /executive com link direto ao módulo fonte (MRR→/financeiro/novo-mrr, churn→/financeiro/churn-dashboard, health→/cs/health, pipeline→/vendas/pipeline)
• [ ] Source attribution: toda métrica mostra data source e timestamp de última atualização

Dependências técnicas

• Tabelas: dados de MA1, MA4, MA-CRM, metric_snapshots (a criar)
• APIs: /api/dashboard/, /api/executive/
• Externas: PostHog (analytics de produto)

Discovery pendente

VDC:
- [x] D-EXEC-1: KPIs já definidos nos Figmas do projeto, por área com drill-down.
- [x] D-EXEC-2: Diário. Overnight aceitável, dados prontos às 8h.
- [x] D-EXEC-3: Apenas liderança, diariamente.

Riscos

• Dados inconsistentes entre módulos podem gerar KPIs conflitantes
• Latência de agregação cross-módulo pode afetar performance

---

3.6 G6: Integrações estabilizadas

Declaração: Todas as integrações externas do Backstage estão monitoradas, documentadas e estáveis, com plano claro de internalização para as que serão substituídas.

Responsável: JP | Sprint: 2 | Completude e2e: ~10%

Macro-áreas: MA7 (Integrações)

Escopo: Integrações externas (evoluindo de 20+ para ~15 com internalização), sync engine, monitoramento de saúde, documentação técnica.

Estado atual (evidência do código)

Integração	O que faz	Status	Plano
HubSpot	CRM legado (16 entidades)	Ativo — em deprecação	Substituir por CRM package (G3)
Stripe	Billing clientes novos. Webhooks.	Ativo — primário	Manter (gateway)
Iugu	Billing legado. Sync ETL.	Ativo — sync estável	Manter (gateway)
Meta Ads	Marketing analytics + CAPI	Ativo	Manter
Google Ads	Marketing analytics	Ativo	Manter
Conta Azul	Contabilidade. Sync despesas.	Ativo	Substituir por Financeiro (G1)
Evolution	WhatsApp Business API	Ativo	Manter (canal)
Blip	Chatbot atendimento	Ativo	Manter (canal)
Banco Inter	Banking (mTLS + OAuth)	Ativo (auto-submit 5min)	Manter
Notion	Documentação. Sync conteúdo.	Ativo	Substituir por Wiki
Slack	Comunicação, alertas	Ativo	Substituir por Chat interno
Discord	Comunicação humanos + Freeclaw	Ativo	Substituir por Chat interno
Golden Record	Entity resolution / dedup	Ativo	Manter
Clicksign	Assinatura digital contratos	Ativo	Manter
Resend	Email transacional + tracking	Ativo	Manter
PostHog	Product analytics	Ativo	Manter
Vapi	Voice/calls webhooks	Ativo	Manter
Exa.ai	Web search/enrichment outbound	Ativo	Manter
Google Places	Busca escritórios Lead Hunter	Ativo	Manter
Mastercard	Corporate card SFTP + PGP	Ativo	Manter
Juit	Jurisprudência brasileira	Ativo	Manter
BigQuery	Google Ads data warehouse	Ativo	Manter
Google Calendar	Agenda bidirecional	Parcial (schema existe)	Manter como integração bidirecional

Ferramentas externas por design: GitHub (código) e Sentry (error monitoring). Não são pontos cegos.

Estratégia de Internalização

Ferramenta	Substituto interno	Timeline	Impacto
HubSpot	CRM package nativo	Fase 0 (G3)	Elimina custo + unifica dados
Conta Azul	Módulo Financeiro com contabilidade nativa	Fase 0-1	Habilita GL próprio
Notion	Wiki/Knowledge Base	Fase 0-1	Gestão de conhecimento centralizada
Slack	Chat interno Backstage	Fase 0-1	Schema workspace-chat (12 tabelas) existe
Discord	Chat interno Backstage	Fase 0-1	Elimina fragmentação da inteligência híbrida
Todoist/Trello	Gestão de Tarefas interno	Fase 0-1	Combinados + tasks dentro do Backstage

Princípios: (1) Só internalizar quando módulo interno for melhor. (2) Migração gradual: dual-write → leitura interna → desligar. (3) Dados históricos: sempre migrar ou manter acessíveis. (4) Contexto máximo para IA: internalizar comunicação é prioridade.

Critérios de aceite

• [ ] Dashboard de integrações: status, última sync, erros, latência
• [ ] Alerta automático (Sentry + Slack/Chat) quando integração falha
• [ ] SLA definido: cada sync tem frequência esperada e threshold de alerta
• [ ] Zero falhas críticas em 7 dias consecutivos
• [ ] Documentação: cada integração com ficha técnica (credenciais, frequência, tabelas, fallback)
• [ ] HubSpot: plano de desligamento com data-alvo e checklist de migração
• [ ] Conta Azul: plano de transição para contabilidade nativa
• [ ] Banco Inter: decisão tomada (D12)
• [ ] Sync engine: dual-write validado sem perda de dados
• [ ] Inventário de credenciais: todas em vault seguro, nenhuma hardcoded

Dependências técnicas

• Tabelas: sync.*, configurações de integração
• APIs: /api/integrations/*, webhooks
• Externas: todas as 20+ integrações listadas acima

Riscos

• Breaking changes em APIs externas podem paralisar operação
• Credenciais espalhadas sem vault centralizado

---

3.7 G7: Mensageria no monorepo

Declaração: WhatsApp, email e inbox operam de forma unificada no Backstage, com histórico consolidado por cliente e classificação IA de mensagens.

Responsável: JP | Sprint: 3 | Completude e2e: ~5%

Macro-áreas: MA5 (Mensageria & Comunicação)

Escopo: WhatsApp, email transacional, inbox unificado, templates, chat interno, classificação IA de mensagens.

Módulos: /interno/whatsapp (12 páginas), /suporte/inbox, /chat (4 páginas)

User Stories

• Como CS, quero ver todas as mensagens (WhatsApp + email) de um cliente numa timeline única.
• Como Vendas, quero enviar cadência de email e ver se o lead abriu/clicou.
• Como Suporte, quero receber mensagens do WhatsApp no inbox unificado com roteamento automático.

Estado atual (evidência do código)

• WhatsApp via Evolution API: envio e recebimento bidirecional → FUNCIONAL
• Email via Resend: transacional com tracking completo → FUNCIONAL
• Inbox unificado em /suporte/inbox → FUNCIONAL (com assignedTo e departments)
• Chat interno com canais, DMs, threads → FUNCIONAL
• Chatbot via Blip para atendimento automatizado → FUNCIONAL
• AI Classification: classifica mensagens por intent (sales/support/cs/marketing) com confidence → FUNCIONAL
• Templates: notification_templates por canal (email, push, sms, in_app, whatsapp, slack) → PARCIAL

Gaps

• Histórico consolidado por cliente cross-channel (v2_comms não linkado ao Customer 360)
• Completar webhook de respostas WhatsApp
• UI de gerenciamento de templates validada com o time
• SMS: stub sem provedor (decisão: entra Fase 0?)

Critérios de aceite

• [ ] Histórico consolidado: dado um orgId, retornar TODAS as interações (WhatsApp + email + suporte) ordenadas
• [ ] Webhook de respostas WhatsApp processando e aparecendo no histórico
• [ ] Templates: UI de CRUD funcional, validada com CS e Vendas
• [ ] Chat interno: notificações de alertas do sistema — substituição gradual do Slack
• [ ] AI Classification: accuracy > 85% medida em amostra real
• [ ] Inbox unificado: assignedTo funcionando com roteamento por department
• [ ] Integração Customer 360 ↔ v2_comms.conversations (link por orgId)
• [ ] Email tracking: opens/clicks registrados e visíveis na timeline do deal
• [ ] Decisão sobre SMS (entra Fase 0 ou não)

Dependências técnicas

• Tabelas: v2_comms.conversations, v2_comms.messages, v2_comms.message_identities, v2_comms.notification_templates, v2_comms.contacts, v2_comms.ai_message_classification
• APIs: /api/whatsapp/, /api/inbox/, /api/chat/*
• Externas: Evolution (WhatsApp), Resend (email), Blip (chatbot)

Discovery pendente

JP:
- [ ] D-WPP-1: WhatsApp é usado para quais fluxos? (vendas? suporte? onboarding?)
- [ ] D-WPP-2: Evolution API vs Cloud API: qual o padrão? Manter os dois?
- [ ] D-WPP-3: Templates: quais são necessários? Quem define conteúdo?
- [ ] D-WPP-4: Automação de mensagens: entra na Fase 0?

JP — Chat:
- [ ] D-CHAT-1: Chat interno é usado? Por alguém?
- [ ] D-CHAT-2: Slack import: migrar histórico completo ou começar do zero?
- [ ] D-CHAT-3: Quais canais criar? (por área? por projeto? por gate?)

Riscos

• Evolution API pode ter instabilidades (API não oficial do WhatsApp)
• Volume de mensagens pode impactar performance do inbox unificado

---

PARTE 4: REFERÊNCIA TÉCNICA

Conteúdo de referência — inventário, schemas, integrações, IA. Consultar sob demanda.

4.1 Inventário do código (mapeado 2026-03-12)

Métrica	Valor
Apps no monorepo	9 (backstage, studio-offices, studio-providers, mobile x2, website, cron-service, automation-service, voice-bot-service)
Packages compartilhados	30+
Pages (Backstage)	~175 reais (muitas são layouts/skeletons)
Pages (total, todos os apps)	448
API Routes (Backstage)	~260
API Routes (total)	629+
Database Schema Files	100+ arquivos, 400+ tabelas em 25 schemas PostgreSQL
Integrações externas	20+ (com plano de internalização)
AI Agents (ecossistema)	18+ (4 backstage + 14+ ai-service)
AI Tools	60+ (legal, documents, platform, actions, search/RAG, content)
Cron Jobs	25+ Backstage + 30+ Studio (migração Vercel → Hetzner planejada)
Test Files (Backstage)	184
UI Components (Design System)	80+

Conclusão: O problema não é "construir do zero" — é terminar, conectar e estabilizar. Schema/skeleton existente ≠ funcional.

Mapa de módulos

Módulo vs Package vs Páginas: Um módulo é um agrupamento de rotas/páginas no app (ex: /vendas/*).
Uma página é um arquivo .tsx que renderiza UI. Um package (OS) é infraestrutura transversal
consumida por múltiplos módulos (ex: CRM OS fornece contacts/deals/pipelines para Vendas, CS e Prestadores).

O CRM aparece aqui como módulo (/crm/*, 12 páginas de gestão direta) E é um OS (package consumido por outros módulos).
O Management OS não tem rotas próprias — ele permeia todas as áreas como home/cockpit personalizado.

Módulo	Tipo	Rota	Páginas	Status	Gate
CRM	OS (package transversal) + módulo	/crm/*	12 (gestão direta) + consumido por Vendas, CS, Prestadores, Marketing	Funcional	G3
Management OS	OS (package transversal)	(permeia todas as áreas)	Cockpit por role, pulses, reports, combinados	Schema parcial	—
Financeiro	Módulo	/financeiro/*	28	Funcional	G1, G5
Vendas	Módulo (consome CRM)	/vendas/*	31	Funcional	G3
Aquisição	Módulo (consome CRM)	/aquisicao/*	6	Parcial (stubs)	G3
CS	Módulo (consome CRM)	/cs/*	9	Parcial	G2
Suporte	Módulo	/suporte/*	13	Parcial	G2, G7
WhatsApp	Módulo	/interno/whatsapp	7	Parcial	G7
Prestadores	Módulo (consome CRM)	/prestadores/*	14	Funcional	—
Produto	Módulo	/produto/*	112	Funcional	—
RH	Módulo	/rh/*	18	Parcial	—
Chat	Módulo	/chat	4	Funcional	—
Wiki	Módulo	/wiki	5	Funcional	—
Oitiva	Módulo	/oitiva/*	8	Em dev	—
Marketing	Módulo (consome CRM)	/marketing/*	4	Parcial	—
Dashboard	Módulo	/dashboard	—	Funcional	G5
Meetings/Calendar	Schema only	(sem rota)	—	Nível 1	MA-MGMT
Pulses	Schema only	(sem rota)	—	Nível 1	MA-MGMT
Social Media	Schema + API	(sem rota)	—	Nível 2	—
Reports Builder	Schema + API	(sem rota)	—	Nível 2	G5
Chatbots	Schema + API	/suporte/chatbot	—	Nível 2	G7

Maturidade Funcional — Schema ≠ Funcional

NÍVEL 0: Não existe (nem schema)
NÍVEL 1: Schema existe (tabelas definidas, sem API nem UI)
NÍVEL 2: Schema + API (endpoints existem, retornam dados)
NÍVEL 3: Schema + API + UI (página existe, mostra dados)
NÍVEL 4: Funcional e2e (fluxo completo testável em produção)
NÍVEL 5: Testado e validado (PO testou, dados reais, zero mock)

Capacidade	Nível	Nota
Financeiro	3-4	v2_billing 24+ tab, 50+ endpoints, 28 páginas
CRM nativo	3-4	v2_sales 20+ tab, 35+ endpoints, 12 páginas
CS/Health Score	3-4	crm.* 5+ tab, 20+ endpoints, 9 páginas
Wiki/Knowledge	3-4	14 tabelas, 18 endpoints
Chat interno	3	12 tabelas, 18 endpoints
OKRs/Strategy	3	6 tabelas, 3 endpoints
HR completo	2-3	25+ tabelas, 12 endpoints
Workflow Executor	2	3 sistemas, UI existe, STUB
Social Media	2	Schema + 5 endpoints
Reports Builder	2	Schema + 4 endpoints
Meetings/Calendar	1	4 tabelas, sem API
Pulses	1	5 tabelas, sem API
Tasks/Projects	1	Schema parcial, skeleton

Leitura: ZERO no Nível 5. 4 no Nível 3-4. 5 no Nível 1-2. O caminho: levar G1-G7 ao Nível 5.

Mapa completo de packages (48 packages — auditado 2026-03-13)

O monorepo segue um sistema de tiers (documentado em backstage-docs.vercel.app, aba Sistema).
ARCH-02: "Packages definem a interface entre apps. São o contrato público."
Apps NUNCA importam de outros apps. Toda comunicação via banco compartilhado + packages.

Tier 1 — CORE (zero deps de infra)

Package	Files	Descrição	Consumido por
@freelaw/core	341	Types, schemas Zod, cálculos, formatters, billing, calendar, documents, events	Backstage, Studio, Providers
@freelaw/types	65	Tipos compartilhados (analytics, calendar, chat, clients, classifications)	Backstage, Studio
@freelaw/config	5	Brand strategy, design tokens, feature flags	Todos
@freelaw/tsconfig	—	Configuração TypeScript compartilhada	Todos
@freelaw/shared	—	Utilidades compartilhadas	Backstage, Studio
@freelaw/backstage-core	16	Domínios do Backstage: finance, leads, comunidade, retention, marketing	Backstage

Tier 2 — INFRA (serviços externos e dados)

@freelaw/infra — Mega-package com 20 sub-packages:

Sub-package	Files	Descrição	Gate relacionado
@freelaw/infra-db	227	Schemas Drizzle, 400+ tabelas, 25 schemas PostgreSQL	Todos
@freelaw/infra-observability	17	Logging, tracing, métricas (cross-cutting)	—
@freelaw/infra-payments	16	Gateway unificado Iugu + Stripe	G1
@freelaw/infra-whatsapp	54	Evolution API integration	G7
@freelaw/infra-banking	11	Open Banking, Banco Inter (mTLS + OAuth)	G1, G6
@freelaw/infra-analytics	13	ETL pipelines, métricas de negócio	G5
@freelaw/infra-erp	7	Integração Conta Azul	G1, G6
@freelaw/infra-meta-ads	7	Meta Ads API + CAPI	G6
@freelaw/infra-meta-ads-cli	23	Ads as Code (terminal tool)	—
@freelaw/infra-mastercard	5	Corporate card SFTP + PGP	G1
@freelaw/infra-jobs	18	BullMQ job queue, background processing	G4
@freelaw/infra-slack	4	Slack API (alertas, notificações)	G6
@freelaw/infra-notion	4	Notion API (sync documentação)	G6
@freelaw/infra-supabase	12	Supabase client, auth, storage	—
@freelaw/infra-cache	3	Cache layer	—
@freelaw/infra-rag	1	RAG client (embeddings, retrieval)	—
@freelaw/infra-ml-taxonomy	1	ML taxonomy classification	—
@freelaw/infra-legacy-api	20	API legada (compatibilidade)	—
@freelaw/infra-shared	3	Utils compartilhados entre infra-*	—
@freelaw/infra-solucionare	12	Integração Solucionare	—

Outros Tier 2:

Package	Files	Descrição	Consumido por
@freelaw/server	326	Auth, domain, integrations, models, repositories, services	Backstage, Studio
@freelaw/lib	217	Actions, API helpers, cache, hooks, formatters, Evolution API	Backstage, Studio
@freelaw/auth	17	Componentes e hooks de autenticação	Backstage, Studio

Tier 3 — FEATURES (UI, AI, Workflows)

Package	Files	Descrição	Consumido por
@freelaw/ui	191	Component library (80+ componentes), tokens, a11y	Backstage (2118 imports), Studio (1647)
@freelaw/ui-native	13	Componentes React Native	Mobile apps
@freelaw/ai	124	Model router, memory, RAG, HITL, guardrails, cost tracking, Mastra	Backstage, AI Service
@freelaw/workflows	7	Workflow executor, domain types, repository	Backstage
@freelaw/editor	13	Editor de texto rico (TipTap/ProseMirror)	Backstage, Studio
@freelaw/api-contracts	27	Contratos HTTP tipados entre apps	Studio
@freelaw/feature-gates	22	Feature flags centralizados, gates, hooks	Backstage
@freelaw/content-pipeline	12	Pipeline de geração de conteúdo (blog, SEO)	Backstage
@freelaw/admin-sdk	13	SDK administrativo (actions, types)	Backstage

Tier 3 — DOMÍNIO (packages de domínio específico)

Package	Files	Descrição	Consumido por
@freelaw/workspace-core	21	Management OS: chat, documents, meetings, pulses, strategy, AI	Backstage
@freelaw/workspace-ui	17	Componentes React do workspace (engagement, shared)	Backstage
@freelaw/hr-core	12	Domínio RH: employees, payroll, performance, OKR, pulse	Backstage
@freelaw/hr-sdk	36	Server actions e repositories de RH	Backstage
@freelaw/payments-core	32	Domínio pagamentos: billing, PIX, invoice validator	Backstage, Providers
@freelaw/matching	21	Smart Match: scoring, filtering, orquestração M1→M2→M3	Backstage
@freelaw/studio-providers-core	28	Domínio prestadores: orders, analytics, assessments, PIX	Backstage, Providers
@freelaw/studio-providers-sdk	48	SDK prestadores: actions, hooks, repositories, services	Providers

Consumo por app (top imports)

App	Top packages (por # de imports)
Backstage	@freelaw/ui (2118), @freelaw/infra-observability (553), @freelaw/infra-db (428), @freelaw/core (79), @freelaw/admin-sdk (63)
Studio Offices	@freelaw/ui (1647), @freelaw/infra-db (605), @freelaw/infra-observability (322), @freelaw/lib (118), @freelaw/server (112)
Studio Providers	@freelaw/infra-db (44), @freelaw/infra-observability (27), @freelaw/ui (4)

Packages → Gates (mapa de relevância)

Gate	Packages críticos
G1 (Financeiro)	infra-db, infra-payments, infra-banking, infra-erp, infra-mastercard, backstage-core (finance), payments-core
G2 (CS)	infra-db, workspace-core (engagement), core (clients)
G3 (CRM/Pipeline)	infra-db, backstage-core (leads, retention), matching, studio-providers-core
G4 (Automações)	infra-jobs, workflows, infra-whatsapp, infra-payments
G5 (Dashboard)	infra-analytics, backstage-core (finance, marketing), infra-db
G6 (Integrações)	infra-* (todos), infra-observability
G7 (Mensageria)	infra-whatsapp, infra-slack, workspace-core (chat), ai

Domínios no backstage-core

Domínio	Entidades principais
Finance	Subscriptions (Stripe+Iugu), MRR, DRE, Budget, Cashflow, Unit Economics
Leads	Lead Hunter, Google Places enrichment, Exa data enrichment
Comunidade	Provider funnel, tiers (S+ a D), journey phases, saturação, ranking
Retention	Churn risk signals, health score (5 componentes), retention offers
Marketing	Ad campaigns (Meta/Google), content analytics, CAPI integration

4.2 Arquitetura de dados

Princípios fundamentais

1. Toda transação financeira → lançamento contábil → General Ledger
2. Ciclo de vida completo do cliente — do primeiro touchpoint até offboarding
3. Single source of truth por domínio — cada dado tem UM owner
4. Auditabilidade — toda mudança com timestamp, autor e motivo

General Ledger (Plano de Contas)

ENTRADAS DE DADOS                    GENERAL LEDGER                    SAÍDAS
Stripe webhooks ────────┐                                    ┌──→ DRE
Iugu sync ──────────────┤      ┌───────────────────┐         ├──→ Balanço
Conta Azul sync ────────┤      │  Journal Entries   │         ├──→ DFC
Banco Inter sync ───────┼────→ │  (Lançamentos)     │─────────├──→ Unit Economics
Pagto prestadores ──────┤      │       ↓            │         ├──→ Business Plan
Despesas manuais ───────┤      │  General Ledger    │         ├──→ Budget vs Real
Receita manual ─────────┘      │  (Razão)           │         └──→ Conciliação
                               │       ↓            │
                               │  Chart of Accounts │
                               │  (Plano de Contas) │
                               └───────────────────┘

Estado: Schema v2_accounting maduro:
- chart_of_accounts: 85 contas hierárquicas, alinhadas com BP 2026
- transactions: Double-entry journal entries (pending → confirmed → reconciled)
- transaction_allocations: Débitos/créditos vinculados a contas e centros de custo
- cost_centers, vendors, bank_accounts, budgets, budget_lines, bank_reconciliations
- approval_requests: Workflow de aprovação multi-nível
- alerts, audit_log

5 Posting Engines (5.689 linhas, 10 arquivos):
1. finance-posting.ts (1.253 linhas) — v2_billing → GL
2. contaazul-posting.ts (405 linhas) — Conta Azul ERP → GL
3. inter-posting.ts (316 linhas) — Banco Inter → GL
4. payroll-posting.ts (283 linhas) — Folha de pagamento → GL
5. tax-posting-etl.ts (455 linhas) — Cálculos tributários → GL

Hierarquia (85 contas): 1.x ATIVO, 2.x PASSIVO, 3.x PL, 4.x RECEITA, 5.x DESPESA, 6.x Depreciação, 7.x Impostos sobre Lucro.

Ownership de dados por macro-área

Domínio	Owner	Tabelas	Consumidores
Leads, Contacts, Companies	CRM	v2_sales.leads, .contacts, .companies	Vendas, Aquisição, CS, Marketing, Prestadores
Deals, Pipelines, Stages	CRM	v2_sales.deals, .pipelines, .stages	Vendas, Financeiro, Dashboard
Subscriptions, Invoices, MRR	Financeiro	v2_billing.*	CS, Dashboard
Despesas, DRE, GL	Financeiro	fin_, budget, vendor_category_mapping	Dashboard, Prestadores
Health Score, NPS, Journey	CS	crm.customer_health_scores, .nps_responses	Financeiro, Vendas, Dashboard
Conversas, Mensagens	Mensageria	v2_comms.conversations, .messages	Vendas, CS
Campanhas, Ads	Marketing	v2_marketing.campaigns, .ad_campaigns_v2	Aquisição, Dashboard
Prestadores, Tiers	Prestadores	providers.*	Financeiro, CRM
Workflows, Automações	Automações	marketing_automations, lead_scoring_rules	Vendas, Aquisição, CS
Sync externo	Integrações	sync.*	Financeiro, CRM

Fluxos de dados críticos

Aquisição → Venda → Cliente → Lifecycle:

PRIMEIRO TOUCHPOINT          QUALIFICAÇÃO              FECHAMENTO
(ad, form, ligação)    →    BDR/SDR prospecta    →    Closer negocia
       ↓                         ↓                         ↓
v2_marketing.conversion    v2_sales.leads           v2_sales.deals
v2_sales.activities        (new→qualified→          (open→won)
                            converted)                    ↓
                                ↓                   ONBOARDING
                           v2_sales.contacts        crm.customer_journey
                           (lead→customer)               ↓
                                                   HEALTH MONITORING
                                                   crm.customer_health_scores
                                                        ↓
                                                   ┌────┴────┐
                                                   SAUDÁVEL   EM RISCO
                                                   Renovação  Playbook CS
                                                        ↓         ↓
                                                   RENEWED    CHURNED

Financeiro → GL:

Stripe webhook + Iugu sync + Conta Azul sync + Banco Inter sync + Pagto prestadores
    → Journal Entries → General Ledger → Plano de Contas
    → DRE, Balanço, DFC, KPIs, Unit Economics, Conciliação, Business Plan

HubSpot → Nativo (Migração G3):

hubspot_contacts  → MIGRAR → v2_sales.contacts
hubspot_companies → MIGRAR → v2_sales.companies
hubspot_deals     → MIGRAR → v2_sales.deals
dedupHubspot()    → SUBSTITUIR → dedup por v2_sales.companies.domain
hubspotWrite()    → SUBSTITUIR → escrita direta em v2_sales

Convenções de schema

• Naming: snake_case para tabelas e colunas
• IDs: UUID v4 (gerado no banco)
• Timestamps: created_at, updated_at (timestamptz)
• Soft delete: deleted_at (nullable timestamptz) para dados regulados
• Organization: organization_id para multi-tenancy
• Schemas nomeados: v2_billing, v2_sales, v2_marketing, v2_comms, crm, sync — nunca public
• RLS obrigatório

RLS e Segurança

Padrão: Row Level Security no Supabase por organization_id.

-- Padrão para tabelas com organizationId
pgPolicy("table_select", { using: sql`(organization_id = user_organization_id())` })

-- Para tabelas filho (herda do pai)
pgPolicy("child_select", { using: sql`EXISTS (SELECT 1 FROM parent WHERE ...)` })

-- Para dados financeiros (restrito a finance team)
pgPolicy("finance_only", { using: sql`(sync.is_finance_team(current_user_id()))` })

Segregação por cargo/área:
- Permissões de agenda: IC (própria), líder (time), C-level (todos)
- Permissões de KPIs: filtro por hr.hrColaboradores.cargo + hr.hrAreas
- Permissões de dados: core.permissions + core.userPermissions + core.permissionDelegations

Schemas detalhados

SCHEMAS BACKSTAGE (apps/backstage/src/db/schema/):
├── deals.ts, sales-people.ts, goals.ts, activities.ts, funnels.ts
├── financeiro.ts (vendor_category_mapping, fin_estruturas, fin_centros_custo + re-exports)
├── hubspot.ts (DEPRECATED), chat.ts, chatbots.ts, clicksign.ts
├── org-chart.ts, planejamento.ts, reports.ts, support.ts
├── user-profiles.ts, users.ts, wiki.ts, imports.ts

SCHEMAS INFRA-DB (packages/infra/db/src/schemas/v2/):
├── billing/       → v2_billing.* (24+ tabelas)
├── sales/         → v2_sales.* (20+ tabelas)
├── marketing/     → v2_marketing.* (15+ tabelas)
├── comms/         → v2_comms.* (10+ tabelas)
├── customer-success/ → crm.* (5+ tabelas)
└── sync/          → sync.* (cópias de dados externos)

Entidades que faltam

• Motor de sequences: schema pronto, falta cron que processa enrollments e envia emails + integração WhatsApp/SMS
• Interação unificada: v2_comms.conversations base existe, falta linkagem com v2_sales.contacts e API unificada GET /api/customer-360/{id}/interactions
• Customer 360: endpoint agrega 9 fontes, falta performance + dados Studio + cohortização
• MetricaSnapshot: tabela dedicada para snapshots históricos + cron diário

Close Management (inspirado Campfire.ai — novo)

Campfire.ai reduz close de 15→3 dias com checklist + flux analysis + period lock. O v2_accounting já tem GL, budgets, audit_log, approval_requests. Faltam 2 tabelas e 1 check.

v2_accounting.close_periods — Controle de período contábil:
- id (UUID), organization_id (FK), period (date, primeiro dia do mês)
- status (enum: open, in_review, closed), locked (boolean)
- closed_by (FK users), closed_at (timestamptz)
- checklist_completed_at, notes, created_at, updated_at

v2_accounting.close_checklist_items — Itens do checklist:
- id (UUID), close_period_id (FK), title, description
- status (enum: pending, in_progress, done), assigned_to (FK users)
- type (enum: reconciliation, review, posting, approval, report, custom)
- auto_check (boolean — AI verifica automaticamente)
- completed_at, order (int), created_at, updated_at

Period Lock: check em todas as APIs de escrita: WHERE NOT EXISTS (SELECT 1 FROM v2_accounting.close_periods WHERE period = target_period AND locked = true). Implementar como middleware ou wrapper nos 3 posting engines.

Checklist padrão (12 items): reconciliar Iugu, Stripe, Inter, Itaú → classificar despesas → validar folha → verificar provisões → revisar AP → DRE draft → flux analysis AI → revisar DRE → lock period.

Tools financeiros da CEO IA (expansão — novo)

CEO IA (ceo-ia-agent.ts, 816 linhas) tem 3 tools hoje: fetchFinancialData (MRR, clientes, inadimplência), fetchSalesData (pipeline, conversões), naturalQuery (livre). Inspirado no Ember Chat do Campfire que responde queries financeiras com source data, expandir com:

Tools de leitura (auto-execute):
- query_gl(account, period, cost_center) — consulta GL via gl-queries.ts (29KB)
- query_dre(period) — gera DRE via dre-builder.ts
- query_cash_position() — posição de caixa D+0 (contas Inter + Itaú)
- query_ar_aging() — aging de recebíveis por bucket
- query_ap_pending() — contas a pagar pendentes com vencimento
- query_unit_economics() — CAC, LTV, payback via unit-economics-calc.ts
- query_close_status(period) — status do checklist de close

Tools de análise (auto-execute):
- flux_analysis(period_a, period_b) — variação DRE com commentary
- anomaly_detection(period) — transações anômalas (padrão do Financial Guardian)
- forecast_cash(weeks) — projeção de caixa (D-FIN-4: 13-week)

Tools de escrita (review before post — confirmação obrigatória):
- create_journal_entry(entries[]) — lançamento manual no GL
- categorize_transaction(id, account) — categoriza transação não classificada
- approve_payment(id) — aprova pagamento via approval_requests

Confidence Thresholds (padrão Campfire):
- Leitura: auto-execute (confidence irrelevante)
- Categorização: auto >90%, review 70-90%, flag <70%
- Reconciliation match: auto >95%, review 80-95%
- Escrita financeira: SEMPRE review (never auto)
- Comunicação: SEMPRE review

Código base: agent-orchestrator.ts já tem confidence no WorkerOutput.metadata. guardrails.ts já tem scoring 0-100 com minScore: 70. Budget manager em budget-manager.ts já tem tiers e atomic checking. Expandir para ações específicas.

4.3 Ecossistema de IA (18+ Agents, 60+ Tools)

Backstage Agents (4)

Agent	Função	Dados que acessa
CEO IA	Planejamento estratégico, insights executivos	MRR, ARR, pipeline, conversões, metas
Backstage Assistant	Assistente geral operacional	Prestadores, KPIs, governança
Maria Insights	Insights sobre comunidade de prestadores	Prestadores, tiers, journey, saturação
Oitiva Evaluation	Avalia qualidade de ligações de vendas	Transcrições, scorecards, critérios

Crons IA: sync-calls (10min), sync-evaluations (15min), process-transcriptions (5min), openclaw-runtime (10min), churn-prediction (weekly)

AI Service Agents (14+)

Agent	Função	Público
Lia Global	Orquestrador principal do Studio (27 tools)	Clientes
Lia WhatsApp	Lia adaptado para WhatsApp	Clientes
Free Tier	Atendimento de leads anônimos	Leads
Document Agent	Geração de peças jurídicas (130+ templates)	Clientes
Petition Orchestrator	Geração multi-step de petições	Clientes
Research/Writing/Review/Summary/Extraction/Deadline/Classification/Jurisprudence	Pipeline de IA jurídica	Interno
SEO/Editorial/Newsletter/Content	Pipeline de marketing e conteúdo	Interno
Consultant	Knowledge base + action plans para suporte	Interno

Freeclaw / OpenClaw (Inteligência Híbrida)

OpenClaw é o orquestrador multi-agente corporativo da Freelaw (terminal, Slack, Notion, Backstage). Freeclaw é a manifestação visível. Problema atual: opera no Discord, separado dos humanos (Slack). Solução: internalizar Slack + Discord → Backstage chat.

AI Tools (60+ por categoria)

Categoria	Qtd	Exemplos
Legal	12	Jurisprudência, legislação, doutrina, cálculos, prazos, OCR
Documents	12	Geração, validação, estilo, templates, 130+ peças
Platform Data	8	Processos, tarefas, clientes, publicações
Actions	8	Criar tarefa, atualizar status, cancelar
Search/RAG	8	Semântico, híbrido, natural query
Content/Marketing	10	Podcast, YouTube, SEO, keywords
Support	2	Tickets, knowledge base

Infraestrutura (@freelaw/ai)

• Model Router: Anthropic, Google, OpenAI
• Memory: Contexto persistente por conversa e usuário
• RAG: Retrieval-Augmented Generation com embeddings
• HITL: Human-in-the-loop para decisões críticas
• Guardrails: Validação de outputs, content filtering
• Cost Tracking: ai_credits + ai_credits_ledger por cliente e agent
• Mastra Workflows: 5 workflows orquestrados

4.4 Débito técnico

Inventário

Segurança (P0):
- ~14 API routes sem autenticação (atualizado 2026-03-12)
- Vulnerabilidades CSRF em OAuth flows
- Sem rate limiting

Qualidade de código:
- 9 instâncias de z.any()
- 0 @ts-nocheck (corrigido)
- 83 console.log (deveria usar logger estruturado)
- 30 páginas sem error handling
- 27 páginas sem loading states
- 13 páginas sem empty states

UX:
- Aquisição KPIs mostrando zeros (falta data binding)
- Módulos com dados mock misturados com dados reais
- Playbooks CS vazio

Estratégia

NÃO tratar débito técnico de forma horizontal na Fase 0. Apenas corrigir nos módulos que tocamos para fechar os gates.
Exceção: se uma route sem auth for pública e expor dados sensíveis, corrigir imediatamente.

Priorização routes sem auth:
1. Routes públicas que expõem dados de clientes → P0
2. Routes que escrevem dados (POST/PUT/DELETE) sem auth → P1
3. Routes internas de leitura → P2

---

PARTE 5: TRACKING & OPERAÇÃO

Decisões, forma de trabalho e métricas. Muda toda semana.

5.1 Decisões pendentes

#	Decisão	Responsável	Deadline	Status	Gate
D1	Quais ferramentas externas eliminar (lista completa)	Time	Sprint 1	Pendente	G6
D2	Prioridade dos gates (ordem proposta OK?)	VDC + Ju	Sprint 1	Pendente	Todos
D3	Health score: quais métricas e pesos? CS valida?	CS + Produto	Sprint 2	Pendente	G2
D4	HubSpot: data-alvo de desligamento	Vendas + Backstage	Sprint 1	Pendente	G3
D5	Stack de mensageria final (Evolution API é definitivo?)	Time	Sprint 1	Pendente	G7
D6	14 routes sem auth: quais priorizar?	VDC + Time	Sprint 1	Pendente	—
D7	Stakeholders para aprovação de UX de cada gate	Ju	Sprint 1	Pendente	Todos
D8	Atribuição final do time (quem faz o quê)	VDC	Sprint 1	Pendente	Todos
D9	ERP (Freelaw One): entra na Fase 0?	VDC	Sprint 1	Pendente	G1
D10	Google Sheets: eliminar ou conviver na Fase 0?	Finance	Sprint 1	Pendente	G1
D11	Dados históricos do HubSpot: migrar ou perder?	Vendas + JP	Sprint 1	Pendente	G3
D12	Banco Inter sync: ativar na Fase 0?	Finance	Sprint 2	Pendente	G1, G6
D13	Workflow builder visual: Fase 0 ou Fase 1?	VDC	Sprint 1	Pendente	G4
D14	Mapeamento completo de conexões cross-área	VDC + Time	Sprint 1	Pendente	Todos
D15	CRM package: quais pipelines configuráveis?	VDC + Time	Sprint 1	Pendente	G3
D16	LIA: compartilhar infraestrutura IA ou separar?	VDC + Produto	Sprint 1	Pendente	—
D17	Documentação completa da arquitetura de dados	VDC + Time	Sprint 1	Pendente	—
D18	Plano de migração gestao.freelaw.ai → Backstage	VDC + RH	Sprint 1	Pendente	—
D19	Design System: escopo Fase 0 e Designer's Bible	VDC + Design	Sprint 1	Pendente	—
D20	Validação em produção: plano de testes	VDC + QA	Sprint 1	Pendente	Todos
D21	Unificar 3 taxonomias sob macro-áreas	VDC + Produto	Sprint 1	Pendente	—
D22	Management OS: escopo MVP e roles iniciais	VDC + Produto	Sprint 1	Pendente	—
D23	CEO AI: quais KPIs vitais v1 por área	VDC + Lideranças	Sprint 1	Pendente	—
D24	Pulses: templates por área + cadência	VDC + Time	Sprint 1	Pendente	—
D25	LIA vs CEO AI: compartilhar infraestrutura?	VDC + Produto	Sprint 1	Pendente	—

5.2 Decisões de Discovery por Pessoa

Tracker centralizado: cada pessoa vê TODAS as suas decisões num só lugar.
Status: [ ] pendente, [x] respondido, [-] não se aplica.
As decisões também aparecem dentro de cada gate/MA, mas aqui é o tracker consolidado.

VDC (Guilherme) — 50 perguntas (todas respondidas ✓)

FINANCEIRO (Sprint 2)
- [x] D-FIN-1: Google Sheets eliminado dos workflows core. Usado apenas para análises pontuais pós-exportação.
- [x] D-FIN-2: ERP entra na Fase 0. Escopo: AP nativo (contas a pagar + approval + PIX Inter), AR consolidado, conciliação bancária UI, vendor management, NFS-e, lançamentos manuais. Objetivo: desligar Conta Azul.
- [x] D-FIN-3: AUDITADO — 25 crons ativos, 73% saudáveis. Issues: (1) ads-insights-report fora do vercel.json; (2) lead-scoring/hubspot-sync sem advisory lock; (3) Meta token precisa System User Token; (4) sem health check agregado.
- [x] D-FIN-4: DIÁRIO: posição de caixa, recebimentos/pagamentos, compromissos vencidos/a vencer, 13-week cash projection. SEMANAL: DRE gerencial, MRR waterfall, unit economics.
- [x] D-FIN-5: Banco Inter E Itaú — ambos ativos na Fase 0. Dados: saldo, extrato, PIX in/out, TED, boletos.

DASHBOARD EXECUTIVO (Sprint 2)
- [x] D-EXEC-1: KPIs já definidos nos Figmas do projeto, por área com drill-down.
- [x] D-EXEC-2: Diário. Overnight aceitável, dados prontos às 8h.
- [x] D-EXEC-3: Apenas liderança, diariamente.

AI COCKPIT (Sprint 2-3)
- [x] D-COCK-1: 6 roles operacionais com 5 métricas cada. BDR/SDR: leads trabalhados, demos agendadas, taxa conversão lead→demo, tempo médio de resposta, meta vs realizado. Closer: deals abertos, pipeline value, win rate, ticket médio, forecast do mês. CS Manager: health score médio, clientes em risco (critical), NPS atual, churn rate, renovações pendentes. Finance: caixa D+0, MRR, inadimplência (% e R$), runway, desvio BP vs realizado. Marketing: CAC, leads por canal, conversão lead→MQL, budget gasto vs planejado, CPL. Executivo: MRR, churn rate, novos clientes, margem operacional, caixa.
- [x] D-COCK-2: Ranking por matriz Urgência × Impacto (Eisenhower). Score = urgência (1-5) × impacto (1-5). Top 5-7 itens no cockpit.
- [x] D-COCK-3: Chat com leitura de dados + escrita leve com confirmação. Toda ação de escrita pede confirmação antes de executar.
- [x] D-COCK-4: Role detection automático via hr.hrAreas + nível hierárquico. Área define métricas, nível define profundidade.

PULSES (Sprint 3)
- [x] D-PULSE-1: Template base + 1 pergunta específica por área.
- [x] D-PULSE-2: Template único: (1) Top 3 vitórias, (2) Top 3 riscos, (3) Pedidos de ajuda.
- [x] D-PULSE-3: Áudio habilitado na Fase 0. Whisper transcreve, IA extrai pontos-chave.
- [x] D-PULSE-4: Fase 0: todos preenchem. Visão futura: IA preenche automaticamente, humano valida.
- [x] D-PULSE-5: Incident pulse com triggers configuráveis por role.

WEEKLY REPORTS (Sprint 3)
- [x] D-WEEK-1: 7 seções: north star + KPIs, narrativa, riscos, oportunidades, decisões (3-7), plano semanal, retrospectiva.
- [x] D-WEEK-2: Report por área com 5 seções simplificadas. IA usa como input para executivo.
- [x] D-WEEK-3: Aprovação em 2 níveis: líder → área, VDC/Ju → executivo.
- [x] D-WEEK-4: Geração sexta 9h SP. Publicação sexta à tarde.

COMBINADOS (Sprint 3)
- [x] D-COMB-1: 3 tipos: Meta (KPI), Tarefa (entrega), Decisão (resposta + rationale).
- [x] D-COMB-2: Cobrança contextual pela IA. Crítico = diária. Menor = weekly. Blocker → renegociação.
- [x] D-COMB-3: Evidência: URL + texto livre. Pelo menos 1 obrigatório.

TASKS & PROJETOS (Sprint 3-4)
- [x] D-TASK-1: Kanban 5 colunas: Backlog → Sprint → Em Progresso → Review → Done.
- [x] D-TASK-2: Fluxo contínuo sem timeboxes. Score urgência × impacto.
- [x] D-TASK-3: Hierarquia: Gate → Epic → Task. Progresso = % epics concluídos.

CALENDAR (Sprint 4)
- [x] D-CAL-1: Reuniões do dia + contexto IA + disponibilidade do time. Google Calendar bidirecional.
- [x] D-CAL-2: Permissões por hierarquia (IC → própria, Líder → time, C-level → todos).
- [x] D-CAL-3: Fase 0: só leitura (Google Calendar read-only). Escrita Fase 1+.

PRODUTO / LIA
- [x] D-PROD-1: Apenas Design System e Feature Gates ativos. Demais dormant.
- [x] D-PROD-2: Dashboard de AI com custos + performance. Dados em ai_credits + ai_credits_ledger.
- [x] D-LIA-1: Custos consolidados no dashboard de AI. Integrado com GL "5.x AI Inference".
- [x] D-LIA-2: 3 status: Produção (Lia Global, Lia WhatsApp, Document Agent, Oitiva), Beta (CEO AI, Backstage Assistant, Maria Insights), Experimental (demais).
- [x] D-LIA-3: 4 guardrails: budget cap, rate limiting, content filtering, HITL obrigatório.

ARQUITETURA & INFRA (Sprint 1)
- [x] D-NORTH-1: MRR é a North Star metric. Topo do cockpit executivo.
- [x] D-KPI-GOV-1: Tabela kpi_definitions no banco. Single definition. VDC aprova. Versionamento.
- [x] D-NOTIF-1: Dual (Slack + in-app) na Fase 0. Migra gradualmente.
- [x] D-SMS-1: Posterga para Fase 1+.
- [x] D-CROSS-1: Modelo híbrido: (1) Críticos = event bus + fallback, (2) Integração = código + logging, (3) Configuráveis = workflow engine.

FINANCEIRO — COMPLEMENTOS (Sprint 1-2)
- [x] D-CA-MIG-1: Dual-write → validar → desligar. 30-60 dias comparação.
- [x] D-BANK-1: Inter + Itaú via API. Itaú = principal. Integração forte, zero interface de banco.
- [x] D-BANK-2: 3 níveis: R$10k C-level. Dual >R$50k.
- [x] D-CRON-1: Audit completo Sprint 1 + fix ou kill. JP faz inventário.

GATES & VALIDAÇÃO (Sprint 1)
- [x] D-GATE-1: PO da área valida + VDC confirma cross-cutting. Checklist de aceite em produção.
- [x] D-ROLLBACK-1: Dual-read 30 dias + credenciais ativas 60 dias. Reverte <1h se divergir.
- [x] D-AUTH-1: Por exposição de dados sensíveis. Zero rotas sensíveis sem auth Sprint 1.

MANAGEMENT OS — COMPLEMENTOS (Sprint 2-3)
- [x] D-COMB-SCHEMA-1: Schema rico com relações. Tabela commitments com FKs para kpi_definitions e tasks.
- [x] D-ALERT-THRESH-1: Infraestrutura primeiro, thresholds com dados reais (2 semanas).
- [x] D-EXEC-ROLE-1: Por nível hierárquico no HR. C-level/Diretor vê cockpit executivo completo.

Alex — 21 perguntas

CRM (Sprint 2-3) — GATE MAIS CRÍTICO
- [ ] D-CRM-1: Dados históricos HubSpot — migrar todos ou só últimos 12 meses?
- [ ] D-CRM-2: Quais campos do HubSpot NÃO existem no v2_sales? Listar gaps
- [ ] D-CRM-3: Provider onboarding: como funciona sem HubSpot? Fluxo step-by-step
- [ ] D-CRM-4: Sequences: quais templates de cadência o time de vendas usa hoje?
- [ ] D-CRM-5: Golden Record: regras de merge estão corretas? Conflitos?
- [ ] D-CRM-6: Quais métricas CRM são consultadas diariamente? (com Didico)

VENDAS (Sprint 3)
- [ ] D-VEND-1: Quais analytics são realmente usados pelo time vs ignorados?
- [ ] D-VEND-2: Commission forecast: modelo BDR 1% + Closer 5% está correto?
- [ ] D-VEND-3: Outbound: qual o fluxo ideal de prospecção? Canais usados? (com Didico)
- [ ] D-VEND-4: ClickSign: contratos fluem corretamente em produção?
- [ ] D-VEND-5: Tactical planning: é usado pelo time? Se não, remover?

AQUISIÇÃO (Sprint 3)
- [ ] D-ACQ-1: Lead Hunter: é usado ativamente? Por quem?
- [ ] D-ACQ-2: KPIs diários: quais métricas o time consulta?
- [ ] D-ACQ-3: Lead scoring: quais regras definem um lead qualificado?
- [ ] D-ACQ-4: Quais canais de aquisição são prioritários? (com Didico)

MARKETING (Sprint 4)
- [ ] D-MKT-1: Time de marketing usa o Backstage para quê?
- [ ] D-MKT-2: Quais ferramentas de marketing são usadas fora do Backstage?
- [ ] D-MKT-3: Pipeline de conteúdo: Fase 0 ou depois?

DECISÕES ADICIONAIS (identificadas 13/mar)
- [ ] D-ALEX-API-1: CRM Package API design — como outras áreas consomem o CRM? Import direto do package ou API REST?
- [ ] D-ALEX-ATTR-1: Lead attribution model — first-touch, last-touch ou multi-touch?
- [ ] D-ALEX-DASH-1: Dashboard executivo — quais métricas Ju quer ver? Validar além dos Figmas
- [ ] D-ALEX-PIPE-1: Pipeline de investidores — design de pipelines configuráveis suporta extensão?
- [ ] D-ALEX-OIT-1: Oitiva — como integrar métricas de qualidade de ligação no ranking do vendedor?

Carol — 7 perguntas

CUSTOMER SUCCESS (Sprint 3)
- [ ] D-CS-1: Health score — os 5 componentes e pesos estão corretos? Validar cada um
- [ ] D-CS-2: Quais playbooks são CRÍTICOS para Fase 0? Descrever step-by-step
- [ ] D-CS-3: Retention offers — quais tipos usar? (desconto %, meses grátis, upgrade?)
- [ ] D-CS-4: Quais clientes são prioritários para onboarding vs self-service?

SUPORTE (Sprint 3)
- [ ] D-SUP-1: Inbox é o canal principal de atendimento? Funciona bem?
- [ ] D-SUP-2: Chatbot está em produção? Com quais regras?
- [ ] D-SUP-3: Knowledge Base está atualizada? Quem mantém? (com Giovanna)

JP — 16 perguntas

WHATSAPP (Sprint 3)
- [ ] D-WPP-1: WhatsApp é usado para quais fluxos? (vendas? suporte? onboarding?)
- [ ] D-WPP-2: Evolution API vs Cloud API: qual o padrão? Manter os dois?
- [ ] D-WPP-3: Templates: quais são necessários? Quem define conteúdo?
- [ ] D-WPP-4: Automação de mensagens: entra na Fase 0?

AUTOMAÇÕES (Sprint 4)
- [ ] D-AUTO-1: Quais automações rodam FORA do Backstage hoje? (Zapier, Make, scripts?)
- [ ] D-AUTO-2: Quais são CRÍTICAS? (sem elas, o que para?)
- [ ] D-AUTO-3: Workflow builder visual: necessário para Fase 0 ou basta config?
- [ ] D-AUTO-4: Lead scoring: quais regras? (quem define o modelo?)

OITIVA (Sprint 2)
- [ ] D-OIT-1: Oitiva é usado ativamente? Por quem?
- [ ] D-OIT-2: Scorecards: critérios atualizados?

CHAT (Sprint 3)
- [ ] D-CHAT-1: Chat interno é usado? Por alguém?
- [ ] D-CHAT-2: Slack import: migrar histórico completo ou começar do zero?
- [ ] D-CHAT-3: Quais canais criar? (por área? por projeto? por gate?)

DECISÕES ADICIONAIS (identificadas 13/mar)
- [ ] D-JP-N8N-1: n8n workflows — migrar para Backstage ou manter n8n como infra? Impacta G4
- [ ] D-JP-EDGE-1: 58 edge functions Deno no Supabase — inventariar críticas, impacto em gates
- [ ] D-JP-WPP-NUM-1: WhatsApp — 1 número ou múltiplos? Impacta routing e inbox
- [ ] D-JP-RESEND-1: Resend webhooks — tracking opens/clicks/replies funciona ou precisa implementar?

Clariny — 9 perguntas

FINANCEIRO (Sprint 2)
- [ ] D-FIN-C1: Recebimentos — quais dados devem aparecer? (Iugu, Stripe, manual?)
- [ ] D-FIN-C2: Estruturas organizacionais — qual o escopo mínimo de CRUD?

PESSOAS/RH (Sprint 4)
- [ ] D-RH-1: Quais funções de RH são usadas hoje?
- [ ] D-RH-2: Payroll integrado com sistema externo?
- [ ] D-RH-3: Performance/PDI: ativo ou parado?
- [ ] D-RH-4: hr-core e hr-sdk consumidos por outras áreas?

WIKI (Sprint 2)
- [ ] D-WIKI-1: Wiki é usada? Por quem?
- [ ] D-WIKI-2: Notion import: migrar todo conteúdo ou selecionar?
- [ ] D-WIKI-3: Quais spaces/categorias criar?

DECISÕES ADICIONAIS (identificadas 13/mar)
- [ ] D-CLAR-TODOIST-1: Todoist — migrar para Tasks do Backstage ou manter + integrar via API?
- [ ] D-CLAR-RH-COCK-1: RH como pré-requisito do cockpit — qual MVP mínimo de dados HR para cockpit funcionar?

Duda — 8 perguntas

PRESTADORES
- [ ] D-PREST-1: Quais funcionalidades de Prestadores são usadas no dia a dia?
- [ ] D-PREST-2: Ranking: como é calculado? Válido?
- [ ] D-PREST-3: Maria AI: insights são úteis? Consome CRM para dados de provider?

DESIGN SYSTEM (Sprint 1)
- [ ] D-DS-1: Componentes faltantes que bloqueiam alguma miniapp?
- [ ] D-DS-2: Tokens sincronizados com Figma?

DECISÕES ADICIONAIS (identificadas 13/mar)
- [ ] D-DUDA-JUR-1: Jurídico — escopo real na Fase 0: visualização ou workflow de aprovação + Clicksign + minutas?
- [ ] D-DUDA-FIGMA-1: Figma tokens sync — mecanismo de sync Figma → código?
- [ ] D-DUDA-PROV-ONBOARD-1: Prestadores onboarding — fluxo completo de cadastro? Integrações acionadas?

Giovanna — 5 perguntas

CUSTOMER SUCCESS
- [ ] D-CS-G1: Timeline CS: quais informações são ESSENCIAIS vs nice-to-have?
- [ ] D-CS-G2: NPS: frequência de envio? Quem responde? Ações por resultado?

DECISÕES ADICIONAIS (identificadas 13/mar)
- [ ] D-GIO-ONBOARD-1: Onboarding playbook — quais tarefas/milestones? O que automatizar vs manual?
- [ ] D-GIO-CHURN-1: Churn prediction — quando health score cai, quais ações o sistema dispara?
- [ ] D-GIO-ALERTS-1: CS alerts — de onde vêm hoje? Estado de migração para Backstage?

---

5.3 Forma de trabalho

Como o time opera. Rituais, cadências, workflow de desenvolvimento e timeline.
Fica junto do tracker para que decisões e forma de trabalho estejam no mesmo lugar.

Rituais e Comunicação

"Toda reunião exige preparação prévia. Sem preparação, sem reunião."

Ritual	Cadência	Quando	O que acontece
Planning	Semanal	Segunda	VDC define prioridades, distribui tasks. Cada um revisa reports e traz 3 prioridades sugeridas.
Report Estruturado	Diário	Fim do dia	Cada pessoa documenta: o que fez, o que travou, próximos passos. Sem report = dia não contou.
Sync Backstage × Migração	Semanal	Quinta, 13:30	Reunião com Migração (Gab, Humberto, Rik). Status, blockers cruzados, decisões.
Demo para Stakeholders	Bi-weekly	Sexta	Didico e Carol veem progresso real em produção. Demo script com fluxos funcionais.

Workflow de Desenvolvimento

Discovery (AI) → mini-PRD (AI + PO aprova) → Dev (AI-assisted) → Review (AI) → PO Testa (em prod) → Merge

Semana 0 — Investigação & Esboço (11–16 mar)

Cada pessoa investiga suas áreas, navega o Backstage, lê código, conversa com stakeholders, e traz esboço de discovery + gaps + decisões.

Pessoa	Áreas para investigar	Entregável até 16/mar
VDC	Financeiro, Auth, Data Architecture, GL, Business Plan	Esboço do PRD Financeiro. Decisões sobre Google Sheets, ERP, auth strategy.
Alex	CRM, Vendas, Aquisição, Marketing, Outbound	Discovery de CRM/Vendas: o que funciona vs stub. Mini-PRD de Taxonomia.
JP	Automações, Workflows, n8n, Integrações, Mensageria	Mapeamento de workflows n8n. Lista de automações críticas. Estado de integrações.
Duda	Jurídico, Prestadores, Design System	Discovery de Jurídico e Prestadores. Inventário de Design System tokens.
Giovanna	CS, Health Score, Retenção, NPS, Suporte	Discovery de CS: testar health score, playbooks, renovações. Conversar com Carol.
Clariny	Financeiro (com VDC), RH, Organização geral	Par do VDC na discovery financeira. Revisar módulo RH. Organizar documentação.

Como investigar: (1) Navegar TODAS as páginas da sua área em produção. (2) Anotar: dados reais vs vazio/erro/placeholder. (3) Testar fluxos e2e. (4) Ler código: APIs reais vs mock. (5) Conversar com quem USA a área. (6) Produzir 1 documento por área: Estado Atual, Gaps, Decisões Pendentes.

Timeline — Semana 0 + 4 Sprints

Período	Datas	Tema	Foco	Responsáveis
Semana 0	11–16 mar	Investigação & Esboço	Discovery de cada área, esboço do PRD	Todos
Sprint 1	17–28 mar	Fundação & Estabilização	Auditorias, Mapeamento, G3 início	VDC (foundation) / todos (discovery)
Sprint 2	31 mar – 11 abr	Fechar G1, G5, G6	G1 fechar, G5 fechar, G6 fechar	VDC (G1) / Alex (G5) / JP (G6)
Sprint 3	14–25 abr	Fechar G2, G3, G7	G2 fechar, G3 fechar, G7 fechar	Alex (G3) / Giovanna (G2) / JP (G7)
Sprint 4	28–30 abr	G4 + Polish + Validação	G4 fechar, Polish, PO Validação	Time completo

Sprint 1 — Auditoria completa de cada módulo. Auth & Taxonomia base. Decisões críticas (HubSpot, ferramentas). Mini-PRDs para CS, Jurídico, Prestadores.

Sprint 2 — Financeiro funcional ponta a ponta. Dashboard executivo com dados reais. Integrações monitoradas e estáveis. Business Plan editável na UI.

Sprint 3 — CS com health score e alertas. CRM unificado (matar HubSpot). Mensageria consolidada. Customer 360 com dados reais.

Sprint 4 — Automações internas operando. Testes e2e em todos os gates. PO valida cada gate em produção. Management OS v1 operando.

---

5.4 Métricas de sucesso

Fase 0 (quantitativas)

• [ ] 7/7 gates fechados e aprovados por VDC + Ju
• [ ] Zero dependência de CRM externo como fonte de verdade
• [ ] 100% dos dados de clientes consultáveis no Backstage
• [ ] Health score calculado para 100% dos clientes ativos
• [ ] Dashboard executivo operando (aprovado pela liderança)
• [ ] HubSpot sync desligado
• [ ] Zero falhas críticas de integração em 7 dias
• [ ] 3 playbooks CS operando
• [ ] Todos os módulos "FUNCIONAL" validados em produção (D20)
• [ ] Ciclo de vida completo do cliente rastreável

Norte pós-Fase 0 (qualitativas)

• Cadências automáticas (email + WhatsApp + ligação) operando
• Sistema omni-channel funcional com timeline unificada
• IA para coaching de SDRs/Closers com comparativo humano vs IA
• Pipeline de conteúdo marketing com IA
• Health score inteligente com tratativa automatizada
• Cohortização transversal de qualquer métrica
• Flywheel operacional rodando
• LIA integrada à plataforma
• Contabilidade 100% nativa (Conta Azul desligado)
• Comunicação interna 100% no Backstage (Slack desligado)

---

APÊNDICES

Apêndice A: Macro-áreas sem gate (backlog)

Estas macro-áreas NÃO têm gate na Fase 0. Ficam como backlog documentado.
Porções relevantes já foram absorvidas pelos gates (ex: Prestadores parcialmente em G3).

MA-MGMT: Management OS (Gestão, Reports, AI Cockpit)

Macro-área mais estratégica do Backstage. Não é módulo — é sistema operacional da gestão. Transversal como o CRM package.

Escopo: AI Cockpit por role, CEO AI, Pulses (qualitativo diário/semanal), Weekly Reports automáticos, Combinados rastreáveis, Knowledge Schema, Gestão de Conhecimento (substituir Notion), Gestão de Tarefas (substituir Todoist/Trello), Gestão de Projetos, Agenda (Google Calendar bidirecional).

Visão: "A IA não é um relatório: ela é o sistema operacional da gestão."

Problema que resolve: Dashboards soltos sem ação. Rituais manuais sem evidência. Decisões que não viram execução. Falta de contexto qualitativo.

Objetivos: (1) Ritmo automático com mínimo esforço. (2) Single Source of Truth de KPIs. (3) Execução guiada por IA. (4) Captura de contexto do "chão". (5) Personalização por função.

Métricas de sucesso: WAU > 80%, taxa conclusão pulses > 70%, insights → ações > 50%, NPS interno > 40.

Cockpit por role:
- Vendas: Pipeline, forecast, deals em risco, top 5 contas
- Marketing: Budget, CAC, leads, conversão por canal
- CS: Health score, churn risk, NPS, tickets, onboarding
- Financeiro: Caixa D+0, runway, inadimplência, MRR/ARR
- Executivo: North Star + KPIs vitais + top riscos

Componentes: (1) AI Cockpit (home personalizada) (2) Dashboards "vivos" (3) Pulses (daily/weekly/incident) (4) Weekly Reports automáticos (5) Combinados + evidências (6) Gestão de Conhecimento (wiki) (7) Gestão de Tarefas (8) Gestão de Projetos (9) Google Calendar bidirecional

CEO AI — Funções: Sensemaking, Prioritização, Orquestração, Cobrança, Documentação
CEO AI — Modos: Autopilot (sugere, humano aprova), Copilot (humano pede, IA executa), Ops Mode (anomalia → playbook)

Knowledge Schema: kpi_definitions, kpi_values, knowledge_events, knowledge_pulses, knowledge_decisions, knowledge_outcomes, management_actions

Fundação de dados existente:
- Pulses: 5 tabelas → Nível 1
- OKRs/Strategy: 6 tabelas → Nível 3
- Meetings: 4 tabelas → Nível 1
- Chat: 12 tabelas → Nível 3
- Wiki: 14 tabelas → Nível 3-4
- Workspace Workflows: 7 tabelas → Nível 1-2
- AI Analysis: 10+ tabelas → Nível 1-2

O que funciona: Mastra AI agents, Dashboard hub, Wiki, Chat interno
O que não existe: Combinados (Nível 0), Tasks/projetos funcional (Nível 1)

Escopo Fase 0 MVP: AI Cockpit 4 roles, Daily/Weekly Pulse com templates, Weekly Report automático, Combinados CRUD, Alertas em 5 KPIs vitais, Chat IA com ferramentas, Wiki com conteúdo do Notion, Tasks CRUD + kanban, Projetos mínimo

Riscos: IA alucinando narrativa, fadiga de pulse, dados inconsistentes entre áreas, adoção baixa

Discovery (VDC) — todas respondidas ✓:
- [x] D-COCK-1: 6 roles operacionais com 5 métricas cada. BDR/SDR: leads trabalhados, demos agendadas, taxa conversão lead→demo, tempo médio de resposta, meta vs realizado. Closer: deals abertos, pipeline value, win rate, ticket médio, forecast do mês. CS Manager: health score médio, clientes em risco (critical), NPS atual, churn rate, renovações pendentes. Finance: caixa D+0, MRR, inadimplência (% e R$), runway, desvio BP vs realizado. Marketing: CAC, leads por canal, conversão lead→MQL, budget gasto vs planejado, CPL. Executivo: MRR, churn rate, novos clientes, margem operacional, caixa.
- [x] D-COCK-2: Ranking por matriz Urgência × Impacto (Eisenhower). Score = urgência (1-5) × impacto (1-5). Urgência baseada em deadline e SLA. Impacto baseado em valor monetário (deal size, MRR em risco, valor da cobrança). Top 5-7 itens aparecem no cockpit. Simples e auditável.
- [x] D-COCK-3: Chat com leitura de dados + escrita leve com confirmação. Leitura: consultar KPIs, dados CRM, health scores, pipeline, financeiro. Gerar emails, resumos, checklists, planos. Escrita leve (com confirmação): criar tarefa, criar combinado, agendar follow-up, atualizar status de deal, enviar email draft. Toda ação de escrita pede confirmação antes de executar.
- [x] D-COCK-4: Role detection automático via hr.hrAreas (área: CS, Vendas, Marketing, Finance, Produto) + nível hierárquico (IC, Líder, C-level derivado de hr.hrColaboradores). Área define quais métricas, nível define profundidade. Sem tabela nova — usa dados HR existentes.
- [x] D-PULSE-1: Template base para todos: (1) "O que você vai focar hoje?" (2) "Algum blocker?" + 1 pergunta específica por área: Vendas: "Deals que você vai mover hoje?" / CS: "Algum cliente em risco que precisa de atenção?" / Finance: "Alguma cobrança ou pagamento crítico?" / Marketing: "Alguma campanha que precisa de ajuste?"
- [x] D-PULSE-2: Template único para todos: (1) Top 3 vitórias da semana, (2) Top 3 riscos/problemas, (3) Pedidos de ajuda ou decisões pendentes. Texto livre em cada bloco.
- [x] D-PULSE-3: Áudio habilitado na Fase 0. Usuário pode gravar áudio de 30-60s, Whisper transcreve automaticamente, IA extrai pontos-chave. Texto também aceito.
- [x] D-PULSE-4: Fase 0: todos (ICs + líderes) preenchem daily pulse. Visão futura (Fase 1+): cada pessoa terá uma IA pessoal que preenche o pulse automaticamente com base nas atividades do dia, pedindo apenas validação humana.
- [x] D-PULSE-5: Incident pulse com triggers configuráveis por role. Admin define defaults (ex: MRR caiu >5%, health score critical, integração fora do ar >1h). Cada área pode customizar thresholds.
- [x] D-WEEK-1: Weekly report executivo com 7 seções: (1) North star + KPIs vitais, (2) Narrativa da semana (IA + pulses), (3) Riscos priorizados, (4) Oportunidades, (5) Decisões sugeridas (3-7), (6) Plano semanal com owners, (7) Retrospectiva (planejado vs realizado).
- [x] D-WEEK-2: Report por área com 5 seções: (1) KPIs da área, (2) Vitórias + entregas, (3) Riscos + blockers, (4) Ações da próxima semana, (5) Pedidos para outras áreas. IA usa esses como input para o executivo.
- [x] D-WEEK-3: Workflow de aprovação em 2 níveis. (1) IA gera por área → líder revisa. (2) IA consolida executivo → VDC/Ju revisa e publica.
- [x] D-WEEK-4: Geração sexta 9h SP. Líderes revisam sexta manhã. Executivo publicado sexta à tarde.
- [x] D-COMB-1: 3 tipos: Meta (vinculado a KPI), Tarefa (entrega concreta), Decisão (precisa de resposta + rationale).
- [x] D-COMB-2: Cobrança contextual pela IA. Crítico = cobrança diária. Menor = só weekly. Se blocker reportado no pulse, sugere renegociação. Default: D-1 lembrete + D+0 notifica líder.
- [x] D-COMB-3: Evidência: URL + texto livre. Pelo menos 1 obrigatório. IA valida se link é acessível.
- [x] D-TASK-1: Board kanban 5 colunas: Backlog → Sprint → Em Progresso → Review → Done. Cada card: gate, responsável, critério de aceite, dependências, sprint alvo.
- [x] D-TASK-2: Fluxo contínuo sem timeboxes. Tasks priorizadas por score (urgência × impacto). Cada pessoa puxa a próxima ao terminar. Weekly report acompanha throughput.
- [x] D-TASK-3: Hierarquia: Gate (G1-G7, MA-MGMT) → Epic → Task. Progresso por gate = % de epics concluídos.
- [x] D-CAL-1: Cockpit: (1) reuniões do dia + contexto IA, (2) disponibilidade do time. Integração bidirecional com Google Calendar.
- [x] D-CAL-2: Permissões por hierarquia. IC: própria agenda. Líder: time. C-level: todos. Reuniões privadas ocultáveis.
- [x] D-CAL-3: Fase 0: só leitura (sync Google Calendar read-only). Escrita bidirecional Fase 1+.

Decisões adicionais VDC (identificadas 13/mar) — todas respondidas ✓:
- [x] D-NORTH-1: MRR é a North Star metric da Freelaw. Topo do cockpit executivo e ponto de partida do weekly report.
- [x] D-KPI-GOV-1: Tabela kpi_definitions no banco. Cada KPI: nome, fórmula, fonte, cadência, owner, target. VDC aprova. Versionamento se fórmula muda.
- [x] D-NOTIF-1: Dual (Slack + in-app) na Fase 0. Migra gradualmente. Corta Slack só quando in-app confirmado.
- [x] D-SMS-1: Posterga para Fase 1+. WhatsApp + Email cobrem os casos de uso.
- [x] D-CROSS-1: Modelo híbrido por criticidade: (1) Críticos = event bus + check + fallback, (2) Integração = código + logging, (3) Configuráveis = workflow engine.
- [x] D-CA-MIG-1: Dual-write → validar → desligar. 30-60 dias de comparação. 100% paridade = desliga Conta Azul.
- [x] D-BANK-1: Inter + Itaú via API. Itaú = principal daqui pra frente. Integração forte: saldo, extrato, pagamento, transferência. Zero interface de banco.
- [x] D-BANK-2: 3 níveis: R$10k C-level. Dual approval >R$50k. Audit log completo.
- [x] D-CRON-1: Audit completo Sprint 1 + fix ou kill. JP faz inventário. Nenhum cron em estado desconhecido.
- [x] D-GATE-1: PO da área valida + VDC confirma cross-cutting. Checklist de aceite testado em produção obrigatório.
- [x] D-ROLLBACK-1: Dual-read 30 dias + credenciais ativas 60 dias. Reverte em <1h se divergir.
- [x] D-AUTH-1: Por exposição de dados sensíveis. Meta: zero rotas sensíveis sem auth no Sprint 1.
- [x] D-COMB-SCHEMA-1: Schema rico: tabela commitments com FKs para kpi_definitions e tasks. 1→N evidências, 1→1 KPI, 1→N follow-ups.
- [x] D-ALERT-THRESH-1: Infraestrutura primeiro, thresholds com dados reais (2 semanas). VDC calibra.
- [x] D-EXEC-ROLE-1: Por nível hierárquico no HR. C-level/Diretor vê cockpit executivo completo. Escala automaticamente.

Discovery pendente do time (Management OS):
- [ ] D-CLAR-TODOIST-1: Todoist — migrar para Tasks do Backstage ou manter + integrar via API?
- [ ] D-CLAR-RH-COCK-1: RH como pré-requisito do cockpit — qual MVP mínimo de dados HR para o cockpit funcionar?

---

MA9: RH & Produtividade

Escopo: Gestão de pessoas, org chart, dashboards de produtividade dev, performance. Migração gestao.freelaw.ai.

Módulos: /rh/* (18 páginas)

Estado: 18 páginas parciais, org chart parcial, user_profiles funcional, gestao.freelaw.ai = mesmo deploy.

Escopo Fase 0:
- [ ] Inventário gestao.freelaw.ai
- [ ] Plano de migração (D18)
- [ ] Org chart funcional
- [ ] Dashboard produtividade dev (GitHub API)
- [ ] Goals CRUD + tracking

Discovery (Clariny):
- [ ] D-RH-1: Quais funções de RH são usadas hoje?
- [ ] D-RH-2: Payroll integrado com sistema externo?
- [ ] D-RH-3: Performance/PDI: ativo ou parado?
- [ ] D-RH-4: hr-core e hr-sdk consumidos por outras áreas?

---

MA10: Marketing

Escopo: Campanhas ads, analytics, email marketing, newsletters, landing pages, CAPI.

Módulos: /marketing/* (4 páginas)

Estado: Meta/Google Ads + CAPI funcional. Schema extenso mas UI mínima (4 páginas).

Escopo Fase 0:
- [ ] Dashboard marketing: investimento, leads, CPL, CAC por canal
- [ ] CAPI: validar eventos de conversão
- [ ] UTM tracking funcional no CRM
- [ ] Email marketing: campanha simples
- [ ] Newsletter: subscriber management + envio

Discovery (Alex):
- [ ] D-MKT-1: Time de marketing usa o Backstage para quê?
- [ ] D-MKT-2: Quais ferramentas fora do Backstage?
- [ ] D-MKT-3: Pipeline de conteúdo: Fase 0 ou depois?

---

MA11: Prestadores & Comunidade

Escopo: Gestão de prestadores jurídicos, funnel, tiers, ranking, saturação. Consome CRM package.

Módulos: /prestadores/* (12 páginas)

Estado: Provider funnel, tiers, journey, saturação → FUNCIONAL. Onboarding depende HubSpot (vinculado ao G3).

Escopo Fase 0:
- [ ] Onboarding 100% no Backstage (zero HubSpot)
- [ ] Pipeline via CRM package
- [ ] Funnel com métricas
- [ ] Saturação: dashboard por região + especialidade
- [ ] Ranking com inputs reais
- [ ] Pagamento integrado com Financeiro → GL

Discovery (Duda):
- [ ] D-PREST-1: Quais funcionalidades são usadas no dia a dia?
- [ ] D-PREST-2: Ranking: como é calculado? Válido?
- [ ] D-PREST-3: Maria AI: insights são úteis?
- [ ] D-DUDA-JUR-1: Jurídico — escopo real na Fase 0: visualização de contratos/documentos ou workflow de aprovação, assinatura (Clicksign), geração de minutas?
- [ ] D-DUDA-PROV-ONBOARD-1: Prestadores onboarding — qual o fluxo completo de cadastro de novo prestador? Quais integrações acionadas?

---

MA12: Produto & Plataforma

Escopo: Design system, wiki, audit logs, feature flags, AI agents, chatbots.

Módulos: /produto/* (112 páginas), /wiki

Estado: Funcional e mantido. Nenhum bloqueio crítico.

Design System (alta prioridade transversal):
- Design Tokens, Component Library, Patterns, Designer's Bible
- TODAS as MAs devem usar (não é opcional)
- Decisão D19: escopo Fase 0, candidato a G8

Escopo Fase 0:
- [ ] Tokens documentados e implementados
- [ ] Componentes core com variants
- [ ] Designer's Bible v1 (D19)
- [ ] Wiki: migração Notion
- [ ] Audit logs: query funcional
- [ ] AI Agents: documentação

Discovery (Duda):
- [ ] D-DS-1: Componentes faltantes que bloqueiam alguma miniapp?
- [ ] D-DS-2: Tokens sincronizados com Figma?
- [ ] D-DUDA-FIGMA-1: Figma tokens sync — mecanismo de sync Figma → código? (manual, Figma Tokens plugin, Style Dictionary, Tailwind config?)

---

MA13: IA & Produção (LIA)

Escopo: IA centralizada — LIA (peças jurídicas para clientes), agents internos (Mastra), Oitiva, infraestrutura compartilhada.

Estado: 4 agents internos funcionais, AI credits + ledger, Oitiva em dev.

Questão arquitetural (D16): Compartilhar infraestrutura (eficiência) vs separar (isolamento).

Escopo Fase 0:
- [ ] Decisão D16
- [ ] Oitiva funcional com scorecards reais
- [ ] AI Agents documentados
- [ ] AI Credits rastreáveis
- [ ] PoC LIA: 1 tipo de peça jurídica
- [ ] Definição de stack (modelos, hosting, rate limiting)

Discovery (VDC/Alex):
- [x] D-PROD-1: Apenas Design System (tokens, componentes, docs) e Feature Gates (feature flags) são usados ativamente. Demais sub-módulos dormant. Não investir na Fase 0.
- [x] D-PROD-2: Dashboard de AI com custos + performance. Custos por provider e agent. Performance: latência, taxa de sucesso, tokens. Dados em ai_credits + ai_credits_ledger.
- [x] D-LIA-1: Custos consolidados no dashboard de AI (D-PROD-2). Break-down por provider + agent + tendência mensal. Integrado com GL como despesa "5.x AI Inference".
- [x] D-LIA-2: 3 status: Produção (Lia Global, Lia WhatsApp, Document Agent, Oitiva), Beta (CEO AI, Backstage Assistant, Maria Insights), Experimental (research, writing, review, demais).
- [x] D-LIA-3: 4 guardrails: (1) Budget cap mensal por provider (alerta 80%, hard stop 100%), (2) Rate limiting por agent, (3) Content filtering (PII), (4) HITL obrigatório em ações críticas.

---

Clariny — Discovery Wiki

• [ ] D-WIKI-1: Wiki é usada? Por quem?
• [ ] D-WIKI-2: Notion import: migrar todo conteúdo ou selecionar?
• [ ] D-WIKI-3: Quais spaces/categorias criar?

---

Apêndice B: Visão pós-Fase 0 (Ju)

Nenhum item desta seção entra no escopo atual. São pré-requisitos futuros que a Fase 0 deve habilitar.

Dados unificados com cohortização

Qualquer métrica segmentável por cohort (mês de aquisição), plano, ICP, canal. A Fase 0 habilita via Customer 360 (G2) + dashboard (G5) + CRM nativo (G3).

Cadências automáticas omni-channel

Sequences multi-canal (email + WhatsApp + ligação) com motor de execução completo e tracking unificado.

IA por área

Coaching de vendas via Oitiva, atendimento inteligente via chatbot, insights financeiros via CEO AI, recomendações de CS via health score.

Flywheel operacional

Lead → cliente → sucesso → referral → mais leads. Cada etapa alimenta a próxima com dados e automação.

Apêndice C: Migração Vercel → Hetzner

Todos os cron jobs e execution engines atualmente no Vercel serão migrados para servidores Hetzner por custos.

Escopo: 25+ crons Backstage, 30+ crons Studio, automation-service, voice-bot-service.

Requisitos: Zero downtime, monitoramento pós-migração, rollback plan, Vercel apenas para frontends (Next.js SSR/SSG).

Apêndice D: Gaps Estruturais (identificados 13/mar)

Pontos que o PRD menciona ou pressupõe mas não detalha ainda.
Cada gap precisa de decisão ou seção dedicada antes de virar código.

#	Gap	Impacto	Próximo passo
GAP-1	Permissões (RLS) por miniapp — sem matriz de permissões (quem vê o quê por role/área)	Bloqueante para cockpit e reports	VDC define matriz role × miniapp × ação
GAP-2	Golden Record unificado — CRM é "OS" mas sem schema canônico (Company, Contact, Deal, Subscription)	Alto — cada MA modela diferente	Alex documenta schema canônico
GAP-3	Contrato de dados Backstage ↔ Studio — sem contrato de quais dados, frequência de sync, ownership	Bloqueante para CS, Prestadores, Financeiro	VDC + Juju definem contrato
GAP-4	Estratégia de notificações — sem estratégia unificada (canais × tipo × urgência) nem anti-spam	Médio — risco de fadiga	VDC decide canais × tipo × urgência
GAP-5	Política de dados sensíveis — LGPD exige política de acesso, retenção e consentimento	Compliance	VDC define com jurídico
GAP-6	Definition of Done por gate — sem checklist de testes em produção para cada critério de aceite	Risco de "gate fechado" sem validação	VDC cria checklist por gate

---

Apêndice E: Changelog

Data	Versão	Alteração	Autor
2026-03-09	v1	Documento criado	Guilherme + Claude
2026-03-09	v2	Atualizado com mapeamento real do código	Guilherme + Claude
2026-03-09	v3	Reescrita: personas, user stories, arquitetura profunda	Guilherme + Claude
2026-03-09	v4	Macro-áreas com ownership, gates orientados	Guilherme + Claude
2026-03-09	v5	CRM como OS, conexões cross-área	Guilherme + Claude
2026-03-09	v6	Rewrite + auditoria de código, internalização, MA13 LIA, GL real	VDC + Claude
2026-03-09	v7	Management OS completo (AI Cockpit, CEO AI, Pulses, Weekly Reports, Combinados)	Guilherme + Claude
2026-03-11	v8	Alinhamento com Kickoff Fase 0: Dupla Core + 4 Domínios, Semana 0, Timeline	Guilherme + Claude
2026-03-11	v8.1	Gestão Interna + Framework SaaS	Guilherme + Claude
2026-03-12	v9	Investigação completa do monorepo: 400+ tabelas, 18+ agents, 60+ tools, princípio Inteligência Híbrida	VDC + Claude
2026-03-12	v9.1	Documentação como infraestrutura: cron horário, métricas auto-atualizadas, Golden Rule	VDC + Claude
2026-03-13	v10	Reorganização estrutural completa: 5 Partes (Fundamentos, Organização, Gates, Técnica, Tracking). Gates absorvem MAs. Discovery questions dentro dos gates. Eliminação de duplicações. Template padronizado por gate. Navegação rápida + mapa por pessoa. MAs sem gate → apêndice.	VDC + Claude
2026-03-13	v10.1	50 decisões VDC respondidas (D-COCK-1→D-CAL-3, D-PROD-1→D-LIA-3, D-NORTH-1→D-EXEC-ROLE-1). Novas decisões para time (+3 Giovanna, +3 Duda, +2 Clariny). 6 gaps estruturais documentados. Portadas da v9.1.	VDC + Claude
2026-03-15	v11	Benchmark Campfire.ai: Novos princípios (IA permeia + real-time). G1: close management (period lock, checklist, dunning automation, AR aging, AP nativo, vendor UI, audit UI). G4: arquitetura Continuous + On-Demand agents, confidence thresholds, 10 billing crons. G5: flux analysis AI, drill-down universal, source attribution. Seção 4.2: schemas close_periods + close_checklist_items. Seção 4.3: 13 tools financeiros CEO IA. Ref: campfire-benchmark-freelaw-one.md.	VDC + Claude

BACKSTAGE FREELAW — PLANO DE TRABALHO

Documento operacional do time de Backstage.
Cada pessoa sabe exatamente o que fazer, quando, e o que bloqueia.
Atualizado a cada sprint planning (segunda-feira).

Versão: 5.1 | Data: 2026-03-15
Líder: Guilherme | Owner: Guilherme (VDC), Diretor Financeiro
Líder Studio: Ju R (Ju Resende)
Liderança envolvida: Carol (Gerente CS), Didico (Gerente Aquisição)
Time: Alex, JP, Duda, Giovanna, Clariny + AI como 7º membro
Prazo hard: 30 de Abril de 2026

---

Modelo Operacional: Dupla Core + 4 Domínios + AI Pipeline

Dupla Core: VDC + Clariny → Liderança, Finance & Data
- VDC (Guilherme): Senior Finance, Good Tech/Dev. Líder do projeto.
- Clariny: Junior, do financeiro. Par do VDC. Implementa com AI.

Domínio 1: JP → Workflows & Automações (n8n, Automações, Mensageria, Integrações)
Domínio 2: Duda → Operations (Jurídico, Prestadores, Design System)
Domínio 3: Giovanna → CS (Customer Success, Health Score, Retenção)
Domínio 4: Alex → CRM & Revenue (CRM OS, Aquisição, Marketing, Vendas)

Workflow AI-First:

Discovery (AI) → mini-PRD (AI + PO aprova) → Dev (AI-assisted) → Review (AI) → PO testa em prod → merge

Rituais:

Ritual	Cadência	Quando	O que acontece
Planning	Semanal	Segunda	VDC define prioridades, distribui tasks. Cada um revisa reports e traz 3 prioridades sugeridas.
Report Estruturado	Diário	Fim do dia	Cada pessoa documenta: o que fez, o que travou, próximos passos. Sem report = dia não contou.
Sync Backstage × Migração	Semanal	Quinta, 13:30	Reunião com Migração (Gab, Humberto, Rik). Status, blockers, decisões.
Demo para Stakeholders	Bi-weekly	Sexta	Didico e Carol veem progresso real em produção.

---

PARTE 1: DIAGNÓSTICO REAL DO CÓDIGO

Estado de cada Gate (mapeado contra o código em 09/mar — atualizado com code audit v2)

Gate	Descrição	% Funcional e2e	Esforço restante	Risco	Notas
G1	Gestão financeira centralizada	~25%	Alto	Médio	GL maduro em código, mas não validado e2e em produção. Business Plan depende de Google Sheets.
G2	Acompanhar Cliente v1	~5%	Alto	Alto	Health score existe em código mas playbooks=0, retention offers desconectadas. Nada validado e2e.
G3	Pipeline/CRM unificado (matar HubSpot)	~8%	Alto	Alto	CRM nativo funciona parcial, mas HubSpot ainda é master. Sequences sem motor.
G4	Automações internas	~2%	Alto	Alto	Framework existe, execução é STUB. Lead scoring sem processador.
G5	Dashboard unificado de métricas	~8%	Alto	Médio	Dashboards existem separados, falta unificado executivo com dados reais.
G6	Integrações estabilizadas	~10%	Médio-Alto	Médio	17 integrações ativas, muitas sem monitoramento. Banco Inter ATIVO.
G7	Mensageria no monorepo	~5%	Alto	Médio	WhatsApp e Email funcionam, falta consolidação e templates.

NOTA: Os percentuais acima são medidos pelo Scoreboard funcional e2e (Modelo de Dados 20%, Backend 25%, Frontend 20%, Integração 20%, Qualidade 15%). Código existente ≠ funcionalidade validada em produção.

O que descobrimos

G1 e G5 estão quase prontos. O General Ledger é MUITO maduro — 85 contas contábeis, 5 posting engines, double-entry validado. Módulo financeiro é robusto: receita, custos, DRE, KPIs, business plan, reconciliação, unit economics. O 95% é uma estimativa precisa. Única dependência externa: Google Sheets para Business Plan.

G2 está melhor do que parecia. Health score com 5 componentes implementado, Customer 360 API com 9 fontes de dados, NPS completo, churn predictions funcionando. Gaps: playbooks vazio, retention offers engine construída mas não conectada, sem log formal de interações.

G3 é o gate mais crítico — mas mais funcional do que pensávamos. CRM nativo funciona (contacts, companies, deals, pipelines, activities). Code audit revelou 12 páginas CRM, ~100 arquivos, e testes extensivos — a base é sólida. MAS ainda depende do HubSpot para: sync de dados entrando, outbound (dedup + write), execução de sequences, onboarding de prestadores. Schema de sequences está completo mas não tem motor de execução.

G4 tem framework mas falta execução. Workflow builder tem tipos e executor, mas execução é STUB (simula trabalho). Automações de marketing tem CRUD e cron rodando a cada 5min, mas ações como SMS, webhooks, deals estão vazias. Lead scoring tem schema mas sem processador. Oitiva está funcional com 4 crons ativos — mais operacional do que relatado inicialmente.

G6 está estável e mais abrangente do que documentado. São 17 integrações no total (não 14 como estimado anteriormente). Iugu e Conta Azul sincronizando. Stripe só webhook. Banco Inter está ATIVO (não inativo como documentado na v1). Integrações adicionais identificadas: Resend (email transacional), PostHog (analytics de produto), Vapi (voice AI).

G7 opera parcialmente. WhatsApp via Evolution API funciona. Email via Resend funciona. Falta: SMS, templates avançados, histórico consolidado por cliente.

ALERTA: Claims "FUNCIONAL" precisam de validação em produção

Achado crítico do code audit: Vários módulos marcados como "funcional" no código
têm lógica implementada mas nunca foram validados com dados reais em produção.
Sprint 1 DEVE incluir validação de produção para cada claim de funcionalidade.

---

PARTE 2: METODOLOGIA

2.1 Princípios inegociáveis

1. Uma pessoa = uma missão por sprint. Sem context switching. Se você está no G2, você só faz G2.
2. Vertical first. Termina um fluxo end-to-end antes de começar outro.
3. Demo ou não existiu. Toda sexta, cada pessoa demonstra o que entregou funcionando.
4. Bloqueio = escala imediata. Se está bloqueado, fala no daily. Se não resolve em 24h, escala para Guilherme. Se não resolve em 48h, escala para Ju.
5. PRD é bounding. Se não está neste documento, não entra no sprint. Mudanças passam por Guilherme.
6. Zero construção no legado. Toda energia no monorepo.
7. Validate before building. Nenhum módulo "funcional" é considerado pronto até rodar com dados reais em produção.

2.2 Rituais

Ritual	Quando	Duração	Quem	Output
Daily standup	Seg-Sex, 9h	15min	Time completo	Bloqueio + foco do dia
Sprint planning	Segunda, 9h30	45min	Time completo	Tarefas da semana atribuídas
Sync técnico	Quarta, 14h	30min	Guilherme + devs	Decisões técnicas, code review
Comitê Produto & Backstage	Quinta, horário empresa	60min	+ Time Migração + Carol (CS)	Dependências cruzadas
Demo & Report	Sexta, horário empresa	30min	Empresa toda	Demonstração do entregue
Sprint retro + PRD review	Sexta, 16h	30min	Time completo	Ajustes no plano

2.3 Definição de "Pronto" (DoD)

Uma tarefa só está PRONTA quando:
- [ ] Código commitado no monorepo (branch + PR)
- [ ] Typecheck passa (bun run typecheck)
- [ ] Funcionalidade testável em staging
- [ ] Validada com dados reais em produção (não apenas staging/mock)
- [ ] Demonstrável (screenshot ou vídeo se UI, curl se API)
- [ ] Sem @ts-nocheck ou as any novo
- [ ] Auth implementada na rota (se API pública)

2.4 Board de tarefas

Usaremos um board Kanban com 5 colunas:

BACKLOG → SPRINT → EM PROGRESSO → REVIEW → DONE

Cada card tem:
- Gate (G1-G7) e/ou Macro-área (MA1-MA14)
- Pessoa responsável
- Critério de aceite (1-3 bullets)
- Dependências (se houver)
- Sprint alvo

---

PARTE 3: ATRIBUIÇÃO POR PESSOA (Domain Pairs)

Visão geral — Dupla Core + 4 Domínios

DUPLA CORE: VDC + CLARINY → Liderança, Finance & Data
├── VDC (Senior): Líder do projeto, lógica financeira, arquitetura, code review, decisões
├── Clariny (Junior): Par do VDC, implementa com AI, organização, onboarding, RH
├── Domínios: Financeiro, GL/Contabilidade, Data Architecture, RH
├── Sprint 1-2: G1 (financeiro + GL validação), G6 (integrações financeiras)
└── Sprint 3-4: G5 (dashboard executivo), G1 (eliminar Google Sheets)

DOMÍNIO 1: JP → Workflows & Automações
├── Responsável: migração workflows n8n, automações, mensageria, integrações
├── Sprint 1-2: G4 (automações), G6 (integrações), G7 (mensageria)
└── Sprint 3-4: G4 (sequences engine), G7 (consolidação)

DOMÍNIO 2: DUDA → Operations
├── Responsável: Jurídico, Prestadores, Design System tokens
├── Sprint 1-2: Discovery Jurídico/Prestadores, Design System audit
└── Sprint 3-4: G3 (provider onboarding), Design System polish

DOMÍNIO 3: GIOVANNA → CS
├── Responsável: Customer Success, Health Score, Retenção
├── Sprint 1-2: G2 (health score, customer 360, playbooks)
└── Sprint 3-4: G2 (alertas, retention offers), validação com Carol

DOMÍNIO 4: ALEX → CRM & Revenue
├── Senior Data, Medium Tech/Dev, RevOps
├── Domínios: CRM OS, Aquisição, Marketing, Vendas
├── Sprint 1-2: G3 (CRM nativo, matar HubSpot) + G6 (integrações audit)
└── Sprint 3-4: G5 (dashboard executivo) + G3 (vendas analytics)

VDC / GUILHERME (Líder / Diretor Financeiro)
├── Arquitetura de dados, decisões técnicas, PRD
├── Code review final de todas as PRs
├── Desbloqueio de dependências com outros times
├── Cross-cutting guardianships: Auth & Permissões, Data Architecture, Management OS
├── Comunicação com Ju R (Líder Studio) e liderança
└── Validação de produção dos módulos "FUNCIONAL"

Cross-cutting Guardians

Responsabilidade	Guardian
Auth & Permissões	VDC
Taxonomia	Alex
Data Architecture	VDC
Design System	Duda
LIA	Alex
Management OS	VDC
Workflows & n8n	JP
RH	Clariny

---

PARTE 4: PLANO SPRINT A SPRINT

---

SEMANA 0 — INVESTIGAÇÃO & ESBOÇO (11–16 mar)

Período: 11-16 mar (1 semana)
Tema: Cada pessoa investiga suas áreas, navega o Backstage, lê código, conversa com stakeholders. Na segunda (16 mar) fazemos o Planning da Sprint 1.

Pessoa	Áreas para investigar	Entregável até 16/mar (segunda)
VDC	Financeiro, Auth, Data Architecture, GL, Business Plan	Esboço do PRD Financeiro. Decisões sobre Google Sheets, ERP, auth strategy. Schemas base definidos.
Alex	CRM, Vendas, Aquisição, Marketing, Outbound	Discovery de CRM/Vendas: o que funciona, o que é stub, dependências HubSpot. Rascunho de Taxonomia.
JP	Automações, Workflows, n8n, Integrações, Mensageria	Mapeamento de todos os workflows n8n existentes. Lista de automações críticas. Estado real de cada integração.
Duda	Jurídico, Prestadores, Design System	Discovery de Jurídico e Prestadores: navegar, testar, anotar gaps. Inventário de Design System tokens.
Giovanna	CS, Health Score, Retenção, NPS, Suporte	Discovery de CS: testar health score, playbooks, renovações. Conversar com Carol. Anotar o que funciona vs. falta.
Clariny	Financeiro (com VDC), RH, Organização geral	Par do VDC na discovery financeira. Revisar módulo RH. Organizar documentação e onboarding do time.

Como investigar:
1. Abrir o Backstage em produção e navegar por TODAS as páginas da sua área
2. Anotar: o que carrega dados reais vs. vazio/erro/placeholder
3. Testar fluxos end-to-end com dados de produção
4. Ler o código: quais APIs retornam dados reais vs. mock
5. Conversar com quem USA a área no dia a dia
6. Produzir: 1 documento por área com Estado Atual, Gaps, e Decisões Pendentes

Planning (16/mar, segunda):
- Cada pessoa apresenta seus findings
- VDC consolida e define prioridades do Sprint 1
- Time define junto: o que entra no Sprint 1 e quem faz o quê

---

SPRINT 1 — FOUNDATION SPRINT (FUNDAÇÃO, ESTABILIZAÇÃO E VALIDAÇÃO DE PRODUÇÃO)

Período: 17-28 mar (2 semanas)
Tema: Auditar, validar claims de funcionalidade em produção, estabilizar integrações, iniciar gates críticos

Foco por domínio:
- VDC + Clariny → Auth, schemas base, Financeiro, RH (FUNDAÇÃO)
- Alex → CRM nativo, HubSpot migration, Integrações audit
- JP → Workflows n8n, Automações, Mensageria, Integrações
- Duda → Mini-PRDs Jurídico, Prestadores. Design System tokens
- Giovanna → CS, Health Score, Customer 360, validação com Carol

---

GUILHERME — Sprint 1

#	Tarefa	Gate	Critério de aceite	Dep.
G-1.1	Validar PRD com Ju (CEO) e liderança	Todos	PRD aprovado e comunicado ao time	—
G-1.2	Configurar board de tarefas (Linear/GitHub Projects)	Todos	Board operando com todos os cards do Sprint 1	—
G-1.3	Mapear TODAS as ferramentas externas em uso	G4,G6	Lista completa: ferramenta → função → substituto → status (atualizar para 17 integrações)	Time
G-1.4	Alinhar dependências com time Migração (Gab)	Todos	Documento de dependências cruzadas assinado por ambos	Gab
G-1.5	Definir com GTM (Didico): ICP e planos/pricing	G2,G3	ICP documentado, planos nomeados com features/preços	Didico
G-1.6	Decisão: timeline de desligamento do HubSpot	G3	Data-alvo definida, plano de migração aprovado	Ju
G-1.7	Decisão: 167 API routes sem auth — priorizar quais?	G6	Lista de routes críticas a proteger + cronograma	Time
G-1.8	Decisões D14-D21 do code audit	Todos	D14: Definir tratamento das 10 orphan routes. D15: Alinhar 3 taxonomias (29 routes vs 11 sidebar vs 10 ColaboradorAreas). D16-D21: Resolver achados restantes do audit	—
G-1.9	Coordenar validação de produção de todos os módulos "FUNCIONAL"	Todos	Cada módulo marcado como funcional validado com dados reais. Lista de claims falsos corrigida	Time
G-1.10	Alinhar com Carol (CS) sobre métricas de health score e playbooks	G2	Documento de requisitos CS aprovado por Carol	Carol

Entregável da demo: PRD validado + board funcionando + mapa de dependências + relatório de validação de produção

---

ALEX — Sprint 1

#	Tarefa	Gate	Critério de aceite	Dep.
A-1.1	Auditoria de TODAS as integrações (17 total)	G6	Para cada uma das 17: status (ok/falha/inativo), última sync, erros recentes, SLA. Incluir Resend, PostHog, Vapi, Banco Inter (ATIVO)	—
A-1.2	Implementar monitoramento de integrações	G6	Alertas para falhas de sync. Dashboard de status de cada integração	A-1.1
A-1.3	Estabilizar sync Iugu (se issues encontrados)	G6	Zero falhas de sync em 7 dias consecutivos	A-1.1
A-1.4	Estabilizar sync Conta Azul (se issues encontrados)	G6	Zero falhas de sync em 7 dias consecutivos	A-1.1
A-1.5	Documentar cada integração	G6	Para cada: o que sincroniza, frequência, credenciais necessárias, fallback	A-1.1
A-1.6	Auditar módulo financeiro — validar GL em produção	G1	Validar 85 contas, 5 posting engines com dados reais. Lista precisa do que falta para G1 (checklist binário)	—

Entregável da demo: Dashboard de monitoramento de integrações (17) + relatório de auditoria + validação GL

---

JP — Sprint 1

#	Tarefa	Gate	Critério de aceite	Dep.
JP-1.1	Auditar mensageria: WhatsApp (Evolution), Email (Resend)	G7	Status real: funciona? Envia? Recebe? Webhook de resposta funciona?	—
JP-1.2	Mapear todas as mensagens enviadas FORA do monorepo	G7	Lista: quais emails/WhatsApp saem por ferramentas externas? Quais templates?	—
JP-1.3	Mapear todos os workflows n8n existentes	G4	Lista completa: trigger, ações, frequência, status. Quais são críticos?	—
JP-1.4	Auditar automações: quais ações do action-executor funcionam?	G4	Testar cada ação: send_email, send_whatsapp, set_contact_property, create_task. Documentar funcionais vs stub	—
JP-1.5	Auditar cron jobs: quais rodam, quais falham? Incluir 4 crons Oitiva	G4	Lista dos crons (incluindo Oitiva): último run, status, erros recentes	—
JP-1.6	Auditar todas as 17 integrações	G6	Para cada: status (ok/falha/inativo), última sync, erros recentes	—

Entregável da demo: Mapa completo de mensageria + automações + workflows n8n + status de integrações

---

DUDA — Sprint 1

#	Tarefa	Gate	Critério de aceite	Dep.
DU-1.1	Discovery Jurídico: navegar todas as páginas, testar fluxos	—	Documento: o que funciona, o que é stub, gaps, decisões pendentes	—
DU-1.2	Discovery Prestadores: navegar, testar fluxos end-to-end	—	Documento: estado real do módulo, Provider 360 funciona? Rankings? Carteirização?	—
DU-1.3	Inventário Design System: tokens, componentes em uso	—	Lista de componentes @freelaw/ui vs. o que as miniapps realmente usam. Gaps identificados	—
DU-1.4	Validar domain alignment: 29 routes vs 11 sidebar vs 10 ColaboradorAreas	Todos	Identificar orphan routes. Proposta de alinhamento	—
DU-1.5	Mini-PRD rascunho: Jurídico	—	Documento com estado ideal, gaps, esforço estimado	DU-1.1
DU-1.6	Mini-PRD rascunho: Prestadores	—	Documento com estado ideal, gaps, esforço estimado	DU-1.2

Entregável da demo: Discovery reports de Jurídico + Prestadores + Design System audit

---

GIOVANNA — Sprint 1

#	Tarefa	Gate	Critério de aceite	Dep.
GI-1.1	Auditar Customer 360 API (/api/customer-360)	G2	Documento: quais das 9 fontes retornam dados reais vs mock. Testar com 5 clientes reais	—
GI-1.2	Auditar health score (/api/customer-success/health)	G2	Verificar: scores calculados? Cron de health roda? Dados reais para quantos clientes?	—
GI-1.3	Garantir /suporte/cliente/[orgId] funciona end-to-end	G2	Página carrega para qualquer cliente ativo. 4 tabs mostram dados	GI-1.1
GI-1.4	Listar gaps do G2: o que falta para "Acompanhar Cliente v1"	G2	Checklist binário: o que funciona vs o que falta	GI-1.1,GI-1.2
GI-1.5	Definir com Carol (CS): métricas do health score	G2	Documento aprovado por Carol com pesos e thresholds	Carol
GI-1.6	Discovery NPS e Renovações: estado real em produção	G2	NPS envia? Dados reais? Pipeline de renovações funciona?	—

Entregável da demo: Customer 360 funcionando para 5 clientes + gap analysis + métricas Carol

---

CLARINY — Sprint 1

#	Tarefa	Gate	Critério de aceite	Dep.
CL-1.1	Discovery módulo RH: navegar, testar, anotar gaps	—	Documento: estado real do RH, org chart funciona? Payroll? People analytics?	—
CL-1.2	Par do VDC: discovery financeiro — validar GL em produção	G1	Validar 85 contas, 5 posting engines com dados reais. Testar DRE, KPIs, reconciliação	—
CL-1.3	Organizar documentação e onboarding do time	Todos	Template de report diário criado. Canais de comunicação definidos. Board de tarefas configurado	—
CL-1.4	Mini-PRD rascunho: Financeiro (VDC guiando)	G1	Documento com estado ideal, gaps, decisões pendentes	CL-1.2
CL-1.5	Mini-PRD rascunho: RH	—	Documento com estado ideal, gaps, esforço estimado	CL-1.1

Entregável da demo: Discovery reports RH + Financeiro + onboarding do time organizado

---

SPRINT 2 — FECHAR G1, G5, G6 + AVANÇAR G3

Período: 31 mar - 11 abr (2 semanas)
Tema: Fechar gates mais próximos, avançar migração HubSpot

---

GUILHERME — Sprint 2

#	Tarefa	Gate	Critério de aceite	Dep.
G-2.1	Revisar PRs e decisões técnicas do Sprint 1	Todos	Todas as PRs do Sprint 1 merged ou com feedback claro	—
G-2.2	Validar G6 para fechamento	G6	Checklist do gate verificado item a item com Alex (17 integrações)	A-1.*
G-2.3	Desenhar schema de unified_interactions (se necessário)	G2,G7	Schema aprovado, migration pronta	D-1.3
G-2.4	Alinhar com Migração: dados do Studio sincronizando para Backstage	G2,G5	Métricas de uso do Studio acessíveis via API/query	Gab
G-2.5	Implementar domain alignment fix (3 taxonomias)	Todos	Resolver 10 orphan routes. Alinhar sidebar com routes reais	D-1.6
G-2.6	Close Management: schema + period lock (Campfire)	G1	Schemas close_periods + close_checklist_items criados. Period lock no posting layer. Checklist de 12 itens	CL-1.2
G-2.7	CEO IA: financial tools expansion	G5	≥5 financial tools no CEO IA (flux-analysis, ar-aging, budget-variance, cashflow-forecast, vendor-spend)	—

---

ALEX — Sprint 2

#	Tarefa	Gate	Critério de aceite	Dep.
A-2.1	Resolver gaps do G1 (identificados em A-1.6)	G1	Cada item do checklist fechado	A-1.6
A-2.2	Eliminar dependência Google Sheets no Business Plan	G1	Business Plan editável 100% na UI do Backstage. Import/export via CSV/JSON como fallback	—
A-2.3	Dashboard executivo unificado	G5	UMA página com: MRR, churn rate, novos clientes, receita, despesas, health score médio. Filtros: período, plano	—
A-2.4	Validar G1 para fechamento	G1	Checklist do gate verificado. GL com 85 contas validado. Nenhuma operação financeira depende de ferramenta externa	A-2.1,A-2.2
A-2.5	Validar G5 para fechamento	G5	Dashboard executivo aprovado por Ju	A-2.3

Entregável da demo: Dashboard executivo + G1 fechado + G5 fechado

---

JP — Sprint 2

#	Tarefa	Gate	Critério de aceite	Dep.
JP-2.1	Implementar ações faltantes no action-executor	G4	send_sms, create_deal, send_internal_notification, webhook — todos funcionais ou com fallback	JP-1.4
JP-2.2	Garantir cron de automações (5min) rodando sem falhas	G4	Zero erros em 7 dias. Logs estruturados. Métricas de execução	JP-1.5
JP-2.3	Histórico consolidado de mensagens acessível via API	G7	GET /api/customer-360/{id}/messages retorna: WhatsApp + Email + Suporte	JP-1.1
JP-2.4	Templates de mensagem gerenciáveis	G7	CRUD de templates (WhatsApp + Email). Time pode criar/editar	—
JP-2.5	Implementar monitoramento de integrações	G6	Dashboard de status de cada integração. Alertas para falhas de sync	JP-1.6

Entregável da demo: Automações rodando + templates + monitoramento de integrações

---

DUDA — Sprint 2

#	Tarefa	Gate	Critério de aceite	Dep.
DU-2.1	Migrar provider onboarding para não depender do HubSpot	G3	/crm/providers funciona sem HubSpot API call	DU-1.2
DU-2.2	Resolver gaps de Design System identificados no audit	—	Tokens atualizados, componentes faltantes criados	DU-1.3
DU-2.3	Implementar domain alignment fix (3 taxonomias)	Todos	Resolver orphan routes. Alinhar sidebar com routes reais	DU-1.4
DU-2.4	Início de implementação: Jurídico mini-PRD	—	Primeiros fluxos funcionais de Jurídico no Backstage	DU-1.5

Entregável da demo: Provider onboarding nativo + Design System atualizado

---

GIOVANNA — Sprint 2

#	Tarefa	Gate	Critério de aceite	Dep.
GI-2.1	Resolver gaps do G2 (identificados em GI-1.4)	G2	Cada item do checklist corrigido	GI-1.4
GI-2.2	Health score calculado para 100% dos clientes ativos	G2	Cron rodando. Todos os clientes com score calculado	GI-1.2
GI-2.3	Alertas automáticos para clientes em risco	G2	Quando health < 40 (critical): notificação + marca na UI	GI-2.2
GI-2.4	Conectar RetentionEngine a retention-offers API	G2	Dado um cliente, retorna oferta de retenção calculada	—
GI-2.5	Tab de interações no Customer 360 com dados reais	G2	Timeline unificada: tickets + conversas + WhatsApp + NPS	JP-2.3

Entregável da demo: Health score 100% + alertas automáticos + retention offers

---

CLARINY — Sprint 2

#	Tarefa	Gate	Critério de aceite	Dep.
CL-2.1	Resolver gaps do G1 (identificados na discovery)	G1	Cada item do checklist financeiro corrigido	CL-1.2
CL-2.2	Eliminar dependência Google Sheets no Business Plan	G1	Business Plan editável 100% na UI do Backstage	—
CL-2.3	Validar módulo RH end-to-end	—	Org chart, payroll, people analytics funcionando com dados reais	CL-1.1
CL-2.4	Manter organização: documentação, board, reports	Todos	Board atualizado, reports diários compilados, decisões registradas	—
CL-2.5	Implementar Close Management UI (par VDC)	G1	/financeiro/close com checklist interativo, status do período, progresso %	G-2.6
CL-2.6	AR Aging Report	G1	/financeiro/receita/aging com buckets (current/30/60/90/120+), valor total por bucket	—

Entregável da demo: G1 gaps resolvidos + Business Plan na UI + Close Management + RH validado

---

SPRINT 3 — FECHAR G2, G3, G7

Período: 14-25 abr (2 semanas)
Tema: Fechar os gates de maior complexidade

---

GUILHERME — Sprint 3

#	Tarefa	Gate	Critério de aceite	Dep.
G-3.1	Validar G2 para fechamento	G2	Checklist verificado com Clariny e Carol (CS)	C-2.*
G-3.2	Validar G3 para fechamento	G3	HubSpot desligado. CRM 100% nativo. Validado com Vendas	B-2.*
G-3.3	Validar G7 para fechamento	G7	Mensageria consolidada no monorepo. Validado com operação	D-2.*
G-3.4	Apresentar status dos gates para Ju (CEO)	Todos	5/7 gates fechados (G1,G2,G3,G5,G6). G4 e G7 em fechamento	—

---

ALEX — Sprint 3

#	Tarefa	Gate	Critério de aceite	Dep.
A-3.1	Adicionar métricas de CS ao dashboard executivo	G5	Health score médio, clientes em risco, NPS. Atualização diária	C-2.2
A-3.2	Adicionar métricas de aquisição ao dashboard	G5	Novos leads, conversão por etapa, CAC. Dados do v2_sales	B-2.*
A-3.3	Validar Banco Inter ativo e estabilizar	G6	Transações bancárias sincronizando. Reconciliação automática	A-1.1
A-3.4	Polish final do módulo financeiro	G1	Completar stubs: ERP placeholder, Recebimentos, Estruturas	—

---

JP — Sprint 3

#	Tarefa	Gate	Critério de aceite	Dep.
JP-3.1	Implementar sequence execution engine	G3,G4	Cron: busca enrollments → envia email via Resend → atualiza enrollment	JP-2.1
JP-3.2	Implementar lead scoring processor	G4	Cron calcula score baseado em lead_scoring_rules. Score visível no CRM	—
JP-3.3	Finalizar mensageria: consolidar TODOS os canais	G7	Qualquer mensagem aparece no histórico unificado do cliente	JP-2.3
JP-3.4	UI de automações básica	G4	Listar automações, ativar/desativar, ver logs de execução	—
JP-3.5	Configurar ≥3 Continuous Agents (Campfire)	G4	Financial Guardian (5min), Reconciliation Auto (15min), Health Score Monitor (15min) rodando via cron-service	JP-2.2
JP-3.6	Confidence thresholds config	G4	confidence_configs table + API CRUD + UI em /configuracoes/ai	—

Entregável da demo: Sequences engine + lead scoring + continuous agents + mensageria unificada

---

DUDA — Sprint 3

#	Tarefa	Gate	Critério de aceite	Dep.
DU-3.1	Implementar tracking de opens/clicks/replies (sequences)	G3	Webhook do Resend processando eventos. Dados visíveis na UI	JP-3.1
DU-3.2	Implementar exit conditions de sequences	G3	Sequence para quando: reply detectado, meeting agendado, unsubscribe	DU-3.1
DU-3.3	Polish Design System: componentes faltantes	—	Componentes identificados no audit implementados	DU-2.2
DU-3.4	Prestadores: completar fluxos pendentes	—	Provider 360 e fluxos críticos funcionando e2e	DU-2.1

Entregável da demo: Sequences tracking + Design System polished + Prestadores funcional

---

GIOVANNA — Sprint 3

#	Tarefa	Gate	Critério de aceite	Dep.
GI-3.1	Implementar Playbooks básico	G2	3 playbooks: onboarding, risco, NPS detractor. Cada um: ações + assignee + status	—
GI-3.2	Dashboard CS unificado	G2	Uma página: clientes por saúde, renovações, NPS, top 10 em risco	GI-2.*
GI-3.3	Conectar dados do Studio ao health score	G2	Componente "usage" alimentado por dados reais de uso	G-2.4
GI-3.4	Validação final G2 com Carol	G2	Demo para Carol e CS. Feedback incorporado. Gate aprovado	GI-3.1-3

Entregável da demo: Playbooks + Dashboard CS + validação com Carol

---

CLARINY — Sprint 3

#	Tarefa	Gate	Critério de aceite	Dep.
CL-3.1	Validar G1 para fechamento	G1	Checklist do gate verificado. GL validado. Nenhuma operação depende de ferramenta externa	CL-2.*
CL-3.2	Apoio na construção do dashboard executivo (com Alex)	G5	Métricas financeiras do dashboard alimentadas por dados reais	A-3.3
CL-3.3	Testar automações e2e (apoio ao JP)	G4	Cenários de automação testados e documentados	JP-3.*
CL-3.4	Documentação: estado de cada módulo investigado	Todos	Documentos de discovery consolidados e atualizados	—

Entregável da demo: G1 validado + contribuição no dashboard + documentação consolidada

---

SPRINT 4 — FECHAR G4 + BUFFER + VALIDAÇÃO FINAL

Período: 28-30 abr (3 dias + buffer)
Tema: Fechar último gate, polish, validação com stakeholders

---

GUILHERME — Sprint 4

#	Tarefa	Gate	Critério de aceite	Dep.
G-4.1	Validar G4 para fechamento	G4	Automações internas substituem ferramentas externas críticas	D-3.*
G-4.2	Validar G7 para fechamento	G7	Mensageria 100% no monorepo. Histórico consolidado	D-3.2
G-4.3	Gate review completa (7/7) com Ju (CEO)	Todos	Apresentação formal: cada gate demonstrado e aprovado	Todos
G-4.4	Documentar estado final + handoff para Fase 1	Todos	Documento de estado de cada módulo. Débito técnico catalogado. Mapeamento MA vs Gates para Fase 1	—
G-4.5	Retrospectiva da Fase 0	Todos	Lições aprendidas. O que manter, mudar, parar	Time

---

ALEX — Sprint 4

#	Tarefa	Gate	Critério de aceite	Dep.
A-4.1	Polish dashboard executivo	G5	Feedback de Ju incorporado. Performance otimizada	—
A-4.2	Testes end-to-end do módulo financeiro	G1	Cenários: nova assinatura → MRR atualiza → DRE reflete → dashboard mostra	—
A-4.3	Documentar integração financeira	G1,G6	Runbook de cada integração: como funciona, como debugar, como resetar	—

---

JP — Sprint 4

#	Tarefa	Gate	Critério de aceite	Dep.
JP-4.1	Testes end-to-end de automações	G4	3 cenários: marketing automation, lead scoring, sequence execution	—
JP-4.2	Testes end-to-end de mensageria	G7	Enviar WhatsApp + Email pelo Backstage. Resposta aparece no histórico	—
JP-4.3	Documentar automações e mensageria	G4,G7	Como criar automação, como enviar mensagem, como ver histórico	—
JP-4.4	Listar ferramentas externas ELIMINADAS vs MANTIDAS	G4	Lista final: o que saiu, o que ficou (e por que ficou)	—
JP-4.5	Configurar ≥2 On-Demand Agents (Campfire)	G4	Weekly Report (domingo 20h) + Close Prep (1º dia útil) agendados e gerando output	JP-3.5
JP-4.6	Agent Dashboard	G4	UI em /automacoes/agents: runs, success rate, actions taken/flagged por agent	JP-3.5
JP-4.7	Migrar 10 billing crons STUB	G4	Crons em cron-service/src/routes/billing/ implementados ou migrados para agents	—

---

DUDA — Sprint 4

#	Tarefa	Gate	Critério de aceite	Dep.
DU-4.1	Testes end-to-end do CRM nativo	G3	Cenários: criar lead → qualificar → criar deal → mover pipeline → fechar	—
DU-4.2	Confirmar HubSpot 100% desligado	G3	Remover HUBSPOT_ACCESS_TOKEN de env. Nada quebra	—
DU-4.3	Documentar CRM/Pipeline/Sequences + Design System	G3	Como usar, como debugar. Designer's Bible draft	—

---

GIOVANNA — Sprint 4

#	Tarefa	Gate	Critério de aceite	Dep.
GI-4.1	Testes end-to-end do CS	G2	Cenários: novo cliente → health calculado → score baixo → alerta → playbook	—
GI-4.2	Treinamento do time de CS (Carol) na ferramenta	G2	Sessão de 1h com Carol e CS. Documentação básica de uso	—
GI-4.3	Documentar Customer 360 e Health Score	G2	Como funciona o cálculo, como interpretar, como agir	—

---

CLARINY — Sprint 4

#	Tarefa	Gate	Critério de aceite	Dep.
CL-4.1	Testes end-to-end do módulo financeiro	G1	Cenários: nova assinatura → MRR atualiza → DRE reflete	—
CL-4.2	Documentar estado final de cada módulo	Todos	Documento consolidado: cada módulo investigado, estado, gaps remanescentes	—
CL-4.3	Organizar handoff para Fase 1	Todos	Documentação de débito técnico, backlog, próximos passos	—

---

PARTE 5: DEPENDÊNCIAS ENTRE TIMES

TIME BACKSTAGE depende de:

MIGRAÇÃO (Gab, Humberto, Rik):
├── Monorepo estável e deployável          → Semana 0-1 (crítico)
├── Dados do Studio acessíveis via query   → Sprint 2 (para health score)
├── Métricas de uso do Studio              → Sprint 2 (para dashboard)
└── 100% clientes migrados                 → Sprint 4 (para G2 completo)

GTM / AQUISIÇÃO (Didico):
├── Definição de ICP                       → Semana 1 (para segmentação)
├── Definição de planos/pricing            → Semana 2 (para financeiro)
├── Narrativa de venda                     → Semana 4 (para sequences)
└── Jornada do cliente                     → Semana 4 (para playbooks CS)

CS (Carol):
├── Métricas de health score               → Semana 1 (pesos e thresholds)
├── Requisitos de playbooks                → Semana 2 (fluxos e ações)
├── Validação de Customer 360              → Semana 4 (UAT com time CS)
└── Treinamento do time na ferramenta      → Semana 8 (handoff)

CEO (Ju):
├── Aprovação do PRD                       → Semana 1 (kick-off)
├── Decisão timeline HubSpot              → Semana 1 (G3)
├── Aprovação dashboard executivo          → Semana 4 (G5)
└── Gate review final (7/7)               → Semana 8 (entrega)

---

PARTE 6: CRITÉRIOS DE FECHAMENTO DOS GATES

G1 — Gestão financeira centralizada

• [ ] Toda operação financeira consultável no Backstage
• [ ] Zero dependência de planilhas externas para dados financeiros
• [ ] Business Plan editável sem Google Sheets
• [ ] GL validado em produção: 85 contas, 5 posting engines, double-entry
• [ ] Sync Iugu + Conta Azul estável (7 dias sem falha)
• [ ] DRE, KPIs, Unit Economics funcionando com dados reais
• [ ] Close Management: checklist ≥10 itens, período trancável, flux analysis (Campfire)
• [ ] Period Lock: posting APIs rejeitam writes para períodos trancados
• [ ] Dunning Automation: cron envia lembretes por aging (D+0/3/7/30)
• [ ] AR Aging: dashboard com buckets (current/30/60/90/120+)
• [ ] Audit Trail: /financeiro/audit com log de operações

G2 — Acompanhar Cliente v1

• [ ] Customer 360 funcional para qualquer cliente ativo
• [ ] Health score calculado para 100% dos clientes (métricas aprovadas por Carol)
• [ ] Alertas automáticos para clientes critical (< 40)
• [ ] Timeline de interações consolidada (WhatsApp + email + suporte)
• [ ] Retention offers calculáveis via API
• [ ] 3 playbooks CS operando

G3 — Pipeline e CRM unificados

• [ ] HubSpot sync desligado
• [ ] Contacts, companies, deals criados nativamente
• [ ] Pipeline de vendas 100% no Backstage
• [ ] Outbound pipeline funciona sem HubSpot
• [ ] Sequences criadas e executadas nativamente
• [ ] Provider onboarding sem HubSpot
• [ ] 12 páginas CRM validadas em produção com dados reais

G4 — Automações internas

• [ ] Marketing automations rodando (cron 5min, ações funcionais)
• [ ] Lead scoring processor ativo
• [ ] Oitiva funcional (4 crons ativos validados)
• [ ] Ferramentas externas de automação eliminadas (ou justificadas)
• [ ] UI para gerenciar automações no Backstage
• [ ] Logs de execução acessíveis
• [ ] ≥3 Continuous Agents rodando (Financial Guardian, Reconciliation Auto, Health Score Monitor)
• [ ] ≥2 On-Demand Agents agendados (Weekly Report, Close Prep)
• [ ] Confidence thresholds configuráveis por ação (>95% auto, 70-95% review, <70% flag)
• [ ] Agent Dashboard: runs, success rate, actions taken/flagged
• [ ] 10 billing crons migrados de stub para funcional

G5 — Dashboard unificado de métricas

• [ ] UM dashboard executivo: MRR, churn, aquisição, operação, CS
• [ ] Filtros: período, plano, cohort
• [ ] Dados em tempo real (ou <24h)
• [ ] Aprovado por Ju (CEO)
• [ ] Flux analysis: cada métrica com variação % + explicação IA (CEO IA tool)
• [ ] Drill-down: clicar em métrica navega para módulo de origem
• [ ] Source attribution: cada card mostra fonte do dado + timestamp

G6 — Integrações estabilizadas

• [ ] Auditoria das 17 integrações completa (incluindo Resend, PostHog, Vapi)
• [ ] Banco Inter ATIVO e estabilizado
• [ ] Monitoramento ativo com alertas
• [ ] Zero falhas críticas em 7 dias
• [ ] Documentação de cada integração

G7 — Mensageria no monorepo

• [ ] WhatsApp enviando e recebendo dentro do monorepo
• [ ] Email transacional funcionando (Resend)
• [ ] Histórico consolidado por cliente (todos os canais)
• [ ] Templates gerenciáveis pelo time
• [ ] Webhook de respostas processando

---

PARTE 7: RISCOS E MITIGAÇÕES

#	Risco	Prob.	Impacto	Mitigação	Owner
R1	HubSpot migration mais complexa que esperado	Alta	Crítico	Plano B: dual-run (Backstage primário, HubSpot read-only)	Alex
R2	Migração atrasa e bloqueia dados do Studio	Alta	Alto	Trabalhar com dados mock até integração. Comitê quinta	Guilherme
R3	Sequence execution engine não fica pronto	Média	Alto	Priorizar: criar+enrollar manual. Envio automático vem depois	JP
R4	Stakeholders pedem mudanças de UX no Sprint 4	Média	Médio	Envolver Carol e stakeholders no Sprint 2 (cedo, não tarde)	Giovanna
R5	167 routes sem auth exploradas em produção	Baixa	Crítico	Priorizar routes públicas. WAF como mitigação imediata	Guilherme
R6	Time sobrecarregado com bugs em produção	Média	Alto	Regra: max 20% do tempo em bugs. Resto é construção	Guilherme
R7	Escopo cresce além dos 7 gates	Alta	Alto	Este documento é bounding. Não entra sem aprovação	Guilherme
R8	Módulos "FUNCIONAL" falham em produção	Alta	Alto	Semana 0 + Sprint 1 dedicados a validação. Buffer em Sprint 4	Guilherme
R9	14 macro-áreas do PRD v8 não cabem em 4 sprints	Alta	Médio	Gates são Fase 0. MAs expandidas entram na Fase 1 (ver PARTE 9)	Guilherme
R10	Domain misalignment (3 taxonomias)	Média	Médio	DU-1.4 + G-2.5: Fix no Sprint 1-2 antes de construir mais	Duda + Guilherme

---

PARTE 8: COMUNICAÇÃO

Canais

• Daily: Canal interno #backstage-daily (async antes das 9h, sync às 9h)
• Bloqueios: Canal interno #backstage-bloqueios (qualquer hora, resposta em <4h)
• PRs: GitHub, com review obrigatório de Guilherme
• Decisões: Registradas neste documento (changelog)

Nota PRD v8: Slack está sendo internalizado. Canais de comunicação migram para ferramenta
interna conforme disponibilidade. Enquanto isso, manter canais existentes.

Escalação

Bloqueio técnico → Sync quarta com Guilherme (ou canal imediato se urgente)
Bloqueio de dependência → Guilherme resolve em 24h ou escala para Ju
Bloqueio de decisão → Ju decide em 48h
Bloqueio CS → Carol resolve em 24h ou escala para Guilherme
Bloqueio Aquisição → Didico resolve em 24h ou escala para Guilherme

Report semanal (sexta)

Cada pessoa preenche:

NOME:
ENTREGUE esta semana: [lista]
BLOQUEADO em: [lista ou "nada"]
FOCO semana que vem: [lista]
GATE status: G_ = __% (mudou +_% esta semana)
VALIDAÇÃO PRODUÇÃO: [quais módulos validados esta semana]

---

PARTE 9: MACRO-ÁREAS vs GATES — MAPEAMENTO E EXPANSÃO

Contexto

O PRD v8 define 14 macro-áreas (MAs) para o Backstage. Este plano de trabalho cobre 7 gates que correspondem à Fase 0 (estabilização). As MAs restantes serão endereçadas na Fase 1 (pós-30/abril) ou requerem dependências externas.

Mapeamento completo

Macro-Área	Descrição	Gate(s) Correspondente(s)	Sprint	Status
MA1	Gestão financeira	G1	Sprint 1-2	Coberto — GL maduro em código (~25% funcional e2e)
MA2	Acompanhamento de clientes (CS)	G2	Sprint 1-3	Coberto
MA3	Pipeline e CRM	G3	Sprint 1-3	Coberto
MA4	Automações internas	G4	Sprint 1-4	Coberto
MA5	Dashboard executivo	G5	Sprint 2-3	Coberto
MA6	Integrações	G6	Sprint 1-2	Coberto — expandido para 17 integrações
MA7	Mensageria	G7	Sprint 1-3	Coberto
MA-CRM	CRM como Operating System	G3 (parcial)	Sprint 2-3	Parcial — pipeline e sequences cobertos, mas CRM-as-OS (todos os módulos integrados ao CRM) é Fase 1
MA9 (RH)	Gestão de pessoas	Nenhum	—	Fase 1 — gestao.freelaw.ai IS the backstage (não sistema separado). Requer decisão de merge
MA10	Gestão de prestadores	G3 (parcial)	Sprint 2	Parcial — onboarding coberto (B-2.4), gestão completa é Fase 1
MA11	Gestão jurídica	Nenhum	—	Fase 1 — específico do domínio jurídico
MA12	Design System	Nenhum	—	Fase 1 — 80+ componentes existem mas precisam de Designer's Bible. Trabalho enorme
MA13 (LIA)	AI em produção	Nenhum	—	Fase 1 — IA para automação de processos e geração de documentos
MA14	Data Architecture	G1 (parcial)	Sprint 1-2	Parcial — GL existe e é maduro, mas precisa de validação de produção (A-1.6) e testing formal

Gaps identificados para Fase 1

1. MA-CRM como OS: O CRM precisa evoluir de "módulo de vendas" para "sistema operacional" que conecta todos os outros módulos. Fase 0 constrói o CRM; Fase 1 integra.

2. MA9 (RH): Descoberta crítica — gestao.freelaw.ai é o backstage, não um sistema separado. Precisa de decisão arquitetural: merge completo ou federação.

3. MA12 (Design System): 80+ componentes React existem no monorepo, mas não há Designer's Bible (guia de design tokens, spacing, typography). Trabalho de design + código.

4. MA13 (LIA): AI features são transversais. Requer definição de onde IA agrega valor (classificação, geração, automação) antes de implementar.

5. MA14 (Data Architecture): GL é maduro em código, mas precisa de validação formal com dados reais de produção. Sprint 1 endereça isso parcialmente (A-1.6).

Recomendação

Fase 0 (este plano): Fechar G1-G7 com validação de produção.
Fase 1 (maio-junho): Expandir para MAs 9, 12, 13 + evoluir CRM-as-OS + Design System.
Transição: Sprint 4 (G-4.4) documenta estado e planeja handoff para Fase 1.

---

PARTE 10: AI CHECKS PIPELINE

Checks automáticos que o AI (7º membro do time) executa em cada PR e a cada sprint.
O que já existe roda desde o Sprint 1. O que está marcado como "Construir" entra no backlog de infra.

Check	Como	Status
Code Review	AI reviewer no PR	✅ Existe
Typecheck + Lint	CI pipeline	✅ Existe
PR Size	preflight-check ≤400 linhas	✅ Existe
Schema/Migration Review	AI valida SQL, RLS, indexes	🔨 Construir
Design Consistency	AI checa tokens do Design System	🔨 Construir
Test Generation	AI gera testes por PR	🔨 Construir
Data Guard	AI valida double-entry, FK integrity	🔨 Construir
Docs Sync	AI atualiza docs quando código muda	🔨 Construir
Gate Progress	AI mede % de cada gate automaticamente	🔨 Construir

---

PARTE 11: RISCOS MAPEADOS — VISÃO EXPANDIDA

Complementa a PARTE 7 com riscos estratégicos e organizacionais identificados no planejamento do modelo operacional.
A PARTE 7 foca em riscos técnicos/de execução. Esta parte foca em riscos de pessoas, processo e dependências.

#	Risco	Prob.	Impacto	Mitigação
R1	VDC como gargalo — PO + Dev + Líder + Guardian de 3 cross-cuttings. Se travar, trava tudo.	Alta	Crítico	Clariny assume tasks financeiras sem depender de spec. Dailies detectam sobrecarga cedo.
R2	Ramp-up com projeto novo — Time entrando em projeto grande e complexo. Produtividade real pode ser menor nas primeiras semanas.	Alta	Alto	Foundation Sprint dedicado. Clariny organiza onboarding. PRD centralizado como guia.
R3	Escopo vs tempo — 14 MAs em 8 semanas com ~8% pronto. Matematicamente apertado.	Alta	Alto	Priorização brutal: definir "mínimo funcional" por MA. Cortar scope, não prazo.
R4	Dependência do projeto Migração — Backstage depende de dados que vêm do Studio (Gab/time). Se migração atrasa, Backstage fica sem dados reais.	Média	Crítico	Sync semanal toda quinta 13:30. Gab como ponte. Foundation Sprint cria schemas independente.
R5	AI-first workflow nunca testado — O time nunca operou nesse modelo. Pode haver resistência ou curva de aprendizado.	Média	Alto	Sprint 1 como piloto do workflow. Ajustar processo conforme feedback real.
R6	Decisões pendentes bloqueiam progresso — Decisões sem dono. Se não forem tomadas, time fica parado.	Média	Alto	Top 6 decisões resolvidas na Semana 0. VDC + Ju R decidem, não comitê.
R7	Golden Record indefinido — Sem modelo unificado de entidades, cada MA modela diferente. Depois não conecta.	Média	Crítico	Alex (guardian de Taxonomia) define o Golden Record no Foundation Sprint.
R8	Qualidade do código gerado por AI — PRs passam no CI mas a lógica de negócio está errada.	Média	Médio	VDC revisa TODA lógica de negócio. AI review pega estilo/padrões, humano pega semântica.
R9	Burnout — 8 semanas intensas, dailies todo dia, documentação rigorosa.	Baixa	Alto	Monitorar nos Pulses (Management OS). Sprint 2→3 tem folga natural.
R10	Integrações frágeis quebram — 17 integrações ativas com APIs externas. Qualquer breaking change paralisa.	Baixa	Médio	JP monitora. Integrações estabilizadas é gate explícito.

Mapeamento Risco → Sprint

Risco	Quando aparece	Onde monitorar
R1 (VDC gargalo)	Sprint 1 em diante	Daily standup — se VDC tem >3 tasks abertas, redistribuir
R2 (Juniors ramp-up)	Sprint 1-2	Velocidade de PRs — se <2 PRs/semana por junior, ajustar tasks
R3 (Escopo vs tempo)	Sprint 2 checkpoint	Sprint retro sexta — se <50% dos gates Sprint 1-2, cortar scope
R4 (Migração)	Sprint 1-2	Sync semanal com Gab (Comitê quinta)
R5 (AI workflow)	Sprint 1	Sprint 1 retro — decisão go/no-go do workflow AI-first
R6 (Decisões)	Sprint 1, semana 1	Board de tarefas — D14-D21 resolvidas até fim da semana 1
R7 (Golden Record)	Sprint 1	Task D-1.6 + A-1.6
R8 (AI code quality)	Sprint 1 em diante	Code review — % de PRs com bugs de lógica detectados
R9 (Burnout)	Sprint 3-4	Pulses qualitativos (Management OS)
R10 (Integrações)	Sprint 2	G6 gate check

---

PARTE 12: MAPA DE STAKEHOLDERS

Quem decide, quem executa, quem consome. Canais de comunicação e caminhos de escalação por stakeholder.

Tier 1 — Decisão

Stakeholder	Papel	Classificação	Canal principal	Frequência
Ju R (Ju Resende)	Líder Studio	Sponsor — Decide conflitos entre projetos, aprova mudanças estruturais	Weekly report async (sexta)	Semanal + ad hoc para bloqueios >48h
VDC	Diretor Financeiro, Líder Backstage	Driver — Lidera, decide, executa. Dono do PRD.	Daily standup + #backstage-daily	Diário + contínuo
Gab	Líder Migração	Parceiro crítico — Backstage depende da Migração	Sync Backstage × Migração (quinta 13:30) + sync bilateral	Semanal

Tier 2 — Execução

Stakeholder	Papel	Classificação	Canal principal	Frequência
Alex	CRM & Revenue	Executor — Guardian de Taxonomia e LIA	Daily + Planning segunda	Daily
JP	Workflows & Automações	Executor — Guardian de Workflows & n8n	Daily + Planning segunda	Daily
Duda	Operations	Executor — Guardian de Design System	Daily + Planning segunda	Daily
Giovanna	CS	Executor — Representante Customer Success	Daily + Planning segunda	Daily
Clariny	Finance & Data	Executor — Par do VDC. Guardian RH	Daily + pair direto com VDC	Daily

Tier 3 — Consumo & Input

Stakeholder	Papel	Classificação	Canal principal	Frequência
Didico	Gerente Aquisição, Líder GTM	Consumidor — Precisa do CRM OS e dashboards	Demo sexta + Sync quinta	Bi-weekly demo
Carol	Gerente CS	Consumidora — Precisa do módulo CS funcional	Demo sexta + Sync quinta	Bi-weekly demo
Time Migração	Humberto, Rik	Dependência — Trabalho alimenta Backstage com dados	Via Gab no Sync quinta 13:30	Via Gab

Matriz Poder x Interesse

• Alto Poder + Alto Interesse: VDC, Ju R, Gab → Gerenciar de perto
• Médio Poder + Alto Interesse: Didico, Carol, Alex → Manter informados
• Alto Interesse: JP, Duda, Giovanna, Clariny → Apoiar e direcionar
• Médio Interesse: Time Migração (Humberto, Rik) → Monitorar

Caminhos de Escalação

NÍVEL 1 — Execução (resolução em <4h)
├── Bloqueio técnico → #backstage-bloqueios → Senior do par resolve
├── Dúvida de spec → Mini-PRD ou #backstage-daily → VDC responde
└── Bug em produção → #backstage-bloqueios → Quem introduziu + senior

NÍVEL 2 — Liderança (resolução em <24h)
├── Bloqueio técnico não resolvido → Sync quarta com VDC
├── Bloqueio de dependência (Migração) → VDC alinha com Gab
├── Conflito de prioridade entre gates → VDC decide
└── Bloqueio CS/Aquisição → Carol/Didico resolve em 24h ou escala

NÍVEL 3 — Sponsor (resolução em <48h)
├── Bloqueio de dependência cross-projeto → VDC escala para Ju
├── Mudança estrutural no PRD → VDC propõe, Ju aprova
├── Conflito entre projetos (Backstage vs Migração) → Ju arbitra
└── Risco crítico materializado (R1, R4, R7) → Ju + VDC definem plano B

Comunicação por Ritual

Ritual	Stakeholders presentes	Output para quem não está
Daily standup (Seg-Sex 9h)	Time completo (VDC, Alex, JP, Duda, Giovanna, Clariny)	—
Sprint planning (Seg 9h30)	Time completo	Cards no board
Sync técnico (Qua 14h)	VDC + devs	Decisões no changelog
Comitê Produto & Backstage (Qui)	+ Gab, Carol, Didico	Ata compartilhada
Demo & Report (Sex)	Empresa toda	Gravação + report async
Sprint retro + PRD review (Sex 16h)	Time completo	Changelog atualizado

---

CHANGELOG

Data	Versão	Alteração	Autor
2026-03-09	1.0	Documento criado com diagnóstico real e plano completo	Guilherme + Claude
2026-03-09	2.0	Major update: Incorpora achados do code audit e PRD v8. G1 GL detalhado (85 contas, 5 engines). G3 CRM mais funcional (12 pgs, 100 files). G6 expandido para 17 integrações, Banco Inter ATIVO, +Resend/PostHog/Vapi. Oitiva com 4 crons. CEO=Ju (corrigido de Gab). Adicionados Carol (CS) e Didico (Aquisição) na liderança. Sprint 1 expandido com validação de produção, D14-D21, domain alignment. Adicionada PARTE 9 (14 MAs vs 7 Gates). Removidas referências a Omie. Atualizada comunicação (Slack sendo internalizado). Novos riscos R8-R10	Guilherme + Claude
2026-03-10	3.0	Modelo operacional: 3 Domain Pairs, workflow AI-First, cross-cutting guardians, AI como 7º membro. PARTE 10: AI Checks Pipeline	Guilherme + Claude
2026-03-10	4.0	Riscos e Stakeholders: PARTE 11 — 10 riscos estratégicos. PARTE 12 — Mapa de stakeholders em 3 tiers	Guilherme + Claude
2026-03-11	5.0	Reestruturação completa: Time atualizado (Alex, JP, Duda, Giovanna, Clariny + AI 7º membro). Dupla Core + 4 Domínios (não mais 3 Domain Pairs). Semana 0 (11-16 mar) com investigação per-person. Planning 16/mar. Sprint 1 começa 17/mar. Gate percentuais atualizados com scoreboard funcional e2e. Todas as atribuições por sprint reescritas. Stakeholders atualizados (Ju R, Gab). Coerência com Super PRD v8	Guilherme + Claude