---
type: WG
asset_id: WG-EL-FLA-F1-RegistroConsejero-v01
version: v01
status: Wargame completo — pendiente ratificación L3 para handoff
owner: Victor Heredia
sherpa_owner: Jay
ratificador: Victor Heredia
superficie: LAB
fecha_creacion: 2026-07-06
intellbank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank/PB-EL-IALab/WG-EL-WarRoom/Wargames
proposito: Wargame del pipeline F0→F1 de la Fuerza Laboral Agéntica (Registro Agéntico v1 + /consejero validado por no-Victor). Piloto #3 del formato WG- — el meta-caso.
mision_origen: PLAN-XX-BMF-FLA-F0F1-Ejecutable-v01 (F0 en ejecución desde 2026-06-20)
ejecutor_declarado: Jay (Shell Sonnet/Opus-class × fan-out subagentes, L1-L2 según workstream) · Victor (decisiones L3) · Runner no-Victor (a asignar — variable crítica V2)
canonicos_referenciados: PLAN-XX-BMF-FLA-F0F1-Ejecutable-v01 · PP-XX-BMF-FuerzaLaboralAgentica-Arquitectura-v01 · CP-XX-BMF-NomenclaturaInvocacion-v01 · SOP-EL-SkillsAlta-v01 · MePB-XX-BrainCode-Anatomy-v02
tags: [wargame, FLA, F0, F1, registro-agentico, consejero, LAB, piloto-WG, meta-caso]
---

# WARGAME — FLA · F0→F1: Registro Agéntico + Consejero
## ⚠️ ORDEN DE WARGAME: este documento SIMULA el pipeline move-by-move. NO lo ejecuta. Superficie: LAB.

---

## 1. Misión y Resultado Final

**Misión:** cerrar el Gate F0 (ontología ratificada + esquema + 4 decisiones L3) y ejecutar F1 completo hasta su gate: Registro v1 poblado, `/consejero` recomendando ≥80% del eval set, **operado end-to-end por alguien que no es Victor**.

**Resultado final simulado (Gate 1 WORX):** un colaborador del equipo plantea un problema real de LoopXDG y el `/consejero` devuelve la composición correcta (Shell × Brain Code(s) × autonomía + Loop Contract) sin que Victor intervenga — la primera evidencia operativa de que el ecosistema puede despachar inteligencia sin el héroe.

**Diagnóstico de arranque (por qué wargamear esto):** el plan es sólido pero tiene 2.5 semanas de vida y, según su propia cadencia (F0 = semanas 1-2), el Gate F0 ya debería estar cerrado — la evidencia sugiere deslizamiento por competencia de prioridades (Posta, DG, dashboards). Las fallas probables de este pipeline no son técnicas: son **de cola de decisiones L3, de trabajo mecánico masivo que se atora, y de una dependencia estructural (el Runner no-Victor) que nadie ha resuelto**. Además, el meta-riesgo: este pipeline valida si el ecosistema funciona sin Victor... y todos sus gates dependen de Victor.

---

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

| # | Variable | Supuesto de trabajo | Owner | Riesgo si falla |
|---|---|---|---|---|
| V1 | Estado real de F0 hoy: ¿qué falta exactamente? (ratificación sección-por-sección, CP-Ontología, schema, 4 decisiones) | F0 parcialmente avanzado, Gate NO cerrado | Victor·Jay | MOVE 1 lo cierra; si está más atrasado, la semana 1 absorbe todo F0 |
| V2 | **Runner no-Victor: sin asignar** ("candidato natural: implementation partner… rol de sistemas") | Sigue sin asignar — y la vacante ex-Carolina Rey + equipo cargado lo complican | Victor | **Variable crítica:** sin Runner, el Gate F1 NO PUEDE cerrar por diseño. Se resuelve en MOVE 1, no en semana 5 |
| V3 | **Alcance de manifiestos BC: el plan dice 33; el banco tiene hoy 58** | El catálogo creció desde junio; el plan quedó desactualizado | Victor | Decidir alcance en MOVE 1: ¿los 58, los 33 originales, o subset LoopXDG? (recomendación: subset primero — ver MOVE 3 fork) |
| V4 | ¿`/consejero` vive en plugin `worx-empowerlabs` o nuevo `worx-fla`? | Nuevo `worx-fla` (aísla el experimento, no contamina el plugin estable) | Victor | Menor — decidible en MOVE 4 |
| V5 | Problemas reales de LoopXDG para el eval set: el loop piloto está 🔴 (DG.1 recién desbloqueándose) | Hay suficiente material histórico (minutas, ANAs, plan GTM) para 10-15 problemas reales aunque el loop no esté a plena cadencia | Jay | Si el material no alcanza: fork del MOVE 5 |
| V6 | Nota BMF: existe `sx-consejero` como skill instalada — ¿es el MVP de F1-B ya en marcha o un prototipo previo al plan? | Prototipo previo; F1-B lo formaliza (o lo versiona) vía SOP | Jay | Duplicidad de despachadores — reconciliar en MOVE 4, no crear dos |

---

## 3. Secuencia move-by-move

### MOVE 1 — Cerrar Gate F0 en UNA sesión L3 (Victor · 45-60 min)
| Campo | Detalle |
|---|---|
| **Acción** | Sesión única con TODO el paquete de decisiones: (1) ratificar ontología Shell×BC×Harness×Gobernanza, (2) nombre (default: EmpowerTeamX), (3) ✅ loop piloto ya ratificado (LoopXDG), (4) factoría ¿producto o capacidad? (default: capacidad interna, reversible), **(5) asignar Runner no-Victor** (de facto la 5ª decisión L3 — el plan la dejó "a asignar" y es el gate más duro de F1), (6) alcance de manifiestos (V3). Jay llega con defaults argumentados; Victor elige o corrige. |
| **Observación si funcionó** | 6 decisiones registradas en 1 sesión; F0-A2 cambia el status de la propuesta a Canonical. |
| **Observación si falló** | "Lo veo el fin de semana" — las decisiones entran a la cola infinita de Victor. |
| **Causa de falla más probable** | El patrón transversal del ecosistema (mismo que DG.1 y POSTA.2): las decisiones L3 compiten contra clientes y fuego del día. |
| **Contramove** | Empaquetar como decisiones BINARIAS con default declarado: si Victor no corrige el default en la sesión, el default queda ratificado por excepción. La sesión es de 45 min porque elegir entre defaults argumentados no requiere más. |
| **Fork/trigger** | Si la decisión 4 (¿producto vendible?) genera debate largo → diferirla explícitamente (no bloquea F1; es decisión de F2+). Ninguna decisión de F0 se difiere EXCEPTO esa. |

### MOVE 2 — CP-OntologiaAgentica + Schema (Jay · L1 · timebox 3 días)
| Campo | Detalle |
|---|---|
| **Acción** | Redactar `CP-XX-BMF-OntologiaAgentica-v01` y `TP-XX-BMF-RegistroAgentico-Schema-v01` desde la propuesta ya ratificada + campos mínimos del anexo §6 del plan. |
| **Observación si funcionó** | Ambos activos en el vault en ≤3 días, ratificados en 1 pasada. |
| **Observación si falló** | Debate ontológico infinito ("¿exactamente dónde termina skill y empieza agente?"). |
| **Causa de falla más probable** | Perfeccionismo ontológico: tratar la ontología como filosofía en vez de como esquema de datos. |
| **Contramove** | La ontología se valida con USO, no con debate: si las 3 clases de entrada del Registro (AgentCard, Manifiesto, Composición) se pueden llenar sin ambigüedad para 5 casos reales, la ontología v01 está lista. v01 imperfecta y en uso > v03 perfecta en discusión. |
| **Fork/trigger** | Si un caso real no cabe en el esquema → se anota como excepción en el CHANGELOG del schema y se sigue; 3+ excepciones del mismo tipo = revisar el esquema (no antes). |

### MOVE 3 — Poblar el Registro v1 (Jay + fan-out subagentes · L2 · semana)
| Campo | Detalle |
|---|---|
| **Acción** | Estrategia de dos olas: **Ola 1 = subset LoopXDG** (shells Bloque A + AI Specialists de DG: linx, cara, celia, cody, sandra, sebo + titan · manifiestos de los ~10-12 BCs relevantes a DG: Hormozi, Walker, Priestley, Golden, etc. · composición Titan). **Ola 2 = el resto de los 58 BCs**, DESPUÉS del Gate F1. Producción: fan-out de subagentes que generan manifiestos draft desde los archivos BC- + QA muestral humano (10%). |
| **Observación si funcionó** | Ola 1 completa en ≤1 semana; cada entrada con frases-gatillo, sinónimos y alcance negativo (la metadata ES la superficie de routing). |
| **Observación si falló** | El poblado se atora a la mitad (trabajo mecánico masivo sin dueño diario) o las descripciones salen genéricas ("experto en marketing"). |
| **Causa de falla más probable** | Tratar 58 manifiestos como un solo lote heroico — exactamente el anti-patrón que la FLA quiere matar. |
| **Contramove** | La estrategia de olas ES el contramove (el eval solo necesita la Ola 1). Para calidad: template de manifiesto con campos obligatorios que fuerzan especificidad (3 frases-gatillo mínimo + 2 casos de NO-uso por entrada); QA muestral rechaza el lote si >20% falla. |
| **Fork/trigger** | Si el fan-out produce manifiestos inconsistentes entre sí → congelar, ajustar el template (no re-instruir agente por agente) y re-correr el lote. Fix the template, not the output. |

### MOVE 4 — `/consejero` MVP (Jay · L2 · con SOP de alta)
| Campo | Detalle |
|---|---|
| **Acción** | Skill `/consejero` que consulta el índice del Registro y RAZONA la recomendación (sin infra vectorial). Reconciliar con el `sx-consejero` existente (V6): una sola línea de despachadores, versionada. Alta por `SOP-EL-SkillsAlta` (7 pasos, editando SOURCE, no cache). Documentar en `DC-XX-BMF-Despachador-Diseno-v01`. |
| **Observación si funcionó** | `/consejero` responde un caso de prueba con composición + autonomía + Loop Contract; si falta cognición, receta crear el BC (no inventa). |
| **Observación si falló** | (a) Scope creep: "ya que estamos, agreguemos embeddings/multi-agente". (b) El skill se edita en cache y los cambios se pierden (falla conocida del ecosistema). |
| **Causa de falla más probable** | Sobre-ingeniería temprana — riesgo #1 declarado en el propio plan. |
| **Contramove** | Regla del plan como ley: *default single-agent, razonamiento sobre índice .md; nada vectorial hasta F2/F3, y solo con evidencia de que el índice no alcanza*. Para (b): checklist del SOP como gate del alta. |
| **Fork/trigger** | Si el razonamiento sobre índice falla por AMBIGÜEDAD (no por metadata pobre) → agregar el paso de refinamiento iterativo del diseño (preguntar antes de recomendar), NO infra nueva. |

### MOVE 5 — Eval set con trampas (Jay construye, Victor valida ground truth · L1)
| Campo | Detalle |
|---|---|
| **Acción** | `EVAL-XX-BMF-Despachador-v01`: 10-15 problemas reales de LoopXDG (fuentes: minutas, PLAN GTM, ANAs de demand gen, casos Posta-DG). Composición obligatoria del set: ~10 casos estándar + **3-4 casos trampa**: (a) problema SIN Brain Code existente → respuesta correcta = "receta crear BC", (b) problema fuera de dominio → derivar, no recomendar, (c) problema ambiguo → refinar con preguntas antes de recetar. |
| **Observación si funcionó** | Eval set balanceado; ground truth ratificado por Victor en 1 pasada. |
| **Observación si falló** | Eval set de puros casos obvios ("¿quién para ofertas?" → Titan) donde 80% no significa nada. |
| **Causa de falla más probable** | Circularidad: quien construye el eval conoce el catálogo y escribe problemas que calzan perfecto — el eval mide memoria, no despacho. |
| **Contramove** | Los casos trampa son obligatorios y pesan doble en el reporte. Fuente de problemas = documentos reales del vault (no inventados). El Runner aporta 2-3 problemas propios SIN ver el catálogo primero — esos son los casos más honestos del set. |
| **Fork/trigger** | Si V5 falla (no hay material DG suficiente) → completar con problemas reales de LoopXSA (Posta) — el despachador debe servir a cualquier loop; el piloto DG es foco, no jaula. |

### MOVE 6 — Correr eval + iterar (Jay · L2 · máx 2 iteraciones)
| Campo | Detalle |
|---|---|
| **Acción** | `/consejero` vs eval set; juez = LLM-as-judge + revisión humana de bordes. Métrica: % correctas (gate: ≥80%). |
| **Observación si funcionó** | ≥80% en la corrida 1 o 2, con los casos trampa correctos. |
| **Observación si falló** | <80% tras 2 iteraciones. |
| **Causa de falla más probable** | Descripciones pobres en el Registro — el plan lo declara: *la descripción ES la superficie de routing*. El routing falla por data, no por razonador. |
| **Contramove** | Regla de iteración: **primero se itera la METADATA del Registro** (frases-gatillo, alcance negativo), nunca el razonador. Cada fallo del eval se rastrea a su entrada del Registro y se corrige ahí. |
| **Fork/trigger** | Si tras 2 iteraciones de metadata sigue <80% → diagnóstico binario: ¿el eval está mal calibrado (revisar con Victor) o el matching por índice es insuficiente (entonces sí: refinamiento del pipeline front-door, documentado como aprendizaje para F2)? No parchar a ciegas una tercera vez. |

### MOVE 7 — Prueba de independencia del héroe (Runner · L2 · Victor AUSENTE)
| Campo | Detalle |
|---|---|
| **Acción** | El Runner (asignado en MOVE 1) opera el `/consejero` end-to-end en una sesión real: plantea SU problema de DG, recibe la receta, la interpreta y declara si le sirve. Victor NO participa ni observa en vivo (revisa la grabación/minuta después). |
| **Observación si funcionó** | El Runner llega a una receta accionable sin ayuda; sus fricciones quedan documentadas como backlog de UX del despachador. |
| **Observación si falló** | El Runner se atora en la INVOCACIÓN o interpretación (no en la recomendación) — el sistema funciona pero solo si sabes usarlo como Victor. |
| **Causa de falla más probable** | Conocimiento tácito de operación no documentado: el gate mide independencia del héroe y la falla típica es que el héroe está en los detalles de uso, no en las respuestas. |
| **Contramove** | El `/consejero` debe incluir su propio onboarding en la primera respuesta (qué es, qué le puedes pedir, ejemplo). Si el Runner se atora: documentar el punto exacto → ese es el hallazgo más valioso de todo F1, no un fracaso. |
| **Fork/trigger** | Runner no disponible llegada la semana 5 (V2 nunca se resolvió) → mínimo viable: un colaborador de OTRO frente corre UNA sesión guiada por escrito (sin Victor en el room). Menos limpio, pero el gate no se declara cumplido con Victor operando. **Jamás cerrar el Gate F1 con auto-validación.** |

---

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

| Trigger | Por qué aborta |
|---|---|
| Victor NO ratifica la ontología Shell×BC×Harness×Gobernanza en F0 (desacuerdo de fondo, no de forma) | Todo F1 construiría sobre arena: el Registro y el `/consejero` presuponen esa columna. Regresar a la propuesta PP-, resolver el desacuerdo, reintentar. |
| La plataforma de skills/plugins cambia de forma que rompe el harness del despachador | El MVP depende de skills instalables; si la superficie técnica cambia, re-especificar el harness antes de seguir construyendo. |
| El equipo entra en modo fuego total (p. ej. cierre Posta + evento Rebelocity simultáneos) y ni Jay tiene ciclos | Pausar FORMALMENTE con fecha de reanudación (el plan es interno, no tiene cliente esperando) — pausa declarada > avance zombie que produce un registro a medias sin eval. |

**Lo que NO es causa de aborto:** eval <80% (se itera con protocolo), Runner atorado en UX (es el hallazgo, no el fracaso), LoopXDG a media cadencia (fork del MOVE 5), decisión "¿producto vendible?" sin tomar (diferible declarada).

---

## 5. Criterios de éxito

**De la misión:** Gate F0 cerrado en 1 sesión L3 · Registro v1 Ola 1 poblado con metadata de calidad (QA muestral) · `/consejero` dado de alta por SOP (source, no cache) · eval ≥80% con casos trampa correctos · **prueba no-Victor ejecutada de verdad** · aprendizajes → CAS- al LoopXKZ.

**Del wargame:** ambas ramas observables ✅ · forks explícitos (MOVES 1-7) ✅ · aborts definidos ✅ · unknown-unknowns capturados (V2 Runner sin asignar como gate estructural · V3 deriva 33→58 BCs · V6 doble despachador · circularidad del eval · meta-riesgo "todos los gates anti-héroe dependen del héroe") ✅ · ejecutable sin este chat ✅.

---

## 6. Handoff Spec

| Rol | Quién | Autonomía | Ratifica |
|---|---|---|---|
| Sesión de decisiones F0 (paquete de 6) | Victor | L3 | — |
| CP-Ontología, Schema, poblado del Registro (fan-out), eval set, iteraciones de metadata | Jay (Shell Sonnet/Opus-class × subagentes) | L2 con QA muestral | Victor por excepción |
| Ground truth del eval | Victor | L3 (1 pasada) | — |
| Alta del skill `/consejero` | Jay vía SOP-EL-SkillsAlta | L1 (checklist como gate) | Victor |
| Prueba de independencia (MOVE 7) | **Runner no-Victor (asignar en MOVE 1)** | L2 | Tripleta revisa el reporte |

**Condición de arranque:** ratificación L3 de este wargame + MOVE 1 agendado (la sesión de 6 decisiones). V2 (Runner) y V3 (alcance 33 vs 58) se resuelven DENTRO del MOVE 1 — son decisiones, no investigación.

**Nota de conexión (IDE-060):** este pipeline es el candidato natural para adoptar el formato WG- como contrato de misión estándar de los despachos del `/consejero` — si F1 cierra, cada receta del despachador puede incluir un mini-WG (moves, forks, aborts) como parte de la composición recomendada. Registrado en el Idea Bank; decisión para F2.

---

## CHANGELOG

| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-06 | Creación. Piloto #3 del formato WG- (meta-caso: wargamear la iniciativa que institucionaliza el wargaming). Insumo: PLAN-XX-BMF-FLA-F0F1-Ejecutable-v01. Hallazgos de la simulación: (1) el Runner no-Victor sin asignar es el gate estructural más duro y nadie lo posee — se resuelve en MOVE 1, no en semana 5; (2) deriva del catálogo: plan dice 33 BCs, banco tiene 58 → estrategia de 2 olas (subset LoopXDG primero); (3) riesgo de circularidad del eval → casos trampa obligatorios + problemas del Runner sin ver catálogo; (4) meta-riesgo declarado: los gates anti-héroe dependen del héroe → paquete de 6 decisiones binarias con defaults en 1 sesión de 45 min. |