@saulwade/swl-ses 1.3.8 → 1.4.1

package/habilidades/eval-framework/SKILL.md

@@ -1,212 +1,212 @@
----
-name: eval-framework
-description: >
-  Eval framework para validar y puntuar outputs estructurados de SWL
-  (aprendizajes, instintos, observaciones, resúmenes, contextos). Cargar
-  cuando un agente produzca un output estructurado y se quiera medir su
-  calidad antes de persistir, o cuando se audite la calidad histórica de
-  funciones críticas (extractor-de-aprendizajes, perfilador-usuario,
-  consolidador, planificador).
-version: "1.0.0"
-herramientasPermitidas: [Read, Bash]
-exclusiones:
-  - "No cargar para validación de input de usuario o request HTTP — eso es validación de boundary, usar Pydantic/Zod en el endpoint."
-  - "No cargar para auditoría de seguridad — usar `revisor-seguridad-swl` y `escaneo-secretos`."
-  - "No cargar para tests unitarios de código — usar `tdd-workflow` y Vitest."
-  - "No cargar cuando el output no tiene estructura definida (texto libre): el eval framework requiere schemas declarados o quality scorers específicos."
-evolvable: true  # default para skill estandar
----
-# Eval Framework — Validación + Calidad de Outputs SWL
-
-## Cuándo cargar
-
-- Tras producir un output estructurado (observación, aprendizaje, resumen,
-  resultado de búsqueda) cuando se quiera puntuar su calidad antes de
-  persistir.
-- Para auditar histórico de calidad de una función crítica (ver métricas
-  agregadas en `.planning/evolucion/eval-metrics.json`).
-- En tests/CI cuando el contrato del output tenga campos obligatorios y
-  quality thresholds.
-- En loops de auto-corrección donde un output inválido debe regenerarse
-  con un prompt más estricto.
-
----
-
-## Componentes del framework
-
-| Módulo | Propósito |
-|---|---|
-| `scripts/lib/eval-schemas.js` | Schemas JSON-lite para outputs (observación, resumen, search input, etc.). |
-| `scripts/lib/eval-validator.js` | Validador zero-deps de schemas (sin Zod). |
-| `scripts/lib/eval-quality.js` | Funciones de scoring: `scoreObservacion`, `scoreResumen`, `scoreAprendizaje`, `scoreInstinto`, `scoreRelevanciaContexto`. |
-| `scripts/lib/eval-self-correct.js` | Loop de retry con sufijo estricto cuando validador falla. |
-| `scripts/lib/eval-metrics-store.js` | Persistencia: JSONL append-only (`eval-results.jsonl`) + agregado JSON (`eval-metrics.json`). |
-| `scripts/run-eval.js` | CLI para evaluar un output desde archivo JSON. |
-
----
-
-## Uso típico desde agente o test
-
-### Validar output contra schema
-
-```js
-const { validar } = require('./scripts/lib/eval-validator');
-const { COMPRESS_OUTPUT_SCHEMA } = require('./scripts/lib/eval-schemas');
-
-const observacion = {
-  type: 'discovery',
-  title: 'Detalle relevante',
-  facts: ['fact 1', 'fact 2'],
-  narrative: 'Narrativa con suficiente detalle para evaluar',
-  concepts: ['c1'],
-  files: ['ruta/al/archivo.js'],
-  importance: 7,
-};
-
-const r = validar(observacion, COMPRESS_OUTPUT_SCHEMA);
-if (!r.valid) {
-  console.error('Output inválido:', r.errors);
-} else {
-  // Persistir
-}
-```
-
-### Puntuar calidad (independiente de validez)
-
-```js
-const { scoreObservacion, scoreAprendizaje, scoreInstinto } = require('./scripts/lib/eval-quality');
-
-const score = scoreObservacion(observacion);
-// score ∈ [0, 100]. 100 = todos los campos óptimos.
-```
-
-### Loop de auto-corrección
-
-```js
-const { compresseConReintento } = require('./scripts/lib/eval-self-correct');
-
-const productor = async (sysPrompt, userPrompt) => {
-  // Llamar al LLM o ejecutar Skill que produzca el output
-  return await llamarClaude(sysPrompt, userPrompt);
-};
-
-const validador = (output) => {
-  const parsed = JSON.parse(output);
-  return validar(parsed, COMPRESS_OUTPUT_SCHEMA);
-};
-
-const r = await compresseConReintento({
-  productor, validador,
-  sysPrompt: '...', userPrompt: '...',
-  maxRetries: 2,
-});
-
-if (r.valid) {
-  // r.output es válido (puede haber requerido r.intentos retries)
-}
-```
-
-### Persistir métricas para auditoría histórica
-
-```js
-const ms = require('./scripts/lib/eval-metrics-store');
-
-ms.registrar(process.cwd(), {
-  functionId: 'extractor-de-aprendizajes::scorer',
-  latencyMs: 42,
-  success: true,
-  qualityScore: 85,
-});
-
-// Lectura agregada
-const m = ms.obtener(process.cwd(), 'extractor-de-aprendizajes::scorer');
-// → { totalCalls, successCount, failureCount, avgLatencyMs, avgQualityScore, ... }
-```
-
-### CLI desde Bash (para CI o manual)
-
-```bash
-# Crear archivo de eval
-cat > /tmp/eval.json << 'EOF'
-{
-  "functionId": "memoria-busqueda::search",
-  "schemaName": "MEMORY_SEARCH_RESULT_SCHEMA",
-  "qualityScorer": null,
-  "expectedKeys": ["id", "tipo", "titulo", "fecha", "relevancia"],
-  "output": { ... }
-}
-EOF
-
-# Ejecutar
-node scripts/run-eval.js /tmp/eval.json
-# Exit 0 si valid, 1 si inválido. Persiste métricas automáticamente.
-
-# Reconstruir agregado desde JSONL si se corrompe
-node scripts/run-eval.js --rebuild-aggregate
-```
-
----
-
-## Schemas disponibles
-
-- `COMPRESS_OUTPUT_SCHEMA` — observación comprimida con type, title, facts,
-  narrative, concepts, files, importance.
-- `SUMMARY_OUTPUT_SCHEMA` — resumen de sesión con title, narrative,
-  keyDecisions, filesModified, concepts.
-- `SEARCH_INPUT_SCHEMA` — input de búsqueda { query, limit? }.
-- `REMEMBER_INPUT_SCHEMA` — input de "remember" { content, type?,
-  concepts?, files? }.
-- `EVAL_RESULT_SCHEMA` — resultado de evaluación { valid, errors?,
-  qualityScore, latencyMs, functionId, metadata? }.
-- `MEMORY_SEARCH_RESULT_SCHEMA` — resultado de `hooks/lib/memory-search`
-  con id, tipo, titulo, fecha, relevancia, combinedScore?, confidence?.
-
-Agregar más schemas en `scripts/lib/eval-schemas.js` siguiendo el formato
-JSON Schema-lite (subset documentado en `eval-validator.js`).
-
----
-
-## Quality scorers disponibles
-
-- `scoreObservacion(obs)` — observación con type/title/facts/narrative/concepts/importance.
-- `scoreResumen(summary)` — resumen con title/narrative/keyDecisions/filesModified/concepts.
-- `scoreAprendizaje(aprendizaje)` — aprendizaje SWL con titulo/contenido/tipo (específico de SWL).
-- `scoreInstinto(instinto)` — instinto con pattern/confidence/status/source_*/evidence_count (específico de SWL).
-- `scoreRelevanciaContexto(context, project)` — contexto inyectado en sesión.
-
-Cada scorer devuelve un número en [0, 100]. Los criterios están documentados
-en cada función en `scripts/lib/eval-quality.js`.
-
----
-
-## Diferencias con tests unitarios
-
-| Eval framework | Tests unitarios |
-|---|---|
-| Mide calidad subjetiva sobre estructura | Mide correctitud lógica |
-| Score graduado [0, 100] | Pass/fail binario |
-| Persiste histórico para auditoría | No persiste (corre en CI) |
-| Para outputs estructurados de agentes | Para funciones puras / API |
-| Permite retry con prompt estricto | No aplicable |
-
-Los dos son complementarios: tests unitarios para `scoring-instintos.js`,
-eval framework para "¿el aprendizaje que extrajo el hook es de calidad?".
-
----
-
-## Gotchas / Errores comunes no obvios
-
-- **Validez estructural ≠ calidad**: un aprendizaje con `titulo: "X"` y
-  `contenido: "trivial"` puede pasar `expectedKeys` pero tener
-  `qualityScore: 0`. El framework los distingue. En CI gates, considerar
-  ambos: `valid && qualityScore >= 60`.
-- **Métricas agregadas se reescriben atómicamente**: si dos procesos
-  llaman `registrar()` en paralelo sobre el mismo `functionId`, el último
-  gana (race condition en agregado). Para alta concurrencia usar
-  `reconstruirAgregado()` periódicamente desde el JSONL append-only.
-- **`run-eval.js` exit code**: 0 = valid, 1 = inválido o error de I/O,
-  2 = error de uso. No confundir con quality threshold — el CLI no
-  bloquea por quality bajo, solo por validez.
-- **`compresseConReintento` no reintenta indefinidamente**: respeta
-  `maxRetries`. Tras agotar reintentos devuelve el último output con
-  `valid: false`. El caller decide qué hacer.
+---
+name: eval-framework
+description: >
+  Eval framework para validar y puntuar outputs estructurados de SWL
+  (aprendizajes, instintos, observaciones, resúmenes, contextos). Cargar
+  cuando un agente produzca un output estructurado y se quiera medir su
+  calidad antes de persistir, o cuando se audite la calidad histórica de
+  funciones críticas (extractor-de-aprendizajes, perfilador-usuario,
+  consolidador, planificador).
+version: "1.0.0"
+herramientasPermitidas: [Read, Bash]
+exclusiones:
+  - "No cargar para validación de input de usuario o request HTTP — eso es validación de boundary, usar Pydantic/Zod en el endpoint."
+  - "No cargar para auditoría de seguridad — usar `revisor-seguridad-swl` y `escaneo-secretos`."
+  - "No cargar para tests unitarios de código — usar `tdd-workflow` y Vitest."
+  - "No cargar cuando el output no tiene estructura definida (texto libre): el eval framework requiere schemas declarados o quality scorers específicos."
+evolvable: true  # default para skill estandar
+---
+# Eval Framework — Validación + Calidad de Outputs SWL
+
+## Cuándo cargar
+
+- Tras producir un output estructurado (observación, aprendizaje, resumen,
+  resultado de búsqueda) cuando se quiera puntuar su calidad antes de
+  persistir.
+- Para auditar histórico de calidad de una función crítica (ver métricas
+  agregadas en `.planning/evolucion/eval-metrics.json`).
+- En tests/CI cuando el contrato del output tenga campos obligatorios y
+  quality thresholds.
+- En loops de auto-corrección donde un output inválido debe regenerarse
+  con un prompt más estricto.
+
+---
+
+## Componentes del framework
+
+| Módulo | Propósito |
+|---|---|
+| `scripts/lib/eval-schemas.js` | Schemas JSON-lite para outputs (observación, resumen, search input, etc.). |
+| `scripts/lib/eval-validator.js` | Validador zero-deps de schemas (sin Zod). |
+| `scripts/lib/eval-quality.js` | Funciones de scoring: `scoreObservacion`, `scoreResumen`, `scoreAprendizaje`, `scoreInstinto`, `scoreRelevanciaContexto`. |
+| `scripts/lib/eval-self-correct.js` | Loop de retry con sufijo estricto cuando validador falla. |
+| `scripts/lib/eval-metrics-store.js` | Persistencia: JSONL append-only (`eval-results.jsonl`) + agregado JSON (`eval-metrics.json`). |
+| `scripts/run-eval.js` | CLI para evaluar un output desde archivo JSON. |
+
+---
+
+## Uso típico desde agente o test
+
+### Validar output contra schema
+
+```js
+const { validar } = require('./scripts/lib/eval-validator');
+const { COMPRESS_OUTPUT_SCHEMA } = require('./scripts/lib/eval-schemas');
+
+const observacion = {
+  type: 'discovery',
+  title: 'Detalle relevante',
+  facts: ['fact 1', 'fact 2'],
+  narrative: 'Narrativa con suficiente detalle para evaluar',
+  concepts: ['c1'],
+  files: ['ruta/al/archivo.js'],
+  importance: 7,
+};
+
+const r = validar(observacion, COMPRESS_OUTPUT_SCHEMA);
+if (!r.valid) {
+  console.error('Output inválido:', r.errors);
+} else {
+  // Persistir
+}
+```
+
+### Puntuar calidad (independiente de validez)
+
+```js
+const { scoreObservacion, scoreAprendizaje, scoreInstinto } = require('./scripts/lib/eval-quality');
+
+const score = scoreObservacion(observacion);
+// score ∈ [0, 100]. 100 = todos los campos óptimos.
+```
+
+### Loop de auto-corrección
+
+```js
+const { compresseConReintento } = require('./scripts/lib/eval-self-correct');
+
+const productor = async (sysPrompt, userPrompt) => {
+  // Llamar al LLM o ejecutar Skill que produzca el output
+  return await llamarClaude(sysPrompt, userPrompt);
+};
+
+const validador = (output) => {
+  const parsed = JSON.parse(output);
+  return validar(parsed, COMPRESS_OUTPUT_SCHEMA);
+};
+
+const r = await compresseConReintento({
+  productor, validador,
+  sysPrompt: '...', userPrompt: '...',
+  maxRetries: 2,
+});
+
+if (r.valid) {
+  // r.output es válido (puede haber requerido r.intentos retries)
+}
+```
+
+### Persistir métricas para auditoría histórica
+
+```js
+const ms = require('./scripts/lib/eval-metrics-store');
+
+ms.registrar(process.cwd(), {
+  functionId: 'extractor-de-aprendizajes::scorer',
+  latencyMs: 42,
+  success: true,
+  qualityScore: 85,
+});
+
+// Lectura agregada
+const m = ms.obtener(process.cwd(), 'extractor-de-aprendizajes::scorer');
+// → { totalCalls, successCount, failureCount, avgLatencyMs, avgQualityScore, ... }
+```
+
+### CLI desde Bash (para CI o manual)
+
+```bash
+# Crear archivo de eval
+cat > /tmp/eval.json << 'EOF'
+{
+  "functionId": "memoria-busqueda::search",
+  "schemaName": "MEMORY_SEARCH_RESULT_SCHEMA",
+  "qualityScorer": null,
+  "expectedKeys": ["id", "tipo", "titulo", "fecha", "relevancia"],
+  "output": { ... }
+}
+EOF
+
+# Ejecutar
+node scripts/run-eval.js /tmp/eval.json
+# Exit 0 si valid, 1 si inválido. Persiste métricas automáticamente.
+
+# Reconstruir agregado desde JSONL si se corrompe
+node scripts/run-eval.js --rebuild-aggregate
+```
+
+---
+
+## Schemas disponibles
+
+- `COMPRESS_OUTPUT_SCHEMA` — observación comprimida con type, title, facts,
+  narrative, concepts, files, importance.
+- `SUMMARY_OUTPUT_SCHEMA` — resumen de sesión con title, narrative,
+  keyDecisions, filesModified, concepts.
+- `SEARCH_INPUT_SCHEMA` — input de búsqueda { query, limit? }.
+- `REMEMBER_INPUT_SCHEMA` — input de "remember" { content, type?,
+  concepts?, files? }.
+- `EVAL_RESULT_SCHEMA` — resultado de evaluación { valid, errors?,
+  qualityScore, latencyMs, functionId, metadata? }.
+- `MEMORY_SEARCH_RESULT_SCHEMA` — resultado de `hooks/lib/memory-search`
+  con id, tipo, titulo, fecha, relevancia, combinedScore?, confidence?.
+
+Agregar más schemas en `scripts/lib/eval-schemas.js` siguiendo el formato
+JSON Schema-lite (subset documentado en `eval-validator.js`).
+
+---
+
+## Quality scorers disponibles
+
+- `scoreObservacion(obs)` — observación con type/title/facts/narrative/concepts/importance.
+- `scoreResumen(summary)` — resumen con title/narrative/keyDecisions/filesModified/concepts.
+- `scoreAprendizaje(aprendizaje)` — aprendizaje SWL con titulo/contenido/tipo (específico de SWL).
+- `scoreInstinto(instinto)` — instinto con pattern/confidence/status/source_*/evidence_count (específico de SWL).
+- `scoreRelevanciaContexto(context, project)` — contexto inyectado en sesión.
+
+Cada scorer devuelve un número en [0, 100]. Los criterios están documentados
+en cada función en `scripts/lib/eval-quality.js`.
+
+---
+
+## Diferencias con tests unitarios
+
+| Eval framework | Tests unitarios |
+|---|---|
+| Mide calidad subjetiva sobre estructura | Mide correctitud lógica |
+| Score graduado [0, 100] | Pass/fail binario |
+| Persiste histórico para auditoría | No persiste (corre en CI) |
+| Para outputs estructurados de agentes | Para funciones puras / API |
+| Permite retry con prompt estricto | No aplicable |
+
+Los dos son complementarios: tests unitarios para `scoring-instintos.js`,
+eval framework para "¿el aprendizaje que extrajo el hook es de calidad?".
+
+---
+
+## Gotchas / Errores comunes no obvios
+
+- **Validez estructural ≠ calidad**: un aprendizaje con `titulo: "X"` y
+  `contenido: "trivial"` puede pasar `expectedKeys` pero tener
+  `qualityScore: 0`. El framework los distingue. En CI gates, considerar
+  ambos: `valid && qualityScore >= 60`.
+- **Métricas agregadas se reescriben atómicamente**: si dos procesos
+  llaman `registrar()` en paralelo sobre el mismo `functionId`, el último
+  gana (race condition en agregado). Para alta concurrencia usar
+  `reconstruirAgregado()` periódicamente desde el JSONL append-only.
+- **`run-eval.js` exit code**: 0 = valid, 1 = inválido o error de I/O,
+  2 = error de uso. No confundir con quality threshold — el CLI no
+  bloquea por quality bajo, solo por validez.
+- **`compresseConReintento` no reintenta indefinidamente**: respeta
+  `maxRetries`. Tras agotar reintentos devuelve el último output con
+  `valid: false`. El caller decide qué hacer.

package/habilidades/extractor-de-aprendizajes/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: extractor-de-aprendizajes
 description: Convertir errores y patrones descubiertos durante la implementación en nuevas habilidades o reglas. Ciclo de mejora continua del sistema SWL.
-version: "1.0.4"
+version: "1.0.5"
 herramientasPermitidas: [Read]
 exclusiones:
   - "No cargar para actualizar el perfil del usuario — las correcciones explícitas del usuario van a `instintos/perfil-usuario.yaml` vía `perfilador-usuario-swl`, no a APRENDIZAJES.md."
@@ -10,10 +10,10 @@ exclusiones:
   - "No cargar si el aprendizaje no tiene causa raíz identificada — documentar síntoma sin causa produce reglas que no previenen el error real."
 evolvable: true  # default para skill estandar
 evolved: true
-evolved-from: "1.0.3"
-evolved-at: "2026-05-11"
+evolved-from: "1.0.4"
+evolved-at: "2026-05-12"
 evolved-by: "aprender"
-evolved-note: "Extender gotcha Explore (papers → papers+repos) tras confirmación x4 — sync desde skill global"
+evolved-note: "Backport L-140 SIGM: extender gotcha sub-agentes a Modo C (revisor-codigo-swl reporta ubicaciones incorrectas y severidades subestimadas); CONFIRMADO x4 → x5"
 ---
 # Extractor de Aprendizajes
 
@@ -296,17 +296,27 @@ Durante `/swl:aprender`, aplicar estas reglas:
 - **`rating: HIGH` asignado sin verificar criterio de irreversibilidad**: el agente promueve a CLAUDE.md un aprendizaje "MEDIUM" por el entusiasmo del momento. Causa: no se aplicó el criterio de "decisión irreversible o bug crítico". Solución: antes de asignar HIGH, verificar: ¿cambiar esto en el futuro requeriría refactorizar múltiples archivos o migrar datos? Si no, mantener MEDIUM.
 - **Regla incompleta sobre registro de hooks**: una entrada en memoria dice "registrar en modulos.json" pero omite `hooks-config.json`, y en la siguiente iteración se repite el fallo en CI porque ambos manifiestos son obligatorios. Causa: la regla de la lección anterior no cubrió todos los manifiestos afectados. Solución: al documentar una regla sobre registro en manifiestos, listar EXPLÍCITAMENTE cada manifiesto con su responsabilidad distinta (`modulos.json` = qué copiar; `hooks-config.json` = cómo registrar evento). Evidencia: tres incidentes históricos del mismo patrón incompleto (v5.7.1, v5.7.2/3, v5.11.0).
 - **Inventario estimado a mano en vez de regenerar**: el agente cuenta "28 hooks" visualmente y propaga la cifra a 5 archivos (CLAUDE/README/package/plugin/SALUD); al regenerar con `scripts/generar-inventario.js` el número real es 30. Causa: confiar en la observación directa en vez de la fuente de verdad determinista. Solución: antes de modificar cualquier contador en documentación oficial, ejecutar el script de inventario y usar su salida como ground truth.
-- **Sub-agente Explore sobreestima al analizar fuentes externas (papers + repos)** [CONFIRMADO x4]: cuando se delega análisis de una fuente externa (paper arXiv, repositorio GitHub, documentación de framework) al sub-agente Explore, el reporte propone implementar contribuciones sin filtrar por restricciones del sistema destino Y, peor, sin verificar qué de eso ya existe en el proyecto. **Dos modos de falla observados**:
+- **Sub-agentes (Explore + revisores) reportan afirmaciones factuales no verificadas sobre el código** [CONFIRMADO x5]: aplica a `Explore`, `revisor-codigo-swl`, `revisor-seguridad-swl`, `investigador-swl`, `planificador-swl`, y en general a cualquier sub-agente que reporte hallazgos sobre código del proyecto destino. **Tres modos de falla observados**:
 
-  **Modo A — papers académicos** (sesión 2026-04-25): sub-agente propuso 50h+ para implementar SPRT + Lyapunov + compositionality theorem del paper Bhardwaj 2026; costo real validado fue ~5h (solo Drift Score + Recovery Catalog). Causa: el Explore evalúa portabilidad técnica sin aplicar filtro de "datos disponibles" ni "infraestructura zero-deps". Evidencia: 3 papers analizados (evolver, Bhardwaj 2026, Zhang et al. 2026) con descarte sistemático ~70-90% del contenido propuesto.
+  **Modo A — papers académicos** (sesión 2026-04-25): sub-agente Explore propuso 50h+ para implementar SPRT + Lyapunov + compositionality theorem del paper Bhardwaj 2026; costo real validado fue ~5h (solo Drift Score + Recovery Catalog). Causa: el Explore evalúa portabilidad técnica sin aplicar filtro de "datos disponibles" ni "infraestructura zero-deps". Evidencia: 3 papers analizados (evolver, Bhardwaj 2026, Zhang et al. 2026) con descarte sistemático ~70-90% del contenido propuesto.
 
-  **Modo B — repositorios externos** (sesión 2026-05-02 cosecha-temp/ EMAIA): sub-agente analizando `temp/docetl-main` (UC Berkeley, arXiv:2410.12189) afirmó dos cosas FALSAS verificables contra el código del proyecto destino: (1) "EMAIA ya usa LiteLLM" — verificación contra `pyproject.toml` + `grep -r litellm core/` mostró que EMAIA tiene clientes propios (`OllamaClient`/`NIMClient`/`vLLMClient`) y NO usa LiteLLM en absoluto; (2) recomendó portar Gleaning como patrón nuevo, cuando `core/learning/evaluator_optimizer.py` y `core/llm/quality_judge.py` YA implementan Anthropic Evaluator-Optimizer + LLM-as-judge. El fix real era WIRING (~30 LOC), no porting. Costo "MEDIO" del agente quedó como BAJO real. Causa: el Explore evalúa el repo externo en aislamiento, sin leer paths del proyecto destino para verificar qué mecanismos ya existen.
+  **Modo B — repositorios externos** (sesión 2026-05-02 cosecha-temp/ EMAIA): sub-agente Explore analizando `temp/docetl-main` (UC Berkeley, arXiv:2410.12189) afirmó dos cosas FALSAS verificables contra el código del proyecto destino: (1) "EMAIA ya usa LiteLLM" — verificación contra `pyproject.toml` + `grep -r litellm core/` mostró que EMAIA tiene clientes propios (`OllamaClient`/`NIMClient`/`vLLMClient`) y NO usa LiteLLM en absoluto; (2) recomendó portar Gleaning como patrón nuevo, cuando `core/learning/evaluator_optimizer.py` y `core/llm/quality_judge.py` YA implementan Anthropic Evaluator-Optimizer + LLM-as-judge. El fix real era WIRING (~30 LOC), no porting. Costo "MEDIO" del agente quedó como BAJO real. Causa: el Explore evalúa el repo externo en aislamiento, sin leer paths del proyecto destino para verificar qué mecanismos ya existen.
 
-  **Solución unificada — aplicar filtros antes de aceptar propuesta del Explore**:
+  **Modo C — revisores reportan ubicaciones y severidades incorrectas en código del proyecto** (sesión 2026-05-12 SIGM): `revisor-codigo-swl` ejecutado en `/swl:verificar --until-converge` reportó dos errores factuales: (1) **ubicación incorrecta**: "deferred import en `caja/router.py:545`" cuando la línea real estaba en `caja/service.py:545` — el archivo `caja/router.py` solo tiene 157 líneas (`wc -l caja/router.py = 157`); (2) **severidad subestimada**: reportó "mismatch `CobroConsolidadoResponse` en pantalla de éxito" como MAYOR, mi auditoría manual descubrió que `CobroConsolidadoRequest` también estaba completamente desalineado (más grave, debería ser CRÍTICO bloqueante) — el revisor solo miró el Response. Causa: el revisor analiza código sin re-verificar el path/línea/extensión reportada cuando produce el reporte; sub-agentes basados en LLM hallucinan números de línea con frecuencia ≥15% en archivos grandes.
 
-  *Para papers académicos (Modo A)*: 3 filtros críticos: (1) ¿requiere SMT solver / SPRT / Lyapunov / DTMC / formal verification? → descartar (rompe zero-deps); (2) ¿requiere N>100 sesiones de campo para validación estadística? → descartar; (3) ¿genera valor accionable HOY o solo elegancia matemática? → solo implementar si HOY.
+  **Solución unificada — protocolo de verificación de afirmaciones factuales antes de aceptar propuesta de CUALQUIER sub-agente**:
 
-  *Para repos externos (Modo B)*: 4 filtros críticos: (1) ¿qué % es teoría/código no-portable vs portable? — si >70% no-portable, recortar; (2) **¿la propuesta reescribe mecanismos existentes en el proyecto destino?** — VERIFICAR con `Grep`/`Read` 2-3 afirmaciones concretas del agente contra el código real ANTES de aceptar (ej: agente dice "X usa Y" → `grep -l Y` para confirmar); (3) ¿LOC nuevas estimadas vs reutilizar lo existente? — si la propuesta supera 500 LOC para un solo patrón, hay sobre-ingeniería; (4) ¿el alcance reducido cubre 80% del valor? — Pareto: identificar el patrón mínimo que captura la mayor parte del beneficio. **Patrón de validación obligatorio**: extraer 2-3 afirmaciones factuales del reporte del Explore (ej: "X usa LiteLLM", "no existe Gleaning en el proyecto") y verificar cada una con `Grep`/`Read` antes de aceptar el plan.
+  *Patrón obligatorio aplicable a TODOS los modos*: extraer 2-3 afirmaciones factuales del reporte del sub-agente y verificar cada una con primitivas baratas (`Grep`/`Read`/`wc -l`/`ls`/`git log`) ANTES de aceptar el plan o acción. Tipos de afirmaciones a verificar:
+
+  - **Ubicaciones de código** (`archivo.py:123`): verificar `wc -l archivo.py` muestra ≥123, y `sed -n '120,125p' archivo.py` muestra el contenido reportado.
+  - **Claims tipo "X usa Y" o "Z no existe"**: `grep -l Y archivo` o `find . -name "Z*"` para confirmar.
+  - **Severidad y alcance**: si el revisor reporta "MAYOR" pero el bug afecta el happy path, re-clasificar a CRÍTICO manualmente.
+
+  *Para papers académicos (Modo A)*: 3 filtros adicionales: (1) ¿requiere SMT solver / SPRT / Lyapunov / DTMC / formal verification? → descartar (rompe zero-deps); (2) ¿requiere N>100 sesiones de campo para validación estadística? → descartar; (3) ¿genera valor accionable HOY o solo elegancia matemática? → solo implementar si HOY.
+
+  *Para repos externos (Modo B)*: 4 filtros adicionales: (1) ¿qué % es teoría/código no-portable vs portable? — si >70% no-portable, recortar; (2) **¿la propuesta reescribe mecanismos existentes en el proyecto destino?** — VERIFICAR con `Grep`/`Read` 2-3 afirmaciones concretas del agente contra el código real ANTES de aceptar; (3) ¿LOC nuevas estimadas vs reutilizar lo existente? — si la propuesta supera 500 LOC para un solo patrón, hay sobre-ingeniería; (4) ¿el alcance reducido cubre 80% del valor? — Pareto.
+
+  *Para revisores de código (Modo C)*: además del patrón obligatorio, **re-clasificar severidad cuando el revisor solo miró parte del flujo**. Si el revisor marca MAYOR un bug del Response, verificar si el Request también está afectado — los happy paths típicamente involucran ambos lados.
 - **Hooks de calidad pre-commit bloquean fixtures de tests como falsos positivos**: el hook `calidad-pre-commit.js` aplica regex `\b(api_key|password|token|secret)\s*[=:]\s*["'][^"'\s]{4,}["']` que matchea fixtures legítimos en archivos de test. Caso real: test que valida que la función `sanitizar()` redacta `api_key="abc12345xyz"` se bloquea. Causa: el hook no distingue contexto de test vs producción. Solución: en archivos de test, construir fixtures con concatenación de strings (`'api' + '_key'`, `'pass' + 'word'`) o agregar marcador placeholder reconocido por el hook (`fake_`, `dummy_`, `placeholder`, `example`, `os.environ`). NUNCA bypassear el hook con `--no-verify` — el detector cumple su función; ajustar el fixture es lo correcto.
 - **Regex de path-matching `/[\\/]<dir>[\\/]/` falla con paths relativos sin slash inicial** [CONFIRMADO x4]: hooks que filtran archivos por directorio (ej: `hooks/extraccion-aprendizajes.js` con `PATRONES_ARCHIVO_SWL_EXCLUIDO`) usan patrones que requieren un separator ANTES del nombre. Caso real: path `scripts/lib/foo.js` (sin slash inicial) eludía el filtro de exclusión y generaba placeholders espurios en APRENDIZAJES.md cada vez que se hacía `Edit` o `Write` sobre archivos del sistema SWL. Causa: el regex `[\\/]` requiere un caracter slash/backslash previo; cuando el path empieza con el nombre del directorio directamente, no matchea. Solución: usar `/(?:^|[\\/])<dir>[\\/]/` para aceptar tanto el inicio del string como un separator previo. Evidencia: 4 placeholders eliminados manualmente entre v1.3.3-v1.3.5 antes de identificar la causa raíz; fix endurecido aplicado en v1.3.5 (Fix I).
 - **`git ls-files` es preferible a `fs.readdir` recursivo para tests anti-regresión que escanean el repo**: usar `execSync('git ls-files')` limita el escaneo a archivos versionados — evita `node_modules/`, `.git/`, `_userland/`, archivos temporales y backups sin enumerar exclusiones. Caso real: `tests/scripts/no-legacy-npx-pattern.test.js` v1.3.6 escanea 1000+ archivos versionados en <200ms; el equivalente con `fs.readdir` recursivo más exclusiones manuales sería más lento y propenso a olvidar paths. Cuando el test es de "calidad del repo" (no de comportamiento), `git ls-files` es la primitiva correcta.

package/habilidades/feynman-auditor-swl/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: feynman-auditor-swl
+description: >
+  Auditor de bugs de lógica de negocio mediante la técnica Feynman: cuestiona
+  cada línea, cada orden de operaciones, cada presencia/ausencia de guard, y
+  cada asunción implícita. Language-agnostic (Python, TS, Go, Rust, Java, C#).
+  Cargar cuando se necesite revisión profunda de funciones individuales en
+  módulos críticos, especialmente tras un revisor-codigo-swl que pasó pero
+  donde sospechas que algo no está bien.
+---
+
+# Cuándo cargar
+
+- El módulo maneja dinero, inventario, permisos, o datos críticos irreversibles.
+- `revisor-codigo-swl` pasó pero hay sospecha de bug de lógica de negocio.
+- Nemesis está corriendo su Pasada 1.
+- Se necesita revisión profunda de una función específica antes de merge.
+
+# Cuándo NO cargar
+
+- Para escaneo de vulnerabilidades conocidas (CVE, inyecciones) — usar `revisor-seguridad-swl`.
+- Para revisión de estilo o cobertura de tests — usar `revisor-codigo-swl`.
+- Para funciones de utilería sin estado (formateo, parsing puro).
+- Como sustituto de tests de regresión.
+
+---
+
+# Feynman Auditor
+
+Encuentra bugs de lógica de negocio cuestionando cada línea como si tuvieras que explicarle el código a alguien que no asume nada.
+
+Las preguntas detalladas están en [recursos/preguntas-language-agnostic.md](recursos/preguntas-language-agnostic.md).
+
+---
+
+## Mentalidad de base
+
+Antes de leer el primer archivo, adoptar esta perspectiva:
+
+> "Este código tiene un bug. Mi trabajo es encontrarlo.
+> No estoy aquí para confirmar que el código es correcto.
+> Cada línea que no entiendo completamente es un sospechoso."
+
+Dos fuentes principales de bugs de lógica:
+
+1. **Bugs de guard ausente**: la condición correcta existe en función A pero falta en función B que hace lo mismo por un path diferente.
+2. **Bugs de orden de operaciones**: el cálculo es correcto, pero se ejecuta antes o después del momento en que los datos son válidos.
+
+---
+
+## Fase 0: Inventario de scope
+
+Antes de auditar, mapear:
+
+- ¿Qué módulos/archivos están en scope?
+- ¿Cuáles son las funciones de punto de entrada (endpoints, handlers, métodos públicos)?
+- ¿Qué datos persisten (BD, caché, archivos, estado en memoria)?
+- ¿Qué actores pueden llamar qué funciones?
+
+---
+
+## Fase 1: Auditoría de funciones individuales
+
+Para cada función no trivial, hacer las preguntas Q1–Q7 del archivo de recursos.
+
+Categorías de preguntas:
+- **Q1** — Propósito: ¿qué hace exactamente esta función y solo esta función?
+- **Q2** — Orden: ¿importa el orden de estas operaciones?
+- **Q3** — Consistencia cross-función: ¿qué tienen en común dos funciones que parecen similares?
+- **Q4** — Asunciones implícitas: ¿qué asume este código sin verificarlo?
+- **Q5** — Límites: ¿qué pasa en los extremos (cero, máximo, vacío, ya-existe)?
+- **Q6** — Returns y errores: ¿qué devuelve esta función cuando algo falla?
+- **Q7** — Interacciones externas: ¿qué puede pasar mal cuando se llama a otro sistema?
+
+Registrar como sospechoso cualquier función donde una pregunta no tenga respuesta clara en el código.
+
+---
+
+## Fase 2: Auditoría cross-función
+
+Buscar divergencias entre funciones que deberían comportarse igual:
+
+- ¿Función A y B hacen lo mismo pero una tiene un guard que la otra no tiene?
+- ¿La función de creación inicializa todos los campos que la función de lectura usa?
+- ¿El path de happy path y el path de error manejan el estado de la misma manera?
+
+---
+
+## Fase 3: Síntesis de hallazgos
+
+Convertir sospechosos en hallazgos concretos:
+
+Para cada sospechoso, construir:
+1. La pregunta Feynman que lo identificó
+2. La asunción que el código hace implícitamente
+3. El contraejemplo concreto que rompe esa asunción
+4. La consecuencia observable del bug
+
+---
+
+## Fase 4: Verificación
+
+Todo hallazgo CRÍTICO, ALTO y MEDIO debe verificarse antes del reporte final.
+
+**Patrón de falsos positivos frecuentes:**
+- El guard existe pero en un nivel superior (middleware, decorator, caller).
+- El orden parece incorrecto pero hay un comentario que explica el diseño intencional.
+- La función parece no validar, pero el tipo de dato ya garantiza el invariante.
+
+**Formato de salida**: `.audit/findings/feynman-passN.md`
+
+---
+
+## Adaptación por lenguaje
+
+| Concepto | Python | TypeScript | Go | Rust | Java | C# |
+|---------|--------|------------|-----|------|------|-----|
+| Actor | `request.user` | `req.user` / `userId` | `ctx.UserID` | `actor_id` | `principal` | `User.Identity` |
+| Guard | decorador / `if not user:` | middleware / `if (!user)` | `if ctx.UserID == ""` | `if actor_id.is_none()` | `@PreAuthorize` | `[Authorize]` |
+| Mutación interna | método privado `_fn` | método privado | función local | `pub(crate) fn` | método `private` | método `private` |
+| Transacción | `with db.begin():` | `await trx.begin()` | `tx, _ := db.Begin()` | `conn.execute("BEGIN")` | `@Transactional` | `using var tx =` |
+
+<!-- Adaptado de nemesis-auditor-main bajo MIT License (https://github.com/0xiehnnkta/nemesis-auditor) -->