---
type: MePB
asset_id: MePB-EL-WarRoom-WargamingPlaybook-v01
version: v01
status: Activo — canónico del método (validado con 4 pilotos + sesión de equipo)
owner: Victor Heredia
sherpa_owner: Jay
ratificador: Victor Heredia (L3+)
fecha_creacion: 2026-07-06
intellbank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank/PB-EL-IALab/WG-EL-WarRoom
proposito: Playbook canónico del método de Wargaming EmpowerLabs — simulación adversarial pre-mortem de misiones, convertida en contratos de misión ejecutables por modelos/agentes más baratos o humanos. Consolida el método, la anatomía WG-, el SOP de equipo, los aprendizajes de los 4 pilotos y el principio P022.
deriva_de: ANA-EL-WargamingPlaybook-SintaxisBMF-v01 (análisis de la fuente externa + traducción BMF)
relacionados: SOP-EL-WarRoom-WargamingEquipo-v01 · CAS-EL-WORX-LabPraxis-BancoCasos-v01 (CASO 026 · P022) · IDE-057–061
tags: [mepb, wargaming, warroom, pre-mortem, metodo, canonico]
---

# MePB — Wargaming Playbook EmpowerLabs
## Simular la falla antes de ejecutar · convertir inteligencia cara en activos permanentes

---

## 1. Qué es y por qué existe

**Wargaming** = simulación adversarial pre-mortem de una misión: en lugar de planear el camino donde todo sale bien (cielo azul), se pelea la misión en papel move-by-move — qué se observa si funcionó VS si falló, cuál es la causa de falla más probable, cuál es el contramove, qué forks existen y cuándo se aborta todo.

**Los dos productos del método:**
1. **El blueprint (WG-):** un activo permanente del vault que captura el conocimiento tácito del modelo de mayor capacidad disponible sobre la misión — incluyendo los unknown-unknowns.
2. **El contrato de misión:** el mismo WG-, ratificado, se entrega a un ejecutor más barato (Opus/Sonnet, un Sherpa, un humano) que ejecuta con alta confianza y mínima supervisión porque las fallas ya están mapeadas con su respuesta.

**Encaje en la arquitectura:**
- **WORX:** el wargame es el complemento adversarial del Gate 1 ("resultado final simulado" solo simula el éxito). Propuesto como **Gate 1.5 opcional** — obligatorio para misiones ≥L2 con riesgo 🔴 (IDE-057, pendiente ratificación).
- **FLA:** el Handoff Spec del WG- es el contrato de misión natural de la ontología Shell×BrainCode×Harness×Gobernanza — al pre-simular fallas, habilita subir la autonomía del ejecutor de L1 a L2 (IDE-060).
- **LoopX:** cada Loop Contract puede exigir WG- previo para misiones nuevas del loop.
- **Vault-First:** el método convierte tokens del modelo caro en activos permanentes — filosofía BMF aplicada a capacidad de modelo.

## 2. Cuándo wargamear (y cuándo NO)

**SÍ:** misiones con ejecución prevista ≤30 días Y (riesgo real 🔴 — cliente, dinero, reputación — O delegación a agente/tercero con autonomía ≥L2). Disparador automático propuesto (P022): todo hito 🔴 con >2 semanas de arrastre.

**NO:** tareas L0/L1 rutinarias (sobre-ingeniería), misiones sin fecha de ejecución (produce shelf-ware), y pulido infinito (máximo 2 pasadas: draft → hardening; el "loop cada 20 minutos" de la fuente original NO se importa — retornos decrecientes).

## 3. La infraestructura (War Room)

```
PB-EL-IALab/WG-EL-WarRoom/
├── Briefs/          → BRF-[ENT]-[Proyecto]-[Misión]-vNN (misiones candidatas)
├── Wargames/        → WG-[ENT]-[Proyecto]-[Misión]-vNN (blueprints)
├── SOP-EL-WarRoom-WargamingEquipo-v01   (proceso de equipo + instrucción de arranque)
├── MePB-EL-WarRoom-WargamingPlaybook-v01 (este documento)
├── CP-EL-WarRoom-CriteriosExito-v01     (pendiente de crear — hoy los criterios viven en §5)
└── CP-EL-WarRoom-Ledger-v01             (pendiente — hoy cada WG- lleva su Ledger en §2)
```
Tipos `WG-`/`BRF-`: en uso piloto, **pendiente ratificación L3** en CP-XX-BMF-NomenclaturaInvocacion.

## 4. Anatomía canónica del WG- (7 secciones)

1. **Misión y Resultado Final** — qué se logra, cómo se ve el éxito (hereda Gate 1 WORX) + diagnóstico de por qué la misión está donde está.
2. **Ledger de supuestos y variables indefinidas** — todo lo que se asumió para poder simular, con owner. Regla: variable sin resolver al handoff = NEXT con owner ANTES del move que depende de ella.
3. **Secuencia move-by-move** — cada MOVE: `Acción | Observación esperada (éxito VS falla) | Causa de falla más probable | Contramove | Fork/trigger`. Un move sin rama de falla está incompleto.
4. **Condiciones de aborto** — cuándo se detiene TODO (y explícitamente qué NO es causa de aborto).
5. **Criterios de éxito** — de la misión (máximo→mínimo aceptable; el limbo es el único resultado prohibido) y del wargame mismo.
6. **Handoff Spec** — quién ejecuta cada move (modelo/agente/humano), autonomía L0-L3, puntos de ratificación humana, condición de arranque.
7. **CHANGELOG** — incluyendo las recalibraciones (ver §6.3).

Frontmatter obligatorio: tripleta + `superficie: LAB` + `ejecutor_declarado` + `mision_origen` + `canonicos_referenciados`.

## 5. El proceso (SOP de equipo — resumen)

Detalle completo e instrucción de arranque lista para pegar: **SOP-EL-WarRoom-WargamingEquipo-v01**.

**1** Seleccionar misiones (filtro §2) → **2** Briefs en BATCH (todos antes de wargamear el primero) → **3** Room Fable/high-tier por misión: Gate G0 (vault primero) + Ledger preguntado en vivo + WG- generado → **4** Ratificación del owner (gate obligatorio — sin "ratificado" no hay ejecución) → **5** Ejecución en room aparte (Opus/Sonnet/humano) con el WG- como contrato → **6** Registro: vault + CHANGELOG del WG- + CAS- al LabPraxis.

**Paralelización:** con varios proyectos, cada dueño abre su room simultáneamente con la misma instrucción — la ventana del modelo caro se aprovecha en paralelo, no en fila.

## 6. Lo que los 4 pilotos enseñaron (enriquecimiento del método)

Pilotos 2026-07-06: WG-EL-DemandGen-PrimeraPublicacion · WG-EL-Posta-CierreContrato · WG-EL-FLA-F1-RegistroConsejero · WG-REB-SantaRosa-PropuestaSponsor.

### 6.1 El wargame es un detector de bloqueos, no solo un plan robusto
Los 4 pilotos convergieron en el mismo hallazgo (CASO 026 · **P022**): los críticos nunca estaban bloqueados por falta de estrategia o activos — siempre era una **decisión L3 sin empaquetar** en la cola del decisor o un **owner difuso** ("Victor·Equipo" = nadie). El Ledger y la pregunta "¿causa de falla más probable?" fuerzan a nombrar la decisión en cola y al owner ausente. Corolario operativo: las decisiones viajan EMPAQUETADAS (binarias o ≤3 opciones, default argumentado, timebox) — "elegir, no crear".

### 6.2 Patrones de move que se repiten (biblioteca de contramoves)
- **El reloj externo como estructura:** si la misión tiene deadline real (evento, ventana de activación), el valor del entregable se deprecia solo — el reloj se declara en §1 y gobierna la secuencia (SantaRosa: "cierre útil = fin de julio").
- **"El documento abre, la sesión cierra":** nunca enviar el número/valor final por escrito si se puede presentar en vivo días después (Posta: propuesta enviada + Workshop).
- **Escalera de compromiso:** diseñar el ask pequeño que ES la firma implícita del ask grande (Posta: C1+C2 acreditables; genérico: el siguiente acto agendado > el sí verbal).
- **Protocolo de silencio:** trigger a 5 días hábiles → (1) valor nuevo, no chase → (2) canal interno/champion → (3) pregunta directa honesta. **Anti-patrón prohibido: descuento preventivo** — el silencio se responde con claridad, no con precio.
- **Pre-brief del champion:** si un entregable expone al aliado interno frente a su jefe, él lo ve PRIMERO y co-diseña el framing (Posta MOVE 3 — el unknown-unknown que puede matar un deal por fuego amigo).
- **Desacoplar canales/frentes:** cada frente enciende cuando SU infraestructura está lista; la simultaneidad no es requisito (DG.1: LinkedIn no espera a newsletter).
- **Prueba de independencia real:** si el gate mide "funciona sin el héroe", el héroe NO participa en la validación — jamás cerrar un gate con auto-validación (FLA MOVE 7).
- **Vender solo lo entregable:** gate de delivery antes de prometer — el éxito comercial sin capacidad de entrega es deuda reputacional (SantaRosa MOVE 7).
- **Fix the template, not the output:** cuando la producción masiva sale inconsistente, se corrige el template/metadata y se re-corre el lote — no se parcha pieza por pieza (FLA MOVES 3 y 6).

### 6.3 El WG- es un documento VIVO (recalibración por Ledger)
Cuando el owner resuelve variables del Ledger, el wargame se **recalibra** (v01-r1, r2… en el CHANGELOG) — moves cambian de naturaleza (Posta: "entrega" → "interpretación" → "Workshop"), riesgos suben o bajan de umbral, forks se activan o quedan obsoletos. La recalibración en vivo con el dueño es donde el wargame gana más precisión por minuto invertido.

### 6.4 El mínimo aceptable se declara desde el diseño
Todo wargame define éxito máximo → mínimo (🥇🥈🥉). El único resultado prohibido es el limbo: un NO claro con aprendizaje extraído vale más que la esperanza ambigua.

## 7. Roles y gobernanza

| Rol | Quién | Superficie |
|---|---|---|
| Wargamer | Modelo high-tier disponible (hoy: Fable 5) | LAB — simula, nunca ejecuta |
| Dueño de la misión | Humano owner | Resuelve Ledger, ratifica (L3 si aplica) |
| Ejecutor | Declarado en Handoff Spec: Opus/Sonnet/Sherpa/humano | PROD — ejecuta el contrato |
| Sherpa | Jay/SherpaX del dueño | Produce briefs, monitorea triggers, registra |

Reglas inviolables: naming BMF antes de escribir · tripleta en cada activo · Gate G0 antes de producir · el WG- no se ejecuta sin ratificación · superficie LAB/PROD nunca se mezcla en el mismo room.

## 8. Métricas del método (para el triage semanal)

1. Wargames producidos vs ejecutados vs shelf-ware (un WG- sin ejecución a 30 días = revisar el filtro §2).
2. % de fallas reales que el wargame SÍ había anticipado (calidad de simulación).
3. Semanas-de-arrastre evitadas en hitos 🔴 (validación de P022).
4. Autonomía efectiva del ejecutor (¿el handoff redujo la supervisión humana de verdad?).

---

## CHANGELOG

| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-06 | Creación. Eleva a playbook canónico el método analizado en ANA-EL-WargamingPlaybook-SintaxisBMF-v01, enriquecido con: aprendizajes de los 4 pilotos (§6 — P022 como hallazgo central, biblioteca de contramoves, recalibración por Ledger, mínimo aceptable), SOP de equipo integrado (§5 → SOP-EL-WarRoom-WargamingEquipo-v01), roles/gobernanza (§7) y métricas de triage (§8). Pendientes L3: ratificar tipos WG-/BRF- en nomenclatura + Gate 1.5 WORX (IDE-057). |