POLIGES

Logotipo

Cinco versiones. La elección depende únicamente del fondo: texto Carbón sobre claro, texto blanco sobre oscuro. Los corchetes son siempre azul POLIGES.

logo-black.pngFondo blanco

logo-white.pngFondo Carbón

POLIGES.pngAvatar · favicon · RRSS

logo-min-black.pngSidebar · correos

logo-min-white.pngSidebar oscura · modo oscuro

✕ EvitarSobre azul se pierden los corchetes

Colores

Tres colores de marca y escalas derivadas. Los componentes nunca usan un hex directamente: consumen tokens semánticos (--primary, --surface, --border…).

Brand

Ink (neutros)

Estados

Semánticos de plataforma: mismos colores en todos los centros salvo que un centro los sobrescriba (colors.md §9.2). Escalas completas 50–950; cada estado se consume con seis tokens.

Tokens semánticos

Lo único que usan los componentes. Los valores se leen en vivo: cambian con el modo oscuro y con el tema del centro.

Contraste (WCAG 2.1)

Tema por centro

Cada centro elige sus semillas y el sistema deriva el resto con contraste garantizado (colors.md §9). Elige un preset o un color: toda la página se re-tematiza en claro y oscuro.

Derivación simplificada para la guía (OKLCH en el navegador). La aplicación resuelve y valida el tema en el servidor al guardarlo. Esta demo solo cambia la semilla primaria; neutros y estados del centro siguen las mismas reglas.

Tipografía

Instrument Sans para toda la interfaz (ya configurada en el proyecto). Archivo expandida, opcional, para titulares de la web pública por su parecido con el logotipo. Cifras siempre tabulares.

Botones

Un único componente <Button> con variantes y tamaños. Una sola acción primaria por pantalla.

Foco visible: anillo --ring de 2 px separado 2 px del botón (prueba con la tecla Tab). Con un tema de centro, todos los botones y estados de esta página cambian solos.

Formularios

Todos los campos se componen con <FormField>: etiqueta, control, ayuda y error siempre en el mismo orden y con el mismo espaciado.

Badges, alertas y avisos

El color comunica estado. Siempre acompañado de texto (nunca solo color).

Aviso persistente de incidencias

Toast, vacío y carga

Datos: KPIs, tabs y tablas

Inspirado en la captura de referencia del dashboard: superficies blancas, bordes finos, cabeceras grises suaves, tabs con contador y paginación limpia.

Tabla de reservas

Componentes de dominio

Piezas propias de POLIGES construidas sobre los componentes base: ocupación, advertencia de exceso de aforo, cuadrícula de franjas y entrada con QR.

Entrada individual

Piscina Municipal Granja

Sábado 14 de noviembre · Entrada 2 de 4

PENDINGPLG-7K3Q-9XWA

Layout del panel

Shell de admin.poliges.com: sidebar con selector de centro arriba, navegación con indicador de marca, cabecera con migas, acción «+» y menú de usuario, franja de avisos y página con título + acción primaria. Sin buscador global ni campana en el MVP. Es intercambiable: las páginas no conocen esta estructura (UI/design.md §4 y UI/components.md §5).

Regiones y medidas

Selector de centro

Dice dónde estás operando. Tarjeta en la sidebar y, al abrirla, buscador, recientes y lista agrupada por tenant. SUPERADMIN ve todos los centros en una lista única, con filtro de tenant y la entrada «Plataforma». Reglas en UI/design.md §4.8 y contrato en UI/components.md §5.7.

Disparador

Panel abierto (interactivo)

Móvil y sidebar colapsada

Dashboards

Tres composiciones de un mismo catálogo de tarjetas: cada una exige un permiso y se muestra solo si el usuario lo tiene. Plataforma, centro · gestión y centro · operativa. Reglas en UI/design.md §5.1 y piezas en UI/components.md §13.

Datos de ejemplo del Polideportivo Granja. «Hoy» es el día del centro. Sin ingresos de semana o mes ni gráficos de series: eso llega con los informes (POL-173). Las tarjetas «en vivo» se refrescan con usePoll (ocupación 15 s; próximas reservas y cobros 30 s).

Plataforma: tenants, centros y dominios

Administración estructural, exclusiva de SUPERADMIN. Es la zona de mayor impacto: las acciones de estado van siempre en un diálogo con resumen de impacto, nombre y motivo. Reglas en UI/design.md §5.2 y piezas en UI/components.md §14.

Configuración, deportes y recursos

La zona de trabajo diario de INSTITUCION: reglas del centro con herencia visible, modalidades habilitadas y pistas. Reglas en UI/design.md §5.3 y piezas en UI/components.md §15. El editor del tema está en Tema por centro.

Calendarios y tarifas

Cuándo se puede reservar y a qué precio: temporadas, perfiles de día, horas de inicio, duraciones y tarifa base con excepciones. Reglas en UI/design.md §5.4 y piezas en UI/components.md §16. Datos del ejemplo de funcional §18.3: se publica el borrador de «Pádel 2027» y, una vez publicado, cada cambio se revisa antes de aplicarse.

Reservas: listado, calendario y reserva manual

El trabajo diario de RESERVAS: buscar, ver, cobrar y cancelar, y crear reservas en taquilla. La reserva y su cobro son hechos distintos y se muestran con dos insignias. Reglas en UI/design.md §5.5 y piezas en UI/components.md §17. Ahora = martes 9/03/2027, 17:00; los precios salen del calendario de «Pádel 2027».

Control de acceso y lector QR

Validar entradas, recibir un grupo y registrar salidas definitivas. Centro activo: Polideportivo Granja. Jornada simulada: 9/03/2027. Diseño en UI/design.md §5.6; contratos en UI/components.md §18.

Ocupación y advertencias de aforo

Panel de solo lectura: cuánta gente hay, cuánto queda por vender y qué excepciones se han autorizado hoy. Comparte datos con la demo de Control de acceso: valida o registra una salida allí y vuelve aquí. Diseño en UI/design.md §5.7; contratos en UI/components.md §19.

Bloqueos e incidencias

Cerrar disponibilidad sin cancelar reservas por sorpresa: el bloqueo calcula las reservas afectadas, abre una incidencia y el personal las gestiona. Usa las reservas de la demo de Reservas: cancelar aquí se refleja allí. Cambia el rol en los controles: Bloqueos exige blocks:manage (INSTITUCION). Diseño en UI/design.md §5.8; contratos en UI/components.md §20.

Usuarios y accesos

Personal del panel (alta por invitación, alcance por centro y deporte, suspensión sin borrado), socios del centro con importación CSV y matriz de permisos. Cambia el actor en los controles: SUPERADMIN lo ve todo; INSTITUCION solo gestiona RESERVAS dentro de su ámbito. Diseño en UI/design.md §5.9; contratos en UI/components.md §21.

Pagos y caja

Caja del día de solo lectura, cobros pendientes, devoluciones y métodos de pago del centro con su pasarela. Comparte los movimientos con las demos de Reservas y Bloqueos: cobra o devuelve allí y mira aquí. Cambia el rol en los controles: RESERVAS solo ve lo suyo; la pasarela solo la edita SUPERADMIN. Diseño en UI/design.md §5.10; contratos en UI/components.md §22.

Web pública · Portada del centro

Primera pantalla de un centro: cabecera, hero, modalidades, servicios y normas, información práctica y pie. La reserva vive en páginas propias (POL-029 a POL-031). Prueba el tema del centro, el idioma, la sesión, los datos en vivo opcionales y los estados. Diseño en UI/design.md §6.2; contratos en UI/components.md §23.

Web pública · Catálogo de la modalidad

La página que hay detrás de cada tarjeta de la portada: la modalidad, el estado de cada día y sus instalaciones. Sirve para ver y elegir el día; la selección de franja o de entradas ocurre en el flujo (POL-030 y POL-031). Hay recursos inactivos y ocultos que no aparecen, una pista en mantenimiento y espacios relacionados. Diseño en UI/design.md §6.3; contratos en UI/components.md §24.

Web pública · Flujo de reserva SLOT

Cuatro pasos desde la franja hasta la confirmación: franja, datos, pago y confirmación. Hasta pulsar «Confirmar» solo existe un borrador; las reservas gratuitas o en efectivo se confirman aquí y las de tarjeta o Bizum se entregan al paso de pago (POL-207). Prueba el registro del centro, los métodos, el invitado y los errores simulados. Diseño en UI/design.md §6.4; contratos en UI/components.md §25.

Web pública · Flujo de compra de entradas

Compra de varias entradas de la piscina (día completo) o de natación (plazas por horario): día, horario, entradas por tipo, datos, pago y confirmación. Las entradas no se emiten siempre al confirmar: gratuitas al confirmar, en efectivo al cobrar en taquilla y online al confirmarse el pago. Los tipos de entrada son una dimensión nueva de la tarifa. Diseño en UI/design.md §6.5; contratos en UI/components.md §26. Las demos del panel aún no muestran los tipos.

Web pública · Acceso y cuenta

Iniciar sesión, crear cuenta, recuperar la contraseña, verificar el correo, vincular reservas de invitado y aceptar la invitación del personal. Mismas pantallas en la web de un centro (con su tema) y en el panel (marca POLIGES, sin registro libre). Cuentas de prueba: lucia@correo.es / Contrasena-2027x (web) y marta@granja.es / Panel-segura-2027 (panel). Diseño en UI/design.md §6.6; contratos en UI/components.md §27.

Web pública · Pago online y resultados

Lo que ocurre tras «Confirmar y pagar»: página de pago con cuenta atrás (hora del servidor), cambio tarjeta ↔ Bizum sin reiniciar el plazo, redirección a la pasarela y todas las pantallas de resultado: verificando, confirmado, rechazado, caducado, pago tardío con y sin franja libre, resultado incierto y reapertura del enlace. La pasarela y la notificación firmada se simulan con los controles. Diseño en UI/design.md §6.7; contratos en UI/components.md §28.

Web pública · Mi cuenta: reservas, entradas y cancelaciones

Listado con pestañas y contadores, detalle con la política y su fecha límite, cancelación según el caso (pago online, efectivo pendiente, efectivo cobrado, fuera de plazo, deshabilitada, pendiente de pago y entradas sueltas), mis entradas y «Mi cuenta» (datos, correo, contraseña, socio y solicitudes de datos). Acceso con sesión, como invitado con enlace firmado o sin sesión. Diseño en UI/design.md §6.8; contratos en UI/components.md §29.

Web pública · Entradas y códigos QR

Vista de las entradas de una reserva: QR grande, código legible, tipo, día y estado (válida hoy, otro día, dentro, salida registrada, cancelada, caducada); carrusel y lista, pantalla completa y PDF A4 simulado. Solo ver y descargar: no hay compartir. El QR es un patrón simulado y no se puede escanear; el real es POL-132. Se dibuja siempre en negro sobre blanco, también en modo oscuro. Diseño en UI/design.md §6.9; contratos en UI/components.md §30.

Responsive

Un componente, un comportamiento adaptable: la estructura cambia con el ancho del contenedor, igual que lo hará la aplicación con sm: y lg:. Móvil < 640 · tablet 640–1023 · escritorio ≥ 1024. Detalle por componente en UI/components.md §11 y reglas comunes en UI/design.md §7.

Las demos usan @container para mostrar los tres tamaños a la vez en esta página; en la aplicación los saltos son los breakpoints de Tailwind. Objetivos táctiles de 44 px en móvil y tablet, 40 px en escritorio. Los marcos de escritorio y tablet hacen scroll horizontal en pantallas estrechas.

Estados de interfaz

Toda vista define cómo se ve cargando, vacía, con error y con éxito, no solo cuando todo va bien. Reglas en UI/design.md §8; componentes en UI/components.md §12.

Carga

Vacío

Errores recuperables y parciales

Páginas de error

Retención de plaza

Formularios

Toasts

Éxito e información: 4 s. Error: hasta cerrarlo. Se pausan con foco o puntero encima. Los textos de ejemplo son orientativos; en la aplicación salen de claves de traducción.