ember-memory-test/episodes/TRAZA_f1-confirmado-consolidado-aggregate-576_S20260607.R12_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
d17c648f-b5da-41a4-a1f6-8b3eff3fe664	TRAZA_f1-confirmado-consolidado-aggregate-576_S20260607.R12_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260607.MNEMO_BUG_FORENSE_MAP	informar	multi_actor	low	TESSERA	operations	troubleshooting	EPISODIO 12 — LEXICON_COSECHA: F1 confirmado consolidado. Aggregate **5.7/6** estable. Sin	claude_code	internal	2026-06-11T08:00:09.380294+00:00	false	pending

F1 confirmado consolidado. Aggregate 5.7/6 estable. Sin decisión nueva surface — solo cierre técnico de R1.

Hallazgo crítico, John: la key activa de L38 es del modelo de embeddings text-embedding-3-large → openrouter/google/gemini-embedding-2-preview. Es el embedder del pipeline MNEMO. Al revocar la key vieja, los embeddings vía LiteLLM quedan rotos → store_memory y retrieval fallarán en la próxima llamada (401). Esto bloquea la columna vertebral de la memoria. Hay que cablear la key nueva ya.

Te enmarco la decisión de cómo entregar la key nueva (PRÓLOGO):

Reframe: no es solo "pega la key" — es "hay 3 keys hardcodeadas en config.yaml (L23/L38/L52); ¿las reemplazo por la nueva hardcodeada otra vez, o aprovecho para sacarlas a variable de entorno y que NUNCA vuelva a haber una key en texto plano en el config?".

Origen: la key vieja estaba hardcodeada directo en config.yaml — por eso terminó leaked en su día. Repetir hardcode = repetir el patrón que causó esto.

Consecuencias por camino:

• (1) Fix limpio con env var (recomendado): tú escribes la key nueva en el .env del stack litellm server-side (OPENROUTER_API_KEY=sk-or-…, una línea, la creas tú — el hook me bloquea tocar .env). Yo cambio L23/L38/L52 a api_key: os.environ/OPENROUTER_API_KEY, limpio las 3 hardcodeadas, restart litellm, verifico embeddings. La key nunca toca chat ni git, nunca más hardcodeada.
• (2) Hardcode rápido: me pasas la key por chat, yo la escribo en L38 server-side (no git), restart. Funciona ya pero repite el patrón leaked + la key pasa por chat.
• (3) Lo haces tú entero: editas config.yaml + restart, yo solo verifico.

Mi inclinación (y qué la cambia): (1) — es el fix de raíz: saca el hardcode que causó el leak original. Tu único paso manual es una línea en el .env del servidor. Cambiaría a (2) solo si tienes prisa y el .env te resulta engorroso ahora.

La pregunta esencial (solo tú): ¿colocas la key nueva en el .env del stack litellm server-side (yo refactorizo config a env var), o prefieres pasármela por chat para hardcodear rápido en L38?