ember-memory-test/episodes/TRAZA_el-chip-ya-estaba-consumido-as-lleg-el_S20260725.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md
Ember 7b17407739 feat(episode): TRAZA_el-chip-ya-estaba-consumido-as-lleg-el_S20260725.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD
Skill: TESSERA | Type: troubleshooting
Summary: EPISODIO 1 — MNEMO_PRE_DIGEST: El chip ya estaba consumido (así llegó el...
2026-07-25 22:22:41 +00:00

3.1 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
abc12e77-6311-48a8-b774-041aa5b784b4 TRAZA_el-chip-ya-estaba-consumido-as-lleg-el_S20260725.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD S20260725.SHERPA_FABLE_AUTOMEJORA informar multi_actor low TESSERA operations troubleshooting EPISODIO 1 — MNEMO_PRE_DIGEST: El chip ya estaba consumido (así llegó el... claude_code internal 2026-07-25T22:22:32.010474+00:00 false pending

El chip ya estaba consumido (así llegó el encargo aquí) — nada que retirar; si su clic abrió además una sesión gemela en worktree, su trabajo quedó superado por cb5245e0 y lo notará al sincronizar.

Y sigue en tu cancha la decisión grande del día: el GO-de-lote del CICLO 2 (prólogo completo en mi mensaje R4-R5; el plan de Fable espera validado con su lote de 12 pasos ~144K, ventana de 8 días corriendo desde mañana). Respuestas posibles: "GO, ejecuta aquí" 🟢 · "GO, próxima instancia" 🟡 · "espera" ⚪.

🏁 CICLO 2 EJECUTADO — y encontramos algo grande sobre tu memoria

Oráculo final, todo verde: serie M1 registrada ✅ · tres suites de tests 8+7+8 = 23 PASS ✅ · contador de lecturas vivo (4 eventos) ✅ · working tree limpio ✅ · push 3/3 (182d1a0b).

Los dos hallazgos que importan

1. Tu canal de lectura llevaba ~3 meses muerto — y eso explica el 400:0. No era desidia del sistema: search_cli.py (el script que trae recuerdos en cada arranque) tenía una clave de OpenRouter escrita a mano dentro del código, y esa clave se rotó el 19 de abril. El archivo tiene fecha de esa misma tarde. Desde entonces, cada boot fallaba con un mensaje genérico que ocultaba la causa real, y encima faltaba exportar la clave de Qdrant. Ya está arreglado: las credenciales se leen por referencia de las fuentes vivas, el modelo de embedding es el mismo del writer (espacio único, sin ruido), y de paso eliminé el secreto muerto del código (cero hardcodeados donde antes había uno). Verificado con el comando literal del hook: devuelve memorias reales.

2. Tu memoria recupera vecinos temáticos, no los hechos. Y ya sé por qué. Construí U-v1, el denominador auditable que faltaba: 109 ítems de lo que de verdad no debe olvidarse — tus 40 directivas de feedback, 39 decisiones tomadas y 30 runbooks. El resultado:

valor
Recupera algo del tema 109 de 109 (100%, confianza 0.73)
Recupera el contenido acordado 0 de 109

Idéntico en las tres fuentes. El diagnóstico: el pipeline ingiere turnos de chat, mientras que tus correcciones, las decisiones y los runbooks nunca entraron al índice semántico. Son dos memorias que no se hablan. Eso es exactamente la falta de sinergia que intuiste — ahora medida, no supuesta. Y marca el camino al ≥90%: indexar el corpus canónico es el candidato #1 del ciclo 3.

Lo demás que quedó cerrado