---
type: ANA
asset_id: ANA-EL-WargamingPlaybook-SintaxisBMF-v01
version: v01
status: Active
owner: Victor Heredia
sherpa_owner: Jay
ratificador: Victor Heredia
fecha_creacion: 2026-07-06
intellbank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank/PB-EL-IALab
proposito: Analizar el "Wargaming Playbook" externo, traducir su sintaxis a la arquitectura BMF/WORX y definir casos de aplicación en 24h
fuente: Playbook externo (texto compartido por Victor) — método de "wargaming" de proyectos con modelo high-tier (Fable 5) para handoff a modelos ejecutores más baratos. Autor desconocido. Claims de producto no verificables (⚠️ "GPT 5.5", comportamiento de modelos futuros) — irrelevantes para el método en sí.
modos: BENCHMARK + INNOVACIÓN
tags: [analisis, wargaming, pre-mortem, BMF, WORX, FLA, LoopX, IALab]
---

# Análisis — Wargaming Playbook · Sintaxis BMF y aplicabilidad
## Reporte ejecutivo · 2026-07-06 · playbook externo (texto)

## Análisis en un párrafo

El playbook propone algo que el ecosistema ya hace a medias y nunca formalizó: **simular la falla antes de ejecutar**. WORX vNext ya exige simular el resultado final (Gate 1), pero solo el escenario "blue sky"; el wargaming agrega la mitad adversarial — move-by-move con observación esperada, causa de falla probable, contramove, forks y condiciones de aborto. Su segunda tesis ("escribir el blueprint PARA un ejecutor declarado más barato") es literalmente nuestra ontología FLA: el wargame es el **contrato de misión** que permite a un Sherpa ejecutor operar en L2 con mínima supervisión. La traducción a BMF es directa (nuevo tipo `WG-` + War Room en IALab), el costo de adopción es bajo porque reutiliza gobernanza existente, y hay 4 candidatos inmediatos — el mejor es DG.1, el crítico bloqueado hace 2+ semanas. Veredicto: **ADOPTAR el método, descartar la premisa coyuntural** ("última semana de Fable"): el valor duradero es el pre-mortem como activo del vault, no el arbitraje de modelos.

**Contexto:** fuente anónima tipo "playbook de operador". Tesis central: "use its raw intelligence to war game your most complex projects… capturing the model's tacit knowledge to uncover unknown unknowns", y luego "hand these deeply simulated blueprints to cheaper models to execute flawlessly". Estructura: workspace (/tasks, /war games, success.md, ledger.md) → prompt de wargame (orden explícita de NO ejecutar, ejecutor declarado, contingencias, aborts) → ejecución bulk en paralelo → handoff.

## 1. Conclusiones para Victor — Estratega · Arquitecto · CEO

| # | Conclusión | Evidencia de la fuente |
|---|---|---|
| 1 | El wargaming es el **complemento adversarial del Gate 1 de WORX**. Nuestro "Diseño del Resultado Final" simula el éxito; esto simula la falla. Juntos cierran el pre-mortem completo. | "standard plans assume a blue sky scenario where everything goes perfectly" |
| 2 | El "ejecutor declarado" valida la ontología FLA: Shell×BC×Harness×Gobernanza. El wargame tailoreado al ejecutor es exactamente lo que un Registro Agéntico permite hacer con rigor (system card = manifiesto del shell). | "Inform the model who will actually do the work later… tailor the output to the future model's specific behaviors and system card" |
| 3 | Convertir tokens caros en activos permanentes del vault **es la filosofía BMF aplicada a capacidad de modelo**. El playbook redescubre Vault-First. | "convert temporary access to an expensive model into permanent, robust assets" |
| 4 | El wargame reduce el costo de supervisión humana → habilita subir autonomía de L1 a L2 en misiones delegadas a Sherpas. Es infraestructura de confianza para la FLA. | "the cheaper model will be able to execute it with high confidence and minimal oversight" |
| 5 | La premisa de urgencia ("before losing access") es coyuntural y NO debe importarse. Si se adopta como ritual permanente, el disparador correcto es el riesgo de la misión, no el calendario de acceso a un modelo. | "burning through tokens on random tasks before losing access" |
| 6 | El "ledger de bloqueos" es la pieza más subestimada: convierte "no puedo simular esto" en NEXTs con owner — nuestro mecanismo natural de destrabado. | "a tracker for the AI to note any blocked tasks, undefined variables, or missing inputs it needs from you" |

## 2. Ideas por foco

### 2A. Sintaxis y organización BMF del wargaming (traducción canónica)

**Mapeo playbook → arquitectura BMF/WORX:**

| Elemento del playbook | Equivalente BMF/WORX | Nota |
|---|---|---|
| Master directory `fables last week` | `PB-EL-IALab/WG-EL-WarRoom/` | Sin carpetas ad-hoc; el War Room vive en el IALab (transversal) |
| `/tasks` (mission briefs) | `WG-EL-WarRoom/Briefs/` → `BRF-EL-[Proyecto]-[Misión]-vNN.md` | Un brief = una misión candidata |
| `/war games` (blueprints) | `WG-EL-WarRoom/Wargames/` → `WG-EL-[Proyecto]-[Misión]-vNN.md` | El activo principal; tipo nuevo `WG-` (requiere ratificación L3 en CP-XX-BMF-NomenclaturaInvocacion) |
| `success.md` | `CP-EL-WarRoom-CriteriosExito-v01.md` | Criterios estrictos de wargame válido (ver abajo) |
| `ledger.md` | `CP-EL-WarRoom-Ledger-v01.md` | Bloqueos y variables indefinidas → cada entrada se convierte en NEXT con owner |
| "you are not executing this mission" | **Superficie = LAB** (declaración obligatoria WORX vNext) | Gate 0 ya existe; el wargame nunca toca PROD |
| "a cheaper executor model will run the brief" | **Ejecutor declarado** = composición del Registro Agéntico: Shell × BC(s) × Harness × Autonomía (ej. `Shell:Opus-4.8 × /sh-dgen-postcopywriter × L2`) | Conecta directo con F1 de la FLA |
| Move-by-move + contingencias | Estructura tipo **Loop Contract**: estados, gates, forks/triggers | Ya dominamos ese formato (DC-EL-LoopXSA-LoopContract-v01) |
| Abort conditions | Regla de stop/ajuste (artefacto obligatorio WORX) | Ya existe como concepto; aquí se vuelve sección canónica |
| Bulk `/goal` fan-out | Skill `/wargame` con subagentes en paralelo sobre todos los BRF- de `Briefs/` | Cowork ya soporta fan-out |
| `/loop every 20 minutes` | **NO importar tal cual** — 2 pasadas máx (draft → hardening) + ledger. El pulido infinito quema tokens con retornos decrecientes | LoopXKZ captura aprendizajes post-ejecución, no pre |
| Handoff al modelo barato | **Handoff Spec** = última sección del WG-: ejecutor, autonomía, qué ratifica el humano y cuándo. Ratificación L3 de Victor antes de ejecutar | Tripleta completa en el activo |

**Anatomía canónica del `WG-` (7 secciones):**

1. **M — Metadata**: frontmatter BMF + tripleta + `superficie: LAB` + ejecutor declarado.
2. **Misión y Resultado Final**: hereda el Gate 1 de WORX (el mock del éxito).
3. **Supuestos y variables indefinidas**: lo que se asumió para poder simular → espejo en el Ledger.
4. **Secuencia move-by-move**: cada MOVE = `Acción | Observación esperada (éxito vs falla) | Causa de falla más probable | Contramove | Fork/trigger`.
5. **Condiciones de aborto**: cuándo el plan completo se detiene (no solo un move).
6. **Criterios de éxito**: heredados del CP-EL-WarRoom-CriteriosExito + específicos de la misión.
7. **Handoff Spec**: composición ejecutora, nivel de autonomía, puntos de ratificación humana.

**Criterios de wargame válido (borrador para CP-EL-WarRoom-CriteriosExito-v01):** todo move tiene ambas ramas (éxito/falla) observables; ≥1 fork explícito por fase; condiciones de aborto definidas; cero dependencias no declaradas (todo lo desconocido está en el Ledger); ejecutor declarado con autonomía asignada; el documento es ejecutable por un agente sin acceso a este chat (autocontenido — prueba XPack).

### 2B. Encaje con WORX · LoopX · FLA

| Dónde encaja | Cómo |
|---|---|
| WORX vNext — Gates | El wargame se inserta como **Gate 1.5 opcional** entre "Resultado final simulado" y "Piloto gobernado", obligatorio solo para misiones L2/L3 con riesgo real (cliente, dinero, reputación) |
| LoopX | Cada Loop Contract puede exigir WG- previo para misiones nuevas dentro del loop (ej. primera campaña de LoopXDG) |
| FLA F0/F1 | El WG- es el formato natural del "contrato de misión" con que la Factoría despacha Sherpas; el eval set de F1 (10-15 problemas con ground truth) puede construirse wargameando |
| Brain Codes | Paralelismo conceptual: un BC captura cognición tácita de una persona; un WG- captura conocimiento tácito del modelo sobre una misión ("unknown unknowns"). Ambos son destilación → activo permanente |
| Umbral de uso | **No wargamear todo.** Tareas L0/L1 rutinarias = sobre-ingeniería. Regla: solo misiones con ejecución prevista ≤30 días Y (autonomía ≥L2 O riesgo 🔴) |

### 2C. Casos aplicables en las próximas 24 horas

Ordenados por (urgencia en minuta 2026-07-06 × idoneidad para wargaming):

| # | Wargame propuesto | Misión (hito de la minuta) | Por qué es buen candidato |
|---|---|---|---|
| 1 | `WG-EL-DemandGen-PrimeraPublicacion-v01` | DG.1 🔴 (bloqueado 2+ semanas) | El bloqueo mismo es evidencia de fallas no mapeadas. Wargamear publicación LinkedIn + newsletter: moves, qué se observa si no hay tracción, contramoves, forks de formato. Desbloquea el crítico #1 y alimenta el DemandGenPack que Fable ya está generando (DG.2) |
| 2 | `WG-EL-Posta-CierreContrato-v01` | POSTA.2 ⚡ (riesgo enfriamiento) | Negociación = terreno wargaming puro: objeciones probables, silencio del cliente, contramoves, abort = enfriamiento irreversible. Input directo para la llamada de cierre |
| 3 | `WG-EL-FLA-F1-RegistroConsejero-v01` | F1 FLA (Registro + `/consejero` ≥80% accuracy) | Wargamear el pipeline F1 antes de ejecutarlo: qué pasa si el eval set da <80%, si el operador no-Victor falla la validación, forks de población del Registro. Meta-caso: usar el método para blindar la iniciativa que lo institucionalizaría |
| 4 | `WG-EL-SantaRosa-PropuestaSponsors-v01` | SPO.1 ⚡ | Propuesta comercial con semanas de arrastre; wargamear objeciones de sponsors y forks de paquete |
| 5 | `WG-EL-Rebelocity-VacanteBD-v01` | DIR.1 ⚡ | Menor idoneidad (proceso humano, menos determinístico), pero útil para mapear fallas del pipeline de contratación antes de L'Étape/IM 70.3 |

**Recomendación 24h:** correr #1 y #2 hoy mismo como piloto del formato (2 wargames bastan para validar la anatomía WG- antes de canonizarla). #3 esta semana.

## 3. Qué ya tenemos incorporado (BENCHMARK)

Verificado con escaneo del vault 2026-07-06 (grep "wargam|pre-mortem" + revisión de canónicos):

| Concepto de la fuente | Nuestro equivalente | Estado + gap honesto |
|---|---|---|
| Simular antes de ejecutar | WORX vNext Gate 1: "Resultado final simulado" (DC-XX-WORX-DocumentoCentral-v01) | 🟡 Solo simula el éxito (blue sky). No existe simulación adversarial de fallas — ese es el gap exacto que el wargaming llena |
| Move-by-move con estados y gates | Loop Contracts (DC-EL-LoopXSA-LoopContract-v01): estados, gates entrada/salida, equipo | 🟡 Los contracts definen el sistema permanente del loop, no la simulación pre-mortem de una misión específica |
| Abort conditions | "Regla de stop/ajuste" (artefacto obligatorio WORX) | ✅ Existe como concepto; falta formato operativo por misión |
| Ejecutor declarado + system card | Ontología FLA Shell×BC×Harness×Gobernanza + Registro Agéntico (PLAN-XX-BMF-FLA-F0F1) | 🟡 Diseñado y en F0/F1, aún no operando. El wargaming le da su primer caso de uso concreto |
| Ledger de bloqueos | NEXTs con owner + next-scanner | ✅ Mecanismo existe; falta el hábito de que la IA lo alimente durante simulación |
| Bulk fan-out paralelo | Cowork subagentes + skills | ✅ Capacidad instalada, sin ritual que la explote para esto |
| Wargaming como método formal | — (solo menciones en PBO-BVH-LatticeworkMentalModels y ThinkingRevolution como modelo mental) | 🔴 No existe. Es la incorporación neta |

**Lectura honesta:** tenemos ~60% de las piezas en gobernanza y formato, 0% del método ensamblado. La adopción es barata precisamente porque reutiliza lo existente.

## 4. Implicaciones de implementación

| # | Innovación | Qué implica | Esfuerzo | Impacto |
|---|---|---|---|---|
| 1 | War Room en IALab (carpetas + CP-CriteriosExito + CP-Ledger) | Crear 2 CPs + 2 subcarpetas | 🟢 | Habilita todo lo demás |
| 2 | Tipo `WG-` + `BRF-` en nomenclatura canónica | Ratificación L3 de Victor; update a CP-XX-BMF-NomenclaturaInvocacion-v01 | 🟢 | Consistencia BMF |
| 3 | Piloto: 2 wargames reales (DG.1 + POSTA.2) | Correr el formato con las 7 secciones; ajustar anatomía con lo aprendido | 🟡 | Valida antes de canonizar; destraba 2 críticos 🔴 |
| 4 | Skill `/wargame` (fan-out sobre Briefs/) | skill-creator; post-piloto | 🟡 | Escala el método |
| 5 | Gate 1.5 en WORX vNext (wargame obligatorio para misiones L2/L3 riesgo 🔴) | Update al DC-XX-WORX-DocumentoCentral; L3 | 🟡 | Institucionaliza el pre-mortem |
| 6 | Handoff Spec como contrato de misión FLA | Integrar al esquema del Registro Agéntico en F1 | 🔴 | Conecta wargaming con la fuerza laboral; el mayor impacto a mediano plazo |

**Secuencia sugerida:** 1 → 3 (hoy/24h, sin esperar ratificación de tipo: los pilotos pueden nacer como DC- y renombrarse) → 2 → 4 → 5 → 6.

## NEXT

| NEXT | Asignado | Eje |
|---|---|---|
| Ratificar tipo `WG-`/`BRF-` y creación del War Room (decisión L3) | Victor | BMF |
| Correr piloto WG-EL-DemandGen-PrimeraPublicacion-v01 (24h) | Victor·Jay | DemandGen |
| Correr piloto WG-EL-Posta-CierreContrato-v01 (24h) | Victor·Jay | HiOrg/Posta |
| Triage de ideas IDE-057–061 en el sync semanal | Victor·Jay | IdeaBank |

## ESTADO DE ADOPCIÓN (actualizado 2026-07-06, mismo día)

El método pasó de análisis a adopción en una sesión. Linaje de activos:

| Activo | Rol |
|---|---|
| Este ANA- | Análisis de la fuente + traducción BMF (histórico) |
| **MePB-EL-WarRoom-WargamingPlaybook-v01** | **CANÓNICO del método** — anatomía, aprendizajes de pilotos, contramoves, gobernanza, métricas. Consultar ESTE para operar |
| SOP-EL-WarRoom-WargamingEquipo-v01 | Proceso de equipo (6 pasos) + instrucción de arranque lista para pegar |
| 4 WG- en Wargames/ | Pilotos ejecutados: DG.1, POSTA.2, FLA-F1, SantaRosa — los 4 recalibrados con Ledger resuelto |
| CASO 026 · P022 (LabPraxis) | Hallazgo transversal de los pilotos: decisión L3 sin empaquetar u owner difuso como causa raíz de arrastre |
| PROPUESTA-PO-PilotoWorxLab-AnexoC3-v02 | Primer entregable comercial real producido por un MOVE de wargame (Posta MOVE 1) |

## CHANGELOG

| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-06 | Creación. Análisis del Wargaming Playbook externo en modos BENCHMARK+INNOVACIÓN, traducción canónica a sintaxis BMF/WORX (anatomía WG- de 7 secciones, War Room en IALab), veredicto ADOPTAR-adaptado y 5 casos 24h. Ideas IDE-057–061 al Idea Bank. |
| v01-r1 | 2026-07-06 | Sección "Estado de adopción" agregada: el método se pilotó (4 WG-), se elevó a canónico (MePB-EL-WarRoom-WargamingPlaybook-v01), se operacionalizó para equipo (SOP) y generó el CASO 026/P022 en el LabPraxis — todo el mismo día del análisis. Este ANA- queda como documento histórico de origen; el canónico operable es el MePB. |