@saulwade/swl-ses 1.5.0 → 1.5.2

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@saulwade/swl-ses",
-  "version": "1.5.0",
-  "description": "Sistema de ingenieria de software auto-evolutivo multi-runtime polyglot con 60 agentes, 158 habilidades, 44 comandos, 65 reglas y 41 hooks. Soporta 11 lenguajes y 7 runtimes: Claude Code, OpenClaude, OpenCode, Gemini CLI (soporte completo), Cursor, Codex CLI y GitHub Copilot (soporte parcial — reglas + MCP swl-memory v1.0.0 con auth opt-in). 100% en espanol (Mexico). Multi-target install (--target CSV / --all-runtimes) y autoconfig MCP en Cursor/Codex con --with-mcp. Gateway bidireccional con relay Telegram y auditoria profunda Nemesis con 8 tools ejecutables.",
+  "version": "1.5.2",
+  "description": "Sistema de ingenieria de software auto-evolutivo multi-runtime polyglot con 60 agentes, 162 habilidades, 44 comandos, 66 reglas y 41 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.",
   "bin": {
     "swl-ses": "bin/swl-ses.js",
     "swl-telegram-bot": "bin/swl-telegram-bot.js",

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

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

@@ -1,107 +1,107 @@
-name: CI
-
-# Plantilla distribuida por swl-ses.
-# Copiar este archivo a .github/workflows/ de tu proyecto.
-# Para setup automatizado: /swl:configurar-ci init
-#
-# Este workflow corre en push y PRs a main.
-# Detecta automáticamente Node.js; los stacks adicionales están comentados.
-# Activar las secciones que correspondan a tu proyecto.
-#
-# Para extender con Python, Rust o Go: descomentar las secciones al final
-# y combinar con el job principal o crear jobs separados según convenga.
-
-on:
-  push:
-    branches: [main]
-  pull_request:
-    branches: [main]
-
-# Cancela runs anteriores del mismo PR para evitar deploys simultáneos.
-concurrency:
-  group: ${{ github.workflow }}-${{ github.ref }}
-  cancel-in-progress: true
-
-jobs:
-  test:
-    runs-on: ubuntu-latest
-    strategy:
-      fail-fast: false
-      matrix:
-        # Node 22 (LTS) + Node 24 (current). Ajustar si el proyecto requiere
-        # solo una versión.
-        node-version: [22, 24]
-
-    steps:
-      - uses: actions/checkout@v5
-
-      - name: Configurar Node.js ${{ matrix.node-version }}
-        uses: actions/setup-node@v5
-        with:
-          node-version: ${{ matrix.node-version }}
-          cache: npm
-
-      # ── Node.js / JavaScript / TypeScript ────────────────────────────────
-
-      - name: Instalar dependencias
-        if: hashFiles('package.json') != ''
-        run: npm ci
-
-      - name: Lint
-        if: hashFiles('package.json') != ''
-        # Ajustar el script según cómo esté configurado en package.json.
-        # Alternativas comunes: "lint", "lint:check", "eslint"
-        run: npm run lint --if-present
-
-      - name: Verificar tipos (TypeScript)
-        if: hashFiles('tsconfig.json') != ''
-        run: npx tsc --noEmit
-
-      - name: Ejecutar tests
-        if: hashFiles('package.json') != ''
-        run: npm test
-
-      # ── Python ────────────────────────────────────────────────────────────
-      # Descomentar si el proyecto tiene código Python.
-      #
-      # - name: Configurar Python
-      #   if: hashFiles('pyproject.toml', 'setup.py', 'requirements.txt') != ''
-      #   uses: actions/setup-python@v5
-      #   with:
-      #     python-version: "3.11"
-      #     cache: pip
-      #
-      # - name: Instalar dependencias Python
-      #   if: hashFiles('pyproject.toml') != ''
-      #   run: pip install -e ".[dev]"
-      #
-      # - name: Lint Python (ruff)
-      #   run: ruff check .
-      #
-      # - name: Tests Python
-      #   run: pytest --cov-fail-under=80
-
-      # ── Rust ─────────────────────────────────────────────────────────────
-      # Descomentar si el proyecto tiene código Rust.
-      #
-      # - name: Configurar Rust
-      #   if: hashFiles('Cargo.toml') != ''
-      #   uses: dtolnay/rust-toolchain@stable
-      #
-      # - name: Lint Rust (clippy)
-      #   run: cargo clippy -- -D warnings
-      #
-      # - name: Tests Rust
-      #   run: cargo test
-
-      # ── Go ───────────────────────────────────────────────────────────────
-      # Descomentar si el proyecto tiene código Go.
-      #
-      # - name: Configurar Go
-      #   if: hashFiles('go.mod') != ''
-      #   uses: actions/setup-go@v5
-      #   with:
-      #     go-version: stable
-      #
-      # - name: Tests Go
-      #   run: go test ./...
+name: CI
+
+# Plantilla distribuida por swl-ses.
+# Copiar este archivo a .github/workflows/ de tu proyecto.
+# Para setup automatizado: /swl:configurar-ci init
+#
+# Este workflow corre en push y PRs a main.
+# Detecta automáticamente Node.js; los stacks adicionales están comentados.
+# Activar las secciones que correspondan a tu proyecto.
+#
+# Para extender con Python, Rust o Go: descomentar las secciones al final
+# y combinar con el job principal o crear jobs separados según convenga.
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+# Cancela runs anteriores del mismo PR para evitar deploys simultáneos.
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        # Node 22 (LTS) + Node 24 (current). Ajustar si el proyecto requiere
+        # solo una versión.
+        node-version: [22, 24]
+
+    steps:
+      - uses: actions/checkout@v5
+
+      - name: Configurar Node.js ${{ matrix.node-version }}
+        uses: actions/setup-node@v5
+        with:
+          node-version: ${{ matrix.node-version }}
+          cache: npm
+
+      # ── Node.js / JavaScript / TypeScript ────────────────────────────────
+
+      - name: Instalar dependencias
+        if: hashFiles('package.json') != ''
+        run: npm ci
+
+      - name: Lint
+        if: hashFiles('package.json') != ''
+        # Ajustar el script según cómo esté configurado en package.json.
+        # Alternativas comunes: "lint", "lint:check", "eslint"
+        run: npm run lint --if-present
+
+      - name: Verificar tipos (TypeScript)
+        if: hashFiles('tsconfig.json') != ''
+        run: npx tsc --noEmit
+
+      - name: Ejecutar tests
+        if: hashFiles('package.json') != ''
+        run: npm test
+
+      # ── Python ────────────────────────────────────────────────────────────
+      # Descomentar si el proyecto tiene código Python.
+      #
+      # - name: Configurar Python
+      #   if: hashFiles('pyproject.toml', 'setup.py', 'requirements.txt') != ''
+      #   uses: actions/setup-python@v5
+      #   with:
+      #     python-version: "3.11"
+      #     cache: pip
+      #
+      # - name: Instalar dependencias Python
+      #   if: hashFiles('pyproject.toml') != ''
+      #   run: pip install -e ".[dev]"
+      #
+      # - name: Lint Python (ruff)
+      #   run: ruff check .
+      #
+      # - name: Tests Python
+      #   run: pytest --cov-fail-under=80
+
+      # ── Rust ─────────────────────────────────────────────────────────────
+      # Descomentar si el proyecto tiene código Rust.
+      #
+      # - name: Configurar Rust
+      #   if: hashFiles('Cargo.toml') != ''
+      #   uses: dtolnay/rust-toolchain@stable
+      #
+      # - name: Lint Rust (clippy)
+      #   run: cargo clippy -- -D warnings
+      #
+      # - name: Tests Rust
+      #   run: cargo test
+
+      # ── Go ───────────────────────────────────────────────────────────────
+      # Descomentar si el proyecto tiene código Go.
+      #
+      # - name: Configurar Go
+      #   if: hashFiles('go.mod') != ''
+      #   uses: actions/setup-go@v5
+      #   with:
+      #     go-version: stable
+      #
+      # - name: Tests Go
+      #   run: go test ./...