📊 Tracker
Fase 0 — Gestão Interativa do Projeto (deadline 30/abr)
🔍 Discovery
Estado Ideal de Cada Miniapp
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
- 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. - Para a IA: As seções "Estado Ideal", "APIs", "Telas", "Comportamentos" são a spec de construção. Use diretamente para gerar código.
- 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 | 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 |
| 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:
- Se bloqueia um gate inteiro → P0 (independente do resto)
- Se elimina ferramenta externa → sobe 1 nível (internalização = segurança + estabilidade)
- Se é quick win que desbloqueia P0 → faz primeiro (ex: Design System é P pequeno mas desbloqueia tudo)
- 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)
- 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
- 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
- Recebimentos: tela STUB, precisa de API + UI com dados reais de Iugu/Stripe
- Business Plan sem Google Sheets: dependência externa. Precisa ser 100% editável na UI
- Estruturas organizacionais: STUB. CRUD mínimo funcional necessário
- Gateway agnóstico: Iugu e Stripe funcionam mas são hardcoded. Precisa de adapter para trocar gateway = trocar config
- GL formalização: GL existe e é maduro, mas precisa ser documentado como hub central
- Validação em produção: DRE, balanço, DFC — verificar com dados reais que batem
- Close Management (P1, Campfire): NÃO EXISTE. Schemas
close_periods+close_checklist_itemsprecisam ser criados. Period lock no posting layer. Checklist de 12 itens. Flux analysis via CEO IA - Dunning Automation (P1, Campfire): PARCIAL.
collections.ts(335 linhas) edunning.tsexistem mas sem automação de envio (WhatsApp/email). Conectar com cron-service - AR Aging Report (P2): FALTA. Invoices têm status tracking mas sem visão consolidada por buckets (current/30/60/90/120+)
- Audit Trail UI (P2):
v2_accounting.audit_logexiste 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)
- Motor de sequences: Schema COMPLETO mas não existe cron que processa enrollments e envia emails. CRÍTICO.
- Dedup nativo: Ainda usa dedupHubspot() — precisa de dedup por v2_sales.companies.domain + contacts.email + phone
- HubSpot desligamento: Crons de sync ainda ativos. Precisa desabilitar após migrar dados
- Migrar dados HubSpot: Contacts, companies, deals históricos — decisão pendente
- Tracking opens/clicks/replies: Schema existe (step_executions) mas webhook processing não implementado
- 3 pipelines configuráveis: vendas (MA2), prestadores (MA11), CS (MA4) — hoje só vendas
- 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
- Outbound sem HubSpot: dedup + escrita nativos (depende CRM #2)
- Motor de sequences: depende CRM #2
- Oitiva integrada: métricas de Oitiva no scorecard do vendedor
- Commission forecast validado: time de vendas precisa confirmar modelo
- 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
- Playbooks: CRUD existe mas execução real (criar tasks, enviar emails) não funciona
- Retention offers wired: schema existe mas NÃO conectado a UI de cancelamento
- Health score validado: pesos dos 5 componentes NÃO foram validados por Carol
- Timeline unificada: mistura dados reais e mock em produção
- Dados de uso Studio: depende time Migração (Juju)
- 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
- Inbox: verificar se funciona end-to-end com dados reais em produção
- Chatbot: verificar se está operando com regras corretas
- Knowledge Base: verificar se está atualizada
- 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
- Histórico consolidado por cliente: msgs existem em v2_comms.conversations mas não linkadas ao Customer 360 de forma unificada
- SMS: stub (sem provedor configurado)
- 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
- Workflow execution e STUB: não executa ações reais
- Lead scoring processador: não existe cron que calcula scores
- 4 ações stub: send_sms, create_deal, webhook, internal_notification
- UI de monitoramento: sem dashboard de automações (logs, falhas, re-runs)
- Inventário de automações externas: Zapier, Make não mapeados
- Continuous Agents (Campfire): nenhum agent contínuo configurado com cron 5-15min
- On-Demand Agents (Campfire): nenhum agent agendado (weekly report, close prep, etc.)
- Confidence Thresholds (Campfire): config table não existe, UI não existe
- Agent Dashboard: sem visão de agent runs, success rate, actions taken/flagged
- 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
- Pagina /executive não existe: precisa ser criada do zero
- Consolidação de métricas: dados existem espalhados, falta view unificada
- Aquisição KPIs mostrando zeros: falta data binding
- Flux Analysis (Campfire): explicação de variações por IA não implementada
- Drill-down: métricas não linkam para módulos de origem
- 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
- KPIs diários vazios: falta data binding (telas existem, dados não)
- Lead scoring processador: não existe
- Cadências outbound: depende motor sequences (CRM #2)
- Atribuição de canal: rastrear de qual canal cada lead veio
- 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:
- Top priorities (hoje): 3-7 cards com "por que", "proximo passo", "botoes de ação"
- Metas e progresso: targets + tendência + gap
- Alertas: anomalias e riscos (com explicação da IA)
- Chat com IA: com ferramentas (gerar email, resumo, plano, checklist)
- 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
- Tudo: cockpit personalizado não existe. Precisa ser construido do zero
- Role detection: lógica de identificar role do usuário e mapear para cockpit
- Priority engine: lógica que rankeia prioridades por role
- API de métricas por role: filtrar KPIs relevantes por cargo/area
- CEO IA financial tools: apenas
fetch-financial-data.tsexiste (3 tools). Faltam 10 tools (benchmark Campfire) - 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
- Notificações push: verificar se funcionam
- Freeclaw no chat: integrar Freeclaw/OpenClaw como participante
- Feature parity com Slack: alertas críticos, menções, canais por area
- 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:
- VDC consolida todos os gaps e decisões
- VDC + Ju priorizam o que entra vs backlog
- Time estima esforço real baseado nos gaps
- Sprint planning com tarefas concretas
- 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:
- CRM — Desligamento HubSpot (MAIS CRÍTICO)
- Listar TODOS os campos do HubSpot que o time usa → verificar quais existem em v2_sales → listar os que faltam
- Decidir: migrar dados históricos (todos ou últimos 12 meses)?
- Testar: criar um lead no Backstage → acompanhar fluxo até virar deal → verificar se funciona sem HubSpot
-
Documentar: quais crons de sync HubSpot ainda rodam? Quais podem ser desligados?
-
CRM — Sequences (BLOQUEANTE para vendas)
- Listar as cadências de email que o time de vendas usa hoje (templates, frequência, triggers)
- Definir: quantas cadências precisam funcionar no MVP?
-
Validar: Golden Record — regras de merge estão corretas? Testou com duplicatas reais?
-
Vendas — Analytics e Commission
- Abrir cada tela de analytics e anotar: funciona com dados reais? Mostra zeros? Quais são consultadas semanalmente?
- Commission: modelo BDR 1% + Closer 5% está correto? Time de vendas confirma?
- ClickSign: contratos fluem em produção? Testar um fluxo real
-
Tactical planning: é usado? Se não, recomendar remoção
-
Aquisição — KPIs e Lead Scoring
- Abrir /aquisicao e listar quais KPIs mostram dados vs quais mostram zero
- Lead Hunter: é usado ativamente? Por quem? Com que frequência?
- Lead scoring: propor regras de qualificação (quais critérios definem um MQL?)
-
Consultar Didico: quais canais de aquisição são prioritários?
-
Marketing
- Listar ferramentas de marketing usadas FORA do Backstage (HubSpot Marketing, Mailchimp, etc.)
- Ads analytics (Google + Meta): dados estão atualizados? Testar
- 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:
- WhatsApp — Consolidação
- Mapear: WhatsApp é usado para quais fluxos hoje? (vendas? suporte? onboarding? todos?)
- Evolution API vs Cloud API: qual é o padrão? Manter os dois ou migrar para um?
- Templates: listar os que existem, quais são necessários, quem define conteúdo
- Testar: enviar e receber msg pelo Backstage → verificar se aparece no histórico do cliente
-
Automação de mensagens: entra na Fase 0?
-
Chat — Internalização Slack/Discord
- Testar: chat interno funciona? Alguém usa? Notificações push funcionam?
- Decidir: migrar histórico do Slack (import já existe) ou começar do zero?
- Decidir: migrar Discord? (import NÃO existe — precisa ser construído?)
- Listar canais necessários: por área? por projeto? por gate?
-
Freeclaw: como integrar como participante no chat?
-
Automações — Inventário Completo
- CRÍTICO: Listar TODAS as automações que rodam FORA do Backstage (Zapier, Make, scripts, crons manuais)
- Para cada uma: o que faz, criticidade (sem ela o que para?), pode ser migrada para Backstage?
- Workflow builder: necessário visual para Fase 0 ou basta configuração por código?
- Lead scoring: quem define as regras? Propor modelo inicial
-
Testar: marketing automations — quais ações funcionam vs quais são stub?
-
Oitiva — Validação
- Oitiva é usado ativamente? Por quem? Qual a frequência?
- Scorecards: critérios estão atualizados? Quem definiu?
- AI Evaluation Agent: qualidade das avaliações é boa? Comparar com avaliação manual
- 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:
- CS — Health Score (VALIDAÇÃO CRÍTICA)
- Os 5 componentes do health score estão corretos? Listar cada um com peso atual
- Para cada componente: o dado fonte é confiável? É atualizado automaticamente?
- Score < 40 dispara alerta? Onde? (Slack? Email? Backstage?)
-
Carol precisa VALIDAR pessoalmente os pesos e propor ajustes se necessário
-
CS — Playbooks
- Listar os playbooks CRÍTICOS para Fase 0 (onboarding, cliente em risco, NPS detractor)
- Para cada playbook: descrever step-by-step (trigger → ação 1 → ação 2 → resultado esperado)
-
Testar: CRUD de playbook funciona? Criar um playbook de teste e verificar
-
CS — Retention Offers
- Quais tipos de retention offer usar? (desconto %, meses grátis, upgrade, etc.)
- Como calcular? (baseado em risco + LTV + tempo de contrato?)
-
Quem aprova a offer? Workflow de aprovação?
-
CS — Timeline e NPS
- Giovanna: abrir /suporte/cliente/[orgId] para 5 clientes reais → anotar o que funciona vs o que mostra mock/vazio
- Quais informações são ESSENCIAIS na timeline vs nice-to-have?
-
NPS: frequência de envio? Quem responde? Quais ações por resultado (promoter, passive, detractor)?
-
Suporte — Validação de Produção
- Inbox: é o canal principal de atendimento? Funciona bem em produção?
- Chatbot: está em produção? Com quais regras? É útil?
- Knowledge Base: está atualizada? Quem mantém?
-
Performance: métricas de atendimento são consultadas?
-
CS — Clientes e Onboarding
- Quais clientes são prioritários para onboarding guiado vs self-service?
- 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:
- Prestadores — Uso Real
- Listar quais funcionalidades são usadas no dia a dia (Provider 360, KPIs, ranking, etc.)
- Ranking: como é calculado? O algoritmo está válido?
- Maria AI: insights são úteis para o time? Exemplos de uso
- Verificar: dados são reais e consistentes? Ou há mock/placeholder?
-
Consome CRM para dados de provider? Qual a dependência?
-
Design System — Cobertura
- Listar componentes usados consistentemente pelas miniapps de Fase 0
- Listar componentes FALTANTES que bloqueiam alguma miniapp (se houver)
- Designer's Bible: necessária na Fase 0 ou Fase 1?
- Tokens sincronizados com Figma? Se não, o que falta?
- 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:
- Wiki — Migração Notion
- Wiki é usada por alguém hoje? Quem?
- Notion import: migrar todo conteúdo ou selecionar os mais importantes?
- Quais spaces/categorias criar? Propor estrutura inicial
-
Testar: busca full-text funciona com conteúdo real?
-
Pessoas/RH — Funcionalidades
- Quais funções de RH são usadas hoje? (Org Chart? Payroll? Colaboradores?)
- Payroll integrado com sistema externo? Qual?
- Performance/PDI: está ativo ou parado?
-
hr-core e hr-sdk: são consumidos por outras áreas? Quais?
-
Suporte ao VDC — Management OS
- Financeiro: Recebimentos — quais dados devem aparecer? (Iugu, Stripe, manual?)
- Financeiro: Estruturas organizacionais — qual o escopo mínimo de CRUD?
- AI Cockpit: Role detection — como mapear cargo → cockpit? Propor tabela de mapeamento
- 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):
- Decisões Bloqueantes:
- 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
- Bancos: Listar TODOS os bancos da Freelaw. Para cada um: operações usadas, viabilidade de API, quem autoriza pagamentos
- Approval flow de pagamentos: Definir níveis por valor (< R$1k, < R$10k, > R$10k)
- Google Sheets pode ser eliminado do Business Plan na Fase 0?
- ERP (Freelaw One): entra na Fase 0? Se sim, qual escopo mínimo?
-
D16: compartilhar ou separar infra IA entre Backstage e Studio?
-
Templates e Regras:
- Templates de daily pulse por área (Vendas, CS, Marketing, Financeiro)
- Templates de weekly pulse por área
- Template de weekly report executivo (seções obrigatórias)
- Tipos de combinados (meta, tarefa, decisão?)
-
Workflow de cobrança de combinados
-
Métricas e Prioridades por Role:
- Para cada role (Vendas, CS, Marketing, Financeiro, Executivo): listar as 5 métricas mais importantes
- Prioridades: como rankear? (urgência × impacto × deadline?)
-
Quais métricas Ju/VDC querem ver ao abrir o Backstage?
-
Validações:
- Os 25 crons estão todos saudáveis? Listar os que falham
- Quais relatórios o CFO usa DIARIAMENTE vs semanalmente?
- Quais sub-módulos de /produto são usados ativamente?
- 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 |
📋 Super PRD v10
O QUE construir
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/aicom 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 emceo-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.ts49.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 anynovo - 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:
- 29 route domains no filesystem (cresceram organicamente)
- 11 sidebar sections na UI (curadoria manual)
- 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, semperiod_lock, semclose_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.mdseção 3.3). - Dunning Automation → PARCIAL:
collections.ts(335 linhas) tem tracking com stages (30_60d, 60_90d, 90_plus) e dunning pipeline emstudio-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.invoicestem status tracking, mas sem view consolidada com buckets (current, 30, 60, 90, 120+ dias) - AP Nativo → 15%:
approval_requeststable 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 dodunning.tsexistente (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_requestsexistente) + 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/auditcom filtros por período, conta, tipo, user — sobrev2_accounting.audit_logexistente
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.tsque já tem confidence metadata nos WorkerOutputs. - [ ] Agent Dashboard: UI mostrando agents ativos, última execução, ações tomadas. Dados:
agent_executionstable (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.tspara gerar DREs efetchFinancialDataToolpara dados. Tool novo:flux_analysis(period_a, period_b)retorna variações + commentary - [ ] Drill-down universal: CADA métrica no
/executivecom 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.tsxque 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 |
| 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
- Toda transação financeira → lançamento contábil → General Ledger
- Ciclo de vida completo do cliente — do primeiro touchpoint até offboarding
- Single source of truth por domínio — cada dado tem UM owner
- 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_idpara multi-tenancy - Schemas nomeados:
v2_billing,v2_sales,v2_marketing,v2_comms,crm,sync— nuncapublic - 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_accountingjá 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:
- [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:
- [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 |
⚡ Plano de Trabalho
COMO construir
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
- Uma pessoa = uma missão por sprint. Sem context switching. Se você está no G2, você só faz G2.
- Vertical first. Termina um fluxo end-to-end antes de começar outro.
- Demo ou não existiu. Toda sexta, cada pessoa demonstra o que entregou funcionando.
- 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.
- PRD é bounding. Se não está neste documento, não entra no sprint. Mudanças passam por Guilherme.
- Zero construção no legado. Toda energia no monorepo.
- 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
-
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.
-
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. -
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.
-
MA13 (LIA): AI features são transversais. Requer definição de onde IA agrega valor (classificação, geração, automação) antes de implementar.
-
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 |
⚙️ Sistema
Arquitetura, DS e CI/CD
BACKSTAGE — SISTEMA: Arquitetura, Design System e CI/CD
Documento de controle técnico do monorepo Freelaw.
Para o PRD geral, vejabackstage-prd.md. Para o Discovery, vejabackstage-discovery.md.
Versão: 1.2 | Data: 2026-03-15 | Atualizado: 2026-03-16 07:00 UTC
Owner: Guilherme (VDC) | Maintainer técnico: Time Backstage
Como os 3 apps interagem
10+ tabelas"] S2["v2_sales
20 tabelas"] S3["v2_cs
14 tabelas"] S4["v2_accounting
12 tabelas"] S5["core
14 tabelas"] S6["+ 12 schemas"] end BS["🎛️ BACKSTAGE
Ops Platform
783 TSX · 351 routes"] SO["⚖️ STUDIO OFFICES
App Advogados
742 TSX · 101 páginas"] SP["👷 STUDIO PROVIDERS
Portal Prestadores
6 TSX"] BS --> DB SO --> DB SP --> DB subgraph PKG["📦 PACKAGES COMPARTILHADOS"] P1["@freelaw/ui"] P2["@freelaw/core"] P3["@freelaw/infra-db"] P4["@freelaw/observability"] end BS --> PKG SO --> PKG SP --> PKG style DB fill:#f0f9ff,stroke:#3b82f6,stroke-width:2px style PKG fill:#f5f0ff,stroke:#7c3aed,stroke-width:2px style BS fill:#fef3c7,stroke:#f59e0b,stroke-width:2px style SO fill:#ecfdf5,stroke:#10b981,stroke-width:2px style SP fill:#fef2f2,stroke:#ef4444,stroke-width:2px
Princípios arquiteturais
1.1 Estrutura Correta e Ideal (Target)
Sistema de Tiers
(cross-cutting — qualquer tier)"] APPS --> T3 APPS --> T2 APPS --> T1 T3 --> T2 T3 --> T1 T2 --> T1 OBS -.-> T1 OBS -.-> T2 OBS -.-> T3 OBS -.-> APPS style T1 fill:#dbeafe,stroke:#3b82f6,stroke-width:2px style T2 fill:#f3e8ff,stroke:#7c3aed,stroke-width:2px style T3 fill:#dcfce7,stroke:#10b981,stroke-width:2px style APPS fill:#fef3c7,stroke:#f59e0b,stroke-width:2px style OBS fill:#f1f5f9,stroke:#64748b,stroke-width:1px,stroke-dasharray: 5 5
Regras de importação
• Core NÃO importa de infra ou UI
• UI NÃO importa de infra (exceto observability)
• Mobile NÃO importa de @freelaw/infra-db
• Packages NÃO têm dependências circulares
Onde colocar código novo
| Tipo de código | Local correto |
|---|---|
| Componente UI reutilizável | packages/ui/src/ |
| Type/Schema Zod | packages/core/src/ |
| Feature Backstage | apps/backstage/src/ |
| Feature advogados | apps/studio-offices/src/ |
| Feature prestadores | apps/studio-providers/src/ |
| Database schema | packages/infra/db/src/schemas/ |
| AI prompt | packages/ai/src/prompts/ |
| Server actions | apps/{app}/src/actions/ |
| DB repositories | packages/infra/db/src/repositories/ |
Mapa de API Routes — Backstage (351 routes)
📋 Todas as 351 routes por módulo (expandir)
| Módulo | Routes | Descrição |
|---|---|---|
| Financeiro | 52 | Business Plans, Reconciliação, Billing, Budgets, DRE, MRR |
| Vendas | 42 | Goals, Funnels, HubSpot sync, Deals, Métricas, Performance |
| Prestadores | 35 | Orders, Performance, KPIs, Incidents, Rankings |
| Cron Jobs | 30 | Sync, ETL, Analytics, Billing, Health Scores |
| Oitiva | 17 | Evaluations, Scorecards, Transcriptions, Dashboard |
| Ads/Marketing | 17 | Campaigns, Analytics, Insights, Creatives, Sync |
| Chat | 15 | Channels, Slack import, Threads, Reactions, Presence |
| Customer Success | 14 | Health Scores, NPS, Churn, Renewals, Retention |
| CRM | 13 | Contacts, Companies, Deals, Pipelines, Activities |
| 12 | Connections, Messages, QR, Team conversations | |
| Wiki | 11 | Documents, Databases, Notion import, Search |
| Auth | 10 | Login, CLI device flow, ContaAzul OAuth |
| RH | 10 | Analytics, Org chart, Headcount, Payroll |
| Automações | 10 | Scoring, Sequences, Enrollments, Attribution |
| Workflows | 8 | Templates, Execution, Variables, N8N import |
| Dashboards | 8 | Stats, Reports, Goals, Executive |
| Email/Content | 8 | Campaigns, Lists, Sequences, Templates |
| OpenClaw | 7 | Agents, Runtime, Collab, Upstream |
| Admin | 5 | Credits, Organizations, HubSpot catchup |
| AI | 5 | Churn, Predictions, Recommendations, Edit |
| Social Media | 5 | Accounts, Analytics, Calendar, Inbox, Posts |
| Webhooks | 5 | Evolution, Meta, Resend, VAPI, WhatsApp Cloud |
| Newsletter | 4 | CRUD, Publish, Generate |
| Billing | 3 | DLQ, Invoice validation |
| Sync | 3 | ContaAzul, Historical import, Iugu |
| Planejamento | 3 | Chat, Ciclos, Visão 2030 |
| Voice | 2 | Calls list, Call detail |
| Experiments | 2 | A/B tests, Feature flags |
| Outros | 5 | Health, Profile, PostHog, Support |
💰 Detalhe — Financeiro (52 routes)
| Rota | Método | Descrição |
|---|---|---|
/financeiro/analytics |
GET | Analytics financeiro consolidado |
/financeiro/assinaturas |
GET | Listar assinaturas |
/financeiro/assinaturas/sync |
POST | Sincronizar assinaturas |
/financeiro/balanco |
GET | Balanço patrimonial |
/financeiro/billing |
GET | Dados de billing |
/financeiro/budget |
GET, POST, PUT, DELETE | CRUD de orçamento |
/financeiro/budget/sync-contaazul |
GET, POST | Sync com ContaAzul |
/financeiro/budget/sync-sheets |
GET, POST | Sync com Google Sheets |
/financeiro/business-plan |
GET, POST, PUT | CRUD Business Plan |
/financeiro/business-plan/[id] |
GET, DELETE | Detalhe/deletar BP |
/financeiro/business-plan/[id]/export-sheets |
POST | Exportar BP para Sheets |
/financeiro/business-plan/[id]/import-sheets |
POST | Importar de Sheets |
/financeiro/business-plan/[id]/realizado |
GET | Realizado vs planejado |
/financeiro/business-plan/[id]/recalculate |
POST | Recalcular cenários |
/financeiro/business-plan/[id]/scenarios |
GET, PUT | Cenários do BP |
/financeiro/business-plan/[id]/tab/[tabName] |
GET, PUT | Tabs individuais |
/financeiro/business-plan/[id]/versions |
GET, POST | Versionamento |
/financeiro/churn-alert |
GET | Alertas de churn |
/financeiro/churn-dashboard |
GET | Dashboard de churn |
/financeiro/conciliacao |
GET | Conciliação bancária |
/financeiro/configuracoes/categorias |
GET, POST, PUT, DELETE | Categorias |
/financeiro/configuracoes/centros-custo |
GET | Centros de custo |
/financeiro/configuracoes/estruturas |
GET | Estruturas contábeis |
/financeiro/despesas |
GET | Despesas |
/financeiro/dfc |
GET | DFC (Fluxo de caixa) |
/financeiro/dre |
GET | DRE |
/financeiro/dre/auditoria |
GET | Auditoria DRE |
/financeiro/dre/validate |
GET | Validação DRE |
/financeiro/enviar-slack |
POST | Enviar report via Slack |
/financeiro/etl |
POST | ETL financeiro |
/financeiro/faturamento |
GET | Faturamento |
/financeiro/inadimplencia |
GET | Inadimplência |
/financeiro/inadimplencia/recorrentes |
GET | Inadimplentes recorrentes |
/financeiro/indicadores |
GET | Indicadores financeiros |
/financeiro/nova-sede |
GET, POST, DELETE | Simulação nova sede |
/financeiro/novo-mrr |
GET | Novo MRR |
/financeiro/overview |
GET | Overview financeiro |
/financeiro/prestadores/process-withdraw |
POST | Processar saque prestador |
/financeiro/reconciliacao/executar |
POST | Executar reconciliação |
/financeiro/reconciliacao/regras |
GET, POST | Regras de reconciliação |
/financeiro/reconciliacao/resolver |
POST | Resolver pendência |
/financeiro/relatorio-diario |
GET | Relatório diário |
/financeiro/sync/historico |
GET, POST | Sync histórico |
/financeiro/unit-economics |
GET | Unit economics |
/financeiro/webhooks/iugu |
GET, POST | Webhook Iugu |
/financeiro/webhooks/stripe |
GET, POST | Webhook Stripe |
/financeiro/admin/cleanup-legacy-postings |
GET, POST | Limpeza postings |
/financeiro/admin/users |
GET | Listar usuários financeiro |
/financeiro/admin/users/toggle-status |
POST | Toggle status usuário |
📊 Detalhe — Vendas (42 routes)
| Rota | Método | Descrição |
|---|---|---|
/vendas/activities |
GET, POST | Atividades de vendas |
/vendas/analytics/churn-cohort |
GET | Análise cohort churn |
/vendas/bdrs |
GET, POST | CRUD BDRs |
/vendas/bdrs/[id] |
GET, PATCH, DELETE | Detalhe BDR |
/vendas/clicksign/* |
GET, POST | ClickSign integration (3 routes) |
/vendas/dashboard/* |
GET | Dashboard stats (4 routes) |
/vendas/deals |
GET, POST | CRUD deals |
/vendas/deals/[id] |
GET, PATCH, DELETE | Detalhe deal |
/vendas/funnels |
GET, POST | CRUD funis |
/vendas/funnels/[id] |
GET, PATCH, DELETE | Detalhe funil |
/vendas/goals/* |
GET, POST, PATCH, DELETE | Metas e planos (10 routes) |
/vendas/hubspot/* |
GET, POST | HubSpot sync (4 routes) |
/vendas/metrics/* |
GET | Métricas (4 routes) |
/vendas/outbound/* |
GET, POST | Outbound runs (4 routes) |
/vendas/performance/* |
GET | Performance (2 routes) |
/vendas/routing |
GET, PATCH, POST | Roteamento de leads |
/vendas/sales-people |
GET, POST | CRUD vendedores |
/vendas/sales-people/[id] |
GET, PATCH, DELETE | Detalhe vendedor |
/vendas/tactical-plans |
GET, POST, PATCH, DELETE | Planos táticos |
🤝 Detalhe — Customer Success (14 routes)
| Rota | Método | Descrição |
|---|---|---|
/customer-success/churn |
GET | Dados de churn |
/customer-success/churn-events |
GET, POST | Eventos de churn |
/customer-success/churn-events/import-sheets |
POST | Importar churn de Sheets |
/customer-success/health |
GET, POST | Health scores |
/customer-success/health/[companyId] |
GET | Health de empresa |
/customer-success/health/[companyId]/history |
GET | Histórico health |
/customer-success/journey |
GET | Jornada do cliente |
/customer-success/nps |
GET, POST, PATCH, DELETE | CRUD NPS |
/customer-success/nps/campaigns |
GET | Campanhas NPS |
/customer-success/nps/score |
GET | Score NPS |
/customer-success/playbooks |
GET | Playbooks de CS |
/customer-success/renewals |
GET, POST, PATCH, DELETE | CRUD renewals |
/customer-success/renewals/risk-stats |
GET | Stats de risco |
/customer-success/retention-offers |
GET, POST | Ofertas de retenção |
⏰ Detalhe — Cron Jobs (30 routes)
| Rota | Método | Descrição |
|---|---|---|
/cron/ads-* |
GET, POST | Reports e alertas de Ads (4 routes) |
/cron/automations |
GET, POST | Processar automações |
/cron/billing-etl |
GET, POST | ETL de billing |
/cron/churn-prediction |
GET, POST | Predição de churn |
/cron/cleanup-oitiva-data |
GET, POST | Limpeza dados Oitiva |
/cron/cohort-analysis |
GET, POST | Análise cohort |
/cron/delinquency-pipeline |
GET, POST | Pipeline inadimplência |
/cron/finance/reconciliation |
GET, POST | Reconciliação financeira |
/cron/health-scores |
GET, POST | Calcular health scores |
/cron/hubspot-* |
GET, POST | Sync HubSpot (2 routes) |
/cron/lead-scoring |
GET, POST | Scoring de leads |
/cron/mrr-waterfall |
GET, POST | Waterfall MRR |
/cron/openclaw-runtime |
GET, POST | Runtime OpenClaw |
/cron/process-* |
GET, POST | Processamentos (3 routes) |
/cron/refresh-* |
GET | Refresh tokens (2 routes) |
/cron/submit-pending-withdrawals |
GET, POST | Submeter saques |
/cron/sync-* |
GET, POST | Sync jobs (6 routes) |
/cron/validate-pending-invoices |
GET, POST | Validar faturas |
API Contracts (19 módulos tipados)
| Módulo | Endpoints | Descrição |
|---|---|---|
| analytics | 5 | Summary, Revenue, Productivity, Export |
| auth | 9 | Login, Refresh, Logout, CLI device flow |
| billing | 6 | Checkout, Portal, Credits |
| calendar | 5 | Events CRUD, Stats, Today, Week |
| cases | 3 | Processos jurídicos CRUD |
| chat | 4 | Send, Conversations CRUD |
| clients | 3 | Clientes CRUD |
| dashboard | 5 | Main, Mobile, Summary, Deadlines, Activities |
| deadlines | 7 | CRUD, Stats, Critical, This week |
| documents | 5 | CRUD, Upload, Download |
| finance | 8 | Transactions, Summary, Cash flow |
| notifications | 7 | CRUD, Read, Archive, Preferences |
| payments | 8 | CRUD, Pay, Boleto, PIX |
| petitions | 7 | CRUD, Generate, Progress, Export |
| publications | 8 | CRUD, Read, Archive, Stats |
| settings | 9 | Profile, Preferences, Organization |
| tasks | 5 | CRUD, Complete, Reopen |
| 13 | Evolution, Chats, Messages, Send |
1.2 Estrutura Atual e Diffs
0 arquivos com @ts-nocheck — bypass do type system (CRÍTICO)
9 schemas com z.any() — validação fraca (ALTO)
APIs que precisam de refactor
| Módulo | Problema | Prioridade |
|---|---|---|
| Financeiro/budget | P0 Dependência de ContaAzul (substituir) | |
| Financeiro/budget | P0 Dependência de Google Sheets | |
| Vendas/hubspot | P0 HubSpot deve ser eliminado (CRM nativo) | |
| Auth/contaazul | P0 Remover após substituição ContaAzul | |
| Cron/hubspot-sync | P1 Remover após migração CRM | |
| Cron/sync-notion | P2 Notion será Wiki nativa | |
| Cron/sync-slack | P2 Slack será Chat nativo |
1.3 Registro de Alterações
| Data | Versão | Alteração | Autor |
|---|---|---|---|
| 2026-03-12 | 1.0 | Documento criado com dados reais do monorepo | Guilherme + Claude |
2.1 Estrutura Correta e Ideal (Target)
Mapa de Schemas
14 tabelas"] billing["💳 v2_billing
10+ tabelas"] accounting["📒 v2_accounting
12 tabelas"] sales["📊 v2_sales
20 tabelas"] cs["🤝 v2_cs
14 tabelas"] sync["🔄 v2_sync
4 tabelas"] infra["⚙️ v2_infra
3 tabelas"] end subgraph PENDING["⏳ SCHEMA-ONLY (aguardando ETL)"] ai["🤖 v2_ai
6 tabelas"] comms["💬 v2_comms
11 tabelas"] hr["👥 v2_hr
6 tabelas"] metrics["📈 v2_metrics
5 tabelas"] marketing["📣 v2_marketing
5 tabelas"] providers["👷 v2_providers
5 tabelas"] legal["⚖️ v2_legal_data
5 tabelas"] knowledge["📚 v2_knowledge
5 tabelas"] delegations["🤝 v2_delegations
13 tabelas"] end core --> billing core --> sales core --> cs core --> accounting billing --> sync style ACTIVE fill:#ecfdf5,stroke:#10b981,stroke-width:2px style PENDING fill:#fef9c3,stroke:#f59e0b,stroke-width:2px
🔵 Schema Core — 14 tabelas (fundação de tudo)
| Tabela | Colunas-chave | RLS |
|---|---|---|
| organizations | id, name, email, subscription_tier, owner_id, stripe_customer_id, slug | ✅ |
| users | id, organization_id, email, full_name, role, is_active | ✅ |
| permissions | id, resource, action, name, access_pii | ✅ |
| user_permissions | id, user_id, permission_id, expires_at | ✅ |
| permission_delegations | id, delegator_id, delegate_id, permission_id | ✅ |
| organization_members | id, user_id, organization_id, role | ✅ |
| organization_invites | id, organization_id, email, token, status | ✅ |
| organization_oabs | id, organization_id, oab_number, oab_state | ✅ |
| onboarding_steps | id, name, category, display_order | ✅ |
| user_onboarding_status | id, user_id, onboarding_completed | ✅ |
| user_onboarding_progress | id, user_id, organization_id, step_id | ✅ |
| user_formatting_preferences | id, user_id, font_family, font_size | ✅ |
| user_style_memory | id, user_id, organization_id, memory_type | ✅ |
| feature_usage | id, user_id, organization_id, feature_name | ✅ |
💳 Schema v2_billing — 10+ tabelas (assinaturas, faturas, créditos)
Enums: plan_type, billing_cycle, subscription_status, invoice_status, credit_type, payment_gateway
| Tabela | Colunas-chave | RLS |
|---|---|---|
| customers | id, organization_id, email, cpf_cnpj, iugu_customer_id, stripe_customer_id | ✅ |
| plans | id, code, name, type, price_in_cents, billing_cycle | ❌ |
| subscriptions | id, organization_id, plan_id, customer_id, status, gateway | ✅ |
| subscription_events | id, subscription_id, event_type, occurred_at | ✅ |
| invoices | id, subscription_id, organization_id, invoice_number, status, total_in_cents | ✅ |
| invoice_items | id, invoice_id, description, quantity, unit_price_in_cents | ✅ |
| ai_credits | id, organization_id, type, amount, balance, expires_at | ✅ |
| credit_usage | id, credit_id, organization_id, user_id, amount, action | ✅ |
| coupons | id, code, discount_type, discount_value, max_uses | ❌ |
| retention_offer_configs | id, offer_type, discount_percent, duration | ❌ |
📒 Schema v2_accounting — 12 tabelas (contabilidade, bancos, orçamentos)
Enums: account_type, transaction_type, transaction_status, approval_status, alert_severity, entry_type
| Tabela | Colunas-chave | Relações |
|---|---|---|
| chart_of_accounts | id, organization_id, code, name, type, parent_id, level | Self-referencing |
| cost_centers | id, organization_id, code, name, parent_id, manager_id | Self-referencing |
| vendors | id, organization_id, name, cpf_cnpj, category | → organizations |
| bank_accounts | id, organization_id, account_id, bank_name, current_balance_in_cents | → chart_of_accounts |
| transactions | id, organization_id, bank_account_id, vendor_id, type, amount_in_cents | → bank_accounts, vendors |
| transaction_allocations | id, transaction_id, account_id, entry_type, amount_in_cents | → transactions, CoA, cost_centers |
| budgets | id, organization_id, fiscal_year, total_amount_in_cents, status | → organizations |
| budget_lines | id, budget_id, account_id, month, planned_amount_in_cents | → budgets, CoA |
| bank_reconciliations | id, bank_account_id, statement_date, difference_in_cents | → bank_accounts |
| approval_requests | id, organization_id, entity_type, entity_id, status, amount_in_cents | → organizations |
| alerts | id, organization_id, type, severity, title, is_read | → organizations |
| audit_log | id, organization_id, user_id, action, entity_type, old_value, new_value | → orgs, users |
📊 Schema v2_sales — 20 tabelas (CRM, leads, deals, pipelines)
Enums: lead_status, lead_source, opportunity_stage, activity_type, deal_status, pipeline_type, sequence_status
| Tabela | Colunas-chave |
|---|---|
| leads | id, organization_id, owner_id, email, phone, company, status, source, score |
| opportunities | id, lead_id, owner_id, name, stage, amount_in_cents |
| activities | id, lead_id, opportunity_id, contact_id, owner_id, type |
| proposals | id, opportunity_id, lead_id, proposal_number, status, amount_in_cents |
| sales_targets | id, user_id, period, year, target_amount_in_cents |
| scorecards | id, name, category, is_active, version |
| scorecard_criteria | id, scorecard_id, name, weight |
| transcriptions | id, seller_id, transcription_text, duration_seconds |
| evaluations | id, transcription_id, scorecard_id, status, overall_score |
| evaluation_scores | id, evaluation_id, criterion_id, score, justification |
| companies | id, name, type, industry, employee_count |
| contacts | id, company_id, email, phone, status, lifecycle_stage |
| deals | id, contact_id, company_id, name, value_in_cents |
| pipelines | id, name, type |
| sales_sequences | id, name, status |
| sequence_steps | id, sequence_id, type, delay_minutes, order |
| sequence_enrollments | id, sequence_id, contact_id, status |
| step_executions | id, enrollment_id, step_id, status |
🤝 Schema v2_cs — 14 tabelas (customer success, health, churn)
Enums: health_status, ticket_status, ticket_priority, churn_risk_level, retention_offer_type, renewal_status
| Tabela | Colunas-chave |
|---|---|
| customer_health | id, organization_id, status, overall_score, engagement_score |
| nps_responses | id, user_id, campaign_id, score, feedback |
| support_tickets | id, user_id, assigned_to, ticket_number, status, priority |
| onboarding_progress | id, user_id, status, progress_percent |
| churn_predictions | id, organization_id, risk_level, risk_score |
| churn_events | id, organization_id, event_type, triggered_at |
| retention_offers | id, organization_id, offer_type, status |
| renewal_tracking | id, organization_id, renewal_date, status |
| survey_campaigns | id, survey_type, status |
| support_providers | id, provider_type, name, is_active |
| support_channels | id, provider_id, channel_type, phone_number |
| support_contacts | id, provider_id, external_contact_id, email |
| support_conversations | id, provider_id, contact_id, channel_id, status |
| support_messages | id, conversation_id, ticket_id, direction, content |
📦 Schemas complementares (v2_ai, v2_comms, v2_hr, v2_metrics, etc.)
| Schema | Tabelas | Status | Principais tabelas |
|---|---|---|---|
| v2_sync | 4 | ✅ Ativo | iugu_customers, iugu_subscriptions, iugu_invoices |
| v2_ai | 8 | ⏳ Schema-only | conversations, messages, embeddings, ai_usage, confidence_configs, agent_runs |
| v2_comms | 11 | ⏳ Schema-only | notifications, email_logs, conversations, messages, automationRules |
| v2_hr | 6 | ⏳ Schema-only | departments, employees, payroll, okrs |
| v2_metrics | 5 | ⏳ Schema-only | kpi_definitions, kpi_values, dashboards, widgets |
| v2_marketing | 5 | ⏳ Schema-only | campaigns, email_campaigns, landing_pages |
| v2_providers | 5 | ⏳ Schema-only | profiles, services, service_orders |
| v2_legal_data | 5 | ⏳ Schema-only | cases, movements, deadlines, documents |
| v2_knowledge | 5 | ⏳ Schema-only | articles, categories, faqs, feedback |
| v2_delegations | 13 | ⏳ Schema-only | delegations, messages + 11 ciclo de vida |
| v2_infra | 3 | ✅ Ativo | migration_checkpoints, id_mappings, feature_flags |
Padrões de dados obrigatórios
Workflow de alteração de schema
packages/infra/db/src/schemas/v2/"] --> B["2️⃣ .enableRLS()
se user-facing"] B --> C["3️⃣ Core type
packages/core/src/"] C --> D["4️⃣ Mapper
(3 arquivos mín.)"] D --> E["5️⃣ db:generate
gerar migration"] E --> F["6️⃣ db:push
aplicar (dev)"] style A fill:#dbeafe,stroke:#3b82f6 style B fill:#fef2f2,stroke:#ef4444 style C fill:#f3e8ff,stroke:#7c3aed style D fill:#fef9c3,stroke:#f59e0b style E fill:#dcfce7,stroke:#10b981 style F fill:#ecfdf5,stroke:#059669
2.2 Estrutura Atual e Diffs
• Schemas legacy (public) ainda em uso pelo studio-offices
• v2_accounting — dados vêm de ContaAzul (será substituído)
• v2_sales — dados duplicados entre CRM nativo e HubSpot
• v2_comms — schema existe mas sem infra unificada
• v2_metrics — KPIs calculados ad-hoc, sem materialização
• Close Management NÃO EXISTE — v2_accounting não tem close_periods nem close_checklist_items (padrão Campfire: reduz close de 15 para 3 dias)
• v2_ai sem confidence_configs — thresholds por tipo de ação (>95% auto, 70-95% review, <70% flag) não implementados
Schemas a criar — Close Management (v2_accounting)
Benchmark Campfire.ai: Month-End Close com checklist, period lock e flux analysis reduz close de 15 para 3 dias.
| Tabela | Colunas-chave | Relações |
|---|---|---|
| close_periods | id, organization_id, period_start, period_end, status (open/in_review/locked), locked_by, locked_at, checklist_progress_pct | → organizations |
| close_checklist_items | id, close_period_id, title, category (reconciliation/review/approval/posting), status (pending/in_progress/done/skipped), assigned_to, completed_at, evidence_url | → close_periods, users |
Period Lock pattern: quando close_periods.status = 'locked', TODAS as posting APIs (finance-posting.ts, contaazul-posting.ts, inter-posting.ts) devem checar e rejeitar writes para aquele período. Implementar via middleware no posting layer.
Checklist padrão (12 itens):
1. Reconciliar Iugu vs GL
2. Reconciliar Banco Inter vs GL
3. Verificar faturas em aberto >30d
4. Revisar lançamentos manuais
5. Validar DRE vs mês anterior (flux analysis)
6. Revisar alocações por centro de custo
7. Verificar budget vs realizado (alertar desvios >10%)
8. Confirmar posting engines sem erros pendentes
9. Gerar relatório de inadimplência
10. Aprovar DRE final
11. Aprovar DFC final
12. Lock do período (irreversível sem aprovação C-level)
Schemas a criar — AI Confidence (v2_ai)
| Tabela | Colunas-chave | Relações |
|---|---|---|
| confidence_configs | id, organization_id, action_type, auto_threshold (default 95), review_threshold (default 70), requires_human_approval | → organizations |
| agent_runs | id, agent_name, trigger_type (continuous/on_demand/manual), started_at, completed_at, actions_taken, actions_flagged, confidence_avg | — |
Código existente que suporta: packages/ai/src/ai/agent-orchestrator.ts já tem confidence no WorkerOutput.metadata. Falta: (1) config table para thresholds por ação, (2) UI para configurar, (3) logging de runs.
Arquitetura de AI Agents (padrão Campfire Ember Agents)
Continuous Agents (via cron-service, interval 5-15min):
| Agent | Função | Código existente | A construir |
|---|---|---|---|
| Financial Guardian | Detecta anomalias em transactions, alerta desvios >10% | cost-alerts.ts (50/80/95/100%) |
Expandir para monitoring contábil contínuo |
| Reconciliation Auto | Compara extrato banco × GL automaticamente | reconciliation-matcher.ts (confidence scoring) |
Evoluir para auto-matching >95% |
| Dunning Processor | Escala cobrança automática por aging | collections.ts (335 linhas), dunning.ts (D+0/3/7/30) |
Conectar com WhatsApp/email |
| Health Score Monitor | Recalcula scores, detecta drops significativos | Cron health scores existe | Adicionar alertas em tempo real |
| Churn Signal Detector | Cruza billing + usage + NPS para prever churn | churn-prediction cron existe |
Evoluir modelo, conectar com playbooks |
On-Demand Agents (scheduled/event-triggered):
| Agent | Função | Trigger | A construir |
|---|---|---|---|
| Close Prep | Pré-preenche checklist do close baseado em dados | 1º dia útil do mês | Schema close_periods + lógica |
| Weekly Report | CEO IA gera report semanal automatizado | Domingo 20h | ceo-ia-agent.ts já tem 16 etapas, falta agendar |
| Commission Calc | Calcula comissões BDR/Closer/Partner | Deal won event | Commission logic existe, falta trigger automático |
| Flux Analyst | Compara DRE mês atual vs anterior, explica variações | Close de período | dre-builder.ts + gl-queries.ts como base |
| Metric Snapshot | Snapshot diário de KPIs para trending | Diário 23h59 | unit-economics-calc.ts como base |
10 billing crons em cron-service/src/routes/billing/ ainda são STUBS — precisam ser migrados para os agents acima ou implementados diretamente.
2.3 Registro de Alterações
| Data | Versão | Alteração | Autor |
|---|---|---|---|
| 2026-03-12 | 1.0 | Inventário completo de schemas | Guilherme + Claude |
| 2026-03-15 | 1.2 | Close Management schemas, AI Confidence schemas, Continuous + On-Demand Agents architecture, ARCH-07/ARCH-08 (benchmark Campfire.ai) | Guilherme + Claude |
3.1 Estrutura Correta e Ideal (Target)
Stack do Design System
Componentes customizados
| Componente | Categoria | Descrição |
|---|---|---|
| DeadlineBadge | Status | Badge com urgência auto-calculada. Pulse animation em itens críticos |
| ExpandableCard | Container | Card expansível com stripe indicator, seleção com checkbox |
| FilterChips | Filtros | Multi/single-select chips com icons e contadores |
| FloatingActionsBar | Ações | Toolbar flutuante para ações em lote. Responsivo |
| StatsFilter | Filtros | Stats clicáveis que filtram. 3 variantes: pills, cards, minimal |
| Layout | Layout | AdminLayout, DashboardLayout (sidebar + header), PageShell |
| PageHeader | Header | Header com título, breadcrumbs, ações |
| Logo | Branding | Theme-aware com variantes (icon, horizontal) |
Token System
freelaw.purple · gold · lilac · dark"] F2["Tipografia
Fraunces (heading) · Public Sans (body)"] F3["Espaçamento
sm · md · lg · xl · 2xl"] F4["Sombras
lp-soft · lp-medium · lp-strong · lp-glow"] end subgraph SEMANTIC["💡 Semantic Tokens"] S1["Brand
primary · accent · surface"] S2["Status
success · warning · error · info"] S3["Typography
title (900) · subtitle (600) · body (300)"] S4["Animation
16 keyframes customizados"] end FOUNDATION --> SEMANTIC subgraph COMPONENTS["🧩 Components"] C1["Button · Card · Input
Dialog · Select · Table..."] end SEMANTIC --> COMPONENTS style FOUNDATION fill:#f3e8ff,stroke:#7c3aed,stroke-width:2px style SEMANTIC fill:#dbeafe,stroke:#3b82f6,stroke-width:2px style COMPONENTS fill:#dcfce7,stroke:#10b981,stroke-width:2px
Cores da marca
| Token | Cor | Uso |
|---|---|---|
freelaw.purple |
#330066 | Cor principal |
freelaw.lilac |
#f5f0ff | Background light |
freelaw.gold |
#CC9900 | Accent/destaque |
freelaw.dark |
#0d001a | Background escuro |
freelaw.red |
#ef4444 | Erro/alerta |
Regras de enforcement
Como usar (exemplos)
```typescript
// ✅ CORRETO
import { Button, Card, Input } from "@freelaw/ui";
// ❌ ERRADO
import { Button } from "@/components/ui/button";
## 3.2 Estrutura Atual e Diffs
<div class="info-box info-yellow">
<span class="info-icon">⚠️</span>
<div class="info-content">
<div class="info-title">Gaps do Design System</div>
<div class="info-text">
• Documentação incompleta (só 4 arquivos MDX)<br/>
• Falta catálogo visual (Storybook ou similar)<br/>
• Componentes do Backstage não extraídos para @freelaw/ui<br/>
• Tokens de espaçamento não formalizados<br/>
• Sem dark mode implementado
</div>
</div>
</div>
## 3.3 Registro de Alterações
| Data | Versão | Alteração | Autor |
|------|--------|-----------|-------|
| 2026-03-12 | 1.0 | Inventário do DS | Guilherme + Claude |
---
<div class="section-banner" style="--banner-from:#7f1d1d;--banner-to:#991b1b">
<span class="banner-icon">🚀</span>
<div class="banner-title">4. CI/CD e Controle de Código</div>
<div class="banner-subtitle">Pipeline com 8 jobs paralelos, 26 git hooks, review por IA (FreeClaw), auto-merge. A CI é o reviewer.</div>
</div>
<div class="info-box info-blue">
<span class="info-icon">💡</span>
<div class="info-content">
<div class="info-title">Filosofia</div>
<div class="info-text">"A CI é o reviewer. FreeClaw é o approver. Humanos fazem ship rápido." — Toda PR é revisada por IA e auto-merged. Se algo quebra em prod, a correção é melhorar o CI/CD.</div>
</div>
</div>
## 4.1 Estrutura Correta e Ideal (Target)
### Pipeline CI — Visão geral
```mermaid
graph TD
PR["🔀 Pull Request"] --> DETECT["🔍 detect<br/>Análise de escopo (30s)"]
DETECT --> CQ["📋 code-quality<br/>13 checks · 2min"]
DETECT --> TC["🔤 typecheck<br/>TS progressivo · 5-7min"]
DETECT --> TEST["🧪 tests<br/>Unit/integration · 3min"]
DETECT --> E2E["🌐 e2e-smoke<br/>Playwright · 2min"]
DETECT --> DBV["🗄️ db-validate<br/>Schema check · 1min"]
DETECT --> BUILD["🏗️ build-smoke<br/>Per-app x4 · 3-6min"]
CQ --> STATUS["✅ ci-status<br/>Aggregador — Gates merge"]
TC --> STATUS
TEST --> STATUS
E2E --> STATUS
DBV --> STATUS
BUILD --> STATUS
STATUS --> MERGE["🎉 Auto-merge<br/>FreeClaw approves"]
style DETECT fill:#dbeafe,stroke:#3b82f6,stroke-width:2px
style STATUS fill:#dcfce7,stroke:#10b981,stroke-width:2px
style MERGE fill:#f3e8ff,stroke:#7c3aed,stroke-width:2px
Job: code-quality (13 checks)
| # | Check | O que valida |
|---|---|---|
| 1 | PR size | Warn >200 linhas, BLOCK >500 |
| 2 | Conventional commits | Formato type(scope): description |
| 3 | Biome lint | Lint em arquivos modificados |
| 4 | SQL schema guard | Padrões SQL válidos |
| 5 | Migration schema guard | Compatibilidade Drizzle |
| 6 | Forbidden patterns | console.log, arquivos grandes |
| 7 | Hook enforcement | Verifica que pre-commit hooks rodaram |
| 8 | Architecture validator | dependency-cruiser rules |
| 9 | Design system check | Se frontend changes |
| 10 | Security scan | Trivy, se security-relevant |
| 11 | Guard strip | Remove debug code |
| 12 | Workflow lint | actionlint nos workflows |
| 13 | Screenshot check | Imagens para .tsx changes |
Deploy Flow
quais apps mudaram"] DETECT2 --> BUILD2["Build per-app
Turbo incremental"] BUILD2 --> DEPLOY["Vercel CLI
deploy --prebuilt"] DEPLOY --> PROD["🌐 Produção"] style PUSH fill:#fef3c7,stroke:#f59e0b style DETECT2 fill:#dbeafe,stroke:#3b82f6 style BUILD2 fill:#f3e8ff,stroke:#7c3aed style DEPLOY fill:#dcfce7,stroke:#10b981 style PROD fill:#ecfdf5,stroke:#059669
| App | Domínio |
|---|---|
| backstage | backstage.freelaw.ai |
| studio-offices | app.freelaw.ai |
| website | freelaw.ai |
| studio-providers | prestadores.freelaw.ai |
Git Hooks (24 comandos totais)
Pre-commit (16 hooks, paralelo, ~5-10s)
Pre-push (8 hooks, paralelo, ~30-60s)
Workflow obrigatório (AGENTS.md v6.0)
Auditar git
Criar TASKS.md"] --> C["1️⃣ CLARIFY
Ler requisito
Perguntar dúvidas"] C --> B["2️⃣ BUILD
1 behavior/iter
Max 500 linhas"] B --> V["3️⃣ VALIDATE
typecheck · test
screenshot · ds:quick"] V --> S["4️⃣ SHIP
Conventional commit
Screenshots no PR"] style P fill:#dbeafe,stroke:#3b82f6 style C fill:#f3e8ff,stroke:#7c3aed style B fill:#fef3c7,stroke:#f59e0b style V fill:#dcfce7,stroke:#10b981 style S fill:#ecfdf5,stroke:#059669
Golden Rules (não-negociáveis)
Regras de segurança (S1-S12)
🔒 12 Security Rules (expandir)
| ID | Regra | Guard | |----|-------|-------| | S1 | Auth scope changes precisam review comment | AI Review | | S2 | Remoção de soft-delete filter precisa justificativa | AI Review | | S3 | Audit fields refletem ator real (JWT) | AI Review | | S4 | Sem N+1 queries (usar batch/join) | AI Review | | S5 | `sql.raw()` com interpolação = BLOCKED | Pre-commit | | S6 | Headers X-User-Id verificados com JWT | Pre-commit | | S7 | Conversão manual de centavos = BLOCKED | Pre-commit | | S8 | PII sem ACL check = BLOCKED | AI Review | | S9 | 3+ DB writes → `db.transaction()` | AI Review | | S10 | Nunca expor `error.message` raw | Pre-commit | | S11 | Client IDs no server → verificar ownership | AI Review | | S12 | RLS `USING(true)` precisa justificativa | CI CODE-021 |Quality Tools
| Ferramenta | Propósito |
|---|---|
| Biome 2.4.4 | Linter + formatter (substitui ESLint + Prettier) |
| dependency-cruiser | Validação de fronteiras arquiteturais |
| Turbo | Build orchestration e caching |
| Playwright | E2E testing |
| tsgo | TypeScript check rápido (per-package) |
| lefthook | Git hooks manager |
| Trivy | Security scanning |
| FreeClaw | AI code review + auto-approve |
4.2 Estrutura Atual e Diffs
• 0 arquivos com @ts-nocheck — bypass do type system
• 9 z.any() em schemas — validação fraca
• E2E tests limitados — cobertura baixa de regressão
4.3 Registro de Alterações
| Data | Versão | Alteração | Autor |
|---|---|---|---|
| 2026-03-12 | 1.0 | Documento criado com configs reais do monorepo | Guilherme + Claude |
CHANGELOG GERAL
| Data | Versão | Alteração | Autor |
|---|---|---|---|
| 2026-03-12 | 1.0 | Documento completo — 4 pilares (Código, Dados, DS, CI/CD) com dados reais do monorepo, diagramas Mermaid, e visual infográfico | Guilherme + Claude |
| 2026-03-15 | 1.2 | +ARCH-07/08 (AI-native, agents), +Close Management schemas, +AI Confidence schemas, +Arquitetura de Agents (Continuous + On-Demand), +Gaps de dados (benchmark Campfire.ai) | Guilherme + Claude |