ember-memory-test/episodes/TRAZA_el-mapa-de-qu-para-qu-escala-qu_S20260727.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
62f24904-30b6-4786-b46d-6ea7b93d6a2b	TRAZA_el-mapa-de-qu-para-qu-escala-qu_S20260727.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260727.ARCO_CICLO10_ESPEJOS	informar	multi_actor	low	NONE	operations	design	EPISODIO 1 — MNEMO: El mapa de qué **para**, qué **escala**, qué...	claude_code	internal	2026-07-27T16:36:21.401687+00:00	false	pending

El mapa de qué para, qué escala, qué avisa y qué no mide nada — y sobre esa base, el patrón mínimo sensor → parada → escalada a Ember construido solo con mecanismos que ya bloquean de verdad en este harness, no con doctrina nueva. Con una pregunta que el diseño tiene que responder sí o sí: cuando el sistema para, ¿dónde queda la obligación para que yo la vea en el turno siguiente y no se evapore? Sin esa respuesta, una parada es solo un error más ruidoso.

• Hice: lancé el inventario medido de los sensores de memoria (cuatro sondas + síntesis + crítico adversarial). Te reporto en cuanto vuelva.
• Falta: el plan priorizado sale de ese inventario, no de mi memoria — y ahí está el punto: no quiero proponerte guardrails sobre una foto imaginada del sistema.
• Mi consejo: mientras corre, la acción de un minuto con más retorno es DJ-1a: colgar en settings.json el hook que lleva desde el ciclo 2 fabricado y desconectado. Es tu directiva en su forma más pequeña y concreta.

📌 PILA (R7): 🔄 inventario sensores memoria (corriendo) · ⛔ DJ-1a colgar hook huérfano (D3, un minuto) · ⛔ GO lote C11 · ⛔ DJ-C11-a/b/c · 🟢 DC-6 (2026-08-03) · ⚪ DJ-2a · ⚪ DJ-3 · 🔵 estructural: sensores con parada y escalada

Verificado todo lo que necesitaba. Ahora sí, el prólogo completo:

📖 La historia de DJ-1a — colgar el muro anti-duplicación

El reframe: qué se decide realmente

No es "¿registramos un hook más?". Es: ¿el ecosistema puede impedirme rehacer algo que ya existe, o solo puede recordármelo? Es tu directiva de hoy en su forma más pequeña y verificable — el primer sensor que pasa de avisar a parar. ### De dónde viene (la historia)

Nació de un fracaso mío, documentado: el 20 de julio reconstruí un guardián de URLs encima de uno que ya existía. La regla que debía evitarlo —AR-AP7, «consulta el grafo antes de fabricar»— existía… como recordatorio. Y un recordatorio depende de que yo me acuerde. Ese mismo día fabricamos el muro que convierte esa regla en gate, con tus manos y las mías (Author: Ember-CC-Local + John). Y ahí lleva siete días esperando: existe, tiene 13 tests verdes (los acabo de correr), y grep en settings.json da cero — porque registrarlo es archivo D3, tu mano. Esto es literalmente el patrón que hoy nombraste: un guardrail fabricado que no está enchufado. Y algo más incómodo: es el muro que previene exactamente la clase de error que cometí cuatro veces en este arco — dar por inexistente algo que ya estaba. ### Consecuencias por camino

Si lo cuelgas: cuando yo intente escribir un hook nuevo, el sistema infiere su disparador, busca en settings.json los que ya cubren ese mismo evento y, si hay solape, me deniega hasta que lea los candidatos o justifique por escrito por qué hace falta otro.