@saulwade/swl-ses 2.2.4 → 2.3.1

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/proceso-debate-adversarial/recursos/personas.md

@@ -1,105 +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 |
-```
+# 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 |
+```