feat(episode): TRAZA_por-qu-capacidad-de-lumen-es-prerrequisi_S20260601.R65_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: NONE | Type: design
Summary: EPISODIO 65 — BLINDADAS: Por qué capacidad-de-LUMEN es prerrequisito, no consecu

episodes/TRAZA_por-qu-capacidad-de-lumen-es-prerrequisi_S20260601.R65_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

@@ -0,0 +1,39 @@
+---
+episode_id: "fcda06b2-7fa5-4226-af83-ce87f2b2982e"
+puente_flat: "TRAZA_por-qu-capacidad-de-lumen-es-prerrequisi_S20260601.R65_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
+session_code: "S20260601.LUMEN_CAPACIDAD_LLM_LIGERO"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "low"
+skill_dominante: "NONE"
+fase_proyecto: "operations"
+tipo_semantico: "design"
+summary_one_line: "EPISODIO 65 — BLINDADAS: Por qué capacidad-de-LUMEN es prerrequisito, no consecuencia"
+source_type: "claude_code"
+trust_boundary: "internal"
+created_at: "2026-06-05T19:27:11.261408+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+Tienes toda la razón, John — y es un orden de pensar muy fino. **La prioritaria es la #4: verificar la capacidad de LUMEN.** Y sí, va ANTES del pipeline, no después. Te explico por qué tu razonamiento es correcto:
+
+## Por qué capacidad-de-LUMEN es prerrequisito, no consecuencia
+
+Asignarle una función en el pipeline a un LLM ligero **sin saber si la soporta** = construir sobre arena: o falla en producción, o lo descubres tras invertir en integrarlo. Verificar la capacidad **primero** invierte el orden correcto — decides *qué* función darle (o si dársela) con **evidencia empírica**, no con fe. Es literalmente tu propia doctrina rectora ("darle a un LLM un objetivo claro, estructurado, con todas las variaciones de salida posibles") aplicada un nivel antes: **antes de definirle el objetivo, hay que medir qué salida puede producir confiablemente.**
+
+## La conexión que lo hace doblemente prioritario
+
+El JAE que acabamos de construir tiene un hueco que LUMEN podría llenar: el **juez F4 hoy corre vía Agent (Claude) — caro**. Si LUMEN soporta clasificación/extracción estructurada confiable, **esa es exactamente la función candidata** para él, tanto en el pipeline de efectividad (defect-signals, pre-clasificación) como en el de memoria (HyDE, pre-digest). Verificar su capacidad ahora mata dos pájaros: desbloquea la decisión del pipeline **y** te dice si puedes abaratar el juez.
+
+## Cómo se verifica (probe empírico, bajo riesgo)
+
+Un probe de 4 mediciones sobre `lumen-v4` (vivo en LiteLLM según el boot):
+1. **Vivo + modelo** (`lumen_status`) — qué es realmente, contexto, params.
+2. **Latencia** — ¿sirve para algo en línea o solo batch?
+3. **Fiabilidad de structured output** — ¿devuelve JSON válido consistente? (el talón de Aquiles de los modelos ligeros, y lo que tu doctrina exige).
+4. **Calidad en tarea representativa** — una clasificación/extracción real (p.ej. etiquetar un defect-signal) vs. ground-truth.
+
+De ahí sale el veredicto: **qué función puede poseer, cuál no, y con qué guardarraíles**. Sin esto, cualquier diseño de pipeline con LUMEN es especulación.
+
+**¿Corro el probe ya?** Lo arranco con NARRATE completo (empezando por `lumen_status` + una prueba de structured-output), y te entrego un veredicto de capacidad con evidencia. Si prefieres, primero acoto contigo qué *función candidata* específica medir (juez de efectividad, HyDE, pre-digest, routing) para que el probe #4 sea exactamente la tarea que te interesa.