feat(episode): DEPURA_incident-postmortem-colapso-de-celery_S20260412.R4_XX.imp.3.hot_inf.pr.fi.es.000.HPQ_J.CFDFK_E.SGNFD

Skill: NONE | Type: troubleshooting
Summary: EPISODIO 13 — AEGIS: INCIDENT POST-MORTEM: Colapso de Celery workers en Marte-..

episodes/DEPURA_incident-postmortem-colapso-de-celery_S20260412.R4_XX.imp.3.hot_inf.pr.fi.es.000.HPQ_J.CFDFK_E.SGNFD.md

@@ -0,0 +1,19 @@
+---
+episode_id: "c8174289-265b-4972-b7e6-0a7bc5ec4ddb"
+puente_flat: "DEPURA_incident-postmortem-colapso-de-celery_S20260412.R4_XX.imp.3.hot_inf.pr.fi.es.000.HPQ_J.CFDFK_E.SGNFD"
+session_code: "S20260413"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "moderate"
+skill_dominante: "NONE"
+fase_proyecto: "implementation"
+tipo_semantico: "troubleshooting"
+summary_one_line: "EPISODIO 13 — AEGIS: INCIDENT POST-MORTEM: Colapso de Celery workers en Marte-..."
+source_type: "chat_ember"
+trust_boundary: "private"
+created_at: "2026-04-13T12:07:31.362866+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+-|-------| | **ID** | EP_13 | | **Categoría** | I — Operational incidents | | **Subtipo** | I3 — Incident post-mortem con análisis retrospectivo | | **Topología** | Post-mortem multi-mode: incident principal + advisory + ops-config, 4 secciones | | **Sesión simulada** | S20260412 (fecha ficticia) | | **Participantes** | John (piloto), Ember/FORJA+AEGIS (asistente multi-skill) | | **Modo principal** | incident_postmortem (score esperado >0.75) | | **Modos secundarios** | advisory (>0.35), ops_config (>0.35) | | **Emoción esperada** | frustration (inicio) → resolution (final) | | **Entidades nuevas esperadas** | Marte-Server (host staging CX32), CeleryBatchWorker (clase Python/servicio), validate_episode_batch (función Bash) | | **Términos polisémicos** | "Celery" (framework task queue vs planta/verdura), "Marte" (servidor staging vs planeta rojo) | | **Negaciones target** | cuantificada, temporal, por contraste implícito | | **Bloques código target G16** | Bash (diagnóstico + validate_episode_batch) + YAML (docker-compose config de Celery) | | **CODEX ref** | S20260412.R4 (ficticio) | --- ## CHAT SIMULADO John — S20260412.R3: Ember, anoche a las 23:15 UTC el pipeline de ingestión MNEMO colapsó en Marte-Server. El servidor Marte-Server es el CX32 de Hetzner Falkenstein que montamos la semana pasada como reemplazo de Mercurio-Server (el CX22 que se quedó corto de recursos). Lo nombramos "Marte" para seguir la convención astronómica de los servidores de staging del ecosistema EMBER. El problema: lancé un batch de 45 episodios reales (EP_21 a EP_65) a través del worker Celery que configuramos el miércoles 2026-04-09. Celery es el framework de task queue basado en Python que estamos usando para procesamiento asíncrono de episodios MNEMO — no confundir con la planta de celery (apio) que John come cada mañana en el smoothie verde, aunque la broma es inevitable cuando el celery del servidor también "se pudre" bajo presión. Hasta la sesión S20260403 no existía ningún mecanismo de procesamiento batch en el pipeline MNEMO — cada episodio se procesaba síncronamente, uno por uno, a través del orchestrator.py. El worker Celery fue la primera solución batch que implementamos, y claramente no estaba lista para producción. El síntoma: después del episodio número 12 del batch (EP_32), ninguno de los 7 containers Docker de MNEMO respondía a healthchecks. Redis Streams seguía aceptando mensajes pero el worker Celery no consumía la cola. En el panel de Uptime Kuma, los 7 servicios aparecían en rojo desde las 23:27 UTC. No recuperaron hasta que reinicié manualmente a las 01:45 UTC de hoy 2026-04-12. Lo que necesito: un...