@saulwade/swl-ses 2.3.0 → 2.4.1

package/package.json

@@ -1,93 +1,93 @@
-{
-  "name": "@saulwade/swl-ses",
-  "version": "2.3.0",
-  "description": "Sistema de ingenieria de software auto-evolutivo multi-runtime polyglot con 60 agentes, 182 habilidades, 44 comandos, 77 reglas y 50 hooks. Soporta 11 lenguajes y 7 runtimes: Claude Code, OpenClaude, OpenCode, Gemini CLI, Cursor, Codex CLI (soporte completo); GitHub Copilot (soporte parcial). 100% en espanol (Mexico). Multi-target install (--target CSV / --all-runtimes), autoconfig MCP en Cursor/Codex con --with-mcp, agentes Codex en TOML, hooks Cursor (17 eventos) y Codex (6 eventos). Gateway bidireccional con relay Telegram y auditoria profunda Nemesis con loop evaluator-optimizer opt-in (ADR-0021) y 8 tools ejecutables. 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.",
-  "bin": {
-    "swl-ses": "bin/swl-ses.js",
-    "swl-telegram-bot": "bin/swl-telegram-bot.js",
-    "swl-mcp-server": "bin/swl-mcp-server.js",
-    "swl-webhook-server": "bin/swl-webhook-server.js"
-  },
-  "files": [
-    "bin",
-    "scripts",
-    "manifiestos",
-    "agentes",
-    "habilidades",
-    "comandos",
-    "reglas",
-    "hooks",
-    "gateway",
-    "plantillas",
-    "contextos",
-    "instintos",
-    "schemas",
-    "_userland",
-    "plugin.json",
-    "CLAUDE.md",
-    "llms.txt"
-  ],
-  "scripts": {
-    "postinstall": "echo '\n  swl-software-engineering-system instalado.\n  Ejecuta: npx swl-ses init\n'",
-    "test": "node --test tests/lib/*.test.js tests/scripts/*.test.js tests/scripts/lib/*.test.js tests/scripts/tui/*.test.js tests/hooks/*.test.js tests/hooks/lib/*.test.js tests/habilidades/*.test.js tests/gateway/*.test.js tests/bin/*.test.js tests/transformadores/*.test.js tests/mcp-server/*.test.js",
-    "test:validate": "node scripts/validar.js",
-    "test:manifest": "node scripts/validar-manifest.js",
-    "test:docs": "node scripts/verificar-docs-vs-codigo.js",
-    "test:smoke": "node scripts/smoke-test.js",
-    "test:aislamiento": "node scripts/validar-tests-aislamiento.js",
-    "test:all": "npm test && node scripts/validar.js && node scripts/validar-manifest.js && node scripts/verificar-docs-vs-codigo.js && node scripts/derivar-feature-list.js --check",
-    "test:userland": "node scripts/validar-userland-vacio.js",
-    "test:release": "npm run test:all && npm run test:userland && npm run test:smoke",
-    "doctor": "node scripts/doctor.js",
-    "prepack": "node scripts/limpiar-artefactos-python.js && node scripts/validar-userland-vacio.js",
-    "prepublishOnly": "npm run test:release",
-    "publish:all": "node scripts/publicar.js",
-    "publish:github": "node scripts/publicar.js --solo-github",
-    "publish:npmjs": "node scripts/publicar.js --solo-npmjs",
-    "publish:dry": "node scripts/publicar.js --dry-run",
-    "generate:docs": "node scripts/generar-inventario.js",
-    "gen-checklists": "node scripts/generar-checklists-consolidados.js",
-    "gen-checklists:check": "node scripts/generar-checklists-consolidados.js --check",
-    "gen:feature-list": "node scripts/derivar-feature-list.js",
-    "gen:feature-list:check": "node scripts/derivar-feature-list.js --check",
-    "field-report": "node scripts/field-report.js",
-    "configure:branch-protection": "node scripts/configurar-branch-protection.js"
-  },
-  "engines": {
-    "node": ">=22.0.0"
-  },
-  "keywords": [
-    "claude-code",
-    "github-copilot",
-    "gemini-cli",
-    "opencode",
-    "codex-cli",
-    "agentes",
-    "skills",
-    "multi-runtime",
-    "spec-driven",
-    "orquestacion",
-    "ingenieria-software"
-  ],
-  "author": "Saul Wade Leon",
-  "license": "MIT",
-  "repository": {
-    "type": "git",
-    "url": "git+https://github.com/saul-wade/swl-ses.git"
-  },
-  "homepage": "https://github.com/saul-wade/swl-ses#readme",
-  "bugs": {
-    "url": "https://github.com/saul-wade/swl-ses/issues"
-  },
-  "publishConfig": {
-    "registry": "https://registry.npmjs.org/",
-    "access": "public"
-  },
-  "dependencies": {
-    "docx": "^9.6.1"
-  },
-  "overrides": {
-    "pako": "^2.1.0",
-    "readable-stream": "^4.7.0"
-  }
-}
+{
+  "name": "@saulwade/swl-ses",
+  "version": "2.4.1",
+  "description": "Sistema de ingenieria de software auto-evolutivo multi-runtime polyglot con 60 agentes, 182 habilidades, 45 comandos, 77 reglas y 49 hooks. Soporta 11 lenguajes y 7 runtimes: Claude Code, OpenClaude, OpenCode, Gemini CLI, Cursor, Codex CLI (soporte completo); GitHub Copilot (soporte parcial). 100% en espanol (Mexico). Multi-target install (--target CSV / --all-runtimes), autoconfig MCP en Cursor/Codex con --with-mcp, agentes Codex en TOML, hooks Cursor (17 eventos) y Codex (6 eventos). Gateway bidireccional con relay Telegram y auditoria profunda Nemesis con loop evaluator-optimizer opt-in (ADR-0021) y 8 tools ejecutables. 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.",
+  "bin": {
+    "swl-ses": "bin/swl-ses.js",
+    "swl-telegram-bot": "bin/swl-telegram-bot.js",
+    "swl-mcp-server": "bin/swl-mcp-server.js",
+    "swl-webhook-server": "bin/swl-webhook-server.js"
+  },
+  "files": [
+    "bin",
+    "scripts",
+    "manifiestos",
+    "agentes",
+    "habilidades",
+    "comandos",
+    "reglas",
+    "hooks",
+    "gateway",
+    "plantillas",
+    "contextos",
+    "instintos",
+    "schemas",
+    "_userland",
+    "plugin.json",
+    "CLAUDE.md",
+    "llms.txt"
+  ],
+  "scripts": {
+    "postinstall": "echo '\n  swl-software-engineering-system instalado.\n  Ejecuta: npx swl-ses init\n'",
+    "test": "node --test tests/lib/*.test.js tests/scripts/*.test.js tests/scripts/lib/*.test.js tests/scripts/tui/*.test.js tests/hooks/*.test.js tests/hooks/lib/*.test.js tests/habilidades/*.test.js tests/gateway/*.test.js tests/bin/*.test.js tests/transformadores/*.test.js tests/mcp-server/*.test.js",
+    "test:validate": "node scripts/validar.js",
+    "test:manifest": "node scripts/validar-manifest.js",
+    "test:docs": "node scripts/verificar-docs-vs-codigo.js",
+    "test:smoke": "node scripts/smoke-test.js",
+    "test:aislamiento": "node scripts/validar-tests-aislamiento.js",
+    "test:all": "npm test && node scripts/validar.js && node scripts/validar-manifest.js && node scripts/verificar-docs-vs-codigo.js && node scripts/derivar-feature-list.js --check",
+    "test:userland": "node scripts/validar-userland-vacio.js",
+    "test:release": "npm run test:all && npm run test:userland && npm run test:smoke",
+    "doctor": "node scripts/doctor.js",
+    "prepack": "node scripts/limpiar-artefactos-python.js && node scripts/validar-userland-vacio.js",
+    "prepublishOnly": "npm run test:release",
+    "publish:all": "node scripts/publicar.js",
+    "publish:github": "node scripts/publicar.js --solo-github",
+    "publish:npmjs": "node scripts/publicar.js --solo-npmjs",
+    "publish:dry": "node scripts/publicar.js --dry-run",
+    "generate:docs": "node scripts/generar-inventario.js",
+    "gen-checklists": "node scripts/generar-checklists-consolidados.js",
+    "gen-checklists:check": "node scripts/generar-checklists-consolidados.js --check",
+    "gen:feature-list": "node scripts/derivar-feature-list.js",
+    "gen:feature-list:check": "node scripts/derivar-feature-list.js --check",
+    "field-report": "node scripts/field-report.js",
+    "configure:branch-protection": "node scripts/configurar-branch-protection.js"
+  },
+  "engines": {
+    "node": ">=22.0.0"
+  },
+  "keywords": [
+    "claude-code",
+    "github-copilot",
+    "gemini-cli",
+    "opencode",
+    "codex-cli",
+    "agentes",
+    "skills",
+    "multi-runtime",
+    "spec-driven",
+    "orquestacion",
+    "ingenieria-software"
+  ],
+  "author": "Saul Wade Leon",
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/saul-wade/swl-ses.git"
+  },
+  "homepage": "https://github.com/saul-wade/swl-ses#readme",
+  "bugs": {
+    "url": "https://github.com/saul-wade/swl-ses/issues"
+  },
+  "publishConfig": {
+    "registry": "https://registry.npmjs.org/",
+    "access": "public"
+  },
+  "dependencies": {
+    "docx": "^9.6.1"
+  },
+  "overrides": {
+    "pako": "^2.1.0",
+    "readable-stream": "^4.7.0"
+  }
+}

package/plantillas/auditor-veto-template.md

@@ -1,105 +1,105 @@
-# Plantilla: Auditor con Veto Items + Cap Enforcement
-
-Plantilla reusable para revisores SWL que aplican el patrón "veto items + cap
-enforcement". Ver `reglas/gobernanza.md` sección "Veto items y cap enforcement".
-
----
-
-## Cuándo usar esta plantilla
-
-Cuando crees o actualices un revisor (`revisor-*-swl.md`) que:
-
-- Audita cumplimiento de reglas globales del sistema (`reglas/*.md`).
-- Necesita comunicar al lector cuáles violaciones son **no negociables**.
-- Debe evitar que un score promedio "redondeado" oculte un problema crítico.
-
----
-
-## Estructura a copiar (insertar antes de "Formato de reporte obligatorio")
-
-```markdown
-## Veto items — cap enforcement a [LÍMITE]
-
-Ciertos hallazgos son **no negociables**. Si encuentras CUALQUIERA de los
-siguientes, el `score` del reporte queda **CAP a [LÍMITE] como máximo absoluto**,
-independientemente de qué tan limpio esté el resto del código. Patrón adaptado
-del modelo de auditor con veto items (ver `reglas/gobernanza.md`).
-
-**Lista de veto items**:
-
-1. **[Nombre del veto]**: [descripción específica + regla que viola].
-2. ...
-N. ...
-
-**Reglas del cap**:
-
-- Encontrar 1 veto item → `score ≤ [LÍMITE]`. Veredicto automático:
-  `RECHAZADO` o `APROBADO CON CORRECCIONES` (nunca `APROBADO` limpio).
-- Encontrar 2+ veto items → `score ≤ [LÍMITE_ESTRICTO]`. Bloqueo absoluto.
-- El veto NO se puede negociar bajando severidad.
-- El cap se levanta SOLO cuando se demuestra remediación (commit + test) y el
-  revisor re-ejecuta la auditoría.
-
-Reportar al inicio del reporte con bloque dedicado:
-
-\`\`\`
-### VETO ITEMS DETECTADOS
-- [VI-1] <descripción>: \`archivo:linea\` — <evidencia>
-- [VI-N] <descripción>: \`archivo:linea\` — <evidencia>
-→ score CAP a [VALOR] ([N] veto items). Veredicto: [VEREDICTO].
-\`\`\`
-
-Si no se detecta ninguno: \`### VETO ITEMS DETECTADOS\n- Ninguno\`.
-```
-
----
-
-## Reglas para definir veto items
-
-Antes de declarar un veto item, verifica:
-
-1. **¿Existe una regla global que lo respalde?** Si no, no es veto. Crear o
-   actualizar la regla primero (`reglas/<dominio>.md`).
-2. **¿Es objetivamente detectable?** Un veto debe ser binario (presente o
-   ausente). Criterios subjetivos como "código feo" no califican.
-3. **¿Su presencia justifica bloquear el merge?** Si el equipo puede aprobar
-   el código sin corregirlo, no es veto — es hallazgo regular.
-4. **¿Es proporcional al dominio del revisor?** Un revisor de seguridad no
-   declara vetos de estilo. Cada revisor solo veta lo de su dominio.
-5. **¿Está la lista cerrada?** Una lista de 50 veto items es señal de mala
-   curación. Lo razonable: 8-15 items por revisor.
-
----
-
-## Escalas recomendadas
-
-| Tipo de reporte | Cap con 1 veto | Cap con 2+ vetos |
-|-----------------|---------------|-----------------|
-| Score 0-100 (CVSSv3-like) | 60/100 | 30/100 |
-| Score 0-10 promedio por dimensión | 6.0/10 | 3.0/10 |
-| Score 0-1 (probabilístico) | 0.6 | 0.3 |
-
----
-
-## Ejemplos en agentes existentes
-
-- `agentes/revisor-seguridad-swl.md` — 10 veto items de OWASP Top 10 + secrets + CVEs
-- `agentes/revisor-codigo-swl.md` — 10 veto items mapeando a `reglas/estilo-codigo.md`
-  y `reglas/arquitectura.md`
-
----
-
-## Cómo el ejecutor responde a un cap
-
-Si recibes un reporte con veto items detectados:
-
-1. **NO negocies la severidad**. El cap está justificado por regla global.
-2. **Aplica las correcciones específicas** que el revisor indica con
-   archivo:línea.
-3. **Agrega un test que pruebe la corrección** (regression test). Sin test,
-   el veto puede regresar.
-4. **Solicita re-revisión** al mismo revisor. Si el veto desapareció, el cap
-   se levanta y el score se recalcula sin penalización.
-5. **Si NO puedes corregir** (limitación externa, blocker técnico): documenta
-   en `.planning/AUDITORIA.md` y escala al humano. NUNCA marques el trabajo
-   como completado con vetos abiertos.
+# Plantilla: Auditor con Veto Items + Cap Enforcement
+
+Plantilla reusable para revisores SWL que aplican el patrón "veto items + cap
+enforcement". Ver `reglas/gobernanza.md` sección "Veto items y cap enforcement".
+
+---
+
+## Cuándo usar esta plantilla
+
+Cuando crees o actualices un revisor (`revisor-*-swl.md`) que:
+
+- Audita cumplimiento de reglas globales del sistema (`reglas/*.md`).
+- Necesita comunicar al lector cuáles violaciones son **no negociables**.
+- Debe evitar que un score promedio "redondeado" oculte un problema crítico.
+
+---
+
+## Estructura a copiar (insertar antes de "Formato de reporte obligatorio")
+
+```markdown
+## Veto items — cap enforcement a [LÍMITE]
+
+Ciertos hallazgos son **no negociables**. Si encuentras CUALQUIERA de los
+siguientes, el `score` del reporte queda **CAP a [LÍMITE] como máximo absoluto**,
+independientemente de qué tan limpio esté el resto del código. Patrón adaptado
+del modelo de auditor con veto items (ver `reglas/gobernanza.md`).
+
+**Lista de veto items**:
+
+1. **[Nombre del veto]**: [descripción específica + regla que viola].
+2. ...
+N. ...
+
+**Reglas del cap**:
+
+- Encontrar 1 veto item → `score ≤ [LÍMITE]`. Veredicto automático:
+  `RECHAZADO` o `APROBADO CON CORRECCIONES` (nunca `APROBADO` limpio).
+- Encontrar 2+ veto items → `score ≤ [LÍMITE_ESTRICTO]`. Bloqueo absoluto.
+- El veto NO se puede negociar bajando severidad.
+- El cap se levanta SOLO cuando se demuestra remediación (commit + test) y el
+  revisor re-ejecuta la auditoría.
+
+Reportar al inicio del reporte con bloque dedicado:
+
+\`\`\`
+### VETO ITEMS DETECTADOS
+- [VI-1] <descripción>: \`archivo:linea\` — <evidencia>
+- [VI-N] <descripción>: \`archivo:linea\` — <evidencia>
+→ score CAP a [VALOR] ([N] veto items). Veredicto: [VEREDICTO].
+\`\`\`
+
+Si no se detecta ninguno: \`### VETO ITEMS DETECTADOS\n- Ninguno\`.
+```
+
+---
+
+## Reglas para definir veto items
+
+Antes de declarar un veto item, verifica:
+
+1. **¿Existe una regla global que lo respalde?** Si no, no es veto. Crear o
+   actualizar la regla primero (`reglas/<dominio>.md`).
+2. **¿Es objetivamente detectable?** Un veto debe ser binario (presente o
+   ausente). Criterios subjetivos como "código feo" no califican.
+3. **¿Su presencia justifica bloquear el merge?** Si el equipo puede aprobar
+   el código sin corregirlo, no es veto — es hallazgo regular.
+4. **¿Es proporcional al dominio del revisor?** Un revisor de seguridad no
+   declara vetos de estilo. Cada revisor solo veta lo de su dominio.
+5. **¿Está la lista cerrada?** Una lista de 50 veto items es señal de mala
+   curación. Lo razonable: 8-15 items por revisor.
+
+---
+
+## Escalas recomendadas
+
+| Tipo de reporte | Cap con 1 veto | Cap con 2+ vetos |
+|-----------------|---------------|-----------------|
+| Score 0-100 (CVSSv3-like) | 60/100 | 30/100 |
+| Score 0-10 promedio por dimensión | 6.0/10 | 3.0/10 |
+| Score 0-1 (probabilístico) | 0.6 | 0.3 |
+
+---
+
+## Ejemplos en agentes existentes
+
+- `agentes/revisor-seguridad-swl.md` — 10 veto items de OWASP Top 10 + secrets + CVEs
+- `agentes/revisor-codigo-swl.md` — 10 veto items mapeando a `reglas/estilo-codigo.md`
+  y `reglas/arquitectura.md`
+
+---
+
+## Cómo el ejecutor responde a un cap
+
+Si recibes un reporte con veto items detectados:
+
+1. **NO negocies la severidad**. El cap está justificado por regla global.
+2. **Aplica las correcciones específicas** que el revisor indica con
+   archivo:línea.
+3. **Agrega un test que pruebe la corrección** (regression test). Sin test,
+   el veto puede regresar.
+4. **Solicita re-revisión** al mismo revisor. Si el veto desapareció, el cap
+   se levanta y el score se recalcula sin penalización.
+5. **Si NO puedes corregir** (limitación externa, blocker técnico): documenta
+   en `.planning/AUDITORIA.md` y escala al humano. NUNCA marques el trabajo
+   como completado con vetos abiertos.

package/plantillas/github-workflows/README.md

@@ -1,47 +1,47 @@
-# Plantillas de GitHub Actions — swl-ses
-
-Tres workflows listos para copiar a `.github/workflows/` de cualquier proyecto.
-
-## Cómo instalar
-
-La forma recomendada es via el comando interactivo:
-
-```bash
-/swl:configurar-ci init
-```
-
-O manualmente: copiar los archivos de esta carpeta a `.github/workflows/` de tu proyecto.
-
-## Workflows disponibles
-
-### `swl-security.yml` — Revisión de seguridad con Claude
-
-Corre en cada PR a `main`. Analiza el diff con `anthropics/claude-code-security-review`
-y comenta hallazgos directamente en el PR.
-
-**Requiere**: secret `CLAUDE_API_KEY` en GitHub Settings → Secrets and variables → Actions.
-
-### `swl-ci.yml` — CI estándar
-
-Corre en push y PRs a `main`. Detecta Node.js automáticamente. Incluye secciones
-comentadas para Python, Rust y Go — activar las que correspondan al proyecto.
-
-- Matrix Node 22 + 24
-- `npm ci` → lint → type-check (si hay tsconfig.json) → tests
-- `concurrency: cancel-in-progress: true`
-
-**No requiere** secrets adicionales.
-
-### `release-please.yml` — Releases automáticos
-
-Tras merge a `main`, crea un Release PR con el bump de versión y CHANGELOG
-generados desde conventional commits. Al mergear el Release PR, crea el tag
-y el GitHub Release.
-
-**No requiere** secrets adicionales (usa `GITHUB_TOKEN`). Requiere conventional commits.
-
-Ver `docs/RELEASE-PLEASE-MIGRATION.md` para comparativa con el flujo manual actual.
-
-## Skill de referencia
-
-Para guía completa de setup, troubleshooting y gotchas: `Skill("infra-github-actions")`.
+# Plantillas de GitHub Actions — swl-ses
+
+Tres workflows listos para copiar a `.github/workflows/` de cualquier proyecto.
+
+## Cómo instalar
+
+La forma recomendada es via el comando interactivo:
+
+```bash
+/swl:configurar-ci init
+```
+
+O manualmente: copiar los archivos de esta carpeta a `.github/workflows/` de tu proyecto.
+
+## Workflows disponibles
+
+### `swl-security.yml` — Revisión de seguridad con Claude
+
+Corre en cada PR a `main`. Analiza el diff con `anthropics/claude-code-security-review`
+y comenta hallazgos directamente en el PR.
+
+**Requiere**: secret `CLAUDE_API_KEY` en GitHub Settings → Secrets and variables → Actions.
+
+### `swl-ci.yml` — CI estándar
+
+Corre en push y PRs a `main`. Detecta Node.js automáticamente. Incluye secciones
+comentadas para Python, Rust y Go — activar las que correspondan al proyecto.
+
+- Matrix Node 22 + 24
+- `npm ci` → lint → type-check (si hay tsconfig.json) → tests
+- `concurrency: cancel-in-progress: true`
+
+**No requiere** secrets adicionales.
+
+### `release-please.yml` — Releases automáticos
+
+Tras merge a `main`, crea un Release PR con el bump de versión y CHANGELOG
+generados desde conventional commits. Al mergear el Release PR, crea el tag
+y el GitHub Release.
+
+**No requiere** secrets adicionales (usa `GITHUB_TOKEN`). Requiere conventional commits.
+
+Ver `docs/RELEASE-PLEASE-MIGRATION.md` para comparativa con el flujo manual actual.
+
+## Skill de referencia
+
+Para guía completa de setup, troubleshooting y gotchas: `Skill("infra-github-actions")`.

package/plantillas/github-workflows/release-please.yml

@@ -1,44 +1,44 @@
-name: release-please
-
-# Plantilla distribuida por swl-ses.
-# Copiar este archivo a .github/workflows/ de tu proyecto.
-# Para setup automatizado: /swl:configurar-ci --with-release-please
-#
-# Release Please automatiza:
-#   - Crea un "Release PR" con el bump de versión y CHANGELOG generado
-#     automáticamente al detectar commits convencionales en main.
-#   - Al mergear el Release PR, crea el tag git y el GitHub Release.
-#
-# Requiere conventional commits (feat:, fix:, chore(release):, etc.)
-# No requiere secrets adicionales — usa el GITHUB_TOKEN automático.
-#
-# Referencia oficial: https://github.com/googleapis/release-please-action
-# Versión en uso: v4
-
-on:
-  push:
-    branches:
-      - main
-
-# release-please necesita escribir en el repo y abrir PRs.
-permissions:
-  contents: write
-  pull-requests: write
-
-name: release-please
-
-jobs:
-  release-please:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: googleapis/release-please-action@v4
-        with:
-          # GITHUB_TOKEN es suficiente en la mayoría de repos.
-          # Si el repo es de organización y las Actions no tienen permiso
-          # de crear PRs, crear un PAT y usar secrets.MY_RELEASE_TOKEN.
-          token: ${{ secrets.GITHUB_TOKEN }}
-          # Estrategia de release. Opciones comunes:
-          #   "node"    — para proyectos Node.js con package.json
-          #   "python"  — para pyproject.toml / setup.cfg
-          #   "simple"  — para cualquier stack (actualiza VERSION file)
-          release-type: node
+name: release-please
+
+# Plantilla distribuida por swl-ses.
+# Copiar este archivo a .github/workflows/ de tu proyecto.
+# Para setup automatizado: /swl:configurar-ci --with-release-please
+#
+# Release Please automatiza:
+#   - Crea un "Release PR" con el bump de versión y CHANGELOG generado
+#     automáticamente al detectar commits convencionales en main.
+#   - Al mergear el Release PR, crea el tag git y el GitHub Release.
+#
+# Requiere conventional commits (feat:, fix:, chore(release):, etc.)
+# No requiere secrets adicionales — usa el GITHUB_TOKEN automático.
+#
+# Referencia oficial: https://github.com/googleapis/release-please-action
+# Versión en uso: v4
+
+on:
+  push:
+    branches:
+      - main
+
+# release-please necesita escribir en el repo y abrir PRs.
+permissions:
+  contents: write
+  pull-requests: write
+
+name: release-please
+
+jobs:
+  release-please:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: googleapis/release-please-action@v4
+        with:
+          # GITHUB_TOKEN es suficiente en la mayoría de repos.
+          # Si el repo es de organización y las Actions no tienen permiso
+          # de crear PRs, crear un PAT y usar secrets.MY_RELEASE_TOKEN.
+          token: ${{ secrets.GITHUB_TOKEN }}
+          # Estrategia de release. Opciones comunes:
+          #   "node"    — para proyectos Node.js con package.json
+          #   "python"  — para pyproject.toml / setup.cfg
+          #   "simple"  — para cualquier stack (actualiza VERSION file)
+          release-type: node