scoreodonto.com/documentação/PENDENCIAS.md

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 os bancos DEV (dev parar de usar o banco de produção)

Estratégia decidida + plano completo em BANCO-DEV-ESTRATEGIA.md: um único container postgis/postgis na VPS4 (rootless) com *_ref (template da VPS3) + *_dev. Resolve scoreodonto, RX e subdomínio (e futuros) numa instância só. O texto abaixo é o contexto original.

Problema: dev (VPS4) e produção (VPS1) apontam para o mesmo banco na VPS3 (scoreodonto, dental_images, subdominio). Qualquer teste em dev 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:<senha>@10.99.0.3:5432/scoreodonto_dev" --no-owner /caminho/scoreodonto_*.dump (ou via container: docker run --rm -v <dump>:/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, :<commit>, :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.