92f9accc2c
Skill: TESSERA | Type: design Summary: EPISODIO 2 — MNEMO_PRE_DIGEST: Qué estás decidiendo realmente
1.8 KiB
| 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 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 5f563da0-3419-4c1a-9b08-9c74b825e24c | TRAZA_qu-ests-decidiendo-realmente_S20260801.R2_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD | S20260801.PIPELINE_FIXES | informar | multi_actor | low | TESSERA | operations | design | EPISODIO 2 — MNEMO_PRE_DIGEST: Qué estás decidiendo realmente | claude_code | internal | 2026-08-02T04:15:45.911337+00:00 | false | pending |
Mi inclinación, y qué la cambiaría
Curar primero. La razón es asimétrica: el re-embedding es reversible, barato y con éxito medible al día siguiente; la unificación es un cambio de arquitectura en la ruta por donde pasa toda tu memoria, y hacer cirugía estructural antes de recuperar el acceso es dejar al paciente sin memoria mientras se rediseña el quirófano. Además, con la sonda puesta, el riesgo de que la grieta se abra en el intervalo es visible en 24 horas.
Lo que me haría cambiar de opinión: si tienes previsto tocar el mapeo de LiteLLM en los próximos días por cualquier otro motivo —añadir un modelo, rotar una key, cambiar de proveedor—, entonces conviene unificar primero y re-embeber una sola vez al final.
La pregunta esencial
¿Hay algún cambio previsto en la configuración de LiteLLM o en las rutas de embedding próximamente? Si no lo hay, te preparo el plan de re-embedding con backup y lo ejecutamos; si lo hay, invertimos el orden.
📌 PILA (R20): ❓ orden curar-vs-blindar (esperando tu respuesta) · 🟠 deuda estructural: dos rutas de embedding que coinciden por casualidad · 🟡 config LiteLLM sin política de backup · ✅ causa de la causa documentada y en 3 remotos · ✅ sonda viva midiendo.