--- type: TP asset_id: TP-EL-PlatformIntelligence-MPX-RClub-v01 version: v01 status: Activo owner: Victor Heredia sherpa_owner: Jay ratificador: Victor Heredia fecha_creacion: 2026-07-03 fecha_ultima_actualizacion: 2026-07-03 intellibank: IB-EL-EmpowerLabs subbank: PB-EL-Plataforma proposito: > Transfer Pack de arranque para el proyecto Platform Intelligence — diagnóstico actualizado de funcionalidades MasterPlaybooks + RClub, tablero vivo con status/responsables/alertas, mapa de operación con métricas en tiempo real (API), y estrategia de revisión de código. Diseñado para Fable 5 (modelo eficiente), transferible entre rooms. modelo_objetivo: Fable 5 (claude-fable-5) platforms: [MasterPlaybooks (masterplaybooks.com/dev), RebelocityClub (rebelocityclub.com/dev)] tags: [TP, plataforma, diagnostico, dashboard, operacion, metricas, api, code-review, MPX, RClub, platform-intelligence] --- # TP · Platform Intelligence — MasterPlaybooks + RClub ## Transfer Pack de arranque · Diagnóstico · Tablero · Operación · Código > **Tripleta WORX** — Owner: Victor Heredia · Sherpa: Jay · Ejecuta: Fable 5 > **Plataformas:** MasterPlaybooks (`masterplaybooks.com/dev`) · RebelocityClub (`rebelocityclub.com/dev`) > **Propósito:** Este pack permite a cualquier Room nuevo ejecutar el proyecto Platform Intelligence desde cero, sin depender de contexto previo. Leer completo antes de iniciar cualquier módulo. --- ## §0 · Contexto del proyecto EmpowerLabs opera **dos plataformas digitales sobre la misma arquitectura de base**: | Plataforma | Descripción | Estado | |---|---|---| | **MasterPlaybooks** (`masterplaybooks.com`) | Plataforma de lecturas inteligentes: resúmenes, audio, Sherpas AI por libro (KatIA) | En operación · membresías activas | | **RebelocityClub** (`rebelocityclub.com`) | Comunidad colaborativa para el ecosistema endurance (Paraguay + expansión): foros, clasificados, directorio, marketplace, gamificación | En dev · piloto próximo | Ambas plataformas comparten el motor de la Plataforma de Comunidades Colaborativas (13 módulos canónicos) pero con verticales distintas. Los problemas de una impactan a la otra — y el equipo de desarrollo es compartido. **El problema actual:** no existe un sistema unificado de visibilidad del estado de la plataforma. Nadie tiene una vista consolidada de (a) qué funciona y qué no, (b) quién es responsable de qué, (c) qué está fallando en producción ahora mismo. Este proyecto lo construye. --- ## §1 · Activos de referencia canónicos ### 1.1 MasterPlaybooks (MPX) | Asset ID | Descripción | Ubicación | |---|---|---| | `DC-MPX-FeatureMap-Recomendaciones-v01` | **Auditoría en vivo de MPX** — exploración sistemática en `masterplaybooks.com/dev`: inventario de funcionalidades por sección con estados, oportunidades de mejora y recomendaciones. Fecha: 2026-05-16 | `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` | | `SIM-Inventario-Funcionalidades-v01` | Inventario de funcionalidades por dimensión (Usuario / Autor / Admin) con estados ✅/⚠️/❌ | `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` | | `SIM-Diagnostico-MPB-v01` | Diagnóstico de bugs críticos, mejoras UX y brechas estructurales. Fuentes: auditoría Sherpa v10 + evaluación BookFactory | `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` | | `AUD-MPX-SherpaPrompt-v10-Auditoria-v01` | Auditoría del Sherpa Prompt v10 (KatIA). Score 51/100 → v2.0 proyectada 87/100 | `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` | | `DC-MPX-BusinessModel-v01` | Modelo de negocio MPX | `IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/` | ### 1.2 RebelocityClub (RClub) | Asset ID | Descripción | Ubicación | |---|---|---| | `OUT-REB-RClub-AnalisisFuncional-v01` | **Auditoría en vivo de RClub** — foros, clasificados, perfil, usuario admin. Fecha: 2026-06-16. Hallazgo clave: datos cross-contaminados entre canales (RClub muestra contenido de TribusRRHH México) | `IB-REB-Rebelocity/` | | `PLAN-EL-DesarrolloPlataformaComunidades-v01` | Plan de desarrollo del sprint de lanzamiento — 13 módulos canónicos con estado por módulo, criterios de éxito, dependencias | `IB-EL-EmpowerLabs/PB-EL-Plataforma/` | | `DC-REB-RClub-SistemaPuntosMembresias-v01` | Documentación técnica del motor Points v2 — flujo completo de puntos, membresías, tiers, recompensas, tarjetas QR | `IB-REB-Rebelocity/` | | `RFI-EL-PlataformaComunidades-AfiliacionTarjetaPuntos-v01` | Requerimientos de implementación: afiliación de comercios, tarjeta de marca privada, tracking comercial | `IB-EL-EmpowerLabs/PB-EL-Plataforma/` | | `KB-REB-RClub-KatIA-CanalContexto-v01` | Knowledge base de KatIA para el canal RClub | `IB-REB-Rebelocity/` | ### 1.3 Arquitectura compartida (13 módulos canónicos) La plataforma tiene 13 módulos canónicos documentados en `PLAN-EL-DesarrolloPlataformaComunidades-v01`: 1. News Engine 2. Librería + MasterPlaybooks 3. Foros 4. Directorio + Perfiles 5. Marketplace B2B/B2C 6. Campus 7. Gamificación + Rallies 8. Clasificados 9. Empleos 10. Comunicación cruzada 11. Eventos + Calendario 12. Membresías multinivel 13. IA transversal (KatIA / Sherpas) --- ## §2 · Alcance del proyecto — 4 módulos de trabajo ### MÓDULO 1 — Diagnóstico actualizado de funcionalidades (MPX + RClub) **Qué es:** Replicar y actualizar la auditoría de `DC-MPX-FeatureMap-Recomendaciones-v01` (MPX) y `OUT-REB-RClub-AnalisisFuncional-v01` (RClub) con la plataforma en su estado actual. El diagnóstico anterior de MPX es de mayo 2026; el de RClub es de junio 2026 — ambos requieren refresh. **Objetivo de salida:** `OUT-EL-PlatformDiag-MPX-v02.md` + `OUT-EL-PlatformDiag-RClub-v02.md` **Protocolo de exploración en vivo:** ``` 1. Ingresar con credenciales de administrador (Victor provee sesión o captura de pantalla) 2. Recorrer módulo por módulo siguiendo los 13 módulos canónicos 3. Para cada funcionalidad documentar: - ID único (formato: [PLATAFORMA]-[MÓDULO]-[SEQ], ej: MPX-LIB-01) - Nombre de la funcionalidad - Estado: ✅ Operativo · ⚠️ Parcial · ❌ Faltante · 🔴 Bug activo · 🔒 Bloqueante - Notas / evidencia observada - Responsable (Alex / Jesús / Gus / Anahí / Victor) - Prioridad de atención: P0 (bloqueante lanzamiento) · P1 (alta) · P2 (media) · P3 (backlog) 4. Contrastar hallazgos con auditorías previas — marcar cambios desde última revisión 5. Identificar: bugs nuevos detectados / funcionalidades reparadas / regresiones ``` **Criterio de completitud:** mínimo 3 módulos canónicos auditados por sesión; documentar evidencia antes de cerrar el room. **Comparar contra:** - Para MPX: `DC-MPX-FeatureMap-Recomendaciones-v01` + `SIM-Inventario-Funcionalidades-v01` - Para RClub: `OUT-REB-RClub-AnalisisFuncional-v01` + spec de los 13 módulos --- ### MÓDULO 2 — Tablero vivo de funcionalidades **Qué es:** Dashboard HTML interactivo (fondo #0a0a0a, estilo EmpowerLabs) que muestra el inventario completo de funcionalidades de ambas plataformas con estado en tiempo real (manual por ahora, API en M3), filtros por plataforma/módulo/responsable/prioridad, y panel de alertas. **Objetivo de salida:** `BRD-EL-PlatformStatus-MPX-RClub-v01.html` **Especificaciones del tablero:** ``` VISTA PRINCIPAL — Tabla de funcionalidades ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Columnas: [ID] | [Funcionalidad] | [Plataforma] | [Módulo] | [Estado] | [Responsable] | [Prioridad] | [Última actualización] | [Notas] Filtros: - Plataforma: MPX / RClub / Ambas - Módulo: dropdown con 13 módulos canónicos - Estado: ✅ / ⚠️ / ❌ / 🔴 / 🔒 - Responsable: Alex / Jesús / Gus / Anahí / Victor - Prioridad: P0 / P1 / P2 / P3 PANEL DE ALERTAS (sidebar derecho) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ - 🔴 Bugs activos por prioridad - ⚠️ Funcionalidades en riesgo - 🔒 Bloqueantes de lanzamiento - Contador por responsable (cuántos items abiertos tiene cada uno) HEADER DE ESTADO ━━━━━━━━━━━━━━━━ - % operativo por plataforma (ej: MPX 78% · RClub 54%) - Última actualización - Botón "Marcar actualización" (actualiza timestamp) ESTADOS DE COLOR ━━━━━━━━━━━━━━━━ ✅ Verde (#22c55e) — Operativo ⚠️ Amarillo (#eab308) — Parcial / Degradado ❌ Gris (#6b7280) — Faltante / No implementado 🔴 Rojo (#ef4444) — Bug activo 🔒 Naranja (#f97316) — Bloqueante de lanzamiento ``` **Responsables del equipo (para columna Responsable):** | Persona | Área principal | |---|---| | Alex | Backend · Infra · Membresías · Pagos · Monitoreo | | Jesús | Frontend · UX · Sherpa/KatIA · Lectura | | Gus | BookFactory · IA Pipeline · Orquestación · QA | | Anahí | Contenido · Administración canal · Publicaciones | | Victor | Estrategia · Decisiones · Aprobaciones | **Dato inicial:** Cargar desde `SIM-Inventario-Funcionalidades-v01.md` (MPX) y `OUT-REB-RClub-AnalisisFuncional-v01.md` (RClub) como base. Marcar qué data viene de simulación (SIM) vs. auditoría en vivo. **Stack técnico:** - HTML autocontenido (todo inline: CSS + JS) - `localStorage` con SK `el-platform-status-v01` para persistir estados manuales entre sesiones - Sin dependencias externas (offline-first) - El tablero debe ser legible en pantalla de laptop sin scroll horizontal --- ### MÓDULO 3 — Mapa de operación y métricas en tiempo real **Qué es:** Sistema de monitoreo operativo de las plataformas — actividad de usuarios, accesos, consultas por sección, y métricas de desempeño (tiempos de carga, latencia). Requiere integración API. **Objetivo de salida:** `BRD-EL-PlatformOps-Dashboard-v01.html` + `ARQ-EL-PlatformOps-API-v01.md` #### 3.1 Métricas de actividad (qué monitorear) ``` USUARIOS - Usuarios activos ahora (concurrent sessions) - DAU / WAU / MAU - Nuevos registros últimas 24h - Sesiones por plataforma (MPX vs RClub) CONTENIDO / CONSULTAS - Libros/playbooks más consultados (MPX) - Módulos más visitados (RClub: Foros / Clasificados / Directorio) - Consultas al Sherpa/KatIA por hora - Artefactos generados en últimas 24h CONVERSIÓN - Tasa de conversión free → membresía (MPX) - Intentos de membresía fallidos (pago rechazado) - Cancelaciones del período DESEMPEÑO TÉCNICO - Tiempo de carga de página (p50 / p95 / p99) - Latencia del Sherpa/KatIA (tiempo de primera respuesta) - Tasa de errores 5xx últimas 1h - Disponibilidad (uptime %) últimas 24h / 7d / 30d - Tamaño de cola BookFactory (MPX) ``` #### 3.2 Estrategia de integración API **Fase 1 — Mock/Manual (inmediato, sin API):** - El dashboard muestra slots con datos de ejemplo o "pendiente de API" - Victor o el equipo alimentan los campos clave manualmente cada día - Valor: el equipo ve el mapa operativo y se acostumbra al hábito **Fase 2 — API propia de la plataforma (medio plazo):** ``` Endpoint canónico sugerido: GET /api/v1/platform/metrics Headers: Authorization: Bearer {ADMIN_TOKEN} Response: { "timestamp": "2026-07-03T10:00:00Z", "active_users": 42, "dau": 387, "requests_last_hour": 1203, "sherpa_avg_latency_ms": 2100, "error_rate_5xx": 0.002, "uptime_24h": 99.8, "top_content": [...], "bookfactory_queue": 3 } El equipo de dev (Alex/Jesús) expone este endpoint con token de administrador. Jay/Room puede construir el fetch JS en el dashboard una vez que el endpoint existe. ``` **Fase 3 — Monitoreo externo (complementario, no bloqueante):** - Herramientas candidatas para evaluar: Uptime Robot (disponibilidad) · Sentry (errores JS) · Datadog/New Relic (APM) · Google Analytics (comportamiento usuario) - Estas herramientas se integran al dashboard mediante sus propias APIs (libres o con plan básico) - RFI a Alex: confirmar qué monitoreo externo ya está activo en la plataforma #### 3.3 Diseño del dashboard de operación ``` HEADER ● MPX ● ONLINE / ⚠ DEGRADED / ✕ DOWN ● RClub ● ONLINE / ⚠ DEGRADED / ✕ DOWN Última actualización: hace X min [Actualizar ahora] BLOQUE 1 — Actividad en tiempo real [Activos ahora] [DAU] [Sesiones MPX] [Sesiones RClub] BLOQUE 2 — Contenido más activo Top 5 libros/playbooks (MPX) Top 5 módulos (RClub) Consultas Sherpa/KatIA (últimas 24h) BLOQUE 3 — Desempeño Tiempo de carga p50 / p95 Latencia Sherpa Error rate Uptime 24h / 7d BLOQUE 4 — Conversión y negocio Nuevos registros hoy Conversiones membresía hoy Cancelaciones hoy Cola BookFactory BLOQUE 5 — Alertas activas [Lista de incidentes activos con severidad] ``` --- ### MÓDULO 4 — Estrategia de revisión y depuración de código (futuro) **Qué es:** Una vez que M1–M3 están operativos, se realiza una revisión técnica del código fuente de la plataforma para identificar ineficiencias, deuda técnica y oportunidades de optimización. **Pre-requisito:** Acceso al repositorio de código (GitHub o equivalente). Victor confirma acceso y metodología de entrega (zip, repo privado, MCP GitHub). **Objetivo de salida:** `ARQ-EL-CodeReview-Platform-v01.md` (mapa de hallazgos técnicos) **Protocolo de revisión de código:** ``` FASE A — Inventario del stack 1. Identificar framework/lenguaje de cada capa (frontend / backend / DB / IA) 2. Mapear estructura de directorios y módulos 3. Detectar versiones de dependencias críticas y su estado (desactualizadas / con CVEs) FASE B — Análisis por módulo crítico Prioridad de revisión: P0 · Módulo de Membresías/Pagos (Stripe) — seguridad y datos de cliente P0 · BookFactory / pipeline IA — throughput y cuellos de botella P1 · Sherpa/KatIA prompt chain — eficiencia de tokens y latencia P1 · Aislamiento multi-canal — el bug de datos cross-contaminados (datos TribusRRHH en RClub) P2 · Autenticación y sesiones — persistencia del historial Sherpa entre sesiones P2 · Frontend Bundle — tamaño, lazy loading, tiempo de carga FASE C — Priorización técnica Para cada hallazgo: - Severidad: Crítico / Alto / Medio / Bajo - Esfuerzo: Horas / Días / Semanas - Impacto en usuario: Alto / Medio / Bajo - Recomendación: Refactor / Parche / Upgrade / Documentar FASE D — Entregable - Mapa de hallazgos técnicos (ARQ-EL-CodeReview-Platform-v01.md) - Top 10 acciones de mayor impacto/esfuerzo - Estimación de roadmap técnico (no cronograma, sí secuencia) ``` --- ## §3 · Plan de ejecución por rooms | Room | Modelo | Módulo(s) | Entregables | |---|---|---|---| | **Room 1 — Diagnóstico MPX** | Fable 5 | M1 (MPX) | `OUT-EL-PlatformDiag-MPX-v02.md` | | **Room 2 — Diagnóstico RClub** | Fable 5 | M1 (RClub) | `OUT-EL-PlatformDiag-RClub-v02.md` | | **Room 3 — Tablero Funcionalidades** | Fable 5 | M2 | `BRD-EL-PlatformStatus-MPX-RClub-v01.html` | | **Room 4 — Dashboard Operación** | Fable 5 | M3 (Fase 1 mock) | `BRD-EL-PlatformOps-Dashboard-v01.html` | | **Room 5 — API Spec** | Fable 5 | M3 (Fase 2 spec) | `ARQ-EL-PlatformOps-API-v01.md` (para Alex/Jesús) | | **Room 6 — Code Review** | Fable 5 | M4 | `ARQ-EL-CodeReview-Platform-v01.md` | **Dependencias entre rooms:** ``` Room 1 + Room 2 (paralelo) → Room 3 (Tablero usa output del diagnóstico) Room 3 → Room 4 (Dashboard Ops comparte diseño con Tablero) Room 4 → Room 5 (API Spec se alinea con lo que el dash necesita mostrar) Room 3/4 independiente de Room 6 (Code Review puede iniciar en paralelo con acceso a repo) ``` --- ## §4 · Instrucciones de arranque para Room nuevo (Fable 5) > Copiar estas instrucciones como primer mensaje al abrir un Room nuevo de este proyecto. ``` Eres un especialista en análisis de plataformas digitales SaaS. Estás trabajando en el proyecto "Platform Intelligence" de EmpowerLabs, que busca construir visibilidad completa del estado operativo de dos plataformas: MasterPlaybooks y RebelocityClub. Antes de hacer cualquier cosa: 1. Lee el TP completo: TP-EL-PlatformIntelligence-MPX-RClub-v01.md Ruta: IB-EL-EmpowerLabs/PB-EL-Plataforma/ 2. Lee los activos de referencia para el módulo que se te asigna (ver §1) 3. Confirma con Victor qué módulo ejecutas en este room 4. Produce SOLO los entregables del módulo asignado — no avances sobre otros módulos Principios de eficiencia (Fable 5): - Lee solo lo que necesitas para el módulo activo - Produce artefactos concretos, no borradores ni esqueletos - Cada room cierra con al menos un entregable completo guardado en vault - Si necesitas acceso a la plataforma en vivo, pide a Victor credenciales o capturas - Naming BMF obligatorio: TIPO-ENTIDAD-Descripcion-vNN.ext ``` --- ## §5 · Gobernanza y gates de salida ### Gate de entrada (antes de iniciar cualquier módulo) - [ ] TP leído completo - [ ] Activos de referencia del módulo leídos - [ ] Módulo a ejecutar confirmado con Victor - [ ] Credenciales de plataforma disponibles (si el módulo requiere auditoría en vivo) ### Gate de salida (antes de cerrar cualquier room) - [ ] Al menos un entregable completo guardado en vault (naming BMF correcto) - [ ] Entregable registrado en la minuta del día - [ ] Notas de continuación escritas (qué sigue, qué faltó, qué decisiones tomar) - [ ] Handoff preparado si hay room siguiente ### Gobernanza de datos sensibles - Los accesos de plataforma (credenciales) NO se guardan en el vault - Datos de usuarios reales NO se incluyen en ningún entregable — solo métricas agregadas - Los entregables de RClub con datos de participantes se etiquetan: `confidencial: true` --- ## §6 · Decisiones pendientes (Victor ratifica) | # | Decisión | Opciones | Deadline | |---|---|---|---| | D1 | ¿Tablero de funcionalidades (M2) es único para ambas plataformas o uno por plataforma? | Único (tabs MPX/RClub) vs. dos archivos separados | Antes de Room 3 | | D2 | ¿El dashboard de operación (M3) arranca en mock manual o esperamos el endpoint API? | Mock inmediato vs. esperar API (2–4 semanas) | Antes de Room 4 | | D3 | ¿Acceso al código para M4? | GitHub repo privado / zip de módulos críticos / MCP GitHub | Antes de Room 6 | | D4 | ¿Herramienta de monitoreo externo ya activa? | Uptime Robot / Sentry / Datadog / ninguna | Alex confirma en RFI | | D5 | ¿El SIM-Inventario-Funcionalidades-v01 se borra después del diagnóstico actualizado? | Archivar vs. borrar (era "BORRAR DESPUÉS DE DEMO") | Después de Room 1+2 | --- ## §7 · NEXTs para arrancar - [ ] **NEXT Victor:** Confirmar D1–D4 antes del primer room - [ ] **NEXT Victor:** Proveer acceso a `masterplaybooks.com/dev` y `rebelocityclub.com/dev` para el room de diagnóstico - [ ] **NEXT Jay:** Abrir Room 1 (Diagnóstico MPX) con este TP como contexto - [ ] **NEXT Alex:** RFI — ¿qué monitoreo externo ya está activo? ¿Puedes exponer `/api/v1/platform/metrics`? - [ ] **NEXT Jesús:** ¿El historial de Sherpa ya persiste entre sesiones? (Bug BUG-02 del diagnóstico previo — ¿resuelto?) --- *Creado: 2026-07-03 · Jay · Transfer Pack Platform Intelligence v01*