@saulwade/swl-ses 1.0.0

package/plantillas/HOJA-RUTA.md

@@ -0,0 +1,143 @@
+# ROADMAP: [Nombre del Proyecto]
+
+> Versión: 0.1 | Última actualización: YYYY-MM-DD
+> El roadmap refleja el plan actual. Las fases futuras son estimaciones —
+> se refinan conforme se completan las fases anteriores.
+
+---
+
+## Resumen de fases
+
+| Fase | Nombre | Objetivo | Duración estimada | Estado |
+|------|--------|----------|-------------------|--------|
+| 1 | [Nombre] | [Qué se logra al terminar] | [N semanas] | Pendiente |
+| 2 | [Nombre] | [Qué se logra al terminar] | [N semanas] | Pendiente |
+| 3 | [Nombre] | [Qué se logra al terminar] | [N semanas] | Pendiente |
+| 4 | [Nombre] | [Qué se logra al terminar] | [N semanas] | Pendiente |
+
+---
+
+## Fase 1: [Nombre de la Fase]
+
+**Objetivo**: [Descripción clara de qué capacidad nueva tiene el sistema al final de esta fase]
+**Duración estimada**: [N semanas]
+**Estado**: Pendiente | En progreso | Completado
+**Fecha inicio**: YYYY-MM-DD
+**Fecha fin estimada**: YYYY-MM-DD
+**Fecha fin real**: —
+
+### Entregables
+
+| # | Entregable | Descripción | Requisitos cubiertos | Estado |
+|---|------------|-------------|---------------------|--------|
+| 1.1 | [Nombre técnico del entregable] | [Qué se construye] | REQ-001, REQ-002 | Pendiente |
+| 1.2 | | | | Pendiente |
+| 1.3 | | | | Pendiente |
+| 1.4 | | | | Pendiente |
+
+### Criterios de verificación de la fase
+
+Al completar la Fase 1, TODOS estos criterios deben ser verdaderos:
+- [ ] [Criterio de funcionalidad verificable]
+- [ ] [Criterio de calidad — tests pasan, cobertura >= 80%]
+- [ ] [Criterio de performance — tiempos de respuesta dentro del objetivo]
+- [ ] [Criterio de documentación — README, ADRs actualizados]
+
+### Dependencias y riesgos
+
+- **Dependencia**: [Qué debe estar listo antes de empezar esta fase]
+- **Riesgo**: [Qué puede retrasarla] — Mitigación: [cómo se mitiga]
+
+---
+
+## Fase 2: [Nombre de la Fase]
+
+**Objetivo**:
+**Duración estimada**:
+**Estado**: Pendiente
+**Fecha inicio**: YYYY-MM-DD
+**Fecha fin estimada**: YYYY-MM-DD
+**Fecha fin real**: —
+
+### Entregables
+
+| # | Entregable | Descripción | Requisitos cubiertos | Estado |
+|---|------------|-------------|---------------------|--------|
+| 2.1 | | | | Pendiente |
+| 2.2 | | | | Pendiente |
+| 2.3 | | | | Pendiente |
+
+### Criterios de verificación de la fase
+
+- [ ]
+- [ ]
+- [ ]
+
+### Dependencias y riesgos
+
+- **Dependencia**:
+- **Riesgo**: — Mitigación:
+
+---
+
+## Fase 3: [Nombre de la Fase]
+
+**Objetivo**:
+**Duración estimada**:
+**Estado**: Pendiente
+**Fecha inicio**: YYYY-MM-DD (estimada)
+**Fecha fin estimada**: YYYY-MM-DD
+
+### Entregables
+
+| # | Entregable | Descripción | Requisitos cubiertos | Estado |
+|---|------------|-------------|---------------------|--------|
+| 3.1 | | | | Pendiente |
+| 3.2 | | | | Pendiente |
+| 3.3 | | | | Pendiente |
+
+### Criterios de verificación de la fase
+
+- [ ]
+- [ ]
+
+---
+
+## Fase 4: [Nombre de la Fase — ej. Go-live y estabilización]
+
+**Objetivo**:
+**Duración estimada**:
+**Estado**: Pendiente
+
+### Entregables
+
+| # | Entregable | Descripción | Estado |
+|---|------------|-------------|--------|
+| 4.1 | | | Pendiente |
+| 4.2 | | | Pendiente |
+
+### Criterios de verificación de la fase
+
+- [ ]
+- [ ]
+
+---
+
+## Leyenda de estados
+
+| Estado | Significado |
+|--------|-------------|
+| Pendiente | No iniciado |
+| En progreso | Trabajo activo |
+| Bloqueado | Esperando dependencia externa |
+| En revisión | Implementado, pendiente de verificación |
+| Completado | Verificado y aceptado |
+| Cancelado | Descartado (documentar razón) |
+
+---
+
+## Historial de cambios al roadmap
+
+| Fecha | Cambio | Motivo | Impacto |
+|-------|--------|--------|---------|
+| YYYY-MM-DD | [descripción del cambio al plan] | [por qué cambió] | [qué fases se afectan] |

package/plantillas/PROYECTO.md

@@ -0,0 +1,122 @@
+# PROJECT: [Nombre del Proyecto]
+
+> Documento vivo. Actualizar cuando cambie el alcance, el equipo o las restricciones.
+> Versión: 0.1 | Última actualización: YYYY-MM-DD | Autor: [nombre]
+
+---
+
+## Visión
+
+[Una sola frase que describe el producto terminado y el valor que entrega.
+Debe ser comprensible para alguien externo al proyecto.]
+
+Ejemplo: "Sistema web que permite a las PyMEs emitir facturas electrónicas CFDI 4.0
+de forma autónoma, sin depender de un contador externo para el proceso cotidiano."
+
+---
+
+## Contexto y motivación
+
+[2-4 párrafos describiendo el problema actual. Por qué existe este proyecto.
+Qué está roto, es ineficiente o falta en el estado actual. Quién sufre el problema
+y cómo lo sufre hoy. Datos cuantitativos si están disponibles.]
+
+**Problema actual:**
+
+
+**Impacto del problema:**
+
+
+**Por qué ahora:**
+
+
+---
+
+## Objetivos
+
+Resultados medibles que este proyecto debe alcanzar. Cada objetivo tiene un
+criterio de éxito verificable.
+
+| # | Objetivo | Criterio de éxito | Prioridad |
+|---|----------|-------------------|-----------|
+| O1 | [Qué se quiere lograr] | [Cómo saber que se logró] | Alta |
+| O2 | | | Alta |
+| O3 | | | Media |
+| O4 | | | Baja |
+
+---
+
+## No-objetivos (fuera del alcance)
+
+Explicitar lo que este proyecto NO hace evita scope creep y alinea expectativas.
+
+- **No:** [Funcionalidad que parece relacionada pero está fuera del alcance]
+  *Razón: [por qué está fuera]*
+- **No:** [Integración o caso de uso que se excluye explícitamente]
+  *Razón: [dependencia futura, proyecto separado, etc.]*
+- **No:** [Tipo de usuario o mercado que no se atiende en esta fase]
+  *Razón: [foco, recursos, etc.]*
+
+---
+
+## Restricciones
+
+Límites no negociables que la solución debe respetar.
+
+### Técnicas
+- [Restricción de plataforma, lenguaje o framework mandatorio]
+- [Restricción de integración con sistema existente]
+- [Restricción de performance o disponibilidad]
+
+### De negocio
+- [Restricción regulatoria o de compliance]
+- [Restricción de tiempo — fecha de entrega fija]
+- [Restricción de presupuesto o recursos]
+
+### Asunciones
+[Lo que se asume como verdadero para que el proyecto tenga sentido.
+Si alguna asunción resulta falsa, el proyecto requiere revisión.]
+- Se asume que [condición del contexto].
+- Se asume que [comportamiento del usuario].
+- Se asume que [disponibilidad de recurso externo].
+
+---
+
+## Stack tecnológico
+
+| Capa | Tecnología | Versión | Justificación |
+|------|-----------|---------|---------------|
+| Backend | [ej. FastAPI] | [ej. 0.111] | [por qué] |
+| ORM / BD | [ej. SQLAlchemy + PostgreSQL] | [versión] | [por qué] |
+| Frontend | [ej. Angular] | [versión] | [por qué] |
+| Auth | [ej. JWT + OAuth2] | — | [por qué] |
+| Infraestructura | [ej. Docker + Kubernetes] | — | [por qué] |
+| CI/CD | [ej. GitHub Actions] | — | [por qué] |
+| Observabilidad | [ej. Sentry + Grafana] | — | [por qué] |
+
+Ver investigación detallada en: `research/STACK.md`
+
+---
+
+## Equipo
+
+| Rol | Nombre | Responsabilidad |
+|-----|--------|-----------------|
+| Tech Lead | [nombre] | Decisiones arquitecturales, reviews |
+| Backend Dev | [nombre] | API, base de datos, lógica de negocio |
+| Frontend Dev | [nombre] | UI, componentes, integración de API |
+| QA | [nombre] | Tests de aceptación, regresión |
+| Product Owner | [nombre] | Priorización, criterios de aceptación |
+| Stakeholder | [nombre/área] | Aprobación final, presupuesto |
+
+---
+
+## Links y recursos
+
+- Repositorio: [URL]
+- Tablero de tareas: [URL]
+- Entorno de staging: [URL]
+- Documentación API: [URL]
+- Canal de comunicación: [Slack/Teams channel]
+- ADRs: `docs/adr/`
+- Investigación técnica: `research/`

package/plantillas/REQUISITOS.md

@@ -0,0 +1,132 @@
+# REQUIREMENTS: [Nombre del Proyecto]
+
+> Versión: 0.1 | Última actualización: YYYY-MM-DD
+> Los requisitos con estado "Aprobado" están congelados para la fase actual.
+> Cambios a requisitos aprobados requieren aprobación del Product Owner.
+
+---
+
+## Guía de prioridades
+
+| Nivel | Significado |
+|-------|-------------|
+| P0 | Crítico — sin esto el sistema no funciona. Bloqueante para el lanzamiento. |
+| P1 | Alta — funcionalidad core esperada por el usuario. MVP incompleto sin esto. |
+| P2 | Media — mejora significativa. Puede lanzarse sin esto pero debe estar pronto. |
+| P3 | Baja — nice-to-have. Entra si hay tiempo disponible en la fase. |
+
+## Guía de estados
+
+| Estado | Significado |
+|--------|-------------|
+| Borrador | En discusión, puede cambiar |
+| Aprobado | Congelado para esta fase, listo para implementar |
+| En desarrollo | Siendo implementado actualmente |
+| Completado | Implementado y verificado |
+| Pospuesto | Movido a fase futura |
+| Cancelado | Descartado con justificación documentada |
+
+---
+
+## Requisitos Funcionales
+
+### Módulo: [Nombre del módulo — ej. Autenticación]
+
+| ID | Prioridad | Descripción | Criterios de aceptación | Estado |
+|----|-----------|-------------|------------------------|--------|
+| REQ-001 | P0 | [Descripción concisa de qué debe hacer el sistema] | - [Criterio 1 verificable] / - [Criterio 2 verificable] | Borrador |
+| REQ-002 | P0 | | | Borrador |
+| REQ-003 | P1 | | | Borrador |
+
+### Módulo: [Nombre del segundo módulo — ej. Gestión de Facturas]
+
+| ID | Prioridad | Descripción | Criterios de aceptación | Estado |
+|----|-----------|-------------|------------------------|--------|
+| REQ-010 | P0 | | | Borrador |
+| REQ-011 | P1 | | | Borrador |
+| REQ-012 | P1 | | | Borrador |
+| REQ-013 | P2 | | | Borrador |
+
+### Módulo: [Nombre del tercer módulo]
+
+| ID | Prioridad | Descripción | Criterios de aceptación | Estado |
+|----|-----------|-------------|------------------------|--------|
+| REQ-020 | P1 | | | Borrador |
+| REQ-021 | P2 | | | Borrador |
+| REQ-022 | P3 | | | Borrador |
+
+---
+
+## Requisitos No Funcionales
+
+| ID | Categoría | Descripción | Métrica | Estado |
+|----|-----------|-------------|---------|--------|
+| RNF-001 | Performance | El sistema responde en menos de [N]ms para el P95 | P95 < [N]ms bajo [X] usuarios concurrentes | Borrador |
+| RNF-002 | Disponibilidad | Uptime mínimo en producción | >= 99.5% mensual | Borrador |
+| RNF-003 | Seguridad | Datos en tránsito cifrados | TLS 1.2+ en todos los endpoints | Borrador |
+| RNF-004 | Seguridad | Autenticación obligatoria en toda operación de escritura | 100% endpoints POST/PUT/DELETE con auth | Borrador |
+| RNF-005 | Escalabilidad | El sistema soporta [N] usuarios concurrentes | Sin degradación hasta [N] usuarios | Borrador |
+| RNF-006 | Mantenibilidad | Cobertura de tests | >= 80% en módulos de lógica de negocio | Borrador |
+| RNF-007 | Accesibilidad | Interfaz web accesible | WCAG 2.1 nivel AA | Borrador |
+
+---
+
+## Restricciones de implementación
+
+| ID | Descripción | Impacto |
+|----|-------------|---------|
+| RES-001 | [Restricción técnica mandatoria — ej. debe integrarse con SAP existente] | [Cómo afecta el diseño] |
+| RES-002 | [Restricción regulatoria — ej. datos deben residir en México] | [Cómo afecta la infraestructura] |
+| RES-003 | [Restricción de tiempo — ej. lanzamiento fijado para fecha X] | [Qué se prioriza] |
+
+---
+
+## Casos de uso principales (flujos happy path)
+
+### [CU-001] [Nombre del caso de uso]
+
+**Actor**: [Tipo de usuario]
+**Precondición**: [Estado del sistema antes de empezar]
+
+1. El usuario [acción 1]
+2. El sistema [respuesta 1]
+3. El usuario [acción 2]
+4. El sistema [respuesta 2]
+5. [...]
+
+**Postcondición**: [Estado del sistema al finalizar]
+**Flujos alternativos**:
+- Si [condición]: [qué pasa]
+
+---
+
+### [CU-002] [Nombre del caso de uso]
+
+**Actor**:
+**Precondición**:
+
+1.
+2.
+3.
+
+**Postcondición**:
+
+---
+
+## Preguntas abiertas
+
+Decisiones de requisitos que aún no están resueltas. Cada una bloquea
+uno o más requisitos hasta que se responda.
+
+| # | Pregunta | Quién decide | Fecha límite | Estado |
+|---|----------|-------------|--------------|--------|
+| Q1 | [Pregunta específica sobre el comportamiento esperado] | [Nombre/Rol] | YYYY-MM-DD | Abierta |
+| Q2 | | | | Abierta |
+
+---
+
+## Historial de cambios a requisitos
+
+| Fecha | ID Req | Cambio | Motivo | Aprobado por |
+|-------|--------|--------|--------|-------------|
+| YYYY-MM-DD | REQ-NNN | [descripción del cambio] | [por qué] | [nombre] |

package/plantillas/auditor-veto-template.md

@@ -0,0 +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.

package/plantillas/github-workflows/README.md

@@ -0,0 +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")`.

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

@@ -0,0 +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

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

@@ -0,0 +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 ./...