@evolith/core-domain 1.0.1 → 1.0.2

package/rulesets/topologies/serverless/README.es.md

@@ -1,74 +0,0 @@
-# Perfil Topologico Serverless
-
-> **Navegacion Bilingue:** [English Version](./README.md)
-
-**Estado:** Accepted  
-**Dimension:** `execution`  
-**ID de Topologia:** `serverless`  
-**Alias de Compatibilidad:** `F1-compatible`  
-**Manifiesto:** [topology.manifest.json](./topology.manifest.json)
-
-Serverless es una topologia de ejecucion para workloads administrados y escalados por eventos donde la plataforma posee el aprovisionamiento runtime y Evolith Core gobierna contratos, observabilidad, seguridad, idempotencia y fronteras de integracion.
-
-## Proposito
-
-Usa esta topologia para capacidades aisladas que se benefician de escalamiento administrado, triggers de eventos, jobs programados, procesamiento asincrono o workloads con picos sin introducir una topologia de servicio separada.
-
-Serverless no reemplaza la arquitectura de dominio. Se compone con `modular-monolith`, `distributed-modules` o `microservices` cuando el manifiesto y la revision arquitectonica permiten la frontera de ejecucion.
-
-## Reglas de Gobernanza
-
-| Regla | Requisito |
-|---|---|
-| Idempotencia | Los handlers disparados por eventos deben tolerar reintentos y entrega duplicada. |
-| Contratos | Entradas, salidas, eventos y dependencias externas deben versionarse explicitamente. |
-| Observabilidad | Cada funcion o workflow administrado debe emitir evidencia trazable y senales de fallo. |
-| Control de frontera | Los handlers serverless no deben saltarse ownership de dominio ni fronteras de persistencia. |
-| Neutralidad de proveedor | La guia Core permanece neutral respecto del proveedor; las selecciones de proveedor pertenecen a perfiles de producto o plataforma. |
-
-## 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-0095: Gobernanza de Arquitectura Serverless](../../../adrs/core/0095-serverless-architecture-governance.md) | Gobierna las restricciones arquitectonicas especificas de serverless. |
-| [Reglas de Arquitectura Serverless](./serverless.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 `serverless.config.json`:
-
-```json
-{
-  "stateless": true,
-  "package": { "maxSizeMb": 25 },
-  "coldStart": { "maxInitMilliseconds": 500, "lazyInitialization": true }
-}
-```
-
-SV-R01 a SV-R04 exigen ese contrato, ejecucion sin estado, un paquete no mayor de 50 MB e inicializacion diferida acotada. El evaluador Native y la [politica OPA](./serverless.rego) evalúan los mismos campos.
-
-## Composicion
-
-`serverless` puede combinarse con:
-
-| Topologia | Por Que Puede Componerse |
-|---|---|
-| `modular-monolith` | Agrega puntos de ejecucion administrados sin forzar extraccion completa de servicios. |
-| `distributed-modules` | Permite handlers serverless dentro de fronteras de modulo controladas. |
-| `microservices` | Soporta funciones de servicio individual con ejecucion escalada por eventos. |
-| `event-driven` | Habilita handlers serverless disparados por eventos gobernados por contratos. |
-| `data-mesh` | Proporciona ejecucion de productos de datos analiticos sin acoplamiento transaccional. |
-| `agentic-ai` | Aloja workflows de agentes IA gobernados por contexto MCP y rulesets. |
-
-## Frontera de Negocio
-
-Este perfil es solo tecnico. No define ROI, modelo de costos, gasto cloud, 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)

package/rulesets/topologies/serverless/README.md

@@ -1,74 +0,0 @@
-# Serverless Topology Profile
-
-> **Bilingual Navigation:** [Version en Espanol](./README.es.md)
-
-**Status:** Accepted  
-**Dimension:** `execution`  
-**Topology ID:** `serverless`  
-**Compatibility Alias:** `F1-compatible`  
-**Manifest:** [topology.manifest.json](./topology.manifest.json)
-
-Serverless is an execution topology for managed, event-scaled workloads where the platform owns runtime provisioning and Evolith Core governs contracts, observability, security, idempotency, and integration boundaries.
-
-## Purpose
-
-Use this topology for isolated capabilities that benefit from managed scaling, event triggers, scheduled jobs, asynchronous processing, or bursty workloads without introducing a separately owned service topology.
-
-Serverless does not replace domain architecture. It composes with `modular-monolith`, `distributed-modules`, or `microservices` when the manifest and architecture review allow the execution boundary.
-
-## Governance Rules
-
-| Rule | Requirement |
-|---|---|
-| Idempotency | Event-triggered handlers must tolerate retries and duplicate delivery. |
-| Contracts | Inputs, outputs, events, and external dependencies must be explicitly versioned. |
-| Observability | Each function or managed workflow must emit traceable evidence and failure signals. |
-| Boundary control | Serverless handlers must not bypass domain ownership or persistence boundaries. |
-| Provider neutrality | Core guidance remains provider-neutral; provider choices belong to product or platform profiles. |
-
-## Required Authority
-
-| Artifact | Role |
-|---|---|
-| [ADR-0079: Multi-Topology Reference Corpus](../../../adrs/core/0079-multi-topology-reference-corpus.md) | Governs topology manifests and composition. |
-| [ADR-0095: Serverless Architecture Governance](../../../adrs/core/0095-serverless-architecture-governance.md) | Governs serverless-specific architecture constraints. |
-| [Serverless Architecture Rules](./serverless.rules.json) | Existing executable compatibility rules. |
-| [Topology Dimensions Model](../../topology-dimensions.md) | Defines composition and compatibility rules. |
-
-## Executable Contract
-
-Every adopting satellite provides `serverless.config.json`:
-
-```json
-{
-  "stateless": true,
-  "package": { "maxSizeMb": 25 },
-  "coldStart": { "maxInitMilliseconds": 500, "lazyInitialization": true }
-}
-```
-
-SV-R01 through SV-R04 require that contract, stateless execution, a package no larger than 50 MB, and bounded lazy initialization. The Native evaluator and [OPA policy](./serverless.rego) evaluate the same fields.
-
-## Composition
-
-`serverless` can combine with:
-
-| Topology | Why It Can Compose |
-|---|---|
-| `modular-monolith` | Adds managed execution points without forcing full service extraction. |
-| `distributed-modules` | Allows serverless handlers within controlled module boundaries. |
-| `microservices` | Supports individual service functions with event-scaled execution. |
-| `event-driven` | Enables event-triggered serverless handlers governed by contracts. |
-| `data-mesh` | Provides analytical data product execution without transactional coupling. |
-| `agentic-ai` | Hosts AI-agent workflows governed by MCP context and rulesets. |
-
-## Business Boundary
-
-This profile is technical-only. It does not define ROI, cost model, cloud spend, staffing, delivery timing, prioritization, or Funnel 0. Evolith Tracker owns those business concerns through its ACL.
-
-## Operational Budgets
-
-This topology declares architectural envelopes for latency, cold-start, and per-execution cost in `spec.operationalBudgets` of [`topology.manifest.json`](./topology.manifest.json). Operators verify satellites against these envelopes following the shared [Operational Budgets Runbook](../operational-budgets-runbook.md).
-
----
-[Back to Topology Hub](../../README.md)

package/rulesets/topologies/serverless/adoption.es.md

@@ -1,50 +0,0 @@
-# Guía de Adopción Sin Servidor
-
-> **Navegación Bilingüe:** [English](./adoption.md) | [Español](./adoption.es.md)
-
-**Propietario:** Ingeniería de Plataforma
-**Topología:** Sin Servidor
-
----
-
-## Criterios de Entrada
-
-Adoptar serverless cuando se cumplan todos los siguientes:
-
-- La carga de trabajo es orientada a eventos o esporádica con patrones de tráfico impredecibles
-- El presupuesto de latencia permite hasta 1500 ms por invocación
-- La tolerancia a inicio en frío es de al menos 1000 ms (SV-R04)
-- El equipo tiene experiencia con al menos la plataforma de funciones de un proveedor de nube
-- La organización acepta la dependencia de servicios gestionados
-
-No adoptar serverless para cargas de trabajo sostenidas de alto rendimiento que excedan los presupuestos de concurrencia o requieran latencia inferior a 100 ms.
-
-## Organización de Funciones
-
-Organizar funciones por contexto acotado. Cada contexto acotado posee sus funciones, eventos y datos. Mantener un catálogo de funciones con:
-
-- Nombre y propósito de la función
-- Equipo propietario
-- Tipo de disparador y esquema de eventos
-- SLA (latencia, tasa de error)
-- Presupuesto de costo por ejecución
-
-## Desarrollo Local
-
-Configurar emulación local para iteración rápida. Usar herramientas como SAM Local, Functions Framework o serverless-offline. Probar integración función-a-función en un entorno de staging. Mantener la emulación local alineada con configuraciones de producción.
-
-## Lista de Verificación de Preparación
-
-- [ ] Descomposición de funciones completa — cada función tiene una única responsabilidad
-- [ ] Roles IAM asignados con privilegio mínimo (SV-SEC-01)
-- [ ] DLQ configurada para todas las invocaciones asíncronas (SV-R01)
-- [ ] Paquetes de despliegue bajo 50 MB (SV-R03)
-- [ ] Perfilado de inicio en frío completado y dentro del presupuesto
-- [ ] Monitoreo y alertas configuradas según la guía de evidencia
-- [ ] Etiquetas de rastreo de costos aplicadas a todas las funciones
-- [ ] Neutralidad con el proveedor evaluada (ADR-0095)
-- [ ] Runbooks documentados para escenarios de fallo comunes
-
----
-
-[Volver al Perfil Sin Servidor](./README.es.md)

package/rulesets/topologies/serverless/adoption.md

@@ -1,50 +0,0 @@
-# Serverless — Adoption Guide
-
-> **Bilingual Navigation:** [English](./adoption.md) | [Español](./adoption.es.md)
-
-**Owner:** Platform Engineering
-**Topology:** Serverless
-
----
-
-## Entry Criteria
-
-Adopt serverless when all of the following are true:
-
-- Workload is event-driven or sporadic with unpredictable traffic patterns
-- Latency budget allows up to 1500 ms per invocation
-- Cold start tolerance is at least 1000 ms (SV-R04)
-- Team has experience with at least one cloud provider's function platform
-- Organization accepts managed-service dependency
-
-Do not adopt serverless for sustained high-throughput workloads that exceed concurrency budgets or require sub-100 ms latency.
-
-## Function Organization
-
-Organize functions by bounded context. Each bounded context owns its functions, events, and data. Maintain a function catalog with:
-
-- Function name and purpose
-- Owner team
-- Trigger type and event schema
-- SLA (latency, error rate)
-- Cost budget per execution
-
-## Local Development
-
-Set up local emulation for rapid iteration. Use tools like SAM Local, Functions Framework, or serverless-offline. Test function-to-function integration in a staging environment. Keep local emulation aligned with production configurations.
-
-## Readiness Checklist
-
-- [ ] Function decomposition complete — each function has a single responsibility
-- [ ] IAM roles assigned with least privilege (SV-SEC-01)
-- [ ] DLQ configured for all asynchronous invocations (SV-R01)
-- [ ] Deployment packages under 50 MB (SV-R03)
-- [ ] Cold start profiling completed and within budget
-- [ ] Monitoring and alerting configured per evidence guide
-- [ ] Cost tracking tags applied to all functions
-- [ ] Vendor neutrality assessed (ADR-0095)
-- [ ] Runbooks documented for common failure scenarios
-
----
-
-[Back to Serverless Profile](./README.md)

package/rulesets/topologies/serverless/cli/cli-flows.es.md

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

package/rulesets/topologies/serverless/cli/cli-flows.md

@@ -1,53 +0,0 @@
-# Serverless — CLI Flows
-
-> **Bilingual Navigation:** [Versión en Español](./cli-flows.es.md)
-
-**Validators declarados:** `validate-architecture`, `validate-topology`
-
-The following CLI commands are available for the Serverless topology.
-
-## Validate
-
-```bash
-evolith validate --topology serverless
-evolith validate --topology serverless --arch-level F2
-evolith validate --topology serverless --format json
-```
-
-Validates a Serverless configuration against the topology's native rules (`serverless.rules.json`) and OPA Rego policies (`serverless.rego`), checking cold-start tolerance, statelessness, timeout limits, and cost profile.
-
-## Inspect
-
-```bash
-evolith topology inspect serverless
-evolith topology inspect serverless --include-functions
-```
-
-Returns the parsed Serverless topology manifest, function definitions, trigger metadata, and corpus artifact references.
-
-## Drift
-
-```bash
-evolith drift detect --topology serverless
-evolith drift detect --topology serverless --format json
-```
-
-Detects configuration drift between the Serverless topology's declared ruleset and the current workspace state.
-
-## Scaffold
-
-```bash
-evolith architecture scaffold --topology serverless
-evolith architecture scaffold --topology serverless --dry-run
-```
-
-Scaffolds a Serverless topology workspace with the canonical corpus structure, manifest, config schema, and OPA policies.
-
-## Gate Evaluation
-
-```bash
-evolith gate evaluate --topology serverless
-evolith gate evaluate --topology serverless --phase F1
-```
-
-Evaluates Serverless phase gates, validating event-driven function isolation and stateless deployment readiness.

package/rulesets/topologies/serverless/evidence.es.md

@@ -1,66 +0,0 @@
-# Guía de Evidencia Sin Servidor
-
-> **Navegación Bilingüe:** [English](./evidence.md) | [Español](./evidence.es.md)
-
-**Propietario:** Ingeniería de Plataforma
-**Topología:** Sin Servidor
-
----
-
-## Comandos de Validación
-
-Ejecutar validación de infraestructura antes de cada despliegue:
-
-```bash
-# Validar configuraciones de funciones
-serverless validate --stage production
-
-# Verificar permisos de roles IAM
-aws iam simulate-principal-policy --policy-source-arn <function-arn>
-
-# Verificar configuración VPC
-aws ec2 describe-security-groups --filters Name=vpc-id,Values=<vpc-id>
-
-# Escanear paquetes de despliegue en busca de vulnerabilidades
-npm audit --production
-```
-
-## Métricas de Invocación
-
-Rastrear lo siguiente por función, por día:
-
-| Métrica | Objetivo | Umbral de Alerta |
-|---------|----------|------------------|
-| Latencia p50 | < 500 ms | > 800 ms |
-| Latencia p95 | < 1000 ms | > 1200 ms |
-| Latencia p99 | < 1500 ms | > 1500 ms |
-| Tasa de error | < 0.1% | > 0.5% |
-| Conteo de limitaciones | 0 | > 0 |
-
-## Mediciones de Inicio en Frío
-
-Muestrear tiempos de inicio en frío semanalmente. Registrar duración de init, duración de runtime y duración total. Comparar contra el presupuesto de 1000 ms de inicio en frío (SV-R04). Señalar cualquier función que exceda el presupuesto para optimización.
-
-## Reportes de Costos
-
-Generar reportes de costos semanales con:
-
-- Total de invocaciones por función
-- Tiempo total de computación (GB-segundos)
-- Costo por ejecución (objetivo: **1 centavo**)
-- Tendencia mes a mes
-- Funciones que exceden el presupuesto de costos
-
-## Evidencia de Cumplimiento
-
-Retener los siguientes artefactos para auditoría:
-
-- Asignaciones y registros de rotación de roles IAM
-- Registros de procesamiento de DLQ
-- Resultados de escaneo de vulnerabilidades de paquetes de despliegue
-- Historial de mediciones de inicio en frío
-- Reportes de rastreo de costos
-
----
-
-[Volver al Perfil Sin Servidor](./README.es.md)

package/rulesets/topologies/serverless/evidence.md

@@ -1,66 +0,0 @@
-# Serverless — Evidence Guide
-
-> **Bilingual Navigation:** [English](./evidence.md) | [Español](./evidence.es.md)
-
-**Owner:** Platform Engineering
-**Topology:** Serverless
-
----
-
-## Validation Commands
-
-Run infrastructure validation before every deployment:
-
-```bash
-# Validate function configurations
-serverless validate --stage production
-
-# Check IAM role permissions
-aws iam simulate-principal-policy --policy-source-arn <function-arn>
-
-# Verify VPC configuration
-aws ec2 describe-security-groups --filters Name=vpc-id,Values=<vpc-id>
-
-# Scan deployment packages for vulnerabilities
-npm audit --production
-```
-
-## Invocation Metrics
-
-Track the following per function, per day:
-
-| Metric | Target | Alert Threshold |
-|--------|--------|-----------------|
-| p50 latency | < 500 ms | > 800 ms |
-| p95 latency | < 1000 ms | > 1200 ms |
-| p99 latency | < 1500 ms | > 1500 ms |
-| Error rate | < 0.1% | > 0.5% |
-| Throttle count | 0 | > 0 |
-
-## Cold Start Measurements
-
-Sample cold start times weekly. Record init duration, runtime duration, and total duration. Compare against the 1000 ms cold start budget (SV-R04). Flag any function exceeding the budget for optimization.
-
-## Cost Reports
-
-Generate weekly cost reports with:
-
-- Total invocations per function
-- Total compute time (GB-seconds)
-- Cost per execution (target: **1 cent**)
-- Month-over-month trend
-- Functions exceeding cost budget
-
-## Compliance Evidence
-
-Retain the following artifacts for audit:
-
-- IAM role assignments and rotation logs
-- DLQ processing records
-- Deployment package vulnerability scan results
-- Cold start measurement history
-- Cost tracking reports
-
----
-
-[Back to Serverless Profile](./README.md)

package/rulesets/topologies/serverless/evolution.es.md

@@ -1,36 +0,0 @@
-# Guía de Evolución Sin Servidor
-
-> **Navegación Bilingüe:** [English](./evolution.md) | [Español](./evolution.es.md)
-
-**Propietario:** Ingeniería de Plataforma
-**Topología:** Sin Servidor
-
----
-
-## Migración de Contenedores a Funciones
-
-Migrar cargas de trabajo contenedorizadas a funciones descomponiendo manejadores monolíticos en funciones discretas y de propósito único. Identificar primero las rutas ligadas a I/O — se benefician más de la concurrencia sin servidor. Mantener tareas síncronas y de larga ejecución en contenedores. Usar patrones strangler-fig para migrar incrementalmente.
-
-## Evolución de la Gestión de Estado
-
-Transitar de estado local a almacenes externos gestionados al adoptar serverless. Implementar estado de sesión en bases de datos o cachés, no en memoria de funciones. Migrar estado de sistema de archivos a almacenamiento de objetos. Auditar patrones de gestión de estado después de cada transición de topología.
-
-## Sin Servidor vs Contenedores
-
-Elegir serverless para cargas de trabajo orientadas a eventos, esporádicas o con picos. Elegir contenedores para cargas sostenidas, de alto rendimiento o críticas en latencia que excedan los presupuestos serverless. Usar topologías híbridas donde serverless maneja la ingesta y contenedores el procesamiento. Documentar compensaciones explícitamente por carga de trabajo.
-
-## Organización de Funciones
-
-Organizar funciones por contexto acotado, no por capa técnica. Agrupar funciones relacionadas en unidades de despliegue con infraestructura compartida. Mantener un catálogo de funciones con metadatos de propiedad, SLA y costo. Evitar un único espacio de nombres plano para todas las funciones.
-
-## Neutralidad con el Proveedor (ADR-0095)
-
-Diseñar interfaces de funciones para ser portables entre proveedores de nube. Abstract los formatos de eventos específicos del proveedor detrás de esquemas internos. Usar runtimes y herramientas de código abierto donde sea posible. Aceptar optimizaciones específicas del proveedor como decisiones deliberadas y documentadas — nunca acoplamientos accidentales.
-
-## Transiciones de Topología
-
-Seguir la ruta de arquitectura progresiva: monolito simple → monolito modular → módulos distribuidos → serverless. Validar criterios de preparación antes de cada transición. Revertir si la carga operativa excede el valor del producto. Tratar la topología como una decisión de producto, no una preferencia de ingeniería.
-
----
-
-[Volver al Perfil Sin Servidor](./README.es.md)

package/rulesets/topologies/serverless/evolution.md

@@ -1,36 +0,0 @@
-# Serverless — Evolution Guide
-
-> **Bilingual Navigation:** [English](./evolution.md) | [Español](./evolution.es.md)
-
-**Owner:** Platform Engineering
-**Topology:** Serverless
-
----
-
-## Containers to Functions Migration
-
-Migrate containerized workloads to functions by decomposing monolithic handlers into discrete, single-purpose functions. Identify I/O-bound paths first — they benefit most from serverless concurrency. Keep synchronous, long-running tasks in containers. Use strangler-fig patterns to migrate incrementally.
-
-## State Management Evolution
-
-Transition from local state to managed external stores as you adopt serverless. Implement session state in databases or caches, not in function memory. Migrate file-system state to object storage. Audit state management patterns after each topology transition.
-
-## Serverless vs Containers
-
-Choose serverless for event-driven, sporadic, or bursty workloads. Choose containers for sustained, high-throughput, or latency-critical paths that exceed serverless budgets. Use hybrid topologies where serverless handles ingestion and containers handle processing. Document trade-offs explicitly per workload.
-
-## Function Organization
-
-Organize functions by bounded context, not by technical layer. Group related functions into deployment units with shared infrastructure. Maintain a function catalog with ownership, SLA, and cost metadata. Avoid a single flat namespace for all functions.
-
-## Provider Neutrality (ADR-0095)
-
-Design function interfaces to be portable across cloud providers. Abstract provider-specific event formats behind internal schemas. Use open-source runtimes and toolchains where possible. Accept vendor-specific optimizations as deliberate, documented decisions — never accidental coupling.
-
-## Topology Transitions
-
-Follow the progressive architecture path: simple monolith → modular monolith → distributed modules → serverless. Validate readiness criteria before each transition. Revert if operational overhead exceeds product value. Treat topology as a product decision, not an engineering preference.
-
----
-
-[Back to Serverless Profile](./README.md)

package/rulesets/topologies/serverless/fixtures/invalid.topology.config.json

@@ -1,6 +0,0 @@
-{
-  "topology": "serverless",
-  "stateless": false,
-  "package": { "maxSizeMb": 100 },
-  "coldStart": { "maxInitMilliseconds": -1, "lazyInitialization": false }
-}

package/rulesets/topologies/serverless/fixtures/valid.topology.config.json

@@ -1,6 +0,0 @@
-{
-  "topology": "serverless",
-  "stateless": true,
-  "package": { "maxSizeMb": 25 },
-  "coldStart": { "maxInitMilliseconds": 500, "lazyInitialization": true }
-}

package/rulesets/topologies/serverless/maturity.es.md

@@ -1,36 +0,0 @@
-# Guia de Adopcion, Operacion y Evolucion de Serverless
-
-> **Navegacion Bilingue:** [English Version](./maturity.md)
-
-## Adoption
-
-Adopte esta topologia cuando las capacidades aisladas se beneficien de escalamiento administrado, triggers de eventos o workloads con picos sin introducir una topologia de servicio separada. Comience con handlers sin estado, contratos explicitos y paquetes de despliegue acotados.
-
-## Operations
-
-Opere uno o mas entornos runtime administrados. Monitoree la distribucion de cold-start, el tamano del paquete de despliegue, las tasas de invocacion y los limites de concurrencia como parte de la validacion normal de arquitectura.
-
-## Security
-
-Autorice el acceso en la frontera del handler. Implemente gestion de identidad y secretos neutral respecto al proveedor. Nunca incruste credenciales en paquetes de despliegue; use secretos inyectados por entorno con capacidad de rotacion.
-
-## Resilience
-
-Disene handlers para reintentos idempotentes, degradacion gradual bajo presion de concurrencia y tiempo de inicializacion acotado. Prefiera mecanismos de integracion durables antes de agregar infraestructura con estado.
-
-## Patterns and Anti-Patterns
-
-Use handlers sin estado, contratos explcitos de entrada/salida, interfaces neutrales al proveedor e inicializacion diferida acotada. No asuma estado local persistente, duracion de ejecucion ilimitada ni caracteristicas runtime especificas del proveedor.
-
-## Evolution
-
-Mueva una capacidad a serverless solo cuando el perfil operativo (burst, event-driven, async) justifique la dependencia de plataforma. Preserve los contratos de dominio y la preparacion para extraccion para que la migracion de retorno u otra topologia siga siendo deliberada.
-
-## Validation Checklist
-
-- Valide la configuracion de topologia con `topology.config.schema.json` y ambos fixtures.
-- Ejecute la evaluacion Native y OPA mediante el plano de control compartido.
-- Confirme ADRs aprobados, guia bilingue y pruebas positivas y negativas reproducibles.
-
----
-[Volver al Perfil Serverless](./README.es.md)

package/rulesets/topologies/serverless/maturity.md

@@ -1,36 +0,0 @@
-# Serverless Adoption, Operations, and Evolution Guide
-
-> **Bilingual Navigation:** [Version en Espanol](./maturity.es.md)
-
-## Adoption
-
-Adopt this topology when isolated capabilities benefit from managed scaling, event triggers, or bursty workloads without introducing a separately owned service topology. Start with stateless handlers, explicit contracts, and bounded deployment packages.
-
-## Operations
-
-Operate one or more managed runtime environments. Monitor cold-start distribution, deployment package size, invocation rates, and concurrency limits as part of normal architecture validation.
-
-## Security
-
-Authorize access at the handler boundary. Enforce provider-neutral identity and secret management. Never embed credentials in deployment packages; use environment-injected, rotation-capable secrets.
-
-## Resilience
-
-Design handlers for idempotent retry, graceful degradation under concurrency pressure, and bounded initialization time. Prefer durable integration mechanisms before adding stateful infrastructure.
-
-## Patterns and Anti-Patterns
-
-Use stateless handlers, explicit input/output contracts, provider-neutral interfaces, and bounded cold-start initialization. Do not assume persistent local state, unbounded execution duration, or provider-specific runtime features.
-
-## Evolution
-
-Move a capability to serverless only when the operational profile (burst, event-driven, async) justifies the platform dependency. Preserve domain contracts and extraction readiness so that migration back or to another topology remains deliberate.
-
-## Validation Checklist
-
-- Validate the topology configuration against `topology.config.schema.json` and both fixtures.
-- Run Native and OPA policy evaluation through the shared control plane.
-- Confirm approved ADRs, bilingual guidance, and reproducible positive and negative tests.
-
----
-[Back to Serverless Profile](./README.md)