# review-mockup — E250-C0097

**Veredicto:** `iterar` (aprobación condicionada a un fix). Las variantes son sólidas, fieles al shell real y cubren todas las superficies de spec; **hay un desajuste real vs PAN-14** (subtítulo) que debe resolverse antes de que esto sea aprobable por el humano. Con ese fix, la selección de variantes queda registrada abajo.

**Selección de variantes (una por superficie), asumido el fix de PAN-14:**
- Pantallas de entrada (a/b/d): `v1-entry-screens.html` — única variante, cumple.
- Cabecera por dato + banda staff (e/c): `v2-panel-branding-and-staff-mode.html` — única variante, cumple con el ajuste de subtítulo.
- Acción in-panel (f): **`v3b-inpanel-action-navgroup.html` (placement B)** — ver recomendación abajo.

Nota de proceso: no pude renderizar con Playwright (el navegador `chrome-for-testing` no está instalado en esta sesión). La review es a nivel de HTML + contraste con el SFC real `PanelView.vue` y el tema `e250` de `tailwind.config.js`; para un mockup estático es autoritativa. Recomiendo una pasada visual del humano antes del OK final, sobre todo el estado con banda staff (altura del shell con la banda añadida) y el dropdown de v3a.

---

## Fidelidad al shell real (verificado contra `PanelView.vue` + tema real)

Alto grado de fidelidad — nada engañaría al implementador TDD:

- **Tema:** los 12 tokens del tema `e250` de los mockups son idénticos a `packages/widget/tailwind.config.js`. `data-theme="e250"` correcto en las 4 variantes.
- **Estructura del sidebar:** `w-60`, `h-14` de header/cabecera, avatar "C" `bg-primary text-primary-content`, grupos "Operación"/"Desarrollo" con badge `DEV`, item activo `bg-primary text-primary-content font-medium`, email + "Salir" al pie. Coincide 1:1 con el SFC.
- **Testids:** el mockup añade testids nuevos coherentes (`brand-name`, `staff-mode-banner`, `global-selector-search`, `access-as-platform`, `panel-group-platform`) y respeta los existentes (`panel-group-operation/development`). Buen hand-off para TDD.
- **DaisyUI semántico:** `input input-bordered`, `btn`/`btn-ghost`/`btn-xs`, `badge badge-secondary`, `card`/`card-body`. Sin CSS global improvisado ni librería ajena.
- **Marca de mockup:** banner sticky + badge "MOCKUP — no producción" presente en las 4. Correcto.
- **Confirmado sobre el código real:** el header NO tiene menú de usuario hoy (placement A es pieza nueva); "Usuarios" se gatea con `auth.canManageUsers` (placement B reutiliza ese patrón con fidelidad); el subtítulo hoy es `t('panel.layout.title')` = "Panel de reservas" y `brand` = "El Cardón" son **literales i18n hardcodeados** — exactamente lo que PAN-14 manda dejar de cablear.

---

## Findings por superficie

### (a) Selector organization→workspace — `v1` — ✅ cumple
- Agrupado por organization, rol por-workspace mostrado ("Administrador"/"Editor"/"Visor"), ninguna sección cargada. Fiel a PAN-12/PAN-13.
- Menor: los avatares con iniciales (EC/EM/VT) — ver decisión visual 2 abajo.

### (b) Selector global de plataforma — `v1` — ✅ cumple
- Barra de búsqueda fija arriba con placeholder de filtrado, lista con `max-h-72 overflow-y-auto`, 6 espacios + contador "6 espacios · desplázate para ver más". Expresa fielmente "filtra al escribir + scroll + escala" (PAN-16).
- Badge "Plataforma" `secondary` como cabecera del selector: coherente con la señalización staff. Bien.
- Menor (no bloqueante): el search es estático (`value=""`), no filtra de verdad — es correcto para un mockup, pero el implementador debe recordar que PAN-16 exige filtrado real al escribir (criterio de aceptación). El texto de spec ya lo cubre; no es un fallo del mockup.

### (d) Pantalla "sin acceso" — `v1` — ✅ cumple
- Limpia, centrada, icono + copy de PAN-18 ("Ya no tienes acceso a ningún espacio… contacta con tu administrador") + botón "Cerrar sesión". Nunca panel en blanco. Testid `no-access` / `no-access-logout`. Correcto.

### (e) Cabecera con branding por dato — `v2` — ⚠️ un fix bloqueante
- Cabecera (`brand-name`) deriva del dato: "El Cardón" y "Volcano Teide" en los dos casos. Solo texto, sin logo/color por-workspace. Correcto para fase B.
- **[BLOQUEANTE] El subtítulo "Panel de reservas" se queda fijo.** PAN-14 y el criterio de aceptación piden que **cabecera + subtítulo + título de pestaña** deriven del nombre del organization/workspace activo. El mockup solo hace derivar la cabecera; el subtítulo sigue siendo el literal `panel.layout.title`. Esto es un desajuste de superficie visual, no un detalle de implementación: el mockup es la referencia que aprueba el humano, y hoy contradice la spec. **Ver decisión 3 abajo para el fix concreto.**
- El título de la pestaña del navegador no es superficie de mockup estático (es `document.title`), así que no se le exige al HTML — pero conviene que el implementador no lo olvide (está en criterios de aceptación).

### (c) Banda modo staff — `v2` — ✅ cumple
- Banda persistente arriba de TODO el panel (fuera del `flex` sidebar+main), `bg-secondary text-secondary-content`, texto literal de PAN-17 "Estás viendo {workspace} como plataforma" + "Salir del espacio". Claramente distinta del panel propio (el caso El Cardón no la lleva). Testid `staff-mode-banner`. Correcto.
- El caso auto-skip de PAN-16 (platform-admin entra directo al único workspace sin selector) está **cubierto conceptualmente**: la banda vive en el shell, no en el flujo de selección, así que aplica igual. Ver decisión 4.

### (f) Acción in-panel — `v3a` (A) vs `v3b` (B) — ambas válidas; recomiendo B
- Ambas gatean la acción a `platform_admin` y abren el selector global. Ambas fieles al shell. Ver recomendación de placement abajo.
- v3a: el dropdown muestra "Operando: El Cardón · Administrador" — buen detalle de contexto. Introduce menú de usuario (pieza de header nueva).
- v3b: grupo "Plataforma" con badge `STAFF` `secondary`, paralelo a Operación/Desarrollo; reutiliza el patrón de grupo + el gate de rol ya existente.

---

## Recomendación de placement (f): **B — grupo "Plataforma" en el sidebar**

Razones, en orden de peso:

1. **Encaje con el shell existente y patrón de rol ya probado.** El sidebar YA renderiza grupos condicionados por rol: "Usuarios" aparece solo si `auth.canManageUsers`. Un grupo "Plataforma" gateado por el flag `platform_admin` es el **mismo patrón** (`v-if` sobre un computed del auth store), con cero piezas de layout nuevas. El implementador TDD extiende una estructura que ya existe y ya está testeada, en vez de introducir un componente de header nuevo (menú de usuario) que hoy no existe — confirmado leyendo `PanelView.vue`: el header solo tiene el breadcrumb.
2. **Coste/superficie.** A obliga a diseñar, montar y testear un dropdown de usuario nuevo (foco, cierre al click-fuera, aria), más el reparto de qué acciones de cuenta viven ahí (hoy el logout vive al pie del sidebar — A duplicaría la noción de "acciones de identidad" en dos sitios). B añade un `<div>` de grupo.
3. **Descubribilidad para un flujo de soporte.** La acción es de uso frecuente para el staff (dar soporte a clientes); un grupo permanente en el sidebar es más descubrible que una entrada enterrada tras un dropdown.

**Contraargumento honesto (a favor de A):** si el producto prevé **más** acciones de cuenta (cambiar de workspace propio en caliente —hoy fuera de alcance pero mencionado como deuda—, preferencias, perfil), un menú de usuario es el hogar estándar y evita inflar el sidebar con acciones que no son navegación. B tiene la impureza semántica de meter una *acción* (abrir un selector) entre *ítems de navegación*. Si el humano ve ese roadmap de cuenta cerca, A gana a medio plazo.

**Mi recomendación:** **B para este change.** El alcance actual es una sola acción staff; B es el menor delta sobre el shell, reutiliza el gate de rol probado, y es lo que mejor cubre el criterio "visible ONLY to platform_admin" con el patrón existente. Si/cuando aparezca una segunda acción de cuenta, migrar a A es un refactor acotado. Dejar A como plan B documentado.

---

## Las 4 decisiones visuales abiertas — mi recomendación

**1. Color de la banda staff: `secondary` (verde) vs `warning` (naranja).**
Recomiendo **`secondary` (verde), como está.** Razón: PAN-17 pide un indicador "distinguible de su panel propio", no una alarma de peligro. El acceso staff es una operación legítima y auditada, no un estado de error; teñirla de naranja `warning` la lee como "algo va mal" y genera fatiga de alarma en un equipo que hará esto a diario. El verde `secondary` (verde oscuro de marca, distinto del `primary` del item activo) ya contrasta con el panel propio sin gritar. **Matiz:** el naranja tiene un argumento real —"estás tocando datos de un cliente ajeno, ten cuidado"—; si el humano prioriza esa cautela sobre la fatiga, `warning` es defendible. No es bloqueante en ninguno de los dos sentidos; es una decisión de tono que el humano cierra. Mi voto: verde.

**2. Iniciales-avatar en los selectores vs lista solo-texto.**
Recomiendo **quitar los avatares de iniciales y dejar lista solo-texto** (o degradarlos a algo inequívocamente no-branding). Razón: fase B es explícitamente "solo texto, sin logo ni colores por-workspace". Los avatares actuales usan colores del tema variados por-fila (`bg-primary/10`, `bg-accent/10`, `bg-secondary/10`, `bg-info/10`, `bg-warning/10`, `bg-success/10`) — eso **parece** color por-workspace aunque no lo sea, y arriesga que el implementador (o el cliente) lo lea como "branding por espacio ya implementado", contradiciendo el alcance. Es exactamente el tipo de ambigüedad que un mockop aprobado no debe dejar. Si se quiere conservar escaneabilidad, un único color neutro para todas las iniciales (p.ej. `bg-base-300 text-base-content/60`) elimina la señal de "color por workspace". **Este es un fix recomendado, no solo una opinión** — el multicolor actual roza el fuera-de-alcance.

**3. Subtítulo de PAN-14: ¿deriva del workspace o se queda "Panel de reservas"?**
**Debe derivar del dato** — es el fix bloqueante. La spec (PAN-14 + criterio de aceptación) enumera literalmente "**cabecera** (arriba-izquierda), **título de la pestaña** y **subtítulo**" como los tres que dejan de ser literales i18n. El mockup deriva solo la cabecera. Fix concreto para el mockup v2: que el subtítulo muestre el nombre del **organization** cuando difiere del workspace (jerarquía "El Cardón" / "El Cardón S.L." o "Volcano Teide" / su organization), o —si se quiere mantener "Panel de reservas" como descriptor funcional— **hay que corregir la spec/contrato**, no el mockup. Dado que la instrucción es no editar el contrato, la lectura fiel es: el mockup debe mostrar el subtítulo derivado del dato. Sugerencia editorial: subtítulo = nombre del organization (línea principal = workspace), lo que da una jerarquía útil ("Volcano Teide" / "Teide, S.A.") y satisface "deriva del dato" sin inventar branding gráfico. El humano confirma la fuente exacta (organization vs slug vs tipo de espacio), pero **quedarse en el literal fijo no es opción** sin tocar la spec.

**4. ¿El caso auto-skip de PAN-16 lleva banda? — Confirmado: sí, y está cubierto.**
El auto-skip (platform-admin con 0 membresías entra directo al único workspace del sistema, sin selector) es acceso a un workspace **ajeno** → PAN-17 aplica: lleva banda staff y fila de auditoría. El mockup lo cubre correctamente **por construcción**: la banda vive en el shell del panel (`v2`), no en el flujo de selección, así que se muestra independientemente de si hubo selector o auto-skip. La `NOTES.md` decisión 2 lo documenta bien. No requiere mockup adicional. **Único apunte para el implementador (no es fallo de mockup):** el gate de la banda debe ser "workspace activo ∉ membresías del usuario", no "el usuario pasó por el selector" — si se cableara al paso por selector, el auto-skip perdería la banda. Vale la pena una nota o un test explícito del caso auto-skip; el mockup ya asume la semántica correcta.

---

## Qué debe corregir `build-mockup` antes de re-revisar (para pasar de `iterar` a `aprobado`)

1. **[BLOQUEANTE] Subtítulo por dato en v2 (decisión 3).** El subtítulo debe derivar del organization/workspace activo, no quedarse en "Panel de reservas" fijo. Es un desajuste directo con PAN-14. Aplicar en los dos casos (El Cardón y Volcano Teide) y, coherentemente, en v3a/v3b (que también muestran el subtítulo fijo).
2. **[RECOMENDADO fuerte] Neutralizar los avatares de color en los selectores (decisión 2).** El multicolor por-fila sugiere branding por-workspace, que está fuera de alcance en fase B. Un color neutro único, o lista solo-texto.

Con (1) resuelto y (2) aplicado, el veredicto pasa a **aprobado**: `v1-entry-screens.html`, `v2-panel-branding-and-staff-mode.html` y `v3b-inpanel-action-navgroup.html` (placement B). El color de banda (decisión 1) queda como elección de tono del humano — no bloquea.