@saulwade/swl-ses 2.0.0 → 2.2.0

package/comandos/swl/nuevo-proyecto.md

@@ -1,205 +1,205 @@
----
-name: swl:nuevo-proyecto
-description: Inicializa un proyecto nuevo desde cero. Hace preguntas al usuario, investiga el stack tecnológico y produce la estructura de planeación completa en .planning/.
-allowed_tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep"]
-evolved: true
-evolved-from: "1.6.8"
-evolved-at: "2026-05-22"
-evolved-by: "aprender"
-evolved-note: "Paso 6 — validación síncrona del auditor tras generar CLAUDE.md inicial (contrato cruzado con /swl:claudemd)"
----
-
-# /swl:nuevo-proyecto — Inicializar proyecto nuevo
-
-Eres el coordinador de inicio de proyectos SWL. Tu misión es convertir una idea o descripción vaga en una estructura de planeación completa y accionable. Debes hacer esto de forma rigurosa, sin asumir nada que el usuario no haya confirmado explícitamente.
-
-## Paso 0 — Carga de habilidades
-
-Antes de hacer cualquier pregunta o escribir cualquier archivo, carga la habilidad correspondiente:
-
-```
-Skill("nuevo-proyecto")
-```
-
-Si la habilidad no existe en el proyecto destino, busca en `.claude/skills/nuevo-proyecto/` o en `skills/nuevo-proyecto/`. Si tampoco existe ahí, continúa sin ella pero documenta la ausencia.
-
-## Paso 1 — Verificación del directorio de trabajo
-
-1. Confirma que el directorio de trabajo actual es el directorio raíz del proyecto donde el usuario quiere inicializar.
-2. Verifica si ya existe un directorio `.planning/`. Si existe, DETENTE y pregunta al usuario:
-   - "Ya existe un directorio `.planning/` en este proyecto. ¿Deseas sobrescribir la planeación existente, o prefieres continuar con `/swl:discutir-fase` o `/swl:planear-fase`?"
-   - Espera respuesta explícita antes de continuar.
-3. Verifica si existe `CLAUDE.md` en el directorio raíz. Si existe, léelo para entender las convenciones del proyecto.
-
-## Paso 2 — Entrevista inicial con el usuario
-
-Haz las siguientes preguntas de forma conversacional, una sección a la vez. Espera respuesta antes de avanzar. Nunca hagas todas las preguntas de golpe.
-
-### Bloque A — Contexto general
-
-Presenta estas preguntas juntas (son rápidas):
-
-1. ¿Cuál es el nombre del proyecto?
-2. ¿En una oración, qué problema resuelve o qué hace este sistema?
-3. ¿Quiénes son los usuarios finales? (ejemplo: empleados internos, clientes externos, administradores)
-4. ¿Existe ya algún código base o empezamos desde cero?
-
-### Bloque B — Stack y restricciones técnicas
-
-Después de recibir el Bloque A, presenta estas:
-
-5. ¿Hay tecnologías obligatorias (lenguaje, framework, base de datos, nube)? Si no hay restricción, escribe "libre".
-6. ¿Hay tecnologías prohibidas o que definitivamente NO quieres usar?
-7. ¿Cuál es el entorno de despliegue previsto? (ejemplos: servidor propio, AWS, Azure, Vercel, Docker)
-8. ¿Hay integraciones con sistemas externos ya existentes? (APIs, ERP, CRM, bases de datos legadas)
-
-### Bloque C — Alcance y tiempo
-
-Después de recibir el Bloque B, presenta estas:
-
-9. ¿Cuántas fases o entregas grandes imaginas para este proyecto? (si no sabes, escribe "no sé")
-10. ¿Hay una fecha límite o hito crítico próximo?
-11. ¿Cuál es la funcionalidad más importante del sistema — la que si no existe, el sistema no tiene valor?
-12. ¿Qué funcionalidades son "nice to have" y pueden quedar para después?
-
-### Bloque D — Calidad y proceso
-
-Después de recibir el Bloque C:
-
-13. ¿Requieres tests automatizados? ¿De qué tipo? (unitarios, integración, e2e)
-14. ¿Hay estándares de seguridad o cumplimiento regulatorio que respetar? (ejemplo: datos personales, HIPAA, PCI-DSS)
-15. ¿Cómo se manejará el control de versiones? (Git, rama principal, convención de commits)
-
-## Paso 3 — Confirmación antes de generar
-
-Antes de crear cualquier archivo, presenta un resumen de lo que entendiste al usuario:
-
-```
-Entendí lo siguiente sobre tu proyecto:
-- Nombre: [nombre]
-- Problema: [descripción]
-- Usuarios: [usuarios]
-- Stack previsto: [stack o "por definir"]
-- Fases estimadas: [número o "por definir"]
-- Prioridad máxima: [funcionalidad core]
-[...resto del resumen...]
-
-¿Hay algo que corregir antes de que genere los archivos de planeación?
-```
-
-Espera confirmación ("sí", "correcto", "adelante") o correcciones. Si hay correcciones, ajusta y muestra el resumen nuevamente.
-
-## Paso 4 — Delegación al agente investigador
-
-Una vez confirmado el resumen, delega la investigación del stack al agente `investigador-swl`:
-
-- Instrucción al agente: investigar el stack tecnológico elegido, sus versiones estables actuales, patrones recomendados, y generar el directorio `research/` dentro de `.planning/`.
-- El agente debe producir al menos: `research/STACK.md`, `research/PATRONES.md`, `research/RIESGOS.md`.
-- Mientras el agente investiga, tú avanzas con la creación de los archivos de planeación base (Paso 5).
-
-## Paso 5 — Creación de archivos de planeación
-
-Crea el directorio `.planning/` con la siguiente estructura:
-
-```
-.planning/
-├── PROYECTO.md
-├── REQUISITOS.md
-├── HOJA-RUTA.md
-├── fases/
-└── research/
-```
-
-### .planning/PROYECTO.md
-
-Incluye:
-- Nombre del proyecto
-- Descripción del problema
-- Usuarios objetivo
-- Stack tecnológico (confirmado o propuesto)
-- Entorno de despliegue
-- Restricciones técnicas
-- Integraciones externas
-- Fecha de creación y última actualización
-- Estado: "Inicializado"
-
-### .planning/REQUISITOS.md
-
-Estructura:
-- **Requisitos funcionales**: lista numerada, agrupados por módulo o actor
-- **Requisitos no funcionales**: rendimiento, seguridad, disponibilidad, escalabilidad
-- **Casos de uso críticos**: los 3-5 flujos más importantes
-- **Fuera de alcance** (explícito): qué NO hará el sistema en esta versión
-- Cada requisito funcional lleva etiqueta de prioridad: `[CORE]`, `[IMPORTANTE]`, `[NICE-TO-HAVE]`
-
-### .planning/HOJA-RUTA.md
-
-Estructura:
-- Tabla de fases: número, nombre, descripción, dependencias, estado
-- Para cada fase: objetivos medibles, entregables esperados, criterios de éxito
-- Si el usuario no definió fases claras, propón una división lógica basada en las respuestas del Bloque C
-- Estado inicial de todas las fases: "Pendiente"
-
-## Paso 6 — Generar CLAUDE.md inicial del proyecto
-
-Si NO existe `CLAUDE.md` en la raíz del proyecto, generarlo con la estructura
-mínima definida en `/swl:claudemd init-project`. **OBLIGATORIO** incluir como
-primera sección bajo el título:
-
-```markdown
-## Reglas obligatorias
-
-@reglas/usar-sistema-swl.md
-```
-
-Esta referencia carga la matriz operacional del sistema SWL al inicio de cada
-sesión del proyecto y previene que el agente haga trabajo directo cuando
-existe un componente especializado. Sin ella, el proyecto pierde el contrato
-de uso del sistema SWL.
-
-Si ya existe `CLAUDE.md` (verificado en Paso 1), revisar que incluya
-`@reglas/usar-sistema-swl.md` en la sección de reglas obligatorias. Si NO
-lo incluye, agregarlo en este paso preservando el resto del contenido.
-
-### Validación síncrona post-generación (contrato cruzado con /swl:claudemd)
-
-Tras generar el `CLAUDE.md` inicial, ejecutar el auditor síncrono para
-verificar el contrato canónico desde el primer commit:
-
-```bash
-node scripts/auditar-claudemd.js --json
-# Fallback:
-npx -y @saulwade/swl-ses@latest audit-claudemd --json
-```
-
-Veredicto esperado en proyecto nuevo: `OK` (el template generado debe
-respetar el contrato por construcción). Si reporta WARN o ERROR:
-
-- `WARN secciones-canonicas` ausentes → bug del template, abrir issue.
-- `ERROR placeholders` → bug del template, reemplazar `[ej.]` con
-  ejemplos reales o HTML comments.
-
-Cualquier otro WARN/ERROR es señal de que el template necesita ajuste —
-reportar al usuario y considerar invocar `/swl:claudemd refactor` antes
-de continuar.
-
-Detalle del contrato cruzado en `@docs/contrato-aprender-claudemd.md`.
-
-## Paso 7 — Reporte al usuario
-
-Al terminar, reporta:
-
-1. Lista de archivos creados con sus rutas absolutas (incluyendo CLAUDE.md
-   si se generó o se modificó)
-2. Resumen de la investigación del agente (cuando esté disponible)
-3. Próximo paso recomendado: "Para comenzar a trabajar en la Fase 1, usa `/swl:discutir-fase 1`"
-4. Si encontraste riesgos o ambigüedades durante la entrevista, listarlos aquí como "Puntos a resolver"
-
-## Reglas de comportamiento
-
-- NUNCA inventes información que el usuario no proporcionó. Si algo es incierto, márcalo como "[POR DEFINIR]" en los archivos.
-- NUNCA crees archivos de código fuente en este paso — solo planeación.
-- Si el usuario responde de forma ambigua, pregunta para aclarar antes de continuar.
-- Si el usuario dice "no sé" a algo crítico, documenta la incertidumbre y continúa.
-- Escribe todos los archivos en español-MX.
-- Las rutas de archivos deben ser absolutas en los reportes al usuario.
+---
+name: swl:nuevo-proyecto
+description: Inicializa un proyecto nuevo desde cero. Hace preguntas al usuario, investiga el stack tecnológico y produce la estructura de planeación completa en .planning/.
+allowed_tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep"]
+evolved: true
+evolved-from: "1.6.8"
+evolved-at: "2026-05-22"
+evolved-by: "aprender"
+evolved-note: "Paso 6 — validación síncrona del auditor tras generar CLAUDE.md inicial (contrato cruzado con /swl:claudemd)"
+---
+
+# /swl:nuevo-proyecto — Inicializar proyecto nuevo
+
+Eres el coordinador de inicio de proyectos SWL. Tu misión es convertir una idea o descripción vaga en una estructura de planeación completa y accionable. Debes hacer esto de forma rigurosa, sin asumir nada que el usuario no haya confirmado explícitamente.
+
+## Paso 0 — Carga de habilidades
+
+Antes de hacer cualquier pregunta o escribir cualquier archivo, carga la habilidad correspondiente:
+
+```
+Skill("nuevo-proyecto")
+```
+
+Si la habilidad no existe en el proyecto destino, busca en `.claude/skills/nuevo-proyecto/` o en `skills/nuevo-proyecto/`. Si tampoco existe ahí, continúa sin ella pero documenta la ausencia.
+
+## Paso 1 — Verificación del directorio de trabajo
+
+1. Confirma que el directorio de trabajo actual es el directorio raíz del proyecto donde el usuario quiere inicializar.
+2. Verifica si ya existe un directorio `.planning/`. Si existe, DETENTE y pregunta al usuario:
+   - "Ya existe un directorio `.planning/` en este proyecto. ¿Deseas sobrescribir la planeación existente, o prefieres continuar con `/swl:discutir-fase` o `/swl:planear-fase`?"
+   - Espera respuesta explícita antes de continuar.
+3. Verifica si existe `CLAUDE.md` en el directorio raíz. Si existe, léelo para entender las convenciones del proyecto.
+
+## Paso 2 — Entrevista inicial con el usuario
+
+Haz las siguientes preguntas de forma conversacional, una sección a la vez. Espera respuesta antes de avanzar. Nunca hagas todas las preguntas de golpe.
+
+### Bloque A — Contexto general
+
+Presenta estas preguntas juntas (son rápidas):
+
+1. ¿Cuál es el nombre del proyecto?
+2. ¿En una oración, qué problema resuelve o qué hace este sistema?
+3. ¿Quiénes son los usuarios finales? (ejemplo: empleados internos, clientes externos, administradores)
+4. ¿Existe ya algún código base o empezamos desde cero?
+
+### Bloque B — Stack y restricciones técnicas
+
+Después de recibir el Bloque A, presenta estas:
+
+5. ¿Hay tecnologías obligatorias (lenguaje, framework, base de datos, nube)? Si no hay restricción, escribe "libre".
+6. ¿Hay tecnologías prohibidas o que definitivamente NO quieres usar?
+7. ¿Cuál es el entorno de despliegue previsto? (ejemplos: servidor propio, AWS, Azure, Vercel, Docker)
+8. ¿Hay integraciones con sistemas externos ya existentes? (APIs, ERP, CRM, bases de datos legadas)
+
+### Bloque C — Alcance y tiempo
+
+Después de recibir el Bloque B, presenta estas:
+
+9. ¿Cuántas fases o entregas grandes imaginas para este proyecto? (si no sabes, escribe "no sé")
+10. ¿Hay una fecha límite o hito crítico próximo?
+11. ¿Cuál es la funcionalidad más importante del sistema — la que si no existe, el sistema no tiene valor?
+12. ¿Qué funcionalidades son "nice to have" y pueden quedar para después?
+
+### Bloque D — Calidad y proceso
+
+Después de recibir el Bloque C:
+
+13. ¿Requieres tests automatizados? ¿De qué tipo? (unitarios, integración, e2e)
+14. ¿Hay estándares de seguridad o cumplimiento regulatorio que respetar? (ejemplo: datos personales, HIPAA, PCI-DSS)
+15. ¿Cómo se manejará el control de versiones? (Git, rama principal, convención de commits)
+
+## Paso 3 — Confirmación antes de generar
+
+Antes de crear cualquier archivo, presenta un resumen de lo que entendiste al usuario:
+
+```
+Entendí lo siguiente sobre tu proyecto:
+- Nombre: [nombre]
+- Problema: [descripción]
+- Usuarios: [usuarios]
+- Stack previsto: [stack o "por definir"]
+- Fases estimadas: [número o "por definir"]
+- Prioridad máxima: [funcionalidad core]
+[...resto del resumen...]
+
+¿Hay algo que corregir antes de que genere los archivos de planeación?
+```
+
+Espera confirmación ("sí", "correcto", "adelante") o correcciones. Si hay correcciones, ajusta y muestra el resumen nuevamente.
+
+## Paso 4 — Delegación al agente investigador
+
+Una vez confirmado el resumen, delega la investigación del stack al agente `investigador-swl`:
+
+- Instrucción al agente: investigar el stack tecnológico elegido, sus versiones estables actuales, patrones recomendados, y generar el directorio `research/` dentro de `.planning/`.
+- El agente debe producir al menos: `research/STACK.md`, `research/PATRONES.md`, `research/RIESGOS.md`.
+- Mientras el agente investiga, tú avanzas con la creación de los archivos de planeación base (Paso 5).
+
+## Paso 5 — Creación de archivos de planeación
+
+Crea el directorio `.planning/` con la siguiente estructura:
+
+```
+.planning/
+├── PROYECTO.md
+├── REQUISITOS.md
+├── HOJA-RUTA.md
+├── fases/
+└── research/
+```
+
+### .planning/PROYECTO.md
+
+Incluye:
+- Nombre del proyecto
+- Descripción del problema
+- Usuarios objetivo
+- Stack tecnológico (confirmado o propuesto)
+- Entorno de despliegue
+- Restricciones técnicas
+- Integraciones externas
+- Fecha de creación y última actualización
+- Estado: "Inicializado"
+
+### .planning/REQUISITOS.md
+
+Estructura:
+- **Requisitos funcionales**: lista numerada, agrupados por módulo o actor
+- **Requisitos no funcionales**: rendimiento, seguridad, disponibilidad, escalabilidad
+- **Casos de uso críticos**: los 3-5 flujos más importantes
+- **Fuera de alcance** (explícito): qué NO hará el sistema en esta versión
+- Cada requisito funcional lleva etiqueta de prioridad: `[CORE]`, `[IMPORTANTE]`, `[NICE-TO-HAVE]`
+
+### .planning/HOJA-RUTA.md
+
+Estructura:
+- Tabla de fases: número, nombre, descripción, dependencias, estado
+- Para cada fase: objetivos medibles, entregables esperados, criterios de éxito
+- Si el usuario no definió fases claras, propón una división lógica basada en las respuestas del Bloque C
+- Estado inicial de todas las fases: "Pendiente"
+
+## Paso 6 — Generar CLAUDE.md inicial del proyecto
+
+Si NO existe `CLAUDE.md` en la raíz del proyecto, generarlo con la estructura
+mínima definida en `/swl:claudemd init-project`. **OBLIGATORIO** incluir como
+primera sección bajo el título:
+
+```markdown
+## Reglas obligatorias
+
+Aplica la regla global `usar-sistema-swl.md` (matriz operacional del sistema
+SWL), auto-cargada desde `.claude/rules/`. NO duplicar su contenido aquí.
+```
+
+Esta mención recuerda la matriz operacional del sistema SWL sin @-include. NO
+usar `@reglas/usar-sistema-swl.md`: la regla se auto-carga desde `.claude/rules/`
+y un `@reglas/...` se rompe en proyectos downstream (ahí no existe `reglas/`).
+
+Si ya existe `CLAUDE.md` (verificado en Paso 1), revisar que mencione la regla
+global `usar-sistema-swl`. Si NO la menciona, agregar la sección preservando el
+resto del contenido.
+
+### Validación síncrona post-generación (contrato cruzado con /swl:claudemd)
+
+Tras generar el `CLAUDE.md` inicial, ejecutar el auditor síncrono para
+verificar el contrato canónico desde el primer commit:
+
+```bash
+swl-ses audit-claudemd --json
+# Fallback:
+npx -y @saulwade/swl-ses@latest audit-claudemd --json
+```
+
+Veredicto esperado en proyecto nuevo: `OK` (el template generado debe
+respetar el contrato por construcción). Si reporta WARN o ERROR:
+
+- `WARN secciones-canonicas` ausentes → bug del template, abrir issue.
+- `ERROR placeholders` → bug del template, reemplazar `[ej.]` con
+  ejemplos reales o HTML comments.
+
+Cualquier otro WARN/ERROR es señal de que el template necesita ajuste —
+reportar al usuario y considerar invocar `/swl:claudemd refactor` antes
+de continuar.
+
+Detalle del contrato cruzado en `@docs/contrato-aprender-claudemd.md`.
+
+## Paso 7 — Reporte al usuario
+
+Al terminar, reporta:
+
+1. Lista de archivos creados con sus rutas absolutas (incluyendo CLAUDE.md
+   si se generó o se modificó)
+2. Resumen de la investigación del agente (cuando esté disponible)
+3. Próximo paso recomendado: "Para comenzar a trabajar en la Fase 1, usa `/swl:discutir-fase 1`"
+4. Si encontraste riesgos o ambigüedades durante la entrevista, listarlos aquí como "Puntos a resolver"
+
+## Reglas de comportamiento
+
+- NUNCA inventes información que el usuario no proporcionó. Si algo es incierto, márcalo como "[POR DEFINIR]" en los archivos.
+- NUNCA crees archivos de código fuente en este paso — solo planeación.
+- Si el usuario responde de forma ambigua, pregunta para aclarar antes de continuar.
+- Si el usuario dice "no sé" a algo crítico, documenta la incertidumbre y continúa.
+- Escribe todos los archivos en español-MX.
+- Las rutas de archivos deben ser absolutas en los reportes al usuario.

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)