docs: implement strict Fail-Safe Stop Protocol and absolute build ban on VPS 1 in staging and deploy protocol

2026-05-18 22:12:04 +02:00
parent 687e71be9b
commit a121c70d2c
2 changed files with 32 additions and 0 deletions
@@ -6,6 +6,22 @@ Como a arquitetura adota segurança **Zero-Trust de movimentação lateral** (im

 ---

+## 🚨 PROTOCOLO DE PARADA IMEDIATA E PÂNICO (FAIL-SAFE MANDATÓRIO)
+**ATENÇÃO AGENTE DE IA: ESTA REGRA TEM PRIORIDADE MÁXIMA SOBRE TODAS AS OUTRAS.**
+
+Se durante a análise local, leitura de código, mapeamento de banco de dados ou execução de qualquer tarefa você encontrar:
+1. Qualquer divergência entre o estado real do servidor e o que está escrito na Wiki/Documentação.
+2. Arquivos de configuração, variáveis de ambiente ou credenciais ausentes ou diferentes das esperadas.
+3. Comandos que retornem erros inesperados ou comportamentos fora do padrão arquitetado.
+
+**VOCÊ DEVE OBRIGATORIAMENTE PARAR TODA E QUALQUER OPERAÇÃO DE ESCRITA OU MODIFICAÇÃO IMEDIATAMENTE!**
+
+*   ❌ **NÃO tente adivinhar, supor, improvisar ou "consertar" na tentativa e erro.**
+*   ❌ **NÃO tome nenhuma iniciativa sem aprovação humana quando o ambiente real divergir da documentação.**
+*   👉 **SUA ÚNICA AÇÃO PERMITIDA:** Interrompa a execução, relate em português claro a divergência exata encontrada, formate uma lista objetiva de perguntas para o Administrador e **aguarde instruções explícitas do Humano antes de tocar em qualquer arquivo!**
+
+---
+
 ## 🧭 REGRA MESTRE DE ROTEAMENTO (DISPATCHER PROTOCOL)
 **ATENÇÃO AGENTE DE IA:** Esta infraestrutura hospeda múltiplos projetos independentes (Multi-Tenant). Antes de tomar qualquer ação, você deve ler a arquitetura e as regras **específicas** do projeto solicitado.

@@ -20,6 +20,22 @@ Este documento define o fluxo obrigatório para garantir a integridade dos ambie

 ---

+## 🚨 LEI DE OURO: PROIBIÇÃO ABSOLUTA DE BUILD NA VPS 1 (PRODUÇÃO)
+
+**ATENÇÃO AGENTE: ESTA REGRA É INVIOLÁVEL, CRÍTICA E MANDATÓRIA.**
+
+A VPS 1 (Produção) é uma máquina reservada estritamente para a execução leve de serviços críticos em produção. Ela não possui recursos nem permissão para rodar rotinas de compilação pesadas.
+
+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)**.
+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.
+    - **Imagens Docker Prontas**: A imagem é gerada (`docker build`) na VPS 4 e enviada para um Registry. A VPS 1 faz apenas `docker pull` da imagem pronta e inicia o contêiner de forma leve e rápida.
+
+---
+
 ## 🛡️ 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: