@saulwade/swl-ses 1.6.0 → 1.6.1

package/habilidades/state-inconsistency-auditor-swl/SKILL.md

@@ -1,166 +1,172 @@
----
-name: state-inconsistency-auditor-swl
-description: >
-  Encuentra bugs donde una operación muta un fragmento de estado acoplado sin
-  actualizar su contraparte dependiente, causando corrupción silenciosa o fallos
-  en operaciones posteriores. Mapea sistemáticamente pares de estado acoplado,
-  todos sus paths de mutación, y los gaps donde un lado se actualiza sin el otro.
-  Language-agnostic (Python, TS, Go, Rust, Java, C#). Cargar cuando se sospeche
-  estado desincronizado: caché obsoleta, índices secundarios huérfanos, contadores
-  que no coinciden con la suma de sus partes, o permisos derivados que no reflejan
-  el estado de origen.
----
-
-# Cuándo cargar
-
-- Sospechas que un caché, índice secundario, o contador agregado está desincronizado.
-- Una función actualiza la tabla principal pero no el índice derivado.
-- Hay paths de "emergencia" o "admin" que modifican estado sin pasar por el flujo normal.
-- Nemesis está corriendo su Pasada 2.
-
-# Cuándo NO cargar
-
-- Para búsqueda de vulnerabilidades conocidas (inyección SQL, XSS) — usar `revisor-seguridad-swl`.
-- Para revisión de lógica de función individual sin estado acoplado — usar `feynman-auditor-swl`.
-- Para módulos sin persistencia de estado (transformaciones funcionales puras, utilería).
-
----
-
-# State Inconsistency Auditor
-
-Encuentra bugs donde una operación actualiza State A sin actualizar State B, cuando el invariante del sistema exige que ambos cambien juntos.
-
-Los patrones detallados de estado acoplado están en [recursos/coupled-state-patterns.md](recursos/coupled-state-patterns.md).
-
----
-
-## El patrón abstracto
-
-Todo sistema mantiene **PARES DE ESTADO ACOPLADO**: dos o más valores de almacenamiento que deben mantener una relación (un invariante) entre sí. Cuando cualquier operación cambia un lado del par sin ajustar el otro, el invariante se rompe. Operaciones posteriores que leen ambos valores producen resultados incorrectos.
-
----
-
-## Reglas del auditor
-
-```
-REGLA 0: MAPEAR ANTES DE CAZAR
-Nunca empezar a revisar funciones sin tener el mapa completo de
-dependencias de estado acoplado. No se puede encontrar una actualización
-faltante si no se sabe qué actualizaciones son necesarias.
-
-REGLA 1: TODOS LOS PATHS DE MUTACIÓN IMPORTAN
-Una variable de estado puede modificarse desde 5 funciones distintas.
-Las 5 deben actualizar el estado acoplado. Si 4 lo hacen y 1 no — ese es el bug.
-
-REGLA 2: LAS OPERACIONES PARCIALES SON LA FUENTE #1
-Las eliminaciones completas (eliminar todo) generalmente resetean todo el estado
-correctamente. Las operaciones parciales (reducir en X) frecuentemente olvidan
-reducir proporcionalmente el estado acoplado.
-
-REGLA 3: COMPARAR PATHS PARALELOS
-Si transferir() y eliminar() ambos reducen un balance, AMBOS deben actualizar
-el mismo conjunto de estado acoplado. Si uno lo hace y el otro no — hallazgo.
-
-REGLA 4: EL CÓDIGO DEFENSIVO ENMASCARA BUGS
-Código como `valor > minimo ? valor - minimo : 0` o `min(calculado, disponible)`
-oculta invariantes rotos silenciosamente. Son señales de alerta, no protecciones.
-
-REGLA 5: SOLO HALLAZGOS BASADOS EN EVIDENCIA
-Todo hallazgo debe incluir: el par acoplado, la operación que lo rompe,
-una secuencia de trigger concreta, y la consecuencia observable.
-```
-
----
-
-## Proceso
-
-### Fase 1: Mapear pares de estado acoplado
-
-Para cada variable de almacenamiento, preguntar: **"¿Qué otros valores de almacenamiento deben cambiar cuando este cambia?"**
-
-Construir un mapa de dependencias. Ver patrones comunes en `recursos/coupled-state-patterns.md`.
-
-Salida de Fase 1: **Mapa de Dependencias de Estado Acoplado**.
-
-### Fase 2: Matriz de mutación
-
-Para cada variable identificada en Fase 1, listar TODAS las funciones y paths de código que la modifican. Incluir: escrituras directas, incrementos/decrementos, eliminaciones, mutaciones indirectas (llamadas internas), triggers externos (callbacks, hooks).
-
-Marcar con `???` toda entrada donde no se ha confirmado si la contraparte acoplada también se actualiza.
-
-Los `???` son los **objetivos primarios de auditoría**.
-
-### Fase 3: Cross-check — el corazón de la auditoría
-
-Para cada par (operación, variable de estado) de Fase 2:
-
-> "Esta operación modifica State A. ¿También actualiza todo el estado acoplado que depende de A?"
-
-Verificar específicamente:
-- Eliminación completa (A → 0): ¿se resetea/limpia todo el estado acoplado?
-- Eliminación parcial (A decrece): ¿se reduce proporcionalmente todo el estado acoplado?
-- Incremento (A crece): ¿se incrementa proporcionalmente todo el estado acoplado?
-- Transferencia (A se mueve entre entidades): ¿el estado acoplado se mueve también?
-- Eliminación de entrada de colección: ¿la entrada del par también se elimina?
-- Operación en lote: ¿el estado acoplado se actualiza por iteración o solo una vez?
-
-**Si algún path actualiza A sin actualizar su estado acoplado → HALLAZGO.**
-
-### Fase 4: Orden de operaciones dentro de funciones
-
-Muchas funciones realizan múltiples cambios de estado en secuencia. Rastrear el orden exacto y preguntar en cada paso: "¿Después de este paso, todos los pares acoplados siguen siendo consistentes?"
-
-Bugs de orden comunes:
-- Calcular resultado ANTES de actualizar el índice → resultado usa estado obsoleto
-- Leer caché DESPUÉS de modificar el origen → validación usa datos viejos
-- Emitir evento con valores viejos DESPUÉS del cambio de estado → sistemas externos se desincronizarán
-
-### Fase 5: Comparar paths paralelos
-
-Encontrar operaciones que logran resultados similares por paths distintos. Para cada grupo, comparar: ¿TODOS los paths actualizan el mismo estado acoplado?
-
-### Fase 6: Rastrear journeys multi-paso
-
-Simular secuencias donde un actor interactúa múltiples veces:
-
-1. Actor inicializa un recurso (estado inicializado)
-2. Tiempo pasa / estado externo evoluciona
-3. Actor hace modificación PARCIAL (el estado acoplado puede romperse aquí)
-4. Más tiempo pasa
-5. Actor hace otra operación que lee el estado acoplado
-
-En el paso 5: ¿el estado acoplado sigue siendo válido dado el cambio parcial del paso 3?
-
-### Fase 7: Patrones de enmascaramiento
-
-El código defensivo puede ocultar invariantes rotos. Ver patrones en `recursos/coupled-state-patterns.md`.
-
-Señal: si un ternario del tipo `a > b ? a - b : 0` está en un cálculo que involucra dos valores acoplados, preguntar: ¿por qué `a` podría ser menor que `b`? Si el invariante se mantuviera, no podría.
-
----
-
-## Verificación (obligatoria para C/A/M)
-
-**Método A: Rastreo de código** — leer la función exacta, rastrear todas las llamadas internas, confirmar que no existe actualización oculta al estado acoplado.
-
-**Método B: Test de PoC** — escribir un test que ejecute la secuencia de trigger y afirme que el estado es inconsistente después de la operación.
-
-**Método C: Híbrido** — rastreo + PoC para hallazgos que abarcan múltiples módulos.
-
-**Falsos positivos frecuentes:**
-- Reconciliación oculta en un hook `_before_save` / `_after_update` / middleware.
-- Evaluación diferida intencional: el estado acoplado se reconcilia en la próxima lectura.
-- Asimetría de diseño documentada: los dos estados no son realmente acoplados como se asumió.
-
----
-
-## Adaptación por lenguaje
-
-| Concepto | Python | TypeScript | Go | Rust | Java | C# |
-|---------|--------|------------|-----|------|------|-----|
-| Almacenamiento | atributos / BD | propiedades / BD | campos struct / BD | campos struct | campos clase | propiedades |
-| Colección clave-valor | `dict` / `HashMap` Redis | `Map` / objeto | `map[K]V` | `HashMap` | `Map<K,V>` | `Dictionary<K,V>` |
-| Eliminar entrada | `del d[k]` / `pop` | `delete obj[k]` | `delete(m, k)` | `map.remove(&k)` | `map.remove(k)` | `dict.Remove(k)` |
-| Hook post-mutación | `@receiver` / signal | middleware / hook | middleware | `impl Drop` / hook | `@PostUpdate` | event handler |
-
-<!-- Adaptado de nemesis-auditor-main bajo MIT License (https://github.com/0xiehnnkta/nemesis-auditor) -->
+---
+name: state-inconsistency-auditor-swl
+description: >
+  Encuentra bugs donde una operación muta un fragmento de estado acoplado sin
+  actualizar su contraparte dependiente, causando corrupción silenciosa o fallos
+  en operaciones posteriores. Mapea sistemáticamente pares de estado acoplado,
+  todos sus paths de mutación, y los gaps donde un lado se actualiza sin el otro.
+  Language-agnostic (Python, TS, Go, Rust, Java, C#). Cargar cuando se sospeche
+  estado desincronizado: caché obsoleta, índices secundarios huérfanos, contadores
+  que no coinciden con la suma de sus partes, o permisos derivados que no reflejan
+  el estado de origen.
+version: "1.0.0"
+exclusiones:
+  - "No cargar para bugs de lógica en función individual — usar feynman-auditor-swl."
+  - "No cargar para auditoría de race conditions en código concurrente — eso requiere análisis específico de threading/async."
+  - "No cargar para módulos sin estado mutable o sin pares de estado acoplado — el patrón no aplica."
+  - "No cargar para revisión de estilo o legibilidad — usar revisor-codigo-swl."
+---
+
+# Cuándo cargar
+
+- Sospechas que un caché, índice secundario, o contador agregado está desincronizado.
+- Una función actualiza la tabla principal pero no el índice derivado.
+- Hay paths de "emergencia" o "admin" que modifican estado sin pasar por el flujo normal.
+- Nemesis está corriendo su Pasada 2.
+
+# Cuándo NO cargar
+
+- Para búsqueda de vulnerabilidades conocidas (inyección SQL, XSS) — usar `revisor-seguridad-swl`.
+- Para revisión de lógica de función individual sin estado acoplado — usar `feynman-auditor-swl`.
+- Para módulos sin persistencia de estado (transformaciones funcionales puras, utilería).
+
+---
+
+# State Inconsistency Auditor
+
+Encuentra bugs donde una operación actualiza State A sin actualizar State B, cuando el invariante del sistema exige que ambos cambien juntos.
+
+Los patrones detallados de estado acoplado están en [recursos/coupled-state-patterns.md](recursos/coupled-state-patterns.md).
+
+---
+
+## El patrón abstracto
+
+Todo sistema mantiene **PARES DE ESTADO ACOPLADO**: dos o más valores de almacenamiento que deben mantener una relación (un invariante) entre sí. Cuando cualquier operación cambia un lado del par sin ajustar el otro, el invariante se rompe. Operaciones posteriores que leen ambos valores producen resultados incorrectos.
+
+---
+
+## Reglas del auditor
+
+```
+REGLA 0: MAPEAR ANTES DE CAZAR
+Nunca empezar a revisar funciones sin tener el mapa completo de
+dependencias de estado acoplado. No se puede encontrar una actualización
+faltante si no se sabe qué actualizaciones son necesarias.
+
+REGLA 1: TODOS LOS PATHS DE MUTACIÓN IMPORTAN
+Una variable de estado puede modificarse desde 5 funciones distintas.
+Las 5 deben actualizar el estado acoplado. Si 4 lo hacen y 1 no — ese es el bug.
+
+REGLA 2: LAS OPERACIONES PARCIALES SON LA FUENTE #1
+Las eliminaciones completas (eliminar todo) generalmente resetean todo el estado
+correctamente. Las operaciones parciales (reducir en X) frecuentemente olvidan
+reducir proporcionalmente el estado acoplado.
+
+REGLA 3: COMPARAR PATHS PARALELOS
+Si transferir() y eliminar() ambos reducen un balance, AMBOS deben actualizar
+el mismo conjunto de estado acoplado. Si uno lo hace y el otro no — hallazgo.
+
+REGLA 4: EL CÓDIGO DEFENSIVO ENMASCARA BUGS
+Código como `valor > minimo ? valor - minimo : 0` o `min(calculado, disponible)`
+oculta invariantes rotos silenciosamente. Son señales de alerta, no protecciones.
+
+REGLA 5: SOLO HALLAZGOS BASADOS EN EVIDENCIA
+Todo hallazgo debe incluir: el par acoplado, la operación que lo rompe,
+una secuencia de trigger concreta, y la consecuencia observable.
+```
+
+---
+
+## Proceso
+
+### Fase 1: Mapear pares de estado acoplado
+
+Para cada variable de almacenamiento, preguntar: **"¿Qué otros valores de almacenamiento deben cambiar cuando este cambia?"**
+
+Construir un mapa de dependencias. Ver patrones comunes en `recursos/coupled-state-patterns.md`.
+
+Salida de Fase 1: **Mapa de Dependencias de Estado Acoplado**.
+
+### Fase 2: Matriz de mutación
+
+Para cada variable identificada en Fase 1, listar TODAS las funciones y paths de código que la modifican. Incluir: escrituras directas, incrementos/decrementos, eliminaciones, mutaciones indirectas (llamadas internas), triggers externos (callbacks, hooks).
+
+Marcar con `???` toda entrada donde no se ha confirmado si la contraparte acoplada también se actualiza.
+
+Los `???` son los **objetivos primarios de auditoría**.
+
+### Fase 3: Cross-check — el corazón de la auditoría
+
+Para cada par (operación, variable de estado) de Fase 2:
+
+> "Esta operación modifica State A. ¿También actualiza todo el estado acoplado que depende de A?"
+
+Verificar específicamente:
+- Eliminación completa (A → 0): ¿se resetea/limpia todo el estado acoplado?
+- Eliminación parcial (A decrece): ¿se reduce proporcionalmente todo el estado acoplado?
+- Incremento (A crece): ¿se incrementa proporcionalmente todo el estado acoplado?
+- Transferencia (A se mueve entre entidades): ¿el estado acoplado se mueve también?
+- Eliminación de entrada de colección: ¿la entrada del par también se elimina?
+- Operación en lote: ¿el estado acoplado se actualiza por iteración o solo una vez?
+
+**Si algún path actualiza A sin actualizar su estado acoplado → HALLAZGO.**
+
+### Fase 4: Orden de operaciones dentro de funciones
+
+Muchas funciones realizan múltiples cambios de estado en secuencia. Rastrear el orden exacto y preguntar en cada paso: "¿Después de este paso, todos los pares acoplados siguen siendo consistentes?"
+
+Bugs de orden comunes:
+- Calcular resultado ANTES de actualizar el índice → resultado usa estado obsoleto
+- Leer caché DESPUÉS de modificar el origen → validación usa datos viejos
+- Emitir evento con valores viejos DESPUÉS del cambio de estado → sistemas externos se desincronizarán
+
+### Fase 5: Comparar paths paralelos
+
+Encontrar operaciones que logran resultados similares por paths distintos. Para cada grupo, comparar: ¿TODOS los paths actualizan el mismo estado acoplado?
+
+### Fase 6: Rastrear journeys multi-paso
+
+Simular secuencias donde un actor interactúa múltiples veces:
+
+1. Actor inicializa un recurso (estado inicializado)
+2. Tiempo pasa / estado externo evoluciona
+3. Actor hace modificación PARCIAL (el estado acoplado puede romperse aquí)
+4. Más tiempo pasa
+5. Actor hace otra operación que lee el estado acoplado
+
+En el paso 5: ¿el estado acoplado sigue siendo válido dado el cambio parcial del paso 3?
+
+### Fase 7: Patrones de enmascaramiento
+
+El código defensivo puede ocultar invariantes rotos. Ver patrones en `recursos/coupled-state-patterns.md`.
+
+Señal: si un ternario del tipo `a > b ? a - b : 0` está en un cálculo que involucra dos valores acoplados, preguntar: ¿por qué `a` podría ser menor que `b`? Si el invariante se mantuviera, no podría.
+
+---
+
+## Verificación (obligatoria para C/A/M)
+
+**Método A: Rastreo de código** — leer la función exacta, rastrear todas las llamadas internas, confirmar que no existe actualización oculta al estado acoplado.
+
+**Método B: Test de PoC** — escribir un test que ejecute la secuencia de trigger y afirme que el estado es inconsistente después de la operación.
+
+**Método C: Híbrido** — rastreo + PoC para hallazgos que abarcan múltiples módulos.
+
+**Falsos positivos frecuentes:**
+- Reconciliación oculta en un hook `_before_save` / `_after_update` / middleware.
+- Evaluación diferida intencional: el estado acoplado se reconcilia en la próxima lectura.
+- Asimetría de diseño documentada: los dos estados no son realmente acoplados como se asumió.
+
+---
+
+## Adaptación por lenguaje
+
+| Concepto | Python | TypeScript | Go | Rust | Java | C# |
+|---------|--------|------------|-----|------|------|-----|
+| Almacenamiento | atributos / BD | propiedades / BD | campos struct / BD | campos struct | campos clase | propiedades |
+| Colección clave-valor | `dict` / `HashMap` Redis | `Map` / objeto | `map[K]V` | `HashMap` | `Map<K,V>` | `Dictionary<K,V>` |
+| Eliminar entrada | `del d[k]` / `pop` | `delete obj[k]` | `delete(m, k)` | `map.remove(&k)` | `map.remove(k)` | `dict.Remove(k)` |
+| Hook post-mutación | `@receiver` / signal | middleware / hook | middleware | `impl Drop` / hook | `@PostUpdate` | event handler |
+
+<!-- Adaptado de nemesis-auditor-main bajo MIT License (https://github.com/0xiehnnkta/nemesis-auditor) -->

package/habilidades/tdd-workflow/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: tdd-workflow
 description: Flujo completo de Test-Driven Development. Ciclo RED (el test falla) → GREEN (implementación mínima) → REFACTOR (limpieza). Incluye cobertura mínima obligatoria, tests de frontera, factories, fixtures y estrategias para diferentes tipos de código (APIs, services, componentes Angular).
-version: "1.0.4"
+version: "1.0.5"
 evolved: true
-evolved-from: "1.0.3"
+evolved-from: "1.0.4"
 evolved-at: "2026-05-16"
 evolved-by: "aprender"
-evolved-note: "v1.0.3: gotcha cwd cacheado al require(). v1.0.4: silenced tests por race en path único compartido + anti-patrón `if (X) assert(Y)` sin else. Origen PR #30 v1.5.2 (swl-ses)."
+evolved-note: "v1.0.5: gotcha 'Tests E2E de CLIs interactivos sin PTY real'. Origen M2 sesión 2026-05-16 — harness TTY mockeado en swl-ses v1.6.0 que evita instalar node-pty. v1.0.4: silenced tests por race en path único compartido + anti-patrón `if (X) assert(Y)` sin else. v1.0.3: gotcha cwd cacheado al require()."
 herramientasPermitidas: [Read, Bash]
 evolvable: true  # default para skill estandar
 exclusiones:
@@ -476,3 +476,178 @@ flag `swl-ses-update-check.json` compartido entre dos archivos `.test.js`
 paralelos. El test "sin flag → debe advertir" pasaba en CI cuando otro
 archivo creaba el flag, sin ejecutar ninguna assertion. Fix: env var
 `SWL_UPDATE_FLAG_PATH` para aislamiento + assertions incondicionales.
+
+---
+
+## Tests E2E de CLIs interactivos sin PTY real
+
+### El problema
+
+Probar un CLI interactivo (TUI con `readline`, prompts, keypress events,
+`process.stdin.isTTY`) en CI requiere normalmente un **pseudo-terminal
+emulado** (PTY) — usualmente vía `node-pty`, una dependencia **nativa** que:
+
+- Requiere compilación de extensiones C++ al instalar (puede fallar en
+  contenedores minimal o en Windows sin Visual Studio Build Tools).
+- Agrega ~5 MB al `node_modules` por imagen.
+- Hace que el test suite no corra en `npm test` sin setup extra.
+
+Para CLIs interactivos donde no se necesita probar **el comportamiento
+real del terminal** (escape codes, redibujado, scroll), sino solo la
+**lógica del wizard** (¿qué pasa si el usuario presiona Esc en el paso 3?,
+¿qué resuelve el promise tras Enter con default?), un harness TTY mockeado
+cubre ~90% de los casos sin dep nativa.
+
+### Patrón del harness
+
+```javascript
+// tests/harness-tty.js
+'use strict';
+
+const readline = require('readline');
+
+function crearHarness() {
+  // 1. Capturar estado original para restauración
+  const stdoutOriginal = process.stdout.write.bind(process.stdout);
+  const isTtyStdoutOriginal = process.stdout.isTTY;
+  const isTtyStdinOriginal = process.stdin.isTTY;
+  const setRawModeOriginal = process.stdin.setRawMode
+    ? process.stdin.setRawMode.bind(process.stdin) : null;
+  const emitKeypressOriginal = readline.emitKeypressEvents;
+
+  let capturado = '';
+  let listenersKeypress = [];
+
+  // 2. Forzar TTY antes de cargar módulos UI (que evalúan ES_TTY al require)
+  Object.defineProperty(process.stdout, 'isTTY', { value: true, configurable: true });
+  Object.defineProperty(process.stdin,  'isTTY', { value: true, configurable: true });
+
+  // 3. Capturar stdout en string buffer
+  process.stdout.write = (chunk) => {
+    capturado += typeof chunk === 'string' ? chunk : chunk.toString();
+    return true;
+  };
+
+  // 4. Mockear setRawMode/resume/pause como no-op (evita tomar control del terminal de test)
+  process.stdin.setRawMode = () => process.stdin;
+  process.stdin.resume = () => process.stdin;
+  process.stdin.pause = () => process.stdin;
+
+  // 5. Interceptar registros de 'keypress' para poder emitirlos a mano
+  const onListenerOriginal = process.stdin.on.bind(process.stdin);
+  process.stdin.on = (evento, listener) => {
+    if (evento === 'keypress') listenersKeypress.push(listener);
+    return onListenerOriginal(evento, listener);
+  };
+
+  // 6. Mockear readline.emitKeypressEvents (no necesita stdin real)
+  readline.emitKeypressEvents = (stream) => stream;
+
+  // 7. Limpiar require cache de módulos UI para que se evalúen con TTY=true
+  delete require.cache[require.resolve('../scripts/tui/lib/render')];
+
+  function cargarUI() {
+    return require('../scripts/tui/lib/render');
+  }
+
+  // 8. Emitir keypress programáticamente
+  function tecla(nombre, extras = {}) {
+    const key = { name: nombre, ctrl: false, meta: false, shift: false, ...extras };
+    const str = nombre.length === 1 ? nombre : '';
+    for (const listener of [...listenersKeypress]) {
+      try { listener(str, key); } catch (_) { /* swallow */ }
+    }
+  }
+
+  // 9. Esperar N ticks del event loop para promesas internas
+  function esperarTicks(n = 1) {
+    let p = Promise.resolve();
+    for (let i = 0; i < n; i++) p = p.then(() => undefined);
+    return p;
+  }
+
+  function captura(opts = {}) {
+    const valor = capturado;
+    if (opts.limpiar) capturado = '';
+    return valor;
+  }
+
+  function restaurar() {
+    Object.defineProperty(process.stdout, 'isTTY', { value: isTtyStdoutOriginal, configurable: true });
+    Object.defineProperty(process.stdin,  'isTTY', { value: isTtyStdinOriginal,  configurable: true });
+    process.stdout.write = stdoutOriginal;
+    if (setRawModeOriginal) process.stdin.setRawMode = setRawModeOriginal;
+    process.stdin.on = onListenerOriginal;
+    readline.emitKeypressEvents = emitKeypressOriginal;
+    listenersKeypress = [];
+    // Limpiar require cache para no contaminar otros tests
+    delete require.cache[require.resolve('../scripts/tui/lib/render')];
+  }
+
+  return { cargarUI, tecla, esperarTicks, captura, restaurar };
+}
+
+module.exports = { crearHarness };
+```
+
+### Uso típico
+
+```javascript
+const test = require('node:test');
+const assert = require('node:assert/strict');
+const { crearHarness } = require('./harness-tty');
+
+test('preguntarSiNo con harness: Enter resuelve con default true', async () => {
+  const h = crearHarness();
+  try {
+    const ui = h.cargarUI();
+    const promesa = ui.preguntarSiNo('test prompt', true);
+
+    await h.esperarTicks(2);
+    h.tecla('return');
+
+    const timeout = new Promise((_, reject) =>
+      setTimeout(() => reject(new Error('no resolvió en 500ms')), 500));
+
+    const r = await Promise.race([promesa, timeout]).catch(() => null);
+    // r === true si el harness simuló bien; null si readline real bloquea
+    // (caso esperado en Windows sin PTY real; documentar limitación)
+  } finally {
+    h.restaurar();
+  }
+});
+```
+
+### Reglas operativas
+
+- **`restaurar()` en `finally`**: el harness modifica state global
+  (process.stdout, process.stdin, readline, require.cache). Si un test
+  no restaura, contamina los siguientes.
+- **Test de captura como smoke**: agregar un test "harness captura stdout"
+  que valida que `process.stdout.write('hola')` aparece en `captura()`.
+  Si falla, el harness está roto antes de testear el SUT.
+- **Test "tecla() es no-op sin listeners"**: validar que emitir keypress
+  cuando nadie escucha NO rompe el harness ni propaga errores.
+- **Limitación reconocida**: si `readline.createInterface()` real toma
+  control de stdin (en Windows con Git Bash sin PTY), el callback de
+  `rl.question()` no se invoca aunque el harness emita teclas. Usar
+  `Promise.race([promesa, timeout])` para que el test no cuelgue —
+  el test marca limitación, no falla.
+
+### Cuándo NO usar este patrón
+
+- Cuando necesitas probar **redibujado real del terminal** (alt screen
+  buffer, escape codes complejos, scrollback). Ahí sí necesitas PTY real
+  via `node-pty` o test manual.
+- Cuando el SUT depende de **timing real del teclado** (input rates,
+  paste detection). El mock no replica latencia.
+- Para CLIs sin lógica de control de flujo (solo `console.log` lineal) —
+  ahí basta capturar stdout sin mockear TTY.
+
+### Origen
+
+Aplicado en swl-ses v1.6.0 (`tests/scripts/tui/harness-tty.js`, ~180 LOC).
+Validó el TUI completo de 5 fases sin instalar `node-pty`. Limitación
+documentada: 1 test E2E "preguntarSiNo con harness" marca timeout en
+Windows + Node 22+ porque readline real bloquea pese a stdin mockeado —
+el harness emite la limitación sin fallar.

package/habilidades/verificacion-evidencia/SKILL.md

@@ -5,6 +5,7 @@ description: >
   el comando de prueba, leer la salida completa y verificar antes de cualquier
   afirmación positiva. Cargar SIEMPRE al terminar una tarea o slice, antes de
   reportar éxito al usuario o al orquestador.
+version: "1.0.0"
 herramientasPermitidas: [Read, Write, Edit, Bash, Glob, Grep]
 exclusiones:
   - "No cargar como sustituto de `verificar-trabajo` — este skill es el gate de afirmaciones puntuales, no la verificación end-to-end de un plan completo."