7.1 KiB
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 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 usage: resource-inventory.service.ts:54 softwareFK: software-installation-snapshot.ts:7 applicationFK: configuration-snapshots.ts:57.
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, 02 plantillas, 03 SQL, 04 seguridad, 05 consumidores, 06 software, 07 API, 08 UX, 09 alternativas.
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. 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. No se ejecutaron typecheck/lint/test/check/build globales porque no hay cambios funcionales. Los cambios previos del usuario quedan fuera de esta entrega.