@evolith/core-domain 1.0.1 → 1.0.3

package/rulesets/adr/generated/adr-nodejs-0075-application-gateway-bff-with-nestjs.rules.json

@@ -1,29 +0,0 @@
-{
-  "$schema": "../../schema/ruleset-standard.schema.json",
-  "$id": "https://evolith.dev/rulesets/adr/generated/adr-nodejs-0075-application-gateway-bff-with-nestjs.rules.json",
-  "title": "ADR-0075 — Application Gateway (BFF) with NestJS Rules (generated)",
-  "description": "Auto-generated ruleset encoding ADR-0075 (nodejs track). Classification: executable. Generated by .harness/scripts/generate-adr-rulesets.mjs — do not edit by hand.",
-  "version": "1.0.0",
-  "adrId": "ADR-0075",
-  "adrTitle": "Application Gateway (BFF) with NestJS",
-  "status": "Approved",
-  "date": "2026-06-12",
-  "rules": [
-    {
-      "id": "NODE-0075-01",
-      "severity": "MUST",
-      "category": "adr-conformance",
-      "title": "Conform to ADR-0075: Application Gateway (BFF) with NestJS",
-      "description": "Implementations MUST conform to the decision recorded in ADR-0075 (nodejs track). ADR decision: Adopt NestJS as the Application Gateway (BFF) framework. NestJS provides a robust dependency injection container, native gRPC and REST support, and enforced modularity. It is safely deployed behind the Tier 1 Edge Gateway. This ADR contains enforceable language (dependency, enforce, enforced); conformance is expected to be verifiable via static analysis, linting, CI gates, or structural checks.",
-      "statement": "ADR decision: Adopt NestJS as the Application Gateway (BFF) framework. NestJS provides a robust dependency injection container, native gRPC and REST support, and enforced modularity. It is safely deployed behind the Tier 1 Edge Gateway.",
-      "rationale": "Derived from ADR-0075 \"Decision\" section. Enforcement signals detected: dependency, enforce, enforced.",
-      "validationQuery": "Verify codebase/CI compliance with ADR-0075 via static analysis, lint rules, or pipeline gates covering: dependency, enforce, enforced. Concrete checks to be wired into the harness.",
-      "blocking": true,
-      "enforcement": "executable"
-    }
-  ],
-  "references": [
-    "reference/architecture/adrs/nodejs/0075-application-gateway-bff-nestjs.md"
-  ],
-  "effectiveDate": "2026-06-12"
-}

package/rulesets/architecture/README.es.md

@@ -1,21 +0,0 @@
-# Índice de Reglas Arquitectónicas del Progressive-Axis
-
-Reglas que gobiernan el modelo de compatibilidad `progressive-axis` desde monolito modular hacia modulos distribuidos y microservicios.
-
-F1, F2 y F3 permanecen soportados como aliases de compatibilidad para CLI, MCP, Service CORE API y contratos de satelite existentes. No representan todo el universo topologico. Los perfiles multi-topologia fuera de este eje se resuelven mediante `topology.manifest.json` y el modelo dimensional en [Modelo de Dimensiones Topologicas](../../reference/architecture/topologies/topology-dimensions.es.md).
-
-| Fase | Archivo de Reglas | Descripción |
-|---|---|---|
-| **F1 — Monolito Modular** | [f1-modular-monolith.rules.json](../../reference/architecture/topologies/progressive-axis/modular-monolith/modular-monolith.rules.json) | Topología canónica de inicio; gates de preparación para extracción |
-| **F2 — Módulos Distribuidos** | [f2-distributed-modules.rules.json](../../reference/architecture/topologies/progressive-axis/distributed-modules/distributed-modules.rules.json) | Límites de módulos formalizados; contratos inter-módulo establecidos |
-| **F3 — Microservicios** | [f3-microservices.rules.json](../../reference/architecture/topologies/progressive-axis/microservices/microservices.rules.json) | Desplegabilidad autónoma; preparación para service mesh |
-
-| Alias de Compatibilidad | Topologia Canonica |
-|---|---|
-| `--arch-level F1` | `--topology modular-monolith` |
-| `--arch-level F2` | `--topology distributed-modules` |
-| `--arch-level F3` | `--topology microservices` |
-
----
-
-Volver al [Rulesets Hub](../README.es.md)

package/rulesets/architecture/README.md

@@ -1,21 +0,0 @@
-# Progressive-Axis Architecture Rules Index
-
-Rules governing the `progressive-axis` compatibility model from modular monolith to distributed modules to microservices.
-
-F1, F2, and F3 remain supported compatibility aliases for existing CLI, MCP, Service CORE API, and satellite contracts. They are not the full topology universe. Multi-topology profiles outside this axis are resolved through `topology.manifest.json` and the dimensional model in [Topology Dimensions Model](../../reference/architecture/topologies/topology-dimensions.md).
-
-| Phase | Rule File | Description |
-|---|---|---|
-| **F1 — Modular Monolith** | [f1-modular-monolith.rules.json](../../reference/architecture/topologies/progressive-axis/modular-monolith/modular-monolith.rules.json) | Canonical starting topology; extraction readiness gates |
-| **F2 — Distributed Modules** | [f2-distributed-modules.rules.json](../../reference/architecture/topologies/progressive-axis/distributed-modules/distributed-modules.rules.json) | Module boundaries formalized; inter-module contracts established |
-| **F3 — Microservices** | [f3-microservices.rules.json](../../reference/architecture/topologies/progressive-axis/microservices/microservices.rules.json) | Autonomous deployability; service mesh readiness |
-
-| Compatibility Alias | Canonical Topology |
-|---|---|
-| `--arch-level F1` | `--topology modular-monolith` |
-| `--arch-level F2` | `--topology distributed-modules` |
-| `--arch-level F3` | `--topology microservices` |
-
----
-
-Back to [Rulesets Hub](../README.md)

package/rulesets/architecture/opa/progressive-axis.rego

@@ -1,50 +0,0 @@
-package evolith.architecture.progressive_axis
-
-import rego.v1
-
-# ---------------------------------------------------------------------------
-# Progressive-Axis Architecture Compliance (ARCH-01..ARCH-05)
-# Validates cross-cutting eligibility rules for F1→F2→F3 topology transitions.
-# Topology-specific rules live co-located with each topology manifest.
-# ---------------------------------------------------------------------------
-
-valid_topologies := {"modular-monolith", "distributed-modules", "microservices"}
-
-upgrade_path := {
-	"modular-monolith": "distributed-modules",
-	"distributed-modules": "microservices",
-}
-
-violations contains {"id": "ARCH-01", "message": "evolith.yaml must declare a topology field matching a valid progressive-axis topology (modular-monolith, distributed-modules, microservices)"} if {
-	not valid_topologies[input.satellite.topology]
-}
-
-violations contains {"id": "ARCH-02", "message": msg} if {
-	from := input.satellite.previousTopology
-	to := input.satellite.topology
-	from != to
-	valid_topologies[from]
-	valid_topologies[to]
-	upgrade_path[from] != to
-	msg := sprintf("Topology transition from '%v' to '%v' is not allowed — must follow the progressive axis upgrade path (modular-monolith → distributed-modules → microservices)", [from, to])
-}
-
-violations contains {"id": "ARCH-03", "message": "An ADR must exist and be in accepted state before topology selection is finalised"} if {
-	not input.satellite.topologyAdrAccepted
-}
-
-violations contains {"id": "ARCH-04", "message": "topology.manifest.json must be present and declare the active topology"} if {
-	not input.satellite.hasTopologyManifest
-}
-
-violations contains {"id": "ARCH-05", "message": msg} if {
-	level := input.satellite.archLevel
-	topology := input.satellite.topology
-	expected := {
-		"F1": "modular-monolith",
-		"F2": "distributed-modules",
-		"F3": "microservices",
-	}
-	expected[level] != topology
-	msg := sprintf("Architecture compatibility alias '%v' does not match declared topology '%v' (expected: '%v')", [level, topology, expected[level]])
-}

package/rulesets/cli/README.es.md

@@ -1,17 +0,0 @@
-# Rulesets del CLI
-
-> **Navegación bilingüe:** [English version](./README.md)
-
-Reglas legibles por máquina para preparación de release del Evolith Smart CLI y paridad con Evolith Core.
-
-## Rulesets
-
-| Ruleset | Propósito |
-|---|---|
-| [Preparación de Release del CLI](./release-readiness.rules.json) | Define evidencia mínima de build, pruebas, paquete y smoke MCP antes de liberar el CLI. |
-| [Paridad CLI/Core](./core-parity.rules.json) | Exige que cada capacidad de regla Core sea trazable a CLI, MCP, pruebas y estado de evidencia. |
-
-## Intención de Validación
-
-Estos rulesets son autoritativos para revisiones de release y deben conectarse a la validación del CLI como checks ejecutables antes de promover una versión del CLI de beta a stable.
-

package/rulesets/cli/README.md

@@ -1,17 +0,0 @@
-# CLI Rulesets
-
-> **Bilingual navigation:** [Versión en Español](./README.es.md)
-
-Machine-readable rules for Evolith Smart CLI release readiness and parity with Evolith Core.
-
-## Rulesets
-
-| Ruleset | Purpose |
-|---|---|
-| [CLI Release Readiness](./release-readiness.rules.json) | Defines minimum build, test, package, and MCP smoke evidence before CLI release. |
-| [CLI/Core Parity](./core-parity.rules.json) | Requires every Core rule capability to be traced to CLI, MCP, tests, and evidence status. |
-
-## Validation Intent
-
-These rulesets are authoritative for release reviews and should be wired into CLI validation as executable checks before promoting a CLI version from beta to stable.
-

package/rulesets/cli/core-parity.rules.json

@@ -1,61 +0,0 @@
-{
-  "$schema": "../schema/ruleset-standard.schema.json",
-  "$id": "https://evolith.dev/rulesets/cli/core-parity.rules.json",
-  "title": "CLI/Core Parity Rules",
-  "description": "Rules ensuring Evolith Core governance capabilities are exposed consistently through CLI and MCP.",
-  "version": "1.0.0",
-  "effectiveDate": "2026-06-08",
-  "scope": "core-cli",
-  "category": "core-parity",
-  "rules": [
-    {
-      "id": "CLI-PAR-01",
-      "severity": "MUST",
-      "category": "traceability",
-      "title": "Every Executable Core Rule Has a Parity Record",
-      "description": "Each Core ruleset rule intended for automation MUST declare CLI status, MCP status, test status, and evidence status.",
-      "validationQuery": "Compare rulesets/**/*.rules.json against reference/governance/standards/vision/gap-tracking.md or generated parity manifest.",
-      "evidenceRequired": [
-        "parity manifest"
-      ],
-      "blocking": true
-    },
-    {
-      "id": "CLI-PAR-02",
-      "severity": "MUST",
-      "category": "shared-logic",
-      "title": "CLI and MCP Must Use Shared Validation Logic",
-      "description": "A validation capability MUST NOT implement divergent business logic in CLI and MCP adapters.",
-      "validationQuery": "Verify CLI commands and MCP tools call shared services or use cases for the same capability.",
-      "evidenceRequired": [
-        "source references",
-        "contract tests"
-      ],
-      "blocking": true
-    },
-    {
-      "id": "CLI-PAR-03",
-      "severity": "MUST",
-      "category": "outputs",
-      "title": "Equivalent CLI and MCP Results Must Be Semantically Consistent",
-      "description": "The same validation request through CLI and MCP MUST return the same rule outcomes, severities, and blocking status.",
-      "validationQuery": "Run paired CLI/MCP fixture tests and compare normalized JSON results.",
-      "evidenceRequired": [
-        "paired fixture report"
-      ],
-      "blocking": true
-    },
-    {
-      "id": "CLI-PAR-04",
-      "severity": "SHOULD",
-      "category": "documentation",
-      "title": "Parity Gaps Must Remain Visible",
-      "description": "Partial or missing parity SHOULD be documented with owner, priority, and planned closure date.",
-      "validationQuery": "Inspect parity tracking for owner, priority, and closure metadata.",
-      "evidenceRequired": [
-        "updated parity tracking"
-      ],
-      "blocking": false
-    }
-  ]
-}

package/rulesets/cli/release-readiness.rules.json

@@ -1,77 +0,0 @@
-{
-  "$schema": "../schema/ruleset-standard.schema.json",
-  "$id": "https://evolith.dev/rulesets/cli/release-readiness.rules.json",
-  "title": "CLI Release Readiness Rules",
-  "description": "Minimum release gates for Evolith Smart CLI, SDK, and MCP exposure.",
-  "version": "1.0.0",
-  "effectiveDate": "2026-06-08",
-  "scope": "core-cli",
-  "category": "release-readiness",
-  "rules": [
-    {
-      "id": "CLI-RR-01",
-      "severity": "MUST",
-      "category": "build",
-      "title": "TypeScript Build Must Pass",
-      "description": "The CLI package MUST compile with npm run build before any release candidate is tagged.",
-      "validationQuery": "Run npm run build in sdk/cli and require exit code 0.",
-      "evidenceRequired": [
-        "build log",
-        "package version"
-      ],
-      "blocking": true
-    },
-    {
-      "id": "CLI-RR-02",
-      "severity": "MUST",
-      "category": "tests",
-      "title": "Unit and Integration Tests Must Start and Pass",
-      "description": "The CLI test runner MUST start successfully and all non-quarantined tests MUST pass.",
-      "validationQuery": "Run npm test -- --runInBand in sdk/cli and require exit code 0.",
-      "evidenceRequired": [
-        "test summary",
-        "failing suite list when blocked"
-      ],
-      "blocking": true
-    },
-    {
-      "id": "CLI-RR-03",
-      "severity": "MUST",
-      "category": "dependencies",
-      "title": "Dependency Graph Must Be Reproducible",
-      "description": "The CLI workspace MUST keep a committed package lock and no missing transitive dependencies.",
-      "validationQuery": "Run npm install --workspace @evolith/smart-cli, npm ls, and verify package-lock.json is present.",
-      "evidenceRequired": [
-        "package-lock.json",
-        "npm ls output"
-      ],
-      "blocking": true
-    },
-    {
-      "id": "CLI-RR-04",
-      "severity": "MUST",
-      "category": "mcp",
-      "title": "MCP Smoke Test Must Pass",
-      "description": "The MCP server MUST respond to initialize and tools/list over the supported release transport.",
-      "validationQuery": "Start smart-cli mcp serve and execute initialize plus tools/list JSON-RPC smoke requests.",
-      "evidenceRequired": [
-        "initialize response",
-        "tools/list response"
-      ],
-      "blocking": true
-    },
-    {
-      "id": "CLI-RR-05",
-      "severity": "SHOULD",
-      "category": "documentation",
-      "title": "Release Documentation Must Match Implementation",
-      "description": "CLI README, architecture, vision, gap analysis, and parity docs SHOULD describe the current implemented state without contradictions.",
-      "validationQuery": "Review CLI documentation state markers against source commands and tests.",
-      "evidenceRequired": [
-        "documentation diff",
-        "gap analysis update"
-      ],
-      "blocking": false
-    }
-  ]
-}

package/rulesets/compliance-baseline/README.es.md

@@ -1,26 +0,0 @@
-# Ruleset de Baseline de Cumplimiento
-
-> **Navegación Bilingüe:** [English Version](./README.md)
-
-Punto de entrada ejecutable WS1 para el ruleset de baseline de cumplimiento de Evolith.
-
-## Propósito
-
-Este directorio expone `rulesets/compliance-baseline` como la ruta ejecutable canónica que verifica la auditoría de fortaleza como data inteligente. El ruleset codifica los pilares de baseline de cumplimiento de Evolith consumidos por el validador nativo de rulesets y los flujos de evidencia CI.
-
-## Artefactos
-
-| Artefacto | Propósito |
-|---|---|
-| [compliance-baseline.rules.json](./compliance-baseline.rules.json) | Ruleset nativo machine-readable para validación de baseline de cumplimiento |
-| [../opa/compliance-baseline.rego](../opa/compliance-baseline.rego) | Artefacto de paridad OPA para validación de baseline de cumplimiento |
-| [../opa/compliance-baseline.test.rego](../opa/compliance-baseline.test.rego) | Cobertura de pruebas OPA para la política de baseline de cumplimiento |
-
-## Validación
-
-Ejecuta estos checks después de cambiar el ruleset:
-
-```bash
-npx jest --config packages/core-domain/jest.config.js --rootDir packages/core-domain --testPathPatterns='ruleset-validation.mode' --no-coverage
-.harness/bin/opa test rulesets/opa/compliance-baseline.rego rulesets/opa/compliance-baseline.test.rego -v
-```

package/rulesets/compliance-baseline/README.md

@@ -1,26 +0,0 @@
-# Compliance Baseline Ruleset
-
-> **Bilingual Navigation:** [Versión en Español](./README.es.md)
-
-Executable WS1 entrypoint for the Evolith compliance baseline ruleset.
-
-## Purpose
-
-This directory exposes `rulesets/compliance-baseline` as the canonical executable path checked by the intelligent data strength audit. The ruleset encodes the Evolith compliance baseline pillars consumed by the native ruleset validator and CI evidence flows.
-
-## Artifacts
-
-| Artifact | Purpose |
-|---|---|
-| [compliance-baseline.rules.json](./compliance-baseline.rules.json) | Native machine-readable ruleset for compliance baseline validation |
-| [../opa/compliance-baseline.rego](../opa/compliance-baseline.rego) | OPA policy parity artifact for compliance baseline validation |
-| [../opa/compliance-baseline.test.rego](../opa/compliance-baseline.test.rego) | OPA test coverage for the compliance baseline policy |
-
-## Validation
-
-Run these checks after changing the ruleset:
-
-```bash
-npx jest --config packages/core-domain/jest.config.js --rootDir packages/core-domain --testPathPatterns='ruleset-validation.mode' --no-coverage
-.harness/bin/opa test rulesets/opa/compliance-baseline.rego rulesets/opa/compliance-baseline.test.rego -v
-```

package/rulesets/compliance-baseline/compliance-baseline.rules.json

@@ -1,81 +0,0 @@
-{
-  "$schema": "../schema/ruleset-standard.schema.json",
-  "$id": "https://evolith.dev/rulesets/compliance-baseline/compliance-baseline.rules.json",
-  "title": "Evolith Compliance Baseline Rules",
-  "description": "Machine-readable encoding of the 5 Evolith Compliance Baseline pillars. These artifacts govern the entire lifecycle and must be in effect from the first artifact to the last deployment.",
-  "version": "1.0.0",
-  "effectiveDate": "2026-01-01",
-  "exitCriteria": {
-    "description": "All 5 pillars validated present and compliant in each satellite. Baseline violations block Phase 1 gate.",
-    "validationTools": [
-      "evolith-cli validate",
-      "architectural review",
-      "CI baseline check"
-    ]
-  },
-  "rules": [
-    {
-      "id": "CB-01",
-      "severity": "MUST",
-      "category": "Agnostic Baseline",
-      "title": "Technology selection respects Agnostic Baseline",
-      "description": "Any technology introduced in a satellite must not contradict the Agnostic Baseline. New technology requires Architecture Board review and ADR before adoption.",
-      "validationQuery": "New dependencies validated against authoritative-tech-stack-agnostic.md approved list. Unlisted tech requires exception.",
-      "blocking": true
-    },
-    {
-      "id": "CB-02",
-      "severity": "MUST",
-      "category": "Reference Architecture (Blueprint)",
-      "title": "Product architecture traceable to Reference Blueprint",
-      "description": "Product architecture diagrams must be traceable to the Evolith Reference Blueprint C4 model. All bounded contexts, layers, and communication paths must map to the reference.",
-      "validationQuery": "Architecture diagrams include reference to Blueprint layers and bounded contexts. Traceability matrix exists.",
-      "blocking": true
-    },
-    {
-      "id": "CB-03",
-      "severity": "MUST",
-      "category": "Engineering Manifesto",
-      "title": "Engineering Manifesto principles enforced",
-      "description": "SOLID, DRY, KISS, YAGNI, and anti-patterns rules from Engineering Manifesto are enforced via linting and code review.",
-      "validationQuery": "ESLint or equivalent rules enforce Manifesto principles. PR reviewer checks compliance.",
-      "blocking": true
-    },
-    {
-      "id": "CB-04",
-      "severity": "MUST",
-      "category": "Definition of Done",
-      "title": "Definition of Done satisfied before story closure",
-      "description": "Every Technical Story must satisfy the Definition of Done checklist before being marked Done. DoD includes: code implemented and reviewed, unit tests passing at >= 80% coverage, acceptance criteria verified, documentation updated.",
-      "validationQuery": "Story status = Done only when all DoD checklist items are checked. CI confirms coverage and test pass.",
-      "blocking": true
-    },
-    {
-      "id": "CB-05",
-      "severity": "MUST",
-      "category": "Repository Taxonomy",
-      "title": "Repository structure follows Taxonomy",
-      "description": "Repository structure, file naming, and artifact classification follow Repository Taxonomy rules. Evolith reference, canonical reference, and product evidence locations are respected.",
-      "validationQuery": "Directory structure matches Repository Taxonomy. Files located in correct taxonomic category.",
-      "blocking": true
-    },
-    {
-      "id": "CB-VAL-01",
-      "severity": "MUST",
-      "category": "validation",
-      "title": "All 5 baseline pillars must be present in evolith.yaml spec.compliance",
-      "description": "All 5 baseline pillars must be present in evolith.yaml spec.compliance",
-      "enforcement": "CLI validates baseline pillar references in satellite evolith.yaml",
-      "blocking": true
-    },
-    {
-      "id": "CB-VAL-02",
-      "severity": "MUST",
-      "category": "validation",
-      "title": "Baseline references must point to existing Evolith Core documents",
-      "description": "Baseline references must point to existing Evolith Core documents",
-      "enforcement": "Broken references to baseline documents block satellite governance validation",
-      "blocking": true
-    }
-  ]
-}

package/rulesets/contracts/README.es.md

@@ -1,19 +0,0 @@
-# Compatibilidad de Contratos de Máquina de Evolith
-
-> **Navegación Bilingüe:** [English Version](./README.md)
-
-El manifiesto de este directorio es el límite canónico de compatibilidad entre Evolith Core, el productor Smart CLI y consumidores independientes como Evolith Tracker.
-
-- Las versiones del contrato y los schemas siguen versionado semántico.
-- Los cambios aditivos compatibles incrementan la versión minor.
-- Los cambios incompatibles incrementan la versión major y requieren una migración explícita del consumidor.
-- Los consumidores fijan la versión del contrato, cada versión de schema y su digest SHA-256.
-- El CI de Core valida la declaración del productor y los digests de schemas. El CI del consumidor ejecuta el mismo validador contra su manifiesto fijado.
-
-Ejecutar:
-
-```bash
-node .harness/scripts/ci/10-validate-contract-conformance.mjs
-node .harness/scripts/ci/10-validate-contract-conformance.mjs --consumer /ruta/a/consumer-contracts.json
-```
-

package/rulesets/contracts/README.md

@@ -1,19 +0,0 @@
-# Evolith Machine Contract Compatibility
-
-> **Bilingual Navigation:** [Versión en Español](./README.es.md)
-
-The manifest in this directory is the canonical compatibility boundary between Evolith Core, the Smart CLI producer, and independent consumers such as Evolith Tracker.
-
-- Contract and schema versions follow semantic versioning.
-- Additive compatible changes increment a minor version.
-- Breaking changes increment the major version and require an explicit consumer migration.
-- Consumers pin the contract version, each schema version, and its SHA-256 digest.
-- Core CI validates the producer declaration and schema digests. Consumer CI runs the same validator against its pinned manifest.
-
-Run:
-
-```bash
-node .harness/scripts/ci/10-validate-contract-conformance.mjs
-node .harness/scripts/ci/10-validate-contract-conformance.mjs --consumer /path/to/consumer-contracts.json
-```
-

package/rulesets/contracts/evolith-machine-contracts.json

@@ -1,29 +0,0 @@
-{
-  "contractVersion": "1.0.0",
-  "compatibilityPolicy": "semver-major",
-  "producer": {
-    "package": "@evolith/smart-cli",
-    "version": "1.1.0"
-  },
-  "schemas": [
-    {
-      "id": "gate-evidence",
-      "version": "1.0.0",
-      "path": "rulesets/schema/gate-evidence.schema.json",
-      "sha256": "9225090e2ee851dbd2d5c22e7a0a6e2d7f97db9835f7f3822ac7d9f861b75754"
-    },
-    {
-      "id": "output-envelope",
-      "version": "1.0.0",
-      "path": "rulesets/schema/output-envelope.schema.json",
-      "sha256": "07eaffaae2c33071ea105fbcbdc497c06d149143f6cc9b94555170740707fd0b"
-    }
-  ],
-  "supportedConsumers": [
-    {
-      "repository": "beyondnetcode/evolith_tracker",
-      "manifestPath": "contracts/evolith-core-contracts.json",
-      "contractVersion": "1.0.0"
-    }
-  ]
-}

package/rulesets/contracts/fixtures/gate-evidence.success.json

@@ -1,10 +0,0 @@
-{
-  "gateId": "design-baseline-approved",
-  "phase": "design",
-  "verdict": "passed",
-  "rulesetRef": "rulesets/sdlc/phase-gates.rules.json",
-  "rulesetVersion": "1.2.0",
-  "violations": [],
-  "evaluatedAt": "2026-06-13T12:00:00Z",
-  "evaluatedBy": "ci"
-}

package/rulesets/contracts/fixtures/output-envelope.success.json

@@ -1,23 +0,0 @@
-{
-  "success": true,
-  "data": {
-    "gateId": "design-baseline-approved",
-    "phase": "design",
-    "verdict": "passed",
-    "rulesetRef": "rulesets/sdlc/phase-gates.rules.json",
-    "rulesetVersion": "1.2.0",
-    "violations": [],
-    "evaluatedAt": "2026-06-13T12:00:00Z",
-    "evaluatedBy": "ci"
-  },
-  "meta": {
-    "command": "evolith gate evaluate",
-    "executedAt": "2026-06-13T12:00:00Z",
-    "durationMs": 10,
-    "correlationId": "contract-fixture-001",
-    "context": {
-      "initiative": "GT-42",
-      "phase": "design"
-    }
-  }
-}

package/rulesets/cross-cutting/README.es.md

@@ -1,14 +0,0 @@
-# Índice de Reglas Transversales
-
-Reglas que aplican a todas las fases y componentes. Son la Línea Base de Cumplimiento Evolith codificada como reglas machine-readable.
-
-| Conjunto de Reglas | Archivo | Descripción |
-|---|---|---|
-| **Línea Base de Cumplimiento** | [compliance-baseline.rules.json](./compliance-baseline.rules.json) | 5 pilares: Baseline Agnóstico, Reference Blueprint, Manifiesto de Ingeniería, DoD, Taxonomía del Repositorio |
-| **Definition of Done** | [definition-of-done.rules.json](./definition-of-done.rules.json) | Checklist obligatorio de 10 ítems antes de cerrar una historia |
-| **Manifiesto de Ingeniería** | [engineering-manifesto.rules.json](./engineering-manifesto.rules.json) | Principios SOLID, DRY, KISS, YAGNI y anti-patrones |
-| **Taxonomía del Repositorio** | [repository-taxonomy.rules.json](./repository-taxonomy.rules.json) | Convenciones de nombres, estructura de directorios, clasificación de artefactos |
-
----
-
-Volver al [Rulesets Hub](../README.es.md)

package/rulesets/cross-cutting/README.md

@@ -1,14 +0,0 @@
-# Cross-Cutting Rules Index
-
-Rules that apply across all phases and components. These are the Evolith Compliance Baseline encoded as machine-readable rules.
-
-| Rule Set | File | Description |
-|---|---|---|
-| **Compliance Baseline** | [compliance-baseline.rules.json](./compliance-baseline.rules.json) | 5 pillars: Agnostic Baseline, Reference Blueprint, Engineering Manifesto, DoD, Repository Taxonomy |
-| **Definition of Done** | [definition-of-done.rules.json](./definition-of-done.rules.json) | 10-item mandatory checklist before story closure |
-| **Engineering Manifesto** | [engineering-manifesto.rules.json](./engineering-manifesto.rules.json) | SOLID, DRY, KISS, YAGNI principles and anti-patterns |
-| **Repository Taxonomy** | [repository-taxonomy.rules.json](./repository-taxonomy.rules.json) | Naming conventions, directory structure, artifact classification |
-
----
-
-Back to [Rulesets Hub](../README.md)