ember-memory-test/episodes/TRAZA_estn-los-52-elementos-en-el-planteamient_S20260808.R2_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
46cd69bd-d842-44b9-8fe3-8cd192b0b332	TRAZA_estn-los-52-elementos-en-el-planteamient_S20260808.R2_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260808.MEMORIA_SOTA_BRECHA	informar	multi_actor	low	NONE	operations	troubleshooting	EPISODIO 2 — MEMORIA: ¿Están los 52 elementos en el planteamiento de Fable? **No.*	claude_code	internal	2026-08-12T00:24:20.484783+00:00	false	pending

Arnés reparado y verificado en las dos direcciones.

Con Qdrant vivo: exit 0 y cifras idénticas al original — 0.146 / 0.420 / 0.232. El guard no estorba la medición sana. Con Qdrant caído: exit 2, cero bytes de salida, diagnóstico con la pista.

Ahora tu pregunta, que es más importante.

¿Están los 52 elementos en el planteamiento de Fable? No.

Y conviene ver por qué, porque hay tres insumos que Fable no tenía cuando planeó:

Insumo	¿Lo tuvo Fable?	Qué cambia
El estado del arte + vías muertas	✅ sí	Su plan actual
Los 52 elementos	❌ no	Tres activos escritos e inertes
El recall real (0.146/0.420)	❌ no	Su gate más incierto ahora pasa

★ Insight ───────────────────────────────────── Fable planeó creyendo que el recall era 0.06 y que su gate del reranker probablemente fallaría. La medición de hoy dice 0.146 con 0.420 en el top-10: el gate pasa con holgura. Su plan es mejor de lo que él pudo saber. Y el inventario añade algo que ni contempló: que las preguntas sembradas, el léxicon y el parentesco entre hermanos ya están escritos y nadie los usa al buscar. ─────────────────────────────────────────────────

Eso significa que el análisis de los 52 campos que pediste no es un extra: es lo que puede reordenar sus prioridades. Con recall@10 = 0.420 sabemos que el recuerdo correcto llega el 42% de las veces y solo se coloca primero el 14,6% — hay un 27,4% recuperable. Y varios de los 52 campos inertes son candidatos directos a cerrar ese hueco.

Hice. El arnés reparado, con control positivo y negativo verificados. El original queda intacto; la versión sana convive con él. Y tengo la medición 1: 0.146 / 0.420.

Falta, en el orden que tú fijaste:

1. Mi segunda medición — probar si indexar las preguntas sembradas mejora el recall.
2. La medición de Fable sobre lo mismo, ya con el arnés que no miente.
3. Su análisis de los 52 campos: cómo interactúan y cuáles sirven para cerrar el 27,4%.

Una cosa que sí debo advertirte. El arnés reparado vive en el servidor MEMORIA, fuera del repositorio. Si nadie lo respalda, se pierde en el próximo trasteo — igual que se perdió el hecho de que el 0.06 estaba obsoleto. Propongo copiarlo al repositorio junto con un registro de la reparación y de las cifras nuevas.

¿Sigo con mi segunda medición, o prefieres que primero respalde el arnés y documente el hallazgo del 0.146?