feat(episode): TRAZA_r5-informe-4-entregado-runbook-de-memo_S20260823.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: TESSERA | Type: troubleshooting
Summary: EPISODIO 1 — MEMORIA: R5 · Informe 4 entregado + runbook de memoria corregido

episodes/TRAZA_r5-informe-4-entregado-runbook-de-memo_S20260823.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,33 @@
+---
+episode_id: "61849547-69f9-4bed-8694-7f181ebd79ee"
+puente_flat: "TRAZA_r5-informe-4-entregado-runbook-de-memo_S20260823.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
+session_code: "S20260823.SID2AEA91FA85F2"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "low"
+skill_dominante: "TESSERA"
+fase_proyecto: "operations"
+tipo_semantico: "troubleshooting"
+summary_one_line: "EPISODIO 1 — MEMORIA: R5 · Informe 4 entregado + runbook de memoria corregido"
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-08-24T03:44:03.301988+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+# R5 · Informe 4 entregado + runbook de memoria corregido
+
+**CHECKPOINT (B3):** entregados 4 informes (uno por fuente) + fila COLA_JOHN con 5 candidatas + runbook de memoria corregido con AVISO · pendiente: próximas fuentes de John · GAUGE 🟢 GREEN.
+
+## [R5.seccion1.I1] Lo que esta fuente forzó a descubrir
+
+Informe entregado 👆: [ANALISIS_S20260823_store_inject_recall_video4_vs_ember.md](docs/ANALISIS_S20260823_store_inject_recall_video4_vs_ember.md). El video (síntesis del mismo creador de la fuente 1) no trajo arquitectura nueva — pero verificarlo pieza por pieza produjo el hallazgo más delicado de la serie:
+
+**Hay DOS "fusiones" en la historia de EMBER y se estaban mezclando.** La **embedding-fusión** (qué se embebe: texto+preguntas, write-time) midió hit@1 20%→60% y es la palanca buena congelada por el freeze. La **ranking-fusión V1** (cómo se rankea: dense+keyword-IDF+entity, retrieval-time) midió **−0.007/−0.057 en held-out** ("la fusión RESTA") y además ni siquiera está desplegada en producción. El problema: el runbook de mi memoria (`reference_uso_memoria_oraculo.md`) prescribía `fusion=True` — la ranking-fusión — como "la búsqueda ganadora", citando un 0.608 exploratorio que las mediciones posteriores refutaron. **Corregido en el acto** con AVISO estilo DLC-2 (texto original preservado, reconciliación por recencia PR-8): cualquier instancia futura que lea ese runbook verá primero la corrección con sus números.
+
+**Y una auto-corrección honesta de mi consejo del informe 3:** te dije "la fusión es la primera bala post-freeze". El §6b del propio runbook matiza: el **factor dominante del recall es el tamaño del pool** (0.36 con pool de 145 candidatos vs 0.06 con 828 — 6× de degradación solo por volumen). La primera evaluación post-freeze debe mirar pool + embedding-fusión **juntas**, no la fusión sola.
+
+Otros dos hallazgos del workflow: la **asimetría BM25** (la doctrina de escritura TP-1 optimiza para un BM25 léxico que el retrieval desplegado — denso puro — jamás ejecuta), y la confirmación de que el "curator cada 7 días" de Hermes es exactamente el hueco de la candidata (2): cuarta fuente consecutiva apuntando al mismo órgano dormido. Del lado bueno: ENGRAMA supera a las herramientas de memoria de Hermes, TECHO_MEMORY son sus "caps" decididos antes y con instrumento, y el resumen autorado at-write con fallback `gemini-flash` supera al Haiku-por-turno del video.
+
+—