ember-memory-test/episodes/TRAZA_para-john-r2_S20260621.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
a3f029ff-bfba-46a5-9588-45581a4295e8	TRAZA_para-john-r2_S20260621.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260621.CRONICA_SEMANAL_C15	informar	multi_actor	low	TESSERA	operations	reflection	EPISODIO 1 — PostgreSQL: 📍 PARA JOHN — R2	claude_code	internal	2026-06-28T15:48:22.217674+00:00	false	pending

Listo, John — 3 episodios completos, crudos, en los 3 stores: docs/EPISODIOS_COMPLETOS_3STORES_S20260621.md. Cada uno con su contenido íntegro literal + todos los campos reales por store.

Los 3 que verás completos:

• A — "PARA JOHN R1" (principio grafos-perennes) · 2.266 chars
• B — "La historia de esta decisión / PRÓLOGO" (settings.json D3) · 2.631 chars
• C — "Checkpoint de ejecución" (PROBATOR C1) · 2.117 chars

Lo que el dump confirma (8 asimetrías, repetidas en los 3):

• Identidad fragmentada: cada episodio tiene 3 ids — PostgreSQL uuid4 propio vs Qdrant/Neo4j uuid5 (= prefijo del content_sha256). Solo puente_flat los une.
• Contenido duplicado 2× (PostgreSQL content_text + Qdrant content); Neo4j no guarda contenido (solo título + 9 props + aristas :MENTIONS).
• Columnas PostgreSQL muertas: embedding = ceros, blc_hash = ceros (el vector y la cadena BLC viven solo en Qdrant).
• 2 inconsistencias que NO son formato (el pipeline escribe versiones distintas a cada store):
  • has_code: PostgreSQL false vs Qdrant true (mismo episodio).
  • hyde_queries: PostgreSQL 5/5/3 vs Qdrant 10/10/10.
• Doble encoding de facets: PostgreSQL palabras/floats (informar, 0.9, low) vs Qdrant abreviado/letras (inf, H, 2).

📍 PARA JOHN — R2

• Hice: dump literal de 3 episodios completos en los 3 stores (contenido + todos los campos), doc entregado. Cacé una inconsistencia nueva: has_code difiere PostgreSQL↔Qdrant.
• Para tu consejo, lo que destaca: cada store tiene rol coherente, pero hay deuda real — contenido 2×, 2 columnas PostgreSQL muertas, y el pipeline F0-F6 escribiendo versiones distintas del mismo episodio (hyde 5 vs 10, has_code false vs true). Eso último es lo más serio: significa que la "verdad" de un episodio depende de qué store consultes.
• Pregunta para ti: ahora que ves el storage real — ¿qué te preocupa más para profundizar? (a) la integridad BLC solo-en-Qdrant, (b) las inconsistencias del pipeline (hyde/has_code distintos por store), (c) la redundancia/columnas muertas, o (d) traer más episodios de otros tipos/colecciones. Dime y voy a fondo donde tú veas.