Pular para o conteúdo principal
O Conversation Hub faz a conversa atravessar canais. Um assunto começado no Telegram continua quando você abre o chatcli no notebook; o que você responde no notebook vira contexto no Telegram/Slack/WhatsApp. Os dois lados se entendem — sem você repetir nada.
O hub é uma ponte do momento, não memória de longo prazo. Ele mantém a conversa atual sincronizada entre canais, com banco limitado (poda automática). Memória persistente entre projetos/sessões continua sendo o sistema de memória (/memory) e o /session save.

​
Como funciona

  • Principal: a identidade compartilhada da conversa. No modo single-user (padrão), o CLI local e o gateway colapsam no mesmo principal (default se você não definir nada), então tudo compartilha sem configuração.
  • hub.db: um log append-only em SQLite (~/.chatcli/hub.db). O CLI e o daemon do gateway abrem o mesmo arquivo — é por isso que se entendem entre processos.
  • Efêmero por sessão: ao abrir o chatcli, começa uma conversa nova e a anterior é podada — o banco não cresce e você não carrega um histórico gigante. Conversas ociosas além do TTL (CHATCLI_HUB_TTL_HOURS, padrão 24h) são varridas.
  • Silencioso: mensagens de outros canais entram no contexto do modelo sem serem impressas no seu prompt (nada de poluição, nada de “apertar Enter pra continuar”).
  • /newsession zera a conversa compartilhada para todos os canais.
Funciona em chat, /agent e /coder: o pedido e a resposta final atravessam os canais (o detalhe de execução das tools fica local em cada máquina).

​
Modos

O caso mais simples — chatcli + gateway no mesmo notebook, zero configuração (basta o principal padrão):
export CHATCLI_TELEGRAM_BOT_TOKEN=123:abc
chatcli                 # abre o REPL (entra em modo hub local)
# dentro dele:
/gateway start          # sobe o daemon, herdando o ambiente
Converse no notebook, depois puxe o assunto no Telegram → tem o contexto. Mande no Telegram com o prompt aberto → entra no contexto do próximo turno do notebook.
Cross-process, o notebook pega o contexto no próximo turno (não há push ao vivo no prompt já aberto). Para tempo real, use o modo co-locado abaixo.

​
Comandos

/hub whoami                         # seu principal e a conversa ativa
/hub bind telegram 123 alice        # vincula uma identidade de canal a um principal
/hub bindings [principal]           # lista os vínculos canal→principal
As settings do hub são mutáveis em runtime e persistem no hub.db (lidas ao vivo pelo gateway, sem restart): 
/config hub                         # painel: valor efetivo + fonte (setting/env/default)
/config hub set principal alice
/config hub set isolate on
/config hub set ttl_hours 72
/config hub reset principal         # volta a env/default
Precedência de resolução: setting (db) > variável de ambiente > default.

​
Identidade compartilhada (single-user vs multi-user)

CenárioConfiguraçãoResultado
Só você (notebook + bot pessoal)nada (ou CHATCLI_HUB_PRINCIPAL=eu)tudo colapsa num principal → uma conversa compartilhada
Bot multi-usuário/públicoCHATCLI_HUB_ISOLATE=true (+ bindings)cada identidade isolada; bindings mesclam quem você quiser

​
Relação com memória e sessões

MecanismoPara quêPersistência
Conversation Hubcontexto cross-channel da conversa atualefêmero/limitado (poda + TTL)
Memória (/memory)fatos/aprendizados de longo prazopermanente
Sessões (/session save)snapshot explícito de uma conversaarquivo JSON
O hub é um trilho paralelo aditivo: o histórico local, o /session save e a memória continuam funcionando exatamente como antes.

​
Observabilidade — o hub nunca morre em silêncio

A continuidade depende do hub estar de pé, então todo estado dele é explícito no log:
  • Hub ativo: o daemon loga gateway: conversation hub active (principal=…, isolate=…, idle_ttl=…) no boot; o CLI loga local hub mode enabled.
  • Hub desligado: um Warn nomeia a fonte exata da decisão — db setting enabled=false, env CHATCLI_HUB_ENABLED=false ou default — em vez de simplesmente sumir com a continuidade.
  • Daemon servindo sem hub (banco inacessível): um aviso único por execução deixa claro que as respostas estão sem contexto cross-channel.
O daemon herda o ambiente da shell que rodou /gateway start, e o .env não sobrescreve variáveis já exportadas. Um CHATCLI_HUB_ENABLED=false esquecido na shell desliga a continuidade mesmo com o .env correto — o log de proveniência acima existe exatamente para flagrar isso (ps eww <pid> confirma o ambiente real do processo).

​
Veja também