fix(ci): COMPOSE_PROJECT_NAME no build (carimbo correto) + deploy automático em tags

- build: fixa COMPOSE_PROJECT_NAME=scoreodontocom (imagem buildada batia com nome errado no tag/push → carimbo da Etapa 3 vazava)
- novo job deploy: só em tags v*, SSH VPS4->VPS1 roda deploy-prod.sh (push na main não deploya)
- deploy.md: Metade B + roadmap Etapa 6 = FEITO

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

.gitea/workflows/build.yml

@@ -32,6 +32,9 @@ jobs:
 
       - name: Build (compose, com carimbo de versão)
         env:
+          # Fixa o nome do projeto p/ a imagem buildada bater com o passo de tag
+          # (em modo host o diretório do checkout muda o project name por padrão).
+          COMPOSE_PROJECT_NAME: scoreodontocom
           APP_VERSION: ${{ steps.vars.outputs.version }}
           GIT_COMMIT: ${{ steps.vars.outputs.commit }}
           BUILD_TIME: ${{ steps.vars.outputs.build_time }}
@@ -63,4 +66,26 @@ jobs:
           echo "Imagens publicadas:"
           echo "  git.clube67.com/ruicesar/scoreodonto-backend:${{ steps.vars.outputs.version }}"
           echo "  git.clube67.com/ruicesar/scoreodonto-frontend:${{ steps.vars.outputs.version }}"
-          echo "Deploy NÃO foi executado (Etapa 6 trata disso)."
+          echo "Deploy só acontece em TAG (job deploy)."
+
+  # Deploy automático SÓ em tags vX.Y.Z (a tag = 'aprovado para produção').
+  # Push na main NÃO deploya — só builda. Etapa 6.
+  deploy:
+    needs: build
+    if: startsWith(github.ref, 'refs/tags/v')
+    runs-on: self-hosted
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Promover a tag para produção (VPS1)
+        run: |
+          set -e
+          TAG="${GITHUB_REF_NAME}"
+          echo "Promovendo $TAG para a produção (VPS1)..."
+          # Garante que o mecanismo de deploy está atualizado na VPS1
+          scp -o StrictHostKeyChecking=accept-new \
+            docker-compose.prod.yml deploy-prod.sh \
+            deploy@10.99.0.1:/home/deploy/stack/scoreodonto.com/
+          ssh -o StrictHostKeyChecking=accept-new deploy@10.99.0.1 \
+            "/home/deploy/stack/scoreodonto.com/deploy-prod.sh $TAG"

documentação/deploy.md

@@ -47,12 +47,13 @@
 
 > **Implementado em 16/jun/2026.** Workflow: `.gitea/workflows/build.yml`. Runner: `vps4-builder` (act_runner 0.6.1, **modo host** com Docker, serviço systemd `act_runner` na VPS4, label `self-hosted`). Login no registry usa o secret `REGISTRY_TOKEN` se presente, senão a credencial do host. Validado: push na main → build → `scoreodonto-{backend,frontend}:v1.0.13`/`:<commit>`/`:latest` publicados.
 
-### Metade B — Entrega por tag (tag → produção)  🔜
+### Metade B — Entrega por tag (tag → produção)  ✅ FEITO
 1. Quando uma versão está aprovada, cria-se uma **tag semântica**: `git tag v1.0.15 && git push origin v1.0.15`.
-2. A CI marca a imagem correspondente como `:v1.0.15` no registry (promoção do artefato já testado — sem rebuild).
-3. A VPS1 recebe o gatilho de entrega (job de deploy / acionamento manual aprovado) e roda:
-   `docker compose pull && docker compose up -d` apontando para `:v1.0.15`.
-4. A versão visível (rodapé/endpoint) confirma `v1.0.15` no ar.
+2. A CI builda e publica a imagem `:v1.0.15` no registry **e** o job `deploy` (só em tags `v*`) promove para a VPS1.
+3. Na VPS1, o `deploy-prod.sh <tag>` faz `docker compose pull` + `up -d --no-build` apontando para a imagem da tag.
+4. A versão visível (rodapé/endpoint `/api/version`) confirma a tag no ar com `environment: PROD`.
+
+> **Implementado em 16/jun/2026.** `docker-compose.prod.yml` (imagens do registry, sem build) + `deploy-prod.sh <tag>` (na VPS1) + job `deploy` no workflow (SSH VPS4→VPS1, só em tags). **Push na main NÃO deploya — só tags.** Rollback: `deploy-prod.sh <tag-anterior>`. Validado: v1.0.13 promovida e confirmada (`V1.0.13 · fc0d65f · PROD`).
 
 ---
 
@@ -97,6 +98,6 @@ Visível no **rodapé** da aplicação, em um **endpoint de diagnóstico** (ex.:
 | 3 | Versionamento visível (rodapé + endpoint + log) | ✅ |
 | 4 | Registry Docker privado na VPS3 | ✅ (Gitea Container Registry — ver `REGISTRY.md`) |
 | 5 | Pipeline de build no Gitea (push → imagem → registry), **sem deploy** | ✅ (`.gitea/workflows/build.yml` + runner `vps4-builder`) |
-| 6 | Deploy por TAG (`vX.Y.Z` → produção na VPS1) + rollback por imagem | 🔜 |
+| 6 | Deploy por TAG (`vX.Y.Z` → produção na VPS1) + rollback por imagem | ✅ (`deploy-prod.sh` + job `deploy` em tags) |
 
 Quando as Etapas 3–6 estiverem prontas, este documento deixa de ter marcações 🔜 e passa a descrever o fluxo corrente.