2.5 GitHub + config set | Agente Hermes

💾 Por que conectar GitHub

Hermes acumula valor com o tempo: meses de feedback, dezenas de skills criadas, memória rica, configurações refinadas. Perder isso por uma falha de hardware ou um docker compose down -v errado é traumático. Git resolve com zero esforço operacional após setup.

🎁O que você ganha

Backup completo: SKILL.md, MEMORY.md, USER.md, SOUL.md, config.yaml versionados
Resiliência: VPS pegou fogo? git clone em outro servidor, restore em minutos
Histórico: ver evolução das suas skills ao longo de meses, fazer rollback
Compartilhamento: múltiplos agentes apontam pro mesmo repo de skills
Confiança pra experimentar: testou skill nova quebrou tudo? git checkout volta

🧠Mental model

Repo privado = ninguém vê (mesmo se username conhecido). Você = único developer + único usuário do agente. Commit message = "snapshot do dia X". Push automático via cron = backup contínuo sem você lembrar.

🔐 Personal Access Token (PAT)

GitHub aposentou autenticação por senha em 2021. Hoje usa Personal Access Token. Existem dois tipos: classic (mais antigo, escopos amplos) e fine-grained (mais novo, escopo cirúrgico). Sempre prefira fine-grained.

📍 Onde criar

GitHub → Foto perfil (canto superior direito)
       → Settings
       → Developer settings (rolar até o fim do menu lateral)
       → Personal access tokens
       → Fine-grained tokens
       → Generate new token

✓ Configuração recomendada

Expiration: 90 dias (renovação periódica força revisão)
Repository access: Only select repositories → seu repo do Hermes
Permissions: Contents: Read and write, Metadata: Read
Nada além disso — sem Workflows, sem Issues, sem Actions

✗ Configuração arriscada

Classic token com repo scope: acesso a TODOS seus repos
Sem expiração: esquecer de revogar é fácil
"All repositories": escopo amplo demais para 1 agente
Workflows + admin: token vazado pode mexer em CI/CD

💡Princípio do menor privilégio

Token cirúrgico limita o estrago se vazar. Pense: "Se esse token caísse na rede agora, qual seria o pior cenário?" Com fine-grained limitado, o pior é alguém alterar um repo seu — recuperável via histórico. Com classic repo, alguém apaga tudo.

🚨 NUNCA cole token no chat do agente

Esse é o erro mais comum de quem está começando. Tokens colados no chat acabam no histórico SQLite, em logs, em sessões pesquisáveis. A forma certa é usar hermes config set, que escreve em local seguro com auto-redação aplicada.

❌O que NÃO fazer

# ERRADO — token vai pro histórico em texto puro
"Use o token ghp_xxxxxxxxxxxxxxx pra fazer push"

# ERRADO — log SQLite captura tudo
"Salva esse token na memória: ghp_xxx"

✅A forma correta

# 1. Setar via config set (escreve em /root/.hermes/.env, com redação)
docker exec -it hermes hermes config set GITHUB_TOKEN ghp_xxxxxxxxxxxxxxx

# 2. Verificar (mostra valor mascarado)
docker exec hermes hermes config get GITHUB_TOKEN

# 3. Restart pra Hermes reler o .env
docker compose restart

# 4. Agora você pode pedir no chat sem expor o token:
"Faça commit e push do estado atual do agente"

🛡️Auto-redação de logs

Hermes redige automaticamente secrets conhecidos em ~/.hermes/logs/errors.log e gateway.log. Mas isso só funciona pra valores que ele sabe que são secret — variáveis de ambiente terminadas em _TOKEN, _KEY, etc. Cola em chat livre não passa pela redação.

🚫 .gitignore: bloquear .env, secrets, state.db

Antes de qualquer git add ., crie o .gitignore certo. Commit acidental de .env é o erro mais comum em VPS pessoal — uma vez no repo, mesmo apagando depois, ele permanece no histórico para sempre.

📄 .gitignore mínimo para Hermes

# .env e variantes
.env
.env.*
!.env.example

# Banco de sessões SQLite + auxiliares
state.db
state.db-*
*.db-journal
*.db-wal
*.db-shm

# Logs (geralmente grandes e mutáveis)
logs/
*.log

# Permissões e tokens em cache
permissions.json
.tick.lock
auth_cache/

# Chaves criptográficas
*.key
*.pem
*.p12
id_rsa*
id_ed25519*

# OS / editor
.DS_Store
Thumbs.db
*.swp
*.swo
.idea/
.vscode/

🚨Se já commitou .env por engano

Revogue IMEDIATAMENTE todos os tokens/secrets que estavam ali (GitHub Settings → revoke)
Gere novos tokens com escopo cirúrgico
Atualize ~/.hermes/.env com os novos via hermes config set
Use git filter-repo ou BFG pra remover do histórico
Force push (cuidado): git push --force-with-lease

Mas saiba: se foi pra repo público mesmo por 1 minuto, bots de scraping já capturaram. Prevenção > remediação.

🤝 Peça pro Hermes configurar tudo

Aplicação direta da mentalidade da T1.2: pergunte ao próprio Hermes. A skill github bundled já sabe criar repo via API, gerar .gitignore correto, fazer primeiro commit. Você não precisa decorar comandos git.

💬 Prompt completo via Telegram

"Configure este agente como repo privado no GitHub chamado hermes-pessoal-backup. Crie .gitignore bloqueando .env, .env.*, state.db, state.db-*, logs/, *.log, permissions.json, *.key, *.pem. Faça primeiro commit incluindo SOUL.md, MEMORY.md, USER.md, config.yaml, e a pasta skills/. Configure remote e push. Me mostre o link do repo no final."

✓O que vai acontecer

Hermes carrega skill github via progressive disclosure
Cria repo privado via API GitHub usando seu token
Gera .gitignore incluindo os patterns que você pediu
Vai pedir permissão pra rodar git init, git commit, git push — aprove com session
Te devolve o link do repo

⚠️Antes de aprovar permissão "always"

Revise o .gitignore que ele propôs. Se faltar algo (ex: ele esqueceu auth_cache/), peça pra adicionar. Só marque always allow pra git push quando o setup estiver validado e você tiver certeza que .env está bloqueado. Um cron de backup só funciona com always allow — mas vale a pena testar manual primeiro.

📂 .env do container vs .env do host

Existem DOIS arquivos .env e confundi-los é fonte clássica de horas perdidas debugando. O Hermes lê o do container. Edita o do host = mudança não tem efeito.

📍 Os dois .env

Arquivo	Quem lê	Quando se aplica
`~/hermes-deploy/.env` (host)	docker compose	Subida do container, injeta env vars iniciais
`/root/.hermes/.env` (container)	O Hermes em runtime	Sempre que precisa de TOKEN, KEY, etc

✏️ Editar / deletar key

# Forma recomendada — config set
docker exec -it hermes hermes config set GITHUB_TOKEN ghp_novo
docker compose restart

# Edição manual (se precisar)
docker exec -it hermes nano /root/.hermes/.env
# remove ou altera linha
# salva, sai (Ctrl+O, Ctrl+X)
docker compose restart

# Ver o que está ativo
docker exec hermes hermes config get GITHUB_TOKEN  # mascarado
docker exec hermes env | grep GITHUB

🤔Sintoma típico de confusão

"Mudei o token no .env mas o Hermes continua usando o antigo." Você editou o .env errado (do host) ou esqueceu de fazer docker compose restart. Sempre: config set + restart, ou edit no container + restart. Esquecer o restart é o erro #2 mais comum.

💡Regra mnemônica

Host .env = receita pra subir container. Mexe raramente. Container .env = configuração do agente em runtime. Mexe sempre via config set. Sempre restart depois de qualquer mudança.

🎯Resumo do módulo

✓

GitHub é backup vivo do agente — skills, memória, config viajam entre VPSs.

✓

Fine-grained PAT > classic — escopo cirúrgico (1 repo, contents R/W), expiração 90 dias.

✓

Token via config set, NUNCA no chat — auto-redação só protege quem segue a regra.

✓

.gitignore antes do primeiro commit — .env, state.db, logs, *.key bloqueados.

✓

.env do container ≠ .env do host — Hermes lê o do container; sempre restart após editar.

Próximo módulo:

2.6 - 🌙 Primeiro cron: backup diário automático

← Módulo Anterior Próximo Módulo →