feat(episode): DEPURA_verificado-el-drain-est-funcionando-joh_S20260606.R5_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: NONE | Type: troubleshooting
Summary: EPISODIO 5 — PostgreSQL: **Verificado — el drain está funcionando, John** (revis

episodes/DEPURA_verificado-el-drain-est-funcionando-joh_S20260606.R5_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -1,25 +1,43 @@
 ---
-episode_id: "f7d3bb1d-e09c-44f1-947f-556553dba04f"
+episode_id: "be944127-1f0a-4918-b9c3-d1dc20d1f05a"
 puente_flat: "DEPURA_verificado-el-drain-est-funcionando-joh_S20260606.R5_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
 session_code: "S20260606.MEMORY_LOOPWRITE_LEXICON_DRAIN"
 acto_dialogico: "informar"
 actor_flujo: "multi_actor"
 criticidad_aegis: "low"
-skill_dominante: "TESSERA"
+skill_dominante: "NONE"
 fase_proyecto: "operations"
-tipo_semantico: "reflection"
+tipo_semantico: "troubleshooting"
 summary_one_line: "EPISODIO 5 — PostgreSQL: **Verificado — el drain está funcionando, John** (reviso..."
 source_type: "claude_code"
 trust_boundary: "internal"
-created_at: "2026-06-06T23:53:58.178894+00:00"
+created_at: "2026-06-09T08:00:10.277166+00:00"
 relectura_tagged: false
 forgejo_commit_sha: "pending"
 ---
 
-Pero como el inbox está enorme → el crisol es lento → **timeout** (justo lo que vimos: `cleared=0, status=fallback, pipeline timeout`). Sin limpiar la cola → el siguiente drain **re-SCPea los MISMOS payloads como `.md` nuevos** (timestamp nuevo) → el inbox crece → el crisol va más lento → más timeout. **Cada instancia × cada intento de drain × el día = el mismo episodio copiado decenas de veces.**
+**Verificado — el drain está funcionando, John** (reviso resultado real, no output stale):
 
-Y esto **es el origen real del lag** que encontré: las memorias frescas no se recuperan porque esperan detrás de 6760 archivos (4333 de ellos basura duplicada) en el inbox. **Lo bueno:** este fix YA estaba identificado como deuda diferida — el MANUAL dice *"Fix arquitectónico completo (check content_sha256 vs PostgreSQL pre-write) diferido Día 8 sprint dedicado"*. Lo acabamos de confirmar empírico. ## Tu pedido original: ✅ hecho (con matiz)
+| Señal | Estado |
+|---|---|
+| **`.md` en el inbox del crisol** | ✅ **CONFIRMADO** — `ember_ep_20260606_234248_*.md` presentes (los episodios SCP'eados llegaron al servidor) |
+| **Crisol procesando** | ✅ `procesados/` activo (crisol F0-F6 consumiendo) |
+| **Proceso drain** | 🔄 sigue vivo (esperando que crisol_run termine F0-F6 + outbox) |
+| **Cola local** | 14 (subió de 10 — nuevas respuestas se encolan en paralelo; dinámica normal) |
 
-Tus episodios **SÍ entraron al pipeline completo** (están en el inbox, el crisol los procesará). Pero se sumaron a un inbox contaminado. ## Decisión (PRÓLOGO) — el fix tiene dos partes
+**Lo importante ya pasó:** los episodios **entraron al pipeline COMPLETO** — están en el inbox del crisol (`/home/johnember/ember-ecosystem/crisol/inbox/`), que es el punto de entrada de F0-F6. De ahí, `crisol_run.py` los distribuye con quintuple-write outbox a **Qdrant + PostgreSQL + Neo4j + Nextcloud + Forgejo**. No es un push Qdrant-only — es la ingesta completa que pediste. El batch más reciente del inbox (23:42) aún no aparece en `procesados/` (último 22:31), así que el crisol **está mid-run procesándolos ahora mismo**. El proceso background me notificará al cerrar; entonces verifico el aterrizaje final en los 5 stores + corro retrieval HyDE de uno drenado para confirmar que **ahora SÍ se recupera** (cierre del lag). Dejo que el crisol termine F0-F6 — es el pipeline robusto server-side, no lo interrumpo. Te reporto los conteos finales por store apenas complete. 🔥
 
-1. **Dedup del inbox** (inmediato): borrar las 4,333 copias redundantes, dejar las 2,427 únicas → el crisol se pone al día rápido + las memorias frescas se vuelven searchables. **PERO es destructivo** (rm en pipeline vivo con crisol activo + otras instancias) → requiere tu OK explícito (LEY ZERO). 2. **Fix raíz** (`push_to_server` idempotente): chequear `content_sha256` antes de SCPear → no re-pushear contenido ya en inbox/procesados. Cierra el ciclo vicioso. Mi inclinación: **dame el GO y hago las dos** — dedup seguro (verificando que conservo 1 copia de cada contenido único, con backup del listado) + el fix de idempotencia. Es el sprint "Día 8" que ya estaba diferido, y cierra deuda real. ¿Procedo, John?
+🔴 **CONFIRMADO — bug de re-push, John. Esto es lo que tu insistencia destapó:**
+
+## El hallazgo: el inbox del crisol está 64% duplicado
+
+| Métrica | Valor |
+|---|---|
+| Archivos `.md` en inbox | **6,760** |
+| Contenidos ÚNICOS (md5) | **2,427** |
+| **Duplicados redundantes** | **4,333 (64%)** |
+| Peor caso | un mismo episodio **re-pusheado 87 veces** |
+
+## Causa raíz (FORENSE)
+
+Es un **ciclo vicioso de re-push**: `push_pending_to_server` solo limpia la cola (`pending_qdrant_payloads`) si el crisol confirma éxito **completo**.