@saulwade/swl-ses 2.0.0 → 2.1.0

package/agentes/_propose-step.md

@@ -0,0 +1,90 @@
+<!--
+Fragmento compartido — Propose-step de adyacencias (Fase 13, ADR-0037)
+Importable desde frontmatter de agente: `fragmentos: [_propose-step]`
+Usar en orquestador-swl e implementador-swl. NO routable, NO invocable con Skill.
+Ver reglas/seguridad-agentes.md y .planning/adrs/0037-propose-step-presupuesto-autonomia.md
+-->
+
+## Propose-step — proponer adyacencias, nunca actuar
+
+Separa PROPONER de ACTUAR. Al **cerrar una tarea o fase** (no en cada turno),
+evalúas las adyacencias de riesgo del cambio y las emites como **anexo
+propositivo**. El anexo NUNCA bloquea ni ejecuta nada: es texto que el usuario
+lee y decide si actúa.
+
+### Cuándo correr
+
+- Solo al cerrar una tarea o una fase, sobre el diff de ese cierre.
+- Nunca en mitad de la implementación (evita ruido por turno).
+- Si `SWL_PROPOSE=0`, el propose-step queda desactivado: silencio total.
+
+### Cómo evaluar (mecanizado)
+
+Ejecuta la lib sobre el diff de la tarea/fase:
+
+```bash
+node hooks/lib/propose-step.js --rango=HEAD~1..HEAD
+```
+
+Imprime el anexo solo si detecta ≥1 señal; silencio si no hay nada. Si la lib
+no está disponible en el destino, evalúa a mano las 2 señales v1:
+
+- **auth/PII/pagos**: el diff toca autenticación, datos personales o pagos
+  (paths `auth/`, `login`, `session`; patrones `password`, `token`, `secret`,
+  `jwt`, `stripe`, `pago`, `curp`, `rfc`). → Sugerir revisión de seguridad y
+  tests de autorización.
+- **migración de schema**: el diff toca `models/`, `migrations/`, `*.sql`, o
+  contiene `ALTER/CREATE/DROP TABLE`. → Sugerir plan de rollback /
+  expand-contract y verificar reversibilidad.
+
+### Formato del anexo
+
+Solo cuando hay señal. Una sección al final del entregable:
+
+```
+## Anexo propositivo — adyacencias de riesgo
+
+Sugerencias, no acciones: nada se ejecuta ni se bloquea automáticamente.
+
+- [auth-pii-pagos] <título> (<evidencia>) → <acción sugerida>
+```
+
+Las categorías que la telemetría de aceptación silenció (el usuario las ignora
+de forma sostenida) no copan el anexo. La lib lo maneja con
+`categoriasSilenciadasPropose`.
+
+## Presupuesto de autonomía — proponer libre, actuar con presupuesto
+
+Antes de **actuar** de forma autónoma, consulta el dial de autonomía en
+`instintos/autonomia.yaml` (defaults = `reglas/seguridad-agentes.md`; este
+fragmento NO relaja ningún control). Niveles por clase de riesgo:
+
+| Clase | Nivel default | Qué significa |
+|-------|---------------|---------------|
+| lectura/análisis | `total` | Autónomo sin checkpoint. |
+| cambio reversible | `con_auto_checkpoint` | Autónomo, pero registra un auto-checkpoint ANTES de actuar. |
+| migración / auth / push / publish | `hitl` | Confirmación humana siempre. |
+
+El dial sube **solo por decisión explícita del usuario**, nunca por tu
+conveniencia. Un valor desconocido en el dial degrada a `hitl`.
+
+### Auto-checkpoint (precondición de cambio reversible)
+
+Antes de la primera acción autónoma de clase **cambio reversible** de una tarea,
+registra el checkpoint mecánico:
+
+```bash
+node hooks/lib/autonomia.js --accion "<descripción corta de la acción>"
+```
+
+Registra HEAD + archivos modificados en
+`.planning/user-profile/auto-checkpoints.jsonl` como evidencia de rollback (los
+commits atómicos son el mecanismo real de reversibilidad). Es best-effort: no
+bloquea la acción que protege.
+
+### Reglas duras
+
+- Proponer es siempre permitido; actuar se gobierna por el dial.
+- Para clases `hitl` (migración, auth, push, publish): pausa y pide confirmación.
+- Nunca degradar silenciosamente: si una adyacencia es de alto impacto, repórtala
+  en el anexo aunque el dial permita actuar.

package/agentes/implementador-swl.md

@@ -44,6 +44,8 @@ exclusiones:
   - "No invocar para backend Node.js puro — usar backend-node-swl para mayor profundidad en NestJS, Prisma y ecosistema Node."
   - "No invocar sin PLAN.md aprobado para features complejas — primero pasar por planificador-swl."
   - "No invocar para decisiones de arquitectura — esas decisiones corresponden a arquitecto-swl; este agente ejecuta planes, no los diseña."
+fragmentos:
+  - _propose-step
 ---
 ## Cuándo NO invocarme
 

package/agentes/orquestador-swl.md

@@ -40,6 +40,8 @@ exclusiones:
   - "No invocar para tareas de un solo agente o preguntas técnicas puntuales: el usuario puede invocar el agente especializado directamente sin pasar por el orquestador."
   - "No invocar para tomar decisiones de arquitectura — esas decisiones corresponden a arquitecto-swl; el orquestador solo coordina, no decide."
   - "No invocar cuando ya existe un PLAN.md aprobado y en ejecución activa: en ese caso invocar directamente a implementador-swl con el plan existente."
+fragmentos:
+  - _propose-step
 ---
 Eres el orquestador central del sistema SWL.
 

package/agentes/perfilador-usuario-swl.md

@@ -17,7 +17,7 @@ modeloAlterno: claude-opus-4-7
 ventanaContexto: 200k
 permissionMode: acceptEdits
 color: indigo
-version: 1.0.0
+version: 1.1.0
 nivelRiesgo: MEDIO
 skillsInvocables: [perfil-usuario, aprendizaje-continuo, memoria-busqueda, privacy-memoria]
 permisosRed: false
@@ -109,10 +109,23 @@ tercero (perfil del usuario). **No cruces los carriles:**
 | Sesiones con commits aceptados | 0.6 | Trabajo validado implícitamente |
 | Sesiones con correcciones frecuentes | 0.4 | Señal de fricción, no de preferencia firme |
 | `instintos/proyecto.yaml` con evidence_count ≥3 | 0.7 | Patrón observado en proyecto |
+| `.planning/user-profile/briefing-telemetria.json` categoría `silenciada:true` | 0.6 | El usuario ignora consistentemente esa categoría de señal proactiva |
 
 **Nunca** uses tool outputs crudos ni logs de errores como evidencia directa
 de preferencia — el ruido es alto.
 
+### Telemetría de aceptación del briefing (Fase 12, ADR-0036)
+
+El hook `session-briefing.js` mantiene `.planning/user-profile/briefing-telemetria.json`
+con, por categoría de señal (`adr-vencido`, `deuda-trigger`, `nudges-pendientes`,
+`gate-calibracion`, `continue-here`), los contadores `{mostrado, actuado, ignorado,
+silenciada}`. Al consolidar el perfil, leer este archivo como señal de **preferencias
+de proactividad**: una categoría con `silenciada:true` (ratio ignorado/mostrado ≥0.8
+con ≥5 muestras) indica que el usuario no quiere ese tipo de aviso — registrarlo en
+el perfil como preferencia de comunicación, no como anti-patrón técnico (canal A de
+`memoria-consolidada.md`, no APRENDIZAJES). NO inferir más de lo que los contadores
+dicen: actuado≠preferencia positiva fuerte, solo "resolvió la señal".
+
 ## Estructura del perfil (`instintos/perfil-usuario.yaml`)
 
 ```yaml

package/bin/swl-ses.js

@@ -192,7 +192,7 @@ GESTIÓN DE COMPONENTES:
 OPCIONES DE INSTALL:
   --target <runtime>     Runtime destino: claude|openclaude|copilot|opencode|codex|gemini|cursor (default: claude)
   --profile <perfil>     Perfil: core|backend-python|backend-node|frontend-react|frontend-angular|
-                         fullstack-python-angular|fullstack-node-react|mobile|devops|completo (default: core)
+                         fullstack-python-angular|fullstack-node-react|mobile|devops|completo (default: completo)
   --with <componentes>   Incluir componentes adicionales (separados por coma)
   --without <comps>      Excluir componentes (separados por coma)
   --global               Instalar en directorio global del runtime (~/.claude, etc.)

package/comandos/swl/aprobar-plan.md

@@ -51,8 +51,9 @@ Lee el campo `estado:` del frontmatter:
 
 ## Paso 2.5 — Validar la matriz REQ×T (trazabilidad G4)
 
-Lee `.planning/fases/0N-CONTEXTO.md` y extrae los IDs `REQ-NN:` de la sección de
-criterios de aceptación.
+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.

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

@@ -218,16 +218,19 @@ Estructura del archivo:
 [descripción de pantallas]
 
 ## 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]
+[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-NN`; los REQ satisfechos por prosa/docs/configuración llevan la
-anotación `(verificación: inspección)` en el criterio — exigen tarea y commit
+`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

package/comandos/swl/ejecutar-fase.md

@@ -167,6 +167,12 @@ 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.

package/comandos/swl/planear-fase.md

@@ -181,9 +181,11 @@ fases técnicas puras — Gherkin sin lector de negocio es ceremonia.]
 ## 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.]
+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 |
 |-----|------------------------|

package/comandos/swl/release.md

@@ -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)

package/comandos/swl/status.md

@@ -23,6 +23,8 @@ funcionalidad ni de flags.
 /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 dora                   — Métricas DORA del proyecto destino (deploy freq, lead time, CFR, MTTR)
+/swl:status dora --dias=N          — Ventana de medición de N días (default 30)
 /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
@@ -42,6 +44,7 @@ como vista por defecto si el contexto lo sugiere.
 | `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` |
+| `dora` | `scripts/lib/metricas-dora.js` + `.planning/evolution/metricas-dora.json` | nuevo (Fase 15, ADR-0039) |
 | `historico` / `dashboard` | `Skill("swl-dashboard")` | `/swl:dashboard` |
 
 ---
@@ -53,6 +56,25 @@ Diagnóstico de salud del sistema SWL con **verificaciones deterministas**
 **Solo lectura** — no modifica nada salvo `SALUD.md`. Para corregir problemas,
 usar `/swl:evolucionar`.
 
+**Paso 0 — Detección host vs consumidor (gate determinista, OBLIGATORIO)**:
+
+`salud` audita los componentes del sistema SWL con un score ponderado. Ese score
+solo tiene sentido en el repo que **hospeda** los componentes (swl-ses o un fork).
+En un proyecto **consumidor** (usa las convenciones SWL vía `~/.claude/` pero no
+aloja `agentes/`, `habilidades/`, `comandos/swl/`, `reglas/`, `hooks/`), el
+inventario daría 0 y un score `0/100` sería señal falsa. Esta distinción es
+**determinista**, NO juicio del agente:
+
+```bash
+node scripts/lib/detectar-host-swl.js --json
+```
+
+- Si `esHost: true` → continuar con el diagnóstico normal (Carga + pasos siguientes).
+- Si `esHost: false` → **NO** calcular score de componentes ni generar `SALUD.md`
+  con `0/100`. Reportar el campo `razon` y la lista `sugerencias` (subcomandos de
+  `/swl:status` que sí aplican aquí: `metricas`, `loops`, `evolucion`, `dashboard`).
+  Ofrecer ejecutar uno de ellos. Terminar sin penalizar el score.
+
 **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.
@@ -225,6 +247,53 @@ archivo, sin prosa.
 
 ---
 
+## Subcomando: `dora`
+
+Métricas DORA (DevOps Research and Assessment) del **proyecto destino** donde SWL
+está instalado: deployment frequency, lead time for changes, change failure rate
+y MTTR, cada una clasificada en elite/high/medium/low (umbrales DORA Report 2023).
+Mide **velocidad de entrega**, ortogonal a la reliability en runtime de
+`observabilidad-swl`/`sre-swl`. Solo lectura salvo el JSON de storage.
+
+**Portabilidad** (D-15-01): deployment frequency + lead time se derivan de git
+(tags de release + commits) y están **siempre** disponibles. Change failure rate
++ MTTR requieren `gh` (GitHub CLI) autenticado; si `gh` falta, no está autenticado,
+o el repo no tiene remoto GitHub, esas dos reportan "no disponible" **sin fallar**.
+
+**Paso 0 — calcular/regenerar**:
+```bash
+node scripts/lib/metricas-dora.js --json [--dias=N]
+```
+Regenera siempre que se invoque el subcomando (la medición es barata) o cuando se
+pase `--dias=N` (ventana en días, default 30). El script persiste el informe en
+`.planning/evolution/metricas-dora.json` (runtime, gitignored).
+
+**Paso 1 — render**: presentar las 4 métricas con su valor y clasificación:
+
+```
+Métricas DORA — ventana de 30 días
+
+  Deployment frequency:  2.30 deploys/semana   [high]
+  Lead time (p50):       18.4 h                 [high]
+  Change failure rate:   no disponible (gh ausente)
+  MTTR:                  no disponible (gh ausente)
+```
+
+Reglas de render:
+- Si una métrica git reporta `sinDatos: true` (proyecto sin tags de release),
+  mostrar "sin datos" — distinto de "frecuencia baja". El informe NO penaliza:
+  un proyecto sin releases no es "low", es "sin datos".
+- Si `changeFailureRate`/`mttr` traen `disponible: false`, mostrar
+  "no disponible (gh ausente)" con la `razon` si ayuda — nunca como error.
+- Tras el render, si CFR/MTTR no están disponibles, sugerir (1 línea) instalar y
+  autenticar `gh` para habilitarlas; no es obligatorio.
+
+**Anti-substitution**: el archivo de storage es **siempre**
+`.planning/evolution/metricas-dora.json` (nunca `metricas.json`, que es del ciclo
+de evolución); el script es **siempre** `scripts/lib/metricas-dora.js`.
+
+---
+
 ## Subcomando: `historico` / `dashboard`
 
 Dashboard histórico multi-sesión vía `claude-usage` (vendored). Complementa

package/comandos/swl/verificar.md

@@ -496,8 +496,9 @@ Sin `--until-converge`, el comportamiento del comando es idéntico al actual: un
 
 ### 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:
+Si la sección de criterios del CONTEXTO usa IDs `REQ-NN:` (fases 10-11) o
+`REQ-<fase>-NN:` (namespaceados, fases ≥12), ejecuta el validador de cadena
+ANTES de la verificación criterio por criterio:
 
 ```bash
 node scripts/verificar-trazabilidad.js --fase=N

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

@@ -53,15 +53,17 @@ const { execSync } = require('node:child_process');
  *   [T-01] feat(hooks): prefijo de trazabilidad de tarea (ejecutar-fase)
  *   [T-07][T-08] refactor(hooks): varios prefijos consecutivos
  *   [REQ-08] feat(scripts): prefijo de requisito
+ *   [F12·T-01] feat(hooks): prefijo namespaceado por fase (DT-IDS-NAMESPACE)
  *
- * El prefijo opcional `[T-NN]` / `[REQ-NN]` (uno o más, consecutivos) proviene
- * de la convención de commits de `habilidades/ejecutar-fase/SKILL.md`
- * (trazabilidad de tarea/requisito). No altera la semántica CC: el
+ * El prefijo opcional `[T-NN]` / `[REQ-NN]` / `[F<fase>·T-NN]` (uno o más,
+ * consecutivos) proviene de la convención de commits de
+ * `habilidades/ejecutar-fase/SKILL.md` (trazabilidad de tarea/requisito; desde
+ * la Fase 12 los IDs se namespacean por fase). No altera la semántica CC: el
  * tipo+scope+descripción siguen presentes después del/los prefijo(s), por lo
  * que el commit cuenta como conforme. Grupo non-capturing para no desplazar
  * los índices [1]=tipo [2]=scope [3]=! [4]=descripcion.
  */
-const RE_CONVENTIONAL = /^(?:\[(?:T|REQ)-\d+\]\s*)*(feat|fix|perf|refactor|docs|style|test|ci|build|chore|revert|evolucion|evolve)(?:\(([^)]+)\))?(!)?:\s*(.+)$/;
+const RE_CONVENTIONAL = /^(?:\[(?:F\d+·)?(?:T|REQ)-\d+(?:-\d+)?\]\s*)*(feat|fix|perf|refactor|docs|style|test|ci|build|chore|revert|evolucion|evolve)(?:\(([^)]+)\))?(!)?:\s*(.+)$/;
 
 /** Mapa tipo CC → categoría Keep a Changelog en es-MX. */
 const CATEGORIAS = Object.freeze({