npm - @evolith/core-domain - Versions diffs - 1.0.1 → 1.0.3 - Mend

@evolith/core-domain 1.0.1 → 1.0.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (502) hide show

package/rulesets/topologies/data-mesh/runbooks.es.md DELETED Viewed

@@ -1,147 +0,0 @@
-# Guía de Libretas de Operaciones de Malla de Datos
-> **Navegación Bilingüe:** [English](./runbooks.md) | [Español](./runbooks.es.md)
-**Propietario:** Arquitectura de Datos
-**Topología:** Malla de Datos
-**Reglas Relacionadas:** DAM-R02, DAM-R07, DAM-R08
-## Propósito
-Esta guía proporciona libretas de operaciones para escenarios comunes de malla de datos. Cada libreta define procedimientos paso a paso para una tarea operativa específica, incluyendo puntos de decisión, pasos de reversión y comandos de validación.
-## Libreta 1 — Despliegue de Producto de Datos
-### Disparador
-El equipo de dominio ha completado el diseño del producto y está listo para publicar.
-### Procedimiento
-1. Validar esquema contra reglas de compatibilidad backward según DAM-R08.
-2. Verificar que los SLAs de calidad estén declarados y dentro de umbrales de la plataforma.
-3. Confirmar que las políticas de acceso estén publicadas y ejecutables.
-4. Registrar producto en índice de descubrimiento según DAM-R09.
-5. Ejecutar validación de plataforma: `node .harness/scripts/ci/01-validate-docs.mjs --target data-mesh`
-6. Publicar producto y verificar actualización del índice de descubrimiento.
-7. Notificar a consumidores registrados de la disponibilidad.
-### Reversión
-Si la publicación falla: eliminar producto del índice de descubrimiento, revertir metadatos de la plataforma, notificar a partes interesadas.
-### Validación
-- Producto visible en catálogo de descubrimiento
-- Versión de esquema coincide con versión registrada
-- Políticas de acceso ejecutadas en tiempo de consulta
----
-## Libreta 2 — Evolución de Esquemas
-### Disparador
-El equipo de dominio necesita modificar el esquema de un producto publicado.
-### Procedimiento
-1. Clasificar el cambio: aditivo (no rupturante) o eliminación/renombrado (rupturante).
-2. Para cambios aditivos: actualizar esquema, registrar nueva versión, mantener compatibilidad backward según DAM-R08.
-3. Para cambios rupturantes: crear plan de deprecación con cronograma de notificación a consumidores.
-4. Actualizar metadatos del producto con nueva versión de esquema.
-5. Ejecutar validación: `node .harness/scripts/ci/01-validate-docs.mjs --target data-mesh`
-6. Publicar esquema actualizado y notificar a consumidores.
-7. Monitorear progreso de migración de consumidores.
-### Reversión
-Revertir a versión de esquema anterior. Notificar a consumidores de la reversión. Investigar causa raíz.
-### Validación
-- Versión anterior de esquema accesible durante ventana de deprecación
-- Contratos de consumidor actualizados o migración completa
-- Sin fallos de consulta contra nuevo esquema
----
-## Libreta 3 — Respuesta a Incidentes de Calidad
-### Disparador
-Una verificación de salud automatizada falla o un consumidor reporta un problema de calidad.
-### Procedimiento
-1. Acknowledger incidente en sistema de monitoreo de la plataforma.
-2. Identificar productos afectados y consumidores downstream.
-3. Evaluar severidad: crítico (SLA de consumidor impactado), estándar (calidad degradada), bajo (problema cosmético).
-4. Para incidentes críticos: activar estrategias de respaldo según contratos de consumidor.
-5. Investigar causa raíz: fallo de flujo, deriva de esquema, corrupción de datos fuente.
-6. Implementar corrección: reinicio de flujo, corrección de datos, reversión de esquema.
-7. Validar corrección: re-ejecutar verificaciones de salud, verificar completitud y frescura de datos.
-8. Documentar incidente y post-mortem.
-### Reversión
-Si la corrección introduce nuevos problemas: revertir cambios, restaurar desde backup, re-activar respaldos de consumidor.
-### Validación
-- Verificación de salud vuelve a estado de aprobación
-- SLAs de consumidor restaurados
-- Incidente documentado con causa raíz
----
-## Libreta 4 — Migración de Contrato de Consumidor
-### Disparador
-Un consumidor necesita migrar a una nueva versión de esquema o producto.
-### Procedimiento
-1. Identificar versión actual del contrato del consumidor y dependencias.
-2. Revisar guía de migración publicada por el dominio productor.
-3. Actualizar aplicación del consumidor para soportar nueva versión de esquema.
-4. Probar con consultas de validación contra versiones antigua y nueva.
-5. Actualizar registro de contrato de consumo en plataforma.
-6. Monitorear consultas del consumidor por errores durante transición.
-7. Descontinuar uso de versión antigua después de ventana de migración.
-### Reversión
-Revertir aplicación del consumidor a versión anterior de esquema. Restaurar contrato de consumo anterior.
-### Validación
-- Consultas del consumidor exitosas contra nuevo esquema
-- Sin regresiones de calidad de datos
-- Contrato de consumo actualizado en plataforma
----
-## Libreta 5 — Remediación de Vacíos de Linaje
-### Disparador
-La validación de linaje descubre documentación faltante aguas arriba o abajo.
-### Procedimiento
-1. Identificar el vacío de linaje: fuente aguas arriba faltante, consumidor aguas abajo faltante o transformación no documentada.
-2. Contactar equipos de dominio para información de linaje faltante.
-3. Actualizar metadatos de linaje en la plataforma.
-4. Validar completitud del linaje: `node .harness/scripts/ci/01-validate-docs.mjs --target data-mesh`
-5. Verificar que el linaje refleje el flujo real de datos.
-6. Documentar excepciones o limitaciones del linaje.
-### Reversión
-Revertir metadatos de linaje a estado anterior si las actualizaciones introducen errores.
-### Validación
-- Gráfico de linaje completo para productos afectados
-- Sin flujos de datos huérfanos
-- Metadatos de linaje coinciden con topología real de flujos
----
-## Comandos de Validación
-```bash
-# Validar procedimientos de libretas
-node .harness/scripts/ci/01-validate-docs.mjs --target data-mesh
-# Verificar paridad bilingüe
-node .harness/scripts/ci/04-check-bilingual-parity.mjs
-# Ejecutar panel de cobertura
-node .harness/scripts/coverage-dashboard.mjs --area data-mesh
-```
----
-[Volver al Perfil de Malla de Datos](./README.es.md)

package/rulesets/topologies/data-mesh/runbooks.md DELETED Viewed

@@ -1,147 +0,0 @@
-# Data Mesh — Runbooks Guide
-> **Bilingual Navigation:** [English](./runbooks.md) | [Español](./runbooks.es.md)
-**Owner:** Data Architecture
-**Topology:** Data Mesh
-**Related Rules:** DAM-R02, DAM-R07, DAM-R08
-## Purpose
-This guide provides operational runbooks for common data mesh scenarios. Each runbook defines step-by-step procedures for a specific operational task, including decision points, rollback steps, and validation commands.
-## Runbook 1 — Data Product Deployment
-### Trigger
-Domain team has completed product design and is ready to publish.
-### Procedure
-1. Validate schema against backward-compatibility rules per DAM-R08.
-2. Verify quality SLOs are declared and within platform thresholds.
-3. Confirm access policies are published and enforceable.
-4. Register product in discovery index per DAM-R09.
-5. Run platform validation: `node .harness/scripts/ci/01-validate-docs.mjs --target data-mesh`
-6. Publish product and verify discovery index update.
-7. Notify registered consumers of availability.
-### Rollback
-If publication fails: remove product from discovery index, revert platform metadata, notify stakeholders.
-### Validation
-- Product visible in discovery catalog
-- Schema version matches registered version
-- Access policies enforced at query time
----
-## Runbook 2 — Schema Evolution
-### Trigger
-Domain team needs to modify a published product schema.
-### Procedure
-1. Classify the change: additive (non-breaking) or removal/rename (breaking).
-2. For additive changes: update schema, register new version, maintain backward compatibility per DAM-R08.
-3. For breaking changes: create deprecation plan with consumer notification timeline.
-4. Update product metadata with new schema version.
-5. Run validation: `node .harness/scripts/ci/01-validate-docs.mjs --target data-mesh`
-6. Publish updated schema and notify consumers.
-7. Monitor consumer migration progress.
-### Rollback
-Revert to previous schema version. Notify consumers of rollback. Investigate root cause.
-### Validation
-- Previous schema version still accessible during deprecation window
-- Consumer contracts updated or migration complete
-- No query failures against new schema
----
-## Runbook 3 — Quality Incident Response
-### Trigger
-Automated health check fails or consumer reports quality issue.
-### Procedure
-1. Acknowledge incident in platform monitoring system.
-2. Identify affected products and downstream consumers.
-3. Assess severity: critical (consumer SLA impacted), standard (degraded quality), low (cosmetic issue).
-4. For critical incidents: activate fallback strategies per consumer contracts.
-5. Investigate root cause: pipeline failure, schema drift, source data corruption.
-6. Implement fix: pipeline restart, data correction, schema rollback.
-7. Validate fix: re-run health checks, verify data completeness and freshness.
-8. Document incident and post-mortem.
-### Rollback
-If fix introduces new issues: revert changes, restore from backup, re-activate consumer fallbacks.
-### Validation
-- Health check returns to passing state
-- Consumer SLAs restored
-- Incident documented with root cause
----
-## Runbook 4 — Consumer Contract Migration
-### Trigger
-Consumer needs to migrate to a new schema version or product.
-### Procedure
-1. Identify consumer's current contract version and dependencies.
-2. Review migration guide published by the producing domain.
-3. Update consumer application to support new schema version.
-4. Test with validation queries against both old and new versions.
-5. Update consumption contract registration in platform.
-6. Monitor consumer queries for errors during transition.
-7. Decommission old version usage after migration window.
-### Rollback
-Revert consumer application to previous schema version. Restore previous consumption contract.
-### Validation
-- Consumer queries succeed against new schema
-- No data quality regressions
-- Consumption contract updated in platform
----
-## Runbook 5 — Lineage Gap Remediation
-### Trigger
-Lineage validation discovers missing upstream or downstream documentation.
-### Procedure
-1. Identify the lineage gap: missing upstream source, missing downstream consumer, or undocumented transformation.
-2. Contact domain teams for missing lineage information.
-3. Update lineage metadata in the platform.
-4. Validate lineage completeness: `node .harness/scripts/ci/01-validate-docs.mjs --target data-mesh`
-5. Verify lineage reflects actual data flow.
-6. Document any lineage exceptions or limitations.
-### Rollback
-Revert lineage metadata to previous state if updates introduce errors.
-### Validation
-- Lineage graph complete for affected products
-- No orphaned data flows
-- Lineage metadata matches actual pipeline topology
----
-## Validation Commands
-```bash
-# Validate runbook procedures
-node .harness/scripts/ci/01-validate-docs.mjs --target data-mesh
-# Check bilingual parity
-node .harness/scripts/ci/04-check-bilingual-parity.mjs
-# Run coverage dashboard
-node .harness/scripts/coverage-dashboard.mjs --area data-mesh
-```
----
-[Back to Data Mesh Profile](./README.md)

package/rulesets/topologies/data-mesh/security.es.md DELETED Viewed

@@ -1,66 +0,0 @@
-# Guía de Seguridad de Malla de Datos
-> **Navegación Bilingüe:** [English](./security.md) | [Español](./security.es.md)
-**Propietario:** Arquitectura de Datos
-**Topología:** Malla de Datos
-**Reglas Relacionadas:** DAM-R03, DAM-R05
-**ADRs Relacionados:** ADR-0079
-## Propósito
-Esta guía establece las prácticas de seguridad para los productos de datos en una topología de malla. Cubre clasificación, control de acceso, manejo de PII, gobernanza federada, residencia de datos y encriptación. La seguridad es una responsabilidad federada — cada dominio aplica controles en sus productos mientras adhiere a estándares corporativos.
-## Clasificación de Datos
-Todos los productos de datos deben clasificarse antes de la publicación. La clasificación determina los controles de acceso, las políticas de retención y los requisitos de cumplimiento. La plataforma de autoservicio aplica metadatos de clasificación en el momento del registro.
-### Niveles de Clasificación
-- **Público:** Sin restricciones de acceso. Distribución externa permitida.
-- **Interno:** Acceso limitado a usuarios autenticados de la organización.
-- **Confidencial:** Acceso restringido a roles específicos. Registro de auditoría requerido.
-- **Restringido:** Máxima sensibilidad. Encriptación en reposo y en tránsito obligatoria. El acceso requiere aprobación explícita.
-## Control de Acceso por Producto
-Cada producto de datos define sus propias políticas de acceso dentro del marco de gobernanza federada. Las políticas especifican qué roles, equipos o servicios pueden consumir el producto. La plataforma aplica las políticas en tiempo de consulta; los dominios las definen en tiempo de diseño.
-Los equipos de dominio deben publicar políticas de acceso junto con los metadatos de su producto. Las políticas se versionan y están sujetas a los mismos requisitos de compatibilidad backward que los esquemas según DAM-R08.
-## Manejo de PII
-Los productos que contienen información de identificación personal deben declarar los campos PII en su esquema. La plataforma aplica enmascaramiento y tokenización según el nivel de autorización del consumidor. Los datos PII nunca deben aparecer en metadatos del índice de descubrimiento ni en vistas previas de productos.
-Los equipos de dominio son responsables de mantener el registro PII y asegurar el cumplimiento con las regulaciones aplicables de protección de datos. Los campos PII requieren justificación explícita del consumidor para acceso sin enmascaramiento.
-## Seguridad de Gobernanza Federada
-La gobernanza federada proporciona la base de seguridad en todos los dominios. El órgano central de gobernanza define estándares mínimos de seguridad; los dominios los implementan dentro de los límites de sus productos. Las excepciones de seguridad requieren aprobación formal del consejo de gobernanza.
-El intercambio de datos entre dominios requiere autenticación y autorización mutuas. La plataforma media todo el acceso interdominio a través de su capa de ejecución de políticas.
-## Residencia de Datos
-Los productos de datos deben declarar su residencia geográfica. La plataforma aplica restricciones de residencia en tiempo de ingesta y consulta. Las transferencias de datos transfronterizas requieren configuración explícita y documentación de cumplimiento.
-Los equipos de dominio deben coordinar con el consejo de gobernanza para asegurar que las declaraciones de residencia se alineen con los requisitos regulatorios y la política corporativa.
-## Encriptación
-Todos los productos de datos deben encriptar datos en reposo usando los estándares organizacionales de gestión de claves. Los productos clasificados como Restringido o Confidencial requieren encriptación en tránsito usando TLS 1.2 o superior. La rotación de claves sigue el calendario centralizado de gestión de claves.
-Los equipos de dominio gestionan la configuración de encriptación a través de la plataforma de autoservicio. El estado de encriptación es auditable y se publica como parte de los metadatos de salud del producto.
-## Comandos de Validación
-```bash
-# Verificar completitud de metadatos de seguridad
-node .harness/scripts/ci/01-validate-docs.mjs --target data-mesh
-# Verificar paridad bilingüe
-node .harness/scripts/ci/04-check-bilingual-parity.mjs
-```
----
-[Volver al Perfil de Malla de Datos](./README.es.md)

package/rulesets/topologies/data-mesh/security.md DELETED Viewed

@@ -1,66 +0,0 @@
-# Data Mesh — Security Guide
-> **Bilingual Navigation:** [English](./security.md) | [Español](./security.es.md)
-**Owner:** Data Architecture
-**Topology:** Data Mesh
-**Related Rules:** DAM-R03, DAM-R05
-**Related ADRs:** ADR-0079
-## Purpose
-This guide establishes security practices for data products in a mesh topology. It covers classification, access control, PII handling, federated governance, data residency, and encryption. Security is a federated responsibility — each domain enforces controls on its products while adhering to corporate standards.
-## Data Classification
-All data products must be classified before publication. Classification determines access controls, retention policies, and compliance requirements. The self-serve platform enforces classification metadata at registration time.
-### Classification Tiers
-- **Public:** No access restrictions. External distribution permitted.
-- **Internal:** Access limited to authenticated organizational users.
-- **Confidential:** Access restricted to specific roles. Audit logging required.
-- **Restricted:** Highest sensitivity. Encryption at rest and in transit mandatory. Access requires explicit approval.
-## Access Control per Product
-Each data product defines its own access policies within the federated governance framework. Policies specify which roles, teams, or services may consume the product. The platform enforces policies at query time; domains define them at design time.
-Domain teams must publish access policies alongside their product metadata. Policies are versioned and subject to the same backward-compatibility requirements as schemas per DAM-R08.
-## PII Handling
-Products containing personally identifiable information must declare PII fields in their schema. The platform applies masking and tokenization based on consumer clearance level. PII data must never appear in discovery index metadata or product previews.
-Domain teams are responsible for maintaining the PII registry and ensuring compliance with applicable data protection regulations. PII fields require explicit consumer justification for unmasked access.
-## Federated Governance Security
-Federated governance provides the security baseline across all domains. The central governance body defines minimum security standards; domains implement them within their product boundaries. Security exceptions require formal approval from the governance council.
-Cross-domain data sharing requires mutual authentication and authorization. The platform mediates all cross-domain access through its policy enforcement layer.
-## Data Residency
-Data products must declare their geographic residency. The platform enforces residency constraints at ingestion and query time. Cross-border data transfers require explicit configuration and compliance documentation.
-Domain teams must coordinate with the governance council to ensure residency declarations align with regulatory requirements and corporate policy.
-## Encryption
-All data products must encrypt data at rest using organizational key management standards. Products classified as Restricted or Confidential require encryption in transit using TLS 1.2 or higher. Key rotation follows the centralized key management schedule.
-Domain teams manage encryption configuration through the self-serve platform. Encryption status is auditable and published as part of product health metadata.
-## Validation Commands
-```bash
-# Verify security metadata completeness
-node .harness/scripts/ci/01-validate-docs.mjs --target data-mesh
-# Check bilingual parity
-node .harness/scripts/ci/04-check-bilingual-parity.mjs
-```
----
-[Back to Data Mesh Profile](./README.md)

package/rulesets/topologies/data-mesh/topology.config.schema.json DELETED Viewed

@@ -1,30 +0,0 @@
-{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "title": "Data Mesh Topology Configuration",
-  "type": "object",
-  "additionalProperties": false,
-  "required": [
-    "topology",
-    "isDataProduct",
-    "hasDataContracts",
-    "federatedGovernance",
-    "hasLineageTracking",
-    "hasRetentionPolicy",
-    "hasConsumptionContracts",
-    "hasDataQualitySLO",
-    "hasBackwardCompatibleContracts",
-    "hasDiscoveryRegistration"
-  ],
-  "properties": {
-    "topology": { "const": "data-mesh" },
-    "isDataProduct": { "const": true },
-    "hasDataContracts": { "const": true },
-    "federatedGovernance": { "const": true },
-    "hasLineageTracking": { "const": true },
-    "hasRetentionPolicy": { "const": true },
-    "hasConsumptionContracts": { "const": true },
-    "hasDataQualitySLO": { "const": true },
-    "hasBackwardCompatibleContracts": { "const": true },
-    "hasDiscoveryRegistration": { "const": true }
-  }
-}

package/rulesets/topologies/data-mesh/topology.manifest.json DELETED Viewed

@@ -1,107 +0,0 @@
-{
-  "apiVersion": "evolith.dev/topology/v1",
-  "kind": "TopologyManifest",
-  "metadata": {
-    "id": "data-mesh",
-    "name": "Data Mesh",
-    "dimension": "data",
-    "status": "accepted",
-    "version": "1.0.0",
-    "governance": {
-      "owner": "Data Architecture",
-      "criticality": "P1"
-    }
-  },
-  "spec": {
-    "summary": "Distributed analytical data ownership topology for governed data products, discoverable contracts, quality evidence, and domain-aligned interoperability.",
-    "topologyType": "data-mesh",
-    "compatibility": {
-      "progressiveAxis": {
-        "phase": "cross",
-        "profile": "cross"
-      },
-      "composableWith": [
-        "distributed-modules",
-        "microservices",
-        "event-driven",
-        "serverless",
-        "agentic-ai"
-      ]
-    },
-    "artifacts": {
-      "adrs": [
-        "reference/architecture/adrs/core/0084-data-mesh-data-products.md",
-        "reference/architecture/adrs/core/0079-multi-topology-reference-corpus.md"
-      ],
-      "rulesets": [
-        "rulesets/topologies/data-mesh/data-mesh.rules.json"
-      ],
-      "opaPolicies": [
-        "rulesets/topologies/data-mesh/data-mesh.rego"
-      ],
-      "aiRulesets": [
-        "rulesets/topologies/data-mesh/README.md"
-      ],
-      "umsContracts": [
-        "reference/knowledge/demo/ums-reference-model.md"
-      ]
-    },
-    "corpus": {
-      "guidance": {
-        "profile": "rulesets/topologies/data-mesh/README.md",
-        "maturityGuide": "rulesets/topologies/data-mesh/maturity.md"
-      },
-      "configurationContract": "rulesets/topologies/data-mesh/topology.config.schema.json",
-      "fixtures": {
-        "valid": "rulesets/topologies/data-mesh/fixtures/valid.topology.config.json",
-        "invalid": "rulesets/topologies/data-mesh/fixtures/invalid.topology.config.json"
-      },
-      "nativeEvaluator": "packages/core-domain/src/application/validators/ruleset-validator.service.ts",
-      "tests": {
-        "positive": "packages/core-domain/src/application/validators/ruleset-validator-architecture.spec.ts",
-        "negative": "packages/core-domain/src/application/validators/ruleset-validator-architecture.spec.ts"
-      },
-      "evidence": "reference/governance/standards/vision/maturity-evidence.json"
-    },
-    "operationalInterfaces": {
-      "cli": {
-        "validators": [
-          "validate-architecture",
-          "validate-topology"
-        ]
-      },
-      "mcp": {
-        "resources": [
-          "evolith://topologies/data-mesh/manifest",
-          "evolith://topologies/data-mesh/rulesets"
-        ],
-        "tools": [
-          "evolith-topology-inspect",
-          "evolith-topology-validate"
-        ],
-        "prompts": [
-          "topology-aware-implementation"
-        ]
-      },
-      "coreApi": {
-        "endpoints": [
-          "GET /topologies/{id}",
-          "GET /topologies/{id}/manifest",
-          "POST /topologies/{id}/validate"
-        ]
-      }
-    }
-  },
-  "businessBoundary": {
-    "technicalOnly": true,
-    "trackerOwns": [
-      "timing",
-      "ownership",
-      "prioritization",
-      "roi",
-      "cost",
-      "budget",
-      "funnel-0"
-    ]
-  }
-}

package/rulesets/topologies/edge-computing/README.es.md DELETED Viewed

@@ -1,81 +0,0 @@
-# Perfil Topologico Edge Computing
-> **Navegacion Bilingue:** [English Version](./README.md)
-**Estado:** Accepted
-**Dimension:** `execution`
-**ID de Topologia:** `edge-computing`
-**Alias de Compatibilidad:** `F2-compatible`
-**Manifiesto:** [topology.manifest.json](./topology.manifest.json)
-Edge computing es una topologia de ejecucion para workloads que deben correr cerca de usuarios, dispositivos, regiones o fronteras de red restringidas mientras permanecen gobernados por los mismos contratos arquitectonicos de Evolith Core.
-## Proposito
-Usa esta topologia cuando latencia, localidad, tolerancia offline, ubicacion regulatoria o procesamiento cercano a dispositivos requiere ejecucion fuera del runtime central.
-Los workloads edge deben permanecer gobernados por reglas explicitas de sincronizacion, seguridad, observabilidad, despliegue y frontera de datos. La ubicacion edge no autoriza duplicar logica de dominio sin ownership.
-## Reglas de Gobernanza
-| Regla | Requisito |
-|---|---|
-| Razon de localidad | La ubicacion edge debe justificarse por latencia, resiliencia, localidad o restricciones regulatorias. |
-| Sincronizacion | La sincronizacion de estado debe ser explicita, observable y consciente de conflictos. |
-| Seguridad | Los nodos edge deben aplicar autenticacion, autorizacion y manejo de secretos apropiados para entornos restringidos. |
-| Observability | Los workloads edge deben reportar salud, fallo y trace context pese a conectividad intermitente. |
-| Ownership de dominio | La logica edge no debe bifurcar comportamiento de dominio fuera del bounded context propietario. |
-## Autoridad Requerida
-| Artefacto | Rol |
-|---|---|
-| [ADR-0079: Corpus de Referencia Multi-Topologia](../../../adrs/core/0079-multi-topology-reference-corpus.md) | Gobierna los manifiestos de topologia y composicion. |
-| [ADR-0096: Gobernanza de Arquitectura Edge Computing](../../../adrs/core/0096-edge-computing-architecture-governance.md) | Gobierna las restricciones arquitectonicas especificas de edge. |
-| [Reglas de Arquitectura Edge Computing](./edge-computing.rules.json) | Reglas de compatibilidad ejecutables existentes. |
-| [Modelo de Dimensiones de Topologia](../../topology-dimensions.md) | Define reglas de composicion y compatibilidad. |
-## Contrato Ejecutable
-Los satelites que adopten esta topologia deben declarar un archivo `edge-computing.config.json` en su raiz. Este JSON actua como el contrato ejecutable machine-readable evaluado por el Evolith Governance Engine.
-```json
-{
-  "syncStrategy": "offline-first",
-  "edgeIsolation": true,
-  "conflictResolution": "last-write-wins"
-}
-```
-EC-R01 a EC-R03 exigen ese contrato, forzando una estrategia de sincronizacion declarada, aislamiento de nodo edge para operacion autonoma y un modo explicito de resolucion de conflictos. El evaluador Native y la [politica OPA](./edge-computing.rego) evaluan estos campos.
-### Patrones de Persistencia Offline-First
-Un aspecto critico de la topologia Edge Computing es manejar la conectividad intermitente. Para cumplir con `EC-R01` (Estrategia de Sincronizacion Obligatoria) y `EC-R03` (Resolucion de Conflictos), los nodos edge deben implementar patrones de persistencia offline-first:
-1.  **Lecturas y Escrituras Local-First:** Usa bases de datos locales (ej. SQLite, IndexedDB) como el data store primario para el workload edge. Esto asegura que la aplicacion permanezca completamente funcional durante particiones de red (`edgeIsolation: true`).
-2.  **Sincronizacion en Background:** Utiliza workers en background o service workers para sincronizar los cambios locales con el plano de control central cuando se restaura la conectividad.
-3.  **Resolucion de Conflictos:** Declara y maneja explicitamente los conflictos de estado resultantes de modificaciones offline (ej. `last-write-wins`, fusion manual).
-## Composicion
-`edge-computing` puede combinarse con:
-| Topologia | Por Que Puede Componerse |
-|---|---|
-| `microservices` | Ubica workloads de servicio individual en el edge con sincronizacion gobernada. |
-| `distributed-modules` | Extiende fronteras de modulo a ubicaciones edge con contratos de sincronizacion explicitos. |
-| `event-driven` | Coordina cambios de estado edge a traves de canales de eventos observables. |
-| `serverless` | Despliega unidades de ejecucion administradas en ubicaciones edge con inicializacion acotada. |
-| `agentic-ai` | Ejecuta inferencia de agentes IA en el edge con gobernanza offline. |
-## Frontera de Negocio
-Este perfil es solo tecnico. No define ROI, modelo de costos, gasto de hardware, staffing, timing de entrega, priorizacion ni Funnel 0. Evolith Tracker posee esas preocupaciones de negocio mediante su ACL.
-## Presupuestos Operativos
-Esta topología declara envelopes arquitectónicos de latencia, cold-start y costo por ejecución en `spec.operationalBudgets` de [`topology.manifest.json`](./topology.manifest.json). Los operadores verifican los satélites contra estos envelopes siguiendo el [Runbook de Presupuestos Operativos](../operational-budgets-runbook.es.md) compartido.
----
-[Volver al Hub de Topologias](../../README.es.md)