---
type: PL
asset_id: PL-METAPLAYBOOKS-EL-v01
version: v01
status: Draft
owner: Victor Heredia
sherpa_owner: Jay
fecha_creacion: 2026-05-20
fecha_ultima_actualizacion: 2026-05-20
fecha_migracion_bmf: 2026-05-20
intellbank: IB-XX-Maestro
subbank: MF-XX-MetaFactorias
proposito: PL · EL · IB-XX-Maestro
nota_migracion: Frontmatter BMF agregado en batch masivo 2026-05-20 · Workbench FASE 5C · proposito pendiente revisión manual
---

# Production Line — Meta Playbooks EmpowerLabs
## PL-METAPLAYBOOKS-EL-v01

---

## Asset Header

| Campo | Valor |
|-------|-------|
| **Asset ID** | `PL-METAPLAYBOOKS-EL-v01` |
| **Versión** | v01 |
| **Status** | Activo |
| **Tipo** | PL — Production Line (L4) |
| **Pipeline** | MPB-10 |
| **Blueprint origen** | `MF-EDITORIAL-v01` · Rama Master Playbooks |
| **Factory Instance** | `FI-ED-EL-v01` |
| **Owner** | Victor Heredia |
| **Operadora** | Anahí + SherpaXAnahí · Victor (arquitectura y aprobación) |
| **Gate final** | Victor Heredia (validación de arquitectura y contenido) |
| **Cadencia** | Según demanda — cuando se identifica una necesidad de nuevo sistema operativo |
| **Fecha de activación** | 2026-04-29 |

---

## I. QUÉ PRODUCE ESTA LÍNEA

Un **MetaPlaybook** es un documento de arquitectura operativa: define cómo funciona un sistema complejo — equipo, proceso, factoría o plataforma — con suficiente detalle para que pueda ser operado de forma reproducible por humanos y agentes de IA.

**Un MetaPlaybook NO es:**
- ❌ Un resumen de libro (eso es PL-RESUMENES)
- ❌ Un framework explicado para un lector (eso es PL-MASTERFORMULAS o PL-MASTERPLAYBOOKS)
- ❌ Contenido de marketing (eso es Demand Gen)

**Un MetaPlaybook SÍ es:**
- ✅ El "manual de operaciones" de un EmpowerTeam o una factoría
- ✅ La especificación técnica de cómo funciona un sistema de Victor
- ✅ Un documento que un agente de IA puede activar para operar de forma autónoma

**Ejemplos de MetaPlaybooks ya existentes:**
- `MF-BMF-GTM-v01` — EmpowerTeam Innovación & Go-to-Market (5 estaciones: Ideador → Evaluador → Productizador → DemandGen → Vendedor)
- `MF-BMF-CSherpa-v01` — C-Sherpas MetaFactory (7 roles + Coordinator)
- `MF-EDITORIAL-v01` — Blueprint de la Factoría Editorial (L2)

**Diferencia con Master Playbooks:**

| Aspecto | Master Playbook | MetaPlaybook |
|---------|----------------|--------------|
| Audiencia | ICP externo (CEO, Founder) | Equipo interno / Agentes de IA |
| Propósito | Transferir conocimiento para que el lector lo aplique | Especificar cómo opera un sistema |
| Formato | Libro / Guía para el lector | Arquitectura operativa / Documento técnico |
| Publicación | MasterPlaybooks.com (público) | Vault interno / EmpowerTeam (interno) |
| IP | Victor habla de su metodología | Victor diseña el sistema |

---

## II. INTERFAZ — ENTRADA Y SALIDA

### ENTRADA

```
Sistema a documentar: [nombre del EmpowerTeam o sistema]
Capa BMF: [L1 / L2 / L3 / L4]
Tipo de MetaPlaybook: [Domain MetaFactory / Factory Instance / Production Line / Blueprint de equipo]
Inputs del sistema: [qué entra al sistema]
Outputs del sistema: [qué produce el sistema]
Contexto: [notas de Victor, sesiones de diseño previas, borradores existentes]
```

### SALIDA

```markdown
---
asset_id: MF-[SISTEMA]-v01
tipo: MetaPlaybook
capa_bmf: L[N]
owner: Victor Heredia
status: Draft / Activo
fecha_creacion: YYYY-MM-DD
---

## [Nombre del sistema]

### 0. Propósito y Alcance
[Por qué existe este sistema y qué governa]

### 1. Arquitectura General
[Diagrama o tabla de las estaciones/roles/capas]

### 2. Estaciones del Pipeline
[Detalle de cada estación: input → proceso → output → artefacto canónico]

### 3. Contratos de Artefactos
[Qué produce exactamente cada estación y qué formato tiene]

### 4. Protocolos de Operación
[Cómo se activa, cómo se escala, cómo se pausa]

### 5. Gates de QA
[Criterios de PASS/FAIL por estación]

### 6. Governance
[Reglas, cadencia, WIP máximo, responsables]
```

---

## III. PIPELINE MPB-10

```
NECESIDAD DE NUEVO SISTEMA IDENTIFICADA
    │
    ▼
MPB1 — ACTIVACIÓN Y BRIEF (½ día — Victor)
    Victor define:
    · Nombre y propósito del sistema
    · Capa BMF (L1-L4)
    · Stakeholders (quién opera, quién gobierna, quién consume)
    · Output: Brief-MPB-[SISTEMA]-v01
    │
    ▼
MPB2 — INVESTIGACIÓN DE CONTEXTO (1 día)
    SherpaXAnahí investiga:
    · ¿Existe algún sistema similar ya documentado en el vault?
    · ¿Hay sesiones previas, dictados o borradores de Victor sobre este tema?
    · Principios de diseño BMF aplicables
    │
    ▼
MPB3 — ARQUITECTURA DE ALTO NIVEL (1 día — Victor + SherpaXAnahí)
    SherpaXAnahí construye:
    · Mapa de estaciones / roles / capas
    · Identificación de artefactos canónicos por estación
    · Gates de entrada y salida del sistema
    Victor valida la arquitectura antes de continuar
    │
    ▼
MPB4 — GATE VICTOR: ARQUITECTURA (1 h)
    · ¿Las estaciones son las correctas?
    · ¿Los artefactos son atómicos y reutilizables?
    · ¿El sistema opera sin Victor en el día a día?
    PASS → producción de detalle
    FAIL → rediseño de arquitectura
    │
    ▼
MPB5 — ESPECIFICACIÓN DE ESTACIONES (2-3 días)
    SherpaXAnahí produce por cada estación:
    · Protocolo de activación
    · Input requerido
    · Proceso paso a paso
    · Output y artefacto canónico
    · Criterios de QA (PASS / FAIL)
    │
    ▼
MPB6 — PROTOCOLOS DE OPERACIÓN (1 día)
    SherpaXAnahí redacta:
    · Cómo se activa el sistema completo
    · Cómo se escala (más WIP, más agentes)
    · Cómo se pausa o se hibernan estaciones
    · Reglas de governance y WIP máximo
    │
    ▼
MPB7 — REVISIÓN ANAHÍ (½ día)
    · ¿Puede operar la factoría siguiendo solo este documento?
    · ¿Hay ambigüedades o pasos incompletos?
    · ¿La voz es técnica pero comprensible para agentes de IA?
    │
    ▼
MPB8 — GATE VICTOR: DOCUMENTO COMPLETO (½ día)
    Victor revisa el MetaPlaybook completo:
    · ¿Gobierna correctamente el sistema?
    · ¿Las non-negotiables están explícitas?
    · ¿Un agente puede operarlo sin necesitar a Victor en el loop?
    PASS → publicar como activo oficial del vault
    FAIL → revisión y ajuste
    │
    ▼
MPB9 — ACTIVACIÓN Y PRUEBA (1 día)
    Anahí activa el sistema con SherpaXAnahí:
    · Prueba de fuego: ¿funciona como se especificó?
    · Ajustes menores si aplica
    │
    ▼
MPB10 — REGISTRO Y CONEXIÓN AL VAULT
    · Registro en LOG-PUB-EL-v01 (si es un activo publicado)
    · O registro en CP-ED-EL-v01 como activo interno activo
    · Conexión a wiki: actualizar entradas en IB-WikiX/Wiki/
    · Asset ID final: MF-[SISTEMA]-v01
```

**Tiempo total estimado:** 1-3 semanas por MetaPlaybook.

---

## IV. TIPOS DE METAPLAYBOOK

| Tipo | Descripción | Capa BMF | Ejemplo |
|------|-------------|---------|---------|
| **Domain MetaFactory** | Governa un dominio completo de actividad | L2 | MF-BMF-GTM-v01 |
| **Factory Instance Blueprint** | Especificación de una instancia de factoría | L3 | FI-ED-EL (blueprint) |
| **EmpowerTeam Operating Manual** | Manual operativo de un equipo SherpaX | L3 | C-Sherpas MetaFactory |
| **Production Line Blueprint** | Especificación técnica de una línea de producción | L4 | Este documento |

---

## V. REGLAS DE DISEÑO BMF PARA METAPLAYBOOKS

| Regla | Descripción |
|-------|-------------|
| **Non-negotiables explícitos** | Todo MetaPlaybook debe tener sus non-negotiables en la sección 0 |
| **Artefactos atómicos** | Cada estación produce UN artefacto canónico — no listas ni outputs ambiguos |
| **Gates que fallan** | Si un gate nunca produce FAIL, no es un gate — especificar criterios de FAIL |
| **Sin dependencia del owner** | El sistema debe operar sin Victor en el loop diario. Victor = cliente, no ejecutor |
| **Escalabilidad** | El MetaPlaybook debe especificar cómo escalar sin reescribir el documento |
| **Versionado** | Versión en el Asset ID — cuando cambia la arquitectura, sube versión |

---

## VI. BACKLOG — METAPLAYBOOKS IDENTIFICADOS

| Sistema | Tipo | Capa BMF | Status | Prioridad |
|---------|------|---------|--------|-----------|
| EmpowerTeam GTM | Domain MetaFactory | L2 | 🟡 Draft (MF-BMF-GTM-v01) | Alta — completar |
| C-Sherpas MetaFactory | EmpowerTeam Manual | L3 | 🟡 Draft (MF-BMF-CSherpa-v01) | Alta — completar |
| Factoría Editorial Blueprint | Factory Instance Blueprint | L3 | 🟡 Operativa sin doc formal | Media — formalizar |
| Re100X Operating System | Domain MetaFactory | L2 | 🔵 Pendiente | Media |
| SherpaX Onboarding | EmpowerTeam Manual | L3 | 🔵 Pendiente | Media |

---

## VII. GOVERNANCE

| Regla | Valor |
|-------|-------|
| Cadencia | Bajo demanda — cuando se activa un nuevo sistema o se rediseña uno existente |
| WIP máximo | 2 MetaPlaybooks simultáneos |
| Gate de Victor | MPB4 (arquitectura) + MPB8 (documento completo) — ambos obligatorios |
| Prueba de operatividad | Antes de declarar un MetaPlaybook "Activo", debe pasar por MPB9 |
| Registro | Activos internos → CP-ED-EL-v01; Activos publicables → LOG-PUB-EL-v01 |

---

## CHANGELOG

| Versión | Fecha | Cambio |
|---------|-------|--------|
| v01 | 2026-04-29 | Creación del PL — pipeline MPB-10 |

---

*PL-METAPLAYBOOKS-EL-v01 · Factoría Editorial EmpowerLabs · Anahí + SherpaXAnahí · Victor Heredia*
*Nota: Los MetaPlaybooks son el sistema nervioso del vault. Sin ellos, las factorías operan por inercia — con ellos, escalan sin depender de Victor.*