4.5 KiB
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
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
Fluxo de Git
Repositório hospedado em Gitea (git.falehandix.com.br). Commits/push do dia a dia vão para a branch
developer, nunca direto para main — o merge para main é feito manualmente pelo Matheus via PR no
próprio Gitea. Só empurrar para main diretamente se pedido explicitamente.
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
anyimplícito. - Toda query SQL parametrizada; nenhuma concatenação de string com input do usuário.
- Dinheiro sempre
NUMERICno banco /string-decimal ou biblioteca decimal no código — nuncafloat/Numberpara 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.
.envnunca commitado (.gitignorejá 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).