feat(episode): TRAZA_4-capa-push-diferida-tras-un-gate_S20260712.R11_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: NONE | Type: troubleshooting
Summary: EPISODIO 11 — MNEMO_PRE_DIGEST: 4. **capa PUSH** — **diferida** tras un gate...

episodes/TRAZA_4-capa-push-diferida-tras-un-gate_S20260712.R11_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,37 @@
+---
+episode_id: "701ebc7e-05f3-402b-bdd4-8d7c7abac140"
+puente_flat: "TRAZA_4-capa-push-diferida-tras-un-gate_S20260712.R11_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
+session_code: "S20260712.PIPELINE_PG_HYDE_FIX"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "low"
+skill_dominante: "NONE"
+fase_proyecto: "operations"
+tipo_semantico: "troubleshooting"
+summary_one_line: "EPISODIO 11 — MNEMO_PRE_DIGEST: 4. **capa PUSH** — **diferida** tras un gate..."
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-07-13T01:44:49.763296+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+4. **capa PUSH** — **diferida** tras un gate medido: solo si, tras el Eje D, un `MEMORY.md` auto-regenerado por cron no cierra el gap. Y si se construye, como overlay no-autoritativo con veto de recall. **B (y C-Neo4j y D-server) están todos SSH-gated**, y `cx43` está baneado ahora. No fabrico progreso sobre un canal caído. El ban es time-boxed — **cuando SSH se recupere, retomo B**. Si quieres, en la próxima ventana lo primero es reintentar SSH y arrancar B/D. - **Hice:** cerré A (backup ✅) y C (panel D-ARCH ✅ con verdict honesto NEEDS_REVISION); aseguré todo en 3 remotos. El panel refutó por medición mi propia premisa de la capa PUSH — el resultado más valioso del turno fue un **"no" bien fundado**. - **Falta:** B (revive Neo4j) — **bloqueado por SSH caído** (`cx43` rate-limited), no por decisión. Junto con Eje C/D server-side. - **Mi consejo:** cuando SSH se enfríe, el orden correcto **ya no es el que yo dije**: es **Eje D (auth) → Eje C (fix write-path Neo4j)**, y la capa PUSH queda archivada tras su gate. Hoy no hay más ejecutable server-side; lo local ya quedó (eje B) y asegurado. ⛽ 🟢 GREEN ~745K | A✅ C✅(NEEDS_REVISION) · B🔴 SSH caído
+
+Balance honesto, John: **A y C hechos y asegurados; B bloqueado por un canal caído, no por mí.** Y lo más valioso del turno fue que el panel me hizo tragar un dato — la capa PUSH no era lo que yo creía. Cuando SSH vuelva, arrancamos por **Eje D → Eje C**. 🔥
+
+**Deploy ejecutado y confirmado en disco. Reinicio programado (~6s) para recargar el módulo.** En segundos esta conexión MCP caerá — es esperado.
+
+## Estado del deploy del fix
+
+| Paso | Resultado |
+|---|---|
+| Auth | ✅ unlocked (TTL 5h9m) |
+| Patch → staging | ✅ `/home/johnember/data/analysis_tools.py` (2 fixes: `anomaly_sample_csv` + `problem{}`) |
+| Backup del vivo | ✅ `analysis_tools.py.bak.S20260712.pre_forense_tools_fix` |
+| Deploy alpine-cp → fuente RO | ✅ `DEPLOY rc:0` |
+| **Verificación en disco** | ✅ el fuente ya muestra `"anomaly_sample_csv": anomaly_csv  # FIX S20260712` |
+| Re-test sin restart | 🔴 aún 422 → **módulo cacheado** en el proceso `ember-mcp` (server FastMCP de larga vida) |
+| Restart para recargar | ⏳ **programado (detached, ~6s)** → recarga `analysis_tools.py` |
+
+El diagnóstico del "¿por qué sigue roto tras el deploy?" quedó cerrado: el archivo en disco está bien; el proceso en ejecución tenía el módulo viejo en memoria. Por eso el restart.