@saulwade/swl-ses 2.3.0 → 2.3.1

package/plantillas/github-workflows/swl-security.yml

@@ -1,51 +1,51 @@
-name: Revisión de Seguridad — Claude Code
-
-# Plantilla distribuida por swl-ses.
-# Copiar este archivo a .github/workflows/ de tu proyecto.
-# Para setup automatizado: /swl:configurar-ci init
-#
-# PREREQUISITO — configurar el secret CLAUDE_API_KEY en tu repositorio:
-#   GitHub → Settings → Secrets and variables → Actions → New repository secret
-#   Nombre: CLAUDE_API_KEY
-#   Valor:  clave API de Anthropic (https://console.anthropic.com)
-#   La clave requiere permisos tanto para Claude API como para Claude Code.
-#
-# Referencia de la action oficial:
-#   https://github.com/anthropics/claude-code-security-review
-#
-# NOTA: los workflows de forks externos no reciben secrets por diseño de GitHub.
-# La revisión de seguridad solo corre en PRs de ramas del mismo repositorio.
-
-on:
-  pull_request:
-    branches: [main]
-
-# Permisos mínimos: escribir comentarios en PRs y leer contenido del repo.
-permissions:
-  pull-requests: write
-  contents: read
-
-jobs:
-  security:
-    name: Análisis de seguridad con Claude
-    runs-on: ubuntu-latest
-
-    steps:
-      - uses: actions/checkout@v5
-        with:
-          # fetch-depth: 2 es requerido por la action para calcular el diff.
-          ref: ${{ github.event.pull_request.head.sha || github.sha }}
-          fetch-depth: 2
-
-      # Análisis semántico de seguridad sobre el diff del PR.
-      # Detecta: inyecciones SQL/OS, credenciales expuestas, auth débil,
-      # SSRF, XSS y las 10 categorías del OWASP Top 10.
-      # Comenta hallazgos directamente en el PR.
-      - uses: anthropics/claude-code-security-review@main
-        with:
-          claude-api-key: ${{ secrets.CLAUDE_API_KEY }}
-          comment-pr: true
-          upload-results: true
-          # Excluir directorios que no son código de producción.
-          # Ajustar según la estructura de tu proyecto.
-          # exclude-directories: "temp,docs,fixtures"
+name: Revisión de Seguridad — Claude Code
+
+# Plantilla distribuida por swl-ses.
+# Copiar este archivo a .github/workflows/ de tu proyecto.
+# Para setup automatizado: /swl:configurar-ci init
+#
+# PREREQUISITO — configurar el secret CLAUDE_API_KEY en tu repositorio:
+#   GitHub → Settings → Secrets and variables → Actions → New repository secret
+#   Nombre: CLAUDE_API_KEY
+#   Valor:  clave API de Anthropic (https://console.anthropic.com)
+#   La clave requiere permisos tanto para Claude API como para Claude Code.
+#
+# Referencia de la action oficial:
+#   https://github.com/anthropics/claude-code-security-review
+#
+# NOTA: los workflows de forks externos no reciben secrets por diseño de GitHub.
+# La revisión de seguridad solo corre en PRs de ramas del mismo repositorio.
+
+on:
+  pull_request:
+    branches: [main]
+
+# Permisos mínimos: escribir comentarios en PRs y leer contenido del repo.
+permissions:
+  pull-requests: write
+  contents: read
+
+jobs:
+  security:
+    name: Análisis de seguridad con Claude
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v5
+        with:
+          # fetch-depth: 2 es requerido por la action para calcular el diff.
+          ref: ${{ github.event.pull_request.head.sha || github.sha }}
+          fetch-depth: 2
+
+      # Análisis semántico de seguridad sobre el diff del PR.
+      # Detecta: inyecciones SQL/OS, credenciales expuestas, auth débil,
+      # SSRF, XSS y las 10 categorías del OWASP Top 10.
+      # Comenta hallazgos directamente en el PR.
+      - uses: anthropics/claude-code-security-review@main
+        with:
+          claude-api-key: ${{ secrets.CLAUDE_API_KEY }}
+          comment-pr: true
+          upload-results: true
+          # Excluir directorios que no son código de producción.
+          # Ajustar según la estructura de tu proyecto.
+          # exclude-directories: "temp,docs,fixtures"

package/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "swl-ses",
-  "version": "2.3.0",
+  "version": "2.3.1",
   "description": "Sistema de ingenieria de software auto-evolutivo multi-runtime polyglot. 60 agentes, 182 habilidades, 44 comandos, 77 reglas y 50 hooks. 77 librerias. 11 lenguajes. Soporta Claude Code, Copilot, OpenCode, Codex y Gemini CLI. Loop evaluator-optimizer en /swl:nemesis (ADR-0021). v1.8.0 unifica los directorios runtime de .planning/ al ingles (evolution/, auto-evolution/, user-profile/, archive/), manteniendo fases/ en espanol, con guard validar-planning-paths y allowlist canonica (ADR-0031). Hereda de v1.7.4: skill calidad-anti-patrones-universales + scripts/lib/pr-analyzer.js + 3 sub-secciones en estilo-sin-ai-isms.",
   "author": "Saul Wade Leon",
   "license": "MIT",

package/reglas/accesibilidad.md

@@ -1,13 +1,13 @@
----
-paths:
-  - "**/*.tsx"
-  - "**/*.jsx"
-  - "**/*.vue"
-  - "**/*.svelte"
-  - "**/*.html"
-  - "**/*.css"
-  - "**/*.scss"
----
+---
+paths:
+  - "**/*.tsx"
+  - "**/*.jsx"
+  - "**/*.vue"
+  - "**/*.svelte"
+  - "**/*.html"
+  - "**/*.css"
+  - "**/*.scss"
+---
 # Regla: Accesibilidad
 
 Esta regla es OBLIGATORIA para todo código frontend sin excepción.

package/reglas/analisis-previo-tareas-grandes.md

@@ -1,172 +1,172 @@
-# Regla: Análisis previo ante tareas grandes
-
-Esta regla es OBLIGATORIA y aplica a todo trabajo donde la solicitud del usuario
-implique cambio masivo: porte de sistema, refactor cross-módulo, replicación de
-arquitectura externa, migración de stack, instalación de framework completo,
-adopción de patrón en N módulos.
-
----
-
-## Principio
-
-> Cuando el usuario pide "replicar íntegramente X", "portar todo Y", "implementar
-> el sistema completo Z", **responde primero con análisis comparativo (qué ya
-> existe vs. qué falta) y propón 3 opciones de alcance** (mínima / media /
-> completa) antes de escribir código. Nunca arrancar el porte literal sin
-> confirmación explícita tras presentar opciones.
-
----
-
-## Cómo aplicar
-
-### Detección — qué cuenta como "tarea grande"
-
-Cualquier solicitud que tenga al menos uno de estos atributos:
-
-- Más de ~10 archivos a crear, mover o reescribir.
-- Más de ~500 LOC estimadas a tocar en un solo turno.
-- Toca más de un dominio (backend + frontend, o varios módulos backend).
-- "Replicar X" donde X es un sistema externo con su propia arquitectura.
-- "Portar todo de Y" donde Y es un repo, framework o lib voluminoso.
-- "Implementar todo Z" donde Z es una fase, un sub-sistema, una capa nueva.
-- Análisis de un repo en `temp/` con la pregunta abierta "¿qué adoptamos?".
-
-Si la solicitud encaja en cualquiera de estas, aplicar la regla.
-
-### Paso 1 — Auditar lo que ya existe
-
-Antes de proponer el porte:
-
-- `Glob` / `Grep` / `Read` para mapear el código actual del usuario.
-- Identificar componentes que ya cubren parte de la solicitud.
-- Verificar versiones, dependencias, convenciones del proyecto.
-- Si es repo externo en `temp/`: aplicar **filtro de dominio** primero
-  (ver `reglas/arquitectura.md` § "Análisis de repositorios externos").
-  Descartar 80-95% del contenido vertical antes de análisis profundo.
-
-### Paso 2 — Tabla comparativa
-
-Producir una tabla con tres columnas:
-
-| Componente del sistema externo | Equivalente actual del usuario | Gap |
-|---|---|---|
-| ... | ya existe / parcial / no existe | qué falta agregar |
-
-Sin la tabla, no se proponen opciones. La tabla es la base objetiva de la decisión.
-
-### Paso 3 — Tres opciones de alcance
-
-Siempre presentar tres opciones:
-
-- **Mínima** — solo cierra los gaps críticos (lo que NO existe). Esfuerzo
-  estimado bajo. Usuario acepta vivir con diferencias menores en lo demás.
-- **Media** — cierra gaps + alinea componentes parciales con el patrón externo.
-  Esfuerzo medio. Convergencia parcial sin reescribir lo que ya funciona.
-- **Completa** — porte literal de todo lo que el usuario pidió, sin reusar
-  componentes existentes. Esfuerzo alto. Justificable solo cuando la
-  arquitectura externa es estrictamente superior.
-
-Cada opción incluye:
-
-- Estimación de esfuerzo (turnos, LOC, archivos afectados).
-- Lista de tareas concretas si se elige.
-- Riesgos / tradeoffs específicos.
-
-### Paso 4 — Recomendación explícita
-
-Tras las tres opciones, **recomendar una** con razonamiento. No dejar la
-decisión "abierta" — el usuario espera tu juicio técnico.
-
-Patrón de recomendación:
-
-> **Recomiendo la opción [N]** porque [razón concreta]. Las opciones [otras]
-> son válidas si [condición específica].
-
-### Paso 5 — Esperar confirmación
-
-Después de presentar tabla + opciones + recomendación: detenerse y esperar.
-
-NO arrancar a escribir código asumiendo aprobación implícita. La autorización
-debe ser literal del usuario ("procede con la opción 2", "adelante con la
-mínima", "hagamos la completa").
-
----
-
-## Excepciones — cuándo NO aplicar la regla
-
-NO aplicar cuando:
-
-1. **El usuario ya pidió explícitamente la opción**: "implementa la versión
-   mínima de X" o "porta solo el módulo Y" — la elección ya está hecha.
-2. **El alcance es trivial** — menos de 5 archivos, una sola dependencia.
-3. **El usuario pidió análisis y ya decidió**: si ya hubo una sesión previa con
-   la tabla comparativa y el usuario eligió, proceder sin re-presentar.
-4. **Es un fix urgente de producción** — bug crítico, vulnerabilidad activa,
-   incidente. El análisis se reduce a confirmar la causa y aplicar el fix
-   específico.
-
----
-
-## Cómo presentar la tabla y opciones
-
-### Formato de tabla comparativa (mínimo)
-
-```markdown
-| Componente | Sistema externo | Tu sistema actual | Gap |
-|---|---|---|---|
-| Auth | OAuth2 + PKCE | JWT custom | parcial — falta PKCE |
-| Storage | S3 + presigned | filesystem local | falta — pendiente migración |
-| ... | ... | ... | ... |
-```
-
-### Formato de las tres opciones (mínimo)
-
-```markdown
-**Opción A — Mínima** (~3 turnos, ~15 archivos)
-- Cerrar solo gaps críticos: PKCE, presigned URLs.
-- No tocar lo que ya funciona.
-- Riesgo: leve divergencia con sistema externo en convenciones menores.
-
-**Opción B — Media** (~6 turnos, ~30 archivos)
-- Cerrar gaps + alinear `auth/` con patrón OAuth2 completo.
-- Mantener storage actual con migración planeada en fase futura.
-- Riesgo: refactor en `auth/` puede romper integraciones existentes.
-
-**Opción C — Completa** (~15 turnos, ~80 archivos)
-- Porte literal del sistema externo completo.
-- Reemplaza todo lo equivalente, no importa que ya funcione.
-- Riesgo: regresiones en funcionalidad madura.
-
-**Recomiendo la Opción A**: el sistema actual cubre el 80% del valor;
-los gaps específicos resuelven el caso concreto sin riesgo de regresión.
-```
-
----
-
-## Anti-patrones
-
-- Arrancar a escribir código tras "replícame X" sin tabla comparativa.
-- Presentar las opciones sin recomendar — pasar la pelota al usuario.
-- Listar 5+ opciones cuando 3 son suficientes (mínima / media / completa).
-- Estimar esfuerzo en términos vagos ("bastante trabajo", "no mucho") sin
-  cuantificar turnos / archivos / LOC.
-- Omitir la auditoría de lo que ya existe y proponer porte literal de todo.
-- Cuando el usuario pide la opción mínima, expandir el alcance "porque
-  conviene" sin pedir confirmación.
-
----
-
-## Origen de esta regla
-
-Consolidada el 2026-05-04 desde feedback del usuario en sesión 2026-04-18 sobre
-porte de Hermes Agent: tras pedir "replicar íntegramente Hermes Agent" (~960
-archivos Python), aceptó la propuesta de cerrar solo 3 gaps específicos
-(perfil de usuario, cron natural, auto-evolución). Lección: la auditoría previa
-+ opciones explícitas evita re-implementar 80% de funcionalidad ya existente.
-
-Reforzada en análisis de repos en `temp/` durante v1.1.0 de swl-ses (2026-04-23):
-filtro de dominio descartó 97% del contenido de 5 repos antes de análisis
-profundo, ahorrando horas de trabajo en arquitectura externa irrelevante.
-
-Memoria nativa local correspondiente (`feedback_analisis_previo.md` en swl-ses):
-redundante tras esta regla; el contenido operativo vive aquí.
+# Regla: Análisis previo ante tareas grandes
+
+Esta regla es OBLIGATORIA y aplica a todo trabajo donde la solicitud del usuario
+implique cambio masivo: porte de sistema, refactor cross-módulo, replicación de
+arquitectura externa, migración de stack, instalación de framework completo,
+adopción de patrón en N módulos.
+
+---
+
+## Principio
+
+> Cuando el usuario pide "replicar íntegramente X", "portar todo Y", "implementar
+> el sistema completo Z", **responde primero con análisis comparativo (qué ya
+> existe vs. qué falta) y propón 3 opciones de alcance** (mínima / media /
+> completa) antes de escribir código. Nunca arrancar el porte literal sin
+> confirmación explícita tras presentar opciones.
+
+---
+
+## Cómo aplicar
+
+### Detección — qué cuenta como "tarea grande"
+
+Cualquier solicitud que tenga al menos uno de estos atributos:
+
+- Más de ~10 archivos a crear, mover o reescribir.
+- Más de ~500 LOC estimadas a tocar en un solo turno.
+- Toca más de un dominio (backend + frontend, o varios módulos backend).
+- "Replicar X" donde X es un sistema externo con su propia arquitectura.
+- "Portar todo de Y" donde Y es un repo, framework o lib voluminoso.
+- "Implementar todo Z" donde Z es una fase, un sub-sistema, una capa nueva.
+- Análisis de un repo en `temp/` con la pregunta abierta "¿qué adoptamos?".
+
+Si la solicitud encaja en cualquiera de estas, aplicar la regla.
+
+### Paso 1 — Auditar lo que ya existe
+
+Antes de proponer el porte:
+
+- `Glob` / `Grep` / `Read` para mapear el código actual del usuario.
+- Identificar componentes que ya cubren parte de la solicitud.
+- Verificar versiones, dependencias, convenciones del proyecto.
+- Si es repo externo en `temp/`: aplicar **filtro de dominio** primero
+  (ver `reglas/arquitectura.md` § "Análisis de repositorios externos").
+  Descartar 80-95% del contenido vertical antes de análisis profundo.
+
+### Paso 2 — Tabla comparativa
+
+Producir una tabla con tres columnas:
+
+| Componente del sistema externo | Equivalente actual del usuario | Gap |
+|---|---|---|
+| ... | ya existe / parcial / no existe | qué falta agregar |
+
+Sin la tabla, no se proponen opciones. La tabla es la base objetiva de la decisión.
+
+### Paso 3 — Tres opciones de alcance
+
+Siempre presentar tres opciones:
+
+- **Mínima** — solo cierra los gaps críticos (lo que NO existe). Esfuerzo
+  estimado bajo. Usuario acepta vivir con diferencias menores en lo demás.
+- **Media** — cierra gaps + alinea componentes parciales con el patrón externo.
+  Esfuerzo medio. Convergencia parcial sin reescribir lo que ya funciona.
+- **Completa** — porte literal de todo lo que el usuario pidió, sin reusar
+  componentes existentes. Esfuerzo alto. Justificable solo cuando la
+  arquitectura externa es estrictamente superior.
+
+Cada opción incluye:
+
+- Estimación de esfuerzo (turnos, LOC, archivos afectados).
+- Lista de tareas concretas si se elige.
+- Riesgos / tradeoffs específicos.
+
+### Paso 4 — Recomendación explícita
+
+Tras las tres opciones, **recomendar una** con razonamiento. No dejar la
+decisión "abierta" — el usuario espera tu juicio técnico.
+
+Patrón de recomendación:
+
+> **Recomiendo la opción [N]** porque [razón concreta]. Las opciones [otras]
+> son válidas si [condición específica].
+
+### Paso 5 — Esperar confirmación
+
+Después de presentar tabla + opciones + recomendación: detenerse y esperar.
+
+NO arrancar a escribir código asumiendo aprobación implícita. La autorización
+debe ser literal del usuario ("procede con la opción 2", "adelante con la
+mínima", "hagamos la completa").
+
+---
+
+## Excepciones — cuándo NO aplicar la regla
+
+NO aplicar cuando:
+
+1. **El usuario ya pidió explícitamente la opción**: "implementa la versión
+   mínima de X" o "porta solo el módulo Y" — la elección ya está hecha.
+2. **El alcance es trivial** — menos de 5 archivos, una sola dependencia.
+3. **El usuario pidió análisis y ya decidió**: si ya hubo una sesión previa con
+   la tabla comparativa y el usuario eligió, proceder sin re-presentar.
+4. **Es un fix urgente de producción** — bug crítico, vulnerabilidad activa,
+   incidente. El análisis se reduce a confirmar la causa y aplicar el fix
+   específico.
+
+---
+
+## Cómo presentar la tabla y opciones
+
+### Formato de tabla comparativa (mínimo)
+
+```markdown
+| Componente | Sistema externo | Tu sistema actual | Gap |
+|---|---|---|---|
+| Auth | OAuth2 + PKCE | JWT custom | parcial — falta PKCE |
+| Storage | S3 + presigned | filesystem local | falta — pendiente migración |
+| ... | ... | ... | ... |
+```
+
+### Formato de las tres opciones (mínimo)
+
+```markdown
+**Opción A — Mínima** (~3 turnos, ~15 archivos)
+- Cerrar solo gaps críticos: PKCE, presigned URLs.
+- No tocar lo que ya funciona.
+- Riesgo: leve divergencia con sistema externo en convenciones menores.
+
+**Opción B — Media** (~6 turnos, ~30 archivos)
+- Cerrar gaps + alinear `auth/` con patrón OAuth2 completo.
+- Mantener storage actual con migración planeada en fase futura.
+- Riesgo: refactor en `auth/` puede romper integraciones existentes.
+
+**Opción C — Completa** (~15 turnos, ~80 archivos)
+- Porte literal del sistema externo completo.
+- Reemplaza todo lo equivalente, no importa que ya funcione.
+- Riesgo: regresiones en funcionalidad madura.
+
+**Recomiendo la Opción A**: el sistema actual cubre el 80% del valor;
+los gaps específicos resuelven el caso concreto sin riesgo de regresión.
+```
+
+---
+
+## Anti-patrones
+
+- Arrancar a escribir código tras "replícame X" sin tabla comparativa.
+- Presentar las opciones sin recomendar — pasar la pelota al usuario.
+- Listar 5+ opciones cuando 3 son suficientes (mínima / media / completa).
+- Estimar esfuerzo en términos vagos ("bastante trabajo", "no mucho") sin
+  cuantificar turnos / archivos / LOC.
+- Omitir la auditoría de lo que ya existe y proponer porte literal de todo.
+- Cuando el usuario pide la opción mínima, expandir el alcance "porque
+  conviene" sin pedir confirmación.
+
+---
+
+## Origen de esta regla
+
+Consolidada el 2026-05-04 desde feedback del usuario en sesión 2026-04-18 sobre
+porte de Hermes Agent: tras pedir "replicar íntegramente Hermes Agent" (~960
+archivos Python), aceptó la propuesta de cerrar solo 3 gaps específicos
+(perfil de usuario, cron natural, auto-evolución). Lección: la auditoría previa
++ opciones explícitas evita re-implementar 80% de funcionalidad ya existente.
+
+Reforzada en análisis de repos en `temp/` durante v1.1.0 de swl-ses (2026-04-23):
+filtro de dominio descartó 97% del contenido de 5 repos antes de análisis
+profundo, ahorrando horas de trabajo en arquitectura externa irrelevante.
+
+Memoria nativa local correspondiente (`feedback_analisis_previo.md` en swl-ses):
+redundante tras esta regla; el contenido operativo vive aquí.

package/reglas/api-diseno.md

@@ -1,12 +1,12 @@
----
-paths:
-  - "**/api/**"
-  - "**/routers/**"
-  - "**/controllers/**"
-  - "**/handlers/**"
-  - "**/endpoints/**"
-  - "**/openapi.{yaml,yml,json}"
----
+---
+paths:
+  - "**/api/**"
+  - "**/routers/**"
+  - "**/controllers/**"
+  - "**/handlers/**"
+  - "**/endpoints/**"
+  - "**/openapi.{yaml,yml,json}"
+---
 # Regla: Diseño de APIs REST
 
 Esta regla es OBLIGATORIA para toda API REST expuesta, ya sea pública o interna.