ember-memory-test/episodes/TRAZA_prlogo-qu-ests-decidiendo-realmente_S20260801.R1_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
cbfff82e-dd70-410f-a62f-277e23ec9e04	TRAZA_prlogo-qu-ests-decidiendo-realmente_S20260801.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260801.PIPELINE_FIXES	informar	multi_actor	low	TESSERA	operations	troubleshooting	EPISODIO 1 — MNEMO_PRE_DIGEST: Prólogo: qué estás decidiendo realmente	claude_code	internal	2026-08-02T00:54:30.032754+00:00	false	pending

Completo el prólogo de la decisión que dejé abierta — la dejé como menú con recomendación, sin la historia que te permite juzgarla. Cuando la retomes no tendrás este contexto fresco.

Prólogo: qué estás decidiendo realmente

El reframe. No estás eligiendo "qué tarea sigue". Estás eligiendo entre reparar el instrumento o perseguir lo que el instrumento señaló. Son cosas distintas y compiten: mientras el retrieval_gate siga emitiendo un FAIL compuesto, cualquier anomalía futura volverá a esconderse igual que esta — incluso si hoy cazas la causa del escalón del 20 de julio.

De dónde viene. El gate se diseñó con dos condiciones unidas por AND porque ambas debían cumplirse para declarar el retrieval sano. Razonable. Lo que nadie previó es que una de las dos métricas se endurece sola con el tiempo (más corpus, más competencia por la primera posición), así que su FAIL se volvió esperable — y el ojo aprende a descontar lo esperable. Cuando la otra métrica se rompió de golpe, el sistema ya llevaba semanas gritando "FAIL" por la razón aburrida. Trece días.

Las consecuencias, en tu situación real. Tienes dos ventanas trabajando y una cola de decisiones con cinco abiertas, la más vieja de 28 días. Eso importa aquí:

• Si separas los veredictos (A): es un cambio pequeño en retrieval_gate.py, sin dependencias, y arregla una clase — no solo este caso. Cualquier gate del ecosistema con umbral AND tiene el mismo defecto latente. Coste: bajo. Riesgo: bajo. No responde qué pasó el 20 de julio.
• Si persigues la causa (B): exige desbloquear la autenticación del servidor MEMORIA y meterte en el carril de pipeline-memoria, donde la otra ventana ya opera. Puede darte la respuesta exacta… o abrirte un FORENSE largo con cuatro hipótesis vivas. Y si no reparas el instrumento, la próxima anomalía se esconderá otra vez mientras excavas ésta.
• Si vas a las recomendaciones del informe (C): es trabajo nuevo sobre un sistema cuyo sensor de retrieval sigue sin discriminar.

Mi inclinación y qué la cambiaría. Me inclino por A porque cierra una clase de fallo por un coste mínimo, y porque el escalón lleva 13 días — trece más no lo empeoran, pero un instrumento ciego sí. Lo que me haría cambiar de opinión: si sospechas que el escalón indica pérdida real de memoria (episodios corrompidos, no solo recall degradado), entonces B es urgente y A puede esperar — porque ahí lo que está en juego no es la medición, son los datos.

La pregunta que solo tú puedes responder: ¿el escalón del 20 de julio te huele a métrica que se rompió o a memoria que se dañó? De eso depende todo lo demás; el resto ya lo tengo medido.