---
type: SOP
asset_id: SOP-EL-WarRoom-WargamingEquipo-v01
version: v01
status: Activo — sesión con equipo 2026-07
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/WG-EL-WarRoom
proposito: Proceso operativo para que el equipo corra wargames de sus proyectos con Fable 5 hoy, y ejecute los blueprints con Opus/Sonnet después. Incluye la instrucción de arranque lista para pegar.
referencia: ANA-EL-WargamingPlaybook-SintaxisBMF-v01 (método) · 4 WG- piloto en Wargames/
tags: [sop, wargaming, warroom, equipo, fable]
---

# SOP — Wargaming de proyectos en equipo
## Proceso validado · 6 pasos

> **Regla de oro:** Fable SIMULA (superficie LAB), nunca ejecuta. Opus/Sonnet EJECUTAN (PROD) con el wargame como contrato de misión. Nadie ejecuta un wargame sin ratificar.

### El proceso

| # | Paso | Quién | Output |
|---|---|---|---|
| **1** | **Seleccionar misiones.** Lista de proyectos vigentes + propuestas nuevas. Filtro de entrada: ejecución prevista ≤30 días Y (riesgo real 🔴 O delegación a agente/tercero). Tareas triviales NO se wargamean. | Equipo + Victor valida | Lista priorizada (hoy: 3-6 misiones máx) |
| **2** | **Brief por misión (BATCH — todos antes de wargamear el primero).** Por proyecto: misión en 1 frase, resultado final esperado, contexto/documentos del vault, restricciones, deadline real, quién ejecutará después. | Cada dueño de proyecto (10 min c/u) | 1 `BRF-[ENT]-[Proyecto]-[Misión]-v01` por misión en `Briefs/` |
| **3** | **Wargamear con Fable (room nuevo por misión).** `/arrancaroom` + pegar la instrucción de abajo + el brief. Fable genera el **WG-** (NO un plan de acción): 7 secciones — misión/resultado, Ledger de variables, moves con rama éxito/falla + contramove + forks, aborts, criterios de éxito, Handoff Spec. Fable PREGUNTA el Ledger; el dueño responde en vivo (lo que no sepa queda como NEXT con owner). | Fable + dueño del proyecto | `WG-[ENT]-[Proyecto]-[Misión]-v01` en `Wargames/` |
| **4** | **Ratificar (gate obligatorio).** El owner lee el WG-, corrige o dice "ratificado". Sin ratificación NO hay ejecución. | Owner (L3) · 10 min | WG- = contrato de misión |
| **5** | **Ejecutar en room aparte (Opus/Sonnet).** `/arrancaroom` + pegar el WG- ratificado. El ejecutor sigue los moves, compara lo observado vs lo esperado, activa contramoves/forks cuando toca, respeta los aborts. Bloqueos nuevos → Ledger → NEXT con owner. | Ejecutor declarado en el Handoff Spec | Misión ejecutada con mínima supervisión |
| **6** | **Registrar.** Resultados al vault (naming BMF), estado del WG- actualizado (CHANGELOG), aprendizajes → CAS- al LabPraxis, sync en la minuta. | Dueño + Sherpa | Vault-First cerrado |

### Correcciones al proceso original del equipo

1. El paso 3 producía "PLAN DE ACCIÓN" → se corrige a **WG- (wargame)**: la diferencia es que cada move lleva su rama de falla, contramove y fork. Un plan asume que todo sale bien; eso es exactamente lo que el método evita.
2. Se agrega el **paso 4 (ratificación)** entre simulación y ejecución — sin gate, se ejecutan simulaciones sin validar.
3. TP+SP → se simplifica a **BRF- (brief de misión)**: para wargamear basta el brief; el TP completo solo si el proyecto ya tiene historia pesada en el vault (entonces se referencia, no se re-escribe).
4. Con varios proyectos hoy: **paso 2 en batch completo primero**, luego los wargames — nunca perfeccionar el WG #1 mientras los demás esperan sin brief.

---

## INSTRUCCIÓN DE ARRANQUE (pegar en el room de Fable, después de /arrancaroom)

```
ORDEN DE WARGAME — NO estás ejecutando esta misión, únicamente la estás simulando (superficie LAB).

Contexto: opera bajo WORX/BMF. El método canónico está en ANA-EL-WargamingPlaybook-SintaxisBMF-v01
y hay 4 wargames de referencia en PB-EL-IALab/WG-EL-WarRoom/Wargames/ — consulta al menos uno
como patrón de formato antes de producir (Gate G0).

Mi pedido: analiza mis proyectos y wargaméalos. Te voy a dar:
(a) mis proyectos VIGENTES: [lista - 1 frase por proyecto]
(b) mis PROPUESTAS de proyecto nuevas: [lista - 1 frase por propuesta]

Para cada uno:
1. Busca primero en el vault qué ya existe del proyecto (Gate G0) — no me preguntes lo que el vault ya sabe.
2. Pregúntame SOLO las variables que el vault no resuelve (Ledger): decisiones, datos, accesos, owners.
3. Genera el wargame WG-[ENTIDAD]-[Proyecto]-[Misión]-v01 en
   PB-EL-IALab/WG-EL-WarRoom/Wargames/ con las 7 secciones canónicas:
   (1) Misión y resultado final · (2) Ledger de supuestos/variables con owner ·
   (3) Secuencia move-by-move — cada move con: acción, observación esperada si funcionó
   VS si falló, causa de falla más probable, contramove, fork/trigger ·
   (4) Condiciones de aborto (y qué NO aborta) · (5) Criterios de éxito (máximo→mínimo aceptable) ·
   (6) Handoff Spec: quién ejecuta cada move (humano u Opus/Sonnet), nivel de autonomía L0-L3,
   qué ratifica el humano · (7) CHANGELOG.

Reglas duras:
- El ejecutor NO serás tú: escribe el wargame PARA el ejecutor declarado (Opus/Sonnet o humano).
- Nada de planes cielo-azul: si un move no tiene rama de falla con contramove, está incompleto.
- Máximo 2 pasadas por wargame (draft → hardening). Con varios proyectos: TODOS los drafts
  primero, pulir después.
- Tripleta en cada WG-: Owner [mi nombre] · Sherpa [SherpaX] · Ratificador [owner o Victor].
- Al final dame: lista de WG- generados + variables del Ledger que quedaron abiertas con owner.

El wargame NO se ejecuta hasta que yo diga "ratificado".
```

---

## CHANGELOG

| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-06 | Creación en sesión con equipo. Proceso del equipo validado y corregido: (1) output = WG-, no plan de acción; (2) gate de ratificación agregado entre simulación y ejecución; (3) TP+SP simplificado a BRF-; (4) batch de briefs antes del primer wargame. Instrucción de arranque incluida lista para pegar. |