Bootstrap EDEN: Fase 0 (arquitetura) e Fase 1 (monorepo + infra)

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>

docs/assumptions.md

@@ -0,0 +1,13 @@
+# 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) |