14 KiB
R2.0 — Plan de implementación R2.1–R2.6
Ratificación posterior — 24 de octubre de 2026: D01–D10 y D04-R ratificadas en los términos recomendados de R2.0; variante A, Resource único con
scopeexplícito. Solo se autoriza implementar R2.1a. El registro vigente de alcance y evidencias está en 11 — Lectores compatibles. Los estados «propuesto», «recomendado» y «pendiente» del cuerpo se conservan como evidencia de la versión documental inicial y quedan actualizados por este registro; ratificación conceptual no equivale a ejecución de R2.1b–R2.6.
Estado: plan propuesto para ratificación, sin autorización para ejecutar ninguna fase desde esta tarea. Usa contrato 01, decisiones 02, gates 07 y pruebas 08 como fuentes únicas; no redefine políticas.
R2.1 — Persistencia, ámbito y lectores compatibles
Objetivo: introducir scope explícito y recursos globales rehidratables sin abrir creación, preservando el contrato local. Subetapa R2.1a prepara lectores de esquema legacy/scoped antes de R2.1b DDL; esto resuelve orden de dependencias de la solicitud.
Prerrequisitos: ratificación D01 y confirmación D02; diseño de rollback y captura SQL en test; baseline de aplicación/locales y tests existentes. No requiere haber habilitado manage ni UI global. Autorización del trabajo posterior debe ser expresa y separada de la aprobación de restricciones.
Cambios permitidos futuros: ResourceProps/create/rehydrate y mapper con ámbito; readInventory/writeInventory y helpers; ResourceRepository/UseCases para mantener rutas locales acotadas; adaptador pre-schema; prepareResourceTemplateUpdates, ResourceDashboardReader y removeResource con ramas correctas; migración explícita de scope/backfill/CHECK/nulabilidad/FK/índices ensayados. Actualizar especificaciones técnicas/test según contrato, conservando estado/history. Infraestructura no exporta modelos. Globales de test solo en metis_desk_test al ejecutar la futura fase.
Excluidos: catálogo/UI, nuevos privilegios concedidos, globales reales, asociación global de software/perfil, adopción/duplicados destructivos, fabricante/categoría/adopción en tabla nueva, refactor de vendor ni legado fuera del objetivo.
Dependencias y pruebas: G0→G1→G2; T01/T02/T03/T12/T13/T14/T19/T20/T21/T24, P01 y regresión de actual/history. Ensayo de migración repetida/interrumpida y rutas locales; pruebas negativas SQL sin quitar constraints.
Aceptación: root global válido solo en prueba, todos los legacy company con mismos IDs/historia, read/write local exactos, mapper rechaza corrupción, todas las FKs restauradas y checks ON, dashboard no cuenta producto como recurso local, propagación global/local conserva snapshots. Nuevas escrituras globales siguen bloqueadas por defecto.
Rollback: antes de primer global, reversión verificada sin NULL y con FK/default compatibles; nunca afirmar rollback de DDL en transaction. Si hubiera un global, ya requiere lectores compatibles; la fase no debe abrir ese estado fuera de test.
R2.2 — Autorización, contratos y resolución segura
Objetivo: implementar capacidades y contratos de lectura por propósito, validar referencia en la misma unidad de escritura y preparar negociación de clientes, sin habilitar producción de globales.
Prerrequisitos: R2.1 completo; D03/D04/D05/D09 ratificados, incluido alcance del guard a mutaciones globales de plantillas/campos. Si se pide ACL estricta o delegación desde primer día, diseñarlas antes de ejecutar/activar esta variante. D10 locking acordado.
Cambios permitidos futuros: servicio/guard público Identity para manage sobre isInitialAdmin según política; nuevos schemas Zod de Resources common/dto/request/response y tipos inferidos; routers de catálogo/candidatos/referencias propuestos en 04; lectura pública/admin separada; nueva factoría de servicio transaccional en Resources y composición servidor. Adaptar Infrastructure de Companies al puerto sin importar repositorio ni cambiar Application para conocer Transaction. Encapsular unidad catálogo→compañía→referencias, y guards contra consumidor no habilitado. Actualizar mapeo 401/403/404/409 y requestId. Compartir la normalización pura de búsqueda con los consumidores web desde un paquete común apropiado, sin importar rdx-ui desde servidor, si se mantiene la semántica del helper concurrente contrastado; no alterar otros listados ni introducir un motor de búsqueda nuevo.
Excluidos: catálogo visible/alta global operativa, tablas RBAC no aprobadas, ampliar IResourceInventoryService.list, cambiar DTO Resource legacy, ensanchar remoto/Access/certificados/SMB/soporte. No asignar isInitialAdmin a usuarios ni migrar compañías como efecto colateral.
Dependencias y pruebas: G3; T03/T05–T08/T10/T11/T13/T14/T15/T19/T23/T24/T26 pertinentes, S01–S12, M01, API A01. Tests de lectores por UUID/lotes activos/inactivos y errores técnicos; serialización probada con barriers, no sleeps.
Aceptación: servidor impide toda operación no autorizada y referencia local B desde A; no filtra datos operativos ajenos; list genérico sigue local; DTO mínimos no tienen history/notes; servicios usan transacción caller; respuestas legacy intactas. Flags negocio false y concesión no delegable documentada.
Rollback: volver a lector R2.1-compatible con flags false solo si datos globales aún no se han creado; si ya existen por una fase posterior, no retirar soporte de lectura/resolución por revertir este paquete.
R2.3 — Catálogo global de aplicaciones
Objetivo: administrar Resource global y ofrecer producto mínimo al espacio autenticado; no instalar software ni configurar perfiles.
Prerrequisitos: R2.2 y G3 completos; D05/D06/D07/D09 técnicos ratificados; plantilla de serie y campos globales consistentes; reintento por creationId, privacidad, cliente y recuperación aprobados.
Cambios permitidos futuros: comandos/resources globales y proyecciones, catalog/list/detail/create/update/status/history propios de Resources por entidad/operación; composición del shell de catálogos globales en Companies; reutilizar rdx-ui/vendor sin modificar vendor; i18n es/en y keys API diferenciadas. Alta global usa UUID v7 solicitado validado y primera revisión para replay; editar mantiene ámbito/owner/template. Historial admin paginado y solo manager. Evitar campo/category inventado, publicar solo whitelist de producto.
Excluidos: delete global, change-scope, nuevo módulo, licencias globales, adopción, instalar/configurar automáticamente, nuevas relaciones de fabricante/familia, snapshots operativos reescritos. No introducir dependencia externa para UUID ya disponible.
Dependencias y pruebas: G3b; T03/T09/T10/T11/T12/T13/T17/T18/T19/T21/T22/T23/T24, A01/P02, U01/U05 y futuras pruebas visuales con dataset prescrito. Test de homónimos como datos distintos, no NAME_EXISTS global por nombre.
Aceptación: manager puede crear/editar/status y leer historia, normal solo consulta datos mínimos; labels/estado y retorno correctos; primera raíz global preserva UUID/historia; solo producto, ninguna copia local. Flags software/perfil todavía false; no asociación global fuera de test.
Rollback: catálogo off bloquea nuevas mutaciones productivas y dependientes, preserva lectura y desactivación de seguridad; desde primer global no volver a V0. Restauración solo coherente y autorizada, no borrar global para hacer downgrade.
R2.4 — Integración con instalaciones de software
Objetivo: usar aplicación global o software local elegible como referencia de una instalación perteneciente a activo/compañía, con selector conjunto y licencia local separada.
Prerrequisitos: R2.2/R2.3 y G4; UI/cliente operativo compatible, lectores secundarios/históricos preparados, factoría transaccional y reglas de needsReview probadas. D04 no resuelto impide activación contextual segura.
Cambios permitidos futuros: policies/context/mappers/repositorio software y queries UI; nueva consulta candidatos/resolución por propósito; SoftwareInstallationsPanel/Form/History y alta rápida local; nombres/enlaces de activo/puesto/entorno y ProcessReviewReader cuando corresponda a referencias existentes de su contrato. Negociación de cliente compatible y gates. Componente visual compartido se extrae por dos consumidores reales software/perfil previstos, con props mínimas y sin DTO/endpoints en rdx-ui.
Excluidos: nullable/scope en software_installations, globalizar OS/licencia, alterar parejas fijas, rellenar versiones/licencias, cálculo de plazas, generar configuraciones de perfil, cambiar destinatarios remotos por recibir lista mixta. Sin DDL operativo salvo índice medido aprobado por necesidad.
Dependencias y pruebas: T04/T05/T07/T08/T09/T12/T13/T15/T16/T19/T22/T24/T26, M01/A01/P02 y U02–U05. Dos compañías usan mismo global con versiones/licencias independientes; global inactive conserva nombres/notas/retirada y estado local.
Aceptación: buscar Chrome muestra global/local A con origen e IDs, nunca B; nuevo vínculo valida producto activo en servidor al commit serializado; licencia sigue local; UUID/historial operativo intactos; todos los lectores de registros usados resolubles aun con flags apagados.
Rollback: software flag off detiene nuevos vínculos/reconfiguraciones dependientes globales, no bloquea local ni recuperación de existentes; conservar lector y protocolo de clientes. No reescribir resourceId para volver a versión anterior.
R2.5 — Configuraciones de aplicaciones por perfil
Objetivo: reutilizar el contrato application y la composición de selector, con perfil/estado/version/delivery independientes de instalaciones del equipo.
Prerrequisitos: R2.2/R2.3 y G5; contrato común de selector preparado en R2.4 o extraído conjuntamente con consumidores reales. Activación de perfil no exige habilitar software en producción; sí exige todas las superficies lectoras pertinentes.
Cambios permitidos futuros: application policy/context/repository/input y queries/forms/list/history/quick editor; búsqueda/resolución por propósito application-configuration; lectores de puesto/entorno/perfil/procesos y enlaces globales. Preservar dominio de perfil y la forma web/installed; versión web sigue null.
Excluidos: fusionar agregados, crear instalaciones automáticamente, licencia por perfil como función nueva, OS en selector, nullable en compañía operativa, cambiar resourceId de configuración existente o reescribir historia.
Dependencias y pruebas: T04/T06/T08/T09/T12/T13/T15/T16/T19/T22/T24/T26; M01, U02/U03/U04/U05. Verificar que misma aplicación tiene versiones distintas instalación/configuración y entre compañías sin sincronización accidental.
Aceptación: perfil A puede usar global application y locales A, nunca B/OS/otros; un cambio de producto sigue prohibido en update; estados/versión/historia propios; inactivo resoluble y recuperación disponible. Refetch no pierde selección ni contexto de perfil fijo.
Rollback: flag perfil off para nuevos vínculos/reconfiguraciones dependientes, lectores/retirada/notas/historia siguen; no downgrade de release que ignore UUID global en configuraciones existentes.
R2.6 — Coexistencia, avisos y futura adopción
Objetivo inicial: convivencia sin pérdida, procedencia clara y coincidencias indicativas; preparar revisión humana de equivalencia sin modificar referencias.
Prerrequisitos: catálogo/resolución estables, D07 ratificado para normalización/avisos; D08 no necesita aprobar consolidación para entregar coexistencia. Datos de prueba y política de no fusión visibles.
Cambios permitidos futuros iniciales: búsqueda de posibles coincidencias global/local A y UI de procedencia/aviso; elección explícita de global al crear nuevas relaciones, sin automatismo sobre existentes; documentación de alcance y comprobación de invariantes. No DDL adicional necesario.
Excluidos iniciales: conversión local→global, cambio de companyId, sustituir resourceId con update, fusionar snapshots, borrar recursos locales, cerrar relaciones simulando retirada técnica, asignación/consumo de licencia, adopción persistida ficticia. Una operación de sucesión posterior necesita ADR específico D08, persistencia relacional de auditoría y pruebas de reversión/idempotencia antes de incluirse en otro prompt.
Dependencias y pruebas: G6, T17/T25, M01 de lectura y U01/U02 con homónimos/fabricante faltante/diferente, ediciones, cifras y acentos. Pruebas de sucesión no se marcan implementadas por una pantalla de avisos.
Aceptación: ningún registro previo cambia por descubrir coincidencia; global/local siguen identificables; avisos no afirman equivalencia, usuario puede continuar con un producto distinto. Aprobación de consolidación se tramita aparte si se desea.
Rollback: retirar avisos/composición sin cambios de datos. Una consolidación futura, si llega a implementarse, tiene rollback compensatorio propio y no se considera reversible con este rollback de presentación.
Trabajo posible sin esquema y límites de alcance
Sin DDL: especificar/ratificar contrato, preparar guard conceptual basado en Identity actual, schemas/proyecciones/queries locales, adaptación de lector pre-schema, keys/negociación cliente y avisos sin mutación. Ninguna permite almacenar un Resource global válido en la tabla NOT NULL actual. Este listado no autoriza esas implementaciones en R2.0.
Cambios transversales futuros exigen los cinco comandos de validación de AGENTS además de integración/Playwright apropiados; no se pretende validar frontend/persistencia con checklist. No migrar datos reales, instalar dependencias o modificar vendor para completar una fase sin aprobación del alcance. La ejecución exacta de pruebas y pendientes se informa por fase.