@saulwade/swl-ses 2.6.0 → 2.8.0

package/habilidades/proceso-dynamic-workflows/recursos/template-triage.js

@@ -1,65 +1,65 @@
-// PLANTILLA (no ejecutar verbatim) — Workflow tool de Claude Code.
-// Patrón: classify-and-act + quarantine. Clasifica ítems de un backlog, dedupe contra lo
-// ya trackeado, y rutea: fix automático (bajo riesgo) vs escalar a humano (alto riesgo).
-// Quarantine: el agente que LEE contenido no confiable NO ejecuta acciones de alto privilegio.
-//
-// `args` = lista de ítems del backlog (issues, reportes, etc.). Adapta schemas y umbrales.
-
-export const meta = {
-  name: 'triage',
-  description: 'Clasifica un backlog, dedupe contra lo trackeado y rutea fix-vs-escalar (con quarantine)',
-  phases: [{ title: 'Clasificar' }, { title: 'Actuar' }],
-}
-
-const items = Array.isArray(args) ? args : []
-
-const CLASIFICACION = {
-  type: 'object', additionalProperties: false,
-  properties: {
-    categoria: { type: 'string', enum: ['bug', 'feature', 'duplicado', 'ruido'] },
-    yaTrackeado: { type: 'boolean' },
-    riesgo: { type: 'string', enum: ['bajo', 'alto'] },
-    resumen: { type: 'string' },
-  },
-  required: ['categoria', 'yaTrackeado', 'riesgo', 'resumen'],
-}
-
-const ACCION = {
-  type: 'object', additionalProperties: false,
-  properties: {
-    accion: { type: 'string', enum: ['fix-aplicado', 'escalado-humano', 'descartado'] },
-    detalle: { type: 'string' },
-  },
-  required: ['accion', 'detalle'],
-}
-
-// Stage 1 (quarantine): clasificador LEE el ítem (posible contenido no confiable) pero NO
-// tiene permiso de actuar — solo emite estructura. Stage 2 actúa sobre data ya saneada.
-const triaged = await pipeline(
-  items,
-  (item) =>
-    agent(
-      `Clasifica este ítem del backlog. NO ejecutes ninguna acción: solo describe. ` +
-      `Marca yaTrackeado=true si ya existe ticket. Ítem: ${JSON.stringify(item)}`,
-      { label: 'clasificar', phase: 'Clasificar', schema: CLASIFICACION }
-    ),
-  (clf, item) => {
-    if (!clf || clf.yaTrackeado || clf.categoria === 'ruido' || clf.categoria === 'duplicado') {
-      return { accion: 'descartado', detalle: clf?.resumen || 'sin señal' }
-    }
-    if (clf.riesgo === 'alto') {
-      // Alto riesgo: escalar a humano, no auto-actuar.
-      return agent(
-        `Redacta un escalamiento conciso para humano sobre: ${clf.resumen}`,
-        { label: 'escalar', phase: 'Actuar', schema: ACCION }
-      )
-    }
-    // Bajo riesgo: el agente que ACTÚA es distinto del que leyó contenido no confiable.
-    return agent(
-      `Aplica el fix de bajo riesgo para: ${clf.resumen}. Devuelve qué hiciste.`,
-      { label: 'fix', phase: 'Actuar', schema: ACCION }
-    )
-  }
-)
-
-return triaged.filter(Boolean)
+// PLANTILLA (no ejecutar verbatim) — Workflow tool de Claude Code.
+// Patrón: classify-and-act + quarantine. Clasifica ítems de un backlog, dedupe contra lo
+// ya trackeado, y rutea: fix automático (bajo riesgo) vs escalar a humano (alto riesgo).
+// Quarantine: el agente que LEE contenido no confiable NO ejecuta acciones de alto privilegio.
+//
+// `args` = lista de ítems del backlog (issues, reportes, etc.). Adapta schemas y umbrales.
+
+export const meta = {
+  name: 'triage',
+  description: 'Clasifica un backlog, dedupe contra lo trackeado y rutea fix-vs-escalar (con quarantine)',
+  phases: [{ title: 'Clasificar' }, { title: 'Actuar' }],
+}
+
+const items = Array.isArray(args) ? args : []
+
+const CLASIFICACION = {
+  type: 'object', additionalProperties: false,
+  properties: {
+    categoria: { type: 'string', enum: ['bug', 'feature', 'duplicado', 'ruido'] },
+    yaTrackeado: { type: 'boolean' },
+    riesgo: { type: 'string', enum: ['bajo', 'alto'] },
+    resumen: { type: 'string' },
+  },
+  required: ['categoria', 'yaTrackeado', 'riesgo', 'resumen'],
+}
+
+const ACCION = {
+  type: 'object', additionalProperties: false,
+  properties: {
+    accion: { type: 'string', enum: ['fix-aplicado', 'escalado-humano', 'descartado'] },
+    detalle: { type: 'string' },
+  },
+  required: ['accion', 'detalle'],
+}
+
+// Stage 1 (quarantine): clasificador LEE el ítem (posible contenido no confiable) pero NO
+// tiene permiso de actuar — solo emite estructura. Stage 2 actúa sobre data ya saneada.
+const triaged = await pipeline(
+  items,
+  (item) =>
+    agent(
+      `Clasifica este ítem del backlog. NO ejecutes ninguna acción: solo describe. ` +
+      `Marca yaTrackeado=true si ya existe ticket. Ítem: ${JSON.stringify(item)}`,
+      { label: 'clasificar', phase: 'Clasificar', schema: CLASIFICACION }
+    ),
+  (clf, item) => {
+    if (!clf || clf.yaTrackeado || clf.categoria === 'ruido' || clf.categoria === 'duplicado') {
+      return { accion: 'descartado', detalle: clf?.resumen || 'sin señal' }
+    }
+    if (clf.riesgo === 'alto') {
+      // Alto riesgo: escalar a humano, no auto-actuar.
+      return agent(
+        `Redacta un escalamiento conciso para humano sobre: ${clf.resumen}`,
+        { label: 'escalar', phase: 'Actuar', schema: ACCION }
+      )
+    }
+    // Bajo riesgo: el agente que ACTÚA es distinto del que leyó contenido no confiable.
+    return agent(
+      `Aplica el fix de bajo riesgo para: ${clf.resumen}. Devuelve qué hiciste.`,
+      { label: 'fix', phase: 'Actuar', schema: ACCION }
+    )
+  }
+)
+
+return triaged.filter(Boolean)

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).