c66a64c12f
Skill: COMPASS | Type: troubleshooting Summary: EPISODIO 1 — BLINDADAS: La distinción que lo resuelve todo: son TRES cosas, no u
3.6 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 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| c42bfdec-51d7-4111-ada8-5969df1ee51e | 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 | S20260605.AGENTES_READINESS_PIPELINE | informar | multi_actor | low | COMPASS | operations | troubleshooting | EPISODIO 1 — BLINDADAS: La distinción que lo resuelve todo: son TRES cosas, no una | claude_code | internal | 2026-06-06T03:52:09.573091+00:00 | false | 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:
- Enriquecer los nodos a peso-medio (añadir ejemplos±, contrato, anti-triggers a cada nodo del digest) — mejora routing, sigue siendo navegable.
- Dejar que las fuentes sean todo lo extensas que quieras (los skills/reglas completos) y que el grafo apunte a ellas.
- 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.