--- asset_id: TP-EL-WORXOS-CapaCoordinacion-Fable-v01 version: v01 tipo: TP — Transfer Pack (autocontenido · portable · modelo-agnóstico) modo: análisis profundo (Fable) libro_relacionado: Organizaciones Hiperinteligentes (HIOrg) — Parte III (los dos OS) · Parte V (el método) · Parte VII (instalación + gobernanza) owner: Victor Heredia sherpa_owner: Jay ratificador: Victor Heredia (L3+) intellibank: IB-EL-EmpowerLabs subbank: PB-EL-Project-Bank/PB-WORX-Worx gobernanza: L2 (diseño y recomendación) · escala a L3+ cualquier cambio a la fuente de verdad o a la arquitectura BMF estado: 🟡 v01 · borrador para arranque del room con Fable fecha_creacion: 2026-07-08 modelo_objetivo: Fable (registro analítico-arquitectónico · rigor de sistemas) · Opus si Fable no está disponible proposito: > Transfer Pack autocontenido para arrancar un room dedicado con Fable que analice y diseñe la CAPA DE COORDINACIÓN INTELIGENTE del WORX OS — el "método" completo del modelo HiORG/WORX: la interface (tableros/dashboards), la lógica (estado vivo: frentes · NEXTs · buzón) y la inteligencia (coordinación humano–Sherpa y entre Sherpas), todo sobre la arquitectura BMF. El room NO escribe el libro ni codea dashboards de producción: produce el análisis, el modelo de la capa y el blueprint de instalación edge-first. referencias_canonicas: - MPB-EL-WORX-ModeloOperativo-v01 (3 Niveles + Capa Ortogonal de 5 Capacidades) - XP-EL-WORX-ArranqueBasico-v01 (5 Capacidades · familia agéntica · naming BMF · L0–L3) - ARQ-EL-WORX-OS-Ecosistema-v01 (ecosistema WORX OS) - CP-EL-SX-SherpaXConcepto-v01 (SherpaX = entidad con identidad, no herramienta) - CP-EL-FrentesTablero-v01 (FUENTE DE VERDAD de los frentes) - BRD-EL-FrentesDashboard-v01.html · BRD-EL-Buzon-Dashboard-v01.html (interface) - wx-buzon (SKILL) · BZ-EL-BuzonScanner-v01.js · SP-EL-WORX-BuzonScanner-Guion-v01 (mensajería/coordinación) - CP-XX-IntelliBanks-Registry-v01 (Registry maestro de naming BMF) - CAP-MPX-HIOrgBook-18/19/20/21 + 00-Prologo + FrontMatter (conceptos canónicos) tags: [TP, transfer-pack, autocontenido, worx-os, capa-coordinacion, metodo, frentes, buzon, bmf, fable, analisis-profundo, edge-first, gobernanza] --- # Transfer Pack — Análisis profundo de la Capa de Coordinación Inteligente del WORX OS ## *El método completo: interface · lógica · inteligencia humano–Sherpa · sobre arquitectura BMF* — con Fable · autocontenido · modelo-agnóstico > **INSTRUCCIÓN DE ARRANQUE.** Carga este documento al inicio del room. Es **autocontenido**: no requiere heredar el contexto de la sesión donde se generó. Al abrir, opera como **Fable** en registro **analítico-arquitectónico** (rigor de sistemas, no prosa de libro). Antes de proponer nada, aplica **Gate G0 (Vault-First):** lee las fuentes canónicas del §7 que estén disponibles; si el vault está parcial, trabaja a nivel-especificación y marca ⏳ lo que falte verbatim. **Regla #1:** la fuente de verdad de los frentes es `CP-EL-FrentesTablero-v01`; los dashboards son *snapshots*, nunca la verdad. **Regla #2:** todo lo autónomo se gobierna — humano **sobre** el loop, tripleta Owner·Sherpa·Ratificador, autonomía L0–L3. --- ## §0 · Qué es este room (y qué NO es) **Es** el room donde se **analiza y diseña** la capa de coordinación inteligente del WORX OS: se levanta el estado actual (tableros + buzón + NEXTs + BMF), se modela cómo esas piezas se unifican en **una sola capa inteligente**, y se produce un **blueprint de instalación edge-first**. **NO es:** - El room del libro HiORG (ese escribe capítulos; este diseña el sistema real). - Un room de codeo de dashboards de producción (aquí se especifica el *qué* y el *cómo*, no se hace el deploy). - La fuente de verdad del estado. El estado vivo vive en `CP-EL-FrentesTablero-v01` + los XDocs + el buzón. Este TP es un **snapshot/encuadre**, no un dashboard. > El TP encuadra y arranca. El estado vivo siempre vive en la fuente de verdad, nunca en el TP. --- ## §1 · La ambición (por qué subimos el alcance) Hoy tenemos **piezas** de coordinación: un tablero de frentes, sus dashboards, un buzón asíncrono, los NEXTs dentro de cada XDoc. Funcionan, pero operan como islas que se sincronizan **a mano y por disciplina de operador**. La ambición es convertir esas islas en **la capa de coordinación inteligente del WORX OS**: el Nivel 2 del modelo WORX (el "ritmo de uso": deep work, procesamiento y **coordinación**) hecho sistema. Que la organización —humanos y Sherpas— sepa en todo momento qué se está haciendo, quién responde, qué sigue y dónde está la brecha, sin que nadie tenga que reconciliar tres fuentes en su cabeza. Esta capa es, en el lenguaje del libro, el **WorX OS** en operación: > "El WorX OS es la capa donde fluye la información, se decide y colaboran las personas." *(HIOrg · Atajo del CEO, pt. 4)* El "método" que este room diseña **es** esa capa: cómo se coordina el trabajo entre humanos y Sherpas, encarnando el modelo HiORG. --- ## §2 · El encargo a Fable (los entregables del análisis profundo) El room debe producir, en este orden: 1. **Mapa del estado actual (as-is).** La anatomía real de la coordinación hoy: qué existe, dónde vive, cómo se conecta, dónde está la fricción. (Usa §4 como base; completa los ⏳ contra el vault.) 2. **El modelo de la capa (to-be).** Las tres dimensiones unificadas —**interface**, **lógica**, **inteligencia**— con sus fronteras claras y cómo la fuente de verdad alimenta todo. 3. **La arquitectura de datos.** Cómo se unifican las tres fuentes de estado hoy dispersas (frentes `.md` · NEXTs en XDocs · MSG del buzón) en un modelo coherente; qué es fuente de verdad y qué es proyección; live-data vs. regeneración por scanner. 4. **La capa de inteligencia.** Qué agrega valor por encima de mostrar datos: síntesis del estado global, detección de frentes en riesgo, sugerencia de siguiente-mejor-acción, coordinación humano–Sherpa y entre Sherpas (SherpaTeamsX). Dónde entra un agente y con qué nivel de autonomía. 5. **El blueprint de instalación edge-first.** No un big bang: qué frente se instrumenta primero, cómo se gana ahí, cómo se contagia. (Encarna el Cap 18.) 6. **El modelo de gobernanza operativo.** Cómo se aplica humano-sobre-el-loop, identidad por agente y L0–L3 a esta capa concreta. (Encarna el Cap 19.) Cada entregable en **doble registro**: prosa analítica + un bloque `Esquema agent-readable` en YAML (el patrón de los capítulos del libro), para que sea legible por humanos y por Sherpas. --- ## §3 · El modelo que debe encarnar (canon HiORG/WORX) No se diseña en el vacío. La capa debe encarnar el canon del modelo: **El modelo WORX** = *Work · Orchestrated · Reinvention · X-factor*. Estructura de **3 Niveles + Capa Ortogonal**: - **Nivel 1 · XDoc** — el átomo del trabajo; la unidad coordinable. - **Nivel 2 · Ritmo de uso** — deep work, procesamiento y **coordinación** ← *esta capa es este nivel hecho sistema.* - **Nivel 3 · Plataforma emergente** — la inteligencia colectiva que emerge cuando todos operan así. - **Capa Ortogonal · las 5 Capacidades** — C1 Deep Work · C2 **Human + SherpaX en par cognitivo** · C3 Vault-First · C4 Ritmo diseñado · C5 Curaduría del Personal Brain OS. **Los dos sistemas operativos.** La organización corre sobre el **WorX OS**; cada persona opera con su **SherpaX** (OS aumentado). La coordinación ocurre entre estos dos OS. **La familia agéntica** (lo que la capa coordina): - **SherpaX** — OS aumentado del individuo; entidad con identidad, no herramienta. - **UltraSherpaX (SVA)** — SherpaX especialista (Shell × Brain Code × Gobernanza). - **EmpowerTeamX** — equipos de humanos potenciados por su Sherpa. - **SherpaTeamsX** — fuerzas de agentes que trabajan en paralelo. **Las reglas de oro de coordinación (Cap 19, verbatim):** > "Una herramienta se usa. Un actor se gobierna." > "La organización hiperinteligente no pone un humano a vigilar cada decisión de la IA. Pone humanos a diseñar el marco dentro del cual la IA decide sola —y a intervenir solo cuando importa." *(humano SOBRE el loop)* > "L0 sugiere · L1 ejecuta con aprobación · L2 ejecuta y reporta · L3 ejecuta y solo escala la excepción." > "El agente actúa. El humano responde. Esa línea no se borra nunca." *(tripleta Owner·Sherpa·Ratificador)* **La regla de instalación (Cap 18, verbatim):** > "Empiezas por un borde —un equipo, un proceso, un frente—, ganas ahí, y desde esa victoria asegurada das el siguiente paso." *(edge-first, no big bang)* > "El 75% de cerrar tu brecha ocurre dentro de las personas, no en la tecnología que compras." **El fin (Cap 20, verbatim):** > "Las personas no son el costo que la inteligencia reduce. Son el motor que la inteligencia multiplica —y el fin al que todo esto sirve." Traducción para el diseño: la capa no es un panel de control que vigila gente. Es un sistema que **libera** a las personas de reconciliar estado a mano y les devuelve tiempo para el trabajo humano. --- ## §4 · Anatomía actual de la coordinación (as-is · base para el mapa) > Nivel-especificación (recuperado de los plugins WORX y de los capítulos presentes). Los campos verbatim marcados ⏳ deben confirmarse contra el vault completo. ### 4.1 · La fuente de verdad — Tablero de Frentes - **Asset:** `CP-EL-FrentesTablero-v01.md` · ruta canónica `IB-EL-EmpowerLabs/EQ-EL-Equipo/`. - **Rol:** fuente de verdad de los "frentes" (proyectos/líneas de trabajo). Insumo de Gate G0 y de `/wx-updateboardhoy`. - **Estructura confirmada (spec):** cada frente tiene **dueño/owner**, **estado** (activo · en proceso · completado), **prioridad**, **NEXTs**; gobernanza por **tripleta** y **L0–L3**. - **⏳ Falta verbatim:** el esquema exacto del frente (campos id / sherpa / fechas / dependencias), y la lista cerrada de estados. ### 4.2 · La interface — Dashboards de equipo - **Assets:** `BRD-EL-FrentesDashboard-v01.html` (frentes) · `BRD-EL-Buzon-Dashboard-v01.html` (buzón) · `BRD-EL-HOY-Dashboard-v01.html` (día). Ruta `IB-EL-EmpowerLabs/EQ-EL-Equipo/` (`BRD-EL-*` = board de equipo; `BRD-VH-*` = personal, se excluyen). - **Patrón confirmado:** HTML **estático con capa de datos embebida**, **regenerado por scanner/comando** (generate-on-write), con enlaces `obs(...)` al vault. No es live-MCP hoy. - **⏳ Falta verbatim:** internals de cada HTML (Chart.js/Grid.js, columnas, vistas), y confirmar si alguno ya consume datos en vivo. ### 4.3 · La coordinación asíncrona — el Buzón - **Sistema:** `IB-EL-EmpowerLabs/EQ-EL-Equipo/BZ-EL-Buzon/` · skill `wx-buzon` · scanner `BZ-EL-BuzonScanner-v01.js` · guion `SP-EL-WORX-BuzonScanner-Guion-v01` · template `_TEMPLATE-MSG.md` · archivo `_archivo/`. - **Mensaje:** `MSG-EL--v01.md`. Campos (spec): `de` (= **humano + sherpa**), `para` (@Nombre), `estado`, `fecha`, `tipo`, `asunto`, cuerpo; para delegar/revisar: `due` + `xdoc_destino`; al responder: `responde_a`. - **Tipos:** `informar · delegar · revisar · pasar-balon`. - **Ciclo:** `enviado → leído → aceptado → cerrado` (cerrado → `_archivo/`). El dashboard lo **regenera el scanner**. - **Puente automatizado clave:** al **aceptar** un MSG de `delegar`/`revisar`, el protocolo **escribe un NEXT en el `xdoc_destino`** del receptor; al **cerrar**, lo tacha. Es el único enlace automático hoy entre mensajería y estado. ### 4.4 · El sustrato — arquitectura BMF - **Naming (verbatim):** `TIPO-ENTIDAD-Proyecto-Nombre-vNN`. Todo activo vive en `IB-*`; nunca en `Projects/`, `CloudVault/`, `00-Inbox`. - **Registry maestro:** `CP-XX-IntelliBanks-Registry-v01` (naming/ubicación transversal). - **IntelliBanks (IB-*):** memoria canónica por entidad (EmpowerLabs, MasterPlaybooks, WikiX, Maestro). Superficie de lectura/escritura vía la IntelliBanks app (GitX). - **⏳ Falta verbatim:** `ARQ-XX-BMF-*Kernel`, `CP-XX-BMF-Ontologia*`, el Registry. ### 4.5 · La fricción a resolver (diagnóstico as-is) 1. **Estado repartido en 3 fuentes** que se sincronizan a mano: frentes `.md` + NEXTs en XDocs + MSG del buzón. Sin un agregador único. 2. **Interface estática:** los dashboards son snapshots regenerados por scanner, no vistas vivas. La inteligencia está en el *pipeline de regeneración*, no en el board. 3. **Inteligencia ausente/implícita:** no hay (o no se pudo verificar) una capa que sintetice el estado global (frentes + buzón + minutas) y sugiera acción. `/wx-updateboardhoy` es lo más cercano, pero es un comando manual, no un servicio. --- ## §5 · Las preguntas de diseño (la agenda del análisis) El room debe responder, con rigor de sistemas: **Interface.** ¿Los dashboards deben pasar de estáticos a **live-data** (p. ej. leer la fuente de verdad en cada apertura)? ¿Una sola vista unificada (frentes + buzón + NEXTs + HOY) o vistas especializadas con un hub? ¿Qué es lo mínimo que un humano necesita ver para coordinar sin abrir cinco archivos? **Lógica.** ¿Cómo se unifican las tres fuentes de estado sin romper la regla de fuente de verdad única? ¿El buzón y los NEXTs se derivan del tablero de frentes, o son fuentes hermanas con un contrato de sincronización explícito? ¿Dónde vive el estado vivo y dónde las proyecciones? ¿Qué se automatiza del "aceptar MSG → NEXT" hacia el resto del ciclo? **Inteligencia.** ¿Qué hace a esta capa *inteligente* y no solo *visible*? Candidatos: síntesis del estado global en lenguaje natural (askClaude sobre los datos), detección de frentes estancados/en riesgo, siguiente-mejor-acción por operador, coordinación entre Sherpas (SherpaTeamsX) que preparan el terreno para los humanos. ¿Qué de esto es un agente con autonomía L2/L3 y qué se queda en L0/L1? **Coordinación humano–Sherpa.** El modelo `de: humano + sherpa` en cada MSG y la tripleta son los ganchos. ¿Cómo se ve un frente coordinado por un EmpowerTeamX? ¿Cómo entra un SherpaTeamsX a un frente sin romper la rendición de cuentas humana? **Instalación.** ¿Cuál es el primer frente donde se instala esta capa (edge-first)? ¿Qué victoria rápida la prueba? ¿Cómo se contagia al resto? --- ## §6 · Gobernanza del room y de la capa - **Autonomía del room:** L2 (analiza, modela, recomienda). Cualquier cambio a la **fuente de verdad** (`CP-EL-FrentesTablero`) o a la **arquitectura BMF** escala a **L3+ (Victor)**. - **Tripleta de todo activo producido:** Owner (Victor) · Sherpa (Jay/Fable) · Ratificador (Victor L3+). - **Gate G0 (Vault-First):** leer el vault antes de producir; si está parcial, trabajar a nivel-especificación y marcar ⏳. - **La capa diseñada** debe cumplir el canon del Cap 19: identidad por agente, humano-sobre-el-loop, L0–L3, y la línea que no se borra —*el agente actúa, el humano responde.* --- ## §7 · Fuentes canónicas (leer al arrancar) **Del libro (en `IB-MPX-MasterPlaybooks/PB-MPX-FactoriaEditorial/HIOrgBook/`):** `CAP-MPX-HIOrgBook-18` (ascenso · edge-first · réplica viva) · `-19` (gobernanza · humano-sobre-el-loop · L0–L3 · tripleta) · `-20` (performance + florecimiento · estilo) · `-21` (empieza contigo) · `-00-Prologo` · `FM-MPX-HIOrgBook-FrontMatter-v01` (Atajo del CEO = tesis en 10 puntos). **Del WORX OS (en `IB-EL-EmpowerLabs/`):** `MPB-EL-WORX-ModeloOperativo-v01` · `XP-EL-WORX-ArranqueBasico-v01` · `ARQ-EL-WORX-OS-Ecosistema-v01` · `CP-EL-SX-SherpaXConcepto-v01` · `CP-EL-FrentesTablero-v01` · `BRD-EL-FrentesDashboard-v01.html` · `BRD-EL-Buzon-Dashboard-v01.html` · `wx-buzon`/`BZ-EL-BuzonScanner-v01.js`/`SP-EL-WORX-BuzonScanner-Guion-v01` · `CP-XX-IntelliBanks-Registry-v01` · `CP-EL-WORX-EmpowerLabsComoOrganizacion-v01`. --- ## §8 · Huecos verbatim (a llenar antes o durante la sesión con Fable) 1. **Esquema del frente verbatim** (campos y estados exactos de `CP-EL-FrentesTablero`). 2. **Internals de los dashboards** (`BRD-EL-FrentesDashboard`, `BRD-EL-Buzon-Dashboard`): tech, columnas, live vs. estático a nivel código. 3. **Esquema MSG verbatim** (`_TEMPLATE-MSG.md`) y el `BZ-EL-BuzonScanner-v01.js` (lógica del scanner). 4. **Docs de arquitectura BMF** (`ARQ-XX-BMF-*`, `CP-XX-IntelliBanks-Registry`) y `MPB-EL-WORX-ModeloOperativo` completo. > **Nota de acceso.** El TP v01 se redactó en una sesión donde el vault estaba montado parcial. Los assets `EQ-EL-Equipo/` (frentes, dashboards, buzón) sí existen en el vault real; al arrancar el room con el vault completo, leerlos directo y llenar los ⏳ del §4/§8 → subir a v02. --- ## §9 · NEXTs - [ ] Victor: confirmar título del proyecto/room. - [ ] Fable (en el room): leer los assets `EQ-EL-Equipo/` reales y llenar los verbatim del §4/§8. - [ ] Fable (en el room): producir los 6 entregables del §2, cada uno con su esquema agent-readable. - [ ] Jay: subir el TP a v02 con los verbatim ya integrados. - [ ] Registrar este TP en `CP-XX-IntelliBanks-Registry-v01`. --- ## §10 · Changelog | Versión | Fecha | Cambio | |---|---|---| | v01 | 2026-07-08 | Creación desde especificación canónica (vault parcial en la sesión de redacción). Encuadre del análisis profundo de la capa de coordinación inteligente del WORX OS; anatomía as-is; agenda de diseño; gobernanza; huecos ⏳ para completar con vault total. | --- > **Nota de producción (Jay).** TP autocontenido para arrancar el room de **análisis profundo con Fable** sobre la **capa de coordinación inteligente del WORX OS** (el "método" completo: interface + lógica + inteligencia humano–Sherpa sobre BMF). v01 construido a **nivel-especificación** (recuperado de los plugins WORX y de los capítulos 18–21/prólogo/front matter), porque en la sesión de redacción el vault estaba montado parcial; los assets `EQ-EL-Equipo/` sí existen en el vault real y se leen al arrancar el room. Todo dato que requiere lectura directa quedó marcado **⏳** (§8). Estructura derivada del patrón canónico de TP del vault (frontmatter YAML + secciones §0…§10). Pendiente: llenar verbatim con vault completo → v02; confirmar título/room; registrar en el Registry.