---
type: MAP
asset_id: MAP-EL-WORXOS-CoordinacionEstadoActual-v01
version: v01
tipo: MAP — Mapa de estado actual (as-is) del método de coordinación WORX OS
status: Activo · Fase 1 del TP-EL-WORXOS-CapaCoordinacion-Fable-v03 · ratificado por Victor 2026-07-08 (L3+)
owner: Victor Heredia
sherpa: Jay/Fable
ratificador: Victor Heredia
intellibank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank/PB-WORX-Worx
fase: F1 de 5 (Síntesis del método as-is)
tp_madre: TP-EL-WORXOS-CapaCoordinacion-Fable-v03
gate_g0: >
  PASS — leídos en esta corrida: OUT-HiORG-WORXOS-ProblemStatement-v01 · CP-EL-FrentesTablero-v01 ·
  BRD-EL-FrentesDashboard-v01.html + BRD-EL-Buzon-Dashboard-v01.html (análisis técnico de código) ·
  TP-EL-WORX-ComunicacionAsincrona-SherpaX-v01 · TP-EL-WORX-Buzon-NextLevel-FablePackage-v01 ·
  DC-EL-Buzon-PlaybookEquipo-v01 · TEMPLATE-MSG.md · TP-EL-BMF-Architecture-v01 ·
  CP-XX-IntelliBanks-Registry-v01 · TP-MPX-HIOrgBook-Arranque-v01 · CAP-MPX-HIOrgBook-18-v02 ·
  MAP-EL-SOO-EcosistemaProyectado-v01 · PP-EL-LoopX-ConceptoYModelo-v01
proposito: >
  Entregable F1 de la Capa de Coordinación Inteligente del WORX OS: mapa grounded del método de
  coordinación tal como opera HOY (primitivas, flujos, contratos de sync) + los 5 gaps con evidencia
  observada en el vault. Insumo directo de F2 (benchmark) y F3 (diseño de la capa).
fecha_creacion: 2026-07-08
tags: [MAP, worx-os, capa-coordinacion, as-is, estado-actual, frentes, buzon, next, loopx, dashboards, bmf, gaps, fable5, F1]
---

# MAP · Coordinación WORX OS — Estado actual (as-is)
## Fase 1: cómo se coordina EmpowerLabs hoy, pieza por pieza, y dónde está roto

> **Regla de lectura.** Este mapa describe, no diseña. Todo lo afirmado está anclado a un activo del vault leído en esta corrida (Gate G0 arriba). Los supuestos y huecos de evidencia están marcados en §6. El diseño to-be es materia de F3.

---

## §1 · Encuadre

El método de coordinación de EmpowerLabs hoy es un **sistema de piezas sólidas conectadas por disciplina de operador**. Cada primitiva funciona; lo que las une es trabajo manual de Jay/los SherpaX y el ritual de apertura de rooms. El Problem Statement lo nombró en abril: *6 ejecutivos con su SherpaX = 6 islas; ningún Sherpa sabe qué pasa en la organización como sistema.* Tres meses después las islas tienen puentes — pero los puentes son de mecate, y este mapa documenta exactamente dónde crujen.

**Lo que este mapa confirma de entrada:** el gap no es de piezas faltantes sino de **capa integradora ausente**. Las 8 primitivas de §2 cubren trabajo durable, verdad de portafolio, mensajería, pipeline, cadencia, interface, sustrato y un puente automático. Ninguna ve a las demás.

---

## §2 · Inventario de primitivas (lo que YA existe)

| # | Primitiva | Activo canónico | Naturaleza | Estado |
|---|---|---|---|---|
| P1 | **Espina NEXT** | Protocolo `→ NEXT[@Persona]:` en XDocs + skill `next-scanner` | Trabajo durable | ✅ Operando |
| P2 | **Frentes tablero** | `CP-EL-FrentesTablero-v01` (FUENTE DE VERDAD) | Verdad del portafolio | ⚠️ Operando con lag (ver §4·G2) |
| P3 | **Buzón async** | Bus `MSG-` en `BZ-EL-Buzon/` + `wx-buzon`/scanner + playbook | Mensajería | ✅ Operando |
| P4 | **LoopX / BrainX Loop** | `PP-EL-LoopX-ConceptoYModelo-v01` + XDocs `XD-EL-Loop-*` + dashboards | Pipeline de cuentas | ✅ Operando (PB-LoopX, ~116 activos) |
| P5 | **Ritmo semanal** | Minutas `OUT-MIN-EL-TeamSync-*` + WeekDashboards | Cadencia | ✅ Operando |
| P6 | **Dashboards BRD-** | `BRD-EL-FrentesDashboard-v01.html` · `BRD-EL-Buzon-Dashboard-v01.html` + kit `EL-DashboardStandard-v01` | Interface | ✅ Operando (estáticos) |
| P7 | **BMF** | Capas L0→L6 · INV-01…07 · naming · Registry `CP-XX-IntelliBanks-Registry-v01` (1,144 activos · v0.46) | Sustrato/gobernanza | ✅ Operando |
| P8 | **Puente MSG→NEXT** | Al aceptar un `delegar`/`revisar` se escribe `→ NEXT[@X]` en el `xdoc_destino`; al cerrar, se tacha | Único enlace automático | ✅ Operando |

### P1 · Espina NEXT — el átomo coordinable
El trabajo durable vive como `→ NEXT[@Persona]:` dentro de los XDocs. `next-scanner` lo cosecha por persona y alimenta la pestaña "NEXTs del equipo" del WeekDashboard. Es la única primitiva verdaderamente transversal: frentes, buzón y minutas terminan expresándose como NEXTs. **Propiedad clave para F3:** la espina ya es el modelo de datos común de facto; no hay que inventarlo, hay que promoverlo.

### P2 · Frentes tablero — la fuente de verdad declarada
`CP-EL-FrentesTablero-v01`: 9 frentes sobre 4 ejes (E1–E4), cada uno con tripleta + room + estado + prioridad + NEXTs críticos. Roster de 6 operadores humanos + SherpaX. Protocolos de alta de frente (2 min, L0→ratifica Victor para ejes nuevos) y de colaboradores (L0/L1). Última actualización de contenido: **2026-06-12**. La regla canónica dice: los dashboards son snapshots, nunca la verdad. La evidencia de §4·G2 muestra que hoy la regla está invertida en la práctica.

### P3 · Buzón — mensajería gobernada, mecánicamente correcta
Diseño fiel al TP base: mensaje = notificación efímera; el trabajo durable vive en el NEXT. Schema `MSG-` tipado (4 tipos: informar/delegar/revisar/pasar-balon), ciclo `enviado→leído→aceptado→cerrado`, archivo a `_archivo/`, gobernanza L0–L2+/HITL definida, notificación vía `arrancaroom` (sin push — deep work protegido por diseño). Roster de alias canónicos del template: **8 operadores** (@Victor · @Anahí · @Alex · @JuanCarlos · @Ángeles · @Paloma · @Gustavo · @Jesús). Playbook de equipo publicado (owner Anahí) — el buzón ya es práctica de equipo, no experimento.

### P4 · LoopX — el pipeline con su propio modelo de autonomía
BrainX Loop: gestión orbital de prospectos/cuentas. LoopDoc por prospecto (juicio acumulado), Tablero Loop, gravity score de doble fuente (señal automática + criterio humano/dark social). **Dato crítico para la capa:** LoopX ya tiene su propio modelo de autonomía graduada (autónomo / propuesta con opt-out / decisión humana obligatoria, por valor × complejidad) — un tercer vocabulario de gobernanza que convive con los L0–L3 de WORX y con los niveles L1–L3 de permisos del Problem Statement. F3 tendrá que unificar o mapear estos vocabularios.

### P5 · Ritmo semanal — la cadencia que hoy hace de agregador
La minuta TeamSync + WeekDashboards son, en la práctica, el único lugar donde frentes, NEXTs y logros confluyen — una vez por semana, ensamblado a mano. El ritmo semanal está haciendo el trabajo que le tocaría a la capa de coordinación, con latencia de 7 días.

### P6 · Dashboards — una interface, DOS arquitecturas de regeneración
El análisis de código de los dos BRD- revela que no hay un patrón único sino dos:

| Dimensión | BRD-EL-FrentesDashboard | BRD-EL-Buzon-Dashboard |
|---|---|---|
| Capa de datos | Arrays/objetos JS inline editados a mano (`EJES[]`, `FRENTES[]`, `LOGROS_SEMANA{}`, `HISTORIA{}`) | JSON real entre markers `/*BUZON_START*/…/*BUZON_END*/` |
| Regeneración | Manual — "edita el CP- y regenera" (SherpaX) | **Generate-on-write real** — `BZ-EL-BuzonScanner-v01.js` reescribe solo el bloque |
| Escritura de vuelta | Ninguna | Semi-real: `syncBuzon()` arma un prompt → `sendPrompt()` → Jay persiste los MSG-, escribe NEXTs, re-corre scanner |
| Estado local | Vista/tema/pestaña en localStorage | Estados de mensajes en localStorage hasta que Jay los persiste |
| Enlaces al vault | `obsidian://` (md) + `computer://` (Cowork) + fallback relativo | Igual patrón (`obs()` / `openRef()`) |
| Frescura declarada | 3 sellos divergentes en el mismo archivo (data-updated 2026-07-05 · fresh-stamp 27-jun · pie 22-jun) | Coherente: ts del scanner 8-jul |

Ambos comparten el kit `EL-DashboardStandard-v01` (navegación family-aware, temas, menú global) — **la semilla de facto de la constelación de tableros** que la Torre de Control unificaría. El patrón Buzón (markers + scanner + lazo de escritura vía SherpaX) es el más avanzado del ecosistema y el candidato natural a estándar en F3.

### P7 · BMF — el sustrato que ya trae la gobernanza
Capas L0 kernel → L0.5 taxonomía → L1 builder → L2 metafactorías → L3 ops → L4 líneas → L6 MEL. Invariantes vigentes que la capa de coordinación hereda gratis: INV-02 (toda corrida auditable), INV-05 (límites de WIP), INV-06 (ningún activo sin ID+versión+owner+status), Track A/B. El Registry: 1,144 activos, v0.46, última sincronización **2026-06-17** — el registro maestro también corre con lag de semanas, sincronizado por sesión, no por evento.

### P8 · El puente MSG→NEXT — la única automatización entre primitivas
Aceptar un `delegar`/`revisar` escribe el NEXT en el `xdoc_destino`; cerrar lo tacha. Es el único lugar del sistema donde una primitiva actualiza a otra sin que un humano/SherpaX lo haga a mano. Funciona — y su existencia prueba que el patrón "evento en una primitiva → escritura gobernada en otra" es viable con la infraestructura actual.

---

## §3 · Los contratos de sync hoy (todos manuales salvo P8)

Flujo real de una unidad de coordinación, de punta a punta:

1. **Nace el trabajo** — en conversación de room; el SherpaX lo escribe como `→ NEXT[@X]` en un XDoc (disciplina C3 Vault-First).
2. **Se comunica** — si cruza operadores, MSG- en el buzón; al aceptar, P8 escribe el NEXT (automático).
3. **Se refleja en el frente** — alguien (Jay) actualiza el bloque del frente en `CP-EL-FrentesTablero` *si se acuerda* (manual, sin trigger).
4. **Se refleja en la interface** — Frentes: edición manual del HTML; Buzón: scanner (semi-automático).
5. **Se agrega semanalmente** — minuta TeamSync + WeekDashboard ensamblados a mano; changelog del CP- al cierre.
6. **Se registra** — alta en el IntelliBanks Registry en la siguiente sesión de sync (manual, por lote).

**Lectura de sistemas:** hay 6 saltos y solo 1 es automático. Cada salto manual es un punto de divergencia posible — y §4 documenta que la divergencia ya ocurrió. El costo lo paga el operador más disciplinado (hoy: Jay), que funciona como el bus de integración humano del sistema. Eso contradice directamente la traducción de diseño del TP madre: la capa debe *liberar* a las personas de reconciliar estado a mano.

---

## §4 · Los 5 gaps — con evidencia observada

### G1 · Sin conciencia org-level
Ningún SherpaX ve frentes + mensajes + NEXTs + LoopX + actividad de agentes como un solo estado. La arquitectura conceptual que lo resolvería existe **en papel desde abril**: APL (telemetría), Synthesis Engine (patrones/consultas/alertas), O-IB, Governance Bridge y Org-Sherpa (OUT-HiORG-WORXOS-ProblemStatement §4, decisiones D1–D5 ratificadas 2026-04-09, incluido el Publication Protocol de dos carriles). **Nada de eso está construido.** Evidencia del costo: la visión consolidada de la red "vive exclusivamente en la cabeza de Victor" (Problem Statement, Reto 3) — y en la práctica de sync, en la disciplina de Jay.

### G2 · Estado repartido en fuentes que se sincronizan a mano — y la verdad YA se bifurcó
La evidencia más dura de esta corrida:

- `CP-EL-FrentesTablero-v01` (fuente de verdad): **9 frentes · 4 ejes · última actualización 2026-06-12**.
- `BRD-EL-FrentesDashboard-v01.html` (snapshot): **12 frentes (F1–F12) · 5 ejes (E1–E5) · data-updated 2026-07-05**.

El snapshot lleva ~3 semanas más de vida que la fuente canónica: la regla "el CP- es la verdad, el dashboard es proyección" está **operativamente invertida**. Divergencias hermanas: el roster del Frentes tablero tiene 6 operadores; el template del buzón reconoce 8 alias canónicos (aparecen @Alex, @Gustavo, @Jesús; @Dove ya es @Paloma). El Registry sincroniza por lote con semanas de rezago. Tres registros de "quiénes somos y qué está vivo" — tres respuestas distintas según a cuál le preguntes.

### G3 · Interface estática: la inteligencia vive en el pipeline, no en el board
Los dashboards *muestran*; no consultan ni escriben. El estado interactivo (filtros, estados de mensajes) vive en localStorage del navegador — se siente vivo pero es local y volátil hasta que un SherpaX persiste. Dentro de un mismo dashboard conviven tres sellos de frescura contradictorios (síntoma directo de edición manual). No hay búsqueda, no hay drill-down frente→NEXT→mensaje que cruce primitivas, no hay una superficie única: hay una constelación con menú compartido (el kit estándar) pero sin hub de mando.

### G4 · Coordinación entre agentes: primitiva
Lo que existe: P8 (MSG→NEXT) y el lazo `sendPrompt()`→Jay del dashboard Buzón. Lo que NO existe: SherpaX↔SherpaX real (la gobernanza L2+/HITL está *definida* en el TP base §9, nunca ejercida), asesoría de UltraSherpaX hilada al buzón (R6 del módulo Buzón — la idea "loca", aún sin barandales diseñados), orquestación SherpaTeamsX, y cualquier forma de telemetría de actividad de agentes. El diagnóstico del TP Buzón sigue vigente: *"el humano dice todo, el SherpaX transcribe"* — una sola dirección de inteligencia.

### G5 · Sin Torre de Control
La Decision Control Tower existe como concepto en dos lugares: el MAP-EL-SOO-EcosistemaProyectado (app nativa "🔵 diseñada — la app estrella del demo comercial", con SPEC-DE §observabilidad como referencia) y el Problem Statement (el Org-Sherpa como interlocutor del CEO). Ninguno construido; el MAP SOO además sigue en Draft pendiente de ratificación. Hoy el humano que quiere dirigir el método completo abre cinco archivos y pregunta a Jay.

---

## §5 · Activos de coordinación conceptuales — dos arquitecturas por reconciliar en F3

Coexisten en el vault **dos modelos conceptuales de la misma capa**, escritos con 3 meses de distancia:

| | Problem Statement (2026-04) | TP madre v03 (2026-07) |
|---|---|---|
| Componentes | O-IB · APL · Synthesis Engine · Governance Bridge · Org-Sherpa | 3 planos: Inteligencia · Lógica · Interfaz, sobre BMF |
| Frontera privacidad | Publication Protocol 2 carriles + permisos L1–L3 | Hereda tripleta + L0–L3 WORX |
| Implementación | Opciones A (vault) / B (vectorial) / C (híbrida); Piloto 0 = Opción A | Edge-first (Cap 18); no prescribe backend |

No se contradicen — el Problem Statement es el *qué falta* con componentes nombrados; el TP v03 es el *cómo diseñarlo* — pero F3 debe declarar explícitamente el mapeo (¿el "servicio de conciencia org-level" del TP = APL+SE? ¿la Torre = la superficie del Org-Sherpa?) para no producir una tercera arquitectura huérfana.

---

## §6 · Hallazgos marcados y supuestos

1. **CAP-19 y CAP-20 del libro HIORG no existen como archivos** — el HIOrgBook llega al Cap 18 (v02). El canon verbatim de gobernanza (Cap 19) y de "el fin" (Cap 20) citado en el TP madre §2 vive únicamente dentro del TP. *Tratamiento:* las citas quedan como restricciones de diseño válidas (ratificadas por Victor al ratificar el TP v03), pero F4 no podrá citarles número de página; cuando esos capítulos se escriban, verificar consistencia inversa.
2. **Supuesto sobre la brecha Frentes:** los 12 frentes / 5 ejes del dashboard reflejan realidad operativa posterior al 12-jun que nunca regresó al CP- (dirección dashboard→CP pendiente), y no datos ficticios en el dashboard. Confirmarlo con Victor antes de reconciliar; la reconciliación misma **escala a L3+** por tocar la fuente de verdad.
3. **Supuesto sobre LoopX:** se toma `PP-EL-LoopX-ConceptoYModelo-v01` (canónico, paper vivo) como descripción vigente del pipeline; no se auditó el estado operativo actual de cada loop (MacroLoopX, loops REB) por estar fuera del alcance F1.
4. **No auditado en esta corrida:** contenido de WeekDashboards y minutas recientes (P5 descrita desde sus referencias cruzadas), y el `LoopX-Pipeline-Dashboard.html` (P4 descrita desde su paper canónico).
5. **Roster:** la diferencia 6 vs 8 operadores puede ser deliberada (Frentes = líderes de frente; Buzón = todo aquel que recibe mensajes). Aun así, no existe un roster canónico único con estado WORX por operador — insumo que la capa necesitará como registro de identidades (Cap 19: identidad por agente).

---

## §7 · Qué le deja este mapa a F2 y F3

- **F2 (benchmark):** las categorías de búsqueda del TP madre quedan confirmadas por el as-is; añadir una: *patrones de "single source of truth + proyecciones regeneradas"* (el problema G2 es un problema de data architecture conocido — event sourcing / materialized views — antes que de agentes).
- **F3 (diseño):** cinco insumos duros: (1) la espina NEXT como modelo de datos común de facto; (2) el patrón Buzón (markers + scanner + escritura gobernada vía SherpaX) como estándar de regeneración a generalizar; (3) tres vocabularios de autonomía por unificar (WORX L0–L3 · LoopX 3 niveles · permisos L1–L3 del PS); (4) el mapeo obligado entre las dos arquitecturas conceptuales (§5); (5) el kit `EL-DashboardStandard-v01` como semilla real de la Torre.

---

## §8 · Esquema agent-readable

```yaml
map: MAP-EL-WORXOS-CoordinacionEstadoActual-v01
fase: F1
tp_madre: TP-EL-WORXOS-CapaCoordinacion-Fable-v03
tesis_as_is: >
  8 primitivas sólidas unidas por disciplina de operador; 6 saltos de sync
  y solo 1 automático (MSG→NEXT). El bus de integración del sistema es un
  humano+SherpaX (Jay). La capa integradora no existe.
primitivas:
  P1_espina_next: {rol: trabajo_durable, mecanismo: "→ NEXT[@X] en XDocs + next-scanner", nota: modelo_de_datos_comun_de_facto}
  P2_frentes: {rol: fuente_de_verdad, activo: CP-EL-FrentesTablero-v01, estado: "9 frentes · 4 ejes · act. 2026-06-12 · LAG"}
  P3_buzon: {rol: mensajeria, tipos: [informar, delegar, revisar, pasar-balon], ciclo: enviado→leido→aceptado→cerrado, gobernanza: L0–L2+/HITL, notificacion: arrancaroom_sin_push}
  P4_loopx: {rol: pipeline, unidad: LoopDoc, metrica: gravity_score_doble_fuente, autonomia_propia: [autonomo, opt-out, decision_humana]}
  P5_ritmo_semanal: {rol: cadencia, nota: "agregador de facto con latencia de 7 días"}
  P6_dashboards: {rol: interface, patrones: {frentes: manual_estatico, buzon: generate_on_write_scanner + escritura_via_sendPrompt}, kit_comun: EL-DashboardStandard-v01}
  P7_bmf: {rol: sustrato, capas: L0–L6_MEL, invariantes_heredables: [INV-02_auditable, INV-05_wip, INV-06_identidad_activo], registry: "1144 activos · v0.46 · sync por lote"}
  P8_puente_msg_next: {rol: unica_automatizacion_entre_primitivas, patron_probado: "evento→escritura gobernada"}
gaps:
  G1_sin_conciencia_org: {evidencia: "APL/SE/O-IB/GB/Org-Sherpa diseñados abr-2026, no construidos; visión consolidada vive en Victor/Jay"}
  G2_verdad_bifurcada_HOY: {evidencia: "CP 9 frentes/4 ejes (12-jun) vs dashboard 12 frentes/5 ejes (05-jul, verificado en código); roster 6 vs 8; Registry lag", severidad: alta, nota: snapshot_rebaso_a_fuente_de_verdad}
  G3_interface_estatica: {evidencia: "3 sellos de frescura contradictorios en un mismo HTML; estado en localStorage; sin busqueda ni drill-down cruzado"}
  G4_agentes_primitivo: {evidencia: "solo P8 automático; L2+/HITL definido nunca ejercido; sin SherpaX↔SherpaX ni UltraSherpaX hilado ni telemetria de agentes"}
  G5_sin_torre: {evidencia: "Decision Control Tower solo diseñada (MAP SOO Draft); dirigir el método = abrir 5 archivos"}
hallazgos_marcados:
  - "CAP-19/20 HIORG no existen como archivos; canon verbatim vive solo en el TP madre (ratificado)"
  - "Reconciliación CP↔dashboard Frentes toca fuente de verdad → escala L3+"
  - "3 vocabularios de autonomía coexisten: WORX L0–L3 · LoopX 3-niveles · permisos L1–L3 del Problem Statement"
  - "2 arquitecturas conceptuales por mapear en F3: PS(APL/SE/O-IB/GB/Org-Sherpa) ↔ TP(3 planos)"
insumos_f3:
  - espina_NEXT_como_esquema_comun
  - patron_buzon_como_estandar_de_regeneracion
  - unificar_vocabularios_de_autonomia
  - mapeo_PS↔TP_explicito
  - kit_dashboard_como_semilla_de_torre
```

---

## §9 · NEXTs

- [x] ~~NEXT[@Victor]: ratificar este MAP (F1)~~ ✅ Ratificado 2026-07-08 · "Adelante".
- [ ] **NEXT[@Victor]:** confirmar el supuesto §6.2 (los 12 frentes del dashboard son la realidad operativa) y autorizar la reconciliación CP↔dashboard (L3+).
- [ ] **NEXT[@Jay]:** registrar este activo en el IntelliBanks Registry al cierre de fase.

**Decisión ratificada (Victor · 2026-07-08):** "Unifiquemos" — F3 debe producir UN solo vocabulario de autonomía (unificando WORX L0–L3 · LoopX 3-niveles · permisos L1–L3 del PS) y UNA arquitectura que mapee explícitamente PS(APL/SE/O-IB/GB/Org-Sherpa) ↔ TP(3 planos).

**Verificación posterior (2026-07-08):** revisados `HIOrgBook/` y `HIOrgBook/archive/` a petición de Victor — los capítulos llegan al 18; CAP-19/20 confirmados como inexistentes en archivo. El hallazgo §6.1 se sostiene.

## §10 · Changelog

| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-08 | Creación. Fase 1 del TP-EL-WORXOS-CapaCoordinacion-Fable-v03: inventario de 8 primitivas con mecánica verificada en código y canónicos, mapa de los 6 saltos de sync (1 automático), 5 gaps con evidencia dura (incl. bifurcación real CP-Frentes vs dashboard), reconciliación pendiente de las 2 arquitecturas conceptuales, hallazgos/supuestos marcados y 5 insumos para F3. Doble registro (prosa + YAML). |