# review-mockup — E250-C0086

**Aprobada:** `v1-tt-primary.html`
**Motivo:** única variante, y cubre los cuatro criterios con superficie visual del contrato con
fidelidad al shell real (`PanelExperiencesView.vue` + `ExperienceEditorModal.vue`): listado con N
experiencias y nombre primario = producto de TuriTop, el caso "dos experiencias sobre el mismo VT
Masca" visible, modal reordenado (TT izquierda / VT derecha / `↔`), selector TT que implica el
catálogo de ~50, y el aviso de identidad duplicada. Se aprueba **con un fix requerido**: el
`data-theme="e250"` está declarado pero **no llega a renderizar** los colores del cliente (ver F1).

## Findings por variante

### v1-tt-primary.html (aprobada)

- ✅ **Banner + badge de mockup** presentes: comentario HTML al inicio + `badge badge-warning`
  "MOCKUP — no producción · E250-C0086". Sin riesgo de confundir con código real.
- ✅ **DaisyUI semántico** — `card`, `table table-sm`, `modal modal-open`, `badge`, `alert
  alert-error`, `select select-bordered`, `divider`, `btn btn-primary`. Coincide clase por clase
  con los SFC reales; sin librería UI ajena ni CSS global improvisado (sólo `font-family` en
  `<style>`, idéntico al `tailwind.config.js` del cliente).
- ✅ **Intención del change cubierta:**
  - Listado: nombre primario = producto **TuriTop** (era VT en `PanelExperiencesView.vue`), VT
    relegado a columna secundaria. Tres filas comparten `vt_masca_01` → hace obvio "muchas
    experiencias, un VT". La fila incompleta no muestra "Código de inserción" (coherente con el
    `v-if="row.summary.complete"` real).
  - Modal: orden invertido TT-izquierda / VT-derecha con `↔`; emparejado opción→unidad con la
    misma orientación. (Nota de implementación, no de mockup: en el SFC real hoy el lado VT es el
    `badge` fijo y el TT el `select`; el mockup invierte la posición visual conservando esa
    semántica — el reorder de columnas es exactamente lo que pide el criterio.)
  - Selector TT con `optgroup` de ~50 productos, 3 marcados "ya integrado", + texto que explica
    catálogo completo vs. integrados.
  - `alert alert-error` de identidad duplicada con copy legible nombrando la experiencia en
    conflicto.
- [ ] **F1 — REQUERIDO antes de tomar el mockup como referencia visual: el tema `e250` no
  renderiza.** Verificado en navegador: `data-theme="e250"` está en `<html>`, pero
  `getComputedStyle(.btn-primary).backgroundColor` = `oklch(0.4912 0.3096 275.75)` (morado, hue
  ~275) y `--p` = `49.12% 0.3096 275.75` — **no** el verde del cliente (`#2eac66`, hue ~150). Causa:
  se carga el **prebuilt `daisyui@4.12.10/dist/full.min.css`** por CDN, que NO trae horneado el
  tema `e250`; el objeto `tailwind.config.daisyui.themes` que define el `<script>` sólo lo lee el
  pipeline de build de DaisyUI, **no** el CSS ya compilado del CDN → el tema cae al default y los
  primarios salen morados, ajenos a la marca. Fix: inyectar el tema como CSS-vars en un bloque
  `[data-theme="e250"]{ --p: …; --s: …; … }` (los tokens del `tailwind.config.js` convertidos a
  formato DaisyUI), o equivalente, para que la captura de revisión muestre el verde real. El layout,
  el copy y la estructura DaisyUI son correctos; sólo la paleta engaña.
- [ ] **F2 — Menor:** el `modal modal-open` está en flujo, así que en la captura tapa la mitad del
  listado (ambas superficies se renderizan a la vez para revisión). Es intencional y aceptable para
  un mockup estático; si se quiere una captura limpia de cada superficie, separarlas o togglear el
  `modal-open`. No bloqueante.

## Veredicto

aprobado: `v1-tt-primary.html`, condicionado al fix **F1** (cablear el tema `e250` para que los
colores rendericen en verde, no morados). F2 es menor y opcional. Layout, copy, DaisyUI semántico,
banner de mockup e intención del change: todo correcto.
