@saulwade/swl-ses 2.4.3 → 2.5.1

package/habilidades/proceso-ingenieria-requerimientos/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: proceso-ingenieria-requerimientos
+description: >
+  Checklist de calidad de requerimientos basado en ingeniería de
+  requerimientos clásica (investigación académica del autor, 2003; refs
+  ZAVE94 y RE'01): las 8 características del buen requerimiento (correcto,
+  necesario, conciso, libre de implementación, factible, priorizable, no
+  ambiguo, verificable), la heurística "una verificación = un requerimiento",
+  la metadata de soporte por REQ (IDUR, padre, fuente, razón, riesgo, estado)
+  y la jerarquía de verificación (inspección < demostración < prueba).
+  Cargar al congelar REQs en /swl:discutir-fase (Bloque 5), al redactar
+  criterios de aceptación en un PRD (producto-prd-swl), o al auditar la
+  calidad de un CONTEXTO.md/REQUISITOS.md existente.
+version: "1.0.0"
+herramientasPermitidas: [Read]
+evolvable: true
+exclusiones:
+  - "No cargar para descomponer REQs en tareas — eso es planificador-swl con el REQ ya congelado."
+  - "No cargar para verificar la CADENA REQ→tarea→commit→test — eso es el gate G4 de /swl:verificar; este skill mejora la calidad del REQ ANTES de que exista la cadena."
+  - "No cargar para decisiones de arquitectura — un ADR documenta el CÓMO se decide; este skill vigila que el REQ diga el QUÉ sin contaminarse de cómo."
+---
+# Ingeniería de requerimientos — checklist de calidad por REQ
+
+Un requerimiento mal escrito se propaga: el plan lo descompone mal, el test
+lo verifica mal y el gate G4 valida una cadena correcta sobre un contenido
+incorrecto. Este skill se aplica a **cada REQ individual antes de congelarlo**
+(cierre de `discutir-fase`, redacción de PRD), no a la cadena posterior.
+
+> La IR "funciona como el puente entre la necesidad que tienen los usuarios
+> del mundo real [...] y las capacidades y oportunidades que brinda la
+> tecnología" (RE'01). El REQ es ese puente: si el puente está torcido, todo
+> lo que cruza llega torcido.
+
+## Cuándo cargar
+
+- Al cerrar el **Bloque 5** de `discutir-fase` (criterios de aceptación),
+  antes de escribir los `REQ-<fase>-NN` al CONTEXTO.md.
+- Al redactar criterios de aceptación e historias en un PRD.
+- Al auditar un CONTEXTO.md o REQUISITOS.md existente (¿por qué esta fase
+  divergió? — a menudo el REQ era ambiguo desde el origen).
+
+## Las 8 características — checklist con prueba operativa
+
+Aplicar a CADA requerimiento. Un REQ que falla una característica se
+reescribe antes de congelar, no después de implementar.
+
+| # | Característica | Prueba operativa |
+|---|---|---|
+| 1 | **Correcto** | Solo el usuario (o su sustituto cercano) determina si es correcto — validarlo con él en la entrevista. "Probablemente es lo que querían" = adivinar, no elicitar. |
+| 2 | **Necesario** | Rastrear a una fuente con autoridad (petición del usuario, REQ padre, estándar, regulación). Prueba: *¿si lo elimino, qué necesidad queda sin resolver?* Sin respuesta = *gold plating* — fuera. |
+| 3 | **Conciso** | Dice QUÉ debe hacerse y solo eso. Explicaciones, racional y análisis van en la metadata `Razón`, no en el enunciado. |
+| 4 | **Libre de implementación** | Dice qué, no cómo. Regla de cascada: *"el diseño de un nivel es el requerimiento del nivel inferior"* — la solución elegida (ADR) genera los REQs del siguiente nivel, sin fijar el diseño de ese nivel. Excepción legítima: requerimientos de interface. |
+| 5 | **Factible** | Chequeo de realidad técnica y de costo contra el sistema y su ambiente conocidos. Valores numéricos sospechosos se retan con física/límites del stack (el radar no ve más allá del horizonte). `/swl:predecir --abogado-diablo` es el retador formal. |
+| 6 | **Priorizable** | Prioridad asignada = f(valor al cliente, costo relativo, riesgo técnico). Si todo es igual de importante, no se puede reaccionar a recortes ni imprevistos. |
+| 7 | **No ambiguo** | Todos los lectores llegan a UNA interpretación. Palabras prohibidas en el enunciado: *fácil, simple, rápido, eficiente, varios, mejorado, robusto, flexible, amigable, maximizar, minimizar, soportar*. Cada una se reemplaza por un valor medible o se elimina. |
+| 8 | **Verificable** | Enunciado en términos mensurables con tolerancias ("105 ± 0.5", "p95 < N ms", "0 hallazgos CRÍTICOS"). Un REQ no verificable convierte la aceptación en cuestión de opinión. No consistente/no factible/ambiguo ⇒ no verificable. |
+
+## Heurística de concisión: una verificación = un requerimiento
+
+¿La alarma visual y la audible son uno o dos REQs? **Se decide por cómo se
+verificará**: si una sola prueba/demostración las verifica juntas, son UN
+requerimiento; si exigen verificaciones separadas, son DOS. Ni párrafos con
+múltiples REQs escondidos, ni multiplicar REQs sin razón — cada REQ se
+administra y verifica, y eso cuesta.
+
+## Tipos técnicos (y su relación de verificación)
+
+- **Funcional** — cualitativo: qué hace ("detectar blancos"). Se verifica por
+  la SUMA de sus requerimientos de desempeño asociados.
+- **Desempeño** — cuantitativo y comprobable individualmente ("detectar 0.1 m²
+  a >20 km con Pd ≥ 0.9"). Usualmente varios por cada funcional.
+- **Restricción de diseño** — límites bajo los que debe existir (peso, tamaño,
+  ambiente, stack impuesto).
+- **Interface** — cómo interactúa con sistemas externos o entre subsistemas;
+  la excepción documentada a "libre de implementación".
+
+## Metadata de soporte por REQ
+
+El REQ es un objeto de primera clase con metadata, no una línea suelta:
+
+| Atributo | En swl-ses | Regla |
+|---|---|---|
+| **IDUR** | `REQ-<fase>-NN` (namespaceado) | Único, jamás reutilizado |
+| **Padre** | `padre: REQ-<fase>-MM` (opcional) | Para REQs derivados de uno de nivel superior — da trazabilidad vertical |
+| **Fuente** | quién/qué lo pidió (usuario en entrevista, PRD §, estándar, regla) | Sin fuente identificable → aplica prueba de "necesario" |
+| **Razón** | 1 línea de racional o puntero (análisis, ADR, supuesto del Bloque 4) | Aquí vive lo que "conciso" echó del enunciado |
+| **Riesgo** | alto/medio/bajo + por qué | Alimenta la priorización del plan |
+| **Estado** | `PENDIENTE → definido → aprobado (gate G1) → verificado (gate G4) → borrado` | Mapa del ciclo PSD/PSR/Definido/Aprobado/Verificado/Borrado clásico; REQs `PENDIENTE` bloquean el cierre de la discusión |
+
+## Jerarquía de verificación (al declarar CÓMO se verificará cada REQ)
+
+**Inspección** (mirar/medir el artefacto) < **demostración** (observar la
+operación con instrumentación mínima — p. ej. medir MTTR reparando fallas
+inducidas) < **prueba** (instrumentada por completo — la más confiable y la
+más cara) — con **análisis** como soporte barato (modelos validados contra
+pruebas previas). Elegir el método MÁS BARATO que realmente verifique el
+REQ; declarar el método junto al criterio de aceptación.
+
+## Dos escalas de priorización (usar una, explícita)
+
+- **Alto / Medio / Bajo** — crítico de misión para la próxima liberación /
+  necesario eventualmente / mejora si los recursos lo permiten.
+- **Esencial / Condicional / Opcional** — el producto no es aceptable sin él /
+  mejora pero el producto es aceptable sin ella / puede o no valer la pena.
+- MoSCoW (del PRD) mapea: Must≈Esencial, Should/Could≈Condicional,
+  Won't≈fuera. Declarar QUÉ escala se usa; nunca mezclar dos en el mismo doc.
+
+## Por qué la elicitación falla (y qué hace el cuestionario al respecto)
+
+Restricciones clásicas que el entrevistador debe asumir como default:
+**conocimiento tácito** (la gente no sabe describir lo que hace — pedir
+ejemplos concretos, no definiciones), **distribución del conocimiento**
+(fuentes múltiples en conflicto — los conflictos se registran como decisiones
+del Bloque 4, no se resuelven en silencio), **observación limitada** y
+**parcialidad** (el resultado afecta al informante). Es la razón por la que
+`discutir-fase` pregunta supuestos explícitos y registra decisiones con
+estado en vez de asumir consenso.
+
+## Cuándo NO cargar
+
+- REQs ya congelados con plan aprobado (gate G1) — re-litigar el REQ ahí es
+  cambio de scope: pasa por re-planificación, no por este checklist.
+- Tareas técnicas triviales sin REQs formales (fix puntual, typo).
+- Verificación post-implementación — eso es `/swl:verificar` (G4).
+
+## Gotchas / Errores comunes no obvios
+
+- **Checklist aplicado al documento y no al requerimiento**: las 8
+  características se evalúan POR REQ individual; un CONTEXTO.md "en general
+  claro" puede contener 2 REQs ambiguos que revientan la fase.
+- **"Verificable" confundido con "tiene test"**: verificable es una propiedad
+  del ENUNCIADO (términos mensurables), previa al test. G4 valida que el test
+  exista; este skill valida que el enunciado sea testeable.
+- **Racional dentro del enunciado**: si el REQ explica por qué, mezcla dos
+  atributos — mover el porqué a `Razón` y dejar el enunciado conciso.
+- **Funcional "verificado" directamente**: un funcional sin desempeños
+  asociados se "verifica" con opinión. Todo funcional no trivial necesita al
+  menos un desempeño cuantitativo asociado.
+
+---
+
+**Origen**: investigación académica de Saúl Wade, *"Ingeniería de
+requerimientos"* (Wade Inc., ~2003; referencias [ZAVE94] y [RE'01 CfP]),
+absorbida al sistema el 2026-07-08 (v2.5.1). El documento fuente vive en
+`temp/` del repo madre (material de referencia, no distribuido); este skill
+es su destilado operativo con el mapeo a los mecanismos SWL (gates G1/G4,
+cuestionario de discutir-fase, MoSCoW del PRD).

package/hooks/check-update.js

@@ -205,9 +205,13 @@ process.stdin.on('end', async () => {
             notificado: 2,
           }), 'utf8');
         } catch { /* silencioso */ }
-        process.stderr.write(
+        // stdout, NO stderr: en Claude Code el stderr de un hook con exit 0 no
+        // se muestra a nadie (bug de visibilidad 2026-07-08 — el aviso llevaba
+        // meses emitiéndose a un canal invisible). El stdout de
+        // UserPromptSubmit/SessionStart sí llega como contexto visible.
+        process.stdout.write(
           '[swl-ses/check-update] lib npm-version no disponible — el aviso de ' +
-          'nuevas versiones está inactivo. Reinstala con: ' +
+          'nuevas versiones está inactivo. Informa al usuario que reinstale con: ' +
           'npx -y @saulwade/swl-ses@latest update\n'
         );
       }
@@ -223,9 +227,11 @@ process.stdin.on('end', async () => {
         // `undefined < 2` evalúa `false` por NaN comparison — usar fallback a 0.
         const notificadoActual = data.notificado || 0;
         if (data.hayNueva && notificadoActual < 2) {
-          process.stderr.write(
-            `[swl-ses] Versión ${data.remota} disponible (actual: ${data.local}). ` +
-            `Ejecuta: npx @saulwade/swl-ses@latest update\n`
+          // stdout (visible como contexto), no stderr (invisible con exit 0).
+          process.stdout.write(
+            `[swl-ses] Hay una versión nueva de swl-ses: ${data.remota} (instalada: ${data.local}). ` +
+            `INFORMA AL USUARIO al inicio de tu respuesta y sugiere actualizar con ` +
+            `\`npx @saulwade/swl-ses@latest update\` o \`/swl:actualizar\`.\n`
           );
           data.notificado = notificadoActual + 1;
           fs.writeFileSync(flagPath(), JSON.stringify(data), 'utf8');
@@ -251,14 +257,17 @@ process.stdin.on('end', async () => {
     registrarCheck(local, remota, hayNueva);
 
     if (hayNueva) {
+      // stdout (visible como contexto del turno / del arranque de sesión),
+      // no stderr (invisible con exit 0 — causa de que el aviso nunca se viera).
       const msg = [
         '',
-        `[swl-ses] Nueva versión disponible: ${remota} (actual: ${local})`,
-        `  Ejecuta: npx @saulwade/swl-ses@latest update`,
-        `  O desde Claude Code: /swl:actualizar`,
+        `[swl-ses] Nueva versión disponible: ${remota} (instalada: ${local}).`,
+        `INFORMA AL USUARIO al inicio de tu respuesta y sugiere actualizar con:`,
+        `  npx @saulwade/swl-ses@latest update`,
+        `  o desde el runtime: /swl:actualizar`,
         '',
       ].join('\n');
-      process.stderr.write(msg);
+      process.stdout.write(msg);
     } else if (process.env.SWL_FORCE_UPDATE_NOTIFICATION === '1') {
       // Modo debug: mostrar siempre el estado aunque local == remota.
       // Útil para el autor (cuya local nunca queda atrás) y para verificar
@@ -268,7 +277,7 @@ process.stdin.on('end', async () => {
       if (cmp === 0) estado = 'al día';
       else if (cmp > 0) estado = 'local adelantada (publicación pendiente)';
       else estado = 'comparación inconclusa';
-      process.stderr.write(
+      process.stdout.write(
         `[swl-ses/check-update] FORCE: local=${local}, remota=${remota}, ${estado}\n`
       );
     }

package/hooks/contexto-subagente.js

@@ -1,68 +1,68 @@
-#!/usr/bin/env node
-'use strict';
-
-/**
- * Hook: contexto-subagente.js
- * Tipo: SubagentStart (aplica a todos los subagentes Task/Agent)
- *
- * El contexto emitido por hooks de SessionStart es solo del hilo padre y
- * NUNCA llega a los subagentes: cada agente spawneado vía Task/Agent corre
- * sin las disciplinas activas de la sesión (patrón documentado en ponytail
- * issue #252 — mismo gap verificado en swl-ses el 2026-07-03: 0 usos de
- * SubagentStart hasta este hook).
- *
- * Re-inyecta a cada subagente un bloque compacto (~120 tokens) con las
- * disciplinas transversales no negociables: idioma es-MX, escalera de código
- * mínimo con guardas intocables, y la convención de marcador `simplificado:`.
- * Deliberadamente mínimo — el costo se paga en CADA spawn de subagente.
- *
- * Opt-out: SWL_CONTEXTO_SUBAGENTE=0 desactiva la inyección.
- * Formato de salida: SubagentStart requiere la forma JSON hookSpecificOutput
- * (stdout crudo se descarta en este evento — a diferencia de SessionStart).
- */
-
-/**
- * Construye el bloque de disciplinas que se inyecta al subagente.
- *
- * @returns {string} Contexto compacto en es-MX.
- */
-function construirContexto() {
-  return [
-    'DISCIPLINAS SWL ACTIVAS (heredadas de la sesión padre):',
-    '- Idioma: español de México en todo output (código, comentarios, commits, reportes).',
-    '- Código mínimo — escalera antes de escribir: ¿necesita existir (YAGNI)? →',
-    '  ¿ya existe en este codebase? → ¿stdlib? → ¿feature nativa de la plataforma? →',
-    '  ¿dependencia ya instalada? → ¿una línea? → solo entonces, el mínimo que funciona.',
-    '- Guardas intocables (nunca simplificar): validación en trust boundaries,',
-    '  manejo de errores que previene pérdida de datos, seguridad, accesibilidad.',
-    '- Simplificación deliberada se marca: `simplificado: <techo>, <trigger de upgrade>`.',
-    '- Bug fix = causa raíz: grep de todos los callers antes de parchar uno.',
-    'Detalle completo: Skill("prevencion-sobreingenieria").',
-  ].join('\n');
-}
-
-/**
- * Emite el contexto en el formato JSON que SubagentStart exige.
- * Nunca falla hacia afuera: un stdout roto no debe reportarse como hook error.
- */
-function main() {
-  if (process.env.SWL_CONTEXTO_SUBAGENTE === '0') return;
-  try {
-    process.stdout.write(JSON.stringify({
-      hookSpecificOutput: {
-        hookEventName: 'SubagentStart',
-        additionalContext: construirContexto(),
-      },
-    }));
-  } catch (_) {
-    // Silencioso — no interrumpir el spawn del subagente.
-  }
-}
-
-// Entrypoint directo o wrapper `node -e "require(...)"` (require.main undefined).
-// No consume stdin: emite y termina — sin listeners, el proceso sale solo.
-if (!require.main || require.main === module) {
-  main();
-}
-
-module.exports = { construirContexto };
+#!/usr/bin/env node
+'use strict';
+
+/**
+ * Hook: contexto-subagente.js
+ * Tipo: SubagentStart (aplica a todos los subagentes Task/Agent)
+ *
+ * El contexto emitido por hooks de SessionStart es solo del hilo padre y
+ * NUNCA llega a los subagentes: cada agente spawneado vía Task/Agent corre
+ * sin las disciplinas activas de la sesión (patrón documentado en ponytail
+ * issue #252 — mismo gap verificado en swl-ses el 2026-07-03: 0 usos de
+ * SubagentStart hasta este hook).
+ *
+ * Re-inyecta a cada subagente un bloque compacto (~120 tokens) con las
+ * disciplinas transversales no negociables: idioma es-MX, escalera de código
+ * mínimo con guardas intocables, y la convención de marcador `simplificado:`.
+ * Deliberadamente mínimo — el costo se paga en CADA spawn de subagente.
+ *
+ * Opt-out: SWL_CONTEXTO_SUBAGENTE=0 desactiva la inyección.
+ * Formato de salida: SubagentStart requiere la forma JSON hookSpecificOutput
+ * (stdout crudo se descarta en este evento — a diferencia de SessionStart).
+ */
+
+/**
+ * Construye el bloque de disciplinas que se inyecta al subagente.
+ *
+ * @returns {string} Contexto compacto en es-MX.
+ */
+function construirContexto() {
+  return [
+    'DISCIPLINAS SWL ACTIVAS (heredadas de la sesión padre):',
+    '- Idioma: español de México en todo output (código, comentarios, commits, reportes).',
+    '- Código mínimo — escalera antes de escribir: ¿necesita existir (YAGNI)? →',
+    '  ¿ya existe en este codebase? → ¿stdlib? → ¿feature nativa de la plataforma? →',
+    '  ¿dependencia ya instalada? → ¿una línea? → solo entonces, el mínimo que funciona.',
+    '- Guardas intocables (nunca simplificar): validación en trust boundaries,',
+    '  manejo de errores que previene pérdida de datos, seguridad, accesibilidad.',
+    '- Simplificación deliberada se marca: `simplificado: <techo>, <trigger de upgrade>`.',
+    '- Bug fix = causa raíz: grep de todos los callers antes de parchar uno.',
+    'Detalle completo: Skill("prevencion-sobreingenieria").',
+  ].join('\n');
+}
+
+/**
+ * Emite el contexto en el formato JSON que SubagentStart exige.
+ * Nunca falla hacia afuera: un stdout roto no debe reportarse como hook error.
+ */
+function main() {
+  if (process.env.SWL_CONTEXTO_SUBAGENTE === '0') return;
+  try {
+    process.stdout.write(JSON.stringify({
+      hookSpecificOutput: {
+        hookEventName: 'SubagentStart',
+        additionalContext: construirContexto(),
+      },
+    }));
+  } catch (_) {
+    // Silencioso — no interrumpir el spawn del subagente.
+  }
+}
+
+// Entrypoint directo o wrapper `node -e "require(...)"` (require.main undefined).
+// No consume stdin: emite y termina — sin listeners, el proceso sale solo.
+if (!require.main || require.main === module) {
+  main();
+}
+
+module.exports = { construirContexto };

package/hooks/degradacion-instintos.js

@@ -191,7 +191,7 @@ function aplicarDegradaciones(contradicciones) {
   try {
     const contenido = fs.readFileSync(RUTA_APRENDIZAJES, 'utf8');
     const lineas = contenido.split('\n');
-    const fecha = new Date().toISOString().slice(0, 10);
+    const fecha = new Date().toLocaleDateString('sv');
 
     for (const { indice, motivo } of contradicciones) {
       if (indice >= lineas.length) continue;

package/hooks/extraccion-aprendizajes.js

@@ -275,7 +275,7 @@ function normalizarFechas(texto, ahora = new Date()) {
       const diasOffset = calc(args);
       const fecha = new Date(ahora);
       fecha.setDate(fecha.getDate() + diasOffset);
-      return fecha.toISOString().slice(0, 10); // YYYY-MM-DD
+      return fecha.toLocaleDateString('sv'); // YYYY-MM-DD local (no UTC)
     });
   }
 
@@ -550,7 +550,7 @@ function escribirAprendizaje(aprendizaje, agente) {
     return;
   }
 
-  const fecha         = new Date().toISOString().slice(0, 10); // YYYY-MM-DD
+  const fecha         = new Date().toLocaleDateString('sv'); // YYYY-MM-DD local (no UTC)
   const contenidoBase = asegurarEncabezado(contenidoExistente);
 
   // Normalizar fechas relativas a absolutas (patrón autoDream)

package/hooks/lib/briefing.js

@@ -161,7 +161,7 @@ function deudaTriggerCumplido(baseDir, hoy = new Date()) {
     out.push(
       item(
         'deuda-trigger',
-        `${id}: trigger con fecha cumplida (${fecha.toISOString().slice(0, 10)})`,
+        `${id}: trigger con fecha cumplida (${fecha.toLocaleDateString('sv')})`,
         `Revisar .planning/DEUDA-TECNICA.md § ${id} y cerrar o re-planear`
       )
     );
@@ -185,7 +185,7 @@ function nudgesPendientes(baseDir /*, hoy */) {
     item(
       'nudges-pendientes',
       `${nudges.length} nudge(s) sin accionar (${detalle})`,
-      'Ejecutar /swl:evolucion-estado para revisarlos y accionar'
+      'Ejecutar /swl:status evolucion para revisarlos y accionar'
     ),
   ];
 }
@@ -338,7 +338,7 @@ function indicePrioridad(categoria) {
  *          null = silencio total (sin señales nuevas).
  */
 function armarDigest(items, estadoPrevio = {}, dia, opts = {}) {
-  const hoyStr = dia || new Date().toISOString().slice(0, 10);
+  const hoyStr = dia || new Date().toLocaleDateString('sv');
   const mismoDia = estadoPrevio && estadoPrevio.dia === hoyStr;
   const yaMostrados = mismoDia && Array.isArray(estadoPrevio.hashesPrevios)
     ? new Set(estadoPrevio.hashesPrevios)

package/hooks/lib/nudge-tracker.js

@@ -241,7 +241,7 @@ function escalarSiAplica(opts = {}) {
 }
 
 /**
- * Resumen de nudges para el comando /swl:evolucion-estado.
+ * Resumen de nudges para el comando /swl:status evolucion.
  *
  * @param {object} [opts]
  * @param {number} [opts.dias=14]

package/hooks/lib/otlp-exporter.js

@@ -80,7 +80,7 @@ function asegurarDirectorio(cwd) {
  * @returns {string}
  */
 function rutaHoy(cwd) {
-  const fecha = new Date().toISOString().slice(0, 10);
+  const fecha = new Date().toLocaleDateString('sv');
   return path.join(asegurarDirectorio(cwd), `${fecha}.jsonl`);
 }
 

package/hooks/lib/webhook-dedup.js

@@ -126,7 +126,7 @@ class WebhookDedup {
     }
 
     if (archivar.length > 0) {
-      const fechaArchivo = new Date(ahora).toISOString().slice(0, 10);
+      const fechaArchivo = new Date(ahora).toLocaleDateString('sv');
       const dirArchive = path.join(path.dirname(this.rutaLedger), 'webhook-events-archive');
       const archivoArchive = path.join(dirArchive, `events-${fechaArchivo}.jsonl`);
       fs.mkdirSync(dirArchive, { recursive: true });

package/hooks/session-briefing.js

@@ -59,7 +59,7 @@ process.stdin.on('end', () => {
     const hoy = new Date();
     const items = briefing.recolectarTodo(cwd, hoy);
     const estadoPrevio = briefing.leerEstadoBriefing(cwd);
-    const dia = hoy.toISOString().slice(0, 10);
+    const dia = hoy.toLocaleDateString('sv');
 
     // Telemetría de aceptación (D-18, REQ-12-05): se actualiza SIEMPRE que el
     // hook corre, comparando lo visto antes con lo presente ahora — independiente

package/llms.txt

@@ -1,6 +1,6 @@
 # swl-ses (@saulwade/swl-ses)
 
-> Sistema de ingeniería de software auto-evolutivo multi-runtime polyglot (SDLC completo), distribuido como paquete npm y plugin de Claude Code. 60 agentes, 182 habilidades, 45 comandos, 37 reglas base y 49 hooks. Soporta 11 lenguajes y 7 runtimes (Claude Code, OpenClaude, OpenCode, Gemini, Cursor, Codex, Copilot). Versión 2.3.1.
+> Sistema de ingeniería de software auto-evolutivo multi-runtime polyglot (SDLC completo), distribuido como paquete npm y plugin de Claude Code. 61 agentes, 181 habilidades, 47 comandos, 37 reglas base y 49 hooks. Soporta 11 lenguajes y 7 runtimes (Claude Code, OpenClaude, OpenCode, Gemini, Cursor, Codex, Copilot). Versión 2.5.1.
 
 Archivo generado por `node scripts/generar-inventario.js` — no editar a mano. Las cifras se sincronizan con INVENTARIO.md en cada regeneración.
 
@@ -16,11 +16,11 @@ Archivo generado por `node scripts/generar-inventario.js` — no editar a mano.
 
 ## Componentes
 
-- 60 agentes especializados en `agentes/` (orquestación, implementación por stack, revisión, calidad, diseño)
-- 182 habilidades cargables bajo demanda en `habilidades/` (conocimiento operacional con divulgación progresiva)
-- 45 comandos `/swl:*` en `comandos/swl/` (ciclo GSD, calidad, release, diagnóstico)
-- 37 reglas base + 40 reglas por lenguaje en `reglas/` (políticas obligatorias por matcher)
-- 49 hooks en `hooks/` (telemetría, validación, seguridad; zero-deps, escrituras atómicas)
+- [61 agentes especializados](AGENTS.md): orquestación, implementación por stack, revisión, calidad, diseño — fuente en `agentes/`
+- [181 habilidades cargables bajo demanda](INVENTARIO.md): conocimiento operacional con divulgación progresiva — fuente en `habilidades/`
+- [47 comandos /swl:*](COMANDOS.md): ciclo GSD, calidad, release, diagnóstico — fuente en `comandos/swl/`
+- [37 reglas base + 40 por lenguaje](INVENTARIO.md): políticas obligatorias por matcher — fuente en `reglas/`
+- [49 hooks](INVENTARIO.md): telemetría, validación, seguridad; zero-deps, escrituras atómicas — fuente en `hooks/`
 
 ## Opcional