ember-memory-test/episodes/DEPURA_nota-de-cierre-automtico-al-terminar-el_S20260726.R2_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
58e6e660-eeb7-4ba6-a0a8-1dc781d5d263	DEPURA_nota-de-cierre-automtico-al-terminar-el_S20260726.R2_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260726.ARCO_CICLO4_AUTOMEJORA	informar	multi_actor	low	TESSERA	operations	troubleshooting	EPISODIO 2 — MCP: Nota de cierre automático: al terminar el turno,...	claude_code	internal	2026-07-27T00:13:09.911596+00:00	false	pending

Nota de cierre automático: al terminar el turno, el hook regeneró REPORTE_EFECTIVIDAD_HOOKS.md (11 veredictos sobre 10 hooks). Es un evento del sistema, no requiere acción mía.

No hay nada más que yo pueda avanzar sin tu criterio. El ciclo 6 quedó entregado y anclado; lo que sigue son tres decisiones tuyas:

1. 🔴 DC-6 — vence mañana; el dossier está completo (fixture verificada contra el canon vivo + contador honesto).
2. ❓ Política de remediación A/B para los 406 tests que no pueden fallar — mi recomendación sigue siendo A (hacer check() asertivo y aceptar el rojo masivo, porque ese rojo es la verdad que llevaba meses oculta).
3. ❓ C5-09 — requiere tu GO porque reinicia el MCP y te cuesta las 3 tmux.

Quedo esperando.

Todo registrado: commit 2c30c210, push 3/3.

—

Lo que pasó, y por qué me detuve

Ejecuté tu GO en orden. P0 dio PROCEDER (152 de 258, 58%). P1 congeló la lista con su huella. Y P2 —el canario— falló, que es exactamente para lo que existe.

Lancé el worker canónico 60 segundos sobre los 8 huérfanos, sin crear un solo evento. Los 8 respondieron lo mismo: HTTP 400. Si hubiera encolado primero los 152, tendría 152 fallos y una cola envenenada. El canario costó ocho intentos sobre episodios que ya estaban rotos.

Y al tirar de ese hilo apareció algo bastante más grande que el hueco.

🔴 El hallazgo real

El 12 de junio rotaste la master key de LiteLLM. El worker de Qdrant la tiene hardcodeada como valor por defecto, y el entorno no define la variable que la sustituiría. Desde ese día el worker pide embeddings con una credencial muerta y recibe 400. El 19 de junio alguien lo sacó del despachador —presumiblemente porque ensuciaba— y ahí sigue, cinco semanas después.

El sistema perdió su redundancia el 19 de junio. Mientras el otro camino funcionó, no se notó. Cuando ese también falló, del 2 al 11 de julio, no había red: 152 episodios cayeron al vacío.

Y el barrido de la clase es lo que me preocupa de verdad: ocho componentes vivos tienen claves muertas hardcodeadas. Entre ellos puente_health_check.py —un chequeo de salud— y fides_report.py —el que calcula la confianza de tu memoria—. Son instrumentos que podrían llevar semanas dando veredictos sin poder hablar con lo que dicen medir.

★ Insight ───────────────────────────────────── Volviendo a tu metáfora: esto no fue un fallo del cerebro reptil. Fue más sutil y más peligroso — el reptil siguió respirando con un pulmón mientras el otro estaba colapsado, y ningún sensor lo reportó porque el sensor también estaba desconectado. Es la razón exacta por la que insistes en que la prudencia sea mecánica: un sistema que se auto-percibe mal es más peligroso que uno que no se auto-percibe, porque produce confianza injustificada. ─────────────────────────────────────────────────

La decisión que te traigo