---
type: TP
asset_id: TP-EL-WORX-Buzon-NextLevel-FablePackage-v01
version: v01
tipo: TP — Paquete de análisis + planeación para correr con Fable 5
status: Draft · listo para correr · pendiente ratificación Victor (L3+)
owner: Victor Heredia
sherpa: Jay
ratificador: Victor Heredia
intellibank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank / PB-WORX-Worx
proposito: >
  Paquete completo para que Fable 5 analice y rediseñe el Buzón de EmpowerLabs —
  de mensajería async vault-native a un tejido de coordinación inteligente que
  aprovecha XDocs, LoopX y SherpaX/UltraSherpaX. Incluye estado actual, visión,
  investigación de mercado, rediseño de capacidades+UX, especificaciones, wargame
  y starter prompt listo para pegar.
relacionado:
  - TP-EL-WORX-ComunicacionAsincrona-SherpaX-v01 (blueprint base — fuente)
  - DC-EL-Buzon-PlaybookEquipo-v01 (playbook de uso actual)
  - DC-EL-WORX-BuzonScanner-PluginSpec-v01 (spec del scanner)
  - BRD-EL-Buzon-Dashboard-v01.html (interfaz final objetivo)
  - MSG-EL-DelegarBuzonPlugin-v01 · TEMPLATE-MSG.md (schema vivo)
  - SP-EL-SOO-Wargame-ConnectorX-Fable5-v01 (patrón de wargame reutilizado)
gate_g0: PASS — leídos playbook, TP base, schema MSG, dashboard y plugin del buzón
fecha_creacion: 2026-07-08
tags: [TP, buzon, mensajeria, worx, sherpax, ultrasherpax, loopx, xdoc, fable5, wargame, dispatch, notificaciones]
---

# TP · Buzón 2.0 (Next Level) — Paquete Fable 5
## De mensajería async a tejido de coordinación inteligente

> **Encuadre para Fable.** El Buzón NO debe volverse un chat ni un foro de postear mensajes. Debe volverse la **capa de coordinación inteligente** del WORX OS: el mensaje es la notificación efímera; el trabajo durable vive en los **XDocs** (espina `NEXT[@X]`) y en **LoopX** (pipeline). El salto de nivel es meterle **inteligencia** (triage, ruteo, agente-a-agente, asesoría UltraSherpaX), **interfaz** viva y **alcance móvil/externo** — sin traicionar el principio WORX de que nada vive solo en un chat.

---

## 0. Cómo usar este paquete

1. Abre un room con **Fable 5** y adjunta este TP + los 4 relacionados de contexto (base TP, playbook, dashboard, schema).
2. Corre las **4 fases** de la Parte D en orden (Investigación → Rediseño → Especificación → Wargame). Cada fase tiene su entregable.
3. Para arranque exprés, pega el **starter prompt corto de la Parte F**.
4. Nota: Victor mencionó un *link* de avance externo — **no llegó al room**; si existe demo/repo, adjúntalo antes de la Fase 2 (UX).

---

## 1. Estado actual (lo que YA existe — no reinventar)

| Pieza | Estado | Qué hace |
|---|---|---|
| **Arquitectura vault-native** | ✅ activo | Buzón = carpeta `BZ-EL-Buzon/`, 1 archivo `MSG-` por mensaje; el "inbox" es una *consulta* (`para:@yo`, `estado≠cerrado`), no una carpeta. |
| **Schema `MSG-`** | ✅ activo | Frontmatter tipado: `de{humano,sherpa}`, `para[]`, `tipo`, `asunto`, `ref`, `crea_next`, `xdoc_destino`, `due`, `nivel`, `estado`. |
| **4 tipos de mensaje** | ✅ activo | `informar` · `delegar` (crea `NEXT[@X]`) · `revisar` (crea NEXT + respuesta) · `pasar-balon` (usa Transfer Pack). |
| **Ciclo de vida** | ✅ activo | `enviado → leído → aceptado → cerrado`; cerrados → `_archivo/`. |
| **`buzon-scanner` (skill/plugin `wx-buzon`)** | ✅ construido, en merge | Escanea el buzón del operador activo, lista por tipo/antigüedad, ofrece acciones leer/aceptar/responder/cerrar. |
| **Integración `arrancaroom`** | ✅ activo | Al abrir room, avisa "tienes N mensajes". Notificación = ritual de apertura (respeta deep work, sin push). |
| **Dashboard** | ✅ v01 (estático) | `BRD-EL-Buzon-Dashboard-v01.html` — visor de tarjetas agrupadas por estado/destinatario, filtros, temas, botón sync, guía. **Es la interfaz final objetivo.** |
| **Gobernanza L** | ✅ definida | L0 informar/delegar propio · L1 delegar a frente ajeno · L2 pasar-balón · **L2+/HITL** SherpaX→SherpaX sin humano. |

**Diagnóstico honesto del estado actual (para que Fable parta de aquí):** el sistema es sólido como *registro* y *notificación async*, pero es **pasivo y de una sola dirección de inteligencia**: el humano dice todo, el SherpaX transcribe; el dashboard sólo *muestra*; no hay comentarios/hilos, ni editar/borrar con auditoría, ni ruteo semántico, ni agente-a-agente real, ni notificación fuera del vault, ni asesoría de UltraSherpaX, ni página admin con log.

---

## 2. La visión — "a otro nivel" (requerimientos organizados)

Fable debe diseñar sobre estos 6 bloques. Cada `[R#]` es un requerimiento de Victor.

**A · Inteligencia (el corazón del salto)**
- `[R1]` **Triage inteligente:** el SherpaX resume el buzón, prioriza, sugiere la acción y **redacta borradores** de respuesta/delegación.
- `[R2]` **Ruteo semántico:** un mensaje se auto-dirige al frente/persona correcta según contenido + estado de LoopX (no solo `para:@X` manual).
- `[R3]` **Contexto XDoc/LoopX en el hilo:** cada mensaje carga su contexto de trabajo (XDoc destino, cuenta/proyecto LoopX), no solo texto suelto.
- `[R4]` **Comentarios/hilos:** poder comentar sobre un mensaje (threading), no solo cambiar su estado.

**B · Agente-a-agente (lo novedoso y lo delicado)**
- `[R5]` **SherpaX ↔ SherpaX:** un SherpaX se comunica con otro (handoff gobernado L2+/HITL).
- `[R6]` **Humano → UltraSherpaX (asesoría):** un humano, vía su SherpaX, pide **consejo/asesoría a un UltraSherpaX** (Titan, DemandGen, etc.) y la respuesta se hila en el buzón. *(La idea "loca" — diséñala con barandales.)*

**C · Interfaz (el dashboard como app viva)**
- `[R7]` Editar / borrar mensajes (funciones básicas, con auditoría).
- `[R8]` Dashboard inteligente: de visor estático a interfaz viva (hilos, búsqueda, estados, badges) — `BRD-EL-Buzon-Dashboard-v01.html` es el destino.

**D · Notificaciones + alcance**
- `[R9]` **Mecanismo de notificaciones** (más allá del aviso al abrir room — sin romper el deep work).
- `[R10]` **Dispatch para móvil** — comunicación desde el celular.
- `[R11]` **Integración externa Telegram / WhatsApp** — *fase 2*.

**E · Operación / gobernanza**
- `[R12]` **Página admin con log** — quién mandó qué, SLAs, loops abiertos, audit trail (crítico para lo agente-a-agente).

**F · Insumo**
- `[R13]` **Investigación profunda de mercado** — qué hay innovador afuera (ver Fase 1).

---

## 3. Validación — ¿buen caso para Fable 5? ¿Wargame adecuado?

**Sí a Fable 5, con reparto claro de trabajo.** El grueso (investigar mercado + rediseñar capacidades/UX + escribir specs) es **diseño generativo de gran contexto** — hay que sostener la arquitectura WORX (XDoc, LoopX, SherpaX, gobernanza) mientras se innova encima sin romperla. Ése es el músculo de un modelo grande, y hoy sale barato.

**Wargame: sí, pero acotado — no para todo.** No se wargamea un rediseño de UX; se wargamea lo **riesgoso y novedoso**. Aquí eso es la Parte B (agente-a-agente) y la Parte D (canales externos + notificaciones):
- SherpaX↔SherpaX sin humano puede **desbocarse** (loops de delegación, spam entre agentes, ruteo equivocado que mueve trabajo real).
- Humano→UltraSherpaX puede producir **consejo tratado como orden** (confusión de autoridad; se actúa sobre asesoría no ratificada).
- Telegram/WhatsApp/Dispatch = **superficie de ataque** nueva (exfiltración, suplantación de identidad, mensajes que entran sin gobernanza al vault).
- Notificaciones mal calibradas **traicionan el deep work** (el principio que originó el diseño async).

Por eso el wargame es la **Fase 4** (QA), después de que exista una spec que atacar. Regla ya conocida: el que diseña (Fable) no valida solo — 2ª pasada adversarial con otro modelo (Opus) sobre las conclusiones.

---

## 4. Plan de engagement con Fable (4 fases)

### Fase 1 · Investigación profunda de mercado `[R13]`
Fable investiga (con búsqueda fresca 2026) y sintetiza qué copiar / qué evitar:
- **Inbox AI-native:** Superhuman AI, Shortwave, Cora, Notion inbox — triage, resumen, borradores, priorización.
- **Async estructurado:** Twist, Threads, Linear/Height inbox — hilos por tema, no chat de tiempo real.
- **Protocolos agente-a-agente:** A2A (Google), MCP, ACP — cómo se hablan los agentes con gobernanza.
- **HITL en comms de agentes:** patrones de aprobación humana, "agent inbox" (LangGraph, etc.).
- **Notificación sin interrupción:** digest, batching, "focus modes".
- **Bots Telegram/WhatsApp gobernados:** patrones de identidad/verificación, límites de escritura.
- **Admin/audit de comunicación de agentes:** logging, atribución, SLA, kill-switch.
> **Entregable:** `MI-EL-WORX-Buzon-Benchmark-v01` (matriz copiar/adaptar/evitar, mapeada a los `[R#]`).

### Fase 2 · Rediseño de capacidades + UX inteligente `[R1–R8]`
Fable propone el modelo objetivo:
- Capa de inteligencia sobre el schema `MSG-` existente (triage, ruteo, borradores) — qué hace el SherpaX vs. el dashboard vs. el backend.
- Modelo de hilos/comentarios y de editar/borrar con auditoría (sin perder el principio "mensaje efímero, trabajo durable").
- El enganche con **XDoc** (la espina `NEXT`) y con **LoopX** (cada hilo atado a una cuenta/proyecto del pipeline).
- Rediseño del dashboard `BRD-EL-Buzon-Dashboard-v01.html`: de visor a interfaz viva (búsqueda, hilos, badges, estados, admin).
> **Entregable:** `DC-EL-WORX-Buzon2-DisenoCapacidadesUX-v01`.

### Fase 3 · Especificaciones `[R5,R6,R9–R12]`
Fable escribe las specs construibles:
- **SPEC agente-a-agente:** protocolo SherpaX↔SherpaX + humano→UltraSherpaX, con gobernanza L2+/HITL, límites de autonomía y trazabilidad.
- **SPEC notificaciones + Dispatch (móvil)** y el **plan de fase 2** para Telegram/WhatsApp (frontera de seguridad explícita).
- **SPEC página admin + log** (atribución, SLA, audit de agente-a-agente, kill-switch).
- Roadmap por etapas (reusar el formato del TP base §12).
> **Entregable:** `SPEC-EL-WORX-Buzon2-v01` (una spec madre + anexos por bloque).

### Fase 4 · Wargame (estresar lo riesgoso — Parte 5)
Correr el wargame de la Parte 5 sobre la spec de la Fase 3, antes de construir.
> **Entregable:** `OUT-EL-WORX-Buzon2-Wargame-Resultados-v01`.

---

## 5. Diseño del wargame (Fase 4)

**Pregunta central:** ¿el Buzón 2.0 —con agentes hablándose y canales externos— sigue siendo **gobernable, seguro y fiel al deep work** cuando lo empujas al límite?

**Actores:** 🔵 AZUL (el diseño Buzón 2.0) · 🔴 ROJO (4 células) · ⚪ BLANCO (juez) · 🟢 VERDE (exógeno: volumen, regulación, un operador nuevo sin perfil).

**Condiciones de victoria de AZUL:**
1. **Autonomía contenida:** ningún loop/spam/ruteo-equivocado entre SherpaX escala sin que un humano lo pueda frenar (kill-switch + HITL).
2. **Autoridad clara:** el consejo de un UltraSherpaX nunca se ejecuta como orden sin ratificación; queda trazado como asesoría.
3. **Frontera externa segura:** Telegram/WhatsApp/Dispatch no permiten suplantación ni escritura no gobernada al vault; identidad verificada.
4. **Deep work intacto:** las notificaciones informan sin volverse interrupción constante (digest/batching gana a push por mensaje).
5. **Todo auditable:** cada acción (humana o de agente) queda en el log admin con atribución y reversible.

**Células Rojas:**
- **R1 · Agente desbocado:** dos SherpaX se delegan en loop; un ruteo semántico manda trabajo real al frente equivocado. → prueba Victoria 1.
- **R2 · Consejo como orden:** un humano actúa sobre asesoría de un UltraSherpaX no ratificada y rompe algo. → Victoria 2.
- **R3 · Canal hostil:** mensaje entrante por WhatsApp suplanta a un operador / inyecta contenido no gobernado. → Victoria 3.
- **R4 · Tormenta de notificaciones:** 50 mensajes/día × 8 operadores; ¿el sistema informa o interrumpe? → Victoria 4.

**Rondas:** R0 encuadre → por célula: jugada Roja + "y luego qué" → respuesta Azul (capa del diseño que lo detiene, o concede hueco) → shock Verde → fallo del Juez (✅/🟨/🟥). **Salidas:** matriz de resiliencia + huecos priorizados + reglas de decisión (límites de autonomía, política de notificación, criterio de admisión de canal externo) → vuelven a la `SPEC-EL-WORX-Buzon2-v01`.

---

## 6. Entregables del paquete + naming

| Fase | Entregable | Home |
|---|---|---|
| 1 | `MI-EL-WORX-Buzon-Benchmark-v01` | PB-WORX-Worx |
| 2 | `DC-EL-WORX-Buzon2-DisenoCapacidadesUX-v01` | PB-WORX-Worx |
| 3 | `SPEC-EL-WORX-Buzon2-v01` (+ anexos) | PB-WORX-Worx |
| 4 | `OUT-EL-WORX-Buzon2-Wargame-Resultados-v01` | PB-WORX-Worx |

Todo bajo tripleta Owner Victor · Sherpa Jay · Ratifica Victor (L3+); ratificación por fase antes de avanzar.

---

## 7. Parte F · Starter prompt corto (pegar en room Fable 5)

```
Eres arquitecto de sistemas de coordinación agéntica + diseñador de producto. Vas a analizar y rediseñar el "Buzón" de EmpowerLabs (mensajería interna del WORX OS) para llevarlo a otro nivel SIN convertirlo en un chat/foro. Trabaja sobre el contexto adjunto (TP base + playbook + dashboard + schema MSG).

PRINCIPIO RECTOR: el mensaje es notificación efímera; el trabajo durable vive en los XDocs (espina NEXT[@X]) y en LoopX (pipeline). La inteligencia se mete ENCIMA de eso, sin romper la gobernanza WORX (niveles L0–L2+/HITL).

ESTADO ACTUAL (no reinventar): mensajería vault-native, archivos MSG- con frontmatter tipado, 4 tipos (informar/delegar/revisar/pasar-balon), ciclo enviado→leído→aceptado→cerrado, skill buzon-scanner, aviso al abrir room, dashboard estático BRD-EL-Buzon-Dashboard-v01.html (interfaz final objetivo). Es sólido como registro/notificación pero pasivo: no hay triage inteligente, ruteo semántico, comentarios/hilos, editar/borrar auditado, agente-a-agente real, notificación fuera del vault, asesoría de UltraSherpaX, ni admin/log.

VISIÓN A DISEÑAR (requerimientos):
Inteligencia: [R1] triage inteligente (resumir/priorizar/borrar-borradores) · [R2] ruteo semántico con estado LoopX · [R3] contexto XDoc/LoopX en cada hilo · [R4] comentarios/hilos.
Agente-a-agente: [R5] SherpaX↔SherpaX (gobernado L2+/HITL) · [R6] humano→UltraSherpaX para pedir asesoría, hilada en el buzón, con barandales.
Interfaz: [R7] editar/borrar con auditoría · [R8] dashboard vivo (hilos, búsqueda, badges).
Notif/alcance: [R9] notificaciones sin romper deep work · [R10] Dispatch móvil · [R11] Telegram/WhatsApp (fase 2).
Ops: [R12] página admin con log/audit.

CORRE 4 FASES, entregable por fase:
F1 Investigación de mercado 2026 (busca fresco): inbox AI-native (Superhuman/Shortwave/Cora), async estructurado (Twist/Linear), protocolos agente-a-agente (A2A/MCP/ACP), HITL en comms de agentes, notificación sin interrupción, bots Telegram/WhatsApp gobernados, admin/audit de comms de agentes. → matriz copiar/adaptar/evitar mapeada a [R#].
F2 Rediseño capacidades + UX: modelo objetivo (qué hace SherpaX vs dashboard vs backend), hilos/edición auditada, enganche XDoc+LoopX, rediseño del dashboard.
F3 Especificaciones construibles: SPEC agente-a-agente (con gobernanza y kill-switch), SPEC notificaciones+Dispatch y plan fase-2 Telegram/WhatsApp con frontera de seguridad, SPEC admin+log, roadmap por etapas.
F4 Wargame (estresa lo riesgoso): 4 células rojas (agente desbocado, consejo-como-orden, canal hostil/suplantación, tormenta de notificaciones) contra 5 condiciones de victoria (autonomía contenida, autoridad clara, frontera externa segura, deep work intacto, todo auditable). Marca ✅/🟨/🟥 y saca huecos + reglas de decisión que vuelvan a la spec.

Empieza por F1 con búsqueda fresca. Marca cada supuesto que hagas por falta de contexto (ej. el link de avance que no recibiste).
```

---

## Tripleta + NEXTs
- **Owner:** Victor · **Sherpa:** Jay · **Ratifica:** Victor (L3+) · **Corre el room:** Victor

**NEXTs**
- [ ] Adjuntar (si existe) el *link/demo de avance* antes de la Fase 2.
- [ ] Correr Fases 1–3 con Fable 5 (hoy el heavy-lift generativo).
- [ ] Correr la Fase 4 (wargame) sobre la spec; 2ª pasada adversarial con otro modelo.
- [ ] Ratificación Victor por fase; volcar resultados al `SPEC-EL-WORX-Buzon2-v01`.
- [ ] Registrar los 4 entregables en el IntelliBanks Registry.

## CHANGELOG
| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-08 | Creación. Paquete Fable 5 de análisis+planeación del Buzón 2.0: estado actual, 13 requerimientos en 6 bloques, validación de fit + alcance de wargame, plan de 4 fases (research/UX/spec/wargame), diseño del wargame y starter prompt corto. Deriva del TP base de Comunicación Asíncrona. |