ember-memory-test/episodes/DEPURA_prlogo-go-de-purga-de-los-50-payloads_S20260610.R36_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
1acadd79-ba6a-448f-85bc-876d1aa68b55	DEPURA_prlogo-go-de-purga-de-los-50-payloads_S20260610.R36_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260610.SELFAWARENESS_MISION_CRITICA	informar	multi_actor	low	TESSERA	operations	troubleshooting	EPISODIO 36 — ember_shared: 📖 Prólogo — GO de purga de los 50 payloads `MNEMO_BUG_FORENS	claude_code	internal	2026-06-11T02:41:45.372720+00:00	false	pending

El hook tiene razón en la forma: comprimí el prólogo apoyándome en el del turno anterior, pero la decisión del GO merece su historia completa y autocontenida. Aquí va, 5/5:

📖 Prólogo — GO de purga de los 50 payloads MNEMO_BUG_FORENSE_MAP

1) Reframe — qué se decide realmente. No es "¿borro unos archivos de una cola?". Es la última palabra sobre el destino del contenido pre-purga: el REINICIO_PERFECTO S20260608 limpió la memoria, pero estos 50 episodios sobrevivieron escondidos en la cola local LOOP_WRITE. Decidir purgarlos es completar el reinicio que ya ordenaste; decidir grabarlos es revertirlo parcialmente.

2) Historia — cómo llegamos aquí. Tu mandato REINICIO_PERFECTO (S20260608) fue borrar y regrabar limpio. Quedaron 74 payloads pre-purga atrapados en la cola. Hoy elegiste la vía incremental: pusheé 24 (verificados con retrievals 4/4 HIT@1) y para los 50 restantes elegiste Camino B: revisar antes de grabar, anticipando que "ahí no hay mucho por rescatar". La revisión íntegra (docs/REVISION_50_PENDIENTES_MNEMO_S20260610.md) confirmó tu hipótesis: 22 son ruido idle, 21 son ecos de contenido que ya vive en docs/git/TOOLBOX, y los 7 candidatos restantes contienen métricas pre-purga hoy falsas (ej. "4742 pts" cuando hay 639) que contaminarían el retrieval.

3) Consecuencias por camino:

• (GO purgar): limpio los 50 de session_state_MNEMO_BUG_FORENSE_MAP.json + regenero el manifiesto → cola queda en 8 (solo episodios frescos de esta sesión). La memoria post-reinicio queda sin contaminación pre-purga. Lo que se pierde: nada irrecuperable — el contenido factual sigue en docs/, git y TOOLBOX; solo desaparece la copia conversacional. Reversibilidad: baja una vez purgado (la cola no se reconstruye), por eso pido GO explícito.
• (NO-GO, grabar igual): los 50 entran a Qdrant; ganas fidelidad histórica del registro conversacional, al costo de ~22 episodios basura + métricas falsas en retrieval — contradice el propósito del reinicio.
• (Posponer): el zombie-filter de 7 días (memory_loop.py:169) los descartará solos en ~4 días — misma purga, pero por inacción y sin trazabilidad.

4) Inclinación razonada + qué la cambiaría. GO purgar, con el gap ember_shared = 0 puntos (único hallazgo no registrado en otro lado) preservado en la PILA y en el doc de revisión — conocimiento rescatado sin re-grabar el episodio. Cambiaría mi inclinación solo si valoras la fidelidad del registro conversacional por encima de la limpieza del retrieval — pero tu propio mandato de reinicio dice lo contrario.

5) Pregunta esencial aislada: ¿GO para purgar los 50 de la cola? (Una palabra basta; al recibirla ejecuto purga + regeneración del manifiesto + commit BLINDADA-29 del doc de revisión.)

Anotado — el reporte de efectividad de hooks se regeneró automáticamente (docs/REPORTE_EFECTIVIDAD_HOOKS.md, 11 verdicts · 10 hooks); es mantenimiento del Stop hook, sin acción requerida.

Sigo en espera de tu GO/NO-GO para la purga de los 50 payloads pre-purga de la cola LOOP_WRITE — el prólogo completo está en mi mensaje anterior y el detalle en docs/REVISION_50_PENDIENTES_MNEMO_S20260610.md.