@saulwade/swl-ses 2.2.3 → 2.3.0

package/habilidades/planear-fase/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: planear-fase
 description: Crea el PLAN.md ejecutable para una fase de desarrollo. Descompone la fase en tareas atómicas con dependencias explícitas, las agrupa en oleadas de ejecución paralela cuando es posible, y aplica verificación goal-backward para garantizar que el plan completo satisface los criterios de éxito definidos en CONTEXTO.md.
-version: "1.3.1"
+version: "1.3.2"
 herramientasPermitidas: [Read, Write, Edit, Bash, Glob, Grep]
 exclusiones:
   - "No cargar si no existe CONTEXTO.md para la fase — ejecutar `discutir-fase` primero."
@@ -144,10 +144,24 @@ goal-backward deja de ser pregunta abierta y se vuelve **matriz verificable**:
    planes con REQ huérfanos.
 4. Tareas sin REQ son válidas (infraestructura, refactor habilitante) pero la matriz
    las hace visibles.
+5. **REQ verificable por inspección (config, CI, lint, docs) DEBE llevar la marca
+   literal `(verificación: inspección)` en su criterio del CONTEXTO.** Sin esa
+   marca, `verificar-trazabilidad.js` aplica el método por defecto (`test`) y exige
+   un test con marker `verifica: REQ-NN`; un REQ satisfecho por ruff/CI/prosa pero
+   sin esa anotación se reporta como **huérfano (REQ sin test)** aunque esté
+   genuinamente cubierto. Si detectas un REQ de este tipo sin la marca, agrégala al
+   CONTEXTO (`0N-CONTEXTO.md`) antes de construir la matriz — no inventes un test
+   artificial para satisfacer al verificador.
 
 En CONTEXTOs legacy sin REQ-IDs (fases 01-09): aplicar la pregunta abierta clásica
 ("¿el criterio de éxito queda satisfecho?") — cláusula de gracia, sin matriz.
 
+**Formato de header de tarea — dos puntos, no em-dash.** Cada tarea se escribe
+`### T-NN:` (2-4 `#`, dos puntos tras el ID). `verificar-trazabilidad.js` parsea la
+matriz con `/^#{2,4}\s*T-\d{1,3}\s*:/`; un header `#### T-01 — Foo` (em-dash) deja
+la tarea **invisible** y sus REQ huérfanos sin causa aparente. El verificador emite
+un WARN explicando esto, pero el plan debe nacer con el separador correcto.
+
 ---
 
 ## Estructura del PLAN.md

package/habilidades/proceso-debate-adversarial/SKILL.md

@@ -1,164 +1,191 @@
----
-name: proceso-debate-adversarial
-description: >
-  Protocolo de debate adversarial con jueces ciegos para decisiones técnicas
-  subjetivas: dos autores en frío generan candidatos, un crítico forzosamente
-  adversarial los ataca, un sintetizador produce un híbrido y un panel de jueces
-  ciegos con etiquetas aleatorizadas elige al ganador hasta convergencia.
-  Cargar cuando una decisión de arquitectura, diseño o estrategia no tiene
-  métrica objetiva y el riesgo de sycophancy (auto-aprobarse) es alto; también
-  cuando arquitecto-swl evalúa alternativas o /swl:predecir necesita el
-  protocolo de personas en frío.
-version: "1.0.0"
-herramientasPermitidas: [Read, Agent, Skill]
-exclusiones:
-  - "No cargar para decisiones con métrica objetiva verificable — ahí aplica el loop de autoresearch (Verify numérico), no un debate."
-  - "No cargar para revisión de código post-implementación — eso es revisor-codigo-swl / nemesis-auditor-swl."
-  - "No cargar para decisiones triviales o de preferencia personal sin impacto técnico — el costo de 5+ invocaciones de agente no se justifica."
-evolvable: true
----
-# Debate Adversarial con Jueces Ciegos
-
-Protocolo para decidir entre alternativas técnicas **sin métrica objetiva**
-eliminando los dos sesgos que arruinan las auto-evaluaciones de un LLM:
-**sycophancy** (el agente aprueba lo que él mismo generó) y **position bias**
-(el juez prefiere la opción presentada primero). Patrón adoptado del análisis
-de autoresearch v2.1 (`reason-judge-protocol`), adaptado al ecosistema SWL.
-
-**Principio**: el que genera nunca juzga, el que juzga nunca sabe quién generó.
-
-## Cuándo cargar este skill
-
-- Decisión de arquitectura con 2+ alternativas viables sin benchmark objetivo
-  (ej: event sourcing vs CRUD+audit, monolito modular vs microservicios).
-- `arquitecto-swl` necesita justificar un ADR con alternativas evaluadas de
-  forma no sesgada.
-- `/swl:predecir` requiere el protocolo de aislamiento de personas.
-- Decisión de producto/estrategia donde el usuario pide "dame la mejor opción"
-  y una sola pasada produciría la primera idea plausible, no la mejor.
-
-## Los 5 roles — aislamiento obligatorio (COLD START)
-
-| Rol | Recibe | Produce | Regla dura |
-|-----|--------|---------|------------|
-| **Autor-A** | tarea | candidato A | No ve crítica ni candidato B |
-| **Crítico** | tarea + candidato A | ≥3 debilidades con evidencia + qué haría un candidato superior | NUNCA elogia — rol puramente adversarial |
-| **Autor-B** | tarea + candidato A + crítica | candidato B que resuelve la crítica preservando fortalezas de A | No ve al sintetizador |
-| **Sintetizador** | tarea + A + B | candidato híbrido AB | Fusiona lo mejor de ambos, no promedia |
-| **Panel de jueces** (3 default) | tarea + 3 candidatos con **etiquetas aleatorizadas** (X, Y, Z) | ranking 1°/2°/3° + justificación de un párrafo c/u | "Todos están bien" NO es veredicto válido |
-
-**COLD START**: cada rol se ejecuta como invocación independiente del Agent
-tool **sin contexto compartido de sesión** — recibe SOLO los insumos de su fila.
-Pasar el historial completo a un juez invalida el protocolo (sabría quién
-escribió qué).
-
-**Aleatorización de etiquetas**: antes de invocar a los jueces, mapear
-A/B/AB → X/Y/Z con orden aleatorio distinto por juez. Previene position bias.
-
-## El loop de convergencia
-
-```
-Ronda N:
-  1. Autor-A genera candidato (ronda 1) o presenta al incumbente (ronda N>1)
-  2. Crítico ataca → ≥3 debilidades con evidencia
-  3. Autor-B genera candidato alternativo
-  4. Sintetizador produce híbrido AB
-  5. Panel ciego vota → ganador por mayoría (empate → gana el híbrido)
-  6. ¿Ganador == incumbente? → convergencia++ ; si no → convergencia = 1,
-     el ganador se vuelve incumbente
-```
-
-| Condición | Acción |
-|-----------|--------|
-| Mismo incumbente gana 3 rondas consecutivas | **CONVERGIDO** — terminar |
-| Ronda ≥ max (default 8) | **ACOTADO** — reportar mejor candidato actual |
-| Incumbente cambió >5 veces en las últimas 8 rondas | **OSCILACIÓN** — detener y reportar: la tarea está mal planteada o las alternativas son equivalentes |
-
-Registrar cada ronda con `hooks/lib/loop-telemetry.js` (tipo `debate`,
-columnas `ronda, timestamp, etiqueta_ganadora, veredicto, convergencia,
-descripcion`) para que la trayectoria sea auditable y `/swl:status metricas` la lea.
-
-## Anti-herd check — obligatorio
-
-Si TODOS los jueces coinciden en la primera ronda, el sintetizador DEBE
-producir al menos un contraargumento antes de aceptar el consenso. Unanimidad
-inmediata en un debate de alternativas reales es señal de herd bias, no de
-calidad — las alternativas genuinas siempre tienen tradeoffs defendibles.
-
-## Criterios de juez por dominio
-
-| Dominio | Criterios de evaluación |
-|---------|------------------------|
-| Arquitectura de software | escalabilidad, mantenibilidad, rendimiento, seguridad, simplicidad |
-| Estrategia de producto | encaje de mercado, factibilidad, diferenciación, riesgo, tiempos |
-| Decisión de negocio | ROI, riesgo, alineación, recursos requeridos, reversibilidad |
-| Enfoque de seguridad | cobertura, tasa de falsos positivos, practicidad, cumplimiento |
-| Hipótesis de investigación | testabilidad, novedad, soporte de evidencia, poder explicativo |
-
-El juez evalúa CADA candidato contra TODOS los criterios del dominio y
-produce ranking con justificación — nunca un score suelto sin comparación.
-
-## Personas para análisis predictivo
-
-Cuando el objetivo es **predecir problemas de un cambio propuesto** (no
-elegir entre alternativas), usar el modo personas: 5 expertos analizan EN FRÍO
-el mismo cambio y un sintetizador deduplica y rankea. Definiciones completas,
-preguntas guía y red flags por persona en
-[recursos/personas.md](recursos/personas.md). Set default: Arquitecto de
-Software, Analista de Seguridad, Ingeniero de Rendimiento, Ingeniero de
-Confiabilidad, Abogado del Diablo. Set adversarial (`--adversarial`): El
-Rompedor, El Tramposo, El Escalador, El Novato, El Insider Malicioso.
-
-Ranking de hallazgos del sintetizador:
-`severidad × confianza promedio × número de personas que coinciden`.
-
-## Integración con el ecosistema SWL
-
-| Componente | Uso del protocolo |
-|-----------|-------------------|
-| `arquitecto-swl` | Debate para la sección "Alternativas consideradas" de un ADR |
-| `/swl:predecir` | Modo personas pre-implementación |
-| `/swl:nemesis` | El evaluator puede pedir un debate cuando dos remediaciones compiten |
-| `hooks/lib/loop-telemetry.js` | Registro de rondas + handoff para encadenar |
-| `/swl:status metricas` | Lectura de trayectorias de debates en `.planning/loops/` |
-
-## Cuándo NO cargar
-
-- La decisión tiene métrica objetiva (latencia, cobertura, bundle size) — usar
-  el loop autoresearch con Verify numérico; un debate es más caro y menos
-  preciso que medir.
-- El usuario ya tomó la decisión y está documentada en ADR/vault — aplicar
-  `consultar-vault-primero`, no reabrir con un debate.
-- Hay restricción dura que elimina las alternativas (compliance, presupuesto,
-  stack fijo) — verificar restricciones ANTES de armar el debate.
-
-## Gotchas / Errores comunes no obvios
-
-- **Jueces con contexto contaminado**: invocar a los jueces en la misma
-  conversación donde se generaron los candidatos les revela la autoría por el
-  historial. Causa: usar el contexto principal en vez del Agent tool con
-  prompt acotado. Solución: cada juez es una invocación Agent independiente
-  cuyo prompt contiene SOLO tarea + candidatos etiquetados.
-- **Crítico que "equilibra"**: el crítico señala 3 debilidades pero cierra con
-  "en general es un buen enfoque" — eso re-introduce sycophancy y debilita al
-  Autor-B. Solución: el prompt del crítico prohíbe explícitamente elogios y
-  exige proponer qué haría un candidato superior.
-- **Sintetizador que promedia en vez de fusionar**: produce un candidato
-  "tibio" que toma la mitad de cada uno y pierde la coherencia interna de
-  ambos. Solución: el híbrido debe tener una tesis propia — tomar la
-  arquitectura dominante de uno e injertar mecanismos puntuales del otro.
-- **Convergencia falsa por candidatos idénticos**: si Autor-B produce
-  esencialmente el mismo candidato que A, el panel "converge" en ronda 2 sin
-  exploración real. Solución: el prompt de Autor-B exige divergencia
-  estructural, no cosmética; si la crítica fue débil, regenerar la crítica.
-
-## Anti-patrones
-
-- **Debate de 1 ronda presentado como consenso** — sin convergencia ×3 no hay
-  veredicto, hay una primera impresión cara.
-- **Saltarse la aleatorización de etiquetas** "porque los jueces son
-  imparciales" — el position bias es estadístico, no intencional.
-- **Usar el debate para decisiones ya cerradas** — teatro de proceso que
-  quema tokens para justificar lo decidido.
-- **Panel de 1 juez** — un juez único reintroduce el sesgo individual que el
-  panel existe para diluir; mínimo 3, número impar.
+---
+name: proceso-debate-adversarial
+description: >
+  Protocolo de debate adversarial con jueces ciegos para decisiones técnicas
+  subjetivas: dos autores en frío generan candidatos, un crítico forzosamente
+  adversarial los ataca, un sintetizador produce un híbrido y un panel de jueces
+  ciegos con etiquetas aleatorizadas elige al ganador hasta convergencia.
+  Cargar cuando una decisión de arquitectura, diseño o estrategia no tiene
+  métrica objetiva y el riesgo de sycophancy (auto-aprobarse) es alto; también
+  cuando arquitecto-swl evalúa alternativas o /swl:predecir necesita el
+  protocolo de personas en frío.
+version: "1.1.0"
+herramientasPermitidas: [Read, Agent, Skill]
+exclusiones:
+  - "No cargar para decisiones con métrica objetiva verificable — ahí aplica el loop de autoresearch (Verify numérico), no un debate."
+  - "No cargar para revisión de código post-implementación — eso es revisor-codigo-swl / nemesis-auditor-swl."
+  - "No cargar para decisiones triviales o de preferencia personal sin impacto técnico — el costo de 5+ invocaciones de agente no se justifica."
+evolvable: true
+---
+# Debate Adversarial con Jueces Ciegos
+
+Protocolo para decidir entre alternativas técnicas **sin métrica objetiva**
+eliminando los dos sesgos que arruinan las auto-evaluaciones de un LLM:
+**sycophancy** (el agente aprueba lo que él mismo generó) y **position bias**
+(el juez prefiere la opción presentada primero). Patrón adoptado del análisis
+de autoresearch v2.1 (`reason-judge-protocol`), adaptado al ecosistema SWL.
+
+**Principio**: el que genera nunca juzga, el que juzga nunca sabe quién generó.
+
+## Cuándo cargar este skill
+
+- Decisión de arquitectura con 2+ alternativas viables sin benchmark objetivo
+  (ej: event sourcing vs CRUD+audit, monolito modular vs microservicios).
+- `arquitecto-swl` necesita justificar un ADR con alternativas evaluadas de
+  forma no sesgada.
+- `/swl:predecir` requiere el protocolo de aislamiento de personas.
+- Decisión de producto/estrategia donde el usuario pide "dame la mejor opción"
+  y una sola pasada produciría la primera idea plausible, no la mejor.
+
+## Los 5 roles — aislamiento obligatorio (COLD START)
+
+| Rol | Recibe | Produce | Regla dura |
+|-----|--------|---------|------------|
+| **Autor-A** | tarea | candidato A | No ve crítica ni candidato B |
+| **Crítico** | tarea + candidato A | ≥3 debilidades con evidencia + qué haría un candidato superior | NUNCA elogia — rol puramente adversarial |
+| **Autor-B** | tarea + candidato A + crítica | candidato B que resuelve la crítica preservando fortalezas de A | No ve al sintetizador |
+| **Sintetizador** | tarea + A + B | candidato híbrido AB | Fusiona lo mejor de ambos, no promedia |
+| **Panel de jueces** (3 default) | tarea + 3 candidatos con **etiquetas aleatorizadas** (X, Y, Z) | ranking 1°/2°/3° + justificación de un párrafo c/u | "Todos están bien" NO es veredicto válido |
+
+**COLD START**: cada rol se ejecuta como invocación independiente del Agent
+tool **sin contexto compartido de sesión** — recibe SOLO los insumos de su fila.
+Pasar el historial completo a un juez invalida el protocolo (sabría quién
+escribió qué).
+
+**Aleatorización de etiquetas**: antes de invocar a los jueces, mapear
+A/B/AB → X/Y/Z con orden aleatorio distinto por juez. Previene position bias.
+
+## El loop de convergencia
+
+```
+Ronda N:
+  1. Autor-A genera candidato (ronda 1) o presenta al incumbente (ronda N>1)
+  2. Crítico ataca → ≥3 debilidades con evidencia
+  3. Autor-B genera candidato alternativo
+  4. Sintetizador produce híbrido AB
+  5. Panel ciego vota → ganador por mayoría (empate → gana el híbrido)
+  6. ¿Ganador == incumbente? → convergencia++ ; si no → convergencia = 1,
+     el ganador se vuelve incumbente
+```
+
+| Condición | Acción |
+|-----------|--------|
+| Mismo incumbente gana 3 rondas consecutivas | **CONVERGIDO** — terminar |
+| Ronda ≥ max (default 8) | **ACOTADO** — reportar mejor candidato actual |
+| Incumbente cambió >5 veces en las últimas 8 rondas | **OSCILACIÓN** — detener y reportar: la tarea está mal planteada o las alternativas son equivalentes |
+
+Registrar cada ronda con `hooks/lib/loop-telemetry.js` (tipo `debate`,
+columnas `ronda, timestamp, etiqueta_ganadora, veredicto, convergencia,
+descripcion`) para que la trayectoria sea auditable y `/swl:status metricas` la lea.
+
+## Anti-herd check — obligatorio
+
+Si TODOS los jueces coinciden en la primera ronda, el sintetizador DEBE
+producir al menos un contraargumento antes de aceptar el consenso. Unanimidad
+inmediata en un debate de alternativas reales es señal de herd bias, no de
+calidad — las alternativas genuinas siempre tienen tradeoffs defendibles.
+
+## Voto incompleto ≠ refutado + degradación del fan-out ante rate limit
+
+Cuando el fan-out de personas/jueces se ejecuta en paralelo y la API responde
+con rate limit (429) o un juez no completa su veredicto (timeout, error
+terminal), el hallazgo asociado queda **"sin verificar"**, NUNCA "refutado" ni
+"descartado". Conflar "no se pudo verificar" con "verificado falso" descarta
+silenciosamente hallazgos reales — el modo de falla más caro de un panel
+adversarial.
+
+Reglas:
+
+- Un veredicto que no se emite NO cuenta como voto en contra. El conteo de
+  refutación solo suma jueces que **emitieron** un veredicto de refutación
+  explícito. `votos_refutan / votos_emitidos`, nunca `/ jueces_lanzados`.
+- Un hallazgo cuyos votos no se completaron se marca `estado: sin-verificar`
+  (distinto de `confirmado` y de `refutado`) y se reporta como tal — el usuario
+  decide si re-ejecutar ese subconjunto.
+- Ante rate limit en el fan-out: **escalonar** las invocaciones (lanzar por
+  lotes con espera entre lotes) o **reducir** el número de jueces/personas a un
+  quórum mínimo (≥3) antes de abortar. Degradar el panel con aviso visible es
+  preferible a marcar todo lo no votado como refutado (regla
+  `seguridad-agentes.md § Anti-fallback silencioso`).
+
+Nota de alcance: esto aplica al panel de este skill y a `/swl:predecir`. El
+patrón adversarial-verify del harness de Workflow (built-in de Claude Code) NO
+es editable desde swl-ses; su semántica de votos vive fuera de este repo.
+
+## Criterios de juez por dominio
+
+| Dominio | Criterios de evaluación |
+|---------|------------------------|
+| Arquitectura de software | escalabilidad, mantenibilidad, rendimiento, seguridad, simplicidad |
+| Estrategia de producto | encaje de mercado, factibilidad, diferenciación, riesgo, tiempos |
+| Decisión de negocio | ROI, riesgo, alineación, recursos requeridos, reversibilidad |
+| Enfoque de seguridad | cobertura, tasa de falsos positivos, practicidad, cumplimiento |
+| Hipótesis de investigación | testabilidad, novedad, soporte de evidencia, poder explicativo |
+
+El juez evalúa CADA candidato contra TODOS los criterios del dominio y
+produce ranking con justificación — nunca un score suelto sin comparación.
+
+## Personas para análisis predictivo
+
+Cuando el objetivo es **predecir problemas de un cambio propuesto** (no
+elegir entre alternativas), usar el modo personas: 5 expertos analizan EN FRÍO
+el mismo cambio y un sintetizador deduplica y rankea. Definiciones completas,
+preguntas guía y red flags por persona en
+[recursos/personas.md](recursos/personas.md). Set default: Arquitecto de
+Software, Analista de Seguridad, Ingeniero de Rendimiento, Ingeniero de
+Confiabilidad, Abogado del Diablo. Set adversarial (`--adversarial`): El
+Rompedor, El Tramposo, El Escalador, El Novato, El Insider Malicioso.
+
+Ranking de hallazgos del sintetizador:
+`severidad × confianza promedio × número de personas que coinciden`.
+
+## Integración con el ecosistema SWL
+
+| Componente | Uso del protocolo |
+|-----------|-------------------|
+| `arquitecto-swl` | Debate para la sección "Alternativas consideradas" de un ADR |
+| `/swl:predecir` | Modo personas pre-implementación |
+| `/swl:nemesis` | El evaluator puede pedir un debate cuando dos remediaciones compiten |
+| `hooks/lib/loop-telemetry.js` | Registro de rondas + handoff para encadenar |
+| `/swl:status metricas` | Lectura de trayectorias de debates en `.planning/loops/` |
+
+## Cuándo NO cargar
+
+- La decisión tiene métrica objetiva (latencia, cobertura, bundle size) — usar
+  el loop autoresearch con Verify numérico; un debate es más caro y menos
+  preciso que medir.
+- El usuario ya tomó la decisión y está documentada en ADR/vault — aplicar
+  `consultar-vault-primero`, no reabrir con un debate.
+- Hay restricción dura que elimina las alternativas (compliance, presupuesto,
+  stack fijo) — verificar restricciones ANTES de armar el debate.
+
+## Gotchas / Errores comunes no obvios
+
+- **Jueces con contexto contaminado**: invocar a los jueces en la misma
+  conversación donde se generaron los candidatos les revela la autoría por el
+  historial. Causa: usar el contexto principal en vez del Agent tool con
+  prompt acotado. Solución: cada juez es una invocación Agent independiente
+  cuyo prompt contiene SOLO tarea + candidatos etiquetados.
+- **Crítico que "equilibra"**: el crítico señala 3 debilidades pero cierra con
+  "en general es un buen enfoque" — eso re-introduce sycophancy y debilita al
+  Autor-B. Solución: el prompt del crítico prohíbe explícitamente elogios y
+  exige proponer qué haría un candidato superior.
+- **Sintetizador que promedia en vez de fusionar**: produce un candidato
+  "tibio" que toma la mitad de cada uno y pierde la coherencia interna de
+  ambos. Solución: el híbrido debe tener una tesis propia — tomar la
+  arquitectura dominante de uno e injertar mecanismos puntuales del otro.
+- **Convergencia falsa por candidatos idénticos**: si Autor-B produce
+  esencialmente el mismo candidato que A, el panel "converge" en ronda 2 sin
+  exploración real. Solución: el prompt de Autor-B exige divergencia
+  estructural, no cosmética; si la crítica fue débil, regenerar la crítica.
+
+## Anti-patrones
+
+- **Debate de 1 ronda presentado como consenso** — sin convergencia ×3 no hay
+  veredicto, hay una primera impresión cara.
+- **Saltarse la aleatorización de etiquetas** "porque los jueces son
+  imparciales" — el position bias es estadístico, no intencional.
+- **Usar el debate para decisiones ya cerradas** — teatro de proceso que
+  quema tokens para justificar lo decidido.
+- **Panel de 1 juez** — un juez único reintroduce el sesgo individual que el
+  panel existe para diluir; mínimo 3, número impar.

package/habilidades/prompt-engineering/SKILL.md

@@ -3,7 +3,7 @@ name: prompt-engineering
 description: >
   Diseño y optimización de prompts para LLMs: chain-of-thought, few-shot,
   system prompts, structured outputs y técnicas de evaluación. Incluye guía
-  para Claude Opus 4.7 y su patrón de instrucciones literales vs inferidas.
+  para Claude Opus 4.8 y su patrón de instrucciones literales vs inferidas.
   Cargar cuando se diseñen system prompts, se optimice la calidad de
   respuestas LLM, se implemente prompt chaining, o se evalúe la efectividad
   de prompts.
@@ -26,15 +26,15 @@ exclusiones:
 - La tarea es fine-tuning o ajuste de pesos de un modelo: usar documentación del proveedor directamente.
 
 
-## Prompts literales vs inferidos (Opus 4.7)
+## Prompts literales vs inferidos (Opus 4.8)
 
-Desde Claude Opus 4.7 (abril 2026), Anthropic cambió cómo el modelo interpreta
+Desde Claude Opus 4.8 (abril 2026), Anthropic cambió cómo el modelo interpreta
 instrucciones ambiguas:
 
 - **Opus 4.6 y anteriores**: rellenaban ambigüedades con inferencia razonable.
   Un prompt como "agrega validación al formulario" generaba validación completa
   con reglas de dominio típicas.
-- **Opus 4.7**: sigue instrucciones de forma más literal. El mismo prompt ahora
+- **Opus 4.8**: sigue instrucciones de forma más literal. El mismo prompt ahora
   genera validación mínima (o pregunta qué validar) porque la instrucción
   literal no especifica qué campos ni qué reglas.
 
@@ -73,7 +73,7 @@ validación fallando."""
 
 ### Effort levels vs verbosidad
 
-Opus 4.7 no mezcla "cuánto pensar" con "cuán verboso ser". Son ejes distintos:
+Opus 4.8 no mezcla "cuánto pensar" con "cuán verboso ser". Son ejes distintos:
 
 | Eje | Control |
 |-----|---------|

package/habilidades/release-semver/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: release-semver
 description: Versionado semántico (SemVer). Cuándo bumpar major/minor/patch, changelogs convencionales, estrategia de tags y proceso de release completo.
-version: "1.0.2"
+version: "1.0.3"
 herramientasPermitidas: [Read, Bash]
 exclusiones:
   - "No cargar para versionar el sistema SWL — el bump de versión de swl-ses sigue el checklist de 15 ubicaciones documentado en `/swl:release`; este skill cubre SemVer general para proyectos de usuario, no el proceso interno de release del sistema."
@@ -325,3 +325,6 @@ de token inválido.
 - **Changelog generado con `git cliff` sin configuración personalizada incluye commits de chore y docs**: el CHANGELOG.md resultante tiene 80% de entradas de limpieza que no interesan a los consumidores. Causa: `git cliff` sin `.cliff.toml` incluye todos los tipos de commit. Solución: crear `.cliff.toml` en el repo con la sección `[git]` filtrando solo `feat`, `fix`, `perf` y `BREAKING CHANGE` para el changelog de release público.
 - **Rama `release/2.1.0` mergeada a `main` pero no a `develop`**: el próximo desarrollo parte de `develop` sin incluir los commits del release, generando conflictos en la siguiente rama de feature. Causa: el Paso 4 requiere merge a ambas ramas pero se omite el merge a `develop` por considerar que el release ya está en `main`. Solución: el proceso de release de 4 pasos del skill requiere merge a `main` Y a `develop` antes de eliminar la rama de release — ambos merges son parte del mismo paso atómico.
 - **`npx <paquete> <comando>` sin `@latest` usa caché stale indefinidamente**: tras publicar una nueva versión, `npx swl-ses doctor` sigue ejecutando la primera versión que el usuario cacheó (por ejemplo v5.7.0 cuando ya hay v5.10.3 instalada). Causa: npx resuelve a la primera versión disponible y la cachea; sin `@latest` nunca vuelve a consultar el registry. Solución: SIEMPRE usar `npx paquete@latest <comando>` en mensajes post-install, hooks de alerta de nueva versión, docs del README, ejemplos en CHANGELOG y scripts de inicialización. Nunca `npx paquete <comando>` desnudo — incluso si el paquete acaba de publicarse; el caché de un desarrollador vecino puede tener una versión anterior desde hace meses. Un bump sin `@latest` en los mensajes post-install perpetúa el problema para todos los usuarios nuevos.
+- **`npm pack --ignore-scripts` mete `__pycache__/*.pyc` (o cualquier artefacto del `prepack`) en el tarball publicado**: al saltar `--ignore-scripts` el lifecycle `prepack`, se omite la limpieza de artefactos que suele ser el ÚNICO filtro efectivo — un `.npmignore` con `**/*.pyc` NO los excluye de forma fiable cuando `package.json#files` es un allowlist (los paths del allowlist se incluyen y `.npmignore` no los poda). Causa: usar `--ignore-scripts` para "acelerar" un `npm pack`/publish manual. Solución: usar `npm pack` a secas — el `prepack` (rápido) limpia el árbol; `prepublishOnly` (lento, tests) solo corre en `npm publish`, NO en `pack`, así que no hay nada que "ahorrar". Señal de alerta: un salto inesperado en `total files` del tarball (p.ej. +1) suele ser un artefacto colado.
+- **Log de release con `createWriteStream` queda VACÍO al `process.exit()`**: un script de publicación que abre el log con `fs.createWriteStream` (async) y termina con `process.exit(code)` no alcanza a vaciar el buffer del stream a disco antes de que el proceso muera — justo cuando más se necesita el log para diagnosticar el fallo. Causa: asumir que `stream.end()` antes de `process.exit()` fuerza el flush (es asíncrono, no lo garantiza). Solución: para logs que DEBEN sobrevivir un `exit` inmediato, usar escritura SÍNCRONA: `fs.writeFileSync` (header) + `fs.appendFileSync` (cada chunk), que vacían en cada llamada.
+- **Forzar prompt de OTP TOTP rompe a usuarios con passkey/WebAuthn**: un wrapper de publish que intercepta el `EOTP` de npm y pide un código de 6 dígitos asume 2FA tipo TOTP; si la cuenta usa passkey (flujo web "abrir URL y seleccionar la llave") el prompt es un callejón sin salida. Causa: tratar `EOTP` como sinónimo de "pedir TOTP". Solución: ante `EOTP` con TTY, reintentar el `npm publish` con **stdio heredado** (`stdio: 'inherit'`) y dejar que npm conduzca su 2FA NATIVO — soporta TOTP Y passkey según la cuenta. Alternativa permanente sin 2FA: token **Automation** (no "Publish", que sí exige 2FA).

package/habilidades/tdd-workflow/SKILL.md

@@ -1,7 +1,7 @@
 ---
 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.2.1"
+version: "1.2.2"
 herramientasPermitidas: [Read, Bash]
 evolvable: true  # default para skill estandar
 exclusiones:
@@ -536,6 +536,38 @@ archivo creaba el flag, sin ejecutar ninguna assertion. Fix: env var
 
 ---
 
+## Tests E2E de UI con Playwright — gotchas de actionability
+
+Dos fallos recurrentes al automatizar UIs con Playwright donde el test "debería
+pasar" pero hace timeout o no observa el efecto esperado:
+
+- **`fill()` hace timeout en un input que el motor considera "not editable" aunque
+  sea interactivo para el usuario** (widgets custom: input dentro de un overlay/
+  option marcado `[disabled]`, combos con buscador, etc.). Playwright aplica
+  checks de actionability (visible, enabled, editable) y se niega a escribir.
+  Fix: setear el valor con el **setter nativo** y despachar el evento `input` vía
+  `evaluate`, en vez de `fill()`:
+
+  ```js
+  await page.locator('#busqueda').evaluate((el, v) => {
+    const setter = Object.getOwnPropertyDescriptor(
+      window.HTMLInputElement.prototype, 'value').set;
+    setter.call(el, v);
+    el.dispatchEvent(new Event('input', { bubbles: true }));
+  }, 'texto');
+  ```
+
+- **Un click en «Guardar»/«Enviar» que no dispara su request** suele tener un
+  **paso de confirmación intermedio** (diálogo «¿Confirmar?», modal con timeout),
+  no un bug del submit. Antes de concluir "no persiste": verificar en la pestaña
+  de red si hubo (o no) la petición, y buscar un diálogo de confirmación que el
+  test deba cerrar dentro de su timeout. Un submit que pasa por confirmación
+  necesita el click de confirmación en la aserción, no solo el del botón inicial.
+
+Regla general: ante un test E2E que falla, distinguir **bug del producto** de
+**gap del test** verificando el estado real (red, DOM, BD) antes de declarar el
+veredicto — un timeout de actionability casi nunca es un bug de la app.
+
 ## Tests E2E de CLIs interactivos sin PTY real
 
 ### El problema

package/habilidades/workflow-claude-code/SKILL.md

@@ -3,7 +3,7 @@ name: workflow-claude-code
 description: >
   Patrones de flujo de trabajo diario con Claude Code: gestión de sesiones,
   atajos de teclado, Plan Mode, feature-per-session, gestión de contexto,
-  jerarquía de memoria, handoff multi-sesión, niveles de esfuerzo de Opus 4.7
+  jerarquía de memoria, handoff multi-sesión, niveles de esfuerzo de Opus 4.8
   (high/xhigh/max) y el patrón de delegación. Cargar cuando el usuario pregunte
   cómo usar Claude Code eficientemente, cuando necesite optimizar su flujo de
   trabajo, o cuando inicie un proyecto nuevo. NO cargar para estructura de
@@ -189,9 +189,9 @@ Para ESTRUCTURA de proyecto, usar `estructura-proyecto-claude`.
 
 ---
 
-## Patrón de delegación con Opus 4.7 (desde abril 2026)
+## Patrón de delegación con Opus 4.8 (desde abril 2026)
 
-Opus 4.7 introduce un shift operativo importante: **rinde mejor tratado como un
+Opus 4.8 introduce un shift operativo importante: **rinde mejor tratado como un
 ingeniero al que delegas, no como un pair programmer al que guías línea por línea**.
 Fuente: https://claude.com/blog/best-practices-for-using-claude-opus-4-7-with-claude-code
 
@@ -228,7 +228,7 @@ el modelo decide dinámicamente cuánto razonar según la tarea.
 
 ### Sub-agentes: paralelismo explícito
 
-Opus 4.7 usa menos sub-agentes por defecto que 4.6. Si una tarea se beneficia
+Opus 4.8 usa menos sub-agentes por defecto que 4.6. Si una tarea se beneficia
 de ejecución paralela, declararlo en el prompt:
 
 - "Ejecuta estos 3 análisis en paralelo" > confiar en que lo decidirá solo.
@@ -236,7 +236,7 @@ de ejecución paralela, declararlo en el prompt:
 
 ### Instrucciones literales
 
-Opus 4.7 interpreta instrucciones de forma más literal. Los prompts ambiguos
+Opus 4.8 interpreta instrucciones de forma más literal. Los prompts ambiguos
 que 4.6 resolvía por inferencia ahora se ejecutan al pie de la letra. Invertir
 tiempo en eliminar ambigüedad al inicio ahorra iteraciones.
 
@@ -257,4 +257,4 @@ y quick reference completa, ver [recursos/referencia-completa.md](recursos/refer
 - **Sesión de >40 turnos sin compactar**: el agente no monitorea el conteo de turnos y continúa trabajando hasta que Claude empieza a "olvidar" decisiones tomadas temprano en la sesión. Causa: no se aplica la señal de context rot (40 turnos). Solución: al llegar a 40 turnos, ejecutar `/swl:compactar` antes de la siguiente tarea grande — no esperar a que la degradación sea visible en la calidad del output.
 - **CLAUDE.md superando 200 líneas sin subdirectorios**: el proyecto crece y todo el contexto se acumula en el CLAUDE.md raíz, incrementando la carga base de contexto de cada conversación. Causa: no se crean CLAUDE.md de subdirectorio para módulos como `backend/` o `frontend/`. Solución: extraer convenciones específicas de módulo a su propio `<directorio>/CLAUDE.md`; el CLAUDE.md raíz mantiene solo lo global.
 - **Auto Accept Mode activado en operaciones destructivas**: el usuario activa `Shift+Tab` para acelerar trabajo y olvida cambiarlo antes de un deploy o borrado de archivos. Causa: el modo no tiene contexto de operación. Solución: volver a Default Mode explícitamente antes de operaciones irreversibles (`Shift+Tab` de vuelta) — Auto Accept es para generación de código, no para operaciones con blast radius alto.
-- **Tokenizer 4.7 subestimado en presupuesto de contexto**: el mismo CLAUDE.md que ocupaba el 30% del contexto en Opus 4.6 ocupa hasta 40% en 4.7 debido al tokenizer más granular. Causa: el umbral de compactación no se recalibró al migrar de modelo. Solución: con Opus 4.7, bajar el umbral de compactación de 70% a 50% tal como indica el skill `compactacion-contexto`.
+- **Tokenizer 4.7 subestimado en presupuesto de contexto**: el mismo CLAUDE.md que ocupaba el 30% del contexto en Opus 4.6 ocupa hasta 40% en 4.7 debido al tokenizer más granular. Causa: el umbral de compactación no se recalibró al migrar de modelo. Solución: con Opus 4.8, bajar el umbral de compactación de 70% a 50% tal como indica el skill `compactacion-contexto`.