## Debate de Roles

Un comando que permite que roles con diferentes experticias discutan y examinen trade-offs para derivar soluciones óptimas.

### Uso

```bash
/role-debate <Rol 1>,<Rol 2> [Tópico]
/role-debate <Rol 1>,<Rol 2>,<Rol 3> [Tópico]
```

### Ejemplos Básicos

```bash
# Trade-off entre Seguridad y Rendimiento
/role-debate security,performance
"Configuración de Expiración de Token JWT"

# Balance entre Usabilidad y Seguridad
/role-debate frontend,security
"Optimización de UX para Autenticación de 2 Factores"

# Discusión de selección de tecnología
/role-debate architect,mobile
"Selección entre React Native vs Flutter"

# Debate de tres partes
/role-debate architect,security,performance
"Pros y Contras de Microservicios"
```

### Principios Básicos del Debate

#### Directrices de Debate Constructivo

- **Respeto Mutuo**: Respetar la experiencia y perspectivas de otros roles
- **Basado en Hechos**: Debatir basado en datos y evidencia, no reacciones emocionales
- **Orientado a Soluciones**: Apuntar a mejores soluciones en lugar de criticar por criticar
- **Enfocado en Implementación**: Considerar factibilidad en lugar de idealismo

#### Requisitos de Calidad para Argumentos

- **Documentación Oficial**: Referenciar estándares, directrices y documentación oficial
- **Casos Empíricos**: Citaciones específicas de casos de éxito o falla
- **Evaluación Cuantitativa**: Comparaciones usando números y métricas cuando sea posible
- **Consideración de Series Temporales**: Evaluación de impactos a corto, mediano y largo plazo

#### Ética del Debate

- **Honestidad**: Reconocer los límites de tu experiencia
- **Apertura**: Flexibilidad hacia nueva información y perspectivas
- **Transparencia**: Declarar explícitamente fundamentos de juicio y suposiciones
- **Responsabilidad**: Mencionar riesgos de implementación de propuestas

### Proceso de Debate

### Fase 1: Declaración de Posición Inicial

Cada rol expresa independientemente opiniones desde su perspectiva profesional

- Presentación de recomendaciones
- Citación explícita de estándares y documentos como fundamentos
- Explicación de riesgos y problemas anticipados
- Definición de métricas de éxito

### Fase 2: Discusión Mutua y Refutación

Discusión cruzada entre roles

- Refutación constructiva de propuestas de otros roles
- Identificación de perspectivas pasadas por alto
- Clarificación de trade-offs
- Presentación de alternativas

### Fase 3: Búsqueda de Compromisos

Exploración de soluciones implementables

- Evaluación de la importancia de cada perspectiva
- Consideración de soluciones ganar-ganar
- Enfoque de implementación paso a paso
- Consideración de medidas de mitigación de riesgos

### Fase 4: Conclusión Integrada

Determinación de recomendaciones finales

- Solución acordada
- Hoja de ruta de implementación
- Métricas de éxito y métodos de medición
- Puntos de revisión futura

### Ejemplos de Formato de Salida

### Para Debate de 2 Roles

```text
Debate de Roles: Seguridad vs Rendimiento
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Tópico: Configuración de Expiración de Token JWT

Argumento del Rol de Seguridad:
"Se recomienda expiración corta de 15 minutos"

Fundamentos:
- Cumplimiento con OWASP JWT Security Cheat Sheet
- Minimizar ventana de daño en caso de filtración de token
- Limitar tiempo disponible para atacante

Preocupaciones:
- Expiración larga aumenta exponencialmente riesgo de ataque
- Expiración corta obligatoria para cumplimiento financiero

Métricas de Éxito:
- Tasa de incidentes de seguridad < 0.1%
- Tiempo promedio de detección de ataque < 5 minutos

Refutación del Rol de Rendimiento:
"Se recomienda expiración de 2 horas"

Fundamentos:
- Referencia a Google OAuth 2.0 Best Practices
- Evitar aumento de carga del servidor por reautenticación frecuente
- Minimizar interrupción de experiencia de usuario

Preocupaciones:
- Reautenticación de 15 minutos aumenta carga de API por 8x
- Desconexiones frecuentes en entornos móviles

Métricas de Éxito:
- Mantener tiempo de respuesta API < 200ms
- Uso de CPU del servidor < 60%

Discusión Mutua:
Seguridad → Rendimiento:
"Las pérdidas comerciales por brechas de seguridad son mayores que la carga del servidor.
Ejemplo: la brecha de Equifax costó $700 millones"

Rendimiento → Seguridad:
"Ambos se pueden lograr con mecanismo de refresh token.
Actualizaciones en segundo plano aseguran seguridad sin comprometer UX"

Seguridad → Rendimiento:
"Los refresh tokens también son objetivos de ataque. Implementación apropiada es prerequisito"

Rendimiento → Seguridad:
"Proponer enfoque por fases. 30 minutos para operaciones normales, 15 minutos para operaciones sensibles"

Búsqueda de Compromiso:
Entendimiento Común:
- Necesidad de balancear experiencia de usuario y seguridad
- Respuesta flexible basada en nivel de riesgo
- Consideración práctica de costos de implementación y operación

Elementos Ganar-Ganar:
- Utilización de mecanismo de refresh token
- Introducción por fases de autenticación basada en riesgo
- Complementación con función de auto-logout

Conclusión Integrada:
"Expiración de 30 minutos + refresh token + autenticación basada en riesgo"

Detalles de Implementación:
1. Access token: Expiración de 30 minutos
2. Refresh token: Expiración de 7 días
3. Operaciones de alto riesgo: Forzar reautenticación cada 15 minutos
4. Auto-logout después de 30 minutos de inactividad

Implementación Por Fases:
Semanas 1-2: Implementación básica de token de 30 minutos
Semanas 3-4: Agregar mecanismo de refresh token
Mes 2: Introducir autenticación basada en riesgo

Métricas de Éxito:
- Seguridad: Tasa de incidentes < 0.1%
- Rendimiento: Aumento de carga API < 20%
- UX: Satisfacción de usuario > 85%

Revisión Futura:
- Después de 3 meses: Evaluar patrones de ataque reales y condiciones de carga
- Después de 6 meses: Considerar migración a autenticación basada en riesgo más sofisticada
```

### Para Debate de 3 Roles

```text
Debate de Roles: Architect vs Security vs Performance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Tópico: Pros y Contras de Microservicios

Argumento del Rol Architect:
"Se recomiendan microservicios por fases"
Fundamentos: Límites de dominio claros, despliegue independiente, libertad en selección de tecnología

Preocupaciones del Rol Security:
"Complejidad de seguridad de comunicación entre servicios"
Fundamentos: Costos de gestión de API Gateway, mTLS, autenticación distribuida

Preocupaciones del Rol Performance:
"Aumento de latencia debido a comunicación de red"
Fundamentos: Problema N+1 por llamadas API internas, transacciones distribuidas

Discusión de Tres Partes:
Architect → Security: "Se puede controlar a través de gestión centralizada de API Gateway"
Security → Architect: "Riesgo de punto único de falla"
Performance → Architect: "La granularidad de división de servicios es importante"
...(la discusión continúa)

Conclusión Integrada:
"Diseño dirigido por dominio para división por fases + diseño security-first"
```

### Patrones de Debate Efectivos

### Selección de Tecnología

```bash
/role-debate architect,performance
"Selección de Base de Datos: PostgreSQL vs MongoDB"

/role-debate frontend,mobile
"Framework de UI: React vs Vue"

/role-debate security,architect
"Método de Autenticación: JWT vs Session Cookie"
```

### Decisiones de Diseño

```bash
/role-debate security,frontend
"Diseño de UX para Autenticación de Usuario"

/role-debate performance,mobile
"Optimización de Estrategia de Sincronización de Datos"

/role-debate architect,qa
"Estrategia de Testing y Diseño de Arquitectura"
```

### Problemas de Trade-off

```bash
/role-debate security,performance
"Nivel de Encriptación vs Velocidad de Procesamiento"

/role-debate frontend,performance
"UI Rica vs Velocidad de Carga de Página"

/role-debate mobile,security
"Conveniencia vs Nivel de Protección de Datos"
```

### Características de Debate Específicas del Rol

#### 🔒 Rol Security

```yaml
debate_stance:
  - Enfoque conservador (minimización de riesgos)
  - Enfocado en cumplimiento (cauteloso sobre desviaciones de estándares)
  - Suposición de peor escenario (perspectiva de atacante)
  - Enfoque en impacto a largo plazo (seguridad como deuda técnica)

typical_issues:
  - Trade-offs "Seguridad vs Conveniencia"
  - "Requisitos de cumplimiento obligatorio"
  - "Comparación de costo de ataque vs costo de defensa"
  - "Protección exhaustiva de privacidad"

evidence_sources:
  - Directrices OWASP
  - Frameworks NIST
  - Estándares de industria (ISO 27001, SOC 2)
  - Casos de ataque reales y estadísticas

debate_strengths:
  - Precisión en evaluación de riesgos
  - Conocimiento de requisitos regulatorios
  - Comprensión de métodos de ataque

potential_biases:
  - Conservadurismo excesivo (inhibir innovación)
  - Consideración insuficiente de UX
  - Subestimar costos de implementación
```

#### ⚡ Rol Performance

```yaml
debate_stance:
  - Decisiones basadas en datos (basadas en medición)
  - Enfocado en eficiencia (optimizar costo-efectividad)
  - Prioridad de experiencia de usuario (enfoque en velocidad percibida)
  - Mejora continua (optimización por fases)

typical_issues:
  - "Rendimiento vs Seguridad"
  - "ROI de costo de optimización vs efectividad"
  - "Escalabilidad actual vs futura"
  - "Experiencia de usuario vs eficiencia de sistema"

evidence_sources:
  - Métricas Core Web Vitals
  - Resultados de benchmark y estadísticas
  - Datos de impacto en comportamiento de usuario
  - Estándares de rendimiento de industria

debate_strengths:
  - Capacidad de evaluación cuantitativa
  - Identificación de cuellos de botella
  - Conocimiento de técnicas de optimización

potential_biases:
  - Subestimar seguridad
  - Consideración insuficiente de mantenibilidad
  - Optimización prematura
```

#### 🏗️ Rol Architect

```yaml
debate_stance:
  - Perspectiva a largo plazo (consideración para evolución del sistema)
  - Búsqueda de balance (optimización general)
  - Cambios por fases (gestión de riesgos)
  - Cumplimiento de estándares (preferencia por patrones probados)

typical_issues:
  - "Eficiencia a corto plazo vs mantenibilidad a largo plazo"
  - "Deuda técnica vs velocidad de desarrollo"
  - "Microservicios vs monolito"
  - "Adopción de nueva tecnología vs estabilidad"

evidence_sources:
  - Colecciones de patrones de arquitectura
  - Principios de diseño (SOLID, DDD)
  - Casos de sistemas a gran escala
  - Tendencias de evolución tecnológica

debate_strengths:
  - Capacidad de perspectiva general
  - Conocimiento de patrones de diseño
  - Predicción de impactos a largo plazo

potential_biases:
  - Generalización excesiva
  - Conservadurismo hacia nuevas tecnologías
  - Comprensión insuficiente de detalles de implementación
```

#### 🎨 Rol Frontend

```yaml
debate_stance:
  - Diseño centrado en usuario (prioridad UX primero)
  - Enfoque inclusivo (consideración de diversidad)
  - Enfoque en intuitividad (minimizar costos de aprendizaje)
  - Estándares de accesibilidad (cumplimiento WCAG)

typical_issues:
  - "Usabilidad vs Seguridad"
  - "Consistencia de diseño vs optimización de plataforma"
  - "Funcionalidad vs simplicidad"
  - "Rendimiento vs experiencia rica"

evidence_sources:
  - Investigación UX y resultados de pruebas de usabilidad
  - Directrices de accesibilidad
  - Estándares de sistema de diseño
  - Datos de comportamiento de usuario

debate_strengths:
  - Representación de perspectiva de usuario
  - Conocimiento de principios de diseño
  - Requisitos de accesibilidad

potential_biases:
  - Comprensión insuficiente de restricciones técnicas
  - Subestimar requisitos de seguridad
  - Subestimación de impacto de rendimiento
```

#### 📱 Rol Mobile

```yaml
debate_stance:
  - Especialización de plataforma (considerar diferencias iOS/Android)
  - Adaptación de contexto (en movimiento, operación con una mano)
  - Restricciones de recursos (batería, memoria, comunicación)
  - Cumplimiento de tienda (directrices de revisión)

typical_issues:
  - "Nativo vs multiplataforma"
  - "Soporte offline vs sincronización en tiempo real"
  - "Eficiencia de batería vs funcionalidad"
  - "Unificación de plataforma vs optimización"

evidence_sources:
  - iOS HIG / Android Material Design
  - Directrices de App Store / Google Play
  - Investigación UX móvil
  - Estadísticas de rendimiento de dispositivos

debate_strengths:
  - Comprensión de restricciones específicas de móvil
  - Conocimiento de diferencias de plataforma
  - Diseño de interfaz táctil

potential_biases:
  - Comprensión insuficiente de plataforma web
  - Subestimar restricciones del lado del servidor
  - Consideración insuficiente para entorno de escritorio
```

#### 🔍 Rol Analyzer

```yaml
debate_stance:
  - Enfocado en evidencia (datos primero)
  - Verificación de hipótesis (enfoque científico)
  - Pensamiento estructural (pensamiento de sistemas)
  - Eliminación de sesgos (búsqueda de objetividad)

typical_issues:
  - "Correlación vs causalidad"
  - "Tratamiento sintomático vs solución de raíz"
  - "Distinción entre hipótesis y hecho"
  - "Síntomas a corto plazo vs problemas estructurales"

evidence_sources:
  - Datos medidos y análisis de logs
  - Métodos estadísticos y resultados de análisis
  - Teoría de pensamiento de sistemas
  - Investigación de sesgos cognitivos

debate_strengths:
  - Capacidad de análisis lógico
  - Objetividad en evaluación de evidencia
  - Descubrimiento de problemas estructurales

potential_biases:
  - Parálisis de análisis (acción insuficiente)
  - Perfeccionismo (subestimar practicidad)
  - Absolutismo de datos
```

### Plantillas de Progresión de Debate

#### Plantilla de Declaración de Posición Fase 1

```text
Recomendación de [Nombre de Rol]:
"[Propuesta específica]"

Fundamentos:
- [Referencia a documentos/estándares oficiales]
- [Casos/datos empíricos]
- [Principios de campo profesional]

Efectos Esperados:
- [Efectos a corto plazo]
- [Efectos a mediano y largo plazo]

Preocupaciones/Riesgos:
- [Riesgos de implementación]
- [Riesgos operacionales]
- [Impactos en otros campos]

Métricas de Éxito:
- [Métrica medible 1]
- [Métrica medible 2]
```

#### Plantilla de Refutación Fase 2

```text
Refutación a [Rol Objetivo]:
"[Refutación específica a propuesta objetivo]"

Fundamentos de Refutación:
- [Perspectivas pasadas por alto]
- [Evidencia/casos contradictorios]
- [Preocupaciones del campo profesional]

Propuesta Alternativa:
"[Propuesta mejorada]"

Puntos de Compromiso:
- [Condiciones aceptables]
- [Posibilidad de implementación por fases]
```

#### Plantilla de Solución Integrada Fase 3

```text
Solución Integrada:
"[Propuesta final considerando preocupaciones de todos los roles]"

Consideraciones para Cada Rol:
- [Seguridad]: [Cómo se cumplen requisitos de seguridad]
- [Rendimiento]: [Cómo se cumplen requisitos de rendimiento]
- [Otros]: [Cómo se cumplen otros requisitos]

Hoja de Ruta de Implementación:
- Fase 1 (Inmediato): [Elementos de respuesta urgente]
- Fase 2 (Corto plazo): [Implementación básica]
- Fase 3 (Mediano plazo): [Implementación completa]

Métricas de Éxito y Métodos de Medición:
- [Métricas de éxito integradas]
- [Métodos/frecuencia de medición]
- [Tiempo de revisión]
```

### Lista de Verificación de Calidad de Debate

#### Calidad de Evidencia

- [ ] Referencias a documentos/estándares oficiales
- [ ] Casos/datos específicos presentados
- [ ] Distinción entre especulación y hecho
- [ ] Fuentes explícitamente declaradas

#### Constructividad del Debate

- [ ] Comprensión precisa de propuestas del oponente
- [ ] Refutación lógica en lugar de emocional
- [ ] Alternativas también presentadas
- [ ] Exploración de posibilidades ganar-ganar

#### Factibilidad de Implementación

- [ ] Factibilidad técnica considerada
- [ ] Costos/duración de implementación estimados
- [ ] Posibilidad de implementación por fases considerada
- [ ] Medidas de mitigación de riesgos presentadas

#### Integración

- [ ] Impactos en otros campos considerados
- [ ] Búsqueda de optimización general
- [ ] Perspectiva a largo plazo incluida
- [ ] Métricas de éxito medibles establecidas

### Colaboración con Claude

```bash
# Debate basado en documentos de diseño
cat system-design.md
/role-debate architect,security
"Discutir problemas de seguridad en este diseño"

# Debate de soluciones basado en problemas
cat performance-issues.md
/role-debate performance,architect
"Discutir soluciones fundamentales a problemas de rendimiento"

# Debate de selección de tecnología basado en requisitos
/role-debate mobile,frontend
"Discutir estrategia de UI unificada para iOS, Android y Web"
```

### Notas

- Los debates pueden tomar tiempo (más largo para tópicos complejos)
- Con 3+ roles, las discusiones pueden divergir
- Las decisiones finales deben ser tomadas por usuarios referenciando resultados de debate
- Para problemas urgentes, considerar rol único o multi-role primero