---
asset_id: MIN-EL-JuanCarlos-20260710-v01
tipo: MIN — Minuta del día
owner: Juan Carlos Angeles Ramírez
sherpa: JuanCarlosX
ratificador: pendiente
fecha: 2026-07-10
intellbank: IB-EL-EmpowerLabs
subbank: EQ-EL-Equipo
---

# Minuta del día — Juan Carlos · 2026-07-10

> 🔄 Minuta viva — se irá iterando durante el día.

## Qué se hizo

1. **Arranque del room** (`/wx-arrancaroom`): contexto WORX cargado, reglas activas (naming canónico, tripleta Owner+Sherpa+Ratificador, Gate G0, Vault-First).

2. **Reconocimiento de perfil.** Cargado `DC-EL-PerfilOperador-JuanCarlos-v01` (Implementation Partner · Pilar Comercial). Revisadas las minutas recientes (7, 8 y 9-jul) — foco de la semana: Sistema de Registros IRONMAN 70.3 (Rebelocity), cerrado en producción el 9-jul.

3. **Ejecución del `TP-EL-Governance-TeamCleanup-v01`** (limpieza de skills/plugins del equipo, ~15 min):
   - **FASE 1 (Diagnóstico) corrió limpia** vía `sk-ibhealth`. Los 5 chequeos:
     1. Rutas muertas (Reinventaverse): ✅ — único 🔴 fue `sk-ibhealth` detectándose a sí misma (contiene la palabra porque *es* el auditor). Falso positivo verificado línea por línea.
     2. Duplicados: ✅ sin duplicados.
     3. Nombres viejos de UltraSherpas: ✅ solo nombres nuevos.
     4. Copias rogue en `Vault_skills/`: omitido (no montado en la sesión).
     5. Carpetas indebidas en la raíz: ✅ raíz limpia.
   - **FASE 2 (Corrección): nada que hacer.** Verificadas explícitamente las 9 skills de gobernanza vieja y los 4 UltraSherpas viejos → **ninguno presente**. Equipo ya sano.
   - **Estado de plugins confirmado en versión correcta:** worx-core v0.2.1 · worx-empowerlabs v0.5.0 · worx-wikix v0.3.0 · worx-ultrasherpas v0.4.0 · worx-governance v0.2.0. (Además: ai-specialists v2.1.4, gohighlevel v0.1.0, cowork-plugin-management v0.2.2 — legítimos, fuera de alcance.)

4. **Verificación de raíz del vault (confirmación de equipo — carpetas intrusas).** Contexto: la carpeta `Intellibanks` se sincroniza entre las máquinas del equipo vía app interna tipo Dropbox; una app de algún miembro genera/actualiza carpetas intrusas automáticamente. JC tiene la sincronización pausada hasta que todo el equipo corra el TP y confirme raíz limpia.
   - **Raíz confirmada LIMPIA.** 9 carpetas de primer nivel, todas legítimas (`IB-*`): IB-BVH-Publications, IB-Clientes, IB-EL-EmpowerLabs, IB-MONEX, IB-MPX-MasterPlaybooks, IB-REB-Rebelocity, IB-Test-Vault, IB-WikiX, IB-XX-Maestro.
   - **Cero carpetas intrusas.** Revisadas explícitamente las sospechosas conocidas (`Reinventaverse`, `LLM-Wiki`, `Projects`, `00-Inbox`, `Companies`, `CloudVault`, `Vault_skills`, `.obsidian`) → ninguna presente.
   - Archivos sueltos en raíz: solo metadatos legítimos del sincronizador (`.intellibanks_sync_*.json`, `.user_session.json`).
   - **JC listo para reportar su parte.** Riesgo residual conocido: al reactivar sync antes de que el resto limpie, las carpetas intrusas pueden re-entrar por sincronización — mantener sync apagada hasta confirmación de todo el equipo (estrategia correcta).
   - **Reportado al equipo (Jay/Victor) por JC. Cleanup de JC cerrado.**

5. **Resolución de las 3 excepciones del maestro IRONMAN 70.3** (Gate G0: verificadas contra `export_tickets` = `DC-REB-IMTickets-Corte20260608-v01.csv`, 682 tickets):
   - **Excepción 1 — Caso Cano Carpi = duplicado confirmado (no 2 personas).** Los 2 tickets (orders 43512 y 44003) son la MISMA persona: Agustín Cano Carpi, mismo evento (70.3 Encarnación), mismo attendee email (`agu_c_c@hotmail.com`), ambos Individual Entry-Complimentary $0. Se revierte la hipótesis del 8-jul (no eran 2 reales compartiendo email). **Decisión del owner:** conservar la más reciente (order **44003**, 2026-01-05); marcar la **43512** (2025-11-19) como duplicada y excluirla del conteo. **Efecto: registrados 70.3 baja en 1** (de 180 a 179 en el conteo de individuales, sujeto a reflejarse en el maestro v03).
   - **Excepción 2 — Relevos order 45359 = 3 personas, pierna Run sin asignar.** Equipo válido (Jhonnathan Ferrazza=Captain/Swim + Alan Cassano Bento y Lua Rezende Nogueira, ambos Member marcando ",Bike,"). Nadie marca "Run". **El conteo NO cambia** (3 personas = 1 relevo). Nota operativa: confirmar con el capitán quién corre la pierna de Run — no afecta estadísticas.
   - **Excepción 3 — 2 cortes mal etiquetados: renombrados en el vault (verificado por Order Date real).** `DC-REB-IM703-Encarnacion-Corte20260516` (Order Date máx real 2026-06-16) → **`Corte20260616`**; `DC-REB-IM703-Encarnacion-Corte20260608` (Order Date máx real 2026-07-04) → **`Corte20260708`**. Contenido intacto (md5 sin cambios). **Decisión del owner:** renombrar solo los 2 de Encarnación.
     - *Residual anotado:* `DC-REB-IMTickets-Corte20260608-v01.csv` (export_tickets) también tiene Purchase Date máx 2026-07-04 (es en realidad el corte de julio), pero por decisión del owner se deja con su nombre actual por ahora.

6. **Dashboard BRD HTML del 70.3 construido (F2 de SherpaX)** — `BRD-REB-IRONMAN703-Dashboard-v01.html` en `IB-REB-Rebelocity/PB-REB-Rebelocity`. Autocontenido, estilo BRD EmpowerLabs (tema claro/oscuro), Chart.js para la curva. Contiene las 15 métricas pedidas (13-15 marcadas pendientes de export GHL/Stripe), curva de registro acumulada (34 semanas) y proyección honesta. Cifras desde `export_tickets` canónico, dedup Cano aplicada, Refunded excluidos.
   - **Cifras clave (corte 08-jul, D-95):** 179 registrados activos (+19 vs. 160 del corte 08-jun) · 12.3% mujeres (22F/157M) vs. 24% del 5150 (palanca marketing) · 79% extranjeros (AR 57, BR 53, PY 38) · 170 individuales + 3 equipos de relevos · categoría mayor 40-44 (37) · 0 en revisión (datos 100% limpios) · proyección 475–550 confianza media.
   - **Verificación:** 9/9 chequeos cruzados OK (recomputo independiente vs. dashboard); sumas de edad/países/tallas cuadran a 179; HTML balanceado y validado.

7. **Proyección del dashboard actualizada a base same-event (70.3-2025).** Con dos archivos de referencia del 70.3-2025 aportados por JC:
   - Primer archivo (`participantExportFULL-9-24-2025.csv`) resultó **contaminado** (mezclaba 5150 + IronKids); su proyección (~250-315) se descartó — el 5150 se registra antes e inflaba el conteo temprano de 2025.
   - Segundo archivo (**solo 70.3**, corte 15-sep) es el bueno: 438 registros (398 ironman.com + 40 planes de pago), cuadra con el ancla del vault (final oficial 462). Se detectó y **corrigió** la columna de fecha (3 formatos mezclados + 29 filas con día/mes transpuesto por auto-conversión de Excel; todas validaron en rango tras invertir).
   - **Resultado same-event:** a D-95 el 2025 tenía el 33% de su final (143 registrados) → proyección 2026 ≈ **548-578**; el 2026 va **125% del ritmo** 2025 (ligeramente adelante). Valida y afina el 475-550 original.
   - Guardado el archivo de referencia en el vault: `DC-REB-IM703-Encarnacion-2025-RegistradosCorte20250915-v01.xlsx`; reemplazada la referencia inservible del 5150.
   - **CORRECCIÓN (mismo día, tras cuestionamiento del owner):** la proyección inicial de 525-600 (media-alta) estaba **inflada**. JC señaló que en 2025 corrieron <400 atletas. Al revisar, se detectó que las dos ediciones abrieron inscripción con **86 días de diferencia** (ventana 2025 = 263 d · 2026 = 349 d), por lo que alinear solo por "días-al-evento" sobreestima. Probando 3 alineaciones la proyección va de **~180 a ~550** — dispersión que muestra que a D-95 no hay proyección firme.
   - **Dashboard corregido a: proyección ≈400-500 inscritos, confianza media**, con nota de incertidumbre (spread 180-550, se afina hacia ~D-45) y distinción explícita **inscritos ≠ atletas en carrera** (2025: ~462 inscritos → <400 corrieron). Insight de "Lectura del corte" matizado (la ventaja 2026 vs 2025 es parcialmente por apertura temprana). **Cambio material — sujeto a ratificación de Víctor.**
   - *Aprendizaje (candidato a LabPraxis):* proyectar con una sola edición de referencia y ventanas de inscripción distintas produce rangos no confiables; declarar siempre el método de alineación y separar inscritos de participantes reales.

9. **Consolidación de listas San Bernardino → registros únicos.** Unión de 2 Excel (L'Étape San Bernardino 61 filas + Registrados+Bundle 70 filas) deduplicando por email → `DC-REB-LEtape-SanBernardino-RegistrosUnicos-Corte20260715-v01.xlsx` (en `IB-REB-Rebelocity/PB-REB-Rebelocity`). **76 registros únicos** (53 en ambos archivos · 16 solo Registrados+Bundle · 7 solo L'Étape). Columnas: nombre, apellido, email, competencia, monto, Origen, Nota.
   - Casos de identidad resueltos con el owner (regla Cano — no colapsar emails compartidos sin verificar): (a) `jordiella_dadalt@hotmail.com` — **Jordiella Dadalt cedió su cupo a Manuela Dadalt Peña** → se eliminó a Jordiella, queda Manuela; (b) `rp.hugo@hotmail.com` — **Hugo Fernandes y Fabio Pinheiro dos Santos = 2 registros individuales válidos** (email compartido confirmado, ambos quedan). También se corrigió un typo (Jordiella "Dodalt"/"Dadalt") para no duplicarla.
   - *Nota técnica:* el HTML se reescribió completo tras un lag de sincronización del entorno; versión autoritativa verificada íntegra (154 líneas, cierra correctamente).
   - **Sección "Lectura del corte" agregada al dashboard:** callout destacado arriba del tablero con el insight titular (2026 ~25% adelante de 2025 a D-95) + lecturas accionables (palanca comercial de empuje, participación femenina baja 12.3% vs. 24%, 79% extranjeros). Componente reutilizable — cada corte puede refrescar estas lecturas.

8. **Procedimiento de regeneración del dashboard documentado.** Anexado al `TP-REB-Corte703-Runbook-v01` (v01.1, 2026-07-10): nueva sección "Regenerar el dashboard BRD HTML (paso 6 — Fase 2)" con la vía Cowork, la verificación obligatoria de cifras y la mecánica interna del archivo (objeto `const D` vs. KPIs escritos a mano — desacople marcado como mejora para v02). Dashboard Fase 2 marcado como entregado en la tabla de pendientes del runbook.

## Decisiones

1. El 🔴 de "ruta muerta" sobre `sk-ibhealth` se clasifica como falso positivo (auto-detección del auditor), no requiere acción.
2. Cleanup cerrado sin desinstalaciones: el equipo de JC ya estaba en los 5 plugins sanos.
3. La verificación de `Vault_skills/` (Fase 2c) **no se considera pendiente** — cerrada por decisión del owner.

## NEXTs

*(Cleanup de skills cerrado — sin pendientes derivados.)*

Arrastres abiertos del Sistema de Registros IRONMAN 70.3 (de la minuta del 9-jul):

1. ~~**JC:** resolver las 3 excepciones del maestro~~ ✅ **Hecho (2026-07-10):** (a) Cano = duplicado, conservada order 44003, excluida 43512 → registrados −1; (b) relevos 45359 = 3 personas, conteo sin cambio, pendiente confirmar pierna Run con el capitán; (c) los 2 cortes de Encarnación renombrados a Corte20260616 y Corte20260708. **Residuos:** reflejar la dedup de Cano en el maestro v03 (Drive/ActividadesDiarias); confirmar Run del relevo 45359; decidir si el `IMTickets-Corte20260608` se renombra a 20260708.
2. **JC → Víctor:** pedir export final del 70.3-2025 → proyección con confianza ALTA.
3. **JC:** conseguir export de suscripciones GHL/Stripe → Fase 3 (planes de pago, métricas 13-15).
4. **JC:** compartir la carpeta `REB-SistemaRegistros-703` con el equipo.
5. ~~**SherpaX (F2):** dashboard BRD HTML del 70.3~~ ✅ **Hecho (2026-07-10):** `BRD-REB-IRONMAN703-Dashboard-v01.html` en `IB-REB-Rebelocity/PB-REB-Rebelocity`. 15 métricas + curva + proyección, verificado 9/9. **Residual:** métricas 13-15 (planes de pago) al conseguir export GHL/Stripe; ratificador del BRD pendiente.
6. **Vault:** trasladar reporte del corte (`DC-REB-SeguimientoRegistro-IRONMAN2026-Corte20260708-v01`), script `.py` y notebook `.ipynb`.

## Reporte de cierre a Jay/Victor

> "JC — cleanup corrido: 0 skills desinstaladas (equipo ya sano), los 5 plugins WORX en versión correcta, cero rutas muertas/duplicados/rogue. Todo ✅."