PRD inicial

# PRD inicial — [Nombre del proyecto]

> Entregable de la fase 2 (F2.1). Es **un solo documento**: la definición que el prototipo de la
> fase 3 materializa y que se itera con él. En F3.4, con el prototipo aprobado, se parte en PRD
> (Product Requirements Document) de negocio y PRD técnico.
>
> Nace del **Documento de Entendimiento** (F1.2) y debe pasar la validación de F2.3 antes de que
> se construya el prototipo.
>
> **IDs estables:** cada requisito y cada métrica llevan un ID (`RF-1`, `MET-1`) que **no cambia
> nunca** — ni al reordenar el documento ni al partirlo en dos. El prototipo traza a esos IDs, no
> a números de sección; es lo que mantiene viva la trazabilidad después de F3.4.

## 1. Resumen

[Qué es el producto en tres frases: qué problema resuelve, para quién y qué cambia cuando existe.
Sale del §1 del Documento de Entendimiento.]

## 2. Usuarios objetivo

| Usuario | Contexto | Qué le resuelve el producto |
|---|---|---|
| [Tipo de usuario 1] | [Su situación] | [Lo que gana] |

## 3. Requisitos funcionales

> El **qué**, no el **cómo**. El comportamiento detallado —estados, validaciones, mensajes,
> permisos, casos límite— vive en las specs, nunca aquí (ver `../methodology/workflow.md` →
> *Las capas de la definición*).

| ID | Requisito | Usuario | Prioridad |
|---|---|---|---|
| RF-1 | [Qué debe poder hacerse] | [Quién] | Debe / Debería / Podría |
| RF-2 | | | |

> Si el proyecto se entrega **por hitos** (`../methodology/hitos.md`), la tabla lleva una columna
> **Hito** (`H-1`, `H-2`, …): los requisitos del hito en curso van completos y los de los
> siguientes, como contorno.

## 4. Flujos principales

Los recorridos que el prototipo debe representar.

| Flujo | Pasos | Requisitos que cubre |
|---|---|---|
| [Nombre del flujo] | [Paso 1 → paso 2 → paso 3] | RF-1, RF-2 |

## 5. Métricas de éxito

| ID | Métrica | Objetivo | Cómo se mide |
|---|---|---|---|
| MET-1 | [Métrica] | [Valor objetivo] | [Fuente del dato] |

## 6. Alcance del PMV

### Incluido

- [Funcionalidad esencial 1]

### Explícitamente fuera de alcance

> Sección obligatoria. Lo que no se escribe aquí se discute después, cuando ya es caro.

- [Lo que NO se construye en el PMV y por qué]

## 7. Restricciones y supuestos

[Heredados del §4 del Documento de Entendimiento, actualizados con lo que se haya aprendido.]

## 8. Notas técnicas preliminares

[Lo que ya se sabe del stack, las integraciones o la infraestructura existente. Son **notas**, no
decisiones: el stack lo propone el PRD técnico (F3.4) y lo valida el arquitecto (F4.2).]

## 9. Preguntas abiertas

> Heredadas del §5 del Documento de Entendimiento. El prototipo es el instrumento con el que se
> cierran: cada una debería tener un bloque del prototipo donde se le pregunta al stakeholder.

| # | Pregunta | Qué bloquea | Dónde se pregunta en el prototipo |
|---|---|---|---|
| 1 | [La duda] | [Qué no se puede decidir sin ella] | [Bloque / pantalla] |

---

## Checklist de validación (F2.3)

- [ ] El problema está claramente definido
- [ ] Los usuarios objetivo están identificados
- [ ] Cada requisito y cada métrica tienen su ID estable
- [ ] El alcance del PMV (Producto Mínimo Viable) y lo que queda fuera están explícitos
- [ ] Las métricas de éxito son medibles
- [ ] Las preguntas abiertas de la fase 1 están recogidas
- [ ] **Aprobación humana explícita**: ____________ (fecha y quién)

---

## Después: la explosión en dos PRDs (F3.4)

Cuando el prototipo se apruebe, este documento se reparte así —los IDs viajan con el requisito:

| De aquí | Va al |
|---|---|
| §1 Resumen, §2 Usuarios, §3 Requisitos, §4 Flujos, §5 Métricas, §6 Alcance | PRD de negocio |
| §7 Restricciones técnicas, §8 Notas técnicas | PRD técnico |
| §9 Preguntas abiertas | Al documento que corresponda; las que se cerraron se anotan como decisión en `decisiones.md` |