---
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).