ember-memory-test/episodes/TRAZA_hice-todo-el-backlog-del-chat-rescate_S20260712.R3_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
2a5ea17f-c26a-4440-8d3c-3e90ae073191	TRAZA_hice-todo-el-backlog-del-chat-rescate_S20260712.R3_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260712.SHERPA_MISION1_LOOPWRITE	informar	multi_actor	low	TESSERA	operations	troubleshooting	EPISODIO 3 — MNEMO: - **Hice:** todo el backlog del chat: rescate...	claude_code	internal	2026-07-12T17:18:05.755046+00:00	false	pending

1. El hallazgo diagnóstico principal — la contradicción de contratos que nadie había visto. El pipeline MNEMO tenía dos reglas del mismo ecosistema peleándose en silencio: la regla MNEMO-HYDE exigía ≥10 preguntas HyDE por episodio, pero el schema de PostgreSQL aceptaba máximo 5. Resultado: PostgreSQL llevaba 5 días congelado rechazando todo episodio nuevo, y tres capas de contabilidad mentían "success" encima. Nadie lo había detectado porque el pipeline se auto-reportaba sano. Ese es el hallazgo mayor: el sistema puede estar roto y decir que está bien. Se arregló, pero la lección de mejora es estructural — hacía falta reconciliar contratos entre capas, no solo dentro de una capa.

2. El hallazgo de calidad que SÍ era mejora no explorada — las preguntas HyDE mecánicas. Al auditar el corpus, Fable descubrió que ~145 de 206 episodios tenían preguntas de recuperación generadas por plantilla ("¿Qué pasó con:…", algunas vacías) en vez de preguntas dignas. Estas preguntas mecánicas arrastran el recall hacia abajo sin ser duplicados. La mejora que ejecutamos: un fan-out de 12 agentes autoró 1.400 preguntas HyDE específicas (10 por episodio, ancladas en los datos reales). Efecto medido: recall@10 subió de 0.794 a 0.852 sobre un corpus 77% más grande. Esta era la palanca que no habíamos tocado antes.

3. El hallazgo que evitó destruir memoria — el criterio de cobertura semántica. La hipótesis previa era "el exceso de puntos en Qdrant es basura duplicada, bórrala". Fable la refutó con verify-first: 206 de esos puntos eran memoria única que solo vivía en Qdrant, sin copia en PostgreSQL. Un dedup a ciegas los habría matado. El criterio nuevo (cobertura de tokens contra el corpus canónico) distingue "variante vieja redundante" de "único a rescatar". "El dedup correcto no es el que más borra — es el que sabe qué no borrar."

Lo que Fable dejó IDENTIFICADO para mejorar (aún sin hacer)