Módulo II — operación en vivo y sesiones

El módulo II es la vista de operación en vivo del estate: qué está haciendo ahora mismo cada sesión de agente, sus totales de tokens y coste en vivo, un estado de Claude Code derivado y una línea temporal reconstruible. Mientras que el módulo I (inventario) materializa el estate durable, el módulo II mantiene una capa operativa en vivo por sesión sobre el mismo flujo de observaciones — y muestra solo lo que ese flujo lleva honestamente.

Olivares 0.4 también lanza CLI oficiales de proveedor como hijos propios bajo un perfil de proveedor. Esa vía gestionada es el mismo módulo. No sustituye la capa ni fusiona dos homes que anuncian el mismo id de sesión del proveedor (CHANGELOG.md [26.9.0] B1/B2).

Qué es

El módulo II es un módulo de la capa Core dirigido por el bus, hermano del inventario. Mantiene un registro en vivo indexado por la referencia externa de cada sesión, construido a partir del flujo cooperativo de observaciones — nunca sondeado, nunca fabricado. Por sesión rastrea:

• la acción actual (la última herramienta usada) y el recurso/modo que tocó;
• los totales de tokens y coste en vivo, leídos de las muestras de coste (el ledger de coste canónico y FinOps son el módulo XI, no aquí — esto es solo la cifra en vivo);
• un estado de Claude Code derivado (cc_state); y
• una línea temporal a la que cada evento observado se añade en orden de ingesta.

Su contrato y entidades

El módulo registra dos entidades acotadas al tenant. sessions.live contiene el registro en vivo por sesión — acción/recurso/modo actual, referencia de modelo, tokens de entrada/salida en vivo, coste en vivo, conteos de eventos y de llamadas a herramientas, y marcas temporales de primer/último evento. sessions.timeline contiene una fila reproducible por evento, ordenada por ingesta. No hay columna de ciclo de vida almacenada: el flujo cooperativo no lleva ninguna señal de fin o fallo, de modo que la única señal de vitalidad honesta es el cc_state derivado.

cc_state se deriva en tiempo de lectura a partir de la recencia de los eventos — active / idle / ended — y cambia a un estado de evasión-silenciosa cuando el conector eleva ese hallazgo (nunca lo escribe el propio módulo). Las lecturas se sirven bajo rutas del módulo (lista en vivo, sesión única, línea temporal por sesión) más un flujo SSE en vivo; cada lectura requiere el permiso de lectura de sesión, y abrir el flujo se audita automáticamente. El canal SSE está estrictamente aislado por tenant (un cliente recibe solo instantáneas de su tenant autorizado) y es de mejor esfuerzo (un cliente lento descarta el frame intermedio y recibe el siguiente — la ingesta nunca se bloquea).

Provider profiles and live_ref

Un perfil de proveedor es la identidad durable de una instancia de proveedor configurada en un entorno de ejecución: controlador, entorno y el config_home / user_home canónicos. No es una cuenta autenticada del proveedor. Registrar, renombrar, desactivar/activar y retirar viven bajo /v1/m/sessions/provider-profiles. Las rutas aparecen solo en la lectura admin configuration. Un lanzamiento nombra provider_profile_ref; el servidor resuelve los homes y persiste una instantánea no secreta en el run antes del spawn (CHANGELOG.md [26.9.0] B1; web/src/features/agentops/types.ts).

Una observación se pliega en la fila en vivo de su canal, calculado por el servidor a partir del registro de fuente sellado por el host (CHANGELOG.md [26.9.0] B2):

Channel	Meaning
legacy	no registration
observed	a source dedicated to a profile by a binding approved at host admission for the exact applied revision
source	a known registration with no verifiable profile
managed	a run the plane launched; the only row carrying canonical_sid and run_ref

Cada fila en vivo expone live_ref y attribution. Dos homes que anuncian el mismo id de sesión del proveedor son dos filas con dos cronologías. Lee una fila con GET /v1/m/sessions/live/by-id/{live_ref} (y su consulta de cronología / stream / runs). Las rutas de id externo desnudo permanecen y son legacy: responden solo para la fila legacy.

Los controladores se registran en cada nodo al arrancar. Al iniciar una sesión, el motor usa la instalación gestionada verificada más reciente y después la CLI en su PATH. OLIVARES_SESSION_RUNTIME_CLAUDE_BIN, _CODEX_BIN, _GROK_BIN y _OPENCODE_BIN sustituyen explícitamente esa resolución (véase Configuración). Si no encuentra un ejecutable, rechaza el lanzamiento. Las demás comprobaciones de preparación, incluida la autenticación del perfil y la política de lanzamiento, siguen vigentes. Pasos del operador: Operar una sesión de proveedor.

Un mensaje puede llevar imágenes. olivares session send <session> --attach shot.png "what is wrong here?" y el compositor de la consola (pegar, soltar o el clip) almacenan cada PNG, JPEG, WebP o GIF con la sesión, hasta cuatro por mensaje y 3.75 MB cada una, y luego las envían junto con el texto; un mensaje necesita su texto, así que una imagen sola no se envía (la CLI y el compositor lo piden). Claude Code recibe un bloque de contenido de imagen y Codex su propia entrada de imagen; una herramienta sin entrada de imagen rechaza el mensaje por su nombre antes de enviar nada. La API es POST /v1/m/sessions/runs/{ref}/attachments (la imagen, en base64), GET .../attachments/{id} y attachments en .../input. Las imágenes viven bajo el directorio de datos, por tenant y sesión, y se eliminan junto con la sesión.

Qué consume (y qué deriva)

El módulo II consume el mismo flujo de observaciones de datos mínimos que el inventario — edge.observed, cost.sampled y finding.reported. Solo los edges cuyo origen es una sesión producen operación en vivo; las muestras de coste ligadas a una sesión suman a la cifra de tokens/coste en vivo (aquí no se escribe ningún CostRecord); los hallazgos cuyo sujeto es una sesión se anotan, y un hallazgo anti-evasión marca el estado de evasión. Dos campos se derivan en vivo a partir de esas mismas señales: agent_ref del agente atribuido a una sesión, y summary de un hallazgo (forense) de compactación de contexto cuyo título es seguro como resumen por contrato — nunca un resumen fabricado por un LLM.

Límites honestos

• goal se mantiene vacío — honestamente. El flujo cooperativo es de datos mínimos y no lleva el objetivo ni la lista de tareas de una sesión; se expurgan en el conector y no hay texto de prompt en proceso sobre el cable. El registro en vivo modela el campo para que el contrato y la UI estén listos y cualquier futuro canal de metadatos pueda poblarlo, pero el módulo nunca lo inventa.
• Sin ciclo de vida almacenado. El flujo no tiene señal de fin/fallo, así que la vitalidad de una sesión es el cc_state derivado por recencia — no un estado persistido. Un estado ended significa no hay eventos recientes, no un apagado limpio confirmado.
• La cifra en vivo no es el ledger. Los tokens/coste en vivo son una lectura operativa de las muestras de coste; el registro de coste autoritativo y conciliable es el ledger FinOps del módulo XI. No trates la cifra en vivo como verdad de facturación.
• Los datos mínimos son una propiedad del cable. Solo se llevan y persisten referencias, clasificaciones y contadores de vitalidad/coste — nunca payloads, prompts, comandos o PII.

Relacionado

• Referencia del bus de eventos — los eventos edge.observed, cost.sampled y finding.reported que consume este módulo.
• Catálogo de módulos — dónde encaja el módulo II y la división honesta de actuación.
• Mapa de acceso y recursos — el módulo Core hermano que es dueño del grafo de acceso R/RW.
• Visión general de la arquitectura — el motor y las capas.
• Conectar Claude Code — empieza a producir el flujo en vivo.
• Honestidad y límites — lo que el producto hace y no hace hoy.