T04x06: «Scriptorium update!»

ESTE MATERIAL ES DENTRO DEL CONTEXTO DE ESCRIVIVIR.CO Y, POR ENDE, DENTRO DE SU CAMPO CONTEXTUAL.

NSFW – PoC – Experimental – Test/Error Laboratory – Don’t use on prod

Raw: https://github.com/escrivivir-co/aleph-scriptorium/tree/integration/beta/scriptorium/ARCHIVO/future-pipeline-engine

Related: https://github.com/escrivivir-co/aleph-scriptorium/tree/integration/beta/scriptorium/ARCHIVO/simulator-hub/.github/skills/simulador-voces/packs/red-blue-white-black-pack

Marco del dossier:

https://escrivivir-co.github.io/para-la-voz-sdk/

Dossier: Future Pipeline Engine & Scriptorium Integration

1. Diagram

VPS Teatro Arrakis (OASIS_PUB)Capa Local / Peer Clientfutures-engine(Dramaturgo)engine-plan(Pipeline E2E)WiringEditor(Node-RED Mesh)media-extraction(STT/faster-whisper)Pub.Rooms(scriptorium-rooms)BotHubSDK(bot-rabbit/spider/horse)StreamDesktop(kick-aleph-bot)futures-engine(Dramaturgo)engine-plan(Pipeline E2E)WiringEditor(Node-RED Mesh)media-extraction(STT/faster-whisper)Pub.Rooms(scriptorium-rooms)BotHubSDK(bot-rabbit/spider/horse)StreamDesktop(kick-aleph-bot)Inicialización del TeatroTransmisión y HostDerivación al TeatroFederación y MensajeríaCaptura y TranscripciónOperación y OrquestaciónIngesta hacia Future MachinesRetorno e Interfaz Externa (IACM)MC ArrakisStreamerEntrevistadoElencoPúblicoCrea Room de sesión1Envía PEER CARD (Token PUBLIC_ROOM)2Conecta y pide capabilities()3Retorna PRESETS (desde Zeus)4launch-session() (Activa el flujo)5Transmite stream base6Audio hosteado7Participación Activa (LiveSharedCoding)8Push narrativo (Chat / Firehose)9Deriva Stream (HLS/VOD) a Room de Teatro Arrakis10Handshake WSS (Red RETRO y Peers)11Solicitud de extracción de media12Descarga y STT (faster-whisper)13Vuelca transcripción a cache (Soporte Textual)14Ingesta asíncrona de transcripciones (canales RxJS)15Inspección y diagnóstico del Pipeline "End-to-End"16Alimentación de texto para nodos de bifurcación (escenarios)17Escenarios diseminados (vía bot-horse a Telegram/Externos)18MC ArrakisStreamerEntrevistadoElencoPúblico

1.2 El Concepto de PRESET y su Asignación a Agentes

El ecosistema Scriptorium no entrega todas las herramientas a todos los actores por defecto. Utiliza el concepto de PRESET para empaquetar capacidades específicas y asignarlas a agentes o clientes especializados, orquestado a través del plugin McpPresets y el generador Zeus.

Ecosistema de AgentesPlugin McpPresets AgentZeus Web InterfaceInfraestructura MCPGalleryExpone ToolsExpone ToolsExpone ToolsExporta JSON CompatibleVincula CapabilitiesVincula CapabilitiesVincula Capabilitiesmcp-mesh-sdk
Tools & Firehosemcp-model-sdk
Inferencia & PromptsMCPLauncherServer
OrquestaciónCatálogo de CapabilitiesGenerador de PRESETSImportación y Validación
Esquema PresetModelpresets/*.jsonagent-assignments.jsonAgente: Agente/Modelo
Inyecta mcpPresets en RecipeAgente: Agente/Modelo
Inyecta mcpPresets en RecipeCliente: Streamer
Recibe Preset de Orquestación

2. Índice de Enlaces y Rutas Clave

El índice completo de referencias y rutas ha sido extraído a su propio documento para facilitar el mantenimiento. 👉 Ver Índice de Enlaces (index.md)

3. Análisis de la Document Machine (BARTLEBY / para-la-voz-sdk)

El flujo de la Document Machine está diseñado como un SDK editorial. Su propósito es analizar corrientes de pensamiento (corpus) para acabar cristalizando una «Voz» (un agente) que produzca nuevo material (en este caso original, poemas) desde las reglas de ese corpus, y no hablando sobre él.

3.1 Los 4 Agentes Core (SDK)

El SDK base proporciona 4 agentes predefinidos que actúan como la maquinaria de análisis y estructuración:

  • @bartleby (Analista): Solo lectura. Analiza los textos de entrada (editoriales) y genera un informe estructurado en 5 secciones: linaje, taxonomía funcional, mecanismos retóricos, emergencias y ausencias estructurales.
  • @archivero (Gestor del Corpus): Gestiona la «fuente de la verdad» (corpus.md). Compara los nuevos análisis con el corpus existente para detectar qué es nuevo, qué confirma algo existente, qué evoluciona y qué discrepa. Luego lo integra.
  • @cristalizador (Diseñador de artefactos): Observa los patrones acumulados. Cuando hay suficiente información, propone la creación de un nuevo agente (la @voz) construyendo sus instructions y prompts.
  • @portal (Interfaz adaptativa): Sirve como interfaz de entrada que adapta el tono según quién interactúe con el sistema (ej. perfil de un editor, comité o inteligencia hostil).

A estos 4 se les suma un quinto agente que es el resultado del proceso:

  • @voz (Agente Mod): El agente generado y cristalizado que reside en la capa de la aplicación (el mod activo) y es el que finalmente produce contenido basándose en el corpus.

3.2 Las Fases / El Flujo (Los 6 Comandos)

El flujo está dictado por «guiones» (documentos humanos paso a paso) y una serie de comandos de Copilot que ejecutan los agentes:

  1. /guion (Usuario): Genera el «roadmap» de trabajo (un documento Markdown con checkboxes) a partir de una plantilla. Prepara el terreno antes de activar los agentes.
  2. /feed (@bartleby): Ingresa un nuevo texto (editorial). Bartleby lo lee y genera el informe de análisis.
  3. /diff-corpus (@archivero): El archivero compara el nuevo informe de Bartleby contra el mapa acumulativo de conocimiento.
  4. /merge-corpus (@archivero): Tras revisar el diff, el archivero integra los hallazgos validados dentro del documento maestro del corpus.
  5. /design (@cristalizador): Si hay suficientes textos procesados, el cristalizador analiza todo y diseña al nuevo agente (@voz), sus prompts y sus instrucciones.
  6. /status (@archivero): Comando de utilidad para saber cuántos textos se han procesado y el estado de las emergencias en el corpus.

3.3 Estructura de Ficheros (main vs mod)

El SDK opera bajo un patrón estricto unidireccional: la capa pura del motor (main) hereda hacia la capa de datos/lore (el mod activo), sin ensuciar el motor.

Capa del Motor (DocumentMachineSDK – main)

  • .github/agents/, .github/prompts/, .github/instructions/: Aquí viven los 4 agentes core y los 6 comandos.
  • .github/templates/guion-ciclo.template.md: La plantilla para generar los guiones paso a paso.
  • proyecto.config.template.md: Plantilla para configurar nuevos proyectos/universos.

Capa del Universo Generado (mod/lore activo)

  • guiones/YYYY-MM-DD_slug.guion.md: Los roadmaps humanos ejecutables.
  • corpus/editoriales/: Los textos fuente «crudos» que entran a la máquina.
  • corpus/analisis/: Los informes generados por @bartleby.
  • corpus/corpus.md: El «mapa acumulativo». Es la fuente de la verdad (lo que se pasa luego a la Vector Machine).
  • mod/agents/voz.agent.md: El agente cristalizado listo para funcionar.
  • mod/prompts/ y mod/instructions/: Las reglas de la @voz.
  • docs/: Catálogo web (Jekyll) donde se publicaría la producción de la @voz.

4. El «Future Machine» Pipeline (La Súper-Cadena)

Investigando más a fondo en el código (como se documenta en el SDK de Cortos / mod legislativa), el flujo base de BARTLEBY descrito en la sección 4 no es siempre el proceso principal. En contextos más amplios, la Document Machine actúa como una subcadena dentro de una pipeline de orquestación narrativa de mayor escala conocida como la Future Machine.

En esta súper-cadena, el análisis meticuloso de @bartleby se convierte en un simple paso interno (un motor de procesamiento de fondo) dentro de un proceso de 5 etapas orquestado por un nuevo conjunto de agentes.

4.1 La Secuencia de 5 Agentes (Future-Machine)

El flujo de trabajo se estructura en la siguiente cadena: Puzzle → Archivero Lore → Grafista → Demiurgo → Dramaturgo Cortos.

  1. @Puzzle (Validación): Recibe las piezas de «lore» (los textos crudos/borradores) y las verifica contra el esquema de datos antes de dejarlas entrar al sistema.
  2. @Archivero Lore (Ingesta y Corpus): Aquí es donde la subcadena de Bartleby es absorbida. El Archivero Lore toma todo el pack validado por Puzzle y delega en @bartleby el análisis profundo de todas las piezas (linajes, mecanismos, ausencias). El resultado unificado es el CORPUS_PREVIEW.md: un mapa puro y sin juicios de todo el material.
  3. @Grafista (Estructuración del Grafo): Lee el corpus generado y detecta los puntos de fricción, huecos, tensiones y bifurcaciones de la historia. Con esta información, estructura un grafo dirigido de narrativas o futuros posibles.
  4. @Demiurgo (Instanciación de Universo): Toma el grafo creado por el Grafista y, en consenso con el usuario, selecciona una rama específica. Rellena las variables faltantes, define las reglas iniciales y convierte esa rama en una «spec concreta»: un Universo (universo/*.md). Es un escenario formalizado.
  5. @Dramaturgo / Dramaturgo Cortos (Generación de Obra): Es el destino final de la pipeline. Toma el Universo instanciado por el Demiurgo y lo transforma en una pieza literaria o producción final (por ejemplo, un «corto»).

5. Análisis e Investigación de StreamDesktop y StreamDesktopAppCronos

La construcción de este diagrama de caso de uso y el índice de referencias se sustenta en los documentos técnicos y manuales de usuario del Scriptorium:

  1. StreamDesktop/README-SCRIPTORIUM.md
  2. StreamDesktopAppCronos/README-SCRIPTORIUM.md
  3. WiringEditor/README-SCRIPTORIUM.md
  4. BlockchainComPort/OASIS_PUB/site/scriptorium/README.md
  5. DocumentMachineSDK/.github/skills/futures-engine/SKILL.md
  6. DocumentMachineSDK/.github/skills/media-extraction/SKILL.md
  7. DocumentMachineSDK/.github/skills/engine-plan/SKILL.md

Para más detalles, consulta el Índice del Future Pipeline Engine.

El análisis de StreamDesktop y StreamDesktopAppCronos no se enfoca en su estado técnico final, sino en el plan y caso de uso que aportan dentro del ecosistema Scriptorium (actualmente en creación).

  • StreamDesktop (kick-aleph-bot): Actúa como un gateway entre plataformas de streaming (Kick.com) y el Scriptorium. Define una arquitectura de 3 canales (App, Sys, UI) usando RxJS, lo que permite que los mensajes de chat y eventos del stream fluyan bidireccionalmente hacia agentes específicos (como @plugin_ox_kickstream o actores del teatro).
  • StreamDesktopAppCronos (kick-aleph-crono-bot): Es un overlay de OBS visual con animaciones y cronómetros. Aunque en su Sprint 1 opera de manera standalone, su integración futura permitirá que comandos desde el Scriptorium (por ejemplo !timer mediante un mini HTTP listener) reaccionen en el stream, integrándolo con el Teatro transmedia.

5.1 Flujo Hipotético: Ingesta hacia Future Machines

Supongamos el siguiente flujo:

  • a) El streamer y un entrevistado hosteados en el scriptorium del streamer derivan el audio a una room en el contexto de Teatro Arrakis de Scriptorium a través del VPS (BlockchainComPort/OASIS_PUB/site/scriptorium) donde está instalada una skill de futures-engine.
  • b) En el VPS está instalado media-extraction y un operador vuelca a las transcripciones del stream en proceso, operados con WiringEditor y la skill de engine-plan.

5.2 Flujo de Conexión y Federación (Pub.Rooms)

A continuación se detalla cómo un cliente externo (por ejemplo, el servidor TypeScript de BotHubSDK o una instancia de StreamDesktopApp) se federa con el servidor VPS del Scriptorium.

El cliente utiliza el endpoint de conexión en el servidor VPS y las credenciales proporcionadas en la Peer Card del vestíbulo público (rooms.scriptorium.escrivivir.co y el token de PUBLIC_ROOM) para autenticarse a través de un transporte WebSocket seguro (WSS), evitando la necesidad de abrir puertos entrantes.

PUBLIC_ROOMFederationScriptorium Rooms(Node-RED scriptorium-rooms)Caddy Proxy(VPS Pub-Web)Peer Client(BotHubSDK / StreamApp)PUBLIC_ROOMFederationScriptorium Rooms(Node-RED scriptorium-rooms)Caddy Proxy(VPS Pub-Web)Peer Client(BotHubSDK / StreamApp)Setup local con token PUBLIC_ROOM y AliasValidación de shared-secretTráfico bidireccional de eventos y comandosalt[Auth Exitosa][Auth Fallida]Conexión saliente WSS (Puerto 443)wss://rooms.scriptorium.escrivivir.co/runtime1Reverse proxy hacia scriptorium-rooms:30102Handshake & Autenticación3Handshake Válido (Conectado)4Ingresa al canal federado (Node-RED mesh)5Rechazado (Unauthorized) + Log auditable6

Además de esta federación externa, BotHubSDK gestiona la conexión real hacia los canales de mensajería mediante el protocolo IACM (bot-rabbit -> bot-spider -> bot-horse).

  • a) bot-rabbit: Actúa como el origen de la cadena local de eventos.
  • b) bot-spider: Nodo intermedio de agregación donde los peers de la red RETRO se conectan. Desde aquí, los peers pueden optar por federarse directamente a Pub.Rooms con su propio Node-RED.
  • c) bot-horse: Da las herramientas para dejar el canal listo. Se encarga de la exposición final del canal IACM, históricamente hacia Telegram.

A continuación se ilustra este segundo grafo detallando la topología de la mensajería IACM:

bot-horse(Canal IACM)bot-spider(Red RETRO Peers)bot-rabbit(Ingesta Local)bot-horse(Canal IACM)bot-spider(Red RETRO Peers)bot-rabbit(Ingesta Local)Cadena BotHubSDKConexión de Peers RETROHabilitación de Canalbot-horse da las herramientaspara dejar el canal listo (ej. Telegram)Flujo de eventos1Enlace IACM2

6. Diagrama de Flujo y Máquina de Estados (MCP Control)

Para orquestar la creación de la sesión y los procesos continuos del ecosistema, el servidor MCP implementa la siguiente máquina de estados. Este diseño garantiza el control de los intervalos de conexión segura, la ingesta de transcripciones y la participación del público.

6.1 State Machine de la Sesión

ESTE MATERIAL ES DENTRO DEL CONTEXTO DE ESCRIVIVIR.CO Y, POR ENDE, DENTRO DE SU CAMPO CONTEXTUAL. NSFW - PoC - Experimental - Test/Error Laboratory - Don't use on prod
MC Arrakis crea la RoomMC envía CARD con token al StreamerStreamer invoca capabilities()Streamer invoca launch-session()MC Arrakis desconecta la roomRoomCreatedStreamerConnectedCapabilitiesReceivedRecibe PRESETS
(Ensamblados por Zeus)ActiveSessionLínea a) Live ConnectionPing / Keep-alive real timeIntervalSeguroLínea b) TranscripcionesInterval con soporte textual (media-extraction)TranscriptionFeedLínea c) Público / ChatFeed MCPFirehoseServer.ts (intervenciones no etiquetadas)PublicFirehoseCycleEnded

6.2 Secuencia de la Máquina de Estados

Esta secuencia complementaria detalla las tres líneas principales de comunicación que se mantienen en paralelo durante la sesión activa:

MCPFirehoseServerServicio de TranscripcionesPub.Rooms (VPS)Streamer (MCP Client)MC ArrakisMCPFirehoseServerServicio de TranscripcionesPub.Rooms (VPS)Streamer (MCP Client)MC ArrakisActive Session (Líneas Paralelas)loop[Reloj / Interval Seguro]loop[Interval Servicio]loop[Firehose]par[a) Real Time Segura][b) Feed de Transcripciones][c) Intervenciones del Público]Crea sesión / Room1Envía PEER CARD con Token2Conecta (WSS)3capabilities()4Retorna PRESETS (Zeus)5launch-session()6Ping / Live Status7Nuevos fragmentos (faster-whisper)8Eventos de chat sin etiquetar (raw feed)9Desconecta Room / Finaliza Ciclo10Cierre de Sesión11

7. Zeus y la Generación de PRESETS (MCPGallery)

Dentro del Scriptorium, la creación y gestión de los packs de capacidades (los PRESETS) no es un proceso manual aislado, sino que recae en Zeus (mcp-presets-site). Zeus es una interfaz web que opera como el organizador del catálogo del ecosistema MCP.

7.1 ¿Cómo Funciona Zeus?

Zeus se conecta a las definiciones de los servidores activos en la galería (como mcp-model-sdk y mcp-mesh-sdk), lee las herramientas que exponen (capabilities) y permite al orquestador agruparlas en packs lógicos. Estos packs se almacenan en mcp_presets.json y se sirven a los agentes o clientes cuando hacen su llamada inicial.

Zeus Web InterfaceMCPGalleryExpone CapabilitiesExpone CapabilitiesExporta mcp_presets.jsonmcp-model-sdk
(Tools & Resources)mcp-mesh-sdk
(Firehose & Net)Lectura de CapabilitiesEmpaquetado de ToolsGeneración de PRESETSCliente / Streamer
Solicita Handshake

7.2 Ejemplo Real: Pack «MCP Launcher Control»

Para habilitar el flujo descrito en la Sección 6, Zeus puede ensamblar un preset específico para el control de la sesión (como el preset real con ID 1777738351433 hallado en su configuración). En lugar de darle al Streamer acceso a todo el motor, Zeus empaqueta exclusivamente las herramientas de orquestación.

Este preset contiene un payload real con tools provenientes de servidores como MCPLauncherServer:

  • launch_mcp_server
  • stop_mcp_server
  • restart_mcp_server
  • launch-session
  • get_server_status
Contiene«PRESET PACK»MCPLauncherControl+String id: "1777738351433"+String category: "productivity"+List<String> items(Tools)Toolslaunch_mcp_server()launch-session()get_server_status()

Gracias a Zeus, el Scriptorium mantiene sus servidores desacoplados, mientras que la interfaz web se encarga de crear estos «trajes a medida» (presets) para cada actor que entra al Arrakis Theater.

Future Pipeline Engine – Índice de Referencias

Este índice recopila y describe los principales componentes del Scriptorium involucrados en el caso de uso del Future Pipeline Engine, detallando su rol, capacidades y ruta en el sistema.

1. Componentes de Transmisión e Interfaz

StreamDesktop (kick-aleph-bot)

  • Ruta: ALEPH/StreamDesktop
  • Referencia: README-SCRIPTORIUM.md
  • Rol en el Ecosistema: Bot de Node.js/TypeScript que actúa como un gateway bidireccional mediante WebSockets entre plataformas de streaming (Kick.com) y Scriptorium.
  • Mapeo Ontológico: Emplea canales RxJS que se asocian con agentes (App → @plugin_ox_kickstream, Sys → @redflag, UI → @orangeflag).

StreamDesktopAppCronos (kick-aleph-crono-bot)

  • Ruta: ALEPH/StreamDesktopAppCronos
  • Referencia: README-SCRIPTORIUM.md
  • Rol en el Ecosistema: Overlay visual HTML/JS para OBS. Proporciona efectos visuales (animación Matrix) y un contador regresivo.
  • Caso de uso a futuro: Podrá controlarse mediante llamadas a una API local o mediante eventos procedentes del chat parseados por kick-aleph-bot.

2. Orquestación y Flujos de Datos

WiringEditor (node-red-alephscript-sdk)

  • Ruta: ALEPH/WiringEditor
  • Referencia: README-SCRIPTORIUM.md
  • Rol en el Ecosistema: Entorno de nodos basado en Node-RED que permite la estructuración de flujos (wiring) para la coordinación de canales (app, sys, ui) y orquestación multi-agente (@teatro, @tarotista).
  • Capacidades: Permite conectar la ingesta asíncrona de transcripciones o eventos de chat (feed JSON) y pasarlos por reglas analíticas hacia agentes de inferencia semántica (FIA).

3. Servidores Públicos y Catálogos

3.1 OASIS_PUB Site Scriptorium

  • Ruta: ALEPH/BlockchainComPort/OASIS_PUB/site/scriptorium
  • Referencia: README.md
  • Rol en el Ecosistema: Catálogo estático del Scriptorium (accesible vía pub.escrivivir.co/scriptorium/). Lee el archivo catalog.json para listar todas las herramientas públicas disponibles y agentes con prefijos SKU (PLG-CORE, SDK-UI, etc.).

3.2 Zeus MCP Web Interface (mcp-presets-site)

  • Ruta: ALEPH/MCPGallery/zeus
  • Rol en el Ecosistema: Interfaz web que lee las capabilities y herramientas de los servidores de MCPGallery (como mcp-model-sdk y mcp-mesh-sdk). Permite agrupar estas capacidades en packs o PRESETS. Cuando un cliente (ej. el Streamer o un agente) pide sus capacidades, recibe uno de estos packs generados por Zeus (por ejemplo, un preset de Launcher con tools reales como launch_mcp_server y launch-session para orquestar la infraestructura).

4. Habilidades del Motor (DocumentMachineSDK Skills)

Las Skills son definiciones portables y agnósticas encargadas de resolver piezas especializadas del pipeline:

4.1 media-extraction

  • Ruta: ALEPH/DocumentMachineSDK/.github/skills/media-extraction/SKILL.md
  • Referencia: SKILL.md
  • Rol en el Ecosistema: Extrae recortes de video o audio de streams remotos (Twitch VODs, YouTube o HLS) usando herramientas como yt-dlp o streamlink y los transcribe de manera local utilizando faster-whisper. El texto extraído conforma un soporte textual versionable y catalogado en la base del Lore.

4.2 engine-plan

  • Ruta: ALEPH/DocumentMachineSDK/.github/skills/engine-plan/SKILL.md
  • Referencia: SKILL.md
  • Rol en el Ecosistema: Protocolo encargado de la inspección, simulación y diagnóstico del pipeline «End-to-End».
  • Conceptos Clave: Define una arquitectura canónica de 6 capas de datos (lore-db, análisis, corpus, grafo de bifurcación, universos, obras) más 2 transversales (@Pipeline, @Portal). Esta herramienta puede identificar huecos de especificación en el sistema.

4.3 futures-engine

  • Ruta: ALEPH/DocumentMachineSDK/.github/skills/futures-engine/SKILL.md
  • Referencia: SKILL.md
  • Rol en el Ecosistema: Toma el texto documentado del Corpus como entrada y genera «ficciones plausibles». Es la habilidad del Dramaturgo. En lugar de predecir o extraer eventos pasados, detecta nodos de bifurcación y construye 2 a 5 escenarios paralelos basados en variables de estado y la asimetría del contexto.
  • Flujo: Las transcripciones ingresadas (provistas por media-extraction y preparadas por WiringEditor) serán alimentadas a este motor para ramificar escenarios de las posibles derivaciones del stream en progreso.

5. Servidores de Capa, Federación y SDKs (VPS)

5.1 ScriptoriumVps (Pub.Rooms & Node-RED Mesh)

  • Ruta: ALEPH/ScriptoriumVps y ALEPH/BlockchainComPort/OASIS_PUB/site/scriptorium/index.html
  • Rol en el Ecosistema: Servidor de replicación y vestíbulo para las salas layer2. Aloja la instancia de Node-RED (scriptorium-rooms) que expone el endpoint WSS rooms.scriptorium.escrivivir.co/runtime.
  • Credenciales y Acceso: La «PEER CARD» de la interfaz pública provee el token PUBLIC_ROOM (q5S6IaYodYVDmhLZeH9RLTGUpcNqlC9c66e9Lylo) para que clientes externos realicen el bootstrap y se federen sin necesidad de abrir puertos locales.

5.2 BotHubSDK (TypeScript Server)

  • Ruta: ALEPH/BotHubSDK
  • Referencia (Ejemplo Broadcast): broadcast-2026-05-09T23-28-42-391Z.md
  • Rol en el Ecosistema: Actúa como el servidor TypeScript que se enlaza como peer a la red federada de Node-RED. Además, orquesta la cadena de conexión IACM estructurada en tres pasos (bot-rabbit -> bot-spider -> bot-horse):
    • a) bot-rabbit: Punto de origen e ingesta local de eventos en la cadena.
    • b) bot-spider: Nodo de agregación al que se conectan los agentes de la red RETRO. Mediante un handshake válido, estos peers pueden unirse a Pub.Rooms para habilitar comunicación bidireccional (vía WSS).
    • c) bot-horse: Da las herramientas para dejar el canal listo. Opera como el puente definitivo del protocolo IACM hacia plataformas externas de mensajería (como Telegram), coexistiendo con la federación a Node-RED.

5.3 Creación de Sesión y Estructura Teatral (Arrakis Theater)

  • Roles y Contexto: El ecosistema opera bajo la metáfora del Arrakis Theater, una infraestructura para sesiones layer2. Se compone de:
    • Casa Arrakis: Opera en las sombras preparando el terreno y los snapshots.
    • MC (Maestro de Ceremonias): Conduce el flujo de la sesión.
    • Elenco: Actores (desarrolladores en LiveSharedCoding) que actúan en pantalla.
    • Público: Participa desde el chat empujando la narrativa (vía Firehose).
  • Flujo de Inicialización (Link con 5.1 y 5.2): A través de la infraestructura VPS (Pub.Rooms), el MC crea la room y envía la PEER CARD con el token (PUBLIC_ROOM) al Streamer. El Streamer se conecta usando este token.
  • Protocolo AlephScript y MCP: Tras conectar, el Streamer realiza la llamada capabilities del protocolo. Como respuesta, recibe los PRESETS (ensamblados por Zeus), los cuales le otorgan herramientas y prompts predefinidos (como los del servidor de Launcher), permitiéndole invocar comandos como launch-session para arrancar la maquinaria de la sesión y conectar su stream.

Deja un comentario