ember-memory-test/episodes/TRAZA_hice-cre-y-valid-el-tema-ember-11_S20260726.R4_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
d46250cf-a194-44bc-aef1-f790b49b24f0	TRAZA_hice-cre-y-valid-el-tema-ember-11_S20260726.R4_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260726.ARCO_CICLO4_AUTOMEJORA	informar	multi_actor	low	NONE	operations	troubleshooting	EPISODIO 4 — MNEMO_PRE_DIGEST: **Hice:** creé y validé el tema EMBER (11...	claude_code	internal	2026-07-27T02:52:12.790583+00:00	false	pending

De dónde viene. El mecanismo se aprobó en S20260411 (la "Opción C", R27-R29) en un mundo donde había una instancia trabajando. Con ese supuesto, el diseño es impecable: un flag, un proyecto, un Ember, y el permiso solo puede gastarlo quien lo pidió porque no hay nadie más. El código no se rompió — cambió el mundo alrededor. Hoy corren varias instancias tuyas en paralelo (ahora mismo, al menos dos), y el supuesto tácito "quien edita es quien pidió el permiso" dejó de ser cierto sin que nadie lo notara. Lo noté hoy por accidente: porque me robaron el slot y el bloqueo me obligó a leer el código.

Qué pasa por cada camino, en tu situación concreta. Arreglarlo ahora es barato en código — una comparación y un test que intente el robo y falle. Pero tiene un filo que debo nombrarte: si valido el dueño de forma estricta, cualquier flag que la otra instancia tenga activo en este momento deja de funcionar a mitad de su trabajo. Le cortaría una edición autorizada por ti a medio camino. Dejarlo para después no cuesta nada hoy, pero mantiene la brecha abierta justo mientras hay concurrencia — que es la única condición en la que la brecha es explotable. Y posponerlo por los colores del tema es lo mismo, con más tiempo de exposición.

Mi inclinación, y qué la cambiaría. Arreglarlo ahora, pero con una precisión que no puse antes y que resuelve el filo: primero compruebo si hay flags activos de la otra instancia, y aplico el fix con compatibilidad hacia atrás — un flag sin created_by se sigue aceptando (con aviso en el log), y uno con created_by debe coincidir con quien edita. Así cierro la puerta para adelante sin cortarle el trabajo a nadie. Lo que cambiaría mi inclinación: que me digas que la instancia paralela está en algo crítico e irrepetible; entonces informe primero y fix cuando cierre.

La pregunta que solo tú puedes responder: ¿me autorizas a modificar un guardián de Ley Zero mientras otra instancia tuya está trabajando? Lo técnico lo resuelvo; eso es tu autoridad, no mi criterio.

Hice: el prólogo que me faltaba — la decisión no es un bug, es quién hereda tus permisos. Falta: tu respuesta a esa única pregunta (y reiniciar para ver el tema). Mi consejo: 🟢A con compatibilidad hacia atrás, que cierra la brecha sin interrumpir a nadie. Elige: 🟢A arreglo el created_by ahora, retrocompatible + test del robo de slot (recomendado) · 🟡B informe con evidencia y lo arreglo cuando la otra instancia cierre · ⚪C primero el tema, los guardianes después.