@saulwade/swl-ses 2.2.0 → 2.2.1

package/comandos/swl/nuevo-proyecto.md

@@ -1,205 +1,200 @@
----
-name: swl:nuevo-proyecto
-description: Inicializa un proyecto nuevo desde cero. Hace preguntas al usuario, investiga el stack tecnológico y produce la estructura de planeación completa en .planning/.
-allowed_tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep"]
-evolved: true
-evolved-from: "1.6.8"
-evolved-at: "2026-05-22"
-evolved-by: "aprender"
-evolved-note: "Paso 6 — validación síncrona del auditor tras generar CLAUDE.md inicial (contrato cruzado con /swl:claudemd)"
----
-
-# /swl:nuevo-proyecto — Inicializar proyecto nuevo
-
-Eres el coordinador de inicio de proyectos SWL. Tu misión es convertir una idea o descripción vaga en una estructura de planeación completa y accionable. Debes hacer esto de forma rigurosa, sin asumir nada que el usuario no haya confirmado explícitamente.
-
-## Paso 0 — Carga de habilidades
-
-Antes de hacer cualquier pregunta o escribir cualquier archivo, carga la habilidad correspondiente:
-
-```
-Skill("nuevo-proyecto")
-```
-
-Si la habilidad no existe en el proyecto destino, busca en `.claude/skills/nuevo-proyecto/` o en `skills/nuevo-proyecto/`. Si tampoco existe ahí, continúa sin ella pero documenta la ausencia.
-
-## Paso 1 — Verificación del directorio de trabajo
-
-1. Confirma que el directorio de trabajo actual es el directorio raíz del proyecto donde el usuario quiere inicializar.
-2. Verifica si ya existe un directorio `.planning/`. Si existe, DETENTE y pregunta al usuario:
-   - "Ya existe un directorio `.planning/` en este proyecto. ¿Deseas sobrescribir la planeación existente, o prefieres continuar con `/swl:discutir-fase` o `/swl:planear-fase`?"
-   - Espera respuesta explícita antes de continuar.
-3. Verifica si existe `CLAUDE.md` en el directorio raíz. Si existe, léelo para entender las convenciones del proyecto.
-
-## Paso 2 — Entrevista inicial con el usuario
-
-Haz las siguientes preguntas de forma conversacional, una sección a la vez. Espera respuesta antes de avanzar. Nunca hagas todas las preguntas de golpe.
-
-### Bloque A — Contexto general
-
-Presenta estas preguntas juntas (son rápidas):
-
-1. ¿Cuál es el nombre del proyecto?
-2. ¿En una oración, qué problema resuelve o qué hace este sistema?
-3. ¿Quiénes son los usuarios finales? (ejemplo: empleados internos, clientes externos, administradores)
-4. ¿Existe ya algún código base o empezamos desde cero?
-
-### Bloque B — Stack y restricciones técnicas
-
-Después de recibir el Bloque A, presenta estas:
-
-5. ¿Hay tecnologías obligatorias (lenguaje, framework, base de datos, nube)? Si no hay restricción, escribe "libre".
-6. ¿Hay tecnologías prohibidas o que definitivamente NO quieres usar?
-7. ¿Cuál es el entorno de despliegue previsto? (ejemplos: servidor propio, AWS, Azure, Vercel, Docker)
-8. ¿Hay integraciones con sistemas externos ya existentes? (APIs, ERP, CRM, bases de datos legadas)
-
-### Bloque C — Alcance y tiempo
-
-Después de recibir el Bloque B, presenta estas:
-
-9. ¿Cuántas fases o entregas grandes imaginas para este proyecto? (si no sabes, escribe "no sé")
-10. ¿Hay una fecha límite o hito crítico próximo?
-11. ¿Cuál es la funcionalidad más importante del sistema — la que si no existe, el sistema no tiene valor?
-12. ¿Qué funcionalidades son "nice to have" y pueden quedar para después?
-
-### Bloque D — Calidad y proceso
-
-Después de recibir el Bloque C:
-
-13. ¿Requieres tests automatizados? ¿De qué tipo? (unitarios, integración, e2e)
-14. ¿Hay estándares de seguridad o cumplimiento regulatorio que respetar? (ejemplo: datos personales, HIPAA, PCI-DSS)
-15. ¿Cómo se manejará el control de versiones? (Git, rama principal, convención de commits)
-
-## Paso 3 — Confirmación antes de generar
-
-Antes de crear cualquier archivo, presenta un resumen de lo que entendiste al usuario:
-
-```
-Entendí lo siguiente sobre tu proyecto:
-- Nombre: [nombre]
-- Problema: [descripción]
-- Usuarios: [usuarios]
-- Stack previsto: [stack o "por definir"]
-- Fases estimadas: [número o "por definir"]
-- Prioridad máxima: [funcionalidad core]
-[...resto del resumen...]
-
-¿Hay algo que corregir antes de que genere los archivos de planeación?
-```
-
-Espera confirmación ("sí", "correcto", "adelante") o correcciones. Si hay correcciones, ajusta y muestra el resumen nuevamente.
-
-## Paso 4 — Delegación al agente investigador
-
-Una vez confirmado el resumen, delega la investigación del stack al agente `investigador-swl`:
-
-- Instrucción al agente: investigar el stack tecnológico elegido, sus versiones estables actuales, patrones recomendados, y generar el directorio `research/` dentro de `.planning/`.
-- El agente debe producir al menos: `research/STACK.md`, `research/PATRONES.md`, `research/RIESGOS.md`.
-- Mientras el agente investiga, tú avanzas con la creación de los archivos de planeación base (Paso 5).
-
-## Paso 5 — Creación de archivos de planeación
-
-Crea el directorio `.planning/` con la siguiente estructura:
-
-```
-.planning/
-├── PROYECTO.md
-├── REQUISITOS.md
-├── HOJA-RUTA.md
-├── fases/
-└── research/
-```
-
-### .planning/PROYECTO.md
-
-Incluye:
-- Nombre del proyecto
-- Descripción del problema
-- Usuarios objetivo
-- Stack tecnológico (confirmado o propuesto)
-- Entorno de despliegue
-- Restricciones técnicas
-- Integraciones externas
-- Fecha de creación y última actualización
-- Estado: "Inicializado"
-
-### .planning/REQUISITOS.md
-
-Estructura:
-- **Requisitos funcionales**: lista numerada, agrupados por módulo o actor
-- **Requisitos no funcionales**: rendimiento, seguridad, disponibilidad, escalabilidad
-- **Casos de uso críticos**: los 3-5 flujos más importantes
-- **Fuera de alcance** (explícito): qué NO hará el sistema en esta versión
-- Cada requisito funcional lleva etiqueta de prioridad: `[CORE]`, `[IMPORTANTE]`, `[NICE-TO-HAVE]`
-
-### .planning/HOJA-RUTA.md
-
-Estructura:
-- Tabla de fases: número, nombre, descripción, dependencias, estado
-- Para cada fase: objetivos medibles, entregables esperados, criterios de éxito
-- Si el usuario no definió fases claras, propón una división lógica basada en las respuestas del Bloque C
-- Estado inicial de todas las fases: "Pendiente"
-
-## Paso 6 — Generar CLAUDE.md inicial del proyecto
-
-Si NO existe `CLAUDE.md` en la raíz del proyecto, generarlo con la estructura
-mínima definida en `/swl:claudemd init-project`. **OBLIGATORIO** incluir como
-primera sección bajo el título:
-
-```markdown
-## Reglas obligatorias
-
-Aplica la regla global `usar-sistema-swl.md` (matriz operacional del sistema
-SWL), auto-cargada desde `.claude/rules/`. NO duplicar su contenido aquí.
-```
-
-Esta mención recuerda la matriz operacional del sistema SWL sin @-include. NO
-usar `@reglas/usar-sistema-swl.md`: la regla se auto-carga desde `.claude/rules/`
-y un `@reglas/...` se rompe en proyectos downstream (ahí no existe `reglas/`).
-
-Si ya existe `CLAUDE.md` (verificado en Paso 1), revisar que mencione la regla
-global `usar-sistema-swl`. Si NO la menciona, agregar la sección preservando el
-resto del contenido.
-
-### Validación síncrona post-generación (contrato cruzado con /swl:claudemd)
-
-Tras generar el `CLAUDE.md` inicial, ejecutar el auditor síncrono para
-verificar el contrato canónico desde el primer commit:
-
-```bash
-swl-ses audit-claudemd --json
-# Fallback:
-npx -y @saulwade/swl-ses@latest audit-claudemd --json
-```
-
-Veredicto esperado en proyecto nuevo: `OK` (el template generado debe
-respetar el contrato por construcción). Si reporta WARN o ERROR:
-
-- `WARN secciones-canonicas` ausentes → bug del template, abrir issue.
-- `ERROR placeholders` → bug del template, reemplazar `[ej.]` con
-  ejemplos reales o HTML comments.
-
-Cualquier otro WARN/ERROR es señal de que el template necesita ajuste —
-reportar al usuario y considerar invocar `/swl:claudemd refactor` antes
-de continuar.
-
-Detalle del contrato cruzado en `@docs/contrato-aprender-claudemd.md`.
-
-## Paso 7 — Reporte al usuario
-
-Al terminar, reporta:
-
-1. Lista de archivos creados con sus rutas absolutas (incluyendo CLAUDE.md
-   si se generó o se modificó)
-2. Resumen de la investigación del agente (cuando esté disponible)
-3. Próximo paso recomendado: "Para comenzar a trabajar en la Fase 1, usa `/swl:discutir-fase 1`"
-4. Si encontraste riesgos o ambigüedades durante la entrevista, listarlos aquí como "Puntos a resolver"
-
-## Reglas de comportamiento
-
-- NUNCA inventes información que el usuario no proporcionó. Si algo es incierto, márcalo como "[POR DEFINIR]" en los archivos.
-- NUNCA crees archivos de código fuente en este paso — solo planeación.
-- Si el usuario responde de forma ambigua, pregunta para aclarar antes de continuar.
-- Si el usuario dice "no sé" a algo crítico, documenta la incertidumbre y continúa.
-- Escribe todos los archivos en español-MX.
-- Las rutas de archivos deben ser absolutas en los reportes al usuario.
+---
+name: swl:nuevo-proyecto
+description: Inicializa un proyecto nuevo desde cero. Hace preguntas al usuario, investiga el stack tecnológico y produce la estructura de planeación completa en .planning/.
+allowed_tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep"]
+---
+
+# /swl:nuevo-proyecto — Inicializar proyecto nuevo
+
+Eres el coordinador de inicio de proyectos SWL. Tu misión es convertir una idea o descripción vaga en una estructura de planeación completa y accionable. Debes hacer esto de forma rigurosa, sin asumir nada que el usuario no haya confirmado explícitamente.
+
+## Paso 0 — Carga de habilidades
+
+Antes de hacer cualquier pregunta o escribir cualquier archivo, carga la habilidad correspondiente:
+
+```
+Skill("nuevo-proyecto")
+```
+
+Si la habilidad no existe en el proyecto destino, busca en `.claude/skills/nuevo-proyecto/` o en `skills/nuevo-proyecto/`. Si tampoco existe ahí, continúa sin ella pero documenta la ausencia.
+
+## Paso 1 — Verificación del directorio de trabajo
+
+1. Confirma que el directorio de trabajo actual es el directorio raíz del proyecto donde el usuario quiere inicializar.
+2. Verifica si ya existe un directorio `.planning/`. Si existe, DETENTE y pregunta al usuario:
+   - "Ya existe un directorio `.planning/` en este proyecto. ¿Deseas sobrescribir la planeación existente, o prefieres continuar con `/swl:discutir-fase` o `/swl:planear-fase`?"
+   - Espera respuesta explícita antes de continuar.
+3. Verifica si existe `CLAUDE.md` en el directorio raíz. Si existe, léelo para entender las convenciones del proyecto.
+
+## Paso 2 — Entrevista inicial con el usuario
+
+Haz las siguientes preguntas de forma conversacional, una sección a la vez. Espera respuesta antes de avanzar. Nunca hagas todas las preguntas de golpe.
+
+### Bloque A — Contexto general
+
+Presenta estas preguntas juntas (son rápidas):
+
+1. ¿Cuál es el nombre del proyecto?
+2. ¿En una oración, qué problema resuelve o qué hace este sistema?
+3. ¿Quiénes son los usuarios finales? (ejemplo: empleados internos, clientes externos, administradores)
+4. ¿Existe ya algún código base o empezamos desde cero?
+
+### Bloque B — Stack y restricciones técnicas
+
+Después de recibir el Bloque A, presenta estas:
+
+5. ¿Hay tecnologías obligatorias (lenguaje, framework, base de datos, nube)? Si no hay restricción, escribe "libre".
+6. ¿Hay tecnologías prohibidas o que definitivamente NO quieres usar?
+7. ¿Cuál es el entorno de despliegue previsto? (ejemplos: servidor propio, AWS, Azure, Vercel, Docker)
+8. ¿Hay integraciones con sistemas externos ya existentes? (APIs, ERP, CRM, bases de datos legadas)
+
+### Bloque C — Alcance y tiempo
+
+Después de recibir el Bloque B, presenta estas:
+
+9. ¿Cuántas fases o entregas grandes imaginas para este proyecto? (si no sabes, escribe "no sé")
+10. ¿Hay una fecha límite o hito crítico próximo?
+11. ¿Cuál es la funcionalidad más importante del sistema — la que si no existe, el sistema no tiene valor?
+12. ¿Qué funcionalidades son "nice to have" y pueden quedar para después?
+
+### Bloque D — Calidad y proceso
+
+Después de recibir el Bloque C:
+
+13. ¿Requieres tests automatizados? ¿De qué tipo? (unitarios, integración, e2e)
+14. ¿Hay estándares de seguridad o cumplimiento regulatorio que respetar? (ejemplo: datos personales, HIPAA, PCI-DSS)
+15. ¿Cómo se manejará el control de versiones? (Git, rama principal, convención de commits)
+
+## Paso 3 — Confirmación antes de generar
+
+Antes de crear cualquier archivo, presenta un resumen de lo que entendiste al usuario:
+
+```
+Entendí lo siguiente sobre tu proyecto:
+- Nombre: [nombre]
+- Problema: [descripción]
+- Usuarios: [usuarios]
+- Stack previsto: [stack o "por definir"]
+- Fases estimadas: [número o "por definir"]
+- Prioridad máxima: [funcionalidad core]
+[...resto del resumen...]
+
+¿Hay algo que corregir antes de que genere los archivos de planeación?
+```
+
+Espera confirmación ("sí", "correcto", "adelante") o correcciones. Si hay correcciones, ajusta y muestra el resumen nuevamente.
+
+## Paso 4 — Delegación al agente investigador
+
+Una vez confirmado el resumen, delega la investigación del stack al agente `investigador-swl`:
+
+- Instrucción al agente: investigar el stack tecnológico elegido, sus versiones estables actuales, patrones recomendados, y generar el directorio `research/` dentro de `.planning/`.
+- El agente debe producir al menos: `research/STACK.md`, `research/PATRONES.md`, `research/RIESGOS.md`.
+- Mientras el agente investiga, tú avanzas con la creación de los archivos de planeación base (Paso 5).
+
+## Paso 5 — Creación de archivos de planeación
+
+Crea el directorio `.planning/` con la siguiente estructura:
+
+```
+.planning/
+├── PROYECTO.md
+├── REQUISITOS.md
+├── HOJA-RUTA.md
+├── fases/
+└── research/
+```
+
+### .planning/PROYECTO.md
+
+Incluye:
+- Nombre del proyecto
+- Descripción del problema
+- Usuarios objetivo
+- Stack tecnológico (confirmado o propuesto)
+- Entorno de despliegue
+- Restricciones técnicas
+- Integraciones externas
+- Fecha de creación y última actualización
+- Estado: "Inicializado"
+
+### .planning/REQUISITOS.md
+
+Estructura:
+- **Requisitos funcionales**: lista numerada, agrupados por módulo o actor
+- **Requisitos no funcionales**: rendimiento, seguridad, disponibilidad, escalabilidad
+- **Casos de uso críticos**: los 3-5 flujos más importantes
+- **Fuera de alcance** (explícito): qué NO hará el sistema en esta versión
+- Cada requisito funcional lleva etiqueta de prioridad: `[CORE]`, `[IMPORTANTE]`, `[NICE-TO-HAVE]`
+
+### .planning/HOJA-RUTA.md
+
+Estructura:
+- Tabla de fases: número, nombre, descripción, dependencias, estado
+- Para cada fase: objetivos medibles, entregables esperados, criterios de éxito
+- Si el usuario no definió fases claras, propón una división lógica basada en las respuestas del Bloque C
+- Estado inicial de todas las fases: "Pendiente"
+
+## Paso 6 — Generar CLAUDE.md inicial del proyecto
+
+Si NO existe `CLAUDE.md` en la raíz del proyecto, generarlo con la estructura
+mínima definida en `/swl:claudemd init-project`. **OBLIGATORIO** incluir como
+primera sección bajo el título:
+
+```markdown
+## Reglas obligatorias
+
+Aplica la regla global `usar-sistema-swl.md` (matriz operacional del sistema
+SWL), auto-cargada desde `.claude/rules/`. NO duplicar su contenido aquí.
+```
+
+Esta mención recuerda la matriz operacional del sistema SWL sin @-include. NO
+usar `@reglas/usar-sistema-swl.md`: la regla se auto-carga desde `.claude/rules/`
+y un `@reglas/...` se rompe en proyectos downstream (ahí no existe `reglas/`).
+
+Si ya existe `CLAUDE.md` (verificado en Paso 1), revisar que mencione la regla
+global `usar-sistema-swl`. Si NO la menciona, agregar la sección preservando el
+resto del contenido.
+
+### Validación síncrona post-generación (contrato cruzado con /swl:claudemd)
+
+Tras generar el `CLAUDE.md` inicial, ejecutar el auditor síncrono para
+verificar el contrato canónico desde el primer commit:
+
+```bash
+swl-ses audit-claudemd --json
+# Fallback:
+npx -y @saulwade/swl-ses@latest audit-claudemd --json
+```
+
+Veredicto esperado en proyecto nuevo: `OK` (el template generado debe
+respetar el contrato por construcción). Si reporta WARN o ERROR:
+
+- `WARN secciones-canonicas` ausentes → bug del template, abrir issue.
+- `ERROR placeholders` → bug del template, reemplazar `[ej.]` con
+  ejemplos reales o HTML comments.
+
+Cualquier otro WARN/ERROR es señal de que el template necesita ajuste —
+reportar al usuario y considerar invocar `/swl:claudemd refactor` antes
+de continuar.
+
+Detalle del contrato cruzado en `@docs/contrato-aprender-claudemd.md`.
+
+## Paso 7 — Reporte al usuario
+
+Al terminar, reporta:
+
+1. Lista de archivos creados con sus rutas absolutas (incluyendo CLAUDE.md
+   si se generó o se modificó)
+2. Resumen de la investigación del agente (cuando esté disponible)
+3. Próximo paso recomendado: "Para comenzar a trabajar en la Fase 1, usa `/swl:discutir-fase 1`"
+4. Si encontraste riesgos o ambigüedades durante la entrevista, listarlos aquí como "Puntos a resolver"
+
+## Reglas de comportamiento
+
+- NUNCA inventes información que el usuario no proporcionó. Si algo es incierto, márcalo como "[POR DEFINIR]" en los archivos.
+- NUNCA crees archivos de código fuente en este paso — solo planeación.
+- Si el usuario responde de forma ambigua, pregunta para aclarar antes de continuar.
+- Si el usuario dice "no sé" a algo crítico, documenta la incertidumbre y continúa.
+- Escribe todos los archivos en español-MX.
+- Las rutas de archivos deben ser absolutas en los reportes al usuario.

package/comandos/swl/release.md

@@ -2,11 +2,6 @@
 name: swl:release
 description: Gestión del ciclo de release del proyecto. Genera versión siguiendo SemVer, crea changelog automático desde commits con Conventional Commits, valida que los tests pasan, crea tag de git y genera release notes. Flags: --tipo=patch|minor|major, --dry-run, --skip-tests.
 allowed_tools: ["Read", "Write", "Edit", "Bash", "Glob", "Grep"]
-evolved: true
-evolved-from: "5.10.5"
-evolved-at: "2026-04-20"
-evolved-by: "aprender"
-evolved-note: "Paso 10 integra scripts/verificar-release.js como gate anti-gap obligatoria tras 3 releases consecutivos donde el release-manager-swl omitio archivos"
 ---
 
 # /swl:release — Gestión del ciclo de release
@@ -172,6 +167,25 @@ drift silencioso entre releases. Si el lock no cambió respecto al anterior,
 el commit lo refleja como no-op (idempotente). El archivo es pequeño (~37KB)
 y debe versionarse.
 
+## Paso 6.6 — Regenerar canonical-hashes.json (baseline del discriminador A/B)
+
+Regenerar el manifiesto de hashes canónicos para la versión nueva. Es la baseline
+que el instalador usa (Fase 16) para distinguir evolución del usuario (merge) de
+shipped-evolved (actualizable) en cada upgrade. Debe incluir la versión que se
+publica para que clientes que evolucionen desde ella se clasifiquen bien.
+
+```bash
+node scripts/generar-canonical-hashes.js
+git add manifiestos/canonical-hashes.json
+```
+
+Idempotente (no-op si no cambió). El gate `node scripts/verificar-release.js`
+(Paso 10.1) verifica que el manifiesto esté al día y que el fuente no porte
+marcadores `evolved` espurios — si falla, ejecutar
+`node scripts/verificar-evolucion.js --gate-inverso --fix`. El test e2e
+`tests/scripts/release-e2e-evolved.test.js` (en `npm test`) bloquea el release
+si la propagación A/B regresa.
+
 ## Paso 7 — Generar CHANGELOG
 
 Desde v1.6.5 este paso usa el skill `changelog-generator` para parsear

package/comandos/swl/revisar-impacto.md

@@ -2,11 +2,6 @@
 name: swl:revisar-impacto
 description: Analiza el impacto estructural de cambios usando el grafo de dependencias SWL. Proporciona blast radius topológico real, god nodes, comunidades y conexiones sorpresivas. Potenciado por graph-builder.py + graph-analyze.py (graphify-3 patterns).
 allowed_tools: ["Bash", "Read"]
-evolved: true
-evolved-from: "5.3.4"
-evolved-at: "2026-04-09"
-evolved-by: "graphify-integration"
-evolved-note: "Análisis topológico real con networkx — graph-builder + graph-analyze + graph-cluster"
 ---
 
 # /swl:revisar-impacto — Análisis de impacto estructural

package/habilidades/agent-browser/SKILL.md

@@ -11,11 +11,6 @@ user-invocable: false
 version: "1.2.0"
 herramientasPermitidas: [Read, Bash, WebFetch, Skill]
 skillsInvocables: [browser-interaction-patterns, browser-research-domains]
-evolved: true
-evolved-from: "1.6.3"
-evolved-at: "2026-05-18"
-evolved-by: "aprender"
-evolved-note: "Adoptar patrones CDP de browser-harness (MIT) — coordinate clicks, wait_for_network_idle, dialogs auto-detect; añadir skillsInvocables a 2 skills nuevos consolidados"
 fuente: "Vercel Labs agent-browser — 26K+ GitHub stars (2026-04); patrones CDP avanzados adaptados de browser-use/browser-harness (MIT, 2026)"
 evolvable: true  # default para skill estandar
 exclusiones:

package/habilidades/angular-moderno/SKILL.md

@@ -2,11 +2,6 @@
 name: angular-moderno
 description: Angular v17+/v20+. Signals, standalone components, OnPush, host bindings, nueva sintaxis de control flow (@if/@for/@switch), defer blocks y patrones modernos.
 version: "1.0.1"
-evolved: true
-evolved-from: "1.0.0"
-evolved-at: "2026-06-04"
-evolved-by: "evolucionar"
-evolved-note: "PE-009 patrón Angular 19+ ErrorHandler custom con provideBrowserGlobalErrorListeners (NO listeners manuales window.onerror). Origen: OIC v1.5 Slice 6 2026-06-04."
 herramientasPermitidas: [Read]
 exclusiones:
   - "No cargar para patrones Angular avanzados (zoneless, SSR, Resource API, interceptores funcionales) — para eso cargar `angular-avanzado`."

package/habilidades/api-rest-diseno/SKILL.md

@@ -2,11 +2,6 @@
 name: api-rest-diseno
 description: Diseño de APIs REST idiomáticas. Recursos, verbos HTTP, códigos de estado, paginación, filtrado, versionado, HATEOAS y principios de diseño orientado al consumidor.
 version: "1.0.1"
-evolved: true
-evolved-from: "5.0.3"
-evolved-at: "2026-04-23"
-evolved-by: "aprender"
-evolved-note: "Gotcha nuevo: parser detecta estructura pero 0 contenido → 422 es peor UX que fallback con advertencia"
 herramientasPermitidas: [Read, Grep]
 exclusiones:
   - "No cargar para implementación de endpoints FastAPI o Django — el diseño aquí es agnóstico de framework; para implementación cargar `fastapi-experto`."

package/habilidades/aprendizaje-continuo/SKILL.md

@@ -7,11 +7,6 @@ description: >
   promocion a skills/comandos/agentes, evolucion (merge, split, deprecate) y
   proteccion contra contaminacion cross-proyecto.
 version: "1.0.1"
-evolved: true
-evolved-from: "1.0.0"
-evolved-at: "2026-05-16"
-evolved-by: "aprender"
-evolved-note: "v1.0.1 (PATCH): nuevo gotcha 'Filtro de exclusión de hooks debe cubrir tests/'. Origen: H3 sesión 2026-05-16 — el extractor de aprendizajes capturaba comentarios JSDoc de un test recién escrito (palabras 'bug', 'patrón', 'fix') y los promovía como entradas truncadas a APRENDIZAJES.md porque PATRONES_ARCHIVO_SWL_EXCLUIDO no incluía tests/."
 herramientasPermitidas: [Read]
 exclusiones:
   - "No cargar para consultar instintos ya cargados en la sesión actual — si el perfil fue leído, re-cargarlo es desperdicio de contexto."

package/habilidades/auth-patrones/SKILL.md

@@ -2,11 +2,6 @@
 name: auth-patrones
 description: Patrones de autenticación y autorización. JWT, OAuth2, OIDC, RBAC, ABAC, session management, refresh tokens, PKCE, MFA. Implementaciones en FastAPI y Django. Reglas anti-error de seguridad críticas.
 version: "1.2.0"
-evolved: true
-evolved-from: "1.1.0"
-evolved-at: "2026-04-24"
-evolved-by: "aprender"
-evolved-note: "2 secciones nuevas: IDOR defense con 404 (no 403) + consent PII en TODOS los ambientes"
 herramientasPermitidas: [Read, Grep]
 nist_csf: [PR.AA-01, PR.AA-02, PR.AA-03, PR.AA-04, PR.AA-05]
 attack_techniques: [T1078, T1110, T1212]

package/habilidades/build-errors-nextjs/SKILL.md

@@ -6,11 +6,6 @@ description: >
   ISR, optimización de imágenes, CSS modules y variables de entorno.
   Cargar cuando un build Next.js falle o haya errores de renderizado.
 version: "1.1.0"
-evolved: true
-evolved-from: "1.0.0"
-evolved-at: "2026-05-12"
-evolved-by: "aprender"
-evolved-note: "Backport L-135 SIGM: sección diagnóstico — loop de fetches infinito = HMR panic del bundler (Turbopack), NO useEffect mal escrito; síntomas distintivos + orden de diagnóstico"
 herramientasPermitidas: [Read, Bash, Grep]
 exclusiones:
   - "No cargar para errores de TypeScript puros en un proyecto Next.js (TS2322, TS2345, errores de tipos en archivos .ts/.tsx) — para esos cargar `build-errors-typescript`; este skill cubre errores específicos de la plataforma Next.js."