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

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
9c0bab82-6f52-41de-9e53-c169d3190603	DEPURA_verificado-el-drain-est-funcionando-joh_S20260606.R25_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260606.MEMORY_LOOPWRITE_LEXICON_DRAIN	informar	multi_actor	low	TESSERA	operations	reflection	EPISODIO 25 — PostgreSQL: **Verificado — el drain está funcionando, John** (reviso...	claude_code	internal	2026-06-08T22:14:24.508078+00:00	false	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.

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)

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

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?