---
type: WG
asset_id: WG-REB-OpsEventos-CorteManual-v01
version: v01
status: Ratificado (2026-07-08) — listo para handoff, arranque bajo demanda
owner: Juan Carlos Angeles Ramírez
sherpa_owner: JuanCarlosX
ratificador: Juan Carlos Angeles Ramírez (proceso propio del owner; escala a Victor solo si cifra a Federación comprometida)
superficie: LAB
fecha_creacion: 2026-07-07
intellbank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank/PB-EL-IALab/WG-EL-WarRoom/Wargames
nota_ubicacion: Entidad REB alojada en el War Room (EL/IALab); al ratificarse la estructura WG-, puede espejearse a IB-REB
proposito: Wargame del próximo corte MANUAL de ops de eventos (seguimiento de registro IRONMAN/L'Étape + cuota Federación) — la misión puente mientras el Motor de Reportes no está vivo. Cada move produce insumos del motor.
mision_origen: Mini-LoopX §1-§2 de PP-REB-JuanCarlos-InventarioProcesos-v01 · puente hacia P3
ejecutor_declarado: Juan Carlos (humano, L1) · Sonnet como copiloto de diff/reportes (L1)
canonicos_referenciados: PP-REB-JuanCarlos-InventarioProcesos-v01 · DC-REB-CuotaFederacion-Letape-SanBernardino2026-v01 · DC-REB-CuotaFederacion-5150-Encarnacion2026-v01 · DC-REB-CuotaFederacion-ResumenGeneral2026-v01 · WG-REB-MotorReportes-ConstruccionPipeline-v01 (hermano)
tags: [wargame, rebelocity, ops-eventos, corte-manual, cuota-federacion, puente, LAB, juancarlos]
---

# WARGAME — Ops Eventos REB · Próximo corte manual (misión puente)
## ⚠️ 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:** ejecutar el próximo corte bajo demanda (seguimiento de registro IRONMAN 5150/70.3 y L'Étape San Bernardino + cuota Federación) sin errores hacia la Federación y con el mínimo tiempo de JC — y que **ese mismo corte deje sembrados los insumos que el Motor de Reportes necesita** (exports de muestra, reglas de tags capturadas, plantilla v0, naming de cortes).

**Resultado final simulado:** corte completo de ambos eventos: diff de altas/bajas hecho con copiloto, hoja de Seguimiento y GHL actualizados, reporte de participantes + proyección entregados, cuota Federación reconciliada. Y como subproducto: V1, V2 y V3 del WG hermano (MotorReportes) resueltas **sin sesión extra** — el corte que igual había que hacer cierra el Ledger del motor.

**Por qué se wargamea un proceso "conocido":** porque es la última vez que debería correr a ciegas. El costo real no es este corte — es que cada corte sin capturar estructura perpetúa el crunch (el ⚠️ del barrido Fable). Esta misión convierte el desperdicio en inversión.

---

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

| # | Variable | Supuesto de trabajo | Owner | Riesgo si falla |
|---|---|---|---|---|
| V1 | Fecha del próximo corte | Bajo demanda, sin fecha dura (confirmado 2026-07-07). Supuesto: dentro de ≤14 días — si no, el WG hermano queda bloqueado en su MOVE 1 | **Juan Carlos** | "Bajo demanda" degrada a "cuando hay crisis": el corte se dispara tarde, con prisa, y no se captura nada para el motor |
| V2 | Ubicación y versión del corte ANTERIOR de cada evento (baseline del diff) | Están en Google Drive, identificables | **Juan Carlos** 🔴 ABIERTA (confirmar al arrancar) | Diff contra baseline equivocada = altas/bajas fantasma que contaminan CRM y cuota |
| V3 | Reglas de depuración de cuota (duplicados · retiros · pagos por transferencia fuera de plataforma) | Documentadas solo como categorías en los DC; el criterio fino vive en la cabeza de JC | **Juan Carlos** | Un caso nuevo que no encaje en las 3 categorías se resuelve por intuición y no queda registrado — el motor no podrá heredarlo |
| V4 | Tiempo de respuesta de la plataforma IRONMAN a la solicitud del CSV | 24-48h (histórico no registrado en el vault) | Juan Carlos (registrar esta vez) | Corte de IRONMAN se desfasa del de L'Étape; consolidado incompleto |
| V5 | Destinatarios reales del reporte de participantes y la proyección (quién lee, qué decide) | Equipo REB/dirección; se confirma en MOVE 4 con 5 líneas de JC | **Juan Carlos** 🔴 ABIERTA | La plantilla v0 se fija contra el destinatario equivocado y el motor hereda un formato que nadie usa |

---

## 3. Secuencia move-by-move

### MOVE 1 — Disparo del corte + solicitud CSV IRONMAN (JC · L1 · primer acto, no el último)
| Campo | Detalle |
|---|---|
| **Acción** | Al decidir el corte: PRIMERO solicitar el CSV a la plataforma IRONMAN (el paso con latencia externa), e inmediatamente descargar el XLSX de L'Étape (sin latencia). Registrar fecha/hora de la solicitud (dato para V4). |
| **Observación si funcionó** | Ambos archivos disponibles el mismo día, o IRONMAN en camino mientras L'Étape ya se procesa. |
| **Observación si falló** | La solicitud IRONMAN se hace al final del corte → todo el consolidado espera a un tercero. |
| **Causa de falla más probable** | Hábito secuencial: procesar L'Étape completo antes de acordarse de pedir IRONMAN. |
| **Contramove** | Regla fija: la solicitud IRONMAN es SIEMPRE el acto que abre el corte. Cero costo, elimina la espera en serie. |
| **Fork/trigger** | Si IRONMAN no responde en 48h → corte parcial solo L'Étape (entregable por sí mismo) + el consolidado se marca "parcial — IRONMAN pendiente" en vez de retenerse completo. |

### MOVE 2 — Diff vs corte anterior (Sonnet copiloto · L1 · JC valida)
| Campo | Detalle |
|---|---|
| **Acción** | Localizar el corte anterior (V2), correr la comparación con el copiloto (no a ojo), obtener altas/bajas. Guardar AMBOS archivos con naming BMF por fecha de corte — la convención que el motor consumirá después. |
| **Observación si funcionó** | Lista de altas/bajas en minutos; los archivos del corte quedan como pareja canónica identificable. |
| **Observación si falló** | No se sabe cuál es el archivo anterior "bueno" (varias copias en Drive sin fecha) o el diff da resultados absurdos (todos altas). |
| **Causa de falla más probable** | Baseline ambigua: años de archivos "final_v2_ahora_sí" sin convención. |
| **Contramove** | Antes de comparar, declarar la baseline en 1 línea ("corte anterior = archivo X del [fecha]") y guardarla renombrada. Si hay duda entre 2 candidatos → comparar contra ambos; el que produzca el diff coherente ES la baseline (y se registra). |
| **Fork/trigger** | Si el export nuevo cambió de estructura (columnas distintas) → NO forzar el diff a mano: registrar el cambio (insumo crítico para el motor, es su abort #2) y hacer el corte con lectura directa. |

### MOVE 3 — Hoja de Seguimiento + upsert GHL + tags (JC · L1 · con captura)
| Campo | Detalle |
|---|---|
| **Acción** | Vaciar altas en la hoja de Seguimiento, subir contactos a GHL y taguear. **Con captura:** cada vez que JC aplica un tag, dicta la regla en una línea ("registrado 70.3 + plan de cuotas → tag X"). Al final del move, las reglas dictadas = V3 del motor resuelta. |
| **Observación si funcionó** | CRM actualizado + lista de reglas de tags escrita (por primera vez fuera de la cabeza de JC). |
| **Observación si falló** | CRM actualizado pero cero reglas capturadas — el corte pasó y el conocimiento sigue tácito. |
| **Causa de falla más probable** | La captura se siente como trabajo extra a mitad del crunch y se salta "por esta vez". |
| **Contramove** | Formato mínimo: dictado por voz o una línea por tag en el chat del copiloto, que las compila. Si aún así se salta → el WG hermano vuelve a su MOVE 1 original (sesión de 30 min), sin drama pero declarado. |
| **Fork/trigger** | Tag ambiguo o caso nuevo sin regla → se anota como excepción con el criterio usado (así nace el catálogo de excepciones que el motor heredará en su cola). |

### MOVE 4 — Reporte de participantes + proyección → fijar plantilla v0 (Sonnet · L1 · JC ratifica)
| Campo | Detalle |
|---|---|
| **Acción** | Armar ambos reportes UNA vez más — pero esta vez el copiloto los produce como plantilla reutilizable (estilo Cuota Federación: tablas + resumen ejecutivo), no como documento desechable. Antes: JC responde en 5 líneas quién lee cada reporte y qué decide con él (V5). |
| **Observación si funcionó** | Los reportes salen Y queda una plantilla v0 con huecos parametrizados — el próximo corte (manual o motor) la llena en vez de rearmar. |
| **Observación si falló** | Reportes entregados desde cero otra vez; nada reutilizable queda. |
| **Causa de falla más probable** | Modo crunch: la urgencia de entregar gana a la estructura ("lo plantillo la próxima"). |
| **Contramove** | Invertir el orden: el copiloto arma primero el esqueleto de plantilla (10 min) y el corte se reporta LLENÁNDOLA — la estructura no compite con la urgencia, la sirve. |
| **Fork/trigger** | Si V5 revela que nadie usa la proyección (se hace por inercia) → se declara y se elimina del alcance del motor (mejor descubrirlo aquí que automatizar un reporte muerto). |

### MOVE 5 — Script Stripe + cuota Federación reconciliada (JC · L1)
| Campo | Detalle |
|---|---|
| **Acción** | Activar el script de revisión de pagos, aplicar la mecánica validada (Daily Pass=1 → tarifa por evento → suma por competición), depurar con checklist explícita de las 3 categorías (duplicados · retiros · transferencias) y producir los artefactos de cuota del corte. Cada excepción se anota con su criterio. |
| **Observación si funcionó** | Totales cuadran contra Stripe; excepciones listadas con criterio; artefactos en formato DC/BRD canónico. |
| **Observación si falló** | El total "no cuadra por poco" y se ajusta a mano sin rastro — la cifra sale pero el criterio se pierde (y el motor no podrá reproducirla jamás). |
| **Causa de falla más probable** | Pagos por transferencia fuera de plataforma detectados tarde, cuadrados de memoria. |
| **Contramove** | Regla dura: NINGÚN ajuste sin línea de registro ("−1 duplicado [nombre], +1 transferencia [fecha]"). El delta entre suma bruta y consolidado debe ser 100% explicable. |
| **Fork/trigger** | Diferencia inexplicada tras la checklist → NO se entrega el consolidado: reconciliación línea por línea contra Stripe primero (mismo principio que el abort del motor: cifra a Federación no viaja sin cuadrar). |

### MOVE 6 — Cierre Vault-First: sembrar el motor (JC + Sherpa · L1 · 10 min)
| Campo | Detalle |
|---|---|
| **Acción** | Registrar el corte en el vault: (a) exports del corte guardados con naming BMF → **V2 del motor resuelta**, (b) reglas de tags compiladas → **V3 del motor resuelta**, (c) nombres reales de hoja/listas/workflows/script anotados al pasar por ellos → **V1 del motor resuelta**, (d) plantilla v0 persistida, (e) tiempo total del corte cronometrado (baseline del ROI del motor). |
| **Observación si funcionó** | El Ledger del WG-REB-MotorReportes queda cerrado como subproducto; su MOVE 1 se marca cumplido vía contramove. |
| **Observación si falló** | El corte terminó, el cansancio ganó, nada se registró — el motor sigue bloqueado y este wargame se corrió para nada estructural. |
| **Causa de falla más probable** | El cierre administrativo siempre pierde contra el siguiente pendiente. |
| **Contramove** | Los 10 minutos de cierre se hacen ANTES de entregar los reportes (la entrega es el premio, no el final): entregar = último acto del corte. |
| **Fork/trigger** | Si algo quedó sin capturar → NEXT específico con fecha en la minuta del día (no "pendiente genérico"). |

---

## 4. Condiciones de aborto

| Trigger | Por qué aborta |
|---|---|
| Export corrupto o con estructura cambiada que no se deja leer con confianza | No forzar interpretación a ojo: datos de identidad y dinero no se adivinan. Registrar, pedir re-export, corte se pausa. |
| Cuota que no cuadra tras checklist + reconciliación Stripe | El consolidado NO viaja a la Federación con diferencia inexplicada — es el único daño reputacional real de la misión. |

**Lo que NO aborta:** retraso del CSV IRONMAN (fork de corte parcial) · ausencia de plantilla previa (v0 nace aquí) · caso de depuración nuevo (se anota con criterio y sigue) · saltarse la captura de tags (degrada la siembra del motor, no el corte).

---

## 5. Criterios de éxito

**De la misión (máximo → mínimo):**
- 🥇 Corte completo de ambos eventos + cuota reconciliada + las 5 siembras del MOVE 6 hechas (Ledger del motor cerrado sin sesión extra).
- 🥈 Corte completo de L'Étape con cuota entregable + al menos exports guardados y tags capturadas (siembra parcial).
- 🥉 **Mínimo aceptable:** cuota Federación correcta y 100% explicable de al menos 1 evento.
- 🚫 **Resultado prohibido:** consolidado entregado con ajustes sin rastro — cifra correcta hoy, irreproducible mañana.

**Del wargame:** ramas observables ✅ · forks (MOVES 1-6, aborts) ✅ · unknown-unknown capturado (el corte como último portador del conocimiento tácito: si pasa sin captura, el crunch se renueva) ✅ · ejecutable sin este chat ✅.

---

## 6. Handoff Spec

| Rol | Quién | Autonomía | Ratifica |
|---|---|---|---|
| Disparo, solicitud IRONMAN, decisiones de depuración | Juan Carlos (humano) | L1 | — (proceso propio) |
| Diff, compilación de reglas de tags, plantilla v0, artefactos de reporte | Sonnet (copiloto en vivo) | L1 | Juan Carlos en el momento |
| Consolidado de cuota hacia la Federación | Juan Carlos | L1 | **Juan Carlos como owner; escala a Victor (L3) SOLO si hay diferencia inexplicada o cambio de cifra ya entregada** |
| Cierre Vault-First (MOVE 6) | JuanCarlosX (Sherpa) | L1 | Juan Carlos |

**Condición de arranque:** ratificación del owner ("ratificado"). Sin dependencias externas: el corte puede arrancar el mismo día. **Regla para el copiloto (Sonnet):** nunca decide sobre identidad de personas ni sobre dinero — toda ambigüedad se presenta a JC como excepción con opciones, no como hecho.

---

## 7. CHANGELOG

| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-07 | Creación (draft + hardening, 2 pasadas). Insumos: PP-InventarioProcesos §1-§4, DC de cuota Federación, WG hermano MotorReportes. Hallazgos de la simulación: (1) la misión real no es "hacer el corte" sino hacer el ÚLTIMO corte a ciegas — cada move siembra el motor (exports, tags, plantilla v0, nombres reales, baseline de tiempo); (2) la solicitud del CSV IRONMAN debe abrir el corte, nunca cerrarlo (latencia externa en serie = desperdicio evitable con costo cero); (3) el riesgo silencioso es el ajuste de cuota sin rastro — cifra correcta pero irreproducible; regla de delta 100% explicable; (4) el MOVE 6 va antes de la entrega porque el cierre administrativo siempre pierde contra el siguiente pendiente. |
| v01 | 2026-07-08 | Ratificado tal cual por el owner (Juan Carlos). Queda listo para handoff y puede arrancar bajo demanda. V2 (baseline del corte anterior) y V5 (destinatarios del reporte/proyección) siguen 🔴 abiertas — confirmar al arrancar el corte. |
| v01 | 2026-07-08 | **Ejecutado** (mismo día de la ratificación, ~90 min, JC + Sonnet copiloto). Resultado: 🥇 máximo — corte completo de ambos eventos (L'Étape San Bernardino +1, IRONMAN 70.3 Encarnación +16), cuota Federación reconciliada, y las 5 siembras del MOVE 6 hechas sin sesión extra (Ledger de WG-REB-MotorReportes: V1/V2 resueltas, V3 parcial). V2 se resolvió con un giro real: el "corte anterior" de L'Étape resultó ser el mismo archivo que se había tomado por "nuevo" (mismo naming, corte del día siguiente lo destrabó). V5 resuelta: lee Víctor/Ángeles/JC, alimenta campañas de marketing y presupuesto de materiales. Hallazgos no anticipados por el WG original: (a) la solicitud IRONMAN es a Víctor (persona), no a "la plataforma" — dependencia interna tipo P022, no SLA externo; (b) el "script Stripe" del WG hermano no es el mecanismo de cuota Federación — son 2 sistemas distintos, recalibración aplicada en WG-REB-MotorReportes; (c) cuota L'Étape en persona (retiro de kit, ~6-sep) es un riesgo declarado para el corte de cierre, no para este. |
| v01 | 2026-07-08 | **Corrección post-cierre, mismo día:** Víctor entregó después el set completo de reportes IRONMAN, incluyendo `export_tickets` (1 fila = 1 persona real). Se descubrió que el campo QTY de `export_orders` NO equivale a personas en órdenes de equipo/relay — el conteo de IRONMAN 70.3 baja de 204 a **180 registrados reales** (171 individuales + 9 en 3 equipos relay de 3; la 4ª "orden relay" resultó ser una inscripción individual reembolsada). Cuota Federación corregida: L'Étape $100 + IRONMAN $1,893.60 = **$1,993.60 USD total** (antes se había reportado $2,246.08). El hueco de identidad de equipos relay quedó resuelto — `export_tickets` trae nombre/email de cada integrante. `export_tickets` pasa a ser la fuente canónica para IRONMAN de aquí en adelante (ya reflejado en `DC-REB-CuotaFederacion-IM703-Encarnacion2026-v01` y en la plantilla de participantes). |