2026-10-25 01:19:17 +02:00

51 KiB

Raw Blame History

Auditoría de skills y UI/UX de la ficha de puesto de trabajo

Fecha: 24 de octubre de 2026. Alcance: investigación del árbol de trabajo actual, auditoría y propuesta; no se implementan mejoras. Ruta de producto: /companies/:companyId/workstations/:id.

1. Resumen ejecutivo

La ficha dispone de una base adecuada: identidad editable, navegación contextual, equipamiento sin duplicación del principal, perfiles con configuraciones desplegables, consultas independientes y componentes compactos compartidos. Conviene refinar la composición existente, conservando Inter, los tokens, Base UI/Vega y los patrones de Metis. No se justifica sustituir la biblioteca ni construir otro sistema visual.

Se verificaron 15 skills locales, coincidentes con skills-lock.json. Las cinco más útiles para implementar el pulido son ux-dashboard, frontend-design, ux-tables, shadcn y ux-navigation. Para esta auditoría se utilizó ux-design-review como guía principal, con disponibilidad parcial: sus auditores dependientes no están instalados. Sus criterios de revisión se aplicaron directamente, sin atribuirles ejecuciones inexistentes.

Las mayores oportunidades verificadas son reducir el peso de la cabecera móvil, resumir la gestión de soporte y mejorar la lectura de perfiles en tarjetas estrechas. Se proponen nueve cambios: dos P0, cinco P1 y dos P2. P0 significa prioridad de mejora visual dentro de este encargo; no acredita un fallo crítico ni una incidencia de producción.

Se inspeccionaron capturas de escritorio, tablet y móvil sobre MariaDB desechable metis_desk_test. El escenario principal tiene dos miembros y dos perfiles activos; el denso, 80 miembros y 60 perfiles, de los cuales 50 activos. Las mediciones y limitaciones se detallan en §4. No se afirma cumplimiento WCAG ni una mejora de productividad medida con usuarios.

2. Inventario de skills relevantes verificadas

Descubrimiento y disponibilidad

Se comprobaron las siguientes ubicaciones, sin instalar ni actualizar nada:

Ubicación o mecanismo	Resultado de esta sesión
`.agents/skills/*/SKILL.md`	15 skills presentes y leídas; todos los nombres coinciden con el lockfile.
`skills-lock.json`	15 entradas con procedencia y `computedHash`; no registra commit/tag inmutable. El fichero presente y el lock son evidencias distintas.
`.codex/skills/`, `skills/` en la raíz	No existen.
`.codex/config.toml`	Playwright MCP configurado mediante Docker; es una herramienta de validación, no una skill de diseño.
`/home/david/.agents/skills/`	`find-skills` presente; sirve para descubrimiento/instalación, no para decidir el diseño de la ficha. No se invocó.
`/home/david/.codex/skills/.system/`	imagegen, openai-docs, review-agent, skill-creator y skill-installer presentes. No aportan una guía específica para esta ficha; presencia física no equivale a disponibilidad como skill en el catálogo de la sesión.
`/home/david/.codex/config.toml`	Se comprobó únicamente si existe registro `skills`: ausente. No se reproducen otros ajustes.
Caché `/home/david/.codex/plugins/cache/openai-curated-remote/`	Existen skills de Pages, Sites, Pets, plugin-management y plantillas de artefactos. No se confunden con dependencias instaladas de la SPA. Sus nombres/ubicaciones se inventariaron; no se aplicaron sus flujos ni se auditó su contenido completo.

Las 15 skills del proyecto también aparecen en el catálogo de esta sesión. Los enlaces siguientes identifican su ubicación exacta y propósito. Se ha leído cada SKILL.md; las referencias adicionales consultadas se enumeran después de la tabla.

Skill y ubicación	Propósito y aplicación a la ficha	Compatibilidad y límites
ux-design-review	Contextualizar una revisión integral y consolidar hallazgos sin duplicarlos.	Principal para este informe; parcial por ausencia de auditores/política. No sustituye pruebas.
ux-dashboard	Jerarquizar por tarea, agrupar relaciones y reducir sobrecarga.	Muy útil aunque esta ficha sea un resumen operativo y no un panel analítico. No introducir gráficos ni más estadísticas.
frontend-design	Composición intencionada, jerarquía, contención decorativa y crítica mediante capturas.	Aplicar dentro de DESIGN.md; no cambiar Inter/paleta ni introducir un hero.
shadcn	Reutilizar primitivas, variantes, tokens y composición accesible.	Base UI/Vega verificado. Preferir wrappers rdx-ui; no regenerar ni modificar vendor.
ux-tables	Lectura, alineación, densidad y elección entre tabla/lista.	Directa en perfiles y relaciones. El patrón compacto de Metis prevalece sobre ordenar/paginar todo.
ux-navigation	Orientación, breadcrumb, rutas reales y adaptación por capacidad.	Cabecera móvil y acceso a entidades; conservar shell y BrowserLink.
ui-ux-pro-max	Catálogo local de pautas UX, responsive y accesibilidad.	Apoyo dirigido; filtrar por plataforma/versión y no generar un design system alternativo.
ux-empty-states	Explicar ausencia y ofrecer siguiente paso sin saturar.	Aplicable al puesto sin ordenador y recursos vacíos; `EmptyState` ya existe.
ux-error-recovery	Errores recuperables, conservación de trabajo y feedback contextual.	Preservar reintento, caché y distinción entre fallo/ausencia. No añadir undo sin soporte funcional.
ux-inputs-and-forms	Etiquetas, agrupación, validación y envío.	Útil si se modifica edición/renombrado; no es prioridad del layout de consulta. El patrón de diálogos prevalece.
ux-microcopy	Etiquetas breves, consistencia y explicación de estados.	Acciones y mensajes es/en, sin perder fechas exactas ni vocabulario del dominio.
ux-notifications-and-toasts	Ajustar canal y urgencia; evitar avisos repetidos.	Apoyo para actualización/error; un contador de relaciones no es una notificación de no leídos.
ux-search	Búsqueda, filtrado y recuperación sin resultados.	Condicional para vistas completas/selectores; no añadir buscador a cada tarjeta compacta.
vercel-composition-patterns	Composición y separación entre estado/presentación sin proliferación de flags.	React 19 compatible; útil al separar resumen/gestión de soporte. No exige Context ni un framework de widgets.
vercel-react-best-practices	Evitar estado derivado, trabajo redundante y cargas secuenciales innecesarias.	Aplicar parte React/Vite y TanStack Query. No copiar APIs Next.js/RSC/SWR ni optimizar sin medición.

Referencias de skills y búsquedas realmente consultadas

shadcn: Base frente a Radix, composición y estilos. Se contrastaron con Button, Badge, Collapsible y Popover instalados, y con apps/web/components.json. No se ejecutó CLI upstream ni se descargaron ejemplos.
Composición: evitar flags y separar gestión de estado. La segunda no justifica añadir un provider donde basten props.
React: estado derivado durante render y operaciones independientes. No se diagnostica una regresión de rendimiento a partir de estas guías.
Pro Max: quick-reference, especialmente accesibilidad, interacción, responsive y tipografía; se comprobó el alcance nativo de pro-rules.md y se descartó como norma web. Se inspeccionó scripts/search.py y se ejecutaron búsquedas locales sin --persist.
badge chip label wraps --domain ux: devolvió Compact Label Overflow, pertinente para etiquetas compactas, y Contextual Live Badge Updates, aplicable solo a anuncios contextuales. No demuestra que los badges actuales se recorten.
responsive container overflow --stack react: resultados sobre separación presentación/datos y objetos inline; no responden al problema de capacidad. La reformulación container query overflow --stack html-tailwind devolvió recomendaciones para Tailwind 4.3, mientras Metis declara 4.2.2. No se utiliza esa respuesta para recomendar APIs 4.3. La propuesta responsive procede del patrón local y del código, no de un supuesto match válido de esa búsqueda.

Solapamientos, contradicciones y ausencias

ux-design-review remite a ux-heuristics-audit, ux-microcopy-audit, ux-dark-patterns-audit, ux-accessibility-audit, ux-aesthetics-audit, ux-information-architecture-audit y ux-mobile-responsiveness-audit: no localizadas entre las skills instaladas. Tampoco existe docs/orchestration-policy.md. No se ejecutaron esos auditores ni se instalaron. La revisión directa cubre usabilidad, microcopy, aplicación visual, semántica, teclado y capacidad dentro de los límites de §4. No hay flujos de conversión/precios/consentimiento en el alcance que justifiquen una auditoría específica de patrones oscuros.

Hay solapamiento deliberado: dashboard decide qué merece prominencia; frontend-design revisa cómo se expresa; tables concreta filas; shadcn comprueba primitivas. La guía integral consolida los resultados. No acumular todos los checklists en cada iteración.

Las recomendaciones genéricas quedan subordinadas a DESIGN.md, listados compactos, listados de entidades, diálogos y estructura frontend:

frontend-design sugiere explorar fuentes/colores y evitar mayúsculas; Metis conserva Inter, tokens y títulos de grupo establecidos.
ux-tables propone acciones al hover y controles de colección a la derecha; Metis exige accesibilidad sin hover y selección inicial en PickerList. Sus herramientas de exploración no se trasladan automáticamente al resumen compacto.
ux-inputs-and-forms propone una columna y marcas de opcionalidad; Metis define container queries, columnas justificadas, asterisco al final y ausencia de «opcional». Tampoco se aplican defaults contra la ayuda sin autocompletado establecida por el proyecto.
Pro Max mezcla tamaños nativos y web: no convertir 44 pt/48 dp en requisito universal para botones web de 32 px. Evaluar área efectiva, separación y contexto táctil. No virtualizar automáticamente por alcanzar 50 filas.
shadcn contiene instrucciones de instalación y regeneración incompatibles con la restricción de vendor de esta tarea. Su ejemplo asChild de Radix tampoco corresponde a Base UI: aquí se usa render.

3. Implementación actual y patrones compartidos

Mapa de código y responsabilidades

Las líneas corresponden al árbol leído durante la auditoría; pueden desplazarse en entregas posteriores.

Referencia	Ubicación y líneas	Responsabilidad observada
E01	workstation-detail-page.tsx, 43–189	Breadcrumb, carga/no encontrado, nombre, metadatos, acciones y montaje de diálogos independientes.
E02	workstation-detail-content.tsx, 44–138	Primera banda Equipamiento/Pendientes desde 900 px de contenedor; segunda banda 1,6:1 desde 1000 px. Software, soporte y último cambio apilados a la derecha.
E03	workstation-assets.tsx, 38–132	Listado de miembros, principal identificado, estados técnico/uso, edición y preview de cinco.
E04	workstation-profiles.tsx, 74–280	Tabla compacta, archivados, alta, preview y detalle único. A ≤600 px de su panel oculta columnas y reproduce sus datos dentro de la identidad.
E05	workstation-profile-configuration-details.tsx, 28–111; workstation-configuration-family.tsx, 51–101	Filtro pendientes, foco, cinco familias, estados, detalles de cobertura y enlaces a gestión.
E06	workstation-support.tsx, 23–120; asset-support.tsx, 32–140	Soporte del ordenador y contexto remoto de la persona del perfil; incluye alta, retirados y tres acciones por registro.
E07	workstation-software.tsx, 27–124	Software del ordenador, licencias, preview y gestión en diálogo.
E08	workstation-latest-change.tsx, 18–69; workstation-pending-configurations.tsx, 20–72	Diferencias verificables e historial; pendientes conocidos/desconocidos y acción contextual.
E09	use-workstation-detail-controller.ts, 16–75	Queries, principal confirmado, perfil expandido, contexto de soporte y total de pendientes.
E10	detail-panel.tsx, 6–60; compact-list-item.tsx, 4–34; compact-table.tsx; collection-preview.tsx	APIs existentes: `density`, `count`, `actions`, metadatos, tabla semántica, expansión accesible. No conocen DTOs ni endpoints.
E11	workstation-name-editor.tsx, 18–145; workstation-actions.tsx, 31–54	Renombrado con borrador local; editar/historial/ciclo de vida.
E12	workstation-dashboard-skeleton.tsx, 7–37; workstation-query-feedback.tsx, 20–52	Carga geométrica inicial y feedback por fuente con reintento.

Sistema visual efectivo

Manifests inspeccionados: React 19.2.5, TanStack Query 5.98.0, Tailwind 4.2.2, Base UI 1.8.0 y CLI shadcn 4.21.1. La SPA utiliza Vite, rsc:false, estilo base-vega; no Next.js. @repo/rdx-ui compone las primitivas de @repo/shadcn-ui.

Los tokens proceden de globals.css vendor, 17–21 y 152, y de global.css de la app, incluida Inter en línea 59. text-base equivale aquí a 14 px; no asumir 16 px. La ficha observada usa primario rojo en enlaces/acciones, superficies claras, paneles sin sombra, iconos Tabler y acentos del shell verde oscuro/turquesa. La descripción histórica de una versión azul en workplace-dashboard-implementacion.md no describe por sí sola el render actual: las capturas actuales muestran rojo. No se propone restaurar el azul.

DetailPanel density="compact" aplica py-4, px-4, gap-3, rounded-lg, título seminegrita y región nombrada. CompactListItem permite salto de línea y coloca metadatos a 12 px. Button sm/icon-sm mide 32 px; default, 36 px. Badge tiene texto sin salto y altura 20 px. Son APIs reales, no ejemplos de una skill externa.

Comparación con otras fichas

AssetDetailPage, 35–104: retorno explícito, h1 de 24 px, identidad con icono, metadatos y acciones. Su cabecera con superficie propia es una variante existente, no una obligación de añadir otra tarjeta al puesto.
PersonDetails, 52–118: identidad con avatar, metadatos y edición explícita. Su h2 y sus confirmaciones nativas existentes no se convierten en modelo normativo para una ficha nueva.
ResourceDetail, 29–78: DetailField, FieldSections, relaciones y revisiones. No importar su historial entero en cada resumen de puesto.
CompanyDetail, 41–63 y 89–137: shell/contexto de compañía y navegación responsive compartidos. La ficha debe aprovechar el espacio que recibe, sin alterar la política de sidebars.

La comparación entre otras entidades es estática; no se hizo una nueva auditoría visual completa de Personas/Recursos. El preparador sí abrió listado, detalle y edición del activo como comprobación básica del entorno.

4. Diagnóstico UI/UX y evidencias

Método, entorno y alcance real

Se ejecutó el procedimiento existente de Playwright MCP: comprobación WSL/Docker, preparador visual-audit.py, volumen y fixtures de puestos. Origen temporal anunciado por Vite y alineado con APP_ORIGIN: http://localhost:39233. Chromium 155.0.8059.12 dentro de la imagen fijada; usuario ordinario con login real. La configuración de proyecto funcionó mediante el cliente stdio MCP existente. También se comprobó que la herramienta directa de navegador de la sesión responde; el recorrido autenticado utilizó el cliente stdio con la sesión privada del preparador.

Las capturas conservadas contienen únicamente datos sintéticos. No se copian .env, credenciales, cookies, sesiones ni logs privados a docs. Los scripts ad hoc de observación se ejecutaron desde /tmp; no modifican código de producción.

Volumen preparado: 15 compañías y, en la principal, 59 personas, 135 activos, 73 recursos, 55 puestos y 64 perfiles; el escenario denso contiene 80 miembros y 60 perfiles (50 activos y diez archivados). El resultado efectivo se conserva en comprobaciones.json. El escenario principal y los de vacío/desmantelado complementan al denso. Tener este volumen no equivale a haber probado todos los filtros ni rendimiento de carga.

Evidencia	Observación
Principal 1600×1000, 1440×900	Dos columnas, identidad legible y jerarquía de paneles reconocible. Equipamiento y Pendientes no tienen el mismo ancho que los dos paneles inferiores por decisión previa.
Principal 1024×768, tablet 768×1024, móvil 390×844	Reflujo a una columna y adaptación del shell; sin desbordamiento global medido en esos estados.
Principal estable 1280×900	Captura repetida tras esperar enlaces de perfil y software. La banda de perfiles ocupa todo el ancho, al no alcanzar su contenedor los 1000 px para dividirla.
Configuraciones 1440	Detalle integrado sin otro selector; carpeta presenta varias líneas de datos técnicos y cobertura. Soporte combina consulta y numerosos controles.
Perfiles móvil, configuraciones móvil	Atributos apilados y expansión accionada con Enter. Rutas/cuentas largas ajustan línea; las señales de estado permanecen visibles.
Resumen denso, 50 perfiles ampliados	Preview de cinco accesible; ampliación real a 50 filas. No se recomienda convertir el resumen en otro inventario.
Puesto vacío, desmantelado	El equipamiento vacío ya orienta y ofrece editar; otras tarjetas repiten la dependencia del ordenador principal.
Edición	Formulario modal existente abierto y cancelado, sin guardado. Escape cierra y devuelve foco a Editar puesto.
Mediciones	Geometría por sección, hashes de PNG, filas y comprobaciones de foco.
Puesto inexistente, fallo inicial de inventario, comprobaciones suplementarias	Inexistente conserva breadcrumb; fallo 503 simulado presenta error y Reintentar. Consulta de inventario de otra compañía devuelve 200 sin el puesto principal ni activos. Esta muestra no equivale a una auditoría exhaustiva de autorización.

Una captura inicial de 1280 px se tomó durante una transición y resultó blanca; se descarta como prueba de defecto visual. No se usa para diagnosticar una pantalla vacía. Se repite la observación esperando datos representativos, sin atribuir el fallo del recorrido al producto.

Hallazgos por perspectiva

Perspectiva	Hallazgo verificado	Interpretación y prioridad
Jerarquía	A 390 px el breadcrumb repite el nombre largo, el título ocupa tres líneas y los metadatos se reparten en varias filas. Equipamiento comienza en Y=437 y Perfiles en Y=835. E01/E11.	Oportunidad de compactar orientación móvil; no un fallo de acceso ni un título ilegible. P0/M01.
Composición	A 1440 px, Soporte mide 798 px frente a 269,5 px de Personas y perfiles, con una conexión de soporte y una remota. Último cambio empieza en Y=1461. E02/E06.	El panel contextual dedica mucho peso a gestión/explicación; resumir sin ocultar acciones. P0/M02.
Exploración	En 1440 px, Personas y perfiles recibe unos 657 px y cinco columnas; el nombre de la persona ocupa varias líneas. En móvil la tabla conserva datos mediante representación apilada. E04.	Hay adaptación existente; la mejora es ajustar jerarquía/capacidad y no eliminar columnas sin alternativa. P1/M03.
Complejidad	El detalle de carpeta muestra ruta, unidad, permisos, cuenta y dos coberturas en la misma fila extensa; las cinco familias siguen una estructura estable. E05.	Escanear estado/nombre primero y revelar metadatos secundarios de forma accesible. Propuesta de diseño, no defecto de datos. P1/M04.
Acciones	Editar puesto se ofrece en cabecera y Equipamiento; historial en cabecera y Último cambio. E01/E03/E08.	La duplicación de edición es visible; la de historial puede ser útil al desplazarse. Revisar cada función, sin retirar accesos por simetría. P1/M05.
Volumen	Los previews muestran cinco elementos y un botón con el total al final; `DetailPanel.count` existe pero los paneles de relaciones no lo usan. E03/E04/E10.	Hacer explícito el alcance del resumen desde la cabecera; no añadir métricas decorativas. P1/M06.
Vacío	Sin principal, Perfiles, Software y Soporte explican por separado el mismo requisito. E04/E06/E07 y captura vacía.	Reducir reiteración manteniendo las secciones y motivos de acciones deshabilitadas. P1/M07.
Coherencia de estados	Pendientes y avisos de revisión emplean `amber-*`; otras configuraciones usan Badge/EntityStatus. E05/E07/E08.	Diferencia estática de recetas; no se ha demostrado contraste insuficiente. Proponer coherencia sin inventar semántica de salud. P2/M08.
Carga	Skeleton usa una cuadrícula uniforme de seis paneles a 1000 px; contenido real tiene dos bandas a 900/1000 y la columna secundaria apilada. E02/E12.	Riesgo estático de transición geométrica. No hay medición de CLS ni captura controlada de carga; validarlo antes de afirmar salto perceptible. P2/M09.

Lo que funciona y debe preservarse

Un h1 para el puesto; regiones nombradas, h2 de paneles y h3/h4 del detalle. Tablas HTML y cabeceras scope="col"; listas ul/li. Iconos decorativos ocultos.
Enlaces reales a activos/personas/perfiles/recursos; acciones explícitas para expandir y abrir modales. Los botones de expansión tienen nombre con perfil, aria-expanded y aria-controls.
Ordenador principal una sola vez y primero; plantilla, estado técnico y uso independientes. No reintroducir las antiguas tarjetas retiradas.
Perfiles y configuraciones integrados; la selección no depende de otro selector duplicado. Responsable/contexto vive en la cabecera y Popover, no en otra tarjeta redundante.
Se comprobó por teclado el acceso a pendientes: foco en #workstation-configurations y filtro activado. Se comprobó cierre de edición por Escape y retorno al disparador. No se guardó ningún formulario de negocio durante la inspección.
Total desconocido distinto de cero; errores con reintento; queries con claves centralizadas y datos previos. El principal se verifica dentro de la composición del puesto antes de habilitar fuentes dependientes.

Límites de la verificación

No se certifica accesibilidad. No se ejecutaron lector de pantalla, medición exhaustiva de contraste, zoom 200/400 %, modo oscuro, orientación apaisada móvil ni benchmark de rendimiento. Se revisaron nombres/semántica por código y se probaron interacciones concretas de teclado/foco; no todo el recorrido Tab de cada formulario. Los breakpoints se observaron en resoluciones representativas, sin barrido exhaustivo de cada píxel alrededor de 600/900/1000 px de contenedor.

Los errores iniciales de selectores del recorrido se corrigieron según el texto real de i18n. No constituyen fallos del producto. La validación de datos anteriores tras refetch, reintento de cada una de las fuentes, renombrado guardado y ciclo de vida completo queda fuera de esta pasada; existen suites previas, cuya existencia no equivale a haberlas ejecutado hoy.

5. Matriz de skills recomendadas

Prioridad referida al plan de pulido, no a severidad de la skill.

Skill	Disponibilidad	Aplicación concreta	Impacto esperado	Prioridad
ux-dashboard	Instalada	Orden y peso de cabecera, soporte y relaciones; M01/M02/M07	Alto	P0
frontend-design	Instalada	Revisar alineación, densidad y ritmo sin otra paleta; M01–M04	Alto	P0
shadcn	Instalada	Contrastar APIs/variantes, estados y overlays existentes; M02/M04/M08	Alto	P0
ux-navigation	Instalada	Orientación móvil y acceso explícito a gestión/entidades; M01/M02	Alto	P0
ux-tables	Instalada	Identidad, metadatos, estados y capacidad del panel; M03/M06	Alto	P1
ux-design-review	Instalada; dependencias no localizadas	Consolidar revisión de cada fase y distinguir evidencia/propuesta	Medio	P1
ui-ux-pro-max	Instalada	Consultas puntuales de overflow, foco y anuncios, filtradas por versión	Medio	P1
ux-empty-states	Instalada	Puesto incompleto y consolidación de ayudas; M07	Medio	P1
ux-microcopy	Instalada	Etiquetas específicas y motivos breves es/en; M01/M05/M07	Medio	P1
vercel-composition-patterns	Instalada	Resumen y gestión de soporte con composición explícita; M02	Medio	P1
ux-error-recovery	Instalada	Conservar contexto, mensajes y reintento durante cambios	Medio	P1
ux-inputs-and-forms	Instalada	Solo si se toca el modal; mantener contrato de campos y validación	Bajo	P2
ux-notifications-and-toasts	Instalada	Feedback contextual sin avisos duplicados; M08/M09 si procede	Bajo	P2
vercel-react-best-practices	Instalada	Evitar duplicar queries/estado; optimizar solo con medición	Bajo	P2
ux-search	Instalada	Vista completa o selector si hace falta explorar; no buscador por tarjeta	Bajo	P2
ux-accessibility-audit, ux-mobile-responsiveness-audit, ux-information-architecture-audit	No localizadas	Auditorías especializadas futuras; no necesarias para ejecutar las verificaciones MCP disponibles	Medio	P1
ux-aesthetics-audit, ux-heuristics-audit, ux-microcopy-audit, ux-dark-patterns-audit	No localizadas	Dependencias del orquestador; no se atribuyen ejecuciones	Bajo	P2

Las cinco primeras recomendaciones de implementación aportan funciones complementarias:

ux-dashboard: filtra por tarea de soporte: identificar equipo, persona y configuración relevante. Aplicarla en E01/E02/E06, combinada con frontend-design. Resultado esperado: menor peso de información auxiliar sin perder relaciones.
frontend-design: usa estructura visual para expresar prioridad y elimina decoración que no informa. Aplicarla en cabecera, columnas y paneles. Combinada con DESIGN.md y shadcn, permite un acabado más cuidado con las mismas recetas.
ux-tables: decide tabla frente a lista, alinea atributos y trata overflow explícitamente. Aplicarla a E03/E04/E05 con el patrón compacto. Resultado: lectura más rápida de identidades y estados, conservando comparación en escritorio.
shadcn: prioriza componentes existentes, variantes y composición Base UI correcta. Aplicarla al resumen de soporte, disclosure, estados y modales con rdx-ui. Resultado: coherencia y accesibilidad de las primitivas sin mantenimiento paralelo.
ux-navigation: mantiene orientación y destinos reconocibles en tamaños reducidos. Aplicarla a breadcrumb/cabecera y accesos de gestión, combinada con microcopy. Resultado: menos repetición móvil y acciones con contexto claro, preservando URL/retorno.

6. Propuestas priorizadas por impacto y esfuerzo

Las skills respaldan principios, no estas geometrías exactas. Todas las soluciones concretas M01–M09 son propuestas propias de esta auditoría, pendientes de diseño y validación. Estimaciones orientativas para una persona familiarizada con el proyecto; incluyen implementación y comprobación dirigida, no investigación con usuarios ni cierre de toda la deuda global.

P0 — Mejoras visuales prioritarias

M01. Compactar la orientación y cabecera en móvil

Problema/evidencia: nombre repetido en breadcrumb y h1, metadatos en varias filas; Perfiles queda en Y=835 a 390 px. E01, líneas 55–149; E11, 90–107; captura móvil.
Solución: probar breadcrumb móvil con retorno directo a Puestos de trabajo y sin repetir el nombre actual; conservar h1 completo. Agrupar metadatos con una receta más compacta y evitar repetir visualmente la compañía cuando la franja contextual ya la identifica, manteniéndola accesible si procede. Conservar estado, sede y responsable a la vista. No reducir tipografía para ganar altura.
Skills: ux-navigation (orientación/jerarquía), ux-dashboard (prioridad), frontend-design (composición), microcopy como apoyo.
Componentes: WorkstationDetailPage; WorkstationNameEditor solo si la prueba demuestra que necesita un ajuste local, sin cambiar su interacción compartida gratuitamente.
Impacto: alto en móvil; más contenido operativo en el primer recorrido vertical.
Esfuerzo: medio, 0,5–1 jornada.
Riesgos/dependencias: conservar enlaces reales, foco y contexto al entrar directamente; comprobar nombres largos y 320/390/768 px. No alterar el shell ni persistir nuevas preferencias.

M02. Reequilibrar Soporte y acceso remoto como resumen operativo

Problema/evidencia: panel de 798 px a 1440, con alta, filtro de retirados y eliminar/editar/historial por registro, antes del bloque remoto; E06 y captura de configuraciones. No es un error funcional: es exceso de peso relativo para consulta rápida.
Solución: resumen inicial de herramienta, destino, estado registrado, VPN y método preferido mediante CompactList/CompactListItem. Jerarquizar gestión en una acción explícita y trasladar controles extensos a un diálogo independiente reutilizando operaciones existentes; valorar primero composición/reutilización de AssetSupport. Mantener el contexto remoto identificado por persona, sus accesos de gestión y la advertencia de que no se comprueba conexión en tiempo real. No añadir botón Conectar.
Skills: ux-dashboard, ux-tables, shadcn y vercel-composition-patterns.
Componentes: WorkstationSupport, AssetSupport y SupportSummary; posible diálogo específico en support-connections, solo si la composición existente no basta.
Impacto: alto en escritorio y móvil; soporte más escaneable y Último cambio más próximo al resto.
Esfuerzo: medio/alto, 1–2 jornadas.
Riesgos/dependencias: AssetSupport tiene otros consumidores. Evitar flags combinatorios y conservar alta, edición, borrado, historial, retirados, permisos y retorno de foco. No modificar conexión ni contratos.

P1 — Refinamiento de componentes y experiencia

M03. Afinar Personas y perfiles por capacidad del panel

Problema/evidencia: cinco columnas en unos 657 px, nombres de varias líneas; a ≤600 px la celda de identidad incorpora persona/cuenta/estado. E04, 134–260; capturas 1440 y móvil. La adaptación actual conserva contenido; no se califica como tabla rota.
Solución: comparar la distribución actual con una fila que dedique más ancho a identidad/persona y compacte el resumen/acción de configuraciones. Definir el cambio por ancho real del panel; mantener etiquetas cuando se apilan los atributos. Conservar el indicador de expansión, las acciones Ver/Ocultar y una única representación accesible. No introducir truncamiento silencioso, avatares mayores ni eliminar cuentas.
Skills: ux-tables, frontend-design, shadcn; Pro Max solo para criterios concretos de overflow.
Componentes: WorkstationProfiles, WorkstationProfilePerson y, únicamente si hay necesidad genérica demostrada, CompactTable.
Impacto: alto en lectura de relaciones; esfuerzo medio, 0,5–1 jornada.
Riesgos: ID/foco del perfil seleccionado, archivados, preview y activación por teclado. Comprobar el borde de 600 px, no solo viewport 600.

M04. Jerarquizar los metadatos de configuraciones

Problema/evidencia: carpeta con múltiples líneas de ruta/cuenta/permisos/coberturas compite con el resto de familias; E05, familia 70–95 y captura de configuraciones.
Solución: mantener nombre, estado y señales de revisión/cobertura visibles; agrupar detalles técnicos bajo disclosure explícito cuando sean extensos, usando primitivas existentes y dl. Conservar acceso íntegro a ruta, cuenta y notas. No resumir cobertura documental como permiso efectivo ni fusionar aplicación de perfil con software instalado.
Skills: ux-dashboard, ux-tables, shadcn y frontend-design.
Componentes: WorkstationConfigurationFamily y WorkstationProfileConfigurationDetails; evaluar Collapsible/DetailSection existentes antes de añadir una abstracción.
Impacto: medio/alto en perfiles poblados; esfuerzo medio, 0,5–1 jornada.
Riesgos: no ocultar incidencias ni mover el filtro a un contenido plegado; preservar nombre accesible y gestión por familia/perfil. Verificar rutas largas y modo Solo pendientes.

M05. Clarificar acciones repetidas y su ámbito

Problema/evidencia: Editar puesto aparece en cabecera y Equipamiento (E01/E03/E11); gestionar software puede saltar de fila por la longitud del título. Historial también tiene dos puntos de entrada, con finalidad contextual válida.
Solución: conservar Editar puesto en cabecera y probar una etiqueta contextual más específica en Equipamiento, como «Cambiar equipamiento», que abre el editor existente sin simular un flujo nuevo. Si ese cambio no describe con precisión el modal completo, conservar la etiqueta y reducir su prominencia, o retirar únicamente la duplicación poblada. Mantener CTA del estado vacío. Alinear acciones de sección con el título cuando haya capacidad y permitir una fila inferior intencionada cuando no la haya. Conservar el historial contextual hasta comprobar su utilidad.
Skills: frontend-design, ux-microcopy, shadcn y ux-navigation.
Componentes: WorkstationAssets, WorkstationSoftware, cabeceras DetailPanel; cambios compartidos solo si se justifican para todos sus consumidores.
Impacto: medio; esfuerzo bajo/medio, 0,5 jornada.
Riesgos: no prometer edición limitada si el modal es completo; traducciones es/en, foco y acciones deshabilitadas. No sustituir todo por iconos sin etiqueta.

M06. Explicar el alcance del preview desde su cabecera

Problema/evidencia: el total del denso se conoce al llegar a Mostrar todos (80)/(50); los paneles no usan DetailPanel.count. E03/E04/E10 y captura densa.
Solución: aportar contador conocido en Equipamiento y Perfiles mediante la API existente; describir «5 de 50 perfiles activos» cuando corresponda, diferenciando archivados. Mantener Mostrar todos/menos y acceso a cada elemento, sin barras de herramientas de inventario. No mostrar cero si la fuente todavía no es fiable.
Skills: ux-tables y ux-dashboard; ux-microcopy para alcance y pluralización.
Componentes: WorkstationAssets y WorkstationProfiles; CollectionPreview solo si la semántica requiere una ampliación reutilizable con consumidor real.
Impacto: medio, especialmente con volumen; esfuerzo bajo, 0,25–0,5 jornada.
Riesgos: no sumar activos/archivados indebidamente ni alterar la selección que puede añadirse fuera de las primeras cinco filas. La cifra es contexto de colección, no KPI ni badge de notificación.

M07. Reducir repetición en el puesto incompleto

Problema/evidencia: tres paneles repiten la dependencia del principal, mientras el vacío de Equipamiento ya explica cómo completar el puesto. E04/E06/E07 y captura vacía.
Solución: mantener Equipamiento como siguiente acción principal; agrupar visualmente la explicación compartida o abreviarla en los paneles dependientes. Mantener títulos, estados y razón de alta deshabilitada. Diferenciar «sin ordenador», «sin perfiles» y «fuente no disponible». No colapsar automáticamente una tarjeta que contiene errores o acciones útiles.
Skills: ux-empty-states, ux-dashboard, ux-microcopy y ux-error-recovery.
Componentes: WorkstationDetailContent, WorkstationProfiles, WorkstationSoftware y WorkstationSupport; reutilizar EmptyState.
Impacto: medio; esfuerzo medio, 0,5–1 jornada.
Riesgos: conservar significado de cero pendientes y estado desmantelado. No borrar información ni transformar el vacío en un wizard obligatorio.

P2 — Pulido final

M08. Homogeneizar la representación de estados y avisos

Problema/evidencia: amber fijo en pendientes/revisión, Badge en familias y EntityStatus binario en software; E05/E07/E08. Hallazgo de código y recetas, no fallo de contraste probado.
Solución: acordar dentro del sistema existente la representación de pendiente, configurado, revisión y total desconocido; mantener texto además de color. Priorizar variantes/token ya disponibles, sin dar a active=false el significado genérico de fallo. Medir los pares efectivos antes de decidir cambios. No crear tokens globales de warning/success en vendor.
Skills: shadcn, ux-microcopy y Pro Max como apoyo dirigido.
Componentes: WorkstationPendingConfigurations, WorkstationConfigurationFamily, WorkstationSoftware; reutilizar Badge/EntityStatus donde encaje su contrato.
Impacto: medio de coherencia; esfuerzo bajo/medio, 0,5 jornada.
Riesgos: no cambiar estados de negocio ni hacer indistinguibles revisión y pendiente. Modo oscuro y contraste requieren nueva prueba; no están certificados aquí.

M09. Acercar la carga inicial a la composición final

Problema/evidencia: E12 usa una cuadrícula uniforme, distinta de las dos bandas y la pila lateral de E02. Riesgo estático, sin CLS demostrado.
Solución: reutilizar geometría de bandas en el skeleton con alturas aproximadas por responsabilidad, evitando una nueva capa genérica. Simular demora de inventario para decidir si el cambio merece implementación y verificar que los paneles parciales siguen informando de su fuente.
Skills: frontend-design, shadcn y ux-error-recovery; React como revisión técnica.
Componentes: WorkstationDashboardSkeleton y WorkstationQueryFeedback; no cambiar consultas por motivos visuales.
Impacto: bajo/medio de calidad percibida; esfuerzo bajo, 0,25–0,5 jornada.
Riesgos: no fijar alturas finales que recorten datos ni retrasar contenido disponible; sin animaciones de entrada adicionales ni esperas arbitrarias.

7. Componentes que reutilizar o modificar

Primero modificar composición específica en modules/companies/src/web/workstations/detail/ui/. Reutilizar DetailPanel, CompactTable, CompactList, CompactListItem, CollectionPreview, EmptyState, DetailField, DetailSection, FormDialog y FormActions cuando su API cubra la tarea; comprobar cada contrato al implementar. DetailPanel ya admite contador y acciones: no duplicar su cabecera.

Reutilizar Button, Badge, Collapsible, Popover, Tooltip, Skeleton y Dialog del vendor mediante sus APIs públicas y wrappers. La existencia de primitivas no autoriza editarlas ni regenerarlas. No se propone instalar Accordion, charts o un grid externo para resolver estas mejoras.

Conservar WorkstationNameEditor, WorkstationActions, WorkstationEditorDialog, WorkstationHistoryDialog, WorkProfileEditorDialog y WorkstationSoftwareDialog. La oportunidad de soporte se resuelve componiendo operaciones existentes; no copiando su implementación ni trasladando DTOs/queries a rdx-ui.

Actualizar posteriormente docs/componentes-de-interfaz.md y el patrón correspondiente solo si cambia un contrato real. Esta auditoría no los reescribe ni presenta propuestas como capacidades actuales.

8. Riesgos y aspectos que preservar

El árbol de trabajo ya contenía modificaciones ajenas en controllers, listados, búsqueda y rdx-ui. Se audita ese estado, no una revisión Git limpia. Esos cambios se conservan; no se atribuyen a este encargo.
El hueco entre Equipamiento y Pendientes, sus umbrales 900/1000 y la proporción inferior 1,6:1 están documentados como decisiones previas. No son por sí mismos defectos ni se propone rellenarlos con estadísticas. Cualquier cambio futuro exige comparar una alternativa concreta con la composición actual.
No recuperar tarjetas ya retiradas de ordenador, responsable/contexto o selector de perfiles. La documentación contiene etapas históricas; se contrasta con código activo y con las últimas secciones WD04.1–WD04.3 de la implementación.
Mantener aislamiento por compañía, principal dentro de miembros, perfiles del ordenador, responsable distinto de persona del perfil, permisos y estados de ciclo de vida. El soporte documenta disponibilidad, no presencia ni conexión activa. La cobertura no acredita permiso SMB efectivo.
Preservar rutas reales, Ctrl/clic modificado, acceso directo, retorno y selección; evitar acciones ocultas solo al hover, filas convertidas en botones o reordenación CSS distinta del DOM.
Los vacíos en celdas siguen siendo «—», sin convertir cero/false/estado real en ausencia. Los mensajes de colección vacía y «Sin responsable» fuera de una celda tienen otra función.
No modificar datos, API, migraciones, dependencias, vendor ni archive/. Cualquier cambio compartido futuro se valida también en sus otros consumidores.

9. Plan incremental de implementación

Fase	Alcance concreto	Verificación antes de seguir
0. Acordar composición	Comparar wireframes de cabecera móvil y soporte con las capturas actuales; elegir M01/M02 y confirmar qué información se mantiene visible.	Revisar nombres largos, ámbito de acciones y restricciones de Metis. No elegir una nueva paleta.
1. Cabecera	M01 aislada, con sus traducciones y enlaces.	320/390/768 y escritorio, foco y retorno al listado; comparar altura útil.
2. Soporte	M02 con resumen y gestión existente accesible; sin cambios en consultas/modelo.	Lectura de destino/VPN/estado, alta/edición/historial/retirados, cancelación y foco; datos parciales.
3. Relaciones	M03/M04/M06, una mejora por revisión; conservar límites de preview.	Dos perfiles, 50 activos/10 archivados, 80 miembros, expansión/contracción, teclado, rutas largas y Solo pendientes.
4. Coherencia	M05/M07, comprobando poblado/vacío/desmantelado.	Acciones disponibles y explicación de bloqueos; no duplicación de mensajes ni pérdida de acceso.
5. Pulido	M08/M09 solo tras comprobar pares de color y transición real.	Tema claro/oscuro, red lenta simulada, cero/desconocido/errores/refetch y reducción de movimiento.

Combinación recomendada: ux-dashboard como principal para composición, frontend-design + shadcn en las fases 1–2; ux-tables como principal en la fase 3, con shadcn y navegación; empty-states/microcopy al concretar vacíos/acciones. Usar ux-design-review para consolidar evidencias al cerrar cada fase, declarando auditores ausentes. Consultar composición/React cuando haya decisiones técnicas reales, no como motivo para refactorizar el módulo entero.

10. Criterios de aceptación y validaciones

Criterios para el futuro cambio

Identidad completa y acciones principales reconocibles; orientación móvil compacta sin perder compañía, sede, responsable ni acceso al listado. El puesto con nombre largo no introduce overflow global.
Soporte permite localizar herramienta/destino/estado/VPN sin recorrer todos los controles de gestión. Las operaciones actuales continúan disponibles con foco/cancelación correctos.
Equipamiento conserva principal único, orden y estados técnico/uso. Perfiles conserva persona, cuenta, activo/archivado y expansión explícita, con etiquetas en distribución estrecha.
Preview explica número mostrado/total fiable y permite acceder a 80 miembros y 50 perfiles activos; archivados diferenciados, sin truncar registros ni perder selección.
Configuraciones conservan familias, estados, notas y cobertura; ningún disclosure oculta incidencias relevantes ni reemplaza desconocido por cero. Sus enlaces conservan perfil/compañía.
Vacío, inexistente, sin principal, desmantelado, carga inicial, fallo inicial y refetch con caché tienen mensajes distintos y recuperación apropiada. Probar fuentes secundarias por separado.
Teclado y foco visibles; Enter/Espacio para controles, Escape y retorno al disparador en overlays. Sin acciones exclusivas de hover; contrastes efectivos y áreas de interacción comprobados.
Validar 1600/1440/1280/1024/768/390/320 px y capacidad alrededor de los umbrales del panel; zoom 200/400 %, modo oscuro y texto largo. Guardar capturas comparables en el mismo escenario sintético.
Sin cambios en API/modelo, nuevas dependencias, vendor o datos reales. Código en inglés, documentación/comentarios en castellano y textos de interfaz es/en. Cambios compartidos documentados y revisados en sus consumidores.

Comandos y comprobaciones de esta entrega

Preflight ejecutado: pwd, git status --short, node --version → v24.20.0 y pnpm --version → 11.25.0; coincide con packageManager y engines.
bash scripts/setup-playwright-wsl.sh: primer intento sin acceso sandbox a Docker; repetido con permisos de ejecución adecuados, correcto. Reutilizó imagen fijada, verificó Chromium y loopback; sin instalación de dependencias.
python3 scripts/visual-audit.py: preparó contenedor/BD exclusivos, API/Vite temporales, login ordinario, 401 sin autenticar, 403 de gestión de usuarios y cancelación del editor del activo.
METIS_PLAYWRIGHT_STORAGE_STATE=<sesión privada> PYTHONDONTWRITEBYTECODE=1 python3 scripts/visual-audit-volume.py: correcto, 15 compañías/50 personas/51 activos/66 recursos antes de ampliar fixtures.
Mismo entorno con python3 scripts/workstation-dashboard-fixtures.py: correcto, 59 personas/135 activos/73 recursos, 80 miembros y 60 perfiles en el denso.
Recorridos MCP ad hoc: capturas y geometría en seis resoluciones, ampliación a 50 perfiles, pendientes por teclado y cierre de edición con retorno de foco. Una captura transitoria se descartó y se repitió; un selector con etiqueta incorrecta se corrigió. No se guardaron ediciones.
No se ejecutaron pnpm typecheck, pnpm lint, pnpm test, pnpm check ni pnpm build: se añaden documentación y evidencias, sin cambios de código. Los resultados históricos del repositorio no se presentan como validaciones actuales.

Las comprobaciones suplementarias, la revisión final de enlaces y la retirada del entorno se registran a continuación.

Cierre de evidencias

Se conservan 16 PNG y dos JSON sanitizados en docs/auditorias/ficha-puesto-trabajo/. Los 16 hashes SHA-256 registrados coinciden con sus PNG. Se comprobaron 74 enlaces locales del documento: todos resuelven. Ambos JSON se parsearon y se comprobó la ausencia de campos de sesión/credenciales. git diff --check terminó correctamente; no sustituye la revisión de archivos nuevos, cuyos enlaces y evidencias se verificaron expresamente.

La repetición estable a 1280 px registró bodyWidth=1280, dos filas de perfil y captura con datos. Los seis anchos observados no mostraron overflow global en los escenarios principales comprobados. No se generaliza ese resultado a todos los estados ni al zoom. El inventario de la otra compañía no contiene el puesto principal ni activos; no se realizó una prueba exhaustiva de permisos entre todas las compañías.

La preparación terminó con 15 compañías y, en la principal, 59 personas, 135 activos, 55 puestos, 73 recursos y 64 perfiles, consultados mediante HTTP real. Se comprobó expansión de cinco a 50 perfiles activos. No se probó aquí la expansión de los 80 miembros ni los diez archivados, la ordenación o los filtros de las vistas completas.

El preparador confirmó retirada de su entorno y se verificó que su session.json ya no existe. Incidencia de limpieza: el filtro de procesos por el comando exacto python3 scripts/visual-audit.py coincidió con dos PID y envió SIGINT a ambos. Solo uno correspondía al entorno identificado de esta auditoría; el segundo también recibió la señal y pudo cerrar otra preparación temporal. No se afirma que la limpieza afectara exclusivamente al proceso propio. No se ejecutaron limpiezas globales ni comandos contra bases reales. Para siguientes ejecuciones, conservar y señalizar exclusivamente el PID del preparador iniciado por la tarea, sin seleccionar por nombre de comando.

El árbol de trabajo recibió cambios ajenos adicionales mientras se investigaba. Esta entrega añade exclusivamente este informe y su directorio de evidencias; no revierte ni incorpora como propios esos cambios. No se ejecutó ninguna de las propuestas M01–M09.

51 KiB Raw Blame History Unescape Escape