--- asset_id: WOI-EL-WORX-MasterPlaybook-v01 type: WOI — Work in Progress version: v01 status: En construcción — actualizar con cada aprendizaje validado owner: Victor Heredia sherpa_owner: Jay fecha_inicio: 2026-06-03 intellbank: IB-EL-EmpowerLabs proposito: > Manual operativo de la metodología WORX para construir OrgsX. Documenta disciplinas, hábitos, reglas, patrones y aprendizajes. Fuente de verdad para Sherpas, facilitadores y nuevos colaboradores. brief: TP-EL-WORX-MasterPlaybook-Brief-v01.md meta_graduacion: Completar M01-M09 + validar con ≥2 casos → MPB-EL-WORX-MasterPlaybook-v01 --- # MasterPlaybook WORX ## Guía operativa para construir una OrgsX --- > *Este documento es vivo. Se construye desde la operación, no desde la teoría. Cada regla aquí escrita ha sido probada en la práctica — en EmpowerLabs o en un cliente. Las hipótesis van en M10 hasta que se validan.* --- ## Estado del documento | Módulo | Título | Estado | Última actualización | |---|---|---|---| | M01 | Fundamentos WORX / OrgsX | 🔄 Borrador inicial | 2026-06-03 | | M02 | Los 3 pilares | 🔄 Borrador inicial | 2026-06-03 | | M03 | Disciplinas fundamentales | 🔄 Borrador inicial | 2026-06-03 | | M04 | Coherencia Vault-Room | 🔄 Borrador inicial | 2026-06-03 | | M05 | El ciclo diario con Sherpa | ⬜ Pendiente | — | | M06 | Coordinación y gobernanza | ⬜ Pendiente | — | | M07 | Ciclo de vida de activos | ⬜ Pendiente | — | | M08 | Onboarding de participantes | ⬜ Pendiente | — | | M09 | Anti-patterns | 🔄 Borrador inicial | 2026-06-03 | | M10 | Aprendizajes del campo | 🔄 Activo (columna viva) | 2026-06-03 | --- --- ## M01 · Fundamentos: qué es WORX y qué es una OrgsX ### Qué es WORX WORX es la metodología operativa de EmpowerLabs para implementar un **WORX OS** en una organización. No es una plataforma tecnológica ni un software — es un modelo de trabajo que integra tres capas: Método, Infraestructura e Interfaz. Cuando los tres pilares operan juntos, la organización se transforma en una **OrgsX**. WORX es agnóstico al tamaño, sector e industria. Lo que varía por cliente es el contenido (los casos de uso, los proyectos, el vocabulario del dominio) — no la estructura. La estructura es siempre la misma. ### Qué es una OrgsX Una **OrgsX** (Organización Hiperinteligente) es una organización donde la inteligencia artificial no es una herramienta de asistencia individual sino una **capa operativa colectiva**. En una OrgsX: - El conocimiento organizacional se acumula de forma estructurada, no se pierde cuando alguien sale - Las dependencias entre personas y proyectos son explícitas y visibles, no implícitas y ocultas - Los Sherpas operan en paralelo para cada persona, sin que el humano tenga que estar presente en cada tarea - La documentación es un producto de operar, no una tarea adicional - El trabajo de bajo valor cognitivo (buscar, reportar, coordinar, documentar) lo hace el sistema; el humano trabaja en lo que solo los humanos pueden hacer: pensar, decidir, crear ### La distinción fundamental > *Una herramienta responde cuando se le pregunta. Una entidad opera aunque no se le pregunte.* ChatGPT, Copilot, Gemini son herramientas. Útiles, poderosas, pero cada vez que se abren empiezan de cero. No recuerdan. No conocen el contexto. No coordinan. Un Sherpa en una OrgsX es una entidad: tiene nombre, tiene memoria, tiene gobernanza embebida, tiene identidad. Opera en el contexto específico de su organización, con las reglas de su dueño, con el conocimiento acumulado de todos los proyectos anteriores. --- ## M02 · Los 3 pilares de WORX Los 3 pilares son necesarios y suficientes. Sin los tres, el sistema no funciona. Con los tres, la OrgsX opera. ### Pilar 1 — Método: las reglas del juego El Método define **cómo va a operar el trabajo**. Sin Método, el sistema puede ser potente pero caótico — como tener carros de carreras sin reglas de tránsito. **Componentes del Método:** **1. Gobernanza por rol** Cada persona tiene reglas embebidas en la memoria de su Sherpa: qué puede ver, qué puede decidir, en qué ámbito opera. No es un filtro externo aplicado después — es conocimiento operativo del sistema desde el inicio. - La gobernanza se captura en la Sesión de Definición (Día 1): 30 min/persona - Se articula en conversación, no en formulario — la gente no siempre sabe sus límites hasta que se los pregunta - Una vez cargada, el Sherpa la aplica sin intervención humana **2. XDoc como unidad canónica de trabajo** Todo trabajo en el sistema vive en un XDoc: proyectos, decisiones, iniciativas, cuentas de cliente. Sin excepción. *Estructura del XDoc — 7 secciones:* - **Cabecera:** Owner (registro formal) · Sponsor (respaldo) · Runner (quien tiene el balón ahora) - **Contexto:** para qué existe y qué resultado concreto se espera - **Estado:** salud 🟢/🟡/🔴 · hito activo · última decisión - **Dependencias:** con tipo explícito — INPUT / APROBACIÓN / DECISIÓN / DOC - **Protocolo:** SOP de referencia + diferencias entre lo que debe pasar y lo que pasa - **NEXTs:** máximo 7 acciones · con responsable y fecha · no tareas abiertas - **Changelog:** bitácora de cambios — la memoria del proyecto, no del individuo *La distinción más importante del XDoc:* **Owner ≠ Runner.** El Owner tiene el registro formal de propiedad. El Runner tiene el balón ahora mismo — quien tiene que moverlo en este momento. Esta distinción elimina la ambigüedad de responsabilidad que paraliza la mayoría de los proyectos. **3. Naming convention canónica** Todo activo en el sistema tiene un nombre estructurado: `PREFIJO-IB-NOMBRE-vNN`. Sin nombre canónico, el sistema no puede encontrar ni relacionar el activo. *Prefijos estándar:* - `TP-` Transfer Pack canónico/frozen · `WOI-` Work In Progress · `MPB-` MasterPlaybook - `OUT-` Entregable externo · `SIM-` Simulación/demo · `PLAN-` Plan interno - `XD-` XDoc · `BC-` Brain Code · `IB-` IntelliBank · `CP-` Control Plane - `GOB-` Documento de gobernanza · `NAMING-` Naming convention --- ### Pilar 2 — Infraestructura: donde vive la memoria La infraestructura es el **hardware del sistema nervioso**. Sin ella, la inteligencia no tiene dónde vivir. **Stack estándar WORX:** - **GenniuxBase (Brain OS MCP):** Node.js 20 + PostgreSQL 16 + pgvector · EC2 t3.small · Schema multitenancy por cliente · **corre en infraestructura del cliente** — la memoria es del cliente, no de EmpowerLabs - **IntelliBanks app:** Apache + PHP 8.x · EC2 t3.micro · Electron + Angular 15 · sync cada 15 min · macOS + Windows - **API LLM:** Anthropic Claude con whitelist de IPs · el cómputo es externo · la memoria es local - **Conectores (MCP):** cualquier herramienta con MCP disponible — SharePoint, Jira, Slack, Gmail, ServiceNow, etc. *Principio de soberanía del dato:* la memoria (documentos, activos, IntelliBank) queda en la infraestructura del cliente. El cómputo (la inteligencia que procesa) usa API externa con whitelist. El cliente controla su conocimiento. --- ### Pilar 3 — Interfaz: quién activa la inteligencia La interfaz es el **Sherpa de cada persona**. Sin interfaz, la infraestructura existe pero nadie la activa. **Componentes de la Interfaz:** - **Sherpa personal:** nombre propio elegido por la persona · Brain Code progresivo · memoria individual técnica (proyectos, decisiones) y conductual (estilo de trabajo, prioridades) · gobernanza por rol - **Corp Sherpa:** interfaz del conocimiento organizacional compartido — responde preguntas que cruzan personas y áreas - **Torre de Control:** vista agregada del estado de todos los proyectos — visible sin junta · componible según las necesidades de cada organización --- ## M03 · Disciplinas fundamentales de trabajo Las disciplinas son hábitos operativos que deben volverse automáticos. Sin disciplina, el sistema se degrada. ### D01 — Naming antes de guardar Antes de guardar cualquier archivo en el vault: asignar nombre canónico con prefijo, IntelliBank y versión. No hay activos sin nombre. No hay activos sin prefijo. Un activo sin nombre canónico no existe para el sistema. **Regla:** si no sabes qué prefijo usar, pregunta al Sherpa antes de guardar. ### D02 — El XDoc como primer paso Antes de empezar a trabajar en cualquier proyecto, iniciativa o decisión: abrir un XDoc. No al final — antes. El XDoc no es documentación del trabajo terminado; es el espacio donde el trabajo sucede. **Regla:** si hay un Runner asignado y un deadline, hay un XDoc. Sin XDoc, no hay proyecto visible para el sistema. ### D03 — Dependencias explícitas Cuando un trabajo necesita algo de otra persona, la dependencia se declara en el XDoc con tipo explícito (INPUT / APROBACIÓN / DECISIÓN / DOC) y responsable. No se supone. No se infiere. Se declara. **Regla:** una dependencia no declarada es un bloqueo invisible. Los bloqueos invisibles son el costo más silencioso de cualquier organización. ### D04 — Changelog como hábito de cierre Al terminar cada sesión de trabajo sobre un proyecto, actualizar el Changelog del XDoc: qué cambió, qué se decidió, qué quedó pendiente. El Changelog es la memoria del proyecto — no la memoria de la persona. **Regla:** si el Sherpa no sabe qué pasó en la última sesión de trabajo, el Changelog no fue actualizado. ### D05 — Registry siempre actualizado Cada activo nuevo que entra al vault se registra en el Registry del IntelliBank. El Registry es el CMDB del conocimiento — si un activo no está en el Registry, no existe para el sistema. **Regla:** crear activo → registrar en Registry. Son dos pasos inseparables. ### D06 — Auto-documentación progresiva El trabajo no se documenta al final — se documenta mientras ocurre. La documentación es el producto de operar, no una tarea adicional. El Sherpa genera documentación como consecuencia de trabajar, no como esfuerzo extra del humano. **Regla práctica:** si hay que hacer un esfuerzo especial para documentar algo, es señal de que el proceso de trabajo no está bien configurado todavía. --- ## M04 · Coherencia Vault-Room: la regla de espejo Este módulo documenta uno de los aprendizajes más importantes del caso Posta (2026-06-03) y es ahora una regla fundacional del modelo WORX. ### El problema que resuelve Sin esta regla, los activos de un proyecto terminan dispersos: algunos en el vault, algunos en conversaciones de Sherpa que se compactan, algunos en carpetas ad-hoc, algunos en proyectos equivocados. Cuando el Lab arranca y hay múltiples rooms operando en paralelo, la dispersión genera caos — el Sherpa de un room no sabe dónde está el activo que generó el Sherpa de otro room. ### La regla **Cada room en Cowork tiene su carpeta espejo en el vault. Todo activo generado en un room va en su carpeta correspondiente. Sin excepción.** ``` Cowork Project: POSTA ├── Room: POSTA-Cuenta → IB-PO-Posta/POSTA-Cuenta/ ├── Room: POSTA-Caso → IB-PO-Posta/POSTA-Caso/ ├── Room: POSTA-Lab-Metodo → IB-PO-Posta/POSTA-Lab-Metodo/ ├── Room: POSTA-Lab-Infra → IB-PO-Posta/POSTA-Lab-Infra/ └── Room: POSTA-Lab-Interfaz → IB-PO-Posta/POSTA-Lab-Interfaz/ TP Raíz: IB-PO-Posta/TP-PO-POSTA-Raiz-v01.md (raíz del IB, no en subcarpeta) ``` ### El IntelliBank del cliente Cada cliente tiene su propio IntelliBank dentro de `IB-Clientes/`: - Formato: `IB-[XX]-[Codename]/` - El XX es el código del cliente (2 letras del codename) - Ejemplo: `IB-PO-Posta/` para el cliente con codename "Posta" ### El TP Raíz El TP Raíz vive en la raíz del IntelliBank del cliente — no dentro de ninguna subcarpeta. Es el contexto base que alimenta todos los rooms. Formato: `TP-[XX]-[CODENAME]-Raiz-v01.md`. ### Por qué importa El Cowork project es la interfaz de trabajo. El IntelliBank es la memoria. Son dos sistemas distintos que deben estar perfectamente alineados. Si están desalineados, los activos se generan en la interfaz pero no persisten en la memoria — o persisten en la memoria en el lugar equivocado. Esta regla garantiza que cualquier Sherpa, en cualquier room, sabe exactamente dónde buscar y dónde guardar. --- ## M09 · Anti-patterns: lo que NO hacer Los anti-patterns son los errores más comunes que degradan el sistema. Documentarlos explícitamente es más valioso que las reglas positivas — es más fácil evitar lo concreto que seguir lo abstracto. ### AP01 — Activos sin nombre canónico **El error:** crear un archivo con nombre descriptivo libre ("análisis de requisitos Posta.docx") sin prefijo BMF. **Por qué ocurre:** la urgencia de guardar algo rápido. **Consecuencia:** el sistema no puede clasificar, relacionar ni encontrar el activo. **Regla:** si no hay tiempo para el nombre canónico, hay tiempo para preguntarle al Sherpa cuál es el nombre correcto. Eso toma 10 segundos. ### AP02 — XDoc creado al final del proyecto **El error:** terminar un proyecto y entonces documentarlo en un XDoc. **Por qué ocurre:** el XDoc se percibe como documentación, no como herramienta de trabajo. **Consecuencia:** el Changelog está vacío, las dependencias no se rastrearon, el Runner cambió sin que nadie lo registrara. **Regla:** el XDoc es el primer paso, no el último. Si no existe antes de que arranque el trabajo, no existe. ### AP03 — Dependencias implícitas **El error:** asumir que "todos saben" quién depende de quién. **Por qué ocurre:** en equipos pequeños, las dependencias parecen obvias hasta que alguien bloquea a dos personas en paralelo sin saberlo. **Consecuencia:** bloqueos invisibles que solo se detectan en una reunión de status — que es exactamente lo que el sistema pretende eliminar. **Regla:** si necesitas algo de alguien para avanzar, está en las Dependencias del XDoc con tipo, responsable y fecha esperada. ### AP04 — Usar el Sherpa como buscador genérico sin contexto **El error:** preguntarle al Sherpa cosas que no están en su vault o en su contexto. **Por qué ocurre:** el Sherpa parece omnisciente — si responde bien a preguntas generales, la tentación es usarlo para todo. **Consecuencia:** el Sherpa responde desde entrenamiento genérico, no desde el conocimiento de la organización. Las respuestas son plausibles pero no son confiables. **Regla:** antes de hacer una pregunta crítica al Sherpa, verificar que la información relevante está en el vault. Si no está en el vault, no está en el Sherpa. ### AP05 — No actualizar el Changelog **El error:** trabajar en un proyecto durante 2 semanas sin actualizar el Changelog del XDoc. **Por qué ocurre:** el Changelog parece opcional cuando todo está en la cabeza del humano. **Consecuencia:** en la siguiente sesión, ni el humano ni el Sherpa saben en qué estado quedó el proyecto. Se reconstruye contexto — que es exactamente el costo que el sistema pretende eliminar. **Regla:** al terminar cada bloque de trabajo sobre un proyecto, el Sherpa actualiza el Changelog. Si el Sherpa no lo hace automáticamente, es una señal de que no tiene suficiente contexto — hay que alimentarlo. ### AP06 — Archivos Posta en carpetas de WORX (y viceversa) **El error:** guardar activos de un cliente en el banco de la metodología (o viceversa). **Por qué ocurre:** el primer proyecto cliente se trabaja antes de tener la estructura del IB del cliente. **Consecuencia:** activos dispersos · referencias rotas · Sherpas de rooms distintos que no se encuentran entre sí. **Regla:** antes de generar el primer activo de un cliente nuevo, crear el IB del cliente y su estructura de rooms. El TP Raíz primero, los activos después. *Aprendizaje validado en Posta, 2026-06-03.* ### AP07 — Rooms sin TP Raíz **El error:** arrancar rooms de un proyecto sin haber creado el TP Raíz. **Por qué ocurre:** la urgencia de empezar a trabajar. **Consecuencia:** el Sherpa de cada room empieza sin contexto común. Se reconstruye el mismo contexto múltiples veces, de formas distintas. Las versiones del contexto divergen. **Regla:** primero el TP Raíz, luego los rooms. El TP es el contrato de contexto compartido. --- ## M10 · Aprendizajes del campo *Columna viva. Cada aprendizaje tiene: fecha · caso · descripción · módulo relacionado.* --- ### [2026-06-03] · Caso Posta · La coherencia vault-room como disciplina fundacional **Aprendizaje:** Antes de crear el IB-PO-Posta, los activos del proyecto Posta vivían en `PB-WORX-Worx/` mezclados con los materiales de demo de WORX. Al planear los rooms del proyecto, quedó claro que sin un IB dedicado y sin la regla de carpeta-espejo, el arranque de los rooms iba a generar caos. **Lección:** La estructura Vault-Room debe crearse antes del primer activo del proyecto, no después. El TP Raíz va primero — siempre. **Módulo:** M04 --- ### [2026-06-03] · Caso Posta · El room POSTA-Caso como diario de campo **Aprendizaje:** En la discusión de la estructura de rooms, se identificó que sin un room dedicado a la documentación del caso, los learnings del engagement quedarían dispersos entre los rooms operativos o perdidos en conversaciones que se compactan. **Lección:** Todo proyecto Lab debe tener un room de Caso desde el inicio. No es el room más visible, pero es el que más valor genera a largo plazo — es la fuente del Playbook de Replicación. **Módulo:** M04, M10 --- ### [2026-05-28] · Caso Posta · El ConceptoLab generado en vivo es el cierre más poderoso **Aprendizaje:** En la sesión fundacional de Posta, el momento de mayor impacto no fue el Brain Code ni la calculadora ROI — fue ver el ConceptoLab del Lab de Posta generarse en vivo con sus propios nombres, sus propios casos y su propio plan de arranque, mientras el equipo miraba. **Lección:** El cierre de cualquier sesión fundacional debe incluir un ConceptoLab generado en vivo con los datos reales del cliente. No hay propuesta que compita con verse dentro del documento mientras aparece. **Módulo:** M08 (cuando se escriba) --- ### [2026-05-28] · Caso Posta · La compactación como momento de enseñanza **Aprendizaje:** Durante la sesión, el sistema compactó el contexto en vivo. En lugar de ocultarlo o disculparse, Victor lo explicó con la analogía de la foto reducida. El equipo entendió visceralmente por qué el vault, la minuta y los XDocs existen — no como burocracia sino como el mecanismo que preserva el contexto real. **Lección:** Los momentos de fricción técnica son oportunidades de enseñanza cuando se manejan con transparencia. La limitación del sistema, explicada bien, se convierte en argumento de valor del sistema. **Módulo:** M05 (cuando se escriba) --- ### [2026-05-28] · Caso Posta · El bottleneck cruzado como narrativa de demo **Aprendizaje:** En el demo de XDocs, la narrativa de Alex bloqueando a Jesús y a Gus en paralelo — sin que nadie lo supiera hasta que el Sherpa lo detectó al cruzar los XDocs — fue el momento más concreto de valor del sistema. La Torre de Control lo mostró en 30 segundos. **Lección:** El demo de XDocs siempre debe incluir un bottleneck cruzado — un bloqueo que afecta a dos personas simultáneamente, invisible sin el sistema. Es el caso que mejor ilustra el costo del caos cognitivo y el valor de las dependencias explícitas. **Módulo:** M03 (D03 — Dependencias explícitas) --- *WOI mantenido por Jay · EmpowerLabs Brain OS* *Actualizar al validar aprendizajes nuevos · Meta: MPB- con M01-M09 completos + ≥2 casos* --- ## Changelog | Fecha | Versión | Cambio | |---|---|---| | 2026-06-03 | v01 | Documento creado. M01-M04, M09, M10 con borrador inicial. Aprendizajes de Posta sembrados. |