diff --git a/Home.md b/Home.md index a94a959..bfdd119 100644 --- a/Home.md +++ b/Home.md @@ -5,7 +5,8 @@ Bem-vindo ao Portal de Consciência de toda a nossa infraestrutura. Esta Wiki un --- ## 📇 1. Diretrizes Globais do Enxame (Doutrina) -* [📖 Doutrina Swarm - Versão v1.0.3 (Atual)](v1.0.3) +* [📖 Doutrina Swarm - Versão v1.0.4 (Atual)](v1.0.4) +* [📜 Doutrina Swarm - Versão v1.0.3 (Histórico)](v1.0.3) * [📜 Doutrina Swarm - Versão v1.0.2 (Histórico)](v1.0.2) * [📜 Doutrina Swarm - Versão v1.0.1 (Histórico)](v1.0.1) * [📜 Doutrina Swarm - Versão v1.0.0 (Histórico)](v1.0.0) @@ -40,3 +41,8 @@ Bem-vindo ao Portal de Consciência de toda a nossa infraestrutura. Esta Wiki un * [🖥️ Setup Completo: VPS 1 - Produção](Setup-VPS1-Production) * [🖥️ Setup Completo: VPS 3 - Cérebro (Postgres/Gitea/Dragonfly)](Setup-VPS3-Brain) * [🖥️ Setup Completo: VPS 4 - Laboratório (Docker Compose Sandbox)](Setup-VPS4-Lab) + + +### ⚙️ Outros Documentos Importantes +* [⚙️ Tuning Avançado de PostgreSQL & DragonflyDB (Cache)](Tuning-Database-e-DragonflyDB) +* [🔄 Loop de Auto-Cura (Self-Healing DevOps - Codar após Issue)](Loop-Auto-Cura-Self-Healing) diff --git a/Loop-Auto-Cura-Self-Healing.md b/Loop-Auto-Cura-Self-Healing.md new file mode 100644 index 0000000..fa5ea16 --- /dev/null +++ b/Loop-Auto-Cura-Self-Healing.md @@ -0,0 +1,83 @@ +# 🔄 Loop de Auto-Cura (Self-Healing DevOps) + +Este documento documenta o funcionamento e a arquitetura do **Loop de Auto-Cura (Self-Healing)** implementado na infraestrutura do **Clube67**. O objetivo é fazer com que erros críticos de execução em nossos containers de produção (Docker) abram chamados automáticos (Issues) no Gitea para que nossos Agentes de IA façam a correção de forma autônoma. + +--- + +## 🗺️ Fluxo Geral da Arquitetura + +```mermaid +graph TD + A["🐳 Docker Container (VPS 1)"] -->|Gera Logs de Erro| B["📊 Loki + Promtail"] + B -->|Avalia Regra de Erro| C["📈 Grafana Alerting"] + C -->|Webhook de Alerta (Local)| D["🔌 Gitea-Bridge (Docker)"] + D -->|API POST /issues| E["🎫 Gitea Server (VPS 3)"] + E -->|Abre Issue de Bug| F["🤖 Agente de IA (SRE)"] + F -->|Corrige, Comita e Dá Push| A +``` + +Como o formato de payload de alertas do Grafana é incompatível com o formato que a API de Issues do Gitea espera, a **`Gitea-Bridge`** atua como o tradutor inteligente desse fluxo, formatando o erro em um relatório Markdown completo. + +--- + +## 🚀 Instalação do Gitea-Bridge (Na VPS 1) + +Como a VPS 1 adota o padrão **"Runtime Puro (Bunker)"**, rodamos a bridge de forma isolada dentro do Docker (sem instalar Node.js no sistema real). + +Rode os comandos abaixo no terminal da **VPS 1**: + +```bash +# 1. Crie a pasta do projeto +mkdir -p /home/deploy/gitea-bridge && cd /home/deploy/gitea-bridge + +# 2. Baixe o código fonte diretamente do Gitea +curl -H "Authorization: token ada47ca2fb196319dd10245cc216a327dac857ec" \ + http://10.99.0.3:3000/ruicesar/clube67_newwhats.local/raw/branch/main/self-healing/bridge.js \ + -o bridge.js + +# 3. Suba o container da Bridge rodando em segundo plano +docker run -d \ + --name gitea-bridge \ + --restart always \ + -p 127.0.0.1:9091:9091 \ + -v /home/deploy/gitea-bridge/bridge.js:/app/bridge.js \ + -e GITEA_TOKEN="ada47ca2fb196319dd10245cc216a327dac857ec" \ + -e PORT=9091 \ + node:alpine node /app/bridge.js +``` + +--- + +## ⚙️ Configuração do Canal de Alertas (Grafana - VPS 1) + +O Grafana foi configurado programmaticamente via API REST para enviar notificações de erro para a bridge local. + +* **Canal de Alerta (Contact Point) Criado:** `Gitea-Bridge` +* **URL de Destino:** `http://localhost:9091/alerts` +* **Política de Notificação Root (Padrão):** Alterada para usar o `Gitea-Bridge` como o destinatário padrão para todos os alertas que dispararem no cluster. + +--- + +## 🚨 Alertas Ativos e Monitorados + +Os seguintes alertas já estão monitorando seus respectivos containers e abrirão Issues no Gitea de forma automática ao falharem: + +1. **`BACKEND - Exceção Não Tratada`** + * *Foco:* Monitora exceções não tratadas (`TypeError`, `ReferenceError`, `UncaughtException`, etc.) no container `newwhats-backend-prod`. +2. **`BACKEND - Colisão Prisma P2002`** + * *Foco:* Monitora violações de chaves únicas no PostgreSQL do WhatsApp. +3. **`BACKEND - Erros HTTP 5xx`** + * *Foco:* Captura instabilidades de requisições web gerando erros 500 para clientes. +4. **`FALCO CRITICAL` & `POSSÍVEL CRYPTOJACKING`** + * *Foco:* Monitoramento do EDR contra invasões de sistema e mineradores de criptomoedas ilegais nas VPSs. + +--- + +## 🤖 Como o Agente Interage com a Issue + +Ao ser notificado de que uma Issue automática foi aberta, o Agente de IA SRE deve: +1. Ler a Issue no Gitea de baixo para cima. +2. Analisar a stack trace ou log de erro anexado no corpo da Issue. +3. Acessar a **VPS 4 (Dev/Builder)** para corrigir o código defeituoso. +4. Realizar o commit e push com a correção. +5. O webhook de deploy enviará o código saudável de volta para a VPS 1 (Produção) e o Grafana resolverá o alerta automaticamente! diff --git a/Tuning-Database-e-DragonflyDB.md b/Tuning-Database-e-DragonflyDB.md new file mode 100644 index 0000000..ea92a80 --- /dev/null +++ b/Tuning-Database-e-DragonflyDB.md @@ -0,0 +1,212 @@ +# 🗄️ Guia de Provisionamento e Tuning de Dados: VPS 3 (newwhats) + +Este documento centraliza as instruções práticas de configuração, tuning e provisionamento para o banco de dados principal de produção (**PostgreSQL**) e o cache de alta performance (**DragonflyDB**) hospedados na **VPS 3 dedicada** (especificações físicas: **8 GB de RAM e 4 núcleos de CPU**). + +--- + +## 🏛️ Divisão e Partilha Fisiológica de Recursos (Capacidade: 8 GB RAM / 4 CPUs) + +Para garantir estabilidade absoluta do sistema e impedir que oscilações no tráfego de mensagens do WhatsApp causem o encerramento forçado de serviços pelo OOM (*Out Of Memory Killer*) do Linux, o hardware é segmentado de forma cirúrgica: + +| Componente | Memória Alocada | Threads / CPUs | Função / Justificativa | +| :--- | :--- | :--- | :--- | +| **PostgreSQL shared_buffers** | **2.0 GB** (25%) | Automático (Host) | Cache interno nativo de tabelas e índices de negócio do PostgreSQL. | +| **PostgreSQL work_mem & OS** | **2.2 GB** (~27%) | Automático (Host) | Ordenações locais de queries, conexões e buffers de escrita do banco. | +| **DragonflyDB `--memlimit_gb`** | **3.0 GB** (~38%) | **`--num_threads 2`** | Armazenamento seguro de sessões de WhatsApp, presenças e QR codes ativos. | +| **Sistema Operacional (SO) & Redes** | **800 MB** (~10%) | Reservado (2 CPUs) | Processamento da rede VPN WireGuard, kernel e deamon de firewall. | + +> [!IMPORTANT] +> **Tuning de CPU**: O DragonflyDB é multi-threaded por natureza. Definir `--num_threads 2` confina a execução do cache a apenas 2 núcleos, deixando 2 núcleos de processamento físico totalmente livres para as consultas SQL do PostgreSQL e para a criptografia do túnel Wireguard. + +--- + +## 🚪 Escolha Estratégica do Temporal: **Opção B (Temporal Server na VPS 5)** + +O **Temporal Server** possui uma pegada de RAM ativa que consome entre **400 MB a 800 MB** em produção. Rodá-lo na VPS 3 deixaria a máquina no limite crítico de recursos físicos (apenas ~600 MB livres de folga). + +Portanto, adota-se a **Opção B: Hospedar o Temporal Server na VPS 5 (Aplicação)**: +* **Ganho de Estabilidade**: Preserva a VPS 3 exclusivamente como um *Data Appliance* de alta performance (Postgres + DragonflyDB). +* **Latência Zero de API**: Como o **Temporal Worker** roda ao lado do backend Express na VPS 5, colocá-los na mesma máquina permite que a comunicação entre Worker e Server aconteça via `localhost`, eliminando overhead de rede VPN. +* **Persistência**: O Temporal Server na VPS 5 continuará salvando seus dados persistentes de workflows (agenda/reputação) de forma segura no database dedicado `temporal` na VPS 3 via túnel privado. + +--- + +## 🗄️ 1. Separação de Databases e Privilégios no PostgreSQL + +O banco de dados do negócio (`newwhats`) e a infraestrutura interna do orquestrador (`temporal`) são isolados fisicamente em databases independentes para evitar conflito de migrações (Prisma/Knex vs `temporal-sql-tool`), facilitar backups por tabela e prover auditoria de acessos. + +Acesse o console do PostgreSQL (`sudo -u postgres psql`) e execute o script SQL abaixo: + +```sql +-- ==================================================== +-- 1. CRIAÇÃO DE DATABASES INDEPENDENTES +-- ==================================================== +CREATE DATABASE newwhats; +CREATE DATABASE temporal; + +-- ==================================================== +-- 2. CRIAÇÃO DOS USUÁRIOS/ROLES ESTREITOS +-- ==================================================== +CREATE USER newwhats_user WITH PASSWORD 'SuaSenhaForteNewwhatsAqui'; +CREATE USER temporal_user WITH PASSWORD 'SuaSenhaForteTemporalAqui'; + +-- ==================================================== +-- 3. REVOGAÇÃO DE ACESSOS PÚBLICOS PADRÃO (ZERO-TRUST) +-- ==================================================== +REVOKE ALL ON DATABASE newwhats FROM PUBLIC; +REVOKE ALL ON DATABASE temporal FROM PUBLIC; + +-- ==================================================== +-- 4. ATRIBUIÇÃO DE CONEXÕES EXCLUSIVAS +-- ==================================================== +GRANT CONNECT ON DATABASE newwhats TO newwhats_user; +GRANT CONNECT ON DATABASE temporal TO temporal_user; + +-- ==================================================== +-- 5. CONFIGURAÇÃO DE PRIVILÉGIOS GRANULARES +-- ==================================================== + +-- Conecte no banco 'newwhats' (\c newwhats) e execute: +GRANT USAGE ON SCHEMA public TO newwhats_user; +GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO newwhats_user; +GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO newwhats_user; +ALTER DATABASE newwhats OWNER TO newwhats_user; + +-- Conecte no banco 'temporal' (\c temporal) e execute: +-- O temporal-sql-tool precisa de privilégios plenos dentro de seu banco para autogerenciar tabelas +GRANT ALL PRIVILEGES ON DATABASE temporal TO temporal_user; +ALTER DATABASE temporal OWNER TO temporal_user; +``` + +--- + +## 📊 2. Hardening da Configuração do PostgreSQL (`pg_hba.conf`) + +Edite o arquivo `/etc/postgresql/15/main/pg_hba.conf` para garantir que o acesso ao banco de dados seja liberado apenas para os papéis designados originados da rede interna da VPN Wireguard: + +```text +# TYPE DATABASE USER ADDRESS METHOD + +# 1. Permissões locais do sistema operacional (Apenas Root local) +local all postgres peer + +# 2. Permitir que o backend (VPS 5) conecte apenas no database de negócio +host newwhats newwhats_user 10.99.0.5/32 scram-sha-256 + +# 3. Permitir que o orquestrador Temporal (VPS 5) conecte apenas no database temporal +host temporal temporal_user 10.99.0.5/32 scram-sha-256 + +# 4. Bloqueio preventivo total para qualquer outro IP ou usuário +host all all 0.0.0.0/0 reject +``` + +*Para aplicar as alterações:* +```bash +sudo systemctl reload postgresql +``` + +--- + +## 🚀 3. Provisionamento do DragonflyDB (Systemd) + +O **DragonflyDB** roda nativamente como um serviço leve do sistema, configurado com escuta restrita e controle estrito de memória física. + +### 🛠️ Configuração do Serviço `/etc/systemd/system/dragonfly.service`: + +Crie o arquivo de configuração de unidade do Systemd: + +```ini +[Unit] +Description=DragonflyDB Cache Server +After=network.target +Wants=network-online.target + +[Service] +Type=simple +User=dragonfly +Group=dragonfly +# Inicialização endurecida e otimizada para 8 GB RAM / 4 CPUs +ExecStart=/usr/local/bin/dragonfly \ + --bind 10.99.0.3 \ + --port 6379 \ + --memlimit_gb 3 \ + --num_threads 2 \ + --save_schedule "" \ + --logtostdout \ + --requirepass SENHA_DRAGONFLY_PRODUCAO + +Restart=always +RestartSec=5 +LimitNOFILE=65536 + +[Install] +WantedBy=multi-user.target +``` + +> [!NOTE] +> **Hardening de Escuta**: O parâmetro `--bind 10.99.0.3` substitui o padrão inseguro `0.0.0.0`. Isso força o DragonflyDB a escutar **exclusivamente** as requisições que transitam por dentro do túnel privado do Wireguard, impossibilitando tentativas de conexão direta a partir da internet pública. + +### 🏁 Passos de ativação do serviço: +1. Certifique-se de criar o usuário dedicado do sistema: + ```bash + sudo useradd -r -s /bin/false dragonfly + ``` +2. Recarregue os daemons e ative o DragonflyDB: + ```bash + sudo systemctl daemon-reload + sudo systemctl enable dragonfly + sudo systemctl start dragonfly + ``` + +--- + +## 🏛️ 4. Centralização de Múltiplos Projetos (Database Appliance) + +Centralizar os bancos de dados de todos os seus projetos (ex: `google.com`, `facebook.com`, `newwhats`) na **VPS 3 dedicada**, mantendo as aplicações e frontends isolados na **VPS 1 (ou outras VPSs de app)**, é uma excelente decisão de design. + +Isso separa a computação volátil das aplicações (onde acontecem picos de tráfego, deploys, memory leaks e builds pesados) da consistência estável da camada de persistência de dados. + +### ⚠️ Regras de Segurança e Isolamento Mandatórias: +Para operar esse modelo compartilhado com segurança de nível corporativo e evitar que uma falha em um projeto comprometa ou degrade os outros (efeito *Noisy Neighbor*): + +#### 1. Isolamento Lógico Absoluto (Databases & Roles Independentes) +**Nunca** use o mesmo banco de dados ou o mesmo usuário PostgreSQL para projetos distintos. Cada projeto deve ter seu banco de dados próprio e seu usuário com privilégios restritos ao seu respectivo banco. + +```text +PostgreSQL (VPS 3) +├── database: google_db ──> OWNER: google_user (Apenas VPS 1 / 10.99.0.1) +├── database: facebook_db ──> OWNER: facebook_user (Apenas VPS 1 / 10.99.0.1) +└── database: newwhats ──> OWNER: newwhats_user (Apenas VPS 5 / 10.99.0.5) +``` + +#### 2. Configuração do `pg_hba.conf` para Múltiplos Projetos: +Edite o arquivo `/etc/postgresql/15/main/pg_hba.conf` para mapear de forma cirúrgica as origens permitidas para cada projeto: + +```text +# TYPE DATABASE USER ADDRESS METHOD + +# 1. Permissões de Administração local +local all postgres peer + +# 2. Projeto GOOGLE (Frontend/Backend na VPS 1 -> Banco na VPS 3) +host google_db google_user 10.99.0.1/32 scram-sha-256 + +# 3. Projeto FACEBOOK (Frontend/Backend na VPS 1 -> Banco na VPS 3) +host facebook_db facebook_user 10.99.0.1/32 scram-sha-256 + +# 4. Projeto NEWWHATS (Backend na VPS 5 -> Banco na VPS 3) +host newwhats newwhats_user 10.99.0.5/32 scram-sha-256 + +# 5. BLOQUEIO PADRÃO TOTAL (Zero-Trust) +host all all 0.0.0.0/0 reject +``` + +#### 3. Gestão de Pools de Conexão no Node.js (Prisma/Knex) +Cada aplicação Node.js aberta na VPS 1 tentará criar um pool de conexões persistentes. Se muitos projetos rodarem simultaneamente, as conexões ativas podem saturar a memória RAM da VPS 3 (cada conexão ativa no Postgres é um processo físico consumindo ~10MB-20MB de RAM). +* **Solução**: Restrinja o tamanho máximo de pool nas variáveis de ambiente `.env` de cada projeto na VPS 1: + ```env + # Exemplo de limite de conexões no Prisma + DATABASE_URL="postgresql://google_user:SENHA@10.99.0.3:5432/google_db?connection_limit=10" + ``` +* **PgBouncer (Avançado)**: Se o número de projetos escalonar para dezenas de aplicações na VPS 1, configure o **PgBouncer** na VPS 3 para multiplexar centenas de conexões virtuais em poucas conexões físicas reais do Postgres, reduzindo drasticamente o consumo de RAM. + diff --git a/v1.0.4.md b/v1.0.4.md new file mode 100644 index 0000000..f6d06db --- /dev/null +++ b/v1.0.4.md @@ -0,0 +1,93 @@ +# 🧠 Doutrina Mestre dos Agentes (Multi-VPS) - Versão v1.0.4 (Atual) + +> [!NOTE] +> **Histórico de Atualização (Versão v1.0.4 - 17/05/2026)**: +> * **Documentação do Loop de Auto-Cura e Tuning**: Integração completa da documentação do Loop de Auto-Cura (Self-Healing DevOps / Codar após Issue) e do Tuning Avançado de Database/DragonflyDB na Wiki Central do Gitea. +> * **Versão v1.0.3**: Protocolo de Auto-Configuração de Novos Projetos. +> * **Versão v1.0.2**: Micro-segmentação de Firewall (SecOps Hardening) na VPS 3. +> * **Versão v1.0.1**: Hardening de terminal (.bash_logout) e carregamento dinâmico JIT via API REST do Gitea. +> * **Versão v1.0.0 (16/05/2026)**: Primeira versão consolidada e estruturada das diretrizes. + +--- + +Este documento define a consciência situacional obrigatória para todos os agentes de IA. + +## 📍 Identificação de Localização +Antes de qualquer ação, identifique seu IP interno: +- **10.99.0.1 (VPS 1 - PRODUÇÃO)**: Ambiente CRÍTICO. Rodando Traefik e Nginx. + - *Regra*: Apenas deploys homologados em Staging. Nunca mexa na infraestrutura de rede. +- **10.99.0.3 (VPS 3 - CÉREBRO)**: Onde reside o Gitea, Postgres e DragonflyDB. + - *Regra*: Proteja os dados. Backups antes de qualquer alteração de schema. +- **10.99.0.4 (VPS 4 - LABORATÓRIO)**: Desenvolvimento e Staging. + - *Regra*: Liberdade para testar, criar e quebrar containers. É o local de nascimento do código. + +## 🔐 Segurança e VPN +- **Interface wg0**: É a sua linha de vida. Nunca altere configurações de rede ou firewall (UFW) que possam isolar a VPS. +- **Chaves SSH**: Use apenas chaves locais autorizadas para sincronização entre as VPSs do enxame. + +## 📇 Protocolo de Identidade Estática (`~/.vps_identity`) +Para garantir 100% de consciência situacional à prova de falhas sem depender de chamadas de rede externas, cada máquina do enxame possui um arquivo de identidade em `/home/deploy/.vps_identity`. + +### 📄 Estrutura Obrigatória do JSON: +Todo arquivo `.vps_identity` deve conter exatamente a seguinte estrutura: +```json +{ + "vps_id": 4, + "vps_name": "VPS-4-LABORATORIO", + "ip_vpn": "10.99.0.4", + "role": "Desenvolvimento, Builds e Staging", + "danger_level": "BAIXO - Liberdade para testar e recriar" +} +``` + +### 🚨 Obrigações das IAs e Agentes: +1. **Verificação Obrigatória**: Toda execução de script ou agente deve prioritariamente ler e interpretar o arquivo `/home/deploy/.vps_identity` para calibrar o seu escopo de atuação. +2. **Respeito ao Danger Level (Nível de Perigo)**: + - **Nível de Perigo ALTO** (ex: VPS 1, VPS 3): Agentes **NÃO PODEM** rodar comandos experimentais, mutações não homologadas de bancos de dados ou reinstalar dependências críticas sem backups nítidos e aprovação explícita. + - **Nível de Perigo BAIXO** (ex: VPS 4): O agente possui total autonomia para realizar testes, compilar códigos, reinstalar pacotes e reiniciar contêineres Docker de staging. +3. **Resiliência (Fallback)**: Caso o arquivo `.vps_identity` não exista ou esteja ilegível, o agente deve fazer o fallback dinâmico (buscando o IP `10.99.x.x` via `hostname -I`) e assumir o perfil de segurança mais restritivo por padrão. + +## 🚫 NUNCA... +- Nunca tente acessar servidores fora da rede 10.99.0.x. +- Nunca exponha senhas ou chaves privadas em logs ou comentários. +- Nunca altere o serviço `swarm-listener` sem autorização. + +## 🔄 Protocolo de Criação e Configuração de Novos Projetos (Auto-Config de Webhook) + +Sempre que um novo projeto for criado no ecossistema Swarm, os agentes e desenvolvedores **devem** seguir e configurar automaticamente a seguinte rotina de integração de CI/CD para que o GitOps funcione perfeitamente: + +### 1. Criação Obrigatória do Webhook de Deploy +Todo novo repositório criado no Gitea **DEVE** possuir um Webhook de deploy ativo configurado da seguinte forma: +* **URL de Destino**: `http://10.99.0.3:5000/webhook` (Se configurado externamente) ou `http://127.0.0.1:5000/webhook` (Se configurado de dentro da VPS 3). +* **Tipo de Conteúdo**: `application/json` +* **Segredo (Secret)**: Em branco ou chave secreta padrão. +* **Eventos que disparam**: Apenas o evento de **Push** (Commit enviado). + +> [!IMPORTANT] +> **Autonomia do Agente (Auto-Identificação)**: +> Se você (o Agente de IA) identificar que está trabalhando em um **novo projeto** ou que o repositório do projeto atual **não possui** o webhook do Swarm Dispatcher (`http://127.0.0.1:5000/webhook`) configurado no Gitea: +> 1. Você **DEVE** usar a API REST do Gitea para criar ou corrigir esse webhook automaticamente. +> 2. Você **DEVE** garantir a criação do arquivo `.vps_identity` apropriado nas VPSs correspondentes. +> 3. Você **DEVE** estruturar o `docker-compose.yml` do projeto sob a pasta `/home/deploy/stack//` seguindo o padrão rootless. + +## 🗣️ Comunicação +- Todo o desenvolvimento, comentários e commits devem ser em **PORTUGUÊS**. +- Use o protocolo **PGS (Protocolo Gitea Swarm)** para hand-offs. + +## 📂 Diretórios de Projetos e Stacks Ativos (Mapeamento de Preservação) + +### 🖥️ VPS 1 - Produção (10.99.0.1) +Os seguintes diretórios são de infraestrutura e serviços críticos ativos e **DEVEM SER ESTRITAMENTE PRESERVADOS** contra qualquer alteração ou limpeza na VPS 1: +* 📁 `/home/deploy/stack/traefik/`: Roteador de borda central e proxy reverso da infraestrutura. +* 📁 `/home/deploy/stack/portainer/`: Interface de gerenciamento e monitoramento de contêineres Docker. +* 📁 `/home/deploy/stack/soc/`: Rotinas de CrowdSec, firewall e auditoria de segurança ativa. + +### 🖥️ VPS 4 - Laboratório (10.99.0.4) +Os seguintes diretórios dentro de `/home/deploy/stack/` contêm contêineres de desenvolvimento e staging ativos e **DEVEM SER ESTRITAMENTE PRESERVADOS** na VPS 4: +* 📁 `scoreodonto.com/`: Aplicação e contêineres de staging do ecossistema ScoreOdonto. +* 📁 `subdominio.clube67.com/`: Branding, front-end e back-end do Gerenciador de Subdomínios. +* 📁 `self-healing/`: Rotinas e scripts locais de auto-recuperação de serviços. +* 📁 `webhook-listener/`: Ouvinte de webhooks de GitOps (porta `9000`) para deploys automatizados. + +> [!WARNING] +> Quaisquer pastas como `/home/deploy/stack/traefik/`, `/home/deploy/stack/portainer/` ou `/home/deploy/stack/soc/` que sejam encontradas na **VPS 4** são duplicatas inativas e obsoletas e **devem ser deletadas** na limpeza dos agentes.