scoreodonto.com/documentação/VERDADE-HOJE.md

Qual é a verdade hoje? — Auditoria de infra ScoreOdonto

Resposta direta às 6 perguntas essenciais, verificada em 16/jun/2026. Sem teoria, sem fantasma. Detalhes em arquitetura.md (real), deploy.md (alvo) e DEPLOY-PRODUCAO.md (runbook).

---

1. Onde está o código?

• Fonte da verdade: Gitea na VPS3, repo ruicesar/scoreodonto.com (ssh://git@10.99.0.3/ruicesar/scoreodonto.com.git).
• Cópia de trabalho (dev): VPS4 em /home/deploy/stack/scoreodonto.com (onde se programa).
• Cópia de produção: VPS1 em /home/deploy/stack/scoreodonto.com (HEAD verificado: 19dbbae).
• Documentação: centralizada em scoreodonto.com/documentação/ (este diretório).

2. Onde está o banco?

• PostgreSQL no host da VPS3 (10.99.0.3:5432), banco scoreodonto, usuário scoreodonto_user.
• ⚠️ DEV e PROD usam o MESMO banco. Não há isolamento. Backup (pg_dump -Fc) é a única rede de segurança.
• Cache DragonflyDB (10.99.0.3:6379, índice /1). Mensageria NATS (:4222) e Temporal (:7233).

3. Onde estão os containers?

• Produção (VPS1, docker rootless unix:///run/user/1000/docker.sock):
  • scoreodontocom-scoreodonto-frontend-1 — Up ~5 dias (imagem :latest buildada na própria VPS1).
  • scoreodontocom-scoreodonto-backend-1 — Up ~5 dias (:8018).
  • traefik-traefik-1 — borda TLS (Up ~13 dias). Também: rx, newwhats, subdominio, mercado.
• Dev (VPS4, docker root /var/run/docker.sock):
  • scoreodontocom-nginx-1 (0.0.0.0:8020->80, alvo do Traefik para dev.), scoreodonto-frontend-1 (:3013), scoreodonto-backend-1 (:8018).
• Roteamento: Traefik na VPS1 → scoreodonto.com (containers locais) e dev.scoreodonto.com → http://10.99.0.4:8020.

4. Quem faz deploy?

• Hoje: ninguém automático. Não há listener nem webhook ativo (o antigo listener-scoreodonto.js porta 9002 foi deletado; serviço desligado). git push NÃO dispara deploy.
• O deploy é manual: na VPS1, git pull + docker compose build + docker compose up -d (passo a passo em DEPLOY-PRODUCAO.md).
• Ou seja: a produção builda a si mesma hoje (o oposto do alvo "prod não builda", que depende do registry — Etapas 4–6).

5. Como versiona?

• APP_VERSION em frontend/constants.ts (dev hoje V1.0.13), incrementado por update-version.js (patch++).
• ⚠️ Bump é manual — nada chama update-version.js no build (npm run build = só vite build). Por isso a versão fica parada se ninguém rodar o script.
• ✅ Versão agora é visível (Etapa 3, 16/jun): rodapé do Sidebar + endpoint GET /api/version + log de boot [VERSION] …. Carimbo (commit/data/ambiente) injetado no build via build args. No ar em DEV; produção passa a exibir após o próximo deploy.

6. Como volta uma versão (rollback)?

• Hoje: na VPS1, git checkout <commit-bom> + docker compose build + up -d (rebuilda a versão anterior; imagens são :latest, sem tag por versão).
• Seguro porque as migrações são aditivas (voltar código não quebra o schema). Restaurar dump só em caso extremo.
• Alvo (Etapa 6): rollback = docker compose pull da tag anterior no registry, sem rebuild.

---

Veredito de uma linha

O código está salvo no Gitea (VPS3) e roda em containers na VPS1 (prod) e VPS4 (dev), ambos no mesmo banco da VPS3. Não há CI/CD automático: deploy e rollback são manuais via git pull + docker compose build/up na VPS1, e a versão é invisível e bumpada à mão — as duas dores que as Etapas 3–6 vão eliminar.