Files
instrucoes_gerais/scoreodonto/arquitetura.md
T

38 lines
1.9 KiB
Markdown

# 🦷 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
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`).
## 🤖 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.