---
type: Transfer Pack
asset_id: TP-EL-WORX-LabPraxis-v01
version: v1.6
room: LabPraxis
owner: Victor Heredia / EmpowerLabs
sherpa: Jacob
fecha_creacion: 2026-04-15
ultima_actualizacion: 2026-07-16 (header sincronizado con banco · cuerpo del TP con drift conocido — ver CASO 017)
sesion: 009b (cuerpo) · header al día
total_casos: 29 (fuente de verdad = CAS-EL-WORX-LabPraxis-BancoCasos-v01)
total_principios: 23 (P001–P023 · P022 y P023 emergentes en piloto · P017 con 2da evidencia)
ultimo_caso: CASO 029 — Derivado del buzón editado a mano sin regenerar ni contrato de formato (2da evidencia P017)
ultimo_principio: P023 (emergente) — Contexto Prerequisito Explícito
---

## 📋 CHANGELOG
| Fecha | Cambio | Por |
|-------|--------|-----|
| 2026-07-16 | **CASO 029 agregado al banco.** Título: "Derivado del buzón editado a mano sin regenerar ni contrato de formato (HTML literal en datos → tablero ilegible)". Tipo: Falla (derivada de la brecha del scanner). Principio **P017** — Derivado = Regenerado + verificación: **segunda evidencia** (primera: CASO 021), refuerza su candidatura a canonización. Reportado por Juan Carlos: 14 de 19 mensajes en `BZ-EL-BuzonData-v01.js` traían HTML literal (`<br>`, `<b>`) en el body; el tablero (que escapa HTML por seguridad) los mostraba como texto. Síntoma resuelto el mismo día: datos normalizados a markdown + `fmtBody` del tablero hecho tolerante a HTML residual. Antídoto de raíz pendiente: el scanner (tercera consecuencia documentada de su ausencia: NULs 14-jul, dashboard a mano, HTML literal). NEXTs: Alex construye el scanner · Jay documenta el contrato de formato del body en la spec. Header de este TP sincronizado con el banco (29 casos · 23 principios); el cuerpo conserva drift conocido (CASO 017, antídoto pendiente). | @JuanCarlos |
| 2026-07-15 | **CASO 028 agregado al banco.** Título: "El Rally asume contexto que aún no ha entregado (ubicación del vault, terminología IntelliBanks, catálogo de Tipos)". Tipo: Brecha compuesta. Principio candidato **P023** (emergente) — Contexto Prerequisito Explícito. Reportado por Juan Carlos: 3 puntos con la misma causa raíz — (1) el Rally manda a leer conceptos básicos sin explicar antes dónde vive el vault; (2) "Intellibanks" se usa para 3 cosas distintas (app, carpeta raíz, carpetas IB-*) sin aclararlo; (3) el ejercicio de naming exige el catálogo de Tipos que aún no se ha entregado. Relacionado con CASO 027 (mismo Rally, capa de mecanismo/UI; este caso es de secuenciación pedagógica). NEXTs: JC envía los 3 hallazgos por buzón junto con los de CASO 027 · Victor decide si agrega paso de "ubicación del vault" · Jay aclara términos y enlaza catálogo de Tipos antes del ejercicio. Header de este TP sincronizado con el banco (28 casos · 23 principios); el cuerpo conserva drift conocido (CASO 017, antídoto pendiente). | @JuanCarlos |
| 2026-07-15 | **CASO 027 agregado al banco.** Título: "Brechas detectadas al correr el Rally de Inducción WORX (candidatas a v02)". Tipo: Brecha. Sin principio formal aún (emergente). Reportado por Juan Carlos tras correr el Rally completo (8/8, 14-jul) como operador real: (1) el botón "+ Compartir" del dashboard HOY solo funciona dentro de Cowork; (2) la Misión 3 puede confundir "WikiX-EL-Hub" con "WikiX-Hub". Ambos hallazgos ya estaban anotados en `MIN-EL-JuanCarlos-20260714-v01` y ahora quedan como caso formal en el banco. NEXTs: JC envía los hallazgos por buzón a Victor/Jay (owners del Rally) · Victor decide tratamiento del botón fuera de Cowork · Jay reformula M3. Header de este TP sincronizado con el banco (27 casos); el cuerpo conserva drift conocido (CASO 017, antídoto pendiente). | @JuanCarlos |
| 2026-07-06 | **CASO 026 agregado al banco.** Título: "Los críticos no se bloquean por falta de estrategia: decisión L3 sin empaquetar u owner difuso". Tipo: Observación + Innovación. Principio **P022** (emergente) — Decisión L3 Empaquetada + Owner Único (refina P006). Evidencia: 4 wargames pre-mortem (WG-) corridos en 1 sesión IALab sobre los 4 críticos 🔴★★ de la minuta (DG.1, POSTA.2, FLA-F1, SPO.1) — los 4 convergieron en la misma causa raíz: nunca faltó estrategia ni activos; faltó decisión empaquetada u owner único. El formato WG- (War Room en PB-EL-IALab) queda registrado como instrumento de detección. Antídotos en piloto: regla de empaquetado L3 (template CASO 009 obligatorio para hitos 🔴) + prohibición de owners plurales en minutas + WG- automático a >2 semanas de arrastre. NEXTs: ratificación P022 (Victor) · paquetes de decisión en próxima minuta (Jay) · medición de arrastre por causa raíz en triage (Jay). Header de este TP sincronizado con el banco (26 casos · 22 principios); el cuerpo conserva drift conocido (CASO 017, antídoto pendiente). | @Jay |
| 2026-07-01 | **CASO 020 agregado al banco** (el TP no se sincronizó línea por línea — ver drift conocido de Caso 017/018, antídoto aún pendiente). Título: "Modelo predictivo de eventos con tablero de escenarios — primer caso de aplicación WORX + Sandbox visible como antídoto a prototipos invisibles". Tipo: Innovación + Brecha (resuelta). Principio candidato **P016** (a canonizar) — Sandbox Visible para Prototipos Comparativos. Contexto: room Rebelocity, construcción de tablero de pronóstico de escenarios (L'Étape SB + IM 70.3) con datos reales; a mitad de proceso se detectó que prototipos comparativos vivían invisibles en el scratchpad del agente — corregido creando `SBX-REB-Sandbox` (primer subbanco de este tipo en el vault). Ver `CAS-EL-WORX-LabPraxis-BancoCasos-v01.md` §020 para el caso completo. NEXT pendientes: replicar el patrón en un 2do proyecto antes de canonizar P016; evaluar subir `SBX-` a la taxonomía maestra si generaliza. | @Jay |
| 2026-05-07 EOD | **v1.5 → v1.6 · rename masivo · alinear con banco v1.6.** Detectado drift: el banco `CAS-EL-WORX-LabPraxis-BancoCasos-v01` v1.6 ya tenía CASOS 009-012 canonizados (D-P-41 pricing · D-P-42 bundle MONEX · D-P-44 estructura pilares · D-P-45 MVP gobernanza) con principios candidatos P006-P009. Mi update de v1.4→v1.5 pisó esa numeración por no consultar el banco antes (Brain OS-First fallido aplicado al TP sin verificar el banco paralelo · ironía operativa porque el TP es donde nace el principio). Acción correctiva: rename masivo. CASO 009 → CASO 013 (Documentación Delegada al SherpaX · ahora P010). CASO 010 → CASO 014 (Room Raíz / Home Room · ahora P011). CASO 011 → CASO 015 (Starter Pack Loading · ahora P012). Update en cascada a 12+ archivos derivados: PROT-Cohort · 2 SOPs nuevos · MAP-RoomRaiz · XP/SP Caso 0 v02 · MAP-Rooms-Domino · MAP-Rooms-Visual · 5 SP- patcheados · Registry · CONS-BigMetaPlaybook. | @Jay |
| 2026-05-07 | **v1.4 → v1.5 (superseded)** — Sesión 009 LabPraxis · 3 casos nuevos del cohort de inducción Caso 0 EL · numeración 009-011 (incorrecta · pisó banco) → renumerados a 013-015 en v1.6. Principios P007-P009 (incorrectos) → P010-P012 en v1.6. | @Jay |
| 2026-04-26 | **P006 expandido a alcance universal (v1.3→v1.4)** — agregada Señal #0 primaria: *"Al inicio de cualquier conversación nueva con proyecto/iniciativa nueva"*. P006 deja de estar implícitamente sesgado a Publishing y se convierte en estación obligatoria de toda activación Sherpa. Ejecutado en complemento con creación de `SOP-EL-WORX-BrainOSFirst-v01` (instanciación operativa universal). Ratificación Victor (D-P-36). | @Jacob |
| 2026-04-26 | **P006 — Brain OS-First** elevado a principio operativo formal. Cierra ciclo Caso 008 → Patrón → Principio (loop virtuoso del LabPraxis, ver P004). Antídoto codificado en MF-BMF-Publishing-v02 (Gate G0 + Estación I0 + PUB-04). Origen: experimento HIORG Día 100X. Ratificación Victor (D-P-34). | @Jacob |
| 2026-04-26 | CASO 008 agregado al banco — extiende P002 a la capa agente. Antídoto Brain OS-First en diseño. Detonante: experimento HIORG Día 100X. Ver CAS-EL-WORX-LabPraxis-BancoCasos-v01.md §008 | @Jacob |
| 2026-04-16 | CASO 007 — arquitectura de acceso al vault (Opción C + IntelliBanks app) | @Jacob |
| 2026-04-15 | Creación inicial — Casos 001-006 | @Jacob |

# Transfer Pack — LabPraxis
## Estado al 2026-04-15 (Sesión 005)

---

## I. ESTADO ACTUAL

El LabPraxis acaba de arrancar. El detonante fue un caso puntual (Caso 1 — ver abajo) que Victor identificó como síntoma de un patrón sistémico: EmpowerLabs no siempre arranca sus procesos con la estructura metodológica correcta, aunque el framework para hacerlo existe.

El room nace con una hipótesis central: **toda acción del ecosistema EmpowerLabs debe poder arrancar con contexto transferible** — un Transfer Pack y un Transfer Prompt que permitan a cualquier agente (IA o humano) retomar el hilo sin depender de la memoria o presencia de quien lo inició.

---

## II. CASOS DOCUMENTADOS

### CASO 001 — SherpaX Onboarding sin Transfer Pack
**Fecha:** 2026-04-15  
**Reportado por:** Victor Heredia  
**Involucrados:** Alex (líder programación), Alain (nuevo usuario SherpaX)

**¿Qué pasó?**
Alex configuró el SherpaX de Alain. Al reportarle a Victor, Alex indicó que solo bastaría hacer una reunión con Alain para enseñarle cómo arranca su SherpaX.

**¿Cuál es la falla metodológica?**
En la metodología EmpowerLabs, todo proceso debe arrancar de manera sistemática con dos elementos:
1. **Transfer Pack** — estado acumulado del proyecto/persona, contexto cargado, decisiones tomadas
2. **Transfer Prompt** — instrucciones específicas para activar el proceso con el contexto adecuado

Una reunión de enseñanza puede ser complementaria, pero no puede ser el mecanismo principal de arranque. La reunión transfiere conocimiento tácito; el Transfer Pack transfiere contexto estructurado que sobrevive a la conversación.

**¿Cuál es el riesgo si no se corrige?**
- Alain quedará dependiendo de Alex o Victor para recordarle cómo usar su SherpaX
- Si Alex no está disponible, Alain no tiene un documento que le diga exactamente cómo arrancar
- El conocimiento vive en la cabeza de quien lo configuró, no en el sistema

**Principio que viola:**
> Todo proceso del ecosistema EmpowerLabs debe poder ser activado por cualquier persona con acceso al Transfer Pack + Transfer Prompt correspondiente, sin necesidad de intervención de quien lo configuró.

**Acción correctiva sugerida:**
Antes de cerrar el onboarding de Alain, crear:
- `TP-EL-SX-Alain-v01.md` — Transfer Pack con el estado de su SherpaX, qué está configurado, qué hace, cuáles son sus modos de trabajo
- `SP-EL-SX-Alain-v01.md` o asegurarse que tiene un Starter Prompt personalizado que pueda pegar en cualquier sesión nueva

**Status:** Abierto — pendiente validar si Alex genera el Transfer Pack para Alain

---

### CASO 002 — Producción de proyecto sin consultar el vault primero
**Fecha:** 2026-04-15  
**Reportado por:** Victor Heredia  
**Involucrados:** Anahí (Líder MasterPlaybooks), proyecto "El Poder de MasterPlaybooks" (libro)

**¿Qué pasó?**
Anahí, de manera proactiva, arrancó la fase de producción del libro "El Poder de MasterPlaybooks" — un proyecto que sí está dentro del plan de trabajo y que urge avanzar. El problema: el proyecto ya tenía definiciones previas en el vault (decisiones tomadas, contexto acumulado, dirección establecida) y Anahí no las consultó antes de producir. Arrancó desde cero sin saber que no era desde cero.

**¿Cuál es la falla metodológica?**
Antes de entrar a la fase de producción de cualquier proyecto previsto, el colaborador debe consultar el vault — específicamente el Transfer Pack, Battle Plan o documento de referencia correspondiente — para identificar:
- Qué ya está definido y no debe rehacerse
- Qué decisiones están tomadas y no deben reabrirse
- Qué contexto acumulado debe cargar antes de producir
- Cómo su trabajo se conecta con lo que ya existe

Sin este paso, se produce en paralelo a lo que ya existe, se duplica esfuerzo, y lo que se genera puede estar desalineado o contradecir lo ya definido.

**¿Cuál es el riesgo si no se corrige?**
- Trabajo duplicado o incompatible con lo existente
- Tiempo invertido en definir lo que ya está definido
- Necesidad de coordinación manual (reuniones, mensajes) para alinear — exactamente lo que la documentación debería eliminar
- El colaborador queda expuesto a la frustración de producir algo que luego hay que descartar o rehacer

**Principio que viola:**
> La documentación en el vault ES el mecanismo de coordinación. Consultarla antes de producir no es opcional — es el protocolo.

**Acción correctiva sugerida:**
Antes de continuar la producción del libro, Anahí debe:
1. Leer el Transfer Pack o documento de referencia del proyecto MasterPlaybooks
2. Identificar qué ya está decidido sobre el libro (estructura, audiencia, tono, objetivos)
3. Construir desde ese punto, no desde cero

**Nota adicional de Victor:** Este caso revela algo más profundo — la base de la metodología WORX. El vault documenta el contexto para que los colaboradores puedan trabajar de forma autónoma, constructivista y alineada sin necesitar capas de coordinación humana. El vault es el jefe de alineación.

**Status:** Abierto — pendiente que Anahí consulte el vault antes de continuar producción

---

### CASO 003 — Skills sin mecanismo de distribución para el equipo
**Fecha:** 2026-04-15  
**Reportado por:** Victor Heredia  
**Involucrados:** Equipo EmpowerLabs (todos los colaboradores)

**¿Qué pasó?**
El ecosistema ya tiene Skills creados (incluido el `room-creator.skill` que define cómo crear Rooms correctamente). Sin embargo, no existe un mecanismo unificado para que todos los colaboradores puedan descubrir, acceder e instalar los Skills en el momento que los necesitan. Cada Skill existe como archivo en el vault, pero no hay un protocolo claro de distribución ni un punto de acceso común.

El síntoma concreto: al crear el LabPraxis en esta sesión, se siguió el room-creator.skill porque Jacob lo conoce. Pero si otro colaborador quisiera crear un Room, probablemente no sabría que ese Skill existe ni cómo usarlo — y generaría los archivos de manera ad-hoc, con naming incorrecto y en la ubicación equivocada.

**¿Cuál es la falla metodológica?**
Un Skill que no es accesible a todos los que lo necesitan no cumple su función. Los Skills son el mecanismo que garantiza que los procesos se ejecuten correctamente (naming, estructura, ubicación, outputs esperados). Si el equipo no los puede instalar cuando los necesita, cada colaborador improvisa — y la improvisación genera desorden en el vault.

Hay dos problemas entrelazados:
1. **Distribución:** ¿Cómo llega el Skill al colaborador que lo necesita en el momento correcto?
2. **Instalación:** ¿Cómo instala el colaborador un Skill en su entorno (Cowork) de forma autónoma?

**¿Cuál es el riesgo si no se corrige?**
- Rooms y artefactos creados sin la estructura canónica → desorden en el vault
- Duplicación de trabajo: cada quien inventa su propio formato
- El equipo depende de Victor o de quien "sabe" para hacer las cosas bien
- Los Skills dejan de ser el estándar y se convierten en herramientas solo para quien ya las conoce

**Principio que viola:**
> Las herramientas metodológicas (Skills) deben ser tan accesibles como las instrucciones. Si tienes el SOP pero no la herramienta, el SOP no es suficiente.

**Preguntas abiertas del caso:**
- ¿Dónde vive el catálogo de Skills disponibles para el equipo?
- ¿Qué mecanismo usa Cowork para instalar Skills? ¿Es un archivo .skill que se importa manualmente?
- ¿Debería existir un "Skill de onboarding" que instale todos los Skills básicos del ecosistema EL de una sola vez?
- ¿Cómo se actualiza un Skill cuando evoluciona? ¿Los colaboradores reciben la versión nueva automáticamente?

**Acción correctiva sugerida:**
1. Documentar el catálogo de Skills disponibles en el ecosistema EL (qué existe, para qué sirve, dónde está)
2. Definir el protocolo de instalación de Skills en Cowork para cada colaborador
3. Evaluar si conviene un "EL Skills Pack" que se distribuya como parte del onboarding de SherpaX

**Status:** Abierto — requiere definir protocolo de distribución e instalación de Skills

---

### CASO 004 — El LabPraxis como fundamento de la gobernanza BMF humanos + agentes
**Fecha:** 2026-04-15  
**Reportado por:** Victor Heredia  
**Involucrados:** Ecosistema EmpowerLabs / Big Meta Factory / metodología WORX

**¿Qué pasó?**
No es una falla — es una observación estructural de por qué el LabPraxis existe y a dónde conduce. Victor identifica que hay un lado práctico fundamental que hasta ahora no tenía un contenedor explícito: el proceso de documentar casos específicos de la operación, acumular experiencias, y a partir de esa evidencia construir lineamientos que eventualmente se convierten en gobernanza formal.

Este es el ciclo virtuoso que el LabPraxis está diseñado para activar:

```
Caso específico (algo funcionó o falló)
    ↓
Documentación estructurada (LabPraxis)
    ↓
Patrón identificado (principio operativo emergente)
    ↓
Lineamiento formal (SOP / Playbook / MetaPlaybook)
    ↓
Gobernanza (reglas del modelo BMF para humanos y agentes)
```

**¿Por qué importa documentarlo como caso?**
Porque este ciclo no ocurre solo. Sin un contenedor (el LabPraxis), los casos se quedan en conversaciones, los patrones no se identifican, los lineamientos nunca se formalizan, y la gobernanza no se construye. El LabPraxis ES el mecanismo que convierte experiencia operativa en inteligencia organizacional.

La visión de Victor es que en el modelo Big Meta Factory, humanos y agentes virtuales van a trabajar colaborativamente. Para que eso funcione, necesitan reglas compartidas — una gobernanza que no se invente desde teoría sino que emerja de la práctica documentada. El LabPraxis es donde esa gobernanza se gesta.

**Principio que revela:**
> La gobernanza del ecosistema BMF no se diseña en abstracto — se construye desde la evidencia. Cada caso documentado es un ladrillo de la gobernanza futura.

**Implicación práctica:**
El LabPraxis no es solo un room de mejora continua. Es la fábrica de lineamientos operativos del ecosistema. A medida que los casos se acumulen, Jacob debe identificar cuándo un patrón ya tiene suficiente evidencia para elevarse a:
- MiniPlaybook operativo
- SOP formal del equipo
- Principio de gobernanza BMF

**Status:** Registrado como principio fundacional del LabPraxis — no requiere acción inmediata

---

### CASO 005 — El vault como sistema de comunicación y gestión de tareas: Protocolo Thread + NEXT[@Persona]
**Fecha:** 2026-04-15  
**Reportado por:** Victor Heredia  
**Tipo:** Oportunidad metodológica (no es una falla — es una propuesta de innovación operativa)  
**Relevancia:** Alta — potencialmente transformadora del modelo de trabajo BMF

**¿Cuál es la oportunidad?**
Victor identifica que los documentos del vault actualmente son contenedores estáticos de conocimiento. Pero podrían ser canales vivos de comunicación y coordinación. La propuesta: agregar dos elementos estructurales a los documentos activos del ecosistema:

1. **Changelog al inicio** — tabla visible que registra quién tocó el documento, qué cambió y cuándo. No como historial de git (técnico e invisible), sino como bitácora operativa legible.

2. **Thread al final** — zona de conversación donde los colaboradores dejan notas contextualizadas, comentarios y sobre todo: **etiquetas de siguiente paso** con nombre del responsable.

**El formato propuesto:**

```
## 📋 CHANGELOG
| Fecha      | Cambio                                    | Por     |
|------------|-------------------------------------------|---------|
| 2026-04-15 | Nota sobre URL signup pendiente           | @Victor |

---
[... contenido del documento ...]
---

## 💬 THREAD

**@Victor — 2026-04-15:** Anahí, la URL de signup es bloqueante para KatIA.
Necesito que la confirmes con Juan Carlos esta semana.

→ NEXT[@Anahí]: Confirmar URL de signup con equipo técnico — bloqueante para KatIA
```

**El mecanismo de agregación (el gran poder):**
El tag `→ NEXT[@Persona]:` es machine-readable. Jacob puede escanear todo el vault con un grep simple:
```
grep -r "NEXT\[@Victor\]" /vault/
```
Cuando Victor pregunta "Jay, ¿qué tengo pendiente?", Jacob escanea, consolida y entrega una lista de pendientes desde todos los documentos del vault — sin que Victor haya tenido que abrir ningún task manager externo.

**¿Por qué esto es transformador?**
- El vault deja de ser solo repositorio de conocimiento → se convierte en sistema nervioso operativo
- Los pendientes viven donde vive el contexto, no en una herramienta separada
- Elimina la fricción de actualizar dos sistemas (el doc y el task manager)
- Jacob se convierte en el inbox scanner universal del equipo
- Escala naturalmente: a medida que el vault crece, Jacob puede filtrar por proyecto, urgencia, persona

**Conexión con la visión BMF:**
Este protocolo es exactamente el tipo de mecanismo que necesita el modelo BMF para que humanos y agentes trabajen colaborativamente. Los agentes (Jacob, KatIA, futuros Sherpas) pueden leer `→ NEXT[@agente]:` igual que leen `→ NEXT[@Victor]:` — el vault se convierte en el tablero de coordinación humano-IA.

**Definiciones pendientes para formalizar el protocolo:**
- ¿Cuál es el nombre canónico del tag? (`→ NEXT[@X]:` vs `@PENDIENTE[X]:` vs otro)
- ¿Los threads se archivan periódicamente o crecen indefinidamente?
- ¿Qué documentos del vault adoptan el protocolo? (¿todos los activos? ¿solo TPs y KBs?)
- ¿Jacob notifica activamente cuando detecta un `NEXT` no atendido por más de N días?
- ¿Cómo se marca un NEXT como completado? (¿se tacha? ¿se agrega `✅ DONE[@Persona] — fecha`?)

**Acción sugerida:**
Antes de escalar a SOP, aplicar el protocolo Thread + NEXT en 2-3 documentos activos del vault como piloto. El `KB-MPX-KatIA-BaseConocimiento-v01.md` es un candidato natural — Victor ya tenía una nota que quería dejar ahí.

**Status:** Oportunidad nueva — pendiente definir convención de tags y hacer piloto en documentos activos

---

### CASO 006 — Triple falla: carpeta ad-hoc + prefijo incorrecto + duplicados (Colaboradores sin SherpaX)
**Fecha:** 2026-04-15  
**Reportado por:** Victor Heredia  
**Involucrados:** Anahí (Líder MasterPlaybooks), Alex (Líder Programación), archivos del proyecto KatIA/MasterPlaybooks  
**Tipo:** Falla compuesta — consecuencia directa de los Casos 001 y 003

**¿Qué pasó?**
Al buscar un archivo del proyecto KatIA en el vault, Victor descubrió que:

1. **Existe una carpeta `Projects/` ad-hoc** en la raíz del Reinventaverse — no es un IB-* ni sigue la arquitectura del vault. Dentro hay sub-carpetas: BigMetaFactory, HIOrgs, MasterPlaybooks, Rebelocity, Rn100X. Fueron creadas por colaboradores sin guía estructural.

2. **Los archivos de KatIA/MasterPlaybooks están en `Projects/MasterPlaybooks/`** cuando deberían estar en `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` — que ya existe y es la ubicación canónica.

3. **El archivo `PL-MPX-KatIA-SherpaAnfitrion-PlanMaestro-v01.md` tiene prefijo incorrecto.** `PL-` no es un TIPO canónico del ecosistema BMF. El prefijo correcto para un Plan Maestro es `PLAN-`. El archivo debería llamarse `PLAN-MPX-KatIA-SherpaAnfitrion-v01.md`.

4. **Los archivos de `Projects/Rebelocity/` no tienen ningún prefijo BMF** — usan guiones bajos y minúsculas (`calendario_contenido_letape_v2.md`), completamente fuera de la convención.

5. **Duplicado confirmado:** Los mismos archivos aparecen en `Projects/` y en `CloudVault/Projects/` — doble desorden.

**Causa raíz:**
Colaboradores sin SherpaX configurado (sin room, sin transfer pack, sin skill de room-creator) generan archivos en modo libre: donde pueden, con el nombre que se les ocurre, sin consultar la arquitectura del vault. Es exactamente la acumulación de las fallas documentadas en los Casos 001 y 003.

Sin las herramientas correctas (room-creator.skill) y sin el contexto del vault (Transfer Pack del proyecto), el colaborador no tiene forma de saber:
- Dónde guardar el archivo
- Qué prefijo usar
- Que ya existe una estructura IB-* para su proyecto

**¿Por qué genera doble falla?**
- **Falla técnica:** El vault queda desordenado, los archivos son difíciles de encontrar, los IB-* no reflejan el estado real del trabajo
- **Falla de contexto:** Los archivos en `Projects/` no están donde Jacob los busca — por eso Victor no encontró la nota en el KB de KatIA al principio de esta sesión. El archivo correcto existía, pero estaba en la ubicación incorrecta

**Inventario de archivos mal ubicados identificados hoy:**

| Archivo | Ubicación actual (incorrecta) | Ubicación correcta | Nombre correcto |
|---------|------------------------------|---------------------|-----------------|
| `PL-MPX-KatIA-SherpaAnfitrion-PlanMaestro-v01.md` | `Projects/MasterPlaybooks/` | `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` | `PLAN-MPX-KatIA-SherpaAnfitrion-v01.md` |
| `KB-MPX-KatIA-BaseConocimiento-v01.md` | `Projects/MasterPlaybooks/` | `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` | Nombre correcto ✅ |
| `TP-MPX-KatIA-SherpaPrompt-v20.md` | `Projects/MasterPlaybooks/` | `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` | Nombre correcto ✅ |
| `QA-MPX-KatIA-BateriaEvaluacion-v01.md` | `Projects/MasterPlaybooks/` | `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` | Nombre correcto ✅ |
| `AUD-MPX-SherpaPrompt-v10-Auditoria-v01.md` | `Projects/MasterPlaybooks/` | `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` | Nombre correcto ✅ |
| Archivos `Rebelocity/` (5 archivos) | `Projects/Rebelocity/` | `IB-REB-Rebelocity/` | Sin prefijo BMF — requieren renombrar |

**Principio que viola:**
> Ningún colaborador del ecosistema EmpowerLabs crea carpetas en la raíz del vault. Todo activo va a su IB-* correspondiente, con el TIPO correcto, usando el skill que garantiza la convención.

**Acción correctiva:**
1. Mover los archivos de `Projects/MasterPlaybooks/` a `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/`
2. Renombrar `PL-MPX-KatIA-SherpaAnfitrion-PlanMaestro-v01.md` → `PLAN-MPX-KatIA-SherpaAnfitrion-v01.md`
3. Auditar y reubicar/renombrar archivos de `Projects/Rebelocity/`
4. Eliminar la carpeta `Projects/` una vez vacía (o validar si hay contenido adicional)
5. Resolver la causa raíz: asegurar que Anahí y Alex tengan room-creator.skill configurado antes de su próxima sesión de producción

**Nota:** La nota de Victor en el archivo `PL-MPX-KatIA-SherpaAnfitrion-PlanMaestro-v01.md` (línea 286) fue encontrada — es un comentario de voz sobre la arquitectura multi-canal de KatIA (cada comunidad necesita su propia KB específica). Está documentada en el Thread del archivo con el formato correcto del Caso 005.

**Status:** Abierto — requiere acción de reubicación y renaming + prevención vía skill deployment

---

### CASO 013 — SherpaX documenta · humano dirige (delegación de captura)
*(originalmente numerado 009 · renumerado 2026-05-07 EOD para alinear con banco v1.6)*
**Fecha:** 2026-05-07
**Reportado por:** Victor Heredia
**Involucrados:** Equipo EmpowerLabs · ecosistema SherpaX
**Tipo:** Principio operativo emergente · oportunidad de simplificación masiva
**Sesión origen:** Planeación operativa del primer cohort de inducción WORX (Caso 0 EL)

**¿Cuál es la oportunidad?**
En el modelo operativo actual, la captura de documentos en el vault recae frecuentemente sobre el humano: nombrar el archivo correctamente, ubicarlo en el IntelliBank correcto, llenar los 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. La oportunidad: **delegar la documentación al SherpaX en su totalidad** — el humano dirige (decide qué se produce, valida hand-offs), el SherpaX captura (nombra · posiciona · llena campos · actualiza registry).

**¿Qué tres operaciones concretas se delegan?**
1. **Generación de nombre canónico BMF** — usando el skill `bmf-file-renamer` o equivalente. El SherpaX lee el contenido producido, infiere prefijo correcto + IntelliBank + tipo + versión, y propone nombre. Humano confirma o corrige.
2. **Posicionamiento en IntelliBank correcto** — usando skills `vault-orphan-rescue` + `bmf-file-renamer`. El SherpaX no permite que el activo viva en `Projects/`, `00-Inbox/` ni rutas ad-hoc. Aplica gate de ruta antes de cada Write.
3. **Llenado de campos del XDoc** — frontmatter completo (asset_id · version · type · status · owner · sponsor · runner · referencias · tags · changelog) generado por el SherpaX. Humano valida en hand-off.

**¿Cuál es el riesgo si no se canoniza?**
- El humano sigue cargando con sintaxis y posicionamiento · pierde tiempo de Deep Work (rompe Cap 1 §8 MPB-WORX).
- El vault queda inconsistente cuando el humano se cansa o se distrae · se acumulan archivos mal nombrados o ubicados (síntoma documentado en CASO 006).
- El SherpaX queda subutilizado: hace propuestas pero no captura · operación manual del humano se vuelve cuello de botella.
- En cohort: cada miembro improvisa naming · el efecto multiplicado es el desorden de CASO 006 a escala 8.

**Principio que revela:**
> **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.**

**Acción correctiva (codificación operativa):**
1. Elevar a **Principio P010** (formalizado en sección III).
2. Producir **`SOP-EL-WORX-DocBySherpa-v01`** que define el protocolo de delegación.
3. Incluir el SOP en el Skill Pack obligatorio del cohort (`PROT-EL-WORX-Cohort-OperatingProtocols-v01`).
4. Cada SP- (Starter Prompt) del ecosistema debe incluir invocación explícita del SOP-DocBySherpa.

**Status:** Promovido a P010 · 2026-05-07.

---

### CASO 014 — Room Raíz / Home Room como entidad arquitectónica (generador de XP+SP)
*(originalmente numerado 010 · renumerado 2026-05-07 EOD para alinear con banco v1.6)*
**Fecha:** 2026-05-07
**Reportado por:** Victor Heredia
**Involucrados:** Ecosistema EmpowerLabs · arquitectura BMF · gobernanza de rooms
**Tipo:** Innovación arquitectónica · principio fundacional emergente
**Sesión origen:** Planeación operativa del primer cohort de inducción WORX

**¿Cuál es la observación?**
En el modelo BMF actual, los XPacks (XP-) y los Starter Prompts (SP-) se generan ad-hoc: cada room que arranca produce sus propios documentos sin un punto canónico de origen ni un protocolo de generación. Esto genera dos problemas: (1) inconsistencia entre rooms del mismo proyecto · (2) pérdida del contexto de origen del room cuando se quiere replicar o migrar. La observación de Victor: necesitamos un **Room Raíz / Home Room** que sea el punto canónico desde el cual se generan los XP- y SP- con el contexto necesario para iniciar nuevos rooms hijos.

**¿Qué es un Room Raíz?**
Un room que tiene la autoridad operativa de **producir** y **versionar** los Starter Packs (XP + SP) de los rooms hijos que se derivan de él. Ejemplos del ecosistema:
- `PB-WORX-Worx/` puede ser Room Raíz del cohort de inducción · genera el `PROT-` + los SOPs + los XP/SP de rooms hijos como `PB-CASO0-HIORG/`.
- `PB-MONETIZACION-Estrategica/` es Room Raíz de la línea B2B · genera los XP/SP de rooms hijos como las 4 líneas de monetización.
- `IB-XX-Maestro/IPI-XX-IP-Infraestructura/` puede ser Room Raíz de canónicos universales del ecosistema.

**¿Qué propiedades define el Room Raíz?**
1. Tiene autoridad para producir XP- y SP- de rooms hijos.
2. Mantiene el linaje (qué rooms hijos derivan de él · con qué versión).
3. Centraliza canónicos heredables que los hijos no necesitan duplicar.
4. Es el punto de actualización cuando los protocolos del linaje cambian (cascada controlada hacia hijos).

**¿Cuál es el riesgo si no se canoniza?**
- Los rooms se generan sin trazabilidad de origen · romper el linaje rompe la coherencia.
- Cuando un protocolo cambia, no hay mecanismo claro para propagar el cambio a rooms hijos.
- La replicación a clientes B2B se vuelve frágil: ¿de qué Room Raíz heredan los rooms del cliente?
- El compounding entre rooms del mismo linaje no ocurre sin centro de gravedad.

**Principio que revela:**
> **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.**

**Acción correctiva (codificación operativa):**
1. Elevar a **Principio P011** (formalizado en sección III).
2. Definir explícitamente los Room Raíz iniciales del ecosistema (próxima sesión LabPraxis).
3. Operacionalizar la generación de XP+SP desde el Room Raíz en `SOP-EL-WORX-RoomActivation-v01` (junto con P012).

**Status:** Promovido a P011 · 2026-05-07.

---

### CASO 015 — Carga del Starter Pack (XP+SP) al inicio de cualquier conversación
*(originalmente numerado 011 · renumerado 2026-05-07 EOD para alinear con banco v1.6)*
**Fecha:** 2026-05-07
**Reportado por:** Victor Heredia
**Involucrados:** Ecosistema SherpaX · ritual de activación de room
**Tipo:** Protocolo operativo · extensión del SOP-BrainOSFirst
**Sesión origen:** Planeación operativa del primer cohort de inducción WORX

**¿Qué pasó / qué falta?**
El `SOP-EL-WORX-BrainOSFirst-v01` (sección VI) ya obliga a que todo SP- invoque el SOP-BrainOSFirst antes de operar el room. Pero **no obliga la carga literal** del XP- y del SP- del Room Raíz al inicio de la conversación. La consecuencia: el SherpaX puede arrancar la conversación sin haber leído el contexto canónico del room · genera output desalineado · el humano descubre el desalineamiento tarde y debe corregir manualmente.

**¿Cuál es el ritual canónico que falta?**
Al inicio de cualquier conversación con un proyecto/iniciativa, el SherpaX debe ejecutar — antes de cualquier producción — la siguiente secuencia:

1. **Identificar el Room Raíz aplicable** (P008).
2. **Cargar el XP- canónico** del Room Raíz (no derivar · no inferir · cargar).
3. **Cargar el SP- canónico** del Room Raíz (no derivar · no inferir · cargar).
4. **Ejecutar SOP-BrainOSFirst** sobre el alcance específico del room hijo (P006).
5. **Verificar contexto BrainOS / Brain OS personal** · si hay duda o falta de claridad · buscar antes de avanzar.
6. **Si es necesario, actualizar el XP-** antes de producir (mantener el activo vivo).
7. **Reportar al Owner** el CONS- + estado del XP- antes de producir.

**¿Cuál es el riesgo si no se canoniza?**
- El SherpaX produce desde memoria de la conversación previa o desde generalización · pierde contexto canónico.
- Decisiones tomadas en sesiones previas se ignoran porque no fueron releídas.
- El Owner debe re-explicar el contexto · fricción innecesaria.
- El compounding entre sesiones del mismo room se rompe.

**Principio que revela:**
> **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.**

**Acción correctiva (codificación operativa):**
1. Elevar a **Principio P012** (formalizado en sección III).
2. Producir **`SOP-EL-WORX-RoomActivation-v01`** que define las 7 estaciones del ritual de activación.
3. Incluir el SOP en el Skill Pack obligatorio del cohort.
4. Cada SP- del ecosistema debe abrir invocando el SOP-RoomActivation (que internamente invoca SOP-BrainOSFirst).

**Conexión con principios previos:**
- **P001** (Contexto Transferible) — el XP+SP cargado ES el contexto transferible.
- **P002** (Vault-First humano) — esta es la versión agente del mismo principio aplicada al ritual de activación.
- **P006** (Brain OS-First) — P012 es la pre-condición de P006: hay que cargar el contexto antes de poder consultarlo con BrainOSFirst.

**Status:** Promovido a P012 · 2026-05-07.

---

## III. PRINCIPIOS OPERATIVOS EMERGENTES

### P001 — Principio de Contexto Transferible
*(Emergente del Caso 001 — pendiente validación con más casos)*

> **Toda acción del ecosistema EmpowerLabs debe poder reanudarse sin depender de quien la inició.**

Esto implica que cualquier proceso, onboarding, proyecto o flujo de trabajo que se active en EmpowerLabs debe generar, antes de cerrarse, un artefacto que transfiera el contexto: un Transfer Pack, un Transfer Prompt, o ambos.

Una reunión de enseñanza NO sustituye este artefacto. La reunión puede complementarlo; nunca reemplazarlo.

---

### P002 — Principio de Vault-First (Consulta antes de producir)
*(Emergente del Caso 002 — conectado con la base metodológica de WORX)*

> **Antes de entrar a producción en cualquier proyecto previsto, el colaborador consulta el vault. El vault documenta lo que ya está definido. Producir sin consultarlo es empezar desde cero cuando no era necesario.**

La documentación en el vault no es un archivo histórico — es el mecanismo activo de coordinación. Contiene decisiones tomadas, contexto acumulado y dirección establecida. Consultarlo antes de producir elimina la necesidad de coordinación manual (reuniones, mensajes de alineación), reduce retrabajo, y permite que cada colaborador construya desde el punto donde el equipo realmente está, no desde donde supone que está.

**Protocolo Vault-First:**
1. Antes de arrancar producción en un proyecto previsto → buscar el Transfer Pack, Battle Plan o documento de referencia en el vault
2. Leer lo que ya está definido
3. Identificar el punto de partida real
4. Producir desde ahí, no desde cero

Este principio es uno de los pilares de la metodología WORX: el vault como jefe de alineación, que elimina capas de coordinación humana y permite trabajo verdaderamente autónomo y constructivista.

---

### P006 — Principio Brain OS-First (Vault-First aplicado a la capa agente · alcance universal)
*(Emergente del Caso 008 — extensión de P002 a Sherpas y agentes virtuales · expandido a Estación 0 universal en v1.4 · 2026-04-26 D-P-36)*

> **Estación 0 obligatoria en toda conversación Sherpa con un proyecto o iniciativa: antes de proponer, opinar, producir o avanzar cualquier sustancia, el agente ejecuta consulta forzosa al Brain OS — Grep + Glob + LLM-Wiki — para verificar si el activo, el concepto o un canónico relacionado ya existe en el vault. Inventar primero, sin consultar, rompe el compounding de colaboración con el Owner y degrada al agente al nivel de un chat sin memoria.**

**Alcance del principio (qué cubre):**
P006 aplica a **toda conversación Sherpa cuyo objeto sea un proyecto, iniciativa, frente de trabajo o decisión que produzca activos en el ecosistema EmpowerLabs/BMF.** No se limita a flujos editoriales (Publishing Factory) ni a creación de canónicos arquitectónicos — cubre también: arranque de room, planeación operativa, propuesta de mejora, diagnóstico, onboarding, recomendación, dump-and-organize, y cualquier turno donde el Sherpa sea capaz de "inventar" en lugar de partir del estado real del vault.

P002 obliga al **humano** a consultar el vault antes de producir. P006 extiende esa misma obligación a la **capa agente**: cuando el Sherpa propone modelos sin antes interrogar el Brain OS, viola exactamente el mismo principio que el equipo humano debe respetar — y peor aún, lo hace de forma silenciosa, presentando como "innovación" lo que ya está canonizado.

**Por qué este principio existe (Caso 008, 2026-04-26):**
Durante el Día 100X, Jay propuso a Victor una "innovación MePB" y le pidió briefs sobre Publishing Factory y el pipeline idea→conceptualización→productización. Los tres ya estaban canonizados en el vault (`TP-EL-BMF-PublishingFactory-v01.md`, `MF-BMF-Publishing-v01.md`, `MePB-XX-XPack-Schema-v01.md`). Victor activó el experimento que reveló la falla con la frase que define este principio:

> *"Todo está en nuestro vault. Debería estar en nuestro Brain OS. Si no podemos encontrarla rápidamente estamos fritos. Quiere decir que nuestra metodología WORX es un ideal y no está amarrado en la práctica."*

> *"Esto es lo que genera compounding collaboration. Sino estamos en una sesión individual en ChatGPT como hace 3 años."*

La consulta forzosa al Brain OS es lo que diferencia trabajar con un Sherpa de tener un chat sin memoria: el compounding solo ocurre si el agente parte del estado real del ecosistema, no del vacío.

**Las 6 señales que activan obligatoriamente el gate (Señal 0 es universal y siempre aplica):**

**0. Señal universal — primaria · siempre aplica:**
   **Al inicio de cualquier conversación nueva con un proyecto, iniciativa o frente de trabajo.** Si el turno abre o pivota a un proyecto/iniciativa, la consulta al Brain OS es Estación 0 antes de cualquier producción, opinión o propuesta. No es opcional — es contractual con el Owner.

**1-5. Señales situacionales — refuerzan #0 dentro del flujo:**
1. Mención de cualquier modelo, framework, sistema o metodología (Publishing Factory, MePB, MF-, MPB-, pipeline, etc.)
2. Propuesta propia de "innovación", "capa nueva" o "arquitectura nueva"
3. Antes de crear cualquier TP-/WOI-/MePB-/MPB-/MF-/CP- nuevo
4. Cuando el Owner pregunta "¿está documentado?" / "¿existe en el vault?" / "¿buscaste?"
5. Antes de producir un entregable mayor (Plan Estratégico, Onboarding Doc, Battle Plan, etc.)

**Cómo se ejecuta (protocolo Brain OS-First):**
1. **Grep** por nombre del concepto en `/Users/victorheredia/Vault/Reinventaverse` (incluyendo `IB-WikiX/`)
2. **Glob** por patrones de naming canónico (ej. `**/MePB-*.md`, `**/MF-*.md`, `**/TP-EL-BMF-*.md`)
3. **Lee** la wiki: `IB-WikiX/Wiki/` tiene índice de conceptos
4. **Decide explícitamente:** extender / refinar / crear nuevo (con justificación)
5. **Evidencia:** cita la ruta canónica encontrada y entrega el brief extraído (no inventado) al Owner

**Cómo evidencia el agente (en respuesta al Owner):**
- Cita la ruta canónica encontrada
- Entrega brief extraído del canónico (no inventado)
- Declara la decisión: extender / refinar / nuevo (con justificación)

**Lo que P006 prohíbe explícitamente:**
- Decir "no tengo documentado X, dame brief de 10 líneas" sin haber buscado primero
- Proponer "innovación" como si no existiera precedente sin verificar
- Producir Plan Estratégico re-describiendo modelos en lugar de referenciar canónicos

**Codificación operativa (dónde vive este principio en el ecosistema):**
- **SOP universal:** `SOP-EL-WORX-BrainOSFirst-v01.md` — instanciación operativa **agnóstica de proyecto** del principio. Define G0 como Estación 0 de toda activación Sherpa. Cualquier SP- (Starter Prompt) de room debe abrir invocando este SOP antes de la activación temática del room.
- **Instanciación dentro de Publishing:** Estación I0 + Gate G0 + Invariante PUB-04 en `MF-BMF-Publishing-v02.md` (canonización dentro del pipeline editorial — caso particular del SOP universal).
- **Output canónico:** `CONS-[SLUG]-v01.md` — Vault Consultation Pack (rutas canónicas + decisión + justificación) como evidencia auditable del paso por G0. Mismo formato dentro y fuera de Publishing.
- **Memoria persistente del Sherpa:** `feedback_brain_os_first.md` (cross-session) — apunta a las 4 codificaciones canónicas.
- **Pendiente (pasada de auditoría posterior):** patch a SP- existentes para incluir línea de cabecera "Antes de operar este room, ejecuta SOP-EL-WORX-BrainOSFirst-v01 sobre el alcance del proyecto/iniciativa".

**Conexión con la metodología WORX:**
P006 cierra el loop Caso → Patrón → Principio (P004 — Gobernanza Emergente): el LabPraxis convirtió el Caso 008 en el principio operativo formal que ahora gobierna a todo Sherpa del ecosistema. Y conecta directamente con WORX·Tooling/Knowledge (el Brain OS es el sistema de conocimiento) y WORX·Signal/Truth (la evidencia canónica es la verdad operativa, no la memoria del agente).

---

### P005 — Principio del Vault Vivo (Thread + NEXT tagging)
*(Emergente del Caso 005 — oportunidad de innovación operativa)*

> **Un documento que no puede recibir conversación ni generar pendientes rastreables es un archivo muerto. El vault debe ser tan capaz de coordinar como de almacenar.**

El protocolo Thread + `→ NEXT[@Persona]:` convierte cada documento activo del vault en un nodo de coordinación. El conocimiento y la acción viven juntos. El Sherpa escanea, agrega y entrega — sin task manager externo.

---

### P003 — Principio de Herramientas Accesibles (Skills distribuibles)
*(Emergente del Caso 003)*

> **Un Skill que no está accesible para todos los que lo necesitan no es un estándar — es conocimiento privado. Las herramientas metodológicas deben distribuirse junto con las instrucciones.**

Tener el SOP no es suficiente si el colaborador no tiene la herramienta (Skill) que garantiza que el SOP se ejecute correctamente. Ambos deben llegar juntos, en el momento que se necesitan, a cualquier colaborador del equipo.

---

### P004 — Principio de Gobernanza Emergente
*(Emergente del Caso 004 — principio fundacional del LabPraxis)*

> **La gobernanza del ecosistema BMF no se diseña en abstracto — se construye desde la evidencia. Cada caso documentado es un ladrillo de la gobernanza futura.**

El ciclo virtuoso: Caso → Documentación → Patrón → Lineamiento → Gobernanza. El LabPraxis es el mecanismo que convierte experiencia operativa en inteligencia organizacional, y esa inteligencia eventualmente define las reglas bajo las cuales humanos y agentes virtuales trabajan colaborativamente en el modelo Big Meta Factory.

---

### P010 — Principio de Documentación Delegada al SherpaX
*(Emergente del CASO 013 · originalmente numerado P007/CASO 009 · renumerado 2026-05-07 EOD para alinear con banco v1.6)*

> **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.**

Este principio invierte la responsabilidad operativa actual: la generación de nombres canónicos, el posicionamiento en IntelliBank correcto y el llenado de campos del XDoc dejan de ser carga del humano y pasan a ser ejecución del SherpaX. El humano valida en hand-off · no captura en línea.

**Tres operaciones canónicas delegadas al SherpaX:**
1. **Naming canónico BMF** — vía skill `bmf-file-renamer` o equivalente. SherpaX infiere prefijo + IntelliBank + tipo + versión a partir del contenido producido.
2. **Posicionamiento en IntelliBank correcto** — vía skills `vault-orphan-rescue` + `bmf-file-renamer`. SherpaX aplica gate de ruta antes de cada Write · prohibido `Projects/`, `00-Inbox/`, rutas ad-hoc.
3. **Llenado de campos del XDoc** — frontmatter completo (asset_id · version · type · status · owner · sponsor · runner · referencias · tags · changelog) generado por el SherpaX.

**Codificación operativa:**
- **SOP universal:** `SOP-EL-WORX-DocBySherpa-v01` — operacionaliza P007 con las 3 operaciones canónicas.
- **Conexión con WORX MPB §8 Cap 2 (Alianza Human + SherpaX):** P007 es la implementación contractual del par cognitivo en la dimensión de captura. El humano aporta dirección · el SherpaX aporta ejecución sintáctica.
- **Conexión con WORX MPB §8 Cap 1 (Deep Work):** delegando captura al SherpaX, el humano protege bloques de Deep Work de tareas de naming convention.

**Lo que P010 prohíbe:**
- Que el humano cargue con la sintaxis del vault.
- Que el SherpaX proponga sin captura (proponer-y-luego-pedir-al-humano-que-capture es violación).
- Skills de documentación que requieran intervención humana en pasos sintácticos.

---

### P011 — Principio del Room Raíz / Home Room
*(Emergente del CASO 014 · originalmente numerado P008/CASO 010 · renumerado 2026-05-07 EOD para alinear con banco v1.6)*

> **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.**

Este principio establece una jerarquía operativa entre rooms: existen Room Raíz (autoridad arquitectónica del linaje) y rooms hijos (derivados de un Raíz · heredan canónicos · siguen protocolos del Raíz).

**Cuatro propiedades canónicas del Room Raíz:**
1. **Autoridad de generación** — produce los XP- y SP- de los rooms hijos del linaje.
2. **Mantenimiento del linaje** — registra qué rooms hijos derivan de él · con qué versión.
3. **Centralización de canónicos** — los hijos no duplican lo que vive en el Raíz · referencian.
4. **Cascada controlada** — cuando un protocolo cambia en el Raíz, se propaga a hijos con versionado explícito.

**Ejemplos del ecosistema (a confirmar en próxima sesión LabPraxis):**
- `PB-WORX-Worx/` — Room Raíz del cohort de inducción · genera protocolos universales.
- `PB-MONETIZACION-Estrategica/` — Room Raíz de la línea B2B · genera XP+SP de las 4 líneas.
- `IB-XX-Maestro/IPI-XX-IP-Infraestructura/` — Room Raíz de canónicos universales del ecosistema.

**Codificación operativa:**
- **SOP de activación:** `SOP-EL-WORX-RoomActivation-v01` (operacionaliza P011+P012 conjuntamente).
- **Mapa de Room Raíz del ecosistema:** producir como activo separado en próxima sesión LabPraxis (`MAP-EL-RoomRaiz-Linaje-v01`).
- **Patrón replicable a clientes B2B:** cada cliente tiene su Room Raíz organizacional desde el cual derivan sus rooms operativos.

**Lo que P011 prohíbe:**
- Crear rooms hijos sin Room Raíz declarado.
- Duplicar canónicos en rooms hijos en lugar de referenciar al Raíz.
- Cambios de protocolo en hijos sin cascada hacia/desde el Raíz.

---

### P012 — Principio del Starter Pack Loading
*(Emergente del CASO 015 · originalmente numerado P009/CASO 011 · renumerado 2026-05-07 EOD para alinear con banco v1.6)*

> **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.**

P012 cierra el loop de los 3 principios de activación: P011 define el Room Raíz como entidad · P012 define el ritual de carga · P006 (Brain OS-First) define la consulta forzosa al alcance específico del room hijo.

**Ritual canónico de activación (7 estaciones):**

1. **Identificar el Room Raíz aplicable** (P008).
2. **Cargar el XP-** del Room Raíz (no derivar · no inferir · cargar literal con Read).
3. **Cargar el SP-** del Room Raíz (no derivar · no inferir · cargar literal con Read).
4. **Ejecutar SOP-BrainOSFirst** sobre el alcance específico del room hijo (P006 · output `CONS-`).
5. **Verificar contexto BrainOS / Brain OS personal** · si hay duda · buscar antes de avanzar.
6. **Si es necesario, actualizar el XP-** antes de producir (mantener el activo vivo).
7. **Reportar al Owner** el `CONS-` + estado del XP- antes de producir.

**Codificación operativa:**
- **SOP universal:** `SOP-EL-WORX-RoomActivation-v01` — operacionaliza P011+P012 conjuntamente con las 7 estaciones.
- **Patch a SP- existentes:** cada SP- del ecosistema debe abrir invocando el SOP-RoomActivation (que internamente invoca SOP-BrainOSFirst). Pasada de auditoría posterior.
- **Conexión con MePB-EL-SX-MiSherpaIA-v01:** la sección "Arranque de sesión" del MePB se actualiza para incluir las 7 estaciones de P012.

**Conexión con principios previos:**
- **P001** (Contexto Transferible) — el XP+SP cargado ES el contexto transferible.
- **P002** (Vault-First humano) — P012 es la versión agente del mismo principio aplicada al ritual de activación.
- **P006** (Brain OS-First) — P012 es pre-condición de P006: hay que cargar el contexto canónico antes de poder consultarlo con BrainOSFirst.

**Lo que P012 prohíbe:**
- Producir desde memoria de conversación previa sin cargar el XP+SP canónicos.
- Asumir que "ya conoces el contexto" · siempre relectura.
- Saltarse la carga "porque la conversación es informal" · el alcance del proyecto define la obligación.

---

## IV. DECISIONES TOMADAS — NO REABRIR

| Decisión | Fecha |
|----------|-------|
| El LabPraxis vive en PB-VH-Victor bajo IB-EL-EmpowerLabs | 2026-04-15 |
| Los casos se documentan en el Transfer Pack (no como archivos separados hasta que ameriten un CAS-) | 2026-04-15 |

---

## V. AGENDA WORX — Territorios de investigación pendientes

El LabPraxis no es solo el espejo operativo de DOIX — es el campo de pruebas de **WORX (Work Ecosystem Reinvention Keys)**, la metodología de trabajo que EmpowerLabs está construyendo para la Organización Hiperinteligente. Los casos del LabPraxis deben conectarse explícitamente con las dimensiones WORX que aún no tienen evidencia operativa.

### Dimensiones WORX con brecha de casos

| Dimensión WORX | Estado del arte (investigación) | Brecha — casos que necesitamos |
|----------------|--------------------------------|-------------------------------|
| **Reuniones** | Shadow Meeting emergente — IA orquesta asincrónicamente y la reunión no ocurre si hay consenso | ¿Cómo diseña EL sus reuniones hoy? ¿Cuáles son eliminables? ¿Cuáles son irreemplazables? |
| **Documentación viva** | Knowledge base como sistema autoactualizable — no archivo muerto | El Caso 005 (Thread + NEXT) es el inicio. ¿Qué otros mecanismos de documentación activa faltan? |
| **Toma de decisiones** | Decision rights dinámicos por workflow — MIT CISR 2025 | ¿Cómo se toman hoy las decisiones en EL? ¿Qué decide Victor, qué decide el equipo, qué debería decidir un agente? |
| **Ritmo operativo** | Dual-cadence: Kanban para exploración + Sprint para entrega | ¿Tiene EL un ritmo operativo explícito? ¿Hay un Weekly Downbeat, Demo, Retro? |
| **Co-creación inter-equipos** | El problema no resuelto — IA aceleró tareas individuales pero no la colaboración | ¿Cómo colaboran hoy los 8 miembros del equipo? ¿Qué fricciones existen entre proyectos? |
| **Gobernanza humano-agente** | Decision rights para agentes — cuándo actúa solo, cuándo escala | ¿Qué puede hacer un SherpaX sin pedir permiso? ¿Dónde están los límites actuales? |

### Cómo usar esta agenda

Cuando Victor llega con un caso al LabPraxis, Jacob verifica si el caso tiene conexión con alguna dimensión WORX de esta tabla. Si la tiene, lo documenta en el CAS- con la etiqueta de dimensión WORX correspondiente. Con el tiempo, los casos por dimensión se comprimen en principios operativos y eventualmente en el playbook WORX formal.

---

## VI. TERRITORIO INEXPLORADO — Agenda para próximas sesiones

### Preguntas abiertas
- ¿Qué otros procesos del equipo actualmente no tienen Transfer Pack ni Transfer Prompt de arranque?
- ¿El SOP de instalación SherpaX ya incluye la generación del TP como paso obligatorio?
- ¿Qué tan replicable es el proceso de onboarding SherpaX hoy? ¿Alguien del equipo podría hacerlo sin Alex?
- ¿El proyecto "El Poder de MasterPlaybooks" tiene Transfer Pack o documento de referencia ya cargado en el vault? ¿Está completo y actualizado?
- ¿Existe un protocolo explícito de "Vault-First" documentado como SOP para el equipo? ¿O solo vive como conocimiento tácito de Victor?
- ¿Cómo se le comunica al equipo que debe consultar el vault antes de producir? ¿Está en el onboarding de SherpaX?

### Territorios a explorar
- Mapear todos los procesos actuales de EL que tienen (o deberían tener) Transfer Pack
- Definir qué hace que un proceso sea "transfer-ready" vs "transfer-dependiente"
- Revisar si el Ritmo de Trabajo documentado cubre el cierre de sesión con transfer
- Formalizar el Protocolo Vault-First como SOP para el equipo
- Conectar P001 y P002 con la metodología WORX — estos dos principios podrían ser el núcleo de un MiniPlaybook de "Cómo arrancamos en EmpowerLabs"

---

## VI. ACTIVOS GENERADOS EN ESTE ROOM

| Asset ID | Tipo | Descripción |
|----------|------|-------------|
| EL-Charter-LabPraxis-v01 | Charter | Definición e identidad del LabPraxis Room |
| TP-EL-OPS-LabPraxis-v01 | Transfer Pack | Este documento |
| SP-EL-OPS-LabPraxis-v01 | Starter Prompt | Activación del room |

---

## VII. PRÓXIMA SESIÓN

**Foco sugerido:** Dos loops abiertos — (1) cerrar el Caso 001 con el TP de Alain, (2) asegurar que Anahí consulte el vault antes de continuar el libro. Y la pregunta de fondo: ¿Cómo formalizamos P001 y P002 como parte del protocolo de equipo?

**Pregunta de entrada:** ¿Existe ya un SOP que le diga al equipo cómo arrancar cualquier proyecto — con Vault-First como paso 1?

---

---

## VIII. REGISTRO DE ACTUALIZACIONES

- **2026-07-16 (Jay):** Documentado **CASO 030** — "Buzón en blanco para todo el equipo: un MSG sin schema tumba el render + la sync muta el archivo de datos" (Falla compuesta · ✅ síntoma resuelto, 🔴 gate de schema pendiente). Principio emergente propuesto: **P024 — Valida en la frontera, degrada con gracia** (todo dato que cruza a un canal compartido se valida contra su schema al escribirse; un dato malformado degrada la vista, nunca tumba el canal). Refuerza P017 con regla nueva candidata: código/datos ejecutables nunca como archivos sueltos en el vault. NEXTs: @Alex (validación de schema MSG en el scanner — MSG-EL-ValidacionBuzonAlex-v01) · @Jay (regla en canonización P017/P024). El banco va en **30 casos**.

*Transfer Pack generado por Jacob — Sesión 001 — 2026-04-15*  
*Actualizar al cierre de cada sesión del LabPraxis*