---
type: WG
asset_id: WG-EL-DemandGenPack-EScanKit-v01
version: v01
status: Ratificado por Owner (Anahí, 2026-07-08) — pendiente ratificación L3 de Victor para handoff a PROD
owner: Anahí Martínez
sherpa_owner: AniX
ratificador: Victor Heredia
superficie: LAB
fecha_creacion: 2026-07-08
intellbank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank/PB-EL-IALab/WG-EL-WarRoom/Wargames
proposito: Wargame de la misión WG-A3 — ratificar y activar la MetaFactoría DemandGenPack con el kit piloto EmpowerScan (KDG.1). Simula move-by-move la cadena de gates (FAC → OFC EST-02 → SPEC EST-03 → G-PR→DG) y la producción K5–K7 sin componentes huérfanos.
mision_origen: WG-A3 (PLAN-EL-WarRoom-MisionesWargame-Anahi-v01) · TP-EL-WarRoom-DemandGenPackWargame-v01
ejecutor_declarado: Jay + agentes IA (Shell Opus/Sonnet-class × demand-gen-ultra × L2) para producción del kit · Anahí+AniX (frente F5 · L2) para K5–K7 · Victor (L3) ratifica FAC, OFC, SPEC, pricing y GO/NO-GO
canonicos_referenciados: FAC-EL-DemandGenPack-v01 · TP-EL-EScan-ProductizacionMacroLoopX-v01 · OFC-EL-EScan-OfferCanvas-v01 · XD-EL-PRD-EScan-Master-v01 · BRD-EL-MacroLoopX-Dashboard-v02 · MePB-EL-WarRoom-WargamingPlaybook-v01
tags: [wargame, WG-A3, demandgenpack, empowerscan, KDG1, metafactoria, LAB]
---

# WARGAME — WG-A3 · MetaFactoría DemandGenPack · Kit piloto EmpowerScan
## ⚠️ ORDEN DE WARGAME: este documento SIMULA la misión move-by-move. NO la ejecuta. Superficie: LAB.

**Hilo adversarial (actor rojo):** la factoría "se activa" con los gates a medias — FAC sin ratificar, SPEC pendiente, tags sin taxonomía — y empieza a escupir componentes. La pregunta que cada move responde: *¿esto produce un kit vendible que mueve al board, o materiales huérfanos sin gate, sin CRM y con pricing improvisado?* **Criterio de victoria: ningún componente sale a demanda sin su gate en PASS y su enrutamiento a CRM previsto; pricing y GO/NO-GO siempre pasan por Victor.**

---

## 1. Misión y Resultado Final

**Misión:** ratificar y activar la MetaFactoría DemandGenPack con el kit piloto EmpowerScan (B2O) — cerrar la cadena de gates (FAC + Offer Canvas EST-02 + SPEC EST-03), cruzar G-PR→DG y encender el motor de demanda del kit sin producir componentes huérfanos. Ventana: ≤30 días (Fase 1–2 del roadmap GTM).

**Resultado final simulado (Gate 1 WORX):**
- FAC-EL-DemandGenPack-v01 ratificada por Victor + roster confirmado (o su fork mínimo declarado).
- OFC v01.1 (EST-02) cerrado completo y SPEC (EST-03) ratificado → **gate G-PR→DG cruzado y escrito en el vault** (XDoc Maestro + dashboard).
- K5 (paper) · K6 (whitepaper) · K7 (MPI, capas no bloqueadas por MOD-02) en draft de Anahí+AniX.
- TAGMAP OneRocket compatible diseñado y canonizado (`kit-escan-[componente]-[accion]` + `b2o`) — sin esperar la conexión LoopX↔OneRocket.
- Ningún componente publicado a demanda sin gate PASS + enrutamiento CRM previsto.

**Diagnóstico de arrastre (por qué los gates llevan ~4 semanas abiertos):** los tres gates dependen de la misma persona (Victor, L3) y las decisiones nunca se le empaquetaron como binarias — patrón P022 del LabPraxis (*decisión L3 sin empaquetar u owner difuso como causa raíz de arrastre*). La FAC espera desde 10-jun, el OFC tiene 3 pendientes puntuales desde 11-jun, el SPEC desde 13-jun. El wargame ataca esto por diseño: **MOVE 1 empaqueta TODA la cadena L3 en una sola sesión de decisiones binarias.**

---

## 2. Ledger de supuestos y variables (estado al 2026-07-08 · confirmado con Anahí)

| # | Variable | Estado | Resolución / NEXT con owner |
|---|---|---|---|
| L1 | Estado de los 3 gates (FAC · OFC completo · SPEC) | 🔴 ABIERTA — nada nuevo desde junio | NEXT: sesión de ratificación empaquetada (MOVE 1) → **Victor** |
| L2 | MOD-02 (modalidad MPI del Sherpa) | 🔴 ABIERTA — sin producir; bloquea ensamblaje de K7 | NEXT: producir MOD-02 → **Jay + Victor**. K7 avanza en capas de contenido (MOVE 6, fork declarado) |
| L3 | MOD-04 (taxonomía tags) + conexión LoopX↔OneRocket | 🔴 ABIERTA — MOD-04 sin producir; conexión en pausa | NEXT: MOD-04 → **Jay + dev**. El TAGMAP del kit se diseña compatible (MOVE 7) y NO espera la conexión |
| L4 | Roster confirmado (Anahí K5–K7 · Ángeles K8/K2 · Dove K3–K4) | 🔴 ABIERTA — nada confirmado | NEXT: confirmación de disponibilidad dentro del paquete del MOVE 1 → **Victor** |
| L5 | Uso del benchmark anonimizado (~30–40 diagnósticos) para el rango de drag | 🔴 ABIERTA — data/legal sin resolver | NEXT: decisión data/legal dentro del paquete del MOVE 1 → **Victor**. No bloquea K5–K6 (citan metodología, no el benchmark) |
| L6 | Alcance del piloto: kit completo K1–K8 vs subset mínimo | 🟡 DELEGADA AL WARGAME | Se resuelve como **fork del MOVE 5** con regla objetiva: el alcance lo decide el roster confirmado (L4), no el apetito |

**Regla del Ledger:** toda variable sin resolver al momento del handoff se convierte en NEXT con owner ANTES de ejecutar el move que dependa de ella.

---

## 3. Secuencia move-by-move

### MOVE 1 — Empaquetar la cadena L3: una sesión, decisiones binarias (Jay prepara · Victor decide · L3 · 45 min)
| Campo | Detalle |
|---|---|
| **Acción** | Jay prepara UN paquete de ratificación con las 6 decisiones pendientes de Victor, cada una binaria con default propuesto: (1) FAC + roster [default: ratificar con roster propuesto §DEL-03]; (2) OFC — garantía 5x [default: sí, Hormozi la valida en el canvas]; (3) OFC — cap 2/mes [default: sí, capacidad real]; (4) OFC — naming A vs B [default: A, "la Radiografía de Costos Ocultos"]; (5) SPEC EST-03 = §3 del TP-EScan [default: ratificar; fórmulas del Módulo C van al SPEC hijo, no bloquean]; (6) benchmark L5 [default: uso anonimizado agregado, sin datos de cliente identificables]. Victor decide sí/no por ítem en una sesión de 45 min. |
| **Observación si funcionó** | ≥5 de 6 ítems cerrados en la sesión, registrados en 1 línea cada uno en el vault (status de FAC/OFC/TP actualizados). |
| **Observación si falló** | La sesión deriva en rediseño de algún activo ("darle otra vuelta al canvas") o se pospone >72h. |
| **Causa de falla más probable** | Patrón P022: cada ítem se siente como decisión estratégica grande porque llega sin empaquetar; Posta/contratos compiten por la ventana de Victor. |
| **Contramove** | Reencuadre: los activos llevan ~4 semanas listos, los defaults vienen validados por el BrainX etiquetado en el propio canvas; lo único que falta es el sí/no. Si se pospone: Jay reduce a la pregunta mínima viable — "¿ratificamos FAC + SPEC con defaults y el resto la próxima semana?: sí/no". |
| **Fork/trigger** | Ítems 2–4 (pendientes del OFC) pueden cerrarse asíncronos por nota/WhatsApp si la sesión no cabe en agenda. Si Victor cuestiona la MetaFactoría o el kit EScan MISMO (no los pendientes) → **ABORT total** (§4): el problema es del PLAN, no de WG-A3. |

### MOVE 2 — Escribir el cruce del gate en el vault (Jay · L1 · 30 min)
| Campo | Detalle |
|---|---|
| **Acción** | Con FAC + OFC + SPEC ratificados: actualizar status en los 3 activos, marcar G-PR→DG como cruzado en XD-EL-PRD-EScan-Master (tablero de loops: LoopXDG 🔒→🟢) y en la pestaña LoopXDG del BRD-EL-MacroLoopX-Dashboard-v02. |
| **Observación si funcionó** | El vault y el chat cuentan la misma historia: cualquier agente que consulte el XDoc ve el gate cruzado con fecha. |
| **Observación si falló** | El gate se cruza "de palabra" en una sesión y el vault sigue diciendo Draft — el actor rojo en su forma más silenciosa: dos fuentes de verdad. |
| **Causa de falla más probable** | La emoción de arrancar producción se come el paso administrativo. |
| **Contramove** | Regla dura: **el gate NO está cruzado hasta que el XDoc Maestro lo diga.** MOVE 5+ no arrancan si este move no está escrito. AniX lo verifica antes de que Anahí toque K5. |
| **Fork/trigger** | Si la ratificación del MOVE 1 fue parcial (solo FAC+SPEC, OFC pendiente de 1 ítem) → el XDoc registra el estado REAL parcial y solo se desbloquean los moves que no dependan del ítem abierto. |

### MOVE 3 — Confirmar roster o declarar el fork mínimo (Victor · L3 · dentro del MOVE 1 o ≤48h después)
| Campo | Detalle |
|---|---|
| **Acción** | Confirmar disponibilidad real: Anahí (K5–K7), Ángeles (K8 + landing K2), Dove (K3–K4). Si alguien no está disponible en la ventana de 30 días, se declara explícitamente fuera del alcance del piloto (alimenta el fork del MOVE 5). |
| **Observación si funcionó** | Roster escrito en la FAC con nombres y componentes; cada productor sabe qué produce y para cuándo. |
| **Observación si falló** | "Todos le entran" sin fechas — roster de dientes para afuera que se descubre vacío en la semana 2. |
| **Causa de falla más probable** | Confirmar disponibilidad se confunde con confirmar buena voluntad; nadie declara sus horas reales contra Posta/Re100X/frentes activos. |
| **Contramove** | La confirmación es por componente con fecha de draft, no genérica. Quien no pueda poner fecha en la ventana → fuera del piloto sin drama (el fork del MOVE 5 existe justo para eso). |
| **Fork/trigger** | Solo Anahí confirmada → **Fork A del MOVE 5 se activa automáticamente** (subset K5–K7). |

### MOVE 4 — TAGMAP OneRocket compatible (Jay · L2 · paralelo desde el día 1)
| Campo | Detalle |
|---|---|
| **Acción** | Canonizar el TAGMAP del kit como activo único (`TAGMAP` del kit, per XDoc §3.8): convención `kit-escan-[componente]-[accion]` + tag de modalidad `b2o` (ej. `kit-escan-mpi-qna`, `kit-escan-landing-optin`), enrutamiento previsto por componente hacia OneRocket (36 tools del MCP documentadas en DC-EL-GHL-EndpointsYMCP-v01). Se diseña COMPATIBLE con la futura conexión LoopX↔OneRocket; NO la espera. |
| **Observación si funcionó** | Todo componente del kit nace con sus tags y su ruta CRM declaradas en el TAGMAP antes de publicarse. |
| **Observación si falló** | Cada componente inventa sus tags al publicarse — taxonomía improvisada que MOD-04 tendrá que deshacer después. |
| **Causa de falla más probable** | "Los tags los vemos cuando conectemos OneRocket" — confundir diseñar la taxonomía (hoy) con operar la integración (bloqueada por MOD-04/dev). |
| **Contramove** | Regla dura del TP: el tagging se diseña compatible sin esperar la conexión. El TAGMAP es prerequisito de publicación (§5 criterio), no de producción de drafts. |
| **Fork/trigger** | Cuando MOD-04 exista, el TAGMAP se reconcilia contra él (v02); si MOD-04 contradice la convención, MOD-04 manda (es el spec canónico). |

### MOVE 5 — Resolver el alcance del piloto: el fork L6 (Victor + Anahí · L3 · decisión objetiva)
| Campo | Detalle |
|---|---|
| **Acción** | Decidir alcance con regla objetiva: **el alcance lo define el roster confirmado (MOVE 3), no el apetito.** **Fork A — subset mínimo:** K5 paper + K6 whitepaper + K7 MPI (Anahí) + TAGMAP + reutilizar activos vivos (landing WOI v01, calculadora v05, guiones de video existentes) como proxies de K2–K4. **Fork B — kit completo K1–K8:** solo si Ángeles Y Dove confirmaron con fechas. |
| **Observación si funcionó** | Alcance declarado en 1 línea en el XDoc; nadie produce componentes fuera del alcance. |
| **Observación si falló** | Alcance "completo" declarado con roster a medias — a los 15 días hay K5 en draft y seis huecos, y se lee como fracaso de la factoría. |
| **Causa de falla más probable** | Sobre-alcance por validar la MetaFactoría entera en el piloto (tentación legítima: el piloto ES el caso de calibración). |
| **Contramove** | Reencuadre: la MetaFactoría se valida cruzando gates con gobernanza, no por número de componentes. Un subset con cadena de gates limpia ES un piloto exitoso; los aprendizajes van a CAS- de LabPraxis igual. |
| **Fork/trigger** | Fork A puede escalar a Fork B a mitad de ventana si Ángeles/Dove confirman después — el inverso (B→A) se declara como recorte formal, no como deslizamiento silencioso. |

### MOVE 6 — Producir K5–K7 en draft (Anahí + AniX · L2 · el corazón de la ventana)
| Campo | Detalle |
|---|---|
| **Acción** | Con gate escrito (MOVE 2) y alcance declarado (MOVE 5): producir en draft K5 (paper) y K6 (whitepaper) **extendiendo la materia prima viva** — WP-BVH-EmpowerScan-CostosOcultos-EraIA-v02, síntesis Empowernomics, dossier EST-01 — bajo D-P-24 (~65% referenciar, ~35% nuevo; el linaje Empowernomics se CITA SIEMPRE, no se re-describe). K7 (MPI): producir las capas de CONTENIDO (Q&A, objection bank del research F3, narrativa por rol) que no dependen de MOD-02; el ensamblaje de modalidad queda explícitamente bloqueado esperando MOD-02. |
| **Observación si funcionó** | K5–K6 en draft ≤ día 20 de la ventana; K7-contenido en draft con su dependencia MOD-02 declarada en el activo; todo con tripleta y QA de Jay (checks KD-*) agendado. |
| **Observación si falló** | Drafts que re-describen el research desde cero (quema la ventana), o K7 "terminado" ensamblando una modalidad MPI inventada sin MOD-02 — el actor rojo produciendo IP huérfana. |
| **Causa de falla más probable** | Gate G0 flojo: producir sin releer los canónicos (el dossier, el canvas F5, el objection bank) y reinventar lo que el vault ya sabe. |
| **Contramove** | AniX corre Gate G0 por componente ANTES del primer párrafo: lista de canónicos a extender con % estimado. Si un draft nace <50% referenciado, se detiene y se reancla. Para K7: la portada del activo declara "capas de contenido — ensamblaje bloqueado por MOD-02" para que nadie lo publique como MPI completo. |
| **Fork/trigger** | Si MOD-02 llega a mitad de ventana → K7 pasa a ensamblaje completo (trigger positivo). Si al día 20 no hay MOD-02 → K7 se entrega como paquete de contenido + NEXT, y NO cuenta como componente publicable. |

### MOVE 7 — QA + gates de componente antes de cualquier publicación (Jay · L2 · por componente)
| Campo | Detalle |
|---|---|
| **Acción** | Cada componente en draft pasa: (1) checks KD-* del modelo de dominio; (2) verificación contra el Offer Canvas (mensaje, naming ratificado, pricing NUNCA en el componente sin cita textual del canvas); (3) tags + ruta CRM del TAGMAP asignados; (4) ratificación del componente (Victor en kits EL). |
| **Observación si funcionó** | Componente con 4/4 → estado "publicable" en el XDoc. |
| **Observación si falló** | Un componente "se adelanta" a un canal (LinkedIn, newsletter, MasterPlaybooks) directo desde draft porque "ya estaba listo". |
| **Causa de falla más probable** | Presión de la ventana de 30 días + canales calientes disponibles (cadencia viva de ReinventaNews) hacen tentador saltarse el QA "solo esta vez". |
| **Contramove** | Regla de victoria del wargame aplicada literal: publicable = gate PASS + CRM previsto. AniX y Jay tienen veto operativo (L2) para detener publicación de cualquier componente sin 4/4 — no necesitan permiso para frenar, sí para publicar. |
| **Fork/trigger** | 2 componentes seguidos rebotados por el mismo check → sesión de calibración con el canvas antes de seguir produciendo (el problema es sistémico, no del draft). |

### MOVE 8 — Encender demanda: handoff a LoopXDG y distribución (Jay + Ángeles/AngyX · L2)
| Campo | Detalle |
|---|---|
| **Acción** | Componentes publicables entran a distribución vía las factorías de contenido existentes (FI-LINKEDIN, FI-PODCAST, FI-NEWSLETTER — el kit las alimenta, no las duplica) con sus tags del TAGMAP. Observación de señal estilo WG-DG.1: conversaciones ICP y DMs, no vanity metrics. Registro CRM manual mientras MOD-04/conexión no existan (los tags viajan en el contenido; el enrutamiento automático llega después). |
| **Observación si funcionó** | ≥1 conversación real de perfil ICP (CIO/CEO mediano) atribuible a un componente del kit dentro de la ventana; señal registrada en el XDoc. |
| **Observación si falló** | Componentes publicados y cero registro de señal — o peor: leads que llegan y se pierden porque nadie previó el paso manual de CRM. |
| **Causa de falla más probable** | El hueco entre "tags diseñados" y "conexión en pausa": el enrutamiento previsto existe en papel pero nadie ejecuta el paso manual. |
| **Contramove** | El TAGMAP (MOVE 4) incluye una columna "ruta manual mientras no hay conexión" con owner por componente. Sin owner de ruta manual, el componente no se publica (es parte del check 3 del MOVE 7). |
| **Fork/trigger** | Cero señal en la ventana NO aborta ni recalibra la oferta (n pequeño — anti-patrón Walker); se registra y la lectura real se hace a las 4–6 piezas distribuidas, patrón WG-DG.1 MOVE 6. |

---

## 4. Condiciones de aborto (misión completa)

| Trigger | Por qué aborta todo |
|---|---|
| Victor cuestiona la MetaFactoría o el kit EScan MISMO en el MOVE 1 (no los pendientes puntuales) | La misión sería activar una factoría en la que el Owner no cree; el problema pertenece al PLAN GTM / FAC, no a WG-A3. Regresar al nivel estratégico. |
| La pregunta mínima viable del MOVE 1 recibe "no" dos veces consecutivas (FAC sin ratificar tras 2 intentos empaquetados) | Activar la factoría sin FAC ratificada es producir sin gobernanza — exactamente el actor rojo. K5–K7 NO se producen; se documenta la causa real del no en el Ledger y se escala a sesión estratégica. |
| Cualquier move fija pricing o declara GO/NO-GO sin ratificación de Victor | Violación del non-negotiable de la MetaFactoría (matriz §4.2 MacroLoopX). Abort inmediato del move, rollback del artefacto, registro en Ledger. |
| Data/legal veta el uso del benchmark (L5) Y el Módulo B pierde su base de calibración declarada | Solo si el veto invalida la metodología del estimado (el claim central del canvas). Si solo restringe el benchmark, K5–K6 citan metodología sin cifras del benchmark — eso NO aborta. |

**Lo que NO es causa de aborto:** MOD-02 pendiente (K7 forkea a capas de contenido) · MOD-04/conexión OneRocket en pausa (TAGMAP se diseña compatible + ruta manual) · roster incompleto (Fork A del MOVE 5) · cero señal en la ventana (n pequeño, MOVE 8) · fórmulas del Módulo C sin cerrar (van al SPEC hijo).

---

## 5. Criterios de éxito

**Máximo (la factoría encendida):** cadena completa ratificada en 1 sesión · G-PR→DG escrito en el vault · roster completo confirmado → Fork B · K5–K7 en draft con QA 4/4 · TAGMAP canonizado · ≥1 componente distribuido con señal ICP registrada · aprendizajes del piloto documentados como CAS- en LabPraxis.

**Intermedio:** FAC + SPEC ratificados (OFC con ≤1 pendiente asíncrono) · gate cruzado parcial escrito · Fork A activo · K5–K6 en draft con Gate G0 verificado · K7-contenido con dependencia declarada · TAGMAP en draft.

**Mínimo aceptable:** la sesión del MOVE 1 OCURRIÓ con las 6 decisiones empaquetadas y cada "no" o aplazamiento quedó documentado con causa y NEXT con owner en el Ledger. (Un "no" informado vale más que 4 semanas más de arrastre silencioso — patrón P022.)

**Del wargame (formato):** todo move con ambas ramas observables ✅ · ≥1 fork explícito por fase ✅ (MOVES 1, 2, 3, 4, 5, 6, 7, 8) · aborts definidos con sus NO-aborts ✅ · Ledger completo con owner ✅ · ejecutor declarado con autonomía ✅ · ejecutable sin acceso a este chat ✅.

---

## 6. Handoff Spec

| Rol | Quién | Autonomía | Ratifica |
|---|---|---|---|
| Empaquetar decisiones L3, QA (KD-*), TAGMAP, distribución | Jay + agentes IA (Shell Opus/Sonnet-class × demand-gen-ultra) | L2 — ejecuta con guardarraíles; veto operativo sobre publicación sin 4/4 | — |
| Producción K5–K7 (drafts, Gate G0 por componente) | Anahí + AniX (frente F5) | L2 — produce en draft; AniX verifica Gate G0 y gate escrito antes de arrancar | Victor (componente) |
| FAC, OFC, SPEC, roster, benchmark, pricing, GO/NO-GO, alcance | Victor | L3 — decisión humana obligatoria; recibe TODO empaquetado binario | Victor |
| Distribución en factorías de contenido (K8/canales) | Ángeles + AngyX (si confirma) | L2 — dentro del TAGMAP y la cadencia existente | Victor |
| Escalamiento por arrastre (>72h sin sesión MOVE 1) | Jay | L1 — pregunta mínima viable binaria; no ratifica nada por su cuenta | Victor |

**Condición de arranque:** ratificación L3 de Victor sobre este wargame. Las 6 variables del Ledger están abiertas al 2026-07-08 — L1, L4, L5 se resuelven DENTRO del MOVE 1 (esa es la jugada); L2, L3 tienen NEXT con owner y forks declarados que las hacen no-bloqueantes; L6 se resuelve en el MOVE 5 con regla objetiva. La ejecución arranca en room aparte (superficie PROD) con este documento como contrato de misión. Un Shell Opus/Sonnet-class puede correrlo como contrato de misión sin acceso a este chat.

---

## CHANGELOG

| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-08 | Creación (WG-A3). Wargame de activación de la MetaFactoría DemandGenPack con kit piloto EmpowerScan: 8 moves cubriendo la cadena FAC → OFC → SPEC → G-PR→DG → K5–K7 → TAGMAP → demanda. Causa raíz de arrastre (P022: decisiones L3 sin empaquetar) atacada por diseño en MOVE 1. Ledger de 6 variables confirmado con Anahí el 8-jul (todas abiertas; L6 delegada al fork del MOVE 5). 4 aborts + 5 no-aborts. Draft → hardening en la misma sesión. |
| v01-r1 | 2026-07-08 | Ratificado por Owner (Anahí) en la sesión de wargame. Queda pendiente la ratificación L3 de Victor como condición de arranque; la ejecución corre en room aparte (superficie PROD) con este documento como contrato de misión. |