feat(episode): EXPLORA_en-espera-de-tu-decisin-john-revives-el_S20260607.R8_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: TESSERA | Type: troubleshooting
Summary: EPISODIO 8 — MEMORIA: En espera de tu decisión, John: ¿revives el...

episodes/EXPLORA_en-espera-de-tu-decisin-john-revives-el_S20260607.R8_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,47 @@
+---
+episode_id: "c5062c6b-3c6d-41e5-a863-4c034b675d07"
+puente_flat: "EXPLORA_en-espera-de-tu-decisin-john-revives-el_S20260607.R8_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
+session_code: "S20260607.MNEMO_BUG_FORENSE_MAP"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "low"
+skill_dominante: "TESSERA"
+fase_proyecto: "operations"
+tipo_semantico: "troubleshooting"
+summary_one_line: "EPISODIO 8 — MEMORIA: En espera de tu decisión, John: ¿revives el..."
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-06-10T23:36:54.550761+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+En espera de tu decisión, John: ¿revives el sshd desde la consola Hetzner ahora, o te apunto una tarea local mientras el servidor sigue caído?
+
+✅ Push a los **3 remotos** (`945a87e..20ccfe2`) — el DNS git-https se recuperó; los commits previos también quedaron. **BLINDADA-29 al día.** (El MCP `ember-ssh-memoria` sigue inestable — es ese servidor MCP el caído, no la red general.)
+
+## Honestidad sobre "el problema grave" — está más resuelto de lo que parecía
+
+`★ Insight ─────────────────────────────────────`
+La disciplina FORENSE evitó que empeorara las cosas: iba a "arreglar" el dual-path-raw, pero al **verificar** descubrí que (a) mi diagnóstico del SCAN era impreciso (`stop-enricher` SÍ chunkea con TESSERA) y (b) la causa raíz real — **dilución por acks triviales** — **ya la diagnostiqué y le puse prevención AYER** (filtro `<60 chars` en `stop-enricher:412`). Si hubiera "fixeado" mi hipótesis original, habría tocado un pipeline que ya estaba bien por el lado de prevención.
+`─────────────────────────────────────────────────`
+
+**Estado real del problema grave (retrieval fallando):**
+
+| Parte | Estado |
+|---|---|
+| **Causa raíz** | dilución por acks-basura ("No response requested." × cientos de turnos vacíos) inundando Qdrant |
+| **Prevención** (no episode-ificar acks) | ✅ **YA APLICADA** ayer — memorias NUEVAS no se diluyen |
+| **Cleanup** (purgar acks-basura ya en Qdrant) | ⏳ **BLOQUEADO** — MCP down + SSH ECONNRESET 3× |
+
+**Por qué NO purgué (zero-harm absoluto):** la purga es un `DELETE` en Qdrant. No haré un borrado destructivo que **no puedo verificar** sobre una conexión que se cae 3 veces seguidas. El spec exacto de la purga (medir→listar→backup→borrar→verificar retrieval >0.6) está listo en `docs/FIX_RETRIEVAL_DILUTION_PLAN_S20260607.md` para ejecutar **en cuanto el servidor MCP estabilice**.
+
+**Causa upstream que conviene mirar:** el chat tuvo **cientos de turnos vacíos** (ciclo Continue→"No response requested.") — esa fue la fábrica de acks-basura. El filtro los neutraliza, pero vale revisar por qué el harness generó tantos turnos vacíos.
+
+📌 PILA-PENDIENTES (R28) — COMPACT
+🟢 Z-DIAG [R28] diagnóstico retrieval CORREGIDO (acks, no raw) + prevención confirmada ya-aplicada ✅
+🟢 Z-PUSH [R28] commit 20ccfe2 en 3 remotos ✅
+🔴 T-PURGE [R28] purgar acks-basura de Qdrant — BLOQUEADO (MCP down/SSH ECONNRESET); spec listo, ejecutar con servidor estable [hard]
+🟡 T-FIX2/3/5 [R1] reconciler + F-entity + dual-path — pendientes (server) [hard]
+⚪ T-EMPTY-TURNS [R28+inferencia] investigar causa upstream de los turnos vacíos (fuente de acks) [inf]
+❓ Q-NEXT: ¿espero a que el servidor MCP estabilice para la purga, o prefieres que reintente más tarde?