ember-memory-test/episodes/DEPURA_prlogo-la-decisin-de-capa-2-los-4-near_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
646b8fef-9d54-4ec7-be07-b21a5058f231	DEPURA_prlogo-la-decisin-de-capa-2-los-4-near_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	TESSERA	operations	troubleshooting	EPISODIO 3 — MEMORIA: 📖 Prólogo — la decisión de Capa 2 (los 4 near-dups existente	claude_code	internal	2026-06-18T14:14:01.563366+00:00	false	pending

Tienes razón — surfacé el fork de Capa 2 sin contarte la historia de la pregunta. Lo corrijo (la integridad ya está cerrada; esto es solo para que decidas Capa 2 con el contexto completo, sin prisa):

📖 Prólogo — la decisión de Capa 2 (los 4 near-dups existentes)

1. Qué se decide realmente. No es "¿limpiamos basura?" — es si vale la pena un borrado irreversible multi-store para ganar ~3,5% de pulcritud en un corpus que ya recupera bien. La pregunta es de proporcionalidad riesgo/beneficio, no de higiene.

2. De dónde viene. En la verificación de retrieval encontré que 4 episodios (sobre ~112) son re-emisiones near-dup: respuestas casi idénticas de turnos "Continue" con content_sha256 distinto, que el sha-guard B-004 no atrapaba. Ensuciaban el ranking semántico (empujaban el target al fondo del top-5 en queries sobre HyDE exactas). Capa 1 — el guard que ya desplegué e intacto — evita que nazcan nuevos. Capa 2 sería limpiar los 4 que ya existen.

3. Consecuencias por camino, en tu situación real.

• Dejarlos (A): el retrieval de queries reales ya funciona (lo verificamos: bullseye en lenguaje natural). Los 4 solo degradan un caso de borde (query == HyDE textual). Costo: un corpus levemente menos pulcro. Reversible: siempre puedes limpiarlos después.
• Borrarlos (B): corpus impecable, pero es un DELETE en 3 stores (Qdrant+PG+Neo4j) — irreversible. Mitigado con archivado previo (backup del contenido a JSON), pero una vez borrado, recuperar es manual. Y rompe momentáneamente la consistencia cross-store que acabamos de validar 5/5 (se re-cuadra al borrar de los 3 a la vez).

4. Mi inclinación. Me inclino por A (dejarlos). Razón: el beneficio es marginal y de borde, el riesgo es irreversible, y el guard ya frenó la hemorragia. Lo que me haría cambiar a B: que me digas que este corpus va a ser base de algo donde el ranking exacto importa (un benchmark, una demo medida), o que simplemente prefieres cero deuda visible y aceptas el archivado como red de seguridad.

5. La pregunta esencial — lo único que solo tú pones: ¿Este corpus de memoria necesita estar impecable ahora, o "funciona bien para queries reales" es suficiente hasta que haya una razón concreta para pulirlo?

No hay prisa: la integridad está confirmada y el guard protege el futuro. Cuando quieras, A / B / C.