Merge pull request 'docs: documenta fluxo de git (push para developer, merge manual via Gitea)' (#1) from developer into main

Reviewed-on: #1

CLAUDE.md

@@ -22,6 +22,12 @@ docker compose --env-file .env up -d           # sobe Postgres + API + worker +
 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
 
 ```

docs/progress.md

@@ -971,40 +971,3 @@ 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

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

@@ -1,89 +0,0 @@
-/**
- * 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]);
-};