Merge pull request 'feat(database): migration de seed com os 7 templates reais de documento' (#3) from developer into main

Reviewed-on: #3

docs/progress.md

@@ -971,3 +971,40 @@ anteriores desta sessão — desativados via `UPDATE document_templates SET acti
 usado antes). Restaram ~9 templates de teste manual mais antigos (`client_test_contract`, `live_test_*`,
 `smoke_*`, `teste_web_final` etc.) que não seguem o prefixo `qa_test_` automatizado — não mexidos, por
 poderem ser exploração manual do próprio usuário.
+
+---
+
+## Os 7 templates viram parte do código (migration de seed)
+
+Data: 2026-09-19. Usuário pediu pra embutir os 7 templates importados na leva anterior no próprio código,
+pra que uma máquina nova (VM de pré-produção) já nasça com eles, sem precisar rodar o script de importação
+manualmente de novo.
+
+Padrão já usado neste repo pra dado de catálogo/referência é seed **dentro de uma migration** (`INSERT ...
+ON CONFLICT DO NOTHING`, ver `1788457368744_fiscal.cjs`/`fiscal_operation_nature` e
+`1788430575858_baseline-schema.cjs`/`applications`/`roles`) — não um serviço à parte. Nova migration
+`packages/database/migrations/1789862600000_seed-document-templates.cjs` segue o mesmo padrão, com os 7
+JSONs (key/name/doc_group/editor_content/html_content/css_content) copiados em
+`document-template-seeds/*.json` ao lado dela. Idempotente por `key`: nunca sobrescreve um template já
+existente (ex.: se alguém já editou manualmente).
+
+Único `up`/`down` assíncrono desta pasta de migrations (as outras usam `pgm.sql` síncrono) — precisa do
+`id` gerado pelo INSERT do template antes de inserir a versão, e do `id` da versão antes de apontar
+`current_version_id` de volta, então usa `pgm.db.query` parametrizado em vez de `pgm.sql`.
+
+**Achado real, corrigido no caminho**: o `html_content` do export original vinha **vazio** pra 4 dos 7
+templates (`client_cession_term`/`client_portability_term`/`client_software_contract`/`client_stfc_term`)
+— só os 3 `reseller_*` tinham. Não afeta geração real nem o editor (ambos leem `editor_content` direto),
+só deixaria o card "Preview da versão publicada" vazio pra esses 4 numa instalação nova. Corrigido
+recalculando o `html_content` desses 4 offline com o próprio `renderToHtml` (o mesmo já testado nesta
+sessão, via `apps/api/dist/documents/editor-content-renderer.js` compilado) antes de gravar os JSONs de
+seed — não precisou mudar nada no motor em si.
+
+### Verificação
+Testado contra banco **totalmente vazio** (não só o de desenvolvimento, que já tinha os 7 da importação
+manual anterior): criado `eden_migration_test` no mesmo Postgres, rodado `node-pg-migrate up` do zero
+(todas as migrations, não só esta) — os 7 templates nasceram publicados, com `editor_content` e
+`html_content` corretos (conferido via query direta: `jsonb_array_length`/`length(html_content)` > 0 para
+os 7). Banco de teste apagado depois. `pnpm --filter @eden/database typecheck` e suíte da API
+125/125 sem regressão. Runbook (`docs/runbooks/setup-vm-pre-producao.md`) atualizado avisando que o passo
+de migrations já traz os templates.

docs/runbooks/setup-vm-pre-producao.md

@@ -0,0 +1,92 @@
+# Setup de uma nova VM (pré-produção)
+
+Passo a passo mínimo para subir o EDEN do zero numa VM nova. Ver `docs/adr/0002-container-topology.md`
+para o porquê da topologia (Postgres isolado, 1 container por app).
+
+## 1. Requisitos da VM
+
+- Linux (Debian/Ubuntu), 4 vCPU / 8GB RAM como piso razoável (Chromium headless para PDF consome memória).
+- Docker Engine + plugin `docker compose` instalados.
+- Git.
+- Portas liberadas no firewall: só as que forem expostas publicamente (ver passo 5) — nunca a porta do
+  Postgres.
+
+```bash
+curl -fsSL https://get.docker.com | sh
+sudo usermod -aG docker $USER   # relogar depois disso
+```
+
+## 2. Clonar o repositório
+
+```bash
+git clone https://git.falehandix.com.br/Matheus/eden.git /opt/eden
+cd /opt/eden
+git checkout main   # pré-produção valida o que já foi mergeado — não a branch developer
+```
+
+## 3. Configurar o `.env`
+
+```bash
+cp .env.example .env
+```
+
+Preencher no `.env` (nunca commitar este arquivo):
+
+- `EDEN_DATABASE_PASSWORD` / ajustar `DATABASE_URL` com a mesma senha.
+- `JWT_SIGNING_SECRET` — `openssl rand -hex 48` (segredo próprio desta VM, nunca reaproveitar o de outro ambiente).
+- `SIGNATURE_OTP_SECRET` — `openssl rand -hex 32`.
+- `EDEN_FIELD_ENCRYPTION_KEY` — `openssl rand -hex 32`.
+- `EDEN_SUPERADMIN_EMAIL` / `EDEN_SUPERADMIN_PASSWORD` — só usado para criar o primeiro usuário se a
+  tabela `users` estiver vazia.
+- `S3_*` — credenciais do MinIO bundled (`openssl rand -hex 12`/`openssl rand -hex 24` para user/senha) ou
+  de um S3 real.
+- `SMTP_*` — se já tiver um provedor de e-mail pra este ambiente.
+- `PUBLIC_BASE_URL` — domínio público desta VM (usado em links de e-mail).
+- Portas (`EDEN_API_PORT`/`EDEN_CORE_PORT`/`EDEN_PARCEIROS_PORT`/`EDEN_ASSINANTE_PORT`) — só mudar se for
+  rodar mais de uma instância na mesma máquina.
+
+## 4. Subir os containers
+
+```bash
+docker compose --env-file .env up -d
+```
+
+Sobe Postgres, MinIO, API, worker e as 3 apps web. Cada serviço tem healthcheck — conferir com:
+
+```bash
+docker compose --env-file .env ps
+```
+
+## 5. Rodar as migrations
+
+A imagem do `eden-api` carrega o monorepo inteiro (ver `infra/docker/Dockerfile.node`), então dá pra
+rodar direto de dentro do container — `DATABASE_URL` já está no ambiente dele:
+
+```bash
+docker compose --env-file .env exec eden-api pnpm --filter @eden/database exec node-pg-migrate up
+```
+
+Isso já cria e publica os 7 templates de documento reais (Contrato de Software, Termo de Cessão, Termo
+de Portabilidade, Termo de Contratação STFC, Contrato Canal Finder, Contrato Canal Recorrente, Termo de
+Adesão) — vêm junto com as migrations (`1789862600000_seed-document-templates.cjs`), não precisa reimportar
+manualmente numa VM nova.
+
+(Ou, se tiver Node 22 + pnpm instalados na própria VM, fora de Docker: `pnpm install && pnpm db:migrate`,
+com `DATABASE_URL` apontando pra porta mapeada do Postgres no host.)
+
+## 6. Confirmar o primeiro acesso
+
+```bash
+curl -X POST http://localhost:${EDEN_API_PORT:-8080}/api/v1/auth/login \
+  -H "Content-Type: application/json" \
+  -d "{\"email\":\"$EDEN_SUPERADMIN_EMAIL\",\"password\":\"$EDEN_SUPERADMIN_PASSWORD\",\"applicationKey\":\"core\"}"
+```
+
+Deve devolver um `accessToken`. Depois logar normalmente em `http://<host>:${EDEN_CORE_PORT}`.
+
+## 7. Proxy reverso / domínio (se for expor publicamente)
+
+- Cada app tem um domínio próprio (core/parceiros/assinante); a API **não** tem domínio público — o proxy
+  na frente de cada domínio deve rotear `/api/*` internamente para `eden-api:8080` na rede docker
+  (`eden_net`), nunca expor a API direto.
+- Nunca expor a porta do Postgres (`EDEN_POSTGRES_DEV_PORT`) fora da rede interna em pré-produção.

packages/database/migrations/1789862600000_seed-document-templates.cjs

@@ -0,0 +1,89 @@
+/**
+ * Semeia os 7 templates reais de documento herdados do OrçaFácil legado
+ * (Contrato de Software, Termo de Cessão, Termo de Portabilidade, Termo de
+ * Contratação STFC, Contrato Canal Finder, Contrato Canal Recorrente, Termo
+ * de Adesão) — eden.md §1.1: "Registros existentes hoje (query real ao
+ * banco): 7 templates". A migration `1788468521075_documents.cjs` que criou
+ * o schema deixou essas 7 linhas explicitamente de fora ("Handix production
+ * data to be migrada later, not schema") — esta migration é esse "depois":
+ * assim toda máquina nova (`pnpm db:migrate` / `docker compose ... exec
+ * eden-api pnpm --filter @eden/database exec node-pg-migrate up`, ver
+ * docs/runbooks/setup-vm-pre-producao.md) já nasce com os 7 templates
+ * publicados, sem precisar reimportar manualmente.
+ *
+ * `editor_content`/`html_content` de cada um vêm de
+ * `document-template-seeds/<key>.json` ao lado deste arquivo — cópia
+ * exata da versão PUBLICADA fornecida pelo usuário (export do sistema
+ * legado, `/home/handix/document_templates_export.zip`), o mesmo conteúdo
+ * já testado ao vivo nesta sessão (renderiza no editor Tiptap, gera PDF via
+ * Chromium, inclusive o nó `conditional` do Termo de Contratação STFC).
+ * `html_content` já vem pré-renderizado (não precisa rodar
+ * `renderEditorContentToHtml` aqui — este pacote não pode depender do
+ * código do apps/api).
+ *
+ * Idempotente via `ON CONFLICT (key) DO NOTHING` (mesmo padrão de
+ * `fiscal_operation_nature`/`applications`/`roles` — ver
+ * 1788457368744_fiscal.cjs e 1788430575858_baseline-schema.cjs): se o
+ * template já existe (por exemplo, alguém já editou manualmente uma versão
+ * mais nova), esta migration NUNCA sobrescreve — só cria o que falta.
+ *
+ * Único par de `up`/`down` assíncrono desta pasta (as outras migrations
+ * usam `pgm.sql` síncrono) — precisa do `id` gerado pelo INSERT do
+ * template antes de inserir a versão (e o `id` da versão antes de apontar
+ * `current_version_id` de volta), então usa `pgm.db.query` (parametrizado,
+ * `$1`/`$2`/...) em vez de `pgm.sql` (que só monta SQL, não devolve linhas
+ * pro código da migration decidir o próximo passo).
+ */
+const fs = require("fs");
+const path = require("path");
+
+const SEED_DIR = path.join(__dirname, "document-template-seeds");
+const SEED_FILES = [
+  "client_software_contract.json",
+  "client_cession_term.json",
+  "client_portability_term.json",
+  "client_stfc_term.json",
+  "reseller_contract_finder.json",
+  "reseller_contract_recorrente.json",
+  "reseller_adhesion_term.json",
+];
+
+function loadSeeds() {
+  return SEED_FILES.map((file) => JSON.parse(fs.readFileSync(path.join(SEED_DIR, file), "utf8")));
+}
+
+exports.shorthands = undefined;
+
+exports.up = async (pgm) => {
+  for (const seed of loadSeeds()) {
+    const { rows: templateRows } = await pgm.db.query(
+      `INSERT INTO document_templates (key, name, doc_group)
+       VALUES ($1, $2, $3)
+       ON CONFLICT (key) DO NOTHING
+       RETURNING id`,
+      [seed.key, seed.name, seed.doc_group],
+    );
+    const template = templateRows[0];
+    if (!template) continue; // já existe — nunca sobrescreve.
+
+    const { rows: versionRows } = await pgm.db.query(
+      `INSERT INTO document_template_versions
+         (template_id, version, status, editor_content, html_content, css_content, page_config, published_at)
+       VALUES ($1, 1, 'published', $2::jsonb, $3, $4, '{}'::jsonb, now())
+       RETURNING id`,
+      [template.id, JSON.stringify(seed.editor_content), seed.html_content ?? "", seed.css_content ?? null],
+    );
+    const version = versionRows[0];
+
+    await pgm.db.query(`UPDATE document_templates SET current_version_id = $1 WHERE id = $2`, [
+      version.id,
+      template.id,
+    ]);
+  }
+};
+
+exports.down = async (pgm) => {
+  const keys = loadSeeds().map((seed) => seed.key);
+  // ON DELETE CASCADE em document_template_versions.template_id cuida da versão junto.
+  await pgm.db.query(`DELETE FROM document_templates WHERE key = ANY($1::text[])`, [keys]);
+};