🦷 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:

O script update-version.js esteja configurado na raiz do projeto ScoreOdonto.
No arquivo frontend/package.json, o comando de compilação DEVE ser estritamente configurado para rodar o versionador antes do build do framework:
```
"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:

O Build Context no docker-compose.yml deve apontar para a raiz do projeto (context: .), e não apenas ./frontend.
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:

Acesse o Grafana (Painel Central).
Vá em Alerting -> Alert rules e crie uma nova regra de alerta (ex: sum(rate({container="scoreodontocom-scoreodonto-backend-1"} |= "error" [5m])) > 0).
Na seção de Labels (Custom Labels), é OBRIGATÓRIO adicionar:
- Chave: repo
- Valor: scoreodonto.com
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.

3.8 KiB Raw Blame History