bf6e21ce4783972a4b20bfd07b99599e7fabd26a
Revoga o ADR 0006. O isolamento multi-tenant deixa de ser um banco por workspace e passa a ser o schema `sar` dentro do proprio banco ERP do cliente, com `id_empresa` discriminando o tenant em todas as tabelas. Provisionamento: - `provision-client.ts` substitui `provision-workspace.ts`. Nao cria mais banco: aplica schema + views + triggers num banco ERP ja existente. Trata o encoding LATIN1 dos bancos ERP via `toLatinSafe()`. - `sar-erp-schema.sql` vira a fonte unica: absorve as views que estavam em `sarweb_views.sql` e passa a conter tambem `sar.chamados` / `sar.chamado_mensagens`, que so existiam via migration. Correcoes necessarias para o provisionamento rodar ponta a ponta: - `migrate deploy` abortava com P3005, porque o schema SQL roda antes do Prisma e o schema `sar` nunca esta vazio. O script agora detecta banco pre-existente e faz o baseline sozinho. - `_prisma_migrations` ia parar no schema `public` do ERP do cliente; a URL de migracao agora leva `?schema=sar`. - `sar.pedidos` nao tinha `end_entrega`, coluna que o schema.prisma ja declarava desde a feature de endereco de entrega, e que derrubava GET /orders com 500. Migration adicionada. - `vw_sitpedido` se perdeu junto com `sarweb_views.sql` e e usada pela consulta de pedidos ERP. Restaurada. Remove o seed de dados demo e os fallbacks de DATABASE_URL hardcoded: sem a variavel configurada a API agora falha explicitamente, em vez de apontar silenciosamente para um banco de desenvolvimento inexistente. Verificado ponta a ponta contra um banco ERP real: schema aplicado, 13 tabelas + 20 views, migrations registradas, e segunda execucao idempotente. BREAKING CHANGE: DATABASE_URL passa a ser obrigatoria. O comando de provisionamento muda para `pnpm client:provision --host <host> --db <banco>` (rename efetivado no commit de dependencias). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
SAR — Força de Vendas
Cliente: JCS Sistemas · Status: MVP em desenvolvimento
Plataforma SaaS B2B de força de vendas com 4 cockpits especializados (Rep / Supervisor / Dono / Admin) sobre dado único em tempo real, atravessado por WhatsApp nativo e IA contextual.
Stack canônica
Ver STACK.md v2.2 (fonte da verdade técnica) e CODING-RULES.md v2.0 (invariantes + pegadinhas 🔥).
| Camada | Tecnologia |
|---|---|
| Runtime | Node 24 LTS · pnpm 11.1 · TypeScript 5.9 |
| Monorepo | Nx 22.7 |
| Backend | NestJS 11 (CJS) · Prisma 7 · PostgreSQL 18 · BullMQ |
| Frontend | React 19 · Vite 8 · Ant Design 6.4 · TanStack Query/Router · Zustand |
| Multi-tenancy | BD-por-workspace (ADR 0006) |
| Infra | Proxmox on-prem BR (ADR 0004) · Docker Compose · Cloudflare |
Quickstart (dev local)
# Pré-requisitos: Node 24, pnpm 11.1 (via corepack), Docker
# 1. Instalar deps
pnpm install
# 2. Copiar template de env
cp .env.example .env
# 3. Subir stack de dev (Postgres, Valkey, MinIO, Mailpit)
pnpm dev:up
# 4. Rodar api (Nest 11) — porta 3000
pnpm dev:api
# 5. Em outro terminal, rodar web (Vite + React 19) — porta 4200
pnpm dev:web
URLs locais:
- Web app: http://localhost:4200
- API: http://localhost:3000
- MinIO console: http://localhost:9001 (login
sar_minio_admin/sar_minio_dev_password) - Mailpit (emails de teste): http://localhost:8025
Estrutura do monorepo
apps/
├── api/ # NestJS HTTP — monólito modular por domínio
├── api-e2e/ # E2E tests da API (Jest)
├── web/ # SPA React + Vite + AntD
└── web-e2e/ # E2E tests do frontend (Playwright)
libs/
└── shared/
└── api-interface/ # Zod schemas + tipos compartilhados api ↔ web
design-artifacts/ # WDS — Phase 1/2/3 docs (Brief, Trigger Map, Scenarios)
_references/ # Logos, mockups legados, materiais
scripts/ # SQL init, deploy scripts
docs/ # Docs do projeto (ADRs futuras)
Scripts úteis
pnpm build # Build de todos os projetos
pnpm lint # ESLint em tudo
pnpm test # Unit tests em tudo
pnpm graph # Visualiza grafo de dependências Nx
pnpm affected -- -t build # Só builda o que foi afetado pela mudança
pnpm format # Prettier write
Próximos passos do setup
- Provisionar VMs Proxmox para staging (Postgres, Valkey, MinIO, master-login, Vault)
- Configurar Gitea Actions (
.gitea/workflows/) — CI básico (lint + test + build) - Implementar master-login (IdP OAuth2/OIDC) — ADR 0005
- Implementar multi-tenant BD-por-workspace — ADR 0006
- Primeiro cockpit: Rafael (Rep) PWA mobile-first
Powered by JCS Sistemas · Stack canon JCS v2.2
Description
Languages
Python
54.3%
TypeScript
31.3%
HTML
10.1%
JavaScript
2.6%
PLpgSQL
0.7%
Other
0.9%