@evolith/core-domain 1.0.1 → 1.0.3

package/rulesets/topologies/event-driven/resilience.md

@@ -1,65 +0,0 @@
-# Event-Driven — Resilience Guide
-
-> **Bilingual Navigation:** [English](./resilience.md) | [Español](./resilience.es.md)
-
-**Owner:** Architecture Board
-**Topology:** Event-Driven
-
-## Purpose
-
-Define resilience patterns for event-driven architectures: idempotent consumers, exactly-once semantics, poison pill handling, retry backoff, consumer rebalancing, and transactional outbox.
-
-## Idempotent Consumers — ED-R05
-
-- Every consumer MUST process events idempotently; duplicate delivery is assumed.
-- Use deduplication keys composed of `(event-id, consumer-group)` stored in a durable cache.
-- Set deduplication window to at least 2x the broker's maximum retention period.
-
-## Exactly-Once Semantics
-
-- Prefer idempotent producers with producer IDs over broker-level exactly-once guarantees.
-- For critical workflows, use transactional producers that atomically write to multiple topics.
-- Document the semantic guarantee level (at-least-once, effectively-once) per consumer.
-
-## Poison Pill Handling — ED-R03
-
-- Detect poison pills by tracking per-message retry counts in consumer state.
-- After configurable retry exhaustion (default: 3), route message to DLQ with full context.
-- Alert on poison pill rate exceeding 0.1% of total message volume.
-
-## Retry Backoff
-
-- Implement exponential backoff with jitter: `base * 2^attempt + random(0, base)`.
-- Cap maximum retry delay at 5 minutes; escalate to DLQ after cap is reached.
-- Use separate retry queues for transient vs. permanent failure categories.
-
-## Consumer Rebalancing
-
-- Design consumers to handle rebalance events gracefully; pause processing during rebalance.
-- Use cooperative sticky partition assignment to minimize partition movement.
-- Monitor rebalance frequency; investigate if rebalances exceed 1 per hour per consumer group.
-
-## Transactional Outbox — ED-R02
-
-- Write domain events to an outbox table within the same transaction as business state changes.
-- Publish outbox events via CDC or polling publisher to the broker.
-- Guarantee that outbox records are eventually published; monitor outbox depth.
-
-## Composable Applicability
-
-| Composable | Guidance |
-|---|---|
-| Modular Monolith | Outbox is intra-database; idempotency via shared cache. |
-| Distributed Modules | Cross-module outbox requires careful transaction boundary design. |
-| Microservices | Per-service outbox; consumer isolation per service boundary. |
-| Serverless | Managed deduplication; outbox via database triggers. |
-| Edge Computing | Local outbox with eventual sync to cloud broker. |
-
-## ADR References
-
-- **ADR-0015**: Consumer resilience and retry policy standards.
-- **ADR-0079**: Transactional outbox implementation pattern.
-
----
-
-[Back to Event-Driven Profile](./README.md)

package/rulesets/topologies/event-driven/runbooks.es.md

@@ -1,79 +0,0 @@
-# Guía de Manuales Operativos Orientada a Eventos
-
-> **Navegación Bilingüe:** [English](./runbooks.md) | [Español](./runbooks.es.md)
-
-**Propietario:** Junta de Arquitectura
-**Topología:** Orientada a Eventos
-
-## Propósito
-
-Proveer manuales operativos para escenarios de falla comunes en arquitecturas orientadas a eventos: failover del broker, rebalanceo de consumidores, migración de esquemas, reproducción de DLQ y recuperación de violaciones de ordenamiento.
-
-## Manual 1: Failover del Broker
-
-**Disparador:** Nodo del broker no responde o falla verificación de salud del clúster.
-
-1. Verificar estado del nodo del broker vía consola de gestión del clúster.
-2. Confirmar que la reasignación de líder de particiones se completó automáticamente.
-3. Verificar retraso del grupo de consumidores para temas afectados; alertar si el retraso excede el umbral.
-4. Validar que los reintentos del productor están teniendo éxito en brokers sobrevivientes.
-5. Post-recuperación: revisar configuración del broker para factor de réplicas y min-insync replicas.
-
-## Manual 2: Rebalanceo de Consumidores
-
-**Disparador:** Grupo de consumidores experimenta rebalanceos repetidos o tormenta de rebalanceo.
-
-1. Identificar el desencadenante del rebalanceo: nuevo ingreso de consumidor, crash de consumidor o timeout de heartbeat.
-2. Verificar salud de la instancia del consumidor: memoria, CPU, pausas de GC.
-3. Revisar configuración de session.timeout.ms y heartbeat.interval.ms.
-4. Si hay tormenta de rebalanceo: reducir temporalmente instancias de consumidor para estabilizar.
-5. Post-recuperación: ajustar configuraciones de timeout; considerar estrategia de asignación cooperativa y pegajosa.
-
-## Manual 3: Migración de Esquemas
-
-**Disparador:** El esquema del evento requiere un cambio rupturante.
-
-1. Registrar nueva versión del esquema en el registro de esquemas con modo de compatibilidad configurado.
-2. Desplegar consumidores actualizados que toleren versiones de esquema antigua y nueva.
-3. Habilitar escritura dual en productores: emitir eventos en ambos formatos antiguo y nuevo.
-4. Monitorear tasas de error de consumidores durante la ventana de migración.
-5. Después de que todos los consumidores se actualicen: eliminar escritura dual; deprecar esquema antiguo.
-
-## Manual 4: Reproducción de DLQ — ED-R03
-
-**Disparador:** Profundidad de DLQ excede umbral o el negocio requiere reprocesamiento.
-
-1. Identificar tema DLQ y grupo de consumidores afectado.
-2. Revisar mensajes de DLQ: confirmar que la causa raíz está resuelta (por ejemplo, corrección de esquema desplegada).
-3. Usar herramienta de reproducción de DLQ para republicar mensajes al tema original.
-4. Monitorear procesamiento del consumidor; confirmar que los mensajes se consumen exitosamente.
-5. Post-reproducción: verificar que la profundidad de DLQ regresa a cero; documentar causa raíz.
-
-## Manual 5: Violación de Ordenamiento — ED-R04
-
-**Disparador:** Consumidor detecta eventos procesados fuera del orden esperado.
-
-1. Identificar partición afectada y secuencia de eventos.
-2. Verificar distribución de clave de partición del productor; confirmar que la clave es estable.
-3. Verificar que el consumidor no esté procesando desde múltiples particiones concurrentemente sin lógica de ordenamiento.
-4. Si el ordenamiento es crítico: forzar consumo de un solo hilo por partición.
-5. Post-recuperación: revisar estrategia de clave de partición; considerar rediseño de clave si se detecta partición caliente.
-
-## Aplicabilidad Componible
-
-| Componible | Orientación |
-|---|---|
-| Monolito Modular | Manuales simplificados; failover intra-proceso es automático. |
-| Módulos Distribuidos | Coordinación entre módulos durante failover y rebalanceo. |
-| Microservicios | Alcance completo de manuales; DLQ y gestión de ordenamiento por servicio. |
-| Serverless | Failover gestionado por proveedor; manuales se enfocan en recuperación a nivel de aplicación. |
-| Computación Edge | Failover local; manuales incluyen pasos de recuperación de sincronización a la nube. |
-
-## Referencias ADR
-
-- **ADR-0015**: Procedimientos de failover del broker y rebalanceo de consumidores.
-- **ADR-0079**: Estándares de migración de esquemas y reproducción de DLQ.
-
----
-
-[Volver al Perfil Orientado a Eventos](./README.es.md)

package/rulesets/topologies/event-driven/runbooks.md

@@ -1,79 +0,0 @@
-# Event-Driven — Runbooks Guide
-
-> **Bilingual Navigation:** [English](./runbooks.md) | [Español](./runbooks.es.md)
-
-**Owner:** Architecture Board
-**Topology:** Event-Driven
-
-## Purpose
-
-Provide operational runbooks for common event-driven failure scenarios: broker failover, consumer rebalancing, schema migration, DLQ replay, and ordering violation recovery.
-
-## Runbook 1: Broker Failover
-
-**Trigger:** Broker node becomes unresponsive or cluster health check fails.
-
-1. Verify broker node status via cluster management console.
-2. Confirm partition leader reassignment has completed automatically.
-3. Check consumer group lag for affected topics; alert if lag exceeds threshold.
-4. Validate that producer retries are succeeding on surviving brokers.
-5. Post-recovery: review broker configuration for replication factor and min-insync replicas.
-
-## Runbook 2: Consumer Rebalancing
-
-**Trigger:** Consumer group experiences repeated rebalances or rebalance storm.
-
-1. Identify the rebalance trigger: new consumer join, consumer crash, or heartbeat timeout.
-2. Check consumer instance health: memory, CPU, GC pauses.
-3. Review session.timeout.ms and heartbeat.interval.ms configuration.
-4. If rebalance storm: temporarily reduce consumer instances to stabilize.
-5. Post-recovery: tune timeout settings; consider cooperative sticky assignment strategy.
-
-## Runbook 3: Schema Migration
-
-**Trigger:** Event schema requires a breaking change.
-
-1. Register new schema version in schema registry with compatibility mode set.
-2. Deploy updated consumers that tolerate both old and new schema versions.
-3. Enable dual-write on producers: emit events in both old and new formats.
-4. Monitor consumer error rates during migration window.
-5. After all consumers updated: remove dual-write; deprecate old schema.
-
-## Runbook 4: DLQ Replay — ED-R03
-
-**Trigger:** DLQ depth exceeds threshold or business requires reprocessing.
-
-1. Identify DLQ topic and affected consumer group.
-2. Review DLQ messages: confirm root cause is resolved (e.g., schema fix deployed).
-3. Use DLQ replay tool to republish messages to the original topic.
-4. Monitor consumer processing; confirm messages are consumed successfully.
-5. Post-replay: verify DLQ depth returns to zero; document root cause.
-
-## Runbook 5: Ordering Violation — ED-R04
-
-**Trigger:** Consumer detects events processed out of expected order.
-
-1. Identify affected partition and event sequence.
-2. Check producer partition key distribution; confirm key is stable.
-3. Verify consumer is not processing from multiple partitions concurrently without ordering logic.
-4. If ordering is critical: enforce single-threaded consumption per partition.
-5. Post-recovery: review partition key strategy; consider key redesign if hot partition detected.
-
-## Composable Applicability
-
-| Composable | Guidance |
-|---|---|
-| Modular Monolith | Simplified runbooks; intra-process failover is automatic. |
-| Distributed Modules | Cross-module coordination during failover and rebalancing. |
-| Microservices | Full runbook scope; per-service DLQ and ordering management. |
-| Serverless | Provider-managed failover; runbooks focus on application-level recovery. |
-| Edge Computing | Local failover; runbooks include cloud sync recovery steps. |
-
-## ADR References
-
-- **ADR-0015**: Broker failover and consumer rebalancing procedures.
-- **ADR-0079**: Schema migration and DLQ replay standards.
-
----
-
-[Back to Event-Driven Profile](./README.md)

package/rulesets/topologies/event-driven/security.es.md

@@ -1,59 +0,0 @@
-# Guía de Seguridad Orientada a Eventos
-
-> **Navegación Bilingüe:** [English](./security.md) | [Español](./security.es.md)
-
-**Propietario:** Junta de Arquitectura
-**Topología:** Orientada a Eventos
-
-## Propósito
-
-Establecer controles de seguridad para arquitecturas orientadas a eventos que cubren autenticación de eventos, validación de esquemas en los límites de publicación/suscripción, control de acceso a temas, cifrado de carga útil y requisitos de auditoría de rastro.
-
-## Autenticación de Eventos
-
-- Requerir TLS mutuo (mTLS) entre productores y el broker, y entre el broker y los consumidores.
-- Usar tokens de corta vida (JWT/OAuth2) para autenticación servicio-a-evento donde mTLS no esté disponible.
-- Rotar credenciales automáticamente; enforce duración máxima de token de 1 hora.
-
-## Validación de Esquemas — ED-R01, ED-R06
-
-- Validar cargas útiles de eventos contra el esquema AsyncAPI registrado al momento de publicar.
-- Rechazar eventos no conformes en el broker antes de que ingresen al tema.
-- Mantener un registro de esquemas con historial de versiones; descontinuar esquemas mediante un ciclo de vida formal.
-
-## Control de Acceso a Temas
-
-- Implementar ACLs a nivel de tema: los productores solo pueden escribir en temas autorizados; los consumidores solo pueden suscribirse a temas autorizados.
-- Usar prefijos de namespace (por ejemplo, `dominio.entorno.nombre-evento`) para enforce aislamiento.
-- Auditar cambios de acceso a temas; requerir revisión de pares para escaladas de privilegios.
-
-## Cifrado de Carga Útil
-
-- Cifrar campos sensibles en la capa de aplicación antes de publicar (cifrado a nivel de campo).
-- Usar cifrado nativo del broker en repositorio para almacenamiento de temas.
-- Nunca incrustar secretos o credenciales en texto plano en cargas útiles de eventos.
-
-## Auditoría de Rastro — ED-R08
-
-- Registrar todos los eventos de registro y desregistro de esquemas.
-- Rastrear cambios de ACL de temas con identidad del actor y marca de tiempo.
-- Retener registros de auditoría por un mínimo de 90 días en almacenamiento inmutable.
-
-## Aplicabilidad Componible
-
-| Componible | Orientación |
-|---|---|
-| Monolito Modular | Los eventos intra-proceso pueden omitir mTLS; la validación de esquemas sigue siendo requerida. |
-| Módulos Distribuidos | Enforce completo de mTLS y ACLs entre límites de módulos. |
-| Microservicios | Delimitación de credenciales por servicio; aislamiento de ACLs de temas. |
-| Serverless | Políticas de seguridad de broker gestionadas; vinculación IAM a nivel de función. |
-| Computación Edge | Cifrado de broker local; sincronizar registros de auditoría al almacén central. |
-
-## Referencias ADR
-
-- **ADR-0015**: Modelo de autenticación y autorización del broker de eventos.
-- **ADR-0079**: Estándares de gobernanza y validación de esquemas.
-
----
-
-[Volver al Perfil Orientado a Eventos](./README.es.md)

package/rulesets/topologies/event-driven/security.md

@@ -1,59 +0,0 @@
-# Event-Driven — Security Guide
-
-> **Bilingual Navigation:** [English](./security.md) | [Español](./security.es.md)
-
-**Owner:** Architecture Board
-**Topology:** Event-Driven
-
-## Purpose
-
-Establish security controls for event-driven architectures covering event authentication, schema validation at publish/subscribe boundaries, topic access control, payload encryption, and audit trail requirements.
-
-## Event Authentication
-
-- Require mutual TLS (mTLS) between producers and the broker, and between broker and consumers.
-- Use short-lived tokens (JWT/OAuth2) for service-to-event authentication where mTLS is unavailable.
-- Rotate credentials automatically; enforce maximum token lifetime of 1 hour.
-
-## Schema Validation — ED-R01, ED-R06
-
-- Validate event payloads against the registered AsyncAPI schema at publish time.
-- Reject non-conforming events at the broker before they enter the topic.
-- Maintain a schema registry with version history; deprecate schemas through a formal lifecycle.
-
-## Topic Access Control
-
-- Implement topic-level ACLs: producers may only write to authorized topics; consumers may only subscribe to authorized topics.
-- Use namespace prefixes (e.g., `domain.environment.event-name`) to enforce isolation.
-- Audit topic access changes; require peer review for privilege escalations.
-
-## Payload Encryption
-
-- Encrypt sensitive fields at the application layer before publishing (field-level encryption).
-- Use broker-native encryption at rest for topic storage.
-- Never embed plaintext secrets or credentials in event payloads.
-
-## Audit Trail — ED-R08
-
-- Log all schema registration and deregistration events.
-- Record topic ACL changes with actor identity and timestamp.
-- Retain audit logs for a minimum of 90 days in immutable storage.
-
-## Composable Applicability
-
-| Composable | Guidance |
-|---|---|
-| Modular Monolith | Intra-process events may skip mTLS; schema validation still required. |
-| Distributed Modules | Full mTLS and ACL enforcement across module boundaries. |
-| Microservices | Per-service credential scoping; topic ACL isolation. |
-| Serverless | Managed broker security policies; function-level IAM binding. |
-| Edge Computing | Local broker encryption; sync audit logs to central store. |
-
-## ADR References
-
-- **ADR-0015**: Event broker authentication and authorization model.
-- **ADR-0079**: Schema governance and validation standards.
-
----
-
-[Back to Event-Driven Profile](./README.md)

package/rulesets/topologies/event-driven/topology.config.schema.json

@@ -1,30 +0,0 @@
-{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "title": "Event-Driven Topology Configuration",
-  "type": "object",
-  "additionalProperties": false,
-  "required": [
-    "topology",
-    "strictAsyncApi",
-    "transactionalOutbox",
-    "deadLetterQueue",
-    "hasOrderingGuarantee",
-    "hasIdempotencyKey",
-    "hasBackwardCompatibleSchema",
-    "hasRetentionPolicy",
-    "hasEventCorrelation",
-    "hasConsumerGroupRegistry"
-  ],
-  "properties": {
-    "topology": { "const": "event-driven" },
-    "strictAsyncApi": { "const": true },
-    "transactionalOutbox": { "const": true },
-    "deadLetterQueue": { "const": true },
-    "hasOrderingGuarantee": { "const": true },
-    "hasIdempotencyKey": { "const": true },
-    "hasBackwardCompatibleSchema": { "const": true },
-    "hasRetentionPolicy": { "const": true },
-    "hasEventCorrelation": { "const": true },
-    "hasConsumerGroupRegistry": { "const": true }
-  }
-}

package/rulesets/topologies/event-driven/topology.manifest.json

@@ -1,109 +0,0 @@
-{
-  "apiVersion": "evolith.dev/topology/v1",
-  "kind": "TopologyManifest",
-  "metadata": {
-    "id": "event-driven",
-    "name": "Event-Driven",
-    "dimension": "integration",
-    "status": "accepted",
-    "version": "1.0.0",
-    "governance": {
-      "owner": "Architecture Board",
-      "criticality": "P0"
-    }
-  },
-  "spec": {
-    "summary": "Asynchronous integration topology for explicit event contracts, reliable publication, idempotent consumers, and observable cross-boundary message flow.",
-    "topologyType": "event-driven",
-    "compatibility": {
-      "progressiveAxis": {
-        "phase": "cross",
-        "profile": "cross"
-      },
-      "composableWith": [
-        "modular-monolith",
-        "distributed-modules",
-        "microservices",
-        "serverless",
-        "edge-computing",
-        "data-mesh",
-        "agentic-ai"
-      ]
-    },
-    "artifacts": {
-      "adrs": [
-        "reference/architecture/adrs/core/0015-event-driven-architecture-intra-domain.md",
-        "reference/architecture/adrs/core/0079-multi-topology-reference-corpus.md"
-      ],
-      "rulesets": [
-        "rulesets/topologies/event-driven/event-driven.rules.json"
-      ],
-      "opaPolicies": [
-        "rulesets/topologies/event-driven/event-driven.rego"
-      ],
-      "aiRulesets": [
-        "rulesets/topologies/event-driven/README.md"
-      ],
-      "umsContracts": [
-        "reference/knowledge/demo/ums-reference-model.md"
-      ]
-    },
-    "corpus": {
-      "guidance": {
-        "profile": "rulesets/topologies/event-driven/README.md",
-        "maturityGuide": "rulesets/topologies/event-driven/maturity.md"
-      },
-      "configurationContract": "rulesets/topologies/event-driven/topology.config.schema.json",
-      "fixtures": {
-        "valid": "rulesets/topologies/event-driven/fixtures/valid.topology.config.json",
-        "invalid": "rulesets/topologies/event-driven/fixtures/invalid.topology.config.json"
-      },
-      "nativeEvaluator": "packages/core-domain/src/application/validators/ruleset-validator.service.ts",
-      "tests": {
-        "positive": "packages/core-domain/src/application/validators/ruleset-validator-architecture.spec.ts",
-        "negative": "packages/core-domain/src/application/validators/ruleset-validator-architecture.spec.ts"
-      },
-      "evidence": "reference/governance/standards/vision/maturity-evidence.json"
-    },
-    "operationalInterfaces": {
-      "cli": {
-        "validators": [
-          "validate-architecture",
-          "validate-topology"
-        ]
-      },
-      "mcp": {
-        "resources": [
-          "evolith://topologies/event-driven/manifest",
-          "evolith://topologies/event-driven/rulesets"
-        ],
-        "tools": [
-          "evolith-topology-inspect",
-          "evolith-topology-validate"
-        ],
-        "prompts": [
-          "topology-aware-implementation"
-        ]
-      },
-      "coreApi": {
-        "endpoints": [
-          "GET /topologies/{id}",
-          "GET /topologies/{id}/manifest",
-          "POST /topologies/{id}/validate"
-        ]
-      }
-    }
-  },
-  "businessBoundary": {
-    "technicalOnly": true,
-    "trackerOwns": [
-      "timing",
-      "ownership",
-      "prioritization",
-      "roi",
-      "cost",
-      "budget",
-      "funnel-0"
-    ]
-  }
-}

package/rulesets/topologies/progressive-axis/distributed-modules/distributed-modules.rules.es.json

@@ -1,111 +0,0 @@
-{
-  "$schema": "../../../../schema/ruleset-standard.schema.json",
-  "$id": "https://evolith.dev/rulesets/topologies/progressive-axis/distributed-modules/distributed-modules.rules.es.json",
-  "title": "Reglas de Arquitectura Módulos Distribuidos",
-  "description": "Reglas que gobiernan los límites de módulos formalizados y contratos inter-módulo en el eje progresivo.",
-  "version": "1.0.0",
-  "phase": "distributed-modules",
-  "effectiveDate": "2026-01-01",
-  "rules": [
-    {
-      "id": "DM-R01",
-      "severity": "MUST",
-      "category": "module-autonomy",
-      "title": "El Módulo es Dueño de su Ciclo de Vida",
-      "description": "Cada módulo distribuido DEBE tener su propio cadencia de releases, pipeline de CI/CD y versión. No se requieren releases coordinados entre múltiples módulos.",
-      "rationale": "El versionado independiente de módulos permite que los equipos iteren de forma autónoma. Los releases coordinados reintroducen el acoplamiento del monolito.",
-      "validationQuery": "Cada módulo tiene pipeline de CI dedicado. La versión del módulo no requiere sincronización con otros módulos.",
-      "blocking": true
-    },
-    {
-      "id": "DM-R02",
-      "severity": "MUST",
-      "category": "contract-stability",
-      "title": "Los Contratos Inter-Módulo son Explícitos y Versionados",
-      "description": "Toda comunicación inter-módulo DEBE usar definiciones de contrato explícitas (Protobuf, JSON Schema u OpenAPI). Los contratos están versionados y son retrocompatibles.",
-      "rationale": "Sin contratos explícitos, la evolución de un módulo rompe a los módulos dependientes. core/ADR-0032 exige gRPC para la interoperabilidad interna.",
-      "validationQuery": "Definiciones de contratos en la biblioteca Contracts compartida. Los cambios de ruptura requieren nueva versión mayor. CI valida retrocompatibilidad.",
-      "blocking": true
-    },
-    {
-      "id": "DM-R03",
-      "severity": "MUST",
-      "category": "data-ownership",
-      "title": "Aislamiento de Datos del Módulo Aplicado",
-      "description": "Ningún módulo puede consultar directamente la capa de persistencia de otro módulo. Todo acceso a datos va a través de la interfaz publicada del módulo propietario.",
-      "rationale": "La propiedad de datos es el núcleo de la independencia del contexto acotado. Las consultas directas a la BD entre módulos crean acoplamiento oculto.",
-      "validationQuery": "Sin consultas de base de datos entre módulos en el código. El acceso a datos pasa únicamente por los puertos de la capa Application.",
-      "blocking": true
-    },
-    {
-      "id": "DM-R04",
-      "severity": "MUST",
-      "category": "async-communication",
-      "title": "Los Eventos Asíncronos Tienen Payloads Validados por Esquema",
-      "description": "Todos los eventos asíncronos inter-módulo DEBEN tener definiciones de esquema JSON Schema o Protobuf. La validación de esquema ocurre al publicar y al suscribirse.",
-      "rationale": "Los eventos validados por esquema previenen roturas en consumidores por deriva de esquema del productor. Permite una evolución asíncrona confiable.",
-      "validationQuery": "Todos los tipos de evento tienen definiciones de esquema en la biblioteca Contracts. La validación en el lado consumidor rechaza campos desconocidos.",
-      "blocking": false
-    },
-    {
-      "id": "DM-R05",
-      "severity": "MUST",
-      "category": "observability",
-      "title": "Trazado Distribuido entre Módulos",
-      "description": "Todas las llamadas inter-módulo DEBEN propagar el contexto de traza W3C. Una sola solicitud de usuario que abarca múltiples módulos produce una traza con múltiples spans.",
-      "rationale": "El trazado distribuido es obligatorio para depurar problemas entre módulos. Sin él, el diagnóstico en producción es imposible.",
-      "validationQuery": "El TraceId aparece de forma consistente en todos los logs de módulos para una sola transacción de usuario.",
-      "blocking": true
-    },
-    {
-      "id": "DM-R06",
-      "severity": "MUST",
-      "category": "deployment",
-      "title": "Los Módulos son Desplegables de Forma Independiente",
-      "description": "Cada módulo DEBE poder desplegarse sin coordinar despliegues con otros módulos. Los cambios de contrato retrocompatibles permiten el despliegue simultáneo.",
-      "rationale": "La deployabilidad independiente es el prerrequisito para los microservicios F3. Si se necesita coordinación, el satélite sigue en F1.",
-      "validationQuery": "El pipeline de despliegue de cada módulo es independiente. Ningún módulo tiene un 'bloqueo de despliegue' sobre otro módulo.",
-      "blocking": true
-    },
-    {
-      "id": "DM-R07",
-      "severity": "MUST",
-      "category": "resiliency",
-      "title": "Circuit Breaker para Llamadas Inter-Módulo",
-      "description": "Todas las llamadas sincrónicas inter-módulo DEBEN implementar el patrón circuit breaker (core/ADR-0011). Un fallo de módulo NO DEBE propagarse como fallo al llamador.",
-      "rationale": "Los circuit breakers previenen fallos en cascada entre límites de módulos. Sin ellos, el fallo de un módulo causa una interrupción a nivel de sistema.",
-      "validationQuery": "El circuit breaker está presente en todas las llamadas HTTP/gRPC inter-módulo. El comportamiento de fallback está definido para cada llamada.",
-      "blocking": false
-    },
-    {
-      "id": "DM-R08",
-      "severity": "MUST",
-      "category": "extraction-readiness",
-      "title": "Mantener Puntuación de Preparación F2 para Extracción",
-      "description": "El satélite DEBE registrar la preparación para extracción según core/ADR-0045 con criterios específicos de F3. La puntuación DEBE ser >= 80% para superar el gate de Diseño Fase 2 cuando F3 está planificado.",
-      "rationale": "La extracción F3 requiere mayor madurez: deployabilidad independiente, circuit breakers, trazado distribuido y contratos explícitos deben estar todos en su lugar.",
-      "validationQuery": "Puntuación de preparación para extracción F3 documentada y >= 80%. Todas las reglas de Módulos Distribuidos en verde.",
-      "blocking": false
-    }
-  ],
-  "f3Prerequisites": {
-    "minScore": 80,
-    "requiredRules": [
-      "DM-R01",
-      "DM-R02",
-      "DM-R03",
-      "DM-R05",
-      "DM-R06"
-    ],
-    "reference": "adr/0045-microservice-extraction-readiness-criteria.md"
-  },
-  "exitGate": {
-    "description": "Módulos Distribuidos sale cuando la puntuación de preparación para extracción F3 es >= 80% Y el consejo de arquitectura aprueba la transición a F3.",
-    "requiredArtifacts": [
-      "Evaluación de preparación F3 de core/ADR-0045 (>= 80%)",
-      "Registro de contratos con historial de versiones",
-      "Documentación de circuit breaker por módulo",
-      "Evidencia de despliegue independiente"
-    ]
-  }
-}