metis-desk/docs/architecture/auditoria-estado-actual-sistemas-operativos-activos-y-puestos.md

Auditoría arquitectónica — Estado actual de los sistemas operativos de activos y puestos

Fecha: 26 de octubre de 2026. Investigación estática y recomendación preliminar. No constituye una nueva decisión aprobada ni autoriza implementación.

1. Resumen ejecutivo

Metis Desk ya separa origen y operación. Assets conserva el SO suministrado como característica textual del activo; Resources representa el producto SO; Companies conserva su relación operativa con una unidad mediante SoftwareInstallation. El puesto consulta las instalaciones de su ordenador principal y no almacena un SO propio. El catálogo implementado admite SO particulares y SO globales, además de aplicaciones globales; la licencia continúa siendo particular de compañía [E01–E13, E18–E22].

El ejemplo ThinkPad/FreeDOS/Windows 11 Pro puede registrarse manualmente sin sustituir el dato de fábrica. Pueden existir varios productos SO configurados en una unidad. No hay detección automática, estado tipado de ausencia confirmada/desconocimiento, instancia de arranque, fecha efectiva de instalación, build/arquitectura estructurados ni procedencia/verificación. El estado configured es una declaración registrada, no una comprobación técnica del equipo [E06–E09, E18–E21].

Hallazgos principales: servidor incorpora dos campos próximos de SO de fábrica; el mismo producto solo puede tener una instalación abierta por activo; reinstalaciones carecen de evento específico; la eliminación física de una instalación borra sus revisiones; nombres/producto de las revisiones se resuelven con referencias actuales; licencias no comprueban cupos, compatibilidad comercial ni restricciones OEM. La relación genérica «Alojado en» es reutilizable documentalmente, pero no equivale a gestionar virtualización [E01, E05–E10, E16, E23].

Recomendación preliminar: D acotada, apoyada en B ya implementada. Mantener fábrica en Assets, producto en Resources, instalación en Companies y presentación derivada en puestos. Resolver primero las carencias funcionales que realmente se necesiten; no duplicar catálogo, instalación o dato SO dentro del puesto. Requisitos de compatibilidad de perfiles e inventario automático quedan condicionados a consumidores y contratos explícitos. Confianza alta en el diagnóstico estático, media en necesidades futuras; ninguna afirmación sobre datos o disponibilidad efectiva de producción.

2. Alcance y metodología

Base: main, HEAD a72d6a2ec8985e1d51f74db68a1b3aabb3693030. Se inspeccionó el árbol de trabajo, que ya contenía cambios concurrentes en fichas SMB, componentes visuales y documentación, incluidos archivos nuevos. Se conservaron. HEAD no identifica por sí solo todo el árbol inspeccionado. Las fuentes citadas se registran con SHA-256 en el manifiesto de esta auditoría; las líneas corresponden a su lectura y pueden desplazarse con cambios posteriores.

Se consultaron dominio, schemas, aplicación, composición, HTTP, persistencia Sequelize/migraciones y consumidores React de Assets, Resources y Companies; también pruebas y documentación normativa de capas, composición, identidad y R2.0–R2.6/D08.2. Las búsquedas incluyeron atributos dinámicos, stockKey, SO, Windows/Linux, firmware, Icecat, virtualización, instalaciones, licencias, perfiles y puestos. Una ausencia significa «no localizado en el código activo examinado», no ausencia demostrada en datos particulares o sistemas externos.

Se aplicó rdx-solid y sus referencias de arquitectura: responsabilidad por agregado, contratos públicos y distinción entre evidencia y propuesta. No se modifican interfaces ni se emite una auditoría visual; no se aplican recetas nuevas de UI/UX ni se requieren auditores visuales para esta investigación.

Evidencia: verificado estáticamente = camino/contrato presentes en código; inferencia = combinación de capacidades, identificada como tal; propuesto = todavía no implementado. Las pruebas se leyeron, no se ejecutaron en esta intervención. No se ejecutaron SQL, migraciones, servicios, fixtures, builds ni Playwright. No se leyeron .env o secretos ni se conectó a ninguna BD. Solo se crean este informe y su registro de evidencias; vendor, archive/ y trabajo ajeno permanecen intactos.

3. Inventario verificado

Elemento real	Naturaleza / propietario	Persistencia y cardinalidad	API / consumidores	Validación e historial
Asset, AssetSpecification, AssetCatalog	Unidad y catálogo de campos/plantillas; Assets	assets: id, companyId, templateId, brandId, estado, etc.; características 1:N en asset_characteristics, clave activo/campo	/api/assets/:companyId; alta/actualización y ficha mediante componentes de inventario	Pertenencia, especificación y valores tipados; asset_revisions y características/especificación de revisiones [E01–E03]
field:factory_os	Campo textual de origen; valor en la unidad	asset_definitions.stockKey → binding de plantilla → asset_characteristics.textValue; un valor por activo/campo	Formulario dinámico y especificaciones de la ficha	Texto, sin fuente certificada ni enum de presencia; historial del activo [E01–E03]
field:factory_preloaded_os	Segundo campo de origen de servidor	Mismo mecanismo; servidor también incluye factory_os	Formulario/ficha dinámica de servidor	No se localiza reconciliación entre ambos [E01]
Resource, uso os	Producto SO; Resources	resources, resource_definitions, resource_template_fields, resource_characteristics; producto 1:N instalaciones	CRUD particular /api/resources/:companyId; catálogo /api/resource-global-operating-systems	Global solo stock elegible; particular según catálogo; resource_revisions y especificaciones históricas [E04, E11–E13]
Identidad SO global	Valores comerciales declarativos, no entidad OperatingSystem separada	Campos proveedor/familia/versión comercial/estado de edición/edición, EAV relacional	DTO SO específico, formulario/revisión del catálogo global	Revisión previa, identidad fija desde primera publicación; edición conocida/no aplicable/desconocida [E11–E13]
SoftwareInstallation	Agregado operativo por unidad; Companies	software_installations: UUID, compañía, activo, producto, licencia opcional, versión, estado, notas, currentKey; activo y producto forman N:M a través de instalaciones	/api/software-installations/:companyId; panel, editor, historial, SO actual y mapa	Destino activo/producto fijo; una pareja abierta; revisiones con actor/fecha; eliminación física explícita [E05–E10]
Recurso software_license, uso license	Documento/licencia particular; Resources	resources.companyId y características de licencia; instalación 0..1 licencia, licencia 0..N instalaciones	Catálogo/recursos particulares y selector de licencia	Misma compañía/tipo, actividad/caducidad cuando procede; revisiones conservan UUID de licencia [E08, E09, E14]
Workstation	Composición de equipamiento; Assets	workstations.computerAssetId 0..1 principal; workstation_assets N miembros, activeKey exclusivo; revisiones en workstation_revisions	/api/assets/:companyId/workstations; ficha y mapa de Companies	Principal debe ser miembro; coherencia de compañía/disponibilidad y exclusividad en otro puesto activo; historial de cambios [E15]
WorkProfile	Contexto persona/dispositivo/cuenta; Companies	work_profiles: referencias a persona, activo y cuenta opcional; no SO ni dependencia obligatoria de UUID de puesto	/api/work-profiles/:companyId y vistas por persona/equipo	Validación de contexto; historial propio [E17]
ApplicationConfiguration	Configuración de aplicación del perfil; Companies	application_configurations, application_configuration_revisions: perfil, recurso, delivery, versión, estado, notas	/api/application-configurations/:companyId	Solo application; no admite SO. No sustituye instalación por activo [E17]
AssetRelationship, relation:hosted	Relación genérica entre activos; Assets	Relación con extremos/tipo, autor/fecha de alta y retirada; no es asociación a un Resource SO	Gestión de relaciones de activos	No acredita VM, hipervisor ni propagación de SO [E16]

El estado scoped de Resource se introduce por migración explícita: scope=company con propietario o scope=global con companyId=null. No debe deducirse del migrateInventory legacy aislado, que aún declara el propietario obligatorio al crear la tabla inicial. El arranque y el inspector verifican compatibilidad; existencia de migraciones no demuestra aplicación en una BD real [E04, E13].

Activos, modelos físicos y fábrica

Las plantillas stock incluyen portátil, sobremesa, monitor, impresora, router, firewall, switch, punto de acceso, NAS, servidor, smartphone y SAI. No se localizaron plantillas stock específicas de VM, mini-PC o workstation de altas prestaciones. Una plantilla propia puede describirlos; eso no añade semántica de virtualización o un nuevo subtipo de entidad [E01].

Existe referencia opcional a asset_brands; modelo, serie, código de producto/MPN, hardware, compra/proveedor/garantía se expresan mediante campos de la plantilla. No se localizó un agregado de producto físico/SKU ni integración Icecat/importador de fichas de fabricante que determine automáticamente el SO de cada unidad. Los ejemplos de las definiciones son ayuda, no datos que acrediten una configuración de fabricante. No es correcto inferir SO a partir del modelo, marca, plantilla o persona asignada [E01–E03].

La política de instalación comprueba que el activo exista en la compañía y no esté retirado, no restringe el SO a plantillas laptop/desktop/server. Esto permite servidores y plantillas propias, pero también exige criterio de inventario para evitar clasificaciones inadecuadas; no hay compatibilidad hardware/SO verificada [E08].

4. Modelo verificado

flowchart LR
  subgraph Assets
    A["Asset: unidad y características de fábrica"]
    W["Workstation: persona, miembros, principal"]
    AH["AssetRevision / WorkstationRevision"]
    REL["AssetRelationship: Alojado en, etc."]
    W -->|"assetIds; computerAssetId opcional"| A
    A --> AH
    W --> AH
    REL -->|"extremos Asset"| A
  end
  subgraph Resources
    PROD["Resource: os/application; company/global"]
    LIC["Resource: license; company"]
    RH["ResourceRevision y especificaciones"]
    PROD --> RH
    LIC --> RH
  end
  subgraph Companies
    I["SoftwareInstallation"]
    IH["SoftwareInstallationRevision"]
    P["WorkProfile: persona/activo/cuenta"]
    C["ApplicationConfiguration: application únicamente"]
    I --> IH
    P --> C
  end
  A -->|"1 unidad por instalación; 0..N instalaciones"| I
  PROD -->|"1 producto por instalación"| I
  LIC -->|"0..1 licencia por instalación"| I
  A -->|"activo del perfil"| P
  PROD -->|"solo application"| C
  V["SO actual en ficha/puesto: consulta derivada"]
  W -.->|"selección del principal"| V
  I -.->|"configured, tipo os, referencias resueltas"| V

PROD y LIC son papeles del mismo agregado/tabla Resource, no tablas nuevas. El gráfico no representa una FK SO–puesto ni una relación directa entre ApplicationConfiguration y SoftwareInstallation: ninguna se ha localizado. Las cardinalidades describen datos del modelo, no recuentos de una instalación desplegada.

5. Flujo de datos actual

1. El catálogo de Assets define campos/bindings. El usuario registra características de la unidad, incluido origen/fábrica; se guardan valores y revisiones del activo. No se crea automáticamente una instalación desde ese texto [E01–E03].
2. Resources registra el producto SO particular o global. El global utiliza stock template:os, identidad comercial revisada y UUID propio; publicar otro producto exige otra identidad. La versión comercial del producto es distinta de la versión textual instalada [E11–E13].
3. La instalación declara activo/producto/estado/versión/licencia. Companies recibe referencias públicas de Resources y Assets en la composición; valida pertenencia, disponibilidad y propósito dentro de la operación transaccional. No consulta modelos ORM ajenos desde el dominio [E05–E10, E22].
4. useAssetSoftware consulta instalaciones de la compañía, filtra las del activo y resuelve productos mediante la API pública. getCurrentOperatingSystems selecciona únicamente configured + kind=os; no consulta el campo de fábrica [E18].
5. La ficha del activo compone AssetOperatingSystems; la del puesto obtiene el miembro computerAssetId válido y reutiliza la misma consulta/presentación. Panel/historial/mapa ofrecen enlaces por scope [E19–E21].

Los estados de carga/error/referencia no disponible se separan del vacío. «No registrado» significa que la lectura no muestra un SO configurado, no que se haya verificado un disco sin SO. Pendiente, retirado o retirada pendiente no forman parte del resumen de SO actual. Un producto inactivo resoluble puede seguir mostrándose con aviso de revisión [E18–E21].

6. Origen de fábrica frente a instalación actual

Pregunta	Respuesta verificada
¿Existe SO suministrado originalmente?	Dos campos textuales stock: factory_os y factory_preloaded_os; valores por activo, no producto físico compartido [E01]
¿Procedencia fabricante frente a introducción manual?	Sin procedencia por valor o marca de verificación; actor/fecha de revisión indican quién registró el dato, no quién lo certificó [E02, E03]
¿Qué pasa si cambia el SO operativo?	Cambia la instalación/producto asociado; no hay camino localizado que sobrescriba automáticamente fábrica [E05–E10]
¿Se preserva fábrica?	Es independiente y tiene historial del activo, pero puede editarse manualmente; no es un dato de fabricante inmutable
¿Puede documentarse «sin SO de fábrica»?	Sí como texto; no hay estado tipado ni regla que lo relacione con presencia real actual
¿Cada unidad del modelo comparte SO?	No se impone. La plantilla define estructura; cada Asset conserva sus propios valores

Portátil y sobremesa usan factory_os. Servidor incluye factory_preloaded_os y factory_os en dos grupos. La duplicidad está verificada en el seed, no contradicciones de datos reales. Decidir un campo canónico y eventual tratamiento de valores existentes requiere otra decisión; no se retira ninguno aquí [E01].

Datos de una instalación efectiva

Dato	Situación actual
Producto	FK resourceId, tipología SO/application; global o particular
Edición	Pertenece al producto. No hay override de edición en la instalación; global publicado fija identidad
Versión	Campo opcional version de hasta 100 caracteres, sin parser específico por fabricante
Build y arquitectura	No tienen campos propios de instalación. Escribirlos en versión/notas no equivale a soporte estructurado
Fecha efectiva de instalación	No existe. recordedAt es fecha de registro/revisión generada por el servidor
Estado	pending, configured, removal_pending, removed, never_configured
Origen/última verificación	No tienen contrato persistido propio
Reinstalaciones	Cerrar anterior y crear nueva relación; sin comando/evento específico ni instancia de arranque
SO anteriores	Instalaciones cerradas y revisiones mientras no se eliminen físicamente

«Edición desconocida» del catálogo no significa «SO de la unidad desconocido». Tampoco never_configured acredita ausencia de cualquier SO: cierra la intención de instalar un producto concreto [E05–E09, E11].

7. Software, licencias e historial

Las aplicaciones y SO son productos Resources, no instalaciones. SoftwareInstallation es una declaración operativa por activo. ApplicationConfiguration vincula una aplicación a un perfil con delivery installed/web, versión y estado; no es por sí sola inventario de lo realmente instalado ni un motor de autorización que prohíba otros productos en el equipo. No se localizó reconciliación automática entre ambos agregados [E05, E17, E22].

El modelo permite varias instalaciones abiertas de productos diferentes por activo. Impide duplicar la pareja abierta activo/producto mediante policy y currentKey único; terminales liberan esa clave. No se pueden representar dos instancias simultáneas del mismo UUID de producto sobre particiones/arranques distintos. Repetir una actualización idéntica no crea revisión; repetir un alta sin identidad idempotente de instalación no debe interpretarse como un evento nuevo de reinstalación [E06–E10].

Las transiciones son pending → configured o never_configured; configured → removal_pending → removed; los terminales no se reabren cambiando valores. Cambiar producto o activo en una instalación existente se rechaza. Para conservar Windows 10 y Windows 11 como productos distintos, el camino disponible es cerrar la relación anterior y registrar el otro producto. La identidad global publicada impide convertir su producto en otra edición/versión comercial; un particular no tiene esa misma protección, por lo que no debe extrapolarse la garantía global a todos los Resources. Actualizar la versión instalada no transforma la identidad del producto global [E05–E09, E11].

Las revisiones registran UUID de instalación/revisión, actor, fecha y valores. Conservan referencias a producto y licencia, no una copia del nombre y de toda su identidad comercial en cada revisión de instalación. La UI resuelve los nombres actuales; no es una reconstrucción temporal completa de todas las entidades relacionadas. Particularmente, la identidad de un Resource particular no disfruta de la garantía global de inmovilidad comercial [E10–E13].

Retirar no equivale a eliminar. El endpoint /delete elimina primero software_installation_revisions y después software_installations, dentro de transacción. En ese camino no se observa una condición de estado que limite el borrado a un alta pendiente: no debe prometerse retención forense permanente. La documentación de software sí declara esa eliminación como corrección de un alta por error; la política funcional de retención merece ratificación explícita [E10, E23].

La licencia es opcional; debe ser particular de la compañía y de uso license. Seleccionar/cambiar a una licencia no disponible se rechaza; actividad y caducidad se verifican cuando procede crear/reconfigurar. Inactividad/caducidad derivan needsReview, sin retirar software automáticamente; notas, desvinculación y retirada tienen reglas que preservan operación histórica [E08–E10].

El catálogo de licencia ofrece modalidad Suscripción, Perpetua, OEM, Otra, métrica, cantidad, vigencia y referencia. No se localizó consumo de puestos, límite de cantidad, asignación de derechos, correspondencia comercial normalizada producto/edición ni restricción de transferencia OEM. «Volumen» puede documentarse, pero no hay política de derechos de volumen implementada. Una licencia activa de la compañía no acredita por sí sola que cubra ese producto [E08, E14].

8. Puestos, perfiles y varios ordenadores

Sí: Metis Desk puede y ya muestra el SO del principal sin duplicarlo en el puesto. computerAssetId debe pertenecer a assetIds; la ficha verifica miembro/compañía antes de llamar a useWorkstationSoftware(companyId, computer.id, ...). El cambio de principal cambia la unidad consultada; no mueve ni copia instalaciones. Su historial queda en Workstation; el del software sigue ligado al activo [E15, E18–E22].

Al retirar un activo de la composición o descomponer el puesto, no se localiza una cascada funcional que cierre o traslade sus instalaciones. La unidad puede seguir teniendo software y consultarse desde su propia ficha. Un puesto admite varios activos; la presentación de SO actual y el software del mapa corresponden al principal, no a una agregación de SO de todos los ordenadores secundarios. Las fichas de los secundarios son el camino de consulta individual [E15, E18–E21].

WorkProfile asocia persona, activo y cuenta opcional, con reglas de anfitrión y pertenencia. No tiene un requisito SO/versión compatible. La configuración de aplicaciones de perfil excluye SO tanto local como global. No se recomienda abrirla a SO para representar instalaciones ya modeladas [E17, E22].

Dependencias prácticas: principal válido, inventario/resolver accesibles, consultas de compañía disponibles y contrato Resources 3 en contextos con SO global. Una referencia no resuelta no se toma como ausencia. Los permisos/gates pueden impedir nuevas asociaciones, pero no son datos de fábrica ni pruebas de presencia del SO [E12, E13, E18–E21].

9. Escenarios SO-01–SO-16

Clasificación por contratos estáticamente inspeccionados, no prueba funcional nueva de los 16 recorridos. SOPORTADO significa representable mediante la operación descrita, con sus límites expresos. H: revisiones conservadas al actualizar/retirar, salvo borrado físico; I: FK/compañía, propósito y pareja abierta, según código, no inspección de BD real.

ID	Escenario / clasificación	Registro, consulta y visualización	Historial / integridad	Límite y evidencia
SO-01	FreeDOS → Windows 11 Pro: SOPORTADO	Fábrica textual FreeDOS + Resource Windows + instalación configured; ficha y principal derivados	H activo + instalación; I	Registro manual, sin importación ni certificación del origen [E01–E09, E18–E21]
SO-02	Windows de origen sin cambios: SOPORTADO	Registrar origen e instalación explícitamente; no basta el texto de fábrica para el resumen	H; I	No se infiere instalación desde fabricante [E01, E18]
SO-03	Origen sin SO → Ubuntu: PARCIALMENTE SOPORTADO	Origen «sin SO» textual, producto Ubuntu e instalación; consulta normal de unidad	H; I	Ausencia de origen no tipada/verificada; instalación sí representable [E01, E05, E11]
SO-04	Windows 10 Pro → 11 Pro: SOPORTADO	Retirar relación anterior y crear otra con producto distinto; historial/panel con cerradas	H en dos identidades; I	No cambiar resourceId de la relación original [E05–E10]
SO-05	Reinstalación limpia del mismo Windows: PARCIALMENTE SOPORTADO	Cerrar instalación y crear otra del mismo producto; se consultan ambas	H si no se borra; I	Sin evento/fecha efectiva de reinstalación; repetir valores no crea evidencia [E05–E10]
SO-06	Arranque dual Windows/Linux: PARCIALMENTE SOPORTADO	Dos productos configured en el mismo activo; resumen plural	H independiente; I	No hay partición, cargador, arquitectura ni arranque predeterminado; mismo producto en dos instancias no cabe [E07, E18]
SO-07	Servidor físico Windows Server: SOPORTADO	Asset servidor + producto SO + instalación; consulta de activo sin exigir puesto	H; I	No comprueba compatibilidad hardware ni derechos por núcleo; fábrica duplicada [E01, E08, E24]
SO-08	Hipervisor y varias VM: PARCIALMENTE SOPORTADO	Host/huéspedes como Assets propios, producto e instalación por unidad, relación genérica hosted; consulta individual	H/relación e I básicos	Inferencia de composición; sin agregado virtualización, descubrimiento, recursos o sincronización host/guest [E01, E16]
SO-09	VM con SO propio: PARCIALMENTE SOPORTADO	Plantilla propia y Asset para VM; instalación normal y ficha de esa unidad	H; I	No hay tipo/plantilla stock VM ni identidad/lifecycle de plataforma verificado [E01, E08, E16]
SO-10	Cambio de principal: SOPORTADO	Modificar principal miembro; ficha deriva SO del nuevo Asset	H puesto, software queda en sus unidades; I	Sin traslado/reinstalación automática [E15, E18–E21]
SO-11	Activo deja el puesto: SOPORTADO	Cambiar composición; el activo conserva instalación y consulta propia	H puesto e instalación; I	El puesto ya no debe presentar esa unidad como principal [E15, E18]
SO-12	SO desconocido: PARCIALMENTE SOPORTADO	Sin instalación configurada se muestra «No registrado»; no disponible/error tienen mensajes propios	Sin evento de desconocimiento; I sobre registros existentes	No distingue desconocido confirmado de ausencia de registro [E18, E19]
SO-13	Equipo entregado sin SO: PARCIALMENTE SOPORTADO	Texto de origen y ausencia de instalación	H del texto; I	NO SOPORTADO el estado operativo tipado «sin SO, verificado» [E01, E05, E19]
SO-14	Cambio de versión o edición: PARCIALMENTE SOPORTADO	Versión instalada editable con revisión; otra identidad comercial exige producto/relación nuevos	H; I, destino fijo	Build/arquitectura no estructurados; no confundir edición con versión instalada [E05–E11]
SO-15	Licencia OEM/volumen/suscripción: PARCIALMENTE SOPORTADO	Recurso licencia particular y vínculo opcional; panel e historial enlazan	H de UUID y valores; I	Sin cupos, derechos efectivos, transferencia OEM ni cobertura comercial automática [E08–E10, E14]
SO-16	Instalado fuera del inventario/verificación: NO SOPORTADO como conocimiento automático	Puede declararse manualmente configured; si no se registra, no aparecerá	H solo tras registro; I del registro	No hay agente, origen de observación o última verificación; no interpretar vacío como inventario exhaustivo [E05, E18, E24]

El estado efectivo de estos escenarios en una base desplegada es NO VERIFICADO para todos: no se consultaron sus datos. Las propiedades técnicas descritas no equivalen a ejecución, licitud de licencia ni disponibilidad productiva.

10. Deficiencias, riesgos y documentación desfasada

1. Origen ambiguo: dos campos de servidor pueden divergir; sin procedencia/certificación por unidad. La lectura del seed acredita el riesgo, no datos contradictorios existentes.
2. Presencia no modelada: no hay estado observado desconocido/sin SO/instalado con fecha. El vacío de UI es honesto como «No registrado», pero no acredita ausencia.
3. Instancias y tiempo: sin arranque/partición, arquitectura, build o fecha efectiva; una pareja abierta limita dos instalaciones del mismo producto; no hay evento de reinstalación.
4. Auditoría no permanente: /delete purga instalación y revisiones. Las referencias históricas de instalación no congelan todas las características comerciales externas.
5. Calidad de catálogo: particulares pueden estar incompletos o coexistir con globales equivalentes. No hay fusión/adopción. La normalización global no equipara sinónimos ni constituye UNIQUE SQL comercial.
6. Licencias documentales: no hay cálculo de consumo/derechos ni política OEM. La optionalidad no equivale a validación de cumplimiento.
7. Asignación frente a instalación: perfil, puesto e instalación son agregados distintos; no se detecta automáticamente discrepancia entre aplicación configurada en perfil y software declarado del activo.
8. Evolución e integraciones: plantillas propias y relaciones genéricas permiten documentación, no inventario automático o gestión completa de VM. No inferir capacidades a partir de texto libre o nombres.

La auditoría original, del 25 de octubre, afirmaba que el catálogo global solo admitía aplicaciones. Esa descripción es histórica y no describe el código actual, ampliado por la decisión implementada del catálogo SO. Se conserva el documento anterior para no reescribir su evidencia. La decisión del SO actual y sus ampliaciones deben leerse junto con esa extensión global.

El cierre técnico y el preflight distinguen código validado de autorización/despliegue. Esta auditoría no levanta su NO PREPARADO operativo ni acredita flags o esquema de producción. No se reejecutaron aquí aquellos diagnósticos ni se atribuyen sus pruebas a esta intervención.

11. Comparación de alternativas

Valoración cualitativa, relativa a requisitos examinados. D significa híbrido acotado, no implementar sus cuatro ejes sin necesidad. Compatibilidad con plugins se interpreta como composición modular existente: no se localizó un framework dinámico de plugins para inventario.

Criterio	A: atributo actual de Asset	B: instalación de software	C: SO propio del puesto	D: origen + instalación + vistas derivadas
1. Coherencia de dominio	Media: unidad correcta, mezcla producto/operación	Alta: diferencia producto e instancia	Baja: confunde equipamiento con configuración de unidad	Alta: responsabilidades separadas ya existentes
2. Normalización	Baja si repite texto/identidad	Alta: FK a Resource	Baja: duplica dato al mover unidad	Alta; origen textual sigue necesitando política
3. Catálogo de software	Poca reutilización	Reutilización directa actual	Requeriría vínculo adicional	Directa mediante B
4. Modularidad/plugins	Cabe en Assets, pero traslada software allí	Puertos y composición ya disponibles	Acopla puesto a semántica de producto	Respeta fronteras sin framework nuevo
5. Servidores y VM	Genérico, sin lifecycle VM	Instalación por cualquier Asset elegible	Mala cobertura de activos sin puesto	Cubre unidad independiente; VM sigue acotada
6. Varios SO	Texto/lista insuficiente sin modelo adicional	Ya soporta productos diferentes	Multiplica duplicación por puesto	Usa B; no añade instancias de arranque implícitas
7. Historial	Revisiones del activo, poca semántica de instalación	Revisiones propias; limitadas por delete	Historia del puesto no reconstruye unidad	Conserva ambos historiales; debe decidir retención
8. Licencias	Necesitaría otro vínculo	Vínculo particular ya existente	Riesgo de atribuir derechos al puesto	Usa B; derechos efectivos siguen pendientes
9. Inventario automático futuro	Reconciliación de texto difícil	Buen destino operativo, faltan observaciones/idempotencia de alta	Mal receptor si cambia equipamiento	Permite separar origen/observación/operación si se justifica
10. Frontend	Simplifica un campo, empobrece estados/múltiples	Paneles y selectores ya existen	Añadiría edición y sincronización duplicadas	Ya reutiliza lectura; extensiones deben ser dirigidas
11. Backend/APIs	Otro camino para el mismo hecho actual	Reutilización máxima	Nuevas reglas de propagación y traslados	Mantener contratos; ampliar solo carencias aprobadas
12. Migración	Riesgo al convertir textos en hechos operativos	Base ya instalada; no migrar fábrica automáticamente	Traslado de responsabilidad de alto riesgo	No necesita nueva base; deduplicar origen sería decisión separada
13. Divergencia	Alta respecto a catálogo/instalaciones	Baja si se usa como fuente operativa	Alta en cambios de principal/asignación	Baja con única fuente por concepto
14. Mantenimiento	Bajo al principio, alto al crecer semántica	Bajo incremental sobre implementación	Alto por sincronización redundante	Proporcional si requisitos/perfiles no se anticipan

A sigue siendo adecuada para origen, no como reemplazo textual del SO operativo. B es la base existente más reutilizable. C carece de justificación para el hecho instalado de una unidad. D combina las responsabilidades sin exigir producto físico, requisito de perfil ni observación automática como nuevos agregados inmediatos.

12. Modelo propuesto y recomendación preliminar

flowchart LR
  OR["Assets: origen de la unidad\naclarar campo canónico y procedencia"]
  PROD["Resources: producto SO\nparticular/global existente"]
  UNIT["Asset: unidad física o documentada como virtual"]
  INST["Companies: SoftwareInstallation existente"]
  WS["Workstation: composición/principal"]
  VIEW["Lectura SO actual derivada por activo"]
  DEC["A decidir: ausencia/desconocimiento,\nfecha efectiva, fuente/verificación, reinstalación"]
  REQ["Solo si hay requisito aprobado:\ncompatibilidad requerida por perfil"]
  OR --> UNIT
  UNIT --> INST
  PROD --> INST
  WS --> UNIT
  INST --> VIEW
  WS --> VIEW
  DEC -.-> INST
  DEC -.-> OR
  REQ -.-> PROD

Modelo propuesto, no implementado por esta auditoría. Los nodos «A decidir» y «Solo si» representan decisiones funcionales, no tablas, estados o entidades aprobadas. La parte central ya existe. No se propone transferir propiedad de datos ni un segundo catálogo.

Preferencia: D acotada sobre B, con confianza alta para conservar las responsabilidades existentes. Confianza media para elegir futuras extensiones, porque no se aportó una política de observación, retención, reinstalación, virtualización o derechos de licencia. La recomendación no sustituye decisiones ratificadas del catálogo global ni justifica reimplementarlo.

13. Arquitectura modular y extensibilidad

Assets debe conservar unidad, origen/equipamiento e historial de asignación; Resources conserva producto e identidad/plantillas; Companies conserva instalación, perfil y configuraciones. identity-runtime.ts inyecta servicios de inventario y referencias por transacción en initializeProfiles; el repositorio de instalación consume puertos y no carga el ORM de Resource/Asset desde su dominio. La composición web aporta información relacionada desde Companies a las fichas, sin introducir un import de Companies en el dominio Assets [E22, E25].

Los servicios públicos existentes bastan para mostrar el SO por activo y principal. No se necesitan nuevos puntos de extensión para ese requisito. Una futura captura automática debería entrar por contratos validados, con pertenencia, fuente/fecha/conflictos definidos; no escribir directamente en tablas ajenas ni usar un framework de plugins, repositorio base o bus de eventos sin consumidores. La capacidad de evitar duplicados y no-op existente no resuelve por sí sola reconciliación de observaciones externas.

Un perfil con requisitos de compatibilidad necesitaría una decisión propia; no debe confundirse con ApplicationConfiguration ni abrir SO en el propósito application-only. El coste y propietario de una futura regla deben fijarse antes de agregar dependencias. D08.2 continúa sin adopción implementada; no autoriza convertir locales, reescribir UUID o fusionar catálogos [E17, E22, E25].

14. Decisiones pendientes

1. ¿Se necesita registrar explícitamente ausencia confirmada y desconocimiento? ¿Qué evidencia y vigencia los acreditan?
2. ¿Qué campo de fábrica será canónico en servidor y qué hacer si los dos valores existentes difieren? No decidir una migración sin revisar datos autorizados.
3. ¿Se requiere origen por valor, fecha efectiva, última verificación y resolución de conflictos manual/agente/fabricante?
4. ¿Una reinstalación necesita identidad/evento propios y fecha efectiva, o basta cerrar/crear? ¿Se permiten instancias simultáneas del mismo producto?
5. ¿Debe prohibirse o limitarse el borrado físico y conservar auditoría central? ¿Quién autoriza corregir un alta errónea?
6. ¿Se requiere reproducción histórica de identidad/etiquetas del producto y licencia, además de sus UUID?
7. ¿La necesidad de VM/hipervisor es documental o exige lifecycle, descubrimiento, instancias y recursos?
8. ¿Licencias solo documentales o gestión de cupos, cobertura comercial, OEM, volumen y transferencias?
9. ¿Hace falta compatibilidad SO/perfil o no existe todavía un consumidor funcional que la justifique?
10. ¿Qué activos pueden tener SO y qué reglas de elegibilidad, además de pertenencia/no retirado, se necesitan?

Estas preguntas corresponden a responsables funcionales/arquitectónicos. No se resuelven creando campos, estados, migraciones o componentes en esta intervención.

15. Evidencias de código y pruebas consultadas

Rutas relativas al repositorio; enlaces con línea inicial y símbolos relevantes. La evidencia de persistencia son definiciones de migración/mapper y código transaccional, no un esquema instalado inspeccionado.

ID	Ruta / símbolo y líneas relevantes
E01	asset-catalog-seed.ts: factory_os 52–55; factory_preloaded_os 122–125; laptop/desktop 137–179; server 267–278; relation:hosted 357–364
E02	asset.model.ts: assets/asset_revisions 21–46; asset-relational-schema.ts: especificaciones y características 75–108
E03	asset.aggregate.ts: update y revisiones; asset.routes.ts: endpoints y actor 90–127
E04	resource.model.ts: tablas/revisiones; resource-scope-schema.ts: cláusulas/inspector; resource-scope-migration.ts: migración explícita
E05	software-installation-values.ts: input 5–12, transiciones 22–28; software-installation-values.vo.ts: terminales y destino 52–68
E06	software-installation.aggregate.ts: create 24–45, no-op/destino/transiciones/history 64–99
E07	software-installation-migration.ts: tablas/FK/unique 20–54; software-installation-persistence.mapper.ts: currentKey 125–130; software-installation-snapshot.ts: columnas
E08	software-installation-policy.ts: referencias/disponibilidad/licencia; software-installation-input.mapper.ts: destino/licencia/duplicados 28–50
E09	software-installation.routes.ts: GET/POST, negociación, delete; software-installation.use-cases.ts: creación/revisión y fecha 38–88
E10	sequelize-software-installation.repository.ts: DELETE raíz/historial 144–150, persistencia 157–175, asociación 215–275; software-installation-response.builder.ts: needsReview e historia
E11	resource-catalog-seed.ts: identidad, SO 170–180, evolución 214/286; operating-system-identity-policy.ts: alcance global e identidad publicada fija
E12	global-application-template-policy.ts: elegibilidad stock; global-resource.routes.ts: superficies por tipo; operating-system-identity.ts: edición/normalización
E13	resource-reference-reader.ts: validación asociación, filtros de propósito 195–199; resource-global-gates.ts: dependencias/propósito; verify-global-resource-enablement.ts: integridad antes de abrir
E14	resource-catalog-seed.ts: producto/modalidad/métrica/cantidad de licencia; software-installation-policy.ts: vigencia UTC
E15	workstation-values.vo.ts: principal miembro; workstation-input.mapper.ts: miembros/disponibilidad/exclusividad; workstation.model.ts: tablas; workstation.aggregate.ts: descomposición y revisiones
E16	asset-relationship.aggregate.ts: identidad/extremos/alta-retirada; seed en E01
E17	work-profile-values.ts: persona/activo/cuenta; work-profile-input.mapper.ts: contexto; application-configuration-values.ts: delivery/estado; application-configuration-policy.ts: solo application
E18	current-operating-systems.ts: selección compañía/activo, estado/tipo y no resuelto; use-asset-software.ts: consulta compartida
E19	current-operating-systems.tsx: error/carga/versión/inactivo/vacío 24–89
E20	use-workstation-detail-controller.ts: principal válido y lectura 29–41; workstation-detail-content.tsx: resumen
E21	company-inventory.tsx: composición del resumen en activo; use-workstation-software.ts: referencia global/local; workplace-map-model.ts: nodos de software del principal
E22	identity-runtime.ts: composición/gates y puertos 30–65; companies/module.ts: initializeProfiles, repositorio de instalación 186–189
E23	software-del-ordenador.md: declaración de eliminar alta errónea y sus revisiones; código en E10
E24	software-installation.test.ts: referencias/identidad/historia/licencia; current-operating-systems.test.tsx: OSUI-01–18, globales y estados; global-operating-systems-closure.integration.test.ts: DB-SO-01–20 y contratos, consultados sin ejecución
E25	composicion-de-modulos.md: constructor injection, servicios, prohibición ORM ajeno; D08.2: ratificable con condiciones, sin adopción implementada

Comprobaciones de esta entrega: correspondencia de rutas/símbolos, lectura de pruebas/migraciones, separación de modelos actual/propuesto y revisión del diff documental. No se han ejecutado las validaciones técnicas ni visuales de las implementaciones anteriores; sus resultados no se presentan como nuevos. La implementación de cualquier extensión queda fuera de esta auditoría.