@saulwade/swl-ses 1.9.0 → 2.0.0

package/comandos/swl/ayuda.md

@@ -44,7 +44,7 @@ Formato: tabla compacta con nombre, descripción corta y flags principales.
 | `/swl:revisar [stack\|archivo]` | Revisión de código por tecnología (auto-detect) |
 | `/swl:revisar-impacto` | Análisis de blast radius y risk score |
 | `/swl:evaluar-skill [nombre]` | Evaluación PluginEval de 2 capas con badge |
-| `/swl:salud` | Diagnóstico de integridad del sistema |
+| `/swl:status salud` | Diagnóstico de integridad del sistema |
 | `/swl:auditar-deps` | Auditoría de dependencias (CVEs) |
 
 #### Aprendizaje y evolución
@@ -70,8 +70,8 @@ Formato: tabla compacta con nombre, descripción corta y flags principales.
 
 | Comando | Descripción |
 |---------|------------|
-| `/swl:metricas [resumen\|detalle]` | Métricas de sesión (tokens, costo) |
-| `/swl:dashboard [today\|stats]` | Dashboard histórico multi-sesión |
+| `/swl:status metricas [resumen\|detalle]` | Métricas de sesión (tokens, costo) |
+| `/swl:status dashboard [today\|stats]` | Dashboard histórico multi-sesión |
 | `/swl:mcp-status` | Estado de servidores MCP conectados |
 
 #### Instalación y sistema

package/comandos/swl/discutir-fase.md

@@ -178,6 +178,12 @@ Espera confirmación. Si hay correcciones, ajusta y presenta el resumen nuevamen
 
 Una vez confirmado, crea `.planning/fases/0N-CONTEXTO.md` (donde N es el número de fase con cero a la izquierda si N < 10, ej: `01-CONTEXTO.md`, `02-CONTEXTO.md`).
 
+**TDD es default ON** (gate G2, decisión D-07 vNext): NO preguntes "¿quieres TDD?".
+La fase se ejecuta con ciclo RED→GREEN→REFACTOR y evidencia en telemetría salvo que
+el usuario pida desactivarlo explícitamente. Si lo desactiva: exige la razón, regístrala
+en el campo `**TDD**` del CONTEXTO y anota la excepción en `.planning/AUDITORIA.md`
+(el opt-out se declara y registra — nunca es silencioso).
+
 Estructura del archivo:
 
 ```markdown
@@ -187,6 +193,8 @@ Estructura del archivo:
 **Fase**: N de M (total de fases en el roadmap)
 **Fecha de discusión**: [fecha actual]
 **Estado**: Listo para planear
+**TDD**: on  <!-- default. Si el usuario lo desactiva: `off — razón: [...]` + entry en AUDITORIA.md -->
+
 
 ## Objetivo de la fase
 [descripción clara del objetivo]
@@ -209,8 +217,18 @@ Estructura del archivo:
 ## Pantallas / vistas (si aplica)
 [descripción de pantallas]
 
-## Criterios de aceptación
-[lista medible de criterios]
+## Criterios de aceptación (REQ)
+[criterios binarios y verificables con ID estable REQ-NN — trazabilidad G4:
+- **REQ-01**: [criterio binario verificable]
+- **REQ-02**: [criterio binario verificable]
+Un REQ emitido NUNCA se renumera ni se reusa: si un criterio se descarta, marcarlo
+"RETIRADO — razón" conservando el número. planear-fase exige que cada tarea T-NN
+declare qué REQ verifica (matriz REQ×T) y aprobar-plan rechaza planes con REQ
+huérfanos. verificar-trazabilidad.js valida la cadena REQ→T→commit→test al cierre.
+Método de verificación: por default cada REQ exige un test con marker
+`verifica: REQ-NN`; los REQ satisfechos por prosa/docs/configuración llevan la
+anotación `(verificación: inspección)` en el criterio — exigen tarea y commit
+pero no test automatizado.]
 
 ## Riesgos identificados
 [lista con nivel de impacto: ALTO/MEDIO/BAJO]

package/comandos/swl/ejecutar-fase.md

@@ -18,6 +18,7 @@ Eres el coordinador de ejecución SWL. Orquestas la implementación real del có
 ```
 /swl:ejecutar-fase 1                # modo default — oleadas paralelas
 /swl:ejecutar-fase 2 --iterative    # modo iterativo — 1 tarea, review per-task, auto-debug
+/swl:ejecutar-fase 3 --sin-verify   # omite el verify automático del cierre (desviación registrada)
 ```
 
 ### Cuándo usar `--iterative` (modo opt-in)
@@ -48,7 +49,7 @@ Si NO hay `--iterative`, carga el flujo default:
 Skill("ejecutar-fase")
 ```
 
-El skill define el protocolo completo de ejecución por tarea (leer > verificar dependencias > implementar > verificar > commit > actualizar ESTADO.md), el formato de commit atómico, las 3 reglas de desviación (menor/moderada/mayor), el manejo de tareas HITL, TDD opcional, el formato de ESTADO.md y el checklist de cierre de fase.
+El skill define el protocolo completo de ejecución por tarea (leer > verificar dependencias > implementar > verificar > commit > actualizar ESTADO.md), el formato de commit atómico, las 3 reglas de desviación (menor/moderada/mayor), el manejo de tareas HITL, TDD por default con evidencia RED en telemetría de loops (opt-out solo si el CONTEXTO declara `**TDD**: off` con razón — gate G2, ADR-0035), el formato de ESTADO.md y el checklist de cierre de fase.
 
 Luego carga habilidades específicas del stack detectado en PLAN.md o PROYECTO.md:
 - Backend Python: `Skill("fastapi-experto")`, `Skill("patrones-python")`
@@ -75,10 +76,33 @@ Verifica en orden:
 5. **Requirement Freeze**: verifica que el frontmatter del PLAN.md contenga
    `estado: aprobado`. Si contiene `estado: borrador` o no tiene campo `estado`:
    - DETENER ejecución
-   - Reportar: "El PLAN.md no está aprobado. Ejecuta `/swl:planear-fase N` y
-     confirma el plan antes de ejecutar."
+   - Reportar: "El PLAN.md no está aprobado. Ejecuta `/swl:aprobar-plan N` para
+     aprobarlo y firmarlo antes de ejecutar."
    - NO proceder sin aprobación explícita del usuario
 
+6. **Gate G1 — verificación de integridad del plan firmado**: tras confirmar
+   `estado: aprobado`, recomputa el hash del PLAN y compáralo contra su lock:
+   ```bash
+   node -e "const {verificarPlan}=require('./scripts/lib/plan-lock'); console.log(JSON.stringify(verificarPlan('.planning/fases/0N-PLAN.md')))"
+   ```
+   Interpreta el resultado:
+   - `ok: true, modo: "firmado"` → el plan no fue mutado tras su aprobación.
+     Continúa con normalidad.
+   - `ok: true, modo: "legacy"` → plan aprobado SIN lock (creado antes de la
+     Fase 09, cláusula de gracia D-05). Muestra una **advertencia visible** al
+     usuario: "Plan en modo legacy (sin firma SHA256). Se ejecuta sin
+     verificación de integridad. Para firmarlo: `/swl:aprobar-plan N`." y
+     continúa.
+   - `ok: false, modo: "mutado"` → **DETENER ejecución**. El plan cambió tras la
+     firma. Reporta `hashEsperado` y `hashActual` y di: "El PLAN fue modificado
+     después de su aprobación. Revisa los cambios y vuelve a aprobarlo con
+     `/swl:aprobar-plan N` antes de ejecutar." NO proceder.
+   - `ok: false` con cualquier otro modo (`lock-corrupto`, `sin-firmar`,
+     `no-existe`) → DETENER y reportar el `motivo` exacto.
+
+   Repite esta verificación al inicio de cada slice (el plan no debe mutar
+   durante la ejecución — Requirement Freeze).
+
 Lee los tres archivos completos. Verifica estado de Git (`git status`, `git log --oneline -5`). Si hay cambios no commiteados, pregunta cómo proceder.
 
 **Nota sobre Requirement Freeze**: una vez que el plan está aprobado y la ejecución
@@ -147,7 +171,30 @@ Al completar todos los slices, genera `.planning/fases/0N-RESUMEN.md` con: slice
 
 Marca fase completada en HOJA-RUTA.md con fecha. Actualiza ESTADO.md con estado general.
 
-## Paso 8 — Reporte final
+**Liberar la fase activa** (gate G0): elimina `.planning/locks/fase-activa.json` —
+la fase ya no está en ejecución y `hooks/spec-gate.js` debe volver a advertir si se
+escribe código sin una nueva fase aprobada:
+
+```bash
+node -e "const fs=require('fs'); const p='.planning/locks/fase-activa.json'; if(fs.existsSync(p)){fs.unlinkSync(p); console.log('fase activa liberada')} else {console.log('sin fase activa que liberar')}"
+```
+
+NO eliminar el `.lock` del plan (`0N-PLAN.md.lock`) — ese es evidencia de
+aprobación versionada, no runtime.
+
+## Paso 8 — Verificación automática y reporte final
+
+**Verify automático (gate G4)**: tras generar RESUMEN.md y liberar la fase activa,
+invoca `/swl:verificar --until-converge` automáticamente — el cierre de fase ya no
+es un paso manual recomendado, es parte del flujo.
+
+- Opt-out: si el usuario invocó `/swl:ejecutar-fase N --sin-verify`, omite la
+  verificación y registra la desviación en el RESUMEN.md ("verificación diferida
+  por --sin-verify — razón: [la que dé el usuario]").
+- Si la verificación converge (Señal A): el VERIFICACION.md queda generado y el
+  reporte final lo incluye.
+- Si NO converge (Señal B/C) o queda abortada: reportar el estado del loop al
+  usuario — la fase NO se declara verificada.
 
 ```
 Fase N — [nombre] completada.
@@ -156,13 +203,13 @@ Slices implementados: [N de N]
 Commits creados: [N]
 Tests pasando: [N de N]
 Desviaciones del plan: [N, o "ninguna"]
+Verificación: [convergió en pasada K | diferida por --sin-verify | NO convergió — ver detalle]
 
 Archivos generados:
 - .planning/fases/0N-RESUMEN.md
+- .planning/fases/0N-VERIFICACION.md (verify automático)
 - .planning/ESTADO.md (actualizado)
 - .planning/HOJA-RUTA.md (actualizado)
-
-Próximo paso recomendado: /swl:verificar
 ```
 
 ## Reglas de comportamiento

package/comandos/swl/evolucionar.md

@@ -215,7 +215,7 @@ score_after = (evals_pass / evals_total) * 100 × factor_peso
 | `score_baseline - 5 <= score_after < score_baseline` | **Requiere revisión humana** — reportar diferencia; usuario decide si acepta la regresión menor o revierte |
 
 Los 3 casos registran evento en `.planning/evolution/evoluciones.jsonl` para el
-dashboard `/swl:evolucion-estado`.
+dashboard `/swl:status evolucion`.
 
 ### Regla de oro
 

package/comandos/swl/inbox.md

@@ -43,7 +43,7 @@ Por cada comando en la cola, decidir:
 | Tipo de contenido | Acción |
 |-------------------|--------|
 | Instrucción de trabajo clara ("arregla el bug X", "ejecuta pruebas") | Procesar como prompt del usuario. Ejecutar la tarea siguiendo el flujo normal SWL. |
-| Slash command (`/swl:salud`, `/swl:metricas`, etc.) | Invocar ese comando directamente. |
+| Slash command (`/swl:status salud`, `/swl:status metricas`, etc.) | Invocar ese comando directamente. |
 | Pregunta/consulta ("¿cómo va X?", "estado del release") | Responder con la información solicitada. Enviar respuesta al gateway si aplica. |
 | Feedback/corrección ("no uses Y", "prefiero Z") | Escribir a `.planning/evolution/feedback-queue.jsonl` con tipo correspondiente y marcar como procesado. |
 | Contenido ambiguo o sospechoso | Marcar como descartado con razón registrada. |

package/comandos/swl/instalar.md

@@ -185,7 +185,7 @@ Doctor:     <resultado>
 Siguiente paso:
   /swl:nuevo-proyecto    → si es un proyecto nuevo
   /swl:mapear-codebase   → si ya hay código existente
-  /swl:salud             → para diagnóstico profundo del sistema
+  /swl:status salud             → para diagnóstico profundo del sistema
 ```
 
 Si la instalación fue local, menciona: "Para instalar SWL en otro proyecto, abre Claude Code en ese proyecto y ejecuta `/swl:instalar` nuevamente."

package/comandos/swl/nemesis.md

@@ -236,7 +236,7 @@ En modo `--remediar`, además de los `iter-N/` el comando registra la
 trayectoria en el formato estándar de telemetría de loops
 (`hooks/lib/loop-telemetry.js`). Esto habilita: inyección de estado por el
 hook `contexto-iteracion.js` durante las ejecuciones largas (8-30 turnos),
-detección de plateau, y lectura de la corrida por `/swl:metricas`.
+detección de plateau, y lectura de la corrida por `/swl:status metricas`.
 
 - Al iniciar iter-1: `iniciarCorrida({tipo: 'nemesis', direccion: 'lower_is_better', config: {modulo, maxIter: 3}})`.
 - Tras cada iteración: `registrarIteracion(dir, {iteracion: N, metrica: criticos+altos, delta, estado: 'keep', descripcion: 'iter N: status=<status>, X criticos, Y altos'})`.

package/comandos/swl/planear-fase.md

@@ -146,7 +146,12 @@ El agente planificador-swl debe generar el plan con esta estructura exacta:
 ...
 
 ## Modelos y esquemas de datos
-[tablas, campos, tipos, constraints — si la fase introduce datos nuevos]
+[tablas, campos, tipos, constraints — si la fase introduce datos nuevos.
+Los schemas declarados aquí (Pydantic/Zod/JSON Schema/OpenAPI) son **contrato
+verificable**, parte de la spec: la tarea que los implementa se verifica con
+contract testing (`Skill("calidad-contract-testing")`), no solo con tests
+unitarios. Declarar el schema con la estrictez de la promesa real (requeridos
+marcados, sin campos extra implícitos).]
 
 ## Endpoints a implementar
 | Método | Ruta | Descripción | Roles permitidos |
@@ -173,6 +178,16 @@ fases técnicas puras — Gherkin sin lector de negocio es ceremonia.]
 | Riesgo | Impacto | Probabilidad | Mitigación |
 |--------|---------|-------------|-----------|
 
+## Matriz REQ×T (obligatoria si el CONTEXTO tiene criterios REQ-NN)
+[tabla REQ → tareas que lo verifican. Cada tarea declara `**Verifica REQ**: REQ-XX`.
+Todo REQ sin tarea = plan NO apto para aprobación (aprobar-plan lo rechaza).
+La convención de cierre de cadena: commits con footer `Refs: REQ-NN` y tests con
+marker `# verifica: REQ-NN` (Python) / `// verifica: REQ-NN` (JS/TS) — validada
+por `scripts/verificar-trazabilidad.js`. Omitir solo en CONTEXTOs legacy sin REQ-IDs.]
+
+| REQ | Tareas que lo verifican |
+|-----|------------------------|
+
 ## Criterios de aceptación de la fase
 [copia del CONTEXTO.md, verificados contra el plan]
 
@@ -190,6 +205,7 @@ Una vez que el agente planificador-swl produce el PLAN.md, ejecuta una revisión
 - [ ] ¿El orden de implementación respeta las dependencias (BD → service → endpoint → frontend)?
 - [ ] ¿Hay criterios de verificación para cada slice?
 - [ ] ¿Los criterios de aceptación de la fase están cubiertos por los slices?
+- [ ] Si el CONTEXTO tiene REQ-IDs: ¿la matriz REQ×T cubre TODOS los REQ (cero huérfanos)?
 - [ ] ¿Los riesgos ALTO del CONTEXTO.md están mitigados en el plan?
 - [ ] ¿Hay tests especificados para cada área crítica?
 - [ ] ¿Hay tareas HITL claramente marcadas?

package/comandos/swl/plugins.md

@@ -122,7 +122,7 @@ echo "Plugin <nombre> v<version> instalado en _userland/plugins/<nombre>/"
 echo "Componentes: agentes=$(count), skills=$(count), reglas=$(count), hooks=$(count)"
 ```
 
-Indicar al usuario que ejecute `/swl:salud` para verificar integridad global.
+Indicar al usuario que ejecute `/swl:status salud` para verificar integridad global.
 
 ---
 

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

@@ -409,7 +409,7 @@ 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`.
+plateau, y lectura por `/swl:status metricas`.
 
 Al iniciar el loop (antes de la pasada 1):
 
@@ -494,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.