---
type: WG
asset_id: WG-REB-MotorReportes-ConstruccionPipeline-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 (ratifica con delegación explícita de Víctor Heredia, 2026-07-08: "lo que yo decida está bien")
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 de la construcción del Motor de Reportes Rebelocity (P3 del barrido Fable) — el pipeline que reemplaza el crunch manual de @JuanCarlos en seguimiento de registro y cuota Federación
mision_origen: P3 (OUT-EL-BarridoFrentes-ProyectosFable-20260707-v01) · TP-REB-JuanCarlos-MotorReportes-Arranque-v01
ejecutor_declarado: Opus 4.8 / Sonnet (spec y construcción, L2) · Juan Carlos (datos, validación con corte real, L1) · Victor (ratificación L3)
canonicos_referenciados: TP-REB-JuanCarlos-MotorReportes-Arranque-v01 · PP-REB-JuanCarlos-InventarioProcesos-v01 · DC-REB-CuotaFederacion-ResumenGeneral2026-v01 · DC-REB-CuotaFederacion-Letape-SanBernardino2026-v01
tags: [wargame, rebelocity, motor-reportes, pipeline, ghl, njuko, cuota-federacion, LAB, juancarlos]
---

# WARGAME — Motor de Reportes REB · Construcción del pipeline
## ⚠️ 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:** convertir los 2 Mini-LoopX manuales de @JuanCarlos (seguimiento de registro IRONMAN 5150/70.3 y L'Étape San Bernardino + cuota Federación) en un pipeline automatizado, parametrizable por evento, que corra bajo demanda — y devolver a JC a su rol real (funnel Re100X · delivery MONEX · cierre comercial).

**Resultado final simulado:** JC dispara el pipeline con un export nuevo; el sistema produce el diff de altas/bajas, actualiza la hoja de Seguimiento, hace upsert + tags en GHL, genera reporte de participantes + proyección (plantillas nuevas, estilo Cuota Federación) y los 3 artefactos de cuota (DC individual · BRD tablero · DC consolidado) **calculados con la mecánica real de cada evento** (IRONMAN: registrados × $10.52 · L'Étape: Daily Pass=1 × $10). Aparte, un segundo pipeline (independiente de la cuota) automatiza el disparo de "Invites" cuando un atleta completa su plan de pago en cuotas vía Stripe/GHL. JC solo revisa una **cola de excepciones** (duplicados reales vs. identidad compartida, retiros, transferencias fuera de plataforma, equipos relay sin identidad individual). De operador a revisor.

**Decisiones ya tomadas por el owner (no re-preguntar):** disparador bajo demanda sin ritmo fijo · clasificación mixta SA→OP · **piloto = L'Étape** (descarga directa, mecánica de cuota ya validada; IRONMAN se parametriza después) · plantillas nuevas en **estilo Cuota Federación** (tablas + resumen ejecutivo + tablero HTML).

**Fuera de alcance:** funnel Re100X y delivery MONEX (el motor libera tiempo hacia allá; no se automatizan aquí).

---

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

| # | Variable | Supuesto de trabajo | Owner | Riesgo si falla |
|---|---|---|---|---|
| V1 | Nombres reales de los activos: hoja "Seguimiento al registro", Smart Lists, Workflows GHL, script Stripe | Existen y funcionan; JC los entrega como NEXT (lo pospuso en el inventario y de nuevo el 2026-07-07) | **Juan Carlos** ✅ RESUELTA (2026-07-08, vía corte manual WG-REB-OpsEventos) | ~~Pipeline diseñado contra activos imaginados~~ — hoja real = pestaña **"Registrados"** del Google Sheet (no "Seguimiento al registro"); upsert/tags a GHL se hace **vía Claude Code** (no este Cowork); "script Stripe" **no es de cuota Federación** — es el seguimiento de los planes de pago en cuotas (GHL+Stripe) que generan el "Invite" de registro gratuito. Recalibrar MOVE 5 abajo. |
| V2 | Estructura real de los exports: columnas del XLSX L'Étape (Njuko) y del CSV IRONMAN | Contienen al menos: identidad del registrante, distancia/competición, "Daily Pass", fecha | **Juan Carlos** ✅ RESUELTA (2026-07-08, corregida el mismo día) | Confirmado: L'Étape (Njuko) tiene **2 exports distintos** — uno general (`id, First name, Last name, Email, Competition, Registration amount`) y uno de cuota (`id, First name, Last name, Email, Daily Pass` — valores '', 0, 1; "0" se trata igual que blanco). **IRONMAN tiene 5 tipos de export** (Víctor los entregó todos): `export_orders` (1 fila/orden, útil para montos pero **el campo QTY NO equivale a personas** en órdenes de equipo — confirmado con casos reales), `export_tickets` (**1 fila = 1 persona real**, con Attendee First/Last Name, Attendee Email, Ticket Status — **esta es la fuente canónica para contar personas y equipos relay**), `export_attendees`, `export_purchasers`, `export_shipping`. Un mismo export trae ambos eventos del año (5150 + 70.3, filtrar por Event Name). Equipos relay: **identidad individual resuelta** vía `export_tickets` (ya no es un hueco). Muestras guardadas: `DC-REB-LEtape-SanBernardino-Corte2026070[7-8]-v01.xlsx` · `DC-REB-IM703-Encarnacion-Corte202605[16]/0608-v01.csv` (orders) · `DC-REB-IMTickets-Corte20260608-v01.csv` (tickets, canónico). |
| V3 | Reglas de tagging en GHL ("tags según corresponda") | Viven en la cabeza de JC; se capturan en MOVE 1 o durante el corte manual (ver WG-REB-OpsEventos) | **Juan Carlos** 🟡 PARCIAL (1ª regla real capturada 2026-07-08) | Primera regla documentada: `128KM DISTANCE San Bernardino + pagado → tags "letape" + "letape-part-sanber26"` — patrón inferido: `letape-part-<sede><año>`. Solo 1 alta en este corte; faltan reglas de las demás distancias/eventos — se sigue capturando corte a corte. |
| V4 | Acceso programático a GHL para upsert + tags | El plugin/MCP GoHighLevel del Cowork de JC sirve como vía de escritura | Juan Carlos (validar) | Fallback declarado: generar CSV de import manual a GHL (MOVE 3, fork) |
| V5 | Dónde vive y corre el pipeline (script local · Apps Script · skill de Cowork) | Skill/script ejecutable bajo demanda por JC o su Sherpa; se decide en la spec (MOVE 2) | Ejecutor propone · JC ratifica | Un pipeline que JC no pueda disparar solo re-crea la dependencia que se quiere eliminar |
| V6 | Método de "proyección de inscripciones" (hoy se inventa desde cero cada corte) | Baseline simple: tendencia semanal + comparación contra curva del evento previo si existe | Ejecutor propone · JC ratifica | Proyección sin método declarado = número decorativo; JC deja de usarla |

**Resueltas en vivo (2026-07-07):** piloto = L'Étape · plantillas = estilo Cuota Federación · sin fecha dura externa.

**Baseline de ROI (2026-07-08):** corte manual completo de ambos eventos (L'Étape San Bernardino + IRONMAN 70.3 Encarnación) = **~90 minutos** de principio a fin (JC + Sonnet copiloto), incluyendo la siembra de este Ledger. Referencia para medir el ahorro real una vez el motor esté construido.

> ⚠️ **Recalibración pendiente de MOVE 5 (hallazgo del corte manual 2026-07-08):** el MOVE 5 tal como está escrito abajo asume que "el script Stripe" automatiza la cuota Federación. Es incorrecto — son 2 sistemas separados: (1) la cuota Federación se calcula distinto por evento (IRONMAN: obligatoria, empaquetada en el pago salvo invitados que la pagan aparte en sitio oficial — pero *todo* registrado en el CSV ya la pagó, así que el cálculo es directo: registrados × $10.52; L'Étape: opcional online vía Daily Pass, o en persona al retirar kit un día antes del evento — el método actual queda corto cerca del cierre); (2) el script de Stripe/GHL rastrea planes de pago en cuotas de inscripción (no de Federación) y genera los "Invite" de registro gratuito. **Antes de construir MOVE 5, reescribirlo separando ambos flujos.**

---

## 3. Secuencia move-by-move

### MOVE 1 — Cerrar V1+V2+V3 con el owner (Juan Carlos · humano · L0 · gate de entrada)
| Campo | Detalle |
|---|---|
| **Acción** | Sesión asincrónica de ~30 min: JC entrega (a) nombres reales de hoja/Smart Lists/Workflows/script, (b) 1 export de muestra por plataforma (XLSX L'Étape, CSV IRONMAN) a IB-REB, (c) las reglas de tags dictadas como lista "si X → tag Y". |
| **Observación si funcionó** | Checklist de 10 datos concretos respondido; muestras en el vault con naming BMF. |
| **Observación si falló** | Tercer aplazamiento (patrón: ya se pospuso en el inventario y en la sesión de wargame). |
| **Causa de falla más probable** | El crunch mismo: JC no tiene 30 min porque está haciendo a mano lo que este motor automatiza — círculo vicioso. |
| **Contramove** | Empaquetarlo dentro del próximo corte manual (WG-REB-OpsEventos MOVE 6 guarda los exports y captura las tags al aplicarlas) — el corte que igual va a hacer resuelve el Ledger sin sesión extra. |
| **Fork/trigger** | Si a los 14 días V1/V2 siguen abiertas → escalar a Victor (el arrastre de P3 mantiene a JC en el pozo; es decisión de prioridad, no técnica). |

### MOVE 2 — Spec del pipeline (Opus 4.8 · L2 · 1 sesión)
| Campo | Detalle |
|---|---|
| **Acción** | Producir `SPEC-REB-JuanCarlos-MotorReportes-v01`: arquitectura de los 2 pipelines (§4 del TP), con el **evento como parámetro** (fuente, formato, columnas, tarifa de cuota, tags, plantillas). Decide V5 (dónde corre) y propone V6 (método de proyección). |
| **Observación si funcionó** | La spec permite describir un evento nuevo llenando una tabla de parámetros — sin tocar código. Cubre la cola de excepciones (duplicados/retiros/transferencias). |
| **Observación si falló** | Spec genérica tipo "ETL de registros" que no menciona Daily Pass, tarifas por evento ni depuración manual — otro documento de diseño que nadie usa. |
| **Causa de falla más probable** | Ejecutar el MOVE con V2 abierta y rellenar con columnas inventadas. |
| **Contramove** | Si V2 sigue abierta: spec con interfaz de columnas marcada "A CONFIRMAR" + gate duro — el MOVE 3 no arranca hasta validar contra el export real. |
| **Fork/trigger** | Si la spec revela que el script Stripe existente ya cubre >50% del pipeline de cuota → cambiar de "construir" a "extender" (menos código nuevo, menos riesgo). |

### MOVE 3 — Construcción del pipeline de seguimiento, piloto L'Étape (Sonnet/Opus · L2)
| Campo | Detalle |
|---|---|
| **Acción** | Implementar: ingesta XLSX → diff vs corte anterior (altas/bajas) → upsert en hoja de Seguimiento → upsert + tags en GHL (vía V4). |
| **Observación si funcionó** | Con 2 exports históricos reales, el diff reproduce exactamente las altas/bajas que JC detectó a mano en su momento. |
| **Observación si falló** | Falsos positivos/negativos en el diff: mismos atletas contados como altas nuevas, o bajas fantasma. |
| **Causa de falla más probable** | Clave de identidad mal elegida (nombre con tildes/mayúsculas inconsistentes, sin ID estable de plataforma) — el clásico de los diffs de registros. |
| **Contramove** | Clave compuesta (ID de plataforma si existe; si no, email normalizado) + toda ambigüedad va a la **cola de excepciones para juicio de JC** — el pipeline nunca decide solo sobre identidad. |
| **Fork/trigger** | Si V4 falla (GHL sin vía programática confiable) → el pipeline emite CSV listo para import manual a GHL; la automatización del upsert se difiere sin bloquear el resto. |

### MOVE 4 — Plantillas: reporte de participantes + proyección (Sonnet · L2)
| Campo | Detalle |
|---|---|
| **Acción** | Diseñar las 2 plantillas que hoy no existen (el mayor desperdicio identificado: se arman desde cero cada corte), en estilo Cuota Federación, generadas por el pipeline. Proyección según método V6. |
| **Observación si funcionó** | JC valida que el reporte responde lo que le preguntan (equipo/dirección) sin retoques manuales. |
| **Observación si falló** | JC lo "completa a mano" después de cada corrida — la plantilla no capturó lo que realmente se reporta. |
| **Causa de falla más probable** | Diseñar desde el formato y no desde el destinatario: nadie preguntó qué decisión alimenta cada reporte. |
| **Contramove** | Antes de fijar la plantilla, JC dicta en 5 líneas quién lee cada reporte y qué decide con él (variable ligera; si no la sabe → el reporte reproduce el último que armó a mano, v0 declarada como provisional). |
| **Fork/trigger** | Si el corte manual puente (WG-REB-OpsEventos MOVE 4) ya fijó una plantilla v0 → heredarla, no rediseñar. |

### MOVE 5 — Pipeline de cuota Federación (Sonnet · L2 · mecánica corregida por evento, 2026-07-08)
| Campo | Detalle |
|---|---|
| **Acción** | Automatizar la cuota Federación — **2 mecánicas distintas, no una sola** (corrección del 2026-07-08, ver recalibración arriba): **(a) IRONMAN** (5150/70.3): usar **`export_tickets`, NUNCA `export_orders`/QTY** (QTY no equivale a personas en órdenes de equipo — confirmado con casos reales donde QTY=9 eran en realidad 3 personas, y una orden QTY=6 era 1 sola inscripción reembolsada) → filtrar por `Event` → contar tickets con `Ticket Status` ≠ "Refunded" → total = tickets válidos × $10.52. **(b) L'Étape**: usar el export específico "Daily Pass" de Njuko (distinto del export general de registro) → filtrar Daily Pass=1 (tratar "0" igual que blanco) → total = pagantes × $10. En ambos: depurar con checklist de 3 categorías (duplicados · retiros · transferencias fuera de plataforma) y producir 3 artefactos por evento (DC individual · BRD.html · DC consolidado). |
| **Observación si funcionó** | Contra el corte histórico del 2026-07-08 (ya corregido), los totales igualan los reportes manuales ya entregados, al centavo: L'Étape $100 · IRONMAN 70.3 $1,893.60 (180 tickets válidos). |
| **Observación si falló** | Totales no cuadran, o el pipeline usa QTY de `export_orders` en vez de `export_tickets` para IRONMAN (error ya cometido una vez en este mismo corte), o mezcla los 2 eventos IRONMAN del año, o inventa pagos en persona de L'Étape que nadie registró. |
| **Causa de falla más probable** | Confundir la cuota Federación con el pipeline de planes de pago Stripe/GHL (MOVE 6, sistema separado) — el error que este WG mismo tenía hasta el 2026-07-08. |
| **Contramove** | Cuota Federación y planes de pago Stripe/GHL son pipelines separados (nunca el mismo código). Ninguna excepción se auto-descarta: delta siempre explicado ("consolidado = suma bruta − N excepciones aprobadas por JC"). "Duplicados" por email compartido NUNCA se colapsan sin verificar identidad real (caso conocido: atletas que inscriben a otros con su propia cuenta). |
| **Fork/trigger** | **Hueco declarado, no resuelto:** el pago de cuota en persona de L'Étape (retiro de kit, ~1 día antes del evento) no tiene ninguna fuente digital — el pipeline no puede capturarlo solo; activa un fork de captura manual complementaria cerca de cada fecha de evento. Diferencia inexplicada tras revisar excepciones → congelar entrega del consolidado y reconciliar línea por línea (nunca cifra a Federación sin cuadrar). |

### MOVE 6 — Pipeline de planes de pago en cuotas Stripe/GHL → disparo de "Invite" (Sonnet · L2 · sistema nuevo, separado de la cuota Federación)
| Campo | Detalle |
|---|---|
| **Acción** | Automatizar el seguimiento de los planes de pago en cuotas que Rebelocity ofrece (landing pages + formularios GHL + Stripe) porque IRONMAN/L'Étape no permiten pagar la inscripción en mensualidades en sus plataformas oficiales. Al completarse el último pago del plan, disparar automáticamente el envío del "Invite" (enlace especial) para que el atleta se registre en la plataforma oficial pagando solo la cuota Federación (o gratis, según el evento). **No toca la cuota Federación** — es un pipeline independiente del MOVE 5. |
| **Observación si funcionó** | Cero intervención manual entre "plan completado" y "Invite enviado"; los invitados aparecen después en el export oficial con `Total Amount Paid` = solo cuota (ej. $10.52 en IRONMAN, "Individual Entry-Complimentary"). |
| **Observación si falló** | Atletas que terminan su plan no reciben el Invite a tiempo, se frustran o pagan la inscripción completa por error en la plataforma oficial (doble cobro). |
| **Causa de falla más probable** | El envío del Invite queda en manos de alguien que se acuerde — sin trigger automático desde GHL, depende de memoria humana (el mismo patrón P022: dependencia no empaquetada). |
| **Contramove** | Workflow de GHL disparado automáticamente al completarse el plan — cero dependencia de que alguien lo note. |
| **Fork/trigger** | Si GHL no soporta el trigger nativo con la confiabilidad necesaria → cola de revisión diaria como fallback (igual que el fork de V4 para el upsert). |

### MOVE 7 — Prueba con corte real + doble corrida (JC + Sonnet · L1)
| Campo | Detalle |
|---|---|
| **Acción** | Correr el pipeline contra un corte real de L'Étape y comparar contra el proceso manual. Luego **2 cortes en paralelo** (manual + motor) antes de apagar el manual. |
| **Observación si funcionó** | 2 corridas paralelas sin diferencias inexplicadas; JC declara el manual apagado. |
| **Observación si falló** | JC sigue corriendo el proceso manual "por si acaso" indefinidamente — automatización zombi: doble trabajo en vez de menos. |
| **Causa de falla más probable** | Desconfianza racional: una cifra que va a la Federación no se delega a un pipeline no probado. La doble corrida ES el contramove — genera la evidencia de confianza. |
| **Fork/trigger** | Si la corrida paralela revela reglas de depuración aún no capturadas → se codifican y se agrega UNA corrida paralela más (máximo 3; a la tercera con diferencias → volver a MOVE 5). |

### MOVE 8 — Parametrizar IRONMAN + handoff final (Sonnet · L2 → JC · L1)
| Campo | Detalle |
|---|---|
| **Acción** | Alta de IRONMAN como segundo evento (solo parámetros, cero código nuevo si la spec cumplió) + checklist de arranque por evento nuevo (§3 del inventario) + actualizar `PP-REB-JuanCarlos-InventarioProcesos` marcando qué quedó automatizado. |
| **Observación si funcionó** | IRONMAN corre con la misma maquinaria; el checklist permite dar de alta el siguiente evento sin el ejecutor original. |
| **Observación si falló** | IRONMAN requiere reabrir código → la parametrización era cosmética. |
| **Causa de falla más probable** | Diferencias no mapeadas entre plataformas (solicitud manual del CSV, columnas distintas) minimizadas durante la spec. |
| **Contramove** | El MOVE 2 exige la tabla de parámetros con AMBOS eventos desde el día 1 (aunque solo L'Étape se construya primero). |
| **Fork/trigger** | La solicitud manual del CSV IRONMAN no es automatizable → queda declarada como paso humano del checklist (no es falla del motor; es frontera del sistema). |

---

## 4. Condiciones de aborto

| Trigger | Por qué aborta |
|---|---|
| V1/V2 abiertas a los 14 días tras escalar a Victor | Sin datos reales el motor es ficción; congelar el WG- (no arrastrarlo como zombi) y registrar la causa en la minuta. |
| La plataforma (Njuko/IRONMAN) cambia la estructura del export a mitad de construcción | Pausar MOVE 3-6, re-validar V2 contra el formato nuevo, ajustar spec — construir contra un blanco móvil quema al ejecutor. |
| Cifra a Federación comprometida: el pipeline entrega un consolidado errado a un tercero oficial | Stop total + reconciliación + post-mortem antes de re-activar. Es el único daño reputacional real de esta misión. |

**Lo que NO aborta:** diferencias en la primera corrida paralela (reconciliar es parte del diseño) · V4 fallando (fork de CSV manual) · falta de plantilla previa (se diseña aquí) · el CSV IRONMAN tardando (frontera humana declarada).

---

## 5. Criterios de éxito

**De la misión (máximo → mínimo):**
- 🥇 Pipeline parametrizable corriendo ambos eventos, 5 salidas automáticas (diff, CRM, 2 reportes nuevos, cuota), JC solo revisa cola de excepciones. Manual apagado tras doble corrida.
- 🥈 Pipeline L'Étape completo end-to-end + IRONMAN parametrizado pendiente de su primer corte real.
- 🥉 **Mínimo aceptable:** pipeline de cuota Federación automatizado para L'Étape (la mecánica más madura) + plantillas v0 fijadas + diff funcional.
- 🚫 **Resultado prohibido:** otra spec/documento sin código corriendo — el vault ya tiene el diseño; lo que falta es el motor.

**Del wargame:** ramas observables en cada move ✅ · forks explícitos (MOVES 1-7, aborts) ✅ · unknown-unknown capturado (automatización zombi del MOVE 6; reglas de depuración como juicio no codificado del MOVE 5) ✅ · ejecutable sin este chat ✅.

---

## 6. Handoff Spec

| Rol | Quién | Autonomía | Ratifica |
|---|---|---|---|
| Cerrar V1+V2+V3 (checklist + muestras) | Juan Carlos (humano) | L0 (NEXT propio) | — |
| Spec del pipeline (MOVE 2) | Opus 4.8 | L2 | Juan Carlos (funcional) + Victor (arquitectura, L3) |
| Construcción MOVES 3-6 (incluye MOVE 6, pipeline Stripe/GHL de Invites, separado de cuota) | Sonnet (Opus si el diff se complica) | L2 | Juan Carlos contra corte real |
| Prueba y doble corrida (MOVE 7) | Juan Carlos + Sonnet | L1 | Juan Carlos declara el apagado del manual |
| Parametrización IRONMAN + checklist (MOVE 8) | Sonnet | L2 | Juan Carlos |
| Motor en producción (cifras a Federación automatizadas) | — | — | **Victor (L3)** — decisión de compliance, per TP §9 |

**Condición de arranque:** ratificación de este WG- por el owner ("ratificado") + MOVE 1 cerrado (o su contramove vía el corte manual puente). El ejecutor NO improvisa columnas ni tags: todo lo no declarado vuelve al Ledger como NEXT.

---

## 7. CHANGELOG

| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-07 | Creación (draft + hardening, 2 pasadas). Insumos: TP-REB-MotorReportes, PP-InventarioProcesos, DC de cuota Federación, barrido Fable P3. Ledger resuelto en vivo: piloto L'Étape, plantillas estilo Cuota Federación; V1-V3 quedan abiertas con owner JC. Hallazgos de la simulación: (1) el círculo vicioso del MOVE 1 — JC no libera los datos porque el crunch no lo suelta — se rompe empaquetando la captura dentro del corte manual (sinergia con WG-REB-OpsEventos-CorteManual); (2) el riesgo dominante no es técnico sino la automatización zombi (doble trabajo permanente) — la doble corrida acotada a 3 es el candado; (3) las reglas de depuración son juicio humano no codificado — la cola de excepciones las mete al flujo sin pretender eliminarlas; (4) cifra a Federación = único abort reputacional real. |
| v01 | 2026-07-08 | Recalibración (§6.3 del playbook) tras la ejecución real de WG-REB-OpsEventos-CorteManual-v01: **V1, V2 resueltas** (nombres reales de activos, estructura real de ambos exports, hueco de identidad en equipos relay IRONMAN); **V3 parcial** (primera regla de tags real capturada). **Baseline de ROI:** 90 min para un corte manual completo de ambos eventos. **Hallazgo crítico:** MOVE 5 diseñado sobre una premisa incorrecta — el script Stripe no es el mecanismo de cuota Federación, son 2 sistemas separados. |
| v01 | 2026-07-08 | **Fix aplicado al mismo hallazgo crítico**, a pedido explícito del owner: **MOVE 5 reescrito** con la mecánica real de cuota Federación por evento (IRONMAN = registrados×$10.52 filtrando por Event Name, incluye hueco de equipos relay; L'Étape = Daily Pass=1×$10 del export específico, con "0"=blanco, más el hueco declarado del pago en persona en retiro de kit). **MOVE 6 nuevo**: pipeline de planes de pago Stripe/GHL → disparo de "Invite", separado y sin tocar la cuota Federación. Renumerado: doble corrida MOVE 6→7, parametrización IRONMAN MOVE 7→8. Handoff Spec y condiciones de aborto actualizados con la nueva numeración. Sigue **Draft — pendiente ratificación de Víctor** (el proyecto escala más allá del owner, per TP §9) antes de iniciar MOVE 2 (spec). |
| v01 | 2026-07-08 | **Segunda corrección, mismo día:** Víctor entregó el set completo de reportes IRONMAN (5 tipos de export). Se descubrió que el campo QTY de `export_orders` no equivale a personas en órdenes de equipo/relay — **V2 corregida** y **MOVE 5 vuelto a ajustar**: IRONMAN debe construirse sobre `export_tickets` (1 fila = 1 persona, con Ticket Status), nunca sobre QTY de `export_orders`. El hueco de identidad de equipos relay (declarado sin resolver en la corrección anterior) quedó cerrado: `export_tickets` trae nombre/email de cada integrante. Cifra de referencia corregida: IRONMAN 70.3 al 2026-07-08 = 180 personas reales (no 204), cuota $1,893.60. |
| v01 | 2026-07-08 | **Ratificado.** Víctor delegó la decisión en JC ("lo que yo decida está bien, así que vamos a ratificar el WG"). `status` actualizado a "Ratificado — listo para handoff, arranque bajo demanda". Condición de arranque del Handoff Spec (§6) queda satisfecha: MOVE 1 (V1+V2+V3) ya cerrado vía el corte manual puente + ratificación del owner. Puede arrancar MOVE 2 (spec del pipeline, Opus 4.8) bajo demanda. |