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

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

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

@@ -1,40 +1,47 @@
 ---
-episode_id: "28104c70-1a37-4c08-a1ca-79d3835bb023"
+episode_id: "ab0094d3-2458-42e0-a1df-10cda7a8cc07"
 puente_flat: "EXPLORA_en-espera-de-tu-decisin-john-revives-el_S20260607.R15_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: "NONE"
+skill_dominante: "TESSERA"
 fase_proyecto: "operations"
 tipo_semantico: "troubleshooting"
 summary_one_line: "EPISODIO 15 — MEMORIA: En espera de tu decisión, John: ¿revives el..."
 source_type: "claude_code"
 trust_boundary: "internal"
-created_at: "2026-06-07T23:13:26.396591+00:00"
+created_at: "2026-06-09T01:14:45.117954+00:00"
 relectura_tagged: false
 forgejo_commit_sha: "pending"
 ---
 
-**Deploy COMPLETO** ✅ — el notebook está vivo en render.brasaluz.com.
+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?
 
-| Paso | Resultado |
+✅ 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 |
 |---|---|
-| scp al volumen | exit 0 ✅ |
-| cp a `/workspace/.compiled/` | CP_OK, 38202 bytes (appuser) ✅ |
-| marimo local health | HTTP 200 ✅ |
+| **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× |
 
-**URL:** `https://render.brasaluz.com/?file=VP-26-SP_GRAFO_INDICE_EMBER-01-GRAFO_NAVEGABLE.py` (tras login Authelia verás: stats 304/280, barras por categoría, backbone Mermaid interactivo, y tabla filtrable de los 304 nodos por grado de conexión).
+**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**.
 
-**FORENSE confirmado post-mortem:** el box tiene **uptime 20 días** (nunca rebooteó) y ahora **load 0.92** → era saturación **transitoria** de sshd (hipótesis H1), no caída del box ni de recursos. Se recuperó solo. Mi diagnóstico externo ("box vivo, sshd saturado, no muerto") quedó validado.
+**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.
 
-## Cierre de la sesión grafo-índice
-Las 3 opciones que pediste (a/b/c) + el FORENSE están **todas completas**:
-- ✅ (a porción + visualización) graph.json mostrado + backbone SVG/Mermaid renderizado
-- ✅ (c) commits a 3 remotos (`13b41c4`, `a258ca7`, `2e99fcb`)
-- ✅ (b) notebook desplegado y live en render.brasaluz.com
-- ✅ FORENSE SSH cx43 diagnosticado + validado
-
-**Pila pendiente (única):** 🟠 rotar la key OpenRouter leaked (`sk-or-v1-6ea27f5c…`) — deuda abierta desde la corrida graphify autorizada.
-
-Con SSH de vuelta, ¿quieres que aborde la rotación de la key OpenRouter ahora, o seguimos con otra cosa?
+📌 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?