---
type: MePB
asset_id: MePB-EL-DashboardBuilder-Metodologia-v01
version: v01
status: Activo
owner: Victor Heredia
sherpa_owner: Jay
fecha_creacion: 2026-06-06
intellbank: IB-EL-EmpowerLabs
room: XP-EL-DashboardBuilderRoom-v01
proposito: >
  Metodología canónica para crear, sincronizar y mantener dashboards vivos en el
  ecosistema VH. Define la arquitectura de 4 capas, el protocolo de sincronización
  bidireccional con el vault (XDocs incluidos), y dónde vive cada artefacto.
referencia_canonica:
  - XP-EL-DashboardBuilderRoom-v01 (room que rige esta metodología)
  - DC-XX-WORX-TaxonomiaXDoc-v01 (tipado de XDocs = data agregable)
  - MPB-EL-WORX-ModeloOperativo-v01 (XDoc base · 7 secciones)
  - Brand/EL-BrandOS-Tokens-v03.css (COLOR · fuente única de tokens · marca azul v03.2)
  - Brand/TP-EL-Brand-WebColorMigration-v01 (receta de migración de color · 3 versiones)
  - IB-XX-Maestro/EL-DashboardStandard-v01.js (kit central que inyecta la paleta · mayor palanca)
tags: [mepb, dashboards, sync, xdoc, worx, artifact, metodologia]
---

# Metodología Dashboard Builder

## El problema que resuelve

Hoy un dashboard del ecosistema vive en cuatro lugares que no se hablan entre sí:

1. **El vault** — documentos .md (minutas, XDocs, TPs) que son la fuente de verdad
2. **El HTML** — el dashboard como archivo en su IntelliBank, abierto vía `computer://`
3. **El artifact Cowork** — copia persistente cross-session en el sidebar
4. **El localStorage del browser** — los clics de Victor (dots pending→working→done) que nadie lee de vuelta

El WeekDashboard demuestra el patrón correcto a medias: separa datos (`AXES`) del render, es interactivo, pero sus datos están *hard-coded* en el JS y sus estados mueren en localStorage. El Dashboard Maestro tiene acciones (`sendPrompt`) pero contenido estático. La metodología cierra el circuito completo.

---

## Decisión arquitectónica: dos dashboards, una fuente

**Se mantienen dos dashboards separados.** No se fusionan. Razones:

| Dimensión | Maestro (ecosistema) | Semanal (operativo) |
|---|---|---|
| Altitud | 30,000 pies — 7 unidades, backlog | Pista — tareas de la semana |
| Cadencia de cambio | Semanal/quincenal | Varias veces al día |
| Interacción | Navegar + disparar prompts | Marcar estados (dots) |
| Fuente de datos | TPs, XPs, prioridades | Minuta TeamSync + XDocs |

Fusionarlos crearía un artefacto pesado que mezcla dos ritmos de actualización distintos: cada clic operativo "ensuciaría" la vista estratégica, y cada rediseño estratégico arriesgaría el estado operativo. La conexión correcta entre ambos no es fusión sino **enlace + fuente compartida**: el Maestro enlaza al Semanal (ya lo hace), y ambos se regeneran desde los mismos documentos del vault.

**Lo que sí se unifica:**

- **El sistema de diseño** — la norma del WeekDashboard (superior) se adopta como Norma v2 para todos los dashboards
- **La capa de datos** — ambos se derivan de documentos tipados del vault
- **El protocolo de sync** — un solo flujo para todos

---

## Arquitectura de 4 capas

Todo dashboard VH se construye con estas cuatro capas separadas:

### Capa 1 · Datos

Los datos viven en un bloque `const DATA = [...]` (o JSON island) claramente separado del render, **nunca** mezclados en el HTML. El bloque se deriva de documentos tipados del vault:

- Dashboard Semanal ← minuta `OUT-MIN-EL-TeamSync` + XDocs activos
- Pipeline LoopX ← frontmatter tipado de los XDoc Loop (`gravity_score`, `orbit_state`, `value_tier`...)
- Dashboard Maestro ← TPs, XPs y prioridades declaradas

El principio viene de `DC-XX-WORX-TaxonomiaXDoc-v01`: *sin tipado, los documentos son notas sueltas; con tipado, son data agregable*. Un dashboard preciso requiere XDocs tipados como fuente. Jay regenera el bloque DATA leyendo el vault — el dashboard nunca inventa datos.

### Capa 2 · Render

Norma de diseño v2 (estructura) + **paleta v03.2 marca azul (CANÓNICA, Victor L3+ 2026-07-20)**:

> **⚠️ COLOR — fuente única de verdad: `Brand/EL-BrandOS-Tokens-v03.css` + `TP-EL-Brand-WebColorMigration-v01`.** La paleta morada/periwinkle y el verde `#567411` quedan **DESCARTADOS**. No definir hex a mano: pegar los tokens. El kit central `IB-XX-Maestro/EL-DashboardStandard-v01.js` inyecta esta paleta a todos los tableros — migrarlo una vez propaga la marca al ecosistema (punto de mayor palanca).

- **Regla dura de color:** los FONDOS son SIEMPRE negro/oscuro neutro (`#0C0C10` · surface `#15151C` · `#1D1D26` · línea `#2B2B36`) o blanco/neutro (`#FFFFFF` · `#FAFAFC` · `#F1F1F6` · `#E6E6EC`). **NUNCA color de relleno.**
- **Azul eléctrico = resalte (casa):** `#1E9BF0` sobre claro / `#5BC3FF` sobre oscuro — texto destacado, viñetas, bordes, iconos, el símbolo. Vía token `--ink-accent`.
- **Rosita/magenta `#CA3BAE` = acción** (CTAs, indicadores activos). **Teal `#34C7BA` = dato/éxito.** Cyan `#3DC7DE` = N3 · índigo `#3B5BD9` = N2.
- Texto neutro: oscuro `#ECECF0` / `#B8B8C4` / `#86868F` · claro `#171622` / `#3D3D4A` / `#6E6A7A`. Contraste AA en texto (el `#5BC3FF` y el teal NO pasan AA sobre blanco → en claro el sistema usa `#1E9BF0` vía `--ink-accent`).
- Tipografía: **Manrope** (display) · **Public Sans** (texto) · JetBrains Mono (código). Radios `16px`/`26px`. Cards colapsables con stripe de color por eje · barra de progreso por card.
- Dots interactivos de 3 estados: pending (borde tenue) → working (borde 2px) → done (relleno teal `#34C7BA`).
- Stats row arriba: total / completadas / working / pendientes / urgentes. Responsive: 3 → 2 → 1 columnas.
- **3 versiones siempre** (regla WebColorMigration): Oscuro · Claro · Híbrido, con sistema de tema por tokens (`data-theme` + clase `sec-light` en secciones alternas para híbrido). Sufijos `-Oscuro/-Claro/-Hibrido` o un solo archivo con switch.
- **Switch de tema obligatorio** en el header; preferencia en localStorage.
- **Tema por defecto: OSCURO** (desde 10-jun-2026). El usuario cambia a claro/híbrido si lo necesita (presentación/proyección).

### Capa 3 · Acción

Dos mecanismos, cada uno para lo suyo:

- **Enlaces directos al vault** — acceso a documentos existentes. La regla canónica por tipo de archivo:
  - **`.md` → `obsidian://open?vault=Intellibanks&file=<ruta-relativa-sin-extensión>`** (la ruta se codifica con `encodeURIComponent` por segmento, separadores como `%2F`). Los markdown son notas de Obsidian; abrirlas en Obsidian es el contexto correcto, no el visor del sistema.
  - **`.html` → RUTA RELATIVA al árbol IntelliBanks (migración-proof).** El link guarda la ruta vault-relativa en `data-path="IB-…/archivo.html"` y un manejador `openDash()` la resuelve: en navegador / archivo del vault antepone `../`×(profundidad del dashboard) — **portable entre máquinas y usuarios**, no depende de la raíz absoluta del vault; dentro de Cowork (artifact) usa `computer://` + raíz configurable. Reemplaza la regla previa de ruta absoluta `/Users/...`, que se rompía al migrar a IntelliBanks (cada miembro tiene el vault en otra ruta).
  - **`.skill`, otros binarios → `computer://<ruta-absoluta>`** cuando se necesita la app del sistema.
  - Patrón canónico: `data-path` (vault-relativo) + `openDash(event,this)` con `const DEPTH='../'×niveles del dashboard`. Implementado en BRD-EL-HOY (`../../`), Hub y Maestro (`../`). Los `.md` siguen en `obsidian://` (portable por nombre de vault, no por ruta).
- **`sendPrompt()` buttons** — acciones que requieren a Jay (generar un Home, actualizar prioridades, correr el sync). Usar cuando el destino aún no existe o la acción es generativa.

Regla práctica: **si el documento existe → link directo; si hay que crearlo o procesarlo → prompt.**

Todo dashboard incluye el **shim estándar**: si `sendPrompt` no está definido en el contexto (browser normal, artifact), el prompt se copia al portapapeles con un toast "Prompt copiado — pégalo en el chat de Jay". Nada falla en silencio.

### Capa 4 · Sync

El protocolo bidireccional completo:

```
VAULT → DASHBOARD (regeneración)
  Jay lee minuta + XDocs tipados
      ↓
  Regenera el bloque DATA del dashboard
      ↓
  Actualiza HTML en vault + artifact Cowork (siempre gemelos)

DASHBOARD → VAULT (captura de estado)
  Victor marca dots durante la semana (localStorage)
      ↓
  Botón "Sync con Jay ↗" serializa los estados a un prompt
      ↓
  Jay actualiza minuta, XDocs afectados y Dashboard Maestro
      ↓
  Jay regenera PRESETS del dashboard (el estado queda persistido en vault)
```

El botón "Sync con Jay" es la pieza que faltaba: convierte el localStorage —antes un callejón sin salida— en input estructurado para el ritual del weekly-sync.

---

## Dónde vive cada cosa

| Artefacto | Ubicación | Ejemplo |
|---|---|---|
| HTML del dashboard | El IntelliBank de su dominio | `IB-EL-.../EQ-EL-Equipo/EL-WeekDashboard-20260601-v01.html` |
| Artifact Cowork | Slug kebab-case, espejo del HTML | `ecosistema-maestro-vh` |
| Documento fuente | Su IB, con frontmatter tipado | `OUT-MIN-EL-TeamSync-20260601-v01.md` |
| Home de unidad (IH-) | El IB de la unidad | `IH-EL-EmpowerLabs-Home-v01.md` |
| Esta metodología | PB-EL-Project-Bank (junto al XPack) | este documento |

Regla invariante: HTML en vault y artifact Cowork son **gemelos** — toda edición se aplica en ambos en la misma operación. El que se desfasa se considera roto.

---

## Checklist de creación (algoritmo del futuro Builder Skill)

1. Definir tipo de dashboard (Maestro / Semanal / Unidad / Financiero / Proyecto / Mapa) y su documento fuente en el vault
2. Si la fuente no está tipada → tiparla primero (frontmatter XDoc)
3. Generar bloque DATA desde la fuente
4. Render con Norma v2
5. Capa acción: enlaces a docs existentes (`.md`→obsidian:// · `.html`→ruta relativa vía `openDash()`/`data-path` · otros→computer://) + botones `sendPrompt` para lo generativo + shim
6. Botón "Sync con Jay" si el dashboard captura estado interactivo
7. Guardar HTML en el IB correcto con nomenclatura BMF
8. Crear/actualizar artifact gemelo
9. Registrar en el XPack del room (§3 Estado actual)

---

## NEXTs

- [ ] **JAY** Convertir este checklist en el Dashboard Builder Skill (spec técnica)
- [ ] **JAY** Migrar el Dashboard Maestro a Norma v2 (diseño WeekDashboard)
- [ ] **JAY** Tipar la minuta TeamSync para que el bloque DATA del Semanal se regenere sin intervención manual
- [ ] **VH** Validar el flujo "Sync con Jay" en uso real durante una semana

---

## Changelog

| Fecha | Versión | Cambio |
|---|---|---|
| 2026-06-06 | v01 | Creación. Derivado del análisis Maestro vs Semanal en el Dashboard Builder Room. |
| 2026-06-06 | v01.1 | Norma v2: switch de tema claro/oscuro obligatorio en todo dashboard (primera implementación: ROI Tracker v2.1). |
| 2026-06-06 | v01.3 | Retrofit completo del switch de tema: Dashboard Maestro y WeekDashboard. Los 3 dashboards activos ya cumplen la Norma v2. |
| 2026-06-06 | v01.2 | Regla de enlaces por tipo de archivo: `.md`→`obsidian://`, resto→`computer://` (función `evHref`). Aplicada a ROI Tracker y Dashboard Maestro. |
| 2026-06-08 | v01.4 | Corrección de la regla de enlaces `.html`: ruta absoluta plana `/Users/...` SIN `computer://` (este no abría bien los HTML). `.md` sigue en obsidian://, binarios en computer://. Aplicada en el Dashboard Maestro. |
| 2026-06-17 | v01.6 | Enlaces `.html` → **ruta relativa migración-proof** (`data-path` + `openDash()`): portable entre máquinas/usuarios, no depende de la raíz del vault. Resuelve el riesgo de la migración a IntelliBanks. Aplicado en BRD-EL-HOY, Hub y Maestro. |
| 2026-06-10 | v01.5 | Tema por defecto cambiado a OSCURO para todos los dashboards (antes claro). Aplicado primero en BRD-EL-HOY. |
| 2026-07-20 | v01.7 | **Paleta canonizada a marca azul v03.2** (Victor L3+): fondos neutros, azul `#1E9BF0`/`#5BC3FF` = resalte, rosita `#CA3BAE` = acción, teal = dato; morado/verde descartados. Fuente única: `EL-BrandOS-Tokens-v03.css` + `TP-EL-Brand-WebColorMigration-v01`. Tipografía Manrope/Public Sans. 3 versiones (Oscuro/Claro/Híbrido). Kit central `EL-DashboardStandard-v01.js` = punto de mayor palanca. Primera aplicación bajo la nueva norma: `EL-ROX-IBX-Visualizaciones-v01.html`. |

---

*MePB-EL-DashboardBuilder-Metodologia-v01 · IB-EL-EmpowerLabs · 2026-06-06 · act. 2026-07-20 · Jay*