metis-desk/docs/auditorias/resources-global-scope/11-resumen-ejecutivo.md

# 11 — Resumen ejecutivo y decisiones

Auditoría del árbol de trabajo al 24 de octubre de 2026. Solo documentación; Resources v2 **no está implementado**. Leer [12](12-matriz-trazabilidad.md) para evidencia, comandos, límites y fuentes.

## Situación actual y viabilidad

**CONFIRMADO:** cada Resource registrado pertenece a una compañía obligatoria. El catálogo de **plantillas/campos** ya es global/local; no es un catálogo de productos. Aplicación se identifica mediante stockKey `template:application` (builtinKey en DTO); las plantillas propias pueden declarar uso application. Instalaciones y configuraciones de perfil usan Resource por UUID y conservan compañía, estado, versión e historial independientes. Licencias son otros Resource locales con vínculo opcional desde instalación. [owner: resource.aggregate.ts:11](../../../modules/resources/src/api/domain/resource.aggregate.ts#L11) [usage: resource-inventory.service.ts:54](../../../modules/resources/src/api/application/resource-inventory.service.ts#L54) [softwareFK: software-installation-snapshot.ts:7](../../../modules/companies/src/api/infrastructure/persistence/software-installation-snapshot.ts#L7) [applicationFK: configuration-snapshots.ts:57](../../../modules/companies/src/api/infrastructure/persistence/configuration-snapshots.ts#L57).

**DERIVABLE:** reutilizar una misma aplicación Resource entre compañías es viable sin fusionar SoftwareInstallation y ApplicationConfiguration ni duplicar producto por compañía. Requiere cambio transversal de ámbito, lectura, seguridad, contratos, UI y despliegue; no basta hacer companyId nullable.

## Recomendación y respuestas de cierre

| Pregunta | Respuesta propuesta y fundamento |
| --- | --- |
| 1. Ampliar Resource u otra entidad | Ampliar Resource; FKs operativas ya apuntan a su UUID. Entidad ApplicationCatalog + copia local no satisface reutilización única |
| 2. Representar ámbito | Preferencia A: scope explícito global/company con CHECK de coherencia; B derivado de NULL sigue viable y debe decidirse antes de DDL |
| 3. companyId en global | NULL, sin compañía ficticia; no significa tenant ni compañía seleccionada. La relación operativa mantiene su propia compañía |
| 4. Plantillas habilitadas | Lanzamiento solo Aplicación de serie global; no SMB, dominio, licencia, certificado, support ni OS global |
| 5. Identificación estable | stockKey template:application; resolver UUID real del catálogo, nunca nombre visible; locales de usage application siguen admitidos |
| 6. Referencias entre compañías | Autorizar contexto y resolver en servidor por finalidad: global elegible O local de C; rechazar local de B. Licencia/activo/perfil se validan separadamente |
| 7. Quién escribe globales | Permiso global explícito de Identity; posible asignación inicial al administrador inicial con aprobación. Hoy rutas Resource no lo exigen |
| 8. Consulta global/local | Gestión local permanece local; catálogo global separado y consulta mixta de candidatos/resolución por referencia con datos mínimos |
| 9. Selectores de software | Búsqueda conjunta application global/local y OS local, origen visible, ID fijo, licencia local aparte; sin elegir ámbito antes de buscar |
| 10. Instalaciones/configuraciones | Mantener raíces, IDs, destinos, versiones, estados y revisiones; adaptar resolución/elegibilidad/nombres, sin conversión automática |
| 11. Licencias | Mantener Resource local de uso license y FK opcional licenseResourceId; no compartir compra, calcular plazas ni afirmar cobertura |
| 12. Duplicación | Coexistencia explícita con origen y avisos; no fusión por nombre ni borrado local; migración de destinos requiere contrato separado |
| 13. Desactivación global | Conservar lectura/historia, impedir nuevas asociaciones según disponibilidad, marcar needsReview de abiertas; permitir notas/retirada, sin retirar automáticamente |
| 14. Migraciones | Scope/backfill y nullable si A, CHECK/FKs/índices ensayados; no cambiar IDs ni companyId de relaciones operativas; lectores preparados antes de activación |
| 15. Módulos/plugins | Resources, Companies, Identity, Assets y composición servidor/web; servicios públicos por propósito; registro de relaciones tipadas local intacto. Plugin Architecture v1 no confirmado |
| 16. Aprobaciones | D01–D10: ámbito, elegibilidad, permiso, modelo de operadores, privacidad/historial, disponibilidad local, duplicados, consolidación, API/URLs y despliegue |

Fundamentos detallados: [01 modelo](01-modelo-resource.md), [02 plantillas](02-plantillas-aplicacion.md), [03 SQL](03-sequelize-mariadb.md), [04 seguridad](04-aislamiento-autorizacion.md), [05 consumidores](05-consumidores-resource.md), [06 software](06-software-configuraciones.md), [07 API](07-contratos-api.md), [08 UX](08-propuesta-ui-ux.md), [09 alternativas](09-alternativas-arquitectonicas.md).

## Riesgos prioritarios

- **Crítico condicionado:** confundir autenticación con ACL operador–compañía. El producto documenta un espacio compartido de soporte; no se confirmó un permiso restringido por compañía. Si se exige ese aislamiento, se debe diseñar expresamente.
- **Crítico:** ampliar indiscriminadamente el servicio genérico de recursos hace accesibles productos globales a consumidores operativos, especialmente remoto. Globalizar aplicaciones no comparte licencias ni permisos.
- **Alto:** permisos globales ausentes en rutas actuales, DTO/mapper no nullable, versiones mixtas, FKs compuestas, propagación de plantillas, historial público y validación/asociación en transacciones distintas.
- **Medio:** duplicados, caché y nombres/enlaces en puestos/entornos, dashboard con NULL y selectores que cargan historiales completos.

Registro A01–A18 con evidencia, escenario, mitigación y prueba en [10](10-plan-implementacion.md). No se explotaron vulnerabilidades ni se midió rendimiento.

## Impacto y orden

Impacto **transversal significativo**, sin estimación numérica de jornadas: cambiar companyId afecta dominio, persistencia, DTO y lectura; usar referencias globales afecta ambos flujos y vistas secundarias. Los UUID simples preservan relaciones y reducen la necesidad de migrar datos operativos. No se justifican nuevas dependencias ni un módulo de catálogo separado de Resources.

Orden: R2.0 decisiones/políticas → R2.1 esquema/lectores → R2.2 autorización y contratos/resolución → R2.3 catálogo → R2.4 software + R2.5 perfiles → R2.6 duplicados/adopción. Preparar autorización puede adelantarse sin DDL; creación de globales permanece desactivada hasta actualizar todos los lectores. Rollback tras referencias globales requiere lectores compatibles o restauración coherente, nunca asignar compañía ficticia.

## Validación real

Comprobación estática y de evidencias; pruebas dirigidas Resources y dominio software/application correctas. Sin conexión a BD, DDL, migraciones, siembra ni pruebas HTTP. Sin Playwright/capturas ni validación visual; requisitos futuros en [08](08-propuesta-ui-ux.md). No se ejecutaron typecheck/lint/test/check/build globales porque no hay cambios funcionales. Los cambios previos del usuario quedan fuera de esta entrega.