@saulwade/swl-ses 1.9.0 → 2.1.0

package/comandos/swl/aprobar-plan.md

@@ -0,0 +1,153 @@
+---
+name: swl:aprobar-plan
+description: Aprueba el PLAN.md de una fase y lo firma con un lock SHA256 (gate G1 de SDD). Transiciona el frontmatter de estado borrador a aprobado y escribe .planning/locks/<plan>.lock. Es la única vía válida de aprobación — ejecutar-fase verifica este lock antes de implementar y detiene la ejecución si el plan fue mutado tras la firma.
+allowed_tools: ["Read", "Write", "Edit", "Bash", "Glob"]
+---
+
+# /swl:aprobar-plan <n> — Aprobar y firmar el plan de una fase (Gate G1)
+
+Eres el guardián del gate G1 del enforcement SDD. Tu trabajo es transicionar un
+PLAN de `borrador` a `aprobado` Y firmarlo con un lock SHA256, de modo que
+cualquier mutación posterior del plan sea detectable por `/swl:ejecutar-fase`.
+
+Este comando es la **única vía documentada de aprobación**. Editar el frontmatter
+a mano (`estado: aprobado`) deja el plan en modo legacy (cláusula de gracia D-05):
+se ejecuta con advertencia pero sin protección de integridad. Usar este comando
+es lo que activa el gate real.
+
+## Uso
+
+```
+/swl:aprobar-plan 9
+```
+
+El argumento `<n>` es el número de la fase cuyo PLAN se aprueba.
+
+## Paso 1 — Localizar el PLAN
+
+Resuelve la ruta `.planning/fases/0N-PLAN.md` (N con cero a la izquierda si N < 10).
+
+- Si no existe: detente con "No existe el PLAN de la fase N. Ejecuta `/swl:planear-fase N` primero."
+- Lee el archivo completo.
+
+## Paso 2 — Validar el estado actual del frontmatter
+
+Lee el campo `estado:` del frontmatter:
+
+- Si `estado: borrador` → continúa al Paso 3 (caso normal).
+- Si `estado: aprobado` → ya está aprobado. Verifica si existe el lock:
+  ```bash
+  node -e "const {verificarPlan}=require('./scripts/lib/plan-lock'); console.log(JSON.stringify(verificarPlan('.planning/fases/0N-PLAN.md')))"
+  ```
+  - Si `modo: "firmado"` → informa "El plan ya está aprobado y firmado." y termina.
+  - Si `modo: "legacy"` (aprobado sin lock) → pregunta al usuario: "El plan está
+    aprobado pero sin firmar (modo legacy). ¿Lo firmo ahora para activar el gate
+    G1?" Si confirma, salta al Paso 4 (firmar sin re-transicionar).
+  - Si `modo: "mutado"` → el plan cambió tras una firma previa. Informa el
+    `hashEsperado` vs `hashActual` y pregunta si re-aprobar (re-firmar el estado
+    actual). Procede solo con confirmación explícita.
+- Si no hay campo `estado` → detente: "El PLAN no tiene campo `estado` en el
+  frontmatter. Revisa que sea un plan válido generado por `/swl:planear-fase`."
+
+## Paso 2.5 — Validar la matriz REQ×T (trazabilidad G4)
+
+Lee `.planning/fases/0N-CONTEXTO.md` y extrae los IDs `REQ-NN:` (fases 01-11) o
+`REQ-<fase>-NN:` (namespaceados, fases ≥12) de la sección de criterios de
+aceptación. `verificar-trazabilidad.js` reconoce ambos formatos.
+
+- **CONTEXTO sin REQ-IDs** (fases legacy 01-09): advertencia informativa
+  ("CONTEXTO sin REQ-IDs — trazabilidad no exigible, gracia legacy") y continúa.
+- **CONTEXTO con REQ-IDs**: verifica que el PLAN cubra TODOS:
+  ```bash
+  node scripts/verificar-trazabilidad.js --fase=N --solo-plan
+  ```
+  - Exit 0 → continúa al Paso 3.
+  - Exit 1 (REQ huérfanos) → **RECHAZA la aprobación**. Lista los REQ sin tarea y
+    remite a `/swl:planear-fase N` para cubrirlos (o a retirar el REQ del CONTEXTO
+    con marca "RETIRADO — razón"). NO firmes un plan con REQ huérfanos.
+
+## Paso 3 — Confirmar con el usuario antes de aprobar
+
+NUNCA apruebes sin confirmación explícita. Presenta un resumen breve del plan
+(número de slices, tareas, slices HITL) y pregunta:
+
+```
+El plan de la fase N tiene [X] slices y [Y] tareas ([Z] HITL).
+¿Confirmas la aprobación? Al aprobar se firma con SHA256 y queda inmutable:
+cualquier edición posterior detendrá /swl:ejecutar-fase.
+```
+
+Espera respuesta afirmativa. Si el usuario pide cambios, NO apruebes — remítelo
+a `/swl:planear-fase N` para refinar.
+
+## Paso 4 — Transicionar y firmar
+
+1. **Transicionar** (omitir si el plan ya estaba `aprobado` en modo legacy):
+   edita el frontmatter `estado: borrador` → `estado: aprobado` y agrega
+   `aprobadoPor: usuario (<nombre>) — <fecha>, via /swl:aprobar-plan`.
+
+2. **Firmar** — escribe el lock SHA256:
+   ```bash
+   node -e "const {firmarPlan}=require('./scripts/lib/plan-lock'); const r=firmarPlan('.planning/fases/0N-PLAN.md'); console.log(JSON.stringify(r))"
+   ```
+   Verifica que el resultado sea `ok: true` y que exista
+   `.planning/locks/0N-PLAN.md.lock`.
+
+3. **Verificar** la firma de inmediato:
+   ```bash
+   node -e "const {verificarPlan}=require('./scripts/lib/plan-lock'); console.log(JSON.stringify(verificarPlan('.planning/fases/0N-PLAN.md')))"
+   ```
+   Debe retornar `modo: "firmado"`, `ok: true`.
+
+4. **Marcar la fase como activa** (gate G0 — `hooks/spec-gate.js` consume este
+   archivo): escribe `.planning/locks/fase-activa.json` con el sha256 devuelto
+   por `firmarPlan`:
+   ```bash
+   node -e "
+   const {atomicWriteJSON} = require('./hooks/lib/atomic-write');
+   const {verificarPlan} = require('./scripts/lib/plan-lock');
+   const v = verificarPlan('.planning/fases/0N-PLAN.md');
+   atomicWriteJSON('.planning/locks/fase-activa.json', {
+     numero: N,
+     planPath: '.planning/fases/0N-PLAN.md',
+     sha256: v.hashEsperado,
+     aprobadoEn: new Date().toISOString(),
+     aprobadoPor: 'usuario via /swl:aprobar-plan'
+   });
+   console.log('fase activa: 0N');
+   "
+   ```
+   Este archivo es runtime local (gitignored — a diferencia del `.lock`, que SÍ
+   se versiona como evidencia). `/swl:ejecutar-fase` lo elimina al cerrar la fase.
+   Si se re-firma un plan (re-aprobación tras mutación), re-escribir también
+   fase-activa.json para que el hash quede alineado.
+
+## Paso 5 — Reporte
+
+```
+Plan de la fase N aprobado y firmado (gate G1 activo).
+
+estado: borrador -> aprobado
+lock: .planning/locks/0N-PLAN.md.lock
+fase activa: .planning/locks/fase-activa.json (gate G0 cubierto)
+sha256: <hash corto>
+
+Cualquier edición del PLAN tras esta firma detendrá /swl:ejecutar-fase con un
+mensaje de "plan mutado tras aprobación". Para cambiar el plan: edítalo y vuelve
+a ejecutar /swl:aprobar-plan N.
+
+Próximo paso: /swl:ejecutar-fase N
+```
+
+## Reglas de comportamiento
+
+- NUNCA apruebes un plan sin confirmación explícita del usuario.
+- NUNCA modifiques el contenido del plan al aprobarlo — solo el campo `estado`
+  del frontmatter y la línea `aprobadoPor`. El cuerpo es lo que se firma.
+- El lock vive en `.planning/locks/` y SÍ se versiona en git (es evidencia de
+  aprobación, parte del audit trail de SDD).
+- Si el usuario quiere cambiar el plan después de aprobado, el flujo correcto es
+  editar el PLAN y re-ejecutar `/swl:aprobar-plan N` (re-firma). NUNCA editar el
+  lock a mano.
+- El número de versión del release que publique esta fase lo decide el usuario
+  (regla CLAUDE.md) — este comando no toca versiones.

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

@@ -0,0 +1,122 @@
+---
+name: swl:briefing
+description: Briefing proactivo del proyecto bajo demanda. Re-presenta las señales baratas del hook SessionStart (ADRs Propuestos con reevaluación vencida, deuda con trigger por fecha cumplido, nudges sin accionar, gates en calibración, retoma pendiente) y agrega el análisis profundo opt-in que el hook no puede pagar: audit de dependencias del proyecto destino, cobertura vs umbral, hubs del grafo tocados sin revisión, drift de feature-list, y triggers de deuda en prosa libre. Cargar cuando el usuario pide "¿qué hay pendiente?", "¿qué riesgos hay?", "ponme al día", o cuando el digest de sesión sugiere el análisis completo por volumen de señales.
+allowed_tools: ["Read", "Bash", "Glob", "Grep"]
+---
+
+# /swl:briefing — Briefing proactivo bajo demanda
+
+Análisis no solicitado del estado del proyecto destino (Fase 12, ADR-0036). El
+hook `session-briefing.js` da el digest barato al abrir sesión; este comando es
+el nivel profundo: re-presenta esas señales Y agrega las que cuestan (deps, grafo,
+cobertura) con degradación funcional si la herramienta no está instalada.
+
+Principio rector: **proponer es barato y siempre permitido; actuar requiere
+autorización del usuario**. Este comando solo propone y analiza — nunca aplica
+cambios sin que el usuario los pida.
+
+## Uso
+
+```
+/swl:briefing            # señales baratas + análisis profundo completo
+/swl:briefing rapido     # solo las 5 señales del hook (sin deps/grafo/cobertura)
+```
+
+## Paso 1 — Señales baratas (mismas del hook)
+
+Ejecuta los recolectores de filesystem y presenta el digest sin tope de 5 (aquí
+sí caben todas, no hay presupuesto de latencia de arranque):
+
+```bash
+node -e "
+const b = require('./hooks/lib/briefing.js');
+const items = b.recolectarTodo(process.cwd(), new Date());
+for (const it of items) console.log('— [' + it.categoria + '] ' + it.titulo + ' → ' + it.accion);
+if (items.length === 0) console.log('(sin señales baratas)');
+"
+```
+
+Las 5 categorías: `adr-vencido`, `deuda-trigger`, `nudges-pendientes`,
+`gate-calibracion`, `continue-here`. Si `rapido`, terminar aquí.
+
+## Paso 2 — Análisis profundo (opt-in, con degradación)
+
+Para cada herramienta, **validar antes de invocar** (patrón "validar antes de
+invocar"): si no está disponible, reportar "no disponible, omitido" y continuar —
+nunca fallar el briefing por una herramienta ausente.
+
+### 2.1 — Audit de dependencias del proyecto destino
+
+Detectar el ecosistema y correr el audit nativo:
+
+```bash
+# Node
+[ -f package.json ] && npm audit --omit=dev 2>/dev/null | tail -5
+# Python
+[ -f requirements.txt -o -f pyproject.toml ] && (command -v pip-audit >/dev/null && pip-audit 2>/dev/null | tail -5 || echo "pip-audit no instalado — omitido")
+```
+
+Reportar CVEs HIGH/CRITICAL con la acción concreta (`npm audit fix`, bump de
+versión). Sin lockfile o sin gestor → omitir.
+
+### 2.2 — Cobertura vs umbral
+
+Si el proyecto define cobertura, comparar contra el umbral del proyecto (80% por
+defecto). Si no hay reporte reciente, indicar el comando para generarlo en vez de
+correrlo (puede ser caro):
+
+```
+Para medir cobertura: <runner del proyecto> --coverage
+```
+
+### 2.3 — Hubs del grafo tocados sin revisión
+
+Si el MCP `code-review-graph` está disponible (tools `mcp__code-review-graph__*`
+registradas o deferred), consultar los nodos hub modificados en los últimos N
+commits sin revisión asociada. Si no está disponible → omitir con nota.
+
+### 2.4 — Drift de feature-list
+
+```bash
+node scripts/derivar-feature-list.js --check 2>/dev/null; echo "exit: $?"
+```
+
+Exit 2 → reportar que `HOJA-RUTA.md` y `feature-list.json` divergieron, con la
+acción `node scripts/derivar-feature-list.js` para regenerar.
+
+### 2.5 — Deuda con trigger en prosa libre
+
+El hook solo evalúa triggers verificables por fecha (D-16). Aquí, leer
+`.planning/DEUDA-TECNICA.md` y evaluar con criterio los triggers en prosa
+("≥2 clientes reportan", "p95 > 60s documentado") contra el estado real del
+proyecto. Reportar los que parezcan cumplidos para revisión del usuario.
+
+## Paso 3 — Presentación y telemetría
+
+Presenta el briefing agrupado por prioridad (continue-here → gates → deuda →
+ADRs → nudges → hallazgos profundos). Cada ítem con su acción ejecutable.
+
+Tras presentar, el usuario decide qué accionar. NO ejecutar acciones de mutación
+(cerrar deuda, promover gates, aplicar fixes) sin que el usuario lo pida — este
+comando es propositivo (separación PROPONER/ACTUAR, ADR-0037 pendiente).
+
+Si el usuario acciona una señal en esta sesión (ejecuta el comando sugerido), esa
+resolución la captura la telemetría de aceptación del hook en la siguiente sesión
+(la señal desaparece del recolector → cuenta como "actuada", D-18).
+
+## Cuándo NO usar este comando
+
+- En cada turno de una sesión: el briefing es por sesión, no por mensaje. El hook
+  ya cubre el inicio; este comando es para cuando el usuario pide el detalle.
+- Para aplicar las acciones propuestas: este comando propone, no ejecuta. Usar el
+  comando concreto de cada señal (`/swl:evolucion-estado`, `/swl:verificar`, etc.).
+- En proyectos sin `.planning/`: no hay señales que recolectar.
+
+## Gotchas
+
+- **Herramienta ausente ≠ error**: si `npm audit`, `pip-audit` o el grafo no están,
+  el briefing los omite con nota y sigue. Nunca abortar por una dependencia opt-in.
+- **No re-listar lo que el hook ya mostró hoy**: el hook aplica dedupe diario; este
+  comando ignora el dedupe a propósito (lo invoca el usuario, quiere ver todo).
+- **`code-review-graph` deferred ≠ ausente**: si las tools aparecen como deferred,
+  cargar su schema con `ToolSearch` antes de concluir que no está disponible.

package/comandos/swl/compactar.md

@@ -269,10 +269,37 @@ Archivos actualizados:
 - .planning/COMPACTACION.md (creado/actualizado)
 - .planning/ESTADO.md (referencia agregada)
 
-El contexto está listo para continuar con sesión fresca.
-Próximo comando: [comando exacto]
+El estado está a salvo en disco. IMPORTANTE: este comando NO compacta la
+ventana de contexto — eso es una operación del harness que el agente no
+puede ejecutar. Para compactar de verdad, AHORA ejecuta TÚ una de estas:
+
+  /compact          ← built-in de Claude Code: trunca la ventana usando
+                       el estado ya persistido (recomendado para seguir
+                       en la misma sesión)
+  /clear o sesión nueva ← arranque limpio; pega la instrucción de arranque
+                       del Paso 7
+
+Próximo comando de trabajo (tras compactar): [comando exacto]
 ```
 
+## Paso 9 — Por qué este comando NO compacta la ventana (límite del harness)
+
+La compactación REAL del contexto (truncar la conversación) es una operación
+exclusiva del harness de Claude Code: el `/compact` built-in o el auto-compact.
+Un comando `/swl:*` corre DENTRO de la conversación y el modelo no tiene
+ninguna herramienta para truncar su propia ventana — por diseño.
+
+División de responsabilidades:
+
+| Mitad | Quién | Qué hace |
+|-------|-------|----------|
+| `/swl:compactar` | el agente | Persiste el estado a disco (COMPACTACION.md + ESTADO.md) para que NADA se pierda al truncar |
+| `/compact` | el usuario (harness) | Trunca la ventana de verdad. Sin la mitad anterior, perdería las decisiones no escritas |
+
+El error a prevenir: ejecutar `/compact` SIN haber corrido `/swl:compactar`
+antes (estado solo en la memoria de la conversación → se pierde). El orden
+correcto siempre es: `/swl:compactar` → `/compact`.
+
 ## Reglas de comportamiento
 
 - El COMPACTACION.md debe reemplazar la necesidad de releer toda la conversación. Si alguien lo lee, debe poder continuar el trabajo.

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,21 @@ 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 namespaceado por fase
+`REQ-<fase>-NN` (DT-IDS-NAMESPACE, fases ≥12) — trazabilidad G4:
+- **REQ-12-01**: [criterio binario verificable]
+- **REQ-12-02**: [criterio binario verificable]
+Las fases 01-11 conservan el formato plano `REQ-NN` (gracia legacy permanente,
+no se renumeran). `verificar-trazabilidad.js` acepta ambos formatos.
+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-<fase>-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
@@ -143,11 +167,40 @@ Según tipo de error:
 
 Al completar todos los slices, genera `.planning/fases/0N-RESUMEN.md` con: slices implementados (commits, archivos), resultados de tests, desviaciones del plan, decisiones técnicas, deuda técnica, estado final, criterios de aceptación verificados, próximos pasos.
 
+**Anexo propositivo (Fase 13, ADR-0037)**: antes de cerrar, ejecuta el propose-step
+sobre el diff de la fase (`node hooks/lib/propose-step.js --rango=<base>..HEAD`) e
+incluye una sección "Anexo propositivo" en el RESUMEN.md **solo si hay ≥1 señal** de
+adyacencia (auth/PII/pagos, migración de schema). Si no hay señal, omite la sección
+(silencio, no sección vacía). El anexo propone, nunca bloquea. Opt-out `SWL_PROPOSE=0`.
+
 ## Paso 7 — Actualización de HOJA-RUTA.md y ESTADO.md
 
 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 +209,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,18 @@ 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 (fases ≥12, IDs namespaceados por fase): commits
+con prefijo `[F<fase>·T-NN]` y footer `Refs: REQ-<fase>-NN`, tests con marker
+`# verifica: REQ-<fase>-NN` (Python) / `// verifica: REQ-<fase>-NN` (JS/TS) —
+validada por `scripts/verificar-trazabilidad.js` (acepta también el formato plano
+`REQ-NN`/`[T-NN]` de fases 01-11). 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 +207,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.
@@ -254,6 +254,52 @@ Usar tags anotados siempre (regla del skill).
 
 Crea `RELEASE-NOTES-v[nueva-versión].md` con: resumen, cambios, instrucciones de actualización y guía de migración si hay breaking changes.
 
+## Paso 9.5 — Evidencia de procedencia (cadena de suministro, ADR-0038)
+
+Genera la evidencia de cadena de suministro del release: SBOM CycloneDX del
+árbol runtime + SHA256SUMS del tarball. No publica nada; produce artefactos
+versionados en `releases/v[nueva-versión]/`.
+
+```bash
+node scripts/lib/evidencia-release.js --version [nueva-versión]
+```
+
+Esto escribe (vía `scripts/lib/evidencia-release.js`):
+- `releases/v[nueva-versión]/sbom-v[nueva-versión].cdx.json` — SBOM CycloneDX
+  runtime-only (`npm sbom --sbom-format cyclonedx --omit dev`).
+- `releases/v[nueva-versión]/SHA256SUMS` — checksum del tarball de `npm pack`.
+
+Luego:
+
+1. **Insertar la sección "Integridad y verificación"** en
+   `RELEASE-NOTES-v[nueva-versión].md`, justo después de la sección de
+   correcciones. La genera `seccionVerificacionNotas` de la lib:
+
+   ```bash
+   node -e "const {seccionVerificacionNotas}=require('./scripts/lib/evidencia-release');const fs=require('fs');const v='[nueva-versión]';const sums=fs.readFileSync('releases/v'+v+'/SHA256SUMS','utf8').trim().split(/\s+/);const md=seccionVerificacionNotas({version:v,hash:sums[0],tarball:sums[1]});console.log(md)"
+   ```
+
+   Copiar ese markdown a RELEASE-NOTES (tras "Correcciones").
+
+2. **Copiar las RELEASE-NOTES** a la carpeta del release como evidencia
+   versionada:
+
+   ```bash
+   cp RELEASE-NOTES-v[nueva-versión].md releases/v[nueva-versión]/
+   git add releases/v[nueva-versión]/
+   ```
+
+`releases/` NO viaja en el tarball npm (`package.json#files` es allowlist y no
+lo incluye) — es evidencia del repo, no del paquete. Verificar con
+`npm pack --dry-run | grep -c "releases/"` → debe ser `0`.
+
+**Provenance (opt-in)**: el publish default sigue siendo local
+(`scripts/publicar.js`). Para publicar a npmjs con `npm publish --provenance`
+(que exige OIDC desde CI) usar el workflow opt-in
+`.github/workflows/publish-npm.yml` (trigger `workflow_dispatch`, `dry_run`
+default true). GitHub Packages permanece local. Runbook de verificación para
+el consumidor: `docs/verificacion-consumidor.md`.
+
 ## Paso 10 — Verificación final
 
 ### 10.1 Gate automática anti-gap (OBLIGATORIA antes del push)