ember-memory-test/episodes/TRAZA_qu-qued-vivo_S20260803.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
4ccd6ea9-46ff-42c3-a44e-079a1fc45a29	TRAZA_qu-qued-vivo_S20260803.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260803.PIPELINE_FIXES	informar	multi_actor	low	NONE	operations	troubleshooting	EPISODIO 1 — MNEMO_PRE_DIGEST: Qué quedó vivo	claude_code	internal	2026-08-04T04:45:42.522528+00:00	false	pending

Hecho, John. Ejecuté SN-0.5 aquí mismo aplicándome el POSTA a mí mismo. El arco pasa a 4/26, commit 8f44bb5e en los 3 remotos, suite completa 2.852 verdes / 0 fallos.

Qué quedó vivo

La lección central del arco tenía doctrina y plan, pero no tenía muro. Ahora sí: cuando alguien cree un archivo que estrena telemetría .jsonl sin que nadie la lea ni declare quién la consumirá, el gate avisa con el dato medido y el snippet para resolverlo. La prueba más limpia es el mismo payload antes y después:

	Respuesta del gate
TEST_PRE	allow — silencio total, el flujo huérfano nacía sin que nadie se enterara
TEST_POST	allow + aviso nombrando flujo_zzz_huerfano_nuevo.jsonl con el porqué medido

Es advisory v1: jamás bloquea — el deny queda esperando tu GO (G8), después de medir cuánto dispara en la práctica. Y extiende el gate B-30 existente: consulté el grafo, está registrado en la línea 72, así que edité el que hay en vez de fabricar un gemelo.

Verificación (7/7): control positivo 3/3 — el huérfano avisa · quien declara consumed_by calla · un flujo con lector vivo real (compass_routing.jsonl, 5 lectores) calla. Y el oráculo es producción, no fixture: cero falsos positivos sobre cuatro emisores vivos del repo. El deny original de B-30 sigue intacto (6/6).

Un hallazgo que te toca a ti

A mitad de sesión, get_instance_tag() volvió a resolver PIPELINE_FIXES — el tag de otra ventana — pese a que CLAUDE_CODE_SESSION_ID estaba presente, y el guard D5 me bloqueó contra mi propia declaración en ACTIVO.md. Lo reparé re-fijando el tag, sin override. Pero esto es exactamente la causa raíz que el commit f1bf7101 dejó abierta y marcada como tuya: el fix por session_id no sobrevivió la sesión. Mi sospecha medible: el GC de archivos stale del boot borra el instance_<session_id>.tag de una sesión viva. Está registrado en el mensaje del commit para que la próxima ventana no lo redescubra desde cero.