@saulwade/swl-ses 2.6.1 → 2.8.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/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 ./...

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,7 +1,7 @@
 {
   "name": "swl-ses",
-  "version": "2.6.1",
-  "description": "Sistema de ingenieria de software auto-evolutivo multi-runtime polyglot. 61 agentes, 181 habilidades, 48 comandos, 77 reglas y 49 hooks. 76 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.",
+  "version": "2.8.0",
+  "description": "Sistema de ingeniería de software auto-evolutivo para proyectos downstream, políglota en 11 lenguajes, con 61 agentes, 181 habilidades, 48 comandos, 77 reglas, 49 hooks, instalación multi-target, MCP, gateway y auditoría Nemesis. Siete targets runtime con compatibilidad experimental y certificación pendiente de evidencia externa.",
   "author": "Saul Wade Leon",
   "license": "MIT",
   "repository": "https://github.com/saul-wade/swl-ses",

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.