senzapaura_es/docs/auditoria-visual-2026-09-14.md

Auditoría visual de Senza Paura — 14 de septiembre de 2026

Dictamen

El sistema visual no está normalizado por función. El diseño no se considera cerrado.

La centralización de variables ha reducido los valores dispersos, pero no ha creado un contrato efectivo entre los componentes. Hay diferencias de comportamiento entre tablas equivalentes, alturas incompatibles dentro de una misma fila de acciones, pesos heredados y una jerarquía administrativa demasiado plana. Estudio necesita una revisión de su estructura visual, además de la corrección de sus controles.

La valoración anterior de «cierre y pulido» era demasiado optimista para el estado del diseño. Las pruebas funcionales y el uso de tokens no acreditan coherencia visual.

Esta auditoría registra el estado del commit 1e24c87, anterior a las correcciones. La implementación y su comprobación posterior se recogen en Correcciones visuales. Las capturas de este documento se conservan como evidencia del estado inicial.

Evidencia y cobertura

Inspección en navegador del código local, con la web conectada a su base configurada y Estudio al esquema de pruebas existente estudio_pruebas_20260911_nuevo. No se han creado contenidos, publicado fichas, enviado formularios ni alterado el catálogo. Se ha utilizado el acceso de prueba existente.

Superficie	Revisión realizada
Portada	Vista de escritorio del carrusel, detenido en la diapositiva del taller
Música	Tarjetas y tablas; claro y oscuro en escritorio; tablas en móvil
Álbum	Cupido sin flechas: cabecera, acciones y tabla de temas
Canción	Ámame esta noche, nada más: cabecera, acciones, letra y ficha lateral
Blog	Índice, buscador, etiquetas y tarjetas
Taller	Índice, navegación lateral y jerarquía editorial
Intérpretes	Directorio y tarjetas
Suscripciones	Cabeceras y tarjetas de planes; no contratación
Juke-box	Hero público y sus dos acciones; no editor autenticado
Contacto	Diálogo abierto desde el pie, campos, foco y acción principal
Estudio	Acceso, inicio, listado de canciones, creación, ficha existente, revisión de publicación, pedidos y medios
Estudio móvil	Ficha existente a 390 × 844
Panel anterior	Lectura de código del layout; no revisión autenticada en navegador

Escritorio: 1280 × 720 y 1280 × 900 según la captura. Móvil: 390 × 844. Las dimensiones se comprobaron en el navegador. Estudio se revisó en su presentación oscura actual; no dispone del selector de tema de la web.

Las capturas y mediciones están en la carpeta de evidencias. Los JSON contienen estilos calculados y geometría; son inventarios, no informes de accesibilidad. También pueden incluir elementos fuera del viewport, ocultos mediante recorte o transformados por la animación de entrada. Las medidas citadas a continuación corresponden a los controles principales inspeccionados, no a esos elementos auxiliares.

No quedan certificados todos los estados de todas las rutas: faltan, entre otros, el panel anterior autenticado, el editor Jukebox, cuenta/biblioteca, el reproductor activo, errores de validación exhaustivos y la matriz completa de móvil/tableta/temas. Esto no reduce la validez de los fallos reproducidos; impide llamar a este informe una aprobación visual integral.

Hallazgos prioritarios

P1 significa que debe resolverse antes de aprobar el sistema visual. P2 significa coherencia o composición que debe corregirse dentro del mismo trabajo de diseño. No son clasificaciones de seguridad.

V01 · P1 · Álbumes y canciones tienen dos patrones de reproducción en tabla

Álbumes conserva una celda exclusiva para Play antes de la portada. Canciones superpone Play sobre la portada y lo muestra con interacción, foco o reproducción. Las portadas y los títulos empiezan en posiciones distintas y la misma acción se busca en dos lugares.

Origen: src/lib/components/TablaAlbumes.svelte:29 y :41; src/lib/components/TablaCanciones.svelte:255 y :349. TablaCatalogo comparte la envoltura, pero no la composición de la fila.

Corrección: compartir una celda de portada/reproducción. Mantener el comportamiento de canciones en ambos listados, con acción visible en táctil y accesible con teclado. La portada no debe cambiar de tamaño al pasar de Play a Pausa.

V02 · P1 · Las acciones de una misma canción tienen alturas diferentes

En la ficha, «Escuchar completa» mide 44 px y «Añadir al carrito» 50,75 px. Ambos tienen texto de 15 px y están juntos. El primero usa interlineado de 15 px; el segundo hereda 24,75 px. El relleno se suma de forma distinta.

Origen: BotonReproducir.svelte:111 y BotonCarrito.svelte:57. Evidencia: web-cancion-medidas.json y web-cancion-claro.jpg.

Corrección: una base geométrica de botón compartida. Dos acciones del mismo tamaño deben tener la misma altura, interlineado, radio y alineación de icono, independientemente del componente que las renderice.

V03 · P1 · El tamaño declarado no coincide con el tamaño final de Estudio

.boton declara mínimo de 44 px, pero 24 px de línea + 24 px de relleno vertical + 2 px de borde producen 50 px. .boton.pequeno declara mínimo de 36 px, pero su línea y relleno producen 42 px. El botón de búsqueda de la cabecera usa un glifo de 24 px y alcanza 52 px de altura.

Origen: src/estudio/estudio.css:94 y :125; barra superior en src/estudio/rutas/(dentro)/+layout.svelte. Evidencia: estudio-canciones-medidas.json.

Corrección: definir tamaños reales, con interlineado explícito y relleno compatible. Un token de min-height por sí solo no establece el tamaño.

V04 · P1 · Estudio aplana funciones distintas a 16 px

Ayudas, small, antetítulos, estados, migas, encabezados de tabla y botones pequeños usan --fs-base. Las cabeceras de tabla añaden mayúsculas y peso 600; los valores, estados y explicaciones ocupan casi el mismo nivel. Se obliga a distinguir la información por posición en lugar de por jerarquía.

Origen: estudio.css:84, :87, :160, :289 y :354.

Corrección: asignar roles completos a metadatos, etiquetas de campo, valores, títulos de registro, sección y página. La normalización debe conservar diferencias funcionales.

V05 · P1 · Los campos heredan negrita de sus etiquetas

El título de una ficha y el buscador de Medios se presentan con peso 600. El buscador de Canciones usa 400. En Medios también se ve la diferencia en el placeholder. La apariencia depende de si el control está envuelto en un label.

Origen: estudio.css:25 (font: inherit) y :209 (label con peso 600); solo textarea restablece explícitamente el peso.

Corrección: separar el estilo de la etiqueta del estilo del valor. Inputs, selects, textareas y placeholders deben tener peso explícito; preferentemente 400 para la entrada.

V06 · P1 · Hay pesos e interlineados efectivos fuera del contrato

El H1 de Estudio calcula 34/51 px y peso 600. Sus H2 calculan 24/36 px y peso 700 heredado de las reglas del navegador. En la web los títulos editoriales sí reciben peso 400 e interlineado 1,1. El problema no es que una página editorial y una pantalla administrativa tengan títulos distintos: es que esa diferencia no está definida por un rol y parte del resultado queda en manos de la herencia.

Origen: estudio.css:57–76. Evidencia: estudio-ficha-medidas.json.

Corrección: declarar familia, tamaño, peso e interlineado de todos los roles de encabezado; no depender de los valores predeterminados de h2, h3 o strong.

V07 · P1 · Conviven varias bases de botón

La web utiliza .btn, botones musicales .boton y estilos locales. Estudio define otra .boton: texto de 16 px/600 y primario dorado plano, frente a 15 px/400 en acciones públicas. Los formularios públicos cambian el primario a navy/celeste según el tema mediante selectores dependientes de sus ancestros. El componente y su ubicación deciden la apariencia.

Origen: src/app.css:453, :545, :665; estudio.css:94; componentes BotonCarrito, BotonReproducir, favoritos y listas.

Corrección: una base compartida y variantes explícitas por importancia y contexto. La excepción del Play dorado puede conservarse, pero tiene que ser deliberada. Mover un botón dentro de un formulario no debe cambiar su diseño accidentalmente.

V08 · P1 · El editor dedica casi toda la primera pantalla a su cabecera

En escritorio a 720 px de alto, el primer campo queda al borde inferior tras cabecera global, aviso de entorno, migas, antetítulo, título, estado, caja de publicación y pestañas. En móvil a 844 px apenas empieza «Datos de la ficha». Se repiten el estado y las explicaciones de publicación.

Origen: layout de Estudio y src/estudio/rutas/(dentro)/[tipo]/[id]/+page.svelte. Evidencia: estudio-ficha-oscuro.jpg y estudio-ficha-movil.jpg.

Corrección: cabecera de editor compacta con título, un estado y acciones; agrupar ayudas secundarias y hacerlas desplegables. El primer campo útil debe quedar visible en la primera pantalla normal de edición. Validar con títulos largos y avisos reales.

Otros hallazgos de coherencia

ID	Prioridad	Evidencia y efecto	Corrección verificable
V09	P2	Inicio de Estudio: «Ver todas» queda junto a «Crear canción», pero debajo de las otras acciones; los títulos largos desplazan el contenido. estudio-inicio-oscuro.jpg; src/estudio/rutas/(dentro)/+page.svelte:31.	Tarjetas con las mismas filas internas y acciones ancladas abajo. Comprobar nombres de una y dos líneas.
V10	P2	Navegación de Estudio a 19 px, frente a texto principal de 16 px. Nombres partidos y menú con scroll propio; el menú compite con el trabajo. +layout.svelte:205.	Navegación utilitaria a 14–15 px, grupos secundarios y áreas táctiles suficientes, sin aumentar el texto para aumentar el área pulsable.
V11	P2	Los estados Publicado y Retirado comparten colores; Borrador y la selección de navegación usan el mismo dorado que las acciones. estudio.css:178–189.	Separar tokens de estado, selección y acción; conservar etiqueta e icono además del color.
V12	P2	La tabla de Canciones ofrece filtros sin etiquetas visibles y botón Buscar; Medios muestra etiquetas y filtrado con otro patrón. Sus inputs también difieren de peso. estudio-canciones-oscuro.jpg, estudio-medios.jpg.	Barra de filtros compartida, con la misma posición de etiquetas y una regla explícita de aplicación de filtros.
V13	P2	En Medios hay imágenes rotas que muestran icono del navegador y nombre de archivo; el audio usa el control nativo gris. Los archivos pertenecen a pruebas: no se atribuye su ausencia a producción.	Estado visual definido para archivo ausente/no disponible; contenedor y densidad comunes para vistas previas. Usar audio nativo puede ser válido si se integra deliberadamente.
V14	P2	En móvil, Música conserva la instrucción «de la izquierda» aunque los filtros estén en un botón superior. La primera portada aparece casi al final de la pantalla. web-tablas-movil.jpg.	Texto neutral respecto a la posición, introducción más breve y separación vertical adaptada a exploración móvil.
V15	P2	Estudio mezcla glifos de texto (⌕, ⌂, ＋, ↗, ♫) con el sistema SVG de la web; cambian tamaño óptico y alineación.	Mismo componente de icono, cajas de 16/20 px por tamaño de control y una línea base común.
V16	P2	Los títulos de tarjetas musicales usan 24 px en álbumes y 19 px en canciones; los metadatos usan 14 frente a 12 px. La excepción no viene dada por un tipo compartido de tarjeta. TarjetaAlbum.svelte:101, TarjetaCancion.svelte:123.	Definir tarjeta normal/compacta por contexto. Un tipo de contenido no debe introducir su propia escala sin una razón de densidad documentada.
V17	P1	node scripts/auditar-estilos.mjs --strict termina con código 0 y «0 infracciones», mientras V01–V08 están presentes. El análisis no calcula cascada, herencia ni medidas reales y no compara funciones equivalentes.	Mantenerlo como control estático; añadir comprobación de estilos calculados y revisión visual de una galería de componentes. No usar su resultado como aprobación del diseño.

Qué conservar y qué no confundir con un fallo

Las familias Archivo y Newsreader y la base marino/dorado proporcionan una identidad reconocible. Las cabeceras de Música, Blog y Taller comparten ya 48 px/400; las tablas de canciones integran la reproducción en la portada y contemplan foco y táctil. Las tarjetas de intérpretes alinean sus acciones inferiores mejor que las del inicio de Estudio.

Un hero editorial puede tener una escala distinta de un editor. La marca puede aparecer en serif mientras la administración utiliza una jerarquía utilitaria. La normalización no exige igualar todos los encabezados HTML, sino dar el mismo tratamiento a las funciones equivalentes y documentar las excepciones.

Contrato propuesto para la corrección

Propuesta de trabajo, todavía no aplicada. Usar los tokens primitivos existentes como base; añadir roles que agrupen familia, tamaño, peso e interlineado. Evitar que cada pantalla seleccione estas cuatro propiedades de forma independiente.

Tipografía por función

Función	Familia	Tamaño / interlineado	Peso
Título de página editorial	Newsreader	48/53 escritorio; 34/39 móvil	400
Hero de marca	Newsreader	Escala fluida propia y acotada	400
Título de página administrativa	Archivo	28/34 escritorio; 24/30 móvil	600
Sección editorial	Newsreader	34/38	400
Sección administrativa / tarjeta de gestión	Archivo	20/26	600
Panel auxiliar / diálogo compacto	Archivo	18/24	600
Título de registro o tarjeta compacta	Archivo	16/22	500
Texto de lectura	Según contexto editorial	16–19, línea 1,6–1,7	400
Valor de formulario	Archivo	16/24	400
Etiqueta de campo, navegación y dato de tabla	Archivo	14/20	500 para etiqueta; 400 para valor
Ayuda y metadatos	Archivo	13/18	400
Antetítulo y cabecera de tabla	Archivo	12/16	500

La elección de Archivo para títulos administrativos es una propuesta de dirección, no un defecto objetivo de Newsreader. Debe validarse en el conjunto antes de extenderla.

Botones y controles

Tamaño	Altura final normal	Texto	Icono	Uso
Compacto	36 px	14/20, peso 500	16 px	Tablas, herramientas y tarjetas densas
Normal	44 px	14/20, peso 500	20 px	Formularios y acciones de página
Destacado	48 px	16/22, peso 500	20 px	CTA de hero cuando lo justifique el contexto

Radio compartido de 6 px; relleno horizontal según tamaño; borde incluido en el cálculo. En táctil, asegurar una zona de interacción de al menos 44 px sin agrandar necesariamente el símbolo. Con ampliación de texto, permitir crecimiento accesible en lugar de cortar las etiquetas para mantener una altura rígida.

Variantes explícitas: primaria, secundaria, discreta, destructiva y reproducción de marca. Todas deben definir reposo, hover, foco, pulsado, deshabilitado y carga. El estado de carga conserva el ancho y la alineación. Los segmentos seleccionados y las etiquetas informativas no heredan automáticamente el tratamiento del botón primario.

Orden de implementación y aceptación

1. Base y galería: crear una página local de referencia con roles tipográficos, botones, campos, estados, tablas y tarjetas. Mostrar juntos los equivalentes de web y Estudio. Revisar el resultado renderizado antes de migrar pantallas.
2. Estudio: corregir herencia y encabezados, tamaños reales de controles, navegación, filtros, tarjetas de inicio y cabecera del editor. Resolver V03–V12 y V15 con una matriz de listado/edición/diálogo/vacío.
3. Catálogo y fichas: compartir celda de reproducción, base de botones y tarjetas. Resolver V01, V02 y V16 con Play/Pausa, foco, táctil y títulos largos.
4. Resto público: aplicar los roles a formulario, navegación, blog, taller, planes y Jukebox; conservar las excepciones editoriales justificadas. Revisar V14 y los estados no cubiertos.
5. Cierre visual: capturas comparables a 390, 768, 1024 y 1440 px, ambos temas donde existan; teclado, carga, error y vacío. Comparar estilos calculados además de imágenes. La ausencia de overflow o de errores de Svelte no sustituye esta revisión.

La aprobación exige que las acciones equivalentes compartan geometría, que no aparezcan pesos accidentales, que los valores de formulario no hereden el énfasis de sus etiquetas y que la tarea principal sea visible sin atravesar bloques repetidos de explicación. El diseño permanece pendiente de corrección y validación visual hasta entonces.