metis-desk/docs/evolucion-de-plantillas-de-activos.md

# Evolución de plantillas de activos

## Estado y objetivo

Propuesta pendiente de implementación. Define cómo deberían reflejarse las ediciones
de una plantilla en los activos existentes de todas las compañías que la utilizan.
No cambia el comportamiento actual ni las reglas del catálogo de recursos.

Actualmente `mapAssetInput` captura la especificación al crear el activo y reutiliza
la anterior al editarlo. El formulario utiliza esa misma instantánea. Por tanto,
añadir campos, secciones o cambiar el orden solo afecta a las nuevas altas.
El icono ya se consulta desde la plantilla actual.

Cada `AssetRevision` conserva valores, autor y fecha, pero no una especificación
propia. Sustituir la especificación del activo sin evolucionar este contrato haría
que las revisiones antiguas se interpretasen con campos y grupos posteriores.
Véanse [campos y plantillas](campos-y-plantillas-de-activos.md) y
[secciones de campos](secciones-de-campos-en-plantillas.md) para el contrato vigente.

## Comportamiento propuesto

La ficha y la edición del activo deben seguir la plantilla actual, conservando los
valores ya registrados. El historial debe mostrar la estructura y las reglas
vigentes cuando se registró cada revisión.

| Cambio en la plantilla | Efecto en los activos existentes |
| --- | --- |
| Añadir un campo opcional | Aparece vacío en la ficha y disponible en la edición; no se inventa un valor. |
| Añadir un campo obligatorio o marcarlo obligatorio | Aparece pendiente de completar si falta un valor. El activo continúa siendo consultable. |
| Añadir, renombrar o reordenar secciones | Se aplica a la presentación actual; una sección vacía no se muestra en la ficha. |
| Mover o reordenar campos | Cambia su presentación, manteniendo identidad y valor. |
| Eliminar una sección | Sus campos pasan a «Sin sección», conservando los valores. |
| Retirar un campo | Deja de solicitarse; los valores existentes siguen consultables como características retiradas, separados de los campos actuales. |
| Reincorporar un campo | Recupera su valor anterior por UUID, si existe. |
| Cambiar nombre, descripción o unidad | Actualiza la presentación actual; no convierte ni modifica los valores. |
| Añadir opciones a un campo de lista | Las opciones nuevas quedan disponibles sin alterar la selección guardada. |
| Desactivar plantilla o campo | Conserva activos, asociaciones, valores e historial; mantiene las reglas de disponibilidad existentes. |

La evolución no cambia el tipo de un campo ni elimina opciones existentes: ambas
operaciones continúan prohibidas por el catálogo. Un campo nuevo con el mismo nombre
que otro retirado tiene otra identidad y no hereda sus valores.

Los nuevos activos cumplen desde el alta todas las reglas actuales. En los
existentes, la edición de características exige completar los campos obligatorios
actuales. Las operaciones independientes sobre estado, ubicación o notas no deben
quedar bloqueadas por un cambio posterior de plantilla; esto requiere distinguir
su validación de la edición de características. Nunca se rellenan valores por
defecto para disimular información pendiente. Un cambio a opcional elimina el
pendiente correspondiente sin borrar información.

## Alcance entre compañías

La dependencia se identifica por UUID de plantilla, nunca por nombre. Una edición
global afecta a los activos vinculados a esa plantilla en todas las compañías,
incluidos los retirados y los de compañías donde se haya desactivado su disponibilidad.
Una plantilla local solo afecta a sus propios activos. Una copia tiene identidad
propia y permanece independiente de la plantilla original.

La propagación respeta la compañía propietaria de cada activo y la autorización del
servidor. El navegador no elige qué compañías pueden ser modificadas. La edición
de una plantilla no reasigna activos ni altera relaciones, puestos o perfiles.

## Implementación prevista

1. Introducir versiones inmutables de la especificación de plantilla, con identidad
   UUID v7 y persistencia relacional. Una modificación semántica crea una versión;
   un guardado equivalente conserva la existente.
2. Asociar cada revisión del activo a la especificación con la que se registró.
   Una migración explícita conserva la instantánea existente para todas sus
   revisiones anteriores: no puede reconstruirse qué plantilla histórica existía
   si esa información nunca se almacenó.
3. Resolver la especificación actual desde la plantilla al consultar y editar el
   activo, combinándola con sus valores por UUID de campo. Así el cambio se refleja
   en todas las compañías sin reescribir masivamente sus activos. Conservar los
   valores retirados y mantener la especificación histórica para el historial.
4. Hacer que el dominio y los mappers distingan validación de características,
   cambios independientes y rehidratación histórica. Guardar una edición real
   contra la versión actual en una transacción. Si la plantilla cambió mientras el
   formulario estaba abierto, devolver un conflicto recuperable que permita
   revisar los cambios conservando la entrada del usuario.
5. Mostrar en el editor de plantilla el alcance del cambio y, en cada activo, los
   campos obligatorios pendientes y los valores retirados. Invalidar las consultas
   afectadas del catálogo y del inventario en el cliente que realiza el cambio;
   otros clientes reciben la estructura vigente al volver a consultar.

Guardar una plantilla no debe generar revisiones técnicas ficticias por activo.
La versión de plantilla conserva autor y fecha para explicar el cambio estructural.
Una consulta tampoco escribe datos ni crea historial. Repetir una operación
equivalente no duplica versiones ni revisiones. La comparación es semántica.

## Validación necesaria

Probar propagación global en dos compañías y aislamiento local y de copias;
altas y activos anteriores; campos opcionales y obligatorios; valores `0` y `false`;
reordenación y eliminación de secciones; retirada y reincorporación por identidad;
historial sin cambios; disponibilidad desactivada; activos retirados; guardados
equivalentes; conflictos entre edición de plantilla y activo; autorización;
migración relacional repetible y caché del frontend.

Esta evolución sustituirá, cuando esté implementada, la regla actual que congela
la estructura del activo. Hasta entonces las instantáneas siguen siendo inmutables,
como documenta el contrato vigente de secciones.