@saulwade/swl-ses 1.8.0 → 1.9.0

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/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/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/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/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.

package/habilidades/changelog-generator/scripts/parse-commits.js

@@ -51,7 +51,7 @@ const { execSync } = require('node:child_process');
  *   refactor(hooks/lib): split evolution-tracker
  *   chore(release): bump version
  */
-const RE_CONVENTIONAL = /^(feat|fix|perf|refactor|docs|style|test|ci|build|chore|revert|evolucion)(?:\(([^)]+)\))?(!)?:\s*(.+)$/;
+const RE_CONVENTIONAL = /^(feat|fix|perf|refactor|docs|style|test|ci|build|chore|revert|evolucion|evolve)(?:\(([^)]+)\))?(!)?:\s*(.+)$/;
 
 /** Mapa tipo CC → categoría Keep a Changelog en es-MX. */
 const CATEGORIAS = Object.freeze({
@@ -61,6 +61,7 @@ const CATEGORIAS = Object.freeze({
   refactor:  'Cambios internos',
   revert:    'Reversiones',
   evolucion: 'Evoluciones de skills/agentes',
+  evolve:    'Evoluciones de skills/agentes',
   docs:      'Mantenimiento',
   style:     'Mantenimiento',
   test:      'Mantenimiento',

package/habilidades/checklist-seguridad/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: checklist-seguridad
 description: Checklist de seguridad basado en OWASP Top 10 + seguridad de agentes autónomos (A11). Cubre inyección, autenticación, exposición de datos, control de acceso, configuración insegura, XSS, deserialización, componentes vulnerables, logging y agencia excesiva de IA. Produce reporte con hallazgos y remediaciones.
-version: "1.1.1"
+version: "1.2.0"
 evolved: true
 evolved-from: "1.1.0"
 evolved-at: "2026-05-04"
@@ -297,6 +297,34 @@ grep -rn "\.env\|credentials\|secret" --include="*.md" agentes/ | head -10
 
 ---
 
+## Modo cobertura — STRIDE + score compuesto (auditorías iterativas)
+
+Para auditorías en profundidad (no el checklist de un solo PR), complementar
+el barrido OWASP con el modelo **STRIDE** y medir la auditoría con un **score
+compuesto de cobertura** — convierte "auditamos seguridad" en un número
+verificable y permite usar la auditoría como loop iterativo:
+
+```
+score = (categorías_OWASP_auditadas / 10) × 50
+      + (categorías_STRIDE_auditadas / 6) × 30
+      + min(hallazgos_únicos, 20)
+```
+
+Score perfecto = 100 (OWASP completo + STRIDE completo + 20 hallazgos). Cada
+hallazgo se etiqueta con AMBAS taxonomías (`OWASP: A03, STRIDE: T`). Reportar
+la cobertura cada 5 iteraciones:
+
+```
+OWASP: [A01✓ A02✓ A03✗ ...] 4/10 | STRIDE: [S✓ T✓ R✗ I✓ D✗ E✗] 3/6 | Score: 48
+```
+
+Tabla STRIDE→OWASP, qué buscar por categoría, y rotación de personas red-team
+(Adversario, Supply Chain, Insider, Infra — definidas en
+`habilidades/proceso-debate-adversarial/recursos/personas.md`) en
+[recursos/stride-cobertura.md](recursos/stride-cobertura.md). Registrar las
+iteraciones de la auditoría con `hooks/lib/loop-telemetry.js` (tipo
+`seguridad`, direccion `higher_is_better`, métrica = score compuesto).
+
 ## Gotchas / Errores comunes no obvios
 
 **El grep de búsqueda de secrets hardcodeados devuelve cero resultados pero hay credenciales en archivos de configuración YAML**: el patrón de búsqueda usa `password\s*=` (sintaxis Python), pero los archivos YAML usan `password:` (sin signo igual). Causa: las búsquedas de código están optimizadas para un lenguaje y pierden variantes de otro formato. Fix: expandir el patrón de búsqueda a `password[\s=:]+['\"][^'\"]{4,}` para capturar asignaciones en Python, YAML y JSON simultáneamente. Verificar también `docker-compose.yml`, `.env.example` y archivos de configuración de CI.

package/habilidades/checklist-seguridad/recursos/stride-cobertura.md

@@ -0,0 +1,60 @@
+# STRIDE — modelo de amenazas para el modo cobertura
+
+Complemento del checklist OWASP de `SKILL.md`. STRIDE clasifica por **tipo de
+amenaza** (qué quiere lograr el atacante); OWASP por **tipo de debilidad**
+(qué error del código lo permite). Auditar con ambas taxonomías cierra los
+huecos que cada una deja sola: repudio y DoS casi no aparecen en OWASP Top 10;
+componentes desactualizados (A06) no mapean limpio a STRIDE.
+
+## Las 6 categorías
+
+| Letra | Amenaza | Qué buscar | OWASP relacionadas |
+|-------|---------|-----------|--------------------|
+| **S**poofing | Suplantación de identidad | Auth débil, tokens predecibles, session fixation, falta de MFA | A07 |
+| **T**ampering | Modificación de datos | Input sin validar, falta de checks de integridad, inyección SQL/NoSQL, deserialización insegura | A03, A08 |
+| **R**epudiation | Acciones negables | Audit logs faltantes, transacciones sin firma, logs mutables, cambios de privilegio sin registro | A09 |
+| **I**nformation Disclosure | Fuga de información | Stack traces al cliente, logging verboso con PII, env vars expuestas, mensajes de error que revelan existencia de recursos | A01, A02, A05 |
+| **D**enial of Service | Ataques a disponibilidad | Queries sin cota ni paginación, rate limits faltantes, regex DoS (ReDoS), uploads sin límite de tamaño | A04 |
+| **E**levation of Privilege | Acceso no autorizado | Checks de authz faltantes, IDOR, rutas de escalación admin, confusión autenticación/autorización | A01, A04 |
+
+## Protocolo de auditoría iterativa con cobertura
+
+1. **Reconocimiento (una vez)**: mapear superficie de ataque — manifest de
+   dependencias, `.env.example`, Dockerfile, rutas de API, módulos de auth,
+   schemas de BD, configuración de CI/CD. Producir threat model inicial:
+   qué activos, qué trust boundaries, qué entry points.
+2. **Por iteración**: elegir el vector MENOS cubierto (OWASP sin auditar →
+   STRIDE sin auditar → profundizar en hallazgos existentes). Adoptar la
+   persona red-team que corresponde al vector (rotación: Adversario de
+   Seguridad → Supply Chain → Insider → Infraestructura — definiciones en
+   `habilidades/proceso-debate-adversarial/recursos/personas.md`).
+3. **Validar cada hallazgo**: evidencia archivo:línea + escenario de ataque
+   concreto + reproducción. Sin escenario de ataque no es hallazgo, es
+   especulación (regla `verificar-citas-normativas.md § Familia 2`).
+4. **Registrar**: fila en la corrida de `loop-telemetry` (columnas sugeridas:
+   `iteracion, timestamp, hallazgo, severidad, owasp, stride, archivo_linea`)
+   y recalcular el score compuesto.
+5. **Salida**: OWASP 10/10 + STRIDE 6/6 cubiertos, o max iteraciones (default
+   15), o plateau de hallazgos (3 iteraciones sin hallazgo nuevo).
+
+## Formato de hallazgo (obligatorio, 7 campos)
+
+```markdown
+### [Título de una línea]
+- **Severidad**: Crítico | Alto | Medio | Bajo | Informativo
+- **OWASP**: A01-A10
+- **STRIDE**: S | T | R | I | D | E
+- **Evidencia**: archivo:línea + escenario de ataque (sin especulación teórica)
+- **Reproducción**: pasos para disparar el problema
+- **Remediación**: fix concreto para ESTE código
+```
+
+## Severidad — criterios
+
+| Severidad | Criterio | Ejemplos |
+|-----------|----------|----------|
+| Crítico | Explotable remoto, sin auth, brecha de datos | RCE, SQL injection, bypass de auth |
+| Alto | Requiere algún acceso, impacto severo | XSS almacenado, IDOR, escalación de privilegios |
+| Medio | Impacto limitado o requiere interacción | CSRF, XSS reflejado, divulgación de info |
+| Bajo | Impacto mínimo | Headers faltantes, errores verbosos |
+| Informativo | Recomendación de hardening | Defensa en profundidad |

package/habilidades/css-moderno/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: css-moderno
 description: CSS moderno 2024+. Cubre Container Queries, CSS Layers (@layer), Nesting nativo, Custom Properties avanzadas, funciones min/max/clamp/color-mix, propiedades lógicas (block/inline), View Transitions API, animaciones performantes solo-compositor, dark mode patterns y anti-patrones críticos.
-version: "1.0.0"
+version: "1.1.0"
 herramientasPermitidas: [Read, Grep]
 exclusiones:
   - "No cargar para Tailwind CSS (clases utilitarias, @theme, cva, responsive) — para Tailwind cargar `tailwind-experto`."
@@ -164,3 +164,5 @@ Para ejemplos completos de Container Queries, CSS Layers, Nesting, Custom Proper
 **`container-type: inline-size` en un elemento con `position: absolute/fixed` puede no funcionar como contenedor de queries en algunos navegadores**: el contenedor crea un nuevo stacking context y en ciertos casos la query no se propaga correctamente a hijos con posicionamiento absoluto en Safari <17. Causa: bug de implementación en Safari relacionado con contenedores posicionados. Fix: en elementos con posicionamiento absoluto dentro de container queries, probar en Safari y usar un wrapper div sin posicionamiento como contenedor si hay problemas.
 
 **`clamp()` con `vw` en la función intermedia no escala correctamente en pantallas muy anchas si no se acota con `max()`**: `font-size: clamp(1rem, 2vw, 2rem)` en un monitor de 2560px da `2vw = 51.2px`, que es mayor que el máximo de `2rem = 32px` — el clamp lo atrapa pero el cálculo puede ser confuso al depurar. Causa: el valor de `vw` crece sin límite. Fix: entender que `clamp(min, preferido, max)` garantiza que el resultado siempre está entre min y max — el valor preferido puede ser cualquier expresión, incluso mayor que max, y el clamp simplemente retorna max en ese caso. Verificar los tres valores en los tamaños de viewport objetivo.
+
+**`var(--token)` NO resuelve cuando el valor lo consume JavaScript pintando a `<canvas>`**: las librerías que renderizan a canvas (Chart.js, OpenLayers, three.js/WebGL, o `ctx.fillStyle`/`strokeStyle`/`ctx.font` directos) NO reciben el contexto CSS del documento → el color sale negro o invisible **sin error en consola**. Causa: el canvas es un buffer de píxeles fuera del árbol CSS; la cascada y `getComputedStyle` no aplican al contexto 2D/WebGL — `var()` queda como string literal que el motor de canvas no interpreta. La frontera es: un color es `var(--x)` SOLO si lo consume CSS (`.css`/`.module.scss` o `style={{}}` sobre HTML); si lo consume JS pintando a canvas, debe ser hex/rgb concreto. Fix: pasar hex/rgb literal a esos objetos, con comentario anti-recurrencia (`// canvas: NO resuelve var()`). Si el color debe ser theme-aware, resolverlo primero en JS — `getComputedStyle(document.documentElement).getPropertyValue('--color-x').trim()` — y pasar el valor ya resuelto al canvas, re-leyéndolo al cambiar de tema.