ember-memory-test/episodes/TRAZA_r38seccion1i1-la-causa-raz-era-ma-y-expl_S20260902.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
a49987c5-34de-45d1-8fcb-ae384f498722	TRAZA_r38seccion1i1-la-causa-raz-era-ma-y-expl_S20260902.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260902.SID80EF6E909F98	informar	multi_actor	low	NONE	operations	troubleshooting	EPISODIO 1 — ember-mcp: [R38.seccion1.I1] La causa raíz era mía, y explica los dos i	claude_code	internal	2026-09-06T16:52:59.443405+00:00	false	pending

Todo limpio: canario retirado, ember-mcp sano con 939e0, y el oráculo final da HTTP 200 · DIMS=3072.

[R38.seccion1.I1] La causa raíz era mía, y explica los dos incidentes

Mi código de escritura hacía esto:

Python evalúa open(p,'w') primero, y abrir en modo escritura vacía el fichero. Así que el .read() que viene después leía un fichero ya vacío, la sustitución se aplicaba sobre la nada, y se escribía la nada. El fichero de configuración quedaba en cero bytes — no solo perdía la clave nueva: borraba todas las variables.

Reproducido en local, no deducido:

Con eso, cada síntoma de los dos incidentes queda explicado sin residuo: ember-mcp caía a la clave grabada en su imagen porque no tenía fichero; litellm no arrancaba porque se quedaba sin ninguna variable; el 000 era «nadie escucha», no «clave rechazada»; y la restauración funcionaba porque los respaldos estaban íntegros.

Y cierra la corrección que te debía: el 3 de septiembre te dije que habías pegado una clave muerta. Era falso. Fue este bug, las dos veces. Tú pegaste sk-or-v1-7946b6b — que es exactamente fusionkey, la correcta.

[R38.seccion2.I2] El arreglo, y por qué son tres cambios

Leer primero, escribir después — sin efectos colaterales en el orden de evaluación. Verificar que la sustitución ocurrió — re.sub no falla cuando no encuentra el patrón, simplemente no sustituye, y ese silencio habría dejado el fichero sin la clave mientras el script anunciaba «actualizado». Escritura atómica — el fichero nunca existe a medias, ni aunque el proceso muera en mitad.

Verificado con oráculo externo: 117 bytes, todas las variables conservadas, clave nueva dentro, vieja fuera. El test del guardián sigue 6/6.

[R38.seccion3.T1] Dos hallazgos colaterales que debes conocer

Hallazgo	Estado
La imagen ember-mcp-with-neo4j-asyncpg:latest lleva grabada sk-or-v1-6ea2	Clave muerta, pero es un respaldo silencioso que enmascaró el fallo dos veces
El fichero de composición de ember-mcp tiene un token de Forgejo en texto plano	Credencial viva; mi filtro de secretos no lo cubrió y se imprimió en tu terminal