metis-desk/docs/auditoria-ui-ux-visual.md

Auditoría UI/UX visual de Metis Desk

Fecha: 21 de octubre de 2026. Referencia del repositorio: 9b33631.

Auditoría diagnóstica sobre Chromium headless mediante Playwright MCP. No se han modificado componentes, estilos, código de negocio, dependencias ni packages/shadcn-ui. Este documento no constituye una certificación de accesibilidad.

1. Resumen ejecutivo

La aplicación tiene una base visual reconocible y bastante consistente: navegación por compañía, cabeceras con iconos, tablas con acciones explícitas, formularios modales, secciones plegables y ficha de activo con Información e Historial. Conviene corregir sus puntos débiles extendiendo los componentes existentes de @repo/rdx-ui, sin incorporar otro sistema de diseño.

Las prioridades observadas son:

1. Recuperar espacio útil en móvil y tablet: la navegación precede al contenido con una altura excesiva en móvil; en 768 px las dos barras laterales dejan unos 251 px para trabajar.
2. Corregir el contraste del enlace del activo sobre la fila seleccionada: aproximadamente 2,68:1.
3. Estabilizar los asistentes de activos y recursos: su ventana cambia de altura entre pasos, aunque el patrón documentado exige estabilidad.
4. Reducir el espacio que consumen la ayuda y el progreso en modales pequeños, conservando la ayuda junto al pie.
5. Conservar la ordenación al volver de una ficha y devolver el foco al disparador al cerrar el alta de activo mediante Escape.

También se confirman dificultades menores de búsqueda sin tildes, selección entre muchas columnas y textos demasiado largos en cabeceras de revisión.

La cobertura funcional está limitada por los datos disponibles: una compañía y un portátil, sin personas, sedes, puestos, perfiles ni recursos registrados. Se han inspeccionado esas pantallas vacías y sus formularios disponibles; no se han validado sus fichas pobladas, relaciones reales ni guardados satisfactorios.

2. Alcance, preparación y método

Entorno realmente utilizado

• Se comprobó que no existía una sesión desechable activa. El usuario autorizó expresamente una única ejecución de python3 scripts/visual-audit.py.
• Se reutilizó la sesión privada producida por esa ejecución durante toda la auditoría. No se crearon otros entornos de aplicación ni usuarios adicionales a los del preparador.
• La preparación verificó el formulario real de acceso, la identidad de usuario ordinario, el rechazo de administración de usuarios, el listado, la ficha, un diálogo cancelado y la reutilización de sesión desde otro contenedor MCP.
• Compañía: «Auditoría visual — Datos sintéticos». Activo: AUDIT-PORT-01, plantilla Portátil, operativo, sin sede ni puesto.
• Playwright MCP Docker fijado en .codex/config.toml: distribución v0.0.83, digest sha256:690763cbb437ee7233f538a953bb5390bf03791eb5c965b471e59d17a6132fcb.
• Se utilizó el cliente stdio del comprobador existente para invocar las herramientas reales de MCP. En esta sesión de agente no estaban expuestas directamente como herramientas de navegador. No se atribuye esta prueba a una carga nueva de herramientas en la extensión o Desktop de Codex.
• Servicios de desarrollo y base aislados, con puertos efímeros; no se accedió a datos de compañías reales. Las rutas de este documento omiten el origen temporal.

Las capturas son de viewport, en píxeles CSS. Se combinaron navegación, snapshots accesibles, geometría DOM, teclado, estado de controles y revisión de PNG abiertos explícitamente. Las comprobaciones de red se describen como simulaciones y no como fallos espontáneos del servidor.

Fuentes y skills consultadas

Se consultaron AGENTS.md, patrón de diálogos, patrón de listados, componentes de interfaz, rutas del cliente y procedimiento Playwright. No se localizó un DESIGN.md del proyecto.

Skill leída	Ruta	Aplicación en esta auditoría
frontend-design	.agents/skills/frontend-design/SKILL.md	Jerarquía, tipografía, espacio, claridad de acciones, densidad y revisión mediante capturas. Sus recomendaciones estéticas se subordinan al producto empresarial existente.
shadcn	.agents/skills/shadcn/SKILL.md	Composición, controles semánticos, títulos de modales, validación, tokens y diferencias Base UI/Radix. Se consultaron las referencias de formularios y Base UI.
vercel-composition-patterns	.agents/skills/vercel-composition-patterns/SKILL.md	Recomendaciones de reutilización por responsabilidad y composición; referencia sobre proliferación de props booleanas.
vercel-react-best-practices	.agents/skills/vercel-react-best-practices/SKILL.md	Separación entre estado derivado y persistente, consultas y riesgos de volumen; referencia sobre estado derivado sin efectos. No se trasladan recomendaciones de Next.js a Vite automáticamente.

ui-ux-pro-max y web-design-guidelines no estaban disponibles. No se instalaron skills ni bibliotecas. La pauta genérica de evitar mayúsculas no sustituye el FormSectionTitle normativo; tampoco se propone sustituir los wrappers propios por otro catálogo de componentes.

Revisiones anteriores

Se contrastaron los hallazgos recuperables del contexto de las auditorías anteriores. No se localizaron los dos informes UI/UX originales como archivos versionados; los documentos de auditoría existentes en docs tratan infraestructura, UniFi, cliente o auditoría centralizada. La comparación de la sección 6 no pretende reconstruir contenidos ausentes ni garantizar trazabilidad exhaustiva contra esos dos originales.

3. Matriz de pantallas y resoluciones

Leyenda: M = navegación y medición del layout mediante MCP; C = además se conserva captura. Una C no significa ausencia de problemas. Se priorizaron imágenes de escritorio, anchuras estrechas y escenarios con incidencias. Las imágenes citadas en los hallazgos se abrieron para su inspección.

Pantalla	1920×1080	1440×900	1366×768	1024×768	768×1024	390×844	320×640
Dashboard	M	C	M	C	M	C	C
Compañías	M	C	M	C	M	C	C
Resumen de compañía	M	C	M	C	M	C	C
Listado de activos	C	C	C	C	C	C	C
Ficha de activo, Información	M	C	M	C	M	C	C
Personas, vacío	M	C	M	C	M	C	C
Puestos, vacío	M	C	M	C	M	C	C
Recursos, vacío	M	C	M	C	M	C	C
Catálogo global de activos	M	C	M	C	M	C	C

Son 63 combinaciones de pantalla y tamaño en la matriz principal. La segunda pasada esperó a las fuentes y a las animaciones finitas tras redimensionar, para evitar interpretar geometría transitoria como un defecto.

Cobertura adicional:

Área	Comprobación ejecutada	Límite
Panel lateral de activo	Apertura por celda, escritorio 1920/1440/1366/1100; paso a diálogo compacto en 1024; apertura móvil en 390	Un único activo, sin interfaces o conexiones registradas
Alta de activo	Pasos 1–3, plantilla Portátil; capturas de cada paso en 1440	Sin guardado positivo
Alta de recurso	Pasos 1–3, plantilla Aplicación; capturas de cada paso en 1440	Sin recurso creado
Alta de puesto	Paso 1 en escritorio y móvil; medición estable en 1440/1366/1024/768/390/320	Sin sedes: no se avanzó a pasos 2–4
Alta de perfil	Paso 1 y selector de puestos, búsqueda enfocada, Tab/Shift+Tab/Escape	Sin puestos: no se avanzó a pasos 2–4
Nueva compañía, persona y activo; editar activo	Apertura y cancelación; capturas en 1440/1366/390/320	No todos los campos o condiciones posibles
Editor de plantilla de activo	Portátil global: apertura, títulos, contadores y filas; apertura nueva en 320	No se guardó ni probó reordenación persistida
Catálogo de recursos	Listado de compañía con nueve plantillas en 1440	No se abrió su editor de plantilla en esta auditoría
Infraestructura, sedes, departamentos	Pantallas vacías en 1440	Sin fichas pobladas
Cuentas y accesos	Pantalla inicial Cuentas en 1440	No se recorrieron todas las subpestañas ni sus formularios
Carpetas, aplicaciones, impresoras, certificados, correo	Listados de configuración vacíos en 1440	Sin permisos, cuentas, publicaciones ni perfiles relacionados
Accesos remotos, teletrabajo, procesos	Listados vacíos en 1440	Sin recorridos de detalle o ejecución
Administración de usuarios	Ruta /settings/users: acceso denegado al usuario ordinario	No se auditó su interfaz administrativa

No se auditó cada ruta existente ni cada combinación de campos. Las resoluciones son viewports de Chromium de escritorio: no equivalen a dispositivos táctiles reales, Safari, teclado virtual o pruebas de orientación en hardware.

4. Evaluación visual y funcional

Lo que funciona en los escenarios ejecutados

• Las cabeceras de entidades mantienen icono, título y acción reconocibles; las tablas conservan bandas de búsqueda, controles, resultados y paginación.
• Activos distingue «sin resultados para estos criterios» del listado poblado. Los demás listados muestran mensajes de ausencia de registros sin inventar datos.
• El nombre del activo abre su ficha y esta ofrece Información e Historial. Se abrió el historial y se vio el evento real de creación sintética.
• Las pestañas de plantilla se desplazan dentro de su franja; no se observó ensanchamiento global del documento en la matriz principal. La tabla puede ser más ancha que su contenedor y desplazarse horizontalmente: eso se distingue del desbordamiento de toda la página.
• El panel de activo permite varias secciones abiertas a la vez. A anchuras compactas aparece un diálogo en lugar del panel lateral.
• Cancelar la edición conserva búsqueda y plantilla. Tanto Atrás del navegador como «Volver a activos» recuperaron la búsqueda probada.
• La selección de columnas se guarda en asset-inventory-columns. Tras marcar Notas y recargar, la cabecera Notas seguía presente; se comprobó el contenido, sin confundirlo con la flecha de ordenación.
• El catálogo de activos pasó de las filas 1–10 a 11–12 de doce plantillas mediante Página 2.
• El selector de puestos abrió la búsqueda como foco inicial; Shift+Tab/Tab permanecieron en el selector y Escape devolvió el foco a «Seleccionar puesto» del formulario padre.
• La validación de Nombre vacío en persona y edición de activo impidió la petición de escritura. Se vio el aviso nativo de Chromium y el foco en el control. El navegador muestra ese mensaje nativo en inglés: no se presenta como traducción del sistema i18n de Metis.
• El alta de puesto conservó una altura exterior de 765 px en 1440×900 y aproximadamente 653 px en 1366×768, adaptándose a la ventana. No se pudieron contrastar cambios de paso por falta de sede.
• El editor de plantilla abierto directamente en 320×640 mantuvo un modal de 288×608 px, cuerpo desplazable y acciones visibles. Título Campos y contador aparecieron alineados en escritorio.

Jerarquía, tipografía y densidad

La tipografía y la separación entre cabecera, grupos y campos resultan legibles en escritorio. El sistema usa Inter, tokens semánticos y un catálogo propio de iconos; no necesita otra familia visual para resolver las incidencias observadas.

La densidad operativa empeora por tres factores concretos: navegación que consume ancho o altura antes de los datos, columnas con frases explicativas completas y ayudas extensas siempre visibles. En el dashboard, la lista de situaciones reserva altura también para contadores cero; es una oportunidad de compactación, no un error funcional demostrado.

En el portátil, los ejemplos de Marca y Modelo enumeran fabricantes y modelos de tipos muy distintos. En el paso 2 ocupan más espacio que sus controles. Conviene ofrecer ejemplos adecuados a la plantilla y desplegar el detalle secundario, manteniendo visibles finalidad y formato esperado.

Accesibilidad: comprobaciones y límites

Se revisaron controles etiquetados, snapshots accesibles, estado de ordenación, foco inicial, navegación parcial por teclado, cierre y contraste de una muestra. El aviso nativo de campo requerido utiliza la semántica de validación HTML; la ausencia de aria-invalid en ese caso, por sí sola, no demuestra inaccesibilidad.

En la muestra medida, blanco sobre el botón primario dio aproximadamente 4,65:1. El mismo primario sobre el fondo de selección dio 2,68:1: no alcanza el umbral de 4,5:1 para texto normal de WCAG 2.2, contraste mínimo. Se tomaron colores computados, convertidos a sRGB mediante canvas y luminancia relativa; no se dedujeron colores de píxeles suavizados de la captura. Esta comprobación puntual no valida el resto de tokens ni el cumplimiento global de WCAG.

No se ejecutaron lector de pantalla, auditoría automatizada completa de accesibilidad, zoom del navegador al 200/400 %, contraste de todos los estados, alto contraste del sistema, modo oscuro o reducción de movimiento completa.

5. Hallazgos priorizados

Gravedad alta: perjudica de forma importante la lectura o el trabajo en la situación indicada. Media: genera pérdida de contexto, esfuerzo recurrente o inconsistencia de interacción. Baja: detalle de presentación o mantenimiento. No se han demostrado pérdida de datos ni bloqueos generales en escritorio.

V01 — El layout reserva demasiado espacio a la navegación

Alta · Confirmado visualmente y funcionalmente. Pantallas de compañía, especialmente Activos.

• Resoluciones: 390×844 y 320×640; también 768×1024. El panel agrava el espacio reducido desde 1100 px.
• Reproducción: abrir Activos con navegación expandida. En móvil, recorrer la navegación hasta alcanzar el listado; en 768 px observar las dos barras laterales. En escritorio abrir el panel pulsando una celda no interactiva de la fila.
• Resultado: con layout asentado, el main comienza aproximadamente en y=1430 en 390 y en y=1496 en 320. En 768 quedan unos 251 px de contenido. Con panel abierto en 1100, la tabla dispone de unos 237 px: gran parte de sus columnas queda fuera de la vista simultánea.
• Evidencia: móvil inicial, contenido tras desplazamiento, tablet, panel a 1366. Mediciones en results-responsive.json y results-panels.json.
• Responsables: CompanyDetail, shell de navegación, AssetInventoryPage, useCompactDetail; umbrales shell e inventory de apps/web/src/global.css.
• Recomendación: acordar una navegación compacta de compañía en móvil, manteniendo contexto y sección activa; permitir contraer o superponer la secundaria en tablet. Decidir la convivencia tabla/panel por ancho real disponible, no solo por viewport. Conservar el desplazamiento de tabla y las acciones ancladas.

V02 — El enlace pierde contraste en la fila seleccionada

Alta · Confirmado visualmente y mediante medición. Inventario de activos con panel abierto.

• Resoluciones: observado en escritorio, incluidas 1440×900 y 1366×768; medición en 1440.
• Reproducción: pulsar Plantilla u otra celda no interactiva de AUDIT-PORT-01, dejando seleccionada la fila.
• Resultado: enlace rgb(230,25,25) sobre fila rgb(255,175,189), aproximadamente 2,68:1. El enlace es texto de 14 px, no texto grande.
• Evidencia: fila seleccionada, colores en results-verify.json.
• Responsables: selectedRowClass y enlace de nombre de inventory-page.tsx, tokens primario/acento.
• Recomendación: definir el par de colores para contenido interactivo seleccionado; comprobar también hover y acciones fijadas. No corregirlo cambiando solo el rojo global, cuyo botón blanco supera el umbral medido.

V03 — Los asistentes de activos y recursos cambian de altura

Media · Confirmado visualmente y funcionalmente. Alta de activo y alta de recurso.

• Resolución reproducida entre pasos: 1440×900.
• Reproducción: Nuevo activo → Portátil → Siguiente → Siguiente. Repetir Nuevo recurso → Aplicación → Siguiente → Siguiente. Cancelar.
• Resultado: activo pasa de unos 615 px a 868 px; recurso de 615 a 797 y 777 px. Se desplazan cabecera y pie. La estabilidad de puestos no se ha trasladado a estos asistentes.
• Evidencia: activo paso 1, activo paso 2, recurso paso 2; results-deep.json.
• Responsables: AssetEditorDialog, ResourceEditorDialog, sus formularios y FormDialog. El primero omite layout, cuyo valor por defecto es content.
• Recomendación: aplicar layout="stable" en ambos asistentes y mantener cuerpo desplazable. Reutilizar FormHelp junto al pie donde corresponda, conservando campos y reglas de cada entidad.

V04 — La ayuda fija y el progreso reducen demasiado el cuerpo en móvil

Media · Confirmado visualmente. Nuevo puesto y nuevo perfil.

• Resoluciones: especialmente 320×640; en 390×844 ya se necesita desplazamiento adicional.
• Reproducción: abrir Nuevo puesto o Nuevo perfil sin completar el primer paso.
• Resultado: en 320 la ventana ocupa 608 px, pero el cuerpo de puesto dispone de unos 197 px. La ayuda ocupa una franja separada hasta el pie. Sede queda debajo del primer encuadre del cuerpo. Las etiquetas «Ordenador principal» y «Resumen» del progreso llegan a juntarse.
• Evidencia: puesto 320, perfil 320, results-responsive.json.
• Responsables: FormHelp, ContextHelp, progreso y composición de los formularios de puesto/perfil.
• Recomendación: conservar la ayuda alineada al pie, con resumen breve y ampliación accesible; ajustar su presupuesto de altura en ventanas cortas. Simplificar el indicador de pasos en anchos mínimos sin perder paso actual y total. Mantener scroll y acceso por teclado a toda la ayuda.

V05 — La ordenación se pierde al volver de la ficha

Media · Confirmado funcionalmente. Activos, 1440×900.

• Reproducción: buscar AUDIT, seleccionar Portátil, ordenar Nombre descendente, abrir el enlace del activo y volver con Atrás.
• Resultado: búsqueda y plantilla permanecen en URL; aria-sort pasa de descending a ascending.
• Evidencia: beforeNavigation y afterNavigation en results-flows.json, vuelta al listado.
• Responsables: estado local de useEntityTable y montaje de la lista al navegar entre listado y ficha.
• Recomendación: definir un contrato de contexto de listado —búsqueda, filtros, orden y página— y restaurarlo al volver. Usar URL o estado de navegación por vista según el patrón acordado; no guardar datos remotos duplicados. La pérdida de página en activos queda pendiente: solo existe una fila.

V06 — Escape puede dejar el foco en el documento

Media · Confirmado funcionalmente. Alta de activo, 1440×900.

• Reproducción: enfocar Nuevo activo, abrir con Enter y cerrar con Escape; esperar al cierre y al retorno de foco.
• Resultado: tras esperar hasta tres segundos el foco seguía en BODY, sin indicación visible, en lugar del botón Nuevo activo. No ocurre en el selector anidado de puestos probado.
• Evidencia: foco tras cierre, focusAfterClosed en results-verify.json.
• Responsables: integración de AssetEditorDialog/FormDialog con el disparador externo y su desmontaje.
• Recomendación: establecer y comprobar la restitución de foco en el wrapper propio y sus consumidores; cubrir Escape y Cancelar, disparador de cabecera y acciones de fila. No modificar la implementación vendor.

V07 — Búsqueda sensible a tildes

Media · Confirmado funcionalmente. Activos, 1440×900.

• Reproducción: escribir portatil; sustituir por portátil.
• Resultado: cero y un resultado respectivamente, aunque ambos buscan la misma plantilla. La ordenación sin tildes no implica que la búsqueda también las ignore.
• Evidencia: consulta sin tilde, resultados de ambas consultas en results-flows.json.
• Responsable: filtrado de AssetList, que aplica minúsculas e includes sin normalización de diacríticos.
• Recomendación: unificar comparación de búsqueda en los consumidores equivalentes, definiendo expresamente el tratamiento de ñ y otros caracteres del idioma. Añadir pruebas sobre comportamiento, no solo sobre el helper.

V08 — Elegir entre 75 columnas requiere recorrer una lista plana

Media · Confirmado visualmente y funcionalmente. Activos → Columnas, 1440×900 y móvil.

• Reproducción: abrir Columnas con los catálogos de serie cargados.
• Resultado: 75 casillas, sin búsqueda ni agrupación visible. La personalización persiste correctamente, pero localizar un campo técnico resulta costoso.
• Evidencia: selector de columnas, columnsCount en results-panels.json.
• Responsables: EntityTableColumnsDialog y la descripción de columnas dinámicas de activos.
• Recomendación: extender el selector existente con búsqueda y grupos semánticos, manteniendo identificación/acciones protegidas y compatibilidad con las preferencias locales. El componente genérico recibe etiquetas y grupos, sin conocer plantillas ni DTO.

V09 — Las cabeceras de revisión contienen explicaciones completas

Media · Confirmado visualmente. Perfiles y configuraciones relacionadas, 1440×900.

• Reproducción: abrir Perfiles de usuario, Aplicaciones del perfil, Impresoras del perfil, Certificados o Correo.
• Resultado: se usa una frase como «Revisar: la persona, el dispositivo…» como título de columna. Se recorta y ocupa un ancho desproporcionado, incluso con la tabla vacía.
• Evidencia: perfiles, aplicaciones.
• Responsables: definiciones de columnas y claves i18n; en perfiles, profiles.review sirve tanto de etiqueta como de explicación.
• Recomendación: cabecera breve «Revisión» y explicación accesible contextual; mantener el motivo específico en la celda cuando existan datos. No ocultar estados de negocio ni depender únicamente de un icono.

V10 — La ficha acumula secciones vacías y mensajes administrativos

Media · Confirmado visualmente. Información del portátil sintético, escritorio y móvil.

• Reproducción: abrir el activo y recorrer Información sin características ni relaciones pobladas.
• Resultado: dos grupos llamados Identificación y una ficha de varios miles de píxeles con muchos guiones y bloques sin relaciones; la advertencia sobre evolución de plantillas precede a los datos en todas las consultas. Se tarda en alcanzar dominios, publicaciones y perfiles.
• Evidencia: primer encuadre de ficha, relaciones, diálogo compacto.
• Responsables: composición de AssetDetail, secciones de características y bloques de relaciones/publicaciones.
• Recomendación: diferenciar datos generales de la sección Identificación de la plantilla; priorizar datos con valor y resumir grupos vacíos plegables, sin eliminar información. Dar menor presencia a la explicación administrativa de sincronización. Conservar accesibles altas y estados vacíos útiles.

V11 — Ausencias representadas de manera distinta en tablas de ficha

Baja · Confirmado visualmente. Ficha y panel de activo.

• Resoluciones: 1440×900 y 390×844.
• Reproducción: consultar Ubicación y asignación de un activo sin sede.
• Resultado: el listado muestra «—»; la tabla de detalle muestra «Sin asignar». En el mismo bloque aparece «Sin puesto activo», cuyo significado debe distinguirse de una mera celda vacía.
• Evidencia: detalle compacto.
• Responsables: renderizadores de detalle y panel; patrón de celdas sin valor.
• Recomendación: usar «—» para ausencia real en tablas y conservar textos que expresen estados de negocio. Revisar la semántica antes de sustituir indiscriminadamente mensajes.

V12 — La carga inicial sustituye todo el listado

Media · Confirmado funcionalmente con demora de red simulada. Activos, 1440×900.

• Reproducción: retener la petición GET del inventario en el navegador y recargar; liberar el bloqueo y recargar para recuperar el listado.
• Resultado: desaparecen búsqueda, filtros, tabla y paginación; se conserva cabecera, alta deshabilitada y «Cargando catálogo…». Tras retirar la interceptación vuelve el activo. No se ha medido latencia real ni se extrapola a una recarga en segundo plano.
• Evidencia: carga inicial, results-network.json.
• Responsables: condiciones de render de AssetInventoryPage y consultas requeridas por el listado.
• Recomendación: reservar estructura y espacio con los componentes de carga existentes; diferenciar inventario y catálogo en el mensaje. Conservar los datos actuales durante actualizaciones cuando ya están disponibles.

6. Contraste con las auditorías anteriores

Hallazgo previo recuperable	Estado en esta auditoría	Contraste, impacto y propuesta
Panel decidido por viewport, sin considerar ambas barras	Confirmado visualmente	V01. Tabla de unos 237 px a 1100 con panel. Resolver por contenedor y prioridades de navegación.
Estado de orden/paginación local al listado	Confirmado funcionalmente para orden; página pendiente	V05. Se conserva q/plantilla y se reinicia orden. No hay página 2 de activos para probarla.
Búsqueda solo en minúsculas, sensible a tildes	Confirmado funcionalmente	V07: portatil=0, portátil=1.
Selector de columnas plano y extenso	Confirmado visualmente	V08: 75 opciones; persistencia sí funciona.
Controles ausentes durante carga inicial	Confirmado funcionalmente mediante simulación	V12. No se considera un resultado de rendimiento real.
Errores de campos no asociados uniformemente en acceso	Detectado únicamente mediante código para CredentialForm	El formulario de credenciales mantiene error general. No se reprodujo un login fallido en esta auditoría autenticada. Los campos requeridos probados sí activan validación nativa; no se infiere un incumplimiento de ese hecho.
Consultas completas y filtrado/paginación en cliente; contadores cargan colecciones	Detectado únicamente mediante código; impacto pendiente	useEntityTable y controlador de compañía mantienen estos patrones. Una compañía y un activo no permiten medir degradación. Evaluar con fixture grande autorizada antes de cambiar contratos o introducir virtualización.
Éxito en color primario y colores fijos en componentes	Detectado únicamente mediante código para éxito/vacío; contraste de selección confirmado	FormFeedback usa primario para éxito y EmptyState contiene un rojo fijo. No hubo éxito de guardado probado. V02 sí aporta medición de una combinación visible defectuosa.
Reglas CSS duplicadas de dialog-content	Detectado únicamente mediante código	Dos reglas consecutivas en global.css; no se atribuye un defecto visual sin reproducción. Consolidación futura acotada, sin editar vendor.
Desbordamiento global de página en móvil	No reproducido en la matriz principal	Tablas anchas desplazan dentro de su contenedor; el problema demostrado es espacio útil y navegación, V01.
Foco inicial del PickerList	No reproducido como problema en el selector probado	Búsqueda de puesto enfocada y retorno al padre correctos. No equivale a validar todos los pickers.
Altura estable de todos los asistentes	Descartado como propiedad general	Puesto estable en el paso disponible; activos/recursos variables, V03.
Alineación de Campos y contador en editor de secciones	No reproducido en editor de activo	Alineados a 1440. Editor de recurso no abierto: pendiente específico.

Los problemas nuevos con evidencia propia incluyen V02, V04, V06, V09 y la composición extensa de ficha. Para los hallazgos solo de código no se inventa una resolución afectada ni una captura de un fallo no visto.

7. Problemas transversales del sistema visual

• Los umbrales no expresan capacidad del contenedor. El shell, la compañía y el panel deciden su distribución por separado. El resultado es coherente técnicamente, pero deja poco espacio para la tarea.
• Las variantes comunes no se usan de forma uniforme. FormDialog ya ofrece estabilidad; FormHelp ya permite ayuda fuera del cuerpo. Su adopción es desigual.
• Un token aislado no garantiza contraste en todas sus combinaciones. El primario funciona sobre blanco y falla sobre selección. Es necesario definir parejas por estado.
• La cantidad de texto no está jerarquizada por utilidad. Se mezclan etiquetas, avisos, explicaciones y ejemplos extensos en lugares de lectura rápida.
• El contexto de navegación está incompleto. Parte vive en URL, parte en estado local que se pierde al desmontar la vista.
• Los vacíos son correctos, pero poco orientativos en algunos casos. Hay CTA de cabecera, aunque «No hay resultados» en Recursos no explica si falta registrar el primer recurso. No se propone convertir todos los vacíos en grandes tarjetas decorativas.
• La presentación compacta no debe ocultar la tarea. Ayuda, progreso y dos niveles de navegación compiten con controles y resultados.

8. Componentes compartidos que conviene revisar

Componente o ámbito	Mejora propuesta	Criterio de aceptación
Shell y CompanyDetail	Navegación adaptable por espacio y jerarquía	Llegar al contenido sin recorrer toda la navegación en móvil; tabla útil en tablet
Inventory layout / useCompactDetail	Panel según ancho de trabajo real	Tabla y panel simultáneos solo cuando ambos conservan espacio operativo
FormDialog	Adopción uniforme de stable y restitución de foco	Misma altura al cambiar paso; Escape y Cancelar devuelven al disparador
FormHelp / ContextHelp	Resumen y expansión adaptados a ventana corta	Ayuda pegada al pie, accesible, sin desplazar fuera del primer encuadre todos los campos
FormProgress / progreso de creación	Variante compacta	Sin solapamiento de etiquetas a 320 px
EntityTableColumnsDialog	Buscar y agrupar opciones	Encontrar un campo sin recorrer decenas de casillas
useEntityTable + navegación de entidades	Contexto persistido por vista	Volver conserva filtro, orden y página válida
EntityTable / enlaces de fila	Contraste de selección y títulos breves	Texto de datos legible y acciones ancladas en cada estado
FieldHelp / catálogo de ejemplos	Ejemplos ajustados al tipo	No enumerar modelos irrelevantes como ayuda permanente
AssetDetail / DetailSection	Datos prioritarios y vacíos resumidos	Identificar características y relaciones sin recorrer bloques vacíos extensos

Son extensiones de componentes con consumidores reales. Los componentes genéricos reciben datos, textos y acciones; no deben conocer endpoints, Sequelize ni DTO concretos. Mantener TimeLine, AssetSummaryCard, EmptyState, CountBadge y las tarjetas de selección existentes donde correspondan, sin duplicar sus estructuras.

9. Plan incremental recomendado

1. Correcciones pequeñas verificables: contraste seleccionado, foco al cerrar, estabilidad de activos/recursos y cabeceras breves. Validar cada escenario de V02/V03/V06/V09 antes y después.
2. Espacio de trabajo: acordar comportamiento de navegación en 320/390/768/1024 y panel por contenedor. Verificar teclado, sección activa, acceso a todas las opciones y ausencia de scroll global horizontal.
3. Formularios cortos: ajustar ayuda y progreso en ventanas bajas; conservar ubicación junto al pie, contenido completo y scroll. Revisar todos los consumidores equivalentes.
4. Productividad de listados: búsqueda sin tildes, selector de columnas con búsqueda y contrato completo de retorno. Comprobar que preferencias existentes siguen siendo válidas.
5. Fichas y relaciones: jerarquizar bloques y datos vacíos con una fixture sintética representativa autorizada: sede, persona, puesto, perfil, impresora compartida, interfaces, dominio y publicación SMB. No utilizar compañías reales como banco de pruebas.
6. Validación ampliada: conjuntos grandes para rendimiento; lector de pantalla, zoom, idiomas, modo oscuro y dispositivos reales. Solo decidir paginación remota/virtualización después de medir el problema con volúmenes representativos.

No se han implementado estas recomendaciones. Los cambios futuros deben respetar las comprobaciones apropiadas de AGENTS.md y el veto de modificación de packages/shadcn-ui.

10. Implicaciones para DESIGN.md

No se ha generado el archivo definitivo. Su contenido debería consolidar decisiones del producto y enlazar las fuentes normativas existentes, sin duplicarlas:

1. Propósito: herramienta de soporte empresarial; prioridad a localizar, comparar y relacionar información.
2. Fuentes y precedencia: AGENTS, patrones de listados/diálogos, biblioteca propia sobre Base UI/Vega.
3. Fundamentos: Inter para interfaz, papel específico de Mono/Serif, escala tipográfica existente, espaciado, bordes y elevación actuales.
4. Color por función y estado: acción primaria, selección, éxito, aviso y error; tabla de parejas de contraste verificadas y pendientes. Registrar V02 como deuda, sin declarar todos los tokens accesibles.
5. Layout por capacidad: mínimos operativos del contenido, jerarquía de navegación global/compañía y convivencia tabla/panel. Documentar el comportamiento por contenedor acordado tras V01.
6. Densidad: filas, etiquetas breves, información secundaria, truncamiento con acceso al valor completo y grupos vacíos.
7. Contratos de interacción: enlaces frente a acciones, contexto de retorno, foco, cierre, cancelación y estados de consulta.
8. Formularios y asistentes: referenciar el patrón normativo, explicar adopción de stable/FormHelp y variante compacta de progreso.
9. Fichas y relaciones: jerarquía de resumen, información, bloques relacionados e historial; independencia de componentes genéricos.
10. Verificación y deuda: matriz de tamaños, evidencias, contraste, teclado, datos necesarios y excepciones justificadas.

Evitar convertirlo en una plantilla genérica de landing pages o imponer cambios de marca para resolver problemas de layout. La biblioteca propia y las primitivas existentes bastan para el plan propuesto.

11. Evidencias, consola y limitaciones

Ubicación y trazabilidad

Las evidencias se guardan en .artifacts/playwright/ui-audit/, excluido de Git. Se verificaron las cabeceras y dimensiones de los PNG. El índice distingue las capturas previas de acceso sin autenticar y una imagen descartada por representar una transición de tamaño; no sustentan los hallazgos de esta auditoría. Este informe se entrega para versionar; los PNG y JSON permanecen locales y deben compartirse expresamente si otro equipo necesita reproducir la inspección.

• results-matrix.json: matriz principal y mediciones.
• results-flows.json: búsquedas, ordenación y cancelación.
• results-panels.json: panel, diálogos compactos y columnas.
• results-dialogs.json: primera pasada de aperturas; algunas medidas inmediatas tras resize son transitorias y no fundamentan defectos geométricos.
• results-deep.json: pasos, selector anidado, validación y error de red simulado.
• results-responsive.json: geometría asentada de móvil y modales, historial y paginación.
• results-sections.json: configuraciones y relaciones disponibles.
• results-final-checks.json y results-verify.json: validación, permisos, comprobaciones adicionales y rectificaciones de medidas iniciales.
• results-network.json: demora artificial y recuperación.
• results-a11y.json: muestra de colores, teclado y acordeones.
• results-mobile-template.json: apertura nueva del editor en 320.
• Snapshots .txt y capturas .png con pantalla y ancho en el nombre; evidence-index.json contiene dimensiones y SHA-256 de las capturas.

Las comprobaciones posteriores prevalecen sobre las observaciones transitorias: el primer test de persistencia buscaba una cabecera exactamente igual a «Notas», ignorando su flecha; la verificación de cabeceras y almacenamiento confirmó persistencia. Una imagen tomada durante el cambio de ancho del editor parecía recortada; la apertura móvil nueva mostró geometría correcta y no se registra como defecto.

Red, consola y ausencia de escrituras

• Se observó un 404 de /favicon.ico en una de las sesiones MCP. Es un recurso accesorio, sin bloqueo de los flujos probados.
• En el recorrido profundo se bloquearon preventivamente todas las escrituras del navegador. El asistente de activo propuso un nombre y llegó a intentar un POST de alta; se abortó antes de llegar al servidor. La interfaz mostró «No se pudo completar la operación». Esa evidencia se conserva en asset-wizard-invalid-1440.png, pero su nombre no debe interpretarse como una validación de campos: documenta un error de red provocado. La validación real de Nombre vacío se ejecutó después en edición, sin petición de escritura.
• El net::ERR_FAILED de ese recorrido corresponde al aborto controlado anterior, no a un fallo espontáneo de la aplicación.
• La demora GET del inventario fue otra interceptación local del navegador; al retirarla y recargar se recuperó el listado.
• No se observaron excepciones JavaScript de aplicación en los registros conservados de los escenarios completados. Esto no demuestra ausencia de errores en rutas no recorridas.
• Hubo fallos del guion de inspección por selectores ambiguos y por esperar el shell en una pantalla de acceso denegado. Se corrigieron los recorridos; no se contabilizan como incidencias de Metis.
• No se guardaron formularios ni se ejecutaron bajas, desactivaciones, eliminaciones o mutaciones de negocio durante la auditoría. Solo el preparador creó su conjunto sintético autorizado. Los cambios de columnas afectaron a preferencias del navegador aislado.

Pendientes reales

No se validaron guardados satisfactorios, estados de éxito, conflictos concurrentes, errores de servidor representativos, datos extensos, historial con múltiples modificaciones, relaciones pobladas, administración de usuarios, fichas de persona/puesto/perfil/recurso ni todos los pickers. Tampoco se validaron todos los pasos de puesto/perfil, por ausencia de sedes y puestos. Para cerrarlos hace falta una fixture ampliada y autorizada; no basta con revisar su JSX.

No se ejecutaron pnpm typecheck, lint, test, check o build: no se ha cambiado código ejecutable. Se ejecutaron el preparador autenticado, los recorridos MCP descritos, comprobaciones de capturas y enlaces locales del informe y revisión del diff. Al finalizar se cerró el preparador: retiró su entorno temporal y se comprobó la eliminación de session.json y database.env. Las capturas se conservan sin la sesión privada.

12. Seguimiento — UI/UX Improvement Sprint 1

Verificación posterior del 21 de octubre de 2026. Se conservan íntegros los hallazgos y mediciones originales de las secciones anteriores. Este seguimiento cambia únicamente el estado de V02, V03, V06 y V09, dentro de los escenarios comprobados. V01, V04, V05, V07, V08, V10, V11 y V12 continúan pendientes.

Resultado por hallazgo

Hallazgo	Estado posterior	Cambio y comprobación
V02	Resuelto en el inventario claro comprobado	Primario, texto secundario y ring contextuales mediante accent-foreground en la fila seleccionada y en hover, sin cambiar tokens globales. Enlace de nombre y Crear puesto pasan de 2,68:1 a 7,81:1 sobre selección. Enlaces en estado normal sobre blanco: 4,65:1; hover sin selección: 12,86:1. Incluyendo el texto secundario, el mínimo medido en hover sin selección es 4,59:1, y en selección 7,81:1. Acciones fijadas legibles y foco visible con Tab/Shift+Tab. No es una declaración WCAG global ni una validación de modo oscuro.
V03	Resuelto en ambos asistentes y cuatro tamaños	AssetEditorDialog y ResourceEditorDialog usan stable. Anterior permanece deshabilitado en el paso inicial para que el pie móvil no cambie de número de filas. El anuncio de progreso usa preventScroll y el cambio de paso devuelve el cuerpo a su inicio. Los tres pasos mantienen altura, cabecera y coordenada del pie, con cuerpo desplazable y Escape funcional.
V06	Resuelto en los disparadores comprobados del inventario	FormDialog reexpone finalFocus de Base UI. El consumidor captura el disparador antes del foco del anuncio y aporta destino alternativo si desaparece o se deshabilita. Ratón/Enter, Escape/Cancelar, cabecera/fila y selector anidado probados; sin retorno a BODY.
V09	Resuelto en seis listados	Cabecera independiente profiles.reviewLabel: Revisión/Review. Se mantienen las explicaciones completas y condiciones de revisión en las celdas de perfiles, carpetas, aplicaciones, certificados, impresoras y correo.

Geometría antes y después

Valores en píxeles CSS, con fuentes y transiciones asentadas. La tabla muestra las alturas de los pasos 1/2/3; dentro de cada fila posterior el pie conserva la misma y.

Resolución	Activos antes	Activos después	Recursos antes	Recursos después
1440×900	615 / 868 / 868	765 / 765 / 765	615 / 797 / 777	765 / 765 / 765
1366×768	615 / 736 / 736	652,8 / 652,8 / 652,8	615 / 736 / 736	652,8 / 652,8 / 652,8
390×844	812 / 812 / 812, pie variable	812 / 812 / 812	812 / 812 / 812, pie variable	812 / 812 / 812
320×640	608 / 608 / 608, pie variable	608 / 608 / 608	608 / 608 / 608, pie variable	608 / 608 / 608

El pie posterior comienza en y=762,5 / 640,4 / 670 / 466 respectivamente. Se comprobó scroll interno con contenido mayor que el cuerpo disponible y acciones dentro del viewport. El progreso sigue perteneciendo al cuerpo desplazable; no se ha rediseñado su densidad ni la ayuda de V04, y un desplazamiento del usuario puede sacarlo de vista.

Evidencias antes/después y pruebas

Carpeta independiente ui-sprint-1; no se han sobrescrito las imágenes históricas de ui-audit. Imágenes representativas abiertas:

• V02: antes y después.
• V03: activo antes, activo después, recurso después.
• V06: antes y después.
• V09: antes y después.

visual-audit-ui.test.py reutiliza el cliente MCP y la sesión del preparador existente, sin SDK o infraestructura de navegador paralelos. Bloquea todas las escrituras HTTP. Se ejecuta con el preparador activo:

METIS_PLAYWRIGHT_STORAGE_STATE=.artifacts/playwright/authenticated-<ejecucion>/session.json \
METIS_UI_AUDIT_PHASE=after python3 scripts/visual-audit-ui.test.py

La fase before conserva las reproducciones iniciales y falla las expectativas de regresión mientras las incidencias están presentes. La verificación posterior consta de cuatro pruebas principales correctas, ampliación de foco/cabeceras a los otros tamaños y contraste de seis estados. Se conservan mediciones y snapshots, además de los resultados en after/test-result.log, after/additional-result.log y after/contrast-final-result.log y after/headers-final-result.log. measurements.json incluye pasadas intermedias; summary-latest.json resume la última observación por escenario. El índice de PNG contiene dimensiones y SHA-256. Las evidencias siguen excluidas de Git y requieren entrega explícita para compartirlas.

Se ampliaron tests es/en de cinco listados y una prueba con perfil sintético en caché para asegurar que la cabecera breve no elimina el motivo detallado de la celda. Se actualizó la prueba del contrato de Anterior deshabilitado en el primer paso. No se han guardado personas, puestos, recursos ni ediciones en el entorno visual.

Archivos y responsabilidades

Área	Archivos principales
Inventario	inventory-page.tsx: color contextual, disparador y alternativa de foco
Diálogos	AssetEditorDialog, ResourceEditorDialog: altura estable
Biblioteca propia	FormDialog: finalFocus; FormStepActions: pie estable; FormProgress: inicio del cuerpo al cambiar de paso
Listados e i18n	Seis pages de work-profiles, folder-mappings, application-configurations, certificate-configurations, printer-configurations y mail-configurations; common/locales/es.json y en.json de companies
Pruebas	visual-audit-ui.test.py, selection-components.test.tsx e inventory.test.tsx; profile.test.tsx, application.test.tsx, certificate.test.tsx, printer.test.tsx y mail.test.tsx
Documentación	Este seguimiento, DESIGN.md y componentes-de-interfaz.md

Comprobaciones técnicas y limitaciones

• Build: correcto; permanece el aviso de Vite sobre tamaño de chunks.
• Tipos dirigidos: correctos para rdx-ui, assets, resources y companies.
• Typecheck global: falla en vendor calendar.tsx:165 por locale y exactOptionalPropertyTypes; archivo sin modificar.
• Lint global: falla por errores en archivos ajenos al sprint, principalmente person-photo y procesos; también hay avisos en ejemplos de skills. Los archivos de código modificados pasan Biome dirigido.
• Check global: falla por los errores anteriores y formato preexistente, incluidos ejemplos de skills. No se reformatearon archivos ajenos para conseguir un resultado verde.
• pnpm test: ejecutado con MariaDB nueva desechable y variables explícitas, sin usar la base local ni la base del navegador. Pasan rdx-ui, assets y resources; companies mantiene dos fallos ajenos en companies-page.test.tsx: expectativas antiguas «Personas (1)» y «Esta persona no tiene acceso a Metis Desk». Son fuentes y pruebas no modificadas en este sprint. Turbo detiene el recorrido y no llega a ejecutar integración de servidor; no se declara superada la suite global.

Durante la implementación se corrigieron una clave de traducción inicialmente no existente y las expectativas anteriores de ocultar Anterior en rdx-ui y activos. También se descartaron pasadas interrumpidas por HMR y errores de sintaxis/selectores del guion de inspección; no se contabilizan como defectos de la aplicación ni como pruebas aprobadas.

Al cerrar se identificó otro preparador anterior que no se había detectado al iniciar. Se retiró exclusivamente la instancia creada para este sprint, su base y su sesión; el entorno anterior permaneció activo. Las pruebas principales utilizaron la sesión sintética del sprint. La comprobación final ampliada de contraste reutilizó la sesión del preparador anterior, sin iniciar servicios ni escribir datos de negocio. Las pruebas técnicas tuvieron bases separadas. Se comprobó la eliminación de la sesión del sprint y de sus servicios. Las filas con avisos de revisión no estaban pobladas en el navegador: la conservación de su motivo se comprobó con renderizado SSR es/en. No se amplía la cobertura a modo oscuro u otros navegadores por haber superado estos escenarios de Chromium.

Se consultaron frontend-design, shadcn, vercel-composition-patterns y vercel-react-best-practices: se conservaron identidad y tokens, se usó la API pública Base UI para el foco y se mantuvieron composición y estado remoto existentes. No se modificaron vendor, autenticación, modelo de datos, rutas ni los otros ocho hallazgos.

Seguimiento V01.2 — Navegación por capacidad

El 21 de octubre de 2026 se implementa la segunda entrega V01.2, sobre V01.1. V01 queda parcialmente resuelto, sin cerrar el panel/diálogo de inventario ni la migración de recursos (V01.3/V01.4).

La nueva matriz sintética de cinco pantallas y once resoluciones conserva las mediciones originales de esta auditoría como historia. En Activos, main pasa de 972 a 1128 px en 1440, de 556 a 952 en 1024 y de 300 a 768 en 768. El móvil conserva Y=106; no se registra desbordamiento horizontal del documento en las 55 mediciones posteriores.

Se mantienen los 21 destinos y sus contadores; se verifican preferencia manual frente a colapso automático, intención contextual temporal, scroll independiente, tooltips, enlaces, teclado, foco y resize. La regresión detectada en activadores que desaparecen tenía una prueba que dejaba el foco en BODY; su corrección traslada el foco a un activador/enlace visible. Resultados de regresiones V02/V03/V06/V09, comandos, capturas y límites se registran en el informe de entrega, sin convertir los checks globales fallidos en pruebas aprobadas.

Seguimiento V01.3 — Detalle de activos por capacidad

La tercera entrega V01.3 sustituye exclusivamente en activos el umbral de viewport por la caja exterior estable del inventario. Las mediciones originales de esta auditoría y V01.2 se conservan. La tabla útil con selección pasa de 453 a 797 px a 1160 de viewport y de 634 a 978 px a 1100. A 1920 permanece el panel de 400 px y la tabla útil de 977 px. El umbral real W=1144 deja 800 px de columna de tabla (798 interiores tras bordes).

El informe de entrega documenta límites exactos, identidad de tabla, estado, foco, transiciones y regresión con Playwright MCP autenticado y datos sintéticos. Una prueba detectó foco en una guarda de Base UI al transferir diálogo a panel; la implementación incorpora la transferencia tras liberar la modalidad y vuelve a comprobarla. Los errores globales se registran como fallos, no como validaciones superadas. V01 sigue parcialmente resuelto: recursos conserva su presentación anterior hasta V01.4. No cambia el estado de los demás hallazgos.

Seguimiento V01.4 — Cierre de V01

El 22 de octubre de 2026 se completa V01.4, conservando esta auditoría como línea base. Recursos adopta un mínimo de contenedor de 984 px (tabla 640 + separación 24 + panel 320), con su selección en URL y diálogo explícito existentes. Activos mantiene 1144 px y sus geometrías de V01.3. El mecanismo independiente del dominio se comparte en rdx-ui, sin modificar shell, vendor, permisos ni rutas.

La comprobación final mediante Docker/Chromium y Playwright MCP autenticado ejecuta 28/28 métodos correctos, incluida regresión de V01.1–V01.4 y V02/V03/V06/V09. Las matrices cubren once resoluciones y ambos lados de los umbrales; no registran overflow horizontal global. Las cuatro suites finales y las matrices no registran errores ni warnings de consola. Se amplían fixtures con 16 recursos sintéticos del catálogo real y se verifican lectura ordinaria, filtros/paginación, relaciones disponibles, edición/cancelación, transiciones y foco; no se realizan borrados ni activaciones.

V01 pasa de parcialmente resuelto a resuelto en los escenarios verificados. Los fallos globales previos siguen documentados como tales: calendario vendor en typecheck, lint/check ajenos y dos expectativas SSR de compañías; las comprobaciones dirigidas y build pasan. No se extiende esta conclusión a WCAG completo, otros motores, datos reales o los hallazgos fuera de alcance. El informe V01.4 conserva las regresiones intermedias y sus correcciones, las evidencias locales y la retirada de servicios/sesión propios.

Seguimiento L02.2 — Configuración de columnas V08

El 22 de octubre de 2026 se completa L02.2. V08 pasa a resuelto en los escenarios verificados: búsqueda con tildes/mayúsculas y distinción ñ/n, keywords, cinco grupos en Activos, contador de visibilidad, columnas obligatorias y restauración inmediata con persistencia tras recarga. Sin grupos, el configurador continúa sirviendo a Recursos, Personas y tablas sencillas. No hay Aplicar/Cancelar ni reordenación.

Se reproduce antes del cambio el catálogo real de 75 columnas y ocho visibles, sin búsqueda/grupos, y la preferencia Sede guardada. Se preservan las medidas originales del hallazgo. La nueva suite MCP completa obtiene 8/8 pruebas correctas, cubriendo siete resoluciones de 320×640 a 1920×1080, es/en, casos de tres columnas, campo compartido entre doce plantillas, storage bloqueado, diálogos anidados, teclado, foco y recarga.

A 320×640 las opciones disponen de 336 px útiles y el diálogo permanece en 608 px exteriores; filtrar hasta cero resultados no colapsa la lista ni desplaza búsqueda/cierre fuera del modal. Las capturas representativas se abren para inspección, además de medir geometría. Se utiliza una única instalación autenticada desechable, con quince compañías y una principal con 50 personas, 51 activos y 66 recursos. El informe enlaza evidencias y registra los resultados técnicos fallidos sin presentarlos como suites globales correctas.

V05, V07 y V12 siguen pendientes. La normalización añadida solo corresponde al buscador de columnas; no corrige las búsquedas de entidades. No se cambia el estado de otros hallazgos ni se acredita WCAG completo o pruebas con datos reales.