ember-memory-test/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

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
49d4298f-fdc0-44ad-b626-6e9ffe9f1db8	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	S20260831.SIDB92171056337	informar	multi_actor	low	NONE	operations	troubleshooting	EPISODIO 2 — PostgreSQL: 1. Qué se decide de verdad: no es...	claude_code	internal	2026-09-06T16:08:54.326077+00:00	false	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.