Implementação MVP

.cursor/rules/elopro-gerador-propostas.mdc

@@ -0,0 +1,63 @@
+---
+description: Regras obrigatórias para qualquer alteração no Gerador de Propostas EloPro
+alwaysApply: true
+---
+
+# EloPro — Gerador de Propostas — Regras do agente
+
+Antes de modificar código, leia `docs/gerador-propostas/SOURCE_OF_TRUTH.md` se existir.
+
+## Não negociável
+
+1. Não invente regra de negócio para preencher lacunas P-001..P-012.
+2. Não confie no frontend para autorização. Revalide workspace, role, ownership, entitlement, estado e limites no servidor.
+3. Toda tabela de domínio deve ser tenant-safe por `workspace_id` direto ou derivável por FK segura + RLS.
+4. Nunca aceitar `workspace_id` do cliente como fonte de autoridade. Resolva-o da sessão/contexto server-side.
+5. Usuário `agent` opera apenas próprias propostas; Gestor/Admin podem operar escopo do workspace conforme matriz.
+6. Usuário Final nunca acessa Modelos, inclusive via rota direta/Server Action.
+7. Versões formais de proposta e versões ativadas de modelo são imutáveis no fluxo normal.
+8. Falha de geração não pode criar número comercial, versão formal ou PDF formal parcial.
+9. Geração deve ser idempotente contra duplo clique, retry e reload.
+10. Lock funcional é de 10 minutos; não implementar force takeover no MVP.
+11. O fluxo 4.2 é uma experiência única com estados Preencher → Validar → Gerar.
+12. Abrir 4.2 não cria rascunho vazio. O rascunho nasce no primeiro persist aplicável.
+13. Apenas Modelo Ativo pode iniciar nova proposta.
+14. Limite de modelos = 10 por workspace, contando draft/active/archived, mas não versões.
+15. Marcadores são `[campo]`; não inferir campos com IA/heurstica.
+16. IA não pode substituir validação determinística de marcadores/regras.
+17. PDF/email/download devem trabalhar com a versão formal explicitamente exibida.
+18. Sentry/logs nunca devem receber documento integral, template integral ou PII desnecessária.
+19. Não introduza ORM, auth provider, query library, PDF engine, e-mail provider ou arquitetura paralela sem ADR/aprovação quando a stack já tem decisão.
+20. Não usar Lucide como “biblioteca oficial da marca”; é fallback quando não houver ícone EloPro.
+
+## Engenharia
+
+- Next.js 16 App Router + React 19.
+- Preferir Server Components para leitura.
+- Client Components somente quando interação/estado local exigir.
+- Server Actions para comandos autenticados da UI; Route Handlers para jobs/callbacks/integrações.
+- TanStack Query somente onde cache/refetch client-side trouxer valor real; não duplicar o cache do App Router.
+- TypeScript strict e tipos explícitos em fronteiras de domínio.
+- Vitest para regras de domínio e helpers críticos.
+- Migrations PostgreSQL versionadas; constraints e RLS fazem parte da feature, não são pós-trabalho.
+- Redis é efêmero; PostgreSQL é fonte de verdade de estados formais.
+
+## UX/UI
+
+- EloPro V2.1: Cloud White/Midnight Ink/Azul+Aqua; Manrope; superfícies claras predominantes.
+- Não criar dark page dominante, neon, cyberpunk, glassmorphism, hologramas, robôs/cérebros futuristas.
+- Erro/status nunca somente por cor.
+- Reutilizar componentes EloPro existentes; lacunas do DS viram componentes locais do domínio, não globais automaticamente.
+- Mobile deve ser adaptado, não encolhido.
+- Todas as ações destrutivas precisam de confirmação contextual e foco acessível.
+
+## Saída obrigatória ao terminar uma tarefa
+
+Responda com:
+1. resumo objetivo;
+2. arquivos criados/alterados;
+3. migrations/policies/constraints afetadas;
+4. testes adicionados e resultados;
+5. comandos de validação executados;
+6. riscos/pendências;
+7. qualquer decisão que dependa de humano/ADR.