# review-mockup — E250-C0062

**Aprobada:** `v1-diagnostico-por-dia.html`
**Motivo:** reproduce el idiom exacto del panel real (`PanelMappingView`: `card bg-base-100 border border-base-300` + `card-body p-0` + cabecera `px-5 py-3 border-b` + `table table-sm` con filas `hover` y el subtítulo `text-xs text-base-content/50 font-mono` para los IDs VT/TT), así que se integra de forma nativa y es lo más directo de construir con `build-frontend`. Para una herramienta de **diagnóstico** —cuyos criterios giran sobre leer VT vs TT lado a lado de forma explícita por par y por día— las columnas Horas VT / Horas TT separadas sirven la intención mejor que la celda compacta de v2. v2 (grid calendario) gana en densidad para rangos largos pero sacrifica justo esa lectura lado-a-lado explícita y estrena un layout que hoy no existe en el panel.

Nota de proceso: el browser del MCP de Playwright estaba en uso por otra sesión paralela (lock `mcp-chrome-for-testing`), así que no se forzó el render para no pisar su trabajo. La review se hizo sobre el fuente HTML completo de ambas variantes (CDN Tailwind + DaisyUI + tema inline e250 autocontenido) cotejado contra `PanelMappingView.vue` y `tailwind.config.js`.

## Cobertura de criterios visuales (ambas variantes)

- ✅ Cabecera "Experiencia combinada" (eyebrow + título VT↔TT + IDs) y back link "‹ Volver a la tabla de mapping".
- ✅ Rango de días: `input type=number min=1 max=180 value=30` + nota "Rango permitido 1–180 días" (default 30).
- ✅ Filtro tri-estado (`join` de 3 radios: Todas / Solo coinciden / Solo no coinciden), "Todas" checked + nota "Por defecto: ambas".
- ✅ Desglose por par de opciones (v1: una card+tabla por par; v2: tabs para alternar par activo).
- ✅ Horas VT vs TT por día con estado coincide/no-coincide indicando el lado ("solo VT"/"solo TT" en v1; ▸V/▸T + leyenda en v2).
- ✅ Estado de fallo "no se pudo consultar TT" distinto de "sin horas" (v1: `alert alert-warning` + Reintentar vs celda `sin horas`; v2: celda con borde warning + "No se pudo consultar TT" + badge `TT ?` vs nota `TT: sin horas`).
- ✅ Tema e250 con tokens reales (`data-theme="e250"`), DaisyUI semántico, banner "MOCKUP — no producción" presente en ambas.

## Findings por variante

### v1-diagnostico-por-dia.html (aprobada)
- ✅ Tema real, DaisyUI semántico, banner de mockup presente, coherencia 1:1 con el shell del panel.
- [ ] Menor: la badge de leyenda "TT no consultado" usa `badge-ghost border border-warning text-warning` ad-hoc; al construir, considerar una clase semántica estable (p.ej. `badge-warning badge-outline`) para no depender de la combinación de utilidades.
- [ ] Menor: el `alert alert-warning` del día con fallo de TT ocupa `colspan="2"` sobre las columnas Horas VT/Horas TT, dejando la columna Estado a su derecha vacía esa fila. Al implementar, decidir si la fila de fallo abarca también la columna Estado (`colspan="3"`) para no dejar un hueco ambiguo.
- [ ] Menor (no visual, para build-frontend): el aviso `alert alert-info` muestra "Consultando 30 días · 2 pares" hardcodeado; en producción debe derivarse del rango/pares reales.

### v2-grid-calendario.html (no aprobada — alternativa válida)
- ✅ Tema, DaisyUI semántico, banner presente; cubre todos los criterios.
- [ ] La abreviatura `▸V` / `▸T` y los badges `2 ✕` priorizan densidad sobre legibilidad; en una herramienta de diagnóstico la lectura explícita VT vs TT (v1) es preferible. No es un fallo, es el eje de decisión.
- [ ] El layout grid-calendario no tiene precedente en el panel actual; adoptarlo introduce un patrón nuevo que el resto del panel no usa.

## Veredicto

aprobado: `v1-diagnostico-por-dia.html` (con los ajustes menores anotados, no bloqueantes para promover)

## Decisión humana (2026-06-04)

Tras revisar también las iteraciones posteriores `v3-resumen-y-tabla.html` y `v4-tira-de-salud-y-semanas.html`, el responsable **reafirma `v1-diagnostico-por-dia.html`** como variante aprobada para construir. v3/v4 quedan como referencia de exploración (capa de resumen de salud, tira por día, agrupación por semana, accesibilidad por glifos) que `build-frontend` puede tomar como guía si surge la necesidad, pero la superficie base a implementar es la de v1.