ember-memory-test/episodes/TRAZA_la-decisin-qu-lleva-dentro-el-writer-v1_S20260719.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
d26d059f-054b-4761-b736-69224ea8bc4f	TRAZA_la-decisin-qu-lleva-dentro-el-writer-v1_S20260719.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260719.ORACULO_RETRIEVAL_X09	informar	multi_actor	low	NONE	operations	design	EPISODIO 1 — MNEMO_PRE_DIGEST: 📖 La decisión: qué lleva dentro el writer v1.2	claude_code	internal	2026-07-20T04:19:52.089373+00:00	false	pending

Tienes razón el hook — enumeré cuatro decisiones sin contarte la historia de ninguna. Te doy el prólogo completo de la que importa ahora (una a la vez, PRO-4); las otras tres esperan su turno sin prisa.

📖 La decisión: qué lleva dentro el writer v1.2

1. Qué se decide realmente. No es "¿adoptamos tu idea?" — eso ya está resuelto: FACT-PUENTE es buena y está anclada en lo que medimos. Lo que se decide es cuánto carga un solo acto de escritura sobre la ingesta viva: si el writer v1.2 hace una cosa o dos.

2. De dónde viene. El writer ya cambió hoy (v1.0→v1.1, summary al nacer) y está en observación de 48h justamente porque el tribunal prohibió apilar cambios sin madurar el anterior. Ahora hay dos mejoras candidatas para la v1.2 — emisión de hechos (F-B del plan) y tu nomenclatura — y ambas tocan el mismo punto del código, el mismo deploy, el mismo gate.

3. Consecuencias por camino.

• Todo junto: un deploy, un riesgo, un ciclo. Pero si algo falla, el diagnóstico es ambiguo (¿falló la emisión o la nomenclatura?) — y la nomenclatura aún no tiene un solo número que la respalde (G-NOM son diseño, no resultado).
• Uno y luego otro: diagnóstico limpio, cada mejora con su medición. Pero dos intervenciones sobre ingesta viva y dos ventanas de espera.
• Un tercer camino que se me hizo visible al pensarlo bien: el v1.2 captura la nomenclatura desde el primer día — pero no la usa para filtrar hasta que G-NOM pase. Separar escribir el dato de confiar en el dato.

4. Mi inclinación, y por qué. El tercer camino, y el argumento me convenció a mí mismo: capturar es irreversible si no se hace — cada episodio que nace sin nomenclatura es un episodio que habrá que backfillear después con menos contexto del que tuvo al nacer; confiar es reversible — el filtro se cablea o se apaga cuando la medición hable. Es exactamente el principio que ya nos funcionó dos veces hoy: escribir al nacer (gratis, contexto máximo), medir después (barato, reversible). Lo que me cambiaría: si el sintético previo al deploy mostrara que pedir la nomenclatura degrada la calidad de los hechos mismos o encarece de más la escritura — es medible antes de tocar nada.

5. La pregunta esencial, aislada: ¿el writer v1.2 captura la nomenclatura desde el primer día, aunque el filtro no se encienda hasta que los gates G-NOM lo autoricen?

Nada de esto corre hasta que el gate 48h cante (~S20260721) y tú firmes. El diseño ya está persistido en DISENO_NOMENCLATURA_HECHOS_FACT_PUENTE — solo faltaría añadirle este matiz de "capturar sin confiar" cuando decidas.