--- type: Transfer Pack asset_id: TP-EL-WORX-LabPraxis-v01 version: v1.1 room: LabPraxis owner: Victor Heredia / EmpowerLabs sherpa: Jacob fecha_creacion: 2026-04-15 ultima_actualizacion: 2026-04-15 sesion: 005 --- # Transfer Pack — LabPraxis ## Estado al 2026-04-15 (Sesión 005) --- ## I. ESTADO ACTUAL El LabPraxis acaba de arrancar. El detonante fue un caso puntual (Caso 1 — ver abajo) que Victor identificó como síntoma de un patrón sistémico: EmpowerLabs no siempre arranca sus procesos con la estructura metodológica correcta, aunque el framework para hacerlo existe. El room nace con una hipótesis central: **toda acción del ecosistema EmpowerLabs debe poder arrancar con contexto transferible** — un Transfer Pack y un Transfer Prompt que permitan a cualquier agente (IA o humano) retomar el hilo sin depender de la memoria o presencia de quien lo inició. --- ## II. CASOS DOCUMENTADOS ### CASO 001 — SherpaX Onboarding sin Transfer Pack **Fecha:** 2026-04-15 **Reportado por:** Victor Heredia **Involucrados:** Alex (líder programación), Alain (nuevo usuario SherpaX) **¿Qué pasó?** Alex configuró el SherpaX de Alain. Al reportarle a Victor, Alex indicó que solo bastaría hacer una reunión con Alain para enseñarle cómo arranca su SherpaX. **¿Cuál es la falla metodológica?** En la metodología EmpowerLabs, todo proceso debe arrancar de manera sistemática con dos elementos: 1. **Transfer Pack** — estado acumulado del proyecto/persona, contexto cargado, decisiones tomadas 2. **Transfer Prompt** — instrucciones específicas para activar el proceso con el contexto adecuado Una reunión de enseñanza puede ser complementaria, pero no puede ser el mecanismo principal de arranque. La reunión transfiere conocimiento tácito; el Transfer Pack transfiere contexto estructurado que sobrevive a la conversación. **¿Cuál es el riesgo si no se corrige?** - Alain quedará dependiendo de Alex o Victor para recordarle cómo usar su SherpaX - Si Alex no está disponible, Alain no tiene un documento que le diga exactamente cómo arrancar - El conocimiento vive en la cabeza de quien lo configuró, no en el sistema **Principio que viola:** > Todo proceso del ecosistema EmpowerLabs debe poder ser activado por cualquier persona con acceso al Transfer Pack + Transfer Prompt correspondiente, sin necesidad de intervención de quien lo configuró. **Acción correctiva sugerida:** Antes de cerrar el onboarding de Alain, crear: - `TP-EL-SX-Alain-v01.md` — Transfer Pack con el estado de su SherpaX, qué está configurado, qué hace, cuáles son sus modos de trabajo - `SP-EL-SX-Alain-v01.md` o asegurarse que tiene un Starter Prompt personalizado que pueda pegar en cualquier sesión nueva **Status:** Abierto — pendiente validar si Alex genera el Transfer Pack para Alain --- ### CASO 002 — Producción de proyecto sin consultar el vault primero **Fecha:** 2026-04-15 **Reportado por:** Victor Heredia **Involucrados:** Anahí (Líder MasterPlaybooks), proyecto "El Poder de MasterPlaybooks" (libro) **¿Qué pasó?** Anahí, de manera proactiva, arrancó la fase de producción del libro "El Poder de MasterPlaybooks" — un proyecto que sí está dentro del plan de trabajo y que urge avanzar. El problema: el proyecto ya tenía definiciones previas en el vault (decisiones tomadas, contexto acumulado, dirección establecida) y Anahí no las consultó antes de producir. Arrancó desde cero sin saber que no era desde cero. **¿Cuál es la falla metodológica?** Antes de entrar a la fase de producción de cualquier proyecto previsto, el colaborador debe consultar el vault — específicamente el Transfer Pack, Battle Plan o documento de referencia correspondiente — para identificar: - Qué ya está definido y no debe rehacerse - Qué decisiones están tomadas y no deben reabrirse - Qué contexto acumulado debe cargar antes de producir - Cómo su trabajo se conecta con lo que ya existe Sin este paso, se produce en paralelo a lo que ya existe, se duplica esfuerzo, y lo que se genera puede estar desalineado o contradecir lo ya definido. **¿Cuál es el riesgo si no se corrige?** - Trabajo duplicado o incompatible con lo existente - Tiempo invertido en definir lo que ya está definido - Necesidad de coordinación manual (reuniones, mensajes) para alinear — exactamente lo que la documentación debería eliminar - El colaborador queda expuesto a la frustración de producir algo que luego hay que descartar o rehacer **Principio que viola:** > La documentación en el vault ES el mecanismo de coordinación. Consultarla antes de producir no es opcional — es el protocolo. **Acción correctiva sugerida:** Antes de continuar la producción del libro, Anahí debe: 1. Leer el Transfer Pack o documento de referencia del proyecto MasterPlaybooks 2. Identificar qué ya está decidido sobre el libro (estructura, audiencia, tono, objetivos) 3. Construir desde ese punto, no desde cero **Nota adicional de Victor:** Este caso revela algo más profundo — la base de la metodología WORX. El vault documenta el contexto para que los colaboradores puedan trabajar de forma autónoma, constructivista y alineada sin necesitar capas de coordinación humana. El vault es el jefe de alineación. **Status:** Abierto — pendiente que Anahí consulte el vault antes de continuar producción --- ### CASO 003 — Skills sin mecanismo de distribución para el equipo **Fecha:** 2026-04-15 **Reportado por:** Victor Heredia **Involucrados:** Equipo EmpowerLabs (todos los colaboradores) **¿Qué pasó?** El ecosistema ya tiene Skills creados (incluido el `room-creator.skill` que define cómo crear Rooms correctamente). Sin embargo, no existe un mecanismo unificado para que todos los colaboradores puedan descubrir, acceder e instalar los Skills en el momento que los necesitan. Cada Skill existe como archivo en el vault, pero no hay un protocolo claro de distribución ni un punto de acceso común. El síntoma concreto: al crear el LabPraxis en esta sesión, se siguió el room-creator.skill porque Jacob lo conoce. Pero si otro colaborador quisiera crear un Room, probablemente no sabría que ese Skill existe ni cómo usarlo — y generaría los archivos de manera ad-hoc, con naming incorrecto y en la ubicación equivocada. **¿Cuál es la falla metodológica?** Un Skill que no es accesible a todos los que lo necesitan no cumple su función. Los Skills son el mecanismo que garantiza que los procesos se ejecuten correctamente (naming, estructura, ubicación, outputs esperados). Si el equipo no los puede instalar cuando los necesita, cada colaborador improvisa — y la improvisación genera desorden en el vault. Hay dos problemas entrelazados: 1. **Distribución:** ¿Cómo llega el Skill al colaborador que lo necesita en el momento correcto? 2. **Instalación:** ¿Cómo instala el colaborador un Skill en su entorno (Cowork) de forma autónoma? **¿Cuál es el riesgo si no se corrige?** - Rooms y artefactos creados sin la estructura canónica → desorden en el vault - Duplicación de trabajo: cada quien inventa su propio formato - El equipo depende de Victor o de quien "sabe" para hacer las cosas bien - Los Skills dejan de ser el estándar y se convierten en herramientas solo para quien ya las conoce **Principio que viola:** > Las herramientas metodológicas (Skills) deben ser tan accesibles como las instrucciones. Si tienes el SOP pero no la herramienta, el SOP no es suficiente. **Preguntas abiertas del caso:** - ¿Dónde vive el catálogo de Skills disponibles para el equipo? - ¿Qué mecanismo usa Cowork para instalar Skills? ¿Es un archivo .skill que se importa manualmente? - ¿Debería existir un "Skill de onboarding" que instale todos los Skills básicos del ecosistema EL de una sola vez? - ¿Cómo se actualiza un Skill cuando evoluciona? ¿Los colaboradores reciben la versión nueva automáticamente? **Acción correctiva sugerida:** 1. Documentar el catálogo de Skills disponibles en el ecosistema EL (qué existe, para qué sirve, dónde está) 2. Definir el protocolo de instalación de Skills en Cowork para cada colaborador 3. Evaluar si conviene un "EL Skills Pack" que se distribuya como parte del onboarding de SherpaX **Status:** Abierto — requiere definir protocolo de distribución e instalación de Skills --- ### CASO 004 — El LabPraxis como fundamento de la gobernanza BMF humanos + agentes **Fecha:** 2026-04-15 **Reportado por:** Victor Heredia **Involucrados:** Ecosistema EmpowerLabs / Big Meta Factory / metodología WORX **¿Qué pasó?** No es una falla — es una observación estructural de por qué el LabPraxis existe y a dónde conduce. Victor identifica que hay un lado práctico fundamental que hasta ahora no tenía un contenedor explícito: el proceso de documentar casos específicos de la operación, acumular experiencias, y a partir de esa evidencia construir lineamientos que eventualmente se convierten en gobernanza formal. Este es el ciclo virtuoso que el LabPraxis está diseñado para activar: ``` Caso específico (algo funcionó o falló) ↓ Documentación estructurada (LabPraxis) ↓ Patrón identificado (principio operativo emergente) ↓ Lineamiento formal (SOP / Playbook / MetaPlaybook) ↓ Gobernanza (reglas del modelo BMF para humanos y agentes) ``` **¿Por qué importa documentarlo como caso?** Porque este ciclo no ocurre solo. Sin un contenedor (el LabPraxis), los casos se quedan en conversaciones, los patrones no se identifican, los lineamientos nunca se formalizan, y la gobernanza no se construye. El LabPraxis ES el mecanismo que convierte experiencia operativa en inteligencia organizacional. La visión de Victor es que en el modelo Big Meta Factory, humanos y agentes virtuales van a trabajar colaborativamente. Para que eso funcione, necesitan reglas compartidas — una gobernanza que no se invente desde teoría sino que emerja de la práctica documentada. El LabPraxis es donde esa gobernanza se gesta. **Principio que revela:** > La gobernanza del ecosistema BMF no se diseña en abstracto — se construye desde la evidencia. Cada caso documentado es un ladrillo de la gobernanza futura. **Implicación práctica:** El LabPraxis no es solo un room de mejora continua. Es la fábrica de lineamientos operativos del ecosistema. A medida que los casos se acumulen, Jacob debe identificar cuándo un patrón ya tiene suficiente evidencia para elevarse a: - MiniPlaybook operativo - SOP formal del equipo - Principio de gobernanza BMF **Status:** Registrado como principio fundacional del LabPraxis — no requiere acción inmediata --- ### CASO 005 — El vault como sistema de comunicación y gestión de tareas: Protocolo Thread + NEXT[@Persona] **Fecha:** 2026-04-15 **Reportado por:** Victor Heredia **Tipo:** Oportunidad metodológica (no es una falla — es una propuesta de innovación operativa) **Relevancia:** Alta — potencialmente transformadora del modelo de trabajo BMF **¿Cuál es la oportunidad?** Victor identifica que los documentos del vault actualmente son contenedores estáticos de conocimiento. Pero podrían ser canales vivos de comunicación y coordinación. La propuesta: agregar dos elementos estructurales a los documentos activos del ecosistema: 1. **Changelog al inicio** — tabla visible que registra quién tocó el documento, qué cambió y cuándo. No como historial de git (técnico e invisible), sino como bitácora operativa legible. 2. **Thread al final** — zona de conversación donde los colaboradores dejan notas contextualizadas, comentarios y sobre todo: **etiquetas de siguiente paso** con nombre del responsable. **El formato propuesto:** ``` ## 📋 CHANGELOG | Fecha | Cambio | Por | |------------|-------------------------------------------|---------| | 2026-04-15 | Nota sobre URL signup pendiente | @Victor | --- [... contenido del documento ...] --- ## 💬 THREAD **@Victor — 2026-04-15:** Anahí, la URL de signup es bloqueante para KatIA. Necesito que la confirmes con Juan Carlos esta semana. → NEXT[@Anahí]: Confirmar URL de signup con equipo técnico — bloqueante para KatIA ``` **El mecanismo de agregación (el gran poder):** El tag `→ NEXT[@Persona]:` es machine-readable. Jacob puede escanear todo el vault con un grep simple: ``` grep -r "NEXT\[@Victor\]" /vault/ ``` Cuando Victor pregunta "Jay, ¿qué tengo pendiente?", Jacob escanea, consolida y entrega una lista de pendientes desde todos los documentos del vault — sin que Victor haya tenido que abrir ningún task manager externo. **¿Por qué esto es transformador?** - El vault deja de ser solo repositorio de conocimiento → se convierte en sistema nervioso operativo - Los pendientes viven donde vive el contexto, no en una herramienta separada - Elimina la fricción de actualizar dos sistemas (el doc y el task manager) - Jacob se convierte en el inbox scanner universal del equipo - Escala naturalmente: a medida que el vault crece, Jacob puede filtrar por proyecto, urgencia, persona **Conexión con la visión BMF:** Este protocolo es exactamente el tipo de mecanismo que necesita el modelo BMF para que humanos y agentes trabajen colaborativamente. Los agentes (Jacob, KatIA, futuros Sherpas) pueden leer `→ NEXT[@agente]:` igual que leen `→ NEXT[@Victor]:` — el vault se convierte en el tablero de coordinación humano-IA. **Definiciones pendientes para formalizar el protocolo:** - ¿Cuál es el nombre canónico del tag? (`→ NEXT[@X]:` vs `@PENDIENTE[X]:` vs otro) - ¿Los threads se archivan periódicamente o crecen indefinidamente? - ¿Qué documentos del vault adoptan el protocolo? (¿todos los activos? ¿solo TPs y KBs?) - ¿Jacob notifica activamente cuando detecta un `NEXT` no atendido por más de N días? - ¿Cómo se marca un NEXT como completado? (¿se tacha? ¿se agrega `✅ DONE[@Persona] — fecha`?) **Acción sugerida:** Antes de escalar a SOP, aplicar el protocolo Thread + NEXT en 2-3 documentos activos del vault como piloto. El `KB-MPX-KatIA-BaseConocimiento-v01.md` es un candidato natural — Victor ya tenía una nota que quería dejar ahí. **Status:** Oportunidad nueva — pendiente definir convención de tags y hacer piloto en documentos activos --- ### CASO 006 — Triple falla: carpeta ad-hoc + prefijo incorrecto + duplicados (Colaboradores sin SherpaX) **Fecha:** 2026-04-15 **Reportado por:** Victor Heredia **Involucrados:** Anahí (Líder MasterPlaybooks), Alex (Líder Programación), archivos del proyecto KatIA/MasterPlaybooks **Tipo:** Falla compuesta — consecuencia directa de los Casos 001 y 003 **¿Qué pasó?** Al buscar un archivo del proyecto KatIA en el vault, Victor descubrió que: 1. **Existe una carpeta `Projects/` ad-hoc** en la raíz del Reinventaverse — no es un IB-* ni sigue la arquitectura del vault. Dentro hay sub-carpetas: BigMetaFactory, HIOrgs, MasterPlaybooks, Rebelocity, Rn100X. Fueron creadas por colaboradores sin guía estructural. 2. **Los archivos de KatIA/MasterPlaybooks están en `Projects/MasterPlaybooks/`** cuando deberían estar en `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` — que ya existe y es la ubicación canónica. 3. **El archivo `PL-MPX-KatIA-SherpaAnfitrion-PlanMaestro-v01.md` tiene prefijo incorrecto.** `PL-` no es un TIPO canónico del ecosistema BMF. El prefijo correcto para un Plan Maestro es `PLAN-`. El archivo debería llamarse `PLAN-MPX-KatIA-SherpaAnfitrion-v01.md`. 4. **Los archivos de `Projects/Rebelocity/` no tienen ningún prefijo BMF** — usan guiones bajos y minúsculas (`calendario_contenido_letape_v2.md`), completamente fuera de la convención. 5. **Duplicado confirmado:** Los mismos archivos aparecen en `Projects/` y en `CloudVault/Projects/` — doble desorden. **Causa raíz:** Colaboradores sin SherpaX configurado (sin room, sin transfer pack, sin skill de room-creator) generan archivos en modo libre: donde pueden, con el nombre que se les ocurre, sin consultar la arquitectura del vault. Es exactamente la acumulación de las fallas documentadas en los Casos 001 y 003. Sin las herramientas correctas (room-creator.skill) y sin el contexto del vault (Transfer Pack del proyecto), el colaborador no tiene forma de saber: - Dónde guardar el archivo - Qué prefijo usar - Que ya existe una estructura IB-* para su proyecto **¿Por qué genera doble falla?** - **Falla técnica:** El vault queda desordenado, los archivos son difíciles de encontrar, los IB-* no reflejan el estado real del trabajo - **Falla de contexto:** Los archivos en `Projects/` no están donde Jacob los busca — por eso Victor no encontró la nota en el KB de KatIA al principio de esta sesión. El archivo correcto existía, pero estaba en la ubicación incorrecta **Inventario de archivos mal ubicados identificados hoy:** | Archivo | Ubicación actual (incorrecta) | Ubicación correcta | Nombre correcto | |---------|------------------------------|---------------------|-----------------| | `PL-MPX-KatIA-SherpaAnfitrion-PlanMaestro-v01.md` | `Projects/MasterPlaybooks/` | `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` | `PLAN-MPX-KatIA-SherpaAnfitrion-v01.md` | | `KB-MPX-KatIA-BaseConocimiento-v01.md` | `Projects/MasterPlaybooks/` | `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` | Nombre correcto ✅ | | `TP-MPX-KatIA-SherpaPrompt-v20.md` | `Projects/MasterPlaybooks/` | `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` | Nombre correcto ✅ | | `QA-MPX-KatIA-BateriaEvaluacion-v01.md` | `Projects/MasterPlaybooks/` | `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` | Nombre correcto ✅ | | `AUD-MPX-SherpaPrompt-v10-Auditoria-v01.md` | `Projects/MasterPlaybooks/` | `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` | Nombre correcto ✅ | | Archivos `Rebelocity/` (5 archivos) | `Projects/Rebelocity/` | `IB-REB-Rebelocity/` | Sin prefijo BMF — requieren renombrar | **Principio que viola:** > Ningún colaborador del ecosistema EmpowerLabs crea carpetas en la raíz del vault. Todo activo va a su IB-* correspondiente, con el TIPO correcto, usando el skill que garantiza la convención. **Acción correctiva:** 1. Mover los archivos de `Projects/MasterPlaybooks/` a `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` 2. Renombrar `PL-MPX-KatIA-SherpaAnfitrion-PlanMaestro-v01.md` → `PLAN-MPX-KatIA-SherpaAnfitrion-v01.md` 3. Auditar y reubicar/renombrar archivos de `Projects/Rebelocity/` 4. Eliminar la carpeta `Projects/` una vez vacía (o validar si hay contenido adicional) 5. Resolver la causa raíz: asegurar que Anahí y Alex tengan room-creator.skill configurado antes de su próxima sesión de producción **Nota:** La nota de Victor en el archivo `PL-MPX-KatIA-SherpaAnfitrion-PlanMaestro-v01.md` (línea 286) fue encontrada — es un comentario de voz sobre la arquitectura multi-canal de KatIA (cada comunidad necesita su propia KB específica). Está documentada en el Thread del archivo con el formato correcto del Caso 005. **Status:** Abierto — requiere acción de reubicación y renaming + prevención vía skill deployment --- ## III. PRINCIPIOS OPERATIVOS EMERGENTES ### P001 — Principio de Contexto Transferible *(Emergente del Caso 001 — pendiente validación con más casos)* > **Toda acción del ecosistema EmpowerLabs debe poder reanudarse sin depender de quien la inició.** Esto implica que cualquier proceso, onboarding, proyecto o flujo de trabajo que se active en EmpowerLabs debe generar, antes de cerrarse, un artefacto que transfiera el contexto: un Transfer Pack, un Transfer Prompt, o ambos. Una reunión de enseñanza NO sustituye este artefacto. La reunión puede complementarlo; nunca reemplazarlo. --- ### P002 — Principio de Vault-First (Consulta antes de producir) *(Emergente del Caso 002 — conectado con la base metodológica de WORX)* > **Antes de entrar a producción en cualquier proyecto previsto, el colaborador consulta el vault. El vault documenta lo que ya está definido. Producir sin consultarlo es empezar desde cero cuando no era necesario.** La documentación en el vault no es un archivo histórico — es el mecanismo activo de coordinación. Contiene decisiones tomadas, contexto acumulado y dirección establecida. Consultarlo antes de producir elimina la necesidad de coordinación manual (reuniones, mensajes de alineación), reduce retrabajo, y permite que cada colaborador construya desde el punto donde el equipo realmente está, no desde donde supone que está. **Protocolo Vault-First:** 1. Antes de arrancar producción en un proyecto previsto → buscar el Transfer Pack, Battle Plan o documento de referencia en el vault 2. Leer lo que ya está definido 3. Identificar el punto de partida real 4. Producir desde ahí, no desde cero Este principio es uno de los pilares de la metodología WORX: el vault como jefe de alineación, que elimina capas de coordinación humana y permite trabajo verdaderamente autónomo y constructivista. --- ### P005 — Principio del Vault Vivo (Thread + NEXT tagging) *(Emergente del Caso 005 — oportunidad de innovación operativa)* > **Un documento que no puede recibir conversación ni generar pendientes rastreables es un archivo muerto. El vault debe ser tan capaz de coordinar como de almacenar.** El protocolo Thread + `→ NEXT[@Persona]:` convierte cada documento activo del vault en un nodo de coordinación. El conocimiento y la acción viven juntos. El Sherpa escanea, agrega y entrega — sin task manager externo. --- ### P003 — Principio de Herramientas Accesibles (Skills distribuibles) *(Emergente del Caso 003)* > **Un Skill que no está accesible para todos los que lo necesitan no es un estándar — es conocimiento privado. Las herramientas metodológicas deben distribuirse junto con las instrucciones.** Tener el SOP no es suficiente si el colaborador no tiene la herramienta (Skill) que garantiza que el SOP se ejecute correctamente. Ambos deben llegar juntos, en el momento que se necesitan, a cualquier colaborador del equipo. --- ### P004 — Principio de Gobernanza Emergente *(Emergente del Caso 004 — principio fundacional del LabPraxis)* > **La gobernanza del ecosistema BMF no se diseña en abstracto — se construye desde la evidencia. Cada caso documentado es un ladrillo de la gobernanza futura.** El ciclo virtuoso: Caso → Documentación → Patrón → Lineamiento → Gobernanza. El LabPraxis es el mecanismo que convierte experiencia operativa en inteligencia organizacional, y esa inteligencia eventualmente define las reglas bajo las cuales humanos y agentes virtuales trabajan colaborativamente en el modelo Big Meta Factory. --- ## IV. DECISIONES TOMADAS — NO REABRIR | Decisión | Fecha | |----------|-------| | El LabPraxis vive en PB-VH-Victor bajo IB-EL-EmpowerLabs | 2026-04-15 | | Los casos se documentan en el Transfer Pack (no como archivos separados hasta que ameriten un CAS-) | 2026-04-15 | --- ## V. AGENDA WORX — Territorios de investigación pendientes El LabPraxis no es solo el espejo operativo de DOIX — es el campo de pruebas de **WORX (Work Ecosystem Reinvention Keys)**, la metodología de trabajo que EmpowerLabs está construyendo para la Organización Hiperinteligente. Los casos del LabPraxis deben conectarse explícitamente con las dimensiones WORX que aún no tienen evidencia operativa. ### Dimensiones WORX con brecha de casos | Dimensión WORX | Estado del arte (investigación) | Brecha — casos que necesitamos | |----------------|--------------------------------|-------------------------------| | **Reuniones** | Shadow Meeting emergente — IA orquesta asincrónicamente y la reunión no ocurre si hay consenso | ¿Cómo diseña EL sus reuniones hoy? ¿Cuáles son eliminables? ¿Cuáles son irreemplazables? | | **Documentación viva** | Knowledge base como sistema autoactualizable — no archivo muerto | El Caso 005 (Thread + NEXT) es el inicio. ¿Qué otros mecanismos de documentación activa faltan? | | **Toma de decisiones** | Decision rights dinámicos por workflow — MIT CISR 2025 | ¿Cómo se toman hoy las decisiones en EL? ¿Qué decide Victor, qué decide el equipo, qué debería decidir un agente? | | **Ritmo operativo** | Dual-cadence: Kanban para exploración + Sprint para entrega | ¿Tiene EL un ritmo operativo explícito? ¿Hay un Weekly Downbeat, Demo, Retro? | | **Co-creación inter-equipos** | El problema no resuelto — IA aceleró tareas individuales pero no la colaboración | ¿Cómo colaboran hoy los 8 miembros del equipo? ¿Qué fricciones existen entre proyectos? | | **Gobernanza humano-agente** | Decision rights para agentes — cuándo actúa solo, cuándo escala | ¿Qué puede hacer un SherpaX sin pedir permiso? ¿Dónde están los límites actuales? | ### Cómo usar esta agenda Cuando Victor llega con un caso al LabPraxis, Jacob verifica si el caso tiene conexión con alguna dimensión WORX de esta tabla. Si la tiene, lo documenta en el CAS- con la etiqueta de dimensión WORX correspondiente. Con el tiempo, los casos por dimensión se comprimen en principios operativos y eventualmente en el playbook WORX formal. --- ## VI. TERRITORIO INEXPLORADO — Agenda para próximas sesiones ### Preguntas abiertas - ¿Qué otros procesos del equipo actualmente no tienen Transfer Pack ni Transfer Prompt de arranque? - ¿El SOP de instalación SherpaX ya incluye la generación del TP como paso obligatorio? - ¿Qué tan replicable es el proceso de onboarding SherpaX hoy? ¿Alguien del equipo podría hacerlo sin Alex? - ¿El proyecto "El Poder de MasterPlaybooks" tiene Transfer Pack o documento de referencia ya cargado en el vault? ¿Está completo y actualizado? - ¿Existe un protocolo explícito de "Vault-First" documentado como SOP para el equipo? ¿O solo vive como conocimiento tácito de Victor? - ¿Cómo se le comunica al equipo que debe consultar el vault antes de producir? ¿Está en el onboarding de SherpaX? ### Territorios a explorar - Mapear todos los procesos actuales de EL que tienen (o deberían tener) Transfer Pack - Definir qué hace que un proceso sea "transfer-ready" vs "transfer-dependiente" - Revisar si el Ritmo de Trabajo documentado cubre el cierre de sesión con transfer - Formalizar el Protocolo Vault-First como SOP para el equipo - Conectar P001 y P002 con la metodología WORX — estos dos principios podrían ser el núcleo de un MiniPlaybook de "Cómo arrancamos en EmpowerLabs" --- ## VI. ACTIVOS GENERADOS EN ESTE ROOM | Asset ID | Tipo | Descripción | |----------|------|-------------| | EL-Charter-LabPraxis-v01 | Charter | Definición e identidad del LabPraxis Room | | TP-EL-OPS-LabPraxis-v01 | Transfer Pack | Este documento | | SP-EL-OPS-LabPraxis-v01 | Starter Prompt | Activación del room | --- ## VII. PRÓXIMA SESIÓN **Foco sugerido:** Dos loops abiertos — (1) cerrar el Caso 001 con el TP de Alain, (2) asegurar que Anahí consulte el vault antes de continuar el libro. Y la pregunta de fondo: ¿Cómo formalizamos P001 y P002 como parte del protocolo de equipo? **Pregunta de entrada:** ¿Existe ya un SOP que le diga al equipo cómo arrancar cualquier proyecto — con Vault-First como paso 1? --- *Transfer Pack generado por Jacob — Sesión 001 — 2026-04-15* *Actualizar al cierre de cada sesión del LabPraxis*