PRD técnico

# PRD Técnico — [Nombre del proyecto]

> Audiencia: arquitecto, agentes implementadores, perfiles técnicos.
> Sale de partir el PRD inicial en dos, con el prototipo ya aprobado (F3.4).
> Este documento debe pasar la validación de F3.4 antes de que el proyecto avance.
> Las decisiones aquí planteadas son la base del trabajo del agente arquitecto (F4.2).
>
> **Frontera:** aquí va lo **estructural y transversal** —stack, arquitectura, modelo de datos,
> decisiones que cruzan el producto—. El comportamiento por capacidad vive en las specs, nunca aquí
> (ver `../methodology/workflow.md` → *Las capas de la definición*). Los IDs del PRD inicial
> (`RF-1`) **se conservan** y se referencian; no se reescribe el requisito.
>
> Es un **mapa vivo**: se corrige cuando el sistema cambia o cuando se aprende algo nuevo. Siempre
> es un snapshot actual — el historial vive en git.

## 1. Resumen técnico

[El problema desde la perspectiva técnica: qué hay que construir y cuál es el reto principal.]

## 2. Stack propuesto

| Capa | Tecnología | Justificación |
|---|---|---|
| Frontend | | |
| Backend | | |
| Base de datos | | |
| Infraestructura | | |
| Otros | | |

> El stack definitivo lo valida el arquitecto. Aquí va la propuesta con su razonamiento.

## 3. Arquitectura inicial

[Diagrama o descripción de alto nivel: componentes principales y cómo se comunican.]

## 4. Modelo de datos preliminar

[Entidades principales y sus relaciones. No el esquema completo — lo suficiente para dimensionar.]

> **Estructura, no reglas.** Qué entidades hay y cómo se relacionan va aquí; las reglas de negocio
> que operan sobre ellas —qué transiciones son válidas, qué se valida al guardar, quién puede
> verlas— son de las specs.

## 5. Integraciones

| Servicio externo | Para qué | Riesgo |
|---|---|---|
| | | |

## 6. Restricciones técnicas

[Lo que limita las decisiones: infraestructura existente, presupuesto de servicios, requisitos de rendimiento, compliance.]

## 7. Datos sensibles

> Qué maneja el producto que no puede terminar en un log, en una traza o en un tercero. Es la
> declaración contra la que se configura el **enmascarado del logger** y la retención
> (`../methodology/standards.md` §9), y contra la que el cuarto foco de la auditoría compara lo
> que los logs registran de verdad.

| Dato | Dónde vive | Qué se registra de él | Retención |
|---|---|---|---|
| [ej. correo del usuario] | [tabla/servicio] | [solo el ID, nunca el valor] | [la del producto] |

**Nunca se registra:** contraseñas, tokens, cookies de sesión, medios de pago, cuerpos de request
sin filtrar. Si el producto no maneja ningún dato sensible, se declara así — explícitamente.

## 8. Funcionalidades críticas

> Esta lista define qué requiere cobertura completa de tests (ver estándares de testing).

- [Funcionalidad crítica 1 — ej. autenticación]
- [Funcionalidad crítica 2 — ej. flujo principal de valor]

## 9. Ambigüedades conocidas

> Decisiones que este PRD (Product Requirements Document) no toma y que el arquitecto debe resolver antes del backlog.

- [Ambigüedad 1]
- [Ambigüedad 2]

---

## Checklist de validación (F3.4)

- [ ] Las restricciones técnicas están documentadas
- [ ] Los datos sensibles están declarados (o se declaró que no hay)
- [ ] Las funcionalidades críticas están identificadas
- [ ] Las ambigüedades conocidas están listadas para el arquitecto
- [ ] El stack propuesto tiene justificación
- [ ] **Aprobación humana explícita**: ____________ (fecha y quién)