feat(episode): TRAZA_1-qu-se-decide-de-verdad-no-es_S20260831.R2_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: NONE | Type: troubleshooting
Summary: EPISODIO 2 — PostgreSQL: 1. Qué se decide de verdad: no es...

episodes/TRAZA_1-qu-se-decide-de-verdad-no-es_S20260831.R2_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,28 @@
+---
+episode_id: "49d4298f-fdc0-44ad-b626-6e9ffe9f1db8"
+puente_flat: "TRAZA_1-qu-se-decide-de-verdad-no-es_S20260831.R2_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
+session_code: "S20260831.SIDB92171056337"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "low"
+skill_dominante: "NONE"
+fase_proyecto: "operations"
+tipo_semantico: "troubleshooting"
+summary_one_line: "EPISODIO 2 — PostgreSQL: 1. Qué se decide de verdad: no es..."
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-09-06T16:08:54.326077+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+1. **Qué se decide de verdad:** no es "¿lo arreglo?" — no hay nada roto que arreglar (es lag benigno). Es: *¿silencio este sensor de integridad cross-store para que el muro deje de estorbar, o lo dejo vivo y acepto que parpadee?*
+2. **De dónde viene:** el chequeo (`check_cross_store_episode_drift`, corregido en jul-2026) es deliberadamente asimétrico — solo un *déficit* >20 cuenta como fallo. Es un buen sensor, pero mide conteos crudos, así que no ve la diferencia entre "el crisol va detrás" (normal) y "se perdieron escrituras" (grave).
+3. **Consecuencias por camino:**
+   - **Registrar el drift** (en `drift_registrado.yaml`): el muro deja de estorbar ya, PERO el registro casa por *nombre de campo* → ese sensor queda **mudo aunque el déficit crezca a 500** (enmascara una pérdida real futura). Es apagar un muro.
+   - **Dejarlo auto-curar** (no registrar): cuando baje la actividad, el lag cae ≤20 y el DRIFT se apaga solo; el sensor sigue intacto. Costo: el muro puede bloquear alguna edición mientras tanto (mitigado con override puntual, como hice hoy).
+   - **Mejorar el chequeo** (comparar frescura/timestamps en vez de solo conteos, o subir TOL): elimina el falso positivo de raíz — pero es cambiar el comportamiento de un sensor, necesita tu GO y cuidado.
+4. **Mi inclinación (y qué la cambiaría):** **no registrar** — dejarlo auto-curar y, si quieres, apuntar la mejora del chequeo como pendiente con dueño+fecha. Un sensor de integridad silenciado es peor que un muro que estorba un rato. Lo que cambiaría mi consejo: si al diferenciar los IDs resultara que los 25 ausentes son **viejos** (no los nuevos), eso sería pérdida real y escalaría a arreglo inmediato.
+5. **La pregunta esencial, aislada:** **¿Dejo el sensor vivo (que el lag se cure solo), o quieres que registre el drift para desbloquear el muro ya — sabiendo que eso silencia ese sensor?**
+
+> 🎯 **En una frase:** el "desajuste" que asustaba NO es pérdida de datos — es que la copia buscable (Qdrant) va 25 episodios detrás del cuaderno oficial (PostgreSQL) porque el mensajero que los copia trabaja por tandas y va un poco atrasado; los 25 están a salvo y se copiarán solos.