Documento de Entendimiento

# Documento de Entendimiento — [Nombre del proyecto]

> Entregable de la fase 1 (F1.2). Es la síntesis **del problema, no de la solución**, y el
> insumo directo del primer PRD (Product Requirements Document).
>
> **Frontera:** acá no van requisitos funcionales, specs ni decisiones de stack. Si algo así
> aparece durante la exploración, se registra en §7 como decisión tomada —con su porqué—, no
> como requisito.
>
> **Confidencialidad:** se nutre de `initial-references/` (confidencial, en `.gitignore`) pero
> no copia datos sensibles: este documento se versiona.
>
> Debe pasar la validación de F1.2 antes de que el proyecto avance a la fase 2.

## 1. Problema y contexto

[Qué problema existe, a quién le duele, qué pasa hoy cuando ocurre y por qué ahora. En lenguaje
de negocio, sin tecnología.]

## 2. Usuarios y sus trabajos

Quién usa esto y qué intenta lograr — el trabajo, no la funcionalidad.

| Usuario | Contexto | Qué intenta lograr | Cómo lo resuelve hoy |
|---|---|---|---|
| [Tipo de usuario 1] | [Su situación] | [El trabajo que necesita hacer] | [Su solución actual y qué le falla] |
| [Tipo de usuario 2] | | | |

## 3. Alcance y no-alcance

**Qué es este producto:**
- [Lo que sí cubre]

**Qué no es:**
- [Lo que queda deliberadamente fuera, y por qué]

> El no-alcance es tan importante como el alcance: es lo que impide que el PRD crezca sin decisión.

**Mapa de hitos** *(solo si el proyecto se entrega en más de un bloque contratado por separado —
ver `../methodology/hitos.md`; si no, borrar esta tabla):*

| Hito | Promesa | Incluye | Deja fuera | Habilita |
|---|---|---|---|---|
| `H-1` | [Qué puede hacer el usuario al terminarlo] | [Rasgos principales] | [Lo que se pospone, y a qué hito] | [Qué desbloquea] |
| `H-2` | | | | |

## 4. Restricciones y supuestos

**Restricciones** (lo que no se puede cambiar: presupuesto, plazos, sistemas existentes, normativa):
- [Restricción 1 — de dónde viene]

**Supuestos** (lo que se está dando por cierto sin confirmar todavía):
- [Supuesto 1 — qué pasa si resulta falso]

## 5. Riesgos y preguntas abiertas

Los huecos honestos. **Se heredan al primer PRD** — no desaparecen acá.

| # | Riesgo o pregunta abierta | Impacto | Cómo se resuelve / quién responde |
|---|---|---|---|
| 1 | [El hueco] | [Qué se rompe si no se resuelve] | [Acción o persona] |

## 6. Glosario / lenguaje ubicuo

Los términos del dominio con el significado que tienen **en este proyecto**. El código, los
PRDs y la UI (interfaz de usuario) usan estas mismas palabras.

| Término | Significado en este proyecto |
|---|---|
| [Término] | [Qué significa acá, y qué no] |

## 7. Decisiones tomadas durante la exploración

Lo que ya se decidió y condiciona todo lo que sigue, con su porqué. Las decisiones de
arquitectura, proceso o producto se anotan además en el `decisiones.md` del proyecto (log
append-only — ver `operations.md` de Argui).

| Fecha | Decisión | Por qué |
|---|---|---|
| [AAAA-MM-DD] | [Qué se decidió] | [La razón] |

## Validación (F1.2 ✋)

Aprobación ligera del humano, sin checklist de agente. Se confirman tres cosas:

- [ ] El **alcance y el no-alcance** son los correctos.
- [ ] Los **riesgos y preguntas abiertas** listados son los reales (y no falta ninguno grande).
- [ ] El **problema** está bien encuadrado: es el que hay que resolver.

Con eso aprobado, el proyecto pasa a la fase 2.