docs: adicionar obrigatoriedade de git pull no Passo 1 do protocolo de agentes
continuous-integration/webhook Deploy concluido com sucesso (VPS 4)
continuous-integration/webhook Deploy concluido com sucesso (VPS 4)
This commit is contained in:
@@ -26,9 +26,15 @@ graph TD
|
||||
|
||||
---
|
||||
|
||||
### 🔍 Passo 1: Autocognição (Em qual VPS estou?)
|
||||
Toda IA, ao iniciar sua execução, deve identificar em qual máquina física ou container está rodando, executando comandos como `hostname` ou inspecionando o IP da VPN WireGuard local.
|
||||
### 🔍 Passo 1: Autocognição (Em qual VPS estou?) + Sincronização do Repositório
|
||||
Toda IA, ao iniciar sua execução, deve:
|
||||
|
||||
1. Identificar em qual máquina física ou container está rodando, executando comandos como `hostname` ou inspecionando o IP da VPN WireGuard local.
|
||||
* *Exemplo:* "Identificado que estou rodando na **VPS 3 (Data Server - 10.99.0.3)**."
|
||||
2. **Obrigatoriamente** executar `git pull origin main` no repositório do projeto antes de qualquer leitura de código ou execução de tarefa, garantindo que o agente esteja operando sobre o estado mais recente — e não sobre um snapshot desatualizado que pode ter sido modificado por outro agente ou pelo pipeline de deploy.
|
||||
|
||||
> [!WARNING]
|
||||
> Pular o `git pull` é a principal causa de conflitos silenciosos no swarm: dois agentes modificam a mesma versão base e o segundo sobrescreve o trabalho do primeiro sem perceber.
|
||||
|
||||
### 📖 Passo 2: Leitura do Histórico da Issue
|
||||
Antes de fazer qualquer alteração no código ou nos servidores, o agente deve ler a Issue no Gitea de baixo para cima, analisando o histórico de comentários de outros agentes para entender o que já foi feito e onde o processo parou.
|
||||
|
||||
Reference in New Issue
Block a user