# rx.scoreodonto.com-client — Runbook do upgrade do build (corte para CI/tag)

> Como migrar o client da forma antiga (webhook 9004 → `deploy-client.sh` no push) para a nova
> (CI valida no push; **tag** builda com a versão da tag e publica). Plano geral: ver `plano-deploy.md`.
> **Regra crítica:** o `latest.yml` em `updates/` é o que **TODOS os clients nas clínicas** leem — um arquivo errado quebra o auto-update de todos. Por isso: backup + teste num Windows ANTES de publicar.

## Pré-requisitos
- Fase 1 (versão no tray) + Fase 2 (`.gitea/workflows/build.yml`) prontas (hoje no working tree, não commitadas).
- **Windows de teste** com o client instalado, para validar o auto-update.
- Gitea Actions habilitado no repo do client.
- SSH VPS4→VPS1 (o release usa `rsync`; já existe, o `deploy-client.sh` usa).
- ⚠️ Desligar o serviço systemd `webhook-rx-client.service` **pode exigir sudo** — confirmar o acesso antes.

## Ordem do corte (com janela de teste e rollback)

### 0. Backup (rede de rollback)
Na VPS1, copiar o `updates/` atual:
```
ssh deploy@10.99.0.1 'cp -a /home/deploy/stack/rx.scoreodonto.com/dental-server/updates \
  /home/deploy/stack/rx.scoreodonto.com/dental-server/updates.bak_$(date +%Y%m%d_%H%M)'
```

### 1. Cortar o gatilho antigo (senão push dispara o build antigo)
- `systemctl disable --now webhook-rx-client.service` (porta 9004).
- No Gitea (repo client → Settings → Webhooks): desabilitar o webhook que aponta para a `:9004`.
- Resultado: push no repo do client **não** dispara mais o `deploy-client.sh`.

### 2. Habilitar o CI + subir o pipeline
- Gitea → repo client → Settings → **Actions: habilitar**.
- `git add -A && git commit && git push origin main` (build.yml + index.js da Fase 1).
- O CI roda o job **build** (`electron-builder --publish never`) → confirma que **compila**. **Não publica**. Conferir CI verde.

### 3. Validar o `.exe` num Windows ANTES de publicar
- Pegar o `.exe` gerado pelo CI (artefato do runner / `dist/`) **ou** rodar o build na VPS4.
- Instalar num **Windows de teste**: app abre, **"Versão v…"** no tray, captura/envio do sensor funciona, conecta ao server.
- (Gate manual: só seguir para a tag se o `.exe` estiver ok — porque o passo 4 publica para todos.)

### 4. Primeira release pela tag
- Próxima versão (a atual é `1.3.8`): `git tag v1.3.9 && git push origin v1.3.9`.
- O CI job **release**: `npm version 1.3.9` → build → `rsync` do `.exe`/`latest.yml` para a VPS1 `updates/`.
- Conferir: `updates/latest.yml` = `1.3.9` e o `.exe` presente.

### 5. Validar o auto-update em campo (1 client monitorado)
- Num client de teste: "Verificar Atualizações" → detecta `1.3.9` → baixa → instala → reinicia → tray mostra **"Versão v1.3.9"**.
- Observar: sem erro de update, app reconecta, envio volta.

### 6. Rollback (se quebrar)
- Restaurar o backup: `rsync`/`cp` do `updates.bak_*/` de volta para `updates/` → no próximo check os clients voltam à versão anterior.
- O `index.js` já tem **anti-loop** de update (aborta após N tentativas) — ajuda se um `.exe` ruim foi instalado.

## Riscos a tratar (antes/durante)
- **Code signing** (SmartScreen): sem assinatura, o Windows alerta em **novas instalações** (não bloqueia o auto-update de quem já tem o app). Pendência antiga do RX.
- **Versão crescente**: a tag (`1.3.9`) tem que ser **> a atual** (`1.3.8`), senão o electron-updater não atualiza.
- **`latest.yml` único para todos** → o teste do passo 3 e o backup do passo 0 são obrigatórios.
- **systemd/sudo** para desligar o webhook (passo 1).

## Pós-corte (limpeza)
- O **bump manual** do `package.json` deixa de existir (versão = tag).
- O **`deploy-client.sh`** fica obsoleto (substituído pelo CI) → mover para `desuso/`.
- Atualizar `plano-deploy.md` marcando Fases 3/4 como ✅.