@saulwade/swl-ses 1.8.0 → 2.0.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/release.md

@@ -167,7 +167,7 @@ node scripts/generar-skills-lock.js
 git add manifiestos/skills-lock.json
 ```
 
-El lock contiene SHA256 de cada SKILL.md y permite que `/swl:salud` detecte
+El lock contiene SHA256 de cada SKILL.md y permite que `/swl:status salud` detecte
 drift silencioso entre releases. Si el lock no cambió respecto al anterior,
 el commit lo refleja como no-op (idempotente). El archivo es pequeño (~37KB)
 y debe versionarse.

package/comandos/swl/status.md

@@ -0,0 +1,279 @@
+---
+name: swl:status
+description: Comando unificado de observabilidad del sistema y la sesión. Enruta a subcomandos [salud | metricas | loops | evolucion | historico | dashboard] que reportan salud del sistema SWL, métricas de la sesión actual, trayectorias de loops iterativos, estado del ciclo de auto-evolución y dashboard histórico multi-sesión. Reemplaza los comandos previos /swl:salud, /swl:metricas, /swl:dashboard y /swl:evolucion-estado (fusionados en este desde la Fase 09).
+allowed_tools: ["Read", "Write", "Bash", "Glob", "Grep"]
+---
+
+# /swl:status <subcomando> — Observabilidad unificada
+
+Punto único de observabilidad de swl-ses. Fusiona los cuatro comandos previos de
+diagnóstico en un router con subcomandos. Cada subcomando delega exactamente en
+la misma lógica (skill o script) que usaba el comando original — sin pérdida de
+funcionalidad ni de flags.
+
+## Uso
+
+```
+/swl:status salud                  — Diagnóstico de salud del sistema SWL (genera SALUD.md)
+/swl:status metricas               — Métricas de la sesión actual (tokens, costo, herramientas)
+/swl:status metricas detalle       — Desglose completo por herramienta, agente y timeline
+/swl:status metricas fases         — Progreso de fases del proyecto (desde feature-list.json)
+/swl:status loops                  — Trayectorias de loops iterativos (.planning/loops/)
+/swl:status evolucion              — Estado del ciclo de auto-evolución (health_score, nudges…)
+/swl:status evolucion --json       — JSON crudo de metricas.json (para pipes)
+/swl:status evolucion --dias=N     — Regenera métricas con ventana de N días (default 14)
+/swl:status evolucion --regenerar  — Fuerza recomputo del hook ciclo-evolucion.js (etapa métricas)
+/swl:status historico              — Dashboard histórico multi-sesión (web, auto-puerto)
+/swl:status dashboard              — Alias de historico
+/swl:status dashboard --port 9090  — Fuerza puerto específico del dashboard
+/swl:status dashboard today        — Resumen de consumo del día (terminal)
+/swl:status dashboard stats        — Estadísticas históricas all-time (terminal)
+/swl:status dashboard scan         — Sincroniza JSONL → SQLite sin abrir el dashboard
+```
+
+Sin subcomando: pide al usuario cuál quiere, o muestra `salud` + `metricas`
+como vista por defecto si el contexto lo sugiere.
+
+## Tabla de enrutamiento (delegación 1:1)
+
+| Subcomando | Delega en | Origen previo |
+|------------|-----------|---------------|
+| `salud` | `Skill("validacion-ci-sistema")` | `/swl:salud` |
+| `metricas` (+ `detalle`, `fases`) | scripts de métricas de sesión + `derivar-feature-list.js` | `/swl:metricas` |
+| `loops` | `hooks/lib/loop-telemetry.js` | `/swl:metricas loops` |
+| `evolucion` | `hooks/ciclo-evolucion.js` (etapa métricas) + `.planning/evolution/metricas.json` | `/swl:evolucion-estado` |
+| `historico` / `dashboard` | `Skill("swl-dashboard")` | `/swl:dashboard` |
+
+---
+
+## Subcomando: `salud`
+
+Diagnóstico de salud del sistema SWL con **verificaciones deterministas**
+(conteos, existencia de campos, sintaxis). Genera `SALUD.md` con score objetivo.
+**Solo lectura** — no modifica nada salvo `SALUD.md`. Para corregir problemas,
+usar `/swl:evolucionar`.
+
+**Carga**: `Skill("validacion-ci-sistema")` — contiene las reglas de validación
+por componente (agentes, skills, hooks, comandos, reglas), la tabla de exit codes
+y el checklist de integridad. Toda la lógica de verificación vive en el skill.
+
+**Cuándo usar**: antes de iniciar proyecto nuevo, tras modificar agentes/skills
+manualmente, tras merge/pull, o como mantenimiento mensual.
+
+**Score global ponderado**:
+```
+Score = agentes×0.30 + skills×0.25 + comandos×0.20 + reglas×0.15 + hooks×0.10
+90-100 Excelente · 75-89 Saludable · 60-74 Funcional · <60 Crítico
+```
+
+**Pasos siempre activos**: inventario determinista, detección de tier del proyecto
+(Simple <500 / Standard 500-5000 / Complex >5000 archivos), diagnóstico de los 5
+componentes, y calidad de `CLAUDE.md` (ADR-0016):
+```bash
+npx -y @saulwade/swl-ses@latest audit-claudemd --json
+```
+Umbrales ajustables: `SWL_CLAUDEMD_MAX_LINES` (default 200),
+`SWL_CLAUDEMD_MAX_BULLET_CHARS` (default 1000).
+
+**Auditorías opt-in** (cada una se activa con su variable de entorno; si no está
+definida, el paso se omite sin afectar el score — diseño zero-config):
+
+| Variable | Qué audita | Comando |
+|----------|-----------|---------|
+| `SWL_AUDIT_SKILLS=1` | Prompt injection, secretos, URLs sospechosas y estructura en SKILL.md | `bash scripts/audit-skills.sh` (requiere `uv`) |
+| `SWL_AUDIT_FRAMEWORKS=1` | Cobertura de NIST CSF/AI RMF, MITRE ATLAS/ATT&CK, D3FEND en skills de seguridad | `npx -y @saulwade/swl-ses@latest audit-coverage-frameworks --resumen` |
+| `SWL_AUDIT_AGENTES=1` | Agentes sin Exclusion Clause o Gotchas (anti agent-hijacking) | `npx -y @saulwade/swl-ses@latest audit-agents-gaps --resumen` |
+
+**Verificación de drift de skills** (si existe `manifiestos/skills-lock.json`):
+```bash
+npx -y @saulwade/swl-ses@latest generate-skills-lock --check
+```
+
+**Smoke test de MCP** (si hay servers en `.claude/settings.json` o configs globales):
+```bash
+python scripts/mcp-orchestrator.py status --json 2>/dev/null
+```
+Detecta drift de apiKeys (`40101`), binarios faltantes y `"env": {}` que rompe la
+herencia de variables — antes de que fallen en uso interactivo.
+
+Formato de salida enriquecido vía `scripts/lib/health-row.js` (barras Unicode;
+respeta `NO_COLOR` y `SWL_ASCII_SIMPLE=1`). Genera `SALUD.md` con los datos
+exactos de los scripts — sin ajustar el score "porque parece sano".
+
+---
+
+## Subcomando: `metricas`
+
+Métricas acumuladas de la **sesión actual**: tokens, costo estimado USD, tool
+calls y distribución por herramienta, más el estado del presupuesto configurado.
+
+**Fuentes de datos**:
+```bash
+# 1. Bridge de tracking de la sesión (generado por el hook de costos)
+ls /tmp/swl-costs-*.json 2>/dev/null | sort -t- -k3 -n | tail -1
+# 2. Métricas persistidas del proyecto
+cat .planning/METRICAS.md 2>/dev/null || echo "(sin métricas previas)"
+# 3. Presupuesto configurado
+node -e "const c=require('./manifiestos/hooks-config.json').costBudget||{}; console.log('maxUsd:',c.maxUsd??'no configurado','| maxTokens:',c.maxTokens??'no configurado','| alertAt:',c.alertAt??'no configurado')"
+```
+
+Construir el resumen con: tool calls totales, tokens, costo estimado, modelo
+predominante, estado de presupuesto (`OK`/`ALERTA`/`EXCEDIDO`) y top 5
+herramientas por costo. Si el estado es ALERTA (≥ `alertAt`), sugerir
+`/swl:compactar`. Si EXCEDIDO, recomendar revisar `manifiestos/hooks-config.json`.
+
+### `metricas detalle`
+
+Desglose completo: tabla por herramienta (calls, tokens entrada/salida, costo),
+desglose por agente SWL desde `costePorAgente` del bridge, comparativa histórica
+contra `~/.claude/usage.db` (últimos 30 días) y timeline de actividad por bloques
+de 5 minutos.
+
+### `metricas fases`
+
+Progreso de fases del proyecto. Regenera primero el JSON derivado de
+`HOJA-RUTA.md` (fuente de verdad) y lo lee:
+```bash
+node scripts/derivar-feature-list.js
+cat .planning/feature-list.json
+```
+Reporta totales por estado canónico (`completado`, `en_progreso`, `pendiente`,
+`bloqueado`, `spec_listo`), lista de fases con marca visual y artefactos
+presentes (`[PLAN]`/`[RESUMEN]`), y timestamp de generación. Detección de drift:
+`node scripts/derivar-feature-list.js --check` (exit 2 si drift).
+
+### Notas de precisión
+
+Los costos son estimaciones según precios publicados de la API de Anthropic. El
+real varía por modelo efectivo, caché de prompt y región/plan. Para costos
+exactos, el dashboard de Anthropic Console.
+
+---
+
+## Subcomando: `loops`
+
+Trayectorias de loops iterativos registradas por `hooks/lib/loop-telemetry.js`
+en `.planning/loops/`:
+```bash
+node -e "
+const fs = require('fs'), path = require('path');
+const lt = require('./hooks/lib/loop-telemetry');
+const base = path.join(process.cwd(), lt.DIR_LOOPS);
+let dirs = [];
+try { dirs = fs.readdirSync(base).map(d => path.join(base, d)).filter(d => fs.statSync(d).isDirectory()); } catch {}
+if (dirs.length === 0) { console.log('(sin corridas de loops registradas)'); process.exit(0); }
+for (const dir of dirs.sort().slice(-10)) {
+  try {
+    const t = lt.analizarTrayectoria(dir);
+    const h = lt.leerHandoff(dir);
+    console.log(path.basename(dir) + ' | iters: ' + t.totalIteraciones +
+      ' | keep/revert: ' + t.keeps + '/' + t.reverts +
+      ' | métrica: ' + t.metricaInicial + ' → ' + t.metricaFinal +
+      ' | plateau: ' + (t.plateau ? 'SÍ' : 'no') +
+      ' | status: ' + (h ? h.status : 'en curso'));
+  } catch (e) { console.log(path.basename(dir) + ' | (ilegible: ' + e.message + ')'); }
+}
+"
+```
+Reportar en tabla: corrida, iteraciones, keep/revert rate, métrica inicial →
+final, plateau y status. Si una corrida activa muestra plateau, sugerir cerrarla
+— iterar sin mejora quema tokens.
+
+---
+
+## Subcomando: `evolucion`
+
+Estado del ciclo de auto-evolución en la ventana reciente (default 14 días).
+Responde con datos a "¿el sistema está aprendiendo?".
+
+**Flags**: `--json` (emite el JSON crudo de `metricas.json`), `--dias=N`
+(ventana de N días), `--regenerar` (fuerza recomputo del hook).
+
+**Paso 0 — métricas frescas** (si `--regenerar` o `metricas.json` > 24h):
+```bash
+echo '{}' | node hooks/ciclo-evolucion.js
+```
+
+**Paso 1 — cargar**:
+```bash
+cat .planning/evolution/metricas.json
+```
+Si no existe, ejecutar el regenerado; si sigue sin existir, reportar que el ciclo
+no ha corrido aún.
+
+**Dashboard** (formato humano) con secciones: health_score + badge, NUDGES
+(emitidos/accionados/pendientes por tipo), INSTINTOS (proyecto/global/perfil),
+AGENTES (runs/fallos/tasa), EVOLUCIONES (aplicadas/revertidas/rollback ratio),
+CALIDAD CONDUCTUAL (fallos por tipo, reintentos, latencia), ALERTAS PERSISTENTES
+y KERNEL (gobernanza: política evolvable, último ADR kernel, ratio
+`evolvable=false`/total).
+
+**Badges**: ≥90 🏆 Óptimo · ≥75 🥇 Saludable · ≥60 🥈 Parcial · ≥40 🥉 Esqueleto
+· <40 ⚠️ Dormido.
+
+**Recomendaciones contextuales** (máx 3, al final): bootstrap de instintos si
+`instintos.proyecto==0` y `aprendizajes>10`; revisar alertas si `tasaAccion<0.3`;
+candidatos a `/swl:evolucionar` si `tasaExito<70`; etc.
+
+**Anti-substitution**: el archivo de métricas es **siempre**
+`.planning/evolution/metricas.json` (nunca `.planning/metricas.json` ni variantes);
+el hook que regenera es **siempre** `hooks/ciclo-evolucion.js` (etapa métricas, Fase 11); para forzar
+regen usar el pipe `echo '{}' | node ...`, nunca `require()` directo.
+
+**Response discipline**: con `--json`, la respuesta es el contenido crudo del
+archivo, sin prosa.
+
+---
+
+## Subcomando: `historico` / `dashboard`
+
+Dashboard histórico multi-sesión vía `claude-usage` (vendored). Complementa
+`metricas` (sesión actual) con perspectiva multi-sesión y gráficos interactivos.
+
+**Carga**: `Skill("swl-dashboard")` con el subcomando indicado:
+- (vacío) o `historico` → dashboard web (auto-detecta puerto: 8888, 9090, 9191…)
+- `--port N` → fuerza un puerto
+- `today` → resumen del día en terminal
+- `stats` → estadísticas históricas all-time en terminal
+- `scan` → solo sincroniza JSONL → SQLite sin abrir el dashboard
+
+### Integración con Mission Control (opt-in)
+
+Dashboard web externo para orquestación de flotas de agentes. **Completamente
+opcional** — el dashboard local funciona igual sin configurarlo.
+
+| Variable | Descripción | Ejemplo |
+|----------|-------------|---------|
+| `SWL_MC_URL` | URL base de la instancia de MC | `http://localhost:3000` |
+| `SWL_MC_TOKEN` | API key de MC (si hay auth) | `mc-key-abc123` |
+
+- Con `SWL_MC_URL` definida: el comando detecta MC (vía `scripts/lib/mc-client.js`)
+  y ofrece redirigir al panel web. Si MC no responde en 2s, fallback graceful al
+  dashboard local con mensaje informativo (sin crash ni degradación silenciosa).
+- Sin `SWL_MC_URL`: dashboard local sin cambios (zero-config).
+
+Instalar MC (opcional): `git clone https://github.com/builderzlabs/mission-control`
+→ `docker compose up` (requiere Node ≥22, pnpm; genera su API key al primer
+arranque). MC expone además un **servidor MCP con ~49 tools** (agentes, memoria,
+soul, tareas, sesiones, tokens/costos, skills, cron, runs/evals). swl-ses **NO**
+modifica `.claude/settings.json` automáticamente — el registro del MCP es manual.
+
+**Seguridad**: el MCP de MC incluye tools de **escritura** (`mc_create_task`,
+`mc_write_memory`, `mc_write_soul`…). Antes de activarlo, evaluar exposición de
+red, permisos mínimos de la API key y confianza en los agentes que lo invocarán.
+La regla `seguridad-agentes.md` recomienda documentarlo en
+`.planning/MCP_REGISTRY.md`.
+
+---
+
+## Reglas de comportamiento
+
+- `salud` y `evolucion` son **solo lectura** (salvo que `salud` genera `SALUD.md`).
+  Para corregir, usar `/swl:evolucionar`.
+- Las verificaciones de `salud` son scripts deterministas — no usar juicio
+  subjetivo ni ajustar scores "porque parece sano".
+- Los reportes opt-in de auditoría (`SWL_AUDIT_SKILLS`, `SWL_AUDIT_FRAMEWORKS`,
+  `SWL_AUDIT_AGENTES`) nunca bloquean el diagnóstico: si fallan (red,
+  dependencia, paquete no publicado), el flujo continúa.
+- Respetar `--json` como salida cruda sin prosa donde aplique (`evolucion`).
+- No reintroducir los comandos eliminados: este comando los reemplaza.

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:status 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:
 
@@ -451,6 +494,31 @@ Sin `--until-converge`, el comportamiento del comando es idéntico al actual: un
 
 ## Paso 5 — Verificación de criterios de aceptación
 
+### 5.0 — Trazabilidad REQ→T→commit→test (si el CONTEXTO tiene REQ-IDs)
+
+Si la sección de criterios del CONTEXTO usa IDs `REQ-NN:` (formato Fase 10+),
+ejecuta el validador de cadena ANTES de la verificación criterio por criterio:
+
+```bash
+node scripts/verificar-trazabilidad.js --fase=N
+```
+
+- Exit 0 → cadena completa; adjunta la tabla REQ→tareas/commits/tests al VERIFICACION.md.
+- Exit 1 → **cada REQ huérfano es hallazgo CRÍTICO** (requisito sin implementar,
+  sin commit trazable o sin test que lo verifique). Listarlos en el VERIFICACION.md
+  con la dirección del gap (sin tarea / sin commit / sin test).
+- Exit 2 → error de invocación; reportar sin bloquear el resto de la verificación.
+
+En CONTEXTOs legacy sin REQ-IDs el script sale 0 con nota — continuar normal.
+
+### 5.0b — Contract testing (si la fase declaró schemas en el PLAN)
+
+Si el PLAN declara schemas (Pydantic/Zod/JSON Schema/OpenAPI) o la fase expone
+una API consumida por otro componente, cargar `Skill("calidad-contract-testing")`
+y verificar que la implementación honra el contrato (schema-based con
+schemathesis/Dredd contra la API real, o validación de forma con el modelo en
+el test de integración). Cada violación de contrato = hallazgo CRÍTICO.
+
 Lee los criterios de aceptación del `.planning/fases/0N-CONTEXTO.md` y verifica cada uno:
 
 Para cada criterio:

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

@@ -141,7 +141,7 @@ Checklist para cualquier aplicación LLM en producción:
 | Tiempo | Estático (pre-incorporación) | Dinámico (runtime) |
 | Objetivo | Artefactos (SKILL.md, scripts) | Sesiones del agente en producción |
 | Amenazas cubiertas | Supply chain, credenciales hardcodeadas, autonomy abuse declarada | Prompt injection directo/indirecto, context poisoning, tool abuse en runtime |
-| Cuándo ejecuta | `/swl:crear-skill`, `/swl:plugins install`, `/swl:salud` | Durante cada request del agente en producción |
+| Cuándo ejecuta | `/swl:crear-skill`, `/swl:plugins install`, `/swl:status salud` | Durante cada request del agente en producción |
 | Herramientas recomendadas | Grep, SAST sobre SKILL.md | Regex + heurístico + clasificador + guardrails |
 
 Ambos skills son necesarios. Ninguno reemplaza al otro.

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.