@saulwade/swl-ses 2.5.3 → 2.6.1

package/bin/swl-ses.js

@@ -106,8 +106,8 @@ const COMANDOS = {
   doctor: '../scripts/doctor.js',
   update: '../scripts/actualizar.js',
   uninstall: '../scripts/desinstalar.js',
-  prune: '../scripts/prune.js',
-  valor: '../scripts/evidencia-valor.js',
+  prune: '../scripts/prune.js',
+  valor: '../scripts/evidencia-valor.js',
   'field-report': '../scripts/field-report.js',
   'check-update': '../scripts/check-update.js',
   'install-git-hook': '../scripts/instalar-git-hook.js',
@@ -141,7 +141,14 @@ const COMANDOS = {
   'loop-telemetry': '../scripts/cli/loop-telemetry.js',
   'configurar-ci': '../scripts/cli/configurar-ci.js',
   'ciclo-evolucion': '../scripts/cli/ciclo-evolucion.js',
+  'ciclo-autonomo': '../scripts/cli/ciclo-autonomo.js',
+  'ciclo-fase-b': '../scripts/cli/ciclo-fase-b.js',
   notificaciones: '../scripts/cli/notificaciones.js',
+  autonomia: '../scripts/cli/autonomia.js',
+  'memoria-search': '../scripts/cli/memoria-search.js',
+  'guardrail-metrics': '../scripts/cli/guardrail-metrics.js',
+  'run-eval': '../scripts/cli/run-eval.js',
+  'benchmark-memoria': '../scripts/cli/benchmark-memoria.js',
 };
 
 // Comandos con subcomandos (nivel 2)
@@ -164,9 +171,9 @@ COMANDOS PRINCIPALES:
   doctor                        Diagnóstica problemas de instalación
   update                        Actualiza componentes instalados
   uninstall                     Desinstala componentes del runtime
-  prune                         Purga componentes retirados del paquete (dry-run; --confirmar ejecuta)
-  valor                         Panel de evidencia de valor del harness (intercepciones, defectos, DORA/CI, uso; --json, --dias N)
-  install --solo-hooks          Activa hooks (telemetría) a nivel proyecto apuntando al scope global — sin duplicar componentes en la UI
+  prune                         Purga componentes retirados del paquete (dry-run; --confirmar ejecuta)
+  valor                         Panel de evidencia de valor del harness (intercepciones, defectos, DORA/CI, uso; --json, --dias N)
+  install --solo-hooks          Activa hooks (telemetría) a nivel proyecto apuntando al scope global — sin duplicar componentes en la UI
   field-report                  Reporte de agregados anónimos para compartir con el autor (opt-in, revisión manual)
   check-update                  Fuerza consulta inmediata de nueva versión en npm (sin throttle)
   install-git-hook [--force]    Instala pre-commit hook que avisa de nuevas versiones.
@@ -244,9 +251,26 @@ COMANDOS PRINCIPALES:
                                 Usado por /swl:configurar-ci.
   ciclo-evolucion               Regenera .planning/evolution/metricas.json.
                                 Usado por /swl:status.
+  ciclo-autonomo [on|off|status] Motor determinista de aprendizaje (Fase A,
+                                ADR-0041). Nace encendido; off = kill-switch.
+                                Usado por /swl:evolucion-continua.
+  ciclo-fase-b [--dry-run|status] Runner headless de Fase B (ADR-0042 gate
+                                G-B). En esta versión siempre dry-run.
+  nudge-accionar <id> [--por X] Marca un nudge como accionado (cierra el
+                                ciclo). Usado por /swl:aprender y /swl:evolucionar.
   notificaciones <op>           Telegram: init|status|disable|repair|bot-start|
                                 bot-stop|bot-status|bot-restart|bot-enable-autostart|
                                 bot-disable-autostart. Usado por /swl:notificaciones.
+  autonomia --accion="..."      Registra auto-checkpoint según el dial de
+                                autonomía. Usado por ejecutar-fase.
+  memoria-search <op>           Búsqueda en memoria del proyecto: search|timeline|
+                                fetch (JSON). Usado por memoria-busqueda.
+  guardrail-metrics [--json]    Métricas + diagnóstico de guardrails de la sesión.
+                                Usado por /swl:status (dashboard).
+  run-eval <eval.json>          Ejecuta un eval del framework de validación de
+                                outputs. --rebuild-aggregate reconstruye métricas.
+  benchmark-memoria [--json]    Benchmark de retrieval de memoria (--dataset,
+                                --limit, --verbose).
   info    [--target <runtime>]  Muestra información del sistema instalado
   help                          Muestra esta ayuda (alias de --help)
   list    [--target <runtime>]  Lista todos los agentes y skills instalados
@@ -263,8 +287,9 @@ OPCIONES DE INSTALL:
   --target <runtime>     Runtime destino: claude|openclaude|copilot|opencode|codex|gemini|cursor (default: claude)
   --profile <perfil>     Perfil: core|backend-python|backend-node|frontend-react|frontend-angular|
                          fullstack-python-angular|fullstack-node-react|mobile|devops|completo (default: completo)
-  --with <componentes>   Incluir componentes adicionales (separados por coma)
-  --without <comps>      Excluir componentes (separados por coma)
+  --with <modulos>       Incluir módulos adicionales, incluidos los opt-in fuera de todo perfil
+                         (p. ej. reglas-personales). Quedan en el install-state y update los preserva
+  --without <modulos>    Excluir módulos (separados por coma; también quita extras preservados)
   --global               Instalar en directorio global del runtime (~/.claude, etc.)
   --local                Instalar en directorio local del proyecto (.claude/, etc.)
   --dry-run              Mostrar plan sin aplicar cambios

package/comandos/swl/actualizar.md

@@ -128,7 +128,7 @@ Espera confirmación del usuario.
 ## Paso 3 — Ejecutar actualización
 
 ```bash
-npx @saulwade/swl-ses@latest install --target claude --profile <PERFIL> [--global] --force
+npx -y @saulwade/swl-ses@latest install --target claude --profile <PERFIL> [--global] --force
 ```
 
 Usa el mismo perfil y ubicación de la instalación original.
@@ -136,7 +136,7 @@ Usa el mismo perfil y ubicación de la instalación original.
 ## Paso 4 — Ejecutar doctor
 
 ```bash
-npx @saulwade/swl-ses@latest doctor
+npx -y @saulwade/swl-ses@latest doctor
 ```
 
 ## Paso 5 — Reportar resultado
@@ -157,7 +157,7 @@ Doctor: <resultado>
 Si el usuario dice algo como "actualiza y cambia a perfil completo", ejecuta:
 
 ```bash
-npx @saulwade/swl-ses@latest install --target claude --profile <NUEVO_PERFIL> [--global] --force
+npx -y @saulwade/swl-ses@latest install --target claude --profile <NUEVO_PERFIL> [--global] --force
 ```
 
 Informa que el cambio de perfil puede agregar componentes nuevos pero no elimina los del perfil anterior. Si quiere una instalación limpia con otro perfil, sugiere:

package/comandos/swl/aprender.md

@@ -542,6 +542,19 @@ Archivos actualizados:
 [lista con rutas]
 ```
 
+### Cierre del ciclo de nudges (obligatorio si este comando fue disparado por un nudge)
+
+Si esta ejecución atendió un nudge (de `auto-consolidacion.js` o cualquier
+otro visible en el briefing o en `evolution/nudges.jsonl`), márcalo como
+accionado — sin este cierre los nudges se acumulan sin consumidor:
+
+```bash
+swl-ses nudge-accionar <id-del-nudge> --por aprender
+```
+
+El `<id>` viene en el propio nudge (campo `id` del JSONL o del mensaje del
+hook). Si la sesión fue manual (sin nudge), omite este cierre.
+
 ## Paso 7.3 — Diary estructurado de la sesión (opcional)
 
 Si la sesión generó al menos 3 aprendizajes aprobados (cualquier categoría),

package/comandos/swl/deuda-codigo.md

@@ -1,97 +1,97 @@
----
-name: swl:deuda-codigo
-description: Cosecha los marcadores `simplificado:` del código (simplificaciones deliberadas con techo y trigger de upgrade) hacia un ledger visible, detecta marcadores sin trigger (riesgo de rot) y sincroniza opcionalmente con .planning/DEUDA-TECNICA.md. Cargar cuando el usuario pida "qué simplificamos", "deuda de código", "cosecha los marcadores", o tras una fase que dejó marcadores simplificado:.
-allowed_tools: ["Grep", "Read", "Edit", "Bash"]
----
-
-# /swl:deuda-codigo — Cosecha de simplificaciones deliberadas
-
-Todo atajo intencional marcado con `simplificado: <techo>, <trigger>` (convención
-de `Skill("prevencion-sobreingenieria")`, adaptada del patrón `ponytail:` de
-ponytail, MIT) se cosecha aquí en un ledger — para que un "después" no se
-convierta en "nunca" (regla `arreglar-al-detectar.md`).
-
-## Uso
-
-```
-/swl:deuda-codigo              — Reporte en pantalla (no escribe nada)
-/swl:deuda-codigo --sync       — Además sincroniza a .planning/DEUDA-TECNICA.md
-/swl:deuda-codigo --owners     — Agrega autor por marcador (git blame)
-/swl:deuda-codigo <directorio> — Limita la cosecha a un subárbol
-```
-
-## Paso 1 — Cosechar los marcadores
-
-Buscar con Grep (herramienta, no shell) el patrón sobre el árbol del proyecto,
-excluyendo `node_modules`, `.git`, `dist`, `build`, `temp`, `respositorios-git`:
-
-```
-Grep(pattern: "(#|//|--|<!--|/\\*)\\s?simplificado:", output_mode: "content", -n: true)
-```
-
-Cada hit es una fila del ledger. El prefijo de comentario evita capturar prosa
-que solo menciona la convención (como este archivo o el SKILL.md).
-
-## Paso 2 — Parsear techo y trigger
-
-La convención es `simplificado: <techo>, <trigger de upgrade>`:
-
-- **techo**: el límite conocido del atajo (lock global, O(n²), heurística naive).
-- **trigger**: la condición observable que obliga el upgrade ("si throughput > X",
-  "cuando haya un segundo consumidor", "antes del primer deploy productivo").
-
-Si el texto tras `simplificado:` no contiene una condición observable,
-etiquetar la fila `sin-trigger` — esos son los que rotan en silencio.
-
-## Paso 3 — Reporte
-
-Una fila por marcador, agrupado por archivo:
-
-```
-## Ledger de simplificaciones — [fecha]
-
-| Ubicación | Qué se simplificó | Techo | Trigger de upgrade | Estado |
-|---|---|---|---|---|
-| src/locks.py:42 | lock global | contención con N workers | throughput > 500 rps | ok |
-| api/cache.js:17 | TTL fijo 5 min | staleness | (ninguno) | sin-trigger |
-
-Total: N marcadores, M sin trigger.
-```
-
-Con `--owners`: agregar columna con `git blame -L<línea>,<línea> --porcelain <archivo>`
-(solo el autor, una llamada por fila).
-
-Si no hay marcadores: `Sin deuda simplificado:. Ledger limpio.` — y terminar.
-
-## Paso 4 — Sincronizar al ledger formal (solo con --sync)
-
-Para cada marcador `sin-trigger` o de techo relevante que no exista ya en
-`.planning/DEUDA-TECNICA.md`:
-
-1. Leer el ledger actual y verificar duplicados por ubicación (`archivo:línea`).
-2. Agregar entrada `### DT-SIMPLIFICADO-<n>` con: ubicación, techo, trigger
-   (o `PENDIENTE DE TRIGGER` marcado como acción requerida), fecha de cosecha.
-3. Los `sin-trigger` NO se sincronizan como DT válidas hasta tener trigger:
-   reportarlos al usuario como acción inmediata — una DT sin trigger verificable
-   viola `arreglar-al-detectar.md § DT formal`.
-
-NUNCA borrar ni editar los marcadores del código durante la cosecha: el
-comando lee y reporta; el código solo cambia cuando el trigger se cumple y
-el upgrade se implementa.
-
-## Cuándo usarlo
-
-- Cierre de fase (`/swl:verificar` lo puede invocar como pasada complementaria).
-- Antes de un release: los `sin-trigger` son bloqueo blando (reportar en el gate).
-- Auditorías de deuda: junto con la sección "Sobre-ingeniería" de `/swl:revisar`.
-
-## Gotchas
-
-- **Marcadores en fixtures o docs**: los hits dentro de `tests/fixtures/`,
-  ejemplos de skills o este propio comando son material de referencia, no deuda
-  — excluirlos del conteo y decir cuántos se excluyeron (sin caps silenciosos).
-- **Prefijos de comentario por stack**: el patrón cubre `#` (Python/shell),
-  `//` (JS/TS/Go/Rust/C#/Java), `--` (SQL/Lua), `<!--` (HTML/MD) y `/*` (CSS/C).
-  Si el proyecto usa otro prefijo, agregarlo al patrón y decirlo en el reporte.
-- **`git blame` sobre archivos renombrados**: usar `git blame -M -C` si el
-  autor aparece como el commit del rename.
+---
+name: swl:deuda-codigo
+description: Cosecha los marcadores `simplificado:` del código (simplificaciones deliberadas con techo y trigger de upgrade) hacia un ledger visible, detecta marcadores sin trigger (riesgo de rot) y sincroniza opcionalmente con .planning/DEUDA-TECNICA.md. Cargar cuando el usuario pida "qué simplificamos", "deuda de código", "cosecha los marcadores", o tras una fase que dejó marcadores simplificado:.
+allowed_tools: ["Grep", "Read", "Edit", "Bash"]
+---
+
+# /swl:deuda-codigo — Cosecha de simplificaciones deliberadas
+
+Todo atajo intencional marcado con `simplificado: <techo>, <trigger>` (convención
+de `Skill("prevencion-sobreingenieria")`, adaptada del patrón `ponytail:` de
+ponytail, MIT) se cosecha aquí en un ledger — para que un "después" no se
+convierta en "nunca" (regla `arreglar-al-detectar.md`).
+
+## Uso
+
+```
+/swl:deuda-codigo              — Reporte en pantalla (no escribe nada)
+/swl:deuda-codigo --sync       — Además sincroniza a .planning/DEUDA-TECNICA.md
+/swl:deuda-codigo --owners     — Agrega autor por marcador (git blame)
+/swl:deuda-codigo <directorio> — Limita la cosecha a un subárbol
+```
+
+## Paso 1 — Cosechar los marcadores
+
+Buscar con Grep (herramienta, no shell) el patrón sobre el árbol del proyecto,
+excluyendo `node_modules`, `.git`, `dist`, `build`, `temp`, `respositorios-git`:
+
+```
+Grep(pattern: "(#|//|--|<!--|/\\*)\\s?simplificado:", output_mode: "content", -n: true)
+```
+
+Cada hit es una fila del ledger. El prefijo de comentario evita capturar prosa
+que solo menciona la convención (como este archivo o el SKILL.md).
+
+## Paso 2 — Parsear techo y trigger
+
+La convención es `simplificado: <techo>, <trigger de upgrade>`:
+
+- **techo**: el límite conocido del atajo (lock global, O(n²), heurística naive).
+- **trigger**: la condición observable que obliga el upgrade ("si throughput > X",
+  "cuando haya un segundo consumidor", "antes del primer deploy productivo").
+
+Si el texto tras `simplificado:` no contiene una condición observable,
+etiquetar la fila `sin-trigger` — esos son los que rotan en silencio.
+
+## Paso 3 — Reporte
+
+Una fila por marcador, agrupado por archivo:
+
+```
+## Ledger de simplificaciones — [fecha]
+
+| Ubicación | Qué se simplificó | Techo | Trigger de upgrade | Estado |
+|---|---|---|---|---|
+| src/locks.py:42 | lock global | contención con N workers | throughput > 500 rps | ok |
+| api/cache.js:17 | TTL fijo 5 min | staleness | (ninguno) | sin-trigger |
+
+Total: N marcadores, M sin trigger.
+```
+
+Con `--owners`: agregar columna con `git blame -L<línea>,<línea> --porcelain <archivo>`
+(solo el autor, una llamada por fila).
+
+Si no hay marcadores: `Sin deuda simplificado:. Ledger limpio.` — y terminar.
+
+## Paso 4 — Sincronizar al ledger formal (solo con --sync)
+
+Para cada marcador `sin-trigger` o de techo relevante que no exista ya en
+`.planning/DEUDA-TECNICA.md`:
+
+1. Leer el ledger actual y verificar duplicados por ubicación (`archivo:línea`).
+2. Agregar entrada `### DT-SIMPLIFICADO-<n>` con: ubicación, techo, trigger
+   (o `PENDIENTE DE TRIGGER` marcado como acción requerida), fecha de cosecha.
+3. Los `sin-trigger` NO se sincronizan como DT válidas hasta tener trigger:
+   reportarlos al usuario como acción inmediata — una DT sin trigger verificable
+   viola `arreglar-al-detectar.md § DT formal`.
+
+NUNCA borrar ni editar los marcadores del código durante la cosecha: el
+comando lee y reporta; el código solo cambia cuando el trigger se cumple y
+el upgrade se implementa.
+
+## Cuándo usarlo
+
+- Cierre de fase (`/swl:verificar` lo puede invocar como pasada complementaria).
+- Antes de un release: los `sin-trigger` son bloqueo blando (reportar en el gate).
+- Auditorías de deuda: junto con la sección "Sobre-ingeniería" de `/swl:revisar`.
+
+## Gotchas
+
+- **Marcadores en fixtures o docs**: los hits dentro de `tests/fixtures/`,
+  ejemplos de skills o este propio comando son material de referencia, no deuda
+  — excluirlos del conteo y decir cuántos se excluyeron (sin caps silenciosos).
+- **Prefijos de comentario por stack**: el patrón cubre `#` (Python/shell),
+  `//` (JS/TS/Go/Rust/C#/Java), `--` (SQL/Lua), `<!--` (HTML/MD) y `/*` (CSS/C).
+  Si el proyecto usa otro prefijo, agregarlo al patrón y decirlo en el reporte.
+- **`git blame` sobre archivos renombrados**: usar `git blame -M -C` si el
+  autor aparece como el commit del rename.

package/comandos/swl/evaluar-skill.md

@@ -374,9 +374,22 @@ Umbral de promoción:
 Si un skill es rechazado ≥3 veces consecutivas, el agente escala al usuario
 con análisis de qué dimensiones bajan el score. Origen: ADR 0013 sección 3C.
 
-## Paso 4 — Emitir reporte
+## Paso 4 — Emitir reporte y artefacto de procedencia
 
-Generar el siguiente reporte directamente en la conversación:
+Tras calcular el score final y el badge, persiste el **artefacto de
+evaluación con procedencia** (única fuente que `run-skill-evals.js
+--record-after` acepta para aprobar una evolución — anti-gaming,
+DT-AGP-SCORE-AUTODECLARADO):
+
+```bash
+swl-ses run-skill-evals <nombre> --emitir-evaluacion \
+  --score=<score-final> --badge=<badge> --producido-por=evaluar-skill
+# → escribe .planning/evolution/evaluaciones/<nombre>.json (fechado)
+#   y registra el evento tipo:evaluacion en evoluciones.jsonl
+```
+
+Es el ÚNICO archivo que este comando crea. Luego generar el siguiente
+reporte directamente en la conversación:
 
 ```markdown
 ## Evaluación de skill: [nombre]
@@ -498,7 +511,9 @@ Score evals: 82.4/100 (peso 30% del final)
 - Los evals NUNCA se inventan en este comando — solo se ejecutan los declarados por el autor del skill. Crear evals nuevos es tarea de `/swl:aprender` o del autor del skill directamente, siguiendo `plantillas/skill-evals-template.json`.
 - Si el archivo no existe, informar al usuario con el path exacto y terminar.
 - Si `--agente` se pasa sin nombre, listar los agentes disponibles y terminar.
-- El reporte siempre se emite en la conversación. No crear archivos.
+- El reporte siempre se emite en la conversación. El único archivo que se
+  crea es el artefacto de procedencia del Paso 4 (`.planning/evolution/
+  evaluaciones/<nombre>.json`) — nunca reportes sueltos.
 - Las "Fortalezas" deben ser específicas del contenido leído, no genéricas.
 - Las "Áreas de mejora" deben incluir la sección o línea aproximada donde se detectó el problema.
 - Si la Capa 1 genera errores E001–E010, reflejar el impacto en el score de la dimensión afectada antes de sumar las contribuciones ponderadas.

package/comandos/swl/evolucion-continua.md

@@ -0,0 +1,73 @@
+---
+name: swl:evolucion-continua
+description: Enciende, apaga o consulta el motor determinista de aprendizaje del ciclo autónomo (ADR-0041). Con on, el proyecto aprende solo — decay y promoción de instintos, drenaje de feedback al perfil, puente de degradación e higiene de nudges — vía cron nocturno o fallback de session-briefing (cada ≥24h). Subcomandos on | off | status. Nace encendido (opt-out): off/SWL_CICLO_AUTONOMO=0 son el kill-switch sagrado.
+allowed_tools: ["Bash", "Read"]
+---
+
+# /swl:evolucion-continua — Motor determinista de aprendizaje (on|off|status)
+
+Eres el operador del motor determinista del ciclo autónomo (Nivel 0,
+ADR-0041). Este comando es la cara de usuario del subcomando CLI
+`swl-ses ciclo-autonomo`: NO implementa lógica propia — delega en el CLI
+(invocación cross-scope, regla `validar.js §7b`).
+
+## Qué hace el motor cuando está encendido
+
+Cada corrida de la Fase A (Node puro, sin LLM, <2s, $0):
+
+1. **Writer de instintos** — aplica decay, promueve drafts maduros
+   (confidence ≥0.5 + evidencia ≥3), degrada por feedback dañino y archiva
+   instintos muertos en `instintos/proyecto.yaml` (con backup previo).
+2. **Puente de degradación** — un aprendizaje `[DEGRADADO]` en
+   APRENDIZAJES.md baja la confidence del instinto derivado.
+3. **Drenador de feedback** — consolida las señales de
+   `evolution/feedback-queue.jsonl` (≤90 días) como drafts en
+   `instintos/perfil-usuario.yaml`; lo más viejo se archiva sin procesar.
+4. **Higiene de nudges** — marca atendidos los que el ciclo consume y
+   archiva los >90 días sin accionar.
+
+Todo queda registrado en `evolution/ciclo-autonomo.jsonl` con
+`origen: ciclo-autonomo`. Corridas sin señales son no-op sin escrituras.
+
+## Uso
+
+```
+/swl:evolucion-continua on      # habilita el motor en este proyecto
+/swl:evolucion-continua off     # lo apaga (kill-switch)
+/swl:evolucion-continua status  # last_run + conteos de la última corrida
+```
+
+## Ejecución
+
+Resuelve el CLI con el patrón cross-scope (repo madre → bin en PATH → npx):
+
+```bash
+# on | off | status según el argumento recibido
+swl-ses ciclo-autonomo <accion>
+```
+
+Sin binario en PATH: `npx -y @saulwade/swl-ses@latest ciclo-autonomo <accion>`.
+
+Tras `on`, informa al usuario los dos disparadores disponibles:
+
+1. **Cron del gateway** (si usa `/swl:cron`): job de ejemplo en
+   `gateway/cron/jobs.example.json` (nocturno, `0 3 * * *`).
+2. **Fallback automático de session-briefing**: sin cron, la Fase A se
+   dispara sola al iniciar sesión cuando pasaron ≥24h de la última corrida
+   (fire-and-forget; el lock evita corridas dobles).
+
+Una corrida manual siempre es posible: `swl-ses ciclo-autonomo`.
+
+## Reglas de comportamiento
+
+- El motor **nace ENCENDIDO** (opt-out estricto, decisión del usuario
+  2026-07-10): en proyectos sin señales la corrida es no-op inofensiva.
+  `off` y `SWL_CICLO_AUTONOMO=0` (docs/variables-entorno.md) son el
+  kill-switch — el off es sagrado: cero corridas, cero escrituras.
+- Este comando NO corre la Fase B con LLM (Fases 22+ del ADR-0042) — el
+  campo `credencial` del config existe pero aquí no se consume.
+- Si `status` reporta corridas con `errores`, sugiere revisar
+  `evolution/ciclo-autonomo.jsonl` y los backups en `instintos/.backups/`.
+- La primera corrida sobre un proyecto con señales acumuladas puede mover
+  mucho (bootstrap con ventana de 90 días): recomienda revisar el diff de
+  `instintos/*.yaml` antes de commitear.

package/comandos/swl/evolucionar.md

@@ -244,6 +244,19 @@ Versión: [anterior] → [nueva]
 Próxima evolución recomendada: después de [N] proyectos o [fecha]
 ```
 
+### Cierre del ciclo de nudges (obligatorio si este comando fue disparado por un nudge)
+
+Si esta evolución atendió un nudge de `etapa-auto-evolucion.js` / drift
+(visible en el briefing o en `evolution/nudges.jsonl`), márcalo como
+accionado — es lo que permite al sistema distinguir sugerencias atendidas
+de ruido acumulado:
+
+```bash
+swl-ses nudge-accionar <id-del-nudge> --por evolucionar
+```
+
+Si la evolución fue manual (sin nudge), omite este cierre.
+
 ## Reglas de comportamiento
 
 - NUNCA apliques cambios sin evidencia concreta. "Parece que sería mejor" no es evidencia.

package/comandos/swl/instalar.md

@@ -121,7 +121,7 @@ Espera confirmación explícita del usuario.
 ## Paso 5 — Ejecutar init
 
 ```bash
-npx @saulwade/swl-ses@latest init
+npx -y @saulwade/swl-ses@latest init
 ```
 
 Esto crea:
@@ -136,7 +136,7 @@ Si reporta archivos omitidos (ya existen), eso es normal.
 Construye el comando según las respuestas del usuario:
 
 ```bash
-npx @saulwade/swl-ses@latest install --target claude --profile <PERFIL> [--global] [--force]
+npx -y @saulwade/swl-ses@latest install --target claude --profile <PERFIL> [--global] [--force]
 ```
 
 - `<PERFIL>`: el perfil que eligió el usuario
@@ -155,7 +155,7 @@ Este paso:
 ## Paso 7 — Ejecutar doctor
 
 ```bash
-npx @saulwade/swl-ses@latest doctor
+npx -y @saulwade/swl-ses@latest doctor
 ```
 
 Verifica que todo quedó correctamente instalado:
@@ -217,4 +217,4 @@ Solo pregunta lo que NO se especificó en los argumentos.
 - Si el usuario no tiene el registry configurado, NO intentes instalar — solo guíalo.
 - Si el usuario pide un perfil que no existe, muestra la tabla de perfiles disponibles.
 - Este comando NO modifica código del proyecto — solo instala componentes SWL en `.claude/` y `.planning/`.
-- Para actualización: `npx @saulwade/swl-ses@latest update` detecta automáticamente el perfil instalado y actualiza sin preguntar perfil.
+- Para actualización: `npx -y @saulwade/swl-ses@latest update` detecta automáticamente el perfil instalado y actualiza sin preguntar perfil.

package/comandos/swl/notificaciones.md

@@ -51,7 +51,7 @@ o quiere reconfigurar.
 **Modo headless** (sin TTY):
 ```bash
 # Usar el instalador directamente con flag
-npx @saulwade/swl-ses@latest install --with-notificaciones=<TOKEN>,<CHAT_ID>
+npx -y @saulwade/swl-ses@latest install --with-notificaciones=<TOKEN>,<CHAT_ID>
 ```
 
 **Criterio de éxito**: al terminar, el hook `notificacion-telegram.js` está

package/comandos/swl/status.md

@@ -17,7 +17,7 @@ funcionalidad ni de flags.
 /swl:status salud                  — Diagnóstico de salud del sistema SWL (genera SALUD.md)
 /swl:status metricas               — Métricas de la sesión actual (tokens, costo, herramientas)
 /swl:status metricas detalle       — Desglose completo por herramienta, agente y timeline
-/swl:status metricas fases         — Progreso de fases del proyecto (desde feature-list.json)
+/swl:status metricas fases         — Progreso de fases del proyecto (desde feature-list.json)
 /swl:status valor                  — Evidencia de valor del harness en ESTE proyecto (intercepciones, defectos/escapes, DORA/CI, uso — con procedencia por métrica)
 /swl:status loops                  — Trayectorias de loops iterativos (.planning/loops/)
 /swl:status evolucion              — Estado del ciclo de auto-evolución (health_score, nudges…)
@@ -45,7 +45,7 @@ como vista por defecto si el contexto lo sugiere.
 | `metricas` (+ `detalle`, `fases`) | scripts de métricas de sesión + `derivar-feature-list.js` | `/swl:metricas` |
 | `loops` | `hooks/lib/loop-telemetry.js` | `/swl:metricas loops` |
 | `evolucion` | `hooks/ciclo-evolucion.js` (etapa métricas) + `.planning/evolution/metricas.json` | `/swl:evolucion-estado` |
-| `dora` | `scripts/lib/metricas-dora.js` + `.planning/evolution/metricas-dora.json` | nuevo (Fase 15, ADR-0039) |
+| `dora` | `scripts/lib/metricas-dora.js` + `.planning/evolution/metricas-dora.json` | nuevo (Fase 15, ADR-0039) |
 | `valor` | CLI cross-scope `swl-ses valor` (`scripts/evidencia-valor.js`) — datos 100% locales; frontera y reglas anti-gaming en `docs/evidencia-valor.md` | nuevo (v2.5.1) |
 | `historico` / `dashboard` | `Skill("swl-dashboard")` | `/swl:dashboard` |
 

package/gateway/cron/jobs.example.json

@@ -0,0 +1,12 @@
+{
+  "_comentario": "Plantilla de referencia — NO se carga automáticamente por el scheduler. Crear el job real con `/swl:cron add` o `store.addJob(cwd, {...})` (ver comandos/swl/cron.md). Campos que store.addJob acepta: name, schedule, command, deliver (opcional, default 'local'), enabled (opcional, default true).",
+  "jobs": [
+    {
+      "name": "Ciclo autónomo nocturno",
+      "schedule": "0 3 * * *",
+      "command": "npx -y @saulwade/swl-ses@latest ciclo-autonomo",
+      "deliver": "local",
+      "descripcion": "Fase A del motor determinista de aprendizaje (ADR-0041); requiere /swl:evolucion-continua on"
+    }
+  ]
+}

package/habilidades/auto-evolucion-protocolo/SKILL.md

@@ -4,7 +4,7 @@ description: >
   Protocolo de auto-evolución del sistema SWL. Cómo los agentes aprenden y se mejoran,
   proponen cambios, versionado semántico de agentes, changelog, métricas de evolución,
   governance de cambios, parser de señales de fricción y safety checks.
-version: "1.1.1"
+version: "1.1.2"
 herramientasPermitidas: [Read, Bash, Grep]
 evolvable: false  # bloqueado por lista (skill de seguridad/privacidad)
 exclusiones:
@@ -148,6 +148,24 @@ Todo agente que proponga modificar un artefacto del sistema DEBE verificar:
 4. **Reversibilidad**: Todo cambio tiene un plan de rollback documentado
 5. **No contradicciones**: El cambio no contradice otros skills o reglas
 
+### Default de features autónomas: opt-out con kill-switch sagrado, no opt-in
+
+[Decisión validada 2026-07-10, motor determinista Fase 21/ADR-0041] Un ciclo
+autónomo que exige encendido explícito es un ciclo muerto en downstream —
+nadie lo opera. El diseño correcto es **nacer encendido** SOLO si se cumplen
+las 4 precondiciones que lo hacen inofensivo:
+
+1. **No-op sin señales**: en un proyecto sin datos, la corrida no escribe nada.
+2. **Backup pre-mutación**: toda escritura sobre memoria/estado tiene respaldo previo.
+3. **Kill-switch doble y sagrado**: config persistente (`off`) + variable por
+   sesión (`=0`); apagado = cero corridas, cero escrituras, sin excepción.
+4. **Visibilidad**: cada corrida deja digest/telemetría que el usuario ve sin pedirla.
+
+Sin las 4, el default sigue siendo opt-in. La autonomía de MUTACIÓN (cambiar
+skills/agentes) queda además detrás de sus propios gates (checklist
+humano-validado, canary con quórum) — el default-on aplica al ciclo
+determinista, no a la aplicación de cambios.
+
 ---
 
 ## Formato de Commit Evolutivo

package/habilidades/autoresearch/SKILL.md

@@ -87,10 +87,11 @@ Ejecutar el skill con un **caso de prueba representativo** y evaluar:
 score = Σ(items_cumplidos × peso) / Σ(todos_pesos) × 100
 ```
 
-Usar el script de scoring para cálculo determinista:
+Usar el script de scoring para cálculo determinista (viaja DENTRO de este
+skill — invocarlo con la ruta del directorio del skill, no relativa al cwd):
 
 ```bash
-node scripts/calcular-score.js '{"items":[{"peso":5,"cumple":true},{"peso":3,"cumple":false}]}'
+node "<dir-de-este-skill>/scripts/calcular-score.js" '{"items":[{"peso":5,"cumple":true},{"peso":3,"cumple":false}]}'
 ```
 
 **Formato de reporte baseline:**

package/habilidades/backend-async-postgres-testing/SKILL.md

@@ -10,7 +10,7 @@ description: >
   `async with conn.transaction():`, cuando un test "deba pasar" pero falla
   con `TypeError: object MagicMock is not async iterable`, o cuando se
   agregue transaction wrapping a un service que tenía tests previos rotos.
-version: "1.0.0"
+version: "1.0.1"
 herramientasPermitidas: [Read, Grep]
 exclusiones:
   - "No cargar para testing de SQLAlchemy async (AsyncSession) — esos usan `async with session.begin()` con un patrón distinto; cargar `fastapi-experto` que cubre el patrón con sessionmaker."
@@ -205,6 +205,7 @@ Si el código olvida envolver en transaction, `conn.transaction.assert_called_on
 - **`fetchrow.side_effect = [row, row]` se agota tras 2 llamadas**: en la 3ra llamada lanza `StopIteration`. Si el código real hace 3 fetchrows en distintas ramas, el test falla con error críptico. Fix: usar lista con suficientes elementos o `side_effect` callable que retorna según args (`lambda *args: row if args[0] == "SELECT..." else None`).
 - **`MagicMock` (no `AsyncMock`) en `conn.transaction` permite `assert_called_with(*args)` natural** — `AsyncMock` también lo soporta, pero produce warnings de "coroutine never awaited" si el mock se invoca incorrectamente. La distinción importa para diagnóstico, no para corrección.
 - **`pytest-asyncio` con `mode="auto"` puede no marcar el test como async si no detecta `async def`**: si el fixture es async pero el test es sync, el fixture nunca se await. Fix: explícito `@pytest.mark.asyncio` en el test, o usar `asyncio_mode = "auto"` en `pyproject.toml` y verificar que el test es `async def`.
+- **Un test que simula transacciones concurrentes abriendo un `asyncpg.connect()` NUEVO (no el mock ni la conexión de la fixture) contra una BD con RLS DENY-by-default (`FORCE ROW LEVEL SECURITY`) ve CERO filas silenciosamente si esa conexión no setea `app.tenant_id`** [CONFIRMADO]: el GUC de tenant NUNCA se hereda entre conexiones distintas — ni siquiera si la conexión que sembró los datos ya seteó `app.tenant_id` y sigue abierta en otra variable. Este patrón aparece en tests de integración E2E (no en los mocks de este skill) que abren 2+ `asyncpg.connect()` para simular procesos concurrentes reales (ej. probar un `SELECT ... FOR SHARE`/TOCTOU). El síntoma es engañoso: no hay excepción de permisos, la query simplemente devuelve `None`/lista vacía, y el código que asume una fila (`row["estatus"]`) revienta con `TypeError: 'NoneType' object is not subscriptable` — fácil de confundir con un bug de lógica. Solo se manifiesta contra un rol que SÍ enforcea RLS (ej. el rol de aplicación en CI); un rol superusuario (usado en desarrollo local) bypasea RLS y el test pasa igual, ocultando el bug hasta CI. Fix: en CADA conexión nueva que abra el test (no solo la primera), `await conn.execute("SELECT set_config('app.tenant_id', $1, false)", str(tenant_id))` antes de cualquier query sobre una tabla con RLS.
 
 ## Referencias
 

package/habilidades/benchmark-memoria/SKILL.md

@@ -71,7 +71,7 @@ significativas**.
 QUERY="qué hicimos sobre force push a main protegida"
 
 # 2. Ejecuta búsqueda y anota top-5 IDs
-node -e "console.log(require('./hooks/lib/memory-search').search('.', '$QUERY').slice(0, 5).map(r => r.id + ' / ' + r.titulo).join('\n'))"
+swl-ses memoria-search search --query="$QUERY" --limit=5
 
 # 3. Verifica manualmente qué IDs son CORRECTOS (revisión humana,
 #    no se inventa). Solo esos van en gold_ids.
@@ -93,7 +93,7 @@ benchmark es gate de release.
 
 ```bash
 # Ejecutar benchmark con dataset por defecto
-node scripts/benchmark-memoria.js
+swl-ses benchmark-memoria
 
 # Output esperado:
 #   Recall @ 5:     85.0%
@@ -107,16 +107,16 @@ node scripts/benchmark-memoria.js
 
 ```bash
 # Dataset alternativo
-node scripts/benchmark-memoria.js --dataset .planning/benchmark/custom.jsonl
+swl-ses benchmark-memoria --dataset=.planning/benchmark/custom.jsonl
 
 # Top-k personalizado (default 20)
-node scripts/benchmark-memoria.js --limit 30
+swl-ses benchmark-memoria --limit=30
 
 # Output JSON (para scripts)
-node scripts/benchmark-memoria.js --json
+swl-ses benchmark-memoria --json
 
 # Detalle por query (útil para debugging)
-node scripts/benchmark-memoria.js --verbose
+swl-ses benchmark-memoria --verbose
 ```
 
 ### Tracking histórico opcional
@@ -126,7 +126,7 @@ agregado a `.planning/evolution/benchmark-memoria.jsonl` (append-only)
 para detectar regresión entre releases:
 
 ```bash
-SWL_BENCHMARK_PERSIST=1 node scripts/benchmark-memoria.js
+SWL_BENCHMARK_PERSIST=1 swl-ses benchmark-memoria
 ```
 
 Comparar entre releases: