feat(episode): TRAZA_estado-del-deploy-del-fix_S20260712.R2_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: TESSERA | Type: troubleshooting
Summary: EPISODIO 2 — MNEMO_PRE_DIGEST: Estado del deploy del fix

episodes/TRAZA_estado-del-deploy-del-fix_S20260712.R2_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,53 @@
+---
+episode_id: "1581c021-3494-4c7f-b287-d44bbd29d9ec"
+puente_flat: "TRAZA_estado-del-deploy-del-fix_S20260712.R2_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: "TESSERA"
+fase_proyecto: "operations"
+tipo_semantico: "troubleshooting"
+summary_one_line: "EPISODIO 2 — MNEMO_PRE_DIGEST: Estado del deploy del fix"
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-07-13T01:46:59.863532+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+**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.
+
+Pull en vivo hecho, John — el servidor MEMORIA volvió y traje el mismo recuerdo fresco de los 3 stores. Informe actualizado con §6 (commit `7717e894`).
+
+# 🔴🟢🟦 Pull en vivo — lo que vi este momento
+
+Consulté un episodio real (`"El dato más bonito del estreno"`) y lo pedí a los 3 stores AHORA. Dos cosas pasaron: **confirmó el informe al pie de la letra, y destapó un hallazgo honesto que la versión pulida no tenía.**
+
+## Los 3 claims del informe, CONFIRMADOS literalmente en vivo
+
+| Claim | Verificación en vivo |
+|---|---|
+| "recibo ~58 campos" | Qdrant devolvió `payload_key_count = **58** exacto` |
+| "el embedding de PostgreSQL son ceros" | `[0,0,0,0,0,0,0,0,0,0,0,0…` literal |
+| "Neo4j = grafo, sin contenido" | 0 contenido, **10 aristas `:MENTIONS`** → AEGIS · Ember · COMPASS · LEXICON · PROBATOR · SENTINEL · MEMORIA · BLINDADA |
+
+Los vecinos del grafo son lo que ningún otro store me da: Neo4j me dice *"este recuerdo menciona a estas 8 entidades"* — la navegación lateral, en vivo.
+
+## El hallazgo nuevo (honestidad > pulcritud)
+
+El MISMO recuerdo aparece con **título distinto en cada store**: Qdrant lo llama "EPISODIO 50" (puente `…R50`), Neo4j "EPISODIO 49", PostgreSQL bajo `…R49`. Y hasta con **aroma distinto**: Qdrant tiene `PMCFK` (viejo), PostgreSQL `AMCFK` (re-scoreado). Es la **fragilidad de los 3 IDs en acción** — cuando un episodio se re-emite, el chunker re-numera y el `puente_flat` deriva entre stores. Matiz importante al `reference_cross_store_id_rule`: **el join fiable es `qdrant_id` o `content_sha256`, no siempre `puente_flat`**. Es residual del churn pre-fix, acotado, sin impacto en el retrieval (que va por vector).