---
asset_id: CAS-EL-WORX-LabPraxis-BancoCasos-v01
version: v2.0
tipo: CAS — Banco de Casos Documentados
room: LabPraxis
owner: EmpowerLabs
sherpa: Jay
fecha_creacion: 2026-04-15
ultima_actualizacion: 2026-07-16
total_casos: 30
---

# 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    |
| [019](#caso-019) | Rename de colaborador sin protocolo de propagación al vault — drift masivo post-rename                             | Falla compuesta        | **P015** (emergente) — Team Member Rename Protocol                                               | ✅ Resuelto (barrido ejecutado 2026-06-27) · protocolo pendiente |
| [020](#caso-020) | Modelo predictivo de eventos con tablero de escenarios — primer caso de aplicación WORX + Sandbox visible como antídoto a prototipos invisibles | Innovación + Brecha (resuelta) | **P016** (a canonizar) — Sandbox Visible para Prototipos Comparativos | ✅ Aplicado · pendiente 2do caso para canonizar |
| [021](#caso-021) | Derivado publicado sin regenerar contra el dataset canónico (sitio v01/v02 mezclados · grafo buzón 23/52) | Falla | **P017** (emergente) — Derivado = Regenerado + verificación numérica | ✅ Resuelto en Room B · antídoto (gate) pendiente |
| [022](#caso-022) | Contaminación caso→banco: dato de cliente hardcodeado en un SVA reutilizable | Falla | **P018** (emergente) — Separación Caso↔Banco · P002/D-P-01 | 🔴 Abierto · gate pendiente |
| [023](#caso-023) | Fuga metodológica a entregable de cliente (piloto interno citado en el reporte) | Falla | **P019** (emergente) — Checklist de lenguaje prohibido pre-entrega | 🟡 En piloto · checklist en guía de edición |
| [024](#caso-024) | "Pre-registro" sin precedencia temporal (protocolo, piloto y paper con la misma fecha) | Falla | **P020** (emergente) — Pre-registro externo timestamped | 🔴 Abierto · aplica a Ciclo 1 curación |
| [025](#caso-025) | Anonimato roto por metadatos (sala+área en verbatims de buzón) | Falla | **P021** (emergente) — Gate de anonimato por metadatos | ✅ Resuelto en Room B · gate a canonizar |
| [026](#caso-026) | Los críticos no se bloquean por falta de estrategia: decisión L3 sin empaquetar u owner difuso (patrón en 4 wargames) | Observación + Innovación | **P022** (emergente) — Decisión L3 Empaquetada + Owner Único · refina P006 | 🟡 En piloto · 4 WG- como evidencia |
| [027](#caso-027) | Brechas detectadas al correr el Rally de Inducción WORX (botón Compartir fuera de Cowork + ambigüedad de hub en M3) | Brecha | Emergente (candidato a v02 del Rally) | 🔴 Abierto |
| [028](#caso-028) | El Rally asume contexto que aún no ha entregado (ubicación del vault, terminología IntelliBanks, catálogo de Tipos) | Brecha compuesta | **P023** (emergente) — Contexto Prerequisito Explícito | 🔴 Abierto |
| [029](#caso-029) | Derivado del buzón editado a mano sin regenerar ni contrato de formato (HTML literal en datos → tablero ilegible) | Falla | **P017** (emergente) — Derivado = Regenerado (2da evidencia) | ✅ Síntoma resuelto · 🔴 antídoto de raíz pendiente (scanner) |
| [030](#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 | **P024** (emergente) — Valida en la frontera, degrada con gracia | ✅ Síntoma resuelto · 🔴 gate de schema pendiente |
| [031](#caso-031) | El rename barrido volvió a entrar: "Paloma" reaparece en docs nuevos 3 semanas después del barrido con 0 residuos | Falla | **P015** (2da evidencia) — un rename se cierra con un gate, no con un barrido | 🔴 Abierto · 66 archivos por barrer |
| [032](#caso-032) | El validador no se valida a sí mismo: skills con rutas internas a carpetas que ya no existen | Falla + Brecha | **P025** (emergente) — El detector está dentro de su propio alcance | 🔴 Abierto |

---

## 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-WORX-OS

---

## 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) + IB-WikiX/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 · Dove 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 · Dove · Á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" | WORX OS (WORX + WORX OS + SherpaX) = ese producto | ✅ Lo construimos y vendemos |
| "Connective layer · makes company legible to AI by default" | WORX 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 + WORX 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.

---

## CASO 019
### Rename de colaborador sin protocolo de propagación al vault — drift masivo post-rename
**Fecha:** 2026-06-27 · **Tipo:** Falla compuesta · **Principio:** P015 (emergente) — Team Member Rename Protocol · **Sistemas WORX:** Signal/Truth + Tooling/Knowledge · **Superficie:** LAB

**¿Qué pasó?**
Dove (antes Paloma) cambió su nombre de persona a "Dove" y su SherpaX a "DoveX". El rename se aplicó manualmente a un conjunto de archivos clave, pero sin un barrido exhaustivo del vault. Al ejecutar `TP-EL-DoveRename-VaultDriftSweep-v01` en 2026-06-27 se encontraron 49 archivos vivos con "Paloma" sin actualizar, 35 links Obsidian rotos (`vault=Intellibanks`) y 64 rutas de path con el nombre del vault anterior (`Intellibanks/`). El total de drift a remediar fue 148 ocurrencias en 3 capas distintas.

**La falla compuesta:**
1. **Signal/Truth roto:** el vault mantenía simultáneamente "Dove" y "Paloma" como nombres del mismo colaborador, dependiendo del documento. Cualquier SherpaX leyendo varios docs obtenía una identidad inconsistente del mismo miembro del equipo.

2. **Tooling/Knowledge brecha:** no existe un protocolo formal (`SOP-` o `TP-`) que establezca qué pasos debe seguir un rename de colaborador en el ecosistema. El rename quedó "a criterio" de quien lo ejecutó, sin checklist ni barrido automatizable definido de antemano.

3. **Coordinación incompleta:** el rename parcial fue peor que ninguno — los docs barridos manualmente crearon la ilusión de que el rename estaba completo. No hubo un "punto de cierre" con verificación de 0 residuos.

4. **Drift de vault acumulado:** el mismo TP también reveló drift `Reinventaverse→Intellibanks` no relacionado con el rename de Dove, lo que sugiere que los renames y migraciones de vault no tienen un mecanismo de cierre verificable. Este drift habría seguido creciendo invisiblemente.

**Riesgos si no se protocoliza:**
- Próximo rename de colaborador reproduce el mismo drift (Falla 019-B, 019-C…)
- SherpaX produce activos con el nombre incorrecto de un colaborador, contaminando nuevos docs
- Identidad del equipo incoherente en entregables a clientes (si el Demo Vault o docs B2B heredan el drift)
- El drift de vault (`Intellibanks/`, `vault=Intellibanks`) invisibiliza links rotos que el equipo no detecta hasta que hace clic en Obsidian

**Acción correctiva ejecutada (2026-06-27):**
- Creado `TP-EL-DoveRename-VaultDriftSweep-v01` con scripts bash low-token (grep/sed en lote)
- JOB A: 48 archivos vivos barridos (Paloma→Dove) · 0 residuos verificados
- JOB B: 35 links `vault=Intellibanks` + 64 rutas `Intellibanks/` arreglados → `vault=Intellibanks` / `Intellibanks/` · 0 residuos

**Principio que revela (P015 emergente):**
> **Team Member Rename Protocol** — Todo cambio de nombre de colaborador (persona o SherpaX) se considera **incompleto** hasta que un barrido scriptado del vault arroje 0 residuos del nombre anterior en docs vivos. El rename debe generar obligatoriamente un TP de propagación con: lista de exclusiones legítimas (históricos fechados · provenance explícita), script de barrido ejecutable, y verificación de 0 residuos antes de cerrar.

**Codificación operativa propuesta (antídoto):**
1. **SOP-EL-WORX-TeamRenameProtocol-v01** — procedimiento de 4 pasos: (1) declarar nombre nuevo y exclusiones, (2) correr grep para candidatos, (3) revisión rápida de contexto, (4) aplicar sed + verificar 0 residuos.
2. **Template TP reutilizable** — el `TP-EL-DoveRename-VaultDriftSweep-v01` ya es el prototipo; parametrizarlo para cualquier rename futuro (`NOMBRE_VIEJO`, `NOMBRE_NUEVO`, exclusiones como variables).
3. **Extensión del checklist de onboarding/offboarding** — agregar "ejecutar rename protocol" como paso explícito ante cualquier cambio de nombre de colaborador.

**Status:** ✅ Resuelto (barrido ejecutado) · 🔴 Antídoto pendiente (SOP + template reutilizable)

→ NEXT[@Jay]: Producir `SOP-EL-WORX-TeamRenameProtocol-v01` parametrizando el TP de Dove como template reutilizable.
→ NEXT[@Victor]: Ratificar canonización de P015 después de revisar el SOP propuesto.

---

## CASO 020
### Modelo predictivo de eventos con tablero de escenarios — primer caso de aplicación WORX + Sandbox visible como antídoto a prototipos invisibles
**Fecha:** 2026-07-01 · **Tipo:** Innovación + Brecha (resuelta) · **Principio:** P016 (a canonizar) — Sandbox Visible para Prototipos Comparativos · **Sistema WORX:** Tooling/Knowledge + Signal/Truth + Flow · **Superficie:** BRIDGE (Rebelocity → patrón generalizable a cualquier room)

**¿Qué pasó?**
En el room de Rebelocity, Victor pidió un tablero de pronóstico de escenarios (Mínimo/Esperado/Optimista) para dos eventos 2026 (L'Étape San Bernardino e IRONMAN 70.3 Encarnación), calibrado con datos reales en vez de supuestos. Jay ejecutó el proceso completo: (1) partió de un export real de órdenes (CSV) y un ejercicio manual previo de Victor, (2) generó **2 caminos de arquitectura en paralelo** para que Victor comparara antes de elegir, (3) integró el camino ganador con 2 planes de venta (uno por evento) y una pestaña de atribución de campañas con datos reales de códigos promocionales, (4) cerró con un Transfer Pack de handover para que el equipo opere el sistema sin depender del room original.

A mitad del proceso, Victor descubrió que los 2 prototipos comparativos se estaban generando en el borrador temporal del agente (invisible para él y el equipo) — solo el elegido llegaba al vault. Lo señaló como una ruptura de gobernanza ("nuestra metodología se cae si haces eso"). La corrección: crear `SBX-REB-Sandbox`, el primer subbanco de este tipo en el vault, donde los prototipos comparativos viven visibles desde el primer momento.

**El patrón replicable (la innovación):**
```
1. Dato real primero — nunca calibrar escenarios solo con supuestos si hay un export/CSV disponible
2. Comparar 2+ caminos de arquitectura en paralelo — nunca construir uno solo a ciegas
3. Escenarios Mínimo/Esperado/Optimista con función de proyección propia por contexto
   (curva de aceleración vs. interpolación por checkpoints reales — no una sola fórmula genérica)
4. Integrar el tablero con los planes de ejecución — el tablero dice dónde estamos,
   el plan dice cómo llegamos ahí; no pueden vivir desconectados
5. Cerrar con Transfer Pack — el equipo debe poder operar el sistema sin el room original
```

**La brecha que se descubrió en el camino (Signal/Truth + Tooling/Knowledge):**
Los prototipos comparativos vivían en el scratchpad temporal del agente — invisible para Victor y el equipo hasta que Jay decidía cuál promover. La intención (no ensuciar el banco canónico con nombres no-BMF) era correcta, pero el mecanismo rompía la promesa WORX de que el equipo pueda ver lo que se está generando, no solo el resultado final. Es una variante de **P002/P003** (Vault-First / Herramientas Accesibles) aplicada específicamente al momento de *comparación*, no solo de producción.

**Riesgos si no se hubiera corregido:**
- El equipo pierde visibilidad del proceso de decisión de arquitectura — depende del reporte verbal del agente, no de evidencia en el vault
- Cada futuro "modelo predictivo" o herramienta comparada repite la misma invisibilidad
- Erosión de confianza: Victor no puede verificar que la gobernanza se respetó sin auditar directamente

**Acción correctiva ejecutada:**
- Creado `SBX-REB-Sandbox` en `IB-REB-Rebelocity` — subbanco de prototipos, visible, con índice (`DC-REB-Sandbox-Indice-v01`)
- Prefijo `PROT-` canonizado para prototipos/herramientas en evaluación antes de graduar a SIM/BRD/EXE
- Los 2 caminos descartados quedaron documentados en el sandbox con status `🟡 DESCARTADO` y referencia al ganador; el ganador se graduó a `PB-REB-Rebelocity/PROT-REB-PronosticoEscenarios-2026H2-v01.html`
- `TP-REB-PronosticoEscenarios-Handover-v01` cierra el ciclo completo (tablero + 2 planes + sandbox + gobernanza)
- Alcance del Sandbox limitado a Rebelocity por ahora (decisión explícita de Victor, 2026-07-01) — no se tocó la taxonomía maestra hasta que el patrón se replique en una 2da entidad

**Lo que revela:**
Construir bien la herramienta (el tablero, los planes, los datos reales) no es suficiente si el *proceso* de construirla queda invisible. La gobernanza WORX no es solo sobre el resultado final — es sobre poder auditar el camino. El Sandbox visible es al proceso de decisión lo que el vault es al conocimiento: un lugar donde "si no está ahí, no pasó."

**Status:** ✅ Aplicado — primer ciclo completo cerrado (dato real → prototipos comparados en sandbox → tablero elegido → planes integrados → TP de handover). Pendiente: replicar el patrón completo en un segundo proyecto/evento para confirmar que generaliza antes de canonizar P016.

→ NEXT[@Jay]: Aplicar el patrón "Sandbox visible" la próxima vez que se comparen 2+ prototipos en cualquier room — no solo Rebelocity.
→ NEXT[@Victor]: Si `SBX-` funciona bien en un segundo proyecto/entidad, decidir si se sube a `MePB-XX-Taxonomia-IntelliBanks-v02` como estándar del ecosistema.
→ NEXT[@Jay]: Cuando se acumule un segundo caso de "modelo predictivo con tablero de escenarios", extraer el patrón como SOP formal (`SOP-EL-WORX-ModeloPredictivoDashboard-v01`) o Brain Code.

---

## CASO 021
### Derivado publicado sin regenerar contra el dataset canónico
**Fecha:** 2026-07-02 · **Tipo:** Falla · **Principio:** P017 (emergente) — Derivado = Regenerado + verificación numérica · **Sistemas WORX:** Signal/Truth + Tooling/Knowledge · **Superficie:** PROD

**¿Qué pasó?**
En la auditoría de entregables de Room B (método EScan / entregables Posta), se detectó que activos derivados del dataset canónico habían divergido de él: el sitio mezclaba datos de versiones distintas (Q4/Q5 de v01 junto a v02) y el grafo tenía el buzón parcialmente mapeado (23 de 52 entradas). Los números del entregable no coincidían con el dataset xlsx de referencia.

**La falla:**
Un activo derivado (sitio, grafo, infografía, reporte) se construyó o editó a mano sobre una versión anterior en lugar de **regenerarse** desde el dataset canónico vigente. Sin un gate de verificación numérica automática antes de publicar, la divergencia es invisible hasta que alguien recontar. Es una variante de **Signal/Truth**: el entregable circula como verdad sin estar sincronizado con la fuente única. La superficie es **PROD** porque estos derivados llegan al cliente.

**Riesgos:**
- El cliente recibe cifras que no reconcilian con el dataset — pérdida de credibilidad del método
- Cada re-edición manual reintroduce drift; el derivado y la fuente se separan compounding
- Auditorías futuras gastan tiempo recontando en vez de confiar en un checksum

**Acción correctiva:**
- En Room B se corrigió regenerando: se extrajeron las 52 entradas Q4 del xlsx y se reclasificaron una por una contra la taxonomía del grafo (52/52 mapeadas, total verificado), sin ajustar números a mano
- Antídoto a canonizar: **gate obligatorio** — todo activo derivado se regenera contra el dataset canónico y pasa verificación numérica automática (sumas de control, totales por pregunta, voto neto) antes de publicarse

**Status:** ✅ Resuelto en Room B (corrección con evidencia ejecutada) · 🔴 Antídoto pendiente (gate de regeneración + verificación numérica como paso canónico)

→ NEXT[@Jay]: Codificar el gate "Derivado = Regenerado + verificación numérica" como estación previa a publicar cualquier derivado del dataset (checklist + script de sumas).
→ NEXT[@Victor]: Ratificar P017 como principio tras la 2da aplicación del gate.

---

## CASO 022
### Contaminación caso→banco: dato de cliente hardcodeado en un activo reutilizable
**Fecha:** 2026-07-02 · **Tipo:** Falla · **Principio:** P018 (emergente) — Separación Caso↔Banco · liga con P002 (Vault-First) y D-P-01 · **Sistemas WORX:** Signal/Truth + Roles/Decisions · **Superficie:** BRIDGE (LAB→PROD)

**¿Qué pasó?**
Durante la auditoría del método se encontró un dato de caso real —una CIO específica del cliente Posta— hardcodeado dentro de un SVA reutilizable (`SVA-EL-EScanEvaluador`), un activo de banco pensado para aplicarse a cualquier cliente. El dato del caso quedó incrustado en la cognición reutilizable.

**La falla:**
No existe un gate de separación entre la capa de **caso** (datos de un cliente concreto) y la capa de **banco** (activos genéricos reutilizables). Es el mismo principio D-P-01 (separación operación/cognición) aplicado a la contaminación de datos: un activo de banco jamás debe contener datos de un caso, porque se propagan a todos los clientes futuros que lo reutilicen. Superficie **BRIDGE** porque nace en operación interna (LAB) pero contamina entregables de cliente (PROD).

**Riesgos:**
- Fuga de datos de un cliente a los entregables de otro cliente al reutilizar el SVA
- Violación de confidencialidad (codename Posta) y exposición legal
- El banco pierde su carácter genérico; cada reutilización arrastra ruido del caso original

**Acción correctiva:**
- Depurar el `SVA-EL-EScanEvaluador` de todo dato de caso; parametrizar lo específico como input, no como contenido
- Antídoto a canonizar: **gate de separación Caso↔Banco** — antes de guardar cualquier activo de banco, verificar 0 datos de caso (nombres, cargos, cifras específicas); los datos de caso viven solo en activos de caso (CAS-, AUD-, DC- del cliente)

**Status:** 🔴 Abierto — gate de separación pendiente de diseño; depuración del SVA pendiente

→ NEXT[@Jay]: Depurar `SVA-EL-EScanEvaluador` de datos del caso Posta y parametrizar los inputs específicos.
→ NEXT[@Victor]: Ratificar P018 (Separación Caso↔Banco) y decidir si se codifica como invariante en el generador de UltraSherpas.

---

## CASO 023
### Fuga metodológica a un entregable de cliente
**Fecha:** 2026-07-02 · **Tipo:** Falla · **Principio:** P019 (emergente) — Checklist de lenguaje prohibido pre-entrega · **Sistemas WORX:** Signal/Truth · **Superficie:** PROD

**¿Qué pasó?**
En el reporte destinado al cliente Posta apareció una frase que exponía el andamiaje metodológico interno: *"el piloto BC-effect ya lo anticipaba"*. Un detalle de la investigación interna (el piloto del efecto Brain Code) se filtró a un entregable de cara al cliente.

**La falla:**
No existe un checklist obligatorio de **lenguaje prohibido** que se corra antes de entregar. El cliente no debe leer los nombres internos de pilotos, experimentos, cogniciones ni el aparato metodológico: solo el resultado y su fundamento. Es un problema de **Signal/Truth** en dirección de salida — información interna circulando hacia afuera. Superficie **PROD** por definición.

**Riesgos:**
- El cliente percibe que es "conejillo de indias" de un experimento en vez de receptor de un método probado
- Se revela IP metodológica (BC-effect, anatomía de BCs) sin necesidad
- Erosión de la percepción de solidez del método

**Acción correctiva:**
- Se creó una guía de edición para el room de producción (`DC-EL-PostaReporte-GuiaEdicion-v01`) con lenguaje permitido/prohibido y checklist de 9 puntos
- Antídoto a canonizar: **checklist de lenguaje prohibido obligatorio** como parte del gate de salida (Paso 8 del protocolo de auditoría) — grep automático de términos internos antes de cualquier entrega

**Status:** 🟡 En piloto — checklist existe en la guía de edición; falta canonizarlo como gate automático pre-entrega para todos los rooms de producción

→ NEXT[@Jay]: Convertir el checklist de 9 puntos de la guía de edición en un grep automatizable de lenguaje prohibido reutilizable en cualquier entregable.
→ NEXT[@Victor]: Ratificar P019 y decidir si el checklist se vuelve invariante del gate de salida (no-entrega sin PASS).

---

## CASO 024
### "Pre-registro" sin precedencia temporal
**Fecha:** 2026-07-02 · **Tipo:** Falla · **Principio:** P020 (emergente) — Pre-registro externo timestamped · **Sistemas WORX:** Signal/Truth + Outcome · **Superficie:** LAB → PROD

**¿Qué pasó?**
La auditoría del método (auditor de protocolo/piloto/paper contra literatura externa) detectó que el protocolo, el piloto y el paper del estudio tenían **la misma fecha**. Un pre-registro que no antecede temporalmente al estudio no es pre-registro: no puede demostrar que las hipótesis se fijaron antes de ver los datos.

**La falla:**
No hay un mecanismo de **registro externo timestamped** anterior a correr cualquier estudio. Sin precedencia temporal verificable, el estudio queda expuesto a la crítica de HARKing (hypothesizing after results are known) y pierde su valor confirmatorio. Es un problema de **Signal/Truth** (la cronología real no es demostrable) con impacto en **Outcome** (la validez del estudio como evidencia). Nace en LAB pero define si el método es defendible ante un cliente o revisor externo (PROD).

**Riesgos:**
- El estudio no resiste una revisión metodológica externa seria — el diferencial "científico" del método se cae
- Cualquier hallazgo confirmatorio queda como circular (el paper "confirma" lo que el mismo día definió)
- Reproduce el patrón en cada estudio futuro del método si no se protocoliza

**Acción correctiva:**
- Antídoto a canonizar: **pre-registro externo timestamped** antes de correr cualquier estudio (registro con sello de tiempo independiente — repositorio versionado con commit fechado, plataforma de pre-registro, o equivalente) que fije hipótesis, método y métricas antes de tocar datos
- Aplica directamente al **Ciclo 1** del plan de curación (el estudio confirmatorio BC-effect debe pre-registrarse antes de correrse)

**Status:** 🔴 Abierto — mecanismo de pre-registro timestamped pendiente de definir antes del Ciclo 1

→ NEXT[@Victor]: Definir el mecanismo de pre-registro timestamped (repo con commit fechado u otra plataforma) antes de correr el estudio confirmatorio del Ciclo 1.
→ NEXT[@Jay]: Ratificada la mecánica, documentar el paso "pre-registro" como prerequisito canónico de cualquier estudio del método (liga con TP-EL-RoomBAudit-Protocol-v01, R4).

---

## CASO 025
### Anonimato roto por metadatos en verbatims
**Fecha:** 2026-07-02 · **Tipo:** Falla · **Principio:** P021 (emergente) — Gate de anonimato por metadatos · **Sistemas WORX:** Signal/Truth + Incentive/Accountability · **Superficie:** PROD

**¿Qué pasó?**
En la auditoría de entregables se encontró que los verbatims del buzón (citas textuales de participantes) conservaban metadatos de sala y área. Aunque no había nombres, la combinación **sala + área** permite reidentificar a la persona que dio el comentario en un grupo pequeño — el anonimato prometido quedó roto.

**La falla:**
El gate de anonimato revisaba nombres pero **no metadatos**. Anonimizar no es solo quitar nombres: es asegurar que ninguna combinación de metadatos (sala, área, cargo, fecha, secuencia) permita reidentificar. Es un problema de **Signal/Truth** (el dato dice más de lo que debería) y de **Incentive/Accountability** (rompe la promesa de confidencialidad hecha a los participantes, de la que depende la calidad de sus respuestas). Superficie **PROD** porque llega en el entregable al cliente.

**Riesgos:**
- Reidentificación de participantes → violación de la promesa de anonimato del método EScan
- Los participantes de futuros estudios responden con menos honestidad si perciben que pueden ser identificados → degrada la señal que el método vende
- Exposición legal/ética para EmpowerLabs y para el cliente

**Acción correctiva:**
- En Room B se removieron los metadatos reidentificantes de los verbatims al regenerar las versiones corregidas
- Antídoto a canonizar: **gate de anonimato por metadatos** — revisar cita por cita incluyendo TODOS los metadatos, no solo nombres; regla: en grupos pequeños, ninguna combinación de metadatos debe permitir k-anonimato < umbral definido

**Status:** ✅ Resuelto en Room B (verbatims regenerados sin metadatos reidentificantes) · 🔴 Gate a canonizar como paso estándar de anonimización

→ NEXT[@Jay]: Codificar el gate de anonimato por metadatos (checklist cita-por-cita + umbral de k-anonimato) como paso obligatorio de anonimización en el método EScan.
→ NEXT[@Victor]: Ratificar P021 y decidir el umbral de k-anonimato para grupos pequeños.

---

## CASO 026
### Los críticos no se bloquean por falta de estrategia: decisión L3 sin empaquetar u owner difuso
**Fecha:** 2026-07-06 · **Tipo:** Observación + Innovación · **Principio:** P022 (emergente) — Decisión L3 Empaquetada + Owner Único (refina P006) · **Sistemas WORX:** Decision + Incentive/Accountability · **Superficie:** LAB (detección) → PROD (los 4 críticos afectados)

**¿Qué pasó?**
En una sesión del IALab (2026-07-06) se corrieron 4 wargames pre-mortem (formato WG-, piloto del método) sobre los 4 hitos críticos 🔴★★ de la minuta: DG.1 (primera publicación, 2+ semanas de arrastre), POSTA.2 (cierre de contrato, 1+ semana), FLA-F1 (Registro+Consejero, cadencia deslizada) y SPO.1 (sponsor Santa Rosa, semanas). Al simular cada misión move-by-move, los 4 diagnósticos convergieron en la misma causa raíz — y en NINGUNO de los 4 la causa fue falta de estrategia o de activos:

| Crítico | Activos/estrategia | Bloqueo real |
|---|---|---|
| DG.1 | Estrategia desde abril · ~100 piezas diseñadas · canales vivos | Elección de tesis + acto de publicar = L3 de Victor en cola · canales acoplados sin necesidad |
| POSTA.2 | Delivery sobrado (reporte, sitio, calculadoras) | Vehículo de cierre (anexo C3) sin producir · esperando "momento" que nadie poseía |
| FLA-F1 | Plan ejecutable completo desde 20-jun | 4 decisiones L3 en cola + Runner "a asignar" (sin dueño desde el día 1 del plan) |
| SPO.1 | Menú 5 niveles · calculadoras v07 · one-pager | Pricing "tentativo — ratificar antes de circular" 3 semanas sin ratificar · owner "Victor·Equipo" = nadie |

**El patrón:**
Dos modos de falla, a veces combinados: **(a) la decisión L3 llega a la cola de Victor sin empaquetar** — como pregunta abierta que exige pensar desde cero, compite contra clientes y fuego, y pierde siempre; **(b) el owner del hito es difuso** ("Victor·Equipo", "el equipo", "a asignar") — difusión de responsabilidad que garantiza el arrastre. Es un problema de **Decision** (el sistema no distingue entre decisión-lista-para-decidir y decisión-sin-estructurar) y de **Incentive/Accountability** (un hito con owner plural no tiene quien rinda cuentas). Confirma a escala lo que el CASO 009 registró en una decisión puntual: *"el cuello de botella no es Victor decidiendo — es la propuesta sin estructurar lo suficiente como para que decidir sea rápido"*. La evidencia inversa de esta misma sesión lo prueba: cuando las decisiones llegaron empaquetadas (Ledger de variables con defaults, calibración del anexo C3), Victor las resolvió en minutos.

**La innovación (el instrumento de detección):**
El wargame pre-mortem (WG-) detectó los 4 bloqueos en UNA sesión — bloqueos que llevaban semanas invisibles bajo la apariencia de "falta avanzar". La sección obligatoria de Ledger (variables indefinidas con owner) y la pregunta "¿cuál es la causa de falla más probable de este move?" fuerzan a nombrar la decisión en cola y al owner ausente. Sin el wargame, el diagnóstico habría seguido siendo "hay que echarle más ganas".

**Riesgos si no se resuelve:**
- Los hitos críticos seguirán arrastrando semanas mientras la estrategia se sigue refinando (el síntoma invita al remedio equivocado: más planeación)
- La cola L3 de Victor crece sin distinción entre lo empaquetado y lo crudo → decide poco y tarde
- Los "Victor·Equipo" en minutas fabrican arrastre estructural nuevo cada semana
- El costo compuesto es comercial directo: POSTA.2 y SPO.1 tienen relojes externos (enfriamiento de cliente, ventana de activación L'Étape)

**Acción correctiva (P022 en piloto):**
1. **Regla de empaquetado L3:** ninguna decisión entra a la cola de Victor sin formato de paquete — pregunta binaria (o elección entre ≤3 opciones), default argumentado, datos faltantes marcados, timebox. El template del CASO 009 deja de ser opcional para hitos 🔴. Corolario: "elegir, no crear" en las sesiones de decisión.
2. **Regla de owner único:** prohibido "Victor·Equipo"/"Equipo"/"a asignar" como owner de un hito 🔴 en minutas — se escribe 1 nombre, o se escribe explícitamente "SIN DUEÑO" (que es información honesta, no un owner falso).
3. **WG- como detector estándar:** todo hito 🔴 con >2 semanas de arrastre dispara un wargame pre-mortem automáticamente (conecta con la propuesta Gate 1.5 de ANA-EL-WargamingPlaybook-SintaxisBMF-v01, IDE-057).

**Status:** 🟡 En piloto — 4 WG- producidos como evidencia (WG-EL-DemandGen-PrimeraPublicacion, WG-EL-Posta-CierreContrato, WG-EL-FLA-F1-RegistroConsejero, WG-REB-SantaRosa-PropuestaSponsor, en PB-EL-IALab/WG-EL-WarRoom/). P022 se canoniza si el triage semanal confirma que los hitos con paquete+owner único cierran y los difusos siguen arrastrando.

→ NEXT[@Victor]: Ratificar P022 (regla de empaquetado L3 + regla de owner único) y los 4 wargames pendientes de ratificación.
→ NEXT[@Jay]: Aplicar formato "paquete de decisión" a TODOS los hitos 🔴 de la próxima minuta semanal y eliminar owners plurales (1 nombre o "SIN DUEÑO").
→ NEXT[@Jay]: En el triage semanal, medir semanas-de-arrastre por causa raíz (decisión-en-cola vs owner-difuso vs otra) para validar o refutar P022 con datos.

---

## CASO 027
### Brechas detectadas al correr el Rally de Inducción WORX (candidatas a v02)
**Fecha:** 2026-07-14 (detectado) · 2026-07-15 (documentado) · **Tipo:** Brecha · **Principio:** Emergente (candidato a v02 del Rally) · **Sistemas WORX:** Tooling/Knowledge + Signal/Truth · **Superficie:** LAB (onboarding interno)

**¿Qué pasó?**
Juan Carlos corrió el Rally de Inducción WORX completo el 2026-07-14 (8/8 misiones selladas, `BRD-EL-RallyWORX-Onboarding-v01.html`, registro en `NOT-EL-JuanCarlos-RallyInduccion-20260714-v01`). Al ejecutarlo de punta a punta como operador real — no como diseñador del Rally — detectó dos brechas en el mecanismo mismo que no eran visibles desde el diseño:

1. **Botón "+ Compartir" del dashboard HOY** (`BRD-EL-HOY-Dashboard-v01`) solo funciona dentro de Cowork. Si el operador lo abre fuera de ese contexto, el mecanismo de compartir no dispara.
2. **Ambigüedad de hub en la Misión 3:** la instrucción puede confundir "WikiX-EL-Hub" con "WikiX-Hub" — dos hubs de nombre similar pero distintos — sin que quede claro a cuál se refiere.

**La brecha:**
Es un problema de **Tooling/Knowledge** (una herramienta del onboarding — el botón de compartir — no funciona en todos los contextos donde el Rally puede correrse) combinado con **Signal/Truth** (la instrucción de M3 no apunta sin ambigüedad al hub correcto, por lo que un sello puede completarse sin verificar comprensión real — eco del mismo patrón del CASO 014/quiz señalado por JC el mismo día en su revisión de MatriX: "el sello mide clics, no comprensión"). Solo se detecta corriendo el Rally como usuario nuevo, no revisándolo en el diseño.

**Riesgos:**
- Un operador nuevo que corra el Rally fuera de Cowork puede quedar bloqueado en silencio sin saber que el botón simplemente no funciona ahí — fricción no explicada en el onboarding
- La ambigüedad de hub en M3 puede llevar a navegar el hub equivocado y sellar la misión sin haber verificado la referencia correcta

**Acción correctiva:**
- Documentado como candidato a la v02 del Rally (referencia: minuta `MIN-EL-JuanCarlos-20260714-v01`, sección "Mejoras detectadas al Rally")
- Pendiente que el owner del Rally decida: (a) condicionar/ocultar el botón "+ Compartir" fuera de Cowork o documentar la limitación explícitamente, y (b) reformular M3 nombrando sin ambigüedad cuál hub (o aclarando la diferencia entre ambos)

**Status:** 🔴 Abierto — candidatas a v02, sin acción tomada aún

→ NEXT[@JuanCarlos]: Enviar estos dos hallazgos por buzón al owner del Rally (Victor/Jay) para que se incorporen a la v02 del board.
→ NEXT[@Victor]: Decidir tratamiento del botón "+ Compartir" fuera de Cowork (ocultar / documentar limitación).
→ NEXT[@Jay]: Reformular M3 para eliminar la ambigüedad WikiX-EL-Hub vs WikiX-Hub.

---

## CASO 028
### El Rally asume contexto que aún no ha entregado (ubicación del vault, terminología IntelliBanks, catálogo de Tipos)
**Fecha:** 2026-07-14 (detectado) · 2026-07-15 (documentado) · **Tipo:** Brecha compuesta · **Principio:** **P023** (emergente) — Contexto Prerequisito Explícito · **Sistemas WORX:** Tooling/Knowledge + Signal/Truth · **Superficie:** LAB (onboarding interno) · **Relacionado:** CASO 027 (mismo Rally, capa de mecanismo/UI — este caso es de secuenciación pedagógica)

**¿Qué pasó?**
Al correr el Rally de Inducción WORX de punta a punta (2026-07-14), Juan Carlos identificó tres puntos donde el Rally exige del usuario un conocimiento que el Rally mismo todavía no le ha entregado:

1. **Ubicación del vault no explicada antes del ejercicio.** El Rally manda al usuario a leer documentos de conceptos básicos en el tablero, pero a esa altura un usuario genuinamente nuevo no sabe qué es "el vault" ni dónde vive en su computadora. JC lo resolvió porque ya conocía de antes que la carpeta `Intellibanks` vive dentro de `Documents` (Windows, en su caso) y contiene las carpetas `IB-*`, accesible por Explorador de archivos o por la app IntelliBanks que sincroniza. Un usuario sin ese contexto previo se queda perdido antes de llegar al concepto.

2. **Ambigüedad del término "Intellibanks".** El Rally usa el término para tres cosas distintas sin distinguirlas: (a) la aplicación que sincroniza, (b) el nombre de la carpeta raíz del vault, y (c) las carpetas individuales `IB-*` dentro de esa carpeta. No es obvio para un usuario nuevo a cuál se refiere cada mención.

3. **Catálogo de Tipos no entregado antes del ejercicio de naming.** El Rally pide nombrar un documento ficticio siguiendo la convención canónica (`TIPO-ENTIDAD-Proyecto-Nombre-vNN`), pero en ese punto el usuario solo conoce la estructura del nombre — no conoce el catálogo de "Tipos" (`TIPO-`) ya definidos en WORX. Sin esa lista, el ejercicio está diseñado para que el usuario falle.

**La brecha:**
Los tres puntos comparten la misma causa raíz: el Rally da por hecho contexto fundacional (dónde está el vault, qué significa cada término, qué Tipos ya existen) que todavía no ha sido entregado al usuario en el momento en que se lo exige. Es un problema de **Tooling/Knowledge** (el usuario no tiene acceso al conocimiento/herramienta antes de que se le pida usarla) y de **Signal/Truth** (el término "Intellibanks" no comunica sin ambigüedad a qué realidad se refiere en cada uso). A diferencia del CASO 027 (bugs de mecanismo/UI del Rally), este es un problema de **secuenciación pedagógica**: el orden de entrega de contexto no respeta lo que el usuario nuevo realmente sabe en cada paso.

**Riesgos:**
- Un usuario nuevo (sin el contexto tácito que ya tiene JC) se bloquea o se frustra antes de completar los conceptos básicos, sin saber cómo ubicar el vault
- La ambigüedad de "Intellibanks" genera confusión acumulada que se arrastra a conversaciones futuras con el SherpaX
- El ejercicio de naming está diseñado para fallar sin el catálogo de Tipos — un sello del Rally que no refleja comprensión real (mismo patrón de "el sello mide clics, no comprensión" ya señalado por JC en su revisión de MatriX el mismo día)

**Acción correctiva:**
- Documentado como candidato a la v02 del Rally, en conjunto con el CASO 027
- Propuesta: (a) agregar un paso explícito al inicio del Rally que explique qué es el vault y dónde se ubica (carpeta `Intellibanks` en `Documents`, o vía la app de sincronización) antes de mandar al usuario a leer cualquier documento; (b) aclarar explícitamente las 3 acepciones de "Intellibanks" la primera vez que se usa el término; (c) entregar o enlazar el catálogo de Tipos (`TIPO-`) antes del ejercicio de naming, no después

**Status:** 🔴 Abierto — candidato a v02, sin acción tomada aún

→ NEXT[@JuanCarlos]: Enviar estos tres hallazgos por buzón al owner del Rally (Victor/Jay), junto con los del CASO 027.
→ NEXT[@Victor]: Decidir si se agrega un paso previo de "ubicación del vault" al inicio del Rally.
→ NEXT[@Jay]: Aclarar las 3 acepciones de "Intellibanks" en el Rally y enlazar el catálogo de Tipos antes del ejercicio de naming.

---

## CASO 029
### Derivado del buzón editado a mano sin regenerar ni contrato de formato (HTML literal en los datos → tablero ilegible)
**Fecha:** 2026-07-16 · **Tipo:** Falla (derivada de brecha conocida: scanner inexistente) · **Principio:** **P017** (emergente) — Derivado = Regenerado + verificación numérica · **2da evidencia** · **Sistemas WORX:** Signal/Truth + Tooling/Knowledge · **Superficie:** LAB (canal de comunicación interna) · **Relacionado:** CASO 021 (mismo patrón de derivado divergente) · incidente NULs de sync del 14-jul (MIN-EL-JuanCarlos-20260714)

**¿Qué pasó?**
Al abrir mensajes en el tablero `BRD-EL-Buzon-Dashboard-v01.html`, los cuerpos mostraban las etiquetas `<br>` y `<b>` como texto visible en lugar de aplicar los saltos de línea y negritas (reportado por Juan Carlos, 2026-07-16). El diagnóstico encontró que 14 de los 19 mensajes en `BZ-EL-BuzonData-v01.js` traían HTML literal en el campo `body`, mientras que el espejo `BZ-EL-BuzonData-v01_json.md` estaba limpio (markdown con saltos reales). El formateador del tablero escapa todo HTML por seguridad (comportamiento correcto), por lo que las etiquetas se volvían texto visible.

**La falla:**
`BZ-EL-BuzonData-v01.js` es un **archivo derivado** — su fuente canónica son los `MSG-*.md` de `BZ-EL-Buzon/`. Como el scanner `BZ-EL-BuzonScanner-v01` sigue sin existir en el vault (señalado por Alex el 10-jul y reconfirmado en los incidentes del 14-jul), los datos del tablero se actualizan a mano — y cada mano escribe formato distinto: alguien escribió HTML donde el contrato implícito del tablero es markdown ligero con saltos reales, contrato que además nunca se escribió en ninguna spec. Es el mismo patrón del CASO 021 (derivado que diverge del canónico por editarse en lugar de regenerarse), operando en **Signal/Truth** (el canal asíncrono del equipo mostraba mensajes ilegibles) y **Tooling/Knowledge** (falta la herramienta que regenera y falta el contrato de formato documentado).

**Riesgos:**
- Mensajes ilegibles minan la confiabilidad del buzón justo en su fase de adopción por el equipo
- Divergencia silenciosa entre `.js` y `_json.md` produce reportes y tableros con datos inconsistentes (tercera consecuencia documentada de la ausencia del scanner: NULs 14-jul, dashboard actualizado a mano, HTML literal)
- Sin contrato de formato escrito, cada edición manual futura puede reintroducir el problema en otra forma

**Acción correctiva:**
- ✅ Datos normalizados (2026-07-16): los 14 `body` afectados del `.js` convertidos a markdown (`<br>` → saltos reales, `<b>` → `**`); verificado JS válido con los 19 mensajes
- ✅ Antídoto de síntoma en el tablero: `fmtBody` ahora normaliza HTML literal (`<br>`, `<b>`, `<i>`) a markdown antes de escapar — el síntoma no reaparece aunque los datos vuelvan a traer HTML
- 🔴 Antídoto de raíz pendiente: construir el scanner para que el `.js` sea siempre **regenerado, nunca editado** + documentar el contrato de formato del campo `body` en la spec

**Status:** ✅ Síntoma resuelto (2026-07-16) · 🔴 antídoto de raíz pendiente (scanner)

→ NEXT[@Alex]: Construir `BZ-EL-BuzonScanner-v01.js` según `DC-EL-WORX-BuzonScanner-PluginSpec-v01` — pendiente arrastrado desde el 10-jul; este caso es la tercera consecuencia documentada de su ausencia.
→ NEXT[@Jay]: Agregar a la spec del scanner el contrato de formato del campo `body` (markdown ligero con saltos reales, sin HTML) y la regla "el `.js` no se edita a mano".

---

## CASO 030
### Buzón en blanco para todo el equipo: un MSG sin schema tumba el render + la sync muta el archivo de datos
**Fecha:** 2026-07-16 · **Tipo:** Falla compuesta · **Principio:** **P024** (emergente) — Valida en la frontera, degrada con gracia · **Sistemas WORX:** Signal/Truth (canal caído) + Tooling/Knowledge (sin gate de validación) · **Superficie:** LAB · **Relacionado:** CASO 029 (mismo archivo derivado, falla distinta) · patrón sync-muta-código (plugin.json→plugin_json.md, jun-2026)

**¿Qué pasó?**
Victor reportó su buzón vacío dos veces el mismo día. **Falla A:** la sync del vault mutó `BZ-EL-BuzonData-v01.js` → `BZ-EL-BuzonData-v01_json.md` (11:50); sin el archivo, el tablero caía al fallback vacío ("corre el scanner"). **Falla B:** tras regenerar los datos, el tablero seguía en blanco — un mensaje (`MSG-EL-MatriXPlanAsimilado-v01`) traía `para: "@Victor"` como *string* en lugar de lista; `paraIncluyeMe()` hacía `.some()` sobre un no-array y el error tumbaba el render **completo, para todos los operadores**. Diagnóstico con navegador simulado (jsdom): el header cargaba (24 mensajes) pero tabs, selector y tarjetas nunca se pintaban.

**La falla:**
Dos causas raíz independientes que comparten patrón: **datos que cruzan una frontera sin validarse**. (A) La sync trata archivos `.js` del vault como documentos y los renombra — el espejo `_json.md` que el CASO 029 asumió "limpio" es en realidad el artefacto de esa mutación; código y datos ejecutables no sobreviven como archivos sueltos en el vault. (B) El buzón no valida el frontmatter de un MSG ni al enviarse ni al agregarse a los datos, y el tablero asumía el schema perfecto: un solo campo malformado = canal de comunicación del equipo caído. En Signal/Truth es la falla más cara: no un mensaje ilegible (CASO 029) sino **el canal entero en silencio**, sin error visible para el usuario.

**Riesgos:**
- Un colaborador cualquiera puede tumbar el buzón de todo el equipo con un MSG mal formado — y nadie sabe por qué "no hay nada"
- El patrón sync-muta-código seguirá cobrando víctimas en cualquier `.js`/`.py`/dotfile que viva en el vault (3 evidencias: plugins jun-2026, BuzonData 16-jul, y el espejo `_json.md` reinterpretado)
- Fallas silenciosas (página en blanco sin mensaje de error) destruyen la confianza en la herramienta justo en fase de adopción

**Acción correctiva:**
- ✅ MSG culpable corregido (`para` normalizado a lista) · 2026-07-16
- ✅ Regenerador normaliza `para`/`de` a su tipo correcto SIEMPRE, escape `</` incluido
- ✅ Tablero blindado: `paraIncluyeMe()` tolera string/vacío — un dato malformado degrada, no tumba
- ✅ Anti-sync: snapshot de datos EMBEBIDO en el HTML como fallback (`__BUZON_FALLBACK__`); el tablero funciona aunque la sync vuelva a mutar el `.js` (el HTML sí sobrevive a la sync)
- ✅ Verificación end-to-end con jsdom: 0 errores runtime, 13 tarjetas para @Victor
- 🔴 Gate de raíz pendiente: validación de schema del MSG **al enviarse** (frontmatter contra `TEMPLATE-MSG.md`) — encaja en el scanner de Alex y/o en `sk-skillvalidator`

**Status:** ✅ Síntoma resuelto (2026-07-16) · 🔴 gate de schema pendiente

→ NEXT[@Alex]: Incluir en el scanner del buzón la validación de schema del frontmatter MSG (para=lista, de=dict, tipo/estado en catálogo, fecha ISO) — rechazar o normalizar al escanear, nunca dejar pasar; considerar la misma validación en `sk-skillvalidator`. MSG enviado: `MSG-EL-ValidacionBuzonAlex-v01`.
→ NEXT[@Jay]: Al canonizar P017/P024, incluir la regla "código y datos ejecutables NUNCA como archivos sueltos en el vault — o van al repo git, o van embebidos en HTML/markdown".

---

## CASO 031
### El rename barrido volvió a entrar: "Paloma" reaparece en docs nuevos 3 semanas después del barrido con 0 residuos verificados
**Fecha:** 2026-07-21 · **Tipo:** Falla · **Principio:** **P015** (2da evidencia — el barrido verifica estado, no flujo) · **Sistemas WORX:** Signal/Truth + Tooling/Knowledge · **Superficie:** LAB → BRIDGE (contaminó una skill instalable) · **Relacionado:** CASO 019 (mismo rename, cerrado como ✅ Resuelto)

**¿Qué pasó?**
Durante el empaquetado de la skill `/ux-diseno`, el SherpaX escribió "Ratificador: Paloma (brand)" en el `SKILL.md`, copiándolo del SPEC y de la cadena de documentos fuente. Al documentar otro caso se revisó el CASO 019 y saltó la contradicción: Paloma se renombró a **Dove** el 2026-06-27, con barrido ejecutado y "0 residuos verificados". La fuente canónica de identidades (`EQ-EL-Equipo/02-PerfilOperador/`) contiene únicamente `DC-EL-PerfilOperador-Dove-v01` — cero archivos de perfil con el nombre anterior. Sin embargo, los documentos **fechados 13 y 20 de julio** — `OUT-MIN-EL-TeamSync-20260720`, `XD-EL-TorreControl-Semana-20260720`, `TP-EL-RoomHandoff-Semana20260720`, `BOL-EL-BoletinSemanal-20260720`, `MIN-EL-Victor-Semana-20260720`, `PLAN-EL-Anahi-Semana-20260720` — usan "Paloma" con **cero menciones de Dove**. Son documentos escritos 2–3 semanas *después* del barrido. Conteo actual en `IB-EL-EmpowerLabs`: 66 archivos con el nombre viejo contra 87 con el nuevo.

**La falla:**
El CASO 019 cerró con el criterio correcto para un barrido ("0 residuos") pero **ese criterio verifica un estado, no un flujo**. Un `sed` deja el vault limpio en el instante T; nada impide que en T+1 un operador o un SherpaX vuelva a escribir el nombre viejo, porque la única memoria del rename vive en un TP archivado que nadie relee al producir. El antídoto propuesto en el 019 (SOP + template parametrizable) sigue pendiente, y aun así habría sido insuficiente: **un SOP de barrido es reactivo por diseño**. Lo que faltaba era un gate — algo que impida la entrada, no que limpie la salida. Es exactamente el mismo hueco que P017/P024 identificaron en otro dominio ("valida en la frontera"), aplicado a identidad en vez de a datos.

Agravante de superficie: el nombre viejo no se quedó en documentos internos. Entró a un `SKILL.md` empaquetado como `.skill` e instalado — es decir, **cruzó de LAB a un artefacto distribuible**, que es la frontera que P018/CASO 022 marcaron como la más cara.

**Riesgos:**
- El nombre viejo se sigue propagando por copia: cada doc nuevo que cite un doc contaminado hereda el error, y el volumen crece más rápido de lo que un barrido manual lo corrige
- Un colaborador nuevo leyendo el vault concluye que Paloma y Dove son dos personas distintas del equipo de brand
- Los NEXT y las ratificaciones quedan asignados a un nombre que no existe en el roster — `sk-next` no los encuentra al escanear por "Dove"
- Si un entregable a cliente hereda la cadena (Brand → SPEC → skill), el drift sale de la casa
- Declarar un rename "✅ Resuelto" cuando solo se resolvió el síntoma degrada la confianza en el propio banco de casos

**Acción correctiva:**
- ✅ Corregidos los artefactos producidos en esta sesión (`ux-diseno/SKILL.md`, `SPEC-EL-UX-FactoriaVisual-v01`) · 2026-07-21
- 🔴 Barrido de los 66 archivos pendiente — requiere separar residuo legítimo (minutas fechadas antes del 27-jun, provenance del propio `TP-EL-DoveRename-VaultDriftSweep-v01`) de drift real
- 🔴 Gate de raíz pendiente: el rename necesita un mecanismo de *entrada*, no solo de barrido

**Principio que revela (refina P015):**
> **Un rename no se cierra con un barrido, se cierra con un gate.** El criterio "0 residuos" verifica el estado del vault en un instante; el nombre viejo vuelve a entrar en cuanto alguien produce desde una fuente contaminada. Todo rename de colaborador debe dejar (a) el barrido, (b) una entrada en la fuente canónica de identidades que los SherpaX consultan al producir, y (c) una verificación de nombres retirados en el mismo lugar donde ya se valida schema. Mientras el nombre viejo sea escribible sin fricción, el barrido es una limpieza recurrente, no una resolución.

**Status:** 🔴 Abierto · síntoma corregido solo en los artefactos de esta sesión

→ NEXT[@Jay]: Correr el barrido `Paloma→Dove` sobre los 66 archivos de `IB-EL-EmpowerLabs`, con lista explícita de exclusiones legítimas (minutas y MSG fechados antes de 2026-06-27, y el TP del rename original que necesita citar ambos nombres).
→ NEXT[@Jay]: Al canonizar P015, sustituir el criterio de cierre "0 residuos" por "0 residuos + nombre retirado registrado en la fuente canónica de identidades + verificación en el validador" — y agregar el catálogo de nombres retirados a `02-PerfilOperador/` para que los SherpaX lo consulten en Gate G0.
→ NEXT[@Victor]: Confirmar que "Dove" es el nombre vigente y que "Paloma" no fue una reversión deliberada — todo el análisis asume que el perfil canónico manda sobre los docs recientes.

---

## CASO 032
### El validador no se valida a sí mismo: skills cuyas rutas internas apuntan a carpetas que ya no existen
**Fecha:** 2026-07-21 · **Tipo:** Falla + Brecha · **Principio:** **P025** (emergente) — El detector está dentro de su propio alcance · **Sistemas WORX:** Tooling/Knowledge + Signal/Truth · **Superficie:** LAB · **Relacionado:** CASO 031 (misma raíz: referencias que envejecen sin que nada las vigile)

**¿Qué pasó?**
Al correr `sk-ibhealth` para auditar la salud de las skills, el Módulo B reportó **1 problema: `sk-ibhealth` con ruta muerta a Reinventaverse**. Al inspeccionar, todas las menciones resultaron ser (a) el propio `grep` que busca la cadena y (b) la línea de su guardrail que dice "Reinventaverse ya no existe — NUNCA leas ahí". El filtro de la línea 31 excluye las prohibiciones legítimas (`ya no existe|NUNCA|guardrail`) pero no excluye el **código detector**, que contiene el patrón literal por necesidad. Falso positivo.

En la misma sesión, `sk-labpraxis` falló al abrir el banco de casos: su `SKILL.md` apunta a `PB-EL-Project-Bank/PB-WERK-Werk/CAS-EL-WERK-LabPraxis-BancoCasos-v01.md`. La ruta real es `PB-WORX-Worx/CAS-EL-WORX-LabPraxis-BancoCasos-v01.md` — el proyecto se renombró WERK→WORX y la skill nunca se actualizó. La skill "corre" igual; solo falla el paso de leer el banco, que un operador distraído podría saltarse.

**La falla y la brecha:**
Dos síntomas, una raíz: **las skills declaran rutas al vault en texto plano y nada verifica que esas rutas sigan existiendo.** El `sk-ibhealth` audita duplicados, nombres viejos y carpetas indebidas *del vault*, pero no audita lo único que garantizaría que las demás skills funcionen: que sus referencias resuelvan. El detector quedó fuera de su propio alcance en dos sentidos — no se auto-excluye del escaneo (falso positivo) y no escanea lo que importa (rutas rotas reales).

El caso de `sk-labpraxis` es además la tercera evidencia del patrón de rename del CASO 031 y del 019: un rename de proyecto (WERK→WORX) propagó al vault pero no a las skills que lo referencian, porque las skills viven en el marketplace de plugins, fuera del alcance de cualquier barrido del vault.

**Riesgos:**
- Una skill con ruta muerta falla en silencio: produce sin la fuente que debía consultar, que es exactamente la falla del CASO 002/008 (producir sin consultar el vault) pero automatizada
- Los falsos positivos entrenan al equipo a ignorar el reporte del health check — la próxima bandera real se descarta
- Cada rename futuro de proyecto o carpeta rompe silenciosamente las skills que lo referencian, y no hay barrido que las alcance

**Acción correctiva:**
- 🔴 `sk-ibhealth`: auto-excluirse del escaneo de rutas muertas (excluir `$0` y el directorio de la propia skill)
- 🔴 `sk-ibhealth`: agregar módulo que extraiga las rutas `IB-*/...` declaradas en cada `SKILL.md` instalado y verifique que existen en el vault — convierte el health check en validador real de referencias
- 🔴 `sk-labpraxis`: corregir `PB-WERK-Werk` → `PB-WORX-Worx` y `CAS-EL-WERK-` → `CAS-EL-WORX-` (2 rutas en el SKILL.md)
- ⚪ Observado y no atendido: `worx-core` expone `arrancaroom`/`wx-arrancaroom` y `arrancaworx`/`wx-arrancaworx` como alias duplicados, y `ai-specialists` cuatro routers casi idénticos. El audit no los detecta porque busca la misma skill cargada dos veces, no alias dentro de un plugin. Descripciones que compiten degradan la precisión del disparo.

**Status:** 🔴 Abierto

→ NEXT[@Jay]: Corregir las rutas WERK→WORX en `sk-labpraxis/SKILL.md` y publicar la actualización del plugin `worx-governance`.
→ NEXT[@Alex]: Agregar a `sk-ibhealth` (a) auto-exclusión del detector de rutas muertas y (b) módulo nuevo de verificación de rutas declaradas — para cada `SKILL.md` instalado, extraer las referencias `IB-*/` y reportar las que no resuelven contra el vault montado.
→ NEXT[@Victor]: Decidir si los alias duplicados de `worx-core` (`arrancaroom` vs `wx-arrancaroom`) se retiran o se documentan como intencionales.

---

## 💬 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*