@saulwade/swl-ses 1.7.4 → 1.9.0

package/comandos/swl/nemesis.md

@@ -8,7 +8,7 @@ description: >
   automático para scope > 1500 LOC o > 5 archivos en módulos distintos.
   Persiste hallazgos en .planning/audit/findings/iter-N/.
 allowed-tools: [Read, Grep, Glob, Bash, Write, Agent, Skill]
-argument-hint: "[--remediar] [--pass1 | --pass2 | --continue] [--modulo <ruta>] [--redistribuir] [--reset-plan]"
+argument-hint: "[--remediar] [--pass1 | --pass2 | --continue] [--modulo <ruta>] [--redistribuir] [--reset-plan] [--cross-model]"
 ---
 
 # /swl:nemesis — Auditoría iterativa con remediación opt-in
@@ -54,6 +54,29 @@ y el ciclo continúa hasta convergencia o agotar el guardrail de 3 iteraciones.
 | Acotar módulo | `--modulo <ruta>` | Limita el scope a un archivo o subdirectorio específico. Se combina con cualquier otro flag. |
 | Forzar redistribución | `--redistribuir` | Activa `Skill("nemesis-redistribuir")` aunque scope sea menor al umbral. |
 | Reset del plan | `--reset-plan` | Regenera `nemesis-plan.json` desde cero (descarta plan previo). |
+| **Revisión cross-modelo** | `--cross-model` | Opt-in: rutea la evaluación a un reviewer en OTRO modelo (vía MCP, p.ej. `gemini-review`/`codex-review`) para combatir *self-preferential bias*. Degrada al reviewer same-model si no hay MCP configurado (anuncia la degradación). Combina con `--remediar`. Ver `Skill("proceso-dynamic-workflows") § Revisión cross-modelo`. |
+
+## Revisión cross-modelo (`--cross-model`)
+
+El reviewer adversarial en el MISMO modelo aún arrastra *self-preferential bias*
+(uno de los 3 modos de falla nombrados en el blog oficial de dynamic workflows).
+`--cross-model` hace que la evaluación la emita un modelo DISTINTO al ejecutor:
+
+- **Wiring (opt-in, ligero)**: si hay un MCP reviewer configurado (patrón ARIS
+  `gemini-review`/`codex-review`: expone `review`/`review_reply`, devuelve JSON con
+  `threadId` + `response`), el paso de evaluación se rutea a ese MCP. swl-ses NO
+  embebe el servidor — lo provee el usuario con su API key del otro modelo.
+- **Degradación explícita** (regla `arreglar-al-detectar.md` / no-fallback-silencioso):
+  si el MCP no está disponible, NO falla — usa el reviewer same-model y **anuncia**
+  "cross-model solicitado pero MCP ausente → degradado a same-model".
+- **Reviewer memory + debate** (de ARIS `auto-review-loop`): el reviewer externo
+  arrastra sospechas entre iteraciones (un `threadId`); el ejecutor puede rebatir,
+  el reviewer falla el veredicto final — *"it can drive, never acquit"*.
+- **Trazabilidad**: el JSON del reviewer (`threadId`, `response`, score) se persiste
+  junto a `evaluacion.json` en `.planning/audit/findings/iter-N/` → veredicto
+  independiente auditable.
+
+Detalle del patrón: `Skill("proceso-dynamic-workflows") § Revisión cross-modelo`.
 
 ## Flujo completo con `--remediar`
 
@@ -207,6 +230,24 @@ Estructura de salida bajo `.planning/audit/findings/`:
 
 Cada `evaluacion.json` sigue el schema `nemesis-evaluacion-json` v1.0.0.
 
+### Telemetría de loop (obligatoria con `--remediar`)
+
+En modo `--remediar`, además de los `iter-N/` el comando registra la
+trayectoria en el formato estándar de telemetría de loops
+(`hooks/lib/loop-telemetry.js`). Esto habilita: inyección de estado por el
+hook `contexto-iteracion.js` durante las ejecuciones largas (8-30 turnos),
+detección de plateau, y lectura de la corrida por `/swl:metricas`.
+
+- Al iniciar iter-1: `iniciarCorrida({tipo: 'nemesis', direccion: 'lower_is_better', config: {modulo, maxIter: 3}})`.
+- Tras cada iteración: `registrarIteracion(dir, {iteracion: N, metrica: criticos+altos, delta, estado: 'keep', descripcion: 'iter N: status=<status>, X criticos, Y altos'})`.
+- Al cerrar (PASS, FAIL o Recovery Catalog): `escribirHandoff(dir, {source: 'swl:nemesis', status, findings: <hallazgos residuales con archivo_linea>, config})`.
+  Mapeo de status: PASS → `COMPLETO`, max iteraciones → `ACOTADO`, Recovery
+  Catalog/escalada → `INTERRUMPIDO`.
+
+El `handoff.json` resultante es consumible por una corrida posterior de
+`/swl:verificar --until-converge` o por el orquestador (los `findings`
+traen `archivo_linea` verificable según `verificar-citas-normativas.md § Familia 2`).
+
 ## Cómo interpretar el reporte
 
 ### Severidades

package/comandos/swl/planear-fase.md

@@ -161,6 +161,14 @@ El agente planificador-swl debe generar el plan con esta estructura exacta:
 ## Tests requeridos
 [lista de tests que deben existir al finalizar la fase]
 
+## Escenarios Gherkin (opt-in — solo si la fase tiene criterios de aceptación de negocio)
+[Si el CONTEXTO.md/PRD trae criterios de aceptación con reglas de negocio
+distinguibles, convertirlos en escenarios Given–When–Then siguiendo
+`habilidades/tdd-workflow/recursos/gherkin-bdd.md` y presentarlos al usuario
+para validación ANTES de aprobar el plan. Cada escenario validado se referencia
+desde la tarea que lo implementa (será su test RED). Omitir esta sección en
+fases técnicas puras — Gherkin sin lector de negocio es ceremonia.]
+
 ## Riesgos y mitigaciones
 | Riesgo | Impacto | Probabilidad | Mitigación |
 |--------|---------|-------------|-----------|

package/comandos/swl/predecir.md

@@ -0,0 +1,139 @@
+---
+name: swl:predecir
+description: >
+  Análisis predictivo pre-implementación: 5 personas expertas (Arquitecto,
+  Seguridad, Rendimiento, Confiabilidad, Abogado del Diablo) analizan EN FRÍO
+  un cambio propuesto antes de implementarlo, un sintetizador deduplica con
+  anti-herd check y entrega hallazgos rankeados por severidad × confianza ×
+  acuerdo. Usar antes de /swl:planear-fase en fases de riesgo, antes de un
+  refactor grande, o cuando el costo de descubrir un problema DESPUÉS de
+  implementar es alto. Con --adversarial usa el set atacante (Rompedor,
+  Tramposo, Escalador, Novato, Insider).
+argument-hint: "[descripción del cambio] [--scope <glob>] [--adversarial] [--presupuesto N] [--chain planear-fase]"
+allowed-tools: [Read, Grep, Glob, Bash, Write, Agent, Skill]
+---
+
+# /swl:predecir — Análisis predictivo pre-implementación
+
+Eres el coordinador de un panel de personas expertas que evalúan un cambio
+propuesto ANTES de que se implemente. El valor del comando está en el
+aislamiento: cada persona analiza en frío, sin ver a las demás — los sesgos
+de manada y de confirmación se eliminan por construcción.
+
+Complementa (no reemplaza) a `/swl:verificar` y `/swl:nemesis`: esos auditan
+código que YA existe; `predecir` ataca el plan cuando corregirlo cuesta una
+conversación, no un refactor.
+
+## Cuándo usar
+
+- Antes de `/swl:planear-fase` en fases que tocan auth, dinero, datos
+  productivos o contratos públicos de API.
+- Antes de un refactor cross-módulo o una migración de schema.
+- Cuando el usuario duda entre implementar o no un cambio con blast radius alto.
+
+**Cuándo NO usar**: cambios triviales (1-2 archivos), código ya implementado
+(usar `/swl:verificar`), o decisiones entre 2+ alternativas (usar el debate
+adversarial de `Skill("proceso-debate-adversarial")` — predecir analiza UNA
+propuesta, el debate compara varias).
+
+## Flags
+
+```
+[descripción]          La propuesta de cambio a analizar (obligatoria; si falta, preguntar)
+--scope <glob>         Archivos relevantes para grounding (default: derivar del texto)
+--adversarial          Set de personas atacantes en vez del set default
+--presupuesto N        Máximo de hallazgos totales (default: 40 → 8 por persona)
+--chain planear-fase   Al terminar, ofrecer arrancar /swl:planear-fase con los hallazgos como contexto
+```
+
+## Paso 0 — Carga y configuración
+
+```
+Skill("proceso-debate-adversarial")
+```
+
+El skill define el protocolo COLD START, el anti-herd check y el formato de
+síntesis. Las definiciones de personas viven en
+`habilidades/proceso-debate-adversarial/recursos/personas.md`.
+
+Confirmar con el usuario: propuesta, scope, set de personas, presupuesto.
+
+## Paso 1 — Reconocimiento del codebase
+
+Construir el paquete de conocimiento que recibirá CADA persona (idéntico para
+todas): descripción de la propuesta + inventario de archivos del scope +
+dependencias relevantes + superficie de API afectada + cobertura de tests del
+área. Usar `code-review-graph` si está disponible (blast radius, callers);
+si no, Grep/Glob dirigidos. Máximo ~1,500 tokens — las personas analizan, no
+exploran.
+
+## Paso 2 — Análisis en frío (5 invocaciones Agent independientes)
+
+Por cada persona, UNA invocación del Agent tool (general-purpose o el agente
+afín al dominio) con prompt autocontenido:
+
+```
+Eres [persona] — [enfoque de recursos/personas.md].
+Propuesta: [descripción]
+Contexto del codebase: [paquete del Paso 1]
+Tu tarea: encuentra hasta [presupuesto/5] problemas que esta propuesta
+causaría, desde tu perspectiva. Por cada uno: título, severidad
+(crítico/alto/medio/bajo), confianza 0-100%, archivo:línea si aplica,
+recomendación concreta. Preguntas guía: [de la persona]. Red flags: [de la
+persona]. NO incluyas elogios ni evaluación general — solo hallazgos.
+```
+
+Las 5 invocaciones pueden correr en paralelo. NUNCA pasar el output de una
+persona a otra — el aislamiento es el mecanismo del comando.
+
+## Paso 3 — Síntesis con anti-herd check
+
+Aplicar el protocolo de síntesis del skill:
+
+1. Deduplicar (mismo archivo:línea + mismo problema → fusionar, severidad más alta gana).
+2. Registrar disensos (dos personas en desacuerdo → ambas posturas visibles).
+3. **Anti-herd check**: si todas las personas coinciden en el hallazgo top,
+   generar explícitamente ≥1 contraargumento antes de aceptarlo.
+4. Rankear: `severidad × confianza promedio × número de personas que coinciden`.
+
+## Paso 4 — Reporte y persistencia
+
+Persistir en `.planning/loops/predecir-[timestamp]/` con
+`hooks/lib/loop-telemetry.js` (tipo `predecir`, columnas `iteracion,
+timestamp, hallazgo, severidad, confianza, personas, archivo_linea`; una fila
+por hallazgo consensuado) + `escribirHandoff` con `source: 'swl:predecir'`,
+`findings` rankeados y `config: {propuesta, scope}`.
+
+Reportar al usuario:
+
+```
+=== Predicción — [propuesta resumida] ===
+Personas: [set] | Hallazgos brutos: N | Tras dedup: M
+
+## Top hallazgos (rankeados)
+| # | Hallazgo | Severidad | Confianza | Acuerdo | archivo:línea | Recomendación |
+
+## Disensos registrados
+- [persona X sostiene A; persona Y sostiene B — evidencia de cada una]
+
+## Veredicto del panel
+[PROCEDER | PROCEDER CON AJUSTES (lista) | REPLANTEAR (razón)]
+```
+
+## Paso 5 — Encadenamiento (si `--chain planear-fase`)
+
+Ofrecer arrancar `/swl:planear-fase` indicando el directorio del handoff. El
+planificador incorpora los hallazgos `crítico`/`alto` como restricciones del
+PLAN.md — cada uno se atiende con una tarea o se descarta con justificación
+explícita (nunca silenciosamente).
+
+## Reglas de comportamiento
+
+- NUNCA compartir contexto entre personas — una invocación Agent por persona.
+- NUNCA omitir el anti-herd check cuando hay unanimidad.
+- Los hallazgos con archivo:línea citan código REAL verificado en el Paso 1 —
+  regla `verificar-citas-normativas.md § Familia 2` aplica al propio output.
+- El comando NO modifica código — produce análisis. Implementar es del flujo
+  planear → ejecutar.
+- Con 0 hallazgos crítico/alto: decirlo claramente y no inflar hallazgos
+  menores para justificar el costo del panel.

package/comandos/swl/reflect-skills.md

@@ -6,7 +6,7 @@ allowed_tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
 
 # /swl:reflect-skills — Descubrimiento de skills emergentes
 
-Analiza los archivos JSONL del historial de Claude Code (`~/.claude/projects/<proyecto>/*.jsonl`) y la cola de feedback del usuario (`.planning/evolucion/feedback-queue.jsonl`) para detectar intenciones repetidas que podrían formalizarse como skills, comandos o agentes nuevos del sistema SWL.
+Analiza los archivos JSONL del historial de Claude Code (`~/.claude/projects/<proyecto>/*.jsonl`) y la cola de feedback del usuario (`.planning/evolution/feedback-queue.jsonl`) para detectar intenciones repetidas que podrían formalizarse como skills, comandos o agentes nuevos del sistema SWL.
 
 Complementa a `/swl:aprender` (que trabaja sobre la sesión actual) y a `/swl:evolucionar` (que opera sobre metadatos de agentes/skills existentes). Este comando mira el **historial acumulado** y propone componentes emergentes basándose en la frecuencia real de uso.
 
@@ -41,7 +41,7 @@ Parámetros:
 
 El script produce:
 - Reporte textual en stdout
-- Archivo estructurado en `.planning/evolucion/reflect-skills-report.json`
+- Archivo estructurado en `.planning/evolution/reflect-skills-report.json`
 
 ### Paso 2 — Leer y clasificar los candidatos
 

package/comandos/swl/salud.md

@@ -290,7 +290,7 @@ SWL_AUDIT_FRAMEWORKS=1 npx -y @saulwade/swl-ses@latest audit-coverage-frameworks
 npx -y @saulwade/swl-ses@latest audit-coverage-frameworks --save
 ```
 
-Persiste en `.planning/evolucion/cobertura-frameworks.json` para comparación
+Persiste en `.planning/evolution/cobertura-frameworks.json` para comparación
 histórica tras incorporar nuevos skills de seguridad.
 
 Si `SWL_AUDIT_FRAMEWORKS` no está definida, este paso se omite sin mensaje

package/comandos/swl/verificar.md

@@ -137,18 +137,30 @@ Verifica que los mensajes de commit siguen la convención del proyecto (si está
 
 Delega al agente `revisor-codigo-swl` para revisión de código en profundidad.
 
+**Presupuesto de contexto (anti-thrashing):** el subagente hereda `CLAUDE.md` +
+reglas globales del proyecto; en proyectos rule-heavy eso consume buena parte de
+su ventana antes de leer código (causa de autocompact thrashing con 0 tokens
+útiles, observado 2026-06-05). Para evitarlo:
+- Pasa al agente SOLO el diff / los archivos del alcance — nunca "revisa el proyecto".
+- Instruye leer los archivos del alcance PRIMERO y cargar skills bajo demanda (solo
+  si el alcance lo amerita), no al inicio.
+- Si el alcance > ~15 archivos o > ~2000 LOC, divídelo en lotes y delega uno por
+  invocación (cada subagente arranca con ventana limpia).
+
 **Instrucción al agente revisor-codigo-swl:**
 
 ```
-Revisa el código de la Fase N del proyecto [nombre].
+Revisa SOLO los archivos del alcance de la Fase N del proyecto [nombre].
+No explores el codebase completo: tu ventana ya hereda CLAUDE.md + reglas
+globales; lee primero los archivos del alcance para no saturarla.
 
 Archivos a revisar (en orden de prioridad):
-[lista del RESUMEN.md]
+[lista del RESUMEN.md / git diff del alcance]
 
-Lee también:
-- .planning/fases/0N-CONTEXTO.md (para entender requisitos)
-- .planning/fases/0N-PLAN.md (para entender qué se debía hacer)
-- CLAUDE.md (para convenciones del proyecto)
+Lee también (solo lo necesario, bajo demanda):
+- .planning/fases/0N-CONTEXTO.md (requisitos)
+- .planning/fases/0N-PLAN.md (qué se debía hacer)
+(CLAUDE.md ya está en tu contexto heredado — no lo releas.)
 
 Para cada archivo revisado, verifica:
 
@@ -391,7 +403,38 @@ El VERIFICACION.md reportado al usuario al final del loop incluye una sección a
 - Estado persistido: `.planning/fases/0N-converge-run-[timestamp].json`
 ```
 
-### 4.6.7 — Protocolo `--ci-aware` (Señal D)
+### 4.6.7 — Telemetría de loop (obligatoria en `--until-converge`)
+
+Además del estado estructurado de 4.6.5, cada corrida del loop registra su
+trayectoria en el formato estándar de telemetría de loops
+(`hooks/lib/loop-telemetry.js`), que habilita: inyección de estado por el hook
+`contexto-iteracion.js` (anti-context-rot en sesiones largas), detección de
+plateau, y lectura por `/swl:metricas`.
+
+Al iniciar el loop (antes de la pasada 1):
+
+```bash
+node -e "const lt=require('./hooks/lib/loop-telemetry');const r=lt.iniciarCorrida({tipo:'verificar',direccion:'lower_is_better',config:{fase:'0N',maxIter:5}});console.log(r.dir)"
+```
+
+Tras CADA pasada, registrar una fila (métrica = hallazgos CRÍTICO+ALTO+MAYOR):
+
+```bash
+node -e "const lt=require('./hooks/lib/loop-telemetry');lt.registrarIteracion('<dir>',{iteracion:N,metrica:M,delta:D,estado:'keep',descripcion:'pasada N: X criticos, Y altos, Z mayores'})"
+```
+
+Al cerrar el loop (cualquier señal de salida), escribir el handoff:
+
+```bash
+node -e "const lt=require('./hooks/lib/loop-telemetry');lt.escribirHandoff('<dir>',{source:'swl:verificar',status:'COMPLETO',findings:[/* hallazgos MEDIO/BAJO residuales */],config:{fase:'0N'}})"
+```
+
+`status` según la señal: A/D → `COMPLETO`, B → `INTERRUMPIDO`, C → `ACOTADO`.
+Si `analizarTrayectoria()` reporta plateau antes de `--max-iter`, tratarlo como
+señal C anticipada: seguir iterando sin mejora de métrica quema tokens sin
+reducir hallazgos.
+
+### 4.6.8 — Protocolo `--ci-aware` (Señal D)
 
 Cuando `--ci-aware` está activo, el bucle de convergencia se extiende con un gate adicional ANTES de declarar Señal A como cierre definitivo:
 

package/habilidades/ai-runtime-security/SKILL.md

@@ -123,12 +123,12 @@ Checklist para cualquier aplicación LLM en producción:
 - [ ] Canary token en system prompt + validación en output (capa 2)
 - [ ] Tool whitelist por agente documentada en frontmatter (capa 3)
 - [ ] Confirmación humana para acciones irreversibles (capa 3)
-- [ ] Logs de intentos detectados en `.planning/auto-evolucion/agentes.jsonl` con campo `tipo_fallo: prompt_injection`
+- [ ] Logs de intentos detectados en `.planning/auto-evolution/agentes.jsonl` con campo `tipo_fallo: prompt_injection`
 
 ## Gotchas / Errores comunes no obvios
 
 - **Confiar solo en regex**: los atacantes reescriben payloads trivialmente (sinónimos, ofuscación base64, division de strings, caracteres Unicode similares). Causa: las firmas son conocidas y públicas; cualquier evasión simple las burla. Solución: combinar siempre capa 1 con capa 2 + capa 3; nunca tratar la detección de la capa 1 como suficiente. Si el regex pasa pero el heurístico marca anomalía estructural, escalar a clasificador o a humano.
-- **Ignorar indirect injection porque "los usuarios son confiables"**: el input legítimo del usuario puede contener contenido externo no confiable (URL que se fetchea, archivo subido, documento RAG). Causa: el autor del payload no es quien interactúa — es quien puso el contenido en la ruta del agente. Solución: tratar TODO contenido externo como datos, nunca como instrucciones; auditar especialmente ingesta de URLs, fetching de páginas web, y documentos en pipelines RAG.
+- **Ignorar indirect injection porque "los usuarios son confiables"**: el input legítimo del usuario puede contener contenido externo no confiable (URL que se fetchea, archivo subido, documento RAG). Causa: el autor del payload no es quien interactúa — es quien puso el contenido en la ruta del agente. Solución: tratar todo el contenido externo como datos, nunca como instrucciones; auditar especialmente ingesta de URLs, fetching de páginas web, y documentos en pipelines RAG.
 - **Tratar el clasificador como oráculo binario**: `protectai/deberta-v3-base-prompt-injection-v2` es un modelo, no una verdad absoluta. Tiene falsos positivos y falsos negativos. Causa: los clasificadores son entrenados con datasets específicos; inputs legítimos de dominios no representados en el training pueden marcarse. Solución: usar el score como una señal entre varias, no como veredicto; calibrar el umbral contra un dataset propio de inputs legítimos antes de desplegar.
 - **Canary tokens estáticos en el código**: incluir el mismo canary en repo público o en logs permite al atacante conocerlo y evitar filtrarlo. Causa: si el canary es predecible, el atacante lo filtra del output antes de devolverlo. Solución: generar canary por sesión o por deploy, nunca hardcodeado en el repo visible; rotarlo al menos por release.
 - **Confiar en el frontmatter `tools:` del agente como único control**: el frontmatter es declaración leída por Claude Code, pero un agente con `tools: [Read]` todavía puede pedir `Bash` en su output y el runtime podría ejecutarlo si no hay enforcement. Causa: pre-aprobación ≠ restricción real. Solución: verificar que el permission mode de Claude Code o los hooks PreToolUse enforsan la restricción; no confiar solo en la declaración.

package/habilidades/angular-moderno/SKILL.md

@@ -1,7 +1,12 @@
 ---
 name: angular-moderno
 description: Angular v17+/v20+. Signals, standalone components, OnPush, host bindings, nueva sintaxis de control flow (@if/@for/@switch), defer blocks y patrones modernos.
-version: "1.0.0"
+version: "1.0.1"
+evolved: true
+evolved-from: "1.0.0"
+evolved-at: "2026-06-04"
+evolved-by: "evolucionar"
+evolved-note: "PE-009 patrón Angular 19+ ErrorHandler custom con provideBrowserGlobalErrorListeners (NO listeners manuales window.onerror). Origen: OIC v1.5 Slice 6 2026-06-04."
 herramientasPermitidas: [Read]
 exclusiones:
   - "No cargar para patrones Angular avanzados (zoneless, SSR, Resource API, interceptores funcionales) — para eso cargar `angular-avanzado`."
@@ -184,3 +189,41 @@ Para ejemplos completos de host bindings con clases dinámicas, services store c
 **`input.required<T>()` accedido fuera del contexto de renderizado (en `constructor`) lanza error de runtime**: `this.factura()` dentro del `constructor` de un componente que usa `input.required<Factura>()` lanza `NG0950: Input is required but no value is available yet`. Causa: los inputs signal no tienen valor hasta que Angular completa la inicialización del componente. Fix: acceder a inputs en `ngOnInit`, en `computed()`, o en métodos del template — nunca en el constructor.
 
 **`takeUntilDestroyed()` usado fuera del contexto de inyección lanza error**: `takeUntilDestroyed()` sin argumentos requiere un `DestroyRef` del contexto de inyección activo — si se llama dentro de un callback asíncrono (como `.then()` o `setTimeout`), el injection context ya no está activo. Causa: `inject()` solo funciona en contextos de inyección síncronos. Fix: capturar `DestroyRef` en el constructor con `private destroyRef = inject(DestroyRef)` y pasarlo explícitamente: `takeUntilDestroyed(this.destroyRef)`.
+
+**Para captura global de errores runtime (window.onerror + unhandledrejection), usar `ErrorHandler` custom con `provideBrowserGlobalErrorListeners` — NO `window.addEventListener('error', ...)` manual** (Angular 19+; patrón portable OIC v1.5 2026-06-04): Angular 19+ provee `provideBrowserGlobalErrorListeners()` que ya registra los listeners nativos. Para reportar errores no controlados al backend (Sentry-style, audit handler, logs centralizados), proveer un `ErrorHandler` custom — listeners manuales duplican el registro y rompen la integración con el ciclo de DI/zone de Angular.
+
+```typescript
+// app.config.ts
+import { ApplicationConfig, ErrorHandler, provideBrowserGlobalErrorListeners } from '@angular/core';
+
+export const appConfig: ApplicationConfig = {
+  providers: [
+    provideBrowserGlobalErrorListeners(),                            // 1. Listeners nativos
+    { provide: ErrorHandler, useClass: GlobalErrorHandler },         // 2. Tu handler custom
+    // ...
+  ],
+};
+
+// global-error-handler.service.ts
+@Injectable({ providedIn: 'root' })
+export class GlobalErrorHandler implements ErrorHandler {
+  private readonly reporter = inject(ErrorReporterService);
+
+  handleError(error: unknown): void {
+    try {
+      this.reporter.reportarErrorGlobal(error, 'global-error-handler');
+    } catch {
+      // Silenciar fallos del reporter — un handler global NUNCA debe propagar.
+    }
+    console.error(error);  // Preservar visibilidad en DevTools.
+  }
+}
+```
+
+**Causa**: con `provideBrowserGlobalErrorListeners` activo, Angular ya escucha `window.onerror`/`unhandledrejection` y los enruta a `ErrorHandler.handleError()`. Registrar listeners manuales propios duplica el callback (cada error se reporta dos veces) y se pierde la integración con el lifecycle Angular (zone tracking, DI context). **Fix**: usar EXCLUSIVAMENTE el `ErrorHandler` custom + `provideBrowserGlobalErrorListeners`.
+
+**Reglas del handler**:
+- `try/except` agresivo: el reporter NUNCA debe propagar al `handleError` (riesgo de recursión si el propio POST de reporte falla).
+- Delegar a `console.error(error)` para preservar DevTools (no silenciar para devs).
+- El reporter debe tener throttle propio (ej: 10 eventos/5s) y silenciar respuestas esperadas (401/403/404/429) — los detalles del reporter viven en su propio service, no en el `ErrorHandler`.
+- Anti-bucle: el `ErrorReporterInterceptor` (si existe) debe excluir llamadas al propio endpoint POST de reportes.

package/habilidades/auto-evolucion-protocolo/SKILL.md

@@ -194,7 +194,7 @@ ver [recursos/referencia-completa.md](recursos/referencia-completa.md).
 ## Parser de señales de fricción (v1.1)
 
 El hook `hooks/auto-evolucion.js` (SubagentStop) alimenta el log
-`.planning/auto-evolucion/agentes.jsonl` y emite *nudges* hacia
+`.planning/auto-evolution/agentes.jsonl` y emite *nudges* hacia
 `auto-evolucion-swl` cuando detecta umbrales cruzados. Este skill define
 **qué cuenta como fricción** para que el agente tenga criterio uniforme al
 interpretar el log.
@@ -233,7 +233,7 @@ Al invocar `auto-evolucion-swl` o `/swl:evolucionar <agente>`:
 
 1. **Leer el log filtrado por agente:**
    ```bash
-   grep "\"agente\":\"<nombre>\"" .planning/auto-evolucion/agentes.jsonl | tail -50
+   grep "\"agente\":\"<nombre>\"" .planning/auto-evolution/agentes.jsonl | tail -50
    ```
 
 2. **Cuantificar las 6 categorías** (fallo duro, run vacío, trivial recurrente,

package/habilidades/autoresearch/SKILL.md

@@ -7,7 +7,9 @@ description: >
   y mejorar skills hasta 95%+ de score. Cargar cuando se quiera mejorar la calidad
   de un skill o agente existente de forma medible y automatizada, o cuando
   auto-evolucion-swl necesite una metodología de mejora iterativa con scoring.
-version: "1.0.0"
+  La disciplina del loop (mutación atómica, keep/revert, condiciones de salida)
+  aplica también al modo --codigo de /swl:autoresearch sobre código del usuario.
+version: "1.1.0"
 herramientasPermitidas: [Read, Bash]
 exclusiones:
   - "No cargar para mejorar el output de una sola sesión; el loop de autoresearch opera sobre el SKILL.md del skill, no sobre outputs puntuales."
@@ -210,6 +212,18 @@ Mutaciones KEEP: [N] | Mutaciones REVERT: [N]
 | 3 reverts consecutivos | **Estancamiento** — cambiar estrategia de mutación |
 | Score baja 2 rounds seguidos | **Degradación** — revertir al mejor score alcanzado |
 
+## Variante: loop sobre código del usuario (modo `--codigo`)
+
+La misma disciplina aplica cuando el objetivo es código del proyecto en lugar
+de un SKILL.md: el checklist se sustituye por un **comando Verify numérico**
+(mutation score, cobertura, conteo de errores, latencia) y un **Guard** de
+regresión (la suite). El protocolo completo del modo vive en
+`comandos/swl/autoresearch.md § Modo --codigo`; la telemetría de iteraciones
+en `hooks/lib/loop-telemetry.js` (corridas en `.planning/loops/`); las
+métricas de mutación en `Skill("calidad-mutation-testing")`. Las reglas
+invariantes son las mismas: UNA mutación por round, revert sin excepciones si
+la métrica no mejora, salida por plateau.
+
 ## Integración con auto-evolución SWL
 
 ```

package/habilidades/benchmark-memoria/SKILL.md

@@ -122,7 +122,7 @@ node scripts/benchmark-memoria.js --verbose
 ### Tracking histórico opcional
 
 Si se setea `SWL_BENCHMARK_PERSIST=1`, el benchmark escribe el resumen
-agregado a `.planning/evolucion/benchmark-memoria.jsonl` (append-only)
+agregado a `.planning/evolution/benchmark-memoria.jsonl` (append-only)
 para detectar regresión entre releases:
 
 ```bash
@@ -131,7 +131,7 @@ SWL_BENCHMARK_PERSIST=1 node scripts/benchmark-memoria.js
 
 Comparar entre releases:
 ```bash
-tail -5 .planning/evolucion/benchmark-memoria.jsonl | jq -c '{ts: .timestamp, r5: .promedio.recall_at_5}'
+tail -5 .planning/evolution/benchmark-memoria.jsonl | jq -c '{ts: .timestamp, r5: .promedio.recall_at_5}'
 ```
 
 ---

package/habilidades/calidad-mutation-testing/SKILL.md

@@ -0,0 +1,170 @@
+---
+name: calidad-mutation-testing
+description: >
+  Mutation testing: medir la calidad real de una suite de tests inyectando
+  mutantes (cambios sintácticos pequeños) en el código y verificando que los
+  tests los maten. Cubre herramientas por stack (Stryker, mutmut, cargo-mutants,
+  PIT, Stryker.NET, Infection), interpretación de mutantes sobrevivientes,
+  modo incremental para que el costo sea viable, y uso del mutation score como
+  métrica Verify/Guard en loops de autoresearch o como gate opcional de
+  tdd-qa-swl. Cargar cuando la cobertura de líneas es alta pero se sospecha de
+  asserts débiles, al endurecer la suite de un módulo crítico, o al configurar
+  el gate de mutación en CI.
+version: "1.0.0"
+herramientasPermitidas: [Read, Bash, Grep, Glob]
+exclusiones:
+  - "No cargar si la suite no está verde y estable — el mutation testing presupone tests deterministas que pasan; con tests flaky el score es ruido."
+  - "No cargar para subir cobertura de líneas — eso es tdd-workflow; la mutación mide calidad de asserts, no cantidad de tests."
+  - "No cargar en proyectos sin tests — primero tdd-qa-swl construye la suite; mutar sin tests produce 100% de sobrevivientes sin información."
+evolvable: true
+---
+# Mutation Testing — La Suite que Vigila a la Suite
+
+La cobertura de líneas responde "¿qué código ejecutan los tests?". El mutation
+testing responde la pregunta importante: **"¿los tests detectarían un bug?"**.
+Una suite con 90% de cobertura y asserts débiles pasa el gate de `pruebas.md`
+sin proteger nada — los mutantes sobrevivientes lo exponen.
+
+**Principio**: un test que no mata mutantes documenta ejecución, no comportamiento.
+
+## Cuándo cargar este skill
+
+- Módulo crítico (pagos, auth, cálculo) con cobertura alta pero bugs que se
+  filtran a producción — sospecha de asserts débiles.
+- Cerrar el ciclo TDD estilo Uncle Bob: spec → tests → código → revisión →
+  **mutación** como verificación final de la suite.
+- Configurar mutation score como métrica de un loop `/swl:autoresearch --codigo`
+  o como gate opcional en CI.
+- Auditar la suite que entrega `tdd-qa-swl` antes de declarar una fase verde.
+
+## Cómo funciona
+
+1. La herramienta genera **mutantes**: copias del código con un cambio mínimo
+   (`>` → `>=`, `+` → `-`, borrar una llamada, `true` → `false`).
+2. Corre la suite contra cada mutante.
+3. Clasifica: **muerto** (algún test falló — bien), **sobreviviente** (la suite
+   pasó con el bug inyectado — gap real), **timeout** (cuenta como muerto),
+   **no cubierto** (ningún test lo ejecuta — gap de cobertura clásico).
+
+```
+mutation score = mutantes muertos / (mutantes totales − equivalentes) × 100
+```
+
+## Herramientas por stack
+
+Antes de instalar, verificar versión vigente con Context7
+(regla `usar-context7.md`) — los nombres de paquete cambian entre majors.
+
+| Stack | Herramienta | Comando típico | Score en JSON |
+|-------|------------|----------------|---------------|
+| JS/TS | Stryker (`@stryker-mutator/core`) | `npx stryker run` | `reports/mutation/mutation.json` → `.thresholds` / score en summary |
+| Python | `mutmut` | `mutmut run && mutmut results` | `mutmut junitxml` o parsear `mutmut results` |
+| Python (alterno) | `cosmic-ray` | `cosmic-ray init/exec/dump` | `cr-report --json` |
+| Rust | `cargo-mutants` | `cargo mutants` | `mutants.out/outcomes.json` |
+| Java/Kotlin | PIT (`pitest`) | `mvn org.pitest:pitest-maven:mutationCoverage` | `target/pit-reports/mutations.xml` |
+| C#/.NET | Stryker.NET (`dotnet-stryker`) | `dotnet stryker` | `StrykerOutput/**/mutation-report.json` |
+| PHP | Infection | `vendor/bin/infection` | `infection-log.json` → MSI |
+| Go | `gremlins` | `gremlins unleash` | salida estructurada con `--output` |
+
+## Hacer viable el costo — modo incremental SIEMPRE
+
+Mutar el proyecto completo es O(mutantes × duración de suite). En un repo
+mediano son horas. Reglas para que sea operable:
+
+- **Mutar solo lo que cambió**: Stryker `--since`/modo incremental, `mutmut`
+  con `--paths-to-mutate`, `cargo mutants --in-diff <(git diff main)`. El gate
+  de PR muta el diff, no el repo.
+- **Acotar al módulo crítico**: configurar `mutate:` solo sobre
+  `src/pagos/**`, no sobre todo `src/`. El score global de un repo grande es
+  una métrica vanidosa; el score del módulo de dinero es accionable.
+- **Suite rápida primero**: si la suite tarda >2 min, mutar solo con los tests
+  unitarios del módulo (los runners permiten filtrar la suite que ejecutan).
+- **Paralelizar**: todos los runners soportan concurrencia
+  (`--concurrency`, `--jobs`); default razonable: núcleos − 1.
+
+## Interpretar mutantes sobrevivientes
+
+Cada sobreviviente es una de tres cosas — diagnosticar antes de actuar:
+
+| Diagnóstico | Señal | Acción |
+|-------------|-------|--------|
+| **Assert débil** | el test ejecuta la línea pero no verifica el resultado mutado | Endurecer el assert (caso típico: verifica que no lanza, no el valor) |
+| **Test faltante** | ningún test cubre el comportamiento de esa rama | Escribir test de frontera dirigido al mutante (`tdd-qa-swl`) |
+| **Mutante equivalente** | el mutante no cambia el comportamiento observable (ej: optimización interna) | Excluirlo/anotarlo — NO escribir un test artificial para matarlo |
+
+Anti-patrón crítico: escribir tests que asertan detalles de implementación
+solo para matar mutantes — eso acopla la suite y degrada el refactor. El
+mutante manda la pregunta; el test responde al **comportamiento**.
+
+## Umbrales recomendados
+
+| Contexto | Score objetivo | Justificación |
+|----------|---------------|---------------|
+| Módulo crítico (dinero, auth, cálculo regulatorio) | ≥ 85% | Un bug aquí cuesta más que el CI lento |
+| Lógica de negocio estándar | ≥ 70% | Equilibrio costo/valor |
+| Glue code, configs, controllers delgados | sin gate | El esfuerzo no paga; cubrir con tests de integración |
+
+No imponer un score global de repo: produce esfuerzo uniforme sobre código de
+valor desigual. Gates por módulo, declarados en la config del runner.
+
+## Uso como métrica en loops SWL
+
+El mutation score es la métrica ideal para `/swl:autoresearch --codigo` porque
+es numérica, determinista y su Guard natural es la propia suite:
+
+```
+Goal: subir mutation score de src/pagos/ de 62% a 85%
+Scope: tests/pagos/**
+Metric: mutation score (higher_is_better)
+Verify: npx stryker run --mutate "src/pagos/**" --incremental && <extraer score del JSON>
+Guard: npm test (la suite completa sigue verde)
+```
+
+Cada iteración: agregar/endurecer UN test → correr Verify → keep si el score
+sube y el Guard pasa. Registrar con `hooks/lib/loop-telemetry.js`.
+
+**Gate opcional en tdd-qa-swl**: tras alcanzar cobertura ≥80%, correr mutación
+incremental sobre el diff de la fase; sobrevivientes con diagnóstico "assert
+débil" o "test faltante" se atienden antes del cierre (regla
+`arreglar-al-detectar.md`). Es opt-in: requiere runner instalado y suite <2 min.
+
+## Cuándo NO cargar
+
+- Suite roja o flaky — primero estabilizar (`pruebas.md § deterministas`); el
+  mutation testing amplifica el ruido de tests no deterministas.
+- Prototipo o spike de descarte — el costo del setup no se recupera.
+- Presupuesto de CI ya saturado — correr mutación local/nightly, no por PR,
+  hasta resolver el presupuesto.
+
+## Gotchas / Errores comunes no obvios
+
+- **El score baja al agregar código nuevo bien testeado**: el denominador
+  crece con mutantes del código nuevo; si el módulo viejo tenía deuda, el
+  score agregado oscila. Causa: medir score global en vez de por módulo/diff.
+  Solución: gates incrementales (`--since`, `--in-diff`) — el código nuevo se
+  evalúa contra su propio diff.
+- **Timeouts contados como éxito inflan el score**: un mutante que cuelga la
+  suite cuenta como "muerto" aunque ningún assert lo detectó. Si el módulo
+  tiene loops sensibles, revisar el desglose `timeout` vs `killed` antes de
+  celebrar — un ratio de timeouts >10% amerita bajar el timeout factor.
+- **Mutación sobre código generado**: mutar archivos generados (protobuf,
+  cliente OpenAPI, migraciones) quema horas sin información. Excluirlos
+  explícitamente en la config del runner desde el día uno.
+- **mutmut y el cache stale**: `mutmut` cachea resultados en `.mutmut-cache`;
+  tras un refactor grande el cache puede reportar resultados de código que ya
+  no existe. Ante números inverosímiles: borrar el cache y re-correr.
+- **Stryker incremental tras rebase**: el archivo `.stryker-tmp`/incremental
+  referencia commits que el rebase reescribió — el modo incremental se
+  degrada a corrida completa sin avisar. Presupuestar la primera corrida
+  post-rebase como completa.
+
+## Anti-patrones
+
+- **Tests escritos para matar mutantes, no para verificar comportamiento** —
+  acoplan la suite a la implementación.
+- **Score global de repo como KPI de equipo** — métrica vanidosa; gates por
+  módulo crítico.
+- **Correr mutación completa en cada PR** — CI de horas; incremental por diff
+  en PR, completa nightly.
+- **Ignorar el desglose y mirar solo el porcentaje** — los sobrevivientes
+  individuales son la información; el score es solo el resumen.