feat(episode): EXPLORA_el-insight-clave-que-t-ya-viste-no-metas_S20260605.R33_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: NONE | Type: design
Summary: EPISODIO 33 — BLINDADAS: El insight clave que tú ya viste: NO metas datos voláti

episodes/EXPLORA_el-insight-clave-que-t-ya-viste-no-metas_S20260605.R33_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,51 @@
+---
+episode_id: "dfccff65-83b4-48e9-a82c-112c72e263ef"
+puente_flat: "EXPLORA_el-insight-clave-que-t-ya-viste-no-metas_S20260605.R33_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: "NONE"
+fase_proyecto: "operations"
+tipo_semantico: "design"
+summary_one_line: "EPISODIO 33 — BLINDADAS: El insight clave que tú ya viste: NO metas datos volátiles e"
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-06-06T14:42:29.159821+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+Sí, clarísimo — y lo mejor: **el ecosistema ya tiene el patrón exacto para esto, se llama ARIADNA** (`rules/ariadna.md`). De hecho ya tienes un ejemplo vivo funcionando: `docs/TRIGGERS_HOOKS_MAP.md` se auto-regenera solo cada vez que tocas un hook. Tu pregunta es aplicar lo mismo al grafo-índice. Te explico el cómo en plastilina, porque tu intuición da justo en el clavo difícil.
+
+## El insight clave que tú ya viste: NO metas datos volátiles en el grafo
+
+El error que mataría el grafo es meterle adentro los datos que cambian rápido. Si el grafo dice "84 hooks" hoy, mañana hay 85 y el grafo miente. La solución no es "actualizar el grafo entero cada rato" — es **separar dos tipos de dato**:
+
+| Tipo | Ejemplos | Cambia | Dónde vive |
+|---|---|---|---|
+| 🗿 **Estructura estable** | qué es cada skill, sus triggers, las relaciones, el principio de cada regla | lento (semanas/meses) | **en el grafo** (los nodos) |
+| 🌊 **Dato volátil** | conteos (84 hooks, 68 skills), status (active/dogfooding), fechas de gate, scores, drift, estado del servidor | rápido (días) | **en una capa "live" aparte** |
+
+El grafo guarda lo estable; lo volátil vive en un **overlay** chiquito que se refresca solo. Cuando la memoria del grafo llama un nodo, **se fusionan los dos al vuelo** → la info sale fresca. Así el grafo grande sigue válido meses, y solo el overlay barato se actualiza cada 15 días. Exactamente lo que pediste.
+
+## El mecanismo (los 5 artefactos ARIADNA)
+
+## Por qué incremental + overlay es la jugada (no regenerar todo con IA cada 15 días)
+
+Regenerar los 241 nodos con 5 agentes cada 15 días sería caro y lento. En cambio:
+- **Estructura:** solo re-destilo el nodo que cambió (1 regla editada → 1 nodo, no 241). Lo demás se cachea.
+- **Volátil:** el overlay es determinista (contar, leer status) — corre en segundos, sin IA.
+
+Resultado: el grafo está **siempre fresco** con costo casi cero, y "cuando la memoria del grafo llame información, esté actualizada" — que es tu objetivo literal.
+
+## Lo honesto (PR-6)
+
+- La prosa rica que escribieron los agentes (qué_hace, ejemplos) **sí** necesita IA para re-destilarse — por eso el incremental: solo los nodos cambiados pasan por IA, el resto es cache. Los campos estructurales (triggers, status, relaciones) sí salen deterministas del frontmatter.
+- El cron de "cada 15 días" en este entorno se monta como scheduled task; el on-event es un hook (ya domino ese patrón con TRIGGERS_HOOKS_MAP).
+
+—
+
+**En una frase:** ARIADNA-izar el digest = generador incremental (estructura) + overlay determinista (volátil) + doble disparo (on-event + cron 15 días), todo bajo path estable. El grafo nunca se pudre.
+
+¿Quiero que **lo construya** (los 5 artefactos: generador + overlay + hook on-event + scheduled task 15 días + path estable + referencia MEMORY.md)? Es la versión auto-actualizable del documento que ya escribí. Dame luz verde y lo armo en autopilot.