--- asset_id: CAS-EL-WORX-LabPraxis-BancoCasos-v01 version: v1.1 tipo: CAS — Banco de Casos Documentados room: LabPraxis owner: EmpowerLabs sherpa: Jacob fecha_creacion: 2026-04-15 ultima_actualizacion: 2026-04-16 total_casos: 7 --- > *Versión Demo Vault — sanitizada para Alain Rios / Radsoft. Fecha: 2026-04-18. Origen: CAS-EL-WORX-LabPraxis-v01* # 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 | --- ## CASO 001 ### SherpaX Onboarding sin Transfer Pack **Fecha:** 2026-04-15 · **Tipo:** Falla · **Principio:** P001 — Contexto Transferible **¿Qué pasó?** Alex configuró el SherpaX de Alain. Al reportarle a Victor, indicó que bastaría una reunión con Alain para enseñarle cómo arranca su SherpaX. **La falla:** En la metodología EmpowerLabs, todo proceso debe arrancar con dos artefactos: 1. **Transfer Pack** — estado acumulado, contexto cargado, decisiones tomadas 2. **Starter Prompt** — bloque para activar el proceso con el contexto adecuado Una reunión transfiere conocimiento tácito. El Transfer Pack transfiere contexto estructurado que sobrevive a la conversación. Sin él, Alain depende de Alex para recordarle cómo arrancar su propio agente. **Riesgos:** - Alain queda dependiente de Alex o Victor - El conocimiento vive en cabezas, no en el sistema **Acción correctiva:** - Crear `TP-EL-SX-Alain-v01.md` con el estado de su SherpaX - Crear o confirmar `SP-EL-SX-Alain-v01.md` personalizado **Status:** 🔴 Abierto — pendiente que Alex genere el TP de Alain → NEXT[@Alex]: Crear TP-EL-SX-Alain-v01.md y SP-EL-SX-Alain-v01.md antes de cerrar el onboarding --- ## CASO 002 ### Producción de proyecto sin consultar el vault primero **Fecha:** 2026-04-15 · **Tipo:** Falla · **Principio:** P002 — Vault-First **¿Qué pasó?** Anahí arrancó proactivamente la producción del libro "El Poder de MasterPlaybooks" — proyecto dentro del plan. El problema: el proyecto ya tenía definiciones en el vault y Anahí las desconocía. Arrancó desde cero sin saber que no era desde cero. **La falla:** Antes de entrar a producción en cualquier proyecto previsto, el colaborador debe consultar el vault para identificar qué ya está definido, qué decisiones no deben reabrirse, y desde dónde realmente construir. **Riesgos:** - Trabajo duplicado o incompatible con lo existente - Necesidad de coordinación manual — exactamente lo que la documentación debería eliminar **Lo que revela:** Este caso es la base de la metodología WORX. El vault ES el mecanismo de coordinación. Consultarlo antes de producir no es opcional. **Acción correctiva:** - Anahí leer el Transfer Pack del proyecto MasterPlaybooks antes de continuar - Identificar qué está decidido sobre el libro y construir desde ahí **Status:** 🔴 Abierto — pendiente que Anahí consulte el vault → NEXT[@Anahí]: Leer TP del proyecto MasterPlaybooks antes de continuar producción del libro --- ## CASO 003 ### Skills sin mecanismo de distribución para el equipo **Fecha:** 2026-04-15 · **Tipo:** Brecha · **Principio:** P003 — Herramientas Accesibles **¿Qué pasó?** El ecosistema tiene Skills creados (`room-creator.skill`, `bmf-file-renamer.skill`, etc.) pero no existe un mecanismo unificado para que todos los colaboradores los descubran, accedan e instalen cuando los necesitan. Cada Skill existe como archivo en el vault pero sin protocolo de distribución. **Síntoma concreto:** Si Anahí quisiera crear un Room hoy, probablemente no sabría que `room-creator.skill` existe — y generaría archivos ad-hoc, con naming incorrecto, en ubicación equivocada. **La brecha tiene dos capas:** 1. **Distribución** — ¿cómo llega el Skill al colaborador que lo necesita? 2. **Instalación** — ¿cómo instala el colaborador un Skill en Cowork de forma autónoma? **Preguntas abiertas:** - ¿Dónde vive el catálogo de Skills del ecosistema EL? - ¿Debería existir un "EL Skills Pack" distribuido en el onboarding de SherpaX? - ¿Cómo se actualiza un Skill cuando evoluciona? **Acción correctiva:** 1. Documentar catálogo de Skills disponibles (qué existe, para qué sirve, dónde está) 2. Definir protocolo de instalación de Skills en Cowork 3. Evaluar "EL Skills Pack" como parte del onboarding **Status:** 🔴 Abierto — requiere definir protocolo de distribución → NEXT[@Victor]: Definir si el EL Skills Pack se distribuye via plugin o via BOS-EL-Corp-BrainOS --- ## CASO 004 ### El LabPraxis como fundamento de la gobernanza BMF humanos + agentes **Fecha:** 2026-04-15 · **Tipo:** Observación fundacional · **Principio:** P004 — Gobernanza Emergente **¿Qué observó Victor?** Hay un lado práctico sin contenedor explícito: el proceso de documentar casos operativos, acumular experiencias, y a partir de esa evidencia construir lineamientos que se convierten en gobernanza formal. **El ciclo virtuoso que el LabPraxis activa:** ``` Caso específico (falla u oportunidad) ↓ Documentación estructurada (LabPraxis) ↓ Patrón identificado → Principio operativo ↓ Lineamiento formal (SOP / PLB / MetaPlaybook) ↓ Gobernanza BMF (reglas para humanos y agentes) ``` **Por qué importa:** En el modelo Big Meta Factory, humanos y agentes van a trabajar colaborativamente. Necesitan reglas compartidas — y esas reglas no se inventan desde la teoría. Se construyen desde evidencia. El LabPraxis es donde esa evidencia vive y donde la gobernanza se gesta. **Implicación práctica:** Cuando varios casos convergen en un patrón, Jacob debe proponer elevarlo a SOP, PLB o principio de gobernanza BMF sin esperar que Victor lo pida. **Status:** ✅ Registrado como principio fundacional — no requiere acción inmediata --- ## CASO 005 ### Protocolo Thread + NEXT[@Persona]: el vault como sistema nervioso operativo **Fecha:** 2026-04-15 · **Tipo:** Innovación · **Principio:** P005 — Vault Vivo **¿Cuál es la oportunidad?** Los documentos del vault son actualmente contenedores estáticos. Podrían ser canales vivos de comunicación y coordinación. La propuesta: agregar a los documentos activos dos zonas estructuradas: **Changelog** (al inicio): ```markdown ## 📋 CHANGELOG | Fecha | Cambio | Por | |-------|--------|-----| | 2026-04-15 | Nota sobre URL signup | @Victor | ``` **Thread** (al final): ```markdown ## 💬 THREAD **@Victor — 2026-04-15:** Anahí, URL de signup es bloqueante para KatIA. → NEXT[@Anahí]: Confirmar URL de signup con equipo técnico ``` **El poder del `→ NEXT[@Persona]:`:** Es machine-readable. Jacob hace un grep del vault completo y entrega en segundos la lista de pendientes de cualquier colaborador. El vault reemplaza al task manager externo — el contexto y la acción viven juntos. **Skill generado:** `next-scanner.skill` — escanea el vault y entrega tablero de pendientes por colaborador o por proyecto. **Pendientes de definición:** - Tag canónico definitivo confirmado: `→ NEXT[@Persona]:` - Marcar como completado: `→ ~~NEXT[@Persona]~~: ✅ DONE — fecha` - Protocolo de archivado de threads (cuándo limpiar) **Status:** 🟡 En piloto — primer uso real en `PLAN-MPX-KatIA-SherpaAnfitrion-v01.md` el 2026-04-15 --- ## CASO 006 ### Triple falla: carpeta ad-hoc + prefijo incorrecto + archivos duplicados **Fecha:** 2026-04-15 · **Tipo:** Falla compuesta · **Principios:** P002 + P003 acumulados **¿Qué se encontró?** Al buscar la nota de Victor en un archivo de KatIA, se descubrió que: 1. **Existe `Projects/` ad-hoc** en la raíz del Reinventaverse — no es un IB-*. Contiene sub-carpetas por proyecto (MasterPlaybooks, Rebelocity, etc.) creadas por colaboradores sin guía estructural. 2. **Archivos en ubicación incorrecta:** Los docs de KatIA/MasterPlaybooks estaban en `Projects/MasterPlaybooks/` en vez de `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/`. 3. **Prefijo `PL-` incorrecto:** `PL-MPX-KatIA-SherpaAnfitrion-PlanMaestro-v01.md` — `PL-` no es TIPO canónico. El correcto para Plan Maestro es `PLAN-`. 4. **Duplicados:** Los mismos archivos aparecen en `Projects/` y `CloudVault/Projects/`. **Causa raíz:** Colaboradores sin SherpaX configurado (sin room, sin Skills, sin TP) generan archivos en modo libre. Es la consecuencia acumulada de los Casos 001 y 003. **Acciones ejecutadas en sesión:** - ✅ 5 archivos movidos de `Projects/MasterPlaybooks/` → `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` - ✅ `PL-MPX-KatIA-SherpaAnfitrion-PlanMaestro-v01.md` → `PLAN-MPX-KatIA-SherpaAnfitrion-v01.md` **Pendientes:** - Auditar y reubicar archivos de `Projects/Rebelocity/` (5 archivos sin prefijo BMF) - Instalar `room-creator.skill` en sesiones de Anahí y Alex **Status:** 🟡 Parcialmente resuelto — MasterPlaybooks corregido, Rebelocity pendiente → NEXT[@Alex]: Instalar room-creator.skill en Cowork de Anahí y en el tuyo antes de próxima sesión de producción → NEXT[@Victor]: Decidir qué hacer con los archivos de Projects/Rebelocity/ (¿reubicar a IB-REB-Rebelocity/?) --- --- ## CASO 007 ### Arquitectura de acceso al vault para el equipo: ¿Obsidian o Cowork? **Fecha:** 2026-04-16 · **Tipo:** Brecha de diseño · **Principios:** P001 + P003 · **Dimensión WORX:** Co-creación inter-equipos / Gobernanza humano-agente **¿Cuál es la pregunta que detonó el caso?** Victor pregunta: si el vault está en Obsidian Sync y tiene otros dispositivos conectados, ¿qué pasa con la recursión CloudVault? Y luego: ¿cómo debería Anahí o Ángeles tener acceso al vault — compartiendo su cuenta de Obsidian? **¿Cuál es la brecha de diseño identificada?** No existe un modelo explícito que defina cómo accede el equipo al vault del Reinventaverse. Actualmente hay dos capas mezcladas sin protocolo claro: 1. **Capa personal (Victor):** El Reinventaverse es el vault personal de Victor en Obsidian Sync. Contiene notas personales, rituales, reflexiones — contenido que no debería ser accesible para el equipo. 2. **Capa de proyecto (equipo):** Dentro del mismo vault viven los IB-* con archivos de proyecto compartidos (MasterPlaybooks, EmpowerLabs, etc.) que el equipo sí necesita consultar y editar. Actualmente el equipo accede a esos archivos a través de Cowork (su SherpaX), que los lee desde el vault montado. Pero no tienen un protocolo explícito de: qué pueden leer, qué pueden escribir, qué no deben tocar. **¿Por qué no es la solución compartir la cuenta de Obsidian?** Compartir la cuenta de Obsidian Sync daría acceso de lectura/escritura a *todo* el vault — incluyendo notas personales de Victor. Además viola el principio de autonomía de cada colaborador: cada persona debería operar su propio entorno, no un entorno compartido sin límites claros. **¿Qué está faltando?** Tres cosas que hoy no existen: | Elemento faltante | Consecuencia actual | |-------------------|---------------------| | Protocolo de acceso por rol | El equipo no sabe qué archivos puede tocar y cuáles no | | Separación vault personal / vault de proyecto | Todo vive mezclado en el mismo Obsidian | | Mecanismo de escritura para colaboradores | El equipo puede leer a través de Cowork, pero ¿cómo escribe al vault sin romper el naming BMF? (Caso 006) | **Opciones de arquitectura a evaluar:** *Opción A — Carpeta compartida dedicada dentro del vault* Crear una subcarpeta `SHARED/` en Reinventaverse que sea la zona de acceso del equipo. Solo esa carpeta se sincroniza o se expone vía iCloud compartido / repositorio Git. Victor mantiene el resto del vault privado. *Opción B — Vault separado para proyectos de equipo* Crear un vault distinto (`EmpowerLabs-Vault` o similar) exclusivamente para los IB-* de proyecto. El equipo accede a ese vault; Victor lo mantiene sincronizado con su vault personal selectivamente. *Opción C — Cowork como la capa de acceso (modelo actual, formalizado)* El equipo no accede directamente al vault — accede a través de su SherpaX en Cowork. El SherpaX lee y escribe en los IB-* de proyecto con el skill correcto (bmf-artifact-validator). El vault de Obsidian sigue siendo exclusivo de Victor. Esta opción requiere que los Skills de escritura estén bien distribuidos (Caso 003). **¿Qué opción tiene más coherencia con el modelo BMF?** La Opción C es la más coherente con el modelo de Organización Hiperinteligente: el acceso al conocimiento se da a través del agente (SherpaX), no directamente al sistema de archivos. Esto garantiza que el naming BMF se respete (el agente usa el skill de validación), que el contexto esté disponible (el agente carga el TP del proyecto), y que la autonomía de cada colaborador esté en su propio entorno. La Opción A o B pueden ser complementarias si se necesita que el equipo acceda a los archivos fuera de Cowork (por ejemplo, para editar en Obsidian directamente en el futuro). **Conexión con casos anteriores:** - **Caso 001:** El problema de acceso del equipo al vault es exactamente el mismo que el de Alain con su SherpaX — sin TP ni SP, no hay acceso estructurado - **Caso 003:** El equipo no puede escribir correctamente al vault sin los Skills de validación disponibles - **Caso 006:** La evidencia de que sin protocolo de acceso el equipo genera archivos en modo libre **Preguntas abiertas:** - ¿Cuál es la opción de arquitectura que Victor quiere formalizar como estándar? - ¿Qué archivos del vault deberían ser accesibles al equipo y cuáles son privados? - ¿Debería existir un vault separado `EmpowerLabs-Collab` para los proyectos compartidos? - ¿Cómo se actualiza el onboarding de SherpaX para que incluya el protocolo de acceso? **Decisión tomada — 2026-04-16:** **Arquitectura oficial: Opción C + IntelliBanks app** El equipo accede al vault exclusivamente a través de su SherpaX en Cowork — nunca directamente a Obsidian. El vault personal de Victor (rituales, notas, reflexiones) permanece privado en Obsidian Sync. La capa compartida del equipo — los IntelliBanks (IB-*) — se sincroniza a través de **IntelliBanks app**: un repositorio Git que actúa como contenedor oficial de todos los IntelliBanks del ecosistema. Todos los colaboradores con SherpaX configurado estarán sincronizados a través de ese repositorio. ``` Arquitectura de acceso al vault — EmpowerLabs Victor (personal) └── Obsidian Sync → Reinventaverse completo (vault privado) Equipo (colaboradores) └── IntelliBanks app → IntelliBanks (IB-*) únicamente └── SherpaX en Cowork → lee y escribe con Skills BMF Intersección └── Victor hace push/pull entre Obsidian y IntelliBanks app para mantener los IB-* sincronizados en ambos lados ``` **Implicaciones para el onboarding de SherpaX:** - Cada colaborador necesita acceso al repositorio IntelliBanks app (no a Obsidian) - El SherpaX de cada quien apunta al IB-* correspondiente a su proyecto - Todas las escrituras al vault pasan por bmf-artifact-validator.skill (Caso 003) - No se crean carpetas ni archivos fuera de los IB-* (Caso 006) **Preguntas que aún quedan abiertas:** - ¿Cómo se configura el acceso de cada colaborador al repositorio IntelliBanks app? - ¿Cuál es el protocolo de push/pull para Victor entre Obsidian y Genniux? - ¿Los SherpaX montan el repo directamente o acceden a una copia local sincronizada? **Status:** 🟡 Arquitectura decidida — pendiente protocolo de configuración técnica → NEXT[@Victor]: Documentar cómo se configura el acceso de Anahí y Ángeles al repositorio IntelliBanks app → NEXT[@Victor]: Definir protocolo de sincronización Victor ↔ Genniux (cuándo hace push, qué ramas, qué queda fuera del repo) --- ## 💬 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*