# 🦷 Arquitetura ScoreOdonto CRM (Multi-Tenant)

Este documento dita as regras exclusivas e as portas da arquitetura do **ScoreOdonto CRM**.
**Nunca** misture essas configurações com as do Clube67.

## 🚀 Stack Tecnológica e Portas de Rede

- **Frontend:** Next.js (React)
  - Porta de Produção/Dev: `3013`
- **Backend:** Node.js + Prisma ORM
  - Porta de Produção/Dev: `8018`
- **Banco de Dados (VPS 3):** PostgreSQL 18
  - Porta Padrão: `5432`
  - Banco de Dados Isolado: `scoreodonto`
- **Cache (VPS 3):** DragonflyDB
  - Porta Padrão: `6379`
  - Índice Isolado: `/1` (exclusivo para ScoreOdonto)
- **Proxy Reverso (VPS 1):** Nginx / Traefik
  - Domínio: `scoreodonto.com`

## 🔄 Fluxo de Deploy Contínuo e Versionamento (+1)
O webhook do ScoreOdonto deve rodar de forma isolada do NewWhats.
- **Webhook Listener Port (VPS 4):** `9002`
- O webhook escuta na porta 9002 e dispara o script de build/deploy exclusivo (`deploy-prod-scoreodonto.sh`).

### 📦 Regra Obrigatória de Incremento de Versão (Build Bump)
Para garantir que o histórico de deploys (`deploys.json`) e o contador de builds (`version.json`) avancem automaticamente a cada alteração no sistema, os Agentes SRE DEVEM OBRIGATORIAMENTE garantir que:

1. O script `update-version.js` esteja configurado na raiz do projeto ScoreOdonto.
2. No arquivo `frontend/package.json`, o comando de compilação DEVE ser estritamente configurado para rodar o versionador antes do build do framework:
   ```json
   "scripts": {
     "build": "node ../update-version.js && next build"
   }
   ```
> [!TIP]
> Sem a chamada `node ../update-version.js` antes do comando de build, o sistema de versionamento não fará a contagem e a versão exibida na interface ficará congelada.

### 🐳 Regra de Contexto Docker e Comportamento do Git
Para que o Docker consiga executar o script `update-version.js` (que fica na raiz) durante a compilação do frontend, os Agentes DEVEM OBRIGATORIAMENTE seguir esta arquitetura de container:

1. O **Build Context** no `docker-compose.yml` deve apontar para a raiz do projeto (`context: .`), e não apenas `./frontend`.
2. O `Dockerfile` do frontend deve copiar a raiz para `/app/` e definir `WORKDIR /app/frontend`.

> [!WARNING]
> **COMPORTAMENTO DE VERSIONAMENTO EM CONTAINER**
> Durante o `docker compose build`, o script `update-version.js` incrementa o contador e altera os arquivos estáticos **dentro do ambiente isolado do container**. Isso significa que a nova versão (ex: V1.0.4) aparecerá perfeitamente na interface web em produção.
> 
> Contudo, como a alteração ocorre dentro do container, os arquivos no repositório Git não são modificados. Para lançamentos de versões maiores fixadas (ex: `V1.1.0` ou `V2.0.0`), o desenvolvedor deve editar o arquivo base manualmente no VSCode e realizar o commit.

## 🤖 Fluxo de Auto-Cura (Self-Healing) com Grafana/Gitea
Para automatizar a geração de Issues no repositório `ruicesar/scoreodonto.com` quando ocorrerem falhas em produção (VPS 1), os Agentes/Administradores devem configurar as regras no Grafana estritamente desta forma:

1. Acesse o **Grafana** (Painel Central).
2. Vá em **Alerting** -> **Alert rules** e crie uma nova regra de alerta (ex: `sum(rate({container="scoreodontocom-scoreodonto-backend-1"} |= "error" [5m])) > 0`).
3. Na seção de **Labels (Custom Labels)**, é OBRIGATÓRIO adicionar:
   * **Chave:** `repo`
   * **Valor:** `scoreodonto.com`
4. Na seção **Notifications**, garanta que o alerta está roteado para o Contact Point `Gitea-Bridge`.

> [!IMPORTANT]
> A tag `repo="scoreodonto.com"` é vital. A Gitea-Bridge multi-tenant na VPS 1 lerá essa tag dinamicamente e fará o POST na API do Gitea criando a Issue de Auto-Cura automaticamente no repositório correto. Sem essa tag, a bridge tentará abrir no repositório padrão.