---
type: WG
asset_id: WG-EL-MPX-SoftLaunch-v01
version: v01
status: Draft — Ledger abierto · pendiente ratificación L3 para handoff
owner: Anahí Martínez
sherpa_owner: AniX
ratificador: Victor Heredia
superficie: LAB
fecha_creacion: 2026-07-07
intellbank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank/PB-EL-IALab/WG-EL-WarRoom/Wargames
proposito: Wargame de la misión WG-A1 — soft-launch escalonado de Master Playbooks (6 semanas, gate de 7 condiciones). Pre-mortem del lanzamiento y del gate bajo presión.
mision_origen: WG-A1 (PLAN-EL-Anahi-MisionesWargame-v01) · Soft-Launch MPX diseñado en MIN-EL-Anahi-20260702
ejecutor_declarado: Anahí (owner · coordinación/canal · L2) · Gustavo (frontend/artefactos · L2) · Jay/agente (specs de contenido y telemetría · L2) · Victor (L3 · ratifica membresías/pricing y decisión de fecha)
canonicos_referenciados: CP-MPX-PlanLanzamiento-v03 · MIN-EL-Anahi-20260702-v01 · OUT-MIN-EL-TeamSync-20260706-v01 · MePB-EL-WarRoom-WargamingPlaybook-v01 · BRF-EL-MPX-SoftLaunch-v01 · CP-MPX-SoftLaunch-Gate-v01
tags: [wargame, mpx, softlaunch, gate, LAB, WG-A1]
---

# WARGAME — WG-A1 · Soft-Launch Master Playbooks
## ⚠️ ORDEN DE WARGAME: este documento SIMULA la misión move-by-move. NO la ejecuta. Superficie: LAB.

---

## 1. Misión y Resultado Final

**Misión:** llevar el soft-launch escalonado de Master Playbooks de **gate-en-rojo a lanzamiento sostenido**, sin saltarse el gate bajo la presión de la fecha (checkpoint 9–10 jul).

**Resultado final simulado (Gate 1 WORX):**
- Las 7 condiciones del gate convertidas en **checklist binario verde/rojo con owner por condición** (no juicio difuso).
- Onboarding "wow en 2 min" **diseñado y probado con usuarios reales** — el nodo 🔴 crítico (brecha de activación) cruzado.
- Telemetría midiendo lo que importa: **% de usuarios registrados que abren sesión con el AI Sherpa** (no vanity).
- **Decisión de fecha tomada por el estado del gate, no por la presión** (regla de la minuta 2-jul: si el 9–10 jul el gate no está en verde, se mueve la fecha; no se recorta el gate).
- Si lanza: **cadencia de 6 semanas agendada** + medición del reto activa desde el día 1.

**Diagnóstico (por qué es wargame y no plan):** el riesgo real no es producir artefactos — es (a) la **brecha de activación** (tráfico que llega y no usa el Sherpa, riesgo 🔴 del plan v03 §10), y (b) que **el equipo salte el gate bajo presión de fecha**. Un plan cielo-azul asume que el 9–10 jul todo estará verde; el wargame simula el día con telemetría en rojo.

---

## 2. Supuestos y variables indefinidas (→ Ledger)

| # | Variable | Estado | Owner | Nota |
|---|---|---|---|---|
| L1 | El diseño del soft-launch de 6 semanas ¿está escrito como asset o solo en la minuta 2-jul? | ✅ RESUELTA | Anahí | Congelado 9-jul en `CP-MPX-SoftLaunch-Gate-v01` (checklist binario) + `BRF-EL-MPX-SoftLaunch-v01` (brief con inventario de pendientes). MOVE 1 completado. |
| L2 | Las **7 condiciones exactas** del gate | 🟡 INFERIDA | Anahí | Inferidas: (1) telemetría, (2) análisis de plataforma, (3) ratificación de membresías, (4) landing, (5) onboarding "wow 2 min", (6) calendario de contenido, (7) operación de redes MPX. Confirmar/corregir. |
| L3 | Tamaño de las **audiencias propias** de MPX (fuera de Lyz) | ⬜ ABIERTA | Anahí/Victor | Dimensiona el soft-launch (NEXT de tu minuta). |
| L4 | **Quién opera las redes** de MPX durante las 6 semanas | ⬜ ABIERTA | Anahí/Victor | NEXT de tu minuta. Sin dueño de canal, la cadencia no arranca. |
| L5 | ¿9–10 jul es **checkpoint o fecha de lanzamiento**? | ⬜ ABIERTA | Anahí | Cambia el timebox de todos los moves. |
| L6 | Estado real de cada artefacto (landing, onboarding, telemetría) | ⬜ ABIERTA | Gustavo | MOVE 1 lo vuelve binario. |
| L7 | Pricing/límites de membresía — ¿hay propuesta para ratificar? | ⬜ ABIERTA | Victor (L3) | Gate condición 3. |
| L8 | **ICP congelado** para el CEM | ⬜ ABIERTA | Anahí | v03 §10: "el CEM no funciona sin ICP congelado". Riesgo 🔴 silencioso. |

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

---

## 3. Secuencia move-by-move

### MOVE 1 — Congelar el gate: de juicio difuso a checklist binario (Anahí · L2 · 1h)
| Campo | Detalle |
|---|---|
| **Acción** | Escribir el diseño del soft-launch como asset (`CP-MPX-SoftLaunch-Gate-v01`) y convertir las 7 condiciones en checklist **verde/rojo con owner y criterio de "verde" objetivo** por condición. |
| **Observación si funcionó** | Cada condición tiene un dueño y una definición de "verde" que no admite interpretación. |
| **Observación si falló** | El gate queda como lista de deseos ("mejorar onboarding") sin criterio binario. |
| **Causa de falla más probable** | Condiciones redactadas como aspiración, no como prueba pasa/falla. |
| **Contramove** | Regla: cada condición se redacta como pregunta de sí/no verificable ("¿un usuario real cruza el onboarding y abre sesión con el Sherpa en ≤2 min? sí/no"). |
| **Fork/trigger** | Si al escribirlo aparecen >7 condiciones reales → no inflar el gate; priorizar las 7 que bloquean y mandar el resto a post-lanzamiento. |

### MOVE 2 — Onboarding "wow en 2 min" (Anahí + Gustavo · L2 · nodo 🔴)
| Campo | Detalle |
|---|---|
| **Acción** | Diseñar y **probar con ≥5 usuarios reales** el flujo registro → primer wow con el Sherpa en ≤2 min (v03 §6: explicar en 60s qué hace el Sherpa, capturar contexto, primer wow, celebrar registro). |
| **Observación si funcionó** | ≥3 de 5 usuarios abren sesión con el Sherpa sin ayuda y reportan el "wow". |
| **Observación si falló** | Los usuarios se registran y no interactúan con el Sherpa (la brecha de activación, riesgo 🔴). |
| **Causa de falla más probable** | El onboarding explica la plataforma en vez de provocar una interacción inmediata con el Sherpa. |
| **Contramove** | Invertir el flujo: la primera pantalla ES una conversación con el Sherpa (no un tour). El cuestionario se vuelve la primera pregunta que el Sherpa hace. |
| **Fork/trigger** | Si 2 rondas de prueba siguen sin cruzar el wow → el onboarding NO es el problema, es el Sherpa mismo: escalar a revisión del prompt/KatIA antes de lanzar. |

### MOVE 3 — Landing + telemetría (Gustavo · L2 · Jay specs)
| Campo | Detalle |
|---|---|
| **Acción** | Landing activa + instrumentación que mide el KPI del reto: **% registrados que abren sesión con el Sherpa**, permanencia por pieza, retorno. |
| **Observación si funcionó** | El tablero muestra el % de activación del Sherpa en vivo. |
| **Observación si falló** | Se mide tráfico/impresiones pero NO activación del Sherpa (vanity). |
| **Causa de falla más probable** | Instrumentar lo fácil (pageviews) en vez de lo que define el éxito (activación). |
| **Contramove** | Regla dura: si el tablero no responde "¿cuántos de los que entraron hablaron con el Sherpa?", la telemetría está en rojo aunque haya gráficas. |
| **Fork/trigger** | Si la instrumentación no llega para el checkpoint → lanzar con medición manual mínima (conteo semanal) antes que lanzar a ciegas. |

### MOVE 4 — Membresías + límites: ratificación L3 (Victor · L3)
| Campo | Detalle |
|---|---|
| **Acción** | Victor ratifica el esquema de membresía básica + límites de acceso + pricing (v03 §4.5/§7.3). |
| **Observación si funcionó** | Esquema ratificado; los límites crean tensión de conversión sin bloquear la adopción. |
| **Observación si falló** | Ratificación no llega o los límites ahogan la adopción inicial. |
| **Causa de falla más probable** | Cuello de botella Victor (riesgo declarado) o límites calibrados sin dato. |
| **Contramove** | Fork de desacople: el soft-launch **arranca con acceso gratuito con límites** y la membresía de pago madura después (secuencia v03 §7.3). La monetización NO bloquea el lanzamiento. |
| **Fork/trigger** | Si Victor no ratifica en la ventana → correr Fork gratuito-con-límites y documentar pricing como NEXT L3. |

### MOVE 5 — Calendario de contenido + operación de redes (Anahí · L2)
| Campo | Detalle |
|---|---|
| **Acción** | Cerrar el calendario editorial de 6 semanas con intención comercial y **asignar dueño de operación de redes** (resuelve L3/L4). |
| **Observación si funcionó** | Calendario agendado + dueño de canal declarado + cadencia sostenible. |
| **Observación si falló** | Calendario sin dueño de ejecución → la cadencia muere en la semana 2. |
| **Causa de falla más probable** | Se diseña la cadencia pero nadie la opera (las 2 preguntas abiertas de tu minuta sin resolver). |
| **Contramove** | No arrancar el soft-launch sin dueño de redes declarado; si no hay humano, declarar el agente/Factoría que produce + quién publica. |
| **Fork/trigger** | Si no hay dueño de redes → reducir el alcance del soft-launch a 1 canal (TribusRRHH) antes que fingir multicanal. |

### MOVE 6 — Coordinar Lyz + comunidad de validación (Anahí · L1)
| Campo | Detalle |
|---|---|
| **Acción** | Confirmar la ventana de Lyz Escalante y arrancar en TribusRRHH como comunidad viva de validación (v03: motor de arranque). |
| **Observación si funcionó** | Lyz confirmada en la ventana; TribusRRHH recibe la primera activación. |
| **Observación si falló** | La agenda de Lyz no cuadra con el checkpoint. |
| **Causa de falla más probable** | Dependencia externa (riesgo 🟡 v03 §10). |
| **Contramove** | Fork: arrancar con comunidad propia + Rebelocity Club (laboratorio cross-vertical) sin bloquear por Lyz; Lyz se suma cuando su agenda abra. |
| **Fork/trigger** | Si Lyz es prerequisito absoluto en la mente del equipo → cuestionarlo: el soft-launch se diseñó escalonado justo para no depender de un solo canal. |

### MOVE 7 — Checkpoint 9–10 jul: el gate decide, no la presión (Anahí + Victor · L3)
| Campo | Detalle |
|---|---|
| **Acción** | Leer el checklist binario del MOVE 1. **Todo verde → lanzar escalonado.** Algo en rojo → **mover la fecha, no recortar el gate** (decisión ya tomada, minuta 2-jul). |
| **Observación si funcionó** | La decisión de lanzar/mover se toma leyendo el gate, en <30 min, sin debate emocional. |
| **Observación si falló** | El equipo lanza con condiciones en rojo "porque ya es la fecha" (el gate se saltó bajo presión). |
| **Causa de falla más probable** | Presión de fecha > disciplina del gate (el gate como política, no como reflejo). |
| **Contramove** | El gate es binario justo para esto: si una condición está en rojo, la conversación no es "¿lanzamos igual?" sino "¿qué falta y para cuándo". Mover la fecha NO es fracaso; saltar el gate sí. |
| **Fork/trigger** | Si se lanza con rojos → registrar en el Ledger qué condición se saltó y por qué (causa raíz real para el LabPraxis). |

---

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

| Trigger | Por qué aborta todo |
|---|---|
| La plataforma no soporta la carga básica (falla técnica dura, no de contenido) | El problema es de infra, no de lanzamiento. Resolver plataforma primero; mover el soft-launch completo. |
| Onboarding no cruza el wow tras 2 rondas de prueba **y** el Sherpa mismo falla (MOVE 2 fork) | Lanzar sería alimentar la brecha de activación a escala. Arreglar el Sherpa antes de traer tráfico. |
| ICP sin congelar (L8) al momento de activar el CEM | v03 §10: "el CEM no funciona sin ICP congelado". Activar el CEM sin ICP produce leads basura — mejor lanzar sin CEM que con CEM roto. |

**Lo que NO es causa de aborto:** membresía sin ratificar (Fork gratuito-con-límites, MOVE 4) · Lyz no disponible (Fork comunidad propia, MOVE 6) · telemetría instrumentada a medias (medición manual mínima, MOVE 3) · fecha movida (es el diseño, no una falla).

---

## 5. Criterios de éxito

**De la misión:** gate escrito como checklist binario con owner ✅ · onboarding probado con usuarios reales cruzando el wow en ≤2 min ✅ · telemetría que responde "% que habló con el Sherpa" ✅ · decisión de fecha tomada por el gate (no por presión) ✅ · si lanza: cadencia 6 sem agendada con dueño de canal + medición del reto activa.

**Del wargame:** todo move con ambas ramas observables ✅ · ≥1 fork explícito por fase ✅ (MOVES 1–7) · aborts definidos ✅ · variables indefinidas en Ledger con owner ✅ · ejecutable sin acceso a este chat ✅.

---

## 6. Handoff Spec

| Rol | Quién | Autonomía | Ratifica |
|---|---|---|---|
| Congelar gate, onboarding, calendario, coordinación, decisión de arranque | Anahí | L2 — ejecuta con guardarraíles | — |
| Landing, onboarding técnico, instrumentación de telemetría | Gustavo | L2 — ejecuta, audita humano | — |
| Specs de contenido y de telemetría, producción de piezas | Jay / agente | L2 | — |
| Membresías/pricing/límites + decisión de fecha (lanzar vs mover) | Victor | L3 — decisión humana obligatoria | Victor |

**Condición de arranque:** ratificación L3 de Victor sobre este wargame + resolución (o conversión a NEXT) de las variables L1–L8 del Ledger. La ejecución arranca en room aparte (superficie PROD) con este documento como contrato de misión. **El wargame NO se ejecuta hasta que Anahí/Victor digan "ratificado".**

---

## CHANGELOG

| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-07 | Creación. Wargame de WG-A1 (soft-launch MPX) sobre CP-MPX-PlanLanzamiento-v03 + diseño de gate de la minuta 2-jul: 7 moves alineados al gate de 7 condiciones + checkpoint, 3 aborts, 8 variables en Ledger (6 abiertas). Pre-mortem enfocado en la brecha de activación (🔴) y en que el gate se sostenga bajo presión de fecha. Ledger abierto — pendiente hardening con Anahí. |