agent-ops

Sessões de terminal persistentes para agentes de IA — 62 ferramentas MCP para operações Linux remotas com sessões alimentadas por rmux, auditoria SQLite de cadeia completa, transferência de arquivos, encaminhamento de porta e orquestração multi-host. Rust.

GitHub

Documentação

clum

clum — terminais remotos seguros e confiáveis para agentes de IA. (Renomeado de yunying na versão 0.10.0; linhagem: agent-ops → yunying → clum.)

Infraestrutura segura para agentes de IA e operadores humanos que gerenciam hosts Linux — sessões de terminal persistentes alimentadas por rmux, registro de auditoria de cadeia completa, interface nativa MCP para clientes de IA + passagem PTY via CLI para humanos, com transferência de arquivos, encaminhamento de portas e orquestração multi-host.

Documentação em chinês

Por que clum?

Os agentes de IA evoluíram de "gerar comandos para humanos" para operar terminais de forma autônoma — implantar serviços, diagnosticar falhas, executar builds longos e tarefas de treinamento, tudo sem intervenção humana. Mas as ferramentas de terminal tradicionais (SSH, tmux) foram projetadas para interação humana, não para chamadas de API programáticas. O clum é construído sobre rmux, transformando sessões de terminal de uma interface humana em um recurso programável tanto para agentes de IA (via MCP) quanto para operadores humanos (via passagem PTY via CLI), com três camadas de nível de produção por cima.

Três problemas separam protótipos de agentes da implantação em produção, e as ferramentas existentes (servidores MCP SSH simples, wrappers básicos de tmux) os ignoram em grande parte:

Confiabilidade: SSH simples derruba processos em execução ao desconectar — tarefas de longa duração falham no meio do caminho. A automação tradicional com tmux depende de send-keys + sleep + grep, onde qualquer variação de tempo quebra o fluxo de trabalho.
Auditabilidade: Quando a IA opera servidores em produção, você deve rastrear quem fez o quê, quando, em qual máquina e com qual resultado. A maioria das ferramentas SSH não possui recursos de auditoria integrados.
Limite de segurança: Entregar chaves SSH diretamente a um cliente de IA é uma superfície de ataque massiva. O clum usa proxy Bridge + autenticação por token + criptografia TLS para confinar o acesso ao servidor apenas ao host de destino — o lado do cliente (tanto MCP quanto CLI) nunca detém as credenciais do servidor.

As três camadas: Camada de protocolo (interface padrão MCP para clientes de IA + passagem PTY via CLI para operadores humanos), Camada de gerenciamento (registro multi-host, filtragem por grupo/etiqueta, operações de transmissão) e Camada de conformidade (trilha de auditoria SQLite estruturada cobrindo operações MCP e CLI, pronta para rastreabilidade operacional). Juntas, elas preenchem a lacuna de infraestrutura entre protótipos de agentes e prontidão para produção.

Onde ele se encaixa?

O clum fornece acesso remoto seguro, confiável e auditável a hosts Linux — sessões de terminal, transferência de arquivos, encaminhamento de portas e auditoria de operações. Não substitui SSH (camada de transporte), Ansible (gerenciamento de configuração) ou tmux (multiplexador de terminal). É uma nova categoria: uma plataforma de operações remotas que transforma sessões de terminal em recursos programáveis tanto para agentes de IA quanto para humanos.

O clum não se importa com o que é executado dentro do terminal — comandos shell brutos, playbooks Ansible, scripts de build ou depuração interativa. Ele fornece a sessão persistente + trilha de auditoria + operações multi-host, e você traz as ferramentas.

Alguns padrões:

# Pattern 1: AI reads system state, makes decisions, executes fixes
AI Agent (via MCP)
  → exec: cat /proc/loadavg && df -h          # read state
  → AI reasons: "disk full on /var/log"
  → exec: du -sh /var/log/* | sort -rh | head  # diagnose
  → exec: journalctl --vacuum-size=500M        # fix
  → audit trail: every step recorded in SQLite

# Pattern 2: Human investigates via CLI while AI assists
Human (via CLI PTY passthrough)
  → clum-cli term tf01  # same session AI was working in
  → vim /etc/nginx/nginx.conf  # human edits in familiar tools
  AI Agent (via MCP)
  → exec: nginx -t && systemctl reload nginx  # AI validates & applies

# Pattern 3: Multi-host batch operations
AI (via MCP)
  → host_filter tags=["web"]                     # select target hosts
  → batch_exec: systemctl status nginx            # check all web servers
  → batch_upload: nginx.conf → /etc/nginx/        # push config to all
  → batch_exec: nginx -s reload                   # reload all at once

Casos de uso:

Resposta a incidentes: IA ou humano entra em uma sessão ao vivo, lê o estado do sistema, diagnostica a causa raiz e executa reparos — tudo dentro do mesmo terminal persistente
Operações ad-hoc: Comandos únicos rápidos em vários hosts (batch_exec), transferências de arquivos, encaminhamento de portas — sem necessidade de Playbook
Depuração interativa: Sessões persistentes para builds, monitoramento de tarefas de longa duração ou solução de problemas interativa via MCP (IA) e passagem PTY via CLI (humano)
Desenvolvimento remoto: clum-cli term devbox — trabalhe em uma máquina remota com seu ambiente de terminal familiar, com assistência de IA a um toque de tecla (Ctrl+G)
Auditoria de conformidade: Trilha de auditoria de cadeia completa cobrindo operações de IA e humanas em cada host, consultável via clum-mcp audit query

Arquitetura

graph LR
    A[AI Client<br/>opencode/Claude/Cursor] <-->|HTTP :9788<br/>MCP Streamable HTTP| S[Central MCP Server<br/>clum-mcp --mode http]
    H[Human] <-->|QUIC :9788<br/>PTY / upload / forward| S
    S <-->|QUIC :9788<br/>reverse registration| C1[rmux-bridge<br/>host-1]
    S <-->|QUIC :9788| C2[rmux-bridge<br/>host-2]
    S <-->|QUIC :9788| C3[rmux-bridge<br/>host-N]
    C1 <-->|Unix Socket| D1[RMUX daemon]
    C2 <-->|Unix Socket| D2[RMUX daemon]
    C3 <-->|Unix Socket| D3[RMUX daemon]

clum-mcp (Servidor Central) — Servidor MCP Central: HTTP :9788 para clientes de IA (protocolo MCP) + QUIC :9788 para registro de Bridge e plano de dados CLI. Fornece 68 ferramentas, auditoria centralizada, autenticação por chave de API e serviço de arquivos estáticos.
clum-cli — CLI para humanos: passagem PTY (term), transferência de arquivos (push/pull — arquivos ou diretórios, streaming em blocos com SHA-256; push suporta globs --exclude para diretórios), encaminhamento de portas (forward — reconexão automática em perda de rede, --give-up-after), listagem de sessões (list), reprodução de gravações (replay). Painel de chat de IA integrado (Ctrl+G). Controle de congestionamento padrão auto: BBR em alvos privados, CUBIC em alvos públicos (adaptativo a perdas, evita desconexões em largura de banda total); substituível com --cc bbr|cubic|auto (ou variável de ambiente CLUM_CC).
rmux-bridge — Agente implantado em cada host Linux. Conecta-se reversamente ao Servidor Central, lida com execução de ferramentas, E/S de arquivos, sessões PTY e envio de gravações.
Daemon RMUX — Multiplexador de terminal em cada host Linux (baseado em rmux).

Modelo de implantação:

Componente	Executa em	Conecta-se a
`clum-mcp --mode http`	Servidor central (1 instância)	—
`rmux-bridge`	Cada host Linux de destino	Servidor Central (QUIC, registro reverso)
Clientes de IA	Qualquer máquina	Servidor Central (HTTP, protocolo MCP)
`clum-cli`	Máquina do operador	Servidor Central (QUIC, `--server-addr`)

💡 Novos bridges são implantados com um único comando (após os ativos releases/ do servidor serem preparados — veja abaixo): curl -fsSLk -H "Authorization: Bearer <download_token>" https://SERVER:9788/releases/install.sh | BRIDGE_TOKEN=xxx SERVER_ADDR=SERVER:9788 sh

<download_token> e BRIDGE_TOKEN=xxx são o mesmo token de bridge (de clum-mcp bridge add) — o script de instalação o usa tanto para o cabeçalho de download quanto para o registro.

⚠️ /releases/* é servido de <static_dir>/releases/, e nenhum script de implantação prepara esses arquivos. Coloque deploy/install.sh, certs/ca.crt e o binário do bridge (nomeado rmux-bridge-linux-<arch>) em <static_dir>/releases/ primeiro — caso contrário, a URL não retorna nada.

💡 Durante a implantação, o bridge detecta automaticamente o caminho do socket RMUX — nenhuma configuração manual necessária.

Recursos

Recurso	Descrição
Terminal interativo	`clum-cli term` — passagem transparente de painel bruto por padrão (sem camada de interface rmux, semelhante a ssh); `--mux` opta pela interface `rmux attach-session` completa (barra de status + prefixo Ctrl+B). Cria a sessão automaticamente se ela não existir. Painel de chat de IA integrado (Ctrl+G) com streaming SSE em tempo real; suporta vim/htop/TUI
Gerenciamento de sessões	Criar/destruir/listar sessões, divisões de múltiplos painéis, layouts de janela
Execução de comandos	`exec` execução única (detecção de sentinela + código de saída, captura completa de scrollback para saídas grandes, reconexão automática em queda de conexão), programas interativos via send_keys + capture_pane
Espera de saída	`wait_for_text` para texto de terminal, `wait_exit` para saída de processo, `wait_stable` para quiescência de saída, `wait_for_bytes` para sequências de bytes brutos
Transferência de arquivos	Upload/download via QUIC (`clum-cli` e ferramentas MCP), transferência recursiva de diretórios com concorrência e globs `--exclude`, streaming em blocos com verificação SHA-256
Encaminhamento de portas	Encaminhamento de porta local encaminha via QUIC para acessar serviços internos remotos
Orquestração multi-host	Registro de hosts com filtragem por grupo/etiqueta/rótulo, broadcast_keys para múltiplos painéis
Registro de auditoria	Logs de auditoria SQLite + gravação PTY no lado do bridge (conteúdo asciinema v2, criptografado em repouso via X25519 + AES-256-GCM) + log de eventos + sincronização push/periódica + reprodução `clum-cli replay`
Consciência de estado do terminal	`capture_pane`, `exec`, `wait_for_text`, `wait_stable`, `pane_info` retornam `terminal_state` (pronto/executando/editor/paginador/senha/confirmação/repl/desconhecido) e posição do cursor, para que agentes de IA saibam o que o terminal está fazendo atualmente
Verificação de segurança de execução	`exec` recusa a execução quando o terminal não está no estado `ready` (por exemplo, dentro de vim, less, prompt de senha), retornando `refused: true` com orientação acionável para prevenir injeção de comandos; falhas de detecção de estado também recusam (falha fechada)

Atalhos de teclado do Painel de Chat de IA

Dentro do painel de IA (ativado via Ctrl+G):

Tecla	Ação
`Ctrl+G` / `Esc`	Fechar painel de IA, retornar ao terminal
`Ctrl+C`	Parar geração atual de IA (permanecer no painel)
`Enter`	Enviar mensagem
`Backspace`	Apagar último caractere
`↑` / `PageUp`	Rolar histórico de mensagens para cima (mensagens mais antigas, sai do modo de acompanhamento)
`↓` / `PageDown`	Rolar histórico de mensagens para baixo (rolar até o final retoma o modo de acompanhamento)
`Mouse Scroll`	Rolar histórico de mensagens

A visualização de mensagens rola automaticamente para a saída mais recente (modo de acompanhamento) enquanto a IA transmite; rolar para cima pausa para revisar o histórico, e rolar de volta ao final retoma. Enquanto aguarda uma resposta, um spinner animado com segundos decorridos é exibido.

Comando	Ação
`@analyze`	Analisar conteúdo atual do terminal
`@clear`	Limpar histórico de conversa

O painel de IA inicia um processo opencode serve no primeiro uso (porta 14096). Ele persiste entre ciclos de abrir/fechar do painel e é limpo quando o CLI sai. Use --opencode-dir <path> para controlar o diretório de trabalho (padrão: diretório atual).

O modo de passagem PTY encaminha bytes brutos do terminal — eventos de mouse funcionam quando o aplicativo remoto habilita o modo mouse (por exemplo, vim, htop).

Início Rápido

Build

# Native build (macOS dev)
cargo build -p clum-mcp --release
cargo build -p clum-cli --release

# Cross-compile bridge + MCP server for Linux x86_64 (static)
just release-linux

Implantação

# Step 1: Deploy rmux daemon (on remote host)
bash deploy/install-daemon.sh root@<your-bridge-ip>

# Step 2: Compile & deploy bridge (one-shot)
just release-linux
BRIDGE_TOKEN="<your-token>" CLUM_SERVER_ADDR=SERVER:9788 just deploy-bridge host=root@<your-bridge-ip>

Registro de Hosts

Crie config/hosts.yaml (veja config/hosts.example.yaml):

hosts:
  # Enrolled mode (recommended) — bridge reverse-registers, no addr/token needed:
  - name: prod-web-01
    group: production
    tags: [web, nginx]
    labels:
      dc: shanghai

  # Direct mode (fallback) — connect to bridge directly:
  - name: legacy-host
    bridge_addr: 10.0.1.10:9778
    bridge_token: "your-token-here"

💡 Recarga a quente: Após editar hosts.yaml, recarregue sem reiniciar — chame a ferramenta MCP reload_config ou envie kill -HUP <pid> ao processo do servidor MCP.

Configuração do Cliente MCP

Modo Servidor Central (recomendado — uma URL + chave de API):

{
  "mcp": {
    "clum": {
      "type": "remote",
      "url": "https://SERVER:9788/mcp",
      "headers": { "Authorization": "Bearer yk_name_..." }
    }
  }
}

Modo stdio local (sem servidor central, conexões diretas):

{
  "mcp": {
    "clum": {
      "type": "local",
      "command": ["/path/to/clum-mcp"],
      "args": ["--ca-cert", "/path/to/ca.crt", "--hosts-file", "/path/to/hosts.yaml"],
      "enabled": true
    }
  }
}

Use ca.crt para implantações remotas; bridge.crt funciona para testes locais com certificado autoassinado.

Gerenciamento do Servidor

# API Key management
clum-mcp agent add <name> (--group <g> | --admin)  # Create key (--admin = superadmin, --group = restricted)
clum-mcp agent list             # List all keys (shows GROUP column)
clum-mcp agent rotate <name>    # Rotate a key (inherits group)
clum-mcp agent revoke <name>    # Revoke a key

# Group isolation: grouped keys can only access hosts in their group.
# host_list/audit_query/recordings auto-filter; reload_config/host_set_meta blocked.

# Bridge enrollment (dynamic registration, no hosts.yaml edit needed)
clum-mcp bridge add <hostname> --tags <t1,t2> [--group <g>]
clum-mcp bridge list
clum-mcp bridge remove <hostname>
clum-mcp bridge join <hostname>   # Generate a new join token (offline recovery)

Quando ainda não existem chaves de API (instalação nova), o servidor executa em modo bootstrap: conexões de loopback agem como superadministrador (acesso ao console no host do servidor); solicitações não-loopback são rejeitadas até que o primeiro agent add crie uma chave.

Segurança

Modo Descrição

Verificado por CA Todas as conexões servidor→bridge verificam o certificado do bridge contra a raiz da CA (--ca-cert) — cadeia completa + verificação de nome de host, sem modo inseguro. --ca-cert pode ser omitido em implantações puramente registradas (bridges iniciam a conexão). Em modo direto, omiti-lo recai nas raízes WebPKI do sistema — o que funciona apenas para certificados de bridge assinados publicamente; uma CA privada deve ser passada explicitamente.

Modo	Descrição
Verificado por CA	Todas as conexões servidor→bridge verificam o certificado do bridge contra a raiz da CA (`--ca-cert`) — cadeia completa + verificação de nome de host, sem modo inseguro. `--ca-cert` pode ser omitido em implantações puramente registradas (bridges iniciam a conexão). Em modo direto, omiti-lo recai nas raízes WebPKI do sistema — o que funciona apenas para certificados de bridge assinados publicamente; uma CA privada deve ser passada explicitamente.

Produção: Execute sua própria CA, emita certificados por bridge, o servidor MCP detém apenas a raiz da CA.

Proteções integradas:

Prevenção de travessia de caminho: Upload/download de arquivos rejeita caminhos contendo ..
Lista de permissões de alvo de túnel: allowed_forward_targets opcional em hosts.yaml restringe alvos de encaminhamento de portas (padrões glob) — aplica-se a hosts definidos em hosts.yaml; bridges registrados dinamicamente sem entrada correspondente não têm lista de permissões (todos os alvos permitidos)
Verificação de segurança de execução: exec recusa a execução quando o terminal não está no estado ready (previne injeção de comandos em prompts vim/less/senha); falhas de detecção também recusam (falha fechada)
Redação de entrada sensível: Entradas enviadas enquanto o terminal está no estado password são automaticamente redigidas no log de auditoria ([REDACTED:N bytes], imposto pelo servidor, sem opção de exclusão); o sinalizador sensitive em ferramentas de entrada força a redação para tokens/códigos 2FA

Auditoria

# Recent operations
clum-mcp audit query --format table

# Commands on specific host
clum-mcp audit query --host tf01 --action exec --since 2026-06-01

# Statistics
clum-mcp audit stats

# Manual cleanup
clum-mcp audit cleanup --older-than 30

# Verify hash-chain integrity (Chain head can be copied to an external
# system for offline comparison — see INVARIANTS.md §8)
clum-mcp audit verify
# Chain check: OK / Hashed events: 12345 / Chain head: <hex64>

Os dados de auditoria são armazenados em ~/.clum/audit.db, retidos por 90 dias, com limite flexível de 500 MB (a limpeza remove os eventos mais antigos; o tamanho do arquivo pode exceder temporariamente o limite). Cada evento é selado em uma cadeia de hash encadeada (entry_hash = SHA256(prev_hash ‖ payload)); audit verify recalcula toda a cadeia e sai com código não zero na primeira evidência de registro adulterado ou ausente.

Base de Conhecimento (Conceito de Design)

O clum produz trilhas de auditoria detalhadas para cada operação, mas os logs brutos de auditoria respondem "o que aconteceu" — não "por que aconteceu" ou "como corrigir na próxima vez". Esta seção descreve uma filosofia de design para transformar experiência operacional em uma base de conhecimento compartilhada. A implementação é deliberadamente deixada para os usuários, porque os backends de base de conhecimento são uma questão de preferência de infraestrutura da equipe, não de prescrição de ferramentas.

O Problema

Após uma sessão de solução de problemas orientada por IA:

O conhecimento permanece local: o diagnóstico, a causa raiz e a correção existem apenas na transcrição do chat.
Sem compartilhamento: outros membros da equipe não conseguem pesquisar incidentes semelhantes anteriores.
Sobrecarga manual: escrever um postmortem ou entrada de wiki exige lembrar do contexto dias depois.

Design em Três Camadas

┌─────────────┐    session activity    ┌──────────────────┐
│  clum  │ ─── audit events ────→ │  Knowledge        │
│  (MCP)      │    (SQLite)            │  Extraction       │
└─────────────┘                        │  (AI review)      │
                                       └────────┬─────────┘
                                                │ structured entry
                                                ▼
                                       ┌──────────────────┐
                                       │  Output Adapter   │
                                       │  (user-defined)   │
                                       └───┬──┬──┬──┬────┘
                                           │  │  │  │
                                      ONES │ wiki GitBook ...
                                           │
                                     curl / git / webhook

1. Coleta (integrada)

O sistema de auditoria existente registra cada invocação de ferramenta MCP e operação de CLI — exec, capture_pane, session_create, term, etc. — com timestamps, host, sucesso/falha e mensagens de erro. Nenhuma alteração é necessária.

2. Extração (orientada por IA)

Quando o usuário aciona explicitamente "salvar esta sessão como conhecimento", a IA revisa todo o histórico da conversa mais a trilha de auditoria daquela sessão. Ela extrai:

Campo	Fonte
Problema	Relato inicial do usuário, saídas de erro
Caminho de diagnóstico	Sequência de chamadas `exec` / `capture_pane`
Causa raiz	Descoberta final antes da correção
Solução	O comando ou alteração de configuração que resolveu
Hosts / tags afetados	A partir dos metadados do evento de auditoria

A saída é uma entrada JSON estruturada, não um arquivo Markdown — para que o adaptador de saída possa transformá-la em qualquer formato.

3. Saída (definida pelo usuário)

Deliberadamente NÃO construímos integrações específicas de plataforma. Em vez disso, os usuários definem um sink — um script, comando ou webhook que recebe a entrada de conhecimento via stdin (JSON). Exemplos:

# ~/.clum/sink.sh — push to ONES wiki
curl -X POST "https://ones.example.com/wiki/api" \
  -H "Authorization: Bearer $TOKEN" \
  -d "$(cat)"

# Push to a git-based knowledge repo
echo "$(cat)" >> knowledge.jsonl && git commit -am "add troubleshooting entry"

Princípios de Design

O usuário decide quando: a extração de conhecimento é acionada explicitamente, não automaticamente — evita entradas de ruído de sessões incompletas.
O usuário decide onde: sem dependência de plataforma. O sink é qualquer CLI/API que sua equipe já usa.
O usuário revisa antes de publicar: entradas geradas por IA devem ser revisadas e editadas antes de serem enviadas ao armazenamento compartilhado.
JSON como intercâmbio: dados estruturados podem ser transformados em Markdown, payloads de API, linhas de banco de dados, etc.

Este design mantém o clum focado em operações, permitindo que as equipes construam seus próprios pipelines de conhecimento sobre os dados de auditoria que ele já gera.

Ferramentas

68 ferramentas MCP cobrindo todo o ciclo de vida do terminal, além de audit query/stats/cleanup subcomandos CLI para operadores humanos:

Categoria	Ferramentas
Host	`host_list`, `host_filter`, `host_set_meta`, `reload_config`
Sessão	`session_create`, `session_list`, `session_attach`, `kill_session`
Entrada	`send_keys`, `send_text`, `broadcast_keys`
Saída	`capture_pane`, `capture_region`, `wait_for_text`, `wait_for_bytes`, `find_pane_text`, `find_text_all`, `stream_pane`
Execução	`exec`, `wait_exit`, `wait_stable`, `collect_until_exit`, `shell_command`, `respawn_pane`, `cmd_escape`
Painel	`split_pane`, `split_pane_with`, `break_pane`, `join_pane`, `swap_pane`, `resize_pane`, `set_pane_title`, `get_pane_title`, `clear_history`, `close_pane`, `pane_info`, `pane_exists`
Janela	`split_window`, `close_window`, `rename_window`, `resize_window`, `select_window`, `select_layout`, `window_info`, `list_window_panes`
Descoberta	`find_panes`, `find_sessions`, `get_pane_by_title`, `host_capabilities`
Buffer	`list_buffers`, `paste_buffer`, `delete_buffer`
Arquivo	`file_upload`, `file_download`
Lote	`batch_exec`, `batch_send_keys`, `batch_upload`, `batch_download`
Túnel	`forward_create`, `forward_list`, `forward_close`
Deploy	`deploy_bridge`
Auditoria	`audit_query`, `query_bridge_audit`, `list_recordings`, `get_recording`, `search_recordings`
Sistema	`clum_usage_rules`

💡 stream_pane é ideal para monitoramento de saída em tempo real de comandos de longa duração (leitura bloqueante, retorno incremental), substituindo a sondagem de capture_pane.

Documentação completa: clum-docs/TOOLS.md

Desempenho

Otimização	Antes	Depois	Ganho
Controle de congestionamento QUIC BBR + janela de fluxo de 16MB	Upload de 200MB: 60,4s	28,1s	+53%
SHA256 no lado do receptor (elimina dupla leitura)	Download de 200MB: 63,5s	21,8s	+192%
Buffer de cópia de 1MB (era 8KB padrão)	Contagem de syscalls: N	N/128	128x menos
Deploy de bridge (reinício fire-and-forget)	47s	4s	-91%

Throughput em estado estável: 82 Mbps (arquivo de 1GB, 82% de utilização do link em link de 100 Mbps).

Principais escolhas de design:

BBR para privado, CUBIC para público: o controle de taxa baseado em modelo do BBR tolera perda de pacotes sem redução drástica da janela (usado em alvos de rede privada); o CUBIC recua na perda para alvos públicos. Desde v0.15.0, o padrão é auto — veja abaixo o adaptativo a perdas.
Controle de congestionamento adaptativo a perdas: o modo auto escolhe BBR para alvos de rede privada (throughput máximo) e CUBIC para alvos públicos (recua na perda como TCP — links públicos em largura de banda total não derrubam mais a conexão). Substituição por componente: clum-cli --cc (ou env CLUM_CC), servidor CLUM_CC, bridge BRIDGE_CC.
Receptor calcula o hash: o remetente transmite dados em uma passagem; o receptor calcula SHA256 inline — reduz pela metade a E/S de disco no lado do envio
Buffer unificado de 1MB: COPY_BUF_SIZE = 1MB é compartilhado por MCP, Bridge e o caminho de encaminhamento de porta da CLI — alinhado para evitar buffering entre fronteiras

Desenvolvimento

just check       # cargo check --workspace
just test        # cargo test --workspace
just fmt         # cargo fmt --all
just lint        # cargo clippy --workspace -- -D warnings
just build       # cargo build --workspace
just release-linux  # cross-compile Linux x86_64 musl

Pilha Tecnológica

Linguagem: Rust stable (edição 2021)
Runtime assíncrono: tokio
TLS: rustls (sem dependência de OpenSSL)
Terminal: rmux-sdk
Armazenamento de auditoria: rusqlite (SQLite embutido)
Transporte MCP: stdio + Streamable HTTP (rmcp v3, JSON-RPC 2.0)

Documentação

Referência de Ferramentas — 68 ferramentas MCP com parâmetros e valores de retorno
Guia de Implantação — Arquitetura, build, deploy, operações, segurança
Design de Estado do Terminal — Motor heurístico de consciência de estado do terminal
Contribuindo
Política de Segurança
Changelog

Licença

MIT