---
type: SP
asset_id: SP-EL-SOO-Wargame-ConnectorX-Fable5-v01
version: v01
tipo: SP — Starter Prompt / Room Kit (proceso ejecutable)
status: Draft · listo para correr · pendiente ratificación Victor
owner: Victor Heredia
sherpa: Jay
ratificador: Victor Heredia (L3+)
intellibank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank / PB-SOO-SistemaOperativoOrganizacional
proposito: >
  Proceso de análisis y planeación por método de Wargaming para la Órbita 3
  (Conectores · apuesta MCP-native + ConnectorX Registry) del MAP-EL-SOO-
  EcosistemaProyectado-v01. Incluye la validación de fit para Fable 5 y el
  room kit listo para correr (actores, rondas, escenarios, salidas de decisión).
relacionado:
  - MAP-EL-SOO-EcosistemaProyectado-v01 (§4 Órbita 3 · Conectores — fuente)
  - ARQ-XX-SOOI-DisenoConceptual-v01 (Cubo A/B · dónde vive el conector)
  - OUT-EL-SOO-Diagnostico-Fable5-v02 (precedente de uso de Fable5 en SOO)
  - MI-EL-SOO-Benchmark-Mercado-v01 (paisaje competitivo 2026)
gate_g0: PASS — deriva de MAP §4, benchmark externo del propio MAP, y precedentes Fable5 del PB-SOO
fecha_creacion: 2026-07-07
tags: [SP, wargame, conectores, mcp, connectorx, fable5, soo, planeacion, adversarial]
---

# SP · Wargame de Conectores (Órbita 3) — ConnectorX bajo fuego
## Proceso de análisis y planeación · validación Fable 5 · room kit listo para correr

> **Qué resuelve.** La Órbita 3 del ecosistema proyectado apuesta a **MCP-native**: WorX OS no fabrica conectores — cura, gobierna y ensambla conectores MCP existentes, con un **ConnectorX Registry** como diferenciador (registry + auth + audit trail + human-in-the-loop). Es la apuesta de mayor **dependencia externa** del mapa (un estándar que no controlamos) y de mayor **exposición de seguridad** (por donde entra el mundo real al Motor). Antes de escribir el SPEC del ConnectorX Registry conviene **estresar la apuesta**, no validarla en el vacío. Eso es este wargame.

---

## PARTE A · Validación — ¿es buen caso para Fable 5?

**Veredicto: Sí, es de los mejores casos de la lista — con una condición y un matiz.**

### Por qué SÍ (dónde Fable rinde de más)
1. **Es simulación adversarial multi-actor sobre gran contexto.** El wargame exige sostener a la vez: el MAP completo, el benchmark 2026 (MCP/AAIF, Agentforce, Copilot), la gobernanza del Registry y la dinámica de partners — sin contradecirse entre rondas. Ése es el músculo de un modelo grande.
2. **Es razonamiento contrafactual.** "¿Qué pasa si el estándar MCP se fragmenta / un hyperscaler lo captura / cambia el licenciamiento?" Generar y encadenar consecuencias de escenarios que aún no ocurren es exactamente donde un modelo chico se queda corto.
3. **Precedente propio validado.** El PB-SOO ya corrió diagnósticos con Fable5 (`OUT-EL-SOO-Diagnostico-Fable5-v02`, `OUT-EL-SOO-Fable5-ValidacionDiagnostico-v01`). No es un experimento: es continuar un patrón que ya rindió en este mismo proyecto.
4. **Timing.** Último día de Fable incluido = el heavy-lift generativo (armar el tablero + jugar Rojo/Azul/Verde) sale barato hoy.

### La condición (sin esto, el wargame alucina)
- **Aterriza el paisaje de amenaza con hechos reales.** La calidad del Rojo depende de datos externos actuales (estado de MCP/AAIF, movimientos de Agentforce/Copilot, incidentes de seguridad de conectores 2026). El MAP §9 ya trae citas — **aliméntalas**, y deja que Fable busque lo más reciente. Un wargame con amenazas inventadas entrena para una guerra que no existe.

### El matiz (regla que ya aplicamos en P1)
- **El que diseña no debe ser el único que valida.** Fable arma y corre el wargame HOY (generativo). Para el veredicto final conviene una **segunda pasada adversarial con otro modelo** (Opus) que ataque las conclusiones de Fable. Aquí es más suave que en P1 —el wargame ya es auto-adversarial por diseño— pero la segunda pasada sigue subiendo la calidad.

### Cuándo NO sería buen caso para Fable
- Si el objetivo real fuera solo **escribir el SPEC del ConnectorX Registry** (eso es ejecución, no wargame — lo hace cualquier modelo).
- Si no se puede aterrizar el paisaje externo (entonces primero investiga, luego wargamea).

> **Recomendación de camino:** correr las Partes B–C **con Fable 5 hoy**, alimentado con el MAP §4/§9 + búsqueda externa fresca. Segunda pasada de ataque con otro modelo cuando haya salida. La planeación (Parte D) se aterriza en el SPEC del Registry.

---

## PARTE B · El tablero del wargame

**Pregunta central que decide la partida:**
> ¿La apuesta MCP-native + ConnectorX Registry sobrevive a un mundo hostil —estándar que se mueve, competidores que comoditizan, seguridad que se rompe, verticales sin conector— **sin necesidad de rediseñar la arquitectura**? ¿Y el Registry sigue teniendo valor defendible aunque los conectores base sean gratis?

### Actores

| Célula | Rol | Juega |
|---|---|---|
| 🔵 **AZUL** — WorX OS | Defiende la estrategia de conectores | La arquitectura actual: curar+gobernar MCP, ConnectorX Registry, autonomía por clase de operación (leer=L2, escribir=L1, borrar=lista negra + kill-switch) |
| 🔴 **ROJO** — 5 células de amenaza | Rompe la apuesta | Cada célula ataca por su vector más fuerte (Parte C) |
| ⚪ **BLANCO** — Juez / Scenario Master | Conduce y puntúa | Marca cada jugada Roja como *Cubierta / Parcial / Hueco* contra el diseño Azul |
| 🟢 **VERDE** — Mercado / exógeno | Inyecta shocks | Evolución de MCP/AAIF, regulación, comportamiento de compra enterprise 2026 |

### Condiciones de victoria de AZUL (el diseño gana si…)
1. **Resiliencia de estándar:** la estrategia sobrevive a un giro de MCP (fork / captura por hyperscaler / cambio de licencia) **sin reescribir** — porque curamos, no dependemos de un fabricante.
2. **Cero exfiltración:** ningún conector gobernado permite fuga de datos cross-cliente ni bypass del human-in-the-loop en operaciones de escritura/borrado.
3. **Moat pese a gratis:** el Registry conserva valor defendible aunque los conectores base sean commodity gratuito (el valor vive en gobernanza + outcomes auditables, no en el cable).
4. **Cobertura vertical:** los conectores críticos del caso Posta (TMS/WMS) son **entregables** — vía curar, adaptar o build-mínimo, con una regla de decisión clara.
5. **Switching cost real:** la tesis de costo de cambio aguanta el escenario "el cliente trae sus propios conectores" (BYO) sin que el Registry se vuelva fricción neta.

---

## PARTE C · Las 5 células Rojas (vectores de ataque)

| # | Célula Roja | Vector más fuerte | Qué pone a prueba |
|---|---|---|---|
| R1 | **Riesgo de estándar** | MCP se fragmenta / un hyperscaler (MS, Google, AWS) captura la gobernanza del estándar / cambia licenciamiento o pricing del protocolo | Victoria #1 — ¿"curar no fabricar" nos protege o nos deja a merced del estándar? |
| R2 | **Comoditización competitiva** | Agentforce/Copilot incluyen conectores gobernados gratis en su plataforma; "¿por qué pagar un Registry aparte?" | Victoria #3 — ¿el moat es el cable o la gobernanza+outcomes? |
| R3 | **Brecha de seguridad** | Un conector curado exfiltra datos; servidor MCP malicioso (supply-chain); bypass del HITL; escritura no gobernada que contamina el Motor | Victoria #2 — ¿el Registry realmente contiene, o es teatro de gobernanza? |
| R4 | **Hueco vertical** | El TMS/WMS que Posta necesita **no existe** como servidor MCP maduro; "curar" falla porque no hay qué curar | Victoria #4 — ¿la regla curar/adaptar/build cubre el caso real, o se rompe en el primer vertical? |
| R5 | **Economía / BYO + partners** | El cliente trae sus propios conectores y ve el Registry como fricción; los partners no quieren gobernanza que los frene | Victoria #5 — ¿el costo de cambio es real o narrativo? |

---

## PARTE D · Estructura de juego (rondas) y salidas

**Turno de juego (repetir por cada célula Roja R1–R5):**

1. **R0 · Encuadre** (una vez) — BLANCO fija las 5 condiciones de victoria y lista los **supuestos actuales** del diseño Azul (curar+gobernar, Registry, autonomía por clase). VERDE fija el estado real del ecosistema MCP 2026 (con datos frescos).
2. **Jugada Roja** — la célula lanza su vector más fuerte + un "y luego qué" (segundo orden).
3. **Respuesta Azul** — AZUL responde con **la capa específica del diseño** que lo detiene (Registry, autonomía por clase, kill-switch, LabPraxis, tripleta…), o **concede el hueco**.
4. **Shock Verde** — VERDE inyecta un factor exógeno que empeora la jugada (ej. regulación de data-residency, un incidente MCP público).
5. **Fallo del Juez** — BLANCO marca: ✅ *Cubierta* (el diseño ya lo resuelve) · 🟨 *Parcial* (lo resuelve con trabajo extra) · 🟥 *Hueco* (no lo resuelve — riesgo abierto).

**Salidas del wargame (lo que produce):**

- **A · Matriz de resiliencia** — las 5 células × 5 condiciones de victoria, cada celda con veredicto Cubierta/Parcial/Hueco + evidencia.
- **B · Lista de huecos priorizada** — cada 🟥/🟨 con severidad × probabilidad, dueño y mitigación.
- **C · Reglas de decisión que el wargame obliga a fijar:**
  - **Curar / Adaptar / Build-mínimo** — el árbol de decisión para cuando un conector vertical no existe (disparado por R4/Posta).
  - **Autonomía por clase de operación** confirmada o ajustada (leer/escribir/borrar) + dónde es obligatorio el HITL.
  - **Criterio de admisión al Registry** — qué debe cumplir un servidor MCP para ser "conector aprobado" (auth, audit, procedencia, mantenedor).
- **D · Input directo a los NEXTs del MAP** — alimenta el `SPEC del ConnectorX Registry` (§11 del MAP) y "Validar Órbita 3 contra el caso Posta" con hallazgos, no con supuestos.

---

## PARTE E · Cómo correrlo (2 pasos)

1. **Hoy · Fable 5.** Abre room, pega este SP como contexto + el MAP-EL-SOO-EcosistemaProyectado-v01 (§4 y §9) + una búsqueda fresca del estado MCP/competidores 2026. Fable actúa como BLANCO (Scenario Master) y genera las jugadas de las 5 células Rojas, la respuesta Azul y los shocks Verdes, hasta producir las 4 salidas (A–D).
2. **Después · otro modelo (Opus).** Segunda pasada: que ataque las conclusiones de Fable — sobre todo las celdas marcadas ✅ *Cubierta* (buscar auto-complacencia). Los desacuerdos entre modelos son señal de dónde mirar.

**Entregable del room:** `OUT-EL-SOO-Wargame-ConnectorX-Resultados-v01` (matriz de resiliencia + huecos priorizados + 3 reglas de decisión) → ratificación Victor → alimenta el SPEC del ConnectorX Registry.

---

## Tripleta + NEXTs

- **Owner:** Victor · **Sherpa:** Jay · **Ratifica:** Victor (L3+) · **Corre el room:** Victor (o quien Victor designe)

**NEXTs**
- [ ] Correr Partes B–D con Fable 5 hoy (alimentado con MAP §4/§9 + búsqueda externa fresca).
- [ ] Producir `OUT-EL-SOO-Wargame-ConnectorX-Resultados-v01` (4 salidas).
- [ ] Segunda pasada de ataque con otro modelo sobre las celdas ✅.
- [ ] Volcar la lista de huecos y las 3 reglas de decisión al **SPEC del ConnectorX Registry** (NEXT del MAP §11).
- [ ] Cerrar el NEXT del MAP "Validar Órbita 3 contra el caso Posta" con los conectores TMS/WMS reales evaluados.

---

## CHANGELOG
| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-07 | Creación. Validación de fit Fable5 para wargamear la Órbita 3 (conectores) + proceso de wargaming completo: tablero, 5 condiciones de victoria, 5 células Rojas, estructura de rondas con Verde/Blanco, 4 salidas de decisión y camino de 2 pasos (Fable genera → otro modelo ataca). Deriva de MAP-EL-SOO-EcosistemaProyectado-v01 §4. |