--- asset_id: MePB-XX-XPack-Schema-v01 version: v01 tipo: MePB — MetaPlaybook (Fórmula Maestra) clase: C — Canónico owner: Victor Heredia / EmpowerLabs fecha_creacion: 2026-04-21 fecha_ultima_actualizacion: 2026-04-21 estado: 🟢 Activo — v01 inaugural tags: [XPack, XDoc, WORX, BMF, gestión, coordinación] --- # MePB-XX — XPack Schema Canónico ## La unidad de gestión de proyectos del ecosistema BMF --- ## 0. POR QUÉ EXISTE EL XPACK El ecosistema BMF usa dos tipos de documentos de proyecto que hasta ahora convivían bajo el mismo prefijo (TP-): | Antes | Problema | |-------|----------| | TP- como documento vivo del proyecto | Mezcla contexto operativo con función de transferencia | | TP- como mecanismo de handoff | Se contamina con estado operativo que no es su función | **La solución es separar dos funciones en dos documentos:** ``` XPack (XP-) — documento vivo del proyecto · Estructura XDoc completa (7 secciones) · Se mantiene durante toda la vida del proyecto · Es la fuente de verdad operativa TP (TP-) — snapshot de transferencia · Ligero y específico · Se genera DESDE el XPack cuando se necesita · Arrancar un room nuevo · Retomar tras split de conversación · Handoff a agente especializado ``` **Regla de oro:** el TP nunca se mantiene directamente. Se genera desde el XPack. El XPack es la fuente; el TP es una vista derivada. --- ## 1. DEFINICIÓN Un **XPack** es el documento operativo central de un proyecto o portafolio dentro del BMF. Hereda la estructura XDoc de WORX (7 secciones fijas, reglas de escritura por sección, append-only donde aplica) y agrega la sección **ASSETS** — el inventario de activos del proyecto — que lo distingue del XDoc genérico. **Dos modos de uso:** | Modo | Descripción | Ejemplo | |------|-------------|---------| | **Proyecto** | Un XPack por proyecto específico | `XP-EL-MM-ProyectoMarcovich-v01` | | **Portafolio** | Un XPack que agrupa proyectos relacionados | `XP-EL-Portfolio-SherpaX-v01` | --- ## 2. NAMING CONVENTION ``` XP-[ENTIDAD]-[Proyecto]-[NombreDescriptivo]-vNN.md ``` **Ejemplos:** - `XP-EL-MM-ProyectoMarcovich-v01.md` - `XP-EL-WORX-PilotoEmpowerLabs-v01.md` - `XP-EL-Portfolio-SherpaX-v01.md` - `XP-EL-Portfolio-R100X-DemandGen-v01.md` **Regla de ubicación:** - XPack de proyecto → vive en la carpeta del proyecto (`PB-EL-Project-Bank/PB-[COD]-[Nombre]/`) - XPack de portafolio → vive en la raíz del Project Bank o en `PB-VH-Victor/` --- ## 3. FRONTMATTER CANÓNICO ```yaml --- asset_id: XP-[ENTIDAD]-[Proyecto]-[Nombre]-vNN version: vNN tipo: XP — XPack modo: proyecto | portafolio room: [nombre del room que activa] owner: [persona o agente responsable operativo] sponsor: [persona humana — autoridad final] runners: [lista de runners activos] brain_codes: [BC-... asesores declarados] cadencia: kanban | sprint | mixta estado: 🟢 Activo | 🟡 En pausa | 🔴 Urgente | ✅ Cerrado fase: [fase actual del proyecto] cliente: [si aplica] fecha_creacion: YYYY-MM-DD fecha_ultima_actualizacion: YYYY-MM-DD continua_desde: [TP o XP previo si hay migración] --- ``` --- ## 4. LAS 7 SECCIONES El orden es fijo. No se agregan ni eliminan secciones. | § | Sección | Quién escribe | Regla de oro | |---|---------|---------------|--------------| | 1 | **BRIEF** | Owner | Propósito, resultado esperado, alcance, stakeholders. Casi nunca cambia. Si cambia de forma material, se cierra el XPack y se abre uno nuevo. | | 2 | **ESTADO** | Owner / Runner | Salud (🟢🟡🔴), fase activa, último hito, dependencias, bloqueos. Se actualiza en cada movimiento material. Un ESTADO desactualizado es ruido sistémico. | | 3 | **ASSETS** | Owner / Runner | Inventario de activos del proyecto con tipo, versión y estado. Append-only de activos; el estado de cada uno sí se edita. | | 4 | **NEXT** | Cualquiera agrega / asignado cierra | Formato: `NEXT[@Persona] — acción — deadline — contexto → estado`. Solo el @Persona asignado cierra. Un NEXT solo cierra con entrada de CHANGELOG que lo referencia. | | 5 | **DISCUSSION** | Cualquiera | Conversación exploratoria async, append-only, con timestamp + autor. Cuando aterriza → se promueve a NEXT o CHANGELOG. Ninguna decisión vinculante vive solo aquí. | | 6 | **CHANGELOG** | Quien ejecuta / decide / aprende | Append-only. Inmutable. Tags: `[EXEC]` `[DECIDE]` `[LEARN]` `[RUNNER]`. Todo `[DECIDE]` requiere firma humana. Si el Owner es agente, requiere co-firma del Sponsor. | | 7 | **CIERRE** | Owner + Sponsor | Solo se escribe al cerrar el XPack. Aprendizajes, evidencia final, destino de los activos, razón del cierre. | --- ### §1 BRIEF — por qué existe el XPack ``` ## BRIEF **Misión:** [en una línea — qué transforma este proyecto] **Resultado esperado:** [qué existe cuando este XPack cierra] **Alcance:** [qué incluye / qué no incluye] **Stakeholders:** - Owner: [nombre] - Sponsor: [nombre] - Cliente / beneficiario: [si aplica] **Brain Codes asesores:** [BC-... declarados] **Continúa desde:** [referencia si hay contexto previo] ``` --- ### §2 ESTADO — dónde estamos ahora ``` ## ESTADO **Salud:** 🟢 / 🟡 / 🔴 **Fase:** [nombre de la fase actual] **Hito activo:** [qué se está construyendo ahora] **Último movimiento:** [YYYY-MM-DD — qué pasó] **Próxima decisión clave:** [qué necesita resolverse] **Dependencias:** - [DECISIÓN] [descripción] — @[responsable] — estado: abierta / satisfecha - [DOC] [activo esperado] — estado: en curso / bloqueado / entregado - [PERSONA] [acción de tercero] — estado: pendiente / confirmado **Bloqueos activos:** [ninguno / descripción] ``` --- ### §3 ASSETS — inventario de activos ``` ## ASSETS | Asset ID | Tipo | Descripción | Estado | |----------|------|-------------|--------| | [TIPO-ENT-Nombre-vNN] | [tipo] | [descripción breve] | Draft / Active / Archived | | ... | | | | **Activos pendientes de crear:** - [ ] [TIPO-ENT-Nombre-vNN] — [descripción] — responsable: @[Runner] ``` --- ### §4 NEXT — qué sigue ``` ## NEXT NEXT[@Persona] — [acción concreta] — [deadline] — [contexto] → [estado] --- Ejemplos: NEXT[@Victor] — VoBo propuesta MM — 2026-04-22 — revisar PROP-EL-MM-PropuestaFases-v01 → abierto NEXT[@Jay] — generar TP de sesión con MM — post-VoBo → bloqueado por NEXT anterior ``` **Reglas:** - Cualquiera puede agregar un NEXT - Solo el @Persona asignado lo cierra - Un NEXT solo cierra con entrada CHANGELOG que lo referencia - Las dependencias estructurales van en ESTADO, no aquí --- ### §5 DISCUSSION — exploración async ``` ## DISCUSSION [YYYY-MM-DD @Persona] — [observación / pregunta / hipótesis] → [respuesta o continuación] → [PROMOVIDO A: NEXT#N / CHANGELOG] cuando aterriza ``` --- ### §6 CHANGELOG — registro inmutable ``` ## CHANGELOG [YYYY-MM-DD @Persona] [TAG] — [descripción] · Evidencia: [link a activo / decisión / entrada de otro XDoc] · Cierra: NEXT#N (si aplica) Tags canónicos: [EXEC] — algo se ejecutó / entregó [DECIDE] — decisión vinculante (requiere firma humana) [LEARN] — aprendizaje capturado (candidato a LabPraxis) [RUNNER] — pase de balón entre runners (con razón + handoff) ``` --- ### §7 CIERRE — cuando el XPack termina ``` ## CIERRE **Fecha de cierre:** YYYY-MM-DD **Razón:** [completado / cancelado / absorbido por XPack#N / pivot] **Resultado final:** [qué existe como evidencia] **Activos finales:** [lista de activos entregados con su estado] **Aprendizajes clave:** 1. [aprendizaje] 2. [aprendizaje] **Candidatos a LabPraxis:** [si hay entradas [LEARN] que ameritan documentación] **Archivado en:** [ruta del activo si se archiva] ``` --- ## 5. RELACIÓN TP ↔ XPACK El TP se genera DESDE el XPack. Nunca al revés. ``` XPack (XP-) │ ├─── [agente lee §1 BRIEF + §2 ESTADO + §4 NEXT] │ └─── genera TP específico para: · Arrancar un room nuevo · Retomar conversación tras split · Handoff a agente especializado · Briefing para colaborador externo ``` **El agente puede generar un TP desde el XPack en cualquier momento.** El comando natural es: > "Genera el TP de [proyecto] para [propósito]" El TP resultante es ligero — contiene solo el contexto necesario para ese propósito específico, extraído del XPack en su estado actual. --- ## 6. PROTOCOLO DE CREACIÓN Cuando nace un proyecto nuevo: 1. **Crear XPack** como primer activo (antes que cualquier otro documento) 2. **Completar §1 BRIEF** con la misión y alcance mínimos conocidos 3. **Completar §2 ESTADO** con la fase de arranque 4. **Declarar el primer NEXT** con la acción inmediata 5. **Registrar en CHANGELOG** `[EXEC] — XPack creado. Room activado.` 6. El TP se genera desde el XPack cuando se necesita — no se crea manualmente **Nota de migración:** los TPs existentes no se migran forzosamente. Los proyectos activos pueden crear su XPack cuando sea natural (siguiente sesión significativa). Los proyectos históricos permanecen con TP como referencia. --- ## 7. TEMPLATE INSTANTIABLE Copiar y pegar para crear un XPack nuevo: ```markdown --- asset_id: XP-[ENTIDAD]-[Proyecto]-[Nombre]-v01 version: v01 tipo: XP — XPack modo: proyecto room: [nombre del room] owner: [nombre] sponsor: [nombre] runners: [] brain_codes: [] cadencia: kanban estado: 🟢 Activo fase: Arranque fecha_creacion: YYYY-MM-DD fecha_ultima_actualizacion: YYYY-MM-DD --- # XPack — [Nombre del Proyecto] --- ## BRIEF **Misión:** **Resultado esperado:** **Alcance:** **Stakeholders:** - Owner: - Sponsor: **Brain Codes asesores:** --- ## ESTADO **Salud:** 🟢 **Fase:** Arranque **Hito activo:** **Último movimiento:** [YYYY-MM-DD — XPack creado] **Próxima decisión clave:** **Dependencias:** ninguna declarada **Bloqueos activos:** ninguno --- ## ASSETS | Asset ID | Tipo | Descripción | Estado | |----------|------|-------------|--------| | — | — | Sin activos aún | — | **Activos pendientes de crear:** - [ ] --- ## NEXT NEXT[@] — — — → abierto --- ## DISCUSSION — --- ## CHANGELOG [YYYY-MM-DD @Owner] [EXEC] — XPack creado. Room activado. · Primer activo del proyecto. --- ## CIERRE *(pendiente — se completa al cerrar el XPack)* ``` --- *MePB-XX-XPack-Schema-v01 · IB-XX-Maestro / FM-XX-Formulas-Maestras · 2026-04-21* *MetaPlaybook Clase C — Fórmula canónica del XPack en el ecosistema BMF* *Basado en: DC-XX-WORX-DocumentoCentral-v01 (arquitectura XDoc WORX)*