---
type: TP
asset_id: TP-REB-Corte703-Runbook-v01
version: v01
status: Activo
owner: Juan Carlos Ángeles Ramírez
sherpa_owner: SherpaX (cualquier room REB de Cowork)
ratificador: Juan Carlos Ángeles Ramírez
fecha_creacion: 2026-07-09
ubicacion_canonica: IB-REB-Rebelocity/PB-REB-Rebelocity (copia operativa del sistema en Drive compartido REB-SistemaRegistros-703)
proposito: Proceso cotidiano del corte de registros del IRONMAN 70.3 Encarnación 2026 — repetible en cualquier room nuevo, sin depender de ninguna conversación previa
canonicos_referenciados:
  - EXE-REB-PipelineCorte703-v01.py (el pipeline ejecutable, misma carpeta)
  - DC-REB-MaestroRegistros-2026-vNN.xlsx (el maestro vivo, misma carpeta — usar siempre la versión más alta)
  - DC-REB-Propuesta-SistemaRegistrosIRONMAN-v01 (diseño ratificado)
  - SPEC-REB-JuanCarlos-MotorReportes-v01 (arquitectura, cola de excepciones)
tags: [TP, rebelocity, 703, corte, runbook, pipeline]
---

# Runbook — Corte de registros 70.3 Encarnación 2026
## El proceso cotidiano en 5 pasos (~10 min)

> **Regla:** el mecanismo NO es "la conversación donde se construyó". Es este runbook + el script + el notebook + el maestro, cuya copia operativa vive en la carpeta compartida de Drive **`REB-SistemaRegistros-703`** (única fuente de verdad del equipo, probada en producción 2026-07-09). **No requiere Cowork:** el script corre en cualquier entorno con Python.

---

## Dónde correr el corte (3 vías equivalentes)

| Vía | Cuándo conviene | Nota |
|---|---|---|
| **Google Colab (estándar del equipo)** | Cualquier miembro, sin instalar nada — solo navegador | Abrir `EXE-REB-CorteColab-703-v01.ipynb` desde la carpeta compartida de Drive → Ejecutar todas. Localiza solo el export más nuevo y el maestro más reciente. |
| **PC con terminal** | Corte rutinario de JC | `python EXE-REB-PipelineCorte703-v01.py <export.csv> <maestro-vNN.xlsx> <AAAA-MM-DD>` · requiere Python + openpyxl · las fórmulas se recalculan solas al abrir el maestro en Excel/Sheets |
| **Claude Code** | Corte + aplicación del paquete GHL (`ghl-rebelocity`) en un solo lugar, sin handoff | pedirle que siga este runbook |
| **Room de Cowork** | Cortes con excepciones que discutir, reporte narrativo con proyección, actualización de dashboards/vault | `/wx-arrancaroom` + "corre el corte del 70.3 según este runbook" |

**Única fuente de verdad:** el trío `EXE-REB-PipelineCorte703-v01.py` + `EXE-REB-CorteColab-703-v01.ipynb` + `DC-REB-MaestroRegistros-2026-vNN.xlsx` vive en la carpeta compartida de Drive **`REB-SistemaRegistros-703`** (crear una sola vez; el equipo usa Drive web). El maestro NUNCA se copia a computadoras personales — cada corte genera el vNN+1 ahí mismo. Quien use la carpeta compartida por primera vez en Colab: clic derecho sobre la carpeta en Drive → "Organizar" → "Añadir acceso directo" a Mi unidad.

## Proceso por corte

| Paso | Quién | Qué |
|---|---|---|
| 1 | Víctor o JC | Descargar **`export_tickets`** de la plataforma IRONMAN (solo ese archivo) y guardarlo en una carpeta accesible al room |
| 2 | JC | Abrir un room de Cowork → `/wx-arrancaroom` → decir: **"Corre el corte del 70.3 según TP-REB-Corte703-Runbook"** (adjuntando o señalando el export) |
| 3 | SherpaX | Ejecuta `EXE-REB-PipelineCorte703-v01.py <export.csv> <maestro más reciente> <fecha de descarga>` → genera maestro vNN+1 + paquete GHL, corre recalc del skill xlsx, reporta altas/bajas y excepciones nuevas |
| 4 | JC | Revisa el resumen: valida altas/bajas, resuelve lo que caiga en `Excepciones` (el pipeline nunca decide solo sobre identidad) |
| 5 | JC | Aplica el paquete GHL (`EXE-REB-PaqueteGHL-703-Corte*.csv`) en **Claude Code** (`ghl-rebelocity`) — Cowork no tiene salida de red a GHL (V5, SPEC §8) |

**Cadencia sugerida:** semanal hasta agosto · 2-3×/semana en septiembre · diaria la última semana. Si un corte se salta, no pasa nada: cada export trae el historial completo de compras (`Purchase Date`) y el sistema se auto-repara.

## Reglas fijas del pipeline

1. `Refunded` **nunca** cuenta como participante: va a la pestaña `Bajas` (auditoría) y a ninguna estadística.
2. Diff nominal por `email + orden`; toda ambigüedad de identidad → pestaña `Excepciones`, juicio de JC.
3. El maestro versiona (v03 → v04 → …): nunca se sobreescribe un corte anterior; la pestaña `Cortes` es el historial auditable.
4. Las pestañas `Excepciones`, `PlanesPago`, `Parametros`, `RefHistorica` y `Cortes` **se arrastran** entre versiones (ahí viven los juicios de JC) — las demás se regeneran desde el export.
5. Ninguna cifra oficial sale con delta inexplicado (regla de oro heredada del wargame).

## Qué mirar después de cada corte

- `DashboardData`: las 12 métricas + AG + países + tallas (fórmulas vivas).
- `CurvaRegistro`: % de avance vs. proyección central (525).
- Salida del script: altas y bajas del corte, listas para comunicar al equipo.

## Pendientes que completan el sistema (estado al 2026-07-09)

| Pendiente | Desbloquea |
|---|---|
| ~~Tags GHL del 70.3 (V3)~~ ✅ Confirmados 2026-07-09: `participante-ironman` + `70.3-2026-participante` | Paquete GHL ya sale con tags reales |
| Export final 70.3-2025 (Víctor) | Proyección con confianza ALTA |
| Export suscripciones GHL/Stripe | Pestaña `PlanesPago` + métricas 13-15 (Fase 3) |
| ~~Dashboard BRD HTML (Fase 2)~~ ✅ **Hecho 2026-07-10:** `BRD-REB-IRONMAN703-Dashboard-v01.html` (ver "Regenerar el dashboard") | Vista visual para el equipo sin abrir Excel |

## Regenerar el dashboard BRD HTML (paso 6 — Fase 2)

El tablero `BRD-REB-IRONMAN703-Dashboard-v01.html` (misma carpeta canónica) es una **foto del corte**: no se actualiza solo. Se regenera al cierre de cada corte, después del paso 5.

**Vía normal (Cowork/SherpaX):** en el mismo room del corte, pedir **"regenera el dashboard del 70.3 con este corte"**. SherpaX recalcula las 15 métricas + curva + proyección desde el `export_tickets` fresco (excluyendo Refunded, aplicando la dedup de Cano y las excepciones ya persistidas) y reescribe el HTML.

**Verificación obligatoria antes de dar por bueno:** recomputo independiente de las cifras del tablero contra el export (registrados, F/M, individuales/relevos, y que las sumas de edad/países/tallas cuadren al total de registrados). No se publica un tablero con una cifra que no cuadre (regla de oro heredada del wargame).

**Mecánica interna del archivo (si se toca a mano):** las cifras viven en DOS lugares que hay que actualizar juntos —
1. El objeto `const D = {…}` dentro del `<script>` (registrados, `ag`, `paises`, `tallas`, `curva`): de ahí se dibujan tablas, barras y la gráfica Chart.js.
2. Las tarjetas KPI del encabezado (`<div class="kpis">`) y la meta del corte (`Corte … · D-XX`): hoy están **escritas a mano** y desacopladas de `D`.

⚠️ Si solo se cambia `D`, los KPIs de arriba quedan viejos. **Mejora recomendada para v02 del tablero:** renderizar los KPIs desde `D` para eliminar el doble mantenimiento.

**Qué se refresca cada corte:** registrados + delta vs. corte anterior (pestaña `Cortes`), género/edad/países/tallas, curva acumulada (se reconstruye completa desde `Purchase Date`), D-XX y la proyección (sube a confianza ALTA al llegar el export del 70.3-2025). Naming y ubicación se conservan; si el corte es un hito, subir a `v02` y archivar el anterior. Ratificador del BRD: pendiente (Víctor/Ángeles).

## Evento nuevo (futuro)

Llenar la fila "(evento futuro)" en `Parametros` + duplicar el script cambiando las 3 constantes del encabezado (`EVENTO`, `EV_FECHA`, `PROY_CENTRAL`) → per checklist SPEC §10, primera corrida en modo solo-lectura.

---

## CHANGELOG

| Versión | Fecha | Cambio |
|---|---|---|
| v01.1 | 2026-07-10 | Addendum: nueva sección "Regenerar el dashboard BRD HTML (paso 6 — Fase 2)" con vía Cowork, verificación obligatoria y mecánica interna del archivo. Marcado el dashboard Fase 2 como entregado en la tabla de pendientes. |
| v01 | 2026-07-09 | Creación. Proceso cotidiano de 5 pasos instalado como artefactos persistentes (runbook + EXE sc