docs: atualiza auditoria e runbook para o fluxo CI/CD por tag (Etapa 6 concluída)

- VERDADE-HOJE.md: deploy/rollback/containers/versão refletem CI/CD por tag + registry
- DEPLOY-PRODUCAO.md: fluxo canônico = deploy por tag; manual vira fallback

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

documentação/DEPLOY-PRODUCAO.md

@@ -1,8 +1,20 @@
-# DEPLOY-PRODUCAO — Runbook operacional (estado de HOJE)
+# DEPLOY-PRODUCAO — Runbook operacional
 
-> 🛑 **LEIA PRIMEIRO.** Procedimento **real e executável hoje**, passo a passo, sem adivinhação.
-> Reflete o mecanismo atual: **a produção (VPS1) builda a si mesma** via `git pull` + `docker compose build` + `up -d`.
-> O fluxo-alvo (registry + deploy por tag, prod sem build) está em `deploy.md` e ainda não existe. A realidade da infra está em `arquitetura.md`.
+> ✅ **FLUXO CANÔNICO HOJE: deploy por TAG (CI/CD).** Para subir uma versão à produção:
+> ```
+> # na VPS4, com a versão validada em dev:
+> node update-version.js && git add -A && git commit -m "..." && git push origin main
+> git tag v1.0.XX && git push origin v1.0.XX     # ← a TAG dispara build + deploy automático na VPS1
+> ```
+> A CI builda a imagem versionada, publica no registry e promove para a VPS1 (`deploy-prod.sh`). Confirme em `https://scoreodonto.com/api/version`.
+> **Rollback:** na VPS1, `./deploy-prod.sh <tag-anterior>`. Detalhes em `deploy.md` e `REGISTRY.md`.
+>
+> ⬇️ O passo a passo manual abaixo continua válido como **fallback** (deploy sem a CI).
+
+---
+
+> 🛑 Procedimento manual (fallback), passo a passo, sem adivinhação.
+> Reflete o mecanismo de build local. A realidade da infra está em `arquitetura.md`; o fluxo por tag em `deploy.md`.
 >
 > ⚠️ **Regra de ouro:** antes de qualquer build/deploy/push, confirme com o operador **DEV ou PRODUÇÃO**.
 > `dev.scoreodonto.com` = VPS4 (descartável, mas **mesmo banco** da prod). `scoreodonto.com` = VPS1 (real).

documentação/VERDADE-HOJE.md

@@ -18,29 +18,28 @@
 
 ### 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`).
+  - `scoreodontocom-scoreodonto-frontend-1` — roda **imagem versionada do registry** (`git.clube67.com/ruicesar/scoreodonto-frontend:<tag>`), promovida por deploy-por-tag. Produção **não builda** mais.
+  - `scoreodontocom-scoreodonto-backend-1` — idem (`: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).
+- **CI/CD por tag (Gitea Actions).** `git tag vX.Y.Z && git push origin vX.Y.Z` → o runner `vps4-builder` builda as imagens, publica no registry e o job `deploy` promove para a VPS1 (`deploy-prod.sh`). **Push na main NÃO deploya — só builda.**
+- **Produção não builda mais:** consome a **imagem versionada** do registry (`docker compose -f docker-compose.yml -f docker-compose.prod.yml pull && up -d --no-build`).
+- Deploy manual também disponível: na VPS1, `./deploy-prod.sh <tag>`. Ver `deploy.md` e `REGISTRY.md`.
 
 ### 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.**
+- ✅ **Versão visível** (Etapa 3): rodapé do Sidebar + `GET /api/version` + log de boot `[VERSION] …`. Carimbo (versão/commit/data/ambiente) injetado no build. **No ar em DEV e em PRODUÇÃO** (prod hoje: `v1.0.14 · 081985c · PROD`).
 
 ### 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**.
+- **Por imagem, sem rebuild:** na VPS1, `./deploy-prod.sh <tag-anterior>` (ex.: `./deploy-prod.sh v1.0.13`) — puxa a imagem da tag anterior do registry e sobe. Minutos, sem recompilar.
+- Seguro porque as migrações são **aditivas** (voltar código não quebra o schema). Restaurar o dump (`/home/deploy/backups/`) só em caso extremo.
 
 ---
 
 ## 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.
+> O código está salvo no Gitea (VPS3) e roda em containers na VPS1 (prod) e VPS4 (dev), ambos no **mesmo banco** da VPS3. **CI/CD por tag ativo**: `git tag vX.Y.Z` → CI builda imagem → deploy automático na VPS1, com **versão visível** no rodapé/`/api/version` e **rollback por imagem** (`deploy-prod.sh <tag-anterior>`). Pendência estrutural restante: **isolar um banco `scoreodonto_dev`** (dev e prod ainda compartilham o banco).