docs: sync Spanish requirements/functional stories with codebase and naming conventions

Author: beyondnetPeru

docs/governance/requirements-es/functional-stories/fs-03-register-organization.md

@@ -51,14 +51,14 @@ Si la referencia empresarial ya existe, el sistema evita crear una organización
 
 ## 8. Requisitos Técnicos
 
-- Persistir datos de organización en el modelo `TENANT` / `ORGANIZATION`.
-- Persistir configuración de proveedor de identidad en `IDP_CONFIGURATION`.
+- Persistir datos del tenant en el Agregado Root `Tenant`.
+- Persistir configuración de proveedor de identidad en la Entidad hija `IdentityProvider`.
 - Aplicar unicidad para referencias externas de compañía.
-- Emitir `OrganizationCreatedEvent`.
+- Emitir `TenantCreatedEvent`.
 - Validar configuración IdP según el tipo de proveedor seleccionado.
 
 ## 9. Trazabilidad
 
-- Entidades: `TENANT`, `BRANCH`, `IDP_CONFIGURATION`, `USER_ACCOUNT`
+- Entidades: `Tenant` (AR), `Branch` (Entidad Hija), `IdentityProvider` (Entidad Hija), `UserAccount` (AR)
 - ADRs: ADR-0031, ADR-0032, ADR-0034, ADR-0010
 - Technical Enabler: TE-03

docs/governance/requirements-es/functional-stories/fs-04-register-system-topology.md

@@ -49,13 +49,16 @@ Si un nodo de topología estáá incompleto, UMS puede guardarlo como borrador p
 
 ## 8. Requisitos Técnicos
 
-- Persistir topología usando `SYSTEM_SUITE`, `FUNCTIONAL_MODULE`, `FUNCTIONAL_SUBMODULE`, `FUNCTIONAL_OPTION` y `ACTION`.
-- Generar y almacenar credencial segura machine-to-machine para sistemas registrados.
-- Emitir `SystemRegisteredEvent`.
-- Validar completitud de topología antes de usarla en plantillas.
+> [!WARNING]
+> **ESTADO DE IMPLEMENTACIÓN: DIFERIDO**  
+> En la fase actual, la gestión activa de la topología de recursos de sistemas (`SystemSuite`, `FunctionalModule`, etc.) está **diferida** en el dominio principal de C# y se maneja mediante referencias externas a nivel de Value Object ID (`SystemSuiteId`).
+
+- Asegurar la persistencia del identificador y metadatos del sistema.
+- Asegurar la unicidad de los códigos de sistema.
+- Emitir eventos de dominio cuando se registran metadatos de sistema.
 
 ## 9. Trazabilidad
 
-- Entidades: `SYSTEM_SUITE`, `FUNCTIONAL_MODULE`, `FUNCTIONAL_SUBMODULE`, `FUNCTIONAL_OPTION`, `ACTION`
+- Entidades: `SystemSuite` (Referencia ID Diferida), `FunctionalModule` (Referencia ID Diferida)
 - ADRs: ADR-0032, ADR-0034, ADR-0047
 - Historias relacionadas: FS-02, FS-07

docs/governance/requirements-es/functional-stories/fs-06-auto-assign-template.md

@@ -50,13 +50,16 @@ Si más de una regla coincide, UMS aplica la regla de mayor prioridad y registra
 
 ## 8. Requisitos Técnicos
 
-- Evaluar reglas activas durante la creación del perfil.
-- Persistir estado de asignación en la relación perfil/plantilla.
-- Invalidar caché del grafo de autorización para usuarios afectados.
-- Emitir evento de auditoría con `auto: true` y referencia de regla seleccionada.
+> [!WARNING]
+> **ESTADO DE IMPLEMENTACIÓN: DIFERIDO**  
+> En la fase actual, la lógica automatizada de reglas de auto-asignación (`TemplateAssignmentRule`) está **diferida** en el dominio principal de C# y se maneja mediante referencias externas o asignaciones directas y manuales en los perfiles.
+
+- Persistir el estado de asignación en la relación perfil/plantilla.
+- Invalidar la caché del grafo de autorización para usuarios afectados.
+- Emitir eventos de dominio y auditoría para las asignaciones de plantillas.
 
 ## 9. Trazabilidad
 
-- Entidades: `PROFILE`, `PERMISSION_TEMPLATE`, `PROFILE_PERMISSION`
+- Entidades: `Profile` (AR), `PermissionTemplate` (AR), `TemplateAssignmentRule` (Diferido)
 - ADRs: ADR-0042, ADR-0043, ADR-0035
 - Technical Enabler: TE-01

docs/governance/requirements-es/functional-stories/fs-11-user-document-upload.md

@@ -50,13 +50,16 @@ Si el archivo estáá corrupto, no puede leerse o incumple reglas de carga, el s
 
 ## 8. Requisitos Técnicos
 
-- Persistir metadata en `USER_DOCUMENT`.
-- Clasificar documentos mediante `DOCUMENT_TYPE`.
+> [!NOTE]
+> En la implementación real de C# (base de código), los agregados de cumplimiento y aprobación están unificados bajo el espacio de nombres **[Ums.Domain.Approvals](file:///d:/Users/aarroyo/personal/sources/ums/src/apps/app-api-dotnet/Ums.Domain/Approvals/)**.
+
+- Persistir metadatos en el Agregado Root `UserDocument`.
+- Clasificar documentos mediante el Agregado Root `DocumentType`.
 - Guardar ubicación del archivo y checksum para recuperación e integridad.
-- Emitir eventos de auditoría por carga, validación, rechazo y cambios de estado.
+- Emitir eventos de dominio y auditoría por carga, validación, rechazo y cambios de estado.
 
 ## 9. Trazabilidad
 
-- Entidades: `USER_DOCUMENT`, `DOCUMENT_TYPE`
+- Entidades: `UserDocument` (AR), `DocumentType` (AR)
 - ADRs: ADR-0045, ADR-0016
 - Historias relacionadas: FS-15, FS-16

docs/governance/requirements-es/functional-stories/fs-12-role-promotion-process.md

@@ -51,13 +51,18 @@ Si el administrador rechaza la promoción, el usuario permanece en el rol actual
 
 ## 8. Requisitos Técnicos
 
-- Evaluar criterios desde `ROLE_PROMOTION_CRITERIA`.
-- Registrar estado del proceso en `USER_PROMOTION_PROCESS`.
-- Usar `APPROVAL_REQUEST` cuando se requiera aprobación manual.
-- Persistir eventos de auditoría por elegibilidad, aprobación, rechazo y cierre de promoción.
+> [!NOTE]
+> En la implementación real de C# (base de código), el motor de promociones está implementado mediante dos agregados independientes en el espacio de nombres **[Ums.Domain.IGA](file:///d:/Users/aarroyo/personal/sources/ums/src/apps/app-api-dotnet/Ums.Domain/IGA/)**:
+> 1. **[RoleMaturityStatus](file:///d:/Users/aarroyo/personal/sources/ums/src/apps/app-api-dotnet/Ums.Domain/IGA/RoleMaturityStatus/RoleMaturityStatus.cs)**: Mantiene las capacitaciones, certificaciones, score de desempeño e invariantes de elegibilidad del usuario.
+> 2. **[PromotionRequest](file:///d:/Users/aarroyo/personal/sources/ums/src/apps/app-api-dotnet/Ums.Domain/IGA/PromotionRequest/PromotionRequest.cs)**: Orquesta el flujo de aprobación transaccional y realiza análisis de riesgo automatizados.
+
+- Monitorear la elegibilidad y métricas del usuario en el Agregado Root `RoleMaturityStatus`.
+- Gestionar las etapas de la transacción de promoción y el análisis de impacto de riesgo en el Agregado Root `PromotionRequest` (con su entidad hija `PromotionImpactAnalysis`).
+- Hacer cumplir las invariantes de elegibilidad (antigüedad mínima en nivel: Junior 6 meses, Intermediate 12 meses, Senior 18 meses, Lead 24 meses; score de desempeño >= 3.0; sin bloqueos de cumplimiento) antes del envío.
+- Emitir Eventos de Dominio específicos: `PromotionRequestCreated`, `PromotionRequestSubmitted`, `PromotionRequestApproved`, `PromotionRequestExecuted`, `PromotionRequestVerified`.
 
 ## 9. Trazabilidad
 
-- Entidades: `ROLE_PROMOTION_CRITERIA`, `USER_PROMOTION_PROCESS`, `ROLE`, `APPROVAL_REQUEST`
+- Entidades: `RoleMaturityStatus` (AR), `PromotionRequest` (AR), `PromotionImpactAnalysis` (Entidad Hija)
 - ADRs: ADR-0046, ADR-0036
 - Historias relacionadas: FS-11, FS-14

docs/governance/requirements-es/functional-stories/fs-13-hierarchical-config.md

@@ -72,18 +72,18 @@ Si ya existe un parámetro con el mismo identificador en el alcance seleccionado
 
 ## 8. Requisitos Técnicos
 
-- Persistir configuraciones en `APP_CONFIGURATION`.
-- Campos obligatorios: `Code`, `Value`, `Description`.
-- Aplicar unicidad por alcance mediante `UX_APP_CONFIGURATION_CODE_SCOPE`.
-- Soportar linaje de versiones, auditoría, eventos de trazabilidad, cacheabilidad e invalidación.
-- Los parámetros sensibles deben soportar valores cifrados.
-- La configuración efectiva puede cachearse, pero debe invalidarse cuando cambia un parámetro.
+> [!WARNING]
+> **ESTADO DE IMPLEMENTACIÓN: DIFERIDO / FUERA DE ALCANCE**  
+> En la fase actual, la gestión activa de parámetros jerárquicos de configuración (`AppConfiguration`) está **diferida** y no está implementada dentro del proyecto principal de dominio de C#.
+
+- Asegurar estructura para parámetros de configuración según su alcance.
+- Soportar el rastreo de auditoría en sobrescrituras de configuración.
 
 ---
 
 ## 9. Trazabilidad
 
-- Entidades: `APP_CONFIGURATION`, `TENANT`, `SYSTEM_SUITE`, `FUNCTIONAL_MODULE`
+- Entidades: `AppConfiguration` (AR Diferido)
 - ADRs: ADR-0024, ADR-0047
 - Technical Enabler: TE-02 Resolve Hierarchical System Configuration
 - Estándar: Estándar de Redacción de Historias Funcionales; Estándar de Catálogos Paramétricos

docs/governance/requirements-es/functional-stories/fs-14-delegated-management.md

@@ -51,13 +51,15 @@ Si la delegación crea una cadena circular de gestión o escalamiento de privile
 
 ## 8. Requisitos Técnicos
 
-- Persistir relaciones en `USER_MANAGEMENT_DELEGATION`.
-- Validar reglas recursivas de alcance y anti-escalamiento de privilegios.
-- Soportar `SuiteId` opcional y alcance temporal.
-- Emitir eventos de auditoría por creación, actualización, revocación e intentos de violación.
+> [!WARNING]
+> **ESTADO DE IMPLEMENTACIÓN: DIFERIDO / FUERA DE ALCANCE**  
+> En la fase actual, la lógica transaccional de delegación administrativa de usuarios (`UserManagementDelegation`) está **diferida** y no está implementada dentro del proyecto principal de dominio de C#.
+
+- Hacer cumplir la lógica de validación recursiva de alcance a nivel de aplicación.
+- Soportar el rastreo de auditoría en eventos del ciclo de vida de la delegación.
 
 ## 9. Trazabilidad
 
-- Entidades: `USER_MANAGEMENT_DELEGATION`, `USER_ACCOUNT`, `SYSTEM_SUITE`
+- Entidades: `UserManagementDelegation` (AR Diferido), `UserAccount` (AR)
 - ADRs: ADR-0038, ADR-0044
 - Historias relacionadas: FS-10, FS-12

docs/governance/requirements-es/functional-stories/fs-15-notification-rules.md

@@ -59,8 +59,11 @@ Si ya existe una regla idéntica para el mismo documento, tenant, anticipación
 
 ## 8. Requisitos Técnicos
 
-- Persistir reglas en `NOTIFICATION_RULE`.
-- Campos obligatorios: `Code`, `Value`, `Description`.
+> [!NOTE]
+> En la implementación real de C# (base de código), `NotificationRule` es una Entidad hija encapsulada dentro del Agregado **[DocumentType](file:///d:/Users/aarroyo/personal/sources/ums/src/apps/app-api-dotnet/Ums.Domain/Approvals/DocumentType/DocumentType.cs)**, bajo el espacio de nombres unificado **[Ums.Domain.Approvals](file:///d:/Users/aarroyo/personal/sources/ums/src/apps/app-api-dotnet/Ums.Domain/Approvals/)**.
+
+- Persistir reglas como parte del Agregado Root `DocumentType`.
+- Campos obligatorios: `Code`, `Value` (JSON con tiempos y canales), `Description`.
 - Aplicar unicidad por `Code`, `TenantId` y `DocumentTypeId`.
 - Registrar trazabilidad de entrega de notificaciones.
 - Soportar invalidación de caché cuando cambian reglas de notificación.
@@ -69,6 +72,6 @@ Si ya existe una regla idéntica para el mismo documento, tenant, anticipación
 
 ## 9. Trazabilidad
 
-- Entidades: `NOTIFICATION_RULE`, `DOCUMENT_TYPE`, `USER_DOCUMENT`
+- Entidades: `DocumentType` (AR), `NotificationRule` (Entidad Hija), `UserDocument` (AR)
 - ADRs: ADR-0045, ADR-0016
 - Historias relacionadas: FS-11, FS-16

docs/governance/requirements-es/functional-stories/fs-16-access-enforcement-policy.md

@@ -65,16 +65,19 @@ Si el tipo de documento seleccionado no es crítico para acceso, el sistema impi
 
 ## 8. Requisitos Técnicos
 
-- Persistir políticas en `ACCESS_ENFORCEMENT_POLICY`.
-- Campos obligatorios: `Code`, `Value`, `Description`.
+> [!NOTE]
+> En la implementación real de C# (base de código), `AccessEnforcementPolicy` es una Entidad hija encapsulada dentro del Agregado **[DocumentType](file:///d:/Users/aarroyo/personal/sources/ums/src/apps/app-api-dotnet/Ums.Domain/Approvals/DocumentType/DocumentType.cs)**, bajo el espacio de nombres unificado **[Ums.Domain.Approvals](file:///d:/Users/aarroyo/personal/sources/ums/src/apps/app-api-dotnet/Ums.Domain/Approvals/)**.
+
+- Persistir políticas como parte del Agregado Root `DocumentType`.
+- Campos obligatorios: `Code`, `Value` (JSON con acciones de la política), `Description`.
 - Aplicar unicidad por `Code`, alcance de tenant y `DocumentTypeId`.
 - Acciones soportadas: `BLOCK_USER`, `RESTRICT_PROFILE` y `LOG_ONLY`.
-- Emitir eventos de auditoría cuando se aplican o revierten restricciónes.
+- Emitir eventos de dominio y auditoría cuando se aplican o revierten restricciones.
 
 ---
 
 ## 9. Trazabilidad
 
-- Entidades: `ACCESS_ENFORCEMENT_POLICY`, `DOCUMENT_TYPE`, `USER_ACCOUNT`, `PROFILE`
+- Entidades: `DocumentType` (AR), `AccessEnforcementPolicy` (Entidad Hija), `UserAccount` (AR), `Profile` (AR)
 - ADRs: ADR-0045, ADR-0035
 - Historias relacionadas: FS-11, FS-15