# 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 |
```
