# review-mockup — E250-C0056

**Aprobada (decisión humana, vs@turitop.com — 2026-06-03):** `v1-tabla-owner.html`

> El review automático había propuesto v2 por cubrir role-awareness + modal de transferencia. **El humano prefiere v1** (tabla + matriz de permisos al pie) como base visual. Las superficies que el review marcó como huecos de v1 **no se descartan**: se pliegan en v1 durante `build-frontend` (ver «Ajustes a plegar»). El análisis comparativo se conserva abajo como contexto.

**Por qué v1:** es la variante más fiel al patrón de tabla dominante del panel (`PanelApiLogsView`/`PanelMappingView`), trae el set de `data-testid` más completo, protege la fila del owner (★ + «No editable») y ofrece la matriz de permisos al pie como referencia. Las dos superficies que le faltaban (confirmación de transferencia y role-awareness) se aportan al implementar, no exigen otra variante.

## Findings por variante

### v1-tabla-owner.html
- ✅ Shell fiel (sidebar w-60, header h-14, breadcrumb, footer email+Salir), tema `e250`, DaisyUI semántico (`card`/`table`/`dropdown`/`modal`/`badge`), banner+badge de mockup presentes.
- ✅ Set de `data-testid` el más completo de las tres: `panel-users-view`, `panel-users-table`, `panel-users-row-N`, `panel-users-add`, `panel-users-actions-N`, `panel-users-matrix`, `panel-group-administration`, `panel-nav-users`. Fila del owner protegida (★ + «No editable»). Modal de alta sin opción «Propietario» con nota explicativa.
- [ ] **Bloqueante para el contrato:** la transferencia de ownership es un simple `<a>Transferir propiedad aquí</a>` dentro del dropdown — **no hay superficie de confirmación** ni texto de que el owner actual pasa a Admin. El criterio «owner-only transfer-ownership flow that states the old owner becomes admin» queda sin mockup. Fix: añadir el modal de confirmación de v2.
- [ ] No muestra el comportamiento role-aware (es estática «vista owner»). El criterio «la UI refleja el rol» queda sin validar visualmente. Fix: tomarlo de v2.
- [ ] Menor: el dropdown ofrece «Transferir propiedad aquí» en TODAS las filas sin distinción de quién puede hacerlo; la regla owner-only no se transmite en esta vista.

### v2-role-aware-switcher.html
- ✅ Cubre role-awareness (sidebar/controles según `data-role`) y el modal de transferencia con el texto explícito «Tú (vs@turitop.com) pasarás automáticamente a **Admin**» + invariante «sólo puede haber un propietario». Alta inline sin opción «Propietario». Owner protegido. Banner+badge de mockup presentes, tema `e250`, DaisyUI semántico.
- [ ] Menor: las filas de la tabla de usuarios traen **menos `data-testid`** que v1 (faltan `panel-users-row-N`, `panel-users-actions-N`, `panel-users-add`, `panel-users-matrix`). Fix en `build-frontend`: adoptar el esquema de testids de v1.
- [ ] Menor: el `<style>` con reglas `[data-role]` y el selector de rol flotante son **andamiaje exclusivo del mockup** (lo dice NOTES.md). No debe filtrarse a producción — en el widget real la visibilidad por rol sale del store de auth, no de CSS por atributo.
- [ ] Menor: «Cambiar rol» es un botón sin desplegar; no muestra que las opciones son sólo Admin/Editor/Lector (sin «Propietario»). v1 (dropdown) y v3 (`select`) lo dejan más claro. Fix: al implementar, el control de cambio de rol debe excluir «Propietario» visiblemente.
- [ ] Menor: la matriz/leyenda de permisos de v1/v3 no está; v2 sólo lo explica en prosa dentro del `alert` de la vista de contenido. Considerar incorporar el rail de permisos de v3 como referencia (nice-to-have, no bloqueante).

### v3-tarjetas-rail.html
- ✅ Shell fiel, tema `e250`, DaisyUI semántico (`card`/`avatar`/`select`/`modal`/`badge`), banner+badge de mockup. Modal de transferencia con «Tú pasarás automáticamente a Admin». Owner en card destacada `border-secondary` sin acciones. Alta por modal sin «Propietario». Rail lateral sticky con permisos por rol (la mejor referencia de permisos de las tres). `select` de rol inline correctamente limitado a Admin/Editor/Lector.
- [ ] No demuestra role-awareness (vista owner estática) — mismo hueco que v1 frente al criterio «la UI refleja el rol».
- [ ] Menor: el botón de transferencia es un icono `⇄` sin etiqueta (sólo `title`) — pobre affordance/accesibilidad frente al «Transferir propiedad» textual de v2. Fix: etiqueta textual o `aria-label`.
- [ ] Menor: el layout en tarjetas se aparta del patrón tabla dominante del panel actual (`PanelApiLogsView`/`PanelMappingView` usan tabla); coherente pero menos consistente que v1/v2.

## Veredicto

aprobado: `v1-tabla-owner.html` (decisión humana, sobreescribe la propuesta automática de v2)

v1 es la base visual. Al implementar con `build-frontend`, plegar en v1 estos ajustes:

1. **Confirmación de transferencia (tomada de v2/v3):** la transferencia de ownership necesita una superficie de confirmación que declare explícitamente que el owner actual pasará a **Admin** y que sólo puede haber un propietario. En v1 era un simple ítem de dropdown sin confirmación — añadir el modal.
2. **Role-awareness:** v1 está dibujada «vista owner». La UI real debe reflejar el rol (la entrada «Usuarios» sólo se renderiza para owner/admin; los controles de escritura se ocultan al lector). Esto sale del store de auth y se valida en servidor (401/403); **no** del andamiaje CSS `[data-role]` de v2.
3. **«Cambiar rol» sólo Admin/Editor/Lector** (sin «Propietario»), como ya hace el dropdown de v1.
4. La matriz de permisos al pie de v1 se conserva como referencia visible.

### Ajustes del humano aplicados al mockup v1 (2026-06-03)

- **Navegación:** «Usuarios» NO va en un grupo «Administración» propio. Se coloca como **último ítem del grupo «Operación»**, y sólo se renderiza para owner/admin. (Ya aplicado en `v1-tabla-owner.html` y reflejado en el breadcrumb.)
- **Specs y logs no los edita nadie:** son secciones de sólo-lectura para todos los roles; no se menciona su edición. La fila de la matriz dice «Editar contenido (reservas, mapeo)» — sin specs/logs. El criterio de aceptación se reformuló en el contrato en términos de «operaciones de escritura» genéricas, sin enumerar specs/logs como editables.