@saulwade/swl-ses 1.8.0 → 2.0.0

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

@@ -0,0 +1,165 @@
+---
+name: calidad-contract-testing
+description: >
+  Contract testing: verificar que la implementación honra el contrato declarado
+  en la spec (Pydantic, Zod, JSON Schema, OpenAPI/AsyncAPI, protobuf) y que
+  consumidor y proveedor de una API no divergen. Cubre herramientas por stack
+  (schemathesis, Dredd, Pact, zod, Pydantic, openapi-typescript), las dos
+  familias de contract testing (schema-based property testing y
+  consumer-driven contracts), generación de tests desde el schema del PLAN, y
+  uso como gate de verificación. Cargar cuando el PLAN declara schemas como
+  parte de la spec, al integrar dos servicios con un contrato compartido, o al
+  detectar drift entre lo que la API documenta y lo que devuelve.
+version: "1.0.0"
+herramientasPermitidas: [Read, Bash, Grep, Glob]
+exclusiones:
+  - "No cargar para tests unitarios de lógica de negocio — eso es tdd-workflow; el contract testing verifica el límite spec↔implementación, no la lógica interna."
+  - "No cargar si no hay un contrato declarado (schema, OpenAPI, Pact) — sin contrato no hay nada que verificar; primero declarar el schema en el PLAN."
+  - "No cargar para validación de input en runtime — eso es responsabilidad del framework (Pydantic/Zod en el endpoint); el contract testing corre en CI, no en cada request."
+evolvable: true
+---
+# Contract Testing — La Spec que se Verifica a Sí Misma
+
+La cobertura responde "¿qué código ejecutan los tests?". El mutation testing,
+"¿los tests detectarían un bug?". El contract testing responde la pregunta del
+límite: **"¿la implementación honra el contrato que la spec promete?"**. Un
+endpoint con 90% de cobertura puede devolver un campo con el tipo equivocado,
+omitir uno requerido o aceptar un payload que el schema prohíbe — los tests
+unitarios no lo ven porque usan los mismos supuestos que el código.
+
+**Principio**: el schema declarado en el PLAN (Pydantic/Zod/JSON Schema/OpenAPI)
+ES parte de la spec. Un contrato que no se verifica es documentación que miente.
+
+## Cuándo cargar este skill
+
+- El PLAN de la fase declara schemas (Pydantic, Zod, JSON Schema, OpenAPI) como
+  entregable — esos schemas son contrato verificable, no decoración.
+- Integración de dos servicios (frontend↔backend, microservicio↔microservicio)
+  con un contrato compartido que ambos lados deben respetar.
+- Drift detectado: la API documenta un campo que ya no devuelve, o devuelve uno
+  no documentado; un cliente generado rompe tras un cambio de backend.
+- Configurar contract testing como paso de `/swl:verificar` o gate de `tdd-qa-swl`.
+
+## Las dos familias de contract testing
+
+| Familia | Pregunta | Cuándo |
+|---------|----------|--------|
+| **Schema-based / property testing** | ¿La API respeta su propio schema OpenAPI ante cualquier input válido? | API con spec OpenAPI; un solo equipo controla ambos lados |
+| **Consumer-driven contracts (CDC)** | ¿El proveedor sigue cumpliendo lo que cada consumidor concreto espera? | Múltiples consumidores, equipos separados, despliegue independiente |
+
+Schema-based es más barato (un solo artefacto, la spec) y cubre el 80% del valor
+en proyectos de un equipo. CDC paga su complejidad cuando hay equipos y
+despliegues independientes que pueden romperse mutuamente sin saberlo.
+
+## Cómo funciona (schema-based)
+
+1. El schema (OpenAPI/Pydantic/Zod) define el contrato: rutas, métodos, forma de
+   request y response, campos requeridos, tipos, constraints.
+2. La herramienta **genera casos** desde el schema (property-based: cientos de
+   payloads válidos e inválidos) y los lanza contra la API real.
+3. Verifica que cada response **conforme al schema**: status esperado, forma,
+   tipos, requeridos presentes, sin campos extra prohibidos.
+4. Reporta violaciones: el contrato dice X, la implementación devolvió Y.
+
+## 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 | Familia | Comando típico |
+|-------|------------|---------|----------------|
+| OpenAPI (cualquier lenguaje) | `schemathesis` | schema-based | `schemathesis run http://localhost:8000/openapi.json` |
+| OpenAPI (Node) | Dredd | schema-based | `dredd openapi.yaml http://localhost:3000` |
+| Python | Pydantic v2 (`model_validate`) | schema (límite) | validar request/response contra el modelo en el test |
+| JS/TS | Zod (`.parse`/`.safeParse`) | schema (límite) | parsear la response contra el schema en el test |
+| TS desde OpenAPI | `openapi-typescript` + tsc | schema (compile-time) | generar tipos y dejar que el compilador detecte drift |
+| Multi-equipo (poliglota) | Pact (`@pact-foundation/pact`, `pact-python`) | CDC | consumer genera pacto → provider lo verifica |
+| gRPC | `buf breaking` / protovalidate | schema-based | `buf breaking --against '.git#branch=main'` |
+
+## Generar tests desde el schema del PLAN
+
+Cuando `planear-fase` declara un schema como entregable, la tarea que lo
+implementa se verifica generando el contract test, no escribiéndolo a mano:
+
+```
+# OpenAPI + FastAPI: schemathesis deriva los casos del propio /openapi.json
+schemathesis run http://localhost:8000/openapi.json --checks all
+```
+
+```python
+# Pydantic como contrato en el test de integración:
+def test_endpoint_respeta_contrato():
+    # verifica: REQ-NN
+    r = client.get("/facturas/1")
+    FacturaResponse.model_validate(r.json())  # falla si la forma no conforma
+```
+
+```typescript
+// Zod como contrato del lado consumidor:
+const FacturaSchema = z.object({ id: z.number(), total: z.number(), vigencia: z.string() });
+const data = FacturaSchema.parse(await res.json()); // throw si el backend cambió la forma
+```
+
+## Umbrales y cuándo aplica el gate
+
+| Contexto | Gate | Justificación |
+|----------|------|---------------|
+| API pública o consumida por otro equipo | obligatorio: 0 violaciones de contrato | Un drift rompe consumidores en silencio |
+| Integración interna front↔back del mismo proyecto | recomendado: schema-based en CI | Barato con OpenAPI ya existente; atrapa el campo renombrado |
+| Endpoint interno sin consumidores externos | opcional | El esfuerzo de mantener pactos no paga |
+
+No imponer CDC donde schema-based basta: Pact con broker es infraestructura que
+solo paga con equipos y despliegues independientes.
+
+## Uso como gate de verificación
+
+En `/swl:verificar`, tras los tests unitarios: si la fase declaró schemas en el
+PLAN, correr el contract test contra la API real (entorno de test) y tratar cada
+violación de contrato como hallazgo CRÍTICO — la implementación contradice la
+spec aprobada. En `tdd-qa-swl` es gate opt-in: requiere la API levantable en CI.
+
+## Cuándo NO cargar
+
+- No hay contrato declarado (ni OpenAPI, ni schema, ni Pact) — primero declarar
+  el schema en el PLAN; sin contrato el contract testing no tiene qué verificar.
+- Lógica de negocio pura sin límite de API — eso es `tdd-workflow`/`testing-*`.
+- Prototipo de descarte donde la API cambia cada hora — el contrato se
+  estabiliza primero, luego se verifica.
+
+## Gotchas / Errores comunes no obvios
+
+- **Schema permisivo da falso verde**: un OpenAPI con `additionalProperties: true`
+  y casi todo opcional "conforma" con cualquier response — el contract test pasa
+  sin verificar nada. Causa: schema generado laxo (FastAPI sin `model_config`
+  estricto, Zod con `.passthrough()`). Solución: el contrato debe ser tan
+  estricto como la promesa real — requeridos marcados, `additionalProperties:
+  false` donde aplica.
+- **Property testing encuentra "bugs" en el schema, no en el código**: schemathesis
+  genera un edge case válido por schema que el código nunca contempló (string de
+  10000 chars, número en el límite). A veces el bug es del schema (demasiado
+  permisivo), no del endpoint. Diagnosticar antes de "arreglar" el código.
+- **Pact sin broker compartido es teatro**: si consumer y provider verifican
+  contra pactos en ramas distintas sin un broker central que versione, cada lado
+  pasa en aislamiento y rompen juntos en producción. CDC sin broker = falsa
+  seguridad; usar schema-based si no hay broker.
+- **Tipos generados que nadie recompila**: `openapi-typescript` genera tipos al
+  día del commit; si el pipeline no los regenera contra la spec viva, el
+  compilador valida contra un contrato fósil. El gate debe regenerar y comparar,
+  no confiar en el archivo commiteado (regla `verificar-citas-normativas.md §
+  comentarios temporales`).
+- **Contract test que levanta la app real es lento y flaky en CI**: si requiere
+  BD y servicios, hereda toda su fragilidad. Para schema-based puro, preferir el
+  modo que valida la spec estáticamente o contra un mock conformante antes de
+  exigir la app completa levantada.
+
+## Anti-patrones
+
+- **Schema decorativo**: declarar OpenAPI/Pydantic y nunca verificar que la
+  implementación lo cumple — documentación que diverge en silencio.
+- **CDC donde basta schema-based**: montar Pact + broker para un front↔back de
+  un solo equipo; complejidad sin retorno.
+- **Verificar el contrato contra un mock que usa el mismo schema**: tautología —
+  el mock conforma por construcción; el contract test debe correr contra la
+  implementación real.
+- **Tratar la violación de contrato como warning**: si la API rompe su contrato,
+  un consumidor ya está roto; es CRÍTICO, no observación.

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

@@ -8,7 +8,12 @@ description: >
   de conformidad para decidir fallback manual. Cargar en /swl:release Paso 7
   cuando hay commits Conventional, o manualmente para previsualizar el
   changelog antes de un release.
-version: 1.0.0
+version: 1.1.0
+evolved: true
+evolved-from: "1.0.0"
+evolved-at: "2026-06-11"
+evolved-by: "fase-10-slice-5"
+evolved-note: "v1.1.0: el parser CC tolera el prefijo de trazabilidad [T-NN]/[REQ-NN] de la convención de ejecutar-fase — commits con prefijo de tarea cuentan como conformes (Fase 10)."
 nivelRiesgo: BAJO
 herramientasPermitidas: [Read, Bash]
 skillsInvocables: [release-semver]
@@ -47,7 +52,9 @@ exclusiones:
 2. **Parsea con Conventional Commits 1.0.0**: regex que captura tipo, scope,
    marca `!`, descripción. Soporta tipos extendidos del proyecto SWL:
    `evolucion` (cambios de skills/agentes), además de `feat/fix/perf/refactor/
-   docs/style/test/ci/build/chore/revert`.
+   docs/style/test/ci/build/chore/revert`. Tolera el prefijo opcional de
+   trazabilidad `[T-NN]` / `[REQ-NN]` de la convención de `ejecutar-fase`
+   (no altera la semántica CC — el tipo+scope+descripción siguen presentes).
 3. **Detecta breaking changes** por marca `!` después del tipo o trailer
    `BREAKING CHANGE:` en el body. Los breaking siempre van al inicio del
    release, sin importar el tipo original.

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

@@ -50,8 +50,18 @@ const { execSync } = require('node:child_process');
  *   feat!: breaking change inline
  *   refactor(hooks/lib): split evolution-tracker
  *   chore(release): bump version
+ *   [T-01] feat(hooks): prefijo de trazabilidad de tarea (ejecutar-fase)
+ *   [T-07][T-08] refactor(hooks): varios prefijos consecutivos
+ *   [REQ-08] feat(scripts): prefijo de requisito
+ *
+ * El prefijo opcional `[T-NN]` / `[REQ-NN]` (uno o más, consecutivos) proviene
+ * de la convención de commits de `habilidades/ejecutar-fase/SKILL.md`
+ * (trazabilidad de tarea/requisito). No altera la semántica CC: el
+ * tipo+scope+descripción siguen presentes después del/los prefijo(s), por lo
+ * que el commit cuenta como conforme. Grupo non-capturing para no desplazar
+ * los índices [1]=tipo [2]=scope [3]=! [4]=descripcion.
  */
-const RE_CONVENTIONAL = /^(feat|fix|perf|refactor|docs|style|test|ci|build|chore|revert|evolucion)(?:\(([^)]+)\))?(!)?:\s*(.+)$/;
+const RE_CONVENTIONAL = /^(?:\[(?:T|REQ)-\d+\]\s*)*(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 +71,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.

package/habilidades/diagrama-arquitectura/SKILL.md

@@ -33,7 +33,7 @@ Basado en architecture-diagram-generator (MIT, Cocoon AI) — adaptado al sistem
 - El usuario pide un diagrama de arquitectura del proyecto
 - `arquitecto-swl` necesita visualizar la arquitectura propuesta
 - `documentador-swl` genera documentación visual
-- `/swl:wiki` o `/swl:dashboard` necesitan representación gráfica
+- `/swl:wiki` o `/swl:status dashboard` necesitan representación gráfica
 - Cualquier tarea de RFC, ADR o propuesta arquitectónica
 
 ## Sistema de diseño