---
type: DC
asset_id: DC-REB-Propuesta-SistemaRegistrosIRONMAN-v01
version: v01
status: ✅ Ratificada — Victor Heredia (arquitectura, L3) y Juan Carlos (funcional), 2026-07-09
owner: Juan Carlos Ángeles Ramírez
sherpa_owner: SherpaX (Cowork, room REB)
ratificador: Juan Carlos Ángeles Ramírez (funcional) + Victor Heredia (arquitectura, L3)
fecha_creacion: 2026-07-09
ubicacion_definitiva: IB-REB-Rebelocity/PB-REB-Rebelocity (trasladada 2026-07-09; copia de trabajo en ActividadesDiarias)
canonicos_referenciados:
  - SPEC-REB-JuanCarlos-MotorReportes-v01 (arquitectura base de los 2 pipelines — esta propuesta la EXTIENDE, no la reemplaza)
  - WG-REB-MotorReportes-ConstruccionPipeline-v01 (MOVE 6 = planes de pago, aquí se propone su diseño)
  - DC-REB-AnalisisCruzadoParticipantes-2025-2026-v01 (histórico 2025/2026)
  - DC-REB-IMTickets-Corte20260608-v01.csv (fuente canónica inspeccionada, 682 tickets reales)
tags: [DC, rebelocity, ironman, 5150, 703, registros, dashboard, proyeccion, ghl, stripe, tshirts]
---

# Propuesta — Sistema Central de Registros IRONMAN Rebelocity
## Centralizar, actualizar, analizar y visualizar registros de 5150 y 70.3 Encarnación

> **Punto de partida (Gate G0):** esta propuesta NO arranca de cero. Se apoya en `SPEC-REB-JuanCarlos-MotorReportes-v01` (ratificación en curso), que ya resolvió arquitectura de pipelines, tabla de parámetros por evento, cola de excepciones, dónde corre el sistema (V5: Cowork + escritura GHL vía Claude Code) y método base de proyección (V6). Lo que esta propuesta agrega: la **capa de analítica de participantes** (género, edades, países, tallas, relevos), el **diseño del pipeline de planes de pago** (MOVE 6 del wargame, aún no diseñado), y el **método de proyección mejorado** con un hallazgo nuevo de los datos reales.
>
> **Todo lo afirmado abajo fue verificado contra archivos reales** — los 3 CSVs de IRONMAN del vault (cortes 16-may y 08-jun) fueron inspeccionados columna por columna. Nada está inventado; lo que falta está marcado como ⚠️ FALTANTE.

---

## 1. Diagnóstico del proceso actual

| Síntoma | Causa raíz |
|---|---|
| Lento y manual | Cada corte se procesa a mano: descargar CSV → editar Sheets → editar GHL, sin diff automatizado |
| Información desactualizada | La actualización depende de una persona (JC) y de descargas bajo demanda sin cadencia |
| Riesgo de duplicidad | Cruces por email hechos a mano; caso conocido de identidad compartida (1 email, 2 personas) |
| Tres silos desconectados | (a) CSVs IRONMAN, (b) planes de pago GHL/Stripe, (c) Sheets de seguimiento — se reconcilian manualmente |
| Decisiones sin proyección | No hay curva de registro visible ni pronóstico sistemático de cierre |
| Dependencia de una persona | El equipo no puede autoconsultarse; pide los números a JC |

El problema **no** es la falta de datos — el `export_tickets` de IRONMAN trae prácticamente todo lo que el sistema necesita (ver §3). El problema es que no existe un paso automatizado entre el CSV y las vistas de decisión.

---

## 2. Archivos CSV: cuáles sirven y cuáles no

Verificado contra los exports reales del vault (`PB-REB-Rebelocity`):

| Export | Veredicto | Razón |
|---|---|---|
| **`export_tickets`** (ej. `DC-REB-IMTickets-Corte20260608-v01.csv`) | ✅ **FUENTE CANÓNICA — el único indispensable** | 1 fila = 1 persona-ticket. Trae identidad, género, fecha de nacimiento, país, talla de T-shirt, tipo de entrada (individual/relevo), pierna de relevo, estatus, waiver, contacto de emergencia, cuota federación, fecha de compra. Un solo archivo trae AMBOS eventos del año (filtrar por `Event`). |
| `export_orders` (ej. `DC-REB-IM703-Encarnacion-Corte*.csv`) | 🟡 Solo para conciliación financiera | Trae `Revenue`, `Total Amount Paid`, `Promo Code` por orden. **NUNCA usar `QTY` para contar personas** (regla ya confirmada en la SPEC con casos reales de relevos). |
| `export_attendees`, `export_purchasers`, `export_shipping` | ❌ No necesarios | Subconjuntos redundantes de `export_tickets`. |
| `fullReport-*`, `participantExport-*` | ❌ No usar | Cifras no explicadas vs. fuente canónica (excepción ya documentada en SPEC §6 — no se usan sin confirmar con Víctor). |

**Regla operativa:** cada corte = descargar **solo `export_tickets`** (y `export_orders` únicamente si toca conciliación de ingresos). Menos carga para las 2 personas con acceso a la plataforma.

⚠️ **FALTANTE:** los planes de pago en cuotas NO aparecen en ningún CSV de IRONMAN. Se resuelven con datos de GHL/Stripe (ver §11).

---

## 3. Columnas clave por archivo

**De `export_tickets`** (65 columnas — estas 20 alimentan el sistema):

| Grupo | Columnas | Alimenta |
|---|---|---|
| Identidad | `Attendee First Name`, `Attendee Last Name`, `Attendee Email`, `Attendee Phone` | Registro, diff, GHL |
| Demografía | `Attendee Gender`, `Attendee Date of Birth` | Género, categorías de edad |
| Geografía | `Shipping Country`, `Shipping City`, `Country Represented 2.0` | Países |
| Evento | `Event`, `Event Start`, `Purchase Date` | Discriminador de evento, curva de registro |
| Modalidad | `Ticket Type`, `Select your leg(s) of the relay`, `Order Number` | Individual vs. relevos, armado de equipos |
| Estatus | `Ticket Status`, `Transfer Status`, `Withdrawn Status`, `Waiver` | Completo/incompleto/revisión |
| Logística | `Included Technical T-Shirt (Please Select Size)` | T-shirts por talla |
| Finanzas | `Ticket Total`, `Amount Paid`, `Amount Refunded`, `PY1: Paraguay Triathlon Federation` | Cuota federación (Pipeline 2 ya especificado) |

**De `export_orders`** (solo conciliación): `Order Number`, `Order Status`, `Revenue`, `Total Amount Paid`, `Promo Code`, `Event Name`.

**Calidad real de los datos** (corte 08-jun, 682 tickets): fecha de nacimiento 100% poblada (0 vacíos), género 99.9% (1 vacío), talla 99.7% (2 vacíos), 1 email de atleta vacío, 42 emails repetidos (mayoría legítimos: compras múltiples/relevos — van a diff por email+evento, ambigüedades a cola de excepciones).

---

## 4. Diseño recomendado del sistema

Extensión directa de la arquitectura ya especificada — un pipeline, cuatro salidas:

```
TABLA DE PARÁMETROS POR EVENTO (SPEC §3 — sin cambios)
        │
        ▼
export_tickets (descarga bajo demanda, 2 personas autorizadas)
        │
        ▼
PIPELINE 1 · Seguimiento de Registro (Cowork)
  ingesta → normalización → diff vs. corte anterior → cola de excepciones
        │
        ├─► A. GOOGLE SHEET MAESTRO (§7) — consulta autónoma del equipo
        ├─► B. DASHBOARD BRD HTML por evento (§8) — mismo estilo de los boards REB
        ├─► C. Paquete de upsert GHL → JC lo aplica en Claude Code (§10)
        └─► D. Trigger Pipeline 2 · Cuota Federación (ya especificado, sin cambios)

PIPELINE 3 · Planes de Pago (NUEVO — MOVE 6, §11)
  GHL/Stripe suscripciones → estado por atleta → cruce vs. export_tickets
  (regla de oro: NUNCA comparte código con Cuota Federación)
```

Principios heredados de la SPEC: evento como parámetro (dar de alta el 70.3 = llenar una fila, no escribir código) · el pipeline nunca decide solo sobre identidad · ninguna cifra oficial sale con delta inexplicado.

---

## 5. Flujo semiautomático propuesto

Diseñado para operar con descargas **bajo demanda** — no requiere horarios fijos:

1. Víctor o JC descargan `export_tickets` de la plataforma IRONMAN (2-3 min).
2. JC lo sube al room y pide: **"corre el pipeline de [evento]"**.
3. El pipeline (Cowork, ~minutos): valida estructura → diff → actualiza Sheet maestro → regenera dashboard → arma paquete GHL → lista excepciones para juicio de JC.
4. JC resuelve excepciones (si hay) y aplica el paquete GHL en Claude Code (`ghl-rebelocity`).
5. El equipo consulta el Sheet/dashboard **sin pedirle nada a nadie**.

Trabajo humano por corte: ~10-15 min (hoy: horas). La frontera humana declarada (solicitud manual del export a Víctor) se mantiene — es restricción de la plataforma, no del sistema.

**Clave anti-fragilidad:** cada `export_tickets` trae `Purchase Date` de TODAS las órdenes históricas → si un corte se salta o se pierde, el siguiente reconstruye la curva completa solo. El sistema nunca queda "roto" por falta de cadencia.

---

## 6. Herramientas: evaluación y recomendación

| Opción | Veredicto | Razón |
|---|---|---|
| **Python en Cowork (pipeline)** | ✅ Núcleo | Ya validado (V5 resuelta, probado 2026-07-09). Cero costo nuevo. |
| **Google Sheets (base de datos)** | ✅ Capa de consulta | El equipo ya vive ahí; suficiente para <2,000 registros/año. |
| **Dashboard BRD HTML** | ✅ Capa visual | Formato ya validado en los boards REB (`BRD-REB-CuotaFederacion-*`); se regenera en cada corte. |
| **GHL vía Claude Code** | ✅ Escritura CRM | Único camino con salida de red confirmada (SPEC §8). |
| Looker Studio | 🟡 Fase 4 opcional | Gratis y lee Sheets directo; útil si el equipo quiere filtros interactivos. No bloquea nada. |
| n8n / Make | ❌ Por ahora no | Automatizan triggers — pero el trigger aquí es una descarga manual humana. Sin API de IRONMAN no hay qué automatizar. Reevaluar si IRONMAN ofrece API/reportes por correo. |
| Airtable | ❌ No | Costo nuevo + migración + curva de aprendizaje, sin capacidad que Sheets no dé a esta escala. |
| Base de datos externa | ❌ No | Sobredimensionado para ~700 registros por evento y equipo pequeño. |

---

## 7. Estructura del Google Sheet maestro

Un solo archivo: **`REB-MaestroRegistros-2026`**, pestañas:

| Pestaña | Contenido | Se actualiza |
|---|---|---|
| `Parametros` | Tabla de parámetros por evento (espejo de SPEC §3): nombre, fecha, regla de cuota, tarifa, tags GHL | Al dar de alta un evento |
| `Registrados` | 1 fila = 1 persona-ticket, todos los eventos, columna `Event` como discriminador + columnas calculadas: edad, categoría AG, modalidad, semáforo de completitud, origen (directo/plan de pagos) | Cada corte (upsert por diff) |
| `Equipos` | 1 fila = 1 equipo de relevos: orden, capitán, integrantes, piernas cubiertas, piernas faltantes | Cada corte |
| `PlanesPago` | 1 fila = 1 suscripción GHL/Stripe: atleta, plan (10/6/4), cuotas pagadas/restantes, estado, ¿ya registrado en IRONMAN? | Corte de planes (§11) |
| `Excepciones` | Cola de excepciones (SPEC §6): pendientes de juicio de JC | Cada corte |
| `Cortes` | 1 fila = 1 corte: fecha, totales por evento, delta vs. anterior | Cada corte (histórico auditable) |
| `DashboardData` | Agregados que alimentan el BRD: por género, categoría, país, talla, modalidad | Cada corte (fórmulas/pipeline) |

Compartido en lectura con todo el equipo Rebelocity; escritura solo vía pipeline + JC.

---

## 8. Métricas del dashboard (las 15 pedidas, todas verificadas como calculables)

Cifras reales del corte 08-jun-2026 como demostración:

| # | Métrica | Fuente | Ejemplo real (corte 08-jun) |
|---|---|---|---|
| 1 | Registrados a la fecha | `Ticket Status` ≠ Refunded, por `Event` | 70.3: **180** activos · 5150 (cerrado): 483 |
| 2-3 | Mujeres / Hombres | `Attendee Gender` | Global ambos eventos: 142 F / 539 M |
| 4 | Por categoría de edad y género | `Attendee Date of Birth` + `Attendee Gender` (§12) | tabla AG completa por evento |
| 5-6 | Países y registrados por país | `Shipping Country` | 15+ países; PY 357, AR 179, BR 85, UY 14… |
| 7 | T-shirts por talla | Columna de talla (§13) | M-Medium 239, M-Large 181, W-Small 54… |
| 8-9 | Individual vs. Relevos | `Ticket Type` | Individual 540 + 95 comp. · Relevos 47 |
| 10-11 | Equipos y sus integrantes | Agrupación por `Order Number` + invites | 23 órdenes de relevo (ver ⚠️ §16-nota) |
| 12 | Completos / incompletos / revisión | Semáforo: Status + Waiver + email/talla/género vacíos | 2 sin talla, 1 sin email, 1 sin género → revisión |
| 13-15 | Atletas de planes de pago: en curso / completados / pendientes | Pipeline 3 (§11) | ⚠️ requiere datos GHL/Stripe — no está en CSV |

Más: curva de registro acumulada + proyección a cierre (§14), delta vs. corte anterior, y comparativa vs. eventos 2025 (existe histórico: `DC-REB-AnalisisCruzadoParticipantes-2025-2026-v01`).

---

## 9. Cómo se actualiza la información

- **Disparador:** bajo demanda — subir el export y pedir el corte. Sin dependencia de horarios.
- **Cadencia sugerida** (no obligatoria): semanal en temporada baja; 2-3×/semana en las 6 semanas previas al evento; diaria la última semana.
- **Auto-reparación:** cualquier export reconstruye la historia completa vía `Purchase Date` (§5).
- **El equipo consulta** Sheet y dashboard en cualquier momento — la "actualidad" del dato es visible (cada vista muestra fecha del último corte).

## 10. Sincronización con GoHighLevel

Sin cambios vs. lo ya resuelto en SPEC §8 (V5, probado en vivo): el conector GHL de Cowork está bloqueado por red → **el pipeline arma el paquete de upsert** (CSV de altas + tags según patrón `<evento>-part-<sede><año>` de la tabla de parámetros) y **JC lo aplica en Claude Code** (`ghl-rebelocity`). Mismo patrón manual de hoy, pero con el paquete pre-armado. Deduplicación: upsert por email — GHL no duplica contactos.

🟡 Pendiente heredado (V3): reglas de tags reales para 5150/70.3 aún no capturadas — se confirman con Víctor/JC en el primer corte real.

## 11. Integración de Stripe / planes de pago (Pipeline 3 — diseño del MOVE 6)

Es un sistema **separado** de Cuota Federación (regla de oro del wargame: nunca comparten código).

1. **Fuente:** export/lista de suscripciones de GHL (integradas con Stripe) — atleta, email, plan (10/6/4 cuotas), pagos realizados. Se obtiene vía Claude Code (misma vía que el upsert) o export manual de GHL.
2. **Estados por atleta:** `EN CURSO` (cuotas restantes > 0) → `COMPLETADO` (pagó todo, pendiente de invite) → `INVITADO` (se le envió el enlace especial) → `REGISTRADO` (su email aparece en `export_tickets` del evento).
3. **Cruce automático:** email del plan vs. `Attendee Email` del export → detecta quién ya usó su invite. Los registros por invite entran típicamente como `Individual Entry-Complimentary` o `Relay-Team Member- Invite` (95 + 6 casos reales en el corte 08-jun) — el cruce por email es la verificación, no el tipo de ticket.
4. **Alertas que produce:** completados sin invitar (acción: enviar enlace + recordar cuota federación $10.52) · invitados sin registrar a N días · pagos vencidos.
5. ⚠️ **FALTANTE por confirmar:** formato exacto del export de suscripciones GHL — primer paso de la Fase 3.

## 12. Categorías por edad y género

Regla IRONMAN estándar: **edad al 31 de diciembre del año del evento** (edad de competencia). Cálculo: `año_evento − año_nacimiento` (con `Attendee Date of Birth`, 100% poblada). Bandas: 18-24, 25-29, 30-34, 35-39, 40-44, 45-49, 50-54, 55-59, 60-64, 65-69, 70-74, 75+ × género (ej. M35-39, F30-34). Los relevos se agrupan aparte (la categoría AG individual no aplica). Menores de 18 → cola de excepciones (verificar elegibilidad).

## 13. Necesidades de T-shirts por talla

Directo de la columna `Included Technical T-Shirt (Please Select Size)` (99.7% poblada), filtrando `Ticket Status` ≠ Refunded, por evento. El dashboard muestra: conteo actual por talla + **proyección de compra** = distribución % actual de tallas × proyección de registros a cierre (§14) + buffer de 8-10% (cambios de talla en sitio, staff, cortesías — % ajustable por JC con la experiencia del 5150). Salida: tabla lista para orden de compra.

## 14. Predicción de ventas / registros

**Hallazgo clave de los datos reales:** `Purchase Date` en `export_tickets` permite reconstruir la **curva completa de registro de cualquier evento con un solo export** — el 70.3 tiene compras desde nov-2025, y el **5150-2026 ya cerrado aporta la curva de referencia completa** (500 tickets desde apertura hasta el día del evento). No hay que "empezar a construir histórico": ya existe dentro de los propios archivos.

**Método (versión mejorada de V6, para ratificar):**

1. **Curva de referencia:** normalizar la curva del 5150-2026 (y de los eventos 2025 si se consiguen sus exports finales) como "% del total registrado a D-x días del evento".
2. **Proyección principal:** al día del corte (ej. hoy D-94 para el 70.3 del 11-oct), leer qué % del total suele estar registrado a D-94 en la curva de referencia → `proyección = registrados_actuales ÷ %_referencia`.
3. **Proyección secundaria (sanity check):** tendencia de las últimas 4 semanas extrapolada linealmente (método V6 original).
4. **Presentación honesta:** rango entre ambos métodos + confianza declarada (alta/media/baja). Nunca un número decorativo (regla heredada del TP).
5. **Ajuste conocido:** el patrón típico es fuerte aceleración final ("last-minute surge") + escalones al cambiar de precio por fases — la curva de referencia los captura automáticamente; los cambios de precio del 70.3 se anotan en `Parametros` para interpretar los escalones.
6. **Caveat declarado:** 5150 (olímpico, mayo) y 70.3 (media distancia, octubre) tienen perfiles de atleta distintos — la referencia cruzada es aproximación hasta acumular la curva 70.3-2025 (⚠️ pedir a Víctor el export final del 70.3-2025 si existe — mejoraría la proyección de inmediato).

## 15. Recomendación final

**Sistema:** pipeline Python en Cowork + Google Sheet maestro + dashboards BRD HTML + escritura GHL vía Claude Code + Pipeline 3 para planes de pago. **Por qué:** cero suscripciones nuevas, usa lo ya validado (SPEC ratificándose, boards existentes, patrón GHL probado), opera bajo demanda, el equipo se autoconsulta, y dar de alta el siguiente evento (70.3-2027, nuevas sedes) es llenar una fila de parámetros. Escala hasta ~2,000 registros/año por evento sin cambiar de arquitectura; si Rebelocity crece más allá, la migración natural es Sheets → base de datos, sin rehacer el pipeline.

## 16. Plan de implementación por fases

| Fase | Entregable | Esfuerzo | Prerrequisito |
|---|---|---|---|
| **F1 (sem 1)** | Pipeline base 70.3: ingesta + diff + Sheet maestro + pestaña Cortes. Primera corrida en modo solo-lectura (SPEC §10.4) validada contra el proceso manual | 2-3 sesiones | **Export `export_tickets` fresco** (el más reciente en vault es del 08-jun) |
| **F2 (sem 2)** | Dashboard BRD por evento (15 métricas + curva + proyección) + paquete upsert GHL + confirmar reglas de tags (V3) | 2 sesiones | F1 + reglas de tags confirmadas |
| **F3 (sem 3)** | Pipeline 3 planes de pago: formato export GHL/Stripe confirmado + cruce + alertas | 2 sesiones | Acceso al export de suscripciones |
| **F4 (opcional)** | Looker Studio sobre el Sheet + curva de referencia 70.3-2025 + generalización a L'Étape y eventos 2027 | 1-2 sesiones | F1-F3 estables |

⚠️ **Nota relevos (métrica 10-11):** los equipos se arman por `Order Number`, pero los miembros que entran por invite generan órdenes separadas (8 de 23 órdenes de relevo del corte 08-jun tienen 1 solo ticket). El pipeline arma lo que puede y manda los equipos incompletos a la cola de excepciones para que JC los asocie una sola vez — la asociación queda persistida en la pestaña `Equipos`.

### Datos faltantes (resumen honesto)

1. Export de suscripciones GHL/Stripe (formato por confirmar) — bloquea métricas 13-15.
2. Export final del 70.3-2025 y 5150-2025 (si existen) — mejorarían la proyección.
3. Reglas de tags GHL reales para 5150/70.3 (V3 abierta).
4. Export fresco de `export_tickets` para la primera corrida (el del vault es del 08-jun).
5. Vínculo invite→plan de pagos: se infiere por cruce de email; si un atleta usa otro email al registrarse, cae a cola de excepciones.

---

## CHANGELOG

| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-09 | Creación. Propuesta integral del sistema de registros IRONMAN (16 entregables solicitados por el owner), construida sobre SPEC-REB-JuanCarlos-MotorReportes-v01 y verificada contra los 3 CSVs reales del vault (cortes 16-may y 08-jun, 682 tickets). Incluye diseño del Pipeline 3 (planes de pago, MOVE 6) y método de proyección mejorado con curva de referencia reconstruible desde Purchase Date. |