docs: traer los registros al repositorio y poner TD-001/ADR-0067/G-066 al día (cierra TD-010)

[beyondnetPeru]

Cierra TD-010 y pone al día tres registros que afirmaban cosas que el código contradice. Cero líneas de código: ninguna corrección es una decisión nueva.

---

Parte 1 — Los registros vienen al repositorio (TD-010)

DECISIONS.md y GAPS.md no estaban aquí y nunca habían estado. Los D-NNN y G-NNN que citan la arquitectura de solución, los objetivos de calidad, el modelo de amenazas, el PRD y ~180 comentarios del código apuntaban a ficheros inexistentes.

Lo que costó: preguntado si se había descartado GraphQL, los ADRs eran el sitio natural donde mirar — y 0055 y 0059 decían Aceptado, así que la respuesta fue «no se decidió nada». Falso. D-007 lo había decidido el 2026-07-14, un mes antes, y el código seguía con el tier completo.

• 255 brechas y 39 decisiones portadas desde unimar-peru/unimar-ums y rebrandeadas.
• 134 enlaces resuelven, 0 rotos. 55 necesitaron recalcular su profundidad de ../.
• 77 enlaces muertos que traían los ficheros portados (./reference/..., rutas del origen) se convierten en referencia textual: un enlace muerto miente más que una referencia sin enlazar.
• Las entradas heredadas conservan numeración y describen el estado del origen. DECISIONS.md abre con una tabla de qué se ha verificado aquí —D-007, D-008, D-009— y dice que el resto no.

---

Parte 2 — Tres registros puestos al día

TD-001 — decía que se viola el aislamiento, y no es cierto

Las tablas ya están separadas por esquema, que es lo que pide ADR-0067:

Esquema	Configs		Esquema	Configs
ums_authorization	413		ums_platform	90
ums_identity	337		iga	36
ums_configuration	264		audit	33
approvals	264

Es un contexto sobre siete esquemas. Lo compartido —y esa sí es la deuda— son tres cosas: un snapshot EF de 3.424 líneas que todos regeneran, un outbox único, y una frontera transaccional única.

Lo que de verdad bloquea la extracción: dos handlers, ya registrados como excepciones formales de D-016 y ya marcados con TODO(D-016) en el código:

	Handler	Escribe	Estado
E1	ApproveTenantSignupCommandHandler	Tenant + UserAccount + SignupRequest	Justificada (arranque indivisible)
E2	ApproveRequestCommandHandler	ApprovalRequest + Profile	Provisional

Orden correcto: saga primero, partir después. Partir manteniendo conexión compartida arregla el conflicto de migraciones y no avanza un metro hacia la extracción: muda el acoplamiento de «un DbContext» a «una transacción compartida».

Se documenta también el cómo: un outbox por contexto (ya hay dos registrados aquí), y por qué E2 es menor de lo que «saga» sugiere — su consumidor ya es idempotente (if (isNewProfile) Add else Update) y el evento que consumiría, ProfileAssignedToUserEvent, ya se emite hoy.

ADR-0067 — promete una extracción hoy imposible

«Puede migrarse a otra base con cambios mínimos» no se cumple mientras E1 y E2 escriban entre esquemas en una transacción. Anotado en ambos idiomas: retirarlas es la precondición de esa promesa, no su consecuencia.

G-066 — su D4.1 ya está arreglado

Declara como bug la publicación pre-commit («mensaje fantasma»). Verificado: EnableOutbox: true en los tres entornos y UseBusOutbox(), así que el publish previo a SaveChangesAsync no va al broker — escribe en el outbox del mismo DbContext y se entrega tras el commit. Lo dice el propio código en DependencyInjection.cs:294. La ficha no se actualizó al activarlo.

---

Lo que este PR no autoriza

Nada aquí es una decisión, así que nada requiere código. Cuando llegue el disparador de la Fase 3 tampoco hará falta un ADR nuevo: D-016 y ADR-0098 ya lo gobiernan. Lo que sí lo exigiría, por S-06 y el precedente de D-012 («la implementación arranca al aceptarse el ADR»), es cambiar la postura — y eso sería un ADR superador aceptado aguas arriba en evolith-core.

Pendiente

Trece identificadores (G-276…G-291) citan un segundo registro, de evolith-core, que no he podido localizar. ums cita dos registros que comparten el espacio G-NNN. Anotado en GAPS.md.

🤖 Generated with Claude Code