@saulwade/swl-ses 2.2.4 → 2.3.1

package/comandos/swl/aprobar-plan.md

@@ -1,141 +1,146 @@
----
-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.
-
-> **Invocación cross-scope** (ver `@docs/invocacion-cli-cross-scope.md`): las
-> partes deterministas del gate viven en subcomandos del CLI. Resuélvelos así:
-> si existe `./scripts/cli/<sub>.js` (repo madre) usa `node scripts/cli/<sub>.js`;
-> si `command -v swl-ses` responde usa `swl-ses <sub>`; si no,
-> `npx -y @saulwade/swl-ses@latest <sub>`. Abajo escribo la forma `swl-ses <sub>`
-> como canónica. NUNCA uses `node -e "require('./scripts/lib/...')"` — esa ruta no
-> existe en proyectos downstream.
-
-## 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
-  swl-ses verificar-plan --fase=N
-  ```
-  - 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
-  swl-ses verificar-trazabilidad --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 y marcar la fase activa** — un solo subcomando hace las tres
-   operaciones deterministas: firma SHA256 → `.planning/locks/0N-PLAN.md.lock`,
-   verifica la firma, y escribe `.planning/locks/fase-activa.json` (gate G0 que
-   consume `hooks/spec-gate.js`):
-   ```bash
-   swl-ses aprobar-plan --fase=N
-   ```
-   Verifica en la salida JSON que `ok: true` y `modo: "firmado"`. Si reporta
-   error de firma, **NO continúes** — revisa el `motivo`.
-
-   El `.lock` SÍ se versiona en git (evidencia de aprobación, parte del audit
-   trail SDD). El `fase-activa.json` es runtime local (gitignored);
-   `/swl:ejecutar-fase` lo elimina al cerrar la fase. Re-ejecutar
-   `swl-ses aprobar-plan --fase=N` tras una re-aprobación (plan mutado) realinea
-   lock y fase-activa automáticamente.
-
-## 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.
+---
+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.
+
+> **Invocación cross-scope** (ver `@docs/invocacion-cli-cross-scope.md`): las
+> partes deterministas del gate viven en subcomandos del CLI. Resuélvelos así:
+> si existe `./scripts/cli/<sub>.js` (repo madre) usa `node scripts/cli/<sub>.js`;
+> si `command -v swl-ses` responde usa `swl-ses <sub>`; si no,
+> `npx -y @saulwade/swl-ses@latest <sub>`. Abajo escribo la forma `swl-ses <sub>`
+> como canónica. NUNCA uses `node -e "require('./scripts/lib/...')"` — esa ruta no
+> existe en proyectos downstream.
+
+## 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
+  swl-ses verificar-plan --fase=N
+  ```
+  - 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
+  swl-ses verificar-trazabilidad --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.
+  - **WARN "headers de tarea malformados"** (warn-only, no cambia el exit): si el
+    reporte lista headers como `#### T-01 — ...`, son la **causa silenciosa** de
+    REQ huérfanos. El parser de la matriz exige `### T-NN:` (2-4 `#`, dos puntos
+    tras el ID; nunca em-dash). Corrige el separador en el PLAN y re-ejecuta antes
+    de aprobar — un header con `—` deja la tarea invisible aunque declare su REQ.
+
+## 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 y marcar la fase activa** — un solo subcomando hace las tres
+   operaciones deterministas: firma SHA256 → `.planning/locks/0N-PLAN.md.lock`,
+   verifica la firma, y escribe `.planning/locks/fase-activa.json` (gate G0 que
+   consume `hooks/spec-gate.js`):
+   ```bash
+   swl-ses aprobar-plan --fase=N
+   ```
+   Verifica en la salida JSON que `ok: true` y `modo: "firmado"`. Si reporta
+   error de firma, **NO continúes** — revisa el `motivo`.
+
+   El `.lock` SÍ se versiona en git (evidencia de aprobación, parte del audit
+   trail SDD). El `fase-activa.json` es runtime local (gitignored);
+   `/swl:ejecutar-fase` lo elimina al cerrar la fase. Re-ejecutar
+   `swl-ses aprobar-plan --fase=N` tras una re-aprobación (plan mutado) realinea
+   lock y fase-activa automáticamente.
+
+## 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/briefing.md

@@ -1,119 +1,119 @@
----
-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
-# Subcomando del CLI (resuelve cross-scope; ver docs/invocacion-cli-cross-scope.md)
-swl-ses briefing
-# fallback: npx -y @saulwade/swl-ses@latest briefing
-```
-
-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
-swl-ses derivar-feature-list --check 2>/dev/null; echo "exit: $?"
-```
-
-Exit 2 → reportar que `HOJA-RUTA.md` y `feature-list.json` divergieron, con la
-acción `swl-ses derivar-feature-list` 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.
+---
+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
+# Subcomando del CLI (resuelve cross-scope; ver docs/invocacion-cli-cross-scope.md)
+swl-ses briefing
+# fallback: npx -y @saulwade/swl-ses@latest briefing
+```
+
+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
+swl-ses derivar-feature-list --check 2>/dev/null; echo "exit: $?"
+```
+
+Exit 2 → reportar que `HOJA-RUTA.md` y `feature-list.json` divergieron, con la
+acción `swl-ses derivar-feature-list` 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.