yunying

Infraestructura segura para agentes de IA que operan hosts Linux: sesiones de terminal persistentes impulsadas por rmux, registro de auditoría de cadena completa, interfaz nativa MCP para todos los principales clientes de IA, con transferencia de archivos y orquestación multi-host.

GitHub

Documentación

clum

clum — terminales remotas seguras y confiables para agentes de IA. (Renombrado de yunying en 0.10.0; linaje: agent-ops → yunying → clum).

Infraestructura segura para agentes de IA y operadores humanos que gestionan hosts Linux — sesiones de terminal persistentes impulsadas por rmux, registro de auditoría de cadena completa, interfaz nativa MCP para clientes de IA + paso directo de PTY por CLI para humanos, con transferencia de archivos, reenvío de puertos y orquestación multi-host.

中文文档

¿Por qué clum?

Los agentes de IA han evolucionado de "generar comandos para humanos" a operar terminales de forma autónoma — desplegar servicios, diagnosticar fallos, ejecutar compilaciones largas y trabajos de entrenamiento, todo sin intervención humana. Pero las herramientas de terminal tradicionales (SSH, tmux) fueron diseñadas para la interacción humana, no para llamadas API programáticas. clum está construido sobre rmux, convirtiendo las sesiones de terminal de una interfaz humana a un recurso programable tanto para agentes de IA (vía MCP) como para operadores humanos (vía paso directo de PTY por CLI), con tres capas de grado de producción encima.

Tres problemas se interponen entre los prototipos de agentes y el despliegue en producción, y las herramientas existentes (servidores MCP SSH simples, envoltorios básicos de tmux) los ignoran en gran medida:

Confiabilidad: SSH simple elimina los procesos en ejecución al desconectarse — las tareas de larga duración fallan a mitad de camino. La automatización tradicional de tmux depende de send-keys + sleep + grep, donde cualquier desviación de tiempo rompe el flujo de trabajo.
Auditabilidad: Cuando la IA opera servidores en producción, debes rastrear quién hizo qué, cuándo, en qué máquina y con qué resultado. La mayoría de las herramientas SSH carecen por completo de capacidades de auditoría integradas.
Límite de seguridad: Entregar claves SSH directamente a un cliente de IA es una superficie de ataque masiva. clum utiliza proxy Bridge + autenticación por token + cifrado TLS para confinar el acceso al servidor al host objetivo — el lado del cliente (tanto MCP como CLI) nunca posee credenciales del servidor.

Las tres capas: Capa de protocolo (interfaz estándar MCP para clientes de IA + paso directo de PTY por CLI para operadores humanos), Capa de gestión (registro multi-host, filtrado por grupo/etiqueta, operaciones de difusión) y Capa de cumplimiento (rastro de auditoría SQLite estructurado que cubre operaciones MCP y CLI, listo para trazabilidad operativa). Juntas llenan la brecha de infraestructura entre los prototipos de agentes y la preparación para producción.

¿Dónde encaja?

clum proporciona acceso remoto seguro, confiable y auditable a hosts Linux — sesiones de terminal, transferencia de archivos, reenvío de puertos y auditoría de operaciones. No es un reemplazo de SSH (capa de transporte), Ansible (gestión de configuración) o tmux (multiplexor de terminal). Es una nueva categoría: una plataforma de operaciones remotas que convierte las sesiones de terminal en recursos programables tanto para agentes de IA como para humanos.

A clum no le importa qué se ejecuta dentro de la terminal — comandos shell crudos, playbooks de Ansible, scripts de compilación o depuración interactiva. Proporciona la sesión persistente + rastro de auditoría + operaciones multi-host, y tú traes las herramientas.

Algunos patrones:

# 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:

Respuesta a incidentes: IA o humano entra en una sesión en vivo, lee el estado del sistema, diagnostica la causa raíz y ejecuta reparaciones — todo dentro de la misma terminal persistente
Operaciones ad-hoc: Comandos rápidos únicos en múltiples hosts (batch_exec), transferencias de archivos, reenvío de puertos — sin necesidad de Playbook
Depuración interactiva: Sesiones persistentes para compilaciones, monitoreo de tareas de larga duración o solución de problemas interactiva vía MCP (IA) y paso directo de PTY por CLI (humano)
Desarrollo remoto: clum-cli term devbox — trabaja en una máquina remota con tu entorno de terminal familiar, con asistencia de IA a una tecla de distancia (Ctrl+G)
Auditoría de cumplimiento: Rastro de auditoría de cadena completa que cubre operaciones de IA y humanas en cada host, consultable vía clum-mcp audit query

Arquitectura

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 y plano de datos CLI. Proporciona 68 herramientas, auditoría centralizada, autenticación por clave API y servicio de archivos estáticos.
clum-cli — CLI para humanos: paso directo de PTY (term), transferencia de archivos (push/pull — archivos o directorios, transmisión fragmentada con SHA-256; push admite --exclude globs para directorios), reenvío de puertos (forward — se reconecta automáticamente ante pérdida de red, --give-up-after), listado de sesiones (list), reproducción de grabaciones (replay). Panel de chat de IA integrado (Ctrl+G). Control de congestión predeterminado auto: BBR en objetivos privados, CUBIC en objetivos públicos (adaptativo a pérdida, evita desconexiones a ancho de banda completo); anular con --cc bbr|cubic|auto (o variable de entorno CLUM_CC).
rmux-bridge — Agente desplegado en cada host Linux. Se conecta inversamente al Servidor Central, maneja la ejecución de herramientas, E/S de archivos, sesiones PTY y envío de grabaciones.
Daemon RMUX — Multiplexor de terminal en cada host Linux (basado en rmux).

Modelo de despliegue:

Componente	Se ejecuta en	Se conecta a
`clum-mcp --mode http`	Servidor central (1 instancia)	—
`rmux-bridge`	Cada host Linux objetivo	Servidor Central (QUIC, registro inverso)
Clientes de IA	Cualquier máquina	Servidor Central (HTTP, protocolo MCP)
`clum-cli`	Máquina del operador	Servidor Central (QUIC, `--server-addr`)

💡 Los nuevos bridges se despliegan con un comando (después de que los activos releases/ del servidor estén preparados — ver abajo): curl -fsSLk -H "Authorization: Bearer <download_token>" https://SERVER:9788/releases/install.sh | BRIDGE_TOKEN=xxx SERVER_ADDR=SERVER:9788 sh

<download_token> y BRIDGE_TOKEN=xxx son el mismo token de bridge (de clum-mcp bridge add) — el script de instalación lo usa tanto para el encabezado de descarga como para el registro.

⚠️ /releases/* se sirve desde <static_dir>/releases/, y ningún script de despliegue prepara esos archivos. Coloca deploy/install.sh, certs/ca.crt y el binario del bridge (nombrado rmux-bridge-linux-<arch>) bajo <static_dir>/releases/ primero — de lo contrario, la URL no devuelve nada.

💡 Durante el despliegue, el bridge detecta automáticamente la ruta del socket RMUX — no se necesita configuración manual.

Características

Característica	Descripción
Terminal interactiva	`clum-cli term` — paso directo de panel crudo transparente por defecto (sin capa de interfaz rmux, similar a ssh); `--mux` opta por la interfaz completa de `rmux attach-session` (barra de estado + prefijo Ctrl+B). Crea automáticamente la sesión si no existe. Panel de chat de IA integrado (Ctrl+G) con transmisión SSE en tiempo real; admite vim/htop/TUI
Gestión de sesiones	Crear/destruir/listar sesiones, divisiones multi-panel, diseños de ventana
Ejecución de comandos	`exec` ejecución única (detección de centinela + código de salida, captura completa de scrollback para salidas grandes, reconexión automática ante caída de conexión), programas interactivos vía send_keys + capture_pane
Espera de salida	`wait_for_text` para texto de terminal, `wait_exit` para salida de proceso, `wait_stable` para quietud de salida, `wait_for_bytes` para secuencias de bytes crudos
Transferencia de archivos	Subir/descargar sobre QUIC (`clum-cli` y herramientas MCP), transferencia recursiva de directorios con concurrencia y `--exclude` globs, transmisión fragmentada con verificación SHA-256
Reenvío de puertos	El reenvío de puertos local reenvía a través de QUIC para acceder a servicios internos remotos
Orquestación multi-host	Registro de hosts con filtrado por grupo/etiqueta/etiqueta, broadcast_keys para multi-panel
Registro de auditoría	Registros de auditoría SQLite + grabación PTY del lado del bridge (contenido asciinema v2, cifrado en reposo vía X25519 + AES-256-GCM) + registro de eventos + sincronización push/periódica + reproducción `clum-cli replay`
Conciencia del estado de terminal	`capture_pane`, `exec`, `wait_for_text`, `wait_stable`, `pane_info` devuelven `terminal_state` (listo/ejecutando/editor/paginador/contraseña/confirmación/repl/desconocido) y posición del cursor, para que los agentes de IA sepan qué está haciendo actualmente la terminal
Verificación de seguridad de ejecución	`exec` rechaza la ejecución cuando la terminal no está en estado `ready` (por ejemplo, dentro de vim, less, prompt de contraseña), devolviendo `refused: true` con orientación accionable para prevenir inyección de comandos; los fallos de detección de estado también rechazan (cierre ante fallo)

Atajos de teclado del Panel de Chat de IA

Dentro del panel de IA (activado vía Ctrl+G):

Tecla	Acción
`Ctrl+G` / `Esc`	Cerrar panel de IA, volver a la terminal
`Ctrl+C`	Detener la generación actual de IA (permanecer en el panel)
`Enter`	Enviar mensaje
`Backspace`	Eliminar el último carácter
`↑` / `PageUp`	Desplazar el historial de mensajes hacia arriba (mensajes más antiguos, sale del modo de seguimiento)
`↓` / `PageDown`	Desplazar el historial de mensajes hacia abajo (desplazarse al final reanuda el modo de seguimiento)
`Mouse Scroll`	Desplazar el historial de mensajes

La vista de mensajes se desplaza automáticamente a la salida más reciente (modo de seguimiento) mientras la IA transmite; desplazarse hacia arriba lo pausa para revisar el historial, y volver al final lo reanuda. Mientras se espera una respuesta, se muestra un indicador animado con segundos transcurridos.

Comando	Acción
`@analyze`	Analizar el contenido actual de la terminal
`@clear`	Borrar el historial de conversación

El panel de IA inicia un proceso opencode serve en el primer uso (puerto 14096). Persiste entre ciclos de apertura/cierre del panel y se limpia cuando el CLI sale. Usa --opencode-dir <path> para controlar el directorio de trabajo (predeterminado: directorio actual).

El modo de paso directo de PTY reenvía bytes crudos de terminal — los eventos de mouse funcionan cuando la aplicación remota habilita el modo de mouse (por ejemplo, vim, htop).

Inicio Rápido

Compilación

# 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

Despliegue

# 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

Crea config/hosts.yaml (ver 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 en caliente: Después de editar hosts.yaml, recarga sin reiniciar — ya sea llamando a la herramienta MCP reload_config o enviando kill -HUP <pid> al proceso del servidor MCP.

Configuración del Cliente MCP

Modo Servidor Central (recomendado — una URL + Clave API):

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

Modo stdio local (sin servidor central, conexiones directas):

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

Usa ca.crt para despliegues remotos; bridge.crt funciona para pruebas locales con certificados autofirmados.

Gestión del 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)

Cuando aún no existen claves API (instalación nueva), el servidor se ejecuta en modo bootstrap: las conexiones de loopback actúan como superadmin (acceso de consola en el host del servidor); las solicitudes no-loopback se rechazan hasta que el primer agent add crea una clave.

Seguridad

Modo Descripción

CA verificado Todas las conexiones servidor→bridge verifican el certificado del bridge contra la raíz de CA (--ca-cert) — cadena completa + verificación de nombre de host, sin modo inseguro. --ca-cert puede omitirse en despliegues puramente inscritos (los bridges inician la conexión). En modo directo, omitirlo recurre a las raíces WebPKI del sistema — lo que funciona solo para certificados de bridge firmados públicamente; una CA privada debe pasarse explícitamente.

Modo	Descripción
CA verificado	Todas las conexiones servidor→bridge verifican el certificado del bridge contra la raíz de CA (`--ca-cert`) — cadena completa + verificación de nombre de host, sin modo inseguro. `--ca-cert` puede omitirse en despliegues puramente inscritos (los bridges inician la conexión). En modo directo, omitirlo recurre a las raíces WebPKI del sistema — lo que funciona solo para certificados de bridge firmados públicamente; una CA privada debe pasarse explícitamente.

Producción: Ejecuta tu propia CA, emite certificados por bridge, el servidor MCP solo posee la raíz de CA.

Protecciones integradas:

Prevención de traversal de rutas: La subida/descarga de archivos rechaza rutas que contienen ..
Lista blanca de objetivos de túnel: allowed_forward_targets opcional en hosts.yaml restringe los objetivos de reenvío de puertos (patrones glob) — se aplica a hosts definidos en hosts.yaml; los bridges inscritos dinámicamente sin una entrada coincidente no tienen lista blanca (todos los objetivos permitidos)
Verificación de seguridad de ejecución: exec rechaza la ejecución cuando la terminal no está en estado ready (previene inyección de comandos en prompts de vim/less/contraseña); los fallos de detección también rechazan (cierre ante fallo)
Redacción de entrada sensible: Las entradas enviadas mientras la terminal está en estado password se redactan automáticamente en el registro de auditoría ([REDACTED:N bytes], aplicado por el servidor, sin opción de exclusión); el indicador sensitive en las herramientas de entrada fuerza la redacción para tokens/códigos 2FA

Auditoría

# 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>

Los datos de auditoría se almacenan en ~/.clum/audit.db, se conservan durante 90 días, con un límite flexible de 500 MB (la limpieza elimina los eventos más antiguos; el tamaño del archivo puede superar temporalmente el límite). Cada evento se sella en una cadena de hash hacia adelante (entry_hash = SHA256(prev_hash ‖ payload)); audit verify recalcula la cadena completa y sale con un código distinto de cero ante el primer registro manipulado o faltante.

Base de Conocimiento (Concepto de Diseño)

clum produce rastros de auditoría detallados para cada operación, pero los registros de auditoría en bruto responden "qué sucedió", no "por qué sucedió" ni "cómo solucionarlo la próxima vez". Esta sección describe una filosofía de diseño para convertir la experiencia operativa en una base de conocimiento compartida. La implementación se deja deliberadamente a los usuarios, porque los backends de bases de conocimiento son una preferencia de infraestructura del equipo, no una prescripción de herramientas.

El Problema

Después de una sesión de resolución de problemas impulsada por IA:

El conocimiento permanece local: el diagnóstico, la causa raíz y la solución viven solo en la transcripción del chat.
Sin compartir: otros miembros del equipo no pueden buscar incidentes pasados similares.
Sobrecarga manual: redactar un informe post-mortem o una entrada de wiki requiere recordar el contexto días después.

Diseño en Tres Capas

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

1. Recopilación (integrada)

El sistema de auditoría existente registra cada invocación de herramienta MCP y operación CLI — exec, capture_pane, session_create, term, etc. — con marcas de tiempo, host, éxito/fracaso y mensajes de error. No se necesitan cambios.

2. Extracción (impulsada por IA)

Cuando el usuario activa explícitamente "guardar esta sesión como conocimiento", la IA revisa el historial completo de la conversación más el rastro de auditoría de esa sesión. Extrae:

Campo	Fuente
Problema	Informe inicial del usuario, salidas de error
Ruta de diagnóstico	Secuencia de llamadas a `exec` / `capture_pane`
Causa raíz	Hallazgo final antes de la solución
Solución	El comando o cambio de configuración que lo resolvió
Hosts / etiquetas afectados	De los metadatos de eventos de auditoría

La salida es una entrada JSON estructurada, no un archivo Markdown — para que el adaptador de salida pueda transformarla a cualquier formato.

3. Salida (definida por el usuario)

Intencionalmente NO construimos integraciones específicas de plataforma. En su lugar, los usuarios definen un sumidero — un script, comando o webhook que recibe la entrada de conocimiento a través de stdin (JSON). Ejemplos:

# ~/.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"

Principios de Diseño

El usuario decide cuándo: la extracción de conocimiento se activa explícitamente, no automáticamente — evita entradas de ruido de sesiones incompletas.
El usuario decide dónde: sin bloqueo de plataforma. El sumidero es cualquier CLI/API que tu equipo ya use.
El usuario revisa antes de publicar: las entradas generadas por IA deben revisarse y editarse antes de enviarse al almacenamiento compartido.
JSON como intercambio: los datos estructurados pueden transformarse a Markdown, cargas útiles de API, filas de base de datos, etc.

Este diseño mantiene a clum enfocado en operaciones mientras permite a los equipos construir sus propios pipelines de conocimiento sobre los datos de auditoría que ya genera.

Herramientas

68 herramientas MCP que cubren el ciclo de vida completo del terminal, más audit query/stats/cleanup subcomandos CLI para operadores humanos:

Categoría	Herramientas
Host	`host_list`, `host_filter`, `host_set_meta`, `reload_config`
Sesión	`session_create`, `session_list`, `session_attach`, `kill_session`
Entrada	`send_keys`, `send_text`, `broadcast_keys`
Salida	`capture_pane`, `capture_region`, `wait_for_text`, `wait_for_bytes`, `find_pane_text`, `find_text_all`, `stream_pane`
Ejecución	`exec`, `wait_exit`, `wait_stable`, `collect_until_exit`, `shell_command`, `respawn_pane`, `cmd_escape`
Panel	`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`
Ventana	`split_window`, `close_window`, `rename_window`, `resize_window`, `select_window`, `select_layout`, `window_info`, `list_window_panes`
Descubrimiento	`find_panes`, `find_sessions`, `get_pane_by_title`, `host_capabilities`
Buffer	`list_buffers`, `paste_buffer`, `delete_buffer`
Archivo	`file_upload`, `file_download`
Lote	`batch_exec`, `batch_send_keys`, `batch_upload`, `batch_download`
Túnel	`forward_create`, `forward_list`, `forward_close`
Despliegue	`deploy_bridge`
Auditoría	`audit_query`, `query_bridge_audit`, `list_recordings`, `get_recording`, `search_recordings`
Sistema	`clum_usage_rules`

💡 stream_pane es ideal para el monitoreo de salida en tiempo real de comandos de larga duración (lectura bloqueante, retorno incremental), reemplazando el sondeo de capture_pane.

Documentación completa: clum-docs/TOOLS.md

Rendimiento

Optimización	Antes	Después	Ganancia
Control de congestión QUIC BBR + ventana de flujo de 16MB	Subida de 200MB: 60.4s	28.1s	+53%
SHA256 en el lado receptor (elimina doble lectura)	Descarga de 200MB: 63.5s	21.8s	+192%
Buffer de copia de 1MB (antes 8KB por defecto)	Conteo de syscalls: N	N/128	128x menos
Despliegue de puente (reinicio fire-and-forget)	47s	4s	-91%

Rendimiento en estado estable: 82 Mbps (archivo de 1GB, 82% de utilización del enlace en un enlace de 100 Mbps).

Decisiones de diseño clave:

BBR para privado, CUBIC para público: el control de tasa basado en modelo de BBR tolera pérdida de paquetes sin reducción drástica de ventana (usado en objetivos de red privada); CUBIC retrocede ante pérdidas en objetivos públicos. Desde v0.15.0 el valor predeterminado es auto — ver pérdida-adaptativa abajo.
Control de congestión pérdida-adaptativa: el modo auto elige BBR para objetivos de red privada (máximo rendimiento) y CUBIC para objetivos públicos (retrocede ante pérdidas como TCP — los enlaces públicos a ancho de banda completo ya no pierden la conexión). Anulación por componente: clum-cli --cc (o variable de entorno CLUM_CC), servidor CLUM_CC, puente BRIDGE_CC.
El receptor calcula el hash: el remitente transmite datos en una sola pasada; el receptor calcula SHA256 en línea — reduce a la mitad la E/S de disco en el lado emisor.
Buffer unificado de 1MB: COPY_BUF_SIZE = 1MB es compartido por MCP, Bridge y la ruta de reenvío de puertos CLI — alineado para evitar buffering entre límites.

Desarrollo

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

Pila Tecnológica

Lenguaje: Rust estable (edición 2021)
Runtime asíncrono: tokio
TLS: rustls (sin dependencia de OpenSSL)
Terminal: rmux-sdk
Almacenamiento de auditoría: rusqlite (SQLite incluido)
Transporte MCP: stdio + Streamable HTTP (rmcp v3, JSON-RPC 2.0)

Documentación

Referencia de Herramientas — 68 herramientas MCP con parámetros y valores de retorno
Guía de Despliegue — Arquitectura, compilación, despliegue, operaciones, seguridad
Diseño de Estado del Terminal — Motor heurístico de conciencia del estado del terminal
Contribuir
Política de Seguridad
Registro de Cambios

Licencia

MIT