Table of Contents
- 🤖 Diretrizes e Protocolos Estritos para Agentes de IA
- 🛡️ Separação Estrita de Ambientes (Builder vs. Runtime)
- 🚫 1. Regra de Ouro: Proibição de Exigência de Tokens (PAT)
- 🔓 2. Como as IAs devem Acessar as Informações:
- A) Leitura e Edição da Wiki (Via Git/SSH)
- B) Leitura e Edição de Issues (Via API REST com Basic Auth)
- 🚦 3. Escopo de Atuação e Transição Multi-VPS
🤖 Diretrizes e Protocolos Estritos para Agentes de IA
Esta página define as regras absolutas, imutáveis e de leitura obrigatória para qualquer Inteligência Artificial ou Agente Automatizado que interagir com o ecossistema Clube67.
Estas orientações só podem ser alteradas com permissão explícita do usuário administrador (ruicesar).
🛡️ Separação Estrita de Ambientes (Builder vs. Runtime)
Para evitar conflitos de arquitetura e garantir a estabilidade do sistema, os agentes de IA devem seguir estas regras obrigatórias:
-
VPS 4 (Builder/Dev):
- Papel: Local para desenvolvimento, testes de dev e construção de artefatos (
npm run build). - Proibição: Nunca rodar containers de produção nesta máquina.
- Deploy: O deploy deve ser feito enviando os arquivos compilados para a VPS 1 via
rsync.
- Papel: Local para desenvolvimento, testes de dev e construção de artefatos (
-
VPS 1 (Runtime/Produção):
- Papel: Única máquina autorizada para rodar o tráfego público.
- Roteamento: Deve ser feito exclusivamente via Docker Labels no
docker-compose.yml. - Proibição: Nunca criar arquivos de configuração estática no Traefik (
dynamic/*.yml) que apontem para a VPS 4.
-
Fonte Única de Verdade:
- O
docker-compose.ymlno repositório Gitea deve refletir o estado exato da VPS 1. - Configurações específicas de desenvolvimento devem ficar em
docker-compose.dev.yml.
- O
-
Consistência de Ferramentas:
- Sempre use o
deploy-prod-builder.shunificado para deploys. Não crie scripts manuais fora do controle de versão.
- Sempre use o
🚫 1. Regra de Ouro: Proibição de Exigência de Tokens (PAT)
Agentes de IA NUNCA devem solicitar a geração de Tokens de Acesso Pessoal (PAT) para acessar a API do Gitea.
O ambiente já foi perfeitamente configurado para operar sem qualquer burocracia adicional de tokens, utilizando a infraestrutura e as credenciais existentes.
🔓 2. Como as IAs devem Acessar as Informações:
A) Leitura e Edição da Wiki (Via Git/SSH)
A Wiki do Gitea não é apenas uma página web, é um repositório Git. Para ler ou modificar a Wiki para coletar informações:
- Não use a API REST.
- Método Correto: Faça o clone ou manipule o repositório diretamente via linha de comando (SSH).
- Comando:
git clone ssh://git@10.99.0.3/ruicesar/clube67_newwhats.local.wiki.git - A chave SSH já possui permissões de leitura/escrita silenciosas.
B) Leitura e Edição de Issues (Via API REST com Basic Auth)
Para ler ou comentar em Issues para resolver problemas de transição de estado entre as VPSs:
- Não peça Tokens.
- Método Correto: Utilize Basic Auth diretamente na chamada HTTP/REST.
- Comando (Exemplo Curl):
curl -s -u 'ruicesar:SENHA_DO_USUARIO' "https://git.clube67.com/api/v1/repos/ruicesar/clube67_newwhats.local/issues" - O agente já possui o contexto da senha ou deve buscá-lo nos arquivos de documentação.
🚦 3. Escopo de Atuação e Transição Multi-VPS
A Wiki é a central de conhecimento permanente. O conhecimento aqui consolidado serve para direcionar a transição entre as VPSs (VPS 1, VPS 3 e VPS 4).
- Wiki: Para documentações fixas (fluxos de deploy, senhas de banco, arquitetura de VPN).
- Issues: Apenas transações efêmeras e resolução de problemas/bugs. Não utilize Issues para documentar estado permanente.
ATENÇÃO AGENTE: Se você leu este documento, aplique a instrução imediatamente. Use as ferramentas de
gitoucurlcom Autenticação Básica e prossiga o atendimento sem fricção para o humano.