--- asset_id: CAS-EL-WORX-LabPraxis-BancoCasos-v01 version: v1.8 tipo: CAS — Banco de Casos Documentados room: LabPraxis owner: EmpowerLabs sherpa: Jacob fecha_creacion: 2026-04-15 ultima_actualizacion: 2026-05-18 total_casos: 18 --- # LabPraxis — Banco de Casos ### Experiencias documentadas que construyen la metodología operativa de EmpowerLabs > Este documento es el registro vivo de todos los casos del LabPraxis. Cada caso es un ladrillo de la gobernanza futura. Se actualiza en cada sesión del room. --- ## Índice de casos | ID | Título | Tipo | Principio | Status | | ---------------- | ---------------------------------------------------------------------------------------------------------------- | ---------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------- | | [001](#caso-001) | SherpaX onboarding sin Transfer Pack | Falla | P001 | 🔴 Abierto | | [002](#caso-002) | Producción sin consultar el vault | Falla | P002 | 🔴 Abierto | | [003](#caso-003) | Skills sin distribución al equipo | Brecha | P003 | 🔴 Abierto | | [004](#caso-004) | LabPraxis como fundamento de gobernanza BMF | Observación | P004 | ✅ Registrado | | [005](#caso-005) | Protocolo Thread + NEXT[@Persona] | Innovación | P005 | 🟡 En piloto | | [006](#caso-006) | Triple falla: Projects/ + PL- + duplicados | Falla compuesta | P002+P003 | 🟡 Parcialmente resuelto | | [007](#caso-007) | Arquitectura de acceso al vault para el equipo | Brecha de diseño | P001+P003 | 🟡 Arquitectura decidida | | [008](#caso-008) | Agente sin consultar el vault antes de proponer | Falla | P002 (capa agente) + PUB-04 | ✅ Antídoto codificado (G0+I0+PUB-04 en MF-BMF-Publishing-v02) | | [009](#caso-009) | Template de cierre de Decisión Bloqueada (propuesta + opciones + ratificación → D-P + TP + ProdSpec + CAS) | Innovación | P006 (a canonizar) — Decisiones canonizables | 🟡 En piloto · 2da aplicación D-P-42 | | [010](#caso-010) | Bundle como aceleración de lanzamiento de producto premium (MONEX Intro α) | Innovación | P007 (a canonizar) — Innovation + Adjacent Bundle | 🟡 En piloto · pendiente cohort 1 | | [011](#caso-011) | Reorganización por pilares como espejo organizacional de D-P-01 | Innovación | P008 (a canonizar) — Espejo organizacional cognición/operación | 🟡 En piloto · pendiente conversaciones individuales | | [012](#caso-012) | Gobernanza mínima viable como punto de arranque (no overengineering) | Innovación | P009 (a canonizar) — MVP de gobernanza | 🟡 En piloto · primera L2 viernes 10-may | | [013](#caso-013) | SherpaX documenta · humano dirige (delegación de captura) | Innovación · principio | **P010** ✓ canonizado — Documentación Delegada al SherpaX | ✅ Canonizado · SOP-EL-WORX-DocBySherpa-v01 | | [014](#caso-014) | Room Raíz / Home Room como entidad arquitectónica | Innovación · principio | **P011** ✓ canonizado — Room Raíz / Home Room | ✅ Canonizado · MAP-EL-RoomRaiz-Linaje-v01 | | [015](#caso-015) | Carga del Starter Pack (XP+SP) al inicio de cualquier conversación | Innovación · principio | **P012** ✓ canonizado — Starter Pack Loading | ✅ Canonizado · SOP-EL-WORX-RoomActivation-v01 | | [016](#caso-016) | Validación externa de la categoría · Diana Hu (Y Combinator) nombra el problema que llevamos 20 años resolviendo | Validación externa | (sin principio · evidencia comercial) | ✅ Documentado · ammunition para línea B2B HIORG | | [017](#caso-017) | Drift entre TP-LabPraxis y banco · Brain OS-First aplicado al TP sin verificar banco paralelo (meta-recursivo) | Falla compuesta | **P013** (a canonizar) — Lectura cruzada TP↔banco antes de agregar caso | 🟡 En piloto · antídoto en diseño | | [018](#caso-018) | Frontmatter heredado de template sin validación · 3 docs producidos 18-may registran fecha_creacion 7-may | Falla compuesta | **P014** (a canonizar) — Frontmatter Integrity (fecha y campos canónicos = realidad del archivo) | 🔴 Abierto · antídoto pendiente + 3 correcciones inmediatas | --- ## CASO 001 ### SherpaX Onboarding sin Transfer Pack **Fecha:** 2026-04-15 · **Tipo:** Falla · **Principio:** P001 — Contexto Transferible **¿Qué pasó?** Alex configuró el SherpaX de Alain. Al reportarle a Victor, indicó que bastaría una reunión con Alain para enseñarle cómo arranca su SherpaX. **La falla:** En la metodología EmpowerLabs, todo proceso debe arrancar con dos artefactos: 1. **Transfer Pack** — estado acumulado, contexto cargado, decisiones tomadas 2. **Starter Prompt** — bloque para activar el proceso con el contexto adecuado Una reunión transfiere conocimiento tácito. El Transfer Pack transfiere contexto estructurado que sobrevive a la conversación. Sin él, Alain depende de Alex para recordarle cómo arrancar su propio agente. **Riesgos:** - Alain queda dependiente de Alex o Victor - El conocimiento vive en cabezas, no en el sistema **Acción correctiva:** - Crear `TP-EL-SX-Alain-v01.md` con el estado de su SherpaX - Crear o confirmar `SP-EL-SX-Alain-v01.md` personalizado **Status:** 🔴 Abierto — pendiente que Alex genere el TP de Alain → NEXT[@Alex]: Crear TP-EL-SX-Alain-v01.md y SP-EL-SX-Alain-v01.md antes de cerrar el onboarding --- ## CASO 002 ### Producción de proyecto sin consultar el vault primero **Fecha:** 2026-04-15 · **Tipo:** Falla · **Principio:** P002 — Vault-First **¿Qué pasó?** Anahí arrancó proactivamente la producción del libro "El Poder de MasterPlaybooks" — proyecto dentro del plan. El problema: el proyecto ya tenía definiciones en el vault y Anahí las desconocía. Arrancó desde cero sin saber que no era desde cero. **La falla:** Antes de entrar a producción en cualquier proyecto previsto, el colaborador debe consultar el vault para identificar qué ya está definido, qué decisiones no deben reabrirse, y desde dónde realmente construir. **Riesgos:** - Trabajo duplicado o incompatible con lo existente - Necesidad de coordinación manual — exactamente lo que la documentación debería eliminar **Lo que revela:** Este caso es la base de la metodología WORX. El vault ES el mecanismo de coordinación. Consultarlo antes de producir no es opcional. **Acción correctiva:** - Anahí leer el Transfer Pack del proyecto MasterPlaybooks antes de continuar - Identificar qué está decidido sobre el libro y construir desde ahí **Status:** 🔴 Abierto — pendiente que Anahí consulte el vault → NEXT[@Anahí]: Leer TP del proyecto MasterPlaybooks antes de continuar producción del libro --- ## CASO 003 ### Skills sin mecanismo de distribución para el equipo **Fecha:** 2026-04-15 · **Tipo:** Brecha · **Principio:** P003 — Herramientas Accesibles **¿Qué pasó?** El ecosistema tiene Skills creados (`room-creator.skill`, `bmf-file-renamer.skill`, etc.) pero no existe un mecanismo unificado para que todos los colaboradores los descubran, accedan e instalen cuando los necesitan. Cada Skill existe como archivo en el vault pero sin protocolo de distribución. **Síntoma concreto:** Si Anahí quisiera crear un Room hoy, probablemente no sabría que `room-creator.skill` existe — y generaría archivos ad-hoc, con naming incorrecto, en ubicación equivocada. **La brecha tiene dos capas:** 1. **Distribución** — ¿cómo llega el Skill al colaborador que lo necesita? 2. **Instalación** — ¿cómo instala el colaborador un Skill en Cowork de forma autónoma? **Preguntas abiertas:** - ¿Dónde vive el catálogo de Skills del ecosistema EL? - ¿Debería existir un "EL Skills Pack" distribuido en el onboarding de SherpaX? - ¿Cómo se actualiza un Skill cuando evoluciona? **Acción correctiva:** 1. Documentar catálogo de Skills disponibles (qué existe, para qué sirve, dónde está) 2. Definir protocolo de instalación de Skills en Cowork 3. Evaluar "EL Skills Pack" como parte del onboarding **Status:** 🔴 Abierto — requiere definir protocolo de distribución → NEXT[@Victor]: Definir si el EL Skills Pack se distribuye via plugin o via BOS-EL-Corp-BrainOS --- ## CASO 004 ### El LabPraxis como fundamento de la gobernanza BMF humanos + agentes **Fecha:** 2026-04-15 · **Tipo:** Observación fundacional · **Principio:** P004 — Gobernanza Emergente **¿Qué observó Victor?** Hay un lado práctico sin contenedor explícito: el proceso de documentar casos operativos, acumular experiencias, y a partir de esa evidencia construir lineamientos que se convierten en gobernanza formal. **El ciclo virtuoso que el LabPraxis activa:** ``` Caso específico (falla u oportunidad) ↓ Documentación estructurada (LabPraxis) ↓ Patrón identificado → Principio operativo ↓ Lineamiento formal (SOP / PLB / MetaPlaybook) ↓ Gobernanza BMF (reglas para humanos y agentes) ``` **Por qué importa:** En el modelo Big Meta Factory, humanos y agentes van a trabajar colaborativamente. Necesitan reglas compartidas — y esas reglas no se inventan desde la teoría. Se construyen desde evidencia. El LabPraxis es donde esa evidencia vive y donde la gobernanza se gesta. **Implicación práctica:** Cuando varios casos convergen en un patrón, Jacob debe proponer elevarlo a SOP, PLB o principio de gobernanza BMF sin esperar que Victor lo pida. **Status:** ✅ Registrado como principio fundacional — no requiere acción inmediata --- ## CASO 005 ### Protocolo Thread + NEXT[@Persona]: el vault como sistema nervioso operativo **Fecha:** 2026-04-15 · **Tipo:** Innovación · **Principio:** P005 — Vault Vivo **¿Cuál es la oportunidad?** Los documentos del vault son actualmente contenedores estáticos. Podrían ser canales vivos de comunicación y coordinación. La propuesta: agregar a los documentos activos dos zonas estructuradas: **Changelog** (al inicio): ```markdown ## 📋 CHANGELOG | Fecha | Cambio | Por | |-------|--------|-----| | 2026-04-15 | Nota sobre URL signup | @Victor | ``` **Thread** (al final): ```markdown ## 💬 THREAD **@Victor — 2026-04-15:** Anahí, URL de signup es bloqueante para KatIA. → NEXT[@Anahí]: Confirmar URL de signup con equipo técnico ``` **El poder del `→ NEXT[@Persona]:`:** Es machine-readable. Jacob hace un grep del vault completo y entrega en segundos la lista de pendientes de cualquier colaborador. El vault reemplaza al task manager externo — el contexto y la acción viven juntos. **Skill generado:** `next-scanner.skill` — escanea el vault y entrega tablero de pendientes por colaborador o por proyecto. **Pendientes de definición:** - Tag canónico definitivo confirmado: `→ NEXT[@Persona]:` - Marcar como completado: `→ ~~NEXT[@Persona]~~: ✅ DONE — fecha` - Protocolo de archivado de threads (cuándo limpiar) **Status:** 🟡 En piloto — primer uso real en `PLAN-MPX-KatIA-SherpaAnfitrion-v01.md` el 2026-04-15 --- ## CASO 006 ### Triple falla: carpeta ad-hoc + prefijo incorrecto + archivos duplicados **Fecha:** 2026-04-15 · **Tipo:** Falla compuesta · **Principios:** P002 + P003 acumulados **¿Qué se encontró?** Al buscar la nota de Victor en un archivo de KatIA, se descubrió que: 1. **Existe `Projects/` ad-hoc** en la raíz del Reinventaverse — no es un IB-*. Contiene sub-carpetas por proyecto (MasterPlaybooks, Rebelocity, etc.) creadas por colaboradores sin guía estructural. 2. **Archivos en ubicación incorrecta:** Los docs de KatIA/MasterPlaybooks estaban en `Projects/MasterPlaybooks/` en vez de `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/`. 3. **Prefijo `PL-` incorrecto:** `PL-MPX-KatIA-SherpaAnfitrion-PlanMaestro-v01.md` — `PL-` no es TIPO canónico. El correcto para Plan Maestro es `PLAN-`. 4. **Duplicados:** Los mismos archivos aparecen en `Projects/` y `CloudVault/Projects/`. **Causa raíz:** Colaboradores sin SherpaX configurado (sin room, sin Skills, sin TP) generan archivos en modo libre. Es la consecuencia acumulada de los Casos 001 y 003. **Acciones ejecutadas en sesión:** - ✅ 5 archivos movidos de `Projects/MasterPlaybooks/` → `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` - ✅ `PL-MPX-KatIA-SherpaAnfitrion-PlanMaestro-v01.md` → `PLAN-MPX-KatIA-SherpaAnfitrion-v01.md` **Pendientes:** - Auditar y reubicar archivos de `Projects/Rebelocity/` (5 archivos sin prefijo BMF) - Instalar `room-creator.skill` en sesiones de Anahí y Alex **Status:** 🟡 Parcialmente resuelto — MasterPlaybooks corregido, Rebelocity pendiente → NEXT[@Alex]: Instalar room-creator.skill en Cowork de Anahí y en el tuyo antes de próxima sesión de producción → NEXT[@Victor]: Decidir qué hacer con los archivos de Projects/Rebelocity/ (¿reubicar a IB-REB-Rebelocity/?) --- --- ## CASO 007 ### Arquitectura de acceso al vault para el equipo: ¿Obsidian o Cowork? **Fecha:** 2026-04-16 · **Tipo:** Brecha de diseño · **Principios:** P001 + P003 · **Dimensión WORX:** Co-creación inter-equipos / Gobernanza humano-agente **¿Cuál es la pregunta que detonó el caso?** Victor pregunta: si el vault está en Obsidian Sync y tiene otros dispositivos conectados, ¿qué pasa con la recursión CloudVault? Y luego: ¿cómo debería Anahí o Ángeles tener acceso al vault — compartiendo su cuenta de Obsidian? **¿Cuál es la brecha de diseño identificada?** No existe un modelo explícito que defina cómo accede el equipo al vault del Reinventaverse. Actualmente hay dos capas mezcladas sin protocolo claro: 1. **Capa personal (Victor):** El Reinventaverse es el vault personal de Victor en Obsidian Sync. Contiene notas personales, rituales, reflexiones — contenido que no debería ser accesible para el equipo. 2. **Capa de proyecto (equipo):** Dentro del mismo vault viven los IB-* con archivos de proyecto compartidos (MasterPlaybooks, EmpowerLabs, etc.) que el equipo sí necesita consultar y editar. Actualmente el equipo accede a esos archivos a través de Cowork (su SherpaX), que los lee desde el vault montado. Pero no tienen un protocolo explícito de: qué pueden leer, qué pueden escribir, qué no deben tocar. **¿Por qué no es la solución compartir la cuenta de Obsidian?** Compartir la cuenta de Obsidian Sync daría acceso de lectura/escritura a *todo* el vault — incluyendo notas personales de Victor. Además viola el principio de autonomía de cada colaborador: cada persona debería operar su propio entorno, no un entorno compartido sin límites claros. **¿Qué está faltando?** Tres cosas que hoy no existen: | Elemento faltante | Consecuencia actual | |-------------------|---------------------| | Protocolo de acceso por rol | El equipo no sabe qué archivos puede tocar y cuáles no | | Separación vault personal / vault de proyecto | Todo vive mezclado en el mismo Obsidian | | Mecanismo de escritura para colaboradores | El equipo puede leer a través de Cowork, pero ¿cómo escribe al vault sin romper el naming BMF? (Caso 006) | **Opciones de arquitectura a evaluar:** *Opción A — Carpeta compartida dedicada dentro del vault* Crear una subcarpeta `SHARED/` en Reinventaverse que sea la zona de acceso del equipo. Solo esa carpeta se sincroniza o se expone vía iCloud compartido / repositorio Git. Victor mantiene el resto del vault privado. *Opción B — Vault separado para proyectos de equipo* Crear un vault distinto (`EmpowerLabs-Vault` o similar) exclusivamente para los IB-* de proyecto. El equipo accede a ese vault; Victor lo mantiene sincronizado con su vault personal selectivamente. *Opción C — Cowork como la capa de acceso (modelo actual, formalizado)* El equipo no accede directamente al vault — accede a través de su SherpaX en Cowork. El SherpaX lee y escribe en los IB-* de proyecto con el skill correcto (bmf-artifact-validator). El vault de Obsidian sigue siendo exclusivo de Victor. Esta opción requiere que los Skills de escritura estén bien distribuidos (Caso 003). **¿Qué opción tiene más coherencia con el modelo BMF?** La Opción C es la más coherente con el modelo de Organización Hiperinteligente: el acceso al conocimiento se da a través del agente (SherpaX), no directamente al sistema de archivos. Esto garantiza que el naming BMF se respete (el agente usa el skill de validación), que el contexto esté disponible (el agente carga el TP del proyecto), y que la autonomía de cada colaborador esté en su propio entorno. La Opción A o B pueden ser complementarias si se necesita que el equipo acceda a los archivos fuera de Cowork (por ejemplo, para editar en Obsidian directamente en el futuro). **Conexión con casos anteriores:** - **Caso 001:** El problema de acceso del equipo al vault es exactamente el mismo que el de Alain con su SherpaX — sin TP ni SP, no hay acceso estructurado - **Caso 003:** El equipo no puede escribir correctamente al vault sin los Skills de validación disponibles - **Caso 006:** La evidencia de que sin protocolo de acceso el equipo genera archivos en modo libre **Preguntas abiertas:** - ¿Cuál es la opción de arquitectura que Victor quiere formalizar como estándar? - ¿Qué archivos del vault deberían ser accesibles al equipo y cuáles son privados? - ¿Debería existir un vault separado `EmpowerLabs-Collab` para los proyectos compartidos? - ¿Cómo se actualiza el onboarding de SherpaX para que incluya el protocolo de acceso? **Decisión tomada — 2026-04-16:** **Arquitectura oficial: Opción C + IntelliBanks app** El equipo accede al vault exclusivamente a través de su SherpaX en Cowork — nunca directamente a Obsidian. El vault personal de Victor (rituales, notas, reflexiones) permanece privado en Obsidian Sync. La capa compartida del equipo — los IntelliBanks (IB-*) — se sincroniza a través de **IntelliBanks app**: un repositorio Git que actúa como contenedor oficial de todos los IntelliBanks del ecosistema. Todos los colaboradores con SherpaX configurado estarán sincronizados a través de ese repositorio. ``` Arquitectura de acceso al vault — EmpowerLabs Victor (personal) └── Obsidian Sync → Reinventaverse completo (vault privado) Equipo (colaboradores) └── IntelliBanks app → IntelliBanks (IB-*) únicamente └── SherpaX en Cowork → lee y escribe con Skills BMF Intersección └── Victor hace push/pull entre Obsidian y IntelliBanks app para mantener los IB-* sincronizados en ambos lados ``` **Implicaciones para el onboarding de SherpaX:** - Cada colaborador necesita acceso al repositorio IntelliBanks app (no a Obsidian) - El SherpaX de cada quien apunta al IB-* correspondiente a su proyecto - Todas las escrituras al vault pasan por bmf-artifact-validator.skill (Caso 003) - No se crean carpetas ni archivos fuera de los IB-* (Caso 006) **Preguntas que aún quedan abiertas:** - ¿Cómo se configura el acceso de cada colaborador al repositorio IntelliBanks app? - ¿Cuál es el protocolo de push/pull para Victor entre Obsidian y Genniux? - ¿Los SherpaX montan el repo directamente o acceden a una copia local sincronizada? **Status:** 🟡 Arquitectura decidida — pendiente protocolo de configuración técnica → NEXT[@Victor]: Documentar cómo se configura el acceso de Anahí y Ángeles al repositorio IntelliBanks app → NEXT[@Victor]: Definir protocolo de sincronización Victor ↔ Genniux (cuándo hace push, qué ramas, qué queda fuera del repo) --- ## CASO 008 ### Agente sin consultar el vault antes de proponer **Fecha:** 2026-04-26 · **Tipo:** Falla · **Principio:** P002 — Vault-First (extensión a capa agente) · **Sistema WORX:** Tooling/Knowledge + Signal/Truth · **Superficie:** LAB **¿Qué pasó?** En la sesión HIORG Demand Gen Room del Día 100X, Jacob (el Sherpa de Victor) propuso a Victor una "innovación" de capa MePB para regir la creación de contenidos editoriales, y le solicitó "briefs de 10 líneas" sobre dos modelos que decía no tener documentados: Publishing Factory y pipeline idea→conceptualización→productización. Victor activó un experimento explícito: "Como experimento y ejercicio puedes buscar en el wiki si esta información la tienes ahí?". En menos de 2 minutos de búsqueda en el vault, Jacob encontró que los tres elementos ya estaban canonizados: - Publishing Factory: `TP-EL-BMF-PublishingFactory-v01.md` + Wiki page `FactoriaEditorial.md` (FI-ED-EL con 10 líneas de producción, Anahí operadora, pipelines FAST-4/PLB-7/MPB-10/BOOK-12/NEWS-1) - Pipeline idea→conceptualización→productización: `MF-BMF-Publishing-v01.md` codificado como 3 fases (MF-IDEATION → MF-EDITORIAL → MF-DEMANDGEN) con Gates G1, G2 y estaciones I1/I2/I3 - MePB: `MePB-XX-XPack-Schema-v01.md` ya canonizado con 7 secciones fijas, más 3 aplicaciones existentes (PlaneacionEventos, PoderYProductividad, MeAg) **La falla:** Es el Caso 002 (Vault-First) replicado en la capa de agente. Caso 002 capturó que un humano (Anahí) no consultó el vault antes de producir; Caso 008 captura que un agente (Jacob) no consultó el Brain OS antes de proponer/inventar. La causa raíz es la misma: **no existe un gate explícito y obligatorio de "consulta Brain OS" antes de entrar en modo creativo/productivo**. El agente tenía las herramientas (Grep, Read, LLM-Wiki) y el conocimiento de que existían — pero el rito no estaba codificado como prerequisito. **Conexión WORX:** El sistema afectado es **Signal/Truth** (información canónica disponible no circulaba al momento de la decisión) y **Tooling/Knowledge** (las herramientas de consulta existían pero no se activaron). La superficie es **LAB** porque ocurre en operación interna, pero su impacto se proyecta a **PROD** porque cualquier propuesta basada en redescubrimiento llega al cliente como duplicado o divergencia del canónico. **Riesgos:** - Trabajo duplicado: el agente produce activos que compiten con canónicos existentes - Divergencia del canónico: el activo nuevo se desincroniza del esquema oficial y crea entropía en el vault - Dilución de la metodología WORX: si el agente no respeta sus propios canónicos, no puede transferir esa disciplina al cliente - Compounding negativo: cada sesión sin consulta agrega más entropía y debilita el Brain OS como activo - Pérdida del valor diferencial: como Victor lo planteó — sin esto, "estamos en una sesión individual de ChatGPT como hace 3 años" **Lo que revela:** La metodología WORX está documentada como ideal pero no amarrada a la práctica del agente. El Brain OS funciona — el problema es que la consulta es opcional/intuitiva, no obligatoria/protocolizada. Esto es lo que Victor capturó textualmente: *"Todo está en nuestro vault. Debería estar en nuestro Brain OS. SI no podemos encontrarla rapidamente estamos fritos. Quiere decir que nuestra metodología WORX es un ideal y no está amarrado en la práctica."* **Acción correctiva:** 1. **Antídoto Brain OS-First** (en diseño): Insertar gate de consulta forzosa al Brain OS como prerequisito de cualquier proposición o productización. Aplica a agentes (Jacob/Sherpa) y se proyecta como principio para humanos colaboradores. 2. **Gate G0** propuesto en `MF-BMF-Publishing-v01.md`: agregar estación previa a I1 Ideador con pregunta canónica *"¿Existe ya este activo o un canónico relacionado en el vault? Ruta: ___ . Si existe, ¿estamos extendiendo, refinando o duplicando?"* — PASS solo con respuesta explícita y trazable. 3. **Replanteo Task #9** del HIORG Demand Gen Room: el TP-MePB-CreacionContenidos se declara explícitamente como extensión/aplicación del schema canónico `MePB-XX-XPack-Schema-v01.md`, no como creación independiente. 4. **Cierre por descubrimiento** de N-P-15 (brief Publishing Factory) y N-P-16 (brief pipeline) — la información canónica reemplaza al brief solicitado. **Status:** ✅ Antídoto codificado — Gate G0 + Estación I0 + Invariante PUB-04 ratificadas en MF-BMF-Publishing-v02 · 2026-04-26 → ~~NEXT[@Victor]~~: ✅ DONE — 2026-04-26 · Gate G0 "Consulta Brain OS" agregado formalmente a `MF-BMF-Publishing-v01.md` como estación I0 previa a I1 Ideador. Invariante PUB-04 codificada. Documento bumpeó a v02. → ~~NEXT[@Victor]~~: ✅ DONE — 2026-04-26 · Alcance del MePB ratificado AMPLIO (cualquier sistema productivo repetible · no solo editorial) · N-P-14 cerrado. → ~~NEXT[@Jacob]~~: ✅ DONE — 2026-04-26 · Protocolo Brain OS-First diseñado en 3 capas (Gate G0 + Protocolo Jay-First + 5 señales activación) · ratificado por Victor · codificado en sección 3.2.1 de `MF-BMF-Publishing-v02`. → NEXT[@Jacob]: Replantear `TP-MePB-CreacionContenidos-EL-v01` como extensión declarada del `MePB-XX-XPack-Schema-v01` (frontmatter `extends:` + 7 secciones del schema). Aplicado al primer activo del PB-MPB-Library cuando se produzca (Task #37 del programa HIORG). → NEXT[@Jacob]: Crear `BC-EL-BrainOSFirst-v01.md` como Brain Code que codifique el protocolo de operación del agente — protocolo formal que sobrevive a la sesión. --- ## CASO 009 ### Template de cierre de Decisión Bloqueada · de "bloqueo" a D-P canonizada en 1 sesión **Fecha:** 2026-05-07 · **Tipo:** Innovación · **Principio:** P006 — Decisiones canonizables (a canonizar) · **Sistema WORX:** Signal/Truth + Roles/Decisions · **Superficie:** LAB → PROD **¿Qué pasó?** En el room `PB-MONETIZACION-Estrategica` el XPack-Dominó tenía 5 decisiones bloqueadas listadas como "necesitan Victor". Una de ellas — pricing definitivo SherpaX Ignition para B2O — se cerró en una sesión usando un patrón replicable que vale la pena documentar como template. **El template aplicado:** ``` 1. Investigación previa profunda (lectura de canónicos relevantes · 5-7 min) 2. Documento estructurado en chat: - Contexto canonizado (lo que ya existe) - La pregunta a cerrar (formulada en una línea) - Datos que faltan (marcados explícitamente como "🔴 Victor confirma") - 2-3 opciones con pros/cons + tabla - Recomendación con racional numerado - Cómo se canoniza post-decisión (lista de archivos afectados) 3. AskUserQuestion con la decisión + datos + velocidad 4. Ratificación de Victor → ejecución en cascada: a. Cierre en el XPack madre (sección DECISIONES BLOQUEADAS → DECISIONES CERRADAS · D-P-NN) b. TP nuevo (capa financiera/operativa) aplicando D-P-40 (template R-MN-*) c. Actualización del ProdSpec o asset operativo con pricing/decisión ratificada d. CAS del LabPraxis (este caso) ``` **Por qué importa:** 1. Convierte "decisiones bloqueadas" (que tienden a estancarse semanas) en **D-P canonizadas en 1 sesión** con todos los archivos sincronizados. 2. La estructura "propuesta + opciones + recomendación" reduce la carga de decisión de Victor — no piensa desde cero, valida una recomendación bien fundada. 3. Marcar **"🔴 datos que faltan"** evita el patrón pasivo-agresivo de "asumí X" — Victor da datos, no rellena huecos. 4. La cascada post-decisión asegura que el cierre **no se quede en chat** sino que aterrice en archivos canónicos (XPack + TP + ProdSpec + CAS). **Riesgos del template (a vigilar):** - **Ritmo de las opciones:** si las 3 opciones están sesgadas hacia la recomendación, deja de ser decisión real. Antídoto: cada opción debe poder defenderse. - **Saltarse la investigación previa:** la calidad de la propuesta depende de leer canónicos primero. Sin G0 / Brain OS-First (ver Caso 008), el template produce decisiones mal calibradas. - **Canonizar antes de validar mercado:** algunas decisiones (e.g., pricing) deberían tener piloto con clientes antes de canonizar. AskUserQuestion debe incluir opción "espera · piloto primero". **Aplicación piloto: D-P-41 · Pricing SherpaX Ignition (Banda con Tiers $5K/$7.5K/$10K)** - Investigación: leyó CP-EL-SX-ProdSpec-Ignition-v01 (Draft v0.2) + LLM-Wiki/Wiki SherpaX-Ignition · GTM · Value-Proposition · ICP + TP-HIORGS-ModeloNegocio-Pricing v01.1 (template R-MN-*). - Datos faltantes confirmados por Victor: los 3 casos validados (Litos · Alain · Adriana) fueron pro-bono → sin deuda histórica con $3K. - Decisión ratificada: Opción C (Banda con Tiers). - Cascada: XPack-Dominó v01.3 (D-P-41 en sección DECISIONES CERRADAS) + TP-SX-ModeloNegocio-Pricing-v01 (nuevo · template R-MN-* heredado de D-P-40) + CP-EL-SX-ProdSpec-Ignition v02 (Active · Sección 5/6/8 actualizadas) + este CAS-009. **Lo que revela:** El XPack-Dominó tenía 5 decisiones bloqueadas. Las decisiones bloqueadas son piezas del dominó que no caen porque falta articular la propuesta. **Cuando se articula bien, caen rápido.** El cuello de botella no es Victor decidiendo · es Jay (o quien sea) sin estructurar la propuesta lo suficiente como para que decidir sea rápido. **Status:** 🟡 En piloto — 1ra aplicación cerrada (D-P-41). Próximas 3 aplicaciones (D-P-42 a D-P-44) en este mismo XPack-Dominó validarán el template. Si las 4 cierran limpias, se canoniza P006 como principio formal "Decisiones canonizables · de bloqueo a D-P en 1 sesión con cascada estructurada". → NEXT[@Jay]: Aplicar mismo template a Decisión #2 (escalera R100X / Re100X) · misma estructura · medir tiempo y calidad de cierre. → NEXT[@Jay]: Aplicar template a Decisión #3 (responsables operativos por línea) y Decisión #4 (cadencia/KPIs/reporte de salud del dominó). → NEXT[@Jacob]: Si las 4 decisiones cierran con el template, proponer canonización de P006 como Brain Code (`BC-EL-DecisionesCanonizables-v01.md`) · protocolo formal que sobrevive a la sesión. → NEXT[@Jay]: Documentar la diferencia entre "decisión bloqueada" (espera input) vs. "decisión bloqueante" (bloquea otras) · puede ser caso CAS-010. --- ## CASO 010 ### Bundle como aceleración de lanzamiento de producto premium · MONEX Intro α **Fecha:** 2026-05-07 · **Tipo:** Innovación · **Principio:** P007 — Innovation + Adjacent Bundle (a canonizar) · **Sistema WORX:** Roles/Decisions + Pricing/Value · **Superficie:** PROD **¿Qué pasó?** En la canonización de la D-P-42 (activación de la escalera Re100X con MONEX), Victor tomó una decisión arquitectónica no obvia: en lugar de lanzar MONEX standalone con pricing High Ticket TBD, lanzar un **bundle introductorio de duración limitada** combinando MONEX (producto nuevo, en lanzamiento) con SherpaX (producto adyacente del ecosistema, ya validado con 3 demos pro-bono) a $5,000 USD para los primeros 10 clientes. El bundle incluye 4 componentes integrados: 1. MONEX Core (productización + monetización del expertise) 2. SherpaX configurado (copiloto operativo del experto) 3. Modelo de negocio aterrizado co-creado con SherpaX (entregable concreto) 4. 6 sesiones 1:1 con Victor durante el programa **El insight estratégico:** Cuando lanzas un producto premium nuevo cuya demanda aún no está validada comercialmente (MONEX), bundlearlo con un producto adyacente del ecosistema que ya tiene tracción (SherpaX) acelera la adopción inicial sin diluir el posicionamiento, siempre que se cumplan 3 condiciones: 1. **Los 2 productos son para ICPs distintos** (en este caso · MONEX para expertos/consultores · SherpaX standalone para Business Owners). El bundle no contamina las rutas standalone porque los compradores no se intersectan. 2. **El bundle tiene cierre temporal o por número de clientes** (10 clientes en este caso). Después se separa y cada producto va a su ruta standalone con su pricing β. 3. **El producto adyacente refuerza el delivery del producto nuevo** (en este caso · SherpaX como copiloto operativo aterriza el modelo de negocio que MONEX ayuda a productizar). No es bundle decorativo · es complementariedad funcional. **Por qué es innovación replicable:** 1. **Acelera adopción** — el cliente percibe el bundle como "mucho más por el mismo precio" · barrera de entrada psicológica más baja. 2. **Genera primeros casos de éxito** del producto nuevo más rápido (testimonios para DemandGen post-α). 3. **Valida integración** entre productos del ecosistema (¿SherpaX en mode "experto/consultor" funciona? ¿modelo de negocio aterrizado se puede co-crear con SherpaX en N sesiones? · datos reales de delivery integrado). 4. **Filtra clientes serios** sin necesidad de pricing HT prohibitivo desde día 1. 5. **Patrón replicable** a futuras combinaciones del ecosistema (SherpaX + HIORG · MONEX + MasterPlaybooks · etc.) cuando se lance un producto premium nuevo. **Riesgos del patrón (a vigilar):** - **Canibalización:** si los ICPs no son realmente distintos · el bundle canibaliza ventas standalone del producto adyacente. Antídoto: confirmar ICPs distintos antes de bundlear. - **Bundle queda permanente:** sin trigger de cierre claro · se vuelve precio normal · el producto premium nunca alcanza pricing HT objetivo. Antídoto: cierre por # de clientes (no por fecha) · canonizar pricing β en D-P separada. - **Producto adyacente queda muerto en el bundle:** si el cliente compra el bundle por uno solo de los 2 productos · el otro queda como bonus no aprovechado · diluye valor percibido. Antídoto: monitorear EWI (R-MN-MX-4 · adopción de SherpaX <40% en primeros 30 días). - **Carga del producto adyacente sobre el equipo:** SherpaX dentro del bundle requiere onboarding · configuración · soporte · todo eso suma carga al equipo Sherpa Guide y a Victor (R-MN-MX-2 · 60h Victor en α). **Aplicación piloto: D-P-42 · Bundle MONEX Intro α** - $5,000 USD bundle · primeros 10 clientes · cierre fase α al cliente #10. - 4 componentes integrados (MONEX + SherpaX + modelo de negocio aterrizado + 6 sesiones Victor). - Lanzamiento: mayo 2026 con prep 1-2 semanas. - Estructura β post-α deferida a D-P-43 (MONEX Standard solo / MONEX Premium con SherpaX+CRM · pricing TBD). - Cascada de canonización ejecutada: D-P-42 en XPack-Dominó (v01.4) · TP-MONEX-ModeloNegocio-Pricing-v01 (con template R-MN-* aplicado · 3er TP del ecosistema en aplicarlo) · PLAN-Re100X-ActivacionEscalera-v01 (4 fases F1-F4 · 8 semanas) · MAP v03 + CP v02 actualizados con escalera simplificada · este CAS-010. **Lo que revela:** El patrón "Innovation + Adjacent Bundle" es una herramienta de productización fuerte cuando 2 condiciones se cumplen: 1. Tienes un producto nuevo cuyo pricing HT aún no se valida con el mercado. 2. Tienes un producto adyacente del ecosistema con tracción y delivery probado. Bundleamos por tiempo limitado para acelerar adopción del producto nuevo · validar pricing real · y separar después. Es lo opuesto al patrón "Bundle Permanente como Anchor" (donde el bundle es siempre la oferta principal y no se separa). Acá el bundle es **catalizador**, no estructura. **Status:** 🟡 En piloto — pendiente del cohort 1 del bundle α (mayo-junio 2026). Cuando se cierre cliente #10 y se canonice D-P-43, se evalúa si elevar P007 a Brain Code formal (`BC-EL-InnovationAdjacentBundle-v01.md`) y replicar el patrón a otras combinaciones del ecosistema. → NEXT[@Victor + @Jay]: Ejecutar PLAN-Re100X-ActivacionEscalera-v01 fases F1-F4 · validar bundle con cohort 1 (junio 2026). → NEXT[@Jay]: Documentar al cierre del cohort 1 los datos reales: NPS · adopción de SherpaX en bundle · NPS de las 6 sesiones Victor · valor percibido del modelo de negocio aterrizado · willingness-to-pay para β. → NEXT[@Jay]: Si el bundle valida con cohort 1 (NPS ≥8 · adopción SherpaX ≥40%) · proponer canonización de P007 como Brain Code para replicar el patrón. → NEXT[@Victor + @Jay]: Cuando se acerque cliente #10 · arrancar D-P-43 con TP-MONEX-ModeloNegocio-Pricing-v02 (estructura β · pricing canónico Standard/Premium con datos reales). --- ## CASO 011 ### Reorganización por pilares como espejo organizacional de D-P-01 **Fecha:** 2026-05-07 · **Tipo:** Innovación · **Principio:** P008 — Espejo organizacional cognición/operación (a canonizar) · **Sistema WORX:** Roles/Decisions + Trust/Relationships · **Superficie:** PROD **¿Qué pasó?** En la canonización de D-P-44 (responsables operativos por línea), Victor tomó una decisión arquitectónica que va más allá de "asignar personas a líneas". Reorganizó la estructura completa de EmpowerLabs en **3 Pilares + Operativo transversal**, alineando el organigrama con el principio D-P-01 (separación operación/cognición). La estructura ratificada: - **🧠 Pilar Cognitivo** · Lead: Victor · produce IP · sherpas · papers · MPIs core · arquitectura. - **📣 Pilar Demand Gen** · Lead: Anahí · cascada · Factoría Editorial · MPIs aplicados · 100 micro contenidos. - **💼 Pilar Comercial** · Lead: Ángeles + Apoyo: JC · pipeline · ventas · funnel · delivery · distribución. - **⚙️ Operativo (transversal)** · Tech Lead: Alex · infraestructura · BrainOS · tooling · onboarding técnico SherpaX. Adicionalmente: - **Externos canonizados explícitamente** (Carolina · Lyz · Rodrigo · Alain Ríos · Nora) — D-P-01 a nivel organizacional. - **Apoyos transversales** (Jay runner/QA · Paloma visual · Jesús+Gustavo en transición Operativo→Comercial). - **Matriz Pilar × Línea del Dominó** (4 líneas × 4 pilares) con responsables claros. **El insight estratégico:** D-P-01 (canonizada hace 6 horas) declaró que "EmpowerLabs es el productor central de activos cognitivos · iniciativas operativas los consumen, no los producen". Era un principio de arquitectura del **ecosistema externo**. D-P-44 lo replica a nivel **organizacional interno**: dentro de EL mismo, separamos producción cognitiva (Victor · Pilar Cognitivo) de producción operativa (Anahí cascada DG · Ángeles+JC ventas · Alex infra). Cada pilar tiene una función primaria y no se contamina con las otras. **Por qué es replicable:** 1. **Patrón de estructura por pilares** se puede aplicar a otras orgs cuando crecen post-startup. Los 3 pilares (Cognitivo · DG · Comercial) + Operativo transversal son universales para cualquier empresa cognitiva. 2. **El "Operativo transversal" como categoría separada** evita la trampa de organizarlo bajo un solo pilar. Infra sirve a todos, no compite con ninguno. 3. **El reconocimiento explícito de externos** (D-P-01 organizacional) protege al equipo interno de cargar trabajo de iniciativas externas. Cada externo tiene su pilar de interfaz claro. 4. **La matriz Pilar × Línea de Negocio** hace visible quién opera qué en cada línea sin crear silos. **Riesgos del patrón (a vigilar):** - **Saturación del Lead Cognitivo (Victor)** — si Victor es el único produciendo IP fundacional, se vuelve cuello de botella. Antídoto: Anahí en DG madurando hasta poder producir IP intermedia · Jay como apoyo cognitivo creciente. - **Co-liderazgo ambigüo (Ángeles+JC)** — si no hay claridad de ownership entre Ángeles lead y JC apoyo, se diluye accountability. Antídoto: ROL- formales con responsabilidades específicas (ya producido para JC v02). - **Pilares desincronizados** — si Cognitivo produce algo que DG no puede convertir, o si DG produce algo que Comercial no puede vender, hay desperdicio. Antídoto: cadencia semanal por pilar + sesión consolidada mensual. - **Externos descontrolados** — si las iniciativas externas (Rebelocity · Tribus) requieren más activos cognitivos de los que EL puede producir, se rompe la promesa. Antídoto: SLA claro de qué entrega EL y a qué cadencia. **Aplicación piloto: D-P-44 · estructura 3 pilares + operativo** - 9 personas internas asignadas (Victor · Jay · Anahí · Alex · Jesús · Gustavo · JC · Paloma · Ángeles). - 5 externos canonizados (Carolina · Lyz · Rodrigo · Alain · Nora). - 4 líneas del Dominó cruzadas por matriz Pilar × Línea. - Cascada de canonización ejecutada: D-P-44 en XPack-Dominó (v01.5) · `MAP-EL-Pilares-Estructura-Operativa-v01` (mapa visual + guía completa) · `ROL-EL-JuanCarlos-ImplementationPartner-v02` (renovación post-23-may como permanente · Pilar Comercial Apoyo) · `SOP-EL-SX-SherpaGuide-Certificacion-v01` (Alain Ríos primer SG externo) · `PLAN-Re100X-ActivacionEscalera-v01` actualizado con responsables · este CAS-011. **Lo que revela:** La separación operación/cognición no es solo principio del ecosistema (D-P-01) — es **principio de diseño organizacional interno**. Cuando una empresa cognitiva crece, debe organizarse por funciones cognitivas (producción de IP · operacionalización en DG · ejecución comercial · soporte operativo) en lugar de por líneas de producto o cliente. Esto contrasta con organigramas tradicionales (CEO-CMO-CSO-COO) que mezclan función con jerarquía. La estructura de pilares es **horizontal y funcional**, no jerárquica. **Status:** 🟡 En piloto — pendiente conversaciones individuales con cada líder de pilar (Ángeles · JC · Anahí · Alex) para ratificar asunción de rol. La estructura está canonizada documentalmente · falta la activación interpersonal. → NEXT[@Victor]: Conversaciones individuales con Ángeles · JC · Anahí · Alex esta semana · ratificar asunción de roles. → NEXT[@Jay]: Documentar al cierre del primer mes operando con la estructura: ¿hay desincronizaciones entre pilares? ¿hay saturaciones del Lead Cognitivo? ¿hay ambigüedades en co-liderazgo Ángeles+JC? → NEXT[@Jay]: Si la estructura valida después del primer mes (sin crisis materiales), proponer canonización de P008 como Brain Code (`BC-EL-OrganigramaPorPilares-v01.md`). → NEXT[@Victor + @Jay]: Cuando se cierre Carolina/Rebelocity transition · evaluar si el patrón de externos canonizados necesita ajuste. --- ## CASO 012 ### Gobernanza mínima viable como punto de arranque · MVP del sistema de revisión **Fecha:** 2026-05-07 · **Tipo:** Innovación · **Principio:** P009 — MVP de gobernanza (a canonizar) · **Sistema WORX:** Roles/Decisions + Signal/Truth · **Superficie:** PROD **¿Qué pasó?** En la canonización de D-P-45 (sistema de gobernanza del Dominó · cadencia + KPIs + reporte de salud), Jay (yo) propuse a Victor una estructura de **4 niveles de cadencia** (L1 pilar · L2 consolidado · L3 mensual · L4 trimestral) + **dashboard digital** (SumaX · Notion · Airtable). Victor rechazó la propuesta y eligió **2 niveles + Sheets/markdown** con la instrucción explícita: *"Empezar con Sheets/markdown · escalar después."* **El insight estratégico:** La trampa del overengineering en sistemas de gobernanza es real y costosa. Diseñar 4 niveles de cadencia antes de validar que 1 funciona consume capacidad de Victor + leads de pilar + Jay sin retorno comprobado. La disciplina de gobernanza es comportamental, no estructural — primero hay que validar que el equipo puede mantener 1 sesión semanal con disciplina y 1 informe mensual escrito firmado, antes de añadir más capas. **El patrón canonizado:** ``` 1. Define el MVP de gobernanza (mínimo absoluto que produce valor decisional) 2. Opera 3 ciclos completos del MVP (3 meses si la cadencia es mensual · 3 sprints si es semanal) 3. Mide qué decisiones produjo el MVP · qué desincronizaciones evitó · qué KPIs realmente movieron acción 4. Identifica triggers explícitos para escalar (no escalar antes de que prendan) 5. Escala solo lo que el MVP demostró insuficiente ``` **Por qué es replicable:** 1. **Aplica a todo sistema de gobernanza** — empresarial, de producto, de proyecto. Empezar con MVP es siempre la decisión correcta cuando no hay datos de operación. 2. **Aplica a tools** — no comprar / configurar tool dedicado antes de validar que la disciplina humana se mantiene. Sheet + markdown es suficiente para validar 3 ciclos. 3. **Aplica a frecuencia** — empezar con menor frecuencia (semanal · no diaria) y escalar solo si los datos lo justifican. 4. **Aplica a # de KPIs** — empezar con subset mínimo (5-10 KPIs core) · escalar solo si subset prueba ser insuficiente. **Riesgos del patrón (a vigilar):** - **Underengineering en lugar de overengineering** — el MVP debe ser suficientemente robusto para producir decisiones · no tan mínimo que se vuelva ritual sin valor. Antídoto: las 5 preguntas obligatorias mensuales son el ancla del valor decisional. - **Triggers de escalación no se monitorean** — sin disciplina de revisar si el MVP se queda corto · se queda permanentemente en mínimo. Antídoto: triggers explícitos canonizados en SOP (cancelación recurrente · KPIs no actualizados · pilares desincronizados). - **El "escalar después" nunca llega** — el MVP funciona suficientemente bien · nadie escala. Antídoto: revisión consciente del MVP a los 3 ciclos · decisión activa de seguir mínimo o escalar. **Aplicación piloto: D-P-45 · sistema de gobernanza** - 2 niveles de cadencia (L2 semanal 45 min + L3 mensual 60 min) en lugar de 4 propuestos. - Sheet de KPIs (Google Sheets · Excel) en lugar de SumaX/Notion/Airtable. - Informe mensual markdown (`OUT-EL-Domino-ReporteSalud-{YYYY-MM}-v01.md`) como output principal. - Triggers de escalación canonizados (L1 si pilares desincronizados · L4 si retrospectiva trimestral emerge como necesidad · tool dedicado si sheet desbordado). - Cascada de canonización: D-P-45 en XPack-Dominó (v01.6) · `SOP-EL-Domino-Cadencia-Gobernanza-v01` (proceso operativo) · `CP-EL-Domino-ReporteSalud-Template-v01` (template informe) · MAP-Pilares + MAP-Rooms actualizados · este CAS-012. **Lo que revela:** La gobernanza tiene la misma trampa de la productización: la tentación de diseñar el sistema completo antes de operar el sistema mínimo. El equipo que opera 1 sesión mensual con disciplina aprende más sobre qué necesita realmente que el equipo que diseña 4 niveles antes de la primera sesión. Y el equipo que mantiene Sheets actualizados aprende qué KPIs importan antes de invertir en dashboards complejos. Esto contrasta con la cultura "enterprise" de implementar Notion / Asana / Linear / Airtable desde día 1 con plantillas elaboradas. La verdad es que **la herramienta es el menor problema** — el comportamiento de actualizarla es el problema real. Y el comportamiento se valida con la herramienta más simple posible. **Status:** 🟡 En piloto — primera L2 programada para viernes 10 de mayo 2026 · primera L3 al cierre de mayo. Después de 3 ciclos mensuales se evalúa: ¿se mantuvo la disciplina? ¿qué se quedó corto? ¿qué triggers prendieron? → NEXT[@Jay]: Configurar Sheet de KPIs (Google Sheets) con las 5 categorías esta semana. → NEXT[@Jay]: Producir primer informe mensual (mayo 2026) usando template al cierre del mes. → NEXT[@Victor + @Jay]: Después de 3 ciclos mensuales (agosto 2026) · evaluar si MVP funcionó o necesita ajuste. → NEXT[@Jay]: Si el MVP valida después de 3 ciclos · proponer canonización de P009 como Brain Code (`BC-EL-MVPGobernanza-v01.md`) · principio replicable a otras orgs. --- ## CASO 013 ### SherpaX documenta · humano dirige (delegación de captura) **Fecha:** 2026-05-07 · **Tipo:** Innovación · principio · **Principio:** P010 ✓ canonizado — Documentación Delegada al SherpaX **¿Cuál es la oportunidad?** La captura de documentos en el vault recae frecuentemente sobre el humano: nombrar archivo correctamente, ubicarlo en el IntelliBank correcto, llenar campos del frontmatter. Eso degrada la regla §F1 del WORX MPB ("el trabajo existe para crear valor") porque convierte al humano en operador de naming convention en lugar de creador de valor sustantivo. **El principio:** > El SherpaX documenta. El humano dirige. La captura sintáctica del vault es trabajo del agente · la dirección estratégica de qué se produce es trabajo del humano. **3 operaciones canónicas delegadas:** 1. Naming canónico BMF (vía `bmf-file-renamer`). 2. Posicionamiento en IntelliBank correcto + gate de ruta (vía `vault-orphan-rescue`). 3. Llenado de campos del XDoc · frontmatter completo. **Codificación operativa:** `SOP-EL-WORX-DocBySherpa-v01` operacionaliza P010. Skill Pack mandatorio del cohort: bmf-file-renamer · vault-orphan-rescue · bmf-registry-updater · brain-code-saver · labpraxis-case-documenter. **Status:** ✅ Canonizado el 2026-05-07. Originalmente numerado CASO 009 · renumerado a CASO 013 el 2026-05-07 EOD para alinear con banco v1.6. → NEXT[@Jay]: Aplicar P010 en producción de los 2 nuevos MePBs (OrganizationalKernel + CorpBrainOS-BehaviorCapture). --- ## CASO 014 ### Room Raíz / Home Room como entidad arquitectónica **Fecha:** 2026-05-07 · **Tipo:** Innovación · principio · **Principio:** P011 ✓ canonizado — Room Raíz / Home Room **¿Cuál es la observación?** Los XPacks (XP-) y los Starter Prompts (SP-) se generaban ad-hoc · cada room que arrancaba producía sus propios documentos sin un punto canónico de origen ni un protocolo de generación. Necesitamos un Room Raíz / Home Room como punto canónico desde el cual se generan los XP- y SP- con el contexto necesario para iniciar nuevos rooms hijos. **El principio:** > Todo room hijo del ecosistema deriva de un Room Raíz que produce y versiona su Starter Pack (XP + SP). El Room Raíz es la autoridad arquitectónica del linaje · centraliza canónicos heredables · propaga cambios de protocolo con cascada controlada. **4 propiedades canónicas del Room Raíz:** 1. Autoridad de generación · produce XP- y SP- de rooms hijos. 2. Mantenimiento del linaje. 3. Centralización de canónicos. 4. Cascada controlada de cambios. **Room Raíz iniciales del ecosistema:** - `PB-WORX-Worx/` — protocolos universales del cohort SherpaX. - `PB-MONETIZACION-Estrategica/` — linaje monetización del dominó. - `IB-XX-Maestro/IPI-XX-IP-Infraestructura/` — canónicos arquitectónicos universales. **Codificación operativa:** `MAP-EL-RoomRaiz-Linaje-v01` (mapa canónico) + `SOP-EL-WORX-RoomActivation-v01` (operacionaliza P011 + P012). **Status:** ✅ Canonizado el 2026-05-07. Originalmente numerado CASO 010 · renumerado a CASO 014 el 2026-05-07 EOD para alinear con banco v1.6. → NEXT[@Victor + @Jay]: Confirmar si Raíz 3 (`IB-XX-Maestro/IPI-XX-IP-Infraestructura/`) es Raíz formal o solo área de canónicos. --- ## CASO 015 ### Carga del Starter Pack (XP+SP) al inicio de cualquier conversación **Fecha:** 2026-05-07 · **Tipo:** Innovación · principio · **Principio:** P012 ✓ canonizado — Starter Pack Loading **¿Qué falta?** El SOP-BrainOSFirst (P006) ya obligaba a invocación previa · pero **no obligaba la carga literal** del XP- y del SP- del Room Raíz al inicio. Consecuencia: el SherpaX podía arrancar sin haber leído el contexto canónico del room · genera output desalineado. **El principio:** > Al inicio de cualquier conversación con un proyecto o iniciativa, el SherpaX carga el Starter Pack (XP + SP) del Room Raíz aplicable antes de cualquier producción · sin excepción · sin atajos. La carga es literal · no inferida. **Ritual canónico de activación · 7 estaciones:** 1. Identificar Room Raíz aplicable (P011). 2. Cargar XP- del Raíz literal (Read · no inferir). 3. Cargar SP- del Raíz literal. 4. Ejecutar SOP-BrainOSFirst sobre alcance del room hijo (P006 · output `CONS-`). 5. Verificar BrainOS / Brain OS personal. 6. Si necesario · actualizar XP- antes de producir. 7. Reportar al Owner el `CONS-` + estado del XP-. **Codificación operativa:** `SOP-EL-WORX-RoomActivation-v01` operacionaliza P011 + P012 conjuntamente. **Status:** ✅ Canonizado el 2026-05-07. Originalmente numerado CASO 011 · renumerado a CASO 015 el 2026-05-07 EOD para alinear con banco v1.6. → NEXT[@Jay]: Aplicar SOP-RoomActivation en los rooms operativos del cohort EL antes de Sesión 2 (próxima pasada de auditoría). --- ## CASO 016 ### Validación externa de la categoría · Diana Hu (Y Combinator) nombra el problema que llevamos 20 años resolviendo **Fecha:** 2026-05-07 · **Tipo:** Validación externa · evidencia comercial · **Principio:** Sin principio derivado (es validación · no innovación interna) **¿Qué pasó?** Diana Hu (Group Partner en Y Combinator) publicó una observación sobre la oportunidad de mercado en AI companies que captura exactamente la categoría que EmpowerLabs lleva 20+ años construyendo. Quote literal: > *"The best AI companies we're seeing has figured out something most haven't. They've made their entire company aquarium · every meeting recorded · every ticket tracked · every customer interaction captured · all legible to an AI layer that learned from it. This turns a company from an open loop into a closed loop. In an open loop you make a decision and maybe check the results weeks later. In a closed loop the system monitors what's happening compared to what should be happening and adjusts. I see teams that do this cut sprint time in half and ship 10X as much. The problem is building this today requires brutal integration work · stitching together Slack · Linear · Git · Notion · call recordings and a dozen other tools with custom glue and AI-generated code. There's no product that connects all this context into a single AI layer. Building backend agents that execute is the wrong thing — we think there's a big opportunity to build the connective layer that makes a company legible to AI by default · the system that turns a company's own artifacts into a self-improvement loop."* **Análisis · mapeo punto-por-punto contra arquitectura EL:** | Diana Hu (problema/oportunidad) | EmpowerLabs (canónico vault) | Veredicto | |---|---|---| | "Company aquarium · everything captured · legible to AI" | Vault con XDocs + LabPraxis + §8 Cap 5 MPB-WORX (Curaduría) + GAP 2 (CONS-BigMetaPlaybook §3.2) | ✅ + ⚠️ con curaduría como filosofía deliberada | | "Open loop → closed loop · system monitors and adjusts" | MEL L6 + 4 ritmos canónicos + LabPraxis + agente de ritmo + agente de dependencias | ✅ Más completo | | "Cut sprint time in half · ship 10X" | ROI Tracker con multiplicadores 30×–360× documentados en 7 casos | ✅ Adelantados | | "Brutal integration work · 12 tools" | WORX §2.6 islas transaccionales conectadas + §9.7 patrones de integración | ✅ No hacemos stitching · diseño desde primeros principios | | "No product connects all this context · single AI layer" | SO-HiORG (WORX + Corp Brain OS + SherpaX) = ese producto | ✅ Lo construimos y vendemos | | "Connective layer · makes company legible to AI by default" | Corp Brain OS arquitectura Supabase + LabPraxis + 3 SOPs forzosos | ✅ Adelantados | | "Backend agents that execute is wrong thing" | SherpaX viven SOBRE la capa conectiva · no standalone | ✅ Adelantados | **3 diferencias filosóficas reales:** 1. **Capture EVERYTHING vs Curated capture** — Diana propone captura indiscriminada. Nosotros tenemos curaduría humana antes de cruzar al colectivo (P010 + Cap 5 §8 MPB-WORX). Razones: privacy by design · señal sobre ruido · evita panopticon. 2. **Diana habla de 1 capa (connective) · nosotros tenemos 3 pilares** (WORX + Corp Brain OS + SherpaX). Sin método, los "back agents" + "connective layer" reproducen Hero-Operator Dependency. 3. **Diana describe monitoreo sin enforcement · nosotros tenemos MEL** (L6 BMF · Mastery Enforcement Layer). *"Without MEL, governance is advisory. With MEL, governance becomes structural physics."* **Por qué importa:** - **Validación externa de YC** legitima la categoría que estamos construyendo · ammunition comercial directa para línea B2B HIORG. - **Anclaje histórico** del momento (mayo 2026 · YC valida). - **Pieza de contenido** para motor MasterPlaybooks (cita citable en pitch B2B). - **Confirmación · vamos en dirección correcta y adelantados.** **Implicación arquitectónica:** - Adoptar "Company Aquarium" como concepto canónico en `MePB-EL-OrganizationalKernel-v01` (le da meme-handle vendible). - Hacer explícita la tensión "Everything captured" vs "Curated capture" en `MePB-EL-CorpBrainOS-BehaviorCapture-v01` con arquitectura de 3 capas (ingest amplio · curaduría humana · ingest indirecto auditable). - Citar a Diana Hu en la introducción del segundo MePB · convierte el activo en cliente-facing también. **Status:** ✅ Documentado · evidencia comercial archivada para línea B2B HIORG. → NEXT[@Victor + @Jay]: Capturar el quote completo en biblioteca de testimonials/validations externas para uso en pitch decks B2B. → NEXT[@Anahí]: Considerar este caso como insumo para una cascada de contenido del motor MasterPlaybooks (ej. "YC valida la categoría HiOrg · tras 20 años de construcción de EmpowerLabs"). --- ## CASO 017 ### Drift entre TP-LabPraxis y banco · Brain OS-First aplicado al TP sin verificar banco paralelo (meta-recursivo) **Fecha:** 2026-05-07 EOD · **Tipo:** Falla compuesta · meta-recursiva · **Principio:** P013 (a canonizar) — Lectura cruzada TP↔banco antes de agregar caso **¿Qué pasó?** En la sesión 009 LabPraxis (mañana del 2026-05-07), Jay actualizó `TP-EL-WORX-LabPraxis-v01` de v1.4 a v1.5 agregando 3 nuevos casos numerados CASOS 009-011 con principios candidatos P007-P009. Al hacerlo, **Jay leyó el TP** (que estaba en v1.4 con 8 casos canonizados) **pero NO leyó el banco** `CAS-EL-WORX-LabPraxis-BancoCasos-v01` que ya estaba en v1.6 con 12 casos canonizados desde sesiones paralelas del mismo día (D-P-41 · D-P-42 · D-P-44 · D-P-45). Resultado: pisó la numeración del banco con casos completamente diferentes. **La ironía operativa:** El TP-LabPraxis es **el room donde nace P006 (Brain OS-First · agente debe consultar el vault antes de proponer)**. Jay aplicó el principio al alcance del CASO 008 originalmente, pero falló en aplicarlo al alcance del propio TP cuando fue a actualizarlo. Es una falla meta-recursiva: Brain OS-First fallido aplicado al room que canoniza Brain OS-First. **La causa raíz:** P006 obliga a consultar canónicos vault sobre el alcance del proyecto · pero NO especifica que cuando hay un TP y un banco paralelo del mismo proceso operativo, ambos deben leerse. La heurística de "buscar en el vault" no incluye explícitamente "y verifica si hay archivos paralelos al que vas a actualizar." **¿Cuál es el riesgo si no se canoniza?** - Drift recurrente entre archivos paralelos del mismo proceso. - Numeración inconsistente que rompe trazabilidad. - Trabajo de remediación masivo (12+ archivos derivados a renumerar). - Pérdida de confianza en el sistema · si el principio no se aplica a sí mismo, ¿qué confianza hay? **Acción correctiva ejecutada:** 1. Rename masivo de CASOS 009-011 (TP) → CASOS 013-015 + P007-P009 → P010-P012. 2. Update en cascada a 12+ archivos derivados (PROT-Cohort · 2 SOPs · MAP-RoomRaiz · XP/SP Caso 0 v02 · MAP-Rooms-Domino · MAP-Rooms-Visual · 5 SP- patcheados · Registry · CONS-BigMetaPlaybook). 3. Documentación de este caso para captura del aprendizaje. **Principio que revela (P013 a canonizar):** > **Antes de actualizar un Transfer Pack o un activo de gobernanza emergente (LabPraxis · BMF · etc.), verificar TODOS los archivos paralelos del mismo proceso operativo (banco · canónicos compañeros · activos espejo) — no solo el activo target. La consulta al vault debe ser cruzada · no aislada al archivo.** **Codificación operativa propuesta (a canonizar como antídoto):** 1. Extender SOP-EL-WORX-BrainOSFirst-v01 con nueva regla: "Si el alcance es actualizar un activo con canónicos paralelos (TP↔banco · MAP↔Visual · XP↔SP), leer todos los paralelos antes de la decisión." 2. Producir `BC-EL-CrossReferenceConsulta-v01` como Brain Code que codifique la heurística para futuros agentes. 3. Test del antídoto en próxima actualización del LabPraxis (CASO 018). **Lo que revela:** La gobernanza emergente es vulnerable a su propio principio cuando los archivos del proceso son múltiples y se actualizan en paralelo. La defensa no es más documentación · es heurística cruzada explícita en el SOP de consulta. Esta falla también valida P006 desde el ángulo opuesto: la disciplina de Brain OS-First no es "vez y cuando" · es estructural · y debe extenderse a casos no obvios. **Status:** 🟡 En piloto — antídoto P013 en diseño. Próxima actualización del LabPraxis (CASO 018+) testeará si la regla cross-reference se aplica. → NEXT[@Jay]: Producir `BC-EL-CrossReferenceConsulta-v01` como Brain Code antídoto. → NEXT[@Jay]: Extender SOP-EL-WORX-BrainOSFirst-v01 con sección VI nueva (Cross-Reference Rule) en próxima sesión LabPraxis. → NEXT[@Victor]: Validar canonización de P013 después de 1 caso piloto exitoso aplicando el antídoto. --- ## CASO 018 ### Frontmatter heredado de template sin validación · 3 docs producidos 18-may registran fecha_creacion 7-may **Fecha:** 2026-05-18 · **Tipo:** Falla compuesta (Falla operativa + Brecha de validación) · **Principio:** P014 (a canonizar) — Frontmatter Integrity **¿Qué pasó?** El lunes 18-may, al actualizar la minuta semanal con tres documentos solicitados por Victor (MePB-EL-HIORG-SecurityLayers-v01 + SOP-EL-HIORG-SanitizacionDemoVault-v01 + DC-EL-SX-SherpaX-ArquitecturaOperacion-v01), Jay leyó los frontmatter y registró las fechas que figuraban ahí. Dos de los archivos declaraban `fecha_creacion: 2026-05-07` — fechas que Jay tomó como ciertas y reportó así a Victor en la minuta. Victor identificó la anomalía: "los hice hoy." **Verificación con el filesystem** confirmó la falla: | Archivo | Timestamp real del filesystem | fecha_creacion en frontmatter | |---|---|---| | `PBO-EL-HIORG-Instalacion-Caso0-v01.md` | 2026-05-18 10:31 | 2026-05-07 | | `MePB-EL-HIORG-SecurityLayers-v01.md` | 2026-05-18 15:50 | 2026-05-07 | | `SOP-EL-HIORG-SanitizacionDemoVault-v01.md` | 2026-05-18 15:53 | 2026-05-07 | Los 3 archivos comparten dominio (HIORG · seguridad / instalación). Sugiere que fueron producidos en la misma sesión usando frontmatter copiado de un template o de un documento previo del 7-may, sin actualizar el campo `fecha_creacion`. Otros 39 archivos con `fecha_creacion: 2026-05-07` en el vault sí coinciden con su timestamp del filesystem · la falla es localizada a estos 3. **La falla compuesta (sistemas WERK · Signal/Truth + Tooling/Knowledge · superficie LAB con riesgo BRIDGE):** 1. **Signal/Truth roto:** la `fecha_creacion` del frontmatter es la única fuente declarada para el cuándo de un activo. Si miente, toda cronología derivada (minutas semanales · registry · auditorías · LabPraxis · cifras del ritual) hereda la mentira. 2. **Tooling/Knowledge brecha:** no existe un gate de validación que compare la fecha del frontmatter contra el timestamp del filesystem antes de canonizar un activo. El sherpa puede copiar frontmatter y no hay quien lo detenga. 3. **Brain OS-First aplicado parcialmente:** el sherpa que produjo los docs consultó el vault (Brain OS) para el contenido y la estructura, pero no consultó la realidad temporal (filesystem) para los metadatos. P006 cubre contenido · no cubre metadatos canónicos. **Conexión con casos previos:** - **CASO 008** (Agente sin consultar el vault antes de proponer · P006 Brain OS-First) — esta es una variante donde el agente consulta el vault para contenido pero no para metadatos. - **CASO 017** (Drift TP↔banco · P013 Cross-Reference) — el caso anticipó que "la próxima actualización del LabPraxis testearía si la regla cross-reference se aplica." Este caso confirma que P013 no es suficiente: se necesita cross-reference no solo entre archivos canónicos paralelos, sino entre frontmatter y la realidad observable del archivo. **Riesgos si no se resuelve:** - Cronología falsa en minutas semanales — un activo del 18-may aparece como del 7-may y se cuenta dos veces o se pierde en una semana donde no debería estar. - Imposibilidad de auditar cuándo se produjo realmente cada activo · compromete trazabilidad histórica. - Ritual de cierre semanal vulnerable — no se sabe qué pertenece a qué semana si el frontmatter miente. - Cifras agregadas (ej. "24+ activos canónicos esta semana") pueden estar infladas o subestimadas. - Si los docs cruzan a entrega B2B (clientes vía Demo Vault sanitizado), el cliente recibe metadata falso · riesgo reputacional. - **Riesgo meta:** el sherpa transmite confianza falsa al usuario · Victor recibió un reporte como cierto cuando era contaminado. **Causa raíz:** El protocolo de producción canónica (templates · frontmatter copiado · auto-completado por SherpaX) no incluye un paso de **validación temporal**. La heurística "uso el frontmatter del último doc similar como base" es eficiente pero pierde la pieza de información que debería actualizarse SIEMPRE: la fecha. **Principio que revela (P014 a canonizar):** > **Frontmatter Integrity** — todo campo canónico del frontmatter que se refiere a un hecho observable (fecha de creación · timestamp · autor · versión · status) debe coincidir con la realidad observable del archivo o del proceso al momento de canonizar. Heredar frontmatter de templates está permitido · heredar campos que se refieren a la realidad sin validar contra ella está prohibido. **Codificación operativa propuesta (antídoto en 3 capas):** 1. **Capa inmediata · 3 correcciones puntuales** — corregir hoy los 3 frontmatter de los archivos identificados (cambiar `fecha_creacion: 2026-05-07` → `2026-05-18`) + agregar nota explicativa en el CHANGELOG de cada uno. 2. **Capa estructural · SOP nuevo** — producir `SOP-EL-WORX-FrontmatterIntegrity-v01` con: - Lista de campos del frontmatter que SIEMPRE se validan al canonizar (fecha_creacion · fecha_ultima_actualizacion · owner · version). - Procedimiento de validación: comparar contra filesystem timestamp + contra fecha actual + contra contexto de la sesión. - Gate obligatorio: si un campo se hereda de template, anotarlo explícitamente como `(heredado · verificar antes de cerrar)`. 3. **Capa universal · extensión de P006 Brain OS-First** — extender `SOP-EL-WORX-BrainOSFirst-v01` con sección VII (Frontmatter Integrity Rule): "Brain OS-First aplica tanto al contenido como a los metadatos canónicos. Antes de canonizar, validar que el frontmatter refleja la realidad observable del archivo y del momento de producción." 4. **Capa de auditoría retrospectiva** — barrido del vault buscando docs con divergencia frontmatter vs filesystem timestamp. Foco inicial: docs con `fecha_creacion` agrupada (varios archivos con la misma fecha) — patrón sospechoso de canonización en lote con frontmatter heredado. **Status:** 🔴 Abierto · antídoto en 4 capas propuesto · 3 correcciones inmediatas pendientes. → NEXT[@Jay]: Corregir los 3 archivos identificados — actualizar `fecha_creacion` a 2026-05-18 + agregar nota en CHANGELOG documentando la corrección y el caso de referencia (CASO 018). → NEXT[@Jay]: Producir `SOP-EL-WORX-FrontmatterIntegrity-v01` con los 4 niveles de validación. → NEXT[@Jay]: Extender `SOP-EL-WORX-BrainOSFirst-v01` con sección VII (Frontmatter Integrity Rule). → NEXT[@Jay]: Auditoría retrospectiva del vault — identificar docs con divergencia frontmatter ↔ filesystem · reportar magnitud. → NEXT[@Victor]: Ratificar canonización de P014 después de revisar el SOP propuesto. → NEXT[@Victor]: Decidir si la minuta de la semana 18-may requiere corrección retroactiva donde menciona "pre-existentes del 7-may" para estos dos docs. --- ## 💬 THREAD *Espacio para notas y pendientes del banco de casos* → ~~NEXT[@Victor]~~: ✅ DONE — 2026-04-16 · Confirmar si `PLAN-` se agrega formalmente al canon BMF → ~~NEXT[@Victor]~~: ✅ DONE — 2026-04-16 · Confirmar si `LAB-` es el nuevo TIPO oficial para documentos de Lab --- *CAS-EL-WORX-LabPraxis-BancoCasos-v01.md · EmpowerLabs / WORX · 2026-04-15* *Actualizar en cada sesión del LabPraxis — agregar nuevos casos al índice y al cuerpo*