# review-mockup — E250-C0108

**Aprobada:** `v2-stacked-cards.html` como técnica **por defecto**, con mezcla explícita por vista (ver «Veredicto»).
**Motivo:** ambas variantes comparten un shell idéntico y fiel a `PanelView.vue` (tema `e250` real, grupos Operación/Plataforma/Desarrollo con sus iconos, banda staff-mode, breadcrumb, footer email+logout, drawer con backdrop, sidebar permanente ≥1024px). El eje que las separa es la tabla densa: en las tablas de muchas columnas (Logs API con 6, Reservas, Email log) el scroll-en-contenedor de v1 obliga a deslizar lateralmente para leer **un solo registro** (en el render, la columna URL/Estado/Duración queda cortada por el borde del contenedor a 375px), mientras las tarjetas apiladas de v2 se leen de un vistazo sin gesto lateral. Por eso v2 es el default; v1 se conserva como técnica válida para tablas estrechas y tablas dentro de modales.

## Verificación realizada (render real, chromium + tema e250 vía CDN)

- **Tema real aplicado:** `--p` resuelve a `oklch(0.66007 0.1499 153.95)` (el verde `#2eac66` del `tailwind.config.js` del widget). DaisyUI carga y los componentes (`btn`, `card`, `badge`, `select`, `table`) renderizan.
- **Objetivos táctiles (v2, móvil):** hamburguesa, enlace de nav del drawer, `btn-primary` «Nueva», `select` de filtro y «Cerrar sesión» miden **exactamente 40px** de alto → cumple ≥40px.
- **Sin recorte a 375px:** en v2 el método+URL usa `break-all` y cada registro cabe entero en la tarjeta (cero scroll horizontal, ni de página ni de contenedor). En v1 la tabla vive en `overflow-x-auto` con indicador visual «↔ Desliza» → la página no hace scroll lateral, el scroll queda acotado a la tabla (dato alcanzable, no recortado).
- **Marca de mockup:** ambas llevan el comentario `MOCKUP ESTÁTICO — NO es código de producción` en la cabecera HTML y el `badge badge-warning "MOCKUP — no producción"` visible arriba. OK.

## Findings por variante

### v1-scroll-container.html
- ✅ Tema `e250`, DaisyUI semántico, banner+badge de mockup presentes.
- ✅ Cubre drawer cerrado/abierto, backdrop, banda staff-mode, footer email+logout, tablet 768px (colapsa a drawer), escritorio con sidebar permanente.
- [ ] Menor/UX: a 375px la tabla de 6 columnas exige deslizar para leer cada fila; aceptable para «sin recorte» pero peor lectura en pulgar que v2 para tablas anchas. Recomendado reservarla para tablas estrechas (ver Veredicto).
- [ ] Menor (fidelidad): el enlace activo «Reservas» del drawer usa `min-h-10` sin `py-2`; en el shell real (`PanelView.vue`) los ítems usan `px-3 py-2`. Alinear el padding vertical al implementar para que el alto activo coincida con desktop (no bloqueante — el mockup ya da 40px).

### v2-stacked-cards.html (aprobada como default)
- ✅ Tema `e250`, DaisyUI semántico (`card`/`card-body`/`badge`), banner+badge de mockup presentes.
- ✅ Mismo shell y navegación que v1; tarjeta apilada por registro con pares etiqueta/valor, badge de estado, y borde `border-l-warning` para el 4xx → jerarquía clara, cero scroll lateral.
- ✅ Escritorio vuelve a tabla clásica (regresión cero).
- [ ] Menor (cobertura del mockup): la fila 3 de escritorio de v2 omite el grupo «Plataforma» que sí aparece en v1 y en el shell real (`PanelView.vue`, gated por `isPlatformAdmin`). Es sólo recorte del mockup; al implementar, el grupo Plataforma debe seguir presente cuando aplique.
- [ ] A tener en cuenta al construir: el layout dual (tabla ↔ tarjetas) es markup por vista; mantener una sola fuente de datos y alternar presentación por breakpoint (`lg:`) para no duplicar lógica.

## Veredicto

**aprobado: `v2-stacked-cards.html` (tarjetas apiladas) como técnica por defecto para las tablas densas de muchas columnas — Reservas, Logs API, Email log — y también recomendable para Experiencias y Usuarios cuando la fila tenga varios campos.**

**Mezcla explícita permitida:** usar **`v1-scroll-container.html` (scroll-en-contenedor)** para:
- tablas estrechas donde las columnas caben o casi caben a 375px (p.ej. Usuarios si son pocas columnas),
- tablas embebidas en modales/diálogos (editor de experiencias, embed) donde reordenar a tarjetas complica el diálogo.

El contrato exige «sin recorte», no una técnica única (Notas/decisiones del `.md`): ambas cumplen; el criterio de elección por vista es la **densidad de columnas y la legibilidad en pulgar**. Al implementar por TDD (`build-frontend`), decidir la técnica vista a vista siguiendo esta regla, manteniendo el shell/drawer de navegación idéntico entre ambas (no está a debate).