docs: renomeia terminologia "staging" -> "dev" em todo o ecossistema

O "staging" nunca foi implementado (sem banco *_staging nem container ativo em nenhum projeto). Padroniza para "dev" (VPS4 = desenvolvimento) em docs de arquitetura, doutrina, protocolo de deploy e configs de VPN (comentários). Renomeia: protocolo_deploy_staging.md -> protocolo_deploy_dev.md; nginx_wildcard_staging.conf -> nginx_wildcard_dev.conf. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-16 03:35:52 +02:00
parent 5398006ec8
commit e93f0edbe9
16 changed files with 85 additions and 70 deletions
@@ -7,8 +7,8 @@ Este arquivo registra o progresso da automação multi-VPS.
 - [x] **1.2 Configurar Dispatcher (VPS 3)**: Script de recepção de Webhooks.
 - [x] **1.3 Integrar com Gitea**: Configurar Webhook nativo do Gitea para o Dispatcher.
-## 🔵 Fase 2: Automação de Staging
+## 🔵 Fase 2: Automação de Dev
- [x] **2.1 Wildcard Proxy (VPS 1)**: Configurar `*.staging.clube67.com`.
+- [x] **2.1 Wildcard Proxy (VPS 1)**: Configurar `*.dev.clube67.com`.
 - [x] **2.2 Roteamento de Porta**: Mapeamento dinâmico Subdomínio -> Porta na VPS 4 (Portas `8081` e `8082`).
 ## 🟡 Fase 3: Listeners e Agentes
@@ -18,8 +18,8 @@ Este arquivo registra o progresso da automação multi-VPS.
 ## 🛡️ Fase 4: Governança SecOps & Homologação em Duas Etapas
 - [x] **4.1 Filtro de Rótulo SecOps (VPS 4)**: Listener configurado para ignorar issues que não possuam a etiqueta `Autônomo`.
- [x] **4.2 Isolamento de Deploy (VPS 4)**: Compilação local e implantação em Staging para `mercado.clube67.com` (porta `8081`) e `scoreodonto.com` (porta `8082`).
+- [x] **4.2 Isolamento de Deploy (VPS 4)**: Compilação local e implantação em Dev para `mercado.clube67.com` (porta `8081`) e `scoreodonto.com` (porta `8082`).
- [x] **4.3 Script de Promoção (VPS 4)**: Criação de scripts `deploy-to-prod.sh` para promoção manual ultra-segura Staging ➔ Produção na VPS 1.
+- [x] **4.3 Script de Promoção (VPS 4)**: Criação de scripts `deploy-to-prod.sh` para promoção manual ultra-segura Dev ➔ Produção na VPS 1.
 ---
 *Última atualização: 18/05/2026 - Agente Antigravity*
@@ -25,7 +25,7 @@ AllowedIPs = 10.99.0.10/32
 PublicKey = S40JqovA4F8oH8aieWsDvNEv1yw5Juwu1wb4zHjQ8Ww=
 AllowedIPs = 10.99.0.3/32
-# Peer 3: VPS 4 (Desenvolvimento / Staging)
+# Peer 3: VPS 4 (Desenvolvimento / Dev)
 [Peer]
 PublicKey = ln7phEfm4w//jZJqqlkGAjsXKWQnOw2kYc64ni5PXX0=
 AllowedIPs = 10.99.0.4/32
@@ -1,4 +1,4 @@
-# 🧪 Configuração de Rede Segura (VPN WireGuard) - VPS 4 (Desenvolvimento / Staging)
+# 🧪 Configuração de Rede Segura (VPN WireGuard) - VPS 4 (Desenvolvimento / Dev)
 Este diretório contém os arquivos de configuração necessários para que a **VPS 4** (`10.99.0.4`) entre na rede privada criptografada do **Clube67** de forma totalmente segura.
@@ -7,7 +7,7 @@ Este diretório contém os arquivos de configuração necessários para que a **
 ## 🗺️ Visão de Conexão da VPS 4
 ```mermaid
 graph LR
-    VPS4["🧪 VPS 4 (Staging) <br> IP: 10.99.0.4"]
+    VPS4["🧪 VPS 4 (Dev) <br> IP: 10.99.0.4"]
    VPS1["🖥️ VPS 1 (Hub Central) <br> IP: 10.99.0.1"]
    VPS3["🗄️ VPS 3 (Banco de Dados) <br> IP: 10.99.0.3"]
@@ -37,7 +37,7 @@ Antes de ativar a conexão na VPS 4, o servidor central (**VPS 1**) precisa auto
 3. Adicione o seguinte bloco de peer ao final do arquivo:
   ```ini
   [Peer]
-   # VPS 4 (Desenvolvimento / Staging)
+   # VPS 4 (Desenvolvimento / Dev)
   PublicKey = ln7phEfm4w//jZJqqlkGAjsXKWQnOw2kYc64ni5PXX0=
   AllowedIPs = 10.99.0.4/32
   PersistentKeepalive = 25
@@ -2,7 +2,7 @@
 # Adicione este bloco ao final do arquivo para autorizar a conexão da VPS 4
 [Peer]
-# VPS 4 (Desenvolvimento / Staging)
+# VPS 4 (Desenvolvimento / Dev)
 PublicKey = ln7phEfm4w//jZJqqlkGAjsXKWQnOw2kYc64ni5PXX0=
 AllowedIPs = 10.99.0.4/32
 PersistentKeepalive = 25
@@ -1,4 +1,4 @@
-# /etc/wireguard/wg0.conf - VPS 4 (Desenvolvimento / Staging)
+# /etc/wireguard/wg0.conf - VPS 4 (Desenvolvimento / Dev)
 # Configuração de Cliente VPN WireGuard
 # IP Atribuído: 10.99.0.4
@@ -2,6 +2,16 @@
 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**.
 > [!NOTE]
 > **Status das VPSs Ativas (Atualizado em 22/05/2026):**
 > Atualmente, a infraestrutura conta com **3 VPSs ativas** em produção/homologação:
 > 1. **VPS 1** (Produção - Gateway / Traefik / Apps) - IP: `10.99.0.1`
 > 2. **VPS 3** (Banco de Dados Appliance) - IP: `10.99.0.3`
 > 3. **VPS 4** (Laboratório / Dev / Builds) - IP: `10.99.0.4`
 > 
 > A **VPS 5** (CRM WhatsApp / newwhats) está planejada e encontra-se **inativa temporariamente** na malha física atual. Todo o tráfego e serviços destinados a ela estão no aguardo de sua ativação futura.
 ---
 ## 🗺️ Visão Geral da Topologia (Rede VPN WireGuard)
@@ -18,7 +28,7 @@ graph TD
    subgraph "Rede Privada VPN (10.99.0.0/24)"
        VPS1["🖥️ VPS 1 (Produção) <br> IP: 10.99.0.1 <br> (Traefik / Apps)"]
        VPS3["🗄️ VPS 3 (Banco de Dados) <br> IP: 10.99.0.3 <br> (PostgreSQL Dedicado)"]
-        VPS4["🧪 VPS 4 (Desenvolvimento) <br> IP: 10.99.0.4 <br> (Staging / Builds)"]
+        VPS4["🧪 VPS 4 (Desenvolvimento) <br> IP: 10.99.0.4 <br> (Dev / Builds)"]
        VPS5["💬 VPS 5 (CRM WhatsApp) <br> IP: 10.99.0.5 <br> (Bots / APIs)"]
    end
@@ -77,22 +87,24 @@ graph TD
 ---
-### 🧪 3. VPS 4: Servidor de Desenvolvimento e Homologação (Staging)
+### 🧪 3. VPS 4: Servidor de Desenvolvimento e Homologação (Dev)
-* **Função Principal**: Testar novos recursos, hospedar containers de staging e realizar builds de desenvolvimento.
+* **Função Principal**: Testar novos recursos, hospedar containers de dev e realizar builds de desenvolvimento.
 * **IP Privado VPN**: `10.99.0.4`
 * **Políticas do Firewall (UFW)**:
  * **Porta 22 (SSH)**: **Bloqueada publicamente**. Apenas acessível via VPN.
  * **Portas de teste (ex: 3002, 8080)**: **Bloqueadas publicamente** ou atreladas apenas ao IP privado da VPN para acesso exclusivo dos desenvolvedores autorizados.
 * **Tecnologias**: Docker, Docker Compose, PostgreSQL 18 (Standby Replica em Container).
 * **Vantagens de Segurança & Performance**:
-  * **Replicação Streaming Real-Time (Staging)**: Hospeda um container PostgreSQL 18 configurado como réplica de leitura (Standby) do banco de dados nativo de produção da VPS 3. Isso permite testar queries pesadas e validar migrações com dados reais em tempo de desenvolvimento de forma 100% segura e com zero impacto no banco principal.
+  * **Replicação Streaming Real-Time (Dev)**: Hospeda um container PostgreSQL 18 configurado como réplica de leitura (Standby) do banco de dados nativo de produção da VPS 3. Isso permite testar queries pesadas e validar migrações com dados reais em tempo de desenvolvimento de forma 100% segura e com zero impacto no banco principal.
  * **Isolamento de Riscos**: Compilações de código (`npm run build`, `docker build`) e testes pesados de carga rodam aqui e consomem CPU sem comprometer os servidores de produção e banco de dados.
  * **Ambiente Espelho**: Homologação idêntica à produção para validações precisas antes de aplicar modificações em produção.
 ---
-### 💬 4. VPS 5: Servidor de Aplicação Proprietária (newwhats)
+### 💬 4. VPS 5: Servidor de Aplicação Proprietária (newwhats) [INATIVA TEMPORARIAMENTE]
 * **Função Principal**: Hospedar o backend e workers da plataforma proprietária **newwhats** (Backend Express com Socket.IO, Workers do Temporal e broker NATS).
 * **Status Atual**: Planejada e em preparação para implantação. Inativa temporariamente na infraestrutura física.
 * **IP Privado VPN**: `10.99.0.5`
 * **Políticas do Firewall (UFW)**:
  * **Portas de Integração Web**: Liberadas apenas para os Webhooks e requisições públicas de Socket.IO mapeadas via gateway.
@@ -197,6 +209,9 @@ graph TD
  * **Tráfego de Borda**: O Traefik na VPS 1 encaminha o tráfego HTTP/HTTPS e conexões persistentes do Socket.IO diretamente para a VPS 5 (`10.99.0.5`) pela interface de túnel criptografado, mantendo as portas da VPS 5 públicas totalmente fechadas.
  * **Persistência de Negócio (Prisma + Knex)**: Ambas as ORMs/Query Builders centralizadas na VPS 5 apontam diretamente para o IP interno `10.99.0.3:5432` da VPS 3.
  * **Cache e Estados Rápidos**: O DragonflyDB na VPS 3 atende instantaneamente às solicitações de sessões e QR codes da VPS 5 via `10.99.0.3:6379`, provendo tempos de resposta na faixa de microssegundos sem concorrência local de CPU.
    > [!TIP]
    > **Sugestão de Evolução Futura (DragonflyDB)**: Atualmente, o DragonflyDB roda de forma nativa (bare-metal) no host da VPS 3. Para manter a VPS 3 focada única e exclusivamente no PostgreSQL nativo e evitar concorrência de RAM/CPU, recomenda-se que no futuro (assim que a VPS 5 estiver operacional) o DragonflyDB seja movido e executado na própria VPS 5 (ou no mesmo host que consumir o cache localmente), eliminando a latência de tráfego de rede interna para estados rápidos.
  * **Workflows Assíncronos**: O Temporal Server processa o agendamento de tarefas e status de reputação na VPS 3, enquanto o **Temporal Worker** na VPS 5 consome e executa as atividades pesadas locais da aplicação.
 ---
@@ -205,15 +220,15 @@ graph TD
 A rede VPN WireGuard (`10.99.0.0/24`) deixa de ser tratada como uma zona de confiança irrestrita. Implementa-se uma política de privilégio mínimo na comunicação entre os servidores da VPN.
 * **O Problema de Movimentação Lateral**:
-  Se a máquina de desenvolvimento/staging (VPS 4) for comprometida por um script malicioso, o atacante não pode ter permissão para escaneá-la ou conectar-se ao banco de dados de produção (VPS 3), exceto para o fluxo estritamente necessário de replicação de dados.
+  Se a máquina de desenvolvimento/dev (VPS 4) for comprometida por um script malicioso, o atacante não pode ter permissão para escaneá-la ou conectar-se ao banco de dados de produção (VPS 3), exceto para o fluxo estritamente necessário de replicação de dados.
 * **Regras de Isolamento Lateral (Exemplo no Firewall da VPS 3)**:
  ```text
  # Bloquear por padrão toda conexão vinda da VPN exceto as estritamente autorizadas:
  - Permitir VPS 1 (Produção) -> Porta 5432 (PostgreSQL)                       [ACEITAR]
  - Permitir VPS 5 (CRM)       -> Porta 5432 (PostgreSQL)                       [ACEITAR]
-  - Permitir VPS 4 (Staging)   -> Porta 5432 (PostgreSQL - Apenas 'replicator') [ACEITAR]
+  - Permitir VPS 4 (Dev)   -> Porta 5432 (PostgreSQL - Apenas 'replicator') [ACEITAR]
-  - Permitir VPS 4 (Staging)   -> VPS 3 (Produção - Outras portas / serviços)   [BLOQUEAR]
+  - Permitir VPS 4 (Dev)   -> VPS 3 (Produção - Outras portas / serviços)   [BLOQUEAR]
  ```
 * **🌐 DNS e Acesso Seguro à Internet no WireGuard**:
@@ -23,7 +23,7 @@ graph TD
    subgraph "Rede Privada VPN (10.99.0.0/24)"
        VPS1["🖥️ VPS 1 (Produção) <br> IP: 10.99.0.1 <br> (Traefik / Apps)"]
        VPS3["🗄️ VPS 3 (Banco de Dados) <br> IP: 10.99.0.3 <br> (PostgreSQL Dedicado)"]
-        VPS4["🧪 VPS 4 (Desenvolvimento) <br> IP: 10.99.0.4 <br> (Staging / Builds)"]
+        VPS4["🧪 VPS 4 (Desenvolvimento) <br> IP: 10.99.0.4 <br> (Dev / Builds)"]
        VPS5["💬 VPS 5 (CRM WhatsApp) <br> IP: 10.99.0.5 <br> (Bots / APIs)"]
    end
@@ -82,8 +82,8 @@ graph TD
 ---
-### 🧪 3. VPS 4: Servidor de Desenvolvimento e Homologação (Staging)
+### 🧪 3. VPS 4: Servidor de Desenvolvimento e Homologação (Dev)
-* **Função Principal**: Testar novos recursos, hospedar containers de staging e realizar builds de desenvolvimento.
+* **Função Principal**: Testar novos recursos, hospedar containers de dev e realizar builds de desenvolvimento.
 * **IP Privado VPN**: `10.99.0.4`
 * **Políticas do Firewall (UFW)**:
  * **Porta 22 (SSH)**: **Bloqueada publicamente**. Apenas acessível via VPN.
@@ -208,14 +208,14 @@ graph TD
 A rede VPN WireGuard (`10.99.0.0/24`) deixa de ser tratada como uma zona de confiança irrestrita. Implementa-se uma política de privilégio mínimo na comunicação entre os servidores da VPN.
 * **O Problema de Movimentação Lateral**:
-  Se a máquina de desenvolvimento/staging (VPS 4) for comprometida por um script malicioso, o atacante não pode ter permissão para escaneá-la ou conectar-se ao banco de dados de produção (VPS 3).
+  Se a máquina de desenvolvimento/dev (VPS 4) for comprometida por um script malicioso, o atacante não pode ter permissão para escaneá-la ou conectar-se ao banco de dados de produção (VPS 3).
 * **Regras de Isolamento Lateral (Exemplo no Firewall da VPS 3)**:
  ```text
  # Bloquear por padrão toda conexão vinda da VPN exceto as estritamente autorizadas:
  - Permitir VPS 1 (Produção) -> Porta 5432 (PostgreSQL)  [ACEITAR]
  - Permitir VPS 5 (CRM)       -> Porta 5432 (PostgreSQL)  [ACEITAR]
-  - Permitir VPS 4 (Staging)   -> VPS 3 (Produção)         [BLOQUEAR]
+  - Permitir VPS 4 (Dev)   -> VPS 3 (Produção)         [BLOQUEAR]
  ```
 ---
@@ -18,7 +18,7 @@ graph TD
    subgraph "Rede Privada VPN (10.99.0.0/24)"
        VPS1["🖥️ VPS 1 (Produção) <br> IP: 10.99.0.1 <br> (Traefik / Apps)"]
        VPS3["🗄️ VPS 3 (Banco de Dados) <br> IP: 10.99.0.3 <br> (PostgreSQL Dedicado)"]
-        VPS4["🧪 VPS 4 (Desenvolvimento) <br> IP: 10.99.0.4 <br> (Staging / Builds)"]
+        VPS4["🧪 VPS 4 (Desenvolvimento) <br> IP: 10.99.0.4 <br> (Dev / Builds)"]
        VPS5["💬 VPS 5 (CRM WhatsApp) <br> IP: 10.99.0.5 <br> (Bots / APIs)"]
    end
@@ -77,15 +77,15 @@ graph TD
 ---
-### 🧪 3. VPS 4: Servidor de Desenvolvimento e Homologação (Staging)
+### 🧪 3. VPS 4: Servidor de Desenvolvimento e Homologação (Dev)
-* **Função Principal**: Testar novos recursos, hospedar containers de staging e realizar builds de desenvolvimento.
+* **Função Principal**: Testar novos recursos, hospedar containers de dev e realizar builds de desenvolvimento.
 * **IP Privado VPN**: `10.99.0.4`
 * **Políticas do Firewall (UFW)**:
  * **Porta 22 (SSH)**: **Bloqueada publicamente**. Apenas acessível via VPN.
  * **Portas de teste (ex: 3002, 8080)**: **Bloqueadas publicamente** ou atreladas apenas ao IP privado da VPN para acesso exclusivo dos desenvolvedores autorizados.
 * **Tecnologias**: Docker, Docker Compose, PostgreSQL 18 (Standby Replica em Container).
 * **Vantagens de Segurança & Performance**:
-  * **Replicação Streaming Real-Time (Staging)**: Hospeda um container PostgreSQL 18 configurado como réplica de leitura (Standby) do banco de dados nativo de produção da VPS 3. Isso permite testar queries pesadas e validar migrações com dados reais em tempo de desenvolvimento de forma 100% segura e com zero impacto no banco principal.
+  * **Replicação Streaming Real-Time (Dev)**: Hospeda um container PostgreSQL 18 configurado como réplica de leitura (Standby) do banco de dados nativo de produção da VPS 3. Isso permite testar queries pesadas e validar migrações com dados reais em tempo de desenvolvimento de forma 100% segura e com zero impacto no banco principal.
  * **Isolamento de Riscos**: Compilações de código (`npm run build`, `docker build`) e testes pesados de carga rodam aqui e consomem CPU sem comprometer os servidores de produção e banco de dados.
  * **Ambiente Espelho**: Homologação idêntica à produção para validações precisas antes de aplicar modificações em produção.
@@ -205,15 +205,15 @@ graph TD
 A rede VPN WireGuard (`10.99.0.0/24`) deixa de ser tratada como uma zona de confiança irrestrita. Implementa-se uma política de privilégio mínimo na comunicação entre os servidores da VPN.
 * **O Problema de Movimentação Lateral**:
-  Se a máquina de desenvolvimento/staging (VPS 4) for comprometida por um script malicioso, o atacante não pode ter permissão para escaneá-la ou conectar-se ao banco de dados de produção (VPS 3), exceto para o fluxo estritamente necessário de replicação de dados.
+  Se a máquina de desenvolvimento/dev (VPS 4) for comprometida por um script malicioso, o atacante não pode ter permissão para escaneá-la ou conectar-se ao banco de dados de produção (VPS 3), exceto para o fluxo estritamente necessário de replicação de dados.
 * **Regras de Isolamento Lateral (Exemplo no Firewall da VPS 3)**:
  ```text
  # Bloquear por padrão toda conexão vinda da VPN exceto as estritamente autorizadas:
  - Permitir VPS 1 (Produção) -> Porta 5432 (PostgreSQL)                       [ACEITAR]
  - Permitir VPS 5 (CRM)       -> Porta 5432 (PostgreSQL)                       [ACEITAR]
-  - Permitir VPS 4 (Staging)   -> Porta 5432 (PostgreSQL - Apenas 'replicator') [ACEITAR]
+  - Permitir VPS 4 (Dev)   -> Porta 5432 (PostgreSQL - Apenas 'replicator') [ACEITAR]
-  - Permitir VPS 4 (Staging)   -> VPS 3 (Produção - Outras portas / serviços)   [BLOQUEAR]
+  - Permitir VPS 4 (Dev)   -> VPS 3 (Produção - Outras portas / serviços)   [BLOQUEAR]
  ```
 ---
@@ -4,8 +4,8 @@
 ## 🎯 Seus Objetivos Unificados:
 1.  **Desenvolvimento e Correção**: Criar e corrigir códigos e scripts exclusivamente na VPS 4.
-2.  **Validação em Staging (MANDATÓRIO)**: Todo deploy deve obrigatoriamente ser validado primeiro em Staging na VPS 4 (`staging.{projeto}.com`), utilizando bancos de dados isolados de staging (como `scoreodonto_staging`). Pular esta homologação é proibido.
+2.  **Validação em Dev (MANDATÓRIO)**: Todo deploy deve obrigatoriamente ser validado primeiro em Dev na VPS 4 (`dev.{projeto}.com`), utilizando bancos de dados isolados de dev (como `scoreodonto_dev`). Pular esta homologação é proibido.
-3.  **Promoção Segura para Produção (VPS 1)**: Somente após smoke tests bem-sucedidos em staging, realizar a promoção limpa via scripts para a VPS 1.
+3.  **Promoção Segura para Produção (VPS 1)**: Somente após smoke tests bem-sucedidos em dev, realizar a promoção limpa via scripts para a VPS 1.
 4.  **Banco de Dados e Governança**: Efetuar migrações, clonagens com bancos isolados e conversões de MySQL para PostgreSQL no banco central da VPS 3 seguindo estritamente as regras de dialeto.
 ## 🛠️ Modus Operandi Geral:
@@ -4,8 +4,8 @@
 ## 🎯 Seus Objetivos Unificados:
 1.  **Desenvolvimento e Correção**: Criar e corrigir códigos e scripts exclusivamente na VPS 4.
-2.  **Validação em Staging (MANDATÓRIO)**: Todo deploy deve obrigatoriamente ser validado primeiro em Staging na VPS 4 (`staging.{projeto}.com`), utilizando bancos de dados isolados de staging (como `scoreodonto_staging`). Pular esta homologação é proibido.
+2.  **Validação em Dev (MANDATÓRIO)**: Todo deploy deve obrigatoriamente ser validado primeiro em Dev na VPS 4 (`dev.{projeto}.com`), utilizando bancos de dados isolados de dev (como `scoreodonto_dev`). Pular esta homologação é proibido.
-3.  **Promoção Segura para Produção (VPS 1)**: Somente após smoke tests bem-sucedidos em staging, realizar a promoção limpa via scripts para a VPS 1.
+3.  **Promoção Segura para Produção (VPS 1)**: Somente após smoke tests bem-sucedidos em dev, realizar a promoção limpa via scripts para a VPS 1.
 4.  **Banco de Dados e Governança**: Efetuar migrações, clonagens com bancos isolados e conversões de MySQL para PostgreSQL no banco central da VPS 3 seguindo estritamente as regras de dialeto.
 ## 🛠️ Modus Operandi Geral:
@@ -5,10 +5,10 @@ Este documento define a consciência situacional obrigatória para todos os agen
 ## 📍 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.
+  - *Regra*: Apenas deploys homologados em Dev. 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.
+- **10.99.0.4 (VPS 4 - LABORATÓRIO)**: Desenvolvimento e Dev.
  - *Regra*: Liberdade para testar, criar e quebrar containers. É o local de nascimento do código.
 ## 🔐 Segurança e VPN
@@ -25,7 +25,7 @@ Todo arquivo `.vps_identity` deve conter exatamente a seguinte estrutura:
  "vps_id": 4,
  "vps_name": "VPS-4-LABORATORIO",
  "ip_vpn": "10.99.0.4",
-  "role": "Desenvolvimento, Builds e Staging",
+  "role": "Desenvolvimento, Builds e Dev",
  "danger_level": "BAIXO - Liberdade para testar e recriar"
 }
 ```
@@ -34,7 +34,7 @@ Todo arquivo `.vps_identity` deve conter exatamente a seguinte estrutura:
 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.
+   - **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 dev.
 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...
@@ -52,7 +52,7 @@ Sempre que um novo projeto for criado no ecossistema Swarm, os agentes **não pr
 > 1. Você **NÃO DEVE** criar Webhooks via API no repositório individual para evitar conflitos.
 > 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/<nome-do-projeto>/` seguindo o padrão rootless.
-> 4. **Exposição de Portas (VPS 4)**: Contêineres na VPS 4 não devem mapear a porta `80` ou `443` diretamente no Host físico, para evitar conflitos com múltiplos projetos de staging. Use redes internas ou labels (Docker Overlay) para que a **VPS 1 (Traefik)** faça o encaminhamento do tráfego.
+> 4. **Exposição de Portas (VPS 4)**: Contêineres na VPS 4 não devem mapear a porta `80` ou `443` diretamente no Host físico, para evitar conflitos com múltiplos projetos de dev. Use redes internas ou labels (Docker Overlay) para que a **VPS 1 (Traefik)** faça o encaminhamento do tráfego.
 > 5. **Bancos de Dados**: É terminantemente **proibido** subir contêineres de Banco de Dados (`postgres`, `mysql`, etc) localmente nos projetos da VPS 4. Todos os serviços devem obrigatoriamente apontar para a VPS 3 (10.99.0.3).
 ## 🗣️ Comunicação
@@ -70,8 +70,8 @@ Os seguintes diretórios são de infraestrutura e serviços críticos ativos e *
 *   📁 `/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:
+Os seguintes diretórios dentro de `/home/deploy/stack/` contêm contêineres de desenvolvimento e dev ativos e **DEVEM SER ESTRITAMENTE PRESERVADOS** na VPS 4:
-*   📁 `scoreodonto.com/`: Aplicação e contêineres de staging do ecossistema ScoreOdonto.
+*   📁 `scoreodonto.com/`: Aplicação e contêineres de dev 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.
@@ -120,7 +120,7 @@ Em vez de criar Webhooks de push repetitivos para cada repositório das aplicaç
 Para mantermos o ecossistema no estado da arte de DevOps, utilizamos os seguintes recursos globais do Gitea:
 *   📁 **Gitea Organizations (Organizações - ex: clube67)**: Agrupa todos os repositórios sob um único tenant corporativo, permitindo gerenciar permissões de equipes (Teams) e IAs de uma única vez para todos os projetos.
 *   🔑 **Personal Access Tokens (PAT - Nível de Usuário)**: Criação de um Token de Acesso único do usuário administrador injetado na RAM dos agentes, dando autorização de API para ler issues, wikis e logs de todos os repositórios atuais e futuros de forma centralizada.
-*   🏷️ **Rótulos Padrão (Global Labels)**: Padronização de etiquetas de Issues (ex: `bug-self-healing`, `deploy-staging`, `security-incident`, `Autônomo`) herdadas automaticamente por qualquer novo repositório, agilizando a triagem de erros.
+*   🏷️ **Rótulos Padrão (Global Labels)**: Padronização de etiquetas de Issues (ex: `bug-self-healing`, `deploy-dev`, `security-incident`, `Autônomo`) herdadas automaticamente por qualquer novo repositório, agilizando a triagem de erros.
 ---
@@ -1,26 +1,26 @@
-# 🚀 Protocolo de Deploy, Staging e Governança Swarm
+# 🚀 Protocolo de Deploy, Dev e Governança Swarm
-Este documento define o fluxo obrigatório para garantir a integridade dos ambientes de Staging e Produção, além de normatizar a governança das Issues e Wikis no Gitea.
+Este documento define o fluxo obrigatório para garantir a integridade dos ambientes de Dev e Produção, além de normatizar a governança das Issues e Wikis no Gitea.
 ---
-## 🏗️ 1. A Estrutura de Ambientes e Roteamento de Staging
+## 🏗️ 1. A Estrutura de Ambientes e Roteamento de Dev
-1.  **Desenvolvimento e Staging (VPS 4 - IP 10.99.0.4)**:
+1.  **Desenvolvimento e Dev (VPS 4 - IP 10.99.0.4)**:
    *   Ambiente de **Nível de Perigo BAIXO**.
    *   Todo build local, compilação de frontends e contêineres de testes rodam isolados aqui.
-    *   **Regra Universal de Domínios de Staging**: Para qualquer domínio (seja subdomínio sob `clube67.com` ou domínio próprio de clientes), o domínio de staging é formado obrigatoriamente adicionando o prefixo **`staging.`** à frente do domínio principal.
+    *   **Regra Universal de Domínios de Dev**: Para qualquer domínio (seja subdomínio sob `clube67.com` ou domínio próprio de clientes), o domínio de dev é formado obrigatoriamente adicionando o prefixo **`dev.`** à frente do domínio principal.
-    *   **Tabela de Roteamento e Bancos de Staging (VPS 4)**:
+    *   **Tabela de Roteamento e Bancos de Dev (VPS 4)**:
-        *   **Porta `8081`**: Mercado (Domínio: `staging.mercado.clube67.com` | Banco de Dados: `mercado_staging`)
+        *   **Porta `8081`**: Mercado (Domínio: `dev.mercado.clube67.com` | Banco de Dados: `mercado_dev`)
-        *   **Porta `8082`**: ScoreOdonto (Domínio: `staging.scoreodonto.com` | Banco de Dados: `scoreodonto_staging`)
+        *   **Porta `8082`**: ScoreOdonto (Domínio: `dev.scoreodonto.com` | Banco de Dados: `scoreodonto` — ⚠️ **o MESMO da produção**, não há banco de dev isolado). Ver `scoreodonto/DEPLOY-PRODUCAO.md`.
-        *   **Porta `8083`**: NewWhats (Domínio: `staging.newwhats.clube67.com` | Banco de Dados: `newwhats_staging`)
+        *   **Porta `8083`**: NewWhats (Domínio: `dev.newwhats.clube67.com` | Banco de Dados: `newwhats_dev`)
    *   **Obrigatoriedade de Homologação (Domínio Coringa)**:
-        *   O subdomínio `staging.` atua como o ambiente **coringa e obrigatório** de homologação.
+        *   O subdomínio `dev.` atua como o ambiente **coringa e obrigatório** de homologação.
-        *   ⚠️ **É TERMINANTEMENTE PROIBIDO** realizar qualquer deploy ou sincronização direta da VPS 4 (Staging/Desenvolvimento) para a VPS 1 (Produção) sem que as alterações tenham sido previamente implantadas no contêiner de Staging da VPS 4, apontando para o seu respectivo banco de staging (ex: `scoreodonto_staging`), e exaustivamente testadas.
+        *   ⚠️ **É TERMINANTEMENTE PROIBIDO** realizar qualquer deploy ou sincronização direta da VPS 4 (Dev/Desenvolvimento) para a VPS 1 (Produção) sem que as alterações tenham sido previamente implantadas no contêiner de Dev da VPS 4, apontando para o seu respectivo banco de dev (ex: `mercado_dev`), e exaustivamente testadas.
        *   Esta homologação prévia é o único escudo que evita downtime e bugs para os usuários finais no contêiner de produção.
 2.  **Produção (VPS 1 - IP 10.99.0.1)**:
    *   Ambiente **CRÍTICO - Nível de Perigo ALTO**.
-    *   Apenas artefatos homologados e estáveis de staging são despachados para cá.
+    *   Apenas artefatos homologados e estáveis de dev são despachados para cá.
 ---
@@ -32,7 +32,7 @@ A VPS 1 (Produção) é uma máquina reservada estritamente para a execução le
 1.  ❌ **É EXPRESSAMENTE PROIBIDO rodar `npm run build`, `yarn build`, `docker build`, `next build` ou qualquer script de compilação, empacotamento, empacotadores (bundlers) ou transpilação (TypeScript/Babel) diretamente na VPS 1.**
 2.  🚀 **Onde o Build DEVE Ocorrer?**
-    Todo e qualquer processo de compilação, build, empacotamento e geração de contêineres deve ocorrer **exclusivamente na VPS 4 (Staging/Laboratório)**.
+    Todo e qualquer processo de compilação, build, empacotamento e geração de contêineres deve ocorrer **exclusivamente na VPS 4 (Dev/Laboratório)**.
 3.  📦 **Como os artefatos chegam na VPS 1?**
    O deploy na VPS 1 deve ser realizado unicamente por importação de artefatos já pré-compilados:
    - **Artefatos Estáticos / Bundles**: O código é compilado na VPS 4 (gerando a pasta `/dist` ou `/build` compactada). O pacote compactado é transferido via rede interna (SCP/Rsync) para a VPS 1, que apenas descompacta e roda os arquivos estáticos, sem realizar nenhuma compilação local.
@@ -56,18 +56,18 @@ Para permitir a colaboração fluida entre as VPSs e agentes sem causar conflito
 ---
-## 📋 3. Fluxo de Homologação em Duas Etapas (Staging ➔ Produção)
+## 📋 3. Fluxo de Homologação em Duas Etapas (Dev ➔ Produção)
-### 🔄 Passo 1: Deploy Automático em Staging (VPS 4)
+### 🔄 Passo 1: Deploy Automático em Dev (VPS 4)
 *   Ao realizar um `git push` no repositório do projeto, o webhook do Gitea dispara a compilação local na VPS 4.
-*   O contêiner de Staging é iniciado e exposto localmente sob o subdomínio `staging.mercado.clube67.com` (ou similar) na porta correspondente para homologação.
+*   O contêiner de Dev é iniciado e exposto localmente sob o subdomínio `dev.mercado.clube67.com` (ou similar) na porta correspondente para homologação.
 *   **Nenhum dado é despachado para a VPS 1 neste momento.**
 ### 🏁 Passo 2: Validação e Smoke Test
-*   O humano (ou a IA assistente) acessa a URL de staging na VPS 4, realiza testes completos e valida as novas funcionalidades.
+*   O humano (ou a IA assistente) acessa a URL de dev na VPS 4, realiza testes completos e valida as novas funcionalidades.
 ### 🚚 Passo 3: Promoção Manual para Produção (VPS 1)
-*   Somente após validação completa em Staging, executa-se o script de promoção manual `deploy-to-prod.sh`.
+*   Somente após validação completa em Dev, executa-se o script de promoção manual `deploy-to-prod.sh`.
 *   Esse script sincroniza os arquivos compilados da VPS 4 para a VPS 1 via `rsync` de forma limpa, reiniciando os contêineres na VPS 1 em menos de 10 segundos.
 ---
@@ -111,7 +111,7 @@ Sempre que um domínio ou subdomínio for clonado para dar origem a um novo ambi
        *   Criar um banco exclusivo (`CREATE DATABASE {nome_clone};`).
        *   Criar um usuário exclusivo com senha aleatória e segura (`CREATE USER {user_clone} WITH PASSWORD '{senha}';`).
        *   Nunca reaproveite credenciais ou usuários existentes de outros tenants.
-*   📁 **Nomenclatura Consistente**: O nome do banco de dados, usuário, contêiner e volumes no disco devem seguir um padrão idêntico ao do novo subdomínio/domínio (ex: se o projeto `staging.scoreodonto.com` tiver a duplicação do banco solicitada, deve usar banco `scoreodonto_staging`).
+*   📁 **Nomenclatura Consistente**: O nome do banco de dados, usuário, contêiner e volumes no disco devem seguir um padrão idêntico ao do novo subdomínio/domínio (ex: se o projeto `dev.mercado.clube67.com` tiver a duplicação do banco solicitada, deve usar banco `mercado_dev`).
 ---
@@ -196,7 +196,7 @@ fi
 ## 🛡️ Pilar 6: Micro-segmentação de Rede e Firewall Restritivo (SecOps)
-Para evitar a movimentação lateral caso qualquer VPS de staging (como a VPS 4) seja comprometida, a **VPS 3 (Cérebro)** possui uma política rígida de firewall (UFW) baseada no **Princípio do Menor Privilégio a Nível de Rede**.
+Para evitar a movimentação lateral caso qualquer VPS de dev (como a VPS 4) seja comprometida, a **VPS 3 (Cérebro)** possui uma política rígida de firewall (UFW) baseada no **Princípio do Menor Privilégio a Nível de Rede**.
 ### Configuração do Firewall da VPS 3 (`wg0`):
@@ -1,7 +1,7 @@
-# 🏗️ Template Nginx Wildcard para Staging (VPS 1)
+# 🏗️ Template Nginx Wildcard para Dev (VPS 1)
 # Este mapeamento associa o subdomínio à porta na VPS 4
-map $project_slug $staging_port {
+map $project_slug $dev_port {
    mercado      8081;
    scoreodonto  8082;
    newwhats     8083;
@@ -10,7 +10,7 @@ map $project_slug $staging_port {
 server {
    listen 80;
-    server_name ~^(?<project_slug>.+)\.staging\.clube67\.com$;
+    server_name ~^(?<project_slug>.+)\.dev\.clube67\.com$;
    # Redirecionamento para HTTPS
    return 301 https://$host$request_uri;
@@ -18,7 +18,7 @@ server {
 server {
    listen 443 ssl;
-    server_name ~^(?<project_slug>.+)\.staging\.clube67\.com$;
+    server_name ~^(?<project_slug>.+)\.dev\.clube67\.com$;
    # Certificados SSL (Substituir pelos caminhos reais do Let's Encrypt Wildcard)
    ssl_certificate /etc/letsencrypt/live/clube67.com/fullchain.pem;
@@ -26,7 +26,7 @@ server {
    location / {
        # Encaminha o tráfego via VPN para a VPS 4
-        proxy_pass http://10.99.0.4:$staging_port;
+        proxy_pass http://10.99.0.4:$dev_port;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
@@ -145,7 +145,7 @@ Definimos o **`MTU = 1360`** (ou `1280` para máxima resiliência) em todos os a
   ```
   *Reinicie o serviço:* `sudo systemctl restart wg-quick@wg0`
-3. **Nas VPSs 4 e 5 (Staging e CRM - REQUER APLICAR):**
+3. **Nas VPSs 4 e 5 (Dev e CRM - REQUER APLICAR):**
   Repita o mesmo procedimento adicionando `MTU = 1360` sob `[Interface]` em seus respectivos `/etc/wireguard/wg0.conf` e reinicie a interface.
 > [!TIP]
@@ -96,7 +96,7 @@ host    newwhats          newwhats_user     10.99.0.5/32            scram-sha-25
 # 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. Permitir conexões de replicação da VPS 4 (Staging/Replica)
+# 4. Permitir conexões de replicação da VPS 4 (Dev/Replica)
 host    replication       replicator        10.99.0.4/32            scram-sha-256
 # 5. Bloqueio preventivo total para qualquer outro IP ou usuário
@@ -200,7 +200,7 @@ host    facebook_db       facebook_user     10.99.0.1/32            scram-sha-25
 # 4. Projeto NEWWHATS (Backend na VPS 5 -> Banco na VPS 3)
 host    newwhats          newwhats_user     10.99.0.5/32            scram-sha-256
-# 5. Permitir conexões de replicação da VPS 4 (Staging/Replica)
+# 5. Permitir conexões de replicação da VPS 4 (Dev/Replica)
 host    replication       replicator        10.99.0.4/32            scram-sha-256
 # 6. BLOQUEIO PADRÃO TOTAL (Zero-Trust)