feat(episode): BACKFILL_q-68abdccd-ccc6-5e98-8c66-ac1f65edfd35_S20260510.BACKFILL-RECOVERED_XX.bkf.0.warm_qdr.orphan.in.cc.es.000.BKF_J.4DD5D_E.2AD-4

Skill: NONE | Type: chronicle
Summary: El diseño de un módulo de alertas para el pipeline MNEMO en el ecosistema EMBER

episodes/BACKFILL_q-68abdccd-ccc6-5e98-8c66-ac1f65edfd35_S20260510.BACKFILL-RECOVERED_XX.bkf.0.warm_qdr.orphan.in.cc.es.000.BKF_J.4DD5D_E.2AD-4.md

@@ -0,0 +1,19 @@
+---
+episode_id: "4dd5d2ad-4510-5fdb-8fff-04af47c67ef2"
+puente_flat: "BACKFILL_q-68abdccd-ccc6-5e98-8c66-ac1f65edfd35_S20260510.BACKFILL-RECOVERED_XX.bkf.0.warm_qdr.orphan.in.cc.es.000.BKF_J.4DD5D_E.2AD-4"
+session_code: "S20260510.BACKFILL_RECOVERED"
+acto_dialogico: "informar"
+actor_flujo: "ember_internal"
+criticidad_aegis: "moderate"
+skill_dominante: "NONE"
+fase_proyecto: "maintenance"
+tipo_semantico: "chronicle"
+summary_one_line: "El diseño de un módulo de alertas para el pipeline MNEMO en el ecosistema EMBER requiere resolver tres trade-offs arquitecturales fundamentales antes de definir el schema. **Trade-off 1 — Acoplamiento"
+source_type: "claude_code"
+trust_boundary: "default"
+created_at: "2026-05-10T00:00:00+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+El diseño de un módulo de alertas para el pipeline MNEMO en el ecosistema EMBER requiere resolver tres trade-offs arquitecturales fundamentales antes de definir el schema. **Trade-off 1 — Acoplamiento vs independencia del módulo de alertas** La alternativa más simple sería agregar columnas de alerta directamente a la tabla `episodes` de PostgreSQL existente (`alert_status`, `alert_timestamp`, `alert_message`). El costo: el módulo de alertas queda acoplado al schema de episodios, y cualquier cambio en la estructura de alertas requiere migrar la tabla principal del pipeline. La alternativa preferida para MNEMO es separación total: el módulo de alertas opera como schema independiente (`mnemo_alerts`) con referencia por `episode_id` hacia la tabla `episodes`. Este patrón es el de Event Sourcing parcial — las alertas son eventos derivados de episodios, NO parte del episodio mismo. VERIFICADO: El principio de separación de concerns en arquitecturas de pipeline recomienda que los componentes de observabilidad (alertas, métricas, logs) NO compartan schema con los componentes de datos principales. Razón: diferentes ciclos de vida (una alerta puede resolverse y eliminarse sin afectar el episodio origen). **Trade-off 2 — Granularidad de las condiciones de alerta** Alternativa A: guardar las condiciones como JSON blob en una columna `conditions JSONB`. Ventaja: flexibilidad máxima para agregar nuevos criterios sin migración de schema. Desventaja: NO permite queries eficientes del tipo "todas las alertas donde el criterio C3 falló" sin índice GIN en el blob. NO usar JSON blob sin índice GIN explícito si se necesita filtrar por criterio individual. Alternativa B (recomendada): tabla normalizada con una fila por criterio fallido. Schema propuesto: | Tabla | Columnas clave | Propósito | |---|---|---| | `alerts` | `id, episode_id, severity, created_at, resolved_at` | Alerta raíz (una por episodio + trigger) | | `alert_criteria_failures` | `alert_id, criterion_code, expected, actual, details` | Una fila por criterio C1-C15 que falló | | `alert_channels` | `id, channel_type, config_json, active` | Canales de notificación (email, Slack, webhook) | | `alert_policies` | `id, criterion_pattern, severity_rule, channel_ids[]` | Reglas: qué criterios activan qué canales | Este diseño permite queries directas como `SELECT episode_id FROM alert_criteria_failures WHERE criterion_code = 'C3'` sin JSON parsing. **Trade-off 3 — Persistencia vs in-memory para evaluación de alertas** El pipeline MNEMO procesa episodios de manera síncrona en Python. Dos alternativas para la evaluación de alertas: Alternativa A: evaluación en-proceso (inline en `pipeline.py`). Ventaja: cero latencia adicional, sin servicios extra. Desventaja: si la evaluación de alertas falla con excepción, puede crashear el pipeline...