feat(episode): TRAZA_la-distincin-que-lo-resuelve-todo-son-tr_S20260605.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: COMPASS | Type: troubleshooting
Summary: EPISODIO 1 — BLINDADAS: La distinción que lo resuelve todo: son TRES cosas, no u

episodes/TRAZA_la-distincin-que-lo-resuelve-todo-son-tr_S20260605.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,52 @@
+---
+episode_id: "c42bfdec-51d7-4111-ada8-5969df1ee51e"
+puente_flat: "TRAZA_la-distincin-que-lo-resuelve-todo-son-tr_S20260605.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
+session_code: "S20260605.AGENTES_READINESS_PIPELINE"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "low"
+skill_dominante: "COMPASS"
+fase_proyecto: "operations"
+tipo_semantico: "troubleshooting"
+summary_one_line: "EPISODIO 1 — BLINDADAS: La distinción que lo resuelve todo: son TRES cosas, no una"
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-06-06T03:52:09.573091+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+Buena pregunta, John — y toca el corazón del diseño. Te respondo con reflexión genuina, porque la respuesta corta ("sí, hazlo más extenso") sería un error.
+
+## La distinción que lo resuelve todo: son TRES cosas, no una
+
+Lo que escribí (el digest/grafo-índice) y "la información extensa" no son lo mismo. Hay **tres capas**, con metas opuestas:
+
+| Capa | Qué es | ¿Extensa? |
+|---|---|---|
+| 1. **El índice/grafo** (el digest que escribí) | el mapa navegable: por nodo → nombre + 1 línea + triggers + relaciones | ❌ **NO** — debe ser LIGERO |
+| 2. **La ficha de cada nodo** (manifest) | lo justo para *decidir/rutear*: triggers, anti-triggers, contrato, 1-2 ejemplos | 🟡 peso medio |
+| 3. **El documento fuente** (lo que el nodo apunta) | el contenido completo del skill/regla/metodología | ✅ **SÍ — tan extenso como quieras** |
+
+## Por qué hacer el ÍNDICE extenso sería contraproducente
+
+El grafo-índice nació para **aligerar** CLAUDE.md (~175K tokens). Si lo escribo "absolutamente extenso", **lo vuelvo tan pesado como lo que quería aligerar** — me dispararía en el pie. Un índice vale precisamente porque es pequeño: es la tabla de contenidos, no los libros.
+
+Y hay evidencia dura (tus propios docs lo respaldan): la constitución-mini cita a *Gloaguen et al. 2602.11988* — **"más contexto = peor"**; y "Lost in the Middle" (Liu 2023) muestra que cargar más texto **degrada** la decisión. Meter todo en lo residente no ayuda al router; lo confunde.
+
+## Pero tu instinto SÍ es correcto — solo en la capa correcta
+
+Donde quieres "máxima información posible" es en la **capa 3 (los documentos fuente)**. Esos sí deben ser completos, exhaustivos, ricos. El grafo es el mapa **a** ese territorio extenso, y el *retrieval perezoso* trae el documento completo solo cuando se necesita. Así el sistema **tiene** toda la información disponible, sin **cargarla** toda de golpe.
+
+> En una frase: **índice ligero + fuentes extensas + retrieval bajo demanda.** Máxima información disponible, mínimo peso al arrancar.
+
+## La mejora real que SÍ recomiendo (el punto medio)
+
+Hay un hallazgo que sí pide enriquecer — pero la capa 2, no la 1: medimos que **"nombre + descripción" es señal débil** (−29 a −44 puntos para rutear). Así que cada nodo debe pasar de "name+desc" a una **ficha de peso medio**: triggers + anti-triggers + contrato I/O + 1-2 ejemplos positivos y negativos. Eso **mejora el routing** sin inflar el índice a prosa. Es el sweet spot.
+
+**Concretamente puedo:**
+1. **Enriquecer los nodos a peso-medio** (añadir ejemplos±, contrato, anti-triggers a cada nodo del digest) — mejora routing, sigue siendo navegable.
+2. **Dejar que las fuentes sean todo lo extensas que quieras** (los skills/reglas completos) y que el grafo apunte a ellas.
+3. **NO** inflar el índice mismo.
+
+¿Quieres que te muestre con un nodo de ejemplo cómo se ve "peso-medio" vs "extenso", para que decidas el nivel exacto? Así calibras tú el punto sin que yo asuma.