@saulwade/swl-ses 2.2.4 → 2.3.1

package/comandos/swl/predecir.md

@@ -1,139 +1,139 @@
----
-name: swl:predecir
-description: >
-  Análisis predictivo pre-implementación: 5 personas expertas (Arquitecto,
-  Seguridad, Rendimiento, Confiabilidad, Abogado del Diablo) analizan EN FRÍO
-  un cambio propuesto antes de implementarlo, un sintetizador deduplica con
-  anti-herd check y entrega hallazgos rankeados por severidad × confianza ×
-  acuerdo. Usar antes de /swl:planear-fase en fases de riesgo, antes de un
-  refactor grande, o cuando el costo de descubrir un problema DESPUÉS de
-  implementar es alto. Con --adversarial usa el set atacante (Rompedor,
-  Tramposo, Escalador, Novato, Insider).
-argument-hint: "[descripción del cambio] [--scope <glob>] [--adversarial] [--presupuesto N] [--chain planear-fase]"
-allowed-tools: [Read, Grep, Glob, Bash, Write, Agent, Skill]
----
-
-# /swl:predecir — Análisis predictivo pre-implementación
-
-Eres el coordinador de un panel de personas expertas que evalúan un cambio
-propuesto ANTES de que se implemente. El valor del comando está en el
-aislamiento: cada persona analiza en frío, sin ver a las demás — los sesgos
-de manada y de confirmación se eliminan por construcción.
-
-Complementa (no reemplaza) a `/swl:verificar` y `/swl:nemesis`: esos auditan
-código que YA existe; `predecir` ataca el plan cuando corregirlo cuesta una
-conversación, no un refactor.
-
-## Cuándo usar
-
-- Antes de `/swl:planear-fase` en fases que tocan auth, dinero, datos
-  productivos o contratos públicos de API.
-- Antes de un refactor cross-módulo o una migración de schema.
-- Cuando el usuario duda entre implementar o no un cambio con blast radius alto.
-
-**Cuándo NO usar**: cambios triviales (1-2 archivos), código ya implementado
-(usar `/swl:verificar`), o decisiones entre 2+ alternativas (usar el debate
-adversarial de `Skill("proceso-debate-adversarial")` — predecir analiza UNA
-propuesta, el debate compara varias).
-
-## Flags
-
-```
-[descripción]          La propuesta de cambio a analizar (obligatoria; si falta, preguntar)
---scope <glob>         Archivos relevantes para grounding (default: derivar del texto)
---adversarial          Set de personas atacantes en vez del set default
---presupuesto N        Máximo de hallazgos totales (default: 40 → 8 por persona)
---chain planear-fase   Al terminar, ofrecer arrancar /swl:planear-fase con los hallazgos como contexto
-```
-
-## Paso 0 — Carga y configuración
-
-```
-Skill("proceso-debate-adversarial")
-```
-
-El skill define el protocolo COLD START, el anti-herd check y el formato de
-síntesis. Las definiciones de personas viven en
-`habilidades/proceso-debate-adversarial/recursos/personas.md`.
-
-Confirmar con el usuario: propuesta, scope, set de personas, presupuesto.
-
-## Paso 1 — Reconocimiento del codebase
-
-Construir el paquete de conocimiento que recibirá CADA persona (idéntico para
-todas): descripción de la propuesta + inventario de archivos del scope +
-dependencias relevantes + superficie de API afectada + cobertura de tests del
-área. Usar `code-review-graph` si está disponible (blast radius, callers);
-si no, Grep/Glob dirigidos. Máximo ~1,500 tokens — las personas analizan, no
-exploran.
-
-## Paso 2 — Análisis en frío (5 invocaciones Agent independientes)
-
-Por cada persona, UNA invocación del Agent tool (general-purpose o el agente
-afín al dominio) con prompt autocontenido:
-
-```
-Eres [persona] — [enfoque de recursos/personas.md].
-Propuesta: [descripción]
-Contexto del codebase: [paquete del Paso 1]
-Tu tarea: encuentra hasta [presupuesto/5] problemas que esta propuesta
-causaría, desde tu perspectiva. Por cada uno: título, severidad
-(crítico/alto/medio/bajo), confianza 0-100%, archivo:línea si aplica,
-recomendación concreta. Preguntas guía: [de la persona]. Red flags: [de la
-persona]. NO incluyas elogios ni evaluación general — solo hallazgos.
-```
-
-Las 5 invocaciones pueden correr en paralelo. NUNCA pasar el output de una
-persona a otra — el aislamiento es el mecanismo del comando.
-
-## Paso 3 — Síntesis con anti-herd check
-
-Aplicar el protocolo de síntesis del skill:
-
-1. Deduplicar (mismo archivo:línea + mismo problema → fusionar, severidad más alta gana).
-2. Registrar disensos (dos personas en desacuerdo → ambas posturas visibles).
-3. **Anti-herd check**: si todas las personas coinciden en el hallazgo top,
-   generar explícitamente ≥1 contraargumento antes de aceptarlo.
-4. Rankear: `severidad × confianza promedio × número de personas que coinciden`.
-
-## Paso 4 — Reporte y persistencia
-
-Persistir en `.planning/loops/predecir-[timestamp]/` con
-`hooks/lib/loop-telemetry.js` (tipo `predecir`, columnas `iteracion,
-timestamp, hallazgo, severidad, confianza, personas, archivo_linea`; una fila
-por hallazgo consensuado) + `escribirHandoff` con `source: 'swl:predecir'`,
-`findings` rankeados y `config: {propuesta, scope}`.
-
-Reportar al usuario:
-
-```
-=== Predicción — [propuesta resumida] ===
-Personas: [set] | Hallazgos brutos: N | Tras dedup: M
-
-## Top hallazgos (rankeados)
-| # | Hallazgo | Severidad | Confianza | Acuerdo | archivo:línea | Recomendación |
-
-## Disensos registrados
-- [persona X sostiene A; persona Y sostiene B — evidencia de cada una]
-
-## Veredicto del panel
-[PROCEDER | PROCEDER CON AJUSTES (lista) | REPLANTEAR (razón)]
-```
-
-## Paso 5 — Encadenamiento (si `--chain planear-fase`)
-
-Ofrecer arrancar `/swl:planear-fase` indicando el directorio del handoff. El
-planificador incorpora los hallazgos `crítico`/`alto` como restricciones del
-PLAN.md — cada uno se atiende con una tarea o se descarta con justificación
-explícita (nunca silenciosamente).
-
-## Reglas de comportamiento
-
-- NUNCA compartir contexto entre personas — una invocación Agent por persona.
-- NUNCA omitir el anti-herd check cuando hay unanimidad.
-- Los hallazgos con archivo:línea citan código REAL verificado en el Paso 1 —
-  regla `verificar-citas-normativas.md § Familia 2` aplica al propio output.
-- El comando NO modifica código — produce análisis. Implementar es del flujo
-  planear → ejecutar.
-- Con 0 hallazgos crítico/alto: decirlo claramente y no inflar hallazgos
-  menores para justificar el costo del panel.
+---
+name: swl:predecir
+description: >
+  Análisis predictivo pre-implementación: 5 personas expertas (Arquitecto,
+  Seguridad, Rendimiento, Confiabilidad, Abogado del Diablo) analizan EN FRÍO
+  un cambio propuesto antes de implementarlo, un sintetizador deduplica con
+  anti-herd check y entrega hallazgos rankeados por severidad × confianza ×
+  acuerdo. Usar antes de /swl:planear-fase en fases de riesgo, antes de un
+  refactor grande, o cuando el costo de descubrir un problema DESPUÉS de
+  implementar es alto. Con --adversarial usa el set atacante (Rompedor,
+  Tramposo, Escalador, Novato, Insider).
+argument-hint: "[descripción del cambio] [--scope <glob>] [--adversarial] [--presupuesto N] [--chain planear-fase]"
+allowed-tools: [Read, Grep, Glob, Bash, Write, Agent, Skill]
+---
+
+# /swl:predecir — Análisis predictivo pre-implementación
+
+Eres el coordinador de un panel de personas expertas que evalúan un cambio
+propuesto ANTES de que se implemente. El valor del comando está en el
+aislamiento: cada persona analiza en frío, sin ver a las demás — los sesgos
+de manada y de confirmación se eliminan por construcción.
+
+Complementa (no reemplaza) a `/swl:verificar` y `/swl:nemesis`: esos auditan
+código que YA existe; `predecir` ataca el plan cuando corregirlo cuesta una
+conversación, no un refactor.
+
+## Cuándo usar
+
+- Antes de `/swl:planear-fase` en fases que tocan auth, dinero, datos
+  productivos o contratos públicos de API.
+- Antes de un refactor cross-módulo o una migración de schema.
+- Cuando el usuario duda entre implementar o no un cambio con blast radius alto.
+
+**Cuándo NO usar**: cambios triviales (1-2 archivos), código ya implementado
+(usar `/swl:verificar`), o decisiones entre 2+ alternativas (usar el debate
+adversarial de `Skill("proceso-debate-adversarial")` — predecir analiza UNA
+propuesta, el debate compara varias).
+
+## Flags
+
+```
+[descripción]          La propuesta de cambio a analizar (obligatoria; si falta, preguntar)
+--scope <glob>         Archivos relevantes para grounding (default: derivar del texto)
+--adversarial          Set de personas atacantes en vez del set default
+--presupuesto N        Máximo de hallazgos totales (default: 40 → 8 por persona)
+--chain planear-fase   Al terminar, ofrecer arrancar /swl:planear-fase con los hallazgos como contexto
+```
+
+## Paso 0 — Carga y configuración
+
+```
+Skill("proceso-debate-adversarial")
+```
+
+El skill define el protocolo COLD START, el anti-herd check y el formato de
+síntesis. Las definiciones de personas viven en
+`habilidades/proceso-debate-adversarial/recursos/personas.md`.
+
+Confirmar con el usuario: propuesta, scope, set de personas, presupuesto.
+
+## Paso 1 — Reconocimiento del codebase
+
+Construir el paquete de conocimiento que recibirá CADA persona (idéntico para
+todas): descripción de la propuesta + inventario de archivos del scope +
+dependencias relevantes + superficie de API afectada + cobertura de tests del
+área. Usar `code-review-graph` si está disponible (blast radius, callers);
+si no, Grep/Glob dirigidos. Máximo ~1,500 tokens — las personas analizan, no
+exploran.
+
+## Paso 2 — Análisis en frío (5 invocaciones Agent independientes)
+
+Por cada persona, UNA invocación del Agent tool (general-purpose o el agente
+afín al dominio) con prompt autocontenido:
+
+```
+Eres [persona] — [enfoque de recursos/personas.md].
+Propuesta: [descripción]
+Contexto del codebase: [paquete del Paso 1]
+Tu tarea: encuentra hasta [presupuesto/5] problemas que esta propuesta
+causaría, desde tu perspectiva. Por cada uno: título, severidad
+(crítico/alto/medio/bajo), confianza 0-100%, archivo:línea si aplica,
+recomendación concreta. Preguntas guía: [de la persona]. Red flags: [de la
+persona]. NO incluyas elogios ni evaluación general — solo hallazgos.
+```
+
+Las 5 invocaciones pueden correr en paralelo. NUNCA pasar el output de una
+persona a otra — el aislamiento es el mecanismo del comando.
+
+## Paso 3 — Síntesis con anti-herd check
+
+Aplicar el protocolo de síntesis del skill:
+
+1. Deduplicar (mismo archivo:línea + mismo problema → fusionar, severidad más alta gana).
+2. Registrar disensos (dos personas en desacuerdo → ambas posturas visibles).
+3. **Anti-herd check**: si todas las personas coinciden en el hallazgo top,
+   generar explícitamente ≥1 contraargumento antes de aceptarlo.
+4. Rankear: `severidad × confianza promedio × número de personas que coinciden`.
+
+## Paso 4 — Reporte y persistencia
+
+Persistir en `.planning/loops/predecir-[timestamp]/` con
+`hooks/lib/loop-telemetry.js` (tipo `predecir`, columnas `iteracion,
+timestamp, hallazgo, severidad, confianza, personas, archivo_linea`; una fila
+por hallazgo consensuado) + `escribirHandoff` con `source: 'swl:predecir'`,
+`findings` rankeados y `config: {propuesta, scope}`.
+
+Reportar al usuario:
+
+```
+=== Predicción — [propuesta resumida] ===
+Personas: [set] | Hallazgos brutos: N | Tras dedup: M
+
+## Top hallazgos (rankeados)
+| # | Hallazgo | Severidad | Confianza | Acuerdo | archivo:línea | Recomendación |
+
+## Disensos registrados
+- [persona X sostiene A; persona Y sostiene B — evidencia de cada una]
+
+## Veredicto del panel
+[PROCEDER | PROCEDER CON AJUSTES (lista) | REPLANTEAR (razón)]
+```
+
+## Paso 5 — Encadenamiento (si `--chain planear-fase`)
+
+Ofrecer arrancar `/swl:planear-fase` indicando el directorio del handoff. El
+planificador incorpora los hallazgos `crítico`/`alto` como restricciones del
+PLAN.md — cada uno se atiende con una tarea o se descarta con justificación
+explícita (nunca silenciosamente).
+
+## Reglas de comportamiento
+
+- NUNCA compartir contexto entre personas — una invocación Agent por persona.
+- NUNCA omitir el anti-herd check cuando hay unanimidad.
+- Los hallazgos con archivo:línea citan código REAL verificado en el Paso 1 —
+  regla `verificar-citas-normativas.md § Familia 2` aplica al propio output.
+- El comando NO modifica código — produce análisis. Implementar es del flujo
+  planear → ejecutar.
+- Con 0 hallazgos crítico/alto: decirlo claramente y no inflar hallazgos
+  menores para justificar el costo del panel.

package/comandos/swl/release.md

@@ -266,7 +266,19 @@ Usar tags anotados siempre (regla del skill).
 
 ## Paso 9 — Generar RELEASE-NOTES
 
-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.
+Crea `releases/v[nueva-versión]/RELEASE-NOTES-v[nueva-versión].md` con: resumen,
+cambios, instrucciones de actualización y guía de migración si hay breaking changes.
+
+```bash
+mkdir -p releases/v[nueva-versión]
+# escribir releases/v[nueva-versión]/RELEASE-NOTES-v[nueva-versión].md
+```
+
+**NUNCA crear las RELEASE-NOTES en la raíz del repo.** La convención (todos los
+releases previos en `releases/`) es que las RELEASE-NOTES viven SOLO en
+`releases/vX.Y.Z/` — no se versiona ninguna copia en raíz. El directorio
+`releases/v[nueva-versión]/` también lo crea `evidencia-release.js` (Paso 9.5);
+si ese paso corre primero, el `mkdir -p` es no-op.
 
 ## Paso 9.5 — Evidencia de procedencia (cadena de suministro, ADR-0038)
 
@@ -286,20 +298,21 @@ Esto escribe (vía `scripts/lib/evidencia-release.js`):
 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:
+   `releases/v[nueva-versión]/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").
+   Anexar ese markdown a `releases/v[nueva-versión]/RELEASE-NOTES-v[nueva-versión].md`
+   (tras "Correcciones").
 
-2. **Copiar las RELEASE-NOTES** a la carpeta del release como evidencia
-   versionada:
+2. **Versionar la evidencia** del release. Las RELEASE-NOTES ya viven en
+   `releases/v[nueva-versión]/` (Paso 9) — NO hacer `cp` desde la raíz (no debe
+   existir copia en raíz):
 
    ```bash
-   cp RELEASE-NOTES-v[nueva-versión].md releases/v[nueva-versión]/
    git add releases/v[nueva-versión]/
    ```
 
@@ -397,7 +410,7 @@ Commits incluidos: [N] (feat: [N], fix: [N], otros: [N])
 Tests: [ejecutados OK | omitidos (--skip-tests)]
 
 Próximos pasos:
-  1. Revisar RELEASE-NOTES-v[nueva-versión].md
+  1. Revisar releases/v[nueva-versión]/RELEASE-NOTES-v[nueva-versión].md
   2. git push origin v[nueva-versión]
   3. Publicar release en GitHub/GitLab si aplica
   4. Notificar al equipo
@@ -416,6 +429,15 @@ Próximos pasos:
   release ya creado pero aún-no-publicado obliga a mover el tag + regenerar la
   evidencia (el SHA del tarball cambia si el commit toca archivos de
   `package.json#files`) — churn evitable. Si hay que iterar, hacerlo antes de taggear.
+- **Si el usuario alimenta archivos de forma incremental para la MISMA versión
+  ("faltan N archivos que agregar a esta versión, espera"), NO finalizar el
+  release** (no congelar tag, no regenerar evidencia final, no proponer push)
+  hasta que el usuario confirme que ya están TODOS los archivos. Mantener el
+  commit de release como HEAD entre tandas para que cada incorporación sea un
+  `amend` limpio + mover tag; regenerar la evidencia (SBOM/SHA256SUMS) SOLO en la
+  última tanda, porque el SHA del tarball cambia con cada archivo nuevo que entre
+  en `package.json#files`. Cerrar el release antes de tiempo obliga a rehacer
+  evidencia y tag por cada archivo tardío.
 - **El agente NUNCA corre `npm` (test/pack/build/publish) en paralelo a un
   `npm run publish:*` que está ejecutando el usuario.** `test:release` incluye
   `test:smoke` (install/uninstall a temp + lectura de estado global); dos suites

package/comandos/swl/sesiones.md

@@ -105,7 +105,7 @@ Herramientas:
   Grep     2
 
 Modelos:
-  claude-sonnet-4-6   47
+  claude-sonnet-5   47
 
 Archivos modificados (6):
   hooks/lib/session-store.js