@evolith/core-domain 1.0.0 → 1.0.1

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

@@ -0,0 +1,218 @@
+# 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

@@ -0,0 +1,13 @@
+{
+  "$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

@@ -0,0 +1,113 @@
+{
+  "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

@@ -0,0 +1,71 @@
+# 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

@@ -0,0 +1,71 @@
+# 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

@@ -0,0 +1,67 @@
+# 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

@@ -0,0 +1,67 @@
+# 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

@@ -0,0 +1,41 @@
+# 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
+```