Inicio es la pantalla inicial después del acceso. Mantiene el layout de compañías como espacios, el usuario, el idioma y los formularios existentes. La cabecera no incluye selector de compañía. El dashboard muestra el resumen global o el ámbito indicado en la URL; el resumen de una compañía recibe su identificador desde la ficha. Ese alcance se aplica a todos los bloques y a las altas rápidas.
Cinco tarjetas KPI preceden al trabajo pendiente, los avisos, la actividad reciente, el resumen de compañías y las acciones rápidas. Se utilizan los tokens y la tipografía existentes. En escritorio, trabajo/avisos ocupan dos tercios/un tercio; la segunda fila reparte actividad y compañías. En móvil se apilan los bloques y las tablas se desplazan dentro de su contenedor.
Las tarjetas son botones accesibles. Compañías abre el directorio filtrado por activas; tickets e intervenciones abren sus listados con “Solo trabajo pendiente”, un filtro visible y eliminable. Activos y recursos abren un listado global o por compañía paginado en el servidor. Cada registro abre su ficha concreta dentro del workspace. El resumen limita la vista a cinco compañías y ofrece la tabla completa con búsqueda, columnas y paginación.
Las cinco altas reutilizan CompanyForm, TicketForm, InterventionForm, AssetForm y ResourceForm. Activos y recursos solicitan primero una compañía cuando no está seleccionada. Se conserva la ayuda antes del pie, Guardar/Cancelar y SelectWithAction. No se añaden registros de ejemplo.
## Definición de indicadores
| Indicador | Regla |
| --- | --- |
| Compañías activas | Compañías con active verdadero. |
| Tickets abiertos | open, in_progress y waiting; excluye resolved y cancelled. |
| Intervenciones pendientes | pending e in_progress; excluye finished y cancelled. |
| Activos registrados | Todos los activos persistidos, incluidos los retirados. |
| Recursos registrados | Todos los recursos persistidos, incluidos los inactivos. |
| Personas por compañía | Todas las personas registradas, incluidas las inactivas. |
Los contadores corresponden al conjunto completo, nunca a las filas visibles. Trabajo pendiente muestra seis entradas y “Ver todos” abre páginas de diez. Primero se ordena por prioridad urgent, high, normal, low y después por la primera revisión (más antiguo primero), con ID como desempate. Una intervención hereda la prioridad del ticket vinculado; sin ticket se ordena como normal. Prioridad y estado se presentan por separado.
## Avisos comprobables
- Certificados y licencias activos cuya fecha de caducidad está entre hoy y hoy + 30 días, incluidos los extremos. La fecha de referencia es UTC. Se identifican por stockKey de las plantillas de serie certificate/software_license y del campo expires, nunca por nombres. No se incluyen recursos sin fecha, inactivos, ya caducados o plantillas personalizadas cuyo significado no está declarado.
- Perfiles activos que requieren revisión porque su persona está inactiva, su activo retirado o su cuenta ya no es válida para ese perfil (cuenta inactiva, técnica, caducada, sistema/entorno desactivado o sin vinculación vigente a la persona). Los campos opcionales vacíos no constituyen errores.
- Activos sin sede asignada, incluidos los retirados, porque el listado representa la ausencia de esa referencia.
- Personas inactivas con activos no retirados asignados, perfiles activos, vinculaciones de cuentas aún pendientes/configuradas/pendientes de retirar (aunque haya cerrado su periodo), necesidades vigentes, conexiones remotas y configuraciones de correo/aplicaciones/certificados/carpetas/impresoras sin retirar, o autorización de teletrabajo activa no caducada.
Estos avisos representan información registrada pendiente de revisión; no verifican permisos efectivos en servidores externos ni ejecutan retiradas. Cada contador abre el conjunto que lo origina. Los accesos personales registrados también se contemplan a través de conexiones remotas y configuraciones de correo.
## Fuentes y capas
GET /api/dashboard/summary, /work, /attention, /activity, /companies y /details son consultas autenticadas de lectura. Admiten companyId; work/details admiten page, details admite kind o issue. Un alcance inexistente devuelve 404; parámetros desconocidos o inválidos devuelven 400. Los contratos se validan con Zod.
DashboardUseCases coordina el repositorio de lectura en Application. La implementación Sequelize y el SQL están en Infrastructure. Assets y Resources ofrecen proyecciones públicas acotadas para contadores, detalles e historial; no se reconstruyen ni descargan inventarios de todas las compañías en el navegador. No se crea ninguna entidad de negocio ni migración de datos.
La actividad combina las seis revisiones más recientes de tickets, intervenciones, activos y recursos y presenta las seis más recientes del conjunto (cuatro en Inicio). Cada evento utiliza el UUID de su revisión. Se muestra “Revisión registrada”, fecha, entidad, compañía y autor cuando existe; no se deduce una acción concreta a partir de un simple cambio. Este bloque no constituye un historial global completo ni incluye todavía todos los historiales del dominio. “Ver todos” muestra este conjunto reciente ampliado.
## Carga, vacío, error y actualización
Cada bloque tiene una consulta independiente con cancelación y clave por alcance. Un fallo parcial no oculta los demás. Loading usa role=status; error usa role=alert; vacío tiene un texto propio. Los KPI pendientes o fallidos muestran un guion, nunca un cero ficticio. La conexión disponible indica que la consulta de resumen ha respondido correctamente; no es un monitor de red permanente.
TanStack Query actualiza las consultas al volver a montarlas/enfocarlas y las altas rápidas invalidan las claves dashboard. No existe polling permanente ni notificación push. Todos los textos están en los JSON es/en del módulo Companies.
## Componentes y verificación
StatisticCard pertenece a @repo/shadcn-ui y solo acepta presentación y callbacks, sin DTO ni endpoints. DashboardPanel y BlockState son componentes locales: organizan los bloques y gestionan sus estados sin acoplar otros módulos al dashboard.
La integración HTTP con la BD de pruebas comprueba totales completos, exclusión de estados finales, alcance de compañías, avisos/detalles consistentes, paginación, contratos, parámetros inválidos y autorización. Las pruebas de renderizado comprueban idiomas, vacío, carga y errores parciales. Las comprobaciones visuales se hacen en desarrollo sin crear datos de negocio.
