feat(episode): TRAZA_por-qu-no-se-unifica-3-razones_S20260621.R3_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: NONE | Type: chronicle
Summary: EPISODIO 3 — PostgreSQL: ¿Por qué NO se unifica? (3 razones)

episodes/TRAZA_por-qu-no-se-unifica-3-razones_S20260621.R3_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,33 @@
+---
+episode_id: "0044d5ae-3aa7-4d58-a4f9-681a9685f2e4"
+puente_flat: "TRAZA_por-qu-no-se-unifica-3-razones_S20260621.R3_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
+session_code: "S20260621.CRONICA_SEMANAL_C15"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "low"
+skill_dominante: "NONE"
+fase_proyecto: "operations"
+tipo_semantico: "chronicle"
+summary_one_line: "EPISODIO 3 — PostgreSQL: ¿Por qué NO se unifica? (3 razones)"
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-06-21T18:56:57.339395+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+## ¿Por qué NO se unifica? (3 razones)
+1. **Requisitos en conflicto (lo de arriba):** unificar obliga a una base a renunciar a su invariante. Si todo usara el uuid5-del-contenido → PostgreSQL pierde la estabilidad de su PK (el id cambiaría al editar el contenido, rompiendo referencias). Si todo usara uuid4 aleatorio → Qdrant pierde la deduplicación automática.
+2. **No hace falta:** el sistema **ya tiene** un identificador unificado e idéntico en los 3 — **`puente_flat`** (estable, derivado de título+sesión+facets, no del contenido completo). Ese ya hace el trabajo de cruce que tú esperas. Unificar `episode_id` además sería esfuerzo redundante.
+3. **Costo de migración:** cambiar la PK de PostgreSQL en 284 filas + sus referencias = refactor riesgoso, para ganancia marginal (ya tenemos puente_flat).
+
+## Mi veredicto honesto
+El diseño es **defendible** (cada base con su id óptimo + `puente_flat` como llave común). PERO **el wart real es el NOMBRE**: llamar `episode_id` a dos cosas distintas (el uuid4 de PostgreSQL y el uuid5 de Qdrant/Neo4j) es lo que confunde — parece que "deberían" coincidir y no. Un diseño más limpio renombraría: `pg_pk` vs `qdrant_point_id`, dejando claro que NO son la misma cosa, y `puente_flat` como la única llave de cruce. Eso es cosmético/documental, no funcional.
+
+**Si quisieras unificar de verdad** (un solo `episode_id` = el uuid5-del-contenido en los 3), se PUEDE — pero aceptando que PostgreSQL pierde la PK estable (el id mutaría al editar contenido). Es una decisión de diseño tuya; no la fuerzo, solo te dejo el trade-off claro.
+
+### 📍 PARA JOHN — R2
+- **Respondido:** `episode_id` = matrícula interna de cada base (PK / point-id); difiere porque PostgreSQL la quiere estable-aleatoria y Qdrant la quiere derivada-del-contenido (para deduplicar) — requisitos opuestos. No se unifica porque `puente_flat` ya cumple el cruce y unificar obligaría a una base a perder su invariante.
+- **Si te sirve:** puedo (a) añadir esta explicación + el renombre sugerido al doc `MAPA`, o (b) si te interesa el diseño "un solo id", lo evaluamos formalmente con su trade-off. Sin prisa — dime.
+
+⛽ 🟢 GREEN ~805K