@evolith/core-domain 1.0.1 → 1.0.2

package/rulesets/topologies/serverless/mcp/mcp-manifest.json

@@ -1,72 +0,0 @@
-{
-  "protocolVersion": "2025-03-26",
-  "topologyId": "serverless",
-  "description": "MCP interface for the Serverless topology. Provides tools for inspecting and validating serverless function configurations, resources for manifest and ruleset access, and prompts for serverless-readiness and implementation guidance.",
-  "capabilities": {
-    "tools": {},
-    "resources": {},
-    "prompts": {}
-  },
-  "tools": [
-    {
-      "name": "evolith-topology-inspect",
-      "description": "Inspect a Serverless topology configuration and return its parsed manifest, function definitions, and corpus artifact references.",
-      "inputSchema": {
-        "type": "object",
-        "properties": {
-          "configPath": {
-            "type": "string",
-            "description": "Path to the Serverless configuration file"
-          },
-          "includeFunctions": {
-            "type": "boolean",
-            "description": "Include function-level metadata and triggers"
-          }
-        },
-        "required": ["configPath"]
-      }
-    },
-    {
-      "name": "evolith-topology-validate",
-      "description": "Validate a Serverless configuration against the topology ruleset and OPA policies, returning pass/fail per gate.",
-      "inputSchema": {
-        "type": "object",
-        "properties": {
-          "configPath": {
-            "type": "string",
-            "description": "Path to the Serverless configuration to validate"
-          },
-          "strictMode": {
-            "type": "boolean",
-            "description": "Fail on warnings, not just errors"
-          }
-        },
-        "required": ["configPath"]
-      }
-    }
-  ],
-  "resources": [
-    {
-      "uri": "evolith://topologies/serverless/manifest",
-      "name": "Serverless Topology Manifest",
-      "description": "Full topology manifest for Serverless, including metadata, artifact references, and corpus configuration.",
-      "mimeType": "application/json"
-    },
-    {
-      "uri": "evolith://topologies/serverless/rulesets",
-      "name": "Serverless Rulesets",
-      "description": "All ruleset files for Serverless: native rules JSON, OPA Rego policies, and WASM bundle.",
-      "mimeType": "application/json"
-    }
-  ],
-  "prompts": [
-    {
-      "name": "serverless-readiness-review",
-      "description": "Assesses whether a workload is suitable for serverless deployment, evaluating cold-start tolerance, statelessness, timeout limits, and cost profile."
-    },
-    {
-      "name": "topology-aware-implementation",
-      "description": "Guides AI-assisted implementation to respect Serverless topology constraints, ephemeral stateless design, and event-driven triggers."
-    }
-  ]
-}

package/rulesets/topologies/serverless/openapi/openapi.yaml

@@ -1,186 +0,0 @@
-openapi: "3.1.0"
-info:
-  title: "Serverless Topology — Core API Surface"
-  version: "0.1.0"
-  description: >
-    REST API surface specific to the Serverless topology.
-    Describes endpoints exposed by the Core API for querying,
-    inspecting, and validating Serverless topology instances.
-servers:
-  - url: "https://api.evolith.dev/v1"
-    description: "Evolith Core API (production)"
-paths:
-  /topologies/{id}:
-    get:
-      tags: [Topologies]
-      summary: "Retrieve Serverless topology information"
-      description: >
-        Returns the full topology record for Serverless, including
-        dimension, status, version, governance metadata, and corpus
-        artifact references (rulesets, OPA policies, ADRs, guidance).
-      operationId: "getServerlessTopology"
-      parameters:
-        - name: id
-          in: path
-          required: true
-          schema:
-            type: string
-            pattern: "^serverless$"
-            example: "serverless"
-      responses:
-        "200":
-          description: "Successful response with Serverless topology data"
-          content:
-            application/json:
-              schema:
-                $ref: "#/components/schemas/EnvelopeTopology"
-        "404":
-          description: "Topology not found"
-  /topologies/{id}/manifest:
-    get:
-      tags: [Topologies]
-      summary: "Get Serverless topology manifest"
-      description: >
-        Returns the full topology manifest for Serverless, with
-        artifact references, corpus configuration, and business
-        boundary declaration.
-      operationId: "getServerlessManifest"
-      parameters:
-        - name: id
-          in: path
-          required: true
-          schema:
-            type: string
-            pattern: "^serverless$"
-      responses:
-        "200":
-          description: "Successful response with Serverless manifest"
-          content:
-            application/json:
-              schema:
-                $ref: "#/components/schemas/EnvelopeManifest"
-  /topologies/{id}/validate:
-    post:
-      tags: [Topologies]
-      summary: "Validate Serverless topology rules"
-      description: >
-        Executes all applicable rulesets and OPA policies for Serverless
-        against a submitted configuration, returning pass/fail per gate.
-      operationId: "validateServerlessTopology"
-      parameters:
-        - name: id
-          in: path
-          required: true
-          schema:
-            type: string
-            pattern: "^serverless$"
-      requestBody:
-        required: true
-        content:
-          application/json:
-            schema:
-              $ref: "#/components/schemas/ValidationRequest"
-      responses:
-        "200":
-          description: "Validation results"
-          content:
-            application/json:
-              schema:
-                $ref: "#/components/schemas/EnvelopeValidation"
-components:
-  schemas:
-    Envelope:
-      type: object
-      properties:
-        success:
-          type: boolean
-        data: {}
-        meta:
-          type: object
-          properties:
-            context:
-              type: string
-            timing:
-              type: number
-            schemaVersion:
-              type: string
-              pattern: "^\\d+\\.\\d+\\.\\d+$"
-          required: [context, timing, schemaVersion]
-      required: [success, data, meta]
-    EnvelopeTopology:
-      allOf:
-        - $ref: "#/components/schemas/Envelope"
-        - type: object
-          properties:
-            data:
-              $ref: "#/components/schemas/TopologyRecord"
-    EnvelopeManifest:
-      allOf:
-        - $ref: "#/components/schemas/Envelope"
-        - type: object
-          properties:
-            data:
-              $ref: "#/components/schemas/TopologyManifest"
-    EnvelopeValidation:
-      allOf:
-        - $ref: "#/components/schemas/Envelope"
-        - type: object
-          properties:
-            data:
-              $ref: "#/components/schemas/ValidationResult"
-    TopologyRecord:
-      type: object
-      properties:
-        id:
-          type: string
-          example: "serverless"
-        name:
-          type: string
-          example: "Serverless"
-        dimension:
-          type: string
-          example: "execution"
-        status:
-          type: string
-          enum: [accepted, draft, deprecated]
-        version:
-          type: string
-          example: "0.1.0"
-    TopologyManifest:
-      type: object
-      properties:
-        apiVersion:
-          type: string
-          example: "evolith.dev/topology/v1"
-        kind:
-          type: string
-          example: "TopologyManifest"
-        metadata:
-          type: object
-        spec:
-          type: object
-    ValidationRequest:
-      type: object
-      properties:
-        config:
-          type: object
-          description: "Configuration to validate against topology rules"
-      required: [config]
-    ValidationResult:
-      type: object
-      properties:
-        passed:
-          type: boolean
-        gates:
-          type: array
-          items:
-            type: object
-            properties:
-              gate:
-                type: string
-              passed:
-                type: boolean
-              evidence:
-                type: array
-                items:
-                  type: string

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

@@ -1,36 +0,0 @@
-# Guía de Operaciones Sin Servidor
-
-> **Navegación Bilingüe:** [English](./operations.md) | [Español](./operations.es.md)
-
-**Propietario:** Ingeniería de Plataforma
-**Topología:** Sin Servidor
-
----
-
-## Optimización de Inicio en Frío
-
-Las funciones deben cumplir con un presupuesto de **1000 ms para inicio en frío** (SV-R04). Utilizar concurrencia provisionada para rutas sensibles a la latencia. Mantener los paquetes de despliegue por debajo de **50 MB** (SV-R03) para reducir el tiempo de inicialización. Evitar dependencias pesadas de runtime; preferir runtimes ligeros (Node.js, Python) sobre stacks pesados.
-
-## Límites de Concurrencia
-
-Monitorear cuotas de concurrencia regionales. Implementar interruptores de circuito al acercarse a los límites. Utilizar concurrencia reservada para aislar funciones críticas de vecinos ruidosos. Rastrear ejecuciones concurrentes contra los presupuestos para evitar cascadas de limitaciones.
-
-## Manejo de Cola de Cartas Muertas (DLQ)
-
-Toda invocación asíncrona debe declarar una DLQ (SV-R01). Los mensajes fallidos se enrutan a la DLQ tras agotar los reintentos. Procesar entradas de DLQ con una función dedicada de remediación. Alertar cuando la profundidad de la DLQ exceda cero por más de 5 minutos.
-
-## Monitoreo de Funciones
-
-Instrumentar invocaciones con logs estructurados, trazas y métricas. Rastrear latencia p50, p95 y p99 por función. Monitorear tasas de error, conteos de limitaciones y frecuencia de inicio en frío. Agregar costos por función para responsabilidad presupuestaria (objetivo: **1 centavo por ejecución**).
-
-## Rastreo de Costos
-
-Etiquetar cada función con metadatos de centro de costo. Generar reportes diarios de costos por función y por topology. Alertar cuando el costo por ejecución exceda el presupuesto. Revisar funciones inactivas mensualmente y descomisionar recursos no utilizados.
-
-## Mitigación de Bloqueo con el Proveedor
-
-Abstract las APIs específicas del proveedor detrás de interfaces internas (ADR-0095). Utilizar runtimes de funciones y formatos de eventos portables entre proveedores. Mantener una capa de contrato neutral al proveedor para esquemas de eventos. Documentar optimizaciones específicas del proveedor como compromisos deliberados, no acoplamientos accidentales.
-
----
-
-[Volver al Perfil Sin Servidor](./README.es.md)

package/rulesets/topologies/serverless/operations.md

@@ -1,36 +0,0 @@
-# Serverless — Operations Guide
-
-> **Bilingual Navigation:** [English](./operations.md) | [Español](./operations.es.md)
-
-**Owner:** Platform Engineering
-**Topology:** Serverless
-
----
-
-## Cold Start Optimization
-
-Functions must meet a **1000 ms cold start budget** (SV-R04). Use provisioned concurrency for latency-sensitive paths. Keep deployment packages under **50 MB** (SV-R03) to reduce initialization time. Avoid large runtime dependencies; prefer lightweight runtimes (Node.js, Python) over heavyweight stacks.
-
-## Concurrency Limits
-
-Monitor regional concurrency quotas. Implement circuit breakers when approaching limits. Use reserved concurrency to isolate critical functions from noisy neighbors. Track concurrent executions against budgets to prevent throttling cascades.
-
-## Dead Letter Queue (DLQ) Handling
-
-Every asynchronous invocation must declare a DLQ (SV-R01). Failed messages route to the DLQ after retry exhaustion. Process DLQ entries with a dedicated remediation function. Alert on DLQ depth exceeding zero for more than 5 minutes.
-
-## Function Monitoring
-
-Instrument invocations with structured logs, traces, and metrics. Track p50, p95, and p99 latency per function. Monitor error rates, throttle counts, and cold start frequency. Aggregate costs per function for budget accountability (target: **1 cent per execution**).
-
-## Cost Tracking
-
-Tag every function with cost-center metadata. Generate daily cost reports per function and per topology. Alert when per-execution cost exceeds budget. Review idle functions monthly and decommission unused resources.
-
-## Vendor Lock-in Mitigation
-
-Abstract cloud-specific APIs behind internal interfaces (ADR-0095). Use function-runtimes and event formats that portable across providers. Maintain a provider-neutral contract layer for event schemas. Document provider-specific optimizations as deliberate trade-offs, not accidental coupling.
-
----
-
-[Back to Serverless Profile](./README.md)

package/rulesets/topologies/serverless/parity-fixtures/compliant.json

@@ -1,13 +0,0 @@
-{
-  "input": {
-    "topology": "serverless",
-    "config": {
-      "networkSecurity": { "mtlsEnabled": true },
-      "hasContract": true,
-      "isStateless": true,
-      "hasBoundedPackage": true,
-      "hasColdStartReadiness": true
-    }
-  },
-  "expectedNative": []
-}

package/rulesets/topologies/serverless/parity-fixtures/violation.json

@@ -1,15 +0,0 @@
-{
-  "input": {
-    "topology": "serverless",
-    "config": {
-      "networkSecurity": { "mtlsEnabled": true },
-      "hasContract": false,
-      "isStateless": true,
-      "hasBoundedPackage": true,
-      "hasColdStartReadiness": true
-    }
-  },
-  "expectedNative": [
-    { "ruleId": "SV-R01", "severity": "error", "file": null }
-  ]
-}

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

@@ -1,36 +0,0 @@
-# Guía de Patrones Sin Servidor
-
-> **Navegación Bilingüe:** [English](./patterns.md) | [Español](./patterns.es.md)
-
-**Propietario:** Ingeniería de Plataforma
-**Topología:** Sin Servidor
-
----
-
-## Fan-Out / Fan-In
-
-Usar fan-out para distribuir trabajo entre múltiples invocaciones paralelas de funciones. Agregar resultados con una función fan-in o una máquina de estados. Asegurar que cada rama paralela sea idempotente. Monitorear la latencia total del pipeline contra el presupuesto de 1500 ms.
-
-## Funciones de Estado / Workflows
-
-Orquestar procesos de múltiples pasos con máquinas de estados (SV-R01). Definir estados explícitos, transiciones y manejadores de errores. Persistir el estado del workflow externamente para sobrevivir reinicios de funciones. Usar workflows visuales para lógica de negocio compleja que excede una sola función.
-
-## Filtrado de Eventos
-
-Filtrar eventos en la fuente para reducir invocaciones innecesarias. Usar reglas de bus de eventos o suscripciones de topics para entrega selectiva. Evitar procesar eventos irrelevantes dentro de la lógica de la función. Medir la efectividad del filtrado rastreando la relación invocación-trabajo-útil.
-
-## Composición de Funciones
-
-Componer funciones pequeñas y de propósito único en workflows de orden superior. Mantener los límites de composición limpios: cada función posee una capacidad de dominio. Usar mensajería asíncrona para comunicación entre funciones. Evitar cadenas de llamadas síncronas profundas que aumentan la latencia y la exposición a inicios en frío.
-
-## Backend-for-Frontend (BFF)
-
-Implementar funciones BFF para agregar servicios backend para clientes específicos. Adaptar payloads de respuesta por frontend para reducir sobre-obtención. Mantener funciones BFF delgadas — componen, no transforman lógica de negocio. Almacenar en caché respuestas BFF para patrones con alta carga de lectura.
-
-## Disparadores Programados
-
-Usar disparadores basados en cron para cargas de trabajo periódicas. Alinear la granularidad del calendario con las necesidades de negocio (minuto, hora, día). Implementar lógica de relleno para calendarios perdidos. Monitorear deriva del calendario y alertar sobre invocaciones perdidas.
-
----
-
-[Volver al Perfil Sin Servidor](./README.es.md)

package/rulesets/topologies/serverless/patterns.md

@@ -1,36 +0,0 @@
-# Serverless — Patterns Guide
-
-> **Bilingual Navigation:** [English](./patterns.md) | [Español](./patterns.es.md)
-
-**Owner:** Platform Engineering
-**Topology:** Serverless
-
----
-
-## Fan-Out / Fan-In
-
-Use fan-out to distribute work across multiple parallel function invocations. Aggregate results with a fan-in function or a state machine. Ensure each parallel branch is idempotent. Monitor total pipeline latency against the 1500 ms budget.
-
-## Step Functions / Workflows
-
-Orchestrate multi-step processes with state machines (SV-R01). Define explicit states, transitions, and error handlers. Persist workflow state externally to survive function restarts. Use visual workflows for complex business logic that exceeds a single function.
-
-## Event Filtering
-
-Filter events at the source to reduce unnecessary invocations. Use event bus rules or topic subscriptions for selective delivery. Avoid processing irrelevant events inside function logic. Measure filtering effectiveness by tracking invocation-to-useful-work ratio.
-
-## Function Composition
-
-Compose small, single-purpose functions into higher-order workflows. Keep composition boundaries clean: each function owns one domain capability. Use async messaging for inter-function communication. Avoid deep synchronous call chains that increase latency and cold start exposure.
-
-## Backend-for-Frontend (BFF)
-
-Implement BFF functions to aggregate backend services for specific clients. Tailor response payloads per frontend to reduce over-fetching. Keep BFF functions thin — they compose, they don't transform business logic. Cache BFF responses for read-heavy patterns.
-
-## Scheduled Triggers
-
-Use cron-based triggers for periodic workloads. Align schedule granularity with business needs (minute, hour, day). Implement backfill logic for missed schedules. Monitor schedule drift and alert on missed invocations.
-
----
-
-[Back to Serverless Profile](./README.md)

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

@@ -1,36 +0,0 @@
-# Guía de Resiliencia Sin Servidor
-
-> **Navegación Bilingüe:** [English](./resilience.md) | [Español](./resilience.es.md)
-
-**Propietario:** Ingeniería de Plataforma
-**Topología:** Sin Servidor
-
----
-
-## Idempotencia
-
-Cada función debe ser idempotente. Usar claves de idempotencia derivadas del payload del evento o un token proporcionado por el cliente. Almacenar registros de idempotencia en un almacén rápido y duradero con un TTL que coincida con el dominio de negocio. Rechazar invocaciones duplicadas con el resultado original.
-
-## Reintento con Backoff Exponencial
-
-Configurar reintentos con backoff exponencial y jitter para fallos transitorios. Establecer el número máximo de reintentos basado en el timeout de la función y el presupuesto de latencia (1500 ms total). Distinguir errores reintatables (5xx, limitaciones) de fallos permanentes (4xx, validación). Evitar bucles de reintento ilimitados.
-
-## Puntos de Control
-
-Para flujos de trabajo de ejecución larga o fan-out, persistir estado interno en almacenamiento externo. Usar colas o bases de datos duraderas como puntos de control. Reanudar desde el último punto de control tras un fallo en lugar de reiniciar todo el flujo de trabajo. Mantener las escrituras de puntos de control atómicas.
-
-## Recuperación de DLQ
-
-Enrutar fallos irrecuperables a la DLQ. Implementar una función de recuperación dedicada que inspeccione, transforme y reprocese entradas de la DLQ. Alertar inmediatamente cuando la profundidad de la DLQ exceda el umbral. Mantener rastros de auditoría para cada intento de procesamiento de DLQ.
-
-## Mitigación de Inicio en Frío
-
-Reservar concurrencia provisionada para rutas críticas para mantenerse dentro del presupuesto de 1000 ms de inicio en frío (SV-R04). Calentar funciones en un calendario para prevenir evicciones por timeout de inactividad. Usar runtimes ligeros y minimizar el tamaño del paquete (SV-R03). Perfilar inicios en frío continuamente y regresar en caso de degradación.
-
-## Diseño Stateless (SV-R02)
-
-Las funciones no deben mantener estado local entre invocaciones. Externalizar todo el estado a almacenes gestionados (base de datos, caché, cola). Tratar cada invocación como independente. Validar esta invariant en pruebas de integración.
-
----
-
-[Volver al Perfil Sin Servidor](./README.es.md)

package/rulesets/topologies/serverless/resilience.md

@@ -1,36 +0,0 @@
-# Serverless — Resilience Guide
-
-> **Bilingual Navigation:** [English](./resilience.md) | [Español](./resilience.es.md)
-
-**Owner:** Platform Engineering
-**Topology:** Serverless
-
----
-
-## Idempotency
-
-Every function must be idempotent. Use idempotency keys derived from the event payload or a client-supplied token. Store idempotency records in a fast, durable store with a TTL matching the business domain. Reject duplicate invocations with the original result.
-
-## Retry with Exponential Backoff
-
-Configure retries with exponential backoff and jitter for transient failures. Set maximum retry attempts based on function timeout and latency budget (1500 ms total). Distinguish retryable errors (5xx, throttling) from permanent failures (4xx, validation). Avoid unbounded retry loops.
-
-## Checkpointing
-
-For long-running or fan-out workflows, persist intermediate state to external storage. Use durable queues or databases as checkpoints. Resume from the last checkpoint after failure rather than restarting the entire workflow. Keep checkpoint writes atomic.
-
-## DLQ Recovery
-
-Route unrecoverable failures to the DLQ. Implement a dedicated recovery function that inspects, transforms, and reprocesses DLQ entries. Alert immediately on DLQ depth exceeding threshold. Maintain audit trails for every DLQ processing attempt.
-
-## Cold Start Mitigation
-
-Reserve provisioned concurrency for critical paths to stay within the 1000 ms cold start budget (SV-R04). Warm functions on a schedule to prevent idle-timeout evictions. Use lightweight runtimes and minimize package size (SV-R03). Profile cold starts continuously and regress on degradation.
-
-## Stateless Design (SV-R02)
-
-Functions must not hold local state between invocations. Externalize all state to managed stores (database, cache, queue). Treat each invocation as independent. Validate this invariant in integration tests.
-
----
-
-[Back to Serverless Profile](./README.md)

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

@@ -1,68 +0,0 @@
-# Runbooks Sin Servidor
-
-> **Navegación Bilingüe:** [English](./runbooks.md) | [Español](./runbooks.es.md)
-
-**Propietario:** Ingeniería de Plataforma
-**Topología:** Sin Servidor
-
----
-
-## Runbook 1: Fallo en Despliegue de Función
-
-**Disparador:** El pipeline de CI/CD reporta un error de despliegue.
-
-1. Revisar logs de despliegue para detalles del error y stack trace.
-2. Verificar permisos del rol IAM para la cuenta de despliegue.
-3. Validar configuración de la función (ruta del handler, runtime, memoria, timeout).
-4. Asegurar que el paquete de despliegue esté bajo 50 MB (SV-R03).
-5. Re-ejecutar el despliegue con logging detallado habilitado.
-6. Si persiste, hacer rollback a la última versión conocida como buena e investigar offline.
-
-## Runbook 2: Latencia de Inicio en Frío Excede el Presupuesto
-
-**Disparador:** La latencia p95 de inicio en frío excede 1000 ms (SV-R04).
-
-1. Identificar la función afectada desde el panel de monitoreo.
-2. Revisar el tamaño del paquete de despliegue y dependencias.
-3. Cambiar a un runtime más ligero si es factible (Node.js, Python).
-4. Habilitar concurrencia provisionada para la función.
-5. Perfilar la fase de init — identificar código de inicialización pesado.
-6. Mover la inicialización fuera del handler donde sea posible.
-7. Validar la mejora contra el presupuesto de 1000 ms.
-
-## Runbook 3: Profundidad de DLQ Excede el Umbral
-
-**Disparador:** La profundidad de la DLQ excede cero por más de 5 minutos.
-
-1. Identificar la función de origen y el tipo de evento fallido.
-2. Inspeccionar entradas de la DLQ para mensajes de error y payloads.
-3. Corregir la causa raíz en la función consumidora.
-4. Reprocesar entradas de la DLQ a través de la función de remediación.
-5. Verificar que la profundidad de la DLQ regresa a cero.
-6. Actualizar umbrales de alerta si el umbral era demasiado sensible.
-
-## Runbook 4: Límite de Concurrencia Excedido
-
-**Disparador:** Invocaciones de función retornan errores de limitación (429).
-
-1. Verificar el uso actual de concurrencia contra la cuota regional.
-2. Identificar qué funciones están consumiendo más concurrencia.
-3. Aumentar concurrencia reservada para funciones críticas si es necesario.
-4. Implementar o ajustar interruptores de circuito en rutas no críticas.
-5. Solicitar aumento de cuota si se espera crecimiento sostenido.
-6. Monitorear durante 30 minutos después de la remediación para confirmar estabilidad.
-
-## Runbook 5: Investigación de Timeout de Función
-
-**Disparador:** La función excede consistentemente el timeout configurado.
-
-1. Revisar logs de ejecución de la función para operaciones lentas.
-2. Verificar latencia de servicios downstream (base de datos, APIs externas).
-3. Aumentar el timeout si la carga de trabajo genuinamente requiere más tiempo.
-4. Optimizar rutas de código — reducir I/O innecesario, operaciones por lotes.
-5. Considerar dividir en funciones más pequeñas si la tarea es demasiado grande.
-6. Validar el nuevo timeout contra el presupuesto de latencia de 1500 ms.
-
----
-
-[Volver al Perfil Sin Servidor](./README.es.md)

package/rulesets/topologies/serverless/runbooks.md

@@ -1,68 +0,0 @@
-# Serverless — Runbooks
-
-> **Bilingual Navigation:** [English](./runbooks.md) | [Español](./runbooks.es.md)
-
-**Owner:** Platform Engineering
-**Topology:** Serverless
-
----
-
-## Runbook 1: Function Deployment Failure
-
-**Trigger:** CI/CD pipeline reports deployment error.
-
-1. Check deployment logs for error details and stack trace.
-2. Verify IAM role permissions for the deployment account.
-3. Validate function configuration (handler path, runtime, memory, timeout).
-4. Ensure deployment package is under 50 MB (SV-R03).
-5. Re-run deployment with verbose logging enabled.
-6. If persistent, rollback to the last known-good version and investigate offline.
-
-## Runbook 2: Cold Start Latency Exceeds Budget
-
-**Trigger:** p95 cold start latency exceeds 1000 ms (SV-R04).
-
-1. Identify the affected function from monitoring dashboard.
-2. Review deployment package size and dependencies.
-3. Switch to a lighter runtime if feasible (Node.js, Python).
-4. Enable provisioned concurrency for the function.
-5. Profile init phase — identify heavy initialization code.
-6. Move initialization outside the handler where possible.
-7. Validate improvement against the 1000 ms budget.
-
-## Runbook 3: DLQ Depth Exceeds Threshold
-
-**Trigger:** DLQ depth exceeds zero for more than 5 minutes.
-
-1. Identify the source function and failing event type.
-2. Inspect DLQ entries for error messages and payloads.
-3. Fix the root cause in the consumer function.
-4. Reprocess DLQ entries via the remediation function.
-5. Verify DLQ depth returns to zero.
-6. Update alerting thresholds if the threshold was too sensitive.
-
-## Runbook 4: Concurrency Limit Exceeded
-
-**Trigger:** Function invocations returning throttling errors (429).
-
-1. Check current concurrency usage against regional quota.
-2. Identify which functions are consuming the most concurrency.
-3. Increase reserved concurrency for critical functions if needed.
-4. Implement or tune circuit breakers on non-critical paths.
-5. Request a quota increase if sustained growth is expected.
-6. Monitor for 30 minutes after remediation to confirm stability.
-
-## Runbook 5: Function Timeout Investigation
-
-**Trigger:** Function consistently timing out near configured timeout.
-
-1. Review function execution logs for slow operations.
-2. Check downstream service latency (database, external APIs).
-3. Increase timeout if the workload genuinely requires more time.
-4. Optimize code paths — reduce unnecessary I/O, batch operations.
-5. Consider splitting into smaller functions if the task is too large.
-6. Validate new timeout against the 1500 ms latency budget.
-
----
-
-[Back to Serverless Profile](./README.md)