ember-memory-test/episodes/TRAZA_completo-el-prlogo-de-esa-decisin_S20260618.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
c9ff0699-d932-4dce-86d1-71d630fc03c6	TRAZA_completo-el-prlogo-de-esa-decisin_S20260618.R3_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260618.VERIFY_FIRST_PASSPORT_FIX	informar	multi_actor	low	NONE	operations	troubleshooting	EPISODIO 3 — MNEMO: Completo el prólogo de esa decisión:	claude_code	internal	2026-06-18T18:10:35.343530+00:00	false	pending

Completo el prólogo de esa decisión:

Lo que realmente se decide (reframe): no es "arreglar un manifiesto stale" — la memoria ya está sana y el ciclo cerró solo. Es ¿invertimos ahora una sesión de coding en endurecer el pipeline, o neutralizamos solo la pieza con riesgo real (el doc engañoso) y diferimos la ingeniería a una ventana dedicada?

De dónde viene (historia): esto no nació como tarea — emergió de tu chequeo de integridad post-caída. La caída destapó la falsa alarma "N pendientes", que mnemo-keeper rastreó a un patrón de diseño (clear all-or-nothing) que lleva acumulando en silencio sin que nadie lo notara, más un AVISO que un sprint pasado (la reorg G-1-NEW / DLC-4) dejó escrito y que hoy describe mal la realidad — dice que el buffer es huérfano cuando es la vía viva.

Consecuencias por camino:

• A (fix de raíz + tests): elimina la recurrencia para siempre, pero toca hooks load-bearing del pipeline de memoria — el área más delicada del ecosistema. Costo: sesión RELOJERO con verificación triple. Riesgo: un bug aquí afecta toda la ingestión.
• B (mata la alarma): silencia el ruido del boot, pero deja la lógica de fondo intacta (la cola sigue convergiendo sola). Cosmético.
• C (corrijo el AVISO ya + difiero A): neutraliza el único riesgo real —que una instancia futura lea el AVISO stale y borre el buffer de fallback creyéndolo basura— en 2 minutos y sin tocar lógica, dejando el fix de ingeniería para cuando haya foco.

Hacia dónde me inclino: C ahora + A en ventana dedicada. La asimetría manda: el fix de raíz (A) es correcto pero no urge (la memoria está sana, la cola converge sola) y su blast radius es alto; en cambio el AVISO engañoso (C) es el único con riesgo asimétrico —barato de arreglar, caro si alguien actúa sobre la info falsa. Hacer A bajo presión, sin ventana de tests, sobre el pipeline crítico, sería imprudencia. Lo que cambiaría mi inclinación hacia A ya: que la falsa alarma te esté estorbando operativamente cada boot al punto de valer el riesgo de tocar el pipeline ahora.

La pregunta esencial, aislada: ¿esto amerita endurecer el pipeline ahora (A), o basta con desactivar el doc que miente (C) hasta una ventana con foco y tests?