metis-desk/docs/architecture/resources-global-scope/19-d08-2-resolucion-ratificacion.md

D08.2 — Resolución de decisiones y expediente de ratificación de adopción

1. Estado del documento

Versión sometida a aprobación: D08.2-v1, 25 de octubre de 2026. Dictamen B: ratificable con condiciones. D08 no está ratificado. No se autoriza R2.7 ni despliegue. El acta efectiva permanece vacía en §25.

Entrega exclusivamente documental y de análisis estático. Solo se añade este archivo; no se modifica documentación anterior, código, modelos, migraciones, APIs, DTO, permisos, flags, dependencias ni tests. No hay ejecución de servicios, fixtures, suites de aplicación, adopción, compensación ni DDL/DML. Las fases futuras requieren nueva instrucción y ratificación expresa.

Clasificación usada en todo el expediente:

Código	Significado
CV	Contrato vigente comprobado en código.
DR	Decisión previa ratificada, con evidencia en el registro vigente.
P1	Propuesta D08.1, aún sin aprobación efectiva.
RT	Nueva recomendación técnica de este expediente; no comportamiento instalado.
PA	Decisión funcional/arquitectónica pendiente de autorización del propietario.

Salvo indicación CV/DR, los contratos, nombres de tablas, estados, métodos, headers y permisos de adopción son RT/PA. «Resolver técnicamente» significa definir una alternativa consistente y verificable, no aprobarla ni afirmar que sus dependencias están implementadas.

2. Resumen ejecutivo

Se recomienda sucesión explícita, sin reasignar resourceId: cerrar documentalmente las raíces seleccionadas y crear sucesoras con UUID nuevos. Particular, global, raíces y revisiones anteriores mantienen identidad, ámbito y pertenencia. La coincidencia R2.6 no acredita equivalencia.

Se concretan seis decisiones sometidas a aprobación independiente:

1. Cierre: operación específica de dominio y terminal superseded, solo en SoftwareInstallation y ApplicationConfiguration; pending/configured admisibles, retirada en curso bloqueada. No usar removed para simular desinstalación.
2. Parcialidad: selección de una o varias asociaciones, incluso de ambas familias, con confirmación de todas o ninguna. Las omitidas siguen usando el particular.
3. Permisos: preparación por operador ordinario en su contexto y consulta de sus propios planes; confirmación, operaciones/auditoría y compensación restringidas a capacidad administrativa específica, inicialmente administrador inicial. Sin RBAC nuevo ni privilegio implícito por leer catálogo.
4. Validez: plan persistido, huella canónica explícita, TTL 30 minutos y revalidación bajo locks. Una nueva asociación a la fuente, aunque no seleccionada, invalida conservadoramente el plan.
5. Retención: separar planes no confirmados de procedencia confirmada. Los primeros no deben bloquear borrados operativos; los segundos sí preservan mediante FK RESTRICT raíces y revisiones implicadas. Se propone depuración técnica de detalles efímeros a 30 días, sujeta a aprobación, conservando tombstones/idempotencia.
6. Compensación: no ejecutable en el primer piloto. Preservar datos desde el primer commit. La confirmación sin una corrección general equivalente solo es aceptable si el propietario acepta expresamente esa limitación; en caso contrario, R2.7-C queda bloqueada hasta aprobar y disponer de compensación.

Se mantienen como prerrequisitos técnicos: escritores conjuntos ligados a transacción, INSERT estricto, autorización pública revalidada dentro de la unidad, auditoría común y lectores preparados para el nuevo terminal. Ninguno se presenta como disponible hoy.

3. Fuentes y método

Se leyó íntegramente D08.1, incluidos sus 685 renglones, diagramas, matrices, P01–P08 y dependencias T01–T05. Se consultaron AGENTS.md y DESIGN.md y se reutilizan las lecturas completas de esta secuencia de R2.0, D01–D10, seguridad, HTTP, consumidores, R2.2, R2.3, R2.4, R2.5 y R2.6. La comparación de huellas con la inspección D08.1 no detectó cambios en esas fuentes ni en los servidores de Resources/Companies/Assets/Identity; se reabrieron los puntos críticos de código citados en §4.

Entorno: WSL, Node 24.20.0, PNPM 11.25.0, HEAD inicial c95c3f1d59dd3c629076a3272e504822c36a7687, Git limpio. Snapshot de 3.169 archivos previos excluyendo .env y directorios generados; no se imprimen ni copian credenciales. Skill aplicada: rdx-solid, con referencias de arquitectura, backend y decisiones ya consultadas, para distinguir evidencia, propuesta y dependencia. No se necesita diseñar UI detallada ni instalar herramientas.

La evidencia es documental/estática. Un índice o una FK declarados en código no prueban que toda BD desplegada ya los tenga: esa comprobación futura corresponde a R2.7-A en MariaDB desechable. Las cifras históricas R2.6 y la deuda global previa no son nuevas validaciones de D08.2.

4. Contratos actuales contrastados

ID / clase	Fuente real	Resultado contrastado
E01 / CV	Resource, scope, migración	Variante company/owner UUID o global/null; create/createGlobal, scope/owner/plantilla inmutables; CHECK y FK del esquema scoped.
E02 / CV	Software, transiciones, VO	create pending/configured; target asset/resource fijo; closed solo removed/never_configured; revisiones UUID/actor/fecha, update sin cambios no añade revisión.
E03 / CV	Profile application, transiciones, VO	Mismo ciclo, target profile/resource fijo; installed/web y versión null obligatoria en web.
E04 / CV	Software use cases, Profile use cases	save adapta create/update dentro de callback; no closeForSuccession ni Transaction externa. remove es eliminación física, no cierre.
E05 / CV	Software repository, Profile repository	get/save/remove abren transacción propia. persist privado usa ON DUPLICATE KEY UPDATE. El retorno Result.fail no es por sí mismo instrucción de rollback.
E06 / CV	Migración Software, Profile	QueryInterface, no dos Model con hooks de adopción. currentKey nullable UNIQUE; UNIQUE(configurationId,position); FK RESTRICT y revisiones actor/fecha.
E07 / CV	Resources session, puerto, dependencias	Sesión ligada a Transaction; catálogo S antes de compañía X; resolve incluye usados inactivos, validateNewAssociation exige activo/gate por propósito.
E08 / CV	Identity, repository, guard	session valida active/authVersion; manage exige isInitialAdmin y marcador identity_state. No autorización de adopción ni lector de autorización ligado a Transaction externa.
E09 / CV	WorkProfile, Workstation	Identidades y ciclos locales independientes. La adopción no reasigna persona/equipo/perfil ni fabrica instalaciones desde configuraciones.
E10 / CV	Software policy, Profile policy	Activo no retirado; perfil/persona activos para nuevas configuraciones; licencia local activa/vigente. No prueba de cobertura comercial ni compatibilidad de versión/edición.
E11 / CV	Software DTO, Profile DTO, estado compartido	Zod estricto de cinco estados; superseded no existe y no debe añadirse al enum de Access. Header Resources:2 solo negocia referencias globales.
E12 / CV	Uso, Software keys, Profile keys	Consulta a demanda de colecciones de C, incluidos cerrados; no preflight de dependencia completo. Estado remoto en Query; invalidaciones en onSuccess del cliente.
E13 / CV de ausencia	Diseño de auditoría, composición actual	Hay revisiones/logs; auditoría común está acordada para implementación futura. No garantía transversal ya instalada.
E14 / CV	Config, gates Resources	Catálogo/software/candidatos/perfiles default false; no gate de adopción.
E15 / CV de pruebas existentes	R2.4, R2.5, R2.6, barreras	Casos existentes de targets fijos, desactivación en ambos órdenes, licencia local, homónimos e instantáneas; no pruebas de adopción. Consultadas, no ejecutadas.
E16 / DR	Registro vigente D01–D10	Ratificación conceptual previa con alcance registrado; D08 conserva sucesión diferida, prohibición de conversión/reescritura y ningún permiso de ejecución de adopción.

No se detectó escritor operativo con hooks que produzcan un efecto externo previo al commit en los dos repositorios inspeccionados: escriben SQL/revisiones dentro de su unidad. No se generaliza esta conclusión a todos los módulos. Query onSuccess ocurre en cliente tras respuesta; no da auditoría durable ni atomicidad entre endpoints.

5. Invariantes

DR/CV preservadas y obligaciones del nuevo contrato:

• Resource particular y global mantienen UUID, owner, scope y plantilla. Sin merge, alias universal ni equivalencia deducida de nombre/proveedor.
• Predecesoras conservan UUID/target y revisiones anteriores. Solo se añade revisión de cierre documental autorizado. Sucesoras, revisiones e items nuevos llevan UUID v7 propios.
• Cerradas históricas no se editan, reabren, eliminan ni trasladan a otro producto. Particular no se archiva ni se oculta automáticamente.
• Versiones, delivery, licencias, notas y estado sucesor se revisan expresamente. No pasan al Resource global ni se heredan por similitud.
• Una operación afecta una C/fuente/destino y solo raíces seleccionadas; pertenencia y propósito se verifican en servidor, incluso para admin.
• Selección atómica, idempotencia persistida y auditoría común en el commit; hash, botón deshabilitado y requestId no sustituyen esas garantías.
• Gates off no revierten commits ni ocultan historia. Compensar es otra operación autorizada, nunca rollback posterior al commit.

A1 (UPDATE directo de resourceId) y retirada técnica ficticia son incompatibles con estas invariantes. Ratificar su prohibición no autoriza otros comandos por omisión.

6. Resolución de cierre

D08.2-A — RT/PA. Misma decisión preferida para ambos agregados: comando específico de sucesión y terminal documental superseded. No dos máquinas nuevas divergentes.

Estados actuales y significado CV

Estado	SoftwareInstallation	ApplicationConfiguration	Cierre actual
pending	Instalación pendiente de documentar/configurar.	Necesidad de aplicación pendiente de configurar.	Puede pasar a configured o never_configured.
configured	Se documenta instalación/disponibilidad configurada en el equipo.	Disponibilidad comprobada para el perfil.	Solo a removal_pending; no cierre documental actual.
removal_pending	Retirada técnica en curso/pendiente.	Retirada de disponibilidad pendiente.	Puede pasar a removed.
removed	Retirada registrada.	Retirada registrada para el perfil.	Terminal inmutable.
never_configured	Pendiente cancelada sin configuración.	Necesidad que no llegó a configurarse.	Terminal inmutable.

La operación pública de transición es save→mapInput→aggregate.update; no endpoint close autónomo. Datos requeridos: C, identidad previa y todos los valores del contrato, actor de sesión y fecha válida no anterior a última revisión. Software: asset/resource, licencia/versión/notas nullable; Profile: profile/resource, delivery, versión/notas nullable. Cambios reales añaden revisión. Cerradas liberan currentKey, no eliminan registros. No hay ejecución técnica de desinstalación ni actualización de otras asociaciones.

Alternativas evaluadas

Alternativa	Resultado técnico
Transición existente	pending→never_configured es válida si se cancela realmente esa necesidad, pero no expresa todas las sucesiones ni sirve para configured. removed exige retirada real. No solución general.
Causa nueva sin cambiar estados	Causa sobre removed seguiría afirmando retirada falsa. Mantener configured con causa lateral obligaría a redefinir closed/currentKey y lecturas en todos los caminos. No es una extensión gratuita; deja dos fuentes de ciclo.
Operación específica sin estado ni otro ciclo	Solo procedencia no cierra la raíz; persistiría abierta. Es parte necesaria del diseño, insuficiente por sí sola.
Operación específica + terminal propio	Expresa que se cierra un registro por sucesión, sin afirmar retirada física. Una fuente de closed, con evolución contractual explícita. Preferida.

Agregado / estado	Transición RT	Significado	Historial	Cambios requeridos y riesgo	Aprobación
Software pending/configured	closeForSuccession → superseded y create sucesora pending/configured revisada	Cierre del registro particular; no desinstalación.	Anteriores intactas, cierre causal y primera revisión sucesora.	Nuevo método específico, union propia, closed/currentKey, mapper/lectores/DTO. Incompatible con antiguos.	PA-A.
Profile pending/configured	Igual	Nueva documentación de disponibilidad del mismo perfil, sin transferir persona/equipo.	Igual; delivery/versión explícitos.	Mismas adaptaciones específicas y consumidores de entorno/procesos.	PA-A.
Ambos removal_pending	Rechazar selección	No interferir con retirada real.	Intacto.	ADOPTION_WITHDRAWAL_IN_PROGRESS; resolver fuera, nuevo plan.	PA-A.
Ambos removed/never_configured/superseded futuro	No seleccionables	Historia conservada; no reapertura.	Intacto.	Terminal futuro solo existe tras aprobar/desplegar A.	PA-A.

El comando propuesto solo puede ejecutarse por el coordinador autorizado de sucesión, no mediante body genérico state:superseded de CRUD ordinario. Conserva target, versión, licencia, delivery y notas anteriores. Añade una revisión con causa vinculada a la operación; no copia en la anterior los valores de la sucesora. La causa normativa es adoption; una futura compensación usaría causa distinta y contrato aparte.

Pregunta concreta PA-A: ¿se aprueba el terminal documental superseded y el comando causal específico para pending/configured de ambos agregados, sin retirada técnica y con bloqueo de removal_pending? Rechazarlo mantiene A0/R2.6; no habilita A1 ni el piloto alternativo pending-only.

flowchart LR
    P[Particular: UUID L conservado] --> A[Raíz anterior: UUID A y resourceId L]
    A --> C[Cierre documental superseded]
    C --> H[Historia anterior conservada]
    C --> O[Operación y causa de adopción]
    O --> N[Sucesora UUID B nueva, mismo asset o profile]
    N --> G[Global: UUID G conservado]

7. Adopción parcial

D08.2-B — RT/PA. Se recomienda selección parcial y commit atómico de la selección; adopción total obligatoria se descarta como norma inicial por bloquear casos válidos con referencias ajenas al alcance o retirada en curso.

Cuestión	Resolución propuesta
Una sola asociación	Sí; mínimo una seleccionada ejecutable, máximo 100 inicialmente.
Software y Profile juntos	Sí, una transacción Companies/MariaDB, sin derivar automáticamente unas de otras.
Operaciones sucesivas sobre mismo Resource	Sí, con planes nuevos sobre raíces aún abiertas. No reutilizar predecesora ya sucedida.
Asociación omitida	selected=false y acción keep con motivo exclusion/not-selected/closed/blocked; conserva UUID/valores/uso.
Particular parcialmente en uso	Sí, normal y explícito; no flag global «adoptado» ni redirect.
Seleccionada se cierra/modifica	Plan obsoleto, cero efectos de toda la selección.
Aparece nueva asociación a fuente	Invalida plan completo aunque no esté seleccionada; nuevo preflight y revisión.
Conflicto no seleccionado	No bloquea por sí solo; visible como omitida bloqueada, sin promesa de resolverla.
Plan con omitidas bloqueadas	Confirmable si cobertura completa, sin bloqueos de plan/seleccionadas y testigos vigentes.
Información de uso restante	Conteos/UUID y motivos de abiertas no seleccionadas, cerradas y consumidores locales intactos, dentro de C.

Ejemplo de ratificación: tres instalaciones abiertas + dos configuraciones abiertas + cuatro cerradas; seleccionar dos instalaciones y una configuración crea tres sucesoras o ninguna. Quedan una instalación y una configuración abiertas usando el particular; las cuatro cerradas no cambian.

No representar elegibilidad, selección y obsolescencia como un único enum excluyente:

• eligibility: eligible/blocked, con códigos de motivo;
• selected: boolean, decisión explícita; seleccionada exige eligible;
• disposition: succeed/keep, derivada y comprobada en servidor;
• validity: current/unverified/stale/expired, evaluación del plan/testigo;
• exclusionReason explica no selección, cierre o bloqueo.

Así una fila puede ser bloqueada y excluida a la vez. Son dimensiones de planificación, no nuevos estados operativos. El estado ready/blocked guardado corresponde a la fotografía y depende de bloqueos seleccionados/globales. En la respuesta inicial current significa validado en validatedAt; un GET posterior sin revalidación completa muestra unverified, no una garantía de vigencia. La confirmación siempre vuelve a evaluar bajo locks. Nunca saltar filas fallidas después de iniciar el commit.

Pregunta PA-B: ¿se aprueba parcialidad con estas reglas, incluyendo que una nueva asociación de fuente invalide el plan aunque se pretenda conservarla?

8. Autorización

D08.2-C — RT/PA. Hay dos categorías operativas comprobadas: sesión ordinaria y administrador inicial identificado por flag y marcador persistido. No se inventan roles de compañía ni RBAC/grants delegables. D04 conserva soporte compartido: abrir explícitamente B puede ser admisible, pero no mezclar referencias B dentro de A.

Se refina P1 admin-only: preparar un plan usa datos propios ya accesibles al operador y no mueve asociaciones; se recomienda permitirlo a sesión ordinaria con capacidad explícita por política. Confirmar sí exige capacidad administrativa distinta. Identidad de preparador y aprobador se conservan separadas; no se exige ni se simula doble persona en la primera política.

Operación	Actor / capacidad conceptual RT	Ámbito, origen/destino y controles servidor	Riesgo / capacidad nueva
Coincidencias	Sesión ordinaria, contrato vigente	C válida, origen particular propio, global mínimo; gate catálogo.	CV; lectura no otorga escritura.
Uso particular	Sesión ordinaria, API vigente	Registros propios C, sin uso de otras compañías.	CV; no acredita cobertura completa de un plan.
Generar preflight	Operador con adoption.plan	C, fuente propia, global público y selección válida; actor de sesión, CSRF y límites.	Nueva política pública, sin datos admin.
Consultar plan	Creador con plan o admin con confirm/history	C y pertenencia del plan; no entregar motivos/evidencias de otro operador ordinario.	Nueva, caché por sujeto.
Confirmar	Administrador inicial con adoption.confirm	Plan de cualquier preparador autorizado, C, UUID/propósito, huella y evidencia revisados; reautorización dentro de unidad.	Nueva específica: global.manage no se hereda tácitamente.
Consultar operación/auditoría	Admin con adoption.history y acceso de auditoría correspondiente	Solo C; fuente/destino mínimos y efectos locales; sin notes/historia admin global.	Nueva, distinta de referencia operacional mínima.
Solicitar plan compensatorio futuro	Admin con adoption.compensation.request	C/operación original, integridad/evolución; no disponible en piloto.	Capacidad independiente futura.
Confirmar compensación futura	Admin con adoption.compensate	Plan nuevo, permiso específico, locks y policies; no disponible en piloto.	Nueva, no concedida por confirmar adopción.

Los nombres son semánticos, no filas de permisos existentes. Implementar política con servicios públicos Identity y asignación fija aprobada; no tablas RBAC nuevas. El creador ordinario puede ver en su plan que se consumió y el ID de operación, sin recibir el resultado/auditoría restringidos ni un enlace de detalle que prometa acceso. La proyección operativa mínima de sucesión puede mostrar UUID anterior/sucesora/operación y causa documental a lectores ordinarios de C, pero no motivo comercial/evidencia de auditoría ni enlace que prometa acceso a su detalle restringido.

Revalidación dentro de confirmación

El guard vigente no recibe Transaction. RT: guard HTTP primero y puerto público Identity ligado a la unidad, tras adquirir locks operativos y antes de cualquier DML, que relea active/authVersion, isInitialAdmin y marcador identity_state y evalúe la acción/policyVersion. No importar UserModel desde Companies ni confiar en capability enviada/caché del navegador.

Protocolo propuesto: tras catálogo→compañía→comando/plan, lector Identity toma estado de identidad S y actor S, mediante su propio adaptador, manteniéndolos hasta commit. La comprobación es el punto de autorización efectivo. Si invalidación de sesión se confirmó antes, rechazar; si el lector obtuvo primero los locks, la modificación posterior espera y la unidad ya autorizada puede terminar. No se promete cancelación retroactiva. Identity actual no bloquea compañía/catálogo al actualizar usuarios; ampliar ese grafo exige revisar orden/pruebas antes de activar.

Actor cambiado respecto a la solicitud o sesión cuyo authVersion difiere del usuario vigente no reutiliza la autorización. Una sesión nueva válida del mismo actor puede recuperar su resultado original; no se ata la idempotencia a una cookie revocada. Cambiar permisos/policyVersion invalida el plan o exige reautorización nueva según §9, nunca conservar un booleano aprobado. Cada GET sensible también comprueba sesión/capacidad vigente.

PA-C: aprobar preparación ordinaria/consulta propia y confirmación/history admin inicial por capacidades explícitas, sin delegación ni doble firma, con compensación separada. Si se exige aislamiento operador–compañía, delegación o dos aprobadores, bloquear esa activación hasta diseñarlo; no imitarlo en UI.

9. Versionado y concurrencia

D08.2-D — RT/PA. Se mantienen revisiones UUID/posición, no se inventa versión numérica existente ni timestamp como CAS suficiente. Versión propuesta de plan: d082-plan-v1; policyVersion y representación operativa independientes. TTL inicial 30 minutos, 100 seleccionadas, 10.000 observadas; límites técnicos propuestos que requieren aprobación y medición, no SLA.

Datos canónicos explícitos

Huella SHA-256 sobre secuencia tipada UTF-8 con nombre/orden de campo definidos, longitudes de bytes y marcadores distintos para ausente, null, texto, entero y booleano. Arrays como conjuntos ordenados por tipo y UUID, UUID minúscula, fechas UTC ISO, posiciones enteras y valores ya normalizados por su contrato de dominio. No JSON.stringify(dto), normalizador fuzzy ni orden de propiedades del navegador.

Grupo incluido	Campos que vinculan lo revisado
Contrato/contexto	Versión algoritmo/schema/policy; planId, C, actor preparador, kind y confirmación que exige; createdAt/expiresAt. La autorización efectiva se comprueba aparte.
Fuente/destino	UUID, scope/owner/template, active, revisión Resource/posición como token opaco, nombre/proveedor/edición descrita comercialmente y forma pública pertinente. Sin DTO administrativo.
Fuente observada	Conjunto completo de raíces Software/Profile de la fuente, IDs, estado y última revisión/posición; selección/acción y valores relevantes. Revisión nueva invalida aunque vuelva a valores anteriores.
Pares destino	Abiertas/cerradas relevantes para los asset/profile seleccionados, IDs/revisiones y currentKey esperado.
Contexto	Asset no retirado; perfil/persona/compañía y pertenencia, actividad y revisiones o columnas de testigo cuando no hay revisión; licencia ID/owner/uso/active/vigencia y propuesta explícita.
Intención/evidencia	Estado/versión/licencia/delivery/notas deseados, decisiones preserve/replace/clear y evidencias ordenadas; dependencias/bloqueos conocidos y gates de propósitos seleccionados.

Excluir etiquetas/traducciones, colores, iconos, orden visual, nombres de presentación de actores, cursores/tamaño de página, requestId y datos de otras compañías. Nombres comerciales sí forman parte de la revisión; no confundirlos con labels visuales. Una nueva revisión Resource puede invalidar conservadoramente sin publicar sus notas privadas. La fecha UTC de licencia se reevalúa aunque el hash histórico sea igual.

Separar creationRequestFingerprint (solo entrada+actor/C para reintento de creación), planFingerprint (fotografía/intención) y requestFingerprint (comando+aprobador+plan/huella/aceptaciones). Ninguno es permiso. El plan no está «aprobado» por generarlo: su revisión se acepta explícitamente al confirmar y queda acreditada solo en la operación/auditoría del commit.

Revalidación y locks

1. Autenticar y validar formato/contrato de entrada y ámbito, sin rechazar todavía por TTL ni gates un comando que pudiera estar confirmado. Distinguir permiso confirm para ejecución nueva de history para recuperar un resultado previo.
2. Consultar identidad/clave del comando en su ámbito autorizado. Si ya tiene resultado, verificar huella y permiso de consulta y devolverlo antes de TTL/gates. Si es nuevo, reservarlo con permiso confirm en transacción breve de metadatos con auditoría. Para pending, continuar sin crear otra reserva.
3. Unidad operativa: puerto Resources primero, catálogo global S→compañía C X; después comando y plan, y autorización Identity estado S→actor S (§8).
4. Current reads de Resources fuente/destino/licencias por UUID ordenado mediante puertos, contexto/dependencias protegidos y raíces Software por UUID, luego Profile por UUID. No elevar catálogo S a X llamando a CRUD Resource.
5. Reconstruir testigos bajo mutex, comprobar versión/policy/huella/TTL, permiso, gates, evidencia, elegibilidad, parejas y disponibilidad. Lectura consistente previa a espera no sustituye current read.
6. Validar todos los candidatos, cerrar/crear/persistir procedencia y auditoría; un commit. Fallo post-escritura obliga a rollback completo.

Cambio entre plan y confirmación	Resolución recomendada
Nueva asociación a fuente, aunque no seleccionada	Stale de todo el plan; preflight y revisión nuevos. Se elige esta opción conservadora, no aviso no bloqueante.
Seleccionada cambia/cierra o aparece dependencia	Stale, ninguna sucesión.
Cambia una omitida observada	Stale porque cambió fotografía de uso restante; no «resolver» seleccionándola automáticamente.
Cambio ajeno a fuente/contextos/pares relevantes	No invalida solo por compartir C; no fingerprint de toda la BD.
Global se desactiva/cambia revisión relevante	Rechazo/stale; si cambia después del commit, relaciones sobreviven con needsReview derivado.
Cambian permisos o policyVersion	Reautorizar dentro; versión de política distinta exige plan nuevo. 401/403 si sesión/capacidad inválida.
Gate necesario off	Bloquear ejecución nueva; resultado confirmado sigue consultable.
Cambia companyId en petición	Plan no pertenece a C: 404 uniforme, no regenerar huella para otra C.
TTL cumplido	Expired, nuevo plan; si había commit, devolver resultado original sin reejecutar.
Algoritmo/contrato rotado	Plan anterior no confirmable salvo compatibilidad explícita versionada; recomendación inicial: nuevo plan.

No snapshot entre peticiones ni aislamiento global SERIALIZABLE inventado. Compañía es mutex cooperante para altas/ediciones; UNIQUE protege par aun sin fila destino que bloquear. No SKIP LOCKED en selección. Deadlock/timeout aborta y puede reintentarse acotadamente como unidad completa. Ensayar el nuevo grafo Identity/Companies y todos los escritores antes de activar. No atribuir a un hash protección frente a DML externo que ignore el protocolo.

10. Retención

D08.2-E — RT/PA. No se ha localizado una política corporativa de plazos aplicable a adopción. Los tiempos siguientes son una propuesta técnica, no plazos legales ni consentimiento. Se refinan explícitamente las FK generales de P1: observar una raíz en un plan no confirmado no debe impedir borrarla por una operación ordinaria válida.

Clase	Fuente de verdad / retención propuesta	Borrado y consultabilidad
A. Dominio y procedencia confirmada	Resources, raíces y revisiones, líneas de sucesión tipadas; conservar íntegramente, sin purga automática inicial.	FK RESTRICT sobre identidades/revisiones implicadas; delete antes permitido pasa a bloquearse para esas raíces. Cambio funcional sometido a PA-E/I.
B. Operación confirmada	Operación, plan/evidencia aprobados completos, resultado inmutable, comandos finalizados, claves/huellas, auditoría causal. Conservación indefinida hasta política aprobada distinta; ninguna fecha automática de borrado.	Consulta autorizada por C y permiso vigente; no reconstruir resultado con valores actuales de sucesoras.
C. Borrador local no enviado	Estado temporal del formulario; no fuente de verdad.	Cancelable/regenerable sin crear adopción ni evento de negocio.
C. Preflight persistido no confirmado, expirado o bloqueado	Fotografía relacional normalizada y evidencia; TTL de confirmación 30 min. Propuesta de elegibilidad para depurar detalle tras 30 días desde createdAt, no eliminación automática autorizada ahora.	Hasta depuración consultable como fotografía, marcada expired/stale cuando corresponda. Después, cabecera tombstone y respuesta de detalle 410 para sujeto autorizado.
C. Intento/rechazo sin adopción	Código seguro, clave/huella y resultado compacto originales durables; detalle diagnóstico normalizado depurable a 30 días si política lo aprueba.	Repetición conserva mismo código/resultado de negocio; no reutilizar clave ni devolver secretos.

Modelo de observación no bloqueante

RT: las filas de plan guardan IDs observados de Resource/raíz/revisión/contexto y sus valores mínimos en columnas tipadas, pero sin FK a esas entidades operativas. Sí tienen PK/UNIQUE y FK al plan y entre sus items/conflictos/evidencias. El plan guarda companyIdObserved/creatorIdObserved, sin FK que retenga por sí sola una compañía/usuario; se valida su existencia al crear/consultar/confirmar. El nombre histórico seguro es dato observado. No se finge que esos IDs sean referencias vivas garantizadas.

Así, eliminar legítimamente un registro no confirmado deja el plan obsoleto, no bloquea el CRUD ni destruye la fotografía. No se admiten observaciones escritas por el navegador como verdad: las captura el lector autorizado y se revalidan antes de commit. No usar JSON ni notas libres como snapshot ni SET NULL en referencias confirmadas para permitir borrados. La normalización almacena filas por raíz/campo tipado necesario, sin depender de una revisión que pueda desaparecer.

Al confirmar se crean relaciones vivas fuertes de procedencia mediante FK a C, Resources, raíces/revisiones y items seleccionados; plan y evidencia aprobados pasan a retención confirmada sin cambiar su contenido revisado. Las observaciones omitidas permanecen como hechos históricos sin retener raíces ajenas a la selección. Esta distinción sustituye la recomendación indiscriminada RESTRICT de P1 únicamente como propuesta nueva, sin modificar aquel documento.

Limpieza segura futura

• Conservar cabecera mínima de plan: id, C/creador observados, fechas/versiones/huellas, estado de payload full/purged y motivo de depuración. No reasignar ID. Un plan expirado nunca revive con la misma clave.
• Conservar comandos, clave/huella y resultado compacto, aunque se depure detalle de un rechazo. La respuesta de error normativa es código/requestId con referencia estable; sus detalles de plan se consultan aparte y pueden haber caducado. requestId de transporte no es parte del resultado inmutable.
• No purgar un plan vinculado a operación confirmada ni sus evidencias/items. Los comandos confirmados no apuntan a un payload desaparecido. FK del resultado/plan aprobado impide un borrado accidental.
• Para un plan no confirmado expirado, limpieza obtiene el mismo prefijo catálogo→compañía→comandos ordenados→plan antes de comprobar operaciones. Un comando pending no se borra: si no hay commit y el TTL expiró, registrar rechazo ADOPTION_PLAN_EXPIRED y auditoría en esa unidad, manteniendo su clave. Si hubo commit, conservar todo.
• Si la compañía ya no existe y no hay procedencia confirmada que la retenga, usar bloqueo de metadatos de comando/plan y comprobar la ausencia; no puede iniciarse adopción nueva en C inexistente. No fingir que se obtuvo un lock sobre una compañía eliminada.
• Depurar solo hijos efímeros autorizados del plan, en orden de FK, conservando tombstone/resultados/auditoría de la limpieza. No cascadas desde Resource ni purga que borre historia confirmada. Guardado de evidencia de limpieza antes de commit obligatorio.
• No hay proceso de limpieza implementado ni autorizado ahora. La retención inicial segura puede conservar detalle más tiempo si la capacidad de limpieza aún no existe; TTL de ejecución sigue aplicándose y nunca se recupera espacio borrando claves.

PA-E: aprobar separación de retenciones, protección de borrado solo por procedencia confirmada y criterios técnicos propuestos de 30 min/30 días, o fijar otra política explícita antes de su implementación. Purgas futuras de confirmados exigirían otro contrato que preserve garantías; no son parte del piloto.

11. Compensación

D08.2-F — RT/PA. Recomendación: no ofrecer compensación ejecutable en R2.7-C. Desde el primer commit deben existir los datos necesarios para reconstruirla, sin un botón, endpoint o tarea que la ejecute. La propuesta completa futura requiere contrato aprobado separado, no basta activar un flag reservado.

Caso	Evaluación de compensación futura y regla del piloto
Sucesora sin modificaciones	Podría admitir nuevo plan revisado que la cierre documentalmente y cree particular nueva. No ejecución automática ni compensación presente.
Revisiones nuevas, incluso valor cambiado y restaurado	Bloquear compensación técnica acotada; nueva intervención evaluada, sin sobrescribir.
Dependencias posteriores	Identificar/validar; incompatibles o desconocidas bloquean todo el conjunto.
Sucesora cerrada	No reabrir ni reutilizar; plan técnico de compensación propuesto no admisible.
Particular original inactivo	No crear nueva asociación a él; reactivación explícita por su flujo o mantener situación.
Global inactivo	Lectura/cierre de usado puede seguir permitido; no exigir reabrir asociaciones globales. Nueva particular valida sus propias policies.
Par particular ya abierto	Conflicto, no merge ni reutilización de UUID.
Licencia modificada	Evolución bloqueante; no devolver ni trasladar licencia automáticamente.
Versión/delivery modificados	Evolución bloqueante; no restaurar snapshot ciegamente.
Ya compensada	Devolver resultado original con misma clave; una nueva solicitud no compensa otra vez.
Compensación concurrente	Mutex de C y UNIQUE(originalOperationId) para una sola compensación completa, si se aprueba.
Parcial solicitada	Rechazar en contrato técnico futuro inicial; nueva decisión para soportarla.

Una futura compensación completa sería otra operación atómica, autorizada/idempotente, con causa distinta, cierre de sucesoras no evolucionadas y nuevas particulares. No reabre las originales ni cambia la adopción confirmada a «nunca ocurrió». Conserva historias y enlaza ambas operaciones. No backups como deshacer.

¿Permiten las operaciones actuales una corrección controlada?

CV: update permite cambiar notas/versión/licencia/delivery en estados abiertos según políticas; pending→never_configured permite cancelar una necesidad que realmente no llegó a configurarse; create permite otra particular si su par está libre. Son operaciones individuales, no una reversión transaccional de adopción. Cuando una sucesora está configured, retirarla exige una retirada real según su ciclo. No existe una operación pública que la cierre documentalmente para devolverla al particular sin falsear retirada; tampoco se puede reabrir una raíz superseded.

Por tanto, no se justifica el piloto prometiendo «si hay un error, se arregla manualmente con los endpoints actuales». Se recomienda aceptar un piloto sin compensación solo si el propietario acepta expresamente:

1. No hay reversión general inmediata de un destino elegido erróneamente, sobre todo en sucesoras configured.
2. Las correcciones ordinarias se limitan a hechos y transiciones realmente válidos, con su auditoría. Cancelar pendiente y crear otra es un proceso secuencial, no atomicidad inversa ni compensación implícita.
3. Un error de identidad que no pueda corregirse sin falsear hechos detiene nuevas adopciones afectadas y necesita nuevo contrato/intervención aprobada; nunca DML directo, delete de historia ni removed ficticio.
4. Trazabilidad, consulta y observabilidad están disponibles antes del primer piloto; el plan y confirmación muestran explícitamente que no existe deshacer.

Si la exigencia de producto es que toda adopción tenga corrección documental inversa disponible desde el inicio, esta condición no se satisface con código actual: bloquear R2.7-C hasta aprobar e implementar R2.7-D o una operación correctiva específica. Preparación/preflight pueden evaluarse por separado. No se toma esa aceptación en nombre del propietario.

flowchart TD
    O[Adopción confirmada y trazable] --> E{La corrección es una transición ordinaria real}
    E -->|Sí| C[Operación posterior autorizada y auditada]
    E -->|No| B[Sin deshacer disponible en el piloto]
    B --> N[Nuevo contrato y plan de intervención]
    N --> A{Compensación específica aprobada e implementada}
    A -->|No| S[Conservar datos y bloquear intervención insegura]
    A -->|Sí| V[Revalidar sucesoras y dependencias]
    V --> T[Nueva operación atómica, nuevas particulares]

PA-F: ¿se acepta el piloto con estos límites y sin compensación ejecutable, o se exige corrección inversa general previa? No responder equivale a mantener bloqueada la confirmación piloto, no a consentimiento.

12. Viabilidad de escritores

D08.2-G — RT/PA. Viable como transacción local única tras adaptaciones; no viable encadenando endpoints/save existentes sin ellas. Domain/Application no reciben Sequelize; Infrastructure posee Transaction y enlaza servicios propietarios mediante composición explícita.

Método actual / agregado	Restricción CV	Adaptación RT	Compatibilidad/riesgo	Prueba futura
SoftwareInstallation.create / ApplicationConfiguration.create	Generan UUID/revisión inicial, aceptan pending/configured.	Reutilizar para sucesora con valores revisados y fecha/actor de unidad.	Sin convertir rehydrate en create; target nuevo solo en raíz nueva.	UUID/primera revisión, no defaults operativos.
aggregate.update	Target fijo y ciclo de cinco estados.	Mantener CRUD; añadir closeForSuccession específico condicionado A.	Nuevo terminal solo command autorizado; no body state libre.	Transiciones, terminales, causa, target inmutable.
UseCases.save	Llama a repository.save sin Transaction externa.	Caso de uso de adopción coordina un puerto de unidad propio. Reutiliza policies/mappers, no llama varios save públicos.	No cambiar API general para colar un parámetro booleano opcional ambiguo.	Ambas familias, validación antes de efectos.
Repositories.save / persist privado	Abren transacción y upsert.	Factorizar las operaciones mínimas de lectura/persistencia ligadas a unidad; crear inserción estricta y actualización de predecesora específicas.	No exponer modelos/repo ajeno ni cambiar comportamiento general del upsert.	Fallo en cada item/tabla, affected rows e IDs.
Resources.applicationReferences e inventoryForTransaction	Admiten ligadura; sesión bloquea catálogo/C.	Reutilizar primero y ampliar proyección de revisión mínima si falta, sin DTO admin.	Batches acotados y propósito derivado en servidor.	Inactivo, propio/ajeno, desactivación en ambos órdenes.
Lectores de activo/perfil/persona	Inventarios disponibles; algunos sin lectura actual específica acotada.	Adaptadores propietarios de testigos/current reads bajo mismo mutex.	No importar ORM de Assets desde Application Companies.	Retirada/archivo concurrente, dependencias.
Identity.canManageGlobalResources	Política útil, sin Transaction externa ni acción adopción.	Nuevo contrato público por acción y lector ligado; reutilizar comprobaciones existentes.	Nuevos locks de identidad, sin inventar delegación.	authVersion/permiso cambian durante espera.
Auditoría común	Diseño, no implementación.	Unidad auditada común para plan, reserva, efectos y rechazo.	Dependencia bloqueante de toda escritura nueva; sin hooks aislados como única garantía.	Fallo de auditoría revierte negocio.
remove/delete	Borra revisiones y raíz.	Guard de uso por procedencia confirmada antes de cualquier delete; planes no confirmados no bloquean.	Reducción funcional explícita sometida I/E; FK final.	Delete protegido, no destrucción parcial.
onSuccess Query	Invalida tras respuesta confirmada.	Invalidaciones dirigidas §18 fuera del commit.	Fallo de cache no revierte ni duplica operación.	Timeout/respuesta perdida/refetch fallido.

El nuevo puerto de unidad es específico de adopción porque tiene un consumidor y atomicidad real; no exige repositorio base genérico ni framework de UoW/event sourcing. No hay hooks de adopción reutilizables ya comprobados. La auditoría no se puede relegar a una petición HTTP posterior.

Rollback: antes de escribir, rechazos pueden guardar únicamente metadatos/auditoría; tras cualquier efecto operativo, un fallo Result debe abortar la unidad en Infrastructure y convertirse fuera. Managed Sequelize v6 confirma si el callback resuelve normalmente: no retornar Result.fail post-DML esperando rollback. Un único adaptador debe hacer explícito ese contrato; se comprueba con inyección de fallo futura, sin implementarlo aquí.

sequenceDiagram
    participant U as Operador autorizado
    participant H as HTTP Companies
    participant T as Unidad Infrastructure
    participant I as Identity público ligado
    participant DB as MariaDB
    U->>H: Plan, huella, clave y aceptaciones
    H->>H: Validar sesión, DTO y alcance
    H->>DB: Consultar o reservar comando y auditar solicitud
    H->>T: Confirmar si no hay resultado final
    T->>DB: BEGIN y catálogo S, compañía X, comando y plan
    T->>I: Reautorizar dentro de Transaction
    I->>DB: Estado identidad S y actor S, validar vigencia
    T->>DB: Current reads y testigos operativos
    T->>T: Validar todas las seleccionadas
    alt Selección vigente y autorizada
        T->>DB: Cierres, revisiones e INSERT sucesoras
        T->>DB: Procedencia, resultado y auditoría
        T->>DB: COMMIT
        H-->>U: Resultado durable
    else Rechazo antes de efectos operativos
        T->>DB: Rechazo y auditoría, commit solo metadatos
        H-->>U: Conflicto sin sucesiones
    else Fallo después de una escritura
        T->>DB: ROLLBACK completo
        H-->>U: Error seguro, consultar misma clave
    end

13. Inserción estricta

D08.2-H — RT/PA. El upsert CV busca cualquier clave única: una colisión de currentKey puede actualizar licencia/versión/state/notes de otra raíz. Las policies/mutex actuales reducen ese riesgo en sus caminos; la sentencia por sí sola no acredita que creó una identidad nueva. No se declara un fallo observado en producción ni se modifica su comportamiento general.

Contrato recomendado: método interno explícito insertSuccessor ligado a la unidad de adopción, dentro de la persistencia Companies existente, no otro repositorio paralelo genérico. El comando de dominio valida sucesión; este escritor aplica inserción estricta y FK, no decide equivalencia comercial.

1. Crear candidato con UUID v7 nuevo y primera revisión nueva mediante create; no reutilizar UUID del plan, predecesora ni raíz destino abierta.
2. Revalidar pareja libre/propósito/contexto en la unidad. Persistir cierres aprobados con testigo y append de revisiones; no borrar filas ni alterar targets.
3. INSERT ordinario de raíz y revisión inicial, con Transaction explícita, sin ON DUPLICATE KEY UPDATE, REPLACE ni INSERT IGNORE. Comprobar fila/ID esperados y currentKey.
4. Colisión UUID o par no actualiza nada implícitamente. Abortar unidad completa y mapear por constraint conocido a error seguro; conflicto técnico no se convierte en raíz «encontrada y adoptada».
5. Insertar relaciones de procedencia, resultado, auditoría y estado final de comando antes del único commit. Solo reintento con resultado committed recupera la identidad anterior del mismo comando.

CREATE conserva semántica actual; INSERT estricto no hace compatible por sí solo el terminal nuevo. Lectores/rehidratación/negociación A/D deben desplegarse primero. No se emite SQL ejecutable ni se crea el método en esta fase.

14. Modelo relacional

D08.2-I — RT/PA. Se conserva la separación P1 de operación, items tipados, auditoría y comando; se corrigen referencias de observaciones según §10. Todas las entidades de negocio/internas tienen UniqueID v7; fechas UTC, columnas tipadas y tablas de filas, sin blobs JSON. Namespaces de PK son reales; un nombre conceptual no afirma tabla instalada.

Grupo propuesto	Claves/columnas y garantías
Plan header	id PK; C/creator/source/target IDs observados y valores comerciales observados en columnas para payload completo, createdAt/expiresAt, schema/policyVersion, creationRequestFingerprint/planFingerprint BINARY(32), evaluación y payloadState. IDs observados sin FK operativa.
Plan software/application observations	id PK, planId FK, role source/destination, observedRootId/revisionId/posición, estado/valores de snapshot en columnas, selección/propuesta/motivos; UNIQUE(planId,role,observedRootId) por tabla. No FK operativa que retenga raíces no confirmadas.
Plan evidence/dependencies/conflicts	id PK, planId FK; referencias internas tipadas a item cuando proceda, códigos, motivo comercial, referencias documentales seguras y testigos normalizados. CHECK coherencia de columnas/tipos; sin FK polimórfica fingida.
Commands	commandId PK solicitado v7, C/actor IDs observados, action, key UUID, planId FK header, requestFingerprint, pending/committed/rejected, resultCode/resultOperationId FK nullable. UNIQUE(C,actorId,action,key); no FK a entidad operativa por mera reserva.
Confirmed operations	id PK, commandId FK UNIQUE, planId FK UNIQUE; companyId/sourceResourceId/targetResourceId/actorId FK reales, nombres seguros, authorizedAt/committedAt, contrato/huella aprobada, motivo/referencias aprobados y resultado; originalOperationId FK UNIQUE nullable reservado para compensación futura.
Confirmed software succession	id PK; operationId FK, planItemId FK UNIQUE; predecessorId/successorId FK a software_installations, cierre y primera revisión FK; companyId; UNIQUE(predecessorId) y UNIQUE(successorId), IDs distintos.
Confirmed application succession	Igual contra application_configurations y sus revisiones. No entityId genérico como sustituto de FK.
Audit linkage	FK/clave única de operación a auditoría común y causalidad de efectos. Actor/nombres históricos sin cascadas destructivas, según su diseño. Intentos separados de efectos.

Integridad por responsable

Garantía	MariaDB directa, si migrada	Transacción / dominio
Existencia de raíz/revisión confirmada	FK RESTRICT.	Confirmar pertenencia/tipo/actividad antes de insert.
Misma C de operación/raíz/item	FK compuesta con columnas C y claves candidatas UNIQUE(id,companyId), nuevas donde falten.	Validar Resources global/null frente a fuente local/C y contexto.
Revisión pertenece a raíz	FK compuesta contra (id,configurationId) o (id,resourceId), con índices nuevos explícitos.	Mapper verifica secuencia y último snapshot.
Pareja abierta	currentKey UNIQUE nullable vigente.	closed incluye terminal propuesto; clave esperada y mutex; NULL no demuestra ámbito.
Un resultado por plan/comando	UNIQUE y FK.	Relectura bajo locks e idempotencia; no éxito parcial.
Una sucesión por predecesora/sucesora en cada rol	UNIQUE separado por tabla.	Cierre legítimo y ausencia de ciclos; futura compensación puede usar sucesora como nueva predecesora.
Campos coherentes	CHECK local de estado/resultOperationId, IDs distintos y referencias internas.	No CHECK con subconsulta a otras tablas para owner/permiso/equivalencia.
Equivalencia y datos operativos	Ninguna FK la acredita.	Evidencia humana revisada, policies, licencia/versión/delivery explícitos.

Columna/tipo/collation de FK compatible con existentes; no convertir todo a otro formato UUID por preferencia. Índices RT: operaciones (companyId,committedAt,id), (sourceResourceId,id)/(targetResourceId,id); comandos por clave única y (C,state,id); hijos por plan/operación, revisiones e IDs de navegación. EXPLAIN y restricciones efectivas en 11.8 son pruebas futuras. No afirmar unicidad parcial WHERE ni usar componente NULL de FK global para fingir validación de compañía.

Borrado: operaciones/linajes confirmados bloquean delete de raíces, revisiones y Resource referidos, también tras cierre de gates; es consecuencia funcional nueva PA-I/E. No cascadas desde esas entidades ni SET NULL para borrar procedencia. Plan purgado conserva header/claves; no rompe resultados confirmados. La auditoría común conserva identidades históricas sin depender exclusivamente de un usuario vivo, según su contrato; el diseño físico debe resolver la referencia de actor confirmado coherentemente antes de permitir cualquier futura eliminación de usuarios.

erDiagram
    PLAN_HEADER ||--o{ PLAN_OBSERVATION : conserva_hechos_sin_FK_operativa
    PLAN_HEADER ||--o{ PLAN_EVIDENCE : fundamenta
    PLAN_HEADER ||--o{ COMMAND : recibe
    COMMAND ||--o| CONFIRMED_OPERATION : confirma
    PLAN_HEADER ||--o| CONFIRMED_OPERATION : plan_aprobado
    COMPANY ||--o{ CONFIRMED_OPERATION : delimita
    RESOURCE ||--o{ CONFIRMED_OPERATION : fuente_particular
    RESOURCE ||--o{ CONFIRMED_OPERATION : destino_global
    CONFIRMED_OPERATION ||--o{ SOFTWARE_LINEAGE : produce
    CONFIRMED_OPERATION ||--o{ PROFILE_LINEAGE : produce
    SOFTWARE_ROOT ||--o| SOFTWARE_LINEAGE : predecesora
    SOFTWARE_ROOT ||--o| SOFTWARE_LINEAGE : sucesora
    PROFILE_ROOT ||--o| PROFILE_LINEAGE : predecesora
    PROFILE_ROOT ||--o| PROFILE_LINEAGE : sucesora
    CONFIRMED_OPERATION ||--|| AUDIT_OPERATION : acredita

El dibujo no convierte PLAN_OBSERVATION en una tabla genérica obligatoria: son dos colecciones tipadas. Su ausencia de FK operativa es deliberada; las líneas confirmadas sí las tienen, incluidas revisiones en el diseño tabular. Una operación exige al menos un item entre ambas familias, comprobación transaccional.

15. Auditoría

CV: auditoría centralizada es diseño acordado y aún no infraestructura compartida disponible. RT: desarrollar su capacidad común necesaria, ligada a la unidad; no afirmar completada toda la cobertura del proyecto por cubrir adopción.

Evidencia durable de confirmación	Registro normalizado requerido
Operación/actor/contexto	UUID, preparador y confirmador, nombres históricos seguros, C, source/target UUID, authorizedAt/committedAt, requestId y resultado.
Decisión comercial	Plan aprobado completo, versión/huella, aceptación, motivo comercial y referencias seguras, decisiones explícitas de licencia/versión/delivery. No nombre como prueba.
Cambios	Items afectados y sucesores, revisiones de cierre/iniciales, causa, valores tipados antes/después y relaciones old/new.
Conflictos resueltos	Guardar solo resoluciones realmente revisadas. Si se sustituye un plan bloqueado, nuevo plan puede enlazar previousPlanId histórico y resoluciones tipadas con código/item/decisión; no declarar resuelto un conflicto que sigue bloqueando. Un cambio fuera del plan se acredita mediante nuevo testigo, no copia de un éxito inventado.
Repetición/fallo	Command/key/huella y resultado original; intentos de transporte separados, código seguro y referencia a operación si existe. Sin eventos duplicados de efecto.

Historial Resource registra evolución del producto; no se modifica por adopción. Historial de raíces registra sus revisiones; procedencia registra relación causal. Auditoría común registra la operación transversal. Logs técnicos diagnostican con requestId; telemetría mide latencias/esperas/conflictos. No son intercambiables.

Negocio y auditoría de éxito en la misma Transaction: falla auditoría→rollback de todo. Reserva/plan también son metadatos escritos con auditoría, no «lecturas sin consecuencias». Rechazo antes de efectos puede confirmar solo metadatos. Fallo tras rollback se registra en otra unidad como intento sin efectos. BD caída impide garantizar intento durable, pero nunca se confirma negocio sin su auditoría.

Sin contraseñas, cookies, tokens, CSRF, secretos de licencia, cuerpo HTTP completo ni notas administrativas globales. Evidencia comercial y motivo libres son acotados, revisables y sin credenciales. No hooks Sequelize como única garantía: SQL/bulk puede eludirlos; el contrato de persistencia debe exigir registro.

16. Contratos HTTP

RT/PA, definitivos como propuesta v1, no endpoints existentes. Prefijo Companies /api/resource-adoptions/:companyId. Coincidencias sigue en Resources y nunca se convierte en adopción. JSON solo transporte; implementación futura con Zod v4 estricto y tipos inferidos.

DTO y validación

DTO conceptual	Entrada/salida normativa propuesta
CreatePlan	creationId v7; sourceResourceId/targetResourceId; softwareItems [{installationId, proposedState pending/configured, version nullable≤100, licenseResourceId nullable, notes nullable≤4.000, versionDecision/licenseDecision preserve/replace/clear}]; applicationItems [{configurationId, proposedState, delivery installed/web, version nullable, notes nullable, versionDecision}]; evidence [{id v7,kind,referenceText≤500,explanation≤2.000}], 1..20. IDs únicos y selección total 0..100. Selección vacía permite un plan blocked/no-effect de exploración; ready y confirmación exigen al menos una seleccionada ejecutable.
PlanSummary	ID/C/creator observado, source/target mínimos comerciales, createdAt/expiresAt, algoritmo/schema/policyVersion, fingerprint, ready/blocked, coverage y conteos seleccionadas/omitidas/cerradas/bloqueadas; validity derivada, payloadState y advertencia sin deshacer.
PlanItem	Unión software/profile; role source/destination, root/revision/posición observadas, valores antes/propuestos, eligibility/selected/disposition/exclusionReason, conflictos públicos y efecto exacto. Destino observado es keep y no seleccionable.
ConfirmPlan	commandId v7, planId, fingerprint hex64, acceptReviewedPlan:true, acceptNoExecutableCompensation:true. Ambas son aceptación explícita de esta intención, no permiso ni casilla preseleccionada.
CommandStatus	pending o committed con operationId/resultURL o rejected con código original. GET no ejecuta pendientes.
OperationSummary / Result	ID/comando/plan/C, fecha/actor autorizado, source/target observados, contrato/huella y conteos, enlaces a items/auditoría. Result es inmutable al commit; estado de compensación actual solo en summary separado.
OperationItem	Tipo, IDs anteriores/sucesores, revisiones de cierre/iniciales y valores al commit, motivo/causa autorizados; no historial global administrativo.

No aceptar actorId/owner/scope/capabilities/force ni destination por item distinto del plan. Nullable explícito, web implica version=null. Las decisiones de conservar valores se comprueban, sin copia automática. Evidencia exige operator-verification y product-reference o vendor-document identificable; sin información suficiente no ready. No se valida certeza comercial por Zod.

creationId es la identidad solicitada del plan (planId); mismo actor/C/entrada devuelve ese mismo plan, no uno regenerado. Tras depurar su payload devuelve cabecera tombstone del mismo ID, no otra fotografía. PlanSummary se define como unión full/tombstone con campos coherentes: tombstone conserva IDs/fechas/versiones/huellas y no exige nombres/valores ya depurados. El resultado confirmado nunca usa esa variante depurada.

Headers: origen/CSRF en POST, Idempotency-Key UUID v7 en confirmación, X-Metis-Operational-Contract: 2 propuesto en estas rutas y lectores B1. X-Metis-Resources-Contract: 2 conserva su significado actual donde corresponda. Params UUID, query vacía salvo páginas/filtros declarados, entradas desconocidas rechazadas; pageSize 1..100 default20, cursor≤2048 ligado a sujeto/C/colección/filtros.

Endpoints propuestos

Método/ruta tras prefijo	Autorización y datos	Respuesta/errores	Versionado, idempotencia y concurrencia
POST /plans	plan + C + CSRF; CreatePlan.	201 nuevo o 200 repetido; blocked puede ser plan válido 201. 400/401/403/404/409.	CreationId ligado a entrada/actor/C; devuelve foto original, no nueva observación bajo mismo ID. Captura y persistencia coherentes.
GET /plans/:planId	Creador o admin autorizado; query vacía.	200 summary; 401/403/404. Expiración no borra hechos.	Versión operativa validada; tombstone incluye payloadState sin reejecución.
GET /plans/:planId/items y /conflicts	Igual; type software/profile si procede, cursor/pageSize.	200 page, 400/401/403/404; 410 ADOPTION_PLAN_PAYLOAD_PURGED si detalles depurados.	Foto persistida orden UUID, no paginar inventario vivo.
POST /confirm	confirm para ejecutar o history para repetición finalizada + C + CSRF; ConfirmPlan y clave.	200 resultado inicial o repetido; 400/401/403/404/409; 503 en curso/retry, 500 fallo interno.	Reserva durable, locks, autorización interior y resultado original; Location al resultado.
GET /commands/:commandId	history + C; query vacía.	200 estado; 401/403/404.	private,no-store; no reejecuta ni condiciona resultado previo a gate/TTL nuevos.
GET /operations	history + C; sourceId/targetId/kind y cursor/pageSize validados.	200 page; 400/401/403/404.	Orden committedAt/id, cursor ligado a filtros/C/sujeto.
GET /operations/:operationId	history + C; query vacía.	200 summary con referencia al resultado y estado actual de compensación; 401/403/404.	No alterar hechos originales por evolución posterior.
GET /operations/:operationId/result	history + C; query vacía.	200 resultado original; 401/403/404.	Inmutable, incluso si sucesoras ya cambiaron.
GET /operations/:operationId/items	history + C; type/cursor/pageSize.	200 líneas; 400/401/403/404.	Relaciones/revisiones confirmadas, estables; no todas las revisiones por defecto.
Compensación futura	Plan/confirmación separados con permisos específicos e originalOperationId.	No rutas registradas en el primer piloto. Ausencia de endpoint no se disfraza como capacidad operativa con gate.	Antes de R2.7-D, contrato específico debe completar DTO, efectos, errores y versión. No autoriza implementación por reservar nombres.

Errores explícitos

HTTP / código propuesto	Situación y efecto
400 INVALID_REQUEST	UUID/header/query/DTO/nullable/arrays inválidos o claves desconocidas.
401 UNAUTHENTICATED	Sesión ausente/invalidada, también en revalidación interior.
403 FORBIDDEN	Capacidad insuficiente como conjunto, antes de proyección protegida.
404 ADOPTION_REFERENCE_NOT_FOUND / ADOPTION_PLAN_NOT_FOUND	Fuente ajena/inexistente/tipo inválido o plan inaccesible, sin revelar B.
409 ADOPTION_NO_EFFECT	Selección vacía o sin raíces ejecutables al intentar confirmar; no produce adopción ficticia.
409 ADOPTION_TARGET_INELIGIBLE / ADOPTION_TARGET_UNAVAILABLE	Destino autorizado pero tipo/actividad/gate por propósito no admisible.
409 ADOPTION_PLAN_STALE / EXPIRED / INCOMPLETE	Foto no vigente, TTL/cobertura; nuevo plan, cero efectos.
409 ADOPTION_ASSOCIATION_CHANGED	Seleccionada cerrada/revisada o dependencia alterada; no continuar con las demás.
409 ADOPTION_SOFTWARE_PAIR_CONFLICT / ADOPTION_PROFILE_PAIR_CONFLICT	Colisión de par abierto, sin datos internos del índice ni actualización implícita.
409 ADOPTION_IDEMPOTENCY_CONFLICT	Clave/comando con contenido distinto en mismo scope; no resultado ajeno.
409 ADOPTION_PLAN_ALREADY_CONFIRMED	Otra clave para mismo plan; enlace al resultado solo autorizado.
503 ADOPTION_IN_PROGRESS / ADOPTION_RETRY_REQUIRED	Espera de locks/procesamiento excedida o fallo transitorio; Retry-After acotado, misma clave. pending no prueba que un proceso siga vivo.
409 ADOPTION_FEATURE_DISABLED / ADOPTION_NOT_READY	Gate cerrado o prerrequisito no desplegado; no afecta lectura de commit previo.
409 OPERATIONAL_CLIENT_UPGRADE_REQUIRED	Cliente no soporta terminal/procedencia; nunca omitir filas ni traducir superseded a removed.
500 INTERNAL_ERROR	Infraestructura/corrupción inesperada, requestId y diagnóstico interno; sin SQL/stack al cliente.

Las abreviaturas EXPIRED/INCOMPLETE de la tabla corresponden a ADOPTION_PLAN_EXPIRED/ADOPTION_PLAN_INCOMPLETE. Todos llevan {code,requestId}; conflictos se consultan en proyección autorizada. Clasificar errores explícitamente, no sufijo genérico que convierta FORBIDDEN en 409.

Idempotencia refinada

Conservar P1: planId, commandId y operationId distintos; UNIQUE(C,actorId,action,key), requestFingerprint explícito e identidad global commandId. Reserva INSERT estricto + auditoría en unidad breve de metadatos, no reserva de par operativo. Dos peticiones iguales esperan compañía/comando; segunda relee el resultado. Mismo plan/dos claves: UNIQUE(planId) y conflicto; dos planes/una raíz: revisión/cierre y UNIQUE(predecessorId) impiden doble sucesión.

Rechazo determinista antes de DML operativo guarda rejected/código/auditoría. Fallo posterior hace rollback y reserva sigue pending, con intento técnico aparte. Caída al commit: consultar antes de suponer rollback. Committed/rejected se recuperan antes de aplicar vigencia/gate de nueva ejecución, manteniendo permiso de lectura vigente. Resultado deriva de filas al commit, nunca roots actuales. La autorización de una sesión nueva válida del mismo actor puede consultar resultado anterior; no se exige conservar una sesión revocada para recuperar su clave.

stateDiagram-v2
    [*] --> pending: reserva y auditoría de solicitud
    pending --> committed: efectos, procedencia y auditoría atómicos
    pending --> rejected: rechazo previo a efectos operativos
    pending --> pending: rollback o caída técnica
    committed --> committed: repetición devuelve mismo resultado
    rejected --> rejected: repetición devuelve mismo código

17. Flags

D08.2-J — RT/PA. CV: flags actuales siguen default false, sin cambios. RT: RESOURCE_ADOPTION_PREFLIGHT_ENABLED y RESOURCE_ADOPTION_CONFIRM_ENABLED, independientes y default false en implementación futura. El primero solo permite metadatos, el segundo ejecución nueva con todas sus condiciones. No conceden permisos.

Superficie	Gate y condiciones recomendadas
Coincidencias R2.6	Contrato/gate catálogo vigente, sin nuevas escrituras.
Crear plan	Gate preflight + permiso plan, C válida; catálogo/propósitos pueden figurar bloqueados sin producir un plan ready.
Confirmar nueva	Gate confirm + catálogo + asociación global por cada familia seleccionada + autorización. No requiere habilitar picker mixto como permiso adicional.
Consultar plan/operación/resultado existente	Permiso vigente y backend compatible; no apagar lectura al cerrar escritura. Retención puede marcar payload purgado.
Compensación	No implementada/registrada en piloto; futuros gates separados requieren otro contrato aprobado.

Activación por fases §19. Desactivación detiene comandos nuevos, no borra ni revierte commit. Validar flags al inicio de unidad no promete cancelación retroactiva en otra instancia: drenar procesos si se exige parada inmediata. Resultado/idempotencia siguen disponibles. Monitorizar pending antiguos, rechazos, stale, latencia/consultas, locks, UNIQUE/auditoría y errores de clientes sin datos sensibles.

Rollback de despliegue después de primera revisión superseded exige mantener lectores capaces; compensar no borra esa revisión. Cerrar gates y corregir hacia delante, o volver solo a versión preparada que siga leyendo datos nuevos. DDL futuro ensayado aparte, sin alter rollback ficticio ni desactivar FK/CHECK. No restaurar backup como deshacer una adopción.

18. Matriz de consumidores

Compatibilidad se evalúa por validaciones reales, no por aceptar string UUID. RT/PA, salvo columna de contrato CV. Gates P=preflight, C=confirmación; ninguno sustituye lector compatible o permiso.

Consumidor	Contrato actual CV	Cambio RT	Compatibilidad / gate	Riesgo y validación futura
Resources	scope/owner/template fijos; local y global separados	Puerto mínimo de revisión/testigos si falta; ninguna mutación Resource por adopción	Aditivo; P/C consumen servicios	Validar stock application global/campos/sin integración, local propio, no DTO admin.
Companies	Raíces por compañía, repositorios independientes	Unidad específica, planes/comandos/procedencia/auditoría	Nueva superficie P/C; no atomicidad existente	Rollback de ambos tipos y autorización interior.
Assets	Activos/puestos locales, inventario público ligado	Testigos actuales/no retirado; no mover relaciones	Lectura aditiva; C antes de escribir	Retirada/cambio de equipo concurrentes.
Identity	Sesión, authVersion y admin inicial	Política por acción y autorización ligada a unidad	Extensión con orden de locks revisado; P/C	No delegación/ACL imaginada; pruebas de revocación en espera.
WorkProfile	Target local fijo, actividad/persona/activo	No mutación de perfil; lectura de sucesión y restricciones de borrado por dependencias	Datos identidad compatibles; proyección nueva negociada	Perfil archivado/persona inactiva bloquean nueva.
Workstation	Equipo/perfiles y configuraciones por sus raíces	Mostrar sucesora abierta y anterior histórica; nuevo terminal en filtros/counters	Incompatible si conserva enum viejo; preparar antes de C	No duplicar pendientes/abiertas ni crear software desde perfil.
SoftwareInstallation	Cinco estados, asset/resource fijos, licencia local	B1 específico, closed, causa, INSERT estricto, linaje, delete protegido	Evolución contractual, gate C para ejecutar B1	UUID/revisiones/par único y licencia nunca global.
ApplicationConfiguration	Cinco estados, profile/resource fijos, delivery/versión	B1 específico y mismas garantías; no licencia nueva	Evolución contractual, C	Web sin versión, perfil/persona/activo y no compartir estado con otros perfiles.
Selectores	Propósito y pertenencia en servidor; UUID/origen/proveedor	No alias/ocultación/selección automática por adopción	Contrato conservado; gates consumidores vigentes	Local sigue disponible, homónimos independientes y OS solo Software local.
Proyección de uso R2.6	Raíces C incluidas cerradas, no recuento de revisiones	Representar superseded/historia sin contarlo como abierta ni confundir total de raíces con instalaciones vigentes	Nuevo estado exige lector preparado; C	Recuento puede crecer por nuevas raíces; no presentar incremento como instalaciones físicas nuevas.
Historiales	Revisión target fijo, actor/fecha	Anterior/sucesora enlazadas a operación; mínima procedencia ordinaria, detalle de auditoría autorizado	DTO nuevos requieren negociación	No fusionar arrays ni mostrar nombres/valores actuales como históricos.
APIs públicas	Zod estricto, Resources-Contract:2	DTO/routes nuevos y Operational-Contract:2 donde hay B1	Incompatible sin evolución explícita; Vary/409 seguro	No lista parcial ni simplificar nuevo estado como removed.
Query keys	Software/Profile por C; admin/public separados	Planes por sujeto/C/ID; operaciones/history por sujeto/C/ID	Aditivo después de commit	Invalidar solo afectadas, eliminar sensibles al logout/403.
Entorno/procesos/dashboard	Proyecciones por referencias operativas/contexto	Revisar discriminaciones, estados/counters y referencias a raíces antiguas	No asumir compatibilidad por UUID	No reescribir FK dependientes; desconocida incompatible bloquea C.
Consumers solo locales	Access, SMB, directorio, soporte, remoto, certificados, buzones/carpetas con validadores propios	Sin ampliación a global ni sucesión de sus relaciones	Contratos conservados; no gate C para abrirlos	Pruebas negativas de scope/owner/propósito, UUID locales intactos.
Borrado	Delete puede borrar raíz/revisiones	Bloquear solo si hay procedencia confirmada, no mera observación de plan	Cambio funcional PA-E/I, permanece aun C off	Mensaje seguro ADOPTION_HISTORY_IN_USE antes de borrar hijos.

La biblioteca de estados compartida con Access no recibe superseded; se separan contratos de los dos agregados. Revisar sus lectores de snapshots además de componentes: un backend antiguo puede fallar al rehidratar antes de generar respuesta.

Query tras commit: invalidar softwareKeys.company(C) si Software, applicationKeys.company(C) si Profile, planes de fuente/C y listas/detalle de operaciones autorizadas. Uso/entorno que comparten esas queries se actualizan por ellas. Para derivadas independientes de puesto/dashboard/procesos, inventariar y añadir sus claves precisas; no invalidar toda la caché ni asumir que una relación hace refetch por sí sola. Resources/actividad no cambian: coincidencias y catálogo global no necesitan vaciado indiscriminado. Fallo de cache muestra actualización pendiente con resultado confirmado; reintentar misma clave nunca crea más sucesoras.

No se diseña pantalla detallada. UI futura: identificación de origen/destino, explicación comercial, selección explícita/omitidas, conflictos visibles, efecto de cierre, ausencia de deshacer, aceptación final y resultado consultable. Respetar DESIGN, diálogos independientes, accesibilidad/i18n y estructura por entidad/operación; MCP se ejecutará entonces, no se declara ahora.

19. Fases futuras

Propuesta de arquitectura de implementación, no autorización de ejecución ni estimación temporal:

Fase	Entrada obligatoria	Alcance	Criterio de salida antes de siguiente fase
R2.7-A — Preparación técnica	Ratificación y nueva instrucción con alcance; diseño relacional/A/C/D/E/G/H/I/J aceptado	Migraciones futuras ensayadas, auditoría común mínima, escritores ligados, INSERT estricto, Identity público, lectores/contratos compatibles y flags cerrados	Constraints efectivas, atomicidad y locks probados; toda escritura nueva auditable, sin introducir adopciones todavía. No declarar implementada toda auditoría central.
R2.7-B — Preflight	A completada y política de planes/retención aprobada	API/DTO de plan, observaciones normalizadas no bloqueantes, conflictos/huella/caducidad, preview y pruebas	Cobertura íntegra, sin truncated-ready ni permisos excesivos; limpieza/tombstone especificados y prueba de no bloqueo de delete por plan. Sin cierres/sucesoras.
R2.7-C — Confirmación piloto	A/B correctas, nueva autorización expresa de piloto y PA-F aceptada; gates/deuda previa tratados	Confirmación acotada en una C, selección atómica, comando idempotente, sucesoras, procedencia/auditoría y consulta	Fallos/races/recovery/regresiones correctos, lectores activos compatibles, monitores/operación preparados y límites de reversibilidad visibles.
R2.7-D — Compensación	Contrato específico ratificado, necesidad funcional y nueva instrucción; no se deduce de C	Plan/confirmación inversos autorizados con política de evolución, claves y pruebas propias	Sin sobrescritura de evolución, sin partial success ni borrado histórico; gate/activación propios.

Pueden ejecutarse ensayos futuros solo en metis_desk_test, por procedimientos desechables. MariaDB 11.8, Sequelize v6; DDL explícito con CHECK/FK activos y compatibilidad de tipos. Versiones de lectores antes de datos nuevos. Piloto no implica activación general: expansión necesita evaluación y autorización posterior.

Parada: cerrar C impide ejecuciones nuevas, conservar resultados y recursos; drenar para detener en curso. Monitorizar rechazos, revisión de producto, espera de locks, fallos UNIQUE/INSERT/auditoría, latencia y pending viejos. Rollback de despliegue no borra historia ni permite un backend incompatible. No se fijan fechas ni esfuerzo sin evidencia.

20. Matriz de pruebas

Futura, no ejecutada. U=unitaria/dominio/DTO/canonicalización; M=MariaDB real; H=HTTP real/sesión/CSRF; P=Playwright MCP. Unitarias pequeñas. Integración/UI con 15 compañías y principal ≥50 personas/activos/recursos/perfiles/puestos, volumen adicional para historia, 100 seleccionadas y 10.000 observadas; límites y excesos medidos, no rendimiento presumido. Barreras observables, sin sleeps arbitrarios.

ID	Cobertura	Resultado esperado	Capas / fase
V01	pending/configured/retirada/terminales y causa	B1 solo vía comando autorizado; retirada real no falsificada; target y revisiones previas fijos	U,M,H / A,C
V02	UUID particular/global/homónimos/ediciones	Sin merge/owner change; sucesora/revisión/items UUID nuevos; evidencia insuficiente bloquea	U,M,H,P / B,C
V03	Parcial: 3 Software +2 Profile +4 cerradas, seleccionar 2+1	Tres o ninguna; una+una abiertas intactas y cuatro históricas intactas	U,M,H,P / C
V04	Sin asociaciones/selección vacía/solo un tipo/ambos	Plan no-effect no confirma; mínimo una para operación; ambas familias mismo commit	U,H,P / B,C
V05	Omitida bloqueada/conflicto global/nueva fuente	Omitida no bloquea por sí; bloqueo seleccionado/global sí; nueva asociación exige nuevo plan	U,M,H,P / B,C
V06	Nueva revisión, cambio revertido, dependencia y root closed	Stale sin sobrescribir; no tomar timestamp como único CAS	U,M,H / C
V07	Canonicalización orden/null/ausente/UTF-8/visual/revisiones	Huellas estables; labels visuales no participan, datos semánticos sí	U / A,B
V08	TTL/policy/contrato/gates/C cambian	Rechazos definidos, nuevo plan cuando aplica; commit previo recuperable	U,M,H,P / B,C
V09	Licencia B/inactiva/caducada/medianoche/cobertura no acreditada	Validación local y evidencia, ningún traslado automático	U,M,H / C
V10	delivery web con versión, versión de otra edición, flags por propósito	Rechazo/blocked y sin efectos; no OS global/Profile OS	U,M,H,P / B,C
V11	Dos claves mismo plan/dos planes misma raíz/dos iguales	Una operación/linaje, resultado original o conflicto; no auditoría duplicada de efecto	M,H / C
V12	Idempotency body/actor distinto; sesión nueva válida y revocada	Scope/fingerprint y autorización; mismo actor válido recupera commit, revocada no	U,M,H / C
V13	Timeout/crash antes/después de commit/restart	Pending retomable o resultado original, sin otra clave ni commit incierto supuesto rollback	M,H,P / C
V14	INSERT colisiona UUID/par, segundo item falla	Ninguna raíz ajena actualizada; rollback integral y error seguro	M,H / A,C
V15	Fallos antes de cierre, tras cierre, raíz/revisión/procedencia/auditoría	Todas las tablas operativas iguales al antes; reserva/intent se distinguen de efecto	M,H / C
V16	Result.fail después de DML administrado	Rollback real por adaptador; no commit accidental	M / A,C
V17	Guard aceptó, espera compañía y authVersion se revoca	Segunda autorización interior rechaza si invalidación primero; orden inverso serial documentado	M,H / A,C
V18	Desactivación global/retirada asset/archivo perfil concurrentes	Relecturas actuales y orden de serialización, sin altas inválidas	M,H / C
V19	Sin sesión/plan ordinario/confirm ordinario/leer plan ajeno	Política específica, 401/403/404 seguros; admin no mezcla B en A	H,P / B,C
V20	Proyecciones y headers legacy/nuevos	Sin secrets/notes admin/uso B; upgrade en vez de filas omitidas; Access rechaza estado ajeno	U,H,P / A,C
V21	Plan no confirmado + delete válido de observada	Delete no bloqueado por plan; plan stale y snapshot conservado	M,H / B
V22	Procedencia confirmada + delete de raíces/revisiones/Resource	Error de negocio y RESTRICT, sin borrar hijos primero	M,H / C
V23	Limpieza expirada versus confirmación y comando pending	Mutex/check operativo; no purgar commit; tombstone/clave/rechazo original preservados	M,H / B,C
V24	Plan depurado/operación antigua/rechazo repetido	GET autorizado muestra tombstone/410 donde corresponde; resultado original no se rompe	M,H,P / B,C
V25	Falla auditoría de plan/reserva/limpieza/éxito	La escritura de esa unidad no confirma; sin éxito huérfano	M,H / A–C
V26	Error de respuesta/cache después de commit	Éxito durable, refetch dirigido/reintento mismo comando, no rollback ficticio	H,P / C
V27	Nuevo terminal en puesto/perfil/uso/procesos/counters	Cerrada no cuenta abierta; total de raíces no se presenta como instalaciones físicas	U,H,P / A,C
V28	Plan claro, selección/omitidas, no deshacer, conflicto y recuperación	Aceptaciones explícitas sin preselección, foco/Tab/Shift+Tab/Escape y resultado enlazable según permiso	H,P / B,C
V29	0/1/límite/exceso, páginas y fuente parcial, textos largos	No truncated-ready, validaciones de cobertura y responsive	U,M,H,P / B,C
V30	Compensación: sin cambios, revisión nueva, dependencia, cerrada	Casos previstos §11; no ejecutables en piloto, sin ruta anunciada falsa	U,H / C; M,H,P / D futura
V31	Compensación: local/global inactivos, par ocupado, versión/licencia nueva, repetida/concurrente/parcial	Nuevo contrato debe bloquear incompatibles y preservar historia; una sola compensación completa	U,M,H,P / D futura
V32	Regresiones R2.2–R2.6, Identity/Assets/Resources/Companies, locales, licencias, SMB/Access/remoto e historia	UUID/refs/gates off conservados, no globales nuevos en consumers no autorizados	U,M,H,P / A–C
V33	Multinstancia, deadlock/timeout/carga/limpieza	Orden consistente, retry acotado de unidad completa, métricas reales sin SLA inventado	M,H / A–C

P futura: seis anchuras 1600/1440/1280/1024/768/390, nombres extensos, estados carga/error/vacío, selección y conservación de contexto, accesibilidad/teclado/foco y capturas abiertas/inspeccionadas conforme procedimiento. No se instala auditor ni se ejecuta navegador para esta entrega documental.

21. Registro de decisiones

Cada fila es aprobable/rechazable por separado. Estado de todas: pendiente de aprobación. «Recomendada» en la columna técnica no significa «aprobada». Evidencias E remiten a §4; las preguntas y condiciones se desarrollan en los apartados señalados.

ID	Cuestión	Alternativas	Recomendación	Evidencia	Consecuencia	Riesgo	Dependencias	Aprobación requerida	Estado
D08.2-A	Cierre	Transición real existente; causa lateral; comando; terminal nuevo	Comando específico + superseded solo Software/Profile, pending/configured; no retirada ficticia (§6)	E02–E04,E11, DR-D08	Nuevas revisiones y closed; historia preservada	Incompatibilidad de lectores	Schemas específicos, mappers/lectores y negociación	Propietario: semántica/alcance; arquitectura: evolución explícita	Pendiente de aprobación
D08.2-B	Parcialidad	Total obligatoria; parcial no atómica; parcial atómica	Parcial permitida, todas las seleccionadas o ninguna (§7)	E05–E07 y P1	Omitidas siguen locales; nueva asociación fuente invalida	Lecturas parciales/plan frecuente stale	Cobertura completa, mutex y huella	Propietario: aceptar parcialidad y regla de cambio	Pendiente de aprobación
D08.2-C	Permisos	Guard global implícito; admin-only todo; preparación ordinaria y confirm específica	Preparar/leer propio ordinario, confirm/history admin inicial, compensación aparte (§8)	E08 y DR-D03/D04	Nueva política pública explícita, sin RBAC/grants	Escalada, sesión invalidada en espera	Lector Identity ligado y nuevo grafo de locks	Propietario/seguridad: sujetos, sin doble firma ni delegación	Pendiente de aprobación
D08.2-D	Versionado/validez	Timestamp; hash DTO; testigos explícitos con locks	d082-plan-v1, revisión/huella, TTL30min, current reads y Operational:2 (§9)	E01–E03,E07,E11,E15	Cualquier nueva fuente obliga a revisar; no snapshot interpetición	Contención/stale, backend antiguo	Lectores, canonicalización, límites 100/10.000 medidos	Propietario: regla/TTL/límites; arquitectura: header/evolución	Pendiente de aprobación
D08.2-E	Retención	RESTRICT todos los planes; efímero sin evidencia; planes snapshot separados	Sin FK operativa en observación no confirmada; confirmado fuerte; TTL30min/detalle30d propuestos (§10)	E06,E13 y hallazgo P1-P07	Preflight no bloquea delete; commit sí protege linaje	Volumen, datos personales, cleanup en carrera	Tombstones, cleanup auditado, política corporativa si aplica	Propietario/privacidad: criterios y protección de borrado	Pendiente de aprobación
D08.2-F	Compensación	Automática; plan específico; ordinarias; bloquear piloto	No ejecutable inicial; piloto solo con aceptación explícita del límite, o bloquear C hasta disponer de inversa (§11)	E02–E05 y DR-D08	No prometer deshacer; conservar datos para futura operación	Corrección de identidad no general con operaciones actuales	Contrato D separado si requerido	Propietario: elegir aceptar límite o exigir inversa previa	Pendiente de aprobación
D08.2-G	Escritores	Varios endpoints; ampliar unidad explícita; transacción distribuida	Unidad Companies específica, puertos propietarios ligados (§12)	E04–E07	Efectos de ambas familias/auditoría en commit único	Result.fail post-DML, locks incompletos	Auditoría común/Identity/current reads y pruebas de fallo	Arquitectura/propietario: alcance de adaptación	Pendiente de aprobación
D08.2-H	Inserción	Upsert existente; REPLACE/IGNORE; INSERT estricto	insertSuccessor interno estricto, sin cambiar upsert general (§13)	E05/E06	Nueva identidad o rechazo, ninguna actualización implícita	Colisión/código mal clasificado	UUID, FK/UNIQUE, unidad auditada	Arquitectura: contrato estricto para sucesión	Pendiente de aprobación
D08.2-I	Procedencia	Notas/JSON; ID polimórfico sin FK; líneas tipadas	Plan/comando/operación/items tipados y auditoría, FK reales confirmadas (§14)	E01,E06,E13 y DR-D01/D08	Reconstrucción durable y delete de implicadas bloqueado	DDL/retención/compatibilidad de tipos	Migración futura ensayada y guards delete	Propietario: efecto funcional; arquitectura: modelo relacional	Pendiente de aprobación
D08.2-J	Gates	Lectura abre escritura; único flag; gates separados	Preflight/confirm default off; lectura histórica independiente; compensación fuera (§17)	E14 y DR-D10	Activación faseada, sin rollback de datos por flag	Instancias antiguas/in-flight	Versiones mínimas y procedimiento operativo	Propietario/operación: fases y activación separadas	Pendiente de aprobación

No hay evidencia de aprobación/rechazo efectivos nuevos: ninguna fila usa esos estados. D01–D10 se conservan con sus ratificaciones históricas; sus estados no se copian como aprobación de A–J. El acta de §25 exige identificar resolución por fila, no un «sí» ambiguo al conjunto.

Correspondencia con pendientes P1

P1	Propuesta concreta D08.2
P01 cierre	A define comando/terminal y estados admitidos.
P02 parcialidad	B define selección, omitidas, conflictos y planes sucesivos.
P03 permisos	C elige preparación ordinaria y aprobación administrativa con revalidación interior; cambio explícito respecto a admin-only preliminar.
P04 límites/TTL	D propone 30 minutos, 100/10.000 y verificación futura, sin cifras de rendimiento inventadas.
P05 versionado	D/A mantienen header operativo separado y todos los lectores antes del primer dato nuevo.
P06 compensación	F la excluye del primer piloto y exige aceptación expresa del límite o bloqueo de C.
P07 retención	E/I separan observaciones sin FK operativa de procedencia confirmada fuerte y definen tombstones/depuración.
P08 gates/despliegue	J y fases A–D fijan entradas/salidas, sin autorización de ejecutar.

22. Riesgos y dependencias

Riesgo residual	Mitigación propuesta / dependencia real
Evidencia comercial errónea	Revisión/evidencia concreta y aceptación humana; nombre/provider no son certificación automática. A0 sigue válido.
Nuevo terminal no soportado	Desplegar unions específicas, lectores, históricos, filtros/counters y negociación antes de C. No basta tipo UUID ni VARCHAR.
Permiso caduca en espera	Puerto Identity ligado y segundo check; ensayar grafo con usuario/estado. No guard frontend ni callback fuera de unidad como garantía.
Upsert/persist actual no sirve para sucesora	Método estricto ligado; no refactor de upsert general fuera de alcance.
Auditoría común no existe	Dependencia bloqueante para todas las escrituras nuevas, no solo éxito. Su cobertura parcial no anuncia auditoría global completada.
Preflight costoso y frecuente stale	Proyección normalizada acotada, índices/mediciones, TTL y límites; no reutilizar indiscriminadamente listas completas con historia para 10.000 raíces.
Reserva pending tras caída	Retomar bajo locks, no lease ficticio ni GET que ejecute; limpiar expiradas sin borrar clave y resolver commit incierto por lectura.
Limpieza destruye resultado	Cabecera/huellas/resultados durables; nunca purgar confirmados; bloqueo ordenado y auditoría, ensayos de carrera.
Delete deja de ser válido tras adopción	Consecuencia PA-E/I explícita; mensaje antes de borrar hijos, FK como defensa. No bloqueo por mero plan.
Error de identidad sin inversa inicial	PA-F explícita, no prometer reparación general con CRUD. Bloquear piloto si producto requiere reversibilidad.
Escritores no cooperantes / SQL externo	Inventario y pruebas de caminos; mutex no garantiza frente a DML arbitrario externo. No ampliar promesas de inmutabilidad absoluta ante admin de BD.
Datos personales/retención	Minimizar, acceso por acción y política aprobada; no inventar plazos legales.
Downgrade incompatible	Versión mínima conservada después de B1; corregir hacia delante. Compensar no elimina la necesidad de lector histórico.
Deuda de aceptación global previa	G6 R2.4 y aceptación R2.5/R2.6 permanecen pendientes hasta evidencia/resolución explícita; D08.2 no los cierra.

Dependencias técnicas antes de C: cierre A, escrituras unitarias G/H, modelo I y retención E, auditoría común, capacidad pública Identity C, lectura actual de contexto/dependencias, esquema/lectores/versionado D, gates/procedimiento J y pruebas §20. Son cambios futuros concretos, no una afirmación de contratos implementables con código actual sin adaptación.

23. Condiciones de ratificación

Lista de consistencia y ratificabilidad

Criterio	Resultado de análisis estático	Condición restante
Cierre por agregado	Definido en A, sin falsear retirada	Aprobación de terminal/comando y evolución contractual.
Parcialidad/atomicidad	B concreta seleccionadas/omitidas/nuevas y commit	Aprobar política; implementación/probar G después.
Autorización	C concreta sujetos/acciones/contexto y check interior	Aprobar nueva política e implementar puerto ligado.
Validez/concurrencia	D define huella/testigos/locks/TTL/cambios	Aprobar presupuestos/versionado y ensayar el grafo ampliado.
Retención	E separa fuentes durables/efímeras y borrado	Aprobar criterios y efectos funcionales; no plazo jurídico ficticio.
Compensación	F define fuera del piloto y decisión de riesgo necesaria	Elegir expresamente límite aceptado o inversa previa. Sin decisión, C bloqueada.
Procedencia/auditoría	I y §15 definen reconstrucción y causalidad	Modelo físico/constraints y capacidad común futuros.
Escritores/INSERT	G/H fijan adaptación mínima y semántica estricta	Implementar únicamente tras autorización, probar atomicidad.
Conflictos/HTTP	§§6–16 cubren sesión, scope, estados, pares, datos, stale, retry y gates	Aprobar contrato y mapear/cubrir con tests futuros.
Consumidores	Matriz §18 incluye límites de UUID/estado/proyección	Inventario final y lectores activos compatibles antes de C.
Flags/activación	J separa lectura/metadata/ejecución	Procedimiento de fases y autorización de activación posterior.
Pruebas	§20 cubre capas/fallos/compensación futura	Diseñadas, no ejecutadas; no reemplazan pruebas de implementación.
D01–D10	Sin cambio de UUID/owner/allowlist/ACL implícita/history	A/D son evolución operacional propuesta explícita, no reinterpretación de ADR ratificado.

Dictamen B — ratificable con condiciones. Las decisiones esenciales tienen una propuesta explícita, pero A/C/E/F y efectos de versionado/borrado requieren resolución del propietario; las nuevas garantías de escritores/auditoría/Identity deben desarrollarse después, bajo alcance autorizado. No se declara «técnicamente ratificado» ni un sistema ya implementable sin esas adaptaciones.

Para autorizar R2.7-A: acta con decisiones A–J y riesgos/alcance resueltos, o autorización parcial precisa que excluya expresamente lo no aprobado, más nueva instrucción de ejecución. Para C: A/B completadas y verificadas, PA-F resuelta, prerrequisitos técnicos implementados, regresiones y deuda/gates previos tratados, lector mínimo en todos los nodos y permiso separado de activación. Ratificar diseño no activa ninguna fase/flag.

Verificación documental de D08.2

Relectura íntegra D08.1, contraste con D01–D10 y evidencia CV citada. Se identifican como sin respaldo de implementación closeForSuccession/superseded, permisos por acción, autorización ligada, tablas/operaciones, auditoría común, INSERT específico, header operativo y flags de adopción; todos permanecen RT/PA. No hay referencia a ellos como exports/rutas instalados.

Cierre: estructura de 25 apartados, referencias locales y fuentes verificadas, tablas/diagramas revisados estáticamente, fences equilibrados, ausencia de conflictos/espacios finales y git diff --check. Comparación con snapshot inicial para acreditar que solo se añade este documento y que flags/modelos/APIs/migraciones/tests y documentos anteriores permanecen intactos. Diagramas no renderizados por motor Mermaid; ninguna prueba funcional, SQL o navegador ejecutada. No se afirman resultados nuevos de aplicación.

24. Recomendación final

Someter a aprobación D08.2-v1 con decisiones A–J separadas. Se recomienda A2 por sucesión documental y parcialidad atómica; preparar planes con privilegio menor que confirmar; retener con fuerza los hechos confirmados sin congelar el CRUD por planes abandonados; rechazar cualquier automatismo por nombre o upsert que reutilice otra raíz.

Antes del piloto se debe elegir expresamente PA-F. La opción recomendada es diferir compensación ejecutable, pero aceptar ese alcance exige asumir que no hay corrección documental inversa general con operaciones actuales. Si ese riesgo no es aceptable, la recomendación pasa a bloquear confirmaciones hasta disponer de contrato/implementación inversos. No simular garantías para evitar ese bloqueo.

A0/R2.6 permanece vigente y útil. El expediente permite una decisión informada; no toma esa decisión por el propietario. No se inicia R2.7.

25. Acta de aprobación pendiente

Esta sección registra un formulario de aprobación, no una aprobación efectiva. Publicar, versionar o recibir este documento no completa el acta.

Campo	Propuesta sometida a decisión
Versión	D08.2-v1, este expediente, con referencias históricas preservadas.
Decisiones propuestas	D08.2-A a D08.2-J; registrar resultado individual, condiciones y alcance en cada caso.
Alternativas desaconsejadas técnicamente	A1/update resourceId; removed ficticio; causa lateral sin resolver closed; parcialidad con commit parcial; permiso implícito por leer global; upsert/REPLACE/IGNORE de sucesora; observación no confirmada que bloquee todo delete; deshacer mediante backup. No constan como rechazadas formalmente por el propietario.
Riesgos sometidos a aceptación	Compatibilidad de estados/lectores, nueva restricción de borrado por confirmados, límites/retención, coste de locks/stale, verificación comercial humana y ausencia de inversa general en piloto.
Dependencias exigidas	Unidad G/H, autorización C interior, procedencia I/retención E, auditoría común, lectores D, gates J y pruebas/operación §§19–20.
Entrada propuesta a R2.7	Nueva instrucción tras ratificación; fases A–D con entradas/salidas de §19; C requiere PA-F y activación separadas.

Campos de aprobación efectiva sin completar:

• Identidad o rol aprobador: ____________________
• Fecha efectiva de aprobación: ____________________
• Resultado global del propietario: ____________________
• Decisiones aprobadas expresamente y condiciones: ____________________
• Decisiones rechazadas expresamente / alternativas elegidas: ____________________
• Resolución PA-F: piloto sin inversa general o inversa previa obligatoria: ____________________
• Riesgos aceptados efectivamente: ____________________
• Alcance de ejecución autorizado mediante nueva instrucción, si procede: ____________________
• Firma o referencia verificable de la decisión: ____________________

Hasta una decisión expresa verificable, todas las filas A–J continúan pendientes y R2.7 no está autorizado. Una aprobación parcial debe indicar qué fases quedan excluidas; el silencio no completa alternativas ni aceptación de riesgos.