# 🔄 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!