64 lines
3.6 KiB
Plaintext
64 lines
3.6 KiB
Plaintext
---
|
|
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.
|