ember-memory-test/episodes/TRAZA_1-dv-2-es-explcita-un-reindexado-de-qdra_S20260802.R7_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
0895cae8-c470-4837-8dc2-d0d6d1763ead	TRAZA_1-dv-2-es-explcita-un-reindexado-de-qdra_S20260802.R7_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260802.SELFAWARE_FASE2_FRESCURA	informar	multi_actor	low	TESSERA	operations	design	EPISODIO 7 — ember_experience: 1. **DV-2 es explícita:** un reindexado de Qdrant...	claude_code	internal	2026-08-03T02:40:46.113395+00:00	false	pending

1. DV-2 es explícita: un reindexado de Qdrant va siempre por el crisol. Nunca por el outbox (los eventos no llegan a Qdrant por diseño) ni por la vía manual (duplicaría). Cualquier plan que no pase por el crisol repite el incidente del 26 de julio.

2. El crisol deduplica por contenido (content_sha256, DV-3). Si re-embebemos episodios cuyo texto no cambia, el crisol podría saltárselos por "duplicados" y dejar el vector viejo intacto — el re-embedding no haría nada y parecería exitoso. Esto hay que resolverlo antes de ejecutar, no durante.

Límite honesto: el censo estratificado por mes —el que daría el número exacto de episodios atrapados en el espacio viejo— no se pudo completar: cinco intentos SSH consecutivos fallaron por caída del canal. El "~731" que venimos usando sale de PostgreSQL y debe re-medirse contra Qdrant antes de dimensionar el trabajo. El script queda listo para relanzarlo cuando el canal vuelva.

—

Hice: verifiqué empíricamente las vías (100 % crisol, cero manual), mapeé qué proceso escribe cada uno de los cinco almacenes, y confirmé que la calidad no depende de la vía sino del espacio. Todo documentado y en los tres remotos (709ea7d8).

Falta: el censo exacto del espacio (canal SSH caído, script listo) y resolver el choque entre el dedup del crisol y el re-embedding.

Mi consejo: el riesgo del dedup cambia el orden de las cosas. Antes de fijar fecha de re-embedding hay que saber cómo forzar al crisol a reescribir un episodio cuyo contenido no cambió — si no, ejecutamos el plan y no pasa nada, con la peor consecuencia posible: creer que la memoria quedó curada cuando sigue partida. Es una lectura de código del crisol, no una decisión tuya.

Para avanzar: 🟢 A — investigo cómo forzar la reescritura en el crisol y te traigo el plan de re-embedding ya viable (recomendado) · 🟡 B — relanzo primero el censo para saber el tamaño exacto y luego lo anterior · ⚪ C — paramos aquí; queda todo documentado para retomarlo.

📌 PILA (R21): 🔴 dedup del crisol vs re-embedding (riesgo de fix fantasma) · 🟠 censo exacto pendiente (canal SSH) · 🟡 7 puntos sin embedding_model_id · 🟠 deuda estructural: escritura por LiteLLM vs lectura directa a OpenRouter · ✅ vías verificadas y documentadas.