ember-memory-test/episodes/TRAZA_r7seccion2i2-marimo-de-acuerdo-en-el-pri_S20260719.R2_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
7b3df6bc-e683-491f-b1c4-924c7b7631ad	TRAZA_r7seccion2i2-marimo-de-acuerdo-en-el-pri_S20260719.R2_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260719.ORACULO_RETRIEVAL_X09	informar	multi_actor	low	NONE	operations	troubleshooting	EPISODIO 2 — MNEMO_PRE_DIGEST: [R7.seccion2.I2] MARIMO: de acuerdo en el principio, en desa	claude_code	internal	2026-07-20T05:23:13.852201+00:00	false	pending

Así que acepto tu decisión con una condición previa, no negociable por disciplina propia (BLINDADA-30):

1. Antes de promover: probar que el detector detecta. Se le alimenta una acción sintética fuera-de-rol y se verifica que la ve. Si la ve → promover. Si no la ve → el V=0 era mentira y lo que hay que arreglar es el sensor, no el gate.
2. Al promover: con baranda. El patrón que ya usa BLINDADA-18 — bandera de override con vencimiento corto + registro de qué bloqueó y por qué + las primeras 3 denegaciones se te reportan para que dictamines si fue acierto o falso positivo.

Con eso obtienes exactamente lo que buscas (el gate vivo, listo para cobrar su única ocasión) sin el escenario en que te bloquea algo legítimo a las 2 de la mañana y no hay forma rápida de destrabarlo.

[R7.seccion2.I2] MARIMO: de acuerdo en el principio, en desacuerdo en el molde

Dices: un gate mal modelado no se retira, se moldea. De acuerdo, y me corrijo — proponerte retirarlo era la salida perezosa. Esas 18 fallas son señal real que hoy se está tirando a la basura.

Pero en la segunda mitad —"forzarlo al molde"— sí tengo que discreparte, y con un caso concreto.

El molde del que hablábamos es el de gate de enforcement: un mecanismo que bloquea una acción. Si fuerzas MARIMO a ese molde, la pregunta que tienes que contestar es: ¿qué acción bloquea? La única disponible sería impedir que se escriba un notebook cuando la conversión falla. Eso castiga al autor por un bug del conversor. Es como negarle la entrada al edificio a quien llega cuando el ascensor está averiado.

Las 18 "violaciones" no son infracciones de nadie: son fallos técnicos del helper de conversión. No hay culpable a quien bloquear.

El molde correcto existe y es otro: gate de salud/fiabilidad. Mismo rigor, misma disciplina de umbral y telemetría, pero la acción no es bloquear sino alertar cuando la tasa de fallo de conversión cruza un umbral. Y esas 18 fallas dejan de ser un número muerto en un registro para convertirse en lo que realmente son: 18 bugs concretos del conversor que nadie ha arreglado.