ember-memory-test/episodes/DEPURA_mem-04-resuelto-es-un-no-op-verificado_S20260704.R99_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
b1495782-b8fb-4ae1-b278-c584cbe88e74	DEPURA_mem-04-resuelto-es-un-no-op-verificado_S20260704.R99_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260704.ANTI_OLVIDO_ESTADO_VIVO	informar	multi_actor	low	NONE	operations	troubleshooting	EPISODIO 192 — MNEMO Pipeline: **MEM-04 resuelto — es un no-op verificado, con...	claude_code	internal	2026-07-12T16:17:05.997173+00:00	false	pending

MEM-04 resuelto — es un no-op verificado, con un hallazgo cross-store valioso. Confirmado: los 3 puente_flat de muestra dan 0 filas en PostgreSQL. Los 23 nodos NULL son huérfanos: existen en Neo4j pero no tienen fila en PostgreSQL, así que no hay session_code autoritativo de dónde copiar.

Qué hice y qué NO hice (zero-harm + FORENSE):

• ✅ Construí el script server-side (con tu GO), corrió las credenciales dentro del container (nunca salieron), dry-run limpio.
• ✅ NO escribí nada — el dry-run probó to_set=0, así que commit habría escrito 0 nodos. Correrlo no aporta; no toco Neo4j en vano.
• ✅ NO borré nada — son episodios reales (NO-HACER del plan; lección EXODUS S20260618). Canario lexicon intacto (15272=15272).

El hallazgo (gap real, distinto al que el plan asumió): MEM-04 esperaba "residuo backfilleable desde PostgreSQL", pero los 23 NULL son un problema más profundo: episodios que viven en Neo4j sin fila en PostgreSQL (drift de consistencia cross-store). Forzar NULL==0 derivando el session_code del propio puente_flat taparía ese drift en vez de entenderlo — por eso no lo hago sin decidirlo contigo. El fix write-inline (ya desplegado) previene NULLs NUEVOS; estos 23 son huérfanos históricos que no afectan materialmente el retrieval (son nodos Neo4j-only).