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>
2.2 KiB
2.2 KiB
EDEN — Registro de Assunções (não bloqueantes)
Conforme Master Prompt §2.3 — cada item aqui é uma decisão tomada para não bloquear o progresso, com a alternativa mais segura/coerente escolhida. Revisar com o operador quando possível.
| # | Assunção | Alternativa escolhida | Revisitar quando |
|---|---|---|---|
| 1 | Retenção/eliminação de dados pessoais (LGPD) ainda não tem política definida pela Handix | Modelar coluna/config de retenção desde já no schema de Identity/Customer 360, mas manter processo de eliminação manual/auditado até jurídico definir política | Início da Fase 2 (Customer 360) |
| 2 | Ambiente de execução não tinha Docker/Node/pnpm instalados | Provisionar via gerenciador de pacote do SO no início da Fase 1, versão LTS atual do Node | Início da Fase 1 |
| 3 | Portas dos containers das 3 apps + API | Definidas via .env (EDEN_CORE_PORT=3001, EDEN_PARCEIROS_PORT=3002, EDEN_ASSINANTE_PORT=3003, EDEN_API_PORT=8080), não hardcoded — ver ADR-0002 |
Se o operador já tiver portas reservadas em uso, ajustar .env |
| 4 | Projeto não estava sob controle de versão Git | Assumir que Git será iniciado no começo da Fase 1 (monorepo) — não iniciar prematuramente na Fase 0 para não versionar tema_do_Eden.zip (360MB) sem .gitignore pronto |
Início da Fase 1 |
| 5 | super_admin inicial do EDEN |
Seguir o padrão do legado (promoção via seed/migration com e-mail vindo de env EDEN_SUPERADMIN_EMAIL, nunca hardcoded no código) — Master Prompt §2.2 já define isso |
Bootstrap da Fase 1 |
| 6 | Overtime multiplier (Art. 59 CLT) no módulo de ponto | Legado tem os campos (overtime_multiplier, apply_multiplier_to_time_bank) mas não os aplica no motor de cálculo — EDEN preserva os campos como metadado e registra decisão explícita (implementar ou não a multiplicação) só quando a Fase 9 (RH/Ponto) for iniciada |
Início da Fase 9 |
| 7 | Extensão Postgres btree_gist para exclusão de conflito de horário (Agenda) |
Legado evita a extensão deliberadamente (nunca usada em produção) e resolve conflito via transação + SELECT ... FOR UPDATE. EDEN preserva essa escolha por padrão — reavaliar EXCLUDE/GiST só se performance exigir |
Início da Fase 9 (Agenda) |