6.3 KiB
Resumen ejecutivo: dashboard de puesto de trabajo
22 de octubre de 2026. Investigación y documentación; no se ha implementado el dashboard ni generado su mockup definitivo.
Qué representa un puesto
CONFIRMADO: Workstation es un agregado de Assets que organiza un conjunto actual de hasta 200 activos exclusivos, con ordenador principal, responsable y sede opcionales, estado y revisiones. La ficha se compone desde Companies. No representa una persona, un perfil de usuario ni AccessWorkspace.
Relaciones e información disponible
Tiene vínculos directos con compañía, sede, responsable, activos y revisiones. Los perfiles se relacionan indirectamente por el ordenador principal y compañía, y aportan otras personas, cuenta y configuraciones de carpetas, correo, aplicaciones, impresoras y certificados. El equipo aporta software instalado, soporte, directorio, entornos locales y posibles publicaciones SMB. Personas aportan departamentos temporales, teletrabajo, conexiones remotas y procesos.
No todos los permisos de una persona son recursos del puesto. La cuenta de una carpeta puede diferir de la cuenta de inicio de sesión del perfil. Una publicación SMB identifica al servidor publicador, no al consumidor ni una autorización de acceso. La cobertura es documental; no prueba acceso real.
Las fuentes existen en inventario, compañía, perfiles, Access y APIs específicas de configuraciones, remoto/teletrabajo y relaciones tipadas. Los atributos y fuentes y el mapa relacional proporcionan trazabilidad a símbolos y archivos.
Qué muestra la ficha y qué queda disperso
Actualmente ofrece cabecera con estado/sede/responsable, equipamiento, personas y perfiles; pestañas de software e historial; edición, renombrado, alta de perfil y ciclo de vida en componentes propios. No reúne las configuraciones por perfil, cuentas, cobertura de carpetas ni contexto de soporte/remoto/departamento.
Los perfiles inactivos también aportan personas al panel actual. Los activos distintos del principal se llaman periféricos aunque el modelo no impone esa clase. Cambiar ordenador principal cambia perfiles/software visibles, sin trasladarlos. Estas tres distinciones deben conservarse o explicarse en el rediseño. Véase la auditoría de ficha.
Dashboard recomendado
PROPUESTO: cabecera de identidad y acciones; resumen del ordenador y señales registradas de revisión; personas/perfiles; equipamiento compacto; software del principal; configuraciones con perfil de origen; soporte y contexto secundario; último cambio e historial.
La propuesta busca responder qué se atiende, quién lo utiliza, qué tiene configurado y dónde consultar o actuar. Los contadores tienen fórmulas explícitas; no se añaden gráficos sin tarea ni datos. Tickets e intervenciones están archivados y se excluyen de la propuesta actual. No se simula salud ni conectividad online.
Componentes reutilizables: DetailPanel, DetailField, EntityTable, EntityStatus, EmptyState, TimeLine, AssetSummaryCard, acciones/editores de puesto, panel de software y primitivas Base UI/Vega. La lógica buildEnvironment es referencia reutilizable para configuraciones. Su hook agregador exige todas las fuentes, por lo que necesita revisar el tratamiento parcial antes de usarlo en un dashboard. Detalle en arquitectura de información.
Viabilidad y límites
El primer dashboard es viable con APIs existentes y nueva composición de lectura; no se ha demostrado necesidad de un endpoint nuevo. Los riesgos son payloads de compañía con historial, consultas por activo, paginación de relaciones y fallos secundarios que bloqueen toda la vista. No hay mediciones de rendimiento.
Las rutas requieren autenticación y validan pertenencia de entidades a compañía. No se confirmó ACL granular operador–compañía; no debe darse por existente ni deducirse del filtrado frontend. El sistema usa composición explícita de módulos y contratos de relaciones, sin registro dinámico de plugins confirmado para esta pantalla.
Una guía de rutas aún menciona activos compartidos en el puesto; la implementación actual los retira y acepta miembros exclusivos. Se registra la discrepancia sin editar documentación fuera de estos entregables. Más detalles y validaciones: viabilidad técnica.
Decisiones y preparación del mockup
Pendiente confirmar: usuarios activos por defecto frente a archivados, nivel de resumen de configuraciones, alcance de soporte/software sobre otros miembros y utilidad de procesos. La propuesta inicial distingue responsable y uso, se limita al ordenador principal para software/soporte y mantiene configuraciones con su perfil.
Se entregan escenarios y prompt posterior y fixture ficticio, con fuentes de forma DTO separadas de presentación derivada. Hay puestos completo, sin responsable, sin miembros y desmantelado; se especifican además alta densidad, errores parciales y cambio de host. El JSON contiene 1 compañía, 2 personas, 5 activos, 7 recursos, 4 puestos y 4 perfiles. No son datos de una BD ni pruebas de volumen.
Skills consultadas: ux-dashboard, ux-tables, ux-design-review (parcial), shadcn, vercel-composition-patterns y vercel-react-best-practices. Guiaron jerarquía, semántica de tablas, composición, APIs y gestión de consultas. No hay auditores ux-*-audit instalados ni política de orquestación localizada; no se instaló nada.
Playwright MCP está disponible, pero solo se comprobó una pestaña vacía; no hubo origen Vite utilizable confirmado. No se inició API ni se ejecutaron migraciones. La revisión visual, teclado/foco, responsive, accesibilidad y pruebas con al menos 15 compañías/50 personas/50 activos/50 recursos quedan pendientes. Se ha creado únicamente documentación y un fixture ficticio; los cambios locales previos permanecen fuera del alcance.
Validación realizada: 16 bloques de DTO correctos, relaciones y contadores coherentes, proyección Access coincidente; los tres archivos de pruebas dirigidas pasaron. Se comprobaron enlaces locales y referencias a líneas. No se ejecutaron suites globales de aplicación por tratarse de documentación y datos ficticios.