ember-memory-test/episodes/TRAZA_1-pipeline-mnemo-sano_S20260618.R4_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
0c7a1be4-813d-46c6-a319-212b03555f8a	TRAZA_1-pipeline-mnemo-sano_S20260618.R4_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260618.VERIFY_FIRST_PASSPORT_FIX	informar	multi_actor	low	TESSERA	operations	troubleshooting	EPISODIO 4 — ember_experience: 1. Pipeline MNEMO — 🟢 SANO	claude_code	internal	2026-06-19T06:17:39.489228+00:00	false	pending

Leído el gate — ahora te lo cuento con precisión. Te respondo las 3 cosas que preguntaste, medidas en vivo hace un momento:

1. Pipeline MNEMO — 🟢 SANO

Señal	Valor (medido ahora)
Episodios PostgreSQL	249 (último hace minutos: 05:58) — ingiriendo en vivo
Completitud episode_outbox	249 completed / 0 partial ✅ (el fix Opción Y aguanta)
Qdrant ember_experience	248 (−1 vs PG = trailing inline benigno, no pérdida)

El pipeline ingiere, graba en los 5 stores y la completitud es perfecta. Nada roto.

2. Retrievals — 🟢 MEJORADOS HOY (fusión V1 desplegada)

search_memories ya defaultea fusión V1 en producción. A/B en vivo de hace minutos (kernel desplegado, 60 self-queries de ember_experience):

• denso 0.40 → V1 0.65 recall@1 (+0.25, 1.63×) · recall@5 0.65 → 0.883.

El re-ranking es real y verificado (el fused_score invierte el orden denso para subir el mejor match a #1).

3. El oráculo — ✅ SÍ FUNCIONA, pero da FAIL (por un pelo) — y la razón conecta con la fusión

retrieval_gate.py corre bien: ejecuta dos sub-oráculos (oracle_hyde + oracle_clean), registra historial y emite veredicto. Umbral: HyDE recall@10 ≥ 0.70 Y clean lenient@1 ≥ 0.85.

• ✅ Salud del embedding OK: clean_lenient@1 = 0.935 (≥ 0.85) — el espacio vectorial está sano.
• ❌ Encontrabilidad falla por 0.023: hyde_recall@10 = 0.677 < 0.70.
• El punto clave [inference, alta confianza]: el oráculo HyDE mide retrieval DENSO (recall@1 = 0.295 ≈ el baseline denso de siempre). Todavía NO usa la fusión V1 que acabo de desplegar. Mi A/B mostró que la fusión sube recall@1 de 0.40→0.65 — si el oráculo midiera la fusión, su recall@10 casi con seguridad cruzaría el 0.70 → PASS.

En una frase: el pipeline está sano, los retrievals mejoraron (fusión live), y el oráculo funciona — pero su veredicto FAIL refleja el denso viejo, no la fusión nueva. La fusión que desplegué es justo la palanca que cerraría ese 0.023.

📍 PARA JOHN — R30

• Estado: pipeline 🟢 · retrievals 🟢 (fusión +1.63× live) · oráculo ✅ funciona, veredicto FAIL por encontrabilidad denso 0.677<0.70.
• Mi consejo: la acción de más valor ahora es wirear oracle_hyde.py a la fusión + re-correr el gate. Hipótesis fuerte: FAIL→PASS, porque la fusión sube el recall que el gate mide. Cierra el lazo — el oráculo reflejaría la mejora ya desplegada. Es ~15 min, load-bearing leve (toco el script de medición, no el pipeline).
• ¿Lo hago? 🟢 Sí, wirear el oráculo a la fusión y re-medir · ⚪ No, déjalo así y lo cuento como pendiente.

📌 PILA-PENDIENTES (R30)

• 🟠 HIGH · G-ORACLE-010 (NUEVO) — wirear oracle_hyde.py a la fusión V1 + re-correr retrieval_gate.py (hipótesis FAIL→PASS). [origen: gate FAIL recall@10 0.677, fusión no usada]
• ✅ RESUELTA · D-FUSED-001 fused-search V1 desplegado+validado+respaldado (c834903).
• 🟡 MEDIUM · G-ABCORPUS-008 A/B duro (mnemo_lab) · G-C2-002 C2 watchdog · D-XB-004 X-b.
• ⚪ LOW · G-DUR-005 · G-WIKI-007 · G-COSECHA-009 (cierre).