--- type: TP asset_id: TP-EL-WORX-ComunicacionAsincrona-SherpaX-v01 version: v01 status: Activo — blueprint listo para construir (entrega lista) owner: Victor Heredia sherpa_owner: Jay ratificador: Victor Heredia (L3+) fecha_creacion: 2026-06-22 fecha_ultima_actualizacion: 2026-06-22 intellbank: IB-EL-EmpowerLabs subbank: PB-EL-Project-Bank/PB-WORX-Worx proposito: > Definir el mecanismo de comunicación asíncrona del WORX OS: cómo los miembros del equipo se coordinan vía sus SherpaX —delegar, informar, pedir revisión y pasar el balón— dejando mensajes estructurados en el vault que el SherpaX del destinatario levanta al abrir su room. Es el segundo salto mortal de la metodología: convertir SherpaX aislados en un tejido que se coordina solo. referencia_canonica: - DC-XX-WORX-TaxonomiaXDoc-v01 (sección NEXT del XDoc base) - next-scanner.skill (cosecha de → NEXT[@Persona]) - arrancaroom.skill (ritual de apertura de room) - EL-WeekDashboard-EmpowerLabs-v01.html (pestaña NEXTs del equipo — Salto 1) tags: [tp, worx, comunicacion-asincrona, sherpax, buzon, handoff, delegacion, doix] --- ## Asset Header - **Asset ID:** TP-EL-WORX-ComunicacionAsincrona-SherpaX-v01 - **Tipo:** Transfer Pack — blueprint de proyecto (entrega lista para construir) - **Owner:** Victor · **Sherpa:** Jay · **Ratificador:** Victor (L3+) - **Última actualización:** 2026-06-22 --- # Comunicación asíncrona entre SherpaX ## 1 · El problema (el salto mortal) Hoy cada SherpaX opera aislado: un humano lo invoca, trabaja sobre el vault, y cierra. No hay forma de que un miembro le pida algo a otro *a través de sus SherpaX*, ni de que un SherpaX delegue o informe a otro. Cuando Victor quiere que Anahí revise un documento, eso vive en su cabeza o en un chat externo — fuera del sistema. El salto: que el equipo se coordine **dentro del WORX OS**, de forma asíncrona, vía sus SherpaX. ## 2 · La restricción que define el diseño Los SherpaX no son demonios siempre-encendidos: cada uno es una sesión que un humano invoca sobre el vault compartido. Por lo tanto "los SherpaX se comunican" significa, sin maquillaje: **un SherpaX deja un mensaje estructurado y direccionado en el vault, y el SherpaX del destinatario lo lee cuando su operador lo invoca.** La comunicación es mediada por el vault y asíncrona por naturaleza — que es exactamente lo que se pidió, y lo único factible sin infraestructura nueva. No hay tiempo real, no hay push. La notificación ocurre al abrir el room (vía `arrancaroom`). Esto es una característica, no una limitación: respeta el trabajo profundo y evita la interrupción constante. ## 3 · Principio rector: montarse sobre la espina que ya existe No inventamos un task manager nuevo. La comunicación cabalga sobre el protocolo `→ NEXT[@Persona]:` que ya usan los XDocs y que `next-scanner` ya cosecha. **Delegar = escribir un NEXT[@destinatario] + un mensaje de aviso.** El registro durable de la tarea vive en el XDoc (el NEXT); el mensaje es la notificación, y es efímero. ``` Mensaje (notificación, efímera) → avisa NEXT[@X] en el XDoc (durable) → registra la tarea Transfer Pack (durable) → pasa trabajo grande / un room completo ``` ## 4 · Arquitectura: bus de mensajes vault-native - **Buzón único:** una carpeta `IB-EL-EmpowerLabs/EQ-EL-Equipo/BZ-EL-Buzon/` con un archivo por mensaje. El "inbox de cada quien" no es una carpeta — es una *consulta* (`para: @yo` y `estado != cerrado`), así no se mueven archivos. - **Mensaje = archivo `MSG-` ligero** con frontmatter tipado (schema en §5). - **Ciclo de vida:** `enviado → leído → aceptado → cerrado`. Al cerrarse se archiva (mueve a `BZ-EL-Buzon/_archivo/`); el rastro durable queda en el NEXT/TP referenciado. ## 5 · Schema del mensaje (`MSG-`) ```yaml --- type: MSG asset_id: MSG-EL--v01 de: { humano: Victor, sherpa: Jay } para: ["@Anahí"] # uno o varios destinatarios del equipo tipo: revisar # informar | delegar | revisar | pasar-balon asunto: "Revisar calculadora de logística antes del 29-jun" ref: IB-EL-.../WOI-EL-EmpowerScan-Logistica-USA-MX-v01.html # doc/room/XDoc crea_next: "@Anahí" # opcional: a quién se le crea el NEXT xdoc_destino: IB-EL-.../XP-...-v01.md # dónde se escribe el NEXT due: 2026-06-26 # opcional nivel: L1 # gobernanza (§9) estado: enviado # enviado | leído | aceptado | cerrado fecha: 2026-06-22 --- Cuerpo: contexto breve de lo que se pide y por qué. Una pantalla, no más. ``` ## 6 · Los cuatro tipos de mensaje - **informar** — "esto pasó / esto cambió". No genera tarea. L0 (libre). - **delegar** — "haz esto". Crea un `→ NEXT[@destinatario]:` en el `xdoc_destino`. La tarea aparece en la pestaña NEXTs del equipo automáticamente. - **revisar** — "dame tu lectura de este `ref`". Crea un NEXT de revisión; la respuesta es un `MSG-` de vuelta (tipo informar) que cierra el ciclo. - **pasar-balon** — handoff de trabajo grande o de un room completo. No usa `MSG-` ligero: usa un **Transfer Pack**. El `MSG-` solo anuncia que el TP está listo. ## 7 · El skill `buzon-scanner` (a construir) Hermano de `next-scanner`. Especificación: - **Dispara con:** "¿tengo mensajes?", "mi buzón", "qué me mandaron", "revisa mi buzón", y dentro de `arrancaroom`. - **Hace:** escanea `BZ-EL-Buzon/` los `MSG-` con `para: @` y `estado != cerrado`; los lista por tipo y antigüedad; ofrece acciones (marcar leído / aceptar → vuelve el NEXT activo / responder / cerrar). - **Resultado:** "Tienes 2 mensajes: 1 revisión de Victor (calculadora logística, due 26-jun) y 1 info de Jay. ¿Aceptas la revisión? La acepto y queda como tu NEXT." - **Independiente de sesión:** deriva la raíz del vault de su ubicación, como `next-scanner` y el `sync-nexts` del Semanal. ## 8 · Integración con `arrancaroom` `arrancaroom` ya carga contexto al abrir un room. Se le añade un paso: **correr `buzon-scanner` para el operador activo** y mostrar "tienes N mensajes dirigidos a ti" antes de arrancar el trabajo. Así nadie tiene que acordarse de revisar el buzón — el ritual de apertura lo hace. ## 9 · Gobernanza (niveles L) - **Informar** y **delegar dentro de tu propio frente/room:** L0 — libre. - **Delegar al room/frente de OTRO operador** (le cargas trabajo): **L1** — el NEXT entra como `propuesto`; se vuelve activo solo cuando el dueño de ese frente pone `estado: aceptado`. - **Pasar el balón de un frente completo:** **L2** — ratifica el senior del eje o Victor. - **Un SherpaX delegando a otro SherpaX sin humano en medio:** **L2+ / HITL** al inicio — siempre con ratificación humana hasta que el patrón esté probado. Este es el límite que evita que la autonomía se desboque. ## 10 · Flujo de referencia — "revisar un documento" 1. Victor (vía Jay): `MSG- tipo:revisar`, `para:@Anahí`, `ref:` calculadora logística, `crea_next:@Anahí`, `due:26-jun`. Se escribe el `MSG-` y el `→ NEXT[@Anahí]:` en el XDoc del frente F5. 2. Anahí abre su room → `arrancaroom` corre `buzon-scanner` → "tienes 1 revisión de Victor". 3. Anahí (vía su SherpaX) acepta → el NEXT pasa a activo y aparece en su pestaña NEXTs. 4. Anahí revisa, responde con `MSG- tipo:informar` (su lectura) y su SherpaX cierra el NEXT (`~~NEXT[@Anahí]~~: ✅ DONE`). 5. El mensaje original pasa a `estado: cerrado` y se archiva. El rastro queda en el XDoc. ## 11 · Cuándo cada unidad | Necesidad | Unidad | |---|---| | Avisar algo, sin tarea | `MSG- informar` | | Pedir una acción puntual | `MSG- delegar` → `NEXT[@X]` | | Pedir lectura/feedback de un doc | `MSG- revisar` → `NEXT[@X]` + respuesta | | Entregar un proyecto/room completo | **Transfer Pack** + `MSG-` que lo anuncia | ## 12 · Plan de implementación (etapas · horas) - **Etapa 1 — Protocolo y schema (≈2 h).** Crear `BZ-EL-Buzon/`, plantilla `MSG-`, y este TP como canónico. Definir el campo `nivel` y el ciclo de estados. - **Etapa 2 — `buzon-scanner` skill (≈3 h).** Construir el skill (gemelo de next-scanner): escaneo por destinatario, acciones leer/aceptar/cerrar, escritura del NEXT al aceptar. - **Etapa 3 — Integración con `arrancaroom` (≈1 h).** Añadir el paso "revisa tu buzón" al ritual de apertura. - **Etapa 4 — Vista buzón (≈2 h).** Tablero/pestaña del buzón (Home-Live, 3 temas) que muestra mensajes por estado y destinatario, enlazado al HOY y al Hub. - **Etapa 5 — Piloto 2+2 (≈1 sesión).** Victor↔Anahí pasan un "revisar documento" real de punta a punta; documentar el caso en el LabPraxis. ## 13 · NEXTs del proyecto → NEXT[@Jay]: crear la carpeta `BZ-EL-Buzon/` y la plantilla `MSG-` con el schema de §5 → NEXT[@Jay]: construir el skill `buzon-scanner` (Etapa 2) como gemelo de next-scanner → NEXT[@Jay]: añadir el paso de buzón a `arrancaroom` (Etapa 3) → NEXT[@Victor]: ratificar la gobernanza por niveles L (§9) antes del piloto → NEXT[@Victor]: elegir la pareja del piloto 2+2 (sugerido Victor↔Anahí con la revisión de la calculadora logística) --- ## Cierre Con este mecanismo, el WORX OS deja de ser un conjunto de SherpaX individuales y se vuelve un **tejido coordinado**: el trabajo se delega, se revisa y se pasa el balón sin salir del sistema, de forma asíncrona, sobre la misma espina `NEXT` que ya alimenta los tableros. Es la pieza que convierte la metodología en una organización distribuida real (DOIX).