From 96b857e40887bb9b7522a93cdc0fd941265059a9 Mon Sep 17 00:00:00 2001 From: VPS 4 Builder Date: Tue, 16 Jun 2026 11:08:59 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20backlog=20de=20pend=C3=AAncias=20(inclu?= =?UTF-8?q?i=20isolar=20scoreodonto=5Fdev)=20+=20valida=20CI=20rootless?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.8 --- documentação/PENDENCIAS.md | 74 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 documentação/PENDENCIAS.md diff --git a/documentação/PENDENCIAS.md b/documentação/PENDENCIAS.md new file mode 100644 index 0000000..1e627c3 --- /dev/null +++ b/documentação/PENDENCIAS.md @@ -0,0 +1,74 @@ +# Pendências & Tarefas a Fazer — ScoreOdonto + +> Backlog operacional/infra após as 6 etapas de CI/CD (16/jun/2026). Ordenado por prioridade. +> Contexto da infra em `arquitetura.md`; fluxo de deploy em `deploy.md`; verdade atual em `VERDADE-HOJE.md`. + +--- + +## 🔴 P0 — Estrutural + +### 1. Isolar o banco `scoreodonto_dev` (dev parar de usar o banco de produção) +**Problema:** dev (VPS4) e produção (VPS1) apontam para o **mesmo** banco `scoreodonto` na VPS3. Qualquer teste em `dev.scoreodonto.com` escreve no dado real. É a maior dívida estrutural restante. + +**Bloqueador descoberto (16/jun/2026):** o role `scoreodonto_user` **não pode criar banco** (`CREATEDB=false`, `SUPER=false`) e **não há shell na VPS3** (`deploy@10.99.0.3` recusa a chave). → Precisa de **ação do operador com acesso superuser** ao Postgres da VPS3 (usuário `postgres`), OU conceder a permissão: `ALTER ROLE scoreodonto_user CREATEDB;`. + +**Passos:** +1. **(operador/superuser na VPS3)** Criar o banco: + `CREATE DATABASE scoreodonto_dev OWNER scoreodonto_user;` +2. **Popular com cópia da produção** (dados realistas p/ dev): + - Já existe dump recente em `/home/deploy/backups/scoreodonto_*.dump` (VPS4, formato `-Fc`). + - Restaurar: `pg_restore -d "postgresql://scoreodonto_user:@10.99.0.3:5432/scoreodonto_dev" --no-owner /caminho/scoreodonto_*.dump` + (ou via container: `docker run --rm -v :/b.dump -e PGPASSWORD=… postgres:18 pg_restore -h 10.99.0.3 -U scoreodonto_user -d scoreodonto_dev --no-owner /b.dump`). +3. **Apontar SÓ o dev para `scoreodonto_dev`** (sem tocar na prod): + - No `docker-compose.yml`, parametrizar: `DATABASE_URL=…@10.99.0.3:5432/${SCOREODONTO_DB:-scoreodonto}?schema=public` (default mantém a prod intacta). + - Na VPS4, criar `.env` (gitignored, dev-only) com `SCOREODONTO_DB=scoreodonto_dev`. + - Rebuild + recreate do backend de dev. +4. **Verificar:** `dev.scoreodonto.com/api/version` sobe; conferir que escrita em dev cai em `scoreodonto_dev` e **não** em `scoreodonto` (contagens divergem após um teste). +5. **(privacidade)** Avaliar anonimizar dados sensíveis de pacientes no `scoreodonto_dev`. + +**Ganho:** dev deixa de poder corromper o dado de produção; fim da “única rede de segurança é o backup”. + +--- + +## 🟠 P1 — Segurança + +### 2. Rotacionar o token do Gitea exposto no chat +O token usado nos `docker login` (VPS4 e VPS1) e na descoberta foi colado no chat → comprometido. **Revogar no Gitea** (Configurações → Aplicações) e gerar um novo. Os logins já estão no keystore do Docker; só re-logar quando o token for trocado. + +### 3. Criar o secret `REGISTRY_TOKEN` no repo +Adicionar em `git.clube67.com` → repo → Settings → Actions → Secrets um token (escopo `write:package`/`read:package`). Hoje o workflow funciona com a credencial do host como fallback; o secret deixa o CI independente disso. + +### 4. Tirar credenciais em texto puro do `docker-compose.yml` +O `DATABASE_URL` e `DRAGONFLY_URL` têm **senha em texto puro** versionada no repo. Mover para `.env`/secrets (e idealmente rotacionar as senhas). Dívida de segurança pré-existente. + +--- + +## 🟡 P2 — Operacional / Cosmético + +### 5. Retenção/limpeza de imagens no registry +O registry vai acumular imagens (`:vX.Y.Z`, `:`, `:latest`) a cada deploy. Definir política de retenção (ex.: manter N últimas + releases) — a VPS3 tem disco finito. Avaliar limpeza automática. + +### 6. Limpar a árvore git suja da VPS1 +O repo em `/home/deploy/stack/scoreodonto.com` na VPS1 está **sujo** (vários `.md` e `.dockerignore` deletados, HEAD antigo `19dbbae`). Não afeta o deploy (que usa imagem), mas convém reconciliar/limpar para não confundir. + +### 7. Ruído de attestation no registry +O BuildKit publica manifests de *provenance/attestation* que aparecem como “tags” `sha256:…` no registry. Inócuo; desligar com `provenance=false`/`--provenance=false` no build se incomodar. + +### 8. Padronizar o case da versão (V vs v) +A CI mostra `v1.0.14` (minúsculo, por `tr 'V' 'v'`); builds manuais mostram `V1.0.14`. Cosmético — alinhar para um padrão único. + +### 9. Backup automatizado do banco +Hoje o `pg_dump` é manual (via container `postgres:18`). Agendar backup periódico do `scoreodonto` (e, após P0, do `scoreodonto_dev`) com retenção. Evolução: WAL archiving / PITR. + +--- + +## 🔵 Futuro (visão de produto — fora do escopo de infra) +Itens herdados do mapa de produto, ainda não implementados: +- **Score Professional** (motor de pontuação) — não existe. +- **Estoque**, **Teleatendimento**. +- Entidade formal **Pessoa × Empresa**. +- Monitoramento/observabilidade (Grafana já existe na stack — integrar métricas do ScoreOdonto). + +--- + +_Atualizar este arquivo conforme as pendências forem resolvidas. As 6 etapas de CI/CD (documentação, versão visível, registry, pipeline, deploy por tag) estão **concluídas** — ver `deploy.md`._