Enrutador de Habilidades
Objetivo
Seleccionar el conjunto mínimo suficiente de habilidades para falsear las suposiciones relevantes. No maximizar la cobertura aparente.
El enrutador es una capa de despacho, no un auditor. La implementación determinista vive en scripts/router.py; las relaciones globales, triggers, costos y solapamientos viven solo en catalog/skills.yaml.
Cuándo Usarlo
- Al inicio de auditorías o revisiones no triviales.
- Cuando la tarea mezcla dominios (por ejemplo, seguridad + fiabilidad).
- Cuando es necesario justificar por qué una habilidad entró o se quedó fuera.
- Para impedir la explosión de habilidades antes de ejecutar trabajo costoso.
- Composición: despacha a habilidades; no produce hallazgos directamente.
Las tareas triviales y reversibles pueden seleccionar cero habilidades.
Modelo Mental
Trata el enrutamiento como un problema de conjunto mínimo:
suposiciones relevantes
↓
lentes mínimas que pueden falsearlas
↓
roles de verificación faltantes, si los hay
↓
detener cuando habilidades adicionales solo repiten cobertura
La decisión usa metadatos estructurados del catálogo:
coincidencia_trigger
+ coincidencia_dominio
+ desbloqueo_riesgo
+ señal_requerida
+ bonificación_composición
- penalización_solapamiento
- penalización_coste
Esto no es aprendizaje automático. La puntuación hace que la decisión sea rastreable y reproducible.
Presupuesto de habilidades
| Riesgo | Presupuesto normal |
|---|---|
trivial | 0–1 |
medium | 1–2 |
high | 2–4 |
critical | 3–6 |
Exceder el presupuesto requiere una justificación concreta de nueva cobertura o confirmación.
Orden por rol
generador → investigador → verificador → revisor → investigador
La investigación puede ir primero cuando la incertidumbre externa es el problema principal.
Procedimiento de Investigación
- ENTENDER — reformular la tarea y el contexto; incluir hechos, no solo el título.
- CLASIFICAR RIESGO —
trivial,medium,highocritical. - CLASIFICAR DOMINIO — auditoría, seguridad, fiabilidad, producto, frontend o investigación.
- LEER CATÁLOGO — usar
catalog/skills.yaml; no reproducir relaciones manualmente. - EMPAREJAR TRIGGERS — seleccionar candidatas con evidencia léxica o señal requerida.
- APLICAR UMBRAL DE RIESGO — descartar la habilidad cuyo
risk_floorno se haya alcanzado. - PUNTUAR — aplicar dominio, coste, composición y solapamiento.
- APLICAR PRESUPUESTO — conservar las candidatas de mayor puntuación y ganancia marginal.
- ORDENAR POR ROL — hipótesis antes de investigación y verificación.
- INFORMAR CERCA-ACIERTOS — como máximo tres candidatas plausibles que se quedaron fuera.
- ENRUTAR INVESTIGACIÓN — indicar si
research-routeres necesario. - VERIFICAR — ejecutar
python3 scripts/eval.py route --router v2 --checkdespués del cambio.
Preguntas que Hacer
- ¿Qué suposición necesita falsear la tarea?
- ¿Hay dinero, recompensa, propiedad, permisos o estado compartido?
- ¿Qué habilidad genera la hipótesis y cuál puede confirmar el mecanismo?
- ¿Esta habilidad agrega una lente nueva o solo repite otra?
- ¿Se ha alcanzado realmente el
risk_floorde la habilidad? - ¿La ganancia de cobertura justifica el coste de razonamiento/investigación?
- ¿La tarea necesita una fuente externa o puede resolverse en el proyecto?
- Si una candidata se queda fuera, ¿es un verdadero casi-acierto o solo ruido de palabras clave?
Patrones de Ataque
Sub-enrutamiento
tarea crítica → un generador amplio → sin verificador
Ataque: buscar mecanismos explícitos (reintento, concurrencia, propiedad, fallo parcial) y verificar si ha entrado una habilidad capaz de confirmarlos.
Sobre-enrutamiento
una palabra coincidente → cada habilidad adyacente
Ataque: eliminar cada habilidad y preguntarse si se pierde alguna suposición o capacidad de confirmación. Si nada cambia, la habilidad era redundante.
Lenguaje ambiguo
"estado" en feedback de UI ≠ consistencia de estado compartido
"acceso" en texto ≠ autorización
"investigación" en tarea rutinaria ≠ flujo completo de investigación
Ataque: usar contexto y señales requeridas, no una palabra aislada.
Contexto negativo
"sin permisos, sin estado compartido"
Ataque: los términos negados no deben activar seguridad/fiabilidad.
Presión del presupuesto
7 habilidades plausibles para una tarea de alto riesgo (presupuesto máximo 4)
Ataque: mantener solo las de mayor puntuación y las que agregan un rol/lente distinto; mover las restantes a Casi-aciertos.
Requisitos de Evidencia
Una decisión de enrutamiento se sostiene cuando incluye:
- tarea y contexto analizados;
- riesgo y categoría dominante;
- habilidades seleccionadas en orden;
- rol, puntuación y triggers/señales de cada selección;
- presupuesto usado;
- como máximo tres casi-aciertos;
- decisión de investigación;
- resultado de las evaluaciones deterministas cuando se modificó el enrutamiento.
Compuertas iniciales:
precisión_enrutamiento >= 90%
recuperación_enrutamiento >= 90%
recuperación_habilidades_críticas = 100%
trivial seleccionado <= 1
Falsos Positivos
- Seleccionar todas las habilidades relacionadas "por si acaso".
- Promover una habilidad solo porque su categoría coincide, sin trigger ni señal.
- Tratar la relación
composes_withcomo una dependencia obligatoria. - Ignorar
overlaps_withy repetir la misma cobertura. - Contar una habilidad
usefulcomo obligatoria en todos los casos. - Usar contexto negado (
sin permisos) como señal positiva. - Listar todas las habilidades rechazadas; solo los casi-aciertos reales importan.
- Duplicar tablas globales del catálogo dentro de este archivo.
Formato de Salida
## Enrutador de Habilidades — Despacho
**Tarea:** <tarea + hechos relevantes>
**Categoría dominante:** <auditoría | seguridad | fiabilidad | producto | frontend | investigación>
**Riesgo:** <trivial | medium | high | critical>
**Presupuesto:** <mín–máx; seleccionado N>
### Seleccionadas
1. `<habilidad>` — rol: `<rol>`; puntuación: `<puntuación>`; evidencia: `<trigger/señal>`
2. ...
### Casi-aciertos
- `<habilidad>` — <por qué parecía relevante y por qué se quedó fuera>
- no más de 3
### Enrutamiento de investigación
<none | proportional | full; fuentes/habilidad si es necesario>
### Justificación del presupuesto
<solo cuando se excede; de lo contrario "within budget">
El ejecutor ejecuta las habilidades seleccionadas y consolida los hallazgos por separado. El enrutamiento no promueve hipótesis a hallazgos ni elige confianza.