# SUMMARY: Resumen Ejecutivo de Investigación — [Nombre del Proyecto]

> Este documento consolida los hallazgos de toda la investigación técnica y
> presenta las recomendaciones finales para tomar decisiones informadas.
> Es el punto de entrada para el planificador y el equipo.
> Autor: [nombre] | Fecha: YYYY-MM-DD | Estado: Borrador / Final

---

## TL;DR — Lo más importante

[3-5 bullets con los hallazgos más críticos y las recomendaciones clave.
Alguien que solo lea esto debe poder tomar decisiones informadas.]

- **Stack recomendado**: [tecnologías principales] — madurez probada, equipo familiarizado.
- **Mayor riesgo técnico**: [descripción en una línea] — mitigación disponible.
- **Feature más compleja**: [nombre] — requiere spike de [N] días antes de comprometerse.
- **Decisión más urgente**: [qué debe decidirse antes de empezar a codificar].
- **Estimación total**: [N] semanas con [M] desarrolladores en [P] fases.

---

## Stack tecnológico — Decisión final

| Capa | Tecnología elegida | Confianza | Alternativa descartada |
|------|-------------------|-----------|------------------------|
| Backend | [ej. FastAPI 0.111 + Python 3.12] | Alta | [Django — overhead para API-only] |
| Base de datos | [ej. PostgreSQL 16] | Alta | [MySQL — menor soporte para JSONB] |
| Frontend | [ej. Angular 18] | Alta | [React — consistencia con stack actual] |
| Cache | [ej. Redis 7] | Alta | [Memcached — estructuras de datos limitadas] |
| Infraestructura | [ej. Docker + GCP Cloud Run] | Media | [VMs — mayor mantenimiento operativo] |

**Ver análisis detallado**: `research/STACK.md`

---

## Análisis de complejidad de features

### Features de alta prioridad (P0-P1)

| Feature | Complejidad | Esfuerzo estimado | Riesgo principal |
|---------|-------------|-------------------|-----------------|
| [Nombre] | [S/M/L/XL] | [N días] | [descripción del riesgo] |
| [Nombre] | | | |
| [Nombre] | | | |

### Features de media-baja prioridad (P2-P3)

| Feature | Complejidad | Esfuerzo estimado | Fase sugerida |
|---------|-------------|-------------------|---------------|
| [Nombre] | | | Fase [N] |
| [Nombre] | | | Fase [N] |

**Ver análisis detallado**: `research/FUNCIONALIDADES.md`

---

## Arquitectura — Resumen de decisiones

**Estilo adoptado**: [ej. Monolito modular con separación de capas + SPA Angular]

**Decisiones más importantes**:

1. **[Decisión 1]**: [Qué se decide y por qué — 2 líneas máximo]
2. **[Decisión 2]**: [Qué se decide y por qué]
3. **[Decisión 3]**: [Qué se decide y por qué]

**ADRs a redactar** (en orden de prioridad):
- [ ] ADR-001: [Título de la decisión]
- [ ] ADR-002: [Título]
- [ ] ADR-003: [Título]

**Ver arquitectura detallada**: `research/ARQUITECTURA.md`

---

## Riesgos identificados

| # | Riesgo | Severidad | Mitigación recomendada |
|---|--------|-----------|------------------------|
| R1 | [Riesgo técnico específico] | Alta | [Acción concreta] |
| R2 | [Riesgo de integración] | Alta | [Acción concreta] |
| R3 | [Riesgo de estimación — feature puede ser más compleja] | Media | [Spike de N días primero] |
| R4 | [Riesgo de dependencia externa] | Media | [Plan B] |
| R5 | [Riesgo de equipo — conocimiento del stack] | Baja | [Capacitación / pair programming] |

**Ver catálogo de trampas**: `research/TRAMPAS.md`

---

## Estimación de esfuerzo total

**Metodología de estimación**: [T-shirt sizing / Story points / días ideales]

| Fase | Contenido | Esfuerzo estimado | Supuestos |
|------|-----------|-------------------|-----------|
| Fase 1 | [Qué features incluye] | [N semanas] | [Supuesto de estimación] |
| Fase 2 | | | |
| Fase 3 | | | |
| **Total** | | **[N] semanas** | |

**Con [M] desarrolladores**: [N/M semanas en paralelo ideal]

**Margen de contingencia recomendado**: +20% sobre el estimado base.

**Incertidumbre**: [Alta/Media/Baja]
- Alta: hay features con tecnología no conocida por el equipo o integraciones no exploradas
- Media: stack conocido, pero hay 1-2 integraciones que necesitan spike
- Baja: stack dominado, todas las integraciones son conocidas

---

## Preguntas que deben resolverse antes de iniciar

[Preguntas cuya respuesta cambia significativamente el diseño o el alcance.
Si no se resuelven antes de codificar, se acumula deuda de decisión.]

| # | Pregunta | Impacto si no se responde | Quién decide | Urgencia |
|---|----------|--------------------------|-------------|----------|
| P1 | [Pregunta técnica o de negocio específica] | [Qué parte del diseño queda bloqueada] | [Nombre/Rol] | Alta |
| P2 | | | | Alta |
| P3 | | | | Media |

---

## Recomendaciones para el planificador

[Recomendaciones específicas sobre cómo planificar la ejecución, basadas
en los hallazgos de la investigación.]

1. **Iniciar con spike técnico de [N] días** para validar [la integración X / la tecnología Y]
   antes de comprometer el equipo a la estimación completa.

2. **Feature [nombre] es el camino crítico** — cualquier retraso en esta feature
   retrasa todo lo demás. Debe iniciar en la Fase 1 sin importar qué.

3. **Contratar / capacitar en [tecnología]** antes de la Fase [N] — el equipo
   actual no tiene experiencia suficiente con [tecnología específica].

4. **No iniciar el frontend hasta que [condición]** — el API contract debe estar
   estable antes de invertir en componentes UI.

5. **Revisar este SUMMARY con el cliente** antes de iniciar — los supuestos de
   [supuesto X] deben ser validados por el stakeholder.

---

## Documentos de investigación completos

| Documento | Descripción | Estado |
|-----------|-------------|--------|
| `research/STACK.md` | Evaluación detallada de tecnologías | Completo / Pendiente |
| `research/FUNCIONALIDADES.md` | Análisis de complejidad por feature | Completo / Pendiente |
| `research/ARQUITECTURA.md` | Arquitectura propuesta con diagramas | Completo / Pendiente |
| `research/TRAMPAS.md` | Trampas y anti-patrones del stack | Completo / Pendiente |

---

## Próximos pasos recomendados

1. [ ] Aprobar (o ajustar) el stack tecnológico — responsable: [nombre], fecha límite: YYYY-MM-DD
2. [ ] Responder preguntas abiertas P1 y P2 — responsable: [nombre], fecha límite: YYYY-MM-DD
3. [ ] Ejecutar spike de [N] días para validar [integración X] — responsable: [nombre]
4. [ ] Redactar ADR-001 a ADR-003 — responsable: [nombre]
5. [ ] Crear HOJA-RUTA.md con fases basadas en estas estimaciones — responsable: planificador
