@evolith/core-domain 1.0.1 → 1.0.3

package/rulesets/topologies/edge-computing/security.md

@@ -1,218 +0,0 @@
-# Edge Computing — Security Guide
-
-> **Bilingual Navigation:** [English](./security.md) | [Español](./security.es.md)
-
-**Owner:** Platform Engineering
-**Topology:** Edge Computing
-
-## Edge Authentication
-
-Edge nodes authenticate using a layered approach: node identity, workload identity, and client tokens.
-
-### Node Identity
-
-Each edge node holds a hardware-backed identity certificate issued during provisioning.
-
-```bash
-# Verify node identity
-edge-cli auth node-identity verify \
-  --node-id edge-node-01 \
-  --check-cert-expiry
-
-# Output:
-# NODE: edge-node-01
-# CERT_EXPIRY: 2027-06-23
-# TRUST_CHAIN: root-ca → intermediate-ca → node-cert
-# STATUS: valid
-```
-
-### Workload Identity
-
-Workloads running on edge nodes use SPIFFE-based workload identities for service-to-service authentication.
-
-```yaml
-spiffe:
-  trust_domain: "edge.example.com"
-  workload:
-    path: "/compute/worker"
-    selector:
-      - "k8s:ns=edge-workloads"
-      - "k8s:sa=edge-worker"
-```
-
-## Data Residency
-
-Edge deployments must respect data residency requirements based on node geographic location.
-
-### Residency Policy Engine
-
-```yaml
-residency:
-  rules:
-    - region: "eu-west-*"
-      restrictions:
-        - data_type: "pii"
-          allowed_destinations: ["eu-west-1", "eu-central-1"]
-        - data_type: "telemetry"
-          allowed_destinations: ["eu-west-*"]
-    - region: "us-*"
-      restrictions:
-        - data_type: "pii"
-          allowed_destinations: ["us-*"]
-    - region: "ap-*"
-      restrictions:
-        - data_type: "pii"
-          allowed_destinations: ["ap-*"]
-```
-
-### Enforcement
-
-```bash
-# Audit data residency compliance
-edge-cli residency audit --fleet-wide --output report.json
-
-# Violations trigger automated remediation:
-# - Cross-border PII: block and alert
-# - Telemetry leakage: redirect to allowed region
-```
-
-## Encryption at Rest
-
-All persistent data on edge nodes is encrypted using AES-256-GCM.
-
-### Encryption Architecture
-
-| Data Category | Key Source | Rotation | Scope |
-|---------------|------------|----------|-------|
-| Cached content | Node-local KMS | 24 hours | Per-node |
-| Configuration | Central KMS | 7 days | Fleet-wide |
-| Logs | Node-local KMS | 24 hours | Per-node |
-| Secrets | External vault | On-demand | Per-workload |
-
-### Key Management
-
-```bash
-# Rotate edge encryption keys
-edge-cli crypto rotate \
-  --scope node-local \
-  --algorithm aes-256-gcm \
-  --grace-period 1h
-```
-
-## Network Security (EC-SEC-01)
-
-Edge nodes enforce network security policies at the node level.
-
-### Network Segmentation
-
-```
-┌─────────────────────────────────────────────┐
-│  Edge Node Network                          │
-│  ┌───────────┐  ┌───────────┐  ┌─────────┐ │
-│  │ Compute   │  │ Storage   │  │ Control │ │
-│  │ Segment   │  │ Segment   │  │ Segment │ │
-│  │ (VLAN 10) │  │ (VLAN 20) │  │ (VLAN 30)│ │
-│  └───────────┘  └───────────┘  └─────────┘ │
-│         │              │             │       │
-│         └──────────────┼─────────────┘       │
-│                        │                     │
-│                   ┌────┴────┐                │
-│                   │ Firewall│                │
-│                   └────┬────┘                │
-│                        │                     │
-└────────────────────────┼─────────────────────┘
-                         │
-                    ┌────┴────┐
-                    │ Origin  │
-                    └─────────┘
-```
-
-### Firewall Rules
-
-```yaml
-firewall:
-  ingress:
-    - port: 443
-      source: "client-cidrs"
-      action: allow
-    - port: 8443
-      source: "peer-nodes"
-      action: allow
-    - port: 9090
-      source: "monitoring-subnet"
-      action: allow
-  egress:
-    - port: 443
-      destination: "origin-servers"
-      action: allow
-    - port: 443
-      destination: "kms-endpoints"
-      action: allow
-    - all: deny
-```
-
-## Mutual TLS (EC-SEC-02)
-
-All communication between edge nodes and between edge and origin uses mTLS.
-
-### Certificate Configuration
-
-```yaml
-mtls:
-  enabled: true
-  min_version: "1.3"
-  cipher_suites:
-    - "TLS_AES_256_GCM_SHA384"
-    - "TLS_CHACHA20_POLY1305_SHA256"
-  client_auth:
-    required: true
-    ca_bundle: "/etc/edge/ca-bundle.pem"
-  cert_rotation:
-    interval: 24h
-    overlap: 1h
-```
-
-### mTLS Verification
-
-```bash
-# Test mTLS connectivity between nodes
-edge-cli mtls test \
-  --source edge-node-01 \
-  --target edge-node-02 \
-  --verify-peer-cert
-
-# Output:
-# SOURCE: edge-node-01
-# TARGET: edge-node-02
-# TLS_VERSION: 1.3
-# CIPHER: TLS_AES_256_GCM_SHA384
-# PEER_CERT_VALID: true
-# STATUS: passed
-```
-
-## Secret Rotation
-
-Secrets on edge nodes are rotated automatically to limit exposure window.
-
-### Rotation Schedule
-
-| Secret Type | Rotation Interval | Grace Period | Failure Action |
-|-------------|-------------------|--------------|----------------|
-| Node identity cert | 90 days | 24 hours | Alert + degrade |
-| API tokens | 1 hour | 5 minutes | Refresh background |
-| Encryption keys | 24 hours | 1 hour | Queue new key |
-| Database credentials | 7 days | 2 hours | Hold connection |
-
-### Rotation Orchestration
-
-```bash
-# Trigger fleet-wide secret rotation
-edge-cli secrets rotate \
-  --scope fleet \
-  --type all \
-  --strategy rolling \
-  --batch 10%
-```
-
----
-[Back to Edge Computing Profile](./README.md)

package/rulesets/topologies/edge-computing/topology.config.schema.json

@@ -1,13 +0,0 @@
-{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "title": "Edge Computing Topology Configuration",
-  "type": "object",
-  "additionalProperties": false,
-  "required": ["topology", "syncStrategy", "edgeIsolation", "conflictResolution"],
-  "properties": {
-    "topology": { "const": "edge-computing" },
-    "syncStrategy": { "type": "string", "enum": ["offline-first", "eventual", "real-time-fallback"] },
-    "edgeIsolation": { "const": true },
-    "conflictResolution": { "type": "string", "enum": ["last-write-wins", "merge", "manual"] }
-  }
-}

package/rulesets/topologies/edge-computing/topology.manifest.json

@@ -1,113 +0,0 @@
-{
-  "apiVersion": "evolith.dev/topology/v1",
-  "kind": "TopologyManifest",
-  "metadata": {
-    "id": "edge-computing",
-    "name": "Edge Computing",
-    "dimension": "execution",
-    "status": "accepted",
-    "version": "1.0.0",
-    "governance": {
-      "owner": "Platform Engineering",
-      "criticality": "P1"
-    }
-  },
-  "spec": {
-    "summary": "Execution topology for workloads placed near users, devices, regions, or constrained networks while preserving Evolith domain ownership and governance contracts.",
-    "topologyType": "edge-computing",
-    "compatibility": {
-      "progressiveAxis": {
-        "phase": "cross",
-        "profile": "cross"
-      },
-      "composableWith": [
-        "microservices",
-        "distributed-modules",
-        "event-driven",
-        "serverless",
-        "agentic-ai"
-      ]
-    },
-    "artifacts": {
-      "adrs": [
-        "reference/architecture/adrs/core/0079-multi-topology-reference-corpus.md",
-        "reference/architecture/adrs/core/0096-edge-computing-architecture-governance.md"
-      ],
-      "rulesets": [
-        "rulesets/topologies/edge-computing/edge-computing.rules.json"
-      ],
-      "opaPolicies": [
-        "rulesets/topologies/edge-computing/edge-computing.rego"
-      ],
-      "aiRulesets": [
-        "rulesets/topologies/edge-computing/README.md"
-      ],
-      "umsContracts": [
-        "reference/knowledge/demo/ums-reference-model.md"
-      ]
-    },
-    "corpus": {
-      "guidance": {
-        "profile": "rulesets/topologies/edge-computing/README.md",
-        "maturityGuide": "rulesets/topologies/edge-computing/maturity.md"
-      },
-      "configurationContract": "rulesets/topologies/edge-computing/topology.config.schema.json",
-      "fixtures": {
-        "valid": "rulesets/topologies/edge-computing/fixtures/valid.topology.config.json",
-        "invalid": "rulesets/topologies/edge-computing/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"
-    },
-    "operationalBudgets": {
-      "latencyBudgetMs": 200,
-      "coldStartCeilingMs": 300,
-      "costCeilingPerExecutionCents": 1
-    },
-    "operationalInterfaces": {
-      "cli": {
-        "validators": [
-          "validate-architecture",
-          "validate-topology"
-        ]
-      },
-      "mcp": {
-        "resources": [
-          "evolith://topologies/edge-computing/manifest",
-          "evolith://topologies/edge-computing/rulesets"
-        ],
-        "tools": [
-          "evolith-topology-inspect",
-          "evolith-topology-validate"
-        ],
-        "prompts": [
-          "topology-aware-implementation",
-          "extraction-readiness-review"
-        ]
-      },
-      "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/event-driven/README.es.md

@@ -1,71 +0,0 @@
-# Perfil Topologico Event-Driven
-
-> **Navegacion Bilingue:** [English Version](./README.md)
-
-**Estado:** Accepted  
-**Dimension:** `integration`  
-**ID de Topologia:** `event-driven`  
-**Alias de Compatibilidad:** `F2-compatible`  
-**Manifiesto:** [topology.manifest.json](./topology.manifest.json)
-
-La arquitectura event-driven es una topologia de integracion para coordinacion asincrona mediante contratos de eventos explicitos, publicacion confiable, consumidores idempotentes y flujo de mensajes observable.
-
-## Proposito
-
-Usa esta topologia cuando bounded contexts, modulos, servicios, funciones o workloads edge deben coordinar sin acoplamiento sincrono fuerte.
-
-La integracion event-driven no autoriza esconder workflows de negocio en infraestructura. Los eventos deben expresar hechos de dominio explicitos, ownership, reglas de evolucion de schema y semantica de fallo.
-
-## Reglas de Gobernanza
-
-| Regla | Requisito |
-|---|---|
-| Contratos de eventos | Los eventos deben ser explicitos, versionados y backward-compatible. |
-| Confiabilidad | La publicacion entre fronteras debe usar Transactional Outbox o un patron equivalente de confiabilidad. |
-| Idempotencia | Los consumidores deben tolerar entrega duplicada y reintentos. |
-| Observabilidad | El flujo de eventos debe exponer correlacion, lag, fallos y evidencia de replay. |
-| Ownership | Los productores poseen el significado del evento; los consumidores poseen sus reacciones locales. |
-
-## Autoridad Requerida
-
-| Artefacto | Rol |
-|---|---|
-| [ADR-0015: Arquitectura Event-Driven Intra-Dominio](../../../adrs/core/0015-event-driven-architecture-intra-domain.md) | Gobierna la coordinacion event-driven dentro de contextos acotados. |
-| [ADR-0079: Corpus de Referencia Multi-Topologia](../../../adrs/core/0079-multi-topology-reference-corpus.md) | Gobierna los manifiestos de topologia y composicion. |
-| [Reglas de Arquitectura Event-Driven](./event-driven.rules.json) | Reglas de compatibilidad ejecutables existentes. |
-| [Modelo de Dimensiones de Topologia](../../topology-dimensions.md) | Define reglas de composicion y compatibilidad. |
-
-## Contrato Ejecutable
-
-Todo satelite que adopte este perfil proporciona `event-driven.config.json`:
-
-```json
-{
-  "strictAsyncApi": true,
-  "transactionalOutbox": true,
-  "deadLetterQueue": true
-}
-```
-
-ED-R01 a ED-R03 exigen ese contrato, forzando la definicion explicita de AsyncAPI, el patron Transactional Outbox para la confiabilidad, y un Dead Letter Queue (DLQ) para el manejo de mensajes fallidos. El evaluador Native y la [politica OPA](./event-driven.rego) evaluan estos campos.
-
-## Composicion
-
-`event-driven` puede combinarse con:
-
-| Topologia | Por Que Puede Componerse |
-|---|---|
-| `modular-monolith` | Agrega integracion event-driven desacoplada preservando un sistema desplegable. |
-| `distributed-modules` | Habilita coordinacion asincrona entre fronteras de modulo con contratos explicitos. |
-| `microservices` | Proporciona comunicacion event-driven confiable entre servicios con propiedad independiente. |
-| `serverless` | Impulsa ejecucion serverless disparada por eventos gobernada por contratos explicitos. |
-| `edge-computing` | Soporta flujo de eventos asincrono hacia y desde workloads ubicados en el edge. |
-| `data-mesh` | Habilita actualizaciones de productos de datos impulsadas por eventos con propiedad analitica gobernada. |
-| `agentic-ai` | Coordina workflows de agentes IA a traves de canales de eventos observables. |
-
-## Frontera de Negocio
-
-Este perfil es solo tecnico. No define priorizacion de negocio, timing, ROI, costo, presupuesto, staffing ni Funnel 0. Evolith Tracker posee esas preocupaciones de negocio mediante su ACL.
-
----
-[Volver al Hub de Topologias](../../README.es.md)

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

@@ -1,71 +0,0 @@
-# Event-Driven Topology Profile
-
-> **Bilingual Navigation:** [Version en Espanol](./README.es.md)
-
-**Status:** Accepted  
-**Dimension:** `integration`  
-**Topology ID:** `event-driven`  
-**Compatibility Alias:** `F2-compatible`  
-**Manifest:** [topology.manifest.json](./topology.manifest.json)
-
-Event-driven architecture is an integration topology for asynchronous coordination through explicit event contracts, reliable publication, idempotent consumers, and observable message flow.
-
-## Purpose
-
-Use this topology when bounded contexts, modules, services, functions, or edge workloads must coordinate without tight synchronous coupling.
-
-Event-driven integration is not permission to hide business workflows in infrastructure. Events must express explicit domain facts, ownership, schema evolution rules, and failure semantics.
-
-## Governance Rules
-
-| Rule | Requirement |
-|---|---|
-| Event contracts | Events must be explicit, versioned, and backward-compatible. |
-| Reliability | Cross-boundary publication should use Transactional Outbox or an equivalent reliability pattern. |
-| Idempotency | Consumers must tolerate duplicate delivery and retries. |
-| Observability | Event flow must expose correlation, lag, failures, and replay evidence. |
-| Ownership | Event producers own event meaning; consumers own local reactions. |
-
-## Required Authority
-
-| Artifact | Role |
-|---|---|
-| [ADR-0015: Event-Driven Architecture Intra-Domain](../../../adrs/core/0015-event-driven-architecture-intra-domain.md) | Governs event-driven coordination within bounded contexts. |
-| [ADR-0079: Multi-Topology Reference Corpus](../../../adrs/core/0079-multi-topology-reference-corpus.md) | Governs topology manifests and composition. |
-| [Event-Driven Architecture Rules](./event-driven.rules.json) | Existing executable compatibility rules. |
-| [Topology Dimensions Model](../../topology-dimensions.md) | Defines composition and compatibility rules. |
-
-## Executable Contract
-
-Every adopting satellite provides `event-driven.config.json`:
-
-```json
-{
-  "strictAsyncApi": true,
-  "transactionalOutbox": true,
-  "deadLetterQueue": true
-}
-```
-
-ED-R01 through ED-R03 require that contract, enforcing explicit AsyncAPI definition, the Transactional Outbox pattern for reliability, and a Dead Letter Queue (DLQ) for failed message handling. The Native evaluator and [OPA policy](./event-driven.rego) evaluate these fields.
-
-## Composition
-
-`event-driven` can combine with:
-
-| Topology | Why It Can Compose |
-|---|---|
-| `modular-monolith` | Adds decoupled event-driven integration while preserving one deployable system. |
-| `distributed-modules` | Enables async coordination across module boundaries with explicit contracts. |
-| `microservices` | Provides reliable event-driven communication between independently owned services. |
-| `serverless` | Drives event-triggered serverless execution governed by explicit contracts. |
-| `edge-computing` | Supports async event flow to and from edge-located workloads. |
-| `data-mesh` | Enables event-driven data product updates with governed analytical ownership. |
-| `agentic-ai` | Coordinates AI-agent workflows through observable event channels. |
-
-## Business Boundary
-
-This profile is technical-only. It does not define business prioritization, timing, ROI, cost, budget, staffing, or Funnel 0. Evolith Tracker owns those business concerns through its ACL.
-
----
-[Back to Topology Hub](../../README.md)

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

@@ -1,67 +0,0 @@
-# Guía de Adopción Orientada a Eventos
-
-> **Navegación Bilingüe:** [English](./adoption.md) | [Español](./adoption.es.md)
-
-**Propietario:** Junta de Arquitectura
-**Topología:** Orientada a Eventos
-
-## Propósito
-
-Definir criterios de entrada, procedimientos de configuración y listas de verificación de adopción para equipos que adoptan arquitectura orientada a eventos: configuración del catálogo de eventos, contratos de productor/consumidor y validación de preparación.
-
-## Criterios de Entrada
-
-Antes de adoptar patrones orientados a eventos, verificar:
-
-- Se ha identificado al menos un caso de uso asincrónico (por ejemplo, notificación entre dominios, requisito de consistencia eventual).
-- El equipo tiene acceso a un broker de mensajes (gestionado o auto-hospedado).
-- El equipo comprende los tradeoffs de orientado a eventos vs. alternativas síncronas.
-- La infraestructura de registro de esquemas está disponible o planificada.
-
-## Configuración del Catálogo de Eventos
-
-- Crear entrada en el catálogo para cada tipo de evento con: nombre, dominio, propietario, versión del esquema, política de retención.
-- Asignar un propietario de dominio responsable de cambios de esquema y deprecación.
-- Publicar el catálogo en una ubicación accesible (wiki, portal o repositorio de código).
-
-## Contratos de Productor — ED-R01
-
-- Registrar especificación AsyncAPI para cada tipo de evento antes de la primera publicación.
-- Definir campos requeridos y opcionales con tipos y valores predeterminados.
-- Incluir metadatos del evento: event-id, event-version, timestamp, correlation-id.
-
-## Contratos de Consumidor — ED-R05
-
-- Declarar tipos de eventos esperados y versiones de esquemas en el registro del consumidor.
-- Documentar estrategia de idempotencia y ventana de deduplicación.
-- Definir tolerancia de retraso y umbrales de alerta para el consumidor.
-
-## Lista de Verificación de Preparación
-
-- [ ] Especificación AsyncAPI registrada en el registro de esquemas
-- [ ] Entrada del catálogo de eventos creada con propietario y retención
-- [ ] Productor implementa validación de esquemas antes de publicar
-- [ ] Consumidor implementa procesamiento idempotente
-- [ ] Enrutamiento DLQ configurado con política de reintento
-- [ ] Paneles de monitoreo creados para retraso y throughput
-- [ ] Manuales operativos documentados para escenarios de falla
-- [ ] Equipo capacitado en patrones y tradeoffs orientados a eventos
-
-## Aplicabilidad Componible
-
-| Componible | Orientación |
-|---|---|
-| Monolito Modular | Catálogo ligero; broker embebido; validación de eventos intra-proceso. |
-| Módulos Distribuidos | Catálogo compartido; se requiere revisión de contratos entre módulos. |
-| Microservicios | Catálogo completo con propiedad de dominio; registro de contratos por servicio. |
-| Serverless | Catálogo gestionado por plataforma; ejecución de contratos vía políticas de plataforma. |
-| Computación Edge | Catálogo local con sincronización a la nube; contrato simplificado para restricciones de edge. |
-
-## Referencias ADR
-
-- **ADR-0015**: Estándares de catálogo de eventos y contratos de productor.
-- **ADR-0079**: Requisitos de contratos de consumidor y preparación.
-
----
-
-[Volver al Perfil Orientado a Eventos](./README.es.md)

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

@@ -1,67 +0,0 @@
-# Event-Driven — Adoption Guide
-
-> **Bilingual Navigation:** [English](./adoption.md) | [Español](./adoption.es.md)
-
-**Owner:** Architecture Board
-**Topology:** Event-Driven
-
-## Purpose
-
-Define entry criteria, setup procedures, and adoption checklists for teams adopting event-driven architecture: event catalog setup, producer/consumer contracts, and readiness validation.
-
-## Entry Criteria
-
-Before adopting event-driven patterns, verify:
-
-- At least one asynchronous use case is identified (e.g., cross-domain notification, eventual consistency requirement).
-- Team has access to a message broker (managed or self-hosted).
-- Team understands event-driven tradeoffs vs. synchronous alternatives.
-- Schema registry infrastructure is available or planned.
-
-## Event Catalog Setup
-
-- Create catalog entry for each event type with: name, domain, owner, schema version, retention policy.
-- Assign a domain owner responsible for schema changes and deprecation.
-- Publish catalog to a discoverable location (wiki, portal, or code repository).
-
-## Producer Contracts — ED-R01
-
-- Register AsyncAPI specification for every event type before first publication.
-- Define required and optional fields with types and defaults.
-- Include event metadata: event-id, event-version, timestamp, correlation-id.
-
-## Consumer Contracts — ED-R05
-
-- Declare expected event types and schema versions in consumer registration.
-- Document idempotency strategy and deduplication window.
-- Define lag tolerance and alert thresholds for the consumer.
-
-## Readiness Checklist
-
-- [ ] AsyncAPI specification registered in schema registry
-- [ ] Event catalog entry created with owner and retention
-- [ ] Producer implements schema validation before publish
-- [ ] Consumer implements idempotent processing
-- [ ] DLQ routing configured with retry policy
-- [ ] Monitoring dashboards created for lag and throughput
-- [ ] Runbooks documented for failure scenarios
-- [ ] Team trained on event-driven patterns and tradeoffs
-
-## Composable Applicability
-
-| Composable | Guidance |
-|---|---|
-| Modular Monolith | Lightweight catalog; embedded broker; intra-process event validation. |
-| Distributed Modules | Shared catalog; cross-module contract review required. |
-| Microservices | Full catalog with domain ownership; per-service contract registration. |
-| Serverless | Platform-managed catalog; contract enforcement via platform policies. |
-| Edge Computing | Local catalog with cloud sync; simplified contract for edge constraints. |
-
-## ADR References
-
-- **ADR-0015**: Event catalog and producer contract standards.
-- **ADR-0079**: Consumer contract and readiness requirements.
-
----
-
-[Back to Event-Driven Profile](./README.md)

package/rulesets/topologies/event-driven/cli/cli-flows.es.md

@@ -1,41 +0,0 @@
-# Event-Driven — Flujos CLI
-
-> **Navegación Bilingüe:** [English Version](./cli-flows.md)
-
-**Validadores declarados:** `validate-architecture`, `validate-topology`
-
-## Validate
-
-```bash
-evolith validate --topology event-driven
-evolith validate --topology event-driven --arch-level F2
-evolith validate --topology event-driven --format json
-```
-
-## Inspect
-
-```bash
-evolith topology inspect event-driven
-evolith topology inspect event-driven --include-channels
-```
-
-## Drift
-
-```bash
-evolith drift detect --topology event-driven
-evolith drift detect --topology event-driven --format json
-```
-
-## Scaffold
-
-```bash
-evolith architecture scaffold --topology event-driven
-evolith architecture scaffold --topology event-driven --dry-run
-```
-
-## Gate Evaluation
-
-```bash
-evolith gate evaluate --topology event-driven
-evolith gate evaluate --topology event-driven --phase F1
-```