# review-mockup — E250-C0109

**Aprobada:** `v1-reflow.html`
**Motivo:** cumple todos los criterios con superficie visual del contrato y es el **delta mínimo** sobre el `StepIndicator` real (que ya usa `flex flex-wrap gap-2` con etiquetas `hidden sm:inline`): en móvil sólo envuelve los números a dos filas. Preserva la afordancia de pasos numerados y su navegabilidad por-paso (los pasos visitados son botones `navigate` en el componente actual), coherente con la nota del contrato de que «el trabajo responsive está mayormente dentro de los pasos, no en el marco». v2 cumple igual de bien las métricas pero introduce un patrón nuevo (barra `progress` + «Paso N de 8») y **pierde la navegación por-paso en móvil** (la barra compacta no es pulsable paso a paso) — más limpio, pero mayor cambio y una capacidad menos.

## Verificación (render headless, tema `e250` vía CDN, medido con Playwright)

Ambas variantes, idénticas salvo en el StepIndicator móvil, pasan las métricas:

- **Cero scroll horizontal** a 320/375/768px: en cada marco de dispositivo el `scrollWidth` del contenido queda ≤ ancho del marco (sin desbordamiento) en las 7 superficies medidas.
- **Calendario @ 320px:** rejilla `grid-cols-7` sin desbordar; días con altura mínima **44px** (≥40px exigido), ancho de celda ~33px.
- **Steppers (`join` −/valor/+):** altura mínima **40px** (cumple).
- **Resumen / Pago @ 375px:** desglose con `min-w-0 truncate` + importe `shrink-0`, email con `break-all`, contenedor de Stripe `w-full max-w-full` sin recorte, botones `btn-block` alcanzables — sin overflow.
- **Tema real:** color primary renderizado `oklch(0.6601 0.15 153.95)` = verde `e250` (`#2eac66`), no el tema DaisyUI por defecto.
- **Coherencia con el shell real** confirmada contra el código: `max-w-2xl mx-auto`, `card bg-base-100 border border-base-300`, `card-body p-6` (los mockups lo bajan a `p-4` en móvil como solución responsive). El `CalendarStep` real usa hoy `aspect-square` + `grid-cols-7 gap-1` — exactamente el riesgo de celda diminuta a 320px que el mockup corrige con `min-h-[44px]`.

## Findings por variante

### v1-reflow.html (aprobada)
- ✅ Tema `e250`, DaisyUI semántico (`btn`, `card`, `join`, `badge`, `alert`), banner + badge «MOCKUP — no producción» presentes.
- ✅ Cero overflow y objetivos táctiles cumplidos en todas las superficies.
- [ ] **Accionable para `build-frontend` (no bloqueante):** los chips numerados del StepIndicator son `w-8 h-8` (**32px**). El criterio de Controles exige objetivo táctil ≥40px para controles interactivos en viewport <1024px, y los pasos visitados **son navegables** (botones `navigate`). El caption del propio mockup lo reconoce («los navegables ganan área táctil ≥40px con padding») pero los renderiza como spans de 32px sin ese padding. Al implementar: cuando un chip sea navegable, envolverlo en control con `min-h-[40px]`/padding que alcance ≥40px de área táctil, sin agrandar visualmente el círculo si no se desea.

### v2-compact.html (no elegida)
- ✅ Mismas métricas cumplidas; `progress progress-primary` es DaisyUI semántico; banner/badge presentes.
- ℹ️ Colapsa a «Paso N de 8 · nombre» + `progress` en móvil: cero riesgo de desbordamiento y menos altura, pero **sin navegación por-paso en móvil** (regresión de una capacidad hoy existente vía `navigable`) y patrón de progreso nuevo. Guardar como alternativa si en el futuro se prioriza altura vertical sobre navegación por-paso.

## Veredicto

aprobado: `v1-reflow.html` — con el ajuste de área táctil ≥40px para los chips navegables del StepIndicator al implementarlo por TDD.