@saulwade/swl-ses 2.5.3 → 2.6.1

package/habilidades/changelog-generator/SKILL.md

@@ -8,7 +8,7 @@ description: >
   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.0
+version: 1.1.1
 nivelRiesgo: BAJO
 herramientasPermitidas: [Read, Bash]
 skillsInvocables: [release-semver]

package/habilidades/changelog-generator/scripts/parse-commits.js

@@ -288,7 +288,8 @@ function generarChangelog(categorias, opts) {
   const { version, fecha, incluirHash = true } = opts || {};
   if (!version) throw new Error('generarChangelog: version es obligatoria');
 
-  const fechaUsada = fecha || new Date().toISOString().slice(0, 10);
+  // Fecha LOCAL, no UTC — desde México la tarde ya es "mañana" en toISOString() (clase C1)
+  const fechaUsada = fecha || new Date().toLocaleDateString('sv');
   const lineas = [`## [${version}] - ${fechaUsada}`, ''];
 
   for (const categoria of ORDEN_CATEGORIAS) {

package/habilidades/checkpoints-verificacion/SKILL.md

@@ -149,6 +149,12 @@ a partir de texto libre. Inspirado en el patrón ExecutionSnapshot de Sim Studio
 
 ### Al completar un agente
 
+Los bloques `javascript` de esta sección documentan la API de los módulos con
+el layout del repo madre (`hooks/lib/`); en instalaciones destino viven
+aplanados junto a los hooks instalados. Son referencia de la API, no comandos
+a ejecutar tal cual en proyectos consumidores (para lectura del estado existe
+`swl-ses execution-state`).
+
 ```javascript
 const es = require('./hooks/lib/execution-state');
 es.completarAgente(process.cwd(), 'implementador-swl', 'api-endpoints', {

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/context-builder/SKILL.md

@@ -107,6 +107,10 @@ El default de 2500 restaura el margen útil.
 
 ## Configuración
 
+API del módulo con el layout del repo madre (`hooks/lib/`); en instalaciones
+destino vive aplanado junto a los hooks instalados. Es referencia para ajustar
+el hook, no un comando a ejecutar en proyectos consumidores.
+
 ```js
 const { buildContext } = require('./hooks/lib/context-builder');
 

package/habilidades/doubt-driven-review/SKILL.md

@@ -9,7 +9,7 @@ description: >
   memoria (eso lo hace red-team-swl) ni de seguridad de código (eso lo hace
   revisor-seguridad-swl) — este skill se especializa en decisiones técnicas
   con costo de cambio alto.
-version: "1.1.0"
+version: "1.2.0"
 exclusiones:
   - "No cargar para revisión de memoria SWL (APRENDIZAJES.md, instintos/) — esa es responsabilidad de red-team-swl."
   - "No cargar para auditoría de seguridad de código (OWASP, CVEs, inyección) — usar revisor-seguridad-swl."
@@ -142,6 +142,22 @@ no en hipótesis falsable. Documentarla como tal en el reporte.
 - BAJO-EVIDENCIA — falla en pasos 2, 4 o 5; reabrir antes de comprometer
 ```
 
+## Patrón validado: dictamen adversarial convertido en gates de activación
+
+[Caso real 2026-07-10, ADR-0042] La forma de mayor valor del veredicto
+adversarial no es el veto sino la **conversión de cada condición del dictamen
+en un gate verificable del propio diseño**: el abogado del diablo (verificando
+contra el repo con archivo:línea, no opinando) produjo 3 pre-mortems plausibles
+(canary sin señal estadística, el-sistema-escribe-su-propio-examen, headless
+que compite con la sesión del usuario) y 7 condiciones; en lugar de rechazar
+el plan, las condiciones se integraron como gates de activación escalonados
+(G-B…G-E) con criterios observables y triggers de reversión. Resultado: la
+decisión del usuario se respeta, el riesgo queda contenido POR CONSTRUCCIÓN y
+el dictamen deja de ser un documento — se vuelve arquitectura. Requisitos del
+patrón: el crítico verifica afirmaciones contra el código real (no memoria),
+cada condición tiene verificación binaria, y los gates viven en el ADR con
+fecha de reevaluación.
+
 ## Anti-patrones del skill
 
 - **Auto-revisión**: el agente que tomó la decisión ejecuta el skill sobre sí mismo.

package/habilidades/drift-detection/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: drift-detection
-version: 1.0.0
+version: 1.0.1
 herramientasPermitidas: [Read]
 description: "Detección de drift de métricas de agentes/skills via ventana deslizante (7d) vs baseline (4 semanas). Integrado al operador Reflect del ciclo AGP."
 exclusiones:
@@ -38,6 +38,11 @@ Adaptado de `runDriftCheck`/`getDriftTimeline` en mission-control-main (MIT).
 
 ## Exports del módulo
 
+Los bloques `js` de este skill documentan la API con el layout del repo madre
+(`scripts/lib/`, `hooks/lib/`); en instalaciones destino los módulos viven
+aplanados junto a los hooks instalados. Referencia de API, no comandos a
+ejecutar tal cual en proyectos consumidores.
+
 ```js
 const { detectarDrift, generarLineaTemporal } = require('./scripts/lib/drift-detector');
 ```

package/habilidades/ejecutar-fase/SKILL.md

@@ -47,7 +47,7 @@ Antes de la primera tarea Y al inicio de cada slice, verificar que el PLAN no
 fue mutado tras su aprobación:
 
 ```bash
-node -e "const {verificarPlan}=require('./scripts/lib/plan-lock'); console.log(JSON.stringify(verificarPlan('.planning/fases/0N-PLAN.md')))"
+swl-ses verificar-plan --fase=0N
 ```
 
 - `modo: "firmado"` → continuar.
@@ -84,13 +84,13 @@ Tras commitear una tarea (y al cerrar la fase), evaluar las adyacencias de riesg
 del diff y anexar propuestas SOLO si hay señal. Propone, nunca bloquea ni ejecuta:
 
 ```bash
-node hooks/lib/propose-step.js --rango=HEAD~1..HEAD
+swl-ses propose-step --rango=HEAD~1..HEAD
 ```
 
 Si imprime un anexo, agregarlo al reporte de la tarea (y al RESUMEN.md al cerrar
 la fase). Si no imprime nada, silencio — no agregar sección vacía. Opt-out con
 `SWL_PROPOSE=0`. Antes de una acción autónoma de clase `cambio_reversible`,
-registrar el auto-checkpoint: `node hooks/lib/autonomia.js --accion "<acción>"`.
+registrar el auto-checkpoint: `swl-ses autonomia --accion="<acción>"`.
 Detalle en el fragmento `agentes/_propose-step.md`.
 
 ### Protocolo de retry con backoff exponencial
@@ -325,7 +325,7 @@ sigue el ciclo con evidencia.
 Al iniciar la primera tarea de código de la fase, abrir la corrida de evidencia:
 
 ```bash
-node -e "const lt=require('./hooks/lib/loop-telemetry');const r=lt.iniciarCorrida({tipo:'tdd',direccion:'lower_is_better',config:{fase:'0N',tarea:'T-NN'}});console.log(r.dir)"
+swl-ses loop-telemetry iniciar --tipo=tdd --direccion=lower_is_better --config='{"fase":"0N","tarea":"T-NN"}'
 ```
 
 **RED**: Escribir el test que describe el comportamiento esperado.
@@ -334,14 +334,14 @@ de sintaxis o configuración. **Registrar la evidencia** (métrica = tests falla
 descripción = fallo exacto):
 
 ```bash
-node -e "const lt=require('./hooks/lib/loop-telemetry');lt.registrarIteracion('<dir>',{iteracion:0,metrica:<N_fallan>,delta:0,estado:'baseline',descripcion:'RED T-NN: <fallo exacto del runner>'})"
+swl-ses loop-telemetry registrar --dir=<dir> --iteracion=0 --metrica=<N_fallan> --delta=0 --estado=baseline --descripcion="RED T-NN: <fallo exacto del runner>"
 ```
 
 **GREEN**: Escribir la implementación mínima que hace pasar el test.
 "Mínima" significa: no implementar más de lo que el test exige. Registrar:
 
 ```bash
-node -e "const lt=require('./hooks/lib/loop-telemetry');lt.registrarIteracion('<dir>',{iteracion:1,metrica:0,delta:-<N>,estado:'keep',descripcion:'GREEN T-NN: suite verde'})"
+swl-ses loop-telemetry registrar --dir=<dir> --iteracion=1 --metrica=0 --delta=-<N> --estado=keep --descripcion="GREEN T-NN: suite verde"
 ```
 
 **REFACTOR**: Limpiar el código sin cambiar el comportamiento.