@evolith/core-domain 1.0.1 → 1.0.3

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

@@ -1,111 +0,0 @@
-{
-  "$schema": "../../../../schema/ruleset-standard.schema.json",
-  "$id": "https://evolith.dev/rulesets/topologies/progressive-axis/distributed-modules/distributed-modules.rules.json",
-  "title": "Distributed Modules Architecture Rules",
-  "description": "Rules governing the distributed modules phase. Module boundaries are formalized; inter-module contracts are explicit and versioned.",
-  "version": "1.0.0",
-  "phase": "distributed-modules",
-  "effectiveDate": "2026-01-01",
-  "rules": [
-    {
-      "id": "DM-R01",
-      "severity": "MUST",
-      "category": "module-autonomy",
-      "title": "Module Owns Its Lifecycle",
-      "description": "Each distributed module MUST have its own release cadence, CI/CD pipeline, and version. No coordinated multi-module releases required.",
-      "rationale": "Independent module versioning enables teams to iterate autonomously. Coordinated releases reintroduce monolith coupling.",
-      "validationQuery": "Each module has dedicated CI pipeline. Module version does not require synchronization with other modules.",
-      "blocking": true
-    },
-    {
-      "id": "DM-R02",
-      "severity": "MUST",
-      "category": "contract-stability",
-      "title": "Inter-Module Contracts are Explicit and Versioned",
-      "description": "All inter-module communication MUST use explicit contract definitions (Protobuf, JSON Schema, or OpenAPI). Contracts are versioned and backward-compatible.",
-      "rationale": "Without explicit contracts, module evolution breaks dependent modules. core/ADR-0032 mandates gRPC for internal inter-op.",
-      "validationQuery": "Contract definitions in shared Contracts library. Breaking changes require new major version. CI validates backward compatibility.",
-      "blocking": true
-    },
-    {
-      "id": "DM-R03",
-      "severity": "MUST",
-      "category": "data-ownership",
-      "title": "Module Data Isolation Enforced",
-      "description": "No module can directly query another module's persistence layer. All data access goes through the owning module's published interface.",
-      "rationale": "Data ownership is the core of bounded context independence. Direct cross-module DB queries create hidden coupling.",
-      "validationQuery": "No cross-module database queries in codebase. Data access goes through Application-layer ports only.",
-      "blocking": true
-    },
-    {
-      "id": "DM-R04",
-      "severity": "MUST",
-      "category": "async-communication",
-      "title": "Async Events Have Schema-Validated Payloads",
-      "description": "All asynchronous inter-module events MUST have JSON Schema or Protobuf schema definitions. Schema validation happens at publish and subscribe.",
-      "rationale": "Schema-validated events prevent consumer breakage from producer schema drift. Enables reliable async evolution.",
-      "validationQuery": "All event types have schema definitions in Contracts library. Consumer-side validation rejects unknown fields.",
-      "blocking": false
-    },
-    {
-      "id": "DM-R05",
-      "severity": "MUST",
-      "category": "observability",
-      "title": "Distributed Tracing Across Modules",
-      "description": "All inter-module calls MUST propagate W3C trace context. A single user request that spans multiple modules produces one trace with multiple spans.",
-      "rationale": "Distributed tracing is mandatory for debugging cross-module issues. Without it, diagnosis is impossible in production.",
-      "validationQuery": "TraceId appears consistently across all module logs for a single user transaction.",
-      "blocking": true
-    },
-    {
-      "id": "DM-R06",
-      "severity": "MUST",
-      "category": "deployment",
-      "title": "Modules Deployable Independently",
-      "description": "Each module MUST be deployable without coordinating deployments with other modules. Backward-compatible contract changes allow simultaneous deployment.",
-      "rationale": "Independent deployability is the prerequisite for F3 microservices. If coordination is needed, the satellite is still in F1.",
-      "validationQuery": "Deployment pipeline for each module is independent. No module has a 'deployment lock' on another module.",
-      "blocking": true
-    },
-    {
-      "id": "DM-R07",
-      "severity": "MUST",
-      "category": "resiliency",
-      "title": "Circuit Breaker for Inter-Module Calls",
-      "description": "All synchronous inter-module calls MUST implement circuit breaker pattern (core/ADR-0011). A module failure MUST NOT cascade to caller failure.",
-      "rationale": "Circuit breakers prevent cascade failures across module boundaries. Without them, one module failure causes system-wide outage.",
-      "validationQuery": "Circuit breaker is present in all inter-module HTTP/gRPC calls. Fallback behavior is defined for each call.",
-      "blocking": false
-    },
-    {
-      "id": "DM-R08",
-      "severity": "MUST",
-      "category": "extraction-readiness",
-      "title": "Maintain F2 Extraction Score",
-      "description": "Satellite MUST track extraction readiness per core/ADR-0045 with F3-specific criteria. Score MUST be >= 80% to pass Phase 2 Design gate when F3 is planned.",
-      "rationale": "F3 extraction requires higher maturity: independent deployability, circuit breakers, distributed tracing, and explicit contracts must all be in place.",
-      "validationQuery": "F3 extraction readiness score documented and >= 80%. All Distributed Modules rules green.",
-      "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": "Distributed Modules exits when F3 extraction readiness score >= 80% AND architecture board approves F3 transition.",
-    "requiredArtifacts": [
-      "core/ADR-0045 F3 readiness assessment (>= 80%)",
-      "Contract registry with version history",
-      "Circuit breaker documentation per module",
-      "Independent deployment evidence"
-    ]
-  }
-}

package/rulesets/topologies/progressive-axis/microservices/microservices.rules.es.json

@@ -1,106 +0,0 @@
-{
-  "$schema": "../../../../schema/ruleset-standard.schema.json",
-  "$id": "https://evolith.dev/rulesets/topologies/progressive-axis/microservices/microservices.rules.es.json",
-  "title": "Reglas de Arquitectura Microservicios",
-  "description": "Reglas que gobiernan el despliegue autónomo y la malla de servicios en el eje progresivo.",
-  "version": "1.0.0",
-  "phase": "microservices",
-  "effectiveDate": "2026-01-01",
-  "rules": [
-    {
-      "id": "MS-R01",
-      "severity": "MUST",
-      "category": "autonomous-deployment",
-      "title": "True Independent Deployability",
-      "description": "Each service MUST deploy independently with no coordination required with any other service. Contract-first approach ensures backward compatibility.",
-      "rationale": "Microservices exists only when services can truly evolve independently. Coordinated deployments indicate premature Microservices adoption.",
-      "validationQuery": "Each service has independent CI/CD. No service has a deployment dependency on another service's release schedule.",
-      "blocking": true
-    },
-    {
-      "id": "MS-R02",
-      "severity": "MUST",
-      "category": "service-mesh",
-      "title": "Service Mesh Readiness",
-      "description": "All services MUST be deployed behind a service mesh (Istio, Linkerd, or equivalent) or equivalent sidecar infrastructure. mTLS MUST be enforced for all in-cluster communication.",
-      "rationale": "Service mesh provides observability, traffic management, and security at the infrastructure level. core/ADR-0013 covers cloud topology and DR.",
-      "validationQuery": "Service-to-service communication uses mTLS. Service mesh provides routing, retries, and circuit breaking.",
-      "blocking": true
-    },
-    {
-      "id": "MS-R03",
-      "severity": "MUST",
-      "category": "failure-isolation",
-      "title": "Bulkhead Pattern per Service",
-      "description": "Each service MUST implement bulkhead isolation: resource pools (connections, threads) are isolated per upstream dependency.",
-      "rationale": "Bulkheads prevent a single upstream failure from consuming all resources and causing cascading failures.",
-      "validationQuery": "Each service has dedicated connection pools per upstream dependency. One upstream timeout does not exhaust shared pool.",
-      "blocking": false
-    },
-    {
-      "id": "MS-R04",
-      "severity": "MUST",
-      "category": "graceful-degradation",
-      "title": "Fallback Behavior for All External Calls",
-      "description": "All inter-service calls MUST have defined fallback behavior when the downstream service is unavailable. Graceful degradation is required.",
-      "rationale": "Microservices services must remain functional even when other services are degraded. No hard failure propagation to end user.",
-      "validationQuery": "All downstream calls have fallback: cached response, default value, or degraded mode. E2E tests validate fallback paths.",
-      "blocking": false
-    },
-    {
-      "id": "MS-R05",
-      "severity": "MUST",
-      "category": "contract-testing",
-      "title": "Contract Tests for All Inter-Service Contracts",
-      "description": "All inter-service contracts (synchronous gRPC/REST and asynchronous events) MUST have contract tests (Pact or equivalent) that validate backward compatibility before merge.",
-      "rationale": "Contract tests prevent breaking changes from reaching production. Consumer-driven contract testing is the gold standard.",
-      "validationQuery": "Contract tests exist for all inter-service contracts. CI fails on breaking contract changes.",
-      "blocking": true
-    },
-    {
-      "id": "MS-R06",
-      "severity": "MUST",
-      "category": "data-sovereignty",
-      "title": "Service Owns Its Data — No Shared Persistence",
-      "description": "Each service owns its data store exclusively. No shared databases, no cross-service table access, no data leakage through APIs.",
-      "rationale": "Data sovereignty is the foundation of service independence. Shared persistence creates hidden coupling that defeats F3.",
-      "validationQuery": "Each service has isolated persistence. No cross-service database queries. Data access only through published API.",
-      "blocking": true
-    },
-    {
-      "id": "MS-R07",
-      "severity": "MUST",
-      "category": "observability",
-      "title": "Service-Level Observability with SLOs",
-      "description": "Each service MUST define and monitor its SLOs (Service Level Objectives). Error budget tracking is required. Dashboard per service is mandatory.",
-      "rationale": "SLOs provide objective health metrics per service. Without them, there's no data-driven basis for reliability decisions.",
-      "validationQuery": "SLO dashboard per service. Error budget tracking active. Alerts fire when SLO is at risk.",
-      "blocking": false
-    },
-    {
-      "id": "MS-R08",
-      "severity": "MUST",
-      "category": "on-call",
-      "title": "Service-Level On-Call Ownership",
-      "description": "Each service MUST have a designated on-call owner. Runbooks exist for all common failure scenarios. Incident response time <= 15 minutes.",
-      "rationale": "Microservices requires service-level ownership. Shared on-call across all services loses the independence benefit.",
-      "validationQuery": "On-call roster per service exists. Runbooks documented and tested.",
-      "blocking": false
-    }
-  ],
-  "stabilityRequirements": {
-    "minDeploymentFrequency": "Daily",
-    "minMTTR": "15 minutes",
-    "minChangeFailureRate": "< 15%",
-    "reference": "adr/0013-cloud-infrastructure-topology-dr.md"
-  },
-  "exitGate": {
-    "description": "Microservices does not exit. Microservices is the terminal architecture phase. Any further evolution requires new architectural decision via ADR.",
-    "requiredArtifacts": [
-      "Service catalog with ownership",
-      "Contract registry with contract tests",
-      "SLO dashboards per service",
-      "Service mesh deployment evidence"
-    ]
-  }
-}

package/rulesets/topologies/progressive-axis/microservices/microservices.rules.json

@@ -1,106 +0,0 @@
-{
-  "$schema": "../../../../schema/ruleset-standard.schema.json",
-  "$id": "https://evolith.dev/rulesets/topologies/progressive-axis/microservices/microservices.rules.json",
-  "title": "Microservices Architecture Rules",
-  "description": "Rules governing the microservices phase. Autonomous deployability is the core principle. Service mesh readiness is mandatory.",
-  "version": "1.0.0",
-  "phase": "microservices",
-  "effectiveDate": "2026-01-01",
-  "rules": [
-    {
-      "id": "MS-R01",
-      "severity": "MUST",
-      "category": "autonomous-deployment",
-      "title": "True Independent Deployability",
-      "description": "Each service MUST deploy independently with no coordination required with any other service. Contract-first approach ensures backward compatibility.",
-      "rationale": "Microservices exists only when services can truly evolve independently. Coordinated deployments indicate premature Microservices adoption.",
-      "validationQuery": "Each service has independent CI/CD. No service has a deployment dependency on another service's release schedule.",
-      "blocking": true
-    },
-    {
-      "id": "MS-R02",
-      "severity": "MUST",
-      "category": "service-mesh",
-      "title": "Service Mesh Readiness",
-      "description": "All services MUST be deployed behind a service mesh (Istio, Linkerd, or equivalent) or equivalent sidecar infrastructure. mTLS MUST be enforced for all in-cluster communication.",
-      "rationale": "Service mesh provides observability, traffic management, and security at the infrastructure level. core/ADR-0013 covers cloud topology and DR.",
-      "validationQuery": "Service-to-service communication uses mTLS. Service mesh provides routing, retries, and circuit breaking.",
-      "blocking": true
-    },
-    {
-      "id": "MS-R03",
-      "severity": "MUST",
-      "category": "failure-isolation",
-      "title": "Bulkhead Pattern per Service",
-      "description": "Each service MUST implement bulkhead isolation: resource pools (connections, threads) are isolated per upstream dependency.",
-      "rationale": "Bulkheads prevent a single upstream failure from consuming all resources and causing cascading failures.",
-      "validationQuery": "Each service has dedicated connection pools per upstream dependency. One upstream timeout does not exhaust shared pool.",
-      "blocking": false
-    },
-    {
-      "id": "MS-R04",
-      "severity": "MUST",
-      "category": "graceful-degradation",
-      "title": "Fallback Behavior for All External Calls",
-      "description": "All inter-service calls MUST have defined fallback behavior when the downstream service is unavailable. Graceful degradation is required.",
-      "rationale": "Microservices services must remain functional even when other services are degraded. No hard failure propagation to end user.",
-      "validationQuery": "All downstream calls have fallback: cached response, default value, or degraded mode. E2E tests validate fallback paths.",
-      "blocking": false
-    },
-    {
-      "id": "MS-R05",
-      "severity": "MUST",
-      "category": "contract-testing",
-      "title": "Contract Tests for All Inter-Service Contracts",
-      "description": "All inter-service contracts (synchronous gRPC/REST and asynchronous events) MUST have contract tests (Pact or equivalent) that validate backward compatibility before merge.",
-      "rationale": "Contract tests prevent breaking changes from reaching production. Consumer-driven contract testing is the gold standard.",
-      "validationQuery": "Contract tests exist for all inter-service contracts. CI fails on breaking contract changes.",
-      "blocking": true
-    },
-    {
-      "id": "MS-R06",
-      "severity": "MUST",
-      "category": "data-sovereignty",
-      "title": "Service Owns Its Data — No Shared Persistence",
-      "description": "Each service owns its data store exclusively. No shared databases, no cross-service table access, no data leakage through APIs.",
-      "rationale": "Data sovereignty is the foundation of service independence. Shared persistence creates hidden coupling that defeats F3.",
-      "validationQuery": "Each service has isolated persistence. No cross-service database queries. Data access only through published API.",
-      "blocking": true
-    },
-    {
-      "id": "MS-R07",
-      "severity": "MUST",
-      "category": "observability",
-      "title": "Service-Level Observability with SLOs",
-      "description": "Each service MUST define and monitor its SLOs (Service Level Objectives). Error budget tracking is required. Dashboard per service is mandatory.",
-      "rationale": "SLOs provide objective health metrics per service. Without them, there's no data-driven basis for reliability decisions.",
-      "validationQuery": "SLO dashboard per service. Error budget tracking active. Alerts fire when SLO is at risk.",
-      "blocking": false
-    },
-    {
-      "id": "MS-R08",
-      "severity": "MUST",
-      "category": "on-call",
-      "title": "Service-Level On-Call Ownership",
-      "description": "Each service MUST have a designated on-call owner. Runbooks exist for all common failure scenarios. Incident response time <= 15 minutes.",
-      "rationale": "Microservices requires service-level ownership. Shared on-call across all services loses the independence benefit.",
-      "validationQuery": "On-call roster per service exists. Runbooks documented and tested.",
-      "blocking": false
-    }
-  ],
-  "stabilityRequirements": {
-    "minDeploymentFrequency": "Daily",
-    "minMTTR": "15 minutes",
-    "minChangeFailureRate": "< 15%",
-    "reference": "adr/0013-cloud-infrastructure-topology-dr.md"
-  },
-  "exitGate": {
-    "description": "Microservices does not exit. Microservices is the terminal architecture phase. Any further evolution requires new architectural decision via ADR.",
-    "requiredArtifacts": [
-      "Service catalog with ownership",
-      "Contract registry with contract tests",
-      "SLO dashboards per service",
-      "Service mesh deployment evidence"
-    ]
-  }
-}

package/rulesets/topologies/progressive-axis/modular-monolith/modular-monolith.rules.es.json

@@ -1,148 +0,0 @@
-{
-  "$schema": "../../../../schema/ruleset-standard.schema.json",
-  "$id": "https://evolith.dev/rulesets/topologies/progressive-axis/modular-monolith/modular-monolith.rules.es.json",
-  "title": "Reglas de Arquitectura Monolito Modular",
-  "description": "Reglas que gobiernan la topología de inicio obligatoria para todos los satélites Evolith.",
-  "version": "1.0.0",
-  "phase": "modular-monolith",
-  "effectiveDate": "2026-01-01",
-  "rules": [
-    {
-      "id": "MM-R01",
-      "severity": "MUST",
-      "category": "topology",
-      "title": "Unidad de Despliegue Única",
-      "description": "Todos los contextos delimitados DEBEN desplegarse como un único artefacto (monolito). No se permite el despliegue autónomo de módulos individuales.",
-      "rationale": "core/ADR-0047 establece el monolito modular como topología de inicio canónica. La extracción prematura introduce complejidad operacional sin drivers de escalabilidad probados.",
-      "validationQuery": "Verificar que todos los módulos compilen en un único assembly/imagen de contenedor. Sin pipelines de despliegue independientes por módulo.",
-      "blocking": true
-    },
-    {
-      "id": "MM-R02",
-      "severity": "MUST",
-      "category": "bounded-contexts",
-      "title": "Límites Explícitos de Contextos Delimitados",
-      "description": "Cada contexto delimitado DEBE implementarse como un módulo claramente separado con su propio namespace/paquete y sin base de datos compartida en tiempo de ejecución.",
-      "rationale": "core/ADR-0031 (Schema-por-Contexto) requiere que cada contexto delimitado sea propietario de su esquema. Las bases de datos compartidas en tiempo de ejecución generan acoplamiento implícito.",
-      "validationQuery": "Cada contexto delimitado tiene persistencia aislada (BD/esquema separado). Sin acceso directo entre tablas de distintos contextos.",
-      "blocking": true
-    },
-    {
-      "id": "MM-R03",
-      "severity": "MUST",
-      "category": "hexagonal-architecture",
-      "title": "Límite de Puertos y Adaptadores",
-      "description": "Todos los contextos delimitados DEBEN implementar arquitectura hexagonal (core/ADR-0002). La capa de dominio no tiene dependencias externas. Los adaptadores de infraestructura se inyectan mediante puertos.",
-      "rationale": "La arquitectura hexagonal permite la extracción futura desacoplando la lógica de dominio de las preocupaciones de infraestructura.",
-      "validationQuery": "La capa de dominio no tiene importaciones de Infraestructura. Los adaptadores implementan interfaces de puerto definidas en la capa de Aplicación.",
-      "blocking": true
-    },
-    {
-      "id": "MM-R04",
-      "severity": "MUST",
-      "category": "communication",
-      "title": "Comunicación Entre Contextos a Través de Puertos",
-      "description": "La comunicación entre contextos delimitados DEBE usar interfaces de puerto explícitas de la capa de aplicación. No se permiten llamadas directas entre infraestructuras.",
-      "rationale": "Refuerza la dirección limpia de dependencias. Los cambios en un contexto no rompen directamente otro contexto.",
-      "validationQuery": "Sin importaciones entre contextos en la capa de Infraestructura. Todas las llamadas entre contextos pasan por puertos de Aplicación.",
-      "blocking": true
-    },
-    {
-      "id": "MM-R05",
-      "severity": "MUST",
-      "category": "persistence",
-      "title": "Sin Base de Datos Compartida Entre Contextos Delimitados",
-      "description": "Cada contexto delimitado DEBE tener su propio esquema de base de datos o instancia de base de datos. La base de datos compartida está prohibida.",
-      "rationale": "core/ADR-0031 impone la propiedad de esquema por contexto. La base de datos compartida impide la evolución independiente de los contextos.",
-      "validationQuery": "Cada contexto delimitado se mapea a un esquema separado (separación de esquemas PostgreSQL) o instancia de base de datos separada.",
-      "blocking": true
-    },
-    {
-      "id": "MM-R06",
-      "severity": "MUST",
-      "category": "async-boundaries",
-      "title": "Eventos Asíncronos Usan Eventos de Dominio",
-      "description": "Cuando los contextos delimitados emiten eventos para reacción asíncrona, DEBEN usar eventos de dominio con contratos de evento explícitos (core/ADR-0015). No se permite el sondeo implícito de tablas ni la manipulación directa de colas.",
-      "rationale": "Los eventos de dominio imponen límites de contrato explícitos y hacen auditables las reacciones entre contextos.",
-      "validationQuery": "Las reacciones basadas en eventos se suscriben a tipos de eventos de dominio, no a flujos de cambios de base de datos.",
-      "blocking": false
-    },
-    {
-      "id": "MM-R07",
-      "severity": "MUST",
-      "category": "extraction-readiness",
-      "title": "Mantener Puntuación de Preparación para Extracción",
-      "description": "El satélite DEBE rastrear y mantener la puntuación de preparación para extracción según core/ADR-0045. La puntuación DEBE ser >= 70% para pasar la puerta de Diseño de Fase 2 cuando F2 está planificado.",
-      "rationale": "core/ADR-0045 define criterios de preparación concretos. Medir continuamente previene la acumulación de deuda técnica.",
-      "validationQuery": "Evaluación de preparación para extracción documentada y actualizada en cada transición de fase. Puntuación >= 70% para la transición F2.",
-      "blocking": false
-    },
-    {
-      "id": "MM-R08",
-      "severity": "MUST",
-      "category": "observability",
-      "title": "Instrumentación de Observabilidad",
-      "description": "Todos los contextos delimitados DEBEN emitir trazas OTel con CorrelationId, TraceId y SpanId según nodejs/ADR-0007. Los logs DEBEN incluir SessionTrackingId estructurado.",
-      "rationale": "La preparación para producción requiere observabilidad desde el primer día. dotnet/ADR-0064 define la propagación de contexto .NET; nodejs/ADR-0007 cubre Node.js.",
-      "validationQuery": "Todos los endpoints de API producen trazas con etiqueta de contexto delimitado. Los logs incluyen el ámbito SessionTrackingId.",
-      "blocking": false
-    },
-    {
-      "id": "MM-R09",
-      "severity": "MUST",
-      "category": "dependency-injection",
-      "title": "Principio Estricto de Inversión de Dependencias (DIP)",
-      "description": "Los servicios de Aplicación y Dominio NO DEBEN instanciarse manualmente mediante la palabra clave 'new' dentro de otros servicios o controladores. Las dependencias DEBEN inyectarse mediante constructor usando un contenedor DI.",
-      "rationale": "La instanciación manual acopla estrechamente las clases a implementaciones específicas, violando DIP e impidiendo las pruebas unitarias efectivas y el desacoplamiento arquitectónico futuro.",
-      "validationQuery": "Verificar AST para expresiones 'new' que instancien servicios de dominio/aplicación dentro de otros servicios/controladores. Se esperan 0 ocurrencias.",
-      "blocking": true
-    },
-    {
-      "id": "MM-R10",
-      "severity": "MUST",
-      "category": "static-analysis",
-      "title": "Análisis de Código Basado en AST Obligatorio",
-      "description": "El análisis estático de código, las comprobaciones de conformidad arquitectónica y la refactorización automatizada DEBEN usar análisis de Árbol de Sintaxis Abstracta (AST). Las Expresiones Regulares (Regex) para el análisis estructural de código están prohibidas.",
-      "rationale": "Regex es frágil para el análisis de código y no puede entender de forma fiable el contexto, el anidamiento o las variaciones de sintaxis. AST proporciona una representación estructural precisa.",
-      "validationQuery": "Escanear scripts de validación de arquitectura en busca de patrones regex estructurales dirigidos al código fuente en lugar de uso de parser AST.",
-      "blocking": true
-    },
-    {
-      "id": "MM-R11",
-      "severity": "MUST",
-      "category": "separation-of-concerns",
-      "title": "Aislamiento Estricto de UI y Lógica (SoC)",
-      "description": "La lógica de UI interactiva (p. ej., prompts de CLI, extracción de solicitudes HTTP) NO DEBE filtrarse en los Casos de Uso de Aplicación o la lógica de Dominio. El límite de Puertos y Adaptadores DEBE respetarse.",
-      "rationale": "Filtrar preocupaciones de UI en la lógica de aplicación impide reutilizar la misma lógica en diferentes interfaces (p. ej., CLI vs MCP vs HTTP) y dificulta las pruebas automatizadas.",
-      "validationQuery": "Verificar que las capas de Aplicación/Dominio no tienen importaciones de bibliotecas UI/CLI (p. ej., '@clack/prompts', 'inquirer', 'express').",
-      "blocking": true
-    },
-    {
-      "id": "MM-R12",
-      "severity": "SHOULD",
-      "category": "domain-purity",
-      "title": "Modelo de Dominio Puro (Aplicación del Patrón Data Mapper)",
-      "description": "Las entidades de dominio NO DEBERÍAN referenciar frameworks de persistencia. Usar el patrón Data Mapper para mantener el modelo de dominio puro e independiente de la persistencia.",
-      "rationale": "Las anotaciones de persistencia en entidades de dominio crean acoplamiento a la infraestructura y violan la arquitectura hexagonal (core/ADR-0002). Data Mapper preserva la pureza del dominio.",
-      "validationQuery": "Escaneo AST de anotaciones relacionadas con persistencia (p. ej., @Entity, @Table, [Column]) en archivos de la capa de dominio. Se esperan 0 ocurrencias.",
-      "blocking": false
-    }
-  ],
-  "extractionCriteria": {
-    "minScore": 70,
-    "requiredADRs": [
-      "core/ADR-0045",
-      "core/ADR-0047"
-    ],
-    "reference": "adr/0045-microservice-extraction-readiness-criteria.md"
-  },
-  "exitGate": {
-    "description": "El Monolito Modular sale cuando la puntuación de preparación para extracción es >= 70% Y el comité de arquitectura aprueba la transición F2.",
-    "requiredArtifacts": [
-      "Evaluación de core/ADR-0045 (puntuación actual)",
-      "Confirmación de core/ADR-0047 (topología aún válida)",
-      "Mapa de contextos delimitados con propietarios",
-      "Registro de contratos entre contextos"
-    ]
-  }
-}

package/rulesets/topologies/progressive-axis/modular-monolith/modular-monolith.rules.json

@@ -1,148 +0,0 @@
-{
-  "$schema": "../../../../schema/ruleset-standard.schema.json",
-  "$id": "https://evolith.dev/rulesets/topologies/progressive-axis/modular-monolith/modular-monolith.rules.json",
-  "title": "Modular Monolith Architecture Rules",
-  "description": "Rules governing the mandatory starting topology for all Evolith satellites. Modular Monolith is the only permitted entry point unless extraction criteria are already satisfied.",
-  "version": "1.0.0",
-  "phase": "modular-monolith",
-  "effectiveDate": "2026-01-01",
-  "rules": [
-    {
-      "id": "MM-R01",
-      "severity": "MUST",
-      "category": "topology",
-      "title": "Single Deployment Unit",
-      "description": "All bounded contexts MUST be deployed as a single artifact (monolith). No autonomous deployment of individual modules is permitted.",
-      "rationale": "core/ADR-0047 mandates modular monolith as the canonical starting topology. Premature extraction introduces operational complexity without proven scalability drivers.",
-      "validationQuery": "Verify all modules compile into a single assembly/container image. No independent module deployment pipelines.",
-      "blocking": true
-    },
-    {
-      "id": "MM-R02",
-      "severity": "MUST",
-      "category": "bounded-contexts",
-      "title": "Explicit Bounded Context Boundaries",
-      "description": "Each bounded context MUST be implemented as a clearly separated module with its own namespace/package and zero runtimeshared database.",
-      "rationale": "core/ADR-0031 (Schema-per-Context) requires each bounded context to own its schema. Runtime shared databases create implicit coupling.",
-      "validationQuery": "Each bounded context has isolated persistence (separate DB/schema). No cross-context direct table access.",
-      "blocking": true
-    },
-    {
-      "id": "MM-R03",
-      "severity": "MUST",
-      "category": "hexagonal-architecture",
-      "title": "Ports and Adapters Boundary",
-      "description": "All bounded contexts MUST implement hexagonal architecture (core/ADR-0002). Domain layer has zero external dependencies. Infrastructure adapters are injected via ports.",
-      "rationale": "Hexagonal architecture enables future extraction by decoupling domain logic from infrastructure concerns.",
-      "validationQuery": "Domain layer has no imports from Infrastructure. Adapters implement port interfaces defined in Application layer.",
-      "blocking": true
-    },
-    {
-      "id": "MM-R04",
-      "severity": "MUST",
-      "category": "communication",
-      "title": "Inter-Context Communication via Ports",
-      "description": "Cross-bounded-context communication MUST use explicit application-layer port interfaces. No direct infrastructure-to-infrastructure calls.",
-      "rationale": "Enforces clean dependency direction. Changes in one context do not directly break another context.",
-      "validationQuery": "No cross-context imports at the Infrastructure layer. All inter-context calls go through Application ports.",
-      "blocking": true
-    },
-    {
-      "id": "MM-R05",
-      "severity": "MUST",
-      "category": "persistence",
-      "title": "No Shared Database Across Bounded Contexts",
-      "description": "Each bounded context MUST have its own database schema or database instance. Shared database is prohibited.",
-      "rationale": "core/ADR-0031 enforces schema-per-context ownership. Shared database prevents independent evolution of contexts.",
-      "validationQuery": "Each bounded context maps to a separate schema (PostgreSQL schema separation) or separate database instance.",
-      "blocking": true
-    },
-    {
-      "id": "MM-R06",
-      "severity": "MUST",
-      "category": "async-boundaries",
-      "title": "Async Events Use Domain Events",
-      "description": "When bounded contexts emit events for async reaction, they MUST use domain events with explicit event contracts (core/ADR-0015). No implicit table-polling or direct queue manipulation.",
-      "rationale": "Domain events enforce explicit contract boundaries and make cross-context reactions auditable.",
-      "validationQuery": "Event-driven reactions subscribe to domain event types, not database change streams.",
-      "blocking": false
-    },
-    {
-      "id": "MM-R07",
-      "severity": "MUST",
-      "category": "extraction-readiness",
-      "title": "Maintain Extraction Readiness Score",
-      "description": "Satellite MUST track and maintain extraction readiness score per core/ADR-0045. Score MUST be >= 70% to pass Phase 2 Design gate when F2 is planned.",
-      "rationale": "core/ADR-0045 defines concrete readiness criteria. Measuring continuously prevents technical debt accumulation.",
-      "validationQuery": "Extraction readiness assessment documented and updated at each phase transition. Score >= 70% for F2 transition.",
-      "blocking": false
-    },
-    {
-      "id": "MM-R08",
-      "severity": "MUST",
-      "category": "observability",
-      "title": "Observability Instrumentation",
-      "description": "All bounded contexts MUST emit OTel traces with CorrelationId, TraceId, and SpanId per nodejs/ADR-0007. Logs MUST include structured SessionTrackingId.",
-      "rationale": "Production readiness requires observability from day one. dotnet/ADR-0064 defines .NET context propagation; nodejs/ADR-0007 covers Node.js.",
-      "validationQuery": "All API endpoints produce traces with bounded context tag. Logs include SessionTrackingId scope.",
-      "blocking": false
-    },
-    {
-      "id": "MM-R09",
-      "severity": "MUST",
-      "category": "dependency-injection",
-      "title": "Strict Dependency Inversion Principle (DIP)",
-      "description": "Application and Domain services MUST NOT be instantiated manually via 'new' keywords within other services or controllers. Dependencies MUST be injected via constructor using a DI container.",
-      "rationale": "Manual instantiation tightly couples classes to specific implementations, violating DIP and preventing effective unit testing and future architectural decoupling.",
-      "validationQuery": "Verify AST for 'new' expressions instantiating domain/application services within other services/controllers. Expected 0 occurrences.",
-      "blocking": true
-    },
-    {
-      "id": "MM-R10",
-      "severity": "MUST",
-      "category": "static-analysis",
-      "title": "AST-Based Code Analysis Mandatory",
-      "description": "Static code analysis, architecture compliance checks, and automated refactoring MUST use Abstract Syntax Tree (AST) parsing. Regular Expressions (Regex) for structural code parsing are prohibited.",
-      "rationale": "Regex is fragile for code parsing and cannot reliably understand context, nesting, or syntax variations. AST provides accurate structural representation.",
-      "validationQuery": "Scan architecture validation scripts for structural regex patterns targeting source code instead of AST parser usage.",
-      "blocking": true
-    },
-    {
-      "id": "MM-R11",
-      "severity": "MUST",
-      "category": "separation-of-concerns",
-      "title": "Strict UI and Logic Isolation (SoC)",
-      "description": "Interactive UI logic (e.g., CLI prompts, HTTP request extraction) MUST NOT leak into Application Use Cases or Domain logic. The Ports & Adapters boundary MUST be respected.",
-      "rationale": "Leaking UI concerns into application logic prevents reusing the same logic across different interfaces (e.g., CLI vs MCP vs HTTP) and makes automated testing difficult.",
-      "validationQuery": "Verify Application/Domain layers have zero imports from UI/CLI libraries (e.g., '@clack/prompts', 'inquirer', 'express').",
-      "blocking": true
-    },
-    {
-      "id": "MM-R12",
-      "severity": "SHOULD",
-      "category": "domain-purity",
-      "title": "Pure Domain Model (Data Mapper Enforcement)",
-      "description": "Domain entities SHOULD NOT reference persistence frameworks. Use Data Mapper pattern to keep domain model pure and persistence-agnostic.",
-      "rationale": "Persistence annotations in domain entities create coupling to infrastructure and violate hexagonal architecture (core/ADR-0002). Data Mapper preserves domain purity.",
-      "validationQuery": "AST scan for persistence-related annotations (e.g., @Entity, @Table, [Column]) in domain-layer files. Expected 0 occurrences.",
-      "blocking": false
-    }
-  ],
-  "extractionCriteria": {
-    "minScore": 70,
-    "requiredADRs": [
-      "core/ADR-0045",
-      "core/ADR-0047"
-    ],
-    "reference": "adr/0045-microservice-extraction-readiness-criteria.md"
-  },
-  "exitGate": {
-    "description": "Modular Monolith exits when extraction readiness score >= 70% AND architecture board approves F2 transition.",
-    "requiredArtifacts": [
-      "core/ADR-0045 assessment (current score)",
-      "core/ADR-0047 confirmation (topology still valid)",
-      "Bounded context map with ownership",
-      "Inter-context contract registry"
-    ]
-  }
-}