ember-memory-test/episodes/DEPURA_para-john-r11_S20260703.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
2105d8a1-ee6f-4ca6-8707-c065d7e2abcb	DEPURA_para-john-r11_S20260703.R99_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260703.ANTI_OLVIDO_ESTADO_VIVO	informar	multi_actor	low	NONE	operations	troubleshooting	EPISODIO 126 — MNEMO: 📍 PARA JOHN — R11	claude_code	internal	2026-07-12T16:16:36.937714+00:00	false	pending

• Consecuencias por camino, en tu situación real:

  • Podar ahora: riesgo casi nulo (nadie los invoca), rollback trivial (git revert), y —lo que importa— demuestra que el mecanismo de resta puede ejecutarse. Es un ensayo de bajo riesgo de la disciplina que el ecosistema necesita para no ahogarte en mantenimiento.
  • No podar: el corpus normativo sigue creciendo monótonamente; cada sprint futuro suma superficie que un solo humano + instancias ya no audita (el drift ya te alcanzó en el GAUGE y la rúbrica, que miden mal).

• Mi inclinación: hacerlo (🟢 A). Lo que la cambiaría: si prefieres que la primera poda sea algo de mayor símbolo (p. ej. un bloque de ceremonia por-turno sin ROI medido) en vez de 2 hooks muertos — pero eso necesita medición previa (el juez, opción B), así que los hooks muertos son el arranque correcto.

• La pregunta esencial, aislada (lo único que solo tú pones): ¿autorizas que Ember retire artefactos —aunque sean 2 hooks muertos— estrenando el mecanismo de resta? Es un cambio de gobernanza, no lo hago sin tu GO.

Sigo en hold por tu elección: 🟢 A (propongo/ejecuto la poda con tu GO) · 🟡 B (scaffold del juez BVB, reversible, sin servidor) · 🔵 C (commit+push de hoy, datos protegidos) · ⚪ D (parar, ya tienes el diagnóstico).