chore: initial monorepo scaffold + WDS Phase 1+2 artifacts

- Nx 22.7 monorepo (pnpm 11.1, TypeScript 5.9, Node 24) - apps/api: NestJS 11 (CJS conforme CODING-RULES.md PGD-DB-004) - apps/web: React 19 + Vite 8 (ESM) - libs/shared/api-interface: Zod contract base - Docker Compose dev: Postgres 18, Valkey 8, MinIO, Mailpit - WDS artifacts: - design-artifacts/A-Product-Brief/ (5 docs canônicos + 16 dialogs) - design-artifacts/B-Trigger-Map/ (hub + 4 personas + feature impact) - Stack canon: STACK.md v2.2 + CODING-RULES.md v2.0 + brand.md - AGENTS.md + README.md como entrada para devs/agentes Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-27 14:34:20 +00:00
commit 17c08e6392
3631 changed files with 855518 additions and 0 deletions
--- a/design-artifacts/A-Product-Brief/dialog/00-context.md
+++ b/design-artifacts/A-Product-Brief/dialog/00-context.md
@@ -0,0 +1,78 @@
+# Phase 1 — Dialog Context
+
+**Project:** SAR — Força de Vendas
+**Owner:** Julian (Product Owner, JCS Sistemas)
+**Agent:** Saga (Business Analyst)
+**Started:** 2026-05-26
+**Brief level:** complete (36 steps)
+**Communication language:** pt-BR
+
+---
+
+## Working Relationship (de wds-project-outline.yaml)
+
+- **Involvement:** balanceado
+- **Presentation:** recomendar com justificativa
+- **Stakes:** small-business (JCS Sistemas)
+- **Role:** Product Owner
+
+---
+
+## Materiais existentes (entrada Phase 1)
+
+| Material | Path | Cobre |
+|---|---|---|
+| Brand identity | `brand.md` | Visual Direction quase completo + parte de tom |
+| Stack canon JCS | `STACK.md` v2.2 | Platform Requirements quase completo |
+| Coding rules | `CODING-RULES.md` v2.0 | Constraints técnicas (invariantes + pegadinhas) |
+| Logos | `frontend/img/SAR_logo_fundo_transparente.png`, `SAR_icone_fundo_transparente.png` | Assets |
+| **Mockup SPA legado** | `design-artifacts/_references/legacy-screens-html/index.html` | Estrutura funcional + 9 telas mockadas alinhadas à marca |
+
+---
+
+## Pré-análise do mockup legado (9 telas)
+
+> Login excluído por decisão do PO (já será coberto pela stack: master-login + jose).
+
+| Tela (id SPA) | Título | Função (inferida) |
+|---|---|---|
+| `indicadores` | Painel de Desempenho | Dashboard executivo: faturamento, ritmo, mix de produtos, status carteira, radar de inatividade |
+| `pedidos` | Meus Pedidos | Lista de pedidos com totais consolidados |
+| `funil` | Meu Funil de Vendas | Kanban CRM |
+| `agenda` | Agenda e Rotas | Calendário + Roteiro Otimizado |
+| `novo-pedido` | Lançamento de Pedido | Form: cliente + comercial + adicionais + total |
+| `analise-cliente` | Visão 360° do Cliente | Timeline integrada (ex.: OPENFRIOS) |
+| `clientes` | Lista de Clientes | — |
+| `cadastro-cliente` | Cadastro de Cliente | Dados principais + endereço + contatos |
+| `produtos` | Catálogo de Produtos | Detalhe + modal de produto |
+
+### Observações da pré-análise
+
+1. **"Painel de Desempenho" não estava em `brand.md`**. O brand.md lista 6 módulos (Vendas, Fiscal, Financeiro, Comissão/FLEX, CRM, Administrativo) e o mockup adiciona um 7º implícito (BI/Dashboard). A confirmar no brief: é módulo separado ou tela transversal a outros módulos?
+2. **CSS do mockup usa variáveis JCS** (`var(--jcs-blue)`, `var(--orange)`, etc.) — o legado já está alinhado à identidade.
+3. **Cliente 360° já está implementado** no mockup — confirma a visão de `brand.md`.
+
+---
+
+## Histórico do diálogo
+
+### 2026-05-26 — Step 1 (Init)
+
+- Saga apresentada como BA do projeto.
+- Escopo Phase 1 explicado (36 steps em 5 blocos: Brief / Content / Visual / Platform / Wrap-up).
+- Tempo previsto: 2-3h (ajuste sobre os 30-60 min default do workflow).
+- Estratégia acordada: **fast-track de Visual (via brand.md + mockup) e Platform (via STACK.md)**, foco em Product Brief (steps 1-12) e Content (steps 13-18) onde há mais lacunas.
+- Materiais adicionais: usuário disponibilizou mockup HTML do SAR (`index.html` SPA com 9 telas) — login não entra no escopo.
+- Ritmo escolhido: sessão longa contínua, até onde der.
+
+---
+
+## Progress Tracker
+
+| Bloco | Steps | Status |
+|---|---|---|
+| A. Product Brief | 1-12 | Step 1 ✅ · Step 1a → próximo |
+| B. Content & Language | 13-18 | Pendente |
+| C. Visual Direction | 19-26 | Pendente (fast-track) |
+| D. Platform Requirements | 27-32 | Pendente (fast-track) |
+| E. Wrap-up | 33-36 | Pendente |
--- a/design-artifacts/A-Product-Brief/dialog/business-customers.md
+++ b/design-artifacts/A-Product-Brief/dialog/business-customers.md
@@ -0,0 +1,114 @@
+# Business Customers — SAR (Força de Vendas)
+
+**Confirmed:** 2026-05-26
+**Step:** 06 — Business Customers
+
+> Perfil da **empresa-cliente** (quem assina contrato e paga). Não confundir com **user personas** (quem usa diariamente — Step 7).
+
+---
+
+## Perfil da empresa-cliente
+
+| Dimensão | Valor |
+|---|---|
+| **Porte** | PME 5-50 reps externos (sweet spot mid-SMB) |
+| **Setores** | Distribuidoras, indústrias, RCAs (representação terceirizada), PMEs com vendas externas |
+| **Geografia** | Brasil (foco regional/nacional) |
+| **Maturidade tech** | Variada — algumas com TI próprio, muitas sem |
+
+---
+
+## Estrutura de decisão
+
+### Decisor final (assina o contrato)
+- **Dono / sócio-fundador** — PME pequena, decisão centralizada, fast-individual
+- **Diretor comercial / gerente de vendas** — PME média, delegação do dono que apenas referenda
+
+### Influenciadores que matam o deal se rejeitarem
+- **Supervisor de vendas** — vai usar diariamente; se odiar a demo, dono não compra
+- **Representantes early users / champions internos** — quando um rep já conheceu SAR em outra empresa, vira advogado interno
+
+### Ausentes (não pesam na decisão típica) ⚠️
+- ✗ Financeiro
+- ✗ TI interna
+- ✗ Jurídico
+
+**Insight central:** SAR é venda **operacional-emocional**, não **técnica-financeira**.
+A demo precisa **brilhar para o supervisor**, não impressionar a TI ou justificar TCO no Excel.
+
+---
+
+## Buyer Persona — "O Dono Empresário B2B"
+
+- **Idade típica:** 35-60 anos
+- **Perfil:** Sócio-fundador ou herdeiro de negócio familiar; conhece o setor profundamente; gerencia "no peito"
+- **Dor que paga:** Não consegue mais administrar pelo WhatsApp + planilha. Vê concorrente crescendo. Tem caixa para investir em ferramenta, mas não sabe qual.
+- **Critério de avaliação principal:** Fé que o produto vai funcionar — não TCO planilhado. Daí a importância de **demo concreta + boca-a-boca + cases**.
+- **O que o convence:**
+  - Ver outro dono usando
+  - Ver o supervisor empolgado na demo
+  - Ouvir rep dizendo "muito melhor que o antigo"
+- **O que o assusta:**
+  - "Meu pessoal não vai aprender"
+  - "É mais um sistema que vai me dar trabalho"
+  - "É caro pra valer?"
+
+---
+
+## Canais de aquisição (4 ativos)
+
+| Canal | Esforço JCS | Velocidade | Custo | Implicação principal |
+|---|---|---|---|---|
+| **Indicação boca-a-boca** | Médio — programa de referral + cases | Lento de construir, rápido depois | Baixo (comissão referral) | Cases públicos + programa de indicação |
+| **Google / SEO + content** | Alto — blog, comparativos, calculadora ROI | 6-12 meses para crescer | Médio (time de conteúdo) | Blog + SEO técnico + landing pages por dor |
+| **Eventos / feiras** | Alto — estande, demos ao vivo, networking | Imediato no evento, follow-up demora | Alto (estandes APAS/Fispal) | Calendário de feiras + kit de evento + CRM para follow-up |
+| **Parceiros** (contadores, revendedores ERP, consultorias) | Médio — kit comercial + treinamento | Médio prazo | Comissão recorrente sobre MRR | Página de parceiros + kit comercial + onboarding de parceiro |
+
+---
+
+## Ciclo de vendas por porte do cliente
+
+| Porte cliente | Ciclo típico | Padrão de venda |
+|---|---|---|
+| **Pequeno (5-10 reps)** | 2-4 semanas | Dono decide; demo curta; fechamento rápido (mensal flexível facilita) |
+| **Médio baixo (11-25 reps)** | 1-2 meses | Dono + supervisor avaliam; comparam com 1-2 concorrentes |
+| **Médio alto (26-50 reps)** | 2-4 meses | Avaliação mais formal; possível POC; anual prepago com desconto acelera |
+
+---
+
+## Implicações para site / marketing (alimenta Steps 13-26)
+
+1. **Hero do site:** demo em vídeo + "Veja o SAR funcionando em 3 minutos" (não "Cadastre-se grátis")
+2. **Prova social pesada:** logos de clientes; depoimentos em vídeo de **donos** (não de TI); números reais ("R$ X em pedidos processados no SAR este mês")
+3. **Páginas dedicadas por papel:**
+   - `/para-donos` — IA estratégica, dashboard de gestão, ROI
+   - `/para-supervisores` — telas de decisão diária, controle de equipe
+   - `/para-representantes` — clareza de carteira, metas, WhatsApp
+4. **Comparativos diretos:** `SAR vs Mercos`, `SAR vs módulo TOTVS` — combate frontal aos concorrentes mapeados em Positioning
+5. **Conteúdo SEO-relevante:**
+   - "Como controlar representante externo"
+   - "Software força de vendas para distribuidora"
+   - "Como integrar WhatsApp com vendas B2B"
+   - "Como saber quais clientes estão esfriando"
+6. **Página de parceiros:** kit comercial + comissão + treinamento — captura canal contador/ERP-revendedor
+7. **Eventos:** calendário público "encontre o SAR em X feira" + agendamento de demo presencial
+
+---
+
+## Implicações para o produto (alimenta Phase 3+4)
+
+1. **Demo-friendliness obrigatória:** as 3 experiências precisam ser **visualmente convincentes em 5 minutos**. Não pode ser produto "que melhora com o tempo".
+2. **Onboarding self-guided no trial:** mesmo sem hand-holding, supervisor consegue se virar (porque ele é o influenciador que tem que aprovar internamente).
+3. **WhatsApp visível desde a primeira tela:** diferencial declarado, precisa estar evidente quando supervisor abre o SAR pela primeira vez.
+
+---
+
+## Implicações para a estrutura comercial JCS
+
+1. **SDR + AE (mesmo papel inicialmente):** Julian provavelmente acumula até o primeiro fechamento; depois separar.
+2. **CRM próprio JCS:** pipeline com estágios (lead → qualificado → demo → proposta → contrato). **Possível dogfood:** usar o SAR para vender o SAR.
+3. **Material de venda padronizado:**
+   - Roteiro de demo (15-20 min)
+   - Proposta template (3 tiers de pricing × 2 contratos)
+   - Termo de aceite + LGPD (controlador de dados é o cliente)
+4. **Pós-venda / onboarding:** definir quem ajuda na implantação inicial (especialmente para médio alto, onde POC pode ser parte do ciclo).
--- a/design-artifacts/A-Product-Brief/dialog/business-model.md
+++ b/design-artifacts/A-Product-Brief/dialog/business-model.md
@@ -0,0 +1,103 @@
+# Business Model — SAR (Força de Vendas)
+
+**Confirmed:** 2026-05-26
+**Step:** 05 — Business Model
+
+---
+
+## Modelo
+
+**B2B SaaS multi-tenant, per-seat, sales-led, com trial real**
+
+| Componente | Decisão |
+|---|---|
+| **Tipo** | B2B SaaS (empresa-cliente paga; reps/supervisor/dono usam) |
+| **Cobrança** | **Per-seat** (por representante ativo / mês) |
+| **Vendas** | **Sales-led** — demo + proposta + acompanhamento comercial |
+| **Trial** | **14-30 dias** com dados reais do cliente (workspace sandbox provisionado) |
+| **Contrato** | Híbrido — cliente escolhe: **mensal sem fidelização** (full price) **ou** **anual prepago com desconto** (10-20%) |
+
+---
+
+## Definição de "rep ativo" (a refinar)
+
+Per-seat exige critério canônico de "ativo" para a fatura mensal. Opções candidatas:
+
+- **Login nos últimos 30 dias** (mais permissivo — captura rep que entra mesmo sem vender)
+- **Pelo menos 1 pedido lançado nos últimos 30 dias** (mais estrito — vincula a valor)
+- **Híbrido:** logou OU lançou pedido nos últimos 30 dias
+
+**Decisão pendente** para Step 8 (Success Criteria) ou Phase 3 (PRD), quando definirmos métricas/billing rules.
+
+---
+
+## Ticket médio estimado (preliminar)
+
+Premissa: R$ 150/rep/mês como referência de mercado (Mercos, Promosoft cobram nessa faixa). Refinar quando JCS validar preço.
+
+| Porte cliente | Reps | Mensal estimado | Anual prepago (-15%) |
+|---|---|---|---|
+| Pequeno | 5-10 | R$ 750-1.500 | R$ 7.650-15.300 |
+| Médio baixo | 11-25 | R$ 1.650-3.750 | R$ 16.830-38.250 |
+| Médio alto | 26-50 | R$ 3.900-7.500 | R$ 39.780-76.500 |
+
+**ARR potencial por cliente:** R$ 9.000 (pequeno) → R$ 90.000 (médio alto).
+
+---
+
+## Implicações técnicas
+
+1. **Per-seat → "active rep counter" no produto**
+   - Job mensal calcula ativos por workspace
+   - Billing consome esse número
+   - UI mostra para o dono quantos ativos estão sendo cobrados (transparência)
+
+2. **Sales-led → JCS precisa de processo comercial próprio**
+   - CRM próprio para pipeline
+   - Templates de proposta/contrato
+   - Possível dogfood: usar o próprio SAR para gerenciar a venda do SAR
+
+3. **Trial com dados reais → provisioning automatizado**
+   - Master-login cria workspace sandbox
+   - Cluster PG dedicado (mesma arquitetura BD-por-workspace, ADR 0006)
+   - Seed opcional com catálogo de exemplo
+   - Função de "trial expirado" → bloqueio de escrita, dados preservados N dias para conversão
+
+4. **Mensal + Anual → módulo de billing precisa suportar ambos**
+   - Cobrança recorrente mensal (cartão/PIX/boleto)
+   - Cobrança única anual (PIX/boleto preferencial — cashflow imediato)
+   - Decidir provider em Step 29 (Integrations): Iugu, Pagar.me, Gerencianet ou Stripe
+
+---
+
+## Implicações de marketing/landing page
+
+- **Site precisa de pricing page** explícita (per-rep + diferencial mensal vs anual)
+- **CTA principal:** "Agende sua demo" (não "Sign up free")
+- **Não há checkout no site** — venda passa por SDR/comercial
+- **Trial gate:**
+  1. Visitante preenche form (empresa, contato, qtd reps, ERP atual)
+  2. SDR JCS qualifica
+  3. Demo (online ou presencial)
+  4. Trial liberado com workspace dedicado e onboarding inicial
+  5. Conversão para contrato pago
+
+---
+
+## Implicações para Phase 1 restante
+
+- **Step 6 (Business Customers):** detalhar a empresa-cliente como **buyer persona** distinta dos 3 user personas. O dono pode ser ambos (buyer + user), mas:
+  - Decisão de compra: avaliação de ROI, integração ERP, suporte JCS
+  - Uso diário: dashboard estratégico + IA
+- **Step 7 (Target Users):** confirmar os 3 user personas (rep / supervisor / dono).
+- **Step 8 (Success Criteria):** métricas-chave provavelmente serão MRR/ARR, churn %, ticket médio, % reps ativos, NPS.
+- **Step 30 (Contact Strategy):** form de demo é a peça-chave do site (não chat genérico, não suporte público).
+
+---
+
+## Lacunas conscientemente adiadas
+
+- Preço exato por rep (a validar com mercado / vendas iniciais)
+- Setup fee / implantação paga? (não decidido — pode ser bundle no Pro tier ou pago separado)
+- Treinamento avulso / consultoria como linha extra de receita? (não decidido)
+- Add-ons (WhatsApp tier premium? IA tier premium?) — possível, decidir quando produto amadurecer
--- a/design-artifacts/A-Product-Brief/dialog/client-profile.md
+++ b/design-artifacts/A-Product-Brief/dialog/client-profile.md
@@ -0,0 +1,86 @@
+# Client Profile: SAR — Força de Vendas
+
+**Cliente:** JCS Sistemas
+**Created:** 2026-05-26
+**Updated:** 2026-05-26
+
+---
+
+## Organisation
+
+| Field | Value |
+|-------|-------|
+| **Type** | PME estabelecida — software house (foco em sistemas de gestão / ERP / SaaS B2B) |
+| **Size** | 11–50 pessoas |
+| **Industry** | Software de gestão para empresas B2B brasileiras; vertical força de vendas + ERP |
+| **Tech maturity** | **Alta** — desenvolve software profissional há anos; já tem `STACK.md` v2.2 e `CODING-RULES.md` v2.0 formalizados; produtos legados em produção (app Android + Desktop) |
+| **Design maturity** | **Iniciante** — produtos funcionam, há identidade visual definida (`brand.md`), mas SAR é o **primeiro projeto com processo UX formal** (WDS). Legado parece ter sido conduzido por dev, sem designer dedicado |
+
+---
+
+## People
+
+### Primary Contact — Julian
+- **Role:** Product Owner + Tech Lead (acumula PO e responsabilidade técnica)
+- **Decision mandate:** **Autonomia total** — decide sozinho sobre escopo, prazo e design
+- **Notes:** Autor de `STACK.md` e `CODING-RULES.md`. Conduz o WDS pela linha de comando do Claude Code.
+
+### Champion (if different)
+- **Name:** Mesmo (Julian)
+- **Role:** —
+- **Notes:** Não há champion adicional. Julian é a força motriz única do SAR. Implicação: ritmo e momentum dependem 100% dele; não há outro patrocinador interno empurrando.
+
+### Technical Contact
+- **Name:** Mesmo (Julian)
+- **Role:** Tech Lead — escreveu a stack e as regras
+- **Notes:** Desenvolvimento principal ainda a definir (time JCS interno provável, dado o tamanho 11-50)
+
+### Other Stakeholders
+| Name | Role | Influence |
+|------|------|-----------|
+| — | — | — |
+
+Nenhum stakeholder externo mencionado nesta fase. Pode haver sócios/diretores na JCS, mas não participam diretamente do SAR.
+
+---
+
+## Decision Culture
+
+- **Decision style:** **fast-individual** — Julian decide, segue
+- **Approval chain:** Julian → execução. Sem comitê, sem signoff externo.
+- **Timeline culture:** **fast-iterative** — velocidade preferida, mas qualidade vem primeiro (sem prazo rígido forçando atalhos)
+
+---
+
+## Internal Driver
+
+- **What triggered this project:**
+  A JCS já oferece produtos legados (app Android + Desktop) para força de vendas e ERP. Viu **oportunidade de modernizar e unificar** esses dois mundos num único SaaS web — não como "conserto" do legado, mas como **upgrade de tier do produto**, integrando força de vendas + ERP de forma nativa.
+
+- **What success means internally:**
+  **Tornar a JCS competitiva como SaaS de força de vendas no mercado regional/nacional.** SAR é vitrine: prova de que a JCS sabe entregar produto digital moderno multi-tenant, com chance de escalar para clientes além da base atual.
+  Implicação política: SAR não é só "produto" — é **posicionamento de marca JCS**. Decisões de UX/qualidade refletem na empresa toda.
+
+- **Internal deadline or pressure:**
+  **Sem deadline rígido.** Preferência por momentum e velocidade, sem queimar qualidade por uma data específica. Pressuposto: progresso visível em meses (não anos).
+
+---
+
+## Working Style
+
+- **Communication preference:** **Sessões longas focadas** neste chat (Claude Code com WDS). Profundidade num turno, sem fragmentação async.
+- **Prior agency experience:** **Nenhuma** com agência/studio de design — estreia em processo UX formal. WDS é o primeiro framework de design adotado.
+- **Notes:**
+  - Comunicação em pt-BR
+  - Apresentação preferida: **recomendar com justificativa** (eu indico opção + porquê)
+  - Envolvimento balanceado: decisões-chave passam por ele, execução avança sem confirmação contínua
+  - Trabalha diretamente em terminal/CLI (Claude Code), valoriza ferramentas que respeitam o workflow técnico
+
+---
+
+## Implicações para o resto da Phase 1
+
+1. **Velocidade autorizada.** Sem comitê + decisão individual + sem deadline rígido = não preciso politicamente embalar recomendações; posso ser direto.
+2. **Tech-side já decidido.** Como Julian é tech lead e autor da stack, steps 27-32 (Platform Requirements) viram **consolidação documental**, não descoberta.
+3. **Design-side é o trabalho de verdade.** Steps 1-12 (Brief estratégico) + 13-18 (Content) são onde há maior lacuna a preencher.
+4. **SAR como vitrine** muda Phase 2: as personas não são só "rep externo / supervisor / admin" — incluem implicitamente **clientes-empresa em potencial** que vão avaliar a JCS pelo SAR.
--- a/design-artifacts/A-Product-Brief/dialog/competitive-landscape.md
+++ b/design-artifacts/A-Product-Brief/dialog/competitive-landscape.md
@@ -0,0 +1,170 @@
+# Competitive Landscape — SAR (Força de Vendas)
+
+**Confirmed:** 2026-05-26
+**Step:** 09 — Competitive Landscape
+
+> 5 alternativas analisadas (incluindo do-nothing). 5 unfair advantages identificados. Posição alvo: vendas-first + baixo atrito de implantação.
+
+---
+
+## 5 grupos de alternativa
+
+### 🔴 Grupo 1 — Apps verticais de força de vendas
+
+**Concorrentes:** Mercos · Promosoft · MaxFV · Workforce · Mobits
+
+| Dimensão | Análise |
+|---|---|
+| **Por que cliente fica** | Já implantado, time treinado, dados migrados são caros, suporte conhecido |
+| **O que fazem bem** | Catálogo+pedido funcional, integração ERP comum, atendimento em pt-BR |
+| **Onde falham** | Tela única (sem cockpits) · IA decorativa ou inexistente · WhatsApp externo · UX antiga (legados PHP/Java/Delphi) · sem real-time · caros após 50+ reps |
+| **SAR ataca onde** | 4 cockpits + IA estrutural + WhatsApp nativo + UX moderna |
+| **SAR aceita perder** | Clientes com > 1 ano de Mercos + 100+ reps treinados (custo de migração mata o deal) |
+
+### 🟠 Grupo 2 — ERPs com módulo de força de vendas
+
+**Concorrentes:** TOTVS · Sankhya · Senior · Bling · Tiny · Omie
+
+| Dimensão | Análise |
+|---|---|
+| **Por que cliente fica** | ERP é backbone — trocar é arriscado/caro; já tem certificações fiscais |
+| **O que fazem bem** | Contábil + fiscal + financeiro completos, NF, ICMS-ST robusto |
+| **Onde falham** | Módulo de vendas é ERP-first, não vendas-first; sem mobile real; sem IA; sem WhatsApp; UX desktop pesada |
+| **SAR ataca onde** | **Coexistência via API** — cliente não precisa trocar o ERP; SAR vira "camada de vendas" sobre TOTVS/Sankhya |
+| **SAR aceita perder** | Cliente enterprise com TOTVS full-stack ultra-integrado (raros no SMB) |
+
+### 🟡 Grupo 3 — Stack improvisado
+
+**Composição típica:** Excel + WhatsApp manual + ERP sem módulo de vendas
+
+| Dimensão | Análise |
+|---|---|
+| **Por que cliente fica** | Custo zero de software, controle total, sem treinamento |
+| **O que faz bem** | Customização total ad-hoc, flexibilidade |
+| **Onde falha** | Zero visibilidade, zero automação, zero IA, erros humanos crescem com volume |
+| **SAR ataca onde** | "Primeira ferramenta de verdade" — ROI óbvio quando SAR mostra "você tem X clientes esfriando que ninguém viu" |
+| **SAR aceita perder** | PMEs com < 5 reps ou que veem TI como inimigo |
+
+### 🟢 Grupo 4 — Apps caseiros (sob medida)
+
+**Cenário típico:** dev terceirizado construiu sistema próprio há 2-5 anos
+
+| Dimensão | Análise |
+|---|---|
+| **Por que cliente fica** | Custo afundado (já investiu R$ 50-200k), dev "conhece o negócio" |
+| **O que faz bem** | Customizações específicas |
+| **Onde falha** | Manutenção pesadelo, dev único = risco, sem roadmap, sem IA, sem multi-tenant, lentidão para evoluir |
+| **SAR ataca onde** | "Acabou o pesadelo de manutenção — roadmap contínuo sem custo extra" |
+| **SAR aceita perder** | Cliente cuja personalização real exige código (raro na prática) |
+
+### ⚪ Grupo 5 — **Do nothing** (não decidir)
+
+> A alternativa mais subestimada — provavelmente **50%+ dos prospects ficam aqui**.
+
+| Dimensão | Análise |
+|---|---|
+| **Por que cliente fica** | "Tá funcionando assim, pra que mexer?" · medo de complicar · orçamento alocado a outras coisas |
+| **O que perde silenciosamente** | **5-10% carteira/ano em churn silencioso** · decisões com dados velhos · reps talentosos migram pra concorrente com ferramenta melhor · concorrente ganha 1-2% market share/ano |
+| **Janela de mercado** | Próximos 2-3 anos B2B SaaS força de vendas vai **consolidar**. Quem espera entra com gap intransponível |
+| **SAR ataca como** | **Demo com dados reais do cliente** — "Olha quantos clientes pararam de comprar nos últimos 60 dias e ninguém viu". Choque que cria urgência. |
+
+---
+
+## Unfair advantages do SAR
+
+### Resistentes a cópia (alto moat, > 2 anos para concorrente neutralizar)
+
+1. **Concept estrutural "4 cockpits"**
+   Mercos/TOTVS são monolíticos; refazer pra cockpits especializados exige reescrita completa do produto. Não é roadmap, é re-arquitetura.
+
+2. **Multi-tenancy BD-por-workspace** (ADR 0006)
+   Arquitetura desde dia 0, não retrofit. Concorrentes em row-level `tenantId` precisam de 1-2 anos para migrar. Viabiliza integração ERP heterogênea + LGPD by design.
+
+3. **Stack moderna JCS** (Node 24 + Nest 11 + Prisma 7 + React 19.2)
+   Velocidade de desenvolvimento ~3x superior aos legados PHP/Java/Delphi. Não copiável sem virar a empresa toda.
+
+4. **IA estratégica desenhada desde o concept**
+   Concorrente que adiciona IA "bolt-on" vai ter feature, não diferencial estrutural. Atravessar os 4 cockpits exige a arquitetura cockpit-first.
+
+5. **Velocidade de iteração JCS** (decisão fast-individual)
+   Equipe pequena + dono-desenvolvedor pode iterar mensalmente; concorrentes corporates lançam anualmente. Vantagem de incumbent inverso (small wins fast).
+
+### Não sustentáveis (precisariam de outro moat para defender)
+
+| Feature | Tempo de cópia |
+|---|---|
+| WhatsApp nativo | 6-12 meses |
+| Editor de campanhas no-code | 1-2 anos |
+| UX moderna por papel | 1-2 anos |
+| Real-time entre cockpits | 6-12 meses |
+
+**Conclusão:** a defesa **não é feature isolada — é a combinação estrutural** dos 5 pontos resistentes. Concorrente que copiar 1-2 features fica atrás; copiar todos requer reescrita arquitetural de 2-3 anos.
+
+---
+
+## Reality checks (tentando derrubar o positioning)
+
+| Ameaça realista | Resposta do SAR |
+|---|---|
+| "Mercos lança IA em 2026" | IA bolt-on sobre tela única não é "4 cockpits + IA atravessando todos". Diferencial estrutural não copia em 1 ano. |
+| "TOTVS abre API gratuita do módulo deles" | SAR vira mais necessário, não menos — cliente quer trocar o módulo, não o ERP. Coexistência joga A FAVOR. |
+| "Surge novo SaaS BR com stack moderna" | Possível. Defesa: velocidade JCS + domain expertise (anos no setor) + canal de indicação. |
+| "WhatsApp Business muda regras de integração" | Risco real. Mitigação: arquitetura plug-in não acoplada + alternativa Telegram/SMS no roadmap. |
+| "IA não convence donos reais — só PMs com viés tech" | Risco real. Mitigação: IA **explicável** (cada alerta com "por que te digo isso") + validação no MVP (Daniel acessa IA 2x/semana é métrica north-star). Se falhar, IA vira feature secundária, não pilar. |
+
+---
+
+## Mapa estratégico
+
+```
+                    Alto custo de implantação
+                              ▲
+                              │
+              TOTVS  ●        │
+              Sankhya         │
+                              │       ● Apps caseiros
+                              │
+                              │
+   ◄─────────────────────────┼─────────────────────────►
+   ERP-first                  │              Vendas-first
+                              │
+                              │   ● Mercos
+                              │   ● Promosoft
+                              │
+              ● SAR           │
+              (vendas-first   │
+              + low-friction) │
+                              │
+                              │   ● Excel + WhatsApp
+                              │   (do-nothing-ish)
+                              ▼
+                    Baixo custo de implantação
+```
+
+**Posição alvo:** **vendas-first + baixo atrito de implantação** — quadrante semi-vazio onde apps verticais (alto atrito, vendas-first) e stack improvisado (zero atrito, baixíssimo valor) deixam espaço.
+
+---
+
+## Implicações estratégicas
+
+### Para a venda
+1. **Demo precisa atacar do-nothing primeiro, não Mercos.** A urgência ("você está perdendo silenciosamente") vence mais leads que o comparativo direto.
+2. **Comparativos públicos no site** (SAR vs Mercos, SAR vs TOTVS) só para leads quentes já comparando — segmento minoritário.
+3. **Coexistência com ERP é mensagem-chave** para clientes Grupo 2 — não "troque o TOTVS", e sim "deixe o TOTVS, troque o módulo de vendas".
+
+### Para o produto
+1. **Manter os 5 unfair advantages estruturais inviolados em todas decisões** — antes de qualquer feature, perguntar: isso compromete cockpits? multi-tenant? velocidade JCS? IA estrutural? stack moderna?
+2. **IA precisa ser explicável desde MVP** — não black-box. Caso contrário diferencial não convence.
+3. **Plug-in para WhatsApp** (não acoplado) — proteção contra mudança de regras Meta.
+
+### Para a estratégia
+1. **Janela de 2-3 anos para entrincheirar.** Depois, ou o SAR é referência, ou entrou tarde demais. Velocidade do MVP (3-4 meses) é decisão estratégica, não apenas operacional.
+2. **Foco em referenciabilidade** sobre tração massiva — primeiros 10 clientes precisam virar cases públicos para alimentar canal #1 (boca-a-boca).
+
+---
+
+## Lacunas conscientemente adiadas
+
+- Benchmark de preço detalhado dos concorrentes (Mercos, Promosoft) — captura no go-to-market
+- Análise SWOT individual por concorrente — não prioritária no Brief; pode entrar em Phase 3 PRD
+- Concorrentes internacionais (Salesforce SMB, HubSpot) — fora do alcance prático no SMB brasileiro hoje
--- a/design-artifacts/A-Product-Brief/dialog/constraints.md
+++ b/design-artifacts/A-Product-Brief/dialog/constraints.md
@@ -0,0 +1,188 @@
+# Constraints — SAR (Força de Vendas)
+
+**Confirmed:** 2026-05-26
+**Step:** 10 — Constraints
+
+> Reposicionados como **parâmetros de design** — o que dá forma ao SAR. Fixo = certeza estratégica; Flexível = decidimos depois.
+
+---
+
+## ⚠️ Tensão estratégica explícita (flagueada por Saga)
+
+**O combo decidido:**
+- Concept ambicioso (4 cockpits + WhatsApp nativo + IA estratégica + multi-tenant + real-time)
+- MVP em 3-4 meses
+- **Solo founder mode** (Julian full-time até 1º cliente)
+
+**A matemática não fecha sem trade-off.** Solo + 3-4 meses não comporta o concept completo no MVP.
+
+### Resolução proposta (a confirmar em Phase 3 PRD)
+
+**MVP mínimo defensível** (refinar em Phase 3):
+- ✅ **Rep cockpit** (Rafael — primária, mobile-first) — obrigatório
+- ✅ **Supervisor cockpit** (Sandra — influenciadora-chave da venda) — obrigatório, mas em forma simplificada
+- ✅ **Arquitetura multi-tenant BD-por-workspace** — fundacional, não dá pra adiar
+- ✅ **WhatsApp** — versão básica (envio de notificações; recebimento e conversa bidirecional pode ser fase pós-MVP)
+- 🟡 **Dono cockpit** (Daniel) — dashboard simples no MVP; **IA estratégica entra pós-MVP** (validar primeiro cliente)
+- 🟡 **Admin cockpit** (Alice) — cadastros essenciais + pautas; **editor no-code de campanhas entra pós-MVP**
+
+**Justificativa:** 1º cliente do MVP é referência interna ou parceiro próximo (não cold lead). Pode aceitar limitações em troca de preço/condições especiais. Quando o 1º cliente renova (north star MVP), Julian contrata 1-2 devs e completa IA + editor no-code + cockpits ricos.
+
+**Alternativa (se o trade-off for inaceitável):**
+- Reduzir solo period — contratar 1 dev mesmo antes do 1º cliente
+- OU esticar MVP para 5-6 meses
+- OU reduzir concept (sacrificar 1 cockpit ou um diferencial)
+
+---
+
+## Timeline
+
+### Fixo
+- **MVP em produção com 1º cliente real:** 3-4 meses (a partir de 2026-05-26)
+- **North star MVP:** 1º cliente renova em mês 6-7
+- **Janela de mercado:** 2-3 anos para entrincheirar antes de saturação SaaS força de vendas BR
+- **10 clientes pagantes:** ~mês 12
+
+### Flexível
+- Ordem das features dentro do MVP
+- GA público / fim de beta (depende de qualidade do MVP)
+- Sem deadline externo rígido (não há feira/contrato amarrando data)
+
+### Implicação de design
+> "Build to learn, not to plan." MVP minimalista, instrumentado para medir desde dia 0.
+
+---
+
+## Budget
+
+### Fixo
+- **Stakes:** small-business (PME software house, 11-50 pessoas) — não é Series A
+- **CAC payback < 12 meses** (Step 8) — limita o quanto se pode gastar para adquirir cada cliente
+- **Aquisição inicial baixa-fricção:** indicação + SEO antes de ads pagos pesados
+- Sem orçamento para infra de luxo — STACK.md self-host Proxmox já calibrado para isso
+
+### Flexível
+- Tamanho do time escala com tração
+- Investimento em marketing escala com receita
+- Eventos/feiras escolhidos seletivamente
+
+### Implicação de design
+> Stack canônica self-host (Proxmox) + multi-tenancy bem feita = custo de infra por workspace baixíssimo. Crescimento sustentável.
+
+---
+
+## Recursos humanos
+
+### Fixo (estado atual)
+- **Julian:** PO + Tech Lead + Champion + único dev (solo founder mode até 1º cliente)
+- Sem time de design dedicado — estreia em processo UX formal via WDS
+- Atendimento/SDR inicial = Julian
+
+### Premissa pós-MVP (a confirmar quando 1º cliente fechar)
+- Contratar 1-2 devs adicionais para acelerar IA + editor no-code + cockpits ricos
+- Atendimento eventualmente separado
+
+### Flexível
+- Quem são os devs adicionais (interno JCS / freelance / contratação)
+- Timing de profissionalização do atendimento
+
+### ⚠️ Implicação crítica
+> Solo founder mode é o **constraint mais apertado** do projeto. Toda decisão de escopo no MVP precisa respeitar isso. Tudo que "pode esperar pra fase 2" → vai pra fase 2.
+
+---
+
+## Técnico — STACK.md v2.2 (FIXO por escolha do PO)
+
+| Camada | Decisão |
+|---|---|
+| Runtime | Node 24 LTS · pnpm 11.1 · TypeScript 5.9 |
+| Monorepo | Nx 22.7 (`apps/api` + `apps/web` + `libs/`) |
+| Backend | NestJS 11.1 · Prisma 7 · PostgreSQL 18 · BullMQ · nestjs-cls |
+| Frontend | React 19.2 · Vite 8 · Ant Design 6.4 · TanStack Query/Router · Zustand |
+| API | REST + OpenAPI 3.1 + RFC 9457 · Zod 4 (catalog) · nestjs-zod |
+| Auth | master-login (IdP próprio) · jose · argon2id |
+| Multi-tenancy | **BD-por-workspace** (ADR 0006) |
+| Real-time | Socket.IO 4 + redis-adapter (Valkey) · SSE nativo NestJS |
+| Secrets | HashiCorp Vault (KV v2) self-host |
+| Observabilidade | Pino + OpenTelemetry · Grafana Cloud LGTM · Sentry |
+| Filas | BullMQ 5.77 |
+| Uploads | MinIO (S3-compat) + ClamAV worker · sharp |
+| Email | Resend (SaaS) + React Email via BullMQ |
+| Infra | Proxmox on-prem BR (ADR 0004) · Docker Compose · Ansible deploy |
+| CDN | Cloudflare + Nginx para SPA estática |
+
+### Flexível (decidir em Step 29 — Integrations)
+- **Provider de pagamento:** Stripe / Iugu / Pagar.me / Gerencianet
+- **Provider de IA:** OpenAI / Anthropic / local
+- **WhatsApp Business API:** oficial Meta vs intermediário (Z-API, Twilio, Gupshup)
+- **Analytics de produto:** PostHog self-host? Amplitude? Misto?
+
+### Implicação de design
+> "STACK.md é fonte da verdade. Nada de propor PostgREST, Supabase, Next.js, trocar AntD por shadcn." Decisões fora da tabela exigem RFC.
+
+---
+
+## Brand — brand.md (FIXO por escolha do PO)
+
+### Fixo
+- **Paleta:** JCS Blue `#004a99` como único destaque cromático
+- **Tipografia:** Plus Jakarta Sans (pesos 400/500/600/700/800)
+- **Ícones:** Font Awesome 6.4.0
+- **Gráficos:** Chart.js
+- **Radius:** 12px (md) / 20px (lg)
+- **Sombra padrão:** `0 4px 25px rgba(0,0,0,0.05)`
+- **Layout base:** topbar 80px + sidebar 260px fixa (cockpits Sandra/Daniel/Alice)
+- **Tom visual:** Apple-inspired, clean, minimalista
+
+### Flexível (Phase 6 Design System detalha)
+- **Variações por cockpit** — especialmente Rafael mobile-first (navegação inferior, single-column, touch-friendly)
+- Tokens secundários (estados de feedback) dentro da paleta JCS
+- Tom de voz textual (Steps 13-15)
+- Imagery (Step 25)
+- **Dark mode** (desejável especialmente Rafael à noite)
+
+### Implicação de design
+> brand.md é a base. Phase 6 (Design System) **estende** com variantes por cockpit, não substitui.
+
+---
+
+## Regulatório / LGPD (FIXO — STACK.md §22)
+
+| Item | Decisão |
+|---|---|
+| **Base legal** | Execução de contrato (cliente-empresa é controlador; SAR é operador) |
+| **Isolamento** | Físico — cluster PG dedicado por workspace (ADR 0006) |
+| **Datacenter** | BR (Proxmox on-prem) — elimina exposição ao CLOUD Act US |
+| **PII** | Criptografada — MinIO SSE + `pgcrypto` |
+| **Logs** | Redact agressivo (CPF, cardNumber, password, authorization, cookie) |
+| **Auditoria** | Art. 18 LGPD (acesso/correção/eliminação de dados pessoais) |
+| **Hash em targeting de flags** | Para feature flags com info pessoal |
+
+### Implicação adicional para WhatsApp + IA
+- DPA (Data Processing Agreement) obrigatório com providers externos (Meta, OpenAI/Anthropic)
+- Hashar dados de cliente antes de mandar para IA (não enviar nome, CPF, telefone real)
+- WhatsApp: cliente do SAR opt-in explícito do contato final (cliente-do-cliente) antes do primeiro envio
+
+---
+
+## Dependências externas (risco fixo, mitigação flexível)
+
+| Dependência | Risco | Mitigação |
+|---|---|---|
+| Meta WhatsApp Business | Mudança de regras → integração quebra | Arquitetura plug-in; alternativas Telegram/SMS no roadmap |
+| OpenAI / Anthropic / IA externa | Mudança de pricing, quota, política | Abstração de provider; capacidade de trocar |
+| Resend (email) | SaaS pode mudar tier | Migrar para SES/Mailgun; abstração de envio |
+| Cloudflare (CDN) | SaaS muda preço/política | Migrar para outro CDN; impacto baixo |
+| Provider BR de pagamento | Falha/lentidão pode bloquear cobrança | Multi-provider com fallback (Step 29) |
+
+---
+
+## Resumo: o que o constraint map nos diz
+
+1. **MVP precisa ser radicalmente priorizado** — solo + 3-4 meses não comporta o concept completo. Refinar em Phase 3 PRD.
+2. **Rafael + Sandra são obrigatórios** no MVP; Daniel e Alice entram em forma simplificada.
+3. **IA estratégica entra pós-MVP** — depois do 1º cliente validado.
+4. **Editor de campanhas no-code** (Alice) entra pós-MVP — pode usar tela direta no MVP.
+5. **Stack canon JCS + brand.md são parâmetros, não restrições negativas** — eliminam decisões e aceleram desenvolvimento.
+6. **LGPD by design** alinha com o concept multi-tenancy físico — não é overhead, é diferencial competitivo.
+7. **Solo founder mode é o constraint mais apertado** — todo escopo precisa respeitar isso. Tudo que pode esperar → espera.
--- a/design-artifacts/A-Product-Brief/dialog/decisions.md
+++ b/design-artifacts/A-Product-Brief/dialog/decisions.md
@@ -0,0 +1,768 @@
+# Decisões — Phase 1 (Project Brief)
+
+> Log de decisões-chave tomadas durante a Phase 1. Append-only.
+
+---
+
+## 2026-05-26 — Step 1a (Client Profile)
+
+### Organização
+- **JCS Sistemas** é PME estabelecida (software house), 11-50 pessoas, alta maturidade técnica, design ainda iniciante.
+- SAR é o **1º projeto da JCS com processo UX formal**.
+
+### People & decisão
+- **Julian** acumula 3 papéis: Product Owner + Tech Lead + único Champion.
+- **Autonomia total** para decidir escopo/prazo/design.
+- **Cultura fast-individual:** sem comitê, sem signoff externo, decisões saem rápido.
+
+### Driver
+- SAR **não é "consertar legado"**. É **upgrade de tier**: unificar força de vendas (app Android) + ERP (Desktop) num **SaaS web vendável**.
+- **Sucesso = JCS competitiva como SaaS de força de vendas regional/nacional.**
+- SAR funciona como **vitrine de marca JCS** — vai além de produto, é posicionamento.
+
+### Working style
+- Sem deadline rígido.
+- Sessões longas focadas no chat.
+- Velocidade > formalismo (mas qualidade > velocidade quando conflitam).
+
+### Implicações
+- Posso ser direto em recomendações (sem precisar embalar politicamente).
+- Steps 27-32 (Platform) vão ser **consolidação documental** via STACK.md, não descoberta.
+- Steps 1-12 (Brief estratégico) e 13-18 (Content) são onde há trabalho real.
+- Phase 2 (Trigger Map) precisa considerar **clientes-empresa potenciais** como persona implícita, além dos 3 perfis usuários (rep / supervisor / admin).
+
+---
+
+## 2026-05-26 — Step 2 (Vision)
+
+### Vision statement aprovada
+> SAR é a plataforma de força de vendas que dá clareza para o representante, ferramenta de decisão para o supervisor, e IA estratégica para o dono — entregue como SaaS web, vendável e escalável, posicionando a JCS Sistemas como fornecedora de software moderno para o mercado B2B brasileiro.
+
+### Decisões-chave reveladas
+1. **3 experiências distintas, não 3 telas iguais.** Rep, Supervisor e Dono usam o SAR de modos qualitativamente diferentes (operacional ↔ tático ↔ estratégico).
+2. **WhatsApp é canal nativo, não integração anexa.** Implica API WhatsApp Business no escopo desde o início.
+3. **IA estratégica para o dono é diferencial declarado.** Implica decidir cedo o escopo de IA (insights generativos? alertas? recomendações?).
+4. **Inteligência de carteira ativa** (inativos, ciclo, oportunidades) — não é "relatório", é parte do produto-base.
+5. **SaaS multi-tenant é o pulo qualitativo**, não "ter mais features que o legado". Distribuição/instalação é o gargalo que o web resolve.
+
+### Implicações para próximos steps
+- Step 3 (Positioning): diferenciais já mapeados (6 itens), prontos para virar positioning statement.
+- Step 7 (Target Users): rep / supervisor / dono (não "admin" do brand.md — o dono é uma persona estratégica distinta).
+- Step 9 (Competitive Landscape): SaaS força de vendas regional/nacional — Mercos, Promosoft, Workforce, etc.
+- Step 10 (Constraints): IA + WhatsApp + multi-tenant impõem escolhas técnicas e regulatórias (LGPD reforçada).
+
+### Lacuna documentada
+- "Cena concreta do dia típico" (pergunta #1) ficou em aberto, será retomada na Phase 2 (Trigger Map).
+
+---
+
+## 2026-05-26 — Step 3 (Positioning)
+
+### Target customer
+- 4 perfis válidos: Distribuidoras, Indústrias, RCAs, PMEs com vendas externas
+- **Sweet spot:** 5-50 representantes na rua (mid-SMB)
+
+### Categoria
+- Plataforma SaaS de Força de Vendas (SFA)
+
+### Dor central
+- **Donos e supervisores decidem no escuro** — não têm visibilidade em tempo real do que acontece na rua
+
+### Concorrência
+- Apps verticais: Mercos, Promosoft, MaxFV, Workforce, Mobits
+- ERPs com módulo: TOTVS, Sankhya, Senior
+- Stack improvisado: Excel + WhatsApp + ERP
+- Apps caseiros sob medida
+
+### Implicações estratégicas chave
+1. **Coexistência com ERPs como diferencial** — multi-tenancy BD-por-workspace facilita integração heterogênea por cliente
+2. **WhatsApp nativo e IA estão no MVP**, não em roadmap futuro
+3. **3 experiências distintas** é pilar de marca, não detalhe
+4. **"Visibilidade em tempo real" é promessa-mãe** — implica websockets/SSE no produto desde o lançamento
+5. **Pricing range** definido pelo sweet spot 5-50 reps (mid-SMB, não enterprise nem micro)
+
+### 4 estratégias de aquisição por origem
+- App vertical concorrente → ganho de IA + 3 experiências + WhatsApp
+- Módulo de ERP → coexistência, não migração
+- Stack improvisado → primeira ferramenta de verdade
+- App caseiro → fim do pesadelo de manutenção
+
+---
+
+## 2026-05-26 — Step 5 (Business Model)
+
+### Modelo escolhido
+- **B2B SaaS multi-tenant, per-seat, sales-led, com trial real**
+- Cobrança: **per-seat** (por rep ativo/mês)
+- Sales motion: **sales-led** (demo + proposta + acompanhamento comercial)
+- Trial: **14-30 dias** com dados reais (workspace sandbox)
+- Contrato: **híbrido** — mensal sem fidelização OU anual prepago com desconto (10-20%)
+
+### Ticket médio estimado (R$ 150/rep referência)
+- Pequeno (5-10 reps): R$ 750-1.500/mês → ARR R$ 9k-18k
+- Médio baixo (11-25): R$ 1.650-3.750/mês → ARR R$ 20k-45k
+- Médio alto (26-50): R$ 3.900-7.500/mês → ARR R$ 47k-90k
+
+### Implicações técnicas chave
+1. Precisa **active rep counter** no produto (define cobrança)
+2. Trial exige **provisioning automatizado** de workspace + seed opcional
+3. Billing suporta **cobrança mensal recorrente + cobrança anual única** (provider a decidir em Step 29 — Iugu/Pagar.me/Gerencianet/Stripe)
+4. Workspace sandbox de trial reusa arquitetura BD-por-workspace (ADR 0006) — não é caso especial
+
+### Implicações de marketing
+- **CTA principal do site:** "Agende demo", não "Sign up free"
+- **Trial é gated:** form → SDR qualifica → demo → liberação
+- **Pricing page** explícita no site
+
+### Lacunas conscientemente adiadas
+- Preço exato/rep (validar com mercado)
+- Setup fee / implantação paga (não decidido)
+- Add-ons premium (WhatsApp tier? IA tier?) — futuro
+
+---
+
+## 2026-05-26 — Step 6 (Business Customers)
+
+### Buyer persona — "O Dono Empresário B2B"
+- 35-60 anos, sócio-fundador ou herdeiro, gerencia "no peito"
+- Critério: **fé que vai funcionar**, não TCO planilhado
+- Convence: demo concreta + boca-a-boca + cases
+- Assusta: aprendizagem do time, complexidade, custo
+
+### Estrutura de decisão
+- **Decisor:** dono OU diretor comercial (varia por porte)
+- **Influenciadores que matam o deal:** supervisor de vendas + reps champions
+- **Ausentes:** financeiro, TI, jurídico (venda operacional-emocional, não técnico-financeira)
+
+### Canais de aquisição (4 ativos)
+- Indicação boca-a-boca + Google/SEO + feiras setoriais + parceiros (contadores, revendedores ERP)
+- Implica: programa de referral, blog SEO, calendário de feiras, página de parceiros
+
+### Ciclo por porte
+- Pequeno (5-10 reps): 2-4 semanas
+- Médio baixo (11-25): 1-2 meses
+- Médio alto (26-50): 2-4 meses (POC possível)
+
+### Implicações chave
+1. **Demo-friendliness obrigatória** — produto precisa brilhar em 5 min, sem hand-holding
+2. **Site precisa 3 páginas por papel** (`/para-donos`, `/para-supervisores`, `/para-representantes`)
+3. **Comparativos diretos** com Mercos/TOTVS no site (combate frontal)
+4. **WhatsApp visível na primeira tela** do produto (diferencial declarado)
+5. **JCS precisa de CRM próprio** para venda — possível dogfood (vender SAR com SAR)
+6. **Conteúdo SEO:** controle de rep externo, força de vendas para distribuidora, WhatsApp + B2B
+
+---
+
+## 2026-05-26 — Step 7 (Target Users)
+
+### 4 user personas confirmados
+1. **Rafael Representante (PRIMÁRIA — MVP focus)** — 30-50a, mobile-first, 70-90% do volume de uso
+2. **Sandra Supervisora** — 35-55a, desktop+mobile, "apertar parafusos diários"
+3. **Daniel Dono** — 40-65a, desktop/iPad, IA estratégica, overlap com buyer persona
+4. **Alice Admin (nova)** — 25-45a, desktop-only, pautas/promoções/tributação
+
+### Decisão crítica de design
+- **Mobile-first para Rafael, desktop-first para os outros 3.** SAR não é "responsivo único" — são paradigmas de UI distintos no mesmo produto.
+- App do Rafael deve funcionar com sinal 3G/4G ruim (offline-resiliente parcial)
+- Touch-friendly + dark mode desejável
+
+### Insights de produto (entram em Phase 3/4)
+- **Editor de campanhas/promoções no-code** vira diferencial declarado (foi mencionado como responsabilidade Alice)
+- **Assistente de tributação ICMS-ST** por NCM+UF — diferencial vs ERP-modules
+- **Auditoria/trilha de mudanças** em pautas, produtos, cadastros (Alice precisa, regulatório também)
+- **WhatsApp integrado** + **comissão em tempo real** + **funil kanban** são fundamentos do Rafael
+- **IA explicável** para Daniel (não black box; alertas com contexto)
+
+### Insight de venda (refina Step 6)
+- Demo precisa: **brilhar para Sandra** (influenciadora), **vender para Daniel** (decisor), **encantar Rafael** (champion)
+- Alice é benefício mostrado, não argumento de venda
+
+---
+
+## 2026-05-26 — Step 7a (Product Concept)
+
+### Concept estrutural canônico
+> **SAR é uma plataforma de 4 cockpits especializados (Rep / Supervisor / Dono / Admin) compartilhando um dado único em tempo real, atravessado por WhatsApp nativo e IA contextual.**
+
+### Metáfora canônica
+- "Equipe de Fórmula 1" — cada papel tem seu próprio dashboard, mas todos veem o mesmo carro em tempo real
+
+### 4 princípios de implementação
+1. **Cada cockpit tem UX/device-target próprios** (Rafael mobile-first, outros desktop-first)
+2. **Camada de dados única em tempo real** (Socket.IO + SSE, <2s entre cockpits)
+3. **WhatsApp e IA são fios horizontais**, não módulos isolados
+4. **Multi-tenancy BD-por-workspace** garante isolamento físico + facilita integração ERP heterogênea
+
+### Tensões deliberadas aceitas
+- Construir 4 UX paradigmas em vez de 1 responsivo (custo alto, diferencial alto)
+- Tempo real obrigatório (custo de infra, ganho de promessa)
+- WhatsApp/IA como pilares horizontais desde MVP (não roadmap)
+
+### Implicações arquiteturais
+- **Phase 6 (Design System) não é opcional** — tokens compartilhados + variantes por cockpit
+- Cada cockpit possível epic na PRD; atravessadores (WhatsApp/IA/real-time/multi-tenant) viram epics horizontais
+- Broadcast WebSocket sempre escopado a workspace (não global) — alinha com BD-por-workspace
+
+---
+
+## 2026-05-26 — Step 8 (Success Criteria)
+
+### North Star MVP
+- **1º cliente real paga e renova sem cancelar nos primeiros 3 meses após go-live**
+- Critério: retenção provada > tração massiva
+
+### Y1 comercial (12 meses pós-GA)
+- **10-20 clientes pagantes** (conservador) | NPS donos > 50 | ARR R$ 200k-600k
+
+### Timeline-chave
+- **MVP em produção com 1º cliente real: 3-4 meses** (a partir de 2026-05-26)
+- MVP validado: mês 6-7 (1º cliente renova)
+- 10 clientes pagantes: mês 12
+- Premissa: Julian + 1-2 devs adicionais
+
+### Targets críticos por camada
+- **Negócio JCS:** logo churn < 3%/mês · NPS > 50 · CAC payback < 12m · NRR > 110%
+- **Cliente:** +15-30% pedidos/rep/mês · 10-20% inativos recuperados · aprovação desconto < 30 min · DAU/MAU reps > 80%
+- **Comportamento usuário:** Rafael > 95% pedidos no SAR + DAU/MAU > 70% · Sandra > 90% aprovações pelo SAR · Daniel > 2x/sem IA · Alice > 80% campanhas no-code
+- **Qualidade:** p95 tela < 800ms · p95 pedido < 60s · uptime 99.5% · pedidos perdidos = 0 · workspace provisionado < 5 min
+
+### Implicação técnica chave
+- **Instrumentação de produto no MVP, não em Phase 2 de roadmap**:
+  - OTel + Pino + Grafana (já em STACK.md §09)
+  - Analytics de produto (PostHog/Amplitude/self-host)
+  - Módulo de feedback in-app para NPS
+
+### Riscos definidos
+- Rafael não adota → DAU/MAU < 50% em 60d
+- Sandra não confia → aprovações por WhatsApp > 30%
+- Daniel ignora IA → < 1x/semana
+- North star falha → cliente cancela em 3m
+- P0 imediato: qualquer pedido perdido por bug
+
+---
+
+## 2026-05-26 — Step 9 (Competitive Landscape)
+
+### 5 grupos de alternativa analisados
+1. Apps verticais (Mercos, Promosoft, MaxFV, Workforce, Mobits) — SAR ataca via 4 cockpits + IA + WhatsApp nativo
+2. ERPs com módulo (TOTVS, Sankhya, Senior, Bling, Tiny, Omie) — SAR ataca via **coexistência** (não migração)
+3. Stack improvisado (Excel + WhatsApp + ERP sem módulo) — SAR ataca via "primeira ferramenta de verdade"
+4. Apps caseiros — SAR ataca via roadmap contínuo + fim do pesadelo de manutenção
+5. **Do nothing** (50%+ dos prospects) — SAR ataca via choque "5-10% carteira/ano perdida silenciosamente"
+
+### 5 unfair advantages estruturais (alto moat, >2 anos para concorrente neutralizar)
+1. **Concept estrutural "4 cockpits"** — reescrita completa para copiar
+2. **Multi-tenancy BD-por-workspace (ADR 0006)** — arquitetura desde dia 0
+3. **Stack moderna JCS** — Node 24 + Nest 11 + Prisma 7 + React 19.2 (~3x velocidade vs PHP/Java/Delphi)
+4. **IA desenhada desde concept** — não bolt-on
+5. **Velocidade de iteração JCS** — equipe pequena + decisão fast-individual → iteração mensal vs anual
+
+### Vantagens não-sustentáveis (copiáveis em 6-24 meses)
+- WhatsApp nativo, editor no-code, UX moderna, real-time
+- **Defesa estratégica: a combinação estrutural** dos 5 itens resistentes, não feature individual
+
+### Posição estratégica alvo
+- **Vendas-first + baixo atrito de implantação** — quadrante semi-vazio do mapa competitivo
+
+### Implicações estratégicas
+1. **Demo ataca do-nothing primeiro**, não Mercos — urgência vende mais que comparativo
+2. **Coexistência com ERP é mensagem-chave** para Grupo 2
+3. **IA precisa ser explicável desde MVP** — black box não convence donos
+4. **WhatsApp via arquitetura plug-in** (não acoplado) — proteção contra mudanças Meta
+5. **Janela de 2-3 anos para entrincheirar** — velocidade do MVP (3-4 meses) é decisão estratégica
+6. **Foco em referenciabilidade** > tração massiva — primeiros 10 clientes viram cases públicos
+
+---
+
+## 2026-05-26 — Step 10 (Constraints)
+
+### ⚠️ Tensão estratégica explícita (flagueada)
+**Combo decidido:** concept ambicioso + MVP 3-4 meses + **solo founder mode** (Julian full-time até 1º cliente).
+**A matemática não fecha sem trade-off.**
+
+### Resolução proposta (refinar em Phase 3 PRD)
+**MVP mínimo defensível:**
+- ✅ Rep cockpit (Rafael) — obrigatório
+- ✅ Supervisor cockpit (Sandra) — obrigatório, simplificado
+- ✅ Multi-tenant BD-por-workspace — fundacional
+- ✅ WhatsApp — versão básica (notificações; conversa bidirecional pós-MVP)
+- 🟡 Dono cockpit (Daniel) — dashboard simples; **IA estratégica entra pós-MVP**
+- 🟡 Admin cockpit (Alice) — cadastros essenciais; **editor no-code de campanhas entra pós-MVP**
+
+**Premissa:** 1º cliente é referência interna/parceiro próximo, aceita limitações em troca de condições especiais. Quando renova (north star), Julian contrata 1-2 devs e completa.
+
+### Constraints fixos
+- **Timeline:** MVP 3-4 meses, janela mercado 2-3 anos
+- **Budget:** small-business, CAC payback < 12m
+- **Time:** **solo founder mode até 1º cliente** (Julian acumula tudo)
+- **Stack:** STACK.md v2.2 é fonte da verdade (RFC para mudanças)
+- **Brand:** brand.md (paleta JCS + Plus Jakarta + AntD 6.4 + topbar/sidebar + tom Apple)
+- **Regulatório:** LGPD by design (isolamento físico multi-tenant, redact, criptografia PII)
+
+### Constraints flexíveis (decisão pós-Brief)
+- Provider de pagamento (Step 29)
+- Provider de IA (Step 29)
+- WhatsApp Business API provider (Step 29)
+- Analytics de produto (Step 8 já flagueado)
+- Dark mode (desejável especialmente Rafael)
+
+### LGPD adicional para WhatsApp + IA
+- DPA com Meta e OpenAI/Anthropic obrigatório
+- Hashar dados antes de enviar para IA (sem nome/CPF/telefone real)
+- Opt-in explícito do contato final no WhatsApp
+
+---
+
+## 2026-05-26 — Step 10a (Platform Strategy)
+
+### Plataforma primária
+- **Web SaaS** (React 19.2 SPA + Vite 8 + Nginx + Cloudflare) — STACK.md
+- Sem app store; deploy = rolling docker-compose em VMs Proxmox
+
+### Device strategy por cockpit
+- **Rafael (Rep):** **PWA mobile-first** com foco primário em **iOS** (gap onde JCS não tem app native). Android secundário (existe legado, mas reps podem optar pelo PWA).
+- **Sandra (Supervisora):** Desktop + PWA mobile-light para consultas/aprovações rápidas.
+- **Daniel (Dono):** Desktop + **iPad first-class** (otimização dedicada).
+- **Alice (Admin):** Desktop-only.
+
+### Coexistência com app Android legado
+- **MVP:** SAR PWA + backend SAR construídos do zero. Android legado intocado.
+- **Pós-MVP (Y1+):** Adaptar app Android legado para consumir backend SAR (unificar fonte da verdade).
+- **Futuro (Y1-Y2):** Avaliar native iOS + native Android sobre backend SAR (Capacitor/React Native).
+
+### Offline strategy (Rafael)
+- **Nível:** Read + Write com sync
+- Lançamento de pedido offline → IndexedDB queue → Service Worker sync quando volta online
+- Conflict resolution: Last-write-wins para rascunho; pedido submetido imutável
+- Idempotency-Key por pedido (UUID local) protege contra duplicação no sync
+
+### Native features no MVP
+- ✅ Geolocation (check-in Rafael)
+- ✅ Web Push (Sandra aprovação, Rafael pedido aprovado) — exige PWA + VAPID
+- ✅ Share API (Rafael compartilha pedido via WhatsApp do celular dele)
+- ✅ Notification API desktop (Sandra)
+- 🟡 Pós-MVP: Camera, File System Access, Voice (este descartado por segurança rodoviária)
+
+### Acessibilidade
+- WCAG AA mínimo desde MVP
+
+### Implicação de execução
+- PWA exige investimento explícito ~1-2 semanas no MVP
+- iPad first-class implica testes regulares em iPad Safari durante Phase 4
+- Web Push backend reusa BullMQ jobs (alinha com STACK.md §11)
+
+---
+
+## 2026-05-26 — Step 11 (Tone of Voice)
+
+### 5 atributos canônicos
+1. **Direto** — sem floreio
+2. **Profissional sem ser frio** — sério, mas humano (não burocratês)
+3. **Confiante** — afirmativo, não tentativo
+4. **Específico** — números/dados sempre que possível
+5. **Empático nos momentos difíceis** — problema + caminho para resolver
+
+### Variações por cockpit (mesmos atributos, registros distintos)
+- Rafael: informal, frases curtas
+- Sandra: direto + decisivo
+- Daniel: executivo, foco em insight
+- Alice: técnico-preciso
+
+### Don'ts
+- Emoji em produção (brand clean Apple)
+- Caps lock para erros
+- Burocratês ("operação", "registro", "movimentação")
+- "Por favor"/"obrigado" excessivo
+- Anglicismos onde tem pt-BR (Submit→Enviar)
+- Frases dúbias ("Talvez", "Possivelmente")
+
+### Vocabulário canônico (padrão único)
+- Cliente · Representante/Rep · Orçamento · Pedido · Faturado · Visita · Carteira · Inativo · Painel · Aprovação
+
+### Implicação
+- Vocabulário vira tokens i18n centralizados (não strings espalhadas)
+- Phase 6 Design System inclui guia de microcopy
+- Prompt de IA generativa precisa incluir esses 5 atributos + vocabulário canônico
+
+---
+
+## 2026-05-26 — Step 12 (Create Product Brief) — BLOCK A COMPLETO
+
+### Product Brief synthesis
+- **Narrativa estratégica apresentada** como história coerente (não checklist)
+- **User confirmation:** confirmado sem ajustes
+- **Brief gerado:** `design-artifacts/A-Product-Brief/01-product-brief.md`
+
+### Conteúdo do brief canônico
+- Resumo estratégico
+- Vision + 3 experiências + 7 diferenciais
+- Positioning (framework Geoffrey Moore) + mapa estratégico
+- 4 personas (Rafael primária + Sandra + Daniel + Alice)
+- Buyer × User mapping
+- Business model (per-seat sales-led trial + contrato híbrido)
+- Buyer persona "Dono Empresário B2B"
+- Canais de aquisição (4) + ciclo por porte
+- Success criteria (North Star MVP + 4 camadas de métricas)
+- Competitive landscape (5 grupos + 5 unfair advantages + janela de mercado)
+- Constraints (tensão solo + 3-4 meses + concept ambicioso flagueada)
+- Platform strategy (PWA iOS + offline + native features)
+- Tone of voice (5 atributos + vocabulário canônico + don'ts)
+- Riscos + mitigações
+- Próximos passos (Blocks B, C, D, E)
+
+### Status do Block A
+- **CONCLUÍDO** — Steps 1, 1a, 2, 3, 5, 6, 7, 7a, 8, 9, 10, 10a, 11, 12 (14 steps)
+- Tempo decorrido: ~2-3 horas em uma sessão
+- Próximo: Block B (Content & Language) — Steps 13-18
+
+---
+
+## 2026-05-26 — Step 13 (Content Init) — BLOCK B INICIADO
+
+### Materiais herdados
+- `brand.md` — identidade visual + tom visual "Apple-inspired"
+- `01-product-brief.md` — Block A canônico
+- `dialog/tone-of-voice.md` — 5 atributos + vocabulário canônico (Step 11)
+
+### Q: Tem brand guidelines existentes?
+**A: Sim** — brand.md + tone-of-voice.md cobrem visual e microcopy. Block B vai expandir para:
+- Personalidade (Step 14)
+- Tom refinado (Step 15)
+- Idiomas (Step 16)
+- SEO (Step 17)
+- Content structure (Step 17a)
+- Documento final (Step 18)
+
+### Output inicializado
+- `design-artifacts/A-Product-Brief/02-content-language.md`
+
+---
+
+## 2026-05-26 — Step 14 (Personality)
+
+### Metáfora canônica
+- **"Consultor sênior brasileiro de vendas B2B"** — 40-50a, ex-rep que virou consultor, conhece a rua e o ERP, sem firula
+
+### 5 atributos de personalidade
+1. **Confiável** — não erra, não some
+2. **Especialista prático** — conhece o setor, fala como amigo, não acadêmico
+3. **Decidido** — diz o que é, aponta caminho
+4. **Discreto** — não atrapalha, Apple-inspired
+5. **Aliado** — do lado do usuário, não vigiando
+
+### Conexão por persona
+- Rafael: colega mais experiente
+- Sandra: assessor de confiança
+- Daniel: consultor estratégico
+- Alice: técnico-parceiro
+
+### O que NÃO é
+- Vendedor barulhento, burocrata, coach motivacional, espião, filósofo, jovem descolado
+
+---
+
+## 2026-05-27 — Step 15 (Tone refinement)
+
+### Posicionamento nos 4 espectros (1-5)
+- **Formality: 3** (levemente formal)
+- **Mood: 2** (sério-com-leveza)
+- **Complexity: 3** (vocabulário do setor + acessível)
+- **Energy: 2** (reservado, Apple-inspired calm)
+
+### Centro de gravidade
+"Levemente formal, sério-com-leveza, tecnicamente acessível, energia contida."
+
+### We Say / Don't Say expandidos
+- 5 categorias com 3 colunas (✅ SAR / ❌ formal demais / ❌ casual demais)
+- Cobre: cumprimentos · sucesso · erro · empty states · IA/sugestão
+
+---
+
+## 2026-05-27 — Step 16 (Languages)
+
+### Estratégia canônica
+- **pt-BR only no MVP, arquitetura i18n-ready**
+- en preparado no código (chaves i18n) mas sem tradução no MVP
+- es (LatAm) fora de escopo (requer adaptação fiscal por país)
+
+### IA generativa
+- **Sempre pt-BR** — prompts em pt-BR + validação de output (rejeitar respostas em en, fallback)
+- Vocabulário canônico naturalmente vira chaves i18n estruturadas
+
+### Localização (BR-only)
+- BRL · DD/MM/AAAA · 24h · fuso `America/Sao_Paulo` por workspace · telefone `+55 (XX) XXXXX-XXXX` · CEP/CNPJ/CPF padrão BR · sistema métrico
+
+### Implicação para STACK
+- Validators Zod para CPF/CNPJ/CEP/telefone BR
+- Date-fns/Day.js com locale pt-BR
+- `Intl.NumberFormat('pt-BR', { style: 'currency', currency: 'BRL' })`
+- Fuso por workspace no master-login
+
+---
+
+## 2026-05-27 — Step 17 (SEO Strategy)
+
+### Keywords nos 6 intents
+- Service/Solução · Problem · Comparison · Brand · Informational · Long-tail setor
+
+### Domínio
+- **A definir** — recomendação: `sarjcs.com.br` (brandable + JCS-link)
+
+### URL pattern
+- pt-BR: `<dominio>/<slug>` · en futuro: `<dominio>/en/<slug>`
+- Slug: lowercase, hífen, sem especiais, ASCII
+
+### Sitemap
+- `/` · `/funcionalidades/<cockpit|whatsapp|ia|carteira>` · `/para/<setor>` · `/comparativos/<concorrente>` · `/precos` · `/recursos/<blog|calculadora|kit>` · `/cases` · `/parceiros` · `/sobre` · `/contato` · `/app/`
+
+### Structured data
+- `Organization` (todas) · `SoftwareApplication` (home) · `Product`+`Offer` (preços) · `Article`+`Review` (cases) · `Article`+`BreadcrumbList` (blog) · `FAQPage`
+
+### Local SEO
+- Reivindicar Google Business Profile da JCS Sistemas
+- NAP consistente no footer
+
+### Implicação técnica
+- Vite + plugin React Helmet para meta dinâmico
+- JSON-LD para structured data (não microdata)
+- Sitemap.xml gerado por script no build
+- robots.txt + meta noindex em `/app/`
+
+---
+
+## 2026-05-27 — Step 17a (Content Structure)
+
+### Site Marketing (10 princípios)
+- Hero em <5s · vídeo não tour · prova social pesada · 3 jornadas por persona · setor dedicado · CTA único · pricing visible · comparativos acessíveis (não em destaque) · `/recursos/` separado · cases viram peça central com 3+ clientes
+
+### Produto / 4 cockpits (11 princípios)
+- Cada cockpit tem home própria · hierarquia por urgência · navegação por device (bottom nav rep / sidebar 260px outros) · max 3 níveis · WhatsApp+IA no caminho principal · empty states informativos · notificações só pra decisão · tempo real com micro-animação · admin fora do path · auditoria em cada entidade · onboarding discreto
+
+### Exclusões explícitas (8)
+- Tutorial agressivo · gamificação gritante · chat-com-cliente in-app · marketing email · NF/SPED · wallet · CMS blog · mobile-first para Daniel/Alice
+
+### Latitude Phase 4
+- Visão alta no produto, restrições claras de tom/estilo
+
+---
+
+## 2026-05-27 — Step 18 (Create Content Document) — BLOCK B COMPLETO
+
+### Output finalizado
+- `design-artifacts/A-Product-Brief/02-content-language.md` — documento canônico de comunicação
+
+### Conteúdo adicional ao doc
+- **Content Type Guidelines:** UI microcopy · Marketing · Informational · Notificações transacionais · WhatsApp programático · IA generativa
+- **Content Ownership** (MVP solo + Y1+ contratações)
+- **Writing Checklist** (13 itens; entra em todo PR de microcopy/artigo/email)
+- **Resumo executivo** (snapshot completo)
+
+### Status do Block B
+- **CONCLUÍDO** — Steps 13, 14, 15, 16, 17, 17a, 18 (7 steps)
+- Próximo: Block C (Visual Direction) — Steps 19-26 (fast-track via brand.md)
+
+---
+
+## 2026-05-27 — Step 19 (Inspiration Workshop) — BLOCK C INICIADO
+
+### 🌟 Insight estratégico chave revelado
+> "Não acho nada que tem no mercado de identidade como inspirador — mais uma das coisas que nos trouxe para esse projeto." (Julian)
+- Mercado B2B força de vendas BR é visualmente medíocre
+- **Estética moderna é parte do diferencial fundacional do SAR**, não detalhe
+- **Adicionar como 6º unfair advantage estrutural** no Brief (refinamento ao Step 9)
+
+### 4 referências externas confirmadas
+1. **Apple iCloud** — Apple-inspired clean canon
+2. **Linear** — SaaS B2B moderno, dense + clean, atalhos, dark mode
+3. **Stripe Dashboard** — densidade + acessibilidade, dados com contexto
+4. **Notion** — flexibilidade, empty states, hierarquia tipográfica
+
+### 7 padrões destilados (entram em Design Style)
+- Sidebar fixa + área limpa · Tipografia hierarquia · Único accent · Densidade respirável · Animações sutis · Dark mode · Empty states informativos
+
+### Referência por cockpit (alimenta Phase 4)
+- Rafael: Linear mobile + Apple Notes
+- Sandra: Linear + Stripe Dashboard
+- Daniel: Stripe Dashboard + Apple iCloud
+- Alice: Notion + Linear
+
+### Output
+- `dialog/inspiration-analysis.md`
+
+---
+
+## 2026-05-27 — Step 21 (Existing Brand)
+
+### Inventário
+- Logo SAR: PNG existe (`frontend/img/`) — refresh para SVG + variantes
+- Logo JCS: 4 PNGs colocados em `design-artifacts/_references/jcs-logo/` — refresh para SVG
+- Paleta JCS: canônica (brand.md), Keep as-is
+- Plus Jakarta Sans: canônica, Keep as-is + self-host produção
+- FA 6.4 + Chart.js + tokens radius/sombra: canônicos, Keep as-is
+- Layout topbar+sidebar: Keep + adaptar Rafael (mobile bottom nav)
+
+### Análise visual da logo JCS
+- "JCS." em bold JCS Blue + seta/swoosh no "C" (movimento, precisão)
+- "sistemas" em peso light, lowercase, mesmo azul
+- Layout horizontal clean — Apple-inspired confirmado
+
+### Análise visual da logo SAR
+- Ícone JCS Blue com gráfico de barras crescente em branco (metáfora analytics)
+- "SAR" em bold sans-serif cinza/preto
+- "FORÇA DE VENDAS" em letterspaced caps cinza médio
+- Hierarquia deliberada: SAR como produto distinto, JCS como marca-mãe
+
+### Afiliações declaradas
+- ✅ "Powered by JCS Sistemas" no footer/login/sobre
+- ✅ Selos LGPD compliant + futuras certificações
+- Nenhuma franquia, nenhuma associação setorial obrigatória
+
+### Brand constraints (não negociáveis)
+- JCS Blue `#004a99` único accent
+- Plus Jakarta única família
+- SAR coexiste visualmente com JCS sempre (parental link)
+- Tom Apple-inspired clean — sem decoração desnecessária
+
+---
+
+## 2026-05-27 — Step 22 (Visual References)
+
+### 9 categorias destiladas das 4 referências positivas
+- Layout · Cor · Tipografia · Densidade · Imagery · Efeitos · Estados · Dark mode · Mobile
+
+### 7 estilos a evitar (referências negativas)
+- Burocrata corporativo legado · apps verticais BR (Mercos/Promosoft) · SaaS "fofo" · Material Design pesado · BI 2010-2015 · sites BR "exuberantes" · tour interativo agressivo
+
+### 5 mood keywords canônicos
+- **Clean · Confident · Specific · Serene · Modern**
+
+### Frase âncora
+"clean, confident, specific, serene, modern — como um consultor sênior que apareceu na sua empresa e abriu o notebook"
+
+---
+
+## 2026-05-27 — Step 23 (Design Style)
+
+### 4 decisões canônicas
+1. **UI Visual Style:** Modern Flat + Minimal (Apple/Linear/Stripe/Notion family) — sem skeumorfismo, sem 3D, radius 12/20px, sombra sutil
+2. **Design Aesthetic:** Minimalism contemporâneo / Digital-native modern — post-Apple, sem ilustrações ornamentais
+3. **Color Direction:** Monochromatic + functional accents — JCS Blue protagonista, cool, light + dark mode, distribuição 60/30/10
+4. **Typography Direction:** Plus Jakarta Sans Geometric Humanist — tabular numerals em dashboards, hierarquia preliminar h1 32-40 / body 14-16 / caption 12-13
+
+---
+
+## 2026-05-27 — Step 24 (Layout & Effects)
+
+### Site Marketing
+- **Hero: Split** (texto + vídeo play-on-click)
+- Layouts variados por tipo de página (single column / card grid / side-by-side / 3-column tier)
+- Top nav sticky · hamburger mobile-only · mega menu em Funcionalidades/Para · CTA demo sempre visível
+
+### Produto — pattern por cockpit
+- **Rafael:** single column + cards verticais + bottom nav
+- **Sandra:** sidebar + grid de cards + tabelas (Linear-like dense+decisão)
+- **Daniel:** sidebar + **bento box** dashboard (Stripe-like KPIs)
+- **Alice:** sidebar + **table-first** + forms drawer lateral
+
+### Visual Effects (nível canônico)
+- Shadows: sutil (brand.md)
+- Animations: sutis funcionais 150-250ms ease-out
+- Parallax: **none** (gimmick em B2B)
+- Hover: sutil (background/opacity, sem transform 3D)
+- Loading: skeleton (não spinner)
+- Real-time: micro-animação 200ms, sem toast intrusivo
+- Focus rings WCAG AA + reduced motion respeitado
+
+### Performance targets
+- Lighthouse mobile > 90 · TTI Rafael 3G < 3s · FCP < 1.5s
+- Bundle inicial < 200KB gzipped por entry
+- Code-split por cockpit · WebP/AVIF + lazy + sharp · Service Worker para Rafael offline · vídeo hero sem autoplay
+
+---
+
+## 2026-05-27 — Step 25 (Imagery)
+
+### Estratégia canônica: **Apple-style produto-primário**
+- MVP usa **screenshots do produto + ilustrações minimíssimas**
+- **Sem stock humano** — sai do mainstream B2B saturado
+- Fotos reais entram pós-MVP quando houver cases/permissões
+
+### Photography style (quando aplicar)
+- Authentic/Documentary — pós-MVP em cases
+- **Product-focused — MVP** (screenshots reais)
+- Lifestyle moderado pós-MVP (sem "team smiling")
+- Polished/staged **NUNCA**
+
+### Anti-padrões absolutos
+- Executive shaking hands · diverse team smiling · UI hologram · gráficos 3D flutuando · senhor preocupado com planilha · cidade + barra sobreposta
+
+### Icons
+- FA 6.4 subset · **Regular/Outline padrão**, Solid só em estados · sistema 16/20/24px · cor inherit + JCS Blue em ações primárias · ícone SAR como signature visual
+
+### Illustrations
+- **Quase nenhuma no MVP** — Apple-clean prefere ausência
+- Permitido: empty states (line art mono JCS Blue) e erro 404/500
+- EVITAR: isométrico hipster · gradiente saturado · diversity blob people
+
+### Image guidelines
+- 16:9 / 4:3 / 1:1 ratios · alt obrigatório WCAG AA · WebP/AVIF + JPG fallback q80-85 · lazy load · srcset 1x/2x/3x · Cloudflare CDN · sharp pipeline
+
+---
+
+## 2026-05-27 — Step 26 (Create Visual Document) — BLOCK C COMPLETO
+
+### Visual DNA Summary
+```
+Style:       Modern Flat + Minimal (Apple/Linear/Stripe/Notion family)
+Aesthetic:   Minimalism contemporâneo / Digital-native modern
+Colors:      Monochromatic JCS Blue + functional accents · cool · light + dark mode · 60/30/10
+Typography:  Plus Jakarta Sans Geometric Humanist · tabular numerals
+Mood:        Clean · Confident · Specific · Serene · Modern
+Layout:      Split hero (site) · cards/grid/bento/table por cockpit
+Effects:     Sutis funcionais 150-250ms · sombra única brand.md · sem parallax
+Imagery:     Screenshots-only Apple-style · sem stock humano · FA outline
+Key element: 4 cockpits sobre dado único em tempo real (ícone do gráfico crescente da logo SAR como símbolo)
+```
+
+### Status do Block C
+- **CONCLUÍDO** — Steps 19, 20, 21, 22, 23, 24, 25, 26 (8 steps)
+- Documento canônico: `design-artifacts/A-Product-Brief/03-visual-direction.md`
+- Próximo: Block D (Platform Requirements) — fast-track via STACK.md (Steps 27-32)
+
+---
+
+## 2026-05-27 — Block D (Platform Requirements) — CONCLUÍDO ✅
+
+### Steps 27-32 batched
+- Step 27 (Init) · Step 28 (Tech Stack — espelho STACK.md v2.2) · Step 29 (Integrations) · Step 30 (Contact Strategy) · Step 31 (Multilingual & SEO) · Step 32 (Final synthesis)
+- Documento canônico: `design-artifacts/A-Product-Brief/04-platform-requirements.md`
+
+### Decisões fechadas no Step 29
+- **Pagamento:** Iugu (boleto/PIX/cartão + assinaturas recorrentes BR)
+- **WhatsApp:** Oficial Meta (WhatsApp Cloud API)
+- **Analytics produto:** PostHog self-host em Proxmox
+- **Email, Storage, Secrets, CDN, Obs:** já cobertos por STACK.md (Resend, MinIO, Vault, Cloudflare, Grafana+Sentry)
+
+### Decisão ABERTA — IA generativa
+- Julian quer estudar todas as opções (Anthropic / OpenAI / Local Ollama / Multi-provider)
+- **Resolução estratégica:** abstração multi-provider via Vercel AI SDK ou LiteLLM desde dia 1 — código fica provider-agnostic
+- **Default temporário:** Anthropic Claude (Sonnet/Opus) por explicabilidade e força em pt-BR, escondido atrás de interface JCS
+- Decisão definitiva: quando 1º cliente fechar e Julian tiver tempo para benchmark
+
+### Contact Strategy
+- **Form de demo** como CTA único (sem chat ao vivo no MVP)
+- 8 campos obrigatórios + 2 opcionais (qualifica origem + porte + ERP)
+- Anti-spam: hCaptcha/Turnstile (não Google reCAPTCHA — LGPD)
+- Rate limit 5/h email + 10/h IP
+- SDR JCS (Julian no início) responde em até 4h úteis
+
+### Multilingual & SEO técnico
+- pt-BR only MVP, i18n-ready
+- Domínio recomendado: `sarjcs.com.br`
+- JSON-LD structured data plan completo
+- noindex em `/app/` (produto privado)
+- Lighthouse > 90 mobile como CI gate
+
+### Maintenance
+- Solo founder mode até 1º cliente; depois +1-2 devs JCS
+- Documentação extensiva (CODING-RULES.md) como mitigação de bus factor
--- a/design-artifacts/A-Product-Brief/dialog/inspiration-analysis.md
+++ b/design-artifacts/A-Product-Brief/dialog/inspiration-analysis.md
@@ -0,0 +1,101 @@
+# Inspiration Analysis — SAR
+
+**Confirmed:** 2026-05-27
+**Step:** 19 — Inspiration Workshop
+
+> **Insight estratégico chave:** O mercado B2B de força de vendas brasileiro é visualmente medíocre (Mercos, Promosoft, TOTVS, etc. todos com UI antiga/burocrata). Julian declarou: "não acho nada que tem no mercado de identidade como inspirador — mais uma das coisas que nos trouxe para esse projeto". **A estética moderna é parte do diferencial do SAR**, não apenas detalhe — é motivo de origem do produto.
+
+---
+
+## Referência primária — Brand.md (já estabelecido)
+
+Tom Apple-inspired: clean, minimalista, espaço em branco generoso, hierarquia clara, sem ruído visual.
+
+---
+
+## 4 referências externas (fora do setor B2B força de vendas BR)
+
+### 1. Apple iCloud / Apple Settings
+
+**Por quê:** Já é a referência declarada no `brand.md`. Personifica "Apple-inspired clean".
+
+**O que destilar:**
+- Sidebar fixa com hierarquia clara
+- White space generoso, sem zebra
+- Tipografia decisiva (SF Pro, peso variável)
+- Sem ruído visual; ações importantes em destaque
+- Cinza neutro como base, azul Apple como único accent
+
+### 2. Linear (linear.app)
+
+**Por quê:** SaaS B2B moderno, dense info + clean — diretamente aplicável aos cockpits Sandra/Alice.
+
+**O que destilar:**
+- Densidade de informação **sem cansar** — tabelas/listas com peso visual baixo
+- Atalhos de teclado-first (boa pista para Sandra e Alice em bulk operations)
+- Animações sutis (funcionais, não enfeite)
+- Dark mode elegante (Rafael à noite)
+- Vocabulário consistente (status, prioridade, owner)
+
+### 3. Stripe Dashboard
+
+**Por quê:** Densidade + acessibilidade visual — referência crítica para o cockpit Daniel (BI + IA).
+
+**O que destilar:**
+- Dados importantes em destaque, secundários comprimidos
+- Métricas com contexto (não só número — comparação + tendência)
+- Tabelas de transação com hierarquia visual clara
+- Estados de erro/alerta integrados ao fluxo (não modal popup)
+- Search/command bar central (futuro acelerador)
+
+### 4. Notion (notion.so)
+
+**Por quê:** Flexibilidade + tom + empty states — referência para o produto se sentir poderoso sem parecer complexo.
+
+**O que destilar:**
+- Empty states informativos e generosos
+- Hierarquia tipográfica que guia o olho
+- Densidade adaptável (cards × lista × tabela)
+- Tom de voz nas micro-interações (próximo do que SAR quer)
+- Apesar de poderoso, parece simples
+
+---
+
+## 7 padrões destilados (entram em Design Style — Step 23)
+
+| Padrão | De onde | Aplicação no SAR |
+|---|---|---|
+| **Sidebar fixa + área de conteúdo limpa** | Apple, Linear, Notion | Cockpits Sandra/Daniel/Alice (alinha com brand.md topbar 80px + sidebar 260px) |
+| **Tipografia faz hierarquia, não cores fortes** | Apple, Stripe | Plus Jakarta com pesos variando (400/500/600/700/800), já no brand.md |
+| **Único accent color** | Apple, Linear | JCS Blue `#004a99` como único destaque cromático (já no brand.md) |
+| **Densidade + ar respirável** | Linear, Stripe | Sandra precisa de densidade, mas com white space que não cansa |
+| **Animações sutis funcionais** | Linear, Stripe | Real-time entre cockpits com micro-animação suave (não toast intrusivo) |
+| **Dark mode elegante** | Linear, Vercel | Desejável especialmente para Rafael à noite (carro/posto) |
+| **Empty states informativos** | Notion | Já estabelecido em Steps 11/15 ("Sem propostas. Cadastre a primeira...") |
+
+---
+
+## Implicações estratégicas
+
+### Insight de positioning (entra no Brief, refina Step 9)
+
+**Adicionar como 6º unfair advantage estrutural:**
+
+> **Estética moderna em mercado visualmente medíocre.** Concorrentes (Mercos, Promosoft, módulo TOTVS) têm UI legada de PHP/Java/Delphi — visualmente datada. O SAR tem possibilidade de **diferenciar via design** num mercado onde quase ninguém prioriza isso. Apple-inspired clean + Linear-density + Stripe-data-clarity + Notion-flexibility = produto que parece de outra categoria.
+
+**Cuidado:** estética isolada é copiável em 2-3 anos. O moat real é a **combinação** estética + multi-tenant físico + concept "4 cockpits" + velocidade JCS. Mas como porta de entrada, vai brilhar muito na demo.
+
+### Implicação para Phase 4 (UX Specs)
+
+- Cada cockpit ganha referência primária de inspiração:
+  - **Rafael (Rep mobile):** Linear mobile + Apple Notes (foco em ação rápida + offline)
+  - **Sandra (Supervisora):** Linear + Stripe Dashboard (densidade + decisão)
+  - **Daniel (Dono):** Stripe Dashboard (métricas + insight) + Apple iCloud (calma executiva)
+  - **Alice (Admin):** Notion (flexibilidade) + Linear (atalhos)
+
+### Implicação para Phase 6 (Design System)
+
+- Tokens compartilhados, **mas variantes por cockpit** com inspiração distinta:
+  - Mesma paleta JCS
+  - Mesma tipografia Plus Jakarta
+  - Mas densidades, tamanhos de elementos, espaçamentos variam por persona
--- a/design-artifacts/A-Product-Brief/dialog/platform-strategy.md
+++ b/design-artifacts/A-Product-Brief/dialog/platform-strategy.md
@@ -0,0 +1,169 @@
+# Platform Strategy — SAR (Força de Vendas)
+
+**Confirmed:** 2026-05-26
+**Step:** 10a — Platform Strategy
+
+> Estratégia de plataforma decorre da STACK.md + Product Concept + Constraints. Esta sessão consolida e abre as decisões de **device strategy** que afetam o MVP.
+
+---
+
+## Plataforma primária — Web SaaS (decisão fixa via STACK.md)
+
+| Camada | Decisão |
+|---|---|
+| **Tipo** | Web SaaS multi-tenant |
+| **Frontend** | React 19.2 SPA via Vite 8 (Rolldown) |
+| **Distribuição** | Sem app store; deploy = rolling docker-compose em VMs Proxmox |
+| **CDN/edge** | Cloudflare + Nginx para SPA estática |
+| **Identidade** | master-login (IdP próprio) OAuth2/OIDC |
+| **Multi-tenancy** | BD-por-workspace; workspace resolvido por host/path |
+
+---
+
+## Device strategy por cockpit
+
+### 🟢 Rafael (Rep) — **PWA mobile-first**
+
+| Aspecto | Decisão |
+|---|---|
+| **Tecnologia** | **Progressive Web App (PWA)** — SPA com Service Worker + Manifest + Web Push |
+| **Device-target primário** | **iOS** (gap no mercado; vocês não têm app native iOS) |
+| **Device-target secundário** | Android (usuários que preferem PWA ao app legado) |
+| **Instalação** | "Adicionar à Tela de Início" no iOS Safari / Android Chrome |
+| **Push** | Web Push API via Service Worker (notificações de pedido aprovado, alertas) |
+| **Offline** | **Read + Write com sync** (lançamento de pedido offline + reconciliação quando volta sinal) |
+| **Native features** | Geolocation (check-in) · Web Push · Share API (compartilhar pedido) |
+| **Dark mode** | Desejável (uso noturno em carro/posto) |
+
+### 🟡 Sandra (Supervisora) — Web desktop + mobile-light
+
+| Aspecto | Decisão |
+|---|---|
+| **Device-target primário** | Desktop (notebook escritório) |
+| **Device-target secundário** | Mobile (PWA — consultas rápidas, aprovações via push) |
+| **Push** | Web Push para notificar aprovações pendentes |
+| **Layout** | Topbar 80px + Sidebar 260px (brand.md) com tabelas/listas densas |
+
+### 🔵 Daniel (Dono) — Desktop + **iPad first-class**
+
+| Aspecto | Decisão |
+|---|---|
+| **Device-target primário** | Desktop/notebook |
+| **Device-target secundário** | **iPad first-class** — testes e ajustes dedicados |
+| **Layout** | Visualização-first (gráficos amplos), tom executivo |
+| **Modo** | Claro/escuro elegante (uso noturno em casa) |
+
+### 🟣 Alice (Admin) — Desktop-only
+
+| Aspecto | Decisão |
+|---|---|
+| **Device-target** | Desktop apenas (sem investimento mobile/tablet) |
+| **Layout** | Dense forms com assistentes, bulk operations, auditoria visível |
+
+---
+
+## Coexistência com app Android legado
+
+### Decisão estratégica
+
+- **MVP:** SAR PWA + backend SAR construídos do zero. **App Android legado continua intocado** no curto prazo.
+- **Pós-MVP (Y1+):** Iniciar **adaptação do app Android legado para consumir backend SAR**, unificando a fonte da verdade.
+- **Futuro (Y1-Y2):** Avaliar reescrita do app Android para mobile-native sobre backend SAR (possivelmente Capacitor wrap do PWA ou React Native).
+
+### Modelo evolutivo
+
+```
+                  HOJE                       MVP                       Pós-MVP                     Futuro
+                  ────                       ───                       ───────                     ──────
+Backend           [App Android legado]       [App Android legado]      [App Android adapt.]        [Native iOS]
+                       │                          │   [SAR backend]              ▲                 [Native Android]
+                       │                          │        │                     │                       │
+                  [Backend                   [Backend         ↓                  ▼                       ▼
+                   legado]                    legado]    [SAR PWA iOS]      [SAR backend]           [SAR backend]
+                                                                              (único)               (único)
+```
+
+### Implicação técnica
+
+- **MVP:** SAR é greenfield, sem dependência do Android legado. Reps Android continuam no app legado se já o usam; clientes novos vão direto para SAR PWA.
+- **Pós-MVP:** App Android passa a consumir API SAR — necessária camada de compatibilidade temporária (provavelmente adapter no backend para mapear contratos antigos do app).
+
+---
+
+## Offline strategy detalhada (Rafael)
+
+### Nível escolhido: **Read + Write com sync**
+
+| Operação | Online | Offline |
+|---|---|---|
+| Visualizar catálogo | API + cache | Cache local (IndexedDB) |
+| Visualizar clientes | API + cache | Cache local (clientes da carteira do rep) |
+| Visualizar últimos pedidos | API + cache | Cache local (últimos N) |
+| **Lançar pedido** | API + ack imediato | **IndexedDB queue + Service Worker sync** |
+| Editar pedido em rascunho | API + cache | IndexedDB |
+| Aprovação de desconto (Sandra) | Real-time | (Não aplicável — Sandra é desktop) |
+
+### Implementação (a detalhar em Phase 3 / 4)
+
+- **Storage local:** IndexedDB para cache + queue de pendentes
+- **Sync layer:** Service Worker reage a `online` event; envia queue serialmente
+- **Conflict resolution:** Last-write-wins para rascunho; pedido finalizado é imutável depois de submeter
+- **UI signaling:** ícone de "modo offline" claro; toast quando sync completa; mostrar status do pedido (`enviando…` → `enviado`)
+- **Limites:** offline funciona por até X dias (configurável); depois força login + sync
+
+### Risco a mitigar
+
+- **Pedido duplicado:** rep lança offline, depois online sem perceber sync, lança de novo. Solução: `Idempotency-Key` por pedido (UUID gerado local) — já é padrão STACK.md §05.
+- **Catálogo desatualizado:** rep lança pedido com preço/produto que mudou. Solução: validação no sync com `If-Match` ou status `requer_revisao` se preço divergiu.
+
+---
+
+## Native features do MVP
+
+| Feature | Cockpit | Web API | Status MVP |
+|---|---|---|---|
+| **Geolocation** (check-in agenda) | Rafael | `navigator.geolocation` + permissão | ✅ MVP |
+| **Web Push** (aprovação para Sandra; pedido aprovado para Rafael) | Sandra, Rafael | Push API + Service Worker | ✅ MVP (parte do PWA) |
+| **Share API** (Rafael compartilha pedido/orçamento via WhatsApp do celular) | Rafael | `navigator.share` | ✅ MVP |
+| **Notification API** (desktop) | Sandra | `Notification` | ✅ MVP |
+| **Camera** (foto documento/produto) | Rafael, Alice | `<input type="file" capture>` | 🟡 Pós-MVP |
+| **File System Access** (Alice import CSV) | Alice | File System API + fallback | 🟡 Pós-MVP |
+
+### Diferença: Share API vs WhatsApp integrado nativo do SAR
+
+- **Share API** (MVP): Rafael toca "Compartilhar pedido" → abre menu nativo do iOS/Android → cliente recebe link/PDF via WhatsApp do celular DELE
+- **WhatsApp nativo do SAR** (parcial no MVP): backend envia mensagem programática via WhatsApp Business API quando pedido é aprovado (notificação ao cliente final). Implementação Step 29.
+
+Os dois coexistem. Share API é "rep compartilha como pessoa", WhatsApp nativo é "produto envia em nome do cliente-empresa".
+
+---
+
+## Interaction models
+
+| Modelo | Cockpits | Notas |
+|---|---|---|
+| **Touch** | Rafael (primário), Sandra/Daniel/Alice (secundário) | Botões 44×44pt mínimo no Rafael |
+| **Mouse + teclado** | Sandra, Daniel, Alice | Atalhos de teclado avaliados em Phase 4 (especialmente Alice bulk ops) |
+| **Voice commands** | Nenhum no MVP | Possível futuro: Rafael ditando pedido enquanto dirige (risco de segurança rodoviária — descartado por enquanto) |
+| **Gesture** | Rafael (swipe entre clientes, pull-to-refresh) | Padrão mobile |
+| **Acessibilidade** | Todos | WCAG AA mínimo; screen reader compatível desde MVP |
+
+---
+
+## Implicações de design e desenvolvimento
+
+1. **PWA exige Service Worker robusto** — não é "responsivo com manifest", é arquitetura cliente complexa. Investimento explícito de ~1-2 semanas no MVP.
+2. **Web Push exige certificado VAPID + backend para envio** — encaixa com BullMQ jobs já previstos.
+3. **Offline write exige UI com estados claros** — `enviando…` `enviado` `falha de sync` `aguardando reconexão` (estados visíveis ao Rafael).
+4. **iPad first-class implica testes regulares em iPad Safari** durante Phase 4 — adicionar ao matriz de QA.
+5. **Compatibilidade com Android legado é débito conhecido**, não esquecido — pós-MVP terá adapter layer ou contratos compartilhados.
+
+---
+
+## Lacunas conscientemente adiadas
+
+- Native iOS / native Android (Capacitor / React Native) — pós-Y1
+- Voice commands para Rafael — descartado por segurança rodoviária
+- Acessibilidade avançada (WCAG AAA, switch controls) — manter WCAG AA no MVP
+- Camera e File System Access — pós-MVP
+- App Smartwatch para alertas Sandra — fora de escopo
--- a/design-artifacts/A-Product-Brief/dialog/positioning.md
+++ b/design-artifacts/A-Product-Brief/dialog/positioning.md
@@ -0,0 +1,105 @@
+# Positioning — SAR (Força de Vendas)
+
+**Confirmed:** 2026-05-26
+**Step:** 03 — Positioning
+**Synthesized by:** Saga (BA)
+
+---
+
+## Positioning Statement (framework Geoffrey Moore)
+
+> **Para** distribuidoras, indústrias e escritórios de representação brasileiros com **5-50 representantes externos**,
+>
+> **que precisam** de visibilidade em tempo real do que está acontecendo na rua para decidir com dados em vez de no escuro,
+>
+> **o SAR é** uma plataforma SaaS de força de vendas que entrega **três experiências distintas no mesmo produto** — clareza operacional para o rep, instrumentos de decisão para o supervisor, IA estratégica para o dono — com WhatsApp como canal nativo e inteligência ativa de carteira.
+>
+> **Diferente de** apps verticais como Mercos e Promosoft (que tratam todos os usuários igual e não têm IA estratégica), módulos de força de vendas de ERPs como TOTVS e Sankhya (burocráticos, caros e desconectados do mobile), e do stack improvisado de planilha+WhatsApp+ERP (que não dá visibilidade nenhuma),
+>
+> **o SAR** é instalado em minutos como SaaS web, com camadas IA-first sobre cada papel — e coexiste com ERPs existentes em vez de exigir migração total.
+
+---
+
+## Componentes do positioning
+
+### Target Customer (primário)
+
+Empresas brasileiras B2B com força de vendas externa, dos seguintes perfis (todos válidos):
+
+- **Distribuidoras / atacadistas** com equipe de representantes externos (perfil clássico)
+- **Indústrias** que vendem via representantes externos (fabricantes com canal próprio: food service, bebidas, química, materiais de construção)
+- **RCAs** — escritórios de representação que vendem para várias indústrias (multi-empresa nativo)
+- **PMEs com vendas externas** (imobiliárias, distribuição de serviços, etc. — extensão além do nicho clássico)
+
+**Porte sweet spot:** **5-50 representantes na rua** — tem dor real de gestão, mas não tem TI interno suficiente para construir sob medida. SaaS chave-na-mão resolve.
+
+### Need / Opportunity
+
+**Donos e supervisores decidem no escuro.** Não sabem em tempo real:
+- Quem visitou quem hoje
+- Pedidos em aberto e status
+- Clientes esfriando / inativos
+- Metas atingidas e gap
+- Onde a equipe precisa de empurrão
+
+Resultado: gestão reativa, perda de clientes silenciosa, esforço comercial desalinhado.
+
+### Category
+
+**Plataforma SaaS de Força de Vendas (SFA — Sales Force Automation)** com integração nativa de WhatsApp e camadas IA por papel.
+
+### Key Benefit
+
+Clareza em tempo real em **três camadas distintas** numa única plataforma:
+- **Rep:** clareza operacional (o que vender, pra quem, quanto, status)
+- **Supervisor:** instrumentos de decisão tática diária
+- **Dono:** análise estratégica com IA proativa
+
+Atravessado por: WhatsApp nativo + inteligência ativa de carteira + facilidade de implantação SaaS.
+
+### Alternatives (concorrência real)
+
+1. **Apps verticais de força de vendas** — Mercos, Promosoft, MaxFV, Workforce, Mobits
+2. **Módulos de força de vendas de ERPs nacionais** — TOTVS, Sankhya, Senior
+3. **Stack improvisado** — planilha Excel + WhatsApp manual + ERP sem módulo
+4. **Apps caseiros** — sistemas próprios feitos por dev terceirizado
+
+### Differentiators (7 itens — herdados de Vision + Step 3)
+
+1. **Inteligência de carteira ativa** — inativos, ciclo de vendas, oportunidades (proativo, não relatório passivo)
+2. **WhatsApp como canal nativo** — não anexo, não webhook externo
+3. **Metas como gamificação operacional** — expostas, atingíveis, na cara do rep
+4. **3 experiências distintas por papel** — não "uma tela igual pra todos"
+5. **IA estratégica para o dono** — não decorativa, foco em insight de gestão
+6. **SaaS web distribuível** — instalação em minutos vs. apps Android/Desktop empacotados
+7. **Facilidade de implantação** — JCS-side: entregar sistema web ao cliente sem fricção (declarado pelo PO)
+
+---
+
+## Estratégia de aquisição por origem do cliente
+
+| Origem | Mensagem-chave | Atrito principal | Vantagem técnica do SAR |
+|---|---|---|---|
+| **App vertical concorrente** (Mercos, Promosoft etc.) | "Ganha IA + 3 experiências por papel + WhatsApp nativo, sem perder o que já tinha" | Migração de dados, mudança de hábito | Importação de catálogo/clientes; UX moderna |
+| **Módulo de ERP** (TOTVS, Sankhya, Senior) | "Mantenha o ERP, troque só a força de vendas — integramos via API" | Convencer que pode "tirar uma peça" do ERP | Multi-tenant BD-por-workspace (ADR 0006) facilita integração heterogênea por cliente |
+| **Stack improvisado** (Excel + WhatsApp + ERP sem módulo) | "Primeira ferramenta de verdade — sai do escuro" | Educação de mercado, mudança comportamental | Onboarding rápido, UX que não exige treinamento longo |
+| **App caseiro** (dev terceirizado) | "Acabou com o pesadelo de manutenção — SaaS pronto + roadmap contínuo" | Custo afundado emocional do app antigo | Roadmap JCS contínuo, sem dependência de dev único |
+
+---
+
+## Implicações estratégicas
+
+1. **Coexistência com ERPs é estratégia, não fallback.** Multi-tenancy BD-por-workspace é arquitetonicamente desenhada para integrar com ERPs distintos por cliente — vira diferencial competitivo vs. apps verticais que forçam migração total.
+2. **WhatsApp nativo e IA não são "futuro" — são MVP.** Estão no positioning statement, então não podem aparecer como Phase 2/3 de roadmap; precisam estar no produto desde o lançamento (ou pelo menos em beta declarado).
+3. **3 experiências distintas** virou pilar de marca, não detalhe. Influencia: design system, navegação, RBAC, telas iniciais por papel, e até pricing (talvez tier por papel?).
+4. **"Visibilidade em tempo real" é a promessa-mãe.** Implica websockets/SSE no produto (já previsto em STACK.md §13), e UX que mostra dados frescos (não relatórios datados de ontem).
+5. **Porte 5-50 reps define o pricing range.** Não pode mirar enterprise (compete com Salesforce), nem micro (não paga SaaS). Mid-SMB sweet spot.
+
+---
+
+## Origem (citações e escolhas do PO)
+
+- Targets selecionados (todos os 4 perfis válidos)
+- Porte: 5-50 reps confirmado como sweet spot
+- Concorrência identificada nas 4 categorias
+- Dor central: **falta de visibilidade em tempo real**
--- a/design-artifacts/A-Product-Brief/dialog/product-concept.md
+++ b/design-artifacts/A-Product-Brief/dialog/product-concept.md
@@ -0,0 +1,160 @@
+# Product Concept — SAR (Força de Vendas)
+
+**Confirmed:** 2026-05-26
+**Step:** 07a — Product Concept
+
+> **Concept** ≠ feature list. É o **princípio organizador estrutural** que define como o produto funciona — não o que ele faz.
+
+---
+
+## A ideia em uma frase
+
+> **SAR é uma plataforma de 4 cockpits especializados (Rep / Supervisor / Dono / Admin) compartilhando um dado único em tempo real, atravessado por WhatsApp nativo e IA contextual.**
+
+---
+
+## Mental model (metáfora canônica)
+
+> Como uma equipe de Fórmula 1: cada papel (piloto, engenheiro, estrategista, mecânico) tem **seu próprio dashboard, suas próprias decisões e seu próprio ritmo** — mas todos veem o mesmo carro em tempo real, com a mesma telemetria. WhatsApp e IA são o rádio que conecta todos.
+
+---
+
+## Por que ESTA estrutura (não outra)
+
+| Alternativa considerada | Por que rejeitada |
+|---|---|
+| "Um produto único, RBAC esconde o que cada um não usa" | Modelo Mercos/Promosoft. Tela do rep cheia de coisa irrelevante e vice-versa. Não diferencia. |
+| "4 produtos separados (4 logins, 4 contas)" | Quebra o tempo real. Quando rep lança pedido, supervisor não vê na hora. Fragmenta a marca. |
+| "Web genérico responsivo igual pra todos" | Rafael precisa mobile-first (carro/posto/3G ruim). Daniel precisa desktop/iPad. Forçar igualdade penaliza ambos. |
+| **"4 cockpits especializados sobre dado único em tempo real"** ✅ | **Cada papel ganha o produto ideal para ele, sem fragmentar dado nem perder consistência.** |
+
+---
+
+## Princípios de implementação
+
+### 1. Cada cockpit tem sua própria UX, navegação e device-target
+
+| Cockpit | Device-target | Padrão UX |
+|---|---|---|
+| **Rafael (Rep)** | **Mobile-first** | Touch-friendly, offline-resiliente, latência percebida baixa, dark mode |
+| **Sandra (Supervisora)** | Desktop-dense + mobile-light | Dense information, ações 1-clique, push notifications |
+| **Daniel (Dono)** | Desktop/iPad | Visualização > tabela, tom executivo, claro/escuro elegante |
+| **Alice (Admin)** | Desktop-only | Dense forms com assistentes, bulk operations, auditoria visível |
+
+### 2. Camada de dados única em tempo real
+
+- **Socket.IO** + **SSE** (já previsto em STACK.md §13)
+- Mudança no Cockpit X aparece em Cockpit Y em <2 segundos
+- Sem batch noturno, sem refresh manual, sem polling
+
+### 3. WhatsApp e IA atravessam os 4 cockpits
+
+- Não são módulos isolados — são **fios condutores horizontais**
+- WhatsApp: mensagem do cliente vira notificação no Rep, alerta no Supervisor, log no Dono, configuração na Admin
+- IA: gera alertas para Supervisor (operacional), recomendações para Dono (estratégico), sugestões para Admin (campanhas)
+
+### 4. Multi-tenancy BD-por-workspace (ADR 0006)
+
+- Cada empresa-cliente tem **cluster Postgres dedicado**
+- Cockpits compartilham fonte de verdade **dentro de um workspace**
+- Isolamento físico entre clientes (LGPD, segurança)
+- Onboarding/trial: workspace sandbox provisionado automaticamente
+
+---
+
+## Exemplo concreto (fluxo que materializa o concept)
+
+**Cenário:** Rafael lança um pedido com 15% de desconto (acima da alçada dele de 10%).
+
+```
+  [Cockpit Rafael — mobile, 14:32]
+     │
+     │ 1. Lança pedido R$ 12.000 c/ 15% desconto
+     │    → toca "Enviar"
+     │
+     ▼
+  Backend: cria pedido status="aguardando_aprovacao"
+     │ broadcast WebSocket → workspace
+     │
+     ├─→  [Cockpit Sandra — desktop, 14:32]
+     │       Fila de aprovações: +1 (animação suave)
+     │       Push notification no celular dela
+     │
+     ├─→  [WhatsApp do cliente — 14:32]
+     │       "Olá! Seu pedido #1234 está em análise.
+     │        Acompanhe: link..."
+     │
+     │
+  [Sandra aprova com 1 clique, 14:34]
+     │ broadcast WebSocket
+     │
+     ├─→  [Cockpit Rafael — mobile, 14:34]
+     │       Pedido muda de "aguardando" → "aprovado"
+     │       Toast: "✅ Sandra aprovou seu desconto"
+     │
+     ├─→  [WhatsApp do cliente — 14:34]
+     │       "Pedido #1234 confirmado!"
+     │
+     │
+  [Cockpit Daniel — desktop, 22:30 mesmo dia]
+       IA: "Hoje você aprovou 3 descontos acima de 10%,
+            todos para o cliente OPENFRIOS.
+            Considere reavaliar a tabela base para eles."
+```
+
+Esse fluxo único toca: **4 cockpits + tempo real + WhatsApp nativo + IA proativa**. É o produto-concept em ação — não é demo, é o dia-a-dia.
+
+---
+
+## Features que DECORREM (não definem) do concept
+
+| Cockpit | Features pilares |
+|---|---|
+| **Rep** | Lançamento de pedido em <60s · Visão 360° cliente · Comissão tempo real · Funil pessoal · WhatsApp integrado · Agenda + GPS check-in |
+| **Supervisor** | Fila de aprovações com contexto · Mapa de calor da equipe · Alertas proativos · Comparativo entre reps · Dashboard "apertar parafusos" |
+| **Dono** | Faturamento vs meta · Top/bottom clientes e produtos · IA estratégica explicável · Análise de carteira/concentração de risco |
+| **Admin** | Cadastros (produto/cliente/rep) · Pautas versionadas · Editor de campanhas no-code · Assistente ICMS-ST · Auditoria · Bulk operations |
+| **Atravessando** | WhatsApp Business API nativo · IA contextual · Multi-tenancy BD-por-workspace · Real-time Socket.IO/SSE · Mobile+Desktop paradigmas distintos |
+
+---
+
+## Tensões deliberadas (decisões que custam, mas valem)
+
+1. **Construir 4 UX paradigmas em vez de 1 responsivo**
+   - **Custo:** mais código, mais design, mais teste, mais complexidade
+   - **Ganho:** cada persona ganha experiência adequada; diferencial vs concorrentes
+   - **Mitigação:** Design System compartilhado (Phase 6) garante tokens/componentes consistentes mesmo com paradigmas distintos
+2. **Tempo real over batch**
+   - **Custo:** infraestrutura Socket.IO + SSE + Valkey adapter; complexidade de estado client-side
+   - **Ganho:** promessa-mãe "visibilidade em tempo real" cumprida; demos brilham
+   - **Mitigação:** STACK.md §13 já previu; multi-tenancy BD-por-workspace facilita escopo de broadcast (por workspace, não global)
+3. **WhatsApp e IA como pilares horizontais, não módulos**
+   - **Custo:** acoplamento entre cockpits via filas e eventos; precisa pensar arquitetura desde o MVP
+   - **Ganho:** diferenciais declarados não são afterthought; entram no produto coerentemente
+   - **Mitigação:** event-driven via BullMQ (já no STACK.md §11); contrato de evento padronizado
+
+---
+
+## Implicações para Phase 2 / 3 / 4
+
+- **Phase 2 (Trigger Map):** as 4 personas já são os Target Groups. Trigger Map vai aprofundar driving forces × feature impact por cockpit.
+- **Phase 3 (PRD):** cada cockpit pode virar um epic. Atravessadores (WhatsApp, IA, real-time, multi-tenancy) viram epics horizontais.
+- **Phase 4 (UX Specs):** cada cockpit gera scenarios separados. Páginas dentro de cada cockpit seguem o paradigma de device-target dele.
+- **Phase 6 (Design System):** tokens compartilhados, mas **variantes por cockpit** (mobile vs desktop dense vs visualização-first vs forms-first). Phase 6 não é opcional para o SAR.
+
+---
+
+## Relação com o concept e o positioning (sanity check)
+
+O concept reforça o positioning:
+
+| Positioning claim | Como o concept entrega |
+|---|---|
+| "3 (4) experiências distintas no mesmo produto" | Princípio estrutural #1: 4 cockpits especializados |
+| "Visibilidade em tempo real" | Princípio #2: dado único em tempo real entre cockpits |
+| "WhatsApp como canal nativo" | Princípio #3: WhatsApp como fio condutor horizontal |
+| "IA estratégica não decorativa" | Princípio #3: IA atravessando 4 cockpits, não cosmética |
+| "Coexistência com ERPs existentes" | Princípio #4: multi-tenancy BD-por-workspace facilita integração heterogênea |
+| "SaaS web distribuível" | Multi-tenancy + provisioning automatizado de workspace |
+
+Positioning declara promessas. Concept estrutura a entrega.
--- a/design-artifacts/A-Product-Brief/dialog/progress-tracker.md
+++ b/design-artifacts/A-Product-Brief/dialog/progress-tracker.md
@@ -0,0 +1,45 @@
+# Progress Tracker — Phase 1 (Project Brief)
+
+> Status dos 36 steps da Phase 1 WDS-v6.
+
+| # | Step | Status | Concluído em |
+|---|---|---|---|
+| 01 | Init | ✅ | 2026-05-26 |
+| 01a | Client Profile | ✅ | 2026-05-26 |
+| 02 | Vision | ✅ | 2026-05-26 |
+| 03 | Positioning | ✅ | 2026-05-26 |
+| 05 | Business Model | ✅ | 2026-05-26 |
+| 06 | Business Customers | ✅ | 2026-05-26 |
+| 07 | Target Users | ✅ | 2026-05-26 |
+| 07a | Product Concept | ✅ | 2026-05-26 |
+| 08 | Success Criteria | ✅ | 2026-05-26 |
+| 09 | Competitive Landscape | ✅ | 2026-05-26 |
+| 10 | Constraints | ✅ | 2026-05-26 |
+| 10a | Platform Strategy | ✅ | 2026-05-26 |
+| 11 | Tone of Voice | ✅ | 2026-05-26 |
+| 12 | Create Product Brief | ✅ **BLOCK A COMPLETO** | 2026-05-26 |
+| 13 | Content Init | ✅ | 2026-05-26 |
+| 14 | Personality | ✅ | 2026-05-26 |
+| 15 | Tone | ✅ | 2026-05-27 |
+| 16 | Languages | ✅ | 2026-05-27 |
+| 17 | SEO Keywords | ✅ | 2026-05-27 |
+| 17a | Content Structure | ✅ | 2026-05-27 |
+| 18 | Create Content Document | ✅ **BLOCK B COMPLETO** | 2026-05-27 |
+| 19 | Inspiration Workshop | ✅ | 2026-05-27 |
+| 20 | Visual Init | ✅ | 2026-05-27 |
+| 21 | Existing Brand | ✅ | 2026-05-27 |
+| 22 | References | ✅ | 2026-05-27 |
+| 23 | Design Style | ✅ | 2026-05-27 |
+| 24 | Layout & Effects | ✅ | 2026-05-27 |
+| 25 | Imagery | ✅ | 2026-05-27 |
+| 26 | Create Visual Document | ✅ **BLOCK C COMPLETO** | 2026-05-27 |
+| 27 | Platform Init | ✅ | 2026-05-27 |
+| 28 | Tech Stack | ✅ | 2026-05-27 |
+| 29 | Integrations | ✅ | 2026-05-27 |
+| 30 | Contact Strategy | ✅ | 2026-05-27 |
+| 31 | Multilingual | ✅ | 2026-05-27 |
+| 32 | Create Platform Document | ✅ **BLOCK D COMPLETO** | 2026-05-27 |
+| 33 | Analyze Brief | ✅ | 2026-05-27 |
+| 34 | Create Summary | ✅ | 2026-05-27 |
+| 35 | Update Design Log | ✅ | 2026-05-27 |
+| 36 | Provide Activation Phase 2 | ✅ **PHASE 1 COMPLETA** | 2026-05-27 |
--- a/design-artifacts/A-Product-Brief/dialog/success-criteria.md
+++ b/design-artifacts/A-Product-Brief/dialog/success-criteria.md
@@ -0,0 +1,141 @@
+# Success Criteria — SAR (Força de Vendas)
+
+**Confirmed:** 2026-05-26
+**Step:** 08 — Success Criteria
+
+> Critérios SMART para guiar decisões. **North Star do MVP:** retenção do 1º cliente nos primeiros 3 meses.
+
+---
+
+## North Star
+
+### MVP (primeiros 6 meses)
+> **1º cliente real paga e renova sem cancelar nos primeiros 3 meses após go-live.**
+
+Critério primário: **retenção provada** > tração massiva. Prova que o produto entrega valor sustentado, não só "wow" da demo.
+
+### Y1 comercial (12 meses pós-GA)
+> **10-20 clientes pagantes (perfil conservador) com NPS dos donos > 50 e ARR de R$ 200k-600k.**
+
+Foco em referências sólidas que alimentem o canal #1 (boca-a-boca).
+
+---
+
+## A. Sucesso do negócio JCS (north star externa)
+
+| Métrica | Target Y1 | Frequência de revisão | Por quê |
+|---|---|---|---|
+| **Clientes pagantes (logos)** | 10-20 | Mensal | Tração de mercado |
+| **MRR** | R$ 17k-50k (final de Y1) | Mensal | Saúde recorrente |
+| **ARR** | R$ 200k-600k | Trimestral | Valuation-relevant |
+| **Logo churn mensal** | < 3% | Mensal | Saúde da retenção SaaS B2B |
+| **NPS dos buyers (donos)** | > 50 | Trimestral | Probabilidade de indicação (canal #1) |
+| **CAC payback** | < 12 meses | Trimestral | Eficiência de aquisição |
+| **NRR (Net Revenue Retention)** | > 110% | Trimestral | Expansão dentro da base (clientes crescem reps) |
+
+### Cálculo de ARR Y1 (sanity check)
+
+Mix realista assumido: maioria clientes pequenos (5-10 reps) no início, alguns médios baixos.
+
+- ARR médio/cliente Y1: ~R$ 15k-30k
+- 10 clientes: R$ 150k-300k (conservador-baixo)
+- 20 clientes: R$ 300k-600k (conservador-alto)
+
+→ **Faixa target: R$ 200k-600k ARR ao final de Y1.**
+
+---
+
+## B. Sucesso do cliente (a empresa que comprou)
+
+> A prova de que o SAR cumpre a promessa. Se o cliente cresce, ele recomenda — alimenta canal #1.
+
+| Métrica | Como medir | Target | Quando |
+|---|---|---|---|
+| **Pedidos/rep/mês vs. baseline pré-SAR** | Cliente declara baseline; SAR mede pós | **+15-30%** | 6 meses pós-go-live |
+| **% clientes inativos recuperados via alerta IA** | Funil: inativo (>60d sem pedido) → pedido novo | **10-20%** | 3 meses pós-go-live |
+| **Tempo médio aprovação de desconto** | Telemetria: rep envia → supervisor decide | **< 30 min** | Imediato (vs horas no WhatsApp) |
+| **% reps ativos no produto** | DAU/MAU dos reps cadastrados | **> 80%** | 60 dias pós-go-live |
+| **NPS dos reps** | Survey trimestral | **> 30** | Trimestral (reps são duros) |
+
+---
+
+## C. Comportamento dos usuários (signal de adoção)
+
+| Persona | Métrica | Target | Por quê |
+|---|---|---|---|
+| **🟢 Rafael (Rep)** | % pedidos lançados pelo SAR vs paralelo (WhatsApp/papel) | **> 95%** | Prova adoção real |
+| | Tempo médio de lançamento de pedido | **< 60s** | Cumpre cenário canônico |
+| | DAU/MAU | **> 70%** | Uso diário esperado |
+| **🟡 Sandra (Supervisora)** | Aprovações via SAR (não WhatsApp) | **> 90%** | Prova que abandona canal velho |
+| | Acessa "tela do dia" diariamente | **> 80% dias úteis** | Validação do "apertar parafusos" |
+| **🔵 Daniel (Dono)** | Acessa insights da IA | **> 2x/semana** | Diferencial declarado (IA estratégica) |
+| **🟣 Alice (Admin)** | Lança campanha sem suporte JCS | **> 80% das campanhas** | Validação do editor no-code |
+
+---
+
+## D. Qualidade de experiência (signal de saúde)
+
+| Métrica | Target | Por quê |
+|---|---|---|
+| **p95 latência de tela** | < 800ms | Promessa "tempo real" |
+| **p95 lançamento de pedido (end-to-end)** | < 60s | Cumpre cenário Rafael |
+| **% tickets de suporte resolvidos < 4h** | > 80% | Padrão B2B SaaS |
+| **Disponibilidade (uptime mensal)** | 99.5% | SLA típico |
+| **Pedidos perdidos por bug/sync** | **0** | Crítico — Rafael não confia se perder pedido |
+| **Workspace provisionado em** | < 5 min (trial) | Onboarding "fácil" declarado |
+
+---
+
+## Timeline / Marcos
+
+| Marco | Quando | Critério de aceite |
+|---|---|---|
+| **MVP em produção com 1º cliente real** | **3-4 meses** (a partir de 2026-05-26) | Cliente assinou contrato pago, está usando os 4 cockpits no dia-a-dia |
+| **MVP validado** | + 3 meses (≈mês 6-7) | 1º cliente renovou (não cancelou) → north star MVP atingida |
+| **Beta público / abertura para SDR** | + 1-2 meses (≈mês 8) | Funcionalidade core estável, processo comercial JCS operacional |
+| **10 clientes pagantes** | ≈ mês 12 | Marco conservador Y1 |
+| **20 clientes pagantes** | ≈ mês 16-18 | Marco esticado Y1+ |
+
+**Premissa de timeline:** Julian acumulando PO + Tech + Champion com 1-2 devs adicionais. Stack canon + brand + concept prontos aceleram em ~30% vs. greenfield total.
+
+---
+
+## Decisões implícitas nessas métricas
+
+1. **Métricas exigem instrumentação no produto desde MVP**
+   - Telemetria de p95 latência, DAU/MAU, tempo de lançamento, funil de inativo→pedido
+   - Implica setup de observabilidade (Pino + OTel + Grafana — STACK.md §09) **no MVP**, não em Phase 2 de roadmap
+   - Implica também eventos de produto para analytics (PostHog, Amplitude, ou solução self-host)
+
+2. **NPS exige operação contínua**
+   - Survey trimestral via email/in-app
+   - Implica módulo de feedback no produto (mesmo simples)
+
+3. **Suporte com SLA de 4h exige time/processo JCS**
+   - Define expectativa: SDR + 1 atendente mínimo
+   - Pode ser Julian no início (não escalável, mas viável)
+
+4. **CAC payback < 12 meses define o range comercial**
+   - Para ticket médio R$ 1.500/mês (cliente médio), CAC < R$ 18k → limita custos de aquisição (eventos, ads, parceiros)
+   - Implica que a aquisição começa **boca-a-boca + SEO** (custo baixo), não ads pagos pesados
+
+---
+
+## Riscos calibrados pelos critérios
+
+| Risco | Métrica que detecta | Ação se falhar |
+|---|---|---|
+| **Rafael não adota** | DAU/MAU < 50% em 60 dias | Revisão UX mobile-first; possível pivot de interação |
+| **Sandra não confia** | Aprovações via WhatsApp > 30% | Investigação: SAR lenta? Falta contexto? Workflow ruim? |
+| **Daniel ignora IA** | < 1x/semana em IA insights | IA está irrelevante / pouco visível / black box demais |
+| **Cliente cancela em 3 meses** | Churn > 0 nos primeiros 3 meses | NORTH STAR FALHADA — review estrutural do MVP |
+| **Pedidos perdidos por bug** | > 0 incidentes em qualquer janela | P0 imediato — bloqueio de release até root cause |
+
+---
+
+## Lacunas conscientemente adiadas
+
+- Preço exato/rep (validar com primeiras vendas)
+- Métrica de eficiência IA (qualidade de sugestão) — definir após primeiros insights gerados
+- NPS de Alice (Admin) — não prioritário no MVP
+- Métricas detalhadas de WhatsApp (engagement, response rate) — após integração funcionar
--- a/design-artifacts/A-Product-Brief/dialog/target-users.md
+++ b/design-artifacts/A-Product-Brief/dialog/target-users.md
@@ -0,0 +1,257 @@
+# Target Users — SAR (Força de Vendas)
+
+**Confirmed:** 2026-05-26
+**Step:** 07 — Target Users
+**Primary persona:** Rafael (Representante)
+
+> 4 user personas no produto. **Buyer persona** (dono empresário) já documentado em `business-customers.md` — overlap real com Daniel (User Dono+IA) em empresas pequenas.
+
+---
+
+## Hierarquia de prioridade no design
+
+| Prioridade | Persona | Justificativa |
+|---|---|---|
+| **PRIMÁRIA (MVP focus)** | Rafael (Rep) | 70-90% do volume de uso; mobile-first; SAR ganha ou perde aqui |
+| Secundária — alto impacto | Sandra (Supervisora) | Influenciadora-chave da compra; demo vitrine |
+| Secundária — alto valor | Daniel (Dono) | Buyer overlap; IA é diferencial declarado |
+| Terciária — operacional | Alice (Admin) | Backoffice de pautas/promoções; baixo volume mas crítica para o produto rodar |
+
+**Implicação de design:** **mobile-first para Rafael, desktop-first para Sandra/Daniel/Alice.** SAR não é "responsivo um-tamanho-só" — são duas paradigmas de UI no mesmo produto.
+
+---
+
+## 🟢 Rafael — Representante (PERSONA PRIMÁRIA)
+
+### Quem é
+- 30-50 anos, vendedor B2B externo
+- Atende 50-200 clientes ativos numa região definida
+- Comissionado, meta mensal pesa muito na renda
+- Trabalha no carro, no posto, no escritório do cliente — **raramente na frente de um computador**
+
+### Cenário típico (8h da manhã, segunda)
+> "No carro entre 2 clientes. Quer abrir o SAR no celular e ver: meta do mês, quem visitar hoje, status do último pedido da OPENFRIOS, se já chegou pedido novo, e se a Distribuidora Norte respondeu o orçamento."
+
+### Frustrações (no legado)
+- Lança pedido pelo app e não sabe se entrou; precisa ligar pro escritório pra confirmar
+- Comissão é mistério até fechar o mês — calcula no Excel próprio "pra não confiar cego"
+- Cliente que parou de comprar passa despercebido até ele perceber sozinho
+- Atualizou número de WhatsApp do contato? Ninguém vai saber, vai esquecer
+- Não vê pipeline: tem 3 propostas em aberto e não lembra qual é mais quente
+- App lento, trava no 3G/4G ruim, perde formulário cheio
+
+### Goals
+- **Bater meta** (sempre — define o salário)
+- Vender mais com menos esforço administrativo
+- Não levar bronca do supervisor por algo que ele já sabia
+- Ter resposta rápida quando cliente pede algo no campo
+
+### Current solution (composição)
+- App Android JCS legado (lançamento de pedido)
+- WhatsApp pessoal (contato cliente)
+- Planilha Excel/Google Sheet própria (comissão, anotações)
+- Ligação pro escritório (confirmação)
+- Agenda física ou Google Agenda (visitas)
+
+### O que ele precisa do SAR
+1. **Lançamento de pedido em < 60 segundos no celular**, mesmo com sinal ruim
+2. **Visão 360° do cliente** — histórico, pedidos, contatos, timeline
+3. **Comissão visível em tempo real** (não fechamento de mês)
+4. **Funil de propostas/oportunidades** (kanban simples)
+5. **Lista de clientes inativos** com alerta proativo
+6. **WhatsApp integrado** (não sair do app para conversar)
+7. **Agenda + check-in GPS** para roteiro do dia
+
+### Implicações de design
+- **Mobile-first OBRIGATÓRIO** (Rafael abre o SAR no celular >80% do tempo)
+- **Offline-first parcial** ou ao menos resiliente — lançamento de pedido não pode perder por sinal ruim
+- **Touch-friendly:** botões grandes, gestos simples, sem dropdown aninhado
+- **Latência percebida baixa:** ack imediato do que ele faz, sync em background
+- **Dark mode** desejável (carro, posto à noite)
+
+---
+
+## 🟡 Sandra — Supervisora de Vendas
+
+### Quem é
+- 35-55 anos, gerente comercial ou gerente regional
+- Coordena 5-30 representantes
+- Reporta para dono/diretor comercial
+- **Trabalha em escritório** com desktop/notebook a maior parte do dia
+
+### Cenário típico (segunda 9h, na sala)
+> "Café na mão, abre o SAR no notebook. Quer ver: quais reps já fizeram check-in essa manhã, pedidos aguardando aprovação de desconto, top 5 clientes da carteira que não compram há 30+ dias, e se tem alguma anomalia (queda brusca de faturamento, rep parado, cliente reclamando)."
+
+### Frustrações (no legado)
+- Reps "somem" — não sabe quem está em campo, quem está enrolado em casa
+- Aprovação de desconto vira fila de WhatsApp ("preciso de R$ X de desconto pro cliente Y, libera?")
+- Não consegue ver pipeline real, só o que cada rep relata na reunião semanal
+- Quando algo dá errado em pedido (cliente bloqueado, crédito estourado), descobre tarde
+- Relatórios do legado são lentos, exigem export-Excel-pivottable
+- Não tem visão consolidada da meta da equipe em tempo real
+
+### Goals
+- Garantir que **time bata meta**
+- Identificar reps performando mal **antes** que perca venda
+- Não negligenciar clientes-chave
+- Liberar descontos com critério (não no impulso)
+- **Dormir tranquila** sabendo que está tudo sob controle
+
+### Current solution
+- Desktop JCS legado (relatórios + aprovações)
+- Planilhas (consolidação manual)
+- WhatsApp (aprovação de desconto, comunicação com reps)
+- Reunião semanal presencial/Zoom (90 min, suga tempo)
+
+### O que ela precisa do SAR
+1. **Dashboard "apertar parafusos" diário** — top 5 ações que ela precisa tomar HOJE
+2. **Fila de aprovação de descontos** com contexto (cliente, histórico, margem)
+3. **Mapa de calor da equipe** — quem está produzindo, quem precisa empurrão
+4. **Alertas proativos** — rep sem check-in há 2 dias, cliente top sem pedido há 30+ dias
+5. **Comparativo entre reps** (sem expor publicamente, só pra ela)
+6. **Relatórios sob demanda** que carregam em <5 segundos
+
+### Implicações de design
+- **Desktop-first**, mas com mobile útil (consulta rápida)
+- **Dense information design** — Sandra quer muita informação na mesma tela
+- **Ações decisórias com 1-2 cliques** (aprovar/negar desconto sem 5 telas)
+- **Notificações push** para itens que exigem decisão dela
+
+---
+
+## 🔵 Daniel — Dono / Diretor Comercial
+
+### Quem é
+- 40-65 anos, sócio-fundador ou diretor sênior
+- Já passou pela operação, hoje dirige
+- Tem o caixa, decide investimentos
+- **Compra o SAR + usa o SAR** (buyer e user — overlap com business-customers.md)
+- Vê o SAR no notebook em casa, no escritório, no celular esporadicamente
+
+### Cenário típico (terça à noite, em casa)
+> "Janta com a família, depois abre o SAR no iPad. Quer ver: faturamento do mês vs. meta, top 5 clientes do mês, top 5 produtos, **clientes que estão esfriando**, e principalmente **o que a IA está sugerindo** ('Atenção: cliente X reduziu pedidos 40% nos últimos 60 dias' / 'Oportunidade: produto Y cresceu 25%, considere campanha')."
+
+### Frustrações (no legado)
+- Dashboards mostram passado, não próximo passo
+- Recebe planilhas mas não consegue extrair direção
+- Sabe que está perdendo cliente, mas não sabe quais nem por quê
+- Quer delegar pra Sandra mas não confia 100% que ela vai ver o que ele veria
+- Reuniões com supervisor são genéricas, sem dados acionáveis
+
+### Goals
+- **Dirigir, não operar**
+- Ter painel que **avisa quando algo desvia** (não precisar procurar)
+- Confiar no time + ter visibilidade estratégica
+- Tomar decisões de investimento (contratar mais rep? trocar tabela de preço?) com dados
+
+### Current solution
+- Desktop JCS legado para relatórios mensais
+- Excel (consolidação que financeiro/Sandra preparam)
+- Reuniões com supervisor (semanal/quinzenal)
+- Intuição + experiência
+
+### O que ele precisa do SAR
+1. **Dashboard estratégico** (não operacional) — faturamento, top/bottom, tendências
+2. **IA estratégica proativa** — alertas + sugestões, não relatório passivo (DIFERENCIAL DECLARADO)
+3. **Comparativo período a período** (este mês vs. mês passado, vs. mesmo mês ano anterior)
+4. **Análise de carteira** — concentração de risco em 1-2 clientes, churn silencioso
+5. **Visão de meta por equipe / por rep**
+6. **Recomendações de IA** (campanhas, alocação de esforço, ajuste de tabela)
+
+### Implicações de design
+- **Desktop/iPad-first** — Daniel quer telas amplas, gráficos grandes
+- **Visualização > tabela** — gráficos, indicadores, alertas; minimizar listas brutas
+- **Tom executivo** — sem ruído operacional ("3 pedidos aguardando aprovação" é da Sandra, não dele)
+- **IA precisa explicar:** "Por que está me dizendo isso?" — alertas com contexto, não black box
+- **Modo claro/escuro elegante** (uso noturno em casa)
+
+---
+
+## 🟣 Alice — Administradora / Backoffice
+
+### Quem é
+- 25-45 anos, funcionária administrativa da empresa-cliente
+- Trabalha em escritório, **desktop o dia todo**
+- Reporta para Sandra ou Daniel
+- Domínio: catálogo, pautas, tributação, campanhas, cadastros
+
+### Cenário típico (quarta 14h, no escritório)
+> "Está cadastrando nova linha de produtos que a empresa vai começar a vender em janeiro. Precisa importar planilha do fornecedor, ajustar pauta de preço por região, configurar grupo tributário (ICMS-ST), depois preparar a **campanha de lançamento com 15% de desconto na primeira compra**."
+
+### Frustrações (no legado)
+- Cadastros lentos, telas confusas, muitos campos opcionais sem orientação
+- Pauta de preço é planilha avulsa importada manualmente — propensa a erro
+- Configurar promoção exige "pedir pro dev rodar SQL"
+- Tributação ICMS-ST por UF é um inferno — não tem assistente, tem que conhecer regra
+- Cadastrar rep com permissões/região é processo manual
+- Não tem trilha de auditoria — quem mexeu na tabela de preço ontem?
+
+### Goals
+- Manter catálogo + tributação + promoções funcionando **sem incidente**
+- Não precisar do dono pra cada ajuste
+- **Lançar campanhas com agilidade** (promoções de fim de mês, sazonais, kit, brinde)
+- Ter confiança de que o sistema não vai "estourar" pedidos por erro de pauta
+
+### Current solution
+- Desktop JCS legado (cadastros e pautas)
+- Excel (planilhas de import/conferência)
+- Pede pro dev (JCS ou interno) quando precisa de algo não-coberto pela tela
+- Documentos PDF da legislação ICMS-ST sempre abertos
+
+### O que ela precisa do SAR
+1. **Cadastro de produto rápido** (form inteligente, validação por contexto)
+2. **Pauta de preço com versionamento** — saber o que mudou, quando, por quem
+3. **Editor de campanhas/promoções no-code** (não SQL): "Produto X com 15% off para clientes da região Y durante o mês Z"
+4. **Assistente de tributação** (ICMS-ST/IPI) — sugere grupo correto baseado em NCM + UF de destino
+5. **Gestão de representantes** — cadastro, região de atuação, hierarquia (rep → supervisor), comissão
+6. **Auditoria** — quem mexeu em quê, quando, conseguir reverter
+7. **Bulk operations** — import CSV, edição em lote
+
+### Implicações de design
+- **Desktop-only** (sem investimento mobile prioritário)
+- **Dense forms** com assistentes — não wizards de 10 passos
+- **Confirmação para operações destrutivas** (alterar pauta de 500 produtos exige double-check)
+- **Trilha de auditoria visível** (histórico em cada entidade)
+- **Editor visual de campanhas** — possível diferencial sobre concorrentes que exigem SQL/script
+
+---
+
+## Comparativo executivo
+
+| Persona | Device | Volume de uso | Frequência | Frustração #1 | Goal #1 |
+|---|---|---|---|---|---|
+| Rafael (Rep) | **Mobile-first** | 70-90% | Várias vezes ao dia | Cliente esfria sem ele saber | Bater meta |
+| Sandra (Supervisora) | Desktop-first + mobile | 5-15% | Várias vezes ao dia | Reps "somem" no campo | Time bate meta + dormir tranquila |
+| Daniel (Dono) | Desktop/iPad | 1-5% | Diário/semanal | Recebe passado, não próximo passo | Dirigir sem operar |
+| Alice (Admin) | Desktop-only | 1-5% | Diário (em ondas) | Promoção exige pedir pro dev | Lançar campanha sozinha |
+
+---
+
+## Buyer × User mapping (atualização do business-customers.md)
+
+| Papel na compra | User persona overlap |
+|---|---|
+| **Decisor (Dono)** | Daniel (alto overlap — buyer = user em PME pequena) |
+| **Decisor (Diretor comercial)** | Sandra (em PME média, diretor comercial é a Sandra subindo na hierarquia) |
+| **Influenciador-chave** | Sandra (sempre) + Rafael (champion interno se já conheceu) |
+| **Ausente** | Alice (não pesa na decisão; só usa depois de comprado) |
+
+**Insight de venda:** a **demo precisa brilhar para Sandra** (influenciadora), **vender para Daniel** (decisor), e **encantar Rafael** (champion). Alice é benefício mostrado, não argumento de venda.
+
+---
+
+## Implicações para Phase 2 (Trigger Map)
+
+As 4 personas viram base para os "Target Groups" do Trigger Map. Cada uma terá:
+- Alliterative persona name confirmado: Rafael Representante / Sandra Supervisora / Daniel Dono / Alice Admin
+- Driving forces positivas + negativas
+- Frequency × Intensity × Fit scoring
+- Feature impact mapping
+
+---
+
+## Lacunas conscientemente adiadas
+
+- Cena visceral / dia típico com dialogo real (Phase 2)
+- Sub-segmentação dentro de Rafael (rep de distribuidora vs rep de indústria — pode ter dores distintas)
+- Mapa empático completo (Phase 2 Trigger Map)
--- a/design-artifacts/A-Product-Brief/dialog/tone-of-voice.md
+++ b/design-artifacts/A-Product-Brief/dialog/tone-of-voice.md
@@ -0,0 +1,131 @@
+# Tone of Voice — SAR (Força de Vendas)
+
+**Confirmed:** 2026-05-26
+**Step:** 11 — Tone of Voice
+
+> Tom de voz para **microcopy de UI** (botões, labels, erros, estados, notificações). Conteúdo estratégico (headlines, value propositions) será definido em Phase 1 Block B (Content & Language).
+
+---
+
+## 5 atributos canônicos
+
+| # | Atributo | Por quê |
+|---|---|---|
+| **1** | **Direto** | Rafael precisa de info em 2 segundos no celular; Sandra decide num clique. Floreio mata fluxo. |
+| **2** | **Profissional sem ser frio** | B2B BR respeita formalidade, mas burocratês mata vendas. Sério mas humano. |
+| **3** | **Confiante** | SAR é ferramenta de trabalho, não conselheiro tímido. Afirmação > tentativa. |
+| **4** | **Específico** | "3 clientes pararam de comprar há 60+ dias" > "Há alertas". Números/dados criam confiança imediata. |
+| **5** | **Empático nos momentos difíceis** | Quando algo dá errado, explica o problema E o caminho, sem culpar o usuário. |
+
+---
+
+## Variações por cockpit (mesmos atributos, registros diferentes)
+
+| Cockpit | Registro | Exemplo |
+|---|---|---|
+| **🟢 Rafael (Rep)** | Mais informal, frases curtas, foco em ação | "Sem sinal. Envio depois." · "Meta de junho: faltam R$ 12.400." |
+| **🟡 Sandra (Supervisora)** | Direto + decisivo, contexto rápido | "3 aprovações pendentes." · "Rep João sem visita há 2 dias." |
+| **🔵 Daniel (Dono)** | Executivo, focado em insight | "Faturamento em junho: +18% vs maio. Liderado por OPENFRIOS." |
+| **🟣 Alice (Admin)** | Técnico-preciso, mas humano | "Pauta atualizada. 1.247 produtos afetados." |
+
+---
+
+## Exemplos canônicos
+
+### Botões
+
+| Ação | ❌ Burocrata | ✅ SAR |
+|---|---|---|
+| Salvar | "Confirmar Operação" | **Salvar** |
+| Enviar pedido | "Submeter para Aprovação" | **Enviar pedido** |
+| Cancelar | "Desistir da Operação" | **Cancelar** |
+| Pedir desconto | "Solicitar Aprovação de Desconto" | **Pedir desconto** |
+
+### Estados vazios
+
+| Tela | ❌ Genérico | ❌ Forçado | ✅ SAR |
+|---|---|---|---|
+| Funil sem propostas | "Nenhum registro encontrado" | "Ops, vazio!" | "Sem propostas em andamento. Cadastre a primeira em **Nova proposta**." |
+| Inativos zerado | "Nenhum cliente com restrição" | "Tudo certo!" | "Nenhum cliente inativo nos últimos 60 dias." |
+| Sem pedidos hoje | "Não há registros" | "Hoje não rolou nada" | "Nenhum pedido lançado hoje. Bom dia para mudar isso." |
+
+### Erros / problemas
+
+| Situação | ❌ Burocrata | ✅ SAR |
+|---|---|---|
+| Sem sinal ao salvar | "ERRO: Falha de conexão" | "Sem sinal. Seu pedido fica salvo aqui e envia quando você se conectar." |
+| Cliente bloqueado | "O sistema identificou que o cliente apresenta restrição que impede a continuidade." | "Cliente **OPENFRIOS** está bloqueado: limite de crédito estourado. Peça liberação ao supervisor ou ajuste o valor." |
+| Senha errada | "Credenciais inválidas" | "Senha incorreta. Tente de novo ou **recupere sua senha**." |
+| Desconto além da alçada | "Operação não permitida" | "Esse desconto precisa de aprovação do supervisor. Quer enviar agora?" |
+
+### Confirmações e notificações
+
+| Evento | ❌ Vago | ✅ SAR |
+|---|---|---|
+| Pedido aprovado | "Operação concluída com sucesso" | "Pedido #1234 aprovado pela Sandra." |
+| Cliente esfriando | "Atenção necessária" | "**OPENFRIOS** não compra há 47 dias. Visite ou ligue." |
+| IA insight (Daniel) | "Análise disponível" | "Você aprovou 3 descontos acima de 10% essa semana, todos para OPENFRIOS. Reavaliar tabela?" |
+
+### Loading states
+
+| ❌ Genérico | ✅ SAR |
+|---|---|
+| "Carregando..." | "Carregando catálogo (8.234 produtos)..." |
+| "Aguarde" | "Sincronizando pedidos do dia..." |
+| "Processing..." | "Enviando pedido..." |
+
+---
+
+## Do's & Don'ts
+
+### ✅ Do's
+- **Voz ativa:** "Sandra aprovou", não "Foi aprovado por Sandra"
+- **pt-BR coloquial profissional:** "Salvar", "Editar", "Excluir" (não "Salve", "Edite")
+- **Dados específicos** sempre que possível
+- **Problema E caminho** para resolver (não só o que deu errado)
+- **Nomes reais** quando aplicável (`OPENFRIOS`, `Rafael`, `Sandra`) — humaniza
+
+### ❌ Don'ts
+- ❌ Emoji em texto de produção. Brand é clean Apple-inspired.
+- ❌ Caps lock para erros
+- ❌ Burocratês ("operação", "registro", "sistema", "movimentação", "documento")
+- ❌ "Por favor" e "obrigado" excessivos
+- ❌ Trocadilhos, gírias regionais, jokes (produto é multi-empresa/multi-região)
+- ❌ Anglicismos onde tem pt-BR claro (Submit → Enviar; Loading → Carregando)
+- ❌ Frases dúbias ou condicionais ("Talvez", "Possivelmente", "Acreditamos que...")
+
+---
+
+## Vocabulário canônico (entra no Design System)
+
+Termos consistentes no produto inteiro. **Padrão único** — nunca sinônimos.
+
+| Termo | Escolha canônica | Não usar |
+|---|---|---|
+| Pessoa que compra do cliente do SAR | **Cliente** | "Comprador", "consumidor", "shopper" |
+| Pessoa que vende (Rafael) | **Representante** ou **Rep** | "Vendedor", "promotor", "agente" |
+| Documento de venda em negociação | **Orçamento** | "Cotação", "proposta orçamentária" |
+| Documento de venda confirmado | **Pedido** | "Ordem de compra", "ordem de venda" |
+| Documento de venda concluído | **Faturado** | "Finalizado", "concluído", "fechado" |
+| Saída para visitar cliente | **Visita** | "Atendimento", "round" |
+| Carteira ativa do rep | **Carteira** | "Base de clientes", "lista" |
+| Cliente que parou de comprar | **Inativo** | "Frio", "perdido", "stand-by" |
+| Painel inicial | **Painel** | "Dashboard", "tela inicial" |
+| Aprovação de desconto | **Aprovação** | "Autorização", "validação", "endosso" |
+
+---
+
+## Implicações
+
+1. **Vocabulário vira tokens i18n** — entrar no projeto como constantes em `libs/shared/api-interface` ou similar. Termos centralizados, não strings espalhadas.
+2. **Tom de voz vai no Design System (Phase 6)** como documento de referência para todos que escrevem microcopy.
+3. **PRs com microcopy** devem verificar contra este documento; eventual lint customizado pode detectar termos proibidos.
+4. **Atributos guiam decisões de IA generativa** quando IA escrever texto (alertas do Daniel, sugestões da Alice). Prompt da IA inclui esses 5 atributos + vocabulário canônico.
+
+---
+
+## Lacunas conscientemente adiadas
+
+- Conteúdo estratégico (headlines, value propositions do site) — Steps 13-18 (Block B Content & Language)
+- Tom para emails transacionais (confirmação de pedido para cliente final) — Step 15
+- Tom para WhatsApp programático (mensagem ao cliente do cliente) — Step 15 ou 29
--- a/design-artifacts/A-Product-Brief/dialog/vision.md
+++ b/design-artifacts/A-Product-Brief/dialog/vision.md
@@ -0,0 +1,67 @@
+# Vision — SAR (Force de Vendas)
+
+**Confirmed:** 2026-05-26
+**Step:** 02 — Vision
+**Synthesized by:** Saga (BA) from Julian's exploratory answers
+
+---
+
+## Vision Statement
+
+> **SAR é a plataforma de força de vendas que dá clareza para o representante, ferramenta de decisão para o supervisor, e IA estratégica para o dono — entregue como SaaS web, vendável e escalável, posicionando a JCS Sistemas como fornecedora de software moderno para o mercado B2B brasileiro.**
+
+---
+
+## Três experiências distintas no mesmo produto
+
+### Representante — "clareza total da minha carteira"
+- Sabe a cada momento: **quanto** vender, **pra quem**, **status** de cada pedido
+- **Metas expostas e atingíveis** (não escondidas em relatórios)
+- **WhatsApp nativo** integrado: conversa com cliente + aquecimento de leads sem sair do SAR
+- **Inteligência de carteira**: lista de inativos, ciclo de vendas por cliente, oportunidades
+
+### Supervisor — "telas que apertam parafusos todos os dias"
+- Não é "dashboard contemplativo" — é **instrumento de ação diária**
+- Vê onde o time precisa de empurrão, libera/bloqueia, ajusta rotas
+- Decide rápido, com dados na frente
+
+### Dono / Diretor — "gerencia só com análise e IA"
+- Sai da operação. Não acompanha pedido a pedido.
+- **IA dá dicas** — onde a empresa sangra, onde cresce, onde investir
+- Camada estratégica, não operacional
+
+---
+
+## Para a JCS Sistemas (perspectiva de negócio)
+
+> **A primeira plataforma SaaS web da JCS** — produto distribuível, não software empacotado.
+
+Salto qualitativo sobre Android+Desktop:
+- **Distribuição instantânea** (onboarding sem instalação)
+- **SaaS multi-tenant** (vende para N empresas com o mesmo produto)
+- **Vitrine de modernidade** (abre porta para próximos produtos JCS na nova stack)
+
+---
+
+## Diferenciais explícitos (entrada para Step 3 — Positioning)
+
+1. **Inteligência de carteira ativa**: estatísticas de inativos, ciclo de vendas, radar de oportunidades
+2. **WhatsApp como canal nativo** (não anexo): conversa + aquecimento de lead
+3. **Metas como gamificação operacional**: expostas, atingíveis, ao alcance do rep
+4. **Camadas distintas por papel**: cada papel vê o que precisa, no formato que precisa decidir
+5. **IA estratégica para o dono** (não IA decorativa)
+6. **Web-first / SaaS distribuível** (vs. legado Android+Desktop instalável)
+
+---
+
+## Origem (citações do PO)
+
+> "Quero que ele [cliente recomendando] fale que é a melhor plataforma de força de vendas, porque ela traz estatísticas de clientes inativos, ciclo de vendas dos cliente, API com WhatsApp para conversa e mensagem de aquecimento de lead. Cada representante sabe quanto, pra quem e status dos pedidos, tem suas metas expostas e prontas para atingir, supervisores com telas que tomam decisões apertam parafusos todos os dias e o dono que gerencia somente com análise e IA dando dicas."
+
+> "Questão de entregar sistemas web para nossos clientes. E fácil instalação e distribuição do produto."
+
+---
+
+## Lacuna documentada
+
+Pergunta 1 ("cena concreta de um dia típico vivido") ficou em aberto — substância suficiente emergiu das respostas de 2 e 3, mas o **dia-a-dia visceral** (clima, sentimento, tensões) será detalhado na Phase 2 (Trigger Map), quando aprofundarmos personas.