📖 Wiki — Diário de Bordo

Catálogo completo de todas as interações entre Juvenildo e Hermes Agent, desde a ativação.

137+
Ações Realizadas
15+
Problemas Corrigidos
11
Dias de Atividade
20+
Sistemas Configurados
🖥️ Ambiente: Oracle Cloud VPS — Ubuntu 24.04 ARM64 (4 núcleos, 23GB RAM, 193GB disco) — IP: 163.176.53.25
📧 Contas: Juvenildo1@gmail.com, valorruralconsultoria@gmail.com, juvenildo@senar-ro.org.br
🌐 Domínios: coocib.com, proxy.coocib.com, evolution.coocib.com, wiki.coocib.com, portainer.coocib.com

📅 Linha do Tempo 30 Mai — 11 Jun 2026

📅 30 de Maio de 2026 Instalação Inicial

🖥️ Instalação do NoMachine + XFCE

setup🕐 Sessão inicial

Instalação do ambiente gráfico remoto na VPS Oracle Cloud:

  • Instalação do XFCE4 + LightDM como gerenciador de desktop
  • Instalação do NoMachine (servidor de acesso remoto) na porta 4000
  • Configuração de display virtual para acesso headless (VPS sem monitor físico)
  • Firewall configurado para liberar porta 4000 TCP/UDP
💡 Por que NoMachine? Alternativa ao VNC/RDP com melhor performance em conexões de baixa latência. O XFCE foi escolhido por ser leve (consome ~300MB vs 1GB+ do GNOME).

🔐 Configuração SSH e Acesso

setup

Estabelecido acesso SSH direto ao VPS para o assistente Hermes:

  • Senha SSH: cecilia (usuário ubuntu)
  • IP público: 163.176.53.25
  • IP interno: 10.0.0.174

📅 01 de Junho de 2026 Ativação do Hermes

🤖 Primeira Ativação do Hermes Agent

setup🕐 12:56

Ativação inicial do assistente Hermes no VPS. Configuração base:

  • Instalação do Hermes Agent no VPS Oracle Cloud
  • Integração com Telegram (chat ID: 8722235969)
  • Modelo inicial: Claude Sonnet via Anthropic
  • Configuração do sistema de memória persistente (SQLite)

🐳 Docker e Portainer

setup

Ambiente de containers configurado:

  • Docker instalado e rodando na VPS
  • Portainer CE na porta 9000 (gerenciador visual de containers)
  • Credenciais Portainer: juvenildo (admin)
  • Domínio: portainer.coocib.com com HTTPS

🌐 Nginx Proxy Manager

setup

Proxy reverso com interface visual:

  • NPM rodando nas portas 80, 443, 81 (admin)
  • Domínio: proxy.coocib.com
  • Certificados SSL automáticos via Let's Encrypt

📧 Limpeza Automática de E-mails (Social)

feature🕐 21:22

Criado o primeiro cron job do Hermes:

  • Job 04b510a4: Limpar e-mails categoria Social do Gmail
  • Execução diária às 8:00 BRT
  • Script Python usa IMAP para mover e-mails da categoria Social para lixeira
  • Primeira execução: removeu centenas de e-mails acumulados
🔑 Aprendizado: Primeiro uso do sistema de cron jobs do Hermes. Jobs rodam em sessões isoladas, sem acesso ao histórico da conversa — precisam ser totalmente autossuficientes.

📬 Resumo Diário de E-mails

feature🕐 21:27

Criado job 339e6b8a: Resumo diário da caixa de entrada principal:

  • Execução diária às 9:00 BRT
  • Lê todos os e-mails das últimas 24h do INBOX
  • Extrai remetente, assunto e resumo do corpo
  • Envia resumo formatado via Telegram

📅 04 de Junho de 2026 Evolution API + WhatsApp

📱 Instalação Evolution API v1.8.6

setup🕐 21:46

API de WhatsApp não-oficial instalada via Docker:

  • Imagem: atendai/evolution-api:v1.8.6 (ARM64)
  • Porta: 8080
  • Domínio: evolution.coocib.com com HTTPS
  • Volumes persistentes: evolution_instances e evolution_store
  • API Key configurada: juvenildo_evolution_key_2024
⚠️ Pitfall descoberto posteriormente: A API key foi truncada pelo Docker para juveni...2024 (com 3 pontos literais). A key correta a ser usada nas chamadas é a versão truncada!

📲 Criação Instâncias WhatsApp

feature

Duas instâncias WhatsApp pareadas via QR Code:

  • Juvenildo-pessoal — número pessoal
  • Juvenildo-Senar — número profissional SENAR
  • Conexão via QR Code escaneado pelo WhatsApp do celular
  • Estado: open (conectado)

📅 07 de Junho de 2026 Sistema de Memória WhatsApp

🧠 Bridge WhatsApp → Hermes (Modo Observação)

feature🕐 manhã

Criado bridge Python para integrar WhatsApp ao Hermes:

  • Script: /home/ubuntu/evolution-bridge/bridge.py
  • Porta: 2999 (localhost)
  • Modo: somente observação — NÃO envia mensagens
  • Regra crítica: Hermes NÃO interage no WhatsApp, apenas monitora
  • Serviço systemd: evolution-bridge.service com auto-restart

💾 Banco de Dados de Memória WhatsApp

feature

Sistema completo de armazenamento e categorização:

  • SQLite database: /home/ubuntu/whatsapp-memory/memory.db (WAL mode)
  • Armazena: mensagens recebidas e enviadas, áudios, contatos
  • Threading de conversas: janela 48h (individual), 24h (grupos)
  • Sistema de Perfis com Histórico: somente contatos individuais
  • Categorizador automático de mensagens
  • Serviço: whatsapp-memory.service rodando 24/7

📊 Relatório de Monitoramento — 07/06

report

Primeiro relatório gerado:

  • 59 mensagens monitoradas, 5 áudios
  • Top contato: "nandreara kester" (48 mensagens)
  • OLX: sem novos leads no período

📅 08 de Junho de 2026 NFSe, NoMachine & Otimizações

🧾 Emissão de Nota Fiscal (NFS-e)

feature

Sistema de emissão de NFSe para o SENAR:

  • Última nota: N51 (08/06/2026, R$ 2.737,20)
  • Tomador: SENAR AR/RO (CNPJ 04.293.236/0001-14)
  • DANFE gerado como HTML (fallback — endpoint oficial retornava 500)
  • Notas salvas em: /home/ubuntu/notas_fiscais/
  • Skill: senar-emissao-nfse (com pitfall do DANFE documentado)
⚠️ Pitfall: Portal oficial da NFS-e retorna erro 500 ao gerar DANFE. Solução de fallback: gerar DANFE como HTML localmente usando os dados do JSON da nota.

🖥️ Correção NoMachine — Tela Preta

fix🕐 tarde

Problema: NoMachine conectava mas mostrava tela preta.

Diagnóstico:

  • Sessão fantasma no display 99 criada por Xvfb de jobs do Hermes
  • Processos travados de sessões anteriores

Solução:

  • Eliminada sessão fantasma: rm /tmp/.X99-lock
  • Limpos processos Xvfb órfãos
  • Reconfigurado NoMachine: CreateDisplay 1
  • Reiniciado XFCE e NoMachine
💡 Aprendizado: Nunca usar CreateDisplay 0 no server.cfg do NoMachine quando o display :0 já está em uso pelo XFCE físico. Isso causa conflito e tela preta.

⚡ Otimização Evolution API (Logs)

config🕐 15:00

Redução de logs para economizar RAM e disco:

  • LOG_LEVEL=ERROR,WARN (antes era DEBUG)
  • Removido Node.js bridge (desnecessário, só Python)
  • Apenas 1 bridge necessário (evolution-bridge)

📅 09 de Junho de 2026 Google Drive & Kanban

📂 Integração Google Drive (3 contas)

feature🕐 manhã

Desafio: Montar 3 contas Google Drive no VPS de forma persistente.

Tentativas frustradas:

  • Servidor Python público na porta 53682: timeout (firewall/bloqueio HTTP Google)
  • SOCAT para proxy público: porta já ocupada
  • Script Python com redirect OAuth: "não deu certo"

Solução final:

  • rclone authorize "drive" executado diretamente no navegador do VPS (via NoMachine/XFCE)
  • Redireciona para localhost (sem bloqueio do Google)
  • Token obtido com sucesso para juvenildo1@gmail.com

Resultado:

  • ✅ gdrive: → ~/GoogleDrive (juvenildo1@gmail.com)
  • ✅ gdrive_valor: → ~/GoogleDrive_Valor (valorruralconsultoria@gmail.com)
  • ✅ gdrive_senar: → ~/GoogleDrive_Senar (juvenildo@senar-ro.org.br)
  • Montagem automática via systemd (3 serviços)
  • Cache otimizado: full, 5GB disco, dir-cache 72h, buffer 64M
💡 Aprendizado: OAuth do Google bloqueia redirect HTTP e IPs de datacenter. A solução foi usar o navegador do próprio VPS (via NoMachine) onde o redirect vai para localhost e não é bloqueado.

📋 Kanban Nativo do Hermes

feature

Ativado Kanban integrado:

  • hermes kanban init — criado kanban.db com 9 tasks demo
  • Dashboard em http://127.0.0.1:9120
  • Removido site customizado kanban.coocib.com (não solicitado)
  • Limpeza: proxy host NPM, DNS Cloudflare, container Docker, arquivos locais

🔧 Correção Evolution API (Container Offline)

fix

Problema: Container Evolution API desapareceu.

Solução: Recriado docker-compose.yml apontando para v1.8.6 ARM64, volumes originais preservados. Ambas instâncias voltaram com estado open.

🌐 Wiki Estática

feature🕐 20:42

Primeira versão da Wiki:

  • Container Nginx Alpine servindo arquivos estáticos
  • Domínio: wiki.coocib.com
  • Conteúdo em /home/ubuntu/wiki/
  • Visual dark theme com sidebar

📅 10 de Junho de 2026 Correção NoMachine (Parte 2)

🔧 NoMachine Não Conecta — Diagnóstico Completo

fix🕐 14:10-15:02

Problema: NoMachine aceitava conexão mas fechava em 2-9 segundos (autenticação falhava).

Investigação (3 horas de debugging):

  1. Verificado que porta 4000 estava acessível (firewall OK)
  2. Descoberto que EnableSystemDatabase nem existe no NoMachine — a chave correta era EnablePasswordDB
  3. CreateDisplay 0 conflitava com display :0 do XFCE
  4. Server config estava quebrada com chaves inválidas

Solução final:

  • Restaurado server.cfg.backup original (Debian sample)
  • Configuração correta: EnablePasswordDB 0 (autenticação via PAM do sistema)
  • Sem CreateDisplay — NoMachine conecta ao desktop físico XFCE
  • Autenticação: usuário ubuntu + senha do sistema
💡 Aprendizado crítico: Sempre manter backup da config original. O sample oficial do Debian (server-debian.cfg.sample) é a referência correta. Não inventar chaves de configuração!

🔑 Descoberta: API Key Truncada

fix

Durante troubleshooting, descoberto que a API key da Evolution foi truncada pelo Docker:

  • Original: juvenildo_evolution_key_2024 (30 caracteres)
  • Truncada: juveni...2024 (13 caracteres, com 3 pontos literais)
  • A key funcional é a truncada
  • Descoberta via: docker exec evolution-api node -e 'console.log(process.env.AUTHENTICATION_API_KEY)'

📅 11 de Junho de 2026 Auditoria Pós-Reboot

🔄 Reinicialização Programada da VPS

evento🕐 04:01 BRT

VPS reiniciou automaticamente (cron job 1aca63 a cada 2 dias às 03:00 UTC):

  • ✅ Docker e containers subiram automaticamente
  • ✅ Google Drives (3) remontaram corretamente
  • ✅ NoMachine, XFCE, Hermes Gateway — tudo OK
  • ✅ Wiki, NPM, Portainer — todos online
  • 🔴 Instâncias WhatsApp PERDIDAS (volume evolution_instances vazio)
  • 🔴 Bridge WhatsApp crashando (instâncias não existiam)

🔧 Recriação das Instâncias WhatsApp

fix🕐 12:41

Problema: Volume evolution_instances ficou vazio após reboot — configurações das instâncias perdidas.

Solução:

  • Recriadas instâncias via API: POST /instance/create
  • Gerados novos QR Codes para pareamento
  • Bridge reiniciada após liberar porta 2999 (ocupada pelo Hermes)
  • Store (mensagens/contatos) preservado no volume evolution_store
⚠️ Atenção: Instâncias WhatsApp NÃO sobrevivem a reboot do VPS. Após cada reboot, é necessário recriar as instâncias e re-parear os QR Codes. A auditoria automática agora detecta isso.

🛡️ Sistema de Auditoria Pós-Reboot

feature🕐 13:28

Criado sistema completo de auditoria automática:

  • Script: /home/ubuntu/scripts/vps_audit.py
  • Timer systemd: dispara 30 minutos após cada boot
  • Verifica: Disco, RAM, 5 containers Docker, 3 Google Drives, Evolution API, instâncias WhatsApp, Bridge, NoMachine, XFCE, Hermes Gateway, Kanban
  • Auto-corrige: Containers parados, drives desmontados, LightDM, Bridge
  • Relatório: JSON em /home/ubuntu/last_audit.json
  • Notificação: Cron job Hermes reporta às 5:00 BRT
  • Resultado do teste: 16 ✅ / 2 ❌ (instâncias aguardando QR)

🗂️ Índice de Sistemas Configurados

🖥️ Infraestrutura

VPSOracle Cloud ARM64, Ubuntu 24.04, 4 cores, 23GB RAM, 193GB disco
Docker5 containers (evolution-api, nginx-proxy-manager, portainer, wiki-server, hermes)
NoMachinePorta 4000, XFCE4 desktop, autenticação PAM
Nginx PMproxy.coocib.com:81, SSL automático
Portainerportainer.coocib.com:9000

📱 WhatsApp

Evolution APIv1.8.6, porta 8080, evolution.coocib.com
InstânciasJuvenildo-pessoal, Juvenildo-Senar
BridgePython, porta 2999, modo observação
MemóriaSQLite, threading 48h/24h, perfis individuais

📂 Armazenamento

Google Drive3 contas via rclone, montagem systemd, cache 5GB
Wikiwiki.coocib.com, Nginx Alpine, HTML estático

🤖 Automações (Cron Jobs)

Limpar SocialDiário 8:00 BRT — apaga e-mails categoria Social
Resumo E-mailsDiário 9:00 BRT — resumo inbox 24h
Monitor OLXA cada 120 min — novos leads
Certidões CNPJSegunda 8:00 BRT — certidões negativas
Reiniciar VPSA cada 2 dias 03:00 UTC
Auditoria Pós-RebootTimer systemd (30 min pós-boot) + relatório 5:00 BRT