fa412ac604
Skill: TESSERA | Type: troubleshooting Summary: EPISODIO 2 — MNEMO_PRE_DIGEST: Estado del deploy del fix
3.3 KiB
| episode_id | puente_flat | session_code | acto_dialogico | actor_flujo | criticidad_aegis | skill_dominante | fase_proyecto | tipo_semantico | summary_one_line | source_type | trust_boundary | created_at | relectura_tagged | forgejo_commit_sha |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1581c021-3494-4c7f-b287-d44bbd29d9ec | TRAZA_estado-del-deploy-del-fix_S20260712.R2_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD | S20260712.PIPELINE_PG_HYDE_FIX | informar | multi_actor | low | TESSERA | operations | troubleshooting | EPISODIO 2 — MNEMO_PRE_DIGEST: Estado del deploy del fix | claude_code | internal | 2026-07-13T01:46:59.863532+00:00 | false | 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).