Matheus (Handix)
44510bd019
Fase 0 — descoberta e arquitetura:
- Inventário do projeto, glossário de domínio, arquitetura com bounded
contexts e topologia de containers, threat model inicial.
- 12 ADRs cobrindo modular monolith, topologia de containers (Postgres
isolado + eden-core/parceiros/assinante em containers e portas
distintos), auth/sessões, modelo de permissões, criptografia/segredos,
contrato first-class, stock ledger, separação billing/finance/fiscal,
outbox transacional, adapters SaperX e Focus NFe, e identidade
compartilhada entre as 3 apps.
- 14 subagentes e 7 skills especializados por domínio em .claude/.
- Hooks de segurança (PreToolUse/PostToolUse/Stop) testados via pipe.
Fase 1 — plataforma (em andamento):
- Monorepo pnpm workspaces + Turborepo: apps/{api,worker,core-web,
reseller-web,subscriber-web} + 9 packages compartilhados.
- apps/api: NestJS mínimo com /health/live e /health/ready (checando
Postgres real via @eden/database).
- 3 frontends Vite + React + TypeScript + Tailwind, com o favicon
oficial do EDEN.
- packages/database: migration baseline (node-pg-migrate) criando
roles/role_permissions/applications/users/user_applications/sessions/
audit_log — audit log append-only com hash-chain, testado ao vivo
(UPDATE/DELETE bloqueados pelo trigger).
- compose.yaml implementando a topologia da ADR-0002, validada de ponta
a ponta: os 6 containers sobem e ficam saudáveis com um único
`docker compose up`.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
75 lines
4.2 KiB
Markdown
75 lines
4.2 KiB
Markdown
# EDEN — CLAUDE.md
|
|
|
|
ERP Handix. Substitui o legado OrçaFácil. Três apps web (Core/Parceiros/Assinante) sobre um backend/API/identidade únicos. Ver `EDEN_MASTER_PROMPT_CLAUDE.md` para a missão e regras completas, `eden.md` para as regras de negócio do legado — não duplicar o conteúdo desses arquivos aqui.
|
|
|
|
## Stack
|
|
|
|
Node 22 LTS · pnpm workspaces + Turborepo · TypeScript strict · NestJS (API) · React + Vite + Tailwind (frontends) · PostgreSQL 18 · Docker Compose.
|
|
|
|
## Comandos principais
|
|
|
|
```bash
|
|
pnpm install # instala tudo no monorepo
|
|
pnpm dev # sobe todos os apps em modo dev (turbo)
|
|
pnpm build # build de todo o monorepo
|
|
pnpm lint / pnpm typecheck / pnpm test
|
|
|
|
pnpm db:migrate # aplica migrations pendentes (packages/database)
|
|
pnpm db:migrate:down # reverte a última migration
|
|
pnpm db:migrate:create <nome># cria uma nova migration
|
|
|
|
docker compose --env-file .env up -d # sobe Postgres + API + worker + as 3 apps
|
|
docker compose --env-file .env up -d eden-postgres # só o banco, para rodar API/apps localmente fora do container
|
|
```
|
|
|
|
## Estrutura do monorepo
|
|
|
|
```
|
|
apps/
|
|
api/ NestJS — API principal, único serviço com credencial de banco
|
|
worker/ jobs assíncronos (BullMQ, quando Redis existir)
|
|
core-web/ EDEN Core (ERP interno)
|
|
reseller-web/ EDEN Parceiros
|
|
subscriber-web/ EDEN Assinante
|
|
packages/
|
|
database/ migrations SQL versionadas (node-pg-migrate) + client de query
|
|
contracts/ DTOs/schemas/eventos compartilhados entre apps
|
|
ui/ Design System (derivado do tema DreamsERP)
|
|
auth/ SDK de auth client-side comum às 3 apps
|
|
observability/ logging estruturado, correlation id
|
|
config/ schema/validação de env compartilhado
|
|
testing/ helpers de teste compartilhados
|
|
integrations/ adapters Focus NFe, SaperX, Control iD, S3, SMTP
|
|
domain-shared/ tipos/constantes de domínio compartilhados
|
|
infra/docker/ Dockerfiles + compose.yaml (topologia: ver docs/adr/0002-container-topology.md)
|
|
docs/ arquitetura, ADRs, threat model, plano de implementação
|
|
.claude/ agentes, skills e hooks especializados do projeto
|
|
```
|
|
|
|
## Convenções de código
|
|
|
|
- TypeScript strict em tudo; sem `any` implícito.
|
|
- Toda query SQL parametrizada; nenhuma concatenação de string com input do usuário.
|
|
- Dinheiro sempre `NUMERIC` no banco / `string`-decimal ou biblioteca decimal no código — nunca `float`/`Number` para valores monetários armazenados.
|
|
- IDs técnicos em UUID; código humano sequencial só quando o domínio precisar (ex.: `client_code`), nunca reaproveitando o UUID.
|
|
- Toda tabela de agregado relevante tem `created_at/updated_at/created_by/updated_by`.
|
|
- Nenhuma decisão de autorização confia em campo vindo do cliente (`role`, `reseller_id`, `customer_id`, `legal_entity_id`) — sempre resolvida a partir da sessão no servidor.
|
|
|
|
## Regras de segurança (resumo — detalhe em `docs/security/threat-model.md`)
|
|
|
|
- Segredo nunca em git/log/doc/fixture. `.env` nunca commitado (`.gitignore` já cobre).
|
|
- Campo sensível classificado explicitamente: hash unidirecional, criptografia reversível (AES-256-GCM, chave versionada) ou plano com controle de acesso — nunca "criptografar tudo" sem critério.
|
|
- Toda rota nova: autenticação + autorização server-side + validação de input, mínimo.
|
|
|
|
## Definição de pronto
|
|
|
|
Ver Master Prompt §20. Resumo: regra de negócio documentada, migration consistente, backend + authz + frontend implementados, estados loading/error/empty tratados, testes unit/integration (+E2E se fluxo crítico), OpenAPI atualizado, sem segredo/TODO crítico, code-reviewer e QA executados, documentação atualizada.
|
|
|
|
## Referências
|
|
|
|
- `EDEN_MASTER_PROMPT_CLAUDE.md` — missão, regras operacionais, arquitetura alvo completa.
|
|
- `eden.md` — especificação funcional do legado OrçaFácil (fonte das regras de negócio).
|
|
- `docs/architecture.md`, `docs/adr/`, `docs/security/threat-model.md`, `docs/implementation-plan.md`, `docs/progress.md`.
|
|
- `.claude/agents/` — subagentes especializados por domínio.
|
|
- `.claude/skills/` — skills de domínio (carregadas sob demanda).
|