@saulwade/swl-ses 2.6.0 → 2.6.1

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

@@ -1,147 +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).
+---
+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/habilidades/release-semver/SKILL.md

@@ -318,8 +318,8 @@ de token inválido.
 - `semantic-release` ya está configurado en CI — si el release está automatizado, el número de versión se calcula desde los commits sin intervención manual; cargar este skill duplicaría el trabajo.
 - El proyecto es una herramienta interna sin consumidores que dependan de compatibilidad de versión — SemVer completo compensa cuando hay consumidores que confían en los números de versión para evaluar breaking changes.
 
-## Gotchas / Errores comunes no obvios
-
+## Gotchas / Errores comunes no obvios
+
 - **El registry espejo NUNCA publica cuando el canónico falló sus gates** [caso real: v2.5.0 y v2.5.1 quedaron huérfanas en GitHub Packages, 2026-07-08/09]: un publisher dual que publica el mirror desde un directorio temporal preparado (donde `prepublishOnly`/gates NO corren) debe condicionar el paso 2 al éxito del paso 1 — si el canónico falló, el mirror se OMITE con aviso visible. Publicar tras el fallo sube un tarball sin validar y desalinea los registries: la misma versión no puede re-subirse, forzando un "republish de coordinación" (bump PATCH) que es puro costo. Verificar además que el flujo del mirror realmente corre gates en alguna parte — "los pre-publish ya pasaron en el intento 1" es una suposición, no una garantía.
 
 - **Tag ligero creado en lugar de anotado para el release**: `git tag v2.1.0` sin la flag `-a` crea un tag ligero que no incluye metadata de autor, fecha ni mensaje. Causa: olvidar la flag `-a` o la costumbre de usar tags ligeros para marcado temporal. Solución: siempre `git tag -a v2.1.0 -m "Release v2.1.0"` para releases — los tags anotados son los que `git describe` y las herramientas de changelog usan correctamente.