docs: update staging protocol with label filters and deploy roadmaps

TAREFAS_SWARM.md

@@ -12,9 +12,15 @@ Este arquivo registra o progresso da automação multi-VPS.
 - [ ] **2.2 Roteamento de Porta**: Mapeamento dinâmico Subdomínio -> Porta na VPS 4.
 
 ## 🟡 Fase 3: Listeners e Agentes
-- [ ] **3.1 Swarm Listener (VPS 1/4)**: Daemon de escuta do Redis.
+- [x] **3.1 Swarm Listener (VPS 4)**: Daemon de escuta do Redis (`swarm_listener.py`).
 - [ ] **3.2 Executor MCP**: Script que instancia a IA com ferramentas MCP.
-- [ ] **3.3 Systemd Services**: Persistência dos listeners.
+- [x] **3.3 Systemd Services**: Persistência ativa do listener via systemd (`swarm-listener.service`).
+
+## 🛡️ 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`.
+- [ ] **4.2 Isolamento de Deploy**: Alterar `deploy-prod-builder.sh` para implantar localmente na VPS 4 sob `staging.mercado.clube67.com`.
+- [ ] **4.3 Script de Promoção**: Criar `deploy-to-prod.sh` para despache manual seguro Staging ➔ Produção.
 
 ---
-*Última atualização: 16/05/2026 - Agente Antigravity*
+*Última atualização: 17/05/2026 - Agente Antigravity*
+

global/protocolo_deploy_staging.md

@@ -1,36 +1,51 @@
-# 🚀 Protocolo de Deploy e Staging via VPN
+# 🚀 Protocolo de Deploy, Staging e Governança Swarm
 
-Este documento define o fluxo obrigatório para garantir que nenhum código quebre a produção.
+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.
-
-## 🏗️ A Estrutura de Ambientes
-1.  **Desenvolvimento (VPS 4)**: Testes locais e rápidos.
-2.  **Staging (VPS 4 + Proxy na VPS 1)**: Onde o código é testado em URL real com SSL.
-3.  **Produção (VPS 1)**: Onde o código estável reside.
-
-## 🌐 Roteamento de Staging
-Para testar o código em Staging antes do deploy final, siga este padrão de rede:
-
-- **Entrada**: Usuário acessa `https://staging.{projeto}.clube67.com` (aponta para o IP da VPS 1).
-- **Trânsito**: A VPS 1 (Proxy) encaminha o tráfego para a VPS 4 através da VPN.
-- **Destino**: `http://10.99.0.4:{PORTA_STAGING}`.
-
-## 📋 Passo a Passo do Deploy Seguro
-
-### Passo 1: Preparação em Staging (VPS 4)
-- O agente deve subir o container de staging na VPS 4.
-- A porta deve ser única por projeto (conforme definido em `arquitetura.md` do projeto).
-
-### Passo 2: Configuração do Proxy (VPS 1)
-- O agente deve acessar a VPS 1 e adicionar/verificar a configuração de Proxy Reverso apontando para o IP `10.99.0.4`.
-- Garantir que o certificado SSL (Let's Encrypt) esteja ativo para o subdomínio `staging`.
-
-### Passo 3: Validação
-- O agente (ou humano) deve acessar a URL de staging e realizar o "Smoke Test" (teste de fumaça).
-- Se houver erro, a correção é feita na VPS 4, sem impacto na VPS 1.
-
-### Passo 4: Promoção para Produção (VPS 1)
-- Somente após validação em Staging, o código/imagem é puxado para a VPS 1.
-- O container principal é reiniciado.
 
 ---
-*Este protocolo é mandatório para evitar downtime em produção.*
+
+## 🏗️ 1. A Estrutura de Ambientes e Roteamento de Staging
+1.  **Desenvolvimento e Staging (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.
+    *   **Subdomínio Curinga**: `staging.mercado.clube67.com` (ou equivalentes) são apontados via Traefik local na VPS 4 para homologação rápida e segura sem contato com servidores externos.
+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á.
+
+---
+
+## 🛡️ 2. Governança de Organização (Wiki vs. Issues)
+
+Para permitir a colaboração fluida entre as VPSs e agentes sem causar conflitos de execução concorrente de código:
+
+### 📚 A. Wiki do Gitea (Estado Estável e Doutrina)
+*   **Finalidade**: Armazenar documentação duradoura de infraestrutura, topologia de rede, comandos de referência e a **Doutrina Swarm Mestre (v1.0.6)**.
+*   **Regra**: Nenhum agente de background deve alterar a Wiki de forma automatizada sem autorização humana explícita.
+
+### 🎫 B. Gitea Issues (Roadmaps e Implementação)
+*   As Issues servem para planejar tarefas e refatorações no ecossistema.
+*   **Filtro SecOps de Execução Autônoma**:
+    *   **Manual/Par-programming (Sem Etiqueta)**: Issues que nós (humano e IA do chat) estamos desenvolvendo **NÃO** devem possuir rótulos especiais.
+    *   **Autônomo (Com Etiqueta `Autônomo` ou `Swarm-Exec`)**: Apenas Issues com a etiqueta `Autônomo` ou com a tag `[Autônomo]` no título/corpo serão consumidas pelo executor automático de background [swarm_listener.py](file:///home/deploy/swarm_listener.py). 
+
+---
+
+## 📋 3. Fluxo de Homologação em Duas Etapas (Staging ➔ Produção)
+
+### 🔄 Passo 1: Deploy Automático em Staging (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.
+*   **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.
+
+### 🚚 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`.
+*   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.
+
+---
+
+*Este protocolo de governança e deploy é mandatório para todos os nós do enxame.*
+