@saulwade/swl-ses 2.4.2 → 2.5.1

package/bin/lib/bot-comandos.js

@@ -696,7 +696,7 @@ function cmdCosto(argDias) {
       bindParam   = limiteSeg;
     } else {
       // ISO 8601 string — usar comparación de string (funciona para fechas ISO)
-      const fechaIso = new Date(limiteMs).toISOString().slice(0, 10);
+      const fechaIso = new Date(limiteMs).toLocaleDateString('sv');
       whereClause = `WHERE ${colTimestamp} >= ?`;
       bindParam   = fechaIso;
     }

package/bin/swl-ses.js

@@ -106,6 +106,9 @@ const COMANDOS = {
   doctor: '../scripts/doctor.js',
   update: '../scripts/actualizar.js',
   uninstall: '../scripts/desinstalar.js',
+  prune: '../scripts/prune.js',
+  valor: '../scripts/evidencia-valor.js',
+  'field-report': '../scripts/field-report.js',
   'check-update': '../scripts/check-update.js',
   'install-git-hook': '../scripts/instalar-git-hook.js',
   'audit-claudemd': '../scripts/cli/audit-claudemd.js',
@@ -161,6 +164,9 @@ COMANDOS PRINCIPALES:
   doctor                        Diagnóstica problemas de instalación
   update                        Actualiza componentes instalados
   uninstall                     Desinstala componentes del runtime
+  prune                         Purga componentes retirados del paquete (dry-run; --confirmar ejecuta)
+  valor                         Panel de evidencia de valor del harness (intercepciones, defectos, DORA/CI, uso; --json, --dias N)
+  field-report                  Reporte de agregados anónimos para compartir con el autor (opt-in, revisión manual)
   check-update                  Fuerza consulta inmediata de nueva versión en npm (sin throttle)
   install-git-hook [--force]    Instala pre-commit hook que avisa de nuevas versiones.
                                 Útil para CLIs que no son Claude Code (Codex, Copilot,

package/comandos/swl/adoptar-proyecto.md

@@ -237,10 +237,22 @@ Hallazgos clave:
 
 Riesgo principal: [descripción]
 
-Próximo paso recomendado:
-  /swl:discutir-fase 1    ← para definir la primera fase de trabajo
+Próximos pasos recomendados:
+  /swl:discutir-fase 1       ← para definir la primera fase de trabajo
+  /swl:seguridad --rapido    ← baseline de seguridad del proyecto adoptado
+                               (secretos en repo+historial + CVEs en deps);
+                               obligatorio recomendarlo si TRAMPAS.md detectó
+                               manejo de auth, pagos o datos personales
+  /swl:configurar-ci init    ← si el repo vive en GitHub y no tiene pipelines
+                               (documentar la ausencia de CI ya es hallazgo)
 ```
 
+Si el usuario acepta correr `/swl:seguridad --rapido`, su reporte de postura
+queda en `.planning/audit/` y los hallazgos CRÍTICOS se listan como "Puntos a
+resolver" del arranque — un proyecto adoptado con secretos en el historial no
+debe empezar fases nuevas sin decidir qué hacer con ellos (Hallazgo C de
+`arreglar-al-detectar.md`).
+
 ## Reglas de comportamiento
 
 - NUNCA inventar información que no se detectó ni el usuario proporcionó. Si un campo no se puede inferir, dejarlo con nota "Pendiente — definir con `/swl:discutir-fase`".

package/comandos/swl/configurar-ci.md

@@ -48,12 +48,19 @@ Mostrar al usuario qué se detectó y confirmar que es el proyecto correcto.
 
 [ ] release-please.yml — Releases automáticos desde conventional commits
     Sin secrets adicionales. Requiere conventional commits.
+
+[ ] swl-devsecops.yml — Gates de seguridad del pipeline: gitleaks (secretos,
+    historial completo) + auditoría de dependencias por ecosistema (npm/pip/cargo)
+    Sin secrets en repos personales; en repos de ORGANIZACIÓN gitleaks exige
+    GITLEAKS_LICENSE (gratuita para individuos). Los gates avanzados
+    (SAST/Trivy/DAST) se configuran por proyecto — ver Skill("devsecops-pipeline-security").
 ```
 
 Si el usuario omite `init` e invoca con flags directos, respetar esos flags sin preguntar:
 - `--with-security` / `--no-security`
 - `--with-ci` / `--no-ci`
 - `--with-release-please`
+- `--with-devsecops`
 - `--dry-run`
 - `--force`
 
@@ -65,7 +72,7 @@ Invocar el subcomando del CLI (resuelve cross-scope; ver
 
 ```bash
 swl-ses configurar-ci init
-# flags: --no-security  --no-ci  --with-release-please  --dry-run  --force
+# flags: --no-security  --no-ci  --with-release-please  --with-devsecops  --dry-run  --force
 # fallback: npx -y @saulwade/swl-ses@latest configurar-ci init
 ```
 

package/comandos/swl/deuda-codigo.md

@@ -1,97 +1,97 @@
----
-name: swl:deuda-codigo
-description: Cosecha los marcadores `simplificado:` del código (simplificaciones deliberadas con techo y trigger de upgrade) hacia un ledger visible, detecta marcadores sin trigger (riesgo de rot) y sincroniza opcionalmente con .planning/DEUDA-TECNICA.md. Cargar cuando el usuario pida "qué simplificamos", "deuda de código", "cosecha los marcadores", o tras una fase que dejó marcadores simplificado:.
-allowed_tools: ["Grep", "Read", "Edit", "Bash"]
----
-
-# /swl:deuda-codigo — Cosecha de simplificaciones deliberadas
-
-Todo atajo intencional marcado con `simplificado: <techo>, <trigger>` (convención
-de `Skill("prevencion-sobreingenieria")`, adaptada del patrón `ponytail:` de
-ponytail, MIT) se cosecha aquí en un ledger — para que un "después" no se
-convierta en "nunca" (regla `arreglar-al-detectar.md`).
-
-## Uso
-
-```
-/swl:deuda-codigo              — Reporte en pantalla (no escribe nada)
-/swl:deuda-codigo --sync       — Además sincroniza a .planning/DEUDA-TECNICA.md
-/swl:deuda-codigo --owners     — Agrega autor por marcador (git blame)
-/swl:deuda-codigo <directorio> — Limita la cosecha a un subárbol
-```
-
-## Paso 1 — Cosechar los marcadores
-
-Buscar con Grep (herramienta, no shell) el patrón sobre el árbol del proyecto,
-excluyendo `node_modules`, `.git`, `dist`, `build`, `temp`, `respositorios-git`:
-
-```
-Grep(pattern: "(#|//|--|<!--|/\\*)\\s?simplificado:", output_mode: "content", -n: true)
-```
-
-Cada hit es una fila del ledger. El prefijo de comentario evita capturar prosa
-que solo menciona la convención (como este archivo o el SKILL.md).
-
-## Paso 2 — Parsear techo y trigger
-
-La convención es `simplificado: <techo>, <trigger de upgrade>`:
-
-- **techo**: el límite conocido del atajo (lock global, O(n²), heurística naive).
-- **trigger**: la condición observable que obliga el upgrade ("si throughput > X",
-  "cuando haya un segundo consumidor", "antes del primer deploy productivo").
-
-Si el texto tras `simplificado:` no contiene una condición observable,
-etiquetar la fila `sin-trigger` — esos son los que rotan en silencio.
-
-## Paso 3 — Reporte
-
-Una fila por marcador, agrupado por archivo:
-
-```
-## Ledger de simplificaciones — [fecha]
-
-| Ubicación | Qué se simplificó | Techo | Trigger de upgrade | Estado |
-|---|---|---|---|---|
-| src/locks.py:42 | lock global | contención con N workers | throughput > 500 rps | ok |
-| api/cache.js:17 | TTL fijo 5 min | staleness | (ninguno) | sin-trigger |
-
-Total: N marcadores, M sin trigger.
-```
-
-Con `--owners`: agregar columna con `git blame -L<línea>,<línea> --porcelain <archivo>`
-(solo el autor, una llamada por fila).
-
-Si no hay marcadores: `Sin deuda simplificado:. Ledger limpio.` — y terminar.
-
-## Paso 4 — Sincronizar al ledger formal (solo con --sync)
-
-Para cada marcador `sin-trigger` o de techo relevante que no exista ya en
-`.planning/DEUDA-TECNICA.md`:
-
-1. Leer el ledger actual y verificar duplicados por ubicación (`archivo:línea`).
-2. Agregar entrada `### DT-SIMPLIFICADO-<n>` con: ubicación, techo, trigger
-   (o `PENDIENTE DE TRIGGER` marcado como acción requerida), fecha de cosecha.
-3. Los `sin-trigger` NO se sincronizan como DT válidas hasta tener trigger:
-   reportarlos al usuario como acción inmediata — una DT sin trigger verificable
-   viola `arreglar-al-detectar.md § DT formal`.
-
-NUNCA borrar ni editar los marcadores del código durante la cosecha: el
-comando lee y reporta; el código solo cambia cuando el trigger se cumple y
-el upgrade se implementa.
-
-## Cuándo usarlo
-
-- Cierre de fase (`/swl:verificar` lo puede invocar como pasada complementaria).
-- Antes de un release: los `sin-trigger` son bloqueo blando (reportar en el gate).
-- Auditorías de deuda: junto con la sección "Sobre-ingeniería" de `/swl:revisar`.
-
-## Gotchas
-
-- **Marcadores en fixtures o docs**: los hits dentro de `tests/fixtures/`,
-  ejemplos de skills o este propio comando son material de referencia, no deuda
-  — excluirlos del conteo y decir cuántos se excluyeron (sin caps silenciosos).
-- **Prefijos de comentario por stack**: el patrón cubre `#` (Python/shell),
-  `//` (JS/TS/Go/Rust/C#/Java), `--` (SQL/Lua), `<!--` (HTML/MD) y `/*` (CSS/C).
-  Si el proyecto usa otro prefijo, agregarlo al patrón y decirlo en el reporte.
-- **`git blame` sobre archivos renombrados**: usar `git blame -M -C` si el
-  autor aparece como el commit del rename.
+---
+name: swl:deuda-codigo
+description: Cosecha los marcadores `simplificado:` del código (simplificaciones deliberadas con techo y trigger de upgrade) hacia un ledger visible, detecta marcadores sin trigger (riesgo de rot) y sincroniza opcionalmente con .planning/DEUDA-TECNICA.md. Cargar cuando el usuario pida "qué simplificamos", "deuda de código", "cosecha los marcadores", o tras una fase que dejó marcadores simplificado:.
+allowed_tools: ["Grep", "Read", "Edit", "Bash"]
+---
+
+# /swl:deuda-codigo — Cosecha de simplificaciones deliberadas
+
+Todo atajo intencional marcado con `simplificado: <techo>, <trigger>` (convención
+de `Skill("prevencion-sobreingenieria")`, adaptada del patrón `ponytail:` de
+ponytail, MIT) se cosecha aquí en un ledger — para que un "después" no se
+convierta en "nunca" (regla `arreglar-al-detectar.md`).
+
+## Uso
+
+```
+/swl:deuda-codigo              — Reporte en pantalla (no escribe nada)
+/swl:deuda-codigo --sync       — Además sincroniza a .planning/DEUDA-TECNICA.md
+/swl:deuda-codigo --owners     — Agrega autor por marcador (git blame)
+/swl:deuda-codigo <directorio> — Limita la cosecha a un subárbol
+```
+
+## Paso 1 — Cosechar los marcadores
+
+Buscar con Grep (herramienta, no shell) el patrón sobre el árbol del proyecto,
+excluyendo `node_modules`, `.git`, `dist`, `build`, `temp`, `respositorios-git`:
+
+```
+Grep(pattern: "(#|//|--|<!--|/\\*)\\s?simplificado:", output_mode: "content", -n: true)
+```
+
+Cada hit es una fila del ledger. El prefijo de comentario evita capturar prosa
+que solo menciona la convención (como este archivo o el SKILL.md).
+
+## Paso 2 — Parsear techo y trigger
+
+La convención es `simplificado: <techo>, <trigger de upgrade>`:
+
+- **techo**: el límite conocido del atajo (lock global, O(n²), heurística naive).
+- **trigger**: la condición observable que obliga el upgrade ("si throughput > X",
+  "cuando haya un segundo consumidor", "antes del primer deploy productivo").
+
+Si el texto tras `simplificado:` no contiene una condición observable,
+etiquetar la fila `sin-trigger` — esos son los que rotan en silencio.
+
+## Paso 3 — Reporte
+
+Una fila por marcador, agrupado por archivo:
+
+```
+## Ledger de simplificaciones — [fecha]
+
+| Ubicación | Qué se simplificó | Techo | Trigger de upgrade | Estado |
+|---|---|---|---|---|
+| src/locks.py:42 | lock global | contención con N workers | throughput > 500 rps | ok |
+| api/cache.js:17 | TTL fijo 5 min | staleness | (ninguno) | sin-trigger |
+
+Total: N marcadores, M sin trigger.
+```
+
+Con `--owners`: agregar columna con `git blame -L<línea>,<línea> --porcelain <archivo>`
+(solo el autor, una llamada por fila).
+
+Si no hay marcadores: `Sin deuda simplificado:. Ledger limpio.` — y terminar.
+
+## Paso 4 — Sincronizar al ledger formal (solo con --sync)
+
+Para cada marcador `sin-trigger` o de techo relevante que no exista ya en
+`.planning/DEUDA-TECNICA.md`:
+
+1. Leer el ledger actual y verificar duplicados por ubicación (`archivo:línea`).
+2. Agregar entrada `### DT-SIMPLIFICADO-<n>` con: ubicación, techo, trigger
+   (o `PENDIENTE DE TRIGGER` marcado como acción requerida), fecha de cosecha.
+3. Los `sin-trigger` NO se sincronizan como DT válidas hasta tener trigger:
+   reportarlos al usuario como acción inmediata — una DT sin trigger verificable
+   viola `arreglar-al-detectar.md § DT formal`.
+
+NUNCA borrar ni editar los marcadores del código durante la cosecha: el
+comando lee y reporta; el código solo cambia cuando el trigger se cumple y
+el upgrade se implementa.
+
+## Cuándo usarlo
+
+- Cierre de fase (`/swl:verificar` lo puede invocar como pasada complementaria).
+- Antes de un release: los `sin-trigger` son bloqueo blando (reportar en el gate).
+- Auditorías de deuda: junto con la sección "Sobre-ingeniería" de `/swl:revisar`.
+
+## Gotchas
+
+- **Marcadores en fixtures o docs**: los hits dentro de `tests/fixtures/`,
+  ejemplos de skills o este propio comando son material de referencia, no deuda
+  — excluirlos del conteo y decir cuántos se excluyeron (sin caps silenciosos).
+- **Prefijos de comentario por stack**: el patrón cubre `#` (Python/shell),
+  `//` (JS/TS/Go/Rust/C#/Java), `--` (SQL/Lua), `<!--` (HTML/MD) y `/*` (CSS/C).
+  Si el proyecto usa otro prefijo, agregarlo al patrón y decirlo en el reporte.
+- **`git blame` sobre archivos renombrados**: usar `git blame -M -C` si el
+  autor aparece como el commit del rename.

package/comandos/swl/discutir-fase.md

@@ -25,8 +25,8 @@ Antes del cuestionario adaptativo completo, el agente clasifica la petición en
 |------|--------------|--------|
 | **RUTA_A** — Extender fase existente | La petición agrega tareas a una fase ya planeada. | Saltar cuestionario; cargar el CONTEXTO.md existente y agregar tareas. |
 | **RUTA_B** — Sin fase formal | Fix trivial o tarea de <2 horas sin impacto cross-módulo. | Saltar cuestionario; proceder con `/swl:ejecutar-fase` directamente. |
-| **RUTA_C** — Nueva fase single-scope | Petición nueva, no encaja en fases existentes, single-domain. | Ejecutar cuestionario completo (Bloques 1-4). |
-| **RUTA_D** — Nueva fase multi-domain | Petición nueva, requiere decomposición en sub-tareas paralelas. | Cuestionario completo + planificación de paralelización. |
+| **RUTA_C** — Nueva fase single-scope | Petición nueva, no encaja en fases existentes, single-domain. | Ejecutar cuestionario completo (Bloques 1-5 del skill). |
+| **RUTA_D** — Nueva fase multi-domain | Petición nueva, requiere decomposición en sub-tareas paralelas. | Cuestionario completo (bloques de dominio combinados) + planificación de paralelización. Si produciría >20 tareas, sugerir descomposición en N fases. |
 | **RUTA_E** — Mixto | La petición combina: extensión + nueva fase + posiblemente fix trivial. | Presentar decomposición propuesta y confirmar antes de proceder. |
 
 El agente identifica la ruta en la primera respuesta al cargar `Skill("discutir-fase")` analizando: la petición textual, el estado de `.planning/HOJA-RUTA.md` y el último `RESUMEN.md`. Solo si la ruta es C o D se ejecuta el cuestionario completo descrito a continuación.
@@ -73,61 +73,19 @@ Haré algunas preguntas para entender los detalles. Puedes responder con todo el
 
 ## Paso 3 — Entrevista adaptativa por bloques
 
-La entrevista se adapta al tipo de fase. Primero determina el tipo leyendo la descripción:
+**El cuestionario canónico vive en `Skill("discutir-fase")`** — este comando NO
+define preguntas propias (única fuente, evita deriva). Aplica los 5 bloques del
+skill en orden:
 
-- **Fase de infraestructura/setup**: preguntas sobre entorno, herramientas, CI/CD
-- **Fase de backend/API**: preguntas sobre modelos de datos, endpoints, reglas de negocio
-- **Fase de frontend/UI**: preguntas sobre pantallas, flujos de usuario, componentes
-- **Fase de integración**: preguntas sobre sistemas externos, formatos, protocolos
-- **Fase de datos/migración**: preguntas sobre volumen, transformaciones, rollback
-- **Fase mixta**: combina bloques relevantes
+1. **Bloque 1 — Contexto** (siempre): objetivo, criterio de terminación, claridad del roadmap, restricciones de tiempo/presupuesto, decisiones previas, supuestos explícitos.
+2. **Bloque 2 — Dominio** (adaptativo): backend/API, frontend/UI, infraestructura, integración, datos/migración. Determina el tipo leyendo la descripción de la fase; las fases mixtas combinan bloques. Cambios destructivos de datos activan SIEMPRE el bloque Datos/Migración (rollback, integridad, expand-contract).
+3. **Bloque 3 — Calidad, proceso y operación** (si aplica): tests, revisión de seguridad, NFRs, observabilidad, deployment.
+4. **Bloque 4 — Dependencias y riesgos** (siempre).
+5. **Bloque 5 — Criterios de aceptación** (siempre, al final): demostración, pruebas, visto bueno, métrica de outcome.
 
-### Bloque universal (todas las fases)
-
-Presenta primero:
-
-1. ¿Cuál es el entregable más importante de esta fase? ¿Cómo sabremos que está terminada?
-2. ¿Hay algo en esta fase que NO quedó claro en el roadmap y que debemos aclarar ahora?
-3. ¿Cuáles son los riesgos más grandes que ves en esta fase?
-4. ¿Hay decisiones técnicas o de producto que debemos tomar antes de empezar a planear?
-
-### Bloque de dominio (según tipo de fase)
-
-**Si la fase es de backend/API:**
-5. ¿Qué entidades de datos nuevas introduce esta fase? Describe sus campos principales.
-6. ¿Qué endpoints o servicios necesita exponer esta fase?
-7. ¿Hay reglas de negocio complejas o cálculos que deben procesarse?
-8. ¿Qué validaciones son críticas? ¿Qué datos nunca deben llegar corruptos a la BD?
-9. ¿Quién tiene permiso de acceder a qué? ¿Hay roles o restricciones de seguridad?
-
-**Si la fase es de frontend/UI:**
-5. ¿Qué pantallas o vistas nuevas introduce esta fase? Descríbelas.
-6. ¿Cuál es el flujo principal del usuario en esta fase? (de dónde viene, qué hace, adónde va)
-7. ¿Hay componentes que deben reutilizarse del diseño existente o del sistema de diseño?
-8. ¿Qué datos consume cada pantalla? ¿De qué endpoints los obtiene?
-9. ¿Hay estados de carga, error y vacío que debemos considerar explícitamente?
-
-**Si la fase es de infraestructura:**
-5. ¿Cuál es el entorno objetivo? (dev, staging, prod — con diferencias entre ellos)
-6. ¿Hay secretos o variables de entorno que esta fase introduce?
-7. ¿Qué servicios gestionados (cloud) se van a usar?
-8. ¿Cuál es la estrategia de rollback si algo sale mal en despliegue?
-9. ¿Se necesita documentar el proceso de despliegue para el equipo?
-
-**Si la fase es de integración:**
-5. ¿Qué sistema externo se integra? ¿Tienes la documentación de su API?
-6. ¿El sistema externo tiene ambiente de pruebas (sandbox)?
-7. ¿Qué pasa si el sistema externo no responde? ¿Hay timeout y retry definidos?
-8. ¿Se sincronizan datos en tiempo real o en batch?
-9. ¿Hay transformaciones de datos entre los formatos de ambos sistemas?
-
-### Bloque de criterios de aceptación
-
-Siempre al final:
-
-10. ¿Qué debe demostrarle el equipo al usuario/cliente para que la fase se apruebe?
-11. ¿Hay pruebas específicas que deben pasar? (pruebas de humo, de carga, de usuario)
-12. ¿Quién da el visto bueno final de esta fase?
+Respeta las reglas del skill: máximo 4 preguntas por mensaje, clasificar cada
+respuesta como CERRADA / ABIERTA / PENDIENTE al recibirla, no avanzar con
+PENDIENTE en ítems críticos.
 
 ## Paso 4 — Preguntas de seguimiento
 
@@ -137,7 +95,7 @@ Después de las respuestas del Bloque de dominio, revisa si hay ambigüedades. P
 - "Dijiste que los datos se sincronizan 'frecuentemente' — ¿cada cuánto tiempo exactamente?"
 - "Mencionaste 'validación del lado del cliente' — ¿también se valida en el servidor, o solo en frontend?"
 
-Máximo 5 preguntas de seguimiento por fase. Si hay más de 5 ambigüedades, documenta las restantes como "[PENDIENTE DE ACLARAR]" en el CONTEXTO.md.
+Máximo 5 preguntas de seguimiento por fase. Si hay más de 5 ambigüedades, documenta las restantes en el CONTEXTO.md con la taxonomía del skill: `ABIERTA` si el usuario delega la decisión, `PENDIENTE` si bloquea el plan.
 
 ## Paso 5 — Confirmación del entendimiento
 
@@ -184,67 +142,13 @@ el usuario pida desactivarlo explícitamente. Si lo desactiva: exige la razón,
 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
-# Contexto de la Fase N — [nombre de la fase]
-
-**Proyecto**: [nombre del proyecto]
-**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]
-
-## Entregables esperados
-[lista con formato de checklist: - [ ] entregable]
-
-## Requisitos técnicos
-[lista detallada]
-
-## Reglas de negocio
-[lista de reglas, numeradas]
-
-## Modelos de datos (si aplica)
-[descripción de entidades y campos clave]
-
-## Endpoints / servicios (si aplica)
-[lista de endpoints con método, ruta y propósito]
-
-## Pantallas / vistas (si aplica)
-[descripción de pantallas]
-
-## 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]
-
-## Dependencias
-[qué fases previas deben estar completas, qué sistemas externos se necesitan]
-
-## Decisiones pendientes
-[preguntas que quedaron abiertas y deben resolverse antes o durante la ejecución]
-
-## Notas adicionales
-[todo lo que no encajó en las categorías anteriores pero es importante]
-```
+Estructura del archivo: usar la **plantilla canónica**
+`habilidades/discutir-fase/recursos/plantilla-contexto.md` (única fuente,
+compartida con el skill). Leerla antes de escribir; incluye el frontmatter con
+gate TDD, la tabla de decisiones CERRADA/ABIERTA/PENDIENTE, supuestos
+explícitos, no-goals, los criterios de aceptación con REQ-IDs namespaceados
+(`REQ-<fase>-NN`, trazabilidad G4), métrica de outcome, NFRs/observabilidad y
+rollback. Las secciones *(si aplica)* se omiten cuando la fase no las toca.
 
 ## Paso 7 — Reporte al usuario
 
@@ -262,4 +166,4 @@ Al terminar:
 - Si el usuario dice "como siempre" o "igual que antes", pregunta para verificar — las asunciones son la fuente principal de retrabajo.
 - El archivo CONTEXTO.md debe ser comprensible sin haber participado en la conversación.
 - Escribe el archivo en español-MX con formato Markdown limpio.
-- Si el usuario no sabe algo importante, documenta "[POR DEFINIR]" y continúa — no bloquees el proceso.
+- Si el usuario no sabe algo importante: regístralo como `ABIERTA` (si delega la decisión al agente) o `PENDIENTE` (si bloquea el plan) y continúa — no bloquees el proceso, pero NUNCA cierres la discusión con `PENDIENTE` en ítems críticos (Regla 3 del skill).

package/comandos/swl/fix.md

@@ -0,0 +1,118 @@
+---
+name: swl:fix
+description: >
+  Punto de entrada único para reparar fallas: recibe un síntoma (stack trace,
+  test rojo, build roto, CI en rojo, hallazgo de revisión) y hace triage para
+  rutear al fixer correcto — depurador-swl (bug runtime/lógica),
+  resolutor-build-swl (build local), gh-fix-ci-swl (GitHub Actions),
+  /swl:verificar --until-converge (hallazgos de review) o /swl:nemesis
+  --remediar (bugs de lógica profunda). Aplica la política de convergencia
+  común (caps de iteración + escalación) y el contrato transversal de
+  regresión obligatoria post-fix. Usar cuando algo falla y no sabes (o no
+  quieres decidir) qué componente de reparación invocar.
+argument-hint: "[descripción del síntoma / pega el error] [--tipo bug|build|ci|hallazgos]"
+allowed-tools: [Read, Grep, Glob, Bash, Agent, Skill]
+---
+
+# /swl:fix — Triage y despacho de reparaciones
+
+Eres el despachador de reparaciones del sistema. El usuario te da un síntoma;
+tú clasificas, ruteas al fixer especializado correcto y garantizas que el fix
+cierre con regresión verificada. NO reparas directamente — despachas y
+supervisas el contrato de cierre.
+
+## Cuándo usar
+
+- "Esto falla y no sé por qué" — cualquier falla sin fixer obvio.
+- Tras `/swl:seguridad` o `/swl:verificar` con hallazgos CRÍTICOS a remediar.
+- Cuando un push dejó el CI en rojo.
+
+**Cuándo NO usar**: si ya sabes exactamente qué fixer necesitas, invócalo
+directo (el triage es overhead); para features nuevas (→ flujo GSD
+discutir→planear→ejecutar); para deuda técnica planificada (→ `/swl:deuda-codigo`).
+
+## Paso 1 — Triage (clasificación del síntoma)
+
+Recolectar la evidencia mínima ANTES de rutear — nunca clasificar por la
+descripción sola:
+
+| Señal observada | Verificación | Ruta |
+|---|---|---|
+| Stack trace en runtime, comportamiento inesperado, bug reportado | Reproducir el error una vez (o pedir pasos de repro) | **A — Bug** |
+| `npm run build` / `tsc` / `cargo build` / compilación falla local | Correr el build y capturar el error real | **B — Build** |
+| GitHub Actions en rojo tras push/PR | `gh run list --limit 3` y verificar SHA | **C — CI** |
+| Reporte de verificación/auditoría con hallazgos (VERIFICACION.md, nemesis, postura de seguridad) | Leer el reporte y verificar 2-3 citas archivo:línea contra el código actual (Familia 2) | **D — Hallazgos** |
+| Test rojo sin cambio de código reciente (flaky o regresión externa) | Correr el test 2 veces; revisar `git log` del área | **A — Bug** (si determinista) o reportar flakiness |
+
+Síntomas mixtos (ej: CI rojo porque el build falla): rutear por la **causa más
+local** primero (build local → B); el CI se re-verifica solo al pushear el fix.
+
+## Paso 2 — Despacho
+
+- **Ruta A — Bug**: `Agent(depurador-swl)` con la evidencia de repro. Su método
+  científico incluye la regresión obligatoria (Fase 7) y test de no-regresión
+  (Fase 8). Si el fix excede el diagnóstico (feature faltante, decisión de
+  producto), el depurador escala — no fuerces el fix por esta vía.
+- **Ruta B — Build**: `Agent(resolutor-build-swl)` — detecta lenguaje, carga el
+  `build-errors-*` correspondiente, fix mínimo.
+- **Ruta C — CI**: `Agent(gh-fix-ci-swl)` — loop fix→push→monitor con HITL
+  approval por fix y verificación por SHA.
+- **Ruta D — Hallazgos**: según el origen del reporte:
+  - Hallazgos de código/seguridad de una fase → `/swl:verificar --aplicar-iteracion`
+    o `--until-converge` (delega la corrección a `implementador-swl` y re-verifica).
+  - Bugs de lógica profunda (estado acoplado, invariantes) → `/swl:nemesis --remediar`.
+  - Hallazgos de postura de seguridad (`/swl:seguridad`): los de código van por
+    `verificar --solo-seguridad`; secretos en historial y cambios de infra son
+    Hallazgo C (decisión del usuario, no automatizar).
+
+## Política de convergencia común (aplica a todas las rutas)
+
+Cada fixer conserva su cap interno; este es el mapa unificado y la regla de
+escalación compartida:
+
+| Fixer / loop | Cap | Al agotar el cap |
+|---|---|---|
+| depurador-swl | 3 intentos de fix | Escalar con hipótesis descartadas documentadas |
+| resolutor-build-swl | 1 fix mínimo verificado | Si el fix rompe la suite: revertir y reportar bloqueado |
+| gh-fix-ci-swl | 3 iteraciones fix→push→monitor (maxTurnos 12) | Escalar al usuario |
+| /swl:verificar --until-converge | 5 iteraciones (default) | Salida por plateau/adversarial |
+| /swl:nemesis --remediar | 3 iteraciones | Recovery Catalog (reprompt→reduce-autonomy→escalate) |
+| verificar-trabajo (por claim) | 2 intentos | Escalar |
+
+Reglas transversales:
+
+1. **NUNCA re-despachar en círculo**: si la Ruta A escala y el síntoma "parece"
+   de build, NO relanzar Ruta B con el mismo síntoma sin evidencia nueva — eso
+   es el loop de reparación infinito que `gobernanza.md` prohíbe (máximo 2
+   despachos por síntoma, luego reporte al usuario con lo aprendido).
+2. **Escalar ≠ fracasar**: el reporte de escalación incluye qué se intentó, qué
+   se descartó y la recomendación — nunca "no pude" a secas (anti-degradación
+   silenciosa, `seguridad-agentes.md`).
+
+## Contrato de cierre — regresión obligatoria
+
+Ningún fix se reporta como completado sin:
+
+1. **La suite de tests del proyecto en verde** (no solo el build/step que
+   falló). Un fix de build que rompe lógica de negocio no está terminado.
+   Si el proyecto NO tiene suite: reportarlo como hallazgo del triage —
+   no como excusa.
+2. **Test de no-regresión** cuando la ruta fue A (bug): el test que reproduce
+   el bug queda en la suite (lo garantiza el método del depurador).
+3. **Commit atómico** del fix, separado de cualquier otra mejora.
+
+## Cierre — captura de aprendizaje
+
+Si el fix fue CRÍTICO o el bug era recurrente (≥2ª vez con el mismo patrón),
+ofrecer `/swl:aprender` para capturar el anti-patrón en APRENDIZAJES.md — la
+causa de la causa vale más que el fix.
+
+## Reglas de comportamiento
+
+- El triage verifica evidencia real (correr el build, reproducir el error,
+  leer el reporte) — clasificar por descripción textual produce despachos
+  erróneos.
+- Este comando NO aplica fixes por sí mismo; el trabajo lo hacen los fixers
+  especializados con sus permisos declarados.
+- Reportar siempre qué ruta se eligió y por qué — el usuario debe poder
+  invocar el fixer directo la próxima vez.