@saulwade/swl-ses 1.8.0 → 2.0.0

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

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)

package/habilidades/protocolo-revision-swl/SKILL.md

@@ -242,7 +242,7 @@ El veredicto JSON se persiste en:
 .planning/audit/reviews/<task-id>-<timestamp>.json
 ```
 
-Esto permite que `auto-evolucion-swl` y `/swl:metricas` calculen tasas de
+Esto permite que `auto-evolucion-swl` y `/swl:status metricas` calculen tasas de
 APPROVED vs REJECTED por agente revisor y por tipo de tarea — datos
 necesarios para identificar revisores con calibración floja o tipos de
 tarea sistemáticamente problemáticos.

package/habilidades/seguridad-skills-ia/SKILL.md

@@ -29,7 +29,7 @@ archivos SKILL.md y scripts asociados.
 
 - Al ejecutar `/swl:crear-skill` — verificación pre-creación
 - Al ejecutar `/swl:plugins install` — gate de seguridad
-- Al auditar skills existentes con `/swl:salud`
+- Al auditar skills existentes con `/swl:status salud`
 - Al revisar skills generados por `auto-evolucion-swl`
 - Cuando se incorporan skills de `_userland/plugins/` al sistema base