@saulwade/swl-ses 1.8.0 → 1.9.0

package/habilidades/fastapi-experto/SKILL.md

@@ -5,12 +5,12 @@ description: >
   testing con httpx. Incluye el anti-patrón crítico MissingGreenlet (lazy loading
   en async). Cargar cuando se implementen endpoints FastAPI, schemas Pydantic v2,
   queries SQLAlchemy async, WebSockets, SSE o tests de integración con httpx.
-version: "1.3.0"
+version: "1.3.1"
 evolved: true
-evolved-from: "1.2.0"
-evolved-at: "2026-05-20"
-evolved-by: "aprender"
-evolved-note: "2 gotchas nuevos SIGAF 2026-05-15: setattr con strings inventados en whitelist bypassea persistencia silenciosamente (extiende gotcha getattr); ClassVar[frozenset] como patrón positivo para whitelists de PATCH endpoints"
+evolved-from: "1.3.0"
+evolved-at: "2026-06-04"
+evolved-by: "evolucionar"
+evolved-note: "3 patrones nuevos OIC v1.5 2026-06-04: handler logging defensivo con sesión SQLAlchemy desacoplada (PE-001); tests pytest cuelgan si handler abre engine con pool_pre_ping al startup sin BD + receta conftest (PE-002); tests de endpoint sin BD con dependency_overrides[get_db]=lambda:None + monkeypatch del service (PE-008)"
 herramientasPermitidas: [Read]
 exclusiones:
   - "No cargar para proyectos Django o Flask — los patrones de ORM sync, Class-Based Views y middleware difieren fundamentalmente; cargar `django-experto` o el skill del framework correspondiente."
@@ -267,6 +267,57 @@ Beneficios:
 
 Regla: para cualquier whitelist usada en `setattr` ciego (PATCH endpoints, factory methods, deserializadores manuales), declarar como `ClassVar[frozenset[str]]` de la clase del service. NUNCA como variable local del método. NUNCA como módulo-level constant fuera de la clase (pierde el namespacing).
 
+- **Handler logging que persiste en BD durante manejo de excepciones — SIEMPRE usar sesión SQLAlchemy desacoplada + silenciar fallos** (patrón portable; caso real OIC v1.5 BitacoraErrorHandler 2026-06-04): si un `logging.Handler` custom (audit trail, Sentry-style, métricas async, observabilidad) usa la sesión del request para persistir el evento, durante una excepción HTTP la sesión está en estado roto y `session.add()` falla, perdiendo la excepción original. Patrón correcto:
+```python
+# Engine PROPIO independiente del pool del request (pool=2 suficiente).
+engine = create_engine(settings.DATABASE_URL, pool_pre_ping=True, pool_size=2, max_overflow=2)
+session_factory = sessionmaker(bind=engine, autocommit=False, autoflush=False)
+
+class MiHandler(logging.Handler):
+    def emit(self, record):
+        try:
+            self._emit_unsafe(record)
+        except Exception:  # noqa: BLE001 — silencio defensivo intencional
+            # NUNCA loggear con `logging` desde aquí (riesgo de recursión infinita).
+            pass
+
+    def _emit_unsafe(self, record):
+        sess = session_factory()  # sesión NUEVA, no la del request
+        try:
+            sess.add(entry); sess.commit()
+        finally:
+            sess.close()
+```
+Reglas clave: (a) engine propio; (b) `try/except: pass` agresivo en `emit()`; (c) NUNCA emitir a logger propio; (d) filtrar loggers ruidosos por nombre (`sqlalchemy.*`, `uvicorn.access`, `httpx`, `httpcore`, `asyncio`, `urllib3`); (e) idempotente: verificar si ya está en `root.handlers` antes de registrar. Aplicable a Sentry-style integrations, audit handlers, métricas async, alertas.
+
+- **Tests pytest se cuelgan al importar `app.main` cuando un handler abre engine BD con `pool_pre_ping=True` al startup** (gotcha crítico OIC v1.5 2026-06-04): si un handler de logging custom se instala en `setup_logging()` y construye un engine con `pool_pre_ping=True`, sin PostgreSQL corriendo SQLAlchemy intenta una query de verificación en `socket.connect()` infinito. El test no falla — se cuelga sin output (ni siquiera el header de pytest). Causa: el bloqueo ocurre en la **importación** del módulo `app.main` (que llama `setup_logging()`), no en el test mismo. Síntoma típico: 3+ invocaciones de `pytest` en background sin output, requiere matar `python.exe` manualmente. Solución obligatoria en `backend/tests/conftest.py`:
+```python
+# ANTES de importar app.main
+os.environ.setdefault("ENV", "test")
+os.environ.setdefault("SKIP_DB_HEALTHCHECK", "true")
+# Por CADA handler del proyecto que abre engine al startup:
+os.environ.setdefault("SWL_BITACORA_ERRORES_ENABLED", "false")
+# (sustituir por la env var real del proyecto)
+```
+Regla: cualquier handler con `pool_pre_ping=True` en su engine debe tener un kill-switch env var, y el conftest debe deshabilitarlo. Sin esto, los tests del proyecto serán inviables sin BD real.
+
+- **Tests de endpoint sin BD con `dependency_overrides[get_db]=lambda:None` + monkeypatch del service** (patrón portable validado OIC v1.5 Slice 4 2026-06-04): para tests de endpoint que verifican contrato HTTP (auth, validación de query params, estructura de respuesta, rate-limit, headers de export CSV) sin requerir PostgreSQL. 25 tests en 0.23s.
+```python
+@pytest.fixture
+def client_admin(monkeypatch: pytest.MonkeyPatch) -> TestClient:
+    app.dependency_overrides[requiere_admin] = _fake_admin  # stub user
+    app.dependency_overrides[get_db] = lambda: None  # type: ignore[return-value]
+    # Mock del service: el endpoint llama service.metodo(db, ...) pero `db` es None;
+    # el service no debe ejecutarse — se reemplaza con fake que devuelve schema válido.
+    from app.services import mi_service
+    monkeypatch.setattr(mi_service, "listar_paginado",
+        lambda db, filtros, page, per_page: SchemaPage(items=[], total=0, ...))
+    with TestClient(app) as c:
+        yield c
+    app.dependency_overrides.clear()
+```
+Aplicabilidad: cualquier endpoint que dependa de `get_db` + service mockeable. NO requiere BD real ni fixtures de datos. Tests de integración con BD viven aparte (`@pytest.mark.integration`).
+
 ## Referencias especializadas
 
 | Tema | Archivo |

package/habilidades/patrones-python/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: patrones-python
 description: Idiomas pythonicos, PEP 8, type hints modernos, dataclasses, async/await, context managers, decorators y generators. Patrones de código limpio en Python.
-version: "1.3.1"
+version: "1.4.2"
 evolved: true
-evolved-from: "1.3.0"
-evolved-at: "2026-05-04"
-evolved-by: "aprender"
-evolved-note: "+1 gotcha: assert se elimina con PYTHONOPTIMIZE=1 — usar if/raise para invariantes (sync desde global tras sesión SIGM Fase 5b)"
+evolved-from: "1.4.1"
+evolved-at: "2026-06-05"
+evolved-by: "evolucionar"
+evolved-note: "+gotcha PEP 758: except A,B: sin paréntesis es válido en Python >=3.14, no SyntaxError; cubre efecto colateral de ruff format (target py314) reformateando archivo completo. Origen: falso positivo reproducible en sistema-verificacion-oic (requires-python >=3.14)"
 herramientasPermitidas: [Read, Glob, Grep]
 exclusiones:
   - "No cargar para patrones de un framework específico (FastAPI, Django, Celery) — los idiomas generales de este skill aplican, pero los patrones de framework tienen restricciones adicionales; cargar el skill del framework correspondiente."
@@ -205,6 +205,9 @@ ver [recursos/referencia-completa.md](recursos/referencia-completa.md).
 - **`__slots__` en clase Python produce `TypeError: multiple bases have instance lay-out conflict`** al heredar de otra clase con `__slots__`: las subclases con `__slots__` requieren que todos los ancestros también tengan `__slots__`, o que el ancestro directo sea `object`. Causa: si `ClaseBase` no tiene `__slots__`, tiene un `__dict__` implícito; si `ClaseHija` tiene `__slots__`, hay conflicto de layout de memoria. Solución: o agregar `__slots__ = ()` vacío a la clase base, o eliminar `__slots__` de la subclase — no mezclar clases con y sin `__slots__` en la misma jerarquía.
 - **`property` setter que modifica un campo privado no refleja el cambio en `__repr__` generado por dataclass**: el `@property` en un dataclass crea un campo de clase que conflictúa con el campo de instancia del dataclass. Causa: `@dataclass` genera `__repr__` basado en los campos declarados en `__init__` — si el setter modifica un atributo con nombre diferente (ej: `_valor`), `__repr__` muestra el campo original sin la modificación. Solución: usar `field(init=False, repr=False)` para el campo interno y exponer solo la `property` en la interfaz pública.
 - **`assert` no es guard de invariantes en producción con `PYTHONOPTIMIZE=1` o `python -O`**: el bytecode optimizado **elimina** todos los `assert` del módulo, por lo que `assert x is not None; return x` puede retornar `None` violando el contrato `-> dict` en producción aunque pase tests en desarrollo. El test runner por defecto NO usa `-O`, por lo que el bug es invisible hasta que alguien despliega con `PYTHONOPTIMIZE=1` (configuración común para reducir memoria en imágenes Docker production). Causa: `assert` está documentado en Python como herramienta de **debugging**, no de validación. Solución: para invariantes que DEBEN cumplirse en producción, usar guard explícito con raise: `if x is None: raise HTTPException(500, "Invariante violado")` o `if x is None: raise RuntimeError(...)`. Reservar `assert` solo para tests, scripts, o pre-condiciones triviales en código de desarrollo. Regla rápida: si el assert protege un caso que activa una respuesta del usuario o un side-effect, NO es assert — es validación y debe ser `if/raise`.
+- **Pasar `None` explícito a un parámetro NO activa su valor por defecto en el callee**: si una función declara `def listar(activa: bool = True)` y el caller hace `listar(activa=valor)` donde `valor` puede ser `None` (típico con parámetros opcionales que viajan entre capas: `activa: bool | None = None`), el callee recibe `None`, NO `True`. Python aplica el default SOLO cuando el argumento se **omite literalmente** en la llamada, no cuando recibe `None` explícito. Causa: el binding del parámetro usa el valor pasado, sea cual sea — el default es fallback de *ausencia*, no de *nulidad*. El bug es silencioso: pasa los tests donde el caller omite el parámetro y falla en producción cuando el cliente omite el valor y una capa intermedia lo traduce a `None` antes de propagarlo. Caso real: un endpoint que documentaba "omitir devuelve solo activos" retornaba inactivos porque el router pasaba `activa=None` al service cuyo default era `True`. Solución: normalizar en la frontera — en el caller (`listar(activa=True if valor is None else valor)`) o tratando `None` como sentinel en el callee (`if activa is None: activa = True`). Regla: cuando un valor opcional cruza de una capa a otra y el callee tiene un default distinto de `None`, convertir `None → default` explícitamente en el punto de cruce.
+- **`getattr(obj, "attr", default)` tampoco aplica `default` si el atributo existe con valor `None`**: misma raíz que el gotcha anterior, otra manifestación. `getattr` usa `default` SOLO cuando el atributo **no existe**; si existe con valor `None` (caso típico: campos opcionales de Pydantic/SQLAlchemy inicializados a `None`), devuelve `None`, no `default`. Así `getattr(modelo, "campo_opcional", "X")` retorna `None` cuando `campo_opcional is None`, no `"X"`. Solución sin ambigüedad: `raw = getattr(modelo, "campo_opcional", None); valor = raw if raw is not None else "X"` (el atajo `getattr(...) or "X"` solo sirve si `""` y `0` son aceptables como falsy). Regla unificada para ambos casos: en Python el `default` —de parámetro o de `getattr`— es fallback de **ausencia**, nunca de **nulidad**; si `None` es un valor posible, normalízalo en la frontera.
+- **`except A, B:` sin paréntesis es sintaxis válida en Python ≥3.14 (PEP 758), NO un SyntaxError**: desde 3.14 los paréntesis en `except`/`except*` con múltiples tipos son opcionales (`except ValueError, TypeError:` ≡ `except (ValueError, TypeError):`). Bajo intérpretes <3.14 esa forma SÍ es SyntaxError, lo que confunde a herramientas y revisores que juzgan la sintaxis contra su conocimiento general del lenguaje en vez de contra la versión objetivo del proyecto (`requires-python`/`tool.ruff.target-version` en `pyproject.toml`). Causa: la validez de la sintaxis depende de la versión, no es absoluta. Efecto colateral a vigilar: `ruff format` con `target-version = "py314"` **quita** los paréntesis redundantes y, además, reformatea el archivo COMPLETO — puede tocar `except` ajenos a tu cambio (churn no intencional); `ruff check` (lo único que suele correr el CI) conserva la forma que encuentre. Solución: antes de marcar cualquier `except A, B:` como error, leer la versión objetivo del proyecto y verificar con evidencia ejecutable (`python -c "import <módulo>"` + `ruff check`). Si se prefieren los paréntesis por portabilidad/Pyright, restaurarlos a mano y NO correr `ruff format` sobre esas líneas. Caso real (2026-06-05): un proyecto con `requires-python >=3.14` recibió un falso positivo de SyntaxError CRÍTICO por esta forma; refutado con import + ruff + CI verde.
 
 ---
 

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

@@ -0,0 +1,164 @@
+---
+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: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: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/proceso-debate-adversarial/recursos/personas.md

@@ -0,0 +1,105 @@
+# Personas para análisis predictivo y debate adversarial
+
+Definiciones operativas de las personas que consume `proceso-debate-adversarial`
+(modo personas) y `/swl:predecir`. Cada persona se invoca EN FRÍO (COLD START):
+recibe la descripción del cambio + conocimiento del codebase + sus criterios —
+nunca el análisis de otra persona.
+
+Formato de hallazgo obligatorio por persona:
+
+```markdown
+| # | Hallazgo | Severidad | Confianza (0-100%) | archivo:línea | Recomendación |
+```
+
+Presupuesto: `max_hallazgos_por_persona = presupuesto_total / num_personas`
+(default presupuesto 40 → 8 por persona). Obliga a priorizar, no a enumerar.
+
+---
+
+## Set default (análisis predictivo estándar)
+
+### 1. Arquitecto de Software
+- **Enfoque**: diseño sistémico, fronteras de componentes, flujo de datos, escalabilidad.
+- **Preguntas guía**: ¿Escala? ¿Los límites entre módulos son limpios? ¿El acoplamiento está minimizado? ¿Sobrevive un crecimiento 10x?
+- **Evidencia exigida**: archivo:línea, grafo de dependencias, métricas de acoplamiento.
+- **Red flags**: god classes, dependencias circulares, abstracciones con fugas, estado mutable compartido.
+
+### 2. Analista de Seguridad
+- **Enfoque**: superficies de ataque, autenticación/autorización, protección de datos, vectores de inyección.
+- **Preguntas guía**: ¿Es explotable? ¿Los trust boundaries se aplican? ¿El input se sanitiza? ¿Los secretos están protegidos?
+- **Evidencia exigida**: archivo:línea + escenario de ataque concreto (no especulación teórica).
+- **Red flags**: SQL crudo, authz faltante, secretos hardcodeados, input sin sanitizar.
+
+### 3. Ingeniero de Rendimiento
+- **Enfoque**: latencia, throughput, uso de recursos, complejidad algorítmica.
+- **Preguntas guía**: ¿Es suficientemente rápido? ¿Cuál es el peor caso? ¿Dónde están los cuellos de botella? ¿El caching es efectivo?
+- **Evidencia exigida**: archivo:línea, análisis de complejidad, estimaciones de recursos.
+- **Red flags**: queries N+1, loops sin cota, índices faltantes, I/O síncrono en hot paths.
+
+### 4. Ingeniero de Confiabilidad
+- **Enfoque**: manejo de errores, modos de falla, observabilidad, recuperación.
+- **Preguntas guía**: ¿Qué pasa cuando falla? ¿Podemos detectarlo? ¿Hay camino de recuperación? ¿Es observable?
+- **Evidencia exigida**: archivo:línea, escenarios de falla, rutas de recuperación.
+- **Red flags**: errores tragados, retries faltantes, sin circuit breakers, fallas silenciosas.
+
+### 5. Abogado del Diablo
+- **Enfoque**: asunciones, casos límite, complejidad oculta, mantenibilidad.
+- **Preguntas guía**: ¿Qué asunciones son falsas? ¿Qué rompe esto? ¿Está sobre-ingenierizado?
+- **Evidencia exigida**: contraejemplos concretos, escenarios de caso límite.
+- **Red flags**: diseño solo-happy-path, asunciones sin probar, complejidad sin justificación.
+
+---
+
+## Set adversarial (`--adversarial`)
+
+Reemplaza al set default cuando el objetivo es estresar el cambio como atacante,
+no como revisor.
+
+### 1. El Rompedor
+Intenta crashear o corromper el sistema. Busca: estados imposibles, inputs
+malformados, condiciones de carrera, límites de recursos.
+
+### 2. El Tramposo
+Busca formas de saltarse reglas y abusar de features. Busca: validaciones solo
+en frontend, límites evadibles, flujos alternos sin guards.
+
+### 3. El Escalador
+Imagina carga 1000x y encuentra qué se rompe primero. Busca: queries sin
+paginación, locks globales, colas sin backpressure, costos lineales ocultos.
+
+### 4. El Novato
+Usa mal cada API esperando que funcione. Busca: defaults peligrosos, errores
+crípticos, documentación que asume contexto, footguns de la interfaz.
+
+### 5. El Insider Malicioso
+Tiene credenciales válidas y quiere exfiltrar. Busca: permisos excesivos,
+auditoría faltante, datos sensibles accesibles lateralmente.
+
+---
+
+## Set red-team de seguridad (para `checklist-seguridad` modo cobertura)
+
+Rotación de mentalidades para auditoría STRIDE/OWASP iterativa:
+
+| Persona | Foco | Mentalidad |
+|---------|------|-----------|
+| Adversario de Seguridad | auth, crypto, inyección | atacante externo con browser + proxy de intercepción |
+| Atacante de Supply Chain | dependencias, CI/CD, build pipeline | comprometer vía código de terceros |
+| Amenaza Interna | acceso a datos, abuso de privilegios, exfiltración | usuario autenticado con intención maliciosa |
+| Atacante de Infraestructura | red, configuración cloud, contenedores | apuntar a misconfigurations de infra |
+
+---
+
+## Protocolo de síntesis (tras el análisis individual)
+
+1. **Deduplicar**: mismo archivo:línea + mismo problema → fusionar, conservar la severidad más alta.
+2. **Resolver conflictos**: si dos personas discrepan → registrar el disenso, no silenciarlo.
+3. **Anti-herd check**: si TODAS las personas coinciden → el sintetizador DEBE producir ≥1 contraargumento.
+4. **Rankear**: `severidad × confianza promedio × número de personas que coinciden`.
+
+Output del sintetizador:
+
+```markdown
+### Consenso — [N hallazgos tras dedup]
+| # | Hallazgo | Severidad | Acuerdo | Personas origen | Acción |
+```

package/habilidades/proceso-dynamic-workflows/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: proceso-dynamic-workflows
+description: >
+  Patrones canónicos de dynamic workflows en Claude Code (Workflow tool / ultracode):
+  classify-and-act, fan-out-and-synthesize, adversarial-verification, generate-and-filter,
+  tournament. Cubre los 3 modos de falla que justifican orquestar (agentic laziness,
+  self-preferential bias, goal drift), cuándo NO usar workflows, token budgets, revisión
+  cross-modelo, y el anti-patrón de envolver skills auto-iterantes en /loop|/cron. Cargar
+  cuando se diseñe una orquestación multi-agente, se decida si una tarea amerita workflow,
+  o se quiera empaquetar un workflow como plantilla reutilizable en un skill.
+when_to_use: >
+  Usar cuando el usuario diga "ultracode", "workflow", "orquesta esto", "fan-out", "panel
+  de revisores", "tournament", o cuando una tarea sea larga, masivamente paralela o
+  adversarial y un solo context window sufra laziness/goal-drift.
+herramientasPermitidas: [Read, Grep, Glob]
+exclusiones:
+  - "No cargar para tareas de codificación normales de un solo paso — la mayoría NO necesitan un workflow; el harness por defecto basta y un workflow gasta muchos más tokens."
+  - "No cargar para el detalle de evaluator-optimizer del nemesis — eso vive en nemesis-evaluacion-json y el comando /swl:nemesis."
+  - "No cargar para escribir el .js de un workflow concreto — este skill da los patrones; el script se escribe con el Workflow tool directamente."
+---
+
+# Dynamic workflows: patrones, modos de falla y cuándo orquestar
+
+Síntesis del blog oficial de Anthropic *"A harness for every task: dynamic workflows
+in Claude Code"* + patrones validados en swl-ses (nemesis evaluator-optimizer,
+`/swl:verificar --until-converge`, `/swl:autoresearch`). Un dynamic workflow deja que
+Claude escriba su propio harness (JS que coordina subagentes con ventanas aisladas).
+
+## Cuándo cargar
+
+- Se va a diseñar una orquestación multi-agente o decidir si una tarea amerita workflow.
+- La tarea es larga, masivamente paralela, o adversarial (review, research, migración, triage).
+- Se quiere empaquetar un workflow como plantilla reutilizable en un skill.
+
+## Cuándo NO cargar
+
+- Tarea de codificación normal de 1-2 archivos — el harness por defecto basta. Un workflow
+  gasta significativamente más tokens; la mayoría de tareas de coding NO necesitan un panel
+  de 5 revisores.
+- Ya estás dentro del detalle del nemesis (`nemesis-evaluacion-json`).
+- Solo necesitas escribir el `.js` — usa el Workflow tool directo con los patrones de abajo.
+
+## Los 3 modos de falla que JUSTIFICAN orquestar
+
+Un solo context window largo degrada de tres formas — nombrarlas guía cuándo separar Claudes:
+
+1. **Agentic laziness** — Claude se detiene antes de terminar una tarea multi-parte y la
+   declara hecha con progreso parcial (ej. 20 de 50 ítems de un security review). Mitiga:
+   fan-out (un subagente por ítem, ventana limpia) + `/goal` (requisito de completitud duro).
+2. **Self-preferential bias** — Claude prefiere sus propios resultados al verificarlos contra
+   un rubric. Mitiga: **adversarial-verification** con subagente separado, y mejor aún
+   **revisión cross-modelo** (el reviewer es OTRO modelo). Es el mismo principio que
+   `gobernanza.md § Separación revisor/ejecutor`.
+3. **Goal drift** — pérdida gradual de fidelidad al objetivo tras muchos turnos y compaction
+   (cada resumen es lossy; se pierde "no hagas X"). Mitiga: subagentes con goal aislado y
+   constraints explícitas por invocación; `/goal` como ancla.
+
+## Los 5 patrones canónicos
+
+| Patrón | Cuándo | Forma |
+|--------|--------|-------|
+| **Classify-and-act** | Rutear según tipo de tarea/ítem | Clasificador → ramas distintas (al inicio o al final para decidir output) |
+| **Fan-out-and-synthesize** | Muchos sub-pasos; cada uno se beneficia de ventana limpia sin cross-contaminación | N agentes en paralelo → barrier → synthesize merge. **Default** para descomponer |
+| **Adversarial-verification** | Evitar self-preferential bias | Por cada agente, un agente separado verifica su output contra rubric. Diversificar lentes |
+| **Generate-and-filter** | Espacio de ideas amplio (taste-based) | Generar N → filtrar por rubric/verificación → dedupe → solo las mejores probadas |
+| **Tournament** | Solución taste-based con criterio | N agentes compiten con enfoques distintos → juez pairwise hasta ganador |
+
+`pipeline()` (sin barrier entre stages) es el default; usa barrier (`parallel()` entre
+stages) SOLO cuando el stage N necesita TODOS los resultados del N-1 (dedup global,
+early-exit por conteo cero, comparación cruzada).
+
+## Revisión cross-modelo (combate self-preferential bias estructuralmente)
+
+El reviewer adversarial en el MISMO modelo aún arrastra sesgo. La mejora: **executor en un
+modelo, reviewer en otro** (Claude ejecuta → Gemini/Codex/otro revisa). Patrón de ARIS
+(`mcp-servers/gemini-review`): MCP que expone `review`/`review_reply`, devuelve JSON con
+`threadId` + `response` → rastro auditable de un veredicto independiente.
+
+En swl-ses esto es **opt-in** vía `/swl:nemesis --cross-model` (ver el comando): si hay un
+MCP reviewer configurado, la verificación se rutea a un modelo externo; si no, degrada al
+reviewer same-model sin fallar (regla `arreglar-al-detectar.md` / no-fallback-silencioso →
+se anuncia la degradación). Mejoras del reviewer (de ARIS `auto-review-loop`):
+- **Reviewer memory**: el reviewer arrastra sus sospechas entre rondas (un solo `threadId`),
+  no parte de cero cada iteración.
+- **Debate protocol**: el executor puede rebatir; el reviewer falla el veredicto final —
+  *"it can drive, never acquit"* (el loop conduce, el jurado decide).
+- **POSITIVE_THRESHOLD compuesto**: `score ≥ N` **AND** `verdict ∈ {ready, almost}` — un
+  score alto con verdict "not ready" NO detiene el loop.
+
+## Anti-patrón: no envolver un skill auto-iterante en /loop · /cron · /schedule
+
+Si un skill YA itera internamente (review→fix→re-review con memoria de reviewer en un
+`threadId`), envolverlo en `/loop`, `/schedule` o `CronCreate` lo re-entra desde cero cada
+tick → `threadId` nuevo, memoria del reviewer reseteada → dispara el veredicto por
+wall-clock en vez de por cambio de artefacto: cero señal nueva, costo de tokens completo.
+Aplica a `/swl:autoresearch`, `/swl:verificar --until-converge`, nemesis `--remediar`. Si
+hay que agendar algo, agenda **la espera externa que lo precede** (ej. experimentos listos →
+entonces corre el loop UNA vez), no el loop mismo.
+
+## Token budgets, /goal y model routing
+
+- **Token budget en workflows**: el global `budget` (o "use 10k tokens" en el prompt) pone
+  cap duro. Alinea con `scripts/lib/budget-enforcer.js` de swl-ses.
+- **/goal + /loop**: para workflows repetibles (triage, research, verificación), `/goal` da
+  requisito de completitud y `/loop` la cadencia. NO sobre skills auto-iterantes (arriba).
+- **Dynamic model routing**: un agente clasificador investiga la complejidad real del scope
+  y rutea a Sonnet vs Opus por tarea (más fino que el Model-Tier estático del frontmatter).
+
+## Workflows como plantillas en skills
+
+Un `.js` de workflow puede vivir en `recursos/` de un skill y referenciarse en su SKILL.md
+como **plantilla** (no script verbatim) — Claude lo adapta al caso. Plantillas incluidas:
+
+- `recursos/template-adversarial-verify.js` — fan-out de hallazgos + verificación adversarial
+  por hallazgo (filtra los reales).
+- `recursos/template-triage.js` — clasifica ítems de un backlog, dedupe contra lo ya
+  trackeado, y rutea (fix automático vs escalar a humano) con patrón quarantine.
+
+## Quarantine (triage de contenido no confiable)
+
+En triage que lee contenido público/no confiable, los agentes lectores quedan **barred** de
+acciones de alto privilegio; esas las ejecutan agentes distintos que actúan sobre la info ya
+saneada. Coherente con `seguridad-agentes.md § Prompt injection` y el quarantine de SWL.
+
+## Gotchas
+
+- **Workflows gastan más tokens** — úsalos cuando la tarea de verdad necesita más cómputo
+  (adversarial, masivamente paralela), no por reflejo.
+- **Subagentes heredan el contexto del padre** (CLAUDE.md + reglas globales). En proyectos
+  rule-heavy pueden saturar al arrancar (autocompact thrashing). Pasa scope acotado y evita
+  hacer que el subagente explore el codebase completo (ver `harness-claude-code`).
+- **Barrier injustificado** mata wall-clock: si no hay dependencia cross-ítem entre stages,
+  usa `pipeline()`, no `parallel()` entre stages.
+
+## Origen
+
+Adoptado 2026-06-05 desde análisis de `temp/` (blog Anthropic dynamic-workflows +
+ARIS `auto-review-loop`/`mcp-servers`). Ver APRENDIZAJES.md Tipo D 2026-06-05.

package/habilidades/proceso-dynamic-workflows/recursos/template-adversarial-verify.js

@@ -0,0 +1,65 @@
+// PLANTILLA (no ejecutar verbatim) — Workflow tool de Claude Code.
+// Patrón: fan-out de hallazgos -> verificación adversarial por hallazgo -> filtrar reales.
+// Combate self-preferential bias y agentic laziness. Adapta DIMENSIONS, rubrics y schemas.
+//
+// Uso: el agente lee esta plantilla, la ajusta al caso concreto y la pasa al Workflow tool.
+
+export const meta = {
+  name: 'adversarial-verify',
+  description: 'Revisa por dimensiones y verifica cada hallazgo adversarialmente antes de aceptarlo',
+  phases: [{ title: 'Review' }, { title: 'Verify' }],
+}
+
+// Dimensiones de revisión — una por lente independiente (no se contaminan entre sí).
+const DIMENSIONS = [
+  { key: 'correctness', prompt: 'Revisa SOLO correctness del scope. Devuelve hallazgos.' },
+  { key: 'security', prompt: 'Revisa SOLO seguridad del scope. Devuelve hallazgos.' },
+  { key: 'dry', prompt: 'Revisa SOLO duplicación/DRY del scope. Devuelve hallazgos.' },
+]
+
+const FINDINGS = {
+  type: 'object', additionalProperties: false,
+  properties: {
+    findings: {
+      type: 'array',
+      items: {
+        type: 'object', additionalProperties: false,
+        properties: {
+          title: { type: 'string' }, file: { type: 'string' }, line: { type: 'string' },
+          severity: { type: 'string', enum: ['critico', 'mayor', 'menor'] },
+        },
+        required: ['title', 'file', 'severity'],
+      },
+    },
+  },
+  required: ['findings'],
+}
+
+const VERDICT = {
+  type: 'object', additionalProperties: false,
+  properties: {
+    isReal: { type: 'boolean' },
+    reason: { type: 'string' },
+  },
+  required: ['isReal', 'reason'],
+}
+
+// pipeline (sin barrier): cada dimensión verifica sus hallazgos en cuanto su review termina.
+const results = await pipeline(
+  DIMENSIONS,
+  (d) => agent(d.prompt, { label: `review:${d.key}`, phase: 'Review', schema: FINDINGS }),
+  (review, d) =>
+    parallel(
+      (review?.findings || []).map((f) => () =>
+        // Verificador adversarial: prompt orientado a REFUTAR (default refutado si dudoso).
+        agent(
+          `Intenta REFUTAR este hallazgo contra el código real (cita archivo:linea). ` +
+          `Si no puedes probarlo, isReal=false: ${JSON.stringify(f)}`,
+          { label: `verify:${f.file}`, phase: 'Verify', schema: VERDICT }
+        ).then((v) => ({ ...f, verdict: v }))
+      )
+    )
+)
+
+const confirmados = results.flat().filter(Boolean).filter((f) => f.verdict?.isReal)
+return { confirmados }

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

@@ -0,0 +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)