# review-mockup — E250-C0107

**Aprobada:** `v2-member-radio.html`
**Motivo:** para una acción de alto impacto como transferir la propiedad, la lista de
miembros con email + rol actual hace inequívoco *quién* será el nuevo owner y refuerza el
invariante "el destino debe ser una membresía existente" mostrando sólo miembros; además
sus tarjetas-radio (`rounded-lg border p-*`) reflejan el mismo lenguaje visual que las
filas de membresía del propio modal de edición, así que encaja mejor con la superficie
real que un `select` suelto. v1 es correcta y más compacta (consistente con el diálogo
"Mover…" existente), pero enuncia peor la consecuencia y oculta el rol del destino.

Ambas variantes cubren los tres cambios de UI del contrato:
1. El selector de rol de la membresía no-owner ofrece sólo `admin`/`editor`/`viewer` — `owner` desaparece.
2. La membresía owner muestra el rol bloqueado (badge `owner 👑`) + botón explícito "Transferir propiedad…".
3. Confirmación previa con la consecuencia enunciada (el owner actual pasa a admin, quién será el nuevo owner, un solo owner).

Tema `e250` real inyectado inline (OKLCH derivadas de `tailwind.config.js`), banner "MOCKUP ESTÁTICO" sticky y comentario de cabecera presentes en ambas. DaisyUI semántico (`modal`, `card`, `badge`, `alert alert-warning`, `select`, `radio`) sin CSS ajeno.

## Findings por variante

### v1-select-confirm.html
- ✅ Tema real, DaisyUI semántico, banner + comentario de mockup, alcance correcto.
- ✅ Diálogo de transferencia consistente con el "Mover…" existente (mismo `select`, `modal-box max-w-md`).
- [ ] a11y: el `<label>` del select ("Nuevo owner…") no está asociado al control (sin `for`/`id` ni `aria-label`). El resto de la vista real usa `aria-label` en los selects → replicarlo al implementar.
- [ ] El rol actual del destino no se ve hasta abrir el desplegable; la opción muestra "email · rol" sólo dentro del `<option>`, menos legible que v2.

### v2-member-radio.html (aprobada)
- ✅ Tema real, DaisyUI semántico, banner + comentario de mockup, alcance correcto.
- ✅ Lista de miembros (radio) con email + rol actual visibles y opción elegida resaltada (`ring-2 ring-primary/40`) → "quién será el nuevo owner" explícito de un vistazo.
- ✅ Labels envuelven el `input radio` (etiquetado implícito) → mejor a11y que el select de v1.
- [ ] Menor a11y: el grupo de radios no tiene `<fieldset>`/`<legend>` (ni `role="radiogroup"` con label). Envolverlo en un fieldset con legend "Nuevo owner (miembro del espacio)" al implementar.
- [ ] Menor: la frase de consecuencia omite el nombre del espacio ("…será el nuevo owner", sin «AleXplore Jetski»). El título del diálogo ya lo lleva, pero conviene mantener el espacio en la frase por claridad (como en v1).

## Notas para build-frontend (no bloqueantes)
- El botón "Transferir propiedad…" y el badge de rol bloqueado deben aparecer sólo en la fila de la membresía `owner`; las no-owner conservan `select` + Mover + Quitar.
- El destino se restringe a miembros existentes del espacio (excluido el owner actual); un email sin membresía no debe poder elegirse (coherente con el criterio de dominio del contrato).
- Un fallo de la transferencia debe mostrar mensaje accionable en el `alert alert-error` del modal, no el genérico "reintenta en unos segundos".

## Veredicto
aprobado: v2-member-radio.html (con los dos ajustes menores de a11y: fieldset/legend en la lista de radios y aria-label; y añadir el nombre del espacio a la frase de consecuencia)