@saulwade/swl-ses 2.6.0 → 2.8.0

package/habilidades/changelog-generator/SKILL.md

@@ -1,174 +1,174 @@
----
-name: changelog-generator
-description: >
-  Generador automático de entradas CHANGELOG.md en formato Keep a Changelog
-  desde commits Conventional Commits. Parser determinista que clasifica feat/
-  fix/perf/refactor/docs/etc. en categorías user-facing en español, detecta
-  breaking changes (marca '!' o trailer 'BREAKING CHANGE:') y reporta nivel
-  de conformidad para decidir fallback manual. Cargar en /swl:release Paso 7
-  cuando hay commits Conventional, o manualmente para previsualizar el
-  changelog antes de un release.
-version: 1.1.1
-nivelRiesgo: BAJO
-herramientasPermitidas: [Read, Bash]
-skillsInvocables: [release-semver]
-exclusiones:
-  - "No invocar para generar release notes con marketing copy o anuncios para usuarios finales — este skill produce listado técnico-legible, no narrativa."
-  - "No invocar si el repo no usa Conventional Commits — el parser detecta <80% conformidad y el caller debe abortar a flujo manual de release-semver."
-  - "No invocar para reescribir CHANGELOG histórico — solo agrega entrada de la próxima versión al inicio."
----
-
-# /habilidades/changelog-generator — CHANGELOG automático desde Conventional Commits
-
-## Cuándo cargar
-
-- Durante `/swl:release` Paso 7 (Generar CHANGELOG), cuando el flujo automático
-  está disponible y los commits del rango siguen Conventional Commits.
-- Para previsualizar el changelog candidato antes de bumpear versión:
-  `node habilidades/changelog-generator/scripts/parse-commits.js --version X`
-- Cuando un colaborador pide un resumen legible de cambios entre dos refs
-  arbitrarias del repo.
-
-## Cuándo NO cargar
-
-- Repo sin Conventional Commits (<80% de conformidad): el parser detecta y
-  reporta; el caller debe usar `Skill("release-semver")` flujo manual.
-- Generación de **release notes** (texto narrativo con contexto de producto):
-  este skill produce CHANGELOG técnico-legible; las release notes con marketing
-  son tarea aparte (`documentador-swl` con plantilla específica).
-- Reescritura histórica del CHANGELOG (squash de varias versiones, corrección
-  de entradas antiguas): solo se agrega entrada de la versión nueva al inicio.
-
-## Qué hace el skill
-
-1. **Lee commits** desde la última tag (o entre dos refs arbitrarias) con
-   `git log --format=...` usando un separador único para parsear subject + body
-   sin colisiones.
-2. **Parsea con Conventional Commits 1.0.0**: regex que captura tipo, scope,
-   marca `!`, descripción. Soporta tipos extendidos del proyecto SWL:
-   `evolucion` (cambios de skills/agentes), además de `feat/fix/perf/refactor/
-   docs/style/test/ci/build/chore/revert`. Tolera el prefijo opcional de
-   trazabilidad `[T-NN]` / `[REQ-NN]` de la convención de `ejecutar-fase`
-   (no altera la semántica CC — el tipo+scope+descripción siguen presentes).
-3. **Detecta breaking changes** por marca `!` después del tipo o trailer
-   `BREAKING CHANGE:` en el body. Los breaking siempre van al inicio del
-   release, sin importar el tipo original.
-4. **Transforma descripción técnica → legible**:
-   - Elimina referencias a issues al final (`(#123)`, `Refs #456`).
-   - Capitaliza primera letra.
-   - Elimina punto final (Keep a Changelog usa bullets sin punto).
-5. **Agrupa en categorías** con orden canónico:
-   1. Breaking changes
-   2. Nuevas funcionalidades (feat)
-   3. Correcciones (fix)
-   4. Mejoras de rendimiento (perf)
-   5. Cambios internos (refactor)
-   6. Reversiones (revert)
-   7. Evoluciones de skills/agentes (evolucion — SWL-specific)
-   8. Mantenimiento (docs/style/test/ci/build/chore — colapsadas)
-   9. Otros (commits sin prefijo CC válido)
-6. **Reporta conformidad**: ratio commits conformes / total. Si <80%, el
-   caller debe decidir si abortar o seguir manualmente.
-
-## Helper programático
-
-```js
-const {
-  parsearCommits,
-  leerCommitsGit,
-  generarChangelog,
-} = require('./habilidades/changelog-generator/scripts/parse-commits');
-
-// 1. Leer commits desde la última tag hasta HEAD
-const commits = leerCommitsGit({ to: 'HEAD' });
-
-// 2. Parsear y clasificar
-const { categorias, conformidad, totalCommits, conformes } = parsearCommits(commits);
-
-// 3. Si conformidad < 0.8, abortar o avisar al usuario
-if (conformidad < 0.8) {
-  console.warn(`Conformidad CC: ${conformes}/${totalCommits}. Revisar "Otros".`);
-}
-
-// 4. Generar markdown listo para insertar en CHANGELOG.md
-const md = generarChangelog(categorias, {
-  version: '1.6.5',
-  fecha: '2026-05-22',  // opcional, default = hoy
-  incluirHash: true,    // muestra hash corto al inicio de cada bullet
-});
-```
-
-## Uso CLI
-
-Previsualizar changelog candidato sin escribir nada:
-
-```bash
-node habilidades/changelog-generator/scripts/parse-commits.js \
-  --version 1.6.5 \
-  --format markdown
-```
-
-Filtrar por rango específico:
-
-```bash
-node habilidades/changelog-generator/scripts/parse-commits.js \
-  --from v1.6.4 \
-  --to HEAD \
-  --version 1.6.5
-```
-
-Salida JSON estructurado para post-procesamiento:
-
-```bash
-node habilidades/changelog-generator/scripts/parse-commits.js \
-  --from v1.6.4 \
-  --format json > /tmp/changelog-candidato.json
-```
-
-## Reglas de uso desde /swl:release
-
-1. Llamar a `leerCommitsGit` con la última tag detectada en el Paso 1 del
-   release.
-2. Verificar `conformidad >= 0.8`. Si menor, presentar al usuario los commits
-   bajo "Otros" y pedir decisión: (a) continuar con el changelog, (b) abortar
-   y reescribir commits, (c) editar manualmente la categoría "Otros".
-3. Si `--dry-run` está activo en `/swl:release`, mostrar el output de
-   `generarChangelog` sin escribir a disco.
-4. Si conformidad OK: leer CHANGELOG.md actual, insertar el bloque generado
-   al inicio después del header `# Changelog`, escribir atómicamente.
-5. NO hacer commit aquí — eso lo hace el Paso 8 de `/swl:release`.
-
-## Gotchas observables
-
-- **Conventional Commits sin scope son válidos**: `fix: corregir X` parsea
-  igual que `fix(modulo): corregir X`. El parser no exige scope.
-- **El subject debe ir en una sola línea**: si un commit usa newline en el
-  subject, el parser lo trata como completo pero `git log %s` ya lo trunca.
-- **Tipos no estándar van a "Otros"**: si un equipo usa `mejora:`, `cambio:`,
-  el parser los marca como no conformes. El usuario debe ajustar la lista
-  `CATEGORIAS` en `parse-commits.js` o adoptar tipos estándar.
-- **El skill NO escribe a disco directamente**: solo retorna markdown. El
-  caller (`/swl:release` Paso 7) es responsable de leer el CHANGELOG actual,
-  insertar al inicio y escribir atómicamente.
-- **Commits revert vienen del propio git**: `git revert` genera mensajes
-  `Revert "Subject original"` que el parser categoriza correctamente bajo
-  Reversiones (regex matchea `revert:` sin que el usuario lo escriba si usa
-  `git revert -e` para editar el mensaje al formato CC).
-- **El hash corto se trunca a 7 chars**: alineado con el formato `git log
-  --oneline` estándar.
-
-## Origen
-
-Adaptado del skill `changelog-generator` de
-`temp/awesome-codex-skills-master/changelog-generator/` (ComposioHQ, MIT) con:
-
-- Frontmatter al estándar SWL (es-MX, `nivelRiesgo: BAJO`, `exclusiones`).
-- Parser determinista en Node.js (`parse-commits.js`) — el origen es solo
-  documentación; este skill agrega la implementación ejecutable.
-- Tipo `evolucion:` específico de SWL agregado al parser.
-- Soporte para breaking changes `!` y trailer `BREAKING CHANGE:` (origen
-  solo menciona el segundo).
-- Reporte de conformidad <80% como gate explícita para fallback manual.
-- Integración con `/swl:release` Paso 7 documentada en `comandos/swl/release.md`.
-
-Documentado en ADR-0029 (integración parcial awesome-codex-skills, Opción B).
+---
+name: changelog-generator
+description: >
+  Generador automático de entradas CHANGELOG.md en formato Keep a Changelog
+  desde commits Conventional Commits. Parser determinista que clasifica feat/
+  fix/perf/refactor/docs/etc. en categorías user-facing en español, detecta
+  breaking changes (marca '!' o trailer 'BREAKING CHANGE:') y reporta nivel
+  de conformidad para decidir fallback manual. Cargar en /swl:release Paso 7
+  cuando hay commits Conventional, o manualmente para previsualizar el
+  changelog antes de un release.
+version: 1.1.1
+nivelRiesgo: BAJO
+herramientasPermitidas: [Read, Bash]
+skillsInvocables: [release-semver]
+exclusiones:
+  - "No invocar para generar release notes con marketing copy o anuncios para usuarios finales — este skill produce listado técnico-legible, no narrativa."
+  - "No invocar si el repo no usa Conventional Commits — el parser detecta <80% conformidad y el caller debe abortar a flujo manual de release-semver."
+  - "No invocar para reescribir CHANGELOG histórico — solo agrega entrada de la próxima versión al inicio."
+---
+
+# /habilidades/changelog-generator — CHANGELOG automático desde Conventional Commits
+
+## Cuándo cargar
+
+- Durante `/swl:release` Paso 7 (Generar CHANGELOG), cuando el flujo automático
+  está disponible y los commits del rango siguen Conventional Commits.
+- Para previsualizar el changelog candidato antes de bumpear versión:
+  `node habilidades/changelog-generator/scripts/parse-commits.js --version X`
+- Cuando un colaborador pide un resumen legible de cambios entre dos refs
+  arbitrarias del repo.
+
+## Cuándo NO cargar
+
+- Repo sin Conventional Commits (<80% de conformidad): el parser detecta y
+  reporta; el caller debe usar `Skill("release-semver")` flujo manual.
+- Generación de **release notes** (texto narrativo con contexto de producto):
+  este skill produce CHANGELOG técnico-legible; las release notes con marketing
+  son tarea aparte (`documentador-swl` con plantilla específica).
+- Reescritura histórica del CHANGELOG (squash de varias versiones, corrección
+  de entradas antiguas): solo se agrega entrada de la versión nueva al inicio.
+
+## Qué hace el skill
+
+1. **Lee commits** desde la última tag (o entre dos refs arbitrarias) con
+   `git log --format=...` usando un separador único para parsear subject + body
+   sin colisiones.
+2. **Parsea con Conventional Commits 1.0.0**: regex que captura tipo, scope,
+   marca `!`, descripción. Soporta tipos extendidos del proyecto SWL:
+   `evolucion` (cambios de skills/agentes), además de `feat/fix/perf/refactor/
+   docs/style/test/ci/build/chore/revert`. Tolera el prefijo opcional de
+   trazabilidad `[T-NN]` / `[REQ-NN]` de la convención de `ejecutar-fase`
+   (no altera la semántica CC — el tipo+scope+descripción siguen presentes).
+3. **Detecta breaking changes** por marca `!` después del tipo o trailer
+   `BREAKING CHANGE:` en el body. Los breaking siempre van al inicio del
+   release, sin importar el tipo original.
+4. **Transforma descripción técnica → legible**:
+   - Elimina referencias a issues al final (`(#123)`, `Refs #456`).
+   - Capitaliza primera letra.
+   - Elimina punto final (Keep a Changelog usa bullets sin punto).
+5. **Agrupa en categorías** con orden canónico:
+   1. Breaking changes
+   2. Nuevas funcionalidades (feat)
+   3. Correcciones (fix)
+   4. Mejoras de rendimiento (perf)
+   5. Cambios internos (refactor)
+   6. Reversiones (revert)
+   7. Evoluciones de skills/agentes (evolucion — SWL-specific)
+   8. Mantenimiento (docs/style/test/ci/build/chore — colapsadas)
+   9. Otros (commits sin prefijo CC válido)
+6. **Reporta conformidad**: ratio commits conformes / total. Si <80%, el
+   caller debe decidir si abortar o seguir manualmente.
+
+## Helper programático
+
+```js
+const {
+  parsearCommits,
+  leerCommitsGit,
+  generarChangelog,
+} = require('./habilidades/changelog-generator/scripts/parse-commits');
+
+// 1. Leer commits desde la última tag hasta HEAD
+const commits = leerCommitsGit({ to: 'HEAD' });
+
+// 2. Parsear y clasificar
+const { categorias, conformidad, totalCommits, conformes } = parsearCommits(commits);
+
+// 3. Si conformidad < 0.8, abortar o avisar al usuario
+if (conformidad < 0.8) {
+  console.warn(`Conformidad CC: ${conformes}/${totalCommits}. Revisar "Otros".`);
+}
+
+// 4. Generar markdown listo para insertar en CHANGELOG.md
+const md = generarChangelog(categorias, {
+  version: '1.6.5',
+  fecha: '2026-05-22',  // opcional, default = hoy
+  incluirHash: true,    // muestra hash corto al inicio de cada bullet
+});
+```
+
+## Uso CLI
+
+Previsualizar changelog candidato sin escribir nada:
+
+```bash
+node habilidades/changelog-generator/scripts/parse-commits.js \
+  --version 1.6.5 \
+  --format markdown
+```
+
+Filtrar por rango específico:
+
+```bash
+node habilidades/changelog-generator/scripts/parse-commits.js \
+  --from v1.6.4 \
+  --to HEAD \
+  --version 1.6.5
+```
+
+Salida JSON estructurado para post-procesamiento:
+
+```bash
+node habilidades/changelog-generator/scripts/parse-commits.js \
+  --from v1.6.4 \
+  --format json > /tmp/changelog-candidato.json
+```
+
+## Reglas de uso desde /swl:release
+
+1. Llamar a `leerCommitsGit` con la última tag detectada en el Paso 1 del
+   release.
+2. Verificar `conformidad >= 0.8`. Si menor, presentar al usuario los commits
+   bajo "Otros" y pedir decisión: (a) continuar con el changelog, (b) abortar
+   y reescribir commits, (c) editar manualmente la categoría "Otros".
+3. Si `--dry-run` está activo en `/swl:release`, mostrar el output de
+   `generarChangelog` sin escribir a disco.
+4. Si conformidad OK: leer CHANGELOG.md actual, insertar el bloque generado
+   al inicio después del header `# Changelog`, escribir atómicamente.
+5. NO hacer commit aquí — eso lo hace el Paso 8 de `/swl:release`.
+
+## Gotchas observables
+
+- **Conventional Commits sin scope son válidos**: `fix: corregir X` parsea
+  igual que `fix(modulo): corregir X`. El parser no exige scope.
+- **El subject debe ir en una sola línea**: si un commit usa newline en el
+  subject, el parser lo trata como completo pero `git log %s` ya lo trunca.
+- **Tipos no estándar van a "Otros"**: si un equipo usa `mejora:`, `cambio:`,
+  el parser los marca como no conformes. El usuario debe ajustar la lista
+  `CATEGORIAS` en `parse-commits.js` o adoptar tipos estándar.
+- **El skill NO escribe a disco directamente**: solo retorna markdown. El
+  caller (`/swl:release` Paso 7) es responsable de leer el CHANGELOG actual,
+  insertar al inicio y escribir atómicamente.
+- **Commits revert vienen del propio git**: `git revert` genera mensajes
+  `Revert "Subject original"` que el parser categoriza correctamente bajo
+  Reversiones (regex matchea `revert:` sin que el usuario lo escriba si usa
+  `git revert -e` para editar el mensaje al formato CC).
+- **El hash corto se trunca a 7 chars**: alineado con el formato `git log
+  --oneline` estándar.
+
+## Origen
+
+Adaptado del skill `changelog-generator` de
+`temp/awesome-codex-skills-master/changelog-generator/` (ComposioHQ, MIT) con:
+
+- Frontmatter al estándar SWL (es-MX, `nivelRiesgo: BAJO`, `exclusiones`).
+- Parser determinista en Node.js (`parse-commits.js`) — el origen es solo
+  documentación; este skill agrega la implementación ejecutable.
+- Tipo `evolucion:` específico de SWL agregado al parser.
+- Soporte para breaking changes `!` y trailer `BREAKING CHANGE:` (origen
+  solo menciona el segundo).
+- Reporte de conformidad <80% como gate explícita para fallback manual.
+- Integración con `/swl:release` Paso 7 documentada en `comandos/swl/release.md`.
+
+Documentado en ADR-0029 (integración parcial awesome-codex-skills, Opción B).

package/habilidades/checklist-seguridad/recursos/stride-cobertura.md

@@ -1,60 +1,60 @@
-# STRIDE — modelo de amenazas para el modo cobertura
-
-Complemento del checklist OWASP de `SKILL.md`. STRIDE clasifica por **tipo de
-amenaza** (qué quiere lograr el atacante); OWASP por **tipo de debilidad**
-(qué error del código lo permite). Auditar con ambas taxonomías cierra los
-huecos que cada una deja sola: repudio y DoS casi no aparecen en OWASP Top 10;
-componentes desactualizados (A06) no mapean limpio a STRIDE.
-
-## Las 6 categorías
-
-| Letra | Amenaza | Qué buscar | OWASP relacionadas |
-|-------|---------|-----------|--------------------|
-| **S**poofing | Suplantación de identidad | Auth débil, tokens predecibles, session fixation, falta de MFA | A07 |
-| **T**ampering | Modificación de datos | Input sin validar, falta de checks de integridad, inyección SQL/NoSQL, deserialización insegura | A03, A08 |
-| **R**epudiation | Acciones negables | Audit logs faltantes, transacciones sin firma, logs mutables, cambios de privilegio sin registro | A09 |
-| **I**nformation Disclosure | Fuga de información | Stack traces al cliente, logging verboso con PII, env vars expuestas, mensajes de error que revelan existencia de recursos | A01, A02, A05 |
-| **D**enial of Service | Ataques a disponibilidad | Queries sin cota ni paginación, rate limits faltantes, regex DoS (ReDoS), uploads sin límite de tamaño | A04 |
-| **E**levation of Privilege | Acceso no autorizado | Checks de authz faltantes, IDOR, rutas de escalación admin, confusión autenticación/autorización | A01, A04 |
-
-## Protocolo de auditoría iterativa con cobertura
-
-1. **Reconocimiento (una vez)**: mapear superficie de ataque — manifest de
-   dependencias, `.env.example`, Dockerfile, rutas de API, módulos de auth,
-   schemas de BD, configuración de CI/CD. Producir threat model inicial:
-   qué activos, qué trust boundaries, qué entry points.
-2. **Por iteración**: elegir el vector MENOS cubierto (OWASP sin auditar →
-   STRIDE sin auditar → profundizar en hallazgos existentes). Adoptar la
-   persona red-team que corresponde al vector (rotación: Adversario de
-   Seguridad → Supply Chain → Insider → Infraestructura — definiciones en
-   `habilidades/proceso-debate-adversarial/recursos/personas.md`).
-3. **Validar cada hallazgo**: evidencia archivo:línea + escenario de ataque
-   concreto + reproducción. Sin escenario de ataque no es hallazgo, es
-   especulación (regla `verificar-citas-normativas.md § Familia 2`).
-4. **Registrar**: fila en la corrida de `loop-telemetry` (columnas sugeridas:
-   `iteracion, timestamp, hallazgo, severidad, owasp, stride, archivo_linea`)
-   y recalcular el score compuesto.
-5. **Salida**: OWASP 10/10 + STRIDE 6/6 cubiertos, o max iteraciones (default
-   15), o plateau de hallazgos (3 iteraciones sin hallazgo nuevo).
-
-## Formato de hallazgo (obligatorio, 7 campos)
-
-```markdown
-### [Título de una línea]
-- **Severidad**: Crítico | Alto | Medio | Bajo | Informativo
-- **OWASP**: A01-A10
-- **STRIDE**: S | T | R | I | D | E
-- **Evidencia**: archivo:línea + escenario de ataque (sin especulación teórica)
-- **Reproducción**: pasos para disparar el problema
-- **Remediación**: fix concreto para ESTE código
-```
-
-## Severidad — criterios
-
-| Severidad | Criterio | Ejemplos |
-|-----------|----------|----------|
-| Crítico | Explotable remoto, sin auth, brecha de datos | RCE, SQL injection, bypass de auth |
-| Alto | Requiere algún acceso, impacto severo | XSS almacenado, IDOR, escalación de privilegios |
-| Medio | Impacto limitado o requiere interacción | CSRF, XSS reflejado, divulgación de info |
-| Bajo | Impacto mínimo | Headers faltantes, errores verbosos |
-| Informativo | Recomendación de hardening | Defensa en profundidad |
+# STRIDE — modelo de amenazas para el modo cobertura
+
+Complemento del checklist OWASP de `SKILL.md`. STRIDE clasifica por **tipo de
+amenaza** (qué quiere lograr el atacante); OWASP por **tipo de debilidad**
+(qué error del código lo permite). Auditar con ambas taxonomías cierra los
+huecos que cada una deja sola: repudio y DoS casi no aparecen en OWASP Top 10;
+componentes desactualizados (A06) no mapean limpio a STRIDE.
+
+## Las 6 categorías
+
+| Letra | Amenaza | Qué buscar | OWASP relacionadas |
+|-------|---------|-----------|--------------------|
+| **S**poofing | Suplantación de identidad | Auth débil, tokens predecibles, session fixation, falta de MFA | A07 |
+| **T**ampering | Modificación de datos | Input sin validar, falta de checks de integridad, inyección SQL/NoSQL, deserialización insegura | A03, A08 |
+| **R**epudiation | Acciones negables | Audit logs faltantes, transacciones sin firma, logs mutables, cambios de privilegio sin registro | A09 |
+| **I**nformation Disclosure | Fuga de información | Stack traces al cliente, logging verboso con PII, env vars expuestas, mensajes de error que revelan existencia de recursos | A01, A02, A05 |
+| **D**enial of Service | Ataques a disponibilidad | Queries sin cota ni paginación, rate limits faltantes, regex DoS (ReDoS), uploads sin límite de tamaño | A04 |
+| **E**levation of Privilege | Acceso no autorizado | Checks de authz faltantes, IDOR, rutas de escalación admin, confusión autenticación/autorización | A01, A04 |
+
+## Protocolo de auditoría iterativa con cobertura
+
+1. **Reconocimiento (una vez)**: mapear superficie de ataque — manifest de
+   dependencias, `.env.example`, Dockerfile, rutas de API, módulos de auth,
+   schemas de BD, configuración de CI/CD. Producir threat model inicial:
+   qué activos, qué trust boundaries, qué entry points.
+2. **Por iteración**: elegir el vector MENOS cubierto (OWASP sin auditar →
+   STRIDE sin auditar → profundizar en hallazgos existentes). Adoptar la
+   persona red-team que corresponde al vector (rotación: Adversario de
+   Seguridad → Supply Chain → Insider → Infraestructura — definiciones en
+   `habilidades/proceso-debate-adversarial/recursos/personas.md`).
+3. **Validar cada hallazgo**: evidencia archivo:línea + escenario de ataque
+   concreto + reproducción. Sin escenario de ataque no es hallazgo, es
+   especulación (regla `verificar-citas-normativas.md § Familia 2`).
+4. **Registrar**: fila en la corrida de `loop-telemetry` (columnas sugeridas:
+   `iteracion, timestamp, hallazgo, severidad, owasp, stride, archivo_linea`)
+   y recalcular el score compuesto.
+5. **Salida**: OWASP 10/10 + STRIDE 6/6 cubiertos, o max iteraciones (default
+   15), o plateau de hallazgos (3 iteraciones sin hallazgo nuevo).
+
+## Formato de hallazgo (obligatorio, 7 campos)
+
+```markdown
+### [Título de una línea]
+- **Severidad**: Crítico | Alto | Medio | Bajo | Informativo
+- **OWASP**: A01-A10
+- **STRIDE**: S | T | R | I | D | E
+- **Evidencia**: archivo:línea + escenario de ataque (sin especulación teórica)
+- **Reproducción**: pasos para disparar el problema
+- **Remediación**: fix concreto para ESTE código
+```
+
+## Severidad — criterios
+
+| Severidad | Criterio | Ejemplos |
+|-----------|----------|----------|
+| Crítico | Explotable remoto, sin auth, brecha de datos | RCE, SQL injection, bypass de auth |
+| Alto | Requiere algún acceso, impacto severo | XSS almacenado, IDOR, escalación de privilegios |
+| Medio | Impacto limitado o requiere interacción | CSRF, XSS reflejado, divulgación de info |
+| Bajo | Impacto mínimo | Headers faltantes, errores verbosos |
+| Informativo | Recomendación de hardening | Defensa en profundidad |

package/habilidades/ci-cd-pipelines/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: ci-cd-pipelines
 description: CI/CD con GitHub Actions y GitLab CI. Stages de lint, test, build, deploy. Caching, artifacts, matrix builds, secrets management, deployment strategies, monorepos y quality gates.
-version: "1.0.0"
+version: "1.0.2"
 herramientasPermitidas: [Read, Bash]
 exclusiones:
   - "No cargar para Kubernetes Deployments o Helm releases — para Kubernetes cargar `kubernetes-orquestacion`."
@@ -155,3 +155,7 @@ Para template de GitHub Actions reutilizable, ver [recursos/github-actions-templ
 **Secrets definidos en GitHub Actions no están disponibles en workflows de forks en PRs externas**: los workflows disparados por un PR de un fork (contribuidor externo) no tienen acceso a los secrets del repositorio por seguridad. Causa: prevención de exfiltración de secrets a forks maliciosos. Fix: usar el evento `pull_request_target` con cuidado para acceder a secrets en PRs de forks, pero solo para jobs que no ejecutan código del PR — los jobs de lint/test pueden correr sin secrets; los de deploy sí necesitan el evento `push` al branch base.
 
 **`docker/build-push-action` con `cache-from: type=gha` puede hacer el build más lento si el cache es muy grande**: el cache de GitHub Actions (10GB límite) se llena con layers de Docker — si se usan imágenes base grandes y muchos stages, el cache puede alcanzar el límite y las layers más antiguas se evictan, causando rebuilds completos. Causa: el cache de GHA tiene límite de 10GB por repositorio. Fix: usar `cache-from: type=registry,ref=ghcr.io/org/app:cache` con un registro de contenedores para cache ilimitado, o usar `mode=min` en el cache para solo guardar las layers finales en lugar de todas las intermedias.
+
+**Un script que monitorea `gh pr checks`/`gh run list` canalizando su `--json` a `jq` externo puede fallar en silencio para siempre si `jq` no está instalado** [CONFIRMADO x2 — SIGM 2026-06-21 y 2026-07-18]: en Windows con Git Bash, `jq` frecuentemente NO está en el PATH (`which jq` → not found). Un loop de polling tipo `s=$(gh pr checks N --json ... 2>/dev/null); cur=$(echo "$s" | jq -r '...' 2>/dev/null)` con stderr suprimido en ambos comandos nunca produce error visible: `cur` queda siempre vacío, la condición de salida (`jq -e '...'`) siempre falla, y el loop de polling corre indefinidamente sin emitir NINGÚN evento — 0 bytes de output, indistinguible de "todavía no hay novedades". Causa: dos supresiones de error (`2>/dev/null`) apiladas ocultan que el binario no existe. Fix confirmado: usar el flag `--jq` PROPIO de `gh` (`gh pr checks N --json name,bucket --jq '.[] | select(...)'`) — es JSON processor vendored dentro del propio binario `gh`, no depende de `jq` externo, y acepta la misma sintaxis de filtro. Antes de confiar en que un monitor de CI sigue "esperando sin novedad", verificar con `TaskOutput(block:false)` que el output acumulado no sea 0 KB tras varios minutos — 0 KB sostenido es señal de este bug, no de que aún no hay nada que reportar.
+
+**Suprimir un fingerprint específico de `gitleaks` en `.gitleaks.toml` bajo `[allowlist] fingerprints = [...]` no funciona en gitleaks ≥8.25** [CONFIRMADO, SIGM 2026-07-19]: desde esa versión gitleaks migró de `[allowlist]` (tabla singular) a `[[allowlists]]` (array de tablas), y el campo `fingerprints` NO existe en NINGUNA de las dos variantes del TOML — solo soporta `paths`/`regexes`/`commits`/`stopwords`/`condition`/`regexTarget`. Un `fingerprints = [...]` agregado al TOML se ignora en silencio (sin error de parseo, sin warning) y el hallazgo sigue reportándose sin cambio. Fix real: los fingerprints se suprimen en un archivo SEPARADO `.gitleaksignore` en la raíz del repo (una línea por fingerprint, texto EXACTO tal como lo imprime `gitleaks detect` en su campo `Fingerprint:`). Verificar el fix localmente ANTES de reintentar en CI: descargar el mismo binario/tag que usa el workflow (`curl -sSL -o gitleaks.zip https://github.com/gitleaks/gitleaks/releases/download/v<TAG>/gitleaks_<TAG>_windows_x64.zip` en Windows, o el tarball `linux_x64` si se prueba en WSL/Linux) y correr `gitleaks detect --source . --no-git --redact -v --config .gitleaks.toml` — el finding suprimido debe desaparecer del output antes de pushear, ahorrando una ronda completa de CI.

package/habilidades/compactacion-contexto/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: compactacion-contexto
 description: Anti-context-rot. Detectar cuándo compactar el contexto, guardar estado antes de compactar, técnicas de resumen progresivo y handoff limpio entre contextos. Recalibrado para el tokenizer de Opus 4.8 (+15-30% tokens vs 4.6).
-version: "1.1.0"
+version: "1.1.1"
 herramientasPermitidas: [Read]
 exclusiones:
   - "No cargar si el contexto está por debajo del 50% y no hay señales cualitativas de degradación — compactar sin necesidad solo interrumpe el flujo."
@@ -235,6 +235,7 @@ instrucción más conservadora o compactar por secciones individuales.
 - **Invariante de headings violada silenciosamente**: el contexto compactado pierde dos secciones `##` del original porque el modelo resumió párrafos en lugar de preservar la estructura. Causa: no se ejecutó la validación post-compactación. Solución: antes de descartar el contexto original, contar `#` en ambos con regex y comparar — tolerancia 0% para headings perdidos.
 - **Compactar todo el codebase al inicio de sesión**: el agente lee 20 archivos en el nuevo contexto "para orientarse" y los compacta de inmediato. Causa: se interpretó "cargar contexto fresco" como cargar y compactar todo. Solución: en el contexto entrante, cargar ESTADO.md + DECISIONS.md + 3 últimos commits, y solo los archivos de la tarea inmediata — no más.
 - **Umbral de 70% sin recalibrar para Opus 4.8**: en proyectos que migraron de Opus 4.6 a 4.7, el umbral de compactación sigue configurado al 70% del contexto cuando debe ser 50%. Causa: el tokenizer de 4.7 produce 1.0-1.35× más tokens y el umbral efectivo llega antes. Solución: al actualizar modelo, ajustar el umbral de compactación a 50% como documenta este skill en su sección de señales cuantitativas.
+- **Análisis forense de un transcript JSONL gigante = digest determinista + lectores paralelos, nunca `Read` directo** [VALIDADO 2026-07-11, sesión de 61.6 MB / 24,862 líneas cubierta al 100%]: para analizar la sesión de otro agente (post-mortem, auditoría, extracción de decisiones), (1) script Node línea-por-línea que emite SOLO el contenido conversacional — mensajes de usuario íntegros, texto del asistente, tool calls como `>> Tool: args` de una línea, tool_results truncados a 200-400 chars (1,200 si `is_error`), resúmenes de compactación completos — en chunks de ~350 KB; (2) un agente por chunk con mandato de leer el 100% (Read con offset/limit hasta cubrir) y reporte estructurado fijo (cronología, intervenciones del usuario con cita+línea, bugs con estado, deudas, hallazgos QA/adversarial, pendientes, problemas de proceso); (3) el driver verifica las citas críticas de cada reporte antes de usarlas. Gotcha descubierto: **los mensajes del usuario que solo sobreviven dentro de un resumen de compactación NO son diálogo crudo** — el digest debe marcarlos como "cobertura parcial" y el análisis debe declararlo en vez de citarlos como verbatim; en la sesión analizada, 3 de 6 instrucciones del usuario del tramo final solo existían en resúmenes de compactación.
 
 ## Anti-patrones a evitar
 

package/habilidades/contenedores-docker/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: contenedores-docker
 description: Docker y containerización. Dockerfiles optimizados con multi-stage builds, docker-compose, volúmenes, networking, health checks, security scanning, build caching, distroless images. Anti-patrones comunes.
-version: "1.0.3"
+version: "1.0.4"
 herramientasPermitidas: [Read]
 exclusiones:
   - "No cargar para orquestación Kubernetes (Deployments, Services, Helm, HPA) — para Kubernetes cargar `kubernetes-orquestacion`."
@@ -140,4 +140,6 @@ Para ejemplos completos de multi-stage Node.js/Angular, .dockerignore, docker-co
 
 **Proxy de desarrollo del frontend (Angular CLI, Vite, webpack-dev-server) con target hardcodeado a `localhost` es deuda invisible hasta el primer `docker compose up`**: en local todo funciona porque frontend y backend comparten host; en cuanto corren en contenedores separados, `localhost` dentro del contenedor del frontend apunta a sí mismo — el proxy devuelve 500/ECONNREFUSED en cada llamada a la API (síntoma típico: el login falla solo en Docker). Causa: el target del proxy es configuración de entorno, no constante del repo. Fix: usar `proxy.conf.js` (no `.json`) que lea `process.env.BACKEND_URL || 'http://localhost:8000'` y pasar `BACKEND_URL=http://backend:8000` (nombre del servicio de compose) vía `environment:` del servicio frontend. Origen: SIGAF 2026-07-02.
 
-**`docker exec ... psql` lanzado en background contra una BD donde el rol no autentica cuelga y congestiona el subsistema `docker exec` de Docker Desktop (Windows)**: lanzar en background (`run_in_background`/`&`) un `docker exec <contenedor> psql -U rol -d db -c "..."` donde el rol no puede autenticar deja la sesión `exec` colgada esperando; varias de esas sesiones huérfanas **saturan el subsistema de `docker exec`** y luego TODO `docker exec` (incluso `echo`) y hasta `docker restart` hacen timeout, aunque `docker ps`/`version` sigan respondiendo. Causa: cada `exec` abre una sesión que no termina; el daemon las acumula. Síntoma distintivo: `docker ps` responde pero cualquier `docker exec` cuelga. Fix: `docker restart <contenedor>` mata las sesiones `exec` huérfanas y destraba el daemon — detener el bash local con TaskStop NO mata el `psql` que corre dentro del contenedor. Prevención: NUNCA lanzar `docker exec ... psql` en background contra una BD/rol cuya autenticación no esté confirmada; correrlo en foreground con timeout corto y verificar el `psql` interactivo primero. En Git Bash (Windows), pasar `MSYS_NO_PATHCONV=1` cuando el comando lleva rutas POSIX (`/tmp/...`) a `docker exec`/`docker cp` para que MSYS no las convierta.
+**`docker exec ... psql` lanzado en background contra una BD donde el rol no autentica cuelga y congestiona el subsistema `docker exec` de Docker Desktop (Windows)**: lanzar en background (`run_in_background`/`&`) un `docker exec <contenedor> psql -U rol -d db -c "..."` donde el rol no puede autenticar deja la sesión `exec` colgada esperando; varias de esas sesiones huérfanas **saturan el subsistema de `docker exec`** y luego TODO `docker exec` (incluso `echo`) y hasta `docker restart` hacen timeout, aunque `docker ps`/`version` sigan respondiendo. Causa: cada `exec` abre una sesión que no termina; el daemon las acumula. Síntoma distintivo: `docker ps` responde pero cualquier `docker exec` cuelga. Fix: `docker restart <contenedor>` mata las sesiones `exec` huérfanas y destraba el daemon — detener el bash local con TaskStop NO mata el `psql` que corre dentro del contenedor. Prevención: NUNCA lanzar `docker exec ... psql` en background contra una BD/rol cuya autenticación no esté confirmada; correrlo en foreground con timeout corto y verificar el `psql` interactivo primero. En Git Bash (Windows), pasar `MSYS_NO_PATHCONV=1` cuando el comando lleva rutas POSIX (`/tmp/...`) a `docker exec`/`docker cp` para que MSYS no las convierta [CONFIRMADO x2 — aplica igual de necesario a `docker cp` que a `docker exec`, no solo al segundo].
+
+**`docker cp <dir-local> contenedor:<dir-remoto>` cuando `<dir-remoto>` YA EXISTE dentro del contenedor NO reemplaza su contenido — lo anida un nivel más profundo** [CONFIRMADO]: un segundo `docker cp database/tests contenedor:/tmp/verify/database/tests` sobre un `/tmp/verify/database/tests/` ya poblado por una corrida anterior crea `/tmp/verify/database/tests/tests/` con los archivos actualizados, mientras el path original sigue con los archivos VIEJOS — silenciosamente, sin error. Causa real de confusión de debugging: un fix a un `.sql` de test parece "no surtir efecto" porque el script verificador (`find /tmp/verify/database/tests -name "*.sql"`) sigue recogiendo la copia vieja en el path esperado; la copia nueva, correcta, queda un nivel más abajo sin que nada la use. Fix: SIEMPRE `docker exec <contenedor> rm -rf <dir-remoto>` inmediatamente antes de cada `docker cp` hacia ese mismo destino — nunca asumir semántica de overwrite en `docker cp` de directorios.

package/habilidades/css-moderno/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: css-moderno
 description: CSS moderno 2024+. Cubre Container Queries, CSS Layers (@layer), Nesting nativo, Custom Properties avanzadas, funciones min/max/clamp/color-mix, propiedades lógicas (block/inline), View Transitions API, animaciones performantes solo-compositor, dark mode patterns y anti-patrones críticos.
-version: "1.1.0"
+version: "1.1.1"
 herramientasPermitidas: [Read, Grep]
 exclusiones:
   - "No cargar para Tailwind CSS (clases utilitarias, @theme, cva, responsive) — para Tailwind cargar `tailwind-experto`."
@@ -166,3 +166,9 @@ Para ejemplos completos de Container Queries, CSS Layers, Nesting, Custom Proper
 **`clamp()` con `vw` en la función intermedia no escala correctamente en pantallas muy anchas si no se acota con `max()`**: `font-size: clamp(1rem, 2vw, 2rem)` en un monitor de 2560px da `2vw = 51.2px`, que es mayor que el máximo de `2rem = 32px` — el clamp lo atrapa pero el cálculo puede ser confuso al depurar. Causa: el valor de `vw` crece sin límite. Fix: entender que `clamp(min, preferido, max)` garantiza que el resultado siempre está entre min y max — el valor preferido puede ser cualquier expresión, incluso mayor que max, y el clamp simplemente retorna max en ese caso. Verificar los tres valores en los tamaños de viewport objetivo.
 
 **`var(--token)` NO resuelve cuando el valor lo consume JavaScript pintando a `<canvas>`**: las librerías que renderizan a canvas (Chart.js, OpenLayers, three.js/WebGL, o `ctx.fillStyle`/`strokeStyle`/`ctx.font` directos) NO reciben el contexto CSS del documento → el color sale negro o invisible **sin error en consola**. Causa: el canvas es un buffer de píxeles fuera del árbol CSS; la cascada y `getComputedStyle` no aplican al contexto 2D/WebGL — `var()` queda como string literal que el motor de canvas no interpreta. La frontera es: un color es `var(--x)` SOLO si lo consume CSS (`.css`/`.module.scss` o `style={{}}` sobre HTML); si lo consume JS pintando a canvas, debe ser hex/rgb concreto. Fix: pasar hex/rgb literal a esos objetos, con comentario anti-recurrencia (`// canvas: NO resuelve var()`). Si el color debe ser theme-aware, resolverlo primero en JS — `getComputedStyle(document.documentElement).getPropertyValue('--color-x').trim()` — y pasar el valor ya resuelto al canvas, re-leyéndolo al cambiar de tema.
+
+**El atributo HTML `hidden` NO oculta un elemento con `display:flex/grid`** [CONFIRMADO x4]: togglear el atributo `hidden` sobre un elemento con `.clase{display:flex}` no lo oculta, **sin error en consola**. Causa: la regla de user-agent `[hidden]{display:none}` tiene menor especificidad que cualquier regla de clase con `display` explícito → la clase gana en la cascada y el elemento sigue visible. Fix: para todo elemento colapsable con `display` distinto de `block`, agregar una regla explícita `.clase[hidden]{display:none}`. Aplica a acordeones, drawers, toggles, tabs — cualquier patrón que dependa del atributo `hidden` para colapsar. Evidencia: 4 instancias en una sola sesión (proyecto convertidor-md, 2026-07-20).
+
+**Items flex/grid-column bajo un contenedor `max-height` + `overflow` se COMPRIMEN y recortan en vez de scrollear**: en `display:flex;flex-direction:column;max-height:N;overflow-y:auto`, los hijos con `flex-shrink:1` (default) se encogen cuando el contenido excede la altura — y si tienen `overflow:hidden`, su contenido se corta — en lugar de que el contenedor haga scroll. Causa: `flex-shrink:1` autoriza al algoritmo flex a reducir los ítems para caber en el contenedor acotado, antes de recurrir al scroll. Fix: `flex-shrink:0` (o `flex:none`) en los hijos que deben conservar su altura natural; entonces el contenedor scrollea correctamente. Síntoma típico: encabezados de acordeón "recortados a rebanadas" cuando uno se expande.
+
+**Redefinir un nombre de clase ya usado re-estiliza el componente original en silencio**: dos reglas con el mismo selector de clase (`.chip {…}` … `.chip {…}`) en la misma hoja mezclan propiedades por cascada — la segunda definición altera el primer componente sin error. Causa: CSS no tiene scoping por defecto; el nombre de clase es global a la hoja. Fix: antes de reusar un nombre de clase para un componente nuevo, `grep` la hoja de estilos; namespacea la clase del componente nuevo (p. ej. `.grp-chip` en vez de reusar `.cfdi-chip`).