# review-mockup — E250-C0080

**Aprobada:** `v1-collapse.html`
**Motivo:** Es la variante que **resuelve** el riesgo que el propio contrato señala (varios ejemplos saturan la tarjeta): primer ejemplo siempre visible + resto tras un `collapse` DaisyUI, así la tarjeta queda compacta por defecto y el operador expande bajo demanda. v2 (stack numerado) es correcta y legible pero deja todo expandido siempre — escala mal cuando una regla acumula muchos ejemplos, que es justo el caso que el contrato pide mitigar. Ambas son de altísima fidelidad al `PanelSpecsView.vue` real y cubren los tres criterios visuales; v1 gana por la decisión de UX.

Verificadas visualmente (Playwright, chromium bundled, vía http://127.0.0.1 — `file://` está bloqueado en el MCP): v1 colapsado y expandido, v2 stack completo. Ambas renderizan con el tema `e250` real.

## Cobertura de los criterios de aceptación (ambas variantes)

- ✅ **Agrupa por Historia (título + narrativa):** sección con `border-l-4 border-primary`, badge `Historia`, título en `text-secondary` y narrativa en `text-base-content/70`. Agrupa PAN-04 y PAN-05 bajo la misma cabecera.
- ✅ **Muestra TODOS los ejemplos, no sólo el primero:** PAN-04 tiene dos ejemplos y ambas variantes exponen los dos (v1 tras el collapse, v2 en el stack numerado).
- ✅ **Degradación con gracia:** el área Reservas (SPEC-RES-01, sin Historia, un solo ejemplo) se renderiza en plano idéntico al de hoy — sin cabecera de Historia, sin numeración, sin control de expansión. PAN-05 (un solo ejemplo, dentro de Historia) también se muestra plano.

## Fidelidad al shell real (`PanelSpecsView.vue`)

Coincidencia exacta verificada contra el SFC: header (`text-lg font-semibold` + intro `text-xs` + fecha global), botonera de filtros (`btn btn-sm` primary/ghost), `input input-bordered w-full mb-6`, lista `<ol class="space-y-4">`, tarjeta `card bg-base-100 border border-base-300` con `card-body p-5`, `card-title text-base` con `badge badge-ghost` de ID + título `flex-1` + tooltip de fecha (mismo `tooltip tooltip-left` + `btn btn-ghost btn-xs btn-circle` + el SVG de calendario idéntico), y el ejemplo con `<strong>Ejemplo.</strong>`. Tema `data-theme="e250"` con los tokens reales de `tailwind.config.js`.

## Findings por variante

### v1-collapse.html (aprobada)
- ✅ Tema `e250`, DaisyUI semántico (`collapse collapse-arrow`, `card`, `badge`, `btn`, `tooltip`), banner + badge "MOCKUP — no producción" en el top, fuera del fold.
- ✅ Una regla con un solo ejemplo (PAN-05, RES-01) no muestra ningún control de expansión — correcto.
- [ ] Menor (para `build-frontend`, no bloqueante): el copy del toggle dice "Ver 1 ejemplo más" hardcodeado; en producción debe pluralizar con i18n (`Ver {n} ejemplo(s) más`) usando el conteo real de ejemplos ocultos. La cuenta es "ejemplos − 1".
- [ ] Menor: el `collapse` usa `<input type="checkbox">` (estado puramente CSS). En el SFC real conviene ligar el toggle a estado Vue/`details` accesible y exponer un `data-testid` para el control de expansión, coherente con los `data-testid` que ya usa la vista.

### v2-numbered-stack.html (no aprobada)
- ✅ Igual de fiel al shell y correcta en DaisyUI; degradación y agrupación impecables.
- [ ] No mitiga la saturación: todos los ejemplos siempre visibles → la tarjeta crece sin techo cuando una regla acumula varios ejemplos, que es precisamente el riesgo del contrato. Por eso se prefiere v1.

## Veredicto

aprobado: `v1-collapse.html` — con los dos ajustes menores no bloqueantes para `build-frontend` (pluralización i18n del label del toggle + toggle accesible con `data-testid`).