--- type: DC asset_id: DC-EL-DashboardsPersonalizacion-Spec-v01 version: v01 status: Spec · diseño técnico owner: Victor Heredia sherpa_owner: Jay fecha_creacion: 2026-06-14 intellbank: IB-EL-EmpowerLabs subbank: EQ-EL-Equipo room: XP-EL-DashboardBuilderRoom-v01 proposito: > Especificación técnica para personalizar los dashboards al usuario activo: una sola fuente de verdad (el perfil de operador que escribe /wx-setupsherpax) alimenta el nombre, rol y accesos a todo el banco de dashboards, y separa la vista global (equipo) de la personal (del usuario). referencia_canonica: - DC-EL-PerfilOperador-{Nombre}-v01 (fuente de identidad · la escribe /wx-setupsherpax) - MePB-EL-DashboardBuilder-Metodologia-v01 (capa de datos / sync) - WOI-EL-ArranqueDia-ActivacionBacklog-v01 (P7 · versión multiusuario) - SOP-EL-SX-RegistryPersonal-v01 (registro personal del operador) tags: [dc, spec, dashboards, personalizacion, multiusuario, perfil-operador, doix] --- # Spec · Personalización de dashboards por usuario ## El problema Los dashboards traen contenido global (del equipo) mezclado con contenido personal (de Victor). Hoy el nombre está escrito a mano en cada archivo ("@Victor", "VH"). Para que el mismo banco sirva a todo el equipo —Ángeles, Juan Carlos, cada nuevo colaborador— hace falta que cada dashboard sepa **quién lo está viendo** y se ajuste solo: su nombre, sus tableros personales, sus accesos. La buena noticia: la fuente de verdad **ya existe**. `/wx-setupsherpax` escribe un `DC-EL-PerfilOperador-{Nombre}-v01` por cada persona. Este spec define cómo los dashboards consumen ese perfil. --- ## 1 · Fuente de verdad — el perfil de operador Cada operador tiene un perfil canónico (ej. `DC-EL-PerfilOperador-Angeles-v01`) con este esquema ya en uso: ```yaml operador: nombre: "Ángeles" rol_el: "Agencia Digital · Ingeniero" rol_doix: "Colaborador WORX · Operador en Inducción" accesos_intellibanks: lectura: "IB-EL-EmpowerLabs · IB-MPX · IB-REB" escritura: "IB-EL-EmpowerLabs · IB-REB · landing · web" luz_verde: true arranque_completado: false # ← controla si muestra el bloque de inducción ``` **Regla:** ningún dashboard inventa la identidad del usuario. La lee de su perfil. Un solo lugar que cambiar, todo el banco se ajusta. --- ## 2 · Cómo el dashboard resuelve "quién soy" Orden de resolución del usuario activo (de más explícito a default): 1. **Parámetro de URL** — `?user=Angeles` (útil para abrir el tablero de alguien más, o para demos) 2. **localStorage** — `dash-user` (lo que el usuario fijó en su equipo) 3. **Perfil de operador** — el `DC-EL-PerfilOperador-{Nombre}` cargado por el SherpaX 4. **Default** — el owner del archivo Implementado ya como prueba de concepto en `BRD-EL-HOY-Dashboard-v01` con la variable `USER` (pasos 1, 2 y 4). Falta conectar el paso 3 (leer del perfil). --- ## 3 · Qué se personaliza | Elemento | Fuente en el perfil | Ejemplo | |---|---|---| | Saludo | `nombre` | "Buen día, Ángeles" | | Título sección personal | `nombre` | "👤 Dashboards personales · @Ángeles" | | Bloque de inducción | `arranque_completado` | se oculta cuando es `true` | | Tableros personales visibles | `rol_el` + accesos | un comercial ve pipeline; un editor ve la factoría | | Filtro de pendientes | `nombre` | el Tablero de NEXTs ya escanea por `@Persona` — encaja directo | | Accesos a IntelliBanks | `accesos_intellibanks` | oculta enlaces a IBs sin permiso de lectura | --- ## 4 · Global vs. personal — la separación canónica Todo dashboard de equipo se divide en dos zonas: - **🌐 Zona global (arriba)** — igual para todos: Frentes, Mapa Cognitivo, WikiX, Skills Bank, mensajes del equipo, feed. No depende del usuario. - **👤 Zona personal (abajo)** — depende del `USER` activo: su Dashboard Semanal, sus NEXTs, su ROI Tracker, su Brain Code Map. Esta separación ya está aplicada en `BRD-EL-HOY`. Se vuelve la regla para todo dashboard con contenido mixto. --- ## 5 · Estrategia para los tableros personales Dos modelos, según el tipo de tablero: **A · Instancia por persona (datos propios).** Tableros cuyo contenido es distinto por usuario (Dashboard Semanal, ROI Tracker, Brain Code Map). Cada persona tiene su archivo: `EL-WeekDashboard-{Nombre}-AAAAMMDD`, `EL-WORX-ROITracker-{Nombre}`. La zona personal del HOY enlaza al archivo del `USER` activo. Naming: sufijo con iniciales o nombre del operador. **B · Vista filtrada (un archivo, filtra por usuario).** Tableros cuyo contenido es uno solo y se filtra (Tablero de NEXTs ya lo hace: escanea el vault por `@Persona`). Aquí no se duplica el archivo — el dashboard recibe el `USER` y muestra solo lo suyo. Regla de decisión: **si el contenido es propio de cada quien → instancia (A); si es un pool común que se filtra → vista filtrada (B).** --- ## 6 · Etapas de implementación **Etapa 1 · Variable de usuario (≈1 h) — 🟢 hecha** `USER` resoluble por URL / localStorage / default, separación global vs. personal, saludo y título dinámicos. Aplicado en `BRD-EL-HOY`. **Etapa 2 · Lector de perfil (≈2-3 h)** Función compartida `getOperador()` que lee el `DC-EL-PerfilOperador-{Nombre}` (vía artifact `callMcpTool` o un JSON derivado del perfil) y devuelve `{nombre, rol, accesos, arranque_completado}`. Los dashboards la usan en vez de la variable suelta. Oculta inducción y enlaces sin acceso. **Etapa 3 · Tableros personales por persona (≈3-4 h)** Convención de naming con sufijo de operador para los de tipo A; el HOY enlaza al archivo del `USER`. Tableros tipo B (NEXTs) reciben el filtro. Un nuevo colaborador que corre `/wx-setupsherpax` obtiene su HOY personalizado sin tocar código. --- ## 7 · Decisiones tomadas (14-jun) - **Fuente de perfiles → archivo derivado ✓ ratificado.** Se eligió un archivo único `EL-Perfiles-Operadores-v01.js` (mismo patrón que el `perfiles.json` propuesto, pero en `.js` para que cargue desde `file://` sin servidor) que expone `window.EL_PERFILES` + helpers `EL_getOperador()` / `EL_perfilKey()`. Lo regenera Jay en el sync semanal. Los dashboards lo incluyen con `