ember-memory-test/episodes/DEPURA_verificado-el-drain-est-funcionando-joh_S20260606.R13_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
8d1e002d-b4d1-478b-b12e-c09ce007a127	DEPURA_verificado-el-drain-est-funcionando-joh_S20260606.R13_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 13 — PostgreSQL: **Verificado — el drain está funcionando, John** (reviso...	claude_code	internal	2026-06-08T18:28:56.423172+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?