| title | DeskcommCRM — PRD-Mestre |
|---|---|
| version | 0.2 |
| status | em revisão |
| date | 2026-07-19 |
| owner | Rafael Melgaço |
| referencia_arquitetural | docs/research/reference-synthesis.md |
Documento-índice da visão, escopo e estrutura do produto. Cada subsistema é detalhado em sub-PRDs (
01-plataforma-base.md...06-nuvemshop-lgpd.md). Decisões arquiteturais herdadas estão emdocs/research/reference-synthesis.md.
Este PRD nasceu (v0.1, abril/2026) com o produto posicionado como CRM operacional para e-commerce. Após a abertura do código, a realidade da adoção mudou o produto: a maioria da comunidade roda o Deskcomm em clínicas, infoprodutos, imobiliárias, agências e serviços, e os pedidos de feature nos especializaram em agentes de IA integrados via MCP. O posicionamento vigente está em VISION.md:
Sistema operacional de vendas open source com agentes de IA nativos e WhatsApp — self-hosted, multi-tenant, para qualquer negócio que vende conversando.
Implicações de leitura deste documento e dos sub-PRDs:
- E-commerce passa de definição do produto a primeiro vertical. Referências a Nuvemshop, pipeline de pedidos e vocabulário de e-commerce continuam válidas como o template do vertical de origem — o mecanismo que as generaliza é o
vocabularyconfigurável por pipeline (Sub-PRD 02 §3.7). - O modelo comercial é open source + infraestrutura (parceria HostGator para self-host em VPS), não venda de assinatura. Menções a "modo SaaS" descrevem uma opção arquitetural preservada, não o plano comercial corrente.
- Requisitos, contratos e decisões técnicas dos sub-PRDs permanecem válidos — a arquitetura multi-tenant com
vocabularyconfigurável foi o que permitiu a expansão multi-nicho sem refactor.
O que é. DeskcommCRM é um sistema operacional de vendas open source com agentes de IA nativos — um CRM operacional onde a IA atende, qualifica e move o funil junto com humanos. Unifica atendimento humano, agentes com RAG por tenant, gestão de pedidos/negócios e pipeline de pós-venda numa única plataforma multi-tenant, tendo WhatsApp como canal primário (via WAHA, API não-oficial). Nasceu especializado em e-commerce (vertical de origem, com integração Nuvemshop); hoje serve qualquer negócio que vende conversando — ver Nota de transição (§0).
Quem usa. Cada pessoa opera as organizações às quais possui vínculo ativo, com papel próprio em cada uma. A administração da plataforma gerencia a instalação; quando precisa acompanhar dados de uma organização, abre uma sessão temporária de edição ou somente leitura, vinculada à sessão autenticada e auditada com o ator real. Esse acompanhamento não cria membership nem uma caixa unificada cross-tenant. O contrato vigente está em docs/support-sessions.md.
Quem é o cliente alvo (tenant). PME brasileira que vende pelo WhatsApp — e-commerce, clínica, imobiliária, infoprodutor, agência ou serviço — na faixa de ~300 atendimentos/dia, 2–5 atendentes humanos e 1–2 números WhatsApp. O perfil de calibração original (e-commerce Nuvemshop com ~5 mil pedidos/mês) segue sendo a referência de carga.
Diferencial competitivo. Quatro elementos juntos — ausentes nos concorrentes incumbentes (Kommo, Octadesk, Zendesk, Pipedrive, RD CRM):
- Agentes de IA operando o CRM com RAG por tenant (FAQ + políticas do negócio + catálogo sincronizado + conversas resolvidas), não chatbot decorativo — com trilha de auto-aprimoramento: conversas resolvidas realimentam a base de conhecimento.
- Multi-nicho por design: pipeline, vocabulário e métricas configuráveis por tenant (
vocabularypor pipeline) — o ciclo de e-commerce ("Carrinho abandonado → Pago → Enviado → Entregue → Pós-venda") é o template do vertical de origem, não o limite do produto. - MCP-ready: arquitetura inclui MCP server (interno hoje; contrato público na Fase 2) com 19 tools canônicas pra LLMs operarem o sistema.
- LGPD nativa: redact e data_request como contrato de primeira-classe (incluindo os webhooks da Nuvemshop no vertical e-commerce), não afterthought.
Restrições principais. MVP-B em produção em 8–12 semanas. Stack obrigatória: bundle adotado (Next.js 14+ App Router + Supabase + WAHA Plus + Vercel + MCP server separado em Node ESM). LGPD desde o dia 1. Arquitetura multi-tenant com RLS Postgres em toda tabela tenant-aware.
-
Atendimento desfragmentado. PMEs hoje atendem via WhatsApp Web pessoal + planilha + memória do atendente. Sem histórico unificado, sem multi-atendente real, sem auditoria. Quando o atendente sai da empresa, o relacionamento com o cliente vai junto.
-
Custo proibitivo de atendimento humano puro. Contratar 5 atendentes 12h/dia é caro. ROI só fecha com IA cobrindo 60–70% dos casos repetitivos (rastreio, troca, FAQ, política de envio), mantendo humano apenas pra casos com fricção emocional ou complexidade.
-
LGPD em pé de fragilidade. Lojistas raramente têm processo formal de redact e data_request. Multas vêm crescendo desde 2023 e passam pra eles em primeiro lugar — e pro fornecedor de software, em segundo. Não é compliance opcional.
-
CRMs B2B genéricos não servem pra quem vende conversando. Pipedrive, RD CRM e similares foram desenhados pra venda de SaaS — funil "Lead → Proposta → Negociação → Fechado". Venda conversacional (e-commerce, clínica, imobiliária, infoproduto) tem ciclo curto, automatizado, repetitivo, centrado no WhatsApp. O vocabulário e o ritmo são outros — e cada nicho precisa do seu (
vocabularyconfigurável). -
Sem MCP nativo no mercado. Lojistas que querem operar o CRM via Claude Desktop ou agentes IA hoje não têm plataforma que exponha CRUD do CRM como tools MCP. Tendência forte pós-2025; janela competitiva aberta.
"DeskcommCRM é o sistema operacional de vendas onde agentes de IA e humanos atendem juntos os clientes de qualquer negócio que vende pelo WhatsApp, com Customer 360° unificado, compliance LGPD nativa, operação multi-tenant pronta pra escala — e agentes que se auto-aprimoram a cada conversa resolvida."
Em três anos: ser a resposta padrão pra "melhor CRM open source com agentes de IA e WhatsApp" — milhares de instâncias self-hosted (VPS HostGator como caminho recomendado), ecossistema de agentes plugados via MCP público, templates prontos por nicho (e-commerce, clínica, imobiliária, infoproduto), e o flywheel de auto-aprimoramento medido em produção. Posicionamento completo em VISION.md.
Quem. Pessoa com vínculo nas organizações em que atende; o papel e a interface podem variar por vínculo. Dores. Trocar de contexto sem carregar dados da organização anterior. Esquecer contexto do cliente entre conversas. Não saber se já respondeu uma dúvida frequente. Saber a hora certa de escalar. Precisa. Troca segura entre vínculos, contexto do cliente em 1 clique, sugestões de resposta da IA e estados claros de conversa e demanda.
Quem. Responsável pela instalação e pela governança da plataforma. Para acompanhar uma organização, escolhe uma sessão temporária de edição ou somente leitura. Dores. Diagnosticar uma organização sem assumir a identidade de cliente, deixar uma sessão privilegiada aberta ou perder a autoria real das ações. Precisa. Gestão de organizações, entrada e saída explícitas do acompanhamento, prazo limitado, MFA conforme a política vigente, modo somente leitura que prevalece sobre vínculos físicos e auditoria com o ator real.
Quem. Dono ou gerente do e-commerce cliente. Acessa o sistema via super-admin do tenant. Dores. Saber se a empresa BPO está atendendo bem (no MVP) ou operar atendimento próprio (no SaaS). Configurar políticas de IA, FAQ, base RAG. Ver métricas (NPS, tempo de resposta, taxa de resolução por IA). Precisa. Painel do tenant com KPIs operacionais, configuração de chatbot/RAG, gestão de atendentes do tenant, exports LGPD.
Quem. Pessoa física que comprou ou está comprando no e-commerce. Não acessa o sistema diretamente; é atendida via WhatsApp. Dores. Esperar 30+ minutos por resposta. Repetir histórico toda vez que troca de atendente. Não conseguir falar com humano quando o bot trava. Precisa. Resposta em <30s pra dúvidas simples, transição transparente pra humano quando complexo, contexto preservado entre interações.
Quem. Funcionário do e-commerce cliente que opera o CRM próprio (no modo SaaS). Dores. Similar ao Operador BPO, mas escopo de 1 tenant. Precisa. Mesma UI do Operador BPO, mas sem cross-tenant.
Quem. Autoridade Nacional de Proteção de Dados ou auditor contratado pelo tenant. Precisa. Audit trail íntegro de toda operação em dados pessoais; capacidade de gerar export estruturado de qualquer titular em até 7 dias úteis; capacidade de redact (anonimização ou delete) em até 15 dias úteis.
Plataforma base
- Auth multi-tenant via Supabase Auth (JWT com
tenant_idclaim, MFA TOTP forçado pra admin) - RBAC com 4 roles (viewer / agent / manager / admin) + super-admin de plataforma
- RLS em toda tabela tenant-aware via
fn_user_org_ids() - Audit log denso (
api_audit_log) em toda mutação - Onboarding de tenant (mesmo que ainda não exposto publicamente)
Customer 360° (determinístico)
- Identity resolution determinística por email + telefone E.164 + CPF
- Timeline event-sourced via
crm_lead_activitiespolimórfica - Custom fields declarativos por pipeline (
pipeline.settings.fields) - Vocabulary customizável (lead=Cliente, deal=Pedido, won=Pago, lost=Cancelado pra e-commerce)
Canal WhatsApp via WAHA Plus
- Conexão de número por QR code via UI
- Recebimento de mensagens com HMAC-SHA512 + idempotência via
unique (org, external_id) - Envio com persistência otimista (
status='sending'antes do despacho) - Anti-banimento (throttle 1msg/1.2s + jitter, warm-up assistido, spinning de copy, detecção STOP automática)
- Multi-número e multi-atendente por tenant
- Mídia via Supabase Storage (não inline)
- Cron
recover-stuck-messages+sync-sessions+process-pending-webhooks
Pipeline Kanban + Atendimento
- 5 tabelas core CRM com fractional indexing (
position_in_stage numeric+midpoint()) - Pipeline default seedado no signup ("Carrinho abandonado → Aguardando pagamento → Pago → Em separação → Enviado → Entregue → Pós-venda")
- Drag-drop com
@hello-pangea/dnd - Roteamento simples (round-robin entre atendentes) e atribuição manual
- Tickets como crm_leads + activities; sem entity separada de "ticket" no MVP
IA Conversacional + Handoff
- Chatbot por tenant com prompt customizável
- RAG por tenant (vector store: pgvector ou Supabase Vector — a escolher na spec)
- Ingestão: FAQ manual + política da loja + catálogo Nuvemshop sincronizado + conversas resolvidas anteriores
- Sentiment detection em tempo real (cada inbound roda análise binária alta/baixa frustração)
- Handoff automático quando: cliente pede explicitamente humano, sentiment cai abaixo do threshold, IA admite incerteza, conversa entra em estágio crítico do pipeline (ex: pós-venda com defeito)
- Atendente humano vê histórico completo do bot ao assumir
Integração Nuvemshop
- OAuth (App embedded ou external, a definir na spec)
- Webhooks
order/created,order/paid,order/cancelled,order/fulfilled,cart/abandoned - Webhooks LGPD
customer/redact,customer/data_request,store/redact - Sync inicial de produtos/clientes/pedidos
- Tabela
orderslinkada acrm_leadsviacrm_lead_linkspolimórfico
LGPD framework
- Endpoint
/api/v1/lgpd/data-request— gera export estruturado (JSON + PDF) em D+7 - Endpoint
/api/v1/lgpd/redact— anonimização (preferida) ou delete cascade conforme caso - Audit log de toda operação em dados sensíveis
- Consentimento granular por tenant (marketing, transacional, perfilamento separados)
- MCP server público (Fase 2)
- Identity resolution probabilística (Fase 3)
- Multi-canal além de WhatsApp — Instagram DM, email, web chat (Fase 4)
- Multi-plataforma e-commerce — VTEX, Shopify (Fase 5)
- Permissão por pipeline (
user_pipeline_accesstable) — adicionar quando cliente real pedir - Dashboard analytics avançado e relatórios executivos
- Programas de fidelidade, NPS automatizado, recovery de carrinho via campanha
- Não adotar microsserviços. Monolito Next.js + Supabase + serviço externo só pra WAHA é a fronteira aceitável.
- Não adotar event sourcing puro.
event_logtable + workers, padrão pub/sub leve. CQRS é overkill nesse estágio. - Não construir abstrações multi-platform especulativas além do
EcommercePlatformAdapter. YAGNI até segundo provedor entrar.
DeskcommCRM adota integralmente a doutrina arquitetural extraída do material da Aula CRM Nichado com WhatsApp (WAHA). Síntese completa em docs/research/reference-synthesis.md.
Pontos não negociáveis herdados:
- Stack Next.js + Supabase + WAHA Plus + Vercel
- Multi-tenant via RLS com helper
fn_user_org_ids() - 5 tabelas core CRM (
crm_pipelines,crm_stages,crm_leads,crm_lead_activities,crm_lead_links) - Polimorfismo explícito em timeline e vínculos
- Fractional indexing no kanban
- Idempotência via
unique (org, external_id) event_log+ workers; trigger NUNCA faz HTTP- Realtime via Supabase Realtime (postgres_changes + broadcast)
- API REST canônica
/api/v1/com cursor pagination, idempotency-key, dual auth - 4 roles RBAC; sem permissão por pipeline no MVP
- Doutrina DIRC (Duplicar / Integrar / Referenciar / Calcular)
- 19 tools MCP canônicas (pra Fase 2)
Toda decisão de spec/epic que conflitar com o bundle herdado requer justificativa explícita no documento que decide a divergência.
São os 6 deltas que o DeskcommCRM constrói sobre a base herdada — onde reside o valor competitivo e onde a engenharia adiciona algo não-trivial:
OAuth + 8+ webhooks (incluindo LGPD redact/data_request) + sync inicial. Adapter pattern (EcommercePlatformAdapter) abstrai a interface pra VTEX/Shopify entrarem em fases posteriores sem reescrita.
Cada mensagem inbound roda análise leve (Haiku 4.5 ou modelo dedicado) em paralelo via event_log. Threshold configurável por tenant. Marcador de timeline (crm_lead_activities.type='handoff_triggered' com metadata.sentiment_score). Política de retomada documentada (cliente volta a engajar bem? bot reassume? quem decide?).
Vector store por tenant (pgvector ou Supabase Vector — a definir na spec). Pipeline de ingestão com 4 fontes: FAQ manual, política da loja (PDF/markdown), catálogo Nuvemshop sincronizado, conversas resolvidas anteriores como exemplos. Roteamento de chamada combina contexto (últimas 20 messages + perfil do contato + último pedido) + RAG hits. Modelo default: Sonnet 4.6 via AI Gateway, Haiku 4.5 pra triagem de sentimento.
platform_admins mantém a autoridade transversal de administração da instalação. Acesso operacional aos dados de uma organização acontece por acompanhamento temporário vinculado à sessão Supabase, com alvo, modo efetivo, prazo máximo de uma hora, política de MFA e saída explícita. O modo somente leitura bloqueia efeitos mesmo se o ator também tiver membership admin no alvo; o modo de edição projeta papel efetivo sem criar membership. Os direitos de plataforma fora do alvo permanecem existentes, isto é, o mecanismo não confina globalmente o JWT. As operações feitas pelas superfícies do aplicativo registram o ator real e a sessão de suporte. Contrato completo: docs/support-sessions.md.
Default: Vercel AI Gateway com fallback de provedor (Anthropic primário; OpenAI de backup). Observability nativa (tokens, latência, custo por tenant). Zero data retention configurável. Strings "anthropic/claude-sonnet-4-6" em vez de import direto de SDK específico, conforme guidance da plataforma.
Interface EcommercePlatformAdapter define fetchOrders, fetchCustomers, subscribeWebhooks, redactCustomer, dataRequest. Nuvemshop é primeira impl no MVP; VTEX e Shopify entram como adapters adicionais sem alterar a camada de domínio (crm_leads, orders, etc.).
- Minimização: armazenar apenas o necessário pra atendimento. Sem coleta de dados secundários sem consentimento explícito.
- Anonimização preferida sobre delete: vendas históricas precisam permanecer pro faturamento; nome do cliente vira "Cliente Anonimizado #1234".
- Audit trail íntegro: toda operação de dados sensíveis logada com
who/what/when/why, em tabela imutável (api_audit_log). - Consentimento granular: marketing / transacional / perfilamento separados, cada um pode ser revogado independentemente.
- Endpoint
/api/v1/lgpd/data-request— gera export estruturado em JSON + PDF entregue em D+7 ao titular ou ao tenant. - Endpoint
/api/v1/lgpd/redact— anonimização cascata (contact + conversations + messages média + activities) com flagis_anonymized. Delete físico apenas quando solicitado e sem dependências (raro). - Webhook receiver pros 3 webhooks LGPD da Nuvemshop:
customer/redact→ fluxo de anonimização sob solicitaçãocustomer/data_request→ fluxo de exportstore/redact→ quando lojista cancela conta Nuvemshop, redact em cascade do tenant inteiro
- HMAC validado em todo webhook LGPD (Nuvemshop assina; nós verificamos).
- Audit do receipt de cada webhook (deduplicação via
unique (provider, external_id)).
- Mensagens: retenção configurável por tenant. Default 365 dias; lojistas podem solicitar arquivamento de fria-via mais curto.
- Audit log: 5 anos (boas práticas ANPD).
- Eventos do
event_log: 90 dias retenção operacional + arquivamento pro cold storage S3 se necessário.
- Certificação SOC 2 / ISO 27001 (entra na Fase 1.5 ou 2 conforme demanda comercial).
- Pseudonimização avançada de payloads em transit (toda comunicação interna já é em transit-encrypted via Supabase).
| KPI | Definição | Target MVP | Como medir |
|---|---|---|---|
| Taxa de resolução por IA | % de conversas que terminam sem handoff humano | 50–60% | Contador de conversas com handoff_triggered=false / total resolvidas |
| Tempo médio até primeira resposta | Minutos entre mensagem do cliente e primeira resposta (humano ou IA) | <30s pra IA; <5min pra humano | Diff entre messages.created_at (inbound) e próxima outbound |
| NPS pós-atendimento | Nota 0–10 do cliente final ao final da conversa resolvida | ≥75 (% promotores) | Mensagem automática de NPS após conversation.status='resolved' |
| Custo médio por atendimento | R$ por conversa resolvida (IA + humano + infra) | <R$ 3,00 | Custo total mensal / número de conversas resolvidas |
| Taxa de banimento WAHA | % de números banidos por mês | 0% | Alertas em ≥1 incidente; pós-mortem obrigatório |
| Tempo de resposta a data_request LGPD | Dias úteis entre webhook recebido e export entregue | ≤7 dias | Diff entre webhook.received_at e export.delivered_at |
| SLA de uptime do tenant | % de minutos no mês com WAHA WORKING + API respondendo 200 | ≥99,5% | Health-check externo (UptimeRobot ou similar) |
- Número de tenants ativos
- Mensagens processadas por mês (por tenant e total)
- Custo de IA por tenant (token use)
- Quantidade de leads/pedidos importados da Nuvemshop
- Tempo médio de ciclo de pipeline (carrinho → entregue)
DeskcommCRM é considerado MVP-validado quando:
- Pelo menos 1 tenant real está em produção atendendo clientes finais por 30 dias contínuos sem incidente que cause banimento WAHA ou perda de dados.
- Pelo menos 5 KPIs dos 7 listados acima estão sendo medidos automaticamente e dentro do target ou com plano de correção.
- Audit log e LGPD passam revisão manual sem encontrar lacuna crítica.
| Fase | Duração | Entrega principal |
|---|---|---|
| Fase 1 — MVP-B | 8–12 semanas | Plataforma base + Customer 360 det. + WAHA + Pipeline Kanban + Atendimento humano + Chatbot RAG + Handoff sentiment + Nuvemshop |
| Fase 1.5 — Hardening | +4–8 semanas | Testes automatizados densos, runbooks, observability profunda, documentação operacional, security review |
| Fase 2 — MCP público | +6–8 semanas | MCP server /crm-mcp/ com 19 tools, deploy HTTP, auth Bearer multi-tenant |
| Fase 3 — Identity probabilística | +4 semanas | Device fingerprint, behavior matching, merge UI |
| Fase 4 — Multi-canal | +6–8 semanas | Instagram DM, email, web chat |
| Fase 5 — Multi-plataforma e-commerce | +4 semanas cada | VTEX, depois Shopify (1 por trimestre) |
Roadmap revisado a cada 4 semanas. Estimativa otimista; recalibrar a cada milestone.
| # | Risco | Severidade | Mitigação |
|---|---|---|---|
| R1 | Banimento de número WAHA (WhatsApp detecta API não-oficial) | Crítico | Anti-banimento herdado (throttle, warm-up, spinning, STOP detection); monitoramento de saúde; ter número backup pré-aquecido por tenant; runbook de troca-de-número documentado |
| R2 | Mudança contratual da Nuvemshop (deprecação de webhook, mudança de auth) | Alto | Adapter pattern isola a integração; assinar feed de release notes da Nuvemshop; testes de contrato no CI |
| R3 | Ban da WAHA Plus pelo WhatsApp (third-party upstream) | Alto | Variante BYO documentada (cliente roda WAHA próprio); consideração de migração futura pra API oficial Meta como Fase 2.5 |
| R4 | Custo de IA escala pior que receita (tokens em RAG explodem) | Alto | AI Gateway com observability por tenant; orçamento por tenant configurável; fallback pra Haiku ou modelos menores pra triagem |
| R5 | LGPD/ANPD multa primeiro tenant (lacuna em data_request) | Alto | LGPD desde o dia 1; revisão jurídica antes de produção; SLA interno de D+7 com alarme em D+5 |
| R6 | Sentiment detection produz falso-positivo crônico (escala humano demais ou de menos) | Médio | Threshold configurável por tenant; revisão semanal de casos divergentes; trigger humano-no-loop pros primeiros 30 dias |
| R7 | Vazamento cross-tenant (bug em RLS ou query sem filtro) | Crítico | RLS em toda tabela; testes de isolamento no CI (cada teste cria 2 tenants e verifica que cliente A não vê dados de B); audit log de queries com flag bypassed_rls=true |
| R8 | Atraso na entrega do MVP (8–12 semanas é otimista) | Médio | Sub-PRDs priorizados Now/Next/Later; possibilidade de MVP-A (sem IA) como fallback se cronograma estourar |
| R9 | Equipe pequena queima (greenfield com escopo grande) | Médio | TBD na próxima rodada; considerar 2-3 devs full-stack + 1 DevOps part-time como mínimo |
- Tenant — uma organização cliente do DeskcommCRM (um negócio que vende pelo WhatsApp: e-commerce, clínica, imobiliária, infoprodutor, etc.). No DB =
organizations. Sinônimo: organização. - Operador de atendimento — pessoa que atende nas organizações em que possui vínculo ativo; papel e interface pertencem a cada vínculo.
- Super-admin de plataforma — autoridade transversal para administrar a instalação. O acompanhamento de dados de uma organização é temporário, por sessão, e não cria membership nem troca a identidade do ator.
- Lead / Cliente — registro central no CRM (
crm_leads). No vocabulary de e-commerce, lead = "Cliente". Engloba cliente em qualquer estágio (interesse, comprou, pós-venda). - Deal / Pedido — instância de oportunidade comercial; em e-commerce, sinônimo de Pedido. Modelado como
crm_leads(nãocrm_deals). - Activity — evento da timeline polimórfica (
crm_lead_activities). Pode ser whatsapp_inbound, whatsapp_outbound, payment_received, stage_changed, agent_action, etc. - WAHA — WhatsApp HTTP API. Solução não-oficial, baseada em engenharia reversa. Usamos a versão Plus (multi-tenant) por padrão.
- Janela de 24h — restrição da Meta: bots WhatsApp só podem enviar mensagens não-iniciadas pelo cliente até 24h após a última inbound. Após isso, exige template aprovado.
- DIRC — Duplicar / Integrar / Referenciar / Calcular. Heurística obrigatória antes de adicionar campo: "Esse dado vive aqui (Duplicar)? Vem de outro lugar via FK (Integrar)? É só ponteiro (Referenciar)? Pode ser computado on-demand (Calcular)?"
- MCP — Model Context Protocol da Anthropic. Spec aberta pra integração de LLMs com sistemas externos. Implementado via tools, resources, prompts e transports (stdio, HTTP).
- RAG — Retrieval-Augmented Generation. Padrão onde o LLM consulta uma base de conhecimento vetorizada antes de responder.
- RLS — Row-Level Security do Postgres. Política aplicada à linha que filtra acesso por usuário/tenant.
- Identity resolution — processo de unificar perfis duplicados de cliente. Determinística no MVP (email, telefone, CPF); probabilística (device fingerprint, comportamento) entra na Fase 3.
| Sub-PRD | Tópico | Status |
|---|---|---|
01-prd-platform-base.md |
Plataforma Base (auth multi-tenant, RBAC, super-admin, audit, LGPD framework) | a escrever |
02-prd-customer-360.md |
Customer 360° + Identity Resolution determinística | a escrever |
03-prd-whatsapp-waha.md |
Canal WhatsApp via WAHA Plus (sessões, anti-banimento, multi-atendente) | a escrever |
04-prd-pipeline-attendance.md |
Pipeline Kanban + Atendimento + Tickets + Roteamento | a escrever |
05-prd-ai-rag-handoff.md |
IA Conversacional (chatbot + RAG + sentiment + handoff) | a escrever |
06-prd-nuvemshop-lgpd.md |
Integração Nuvemshop (OAuth + webhooks + LGPD) | a escrever |
Cada sub-PRD contém: contexto, escopo, requisitos funcionais, requisitos não-funcionais, contratos de API/dados, dependências, riscos específicos, plano de validação.
docs/research/reference-synthesis.md— Síntese da arquitetura herdadatasks/todo.md— Workflow de construção (PRD → Regras → Specs → Epics → Stories → Plano)