john/ember-memory-test
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

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

Browse source 
Skill: TESSERA | Type: troubleshooting
Summary: EPISODIO 38 — LEXICON_COSECHA: F1 confirmado consolidado. Aggregate **5.7/6** es
This commit is contained in:
Ember 2026-06-09 14:00:42 +00:00
parent 9b237dcda1
commit 2ccc75e9cb
1 changed files with 36 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

36
episodes/TRAZA_f1-confirmado-consolidado-aggregate-576_S20260607.R38_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md Normal file
View file

@ -0,0 +1,36 @@
---
episode_id: "f7baeb78-0cc5-4257-ac58-896c2b94e5f6"
puente_flat: "TRAZA_f1-confirmado-consolidado-aggregate-576_S20260607.R38_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 38 — LEXICON_COSECHA: F1 confirmado consolidado. Aggregate **5.7/6** estable. Sin "
source_type: "claude_code"
trust_boundary: "internal"
created_at: "2026-06-09T14:00:07.680309+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?