diff --git a/self-healing.md b/self-healing.md
new file mode 100644
index 0000000..fa5ea16
--- /dev/null
+++ b/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!