Primera parte del bloque de teletrabajo y accesos remotos. Documenta la autorización para trabajar fuera de la sede. Los equipos de origen, conexiones VPN y destinos se documentan en [Accesos remotos](accesos-remotos.md). La [asistencia técnica remota](asistencia-tecnica-remota.md) está implementada como función independiente.
Una autorización pertenece a una persona de una compañía y tiene UUID propio. No depende de un perfil o un equipo: es común a los perfiles de esa persona. Las personas no acceden a Metis Desk.
Se conserva una sola autorización por persona, incluso al revocarla. Renovar, revocar o reactivar se realiza editando el mismo registro y conservando todas sus revisiones. La persona no se puede cambiar. No hay borrado.
Los campos son persona, autorización activa, fecha inicial opcional, fecha final opcional y notas opcionales. Sin fechas no hay límite temporal. Si se indican ambas, la inicial no puede ser posterior a la final. Ambos días están incluidos. La fecha actual se calcula en el servidor en UTC, como las demás caducidades del sistema.
El estado se calcula en lectura: Revocada si está desactivada; Caducada si ha pasado la fecha final; Programada si aún no ha llegado la fecha inicial; Autorizada en los demás casos. La autorización solo es efectiva cuando está Autorizada y la persona está activa. No se persiste una segunda copia del estado calculado.
No se autoriza ni reactiva una persona inactiva. Una autorización activa de una persona que se desactiva se conserva y muestra revisión, sin ser efectiva. Puede revocarse; una repetición idéntica sigue siendo idempotente. Para modificar notas de una autorización conservada de una persona inactiva, revocarla o reactivar previamente a la persona.
Revocar no cierra una VPN ni desinstala o retira configuraciones reales. Sirve como información documentada para revisar los accesos existentes. No se eliminan correos, permisos o configuraciones por desactivar la autorización.
## Interfaz
Sección Teletrabajo dentro del espacio de compañía: búsqueda por persona, consulta de vigencia, edición e historial. Nueva autorización en la cabecera derecha; alta y edición en modal. La ayuda y los ejemplos aparecen inmediatamente antes del pie con Guardar y Cancelar.
La persona utiliza SelectWithAction con alta rápida en un segundo modal. No se abre un tercer nivel. Cancelar la persona conserva el formulario padre. Una persona ya guardada se conserva aunque se cancele la autorización.
Entorno actual consulta la autorización de la persona, separada de los cinco bloques de configuración. Si no existe, lo indica sin presuponer permiso. Gestionar teletrabajo abre una consulta filtrada de esa persona; un alta iniciada desde el perfil la deja fija. Si ya hay autorización, se edita en lugar de crear otra. Volver al entorno conserva el perfil seleccionado.
Los listados no tienen formularios visibles junto a los registros. Traducciones es/en, carga, error, vacío, reintento y acciones deshabilitadas durante escritura.
## Dominio y persistencia
TeleworkAuthorization es AggregateRoot; TeleworkAuthorizationRevision es DomainEntity con UUID propio; TeleworkAuthorizationValues encapsula referencias UniqueID, fechas CalendarDate y opcionales Maybe.
Crear genera UUID v7. Update conserva la identidad y compara valores semánticamente: una repetición no crea revisión. El destino persona es fijo y las revisiones conservan actor de sesión y fecha UTC. Rehydrate reconstruye identidades e historial sin emitir eventos.
Migraciones explícitas e idempotentes para telework_authorizations y telework_authorization_revisions. FK a compañía, persona, autorización y actor. Persona única; posición de revisión única dentro de cada autorización.
Las escrituras bloquean la compañía antes de leer, validar y guardar. Las altas concurrentes no crean dos autorizaciones. El mapper bidireccional detecta referencias incoherentes, historial vacío, posiciones o fechas inválidas, destino alterado y discrepancia entre raíz y última revisión. Se valida pertenencia a compañía también al leer; los fallos de persistencia no exponen SQL ni datos internos.
## HTTP
GET /api/telework-authorizations/:companyId devuelve autorizaciones, estado calculado, efectividad, revisión e historial.
POST en la misma ruta crea. POST /api/telework-authorizations/:companyId/:id/update modifica. Entrada estricta Zod y UUID. Sesión obligatoria; origen y CSRF en escrituras. Actor obtenido de sesión, nunca del formulario. No se pueden leer ni actualizar por otra compañía.
## Pruebas
Dominio: fechas y ausencia, límites, contrato estricto, UUID, igualdad semántica, actualización idempotente, destino fijo, historial y renovación, vigencia inclusiva, caducidad, programación, unicidad, persona inactiva y revocación, rehidratación corrupta.
HTTP con MariaDB de test: persistencia, origen/CSRF, sesión, aislamiento, alta concurrente, actor autenticado, historial, fechas límite, revocación, renovación y fallo cerrado ante corrupción.
Interfaz: listado sin formularios, traducciones, alta rápida, ayuda inferior, campos opcionales, persona fija al iniciar desde perfil, avisos de revisión y autorización común a perfiles.
La comprobación en navegador verifica selector de persona, alta rápida y retorno, formulario padre conservado, ayuda antes del pie, cancelación, consulta desde Entorno actual y persona fija desde el perfil. Se corrige la actualización de los calendarios con su evento de entrada: las fechas se conservan al editar notas y el periodo inválido se rechaza en el modal. El registro temporal creado durante la comprobación se retiró; no quedan datos ficticios de teletrabajo en desarrollo.
Validación final: 132 pruebas pasan en el monorepo, incluidos diez casos nuevos de dominio/interfaz y la integración HTTP con MariaDB de test. Se repite la suite completa tras corregir el calendario y la suite de Companies después del ajuste de textos. Typecheck y build pasan. Los 33 archivos de código y configuración de este bloque pasan Biome; lint y check globales mantienen los errores anteriores (32 y 90), sin errores nuevos del bloque.
