feat(episode): TRAZA_f1-confirmado-consolidado-aggregate-576_S20260607.R22_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: TESSERA | Type: troubleshooting
Summary: EPISODIO 22 — LEXICON_COSECHA: F1 confirmado consolidado. Aggregate **5.7/6** es

episodes/TRAZA_f1-confirmado-consolidado-aggregate-576_S20260607.R22_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,36 @@
+---
+episode_id: "32ffd072-e7ea-49e9-ab84-fc04a8fad250"
+puente_flat: "TRAZA_f1-confirmado-consolidado-aggregate-576_S20260607.R22_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
+session_code: "S20260607.MNEMO_BUG_FORENSE_MAP"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "low"
+skill_dominante: "TESSERA"
+fase_proyecto: "operations"
+tipo_semantico: "troubleshooting"
+summary_one_line: "EPISODIO 22 — LEXICON_COSECHA: F1 confirmado consolidado. Aggregate **5.7/6** estable. Sin "
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-06-08T17:49:28.540885+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "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?