13 KiB
Escenarios y contrato del mockup posterior
Fecha: 22 de octubre de 2026. Son escenarios PROPUESTOS, no recorridos ejecutados en navegador. Fixture: 07-datos-ejemplo.json. Modelo y evidencias: inventario.
Contrato del fixture
El JSON no es un endpoint ni una propuesta de persistencia JSON. Es un contenedor de diseño con bloques metadata, selection, sources, presentation y scenarios. sources conserva formas de DTO existentes; el envoltorio, los estados de pantalla, los contadores y los escenarios son PROPUESTOS. No deben enviarse al servidor como un comando.
Los nombres, personas, compañías, identificadores y direcciones son ficticios. Fecha de referencia fija: 2026-10-22. Los UUID usan forma v7, con sufijos legibles para rastrear referencias; no representan una generación cronológica real. El operador de revisiones es una identidad ficticia, no un usuario creado. Los datos no contienen contraseñas ni credenciales.
Correspondencia de propiedades
La notación [] se aplica a cada elemento; los schemas enlazados en E01–E37 definen cada campo interno. «Disponible» se refiere al contrato de origen, no a que el dashboard ya lo consulte.
| Propiedad | Fuente real / tipo y cardinalidad | Disponibilidad / agregación | Etiqueta |
|---|---|---|---|
metadata |
Sin DTO: objeto de descripción, fecha fija y límites | Solo fixture | PROPUESTO |
selection.companyId, selection.workstationId |
UUID de contexto/ruta; uno de cada | Ya seleccionables en navegador | CONFIRMADO para datos; PROPUESTO para envoltorio |
sources.company |
CompanySchema: objeto con id/name/active y arrays contacts/sites/people/departments/assignments |
GET compañía; ya recibida por ficha | CONFIRMADO |
sources.inventory.workstations[] |
WorkstationSchema: id/companyId/values/history |
Inventario; cada puesto con 1..N revisiones | CONFIRMADO |
sources.inventory.assets[] |
AssetSchema: id/companyId/values/specification/displayStatus/assigned/history |
Inventario; equipo principal y otros, incluida impresora fuera de miembros | CONFIRMADO |
sources.inventory.relationships[] |
RelationshipSchema, 0..N |
Inventario; vacío en ejemplo | CONFIRMADO |
sources.profiles.profiles[] |
WorkProfileSchema: id/companyId/values/needsReview/history |
API perfiles; requiere filtro de host | CONFIRMADO |
sources.resources.resources[] |
ResourceSchema: id/companyId/values/specification/history, networkShare opcional |
API recursos; cada característica por fieldId de specification | CONFIRMADO |
sources.access.items[] |
AccessItemSchema: id/companyId/values/history, values discriminado por kind |
API Access; catálogo, cuenta, relación persona, recurso proyectado, necesidad, grant y cobertura | CONFIRMADO |
sources.access.coverage[] |
{needId, covered, missingPermissionIds} |
Proyección backend; no recomputar como autorización real | CONFIRMADO |
sources.access.reviews[] |
{itemId, reason} |
Proyección backend, vacía en el caso principal | CONFIRMADO |
sources.folders.mappings[] |
FolderMappingSchema: perfil, need, cuenta elegida, UNC, unidad, state, notes, revisiones y tres resultados de cobertura/revisión |
API carpetas; filtrar por perfil y compañía | CONFIRMADO |
sources.software.configurations[] |
SoftwareInstallationSchema: activo, recurso, licencia, versión, state, notes, revisión |
API software; filtrar por principal | CONFIRMADO |
sources.applications.configurations[] |
ApplicationConfigurationSchema: perfil, recurso, delivery, versión, state, notes, revisión |
API aplicaciones; no fusionar con instalación | CONFIRMADO |
sources.printers.configurations[] |
PrinterConfigurationSchema: perfil, printerId, connection, isDefault, state, notes, revisión |
API impresoras; referencia a activo ajeno a composición | CONFIRMADO |
sources.certificates.configurations[] |
CertificateConfigurationSchema: perfil, recurso, ubicación, state, notes, revisión, expiresOn y expired |
API certificados; fecha de referencia fija | CONFIRMADO |
sources.mail.configurations[] |
MailConfigurationSchema: perfil/buzón/método/state/notes/address snapshot, history, needsReview, legacy |
API correo; caso nuevo, no legacy | CONFIRMADO |
sources.mailboxes.mailboxes[], uses[] |
MailboxesResponseSchema: buzón con dirección/tipo/contexto/cuenta/estado/notas e historial; uso con buzón/persona/periodo/historial |
API buzones; uso vigente de la persona del perfil | CONFIRMADO |
sources.telework.authorizations[] |
TeleworkAuthorizationSchema: persona/active/startsOn/expiresOn/notes, status/effective/needsReview/history |
API teletrabajo; contexto de persona | CONFIRMADO |
sources.remote.connections[] |
RemoteConnectionSchema: persona, origen/destino, sede, método, VPN, configuración, notas; resultados e historial |
API remoto; caso desde equipo principal | CONFIRMADO |
sources.support.connections[], tools[] |
SupportListSchema; conexión tiene assetId/values/history, herramienta id/name/active |
API soporte por equipo | CONFIRMADO |
sources.publications.publications[], nextCursor |
NetworkSharePublicationPageSchema: publicación con assetId/resourceId/periodo/actores/predecessor |
API paginada; en ejemplo publicador es otro activo, no el puesto | CONFIRMADO |
presentation.relatedProfileIds, activeProfileIds, relatedPersonIds |
UUID[] calculados por filtros/set descritos en 02/04 | Join local sobre fuentes completas | DERIVABLE; forma PROPUESTA |
presentation.counts |
Enteros para miembros/perfiles/personas/configuraciones; fórmulas en 04 | Solo fuentes completas; fecha fija | DERIVABLE; forma PROPUESTA |
presentation.latestRevisionId |
UUID de última revisión del puesto seleccionado | No feed combinado | DERIVABLE |
scenarios[] |
id/name/baseWorkstationId, opcional displayUnavailable y descripción | Instrucciones de estado de pantalla, no propiedades del dominio | PROPUESTO |
No se añaden tickets, «salud» ni permisos efectivos del puesto al fixture. Tampoco se incluyen todos los procesos, dominios y entornos locales posibles: están auditados, pero quedan como detalles opcionales fuera del dataset mínimo. El ejemplo de publicación SMB muestra la diferencia entre el servidor que publica y el puesto que consume por configuración.
La validación de schemas comprueba forma de DTO y referencias locales; no sustituye las políticas de creación, capacidades de plantilla ni restricciones de una BD. La fixture no incluye un catálogo de producción instalable ni pretende ser un seed HTTP.
Volumen materializado: 1 compañía, 2 personas, 5 activos, 7 recursos, 4 puestos y 4 perfiles. Se validaron 16 bloques de DTO, invariantes locales de composición, referencias y contadores. La proyección de Access coincide con las coberturas/revisiones del ejemplo. Los dos perfiles activos del puesto principal comparten equipo, no identidad; la impresora configurada está fuera de su composición exclusiva.
Escenarios de diseño
| ID | Caso compatible con modelo | Preparación del ejemplo / resultado esperado |
|---|---|---|
| S01 | Puesto completo | Seleccionar puesto principal del fixture. Responsable y dos perfiles activos de personas diferentes; uno archivado adicional. Equipo + monitor; software, configuración de carpetas, correo, app, certificado e impresora; última revisión |
| S02 | Sin responsable | Seleccionar puesto de laboratorio: personId=null, pero tiene host y perfil activo. Mostrar responsable «—» y uso de la persona del perfil. No deducir «nadie lo utiliza» |
| S03 | Sin activos | Seleccionar puesto pendiente: activo, assetIds=[], sin ordenador ni perfiles derivados. CTA editar/completar. Deshabilitar creación de perfil e instalación sin host; mostrar vacío coherente, no fallo |
| S04 | Muchas relaciones | Variante a preparar desde S01: 80 miembros únicos incluido principal, 50 personas y 60 perfiles coherentes con unicidad activa por persona/host; generar archivados con identidades propias. Software/configuraciones extensos con nombres largos. No superar 200 miembros |
| S05 | Información incompleta | Desde S01, scenarios.displayUnavailable simula error de perfiles y carpetas en presentación, sin cambiar DTO a relaciones inválidas. Mantener cabecera/host conocidos; usuarios parciales, contador no definitivo, error y reintento de cada bloque |
| S06 | Desmantelado | Seleccionar puesto inactivo del fixture: revisión inicial con equipo/responsable y última revisión sin ellos. Actual sin miembros/perfiles derivados; historial conserva referencias. No incluir equipo histórico en contador actual |
| S07 | Refetch con datos previos | Desde S01 mantener datos, selección y foco; feedback discreto. Si falla, avisar que hay datos anteriores y reintentar solo fuente afectada |
| S08 | Sin coincidencias | Búsqueda de perfiles/software sin resultados conserva búsqueda y ofrece limpiar; no confundir con ausencia total |
| S09 | UUID ausente / sesión sin acceso | Destino válido no existente muestra ausencia sin seleccionar otro puesto; 401 ofrece flujo de acceso existente. No diseñar un rol por compañía no implementado |
| S10 | Principal sustituido | Variante cambia principal por otro miembro y registra revisión; perfiles/software anteriores siguen en activo anterior. Mostrar nuevo contexto y permitir consultar historial, sin simular migración automática |
| S11 | Permiso documental desconocido | Mapping con cuenta ausente → cobertura de cuenta unknown; distinguir configured, permissionsCovered y revisión. No sustituir por acceso concedido/denegado real |
S01/S02/S03/S06 tienen puestos concretos en el JSON; S05 describe estados sobre S01; S04 y S07–S11 son especificaciones reproducibles pendientes de materializar/ejecutar. No presentar todos como fixtures completas ni pruebas superadas.
Esquema de composición para el futuro mockup
Escritorio, orden de lectura propuesto:
Volver · Compañía / Puestos
Nombre del puesto · Estado Editar · Más acciones
Sede · Responsable
Ordenador principal + estado técnico | Revisiones y relaciones resumidas
Personas y perfiles (cuenta, estado, revisión, abrir entorno)
Equipamiento compacto | Software del principal
Configuraciones del perfil seleccionado (procedencia visible)
Soporte del equipo | Contexto remoto/organizativo
Último cambio → Historial completo
Móvil: mismo orden en una columna; cabecera con acciones que envuelven, filtro de perfil visible, tablas dentro de su área desplazable, contexto secundario plegable con títulos descriptivos. Ningún dato esencial requiere hover. Es un wireframe textual, no un mockup definitivo.
Comprobaciones posteriores
Matriz prevista: 1920×1080, 1440×900, 1366×768, 1024×768, 768×1024, 390×844 y 320×640, además de zoom 200/400 %. Evaluar teclado/foco, vuelta a listado/perfil, scroll, nombres y UNC largos, fechas exactas, 0/false/ausente, permisos, carga parcial y no coincidencias.
Para pruebas funcionales/visuales persistentes preparar al menos 15 compañías y una principal con 50 personas, 50 activos y 50 recursos, ampliando puestos/perfiles coherentes. Usar exclusivamente metis_desk_test aislada y desechable según procedimiento Playwright. Esta fase no prepara ni modifica esa BD: lo prohíbe la petición. El fixture de diseño tiene un volumen menor declarado en metadata y validado al cierre; no acredita aislamiento real entre compañías ni rendimiento.
Prompt para crear el mockup después
Lee los ocho entregables de docs/auditorias/workplace-dashboard/ y las instrucciones
vigentes de AGENTS.md, DESIGN.md y la matriz de skills. Diseña un mockup de la ficha
de Workstation orientada a consulta operativa, usando 04 como arquitectura y 07 como
fixture ficticio. Comprueba contratos reales de componentes antes de implementarlo.
Usa frontend-design para la composición y ux-dashboard como complemento. Conserva
Inter, tokens, identidad del shell, shadcn/Base UI Vega y componentes de @repo/rdx-ui.
No modifiques vendor ni añadas dependencias. No conectes mutaciones reales ni migres BD.
Distingue responsable, usuarios actuales y perfiles archivados; equipamiento exclusivo,
impresoras configuradas, software del equipo y aplicaciones del perfil. Identifica la
procedencia de recursos y cobertura documental. No incluyas tickets, salud online,
ocupación en directo ni accesos efectivos inventados.
Representa S01, S02, S03, S05 y S06 y prepara S04 con el volumen y reglas documentados.
Declara las hipótesis de diseño pendientes. Mantén acciones/diálogos reconocibles,
enlaces con destinos existentes, estados por bloque y ausencia «—» en celdas.
Antes de elegir destino/formato del prototipo, comprueba convenciones existentes y
alcance autorizado de la nueva tarea. Valida su interfaz en Playwright MCP cuando haya
un entorno permitido; informa exactamente qué se ha probado y qué sigue pendiente.
No presentes el mockup como una funcionalidad integrada en producción.