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.
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
Sección titulada «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).
Qué consume (y qué deriva)
Sección titulada «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.
Relacionado
Sección titulada «Relacionado»- Referencia del bus de eventos — los eventos
edge.observed,cost.sampledyfinding.reportedque 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.