refactor: limpeza de testes, reestruturacao multi-tenant e auto-cura scoreodonto

clube67/arquitetura.md

@@ -1,4 +1,9 @@
-# 📐 Arquitetura de Rede e Topologia de Servidores
+# 📐 Arquitetura de Rede e Topologia de Servidores (Clube67 / NewWhats)
+
+> [!WARNING]
+> **REGRAS DE ISOLAMENTO (MULTI-TENANT)**
+> Este documento dita a arquitetura EXCLUSIVA do ecossistema Clube67 e NewWhats.
+> As informações contidas aqui (como MySQL, redis na porta 6379 índice 0, e uso da VPS 5) **NÃO SE APLICAM** ao ScoreOdonto ou outros projetos.
 
 Este documento descreve detalhadamente a arquitetura de servidores e rede privada projetada para garantir **alta performance, isolamento de riscos, segurança de dados e facilidade de escalonamento**.
 
@@ -242,3 +247,16 @@ Para garantir que a invasão de um container não resulte no comprometimento do
 * **Read-Only Root Filesystem**: Monta o sistema de arquivos do container como apenas leitura, forçando gravações temporárias apenas em volumes declarados ou `/tmp` na memória (tmpfs).
 * **CAP Drop**: Remove capacidades de sistema desnecessárias ao container (ex: `NET_ADMIN`, `SYS_ADMIN`, `SYS_CHROOT`).
 * **Rootless Containers**: Sempre que suportado pela aplicação, os containers devem rodar com IDs de usuário não privilegiados (non-root).
+
+---
+
+## 🤖 Fluxo de Auto-Cura (Self-Healing) com Grafana/Gitea
+
+O Clube67 / NewWhats utiliza um fluxo GitOps de Auto-Cura para detecção e mitigação autônoma de falhas. Quando ocorrem falhas críticas de execução no container, o Grafana deve enviar um webhook para a Gitea-Bridge.
+
+Para configurar alertas de auto-cura no Grafana:
+1. Acesse o **Grafana** e crie uma nova regra de alerta baseada em LogQL (Loki) do container afetado.
+2. Na seção de **Labels**, você **não precisa** definir a label `repo`, pois o `clube67_newwhats.local` é o repositório padrão de fallback da Bridge.
+3. Roteie a notificação para o Contact Point `Gitea-Bridge`.
+
+Assim que a falha disparar, a Gitea-Bridge multi-tenant criará uma Issue automática com o prefixo `🚨 [AUTO-BUG]` no repositório `clube67_newwhats.local`, contendo todo o stack trace para o Agente IA realizar a manutenção e o hotfix.

protocolo_agentes.md

@@ -1,11 +1,20 @@
 # 🤖 Protocolo Gitea Swarm (PGS): Coordenação de Multi-Agentes em Ambiente Multi-VPS
 
-Este documento estabelece o protocolo de comunicação padrão, obrigatório e imutável para todos os Agentes de Inteligência Artificial (IAs) que atuarem no gerenciamento, desenvolvimento ou manutenção da infraestrutura do **Clube67** distribuída em múltiplos servidores.
+Este documento estabelece o protocolo de comunicação padrão, obrigatório e imutável para todos os Agentes de Inteligência Artificial (IAs) que atuarem no gerenciamento, desenvolvimento ou manutenção da infraestrutura multi-tenant (múltiplos projetos) distribuída em múltiplos servidores.
 
 Como a arquitetura adota segurança **Zero-Trust de movimentação lateral** (impedindo que agentes em uma VPS acessem outras máquinas via SSH automático), o **Gitea** atua como o **Orquestrador de Estado Assíncrono** do enxame de agentes.
 
 ---
 
+## 🧭 REGRA MESTRE DE ROTEAMENTO (DISPATCHER PROTOCOL)
+**ATENÇÃO AGENTE DE IA:** Esta infraestrutura hospeda múltiplos projetos independentes (Multi-Tenant). Antes de tomar qualquer ação, você deve ler a arquitetura e as regras **específicas** do projeto solicitado.
+
+1. Se a tarefa envolver o **Clube67** ou **NewWhats**, você DEVE LER OBRIGATORIAMENTE a documentação na pasta `/home/deploy/instrucoes/clube67/`.
+2. Se a tarefa envolver o **ScoreOdonto**, você DEVE LER OBRIGATORIAMENTE a documentação na pasta `/home/deploy/instrucoes/scoreodonto/`.
+3. **Jamais** presuma que a arquitetura ou as portas de um projeto se aplicam ao outro. Mantenha os contextos estritamente isolados.
+
+---
+
 ## ⚠️ Regras Cruciais de Governança e Codificação (Obrigatório)
 
 1. **Comunicação Prévia e Autorização:** Qualquer alteração na estrutura, infraestrutura ou lógica core do sistema deve ser obrigatoriamente comunicada de antemão. **As mudanças somente devem ser aplicadas após a autorização explícita do Administrador**.

scoreodonto/arquitetura.md

@@ -0,0 +1,37 @@
+# 🦷 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.