# PROJECT: [Nombre del Proyecto]

> Documento vivo. Actualizar cuando cambie el alcance, el equipo o las restricciones.
> Versión: 0.1 | Última actualización: YYYY-MM-DD | Autor: [nombre]

---

## Visión

[Una sola frase que describe el producto terminado y el valor que entrega.
Debe ser comprensible para alguien externo al proyecto.]

Ejemplo: "Sistema web que permite a las PyMEs emitir facturas electrónicas CFDI 4.0
de forma autónoma, sin depender de un contador externo para el proceso cotidiano."

---

## Contexto y motivación

[2-4 párrafos describiendo el problema actual. Por qué existe este proyecto.
Qué está roto, es ineficiente o falta en el estado actual. Quién sufre el problema
y cómo lo sufre hoy. Datos cuantitativos si están disponibles.]

**Problema actual:**


**Impacto del problema:**


**Por qué ahora:**


---

## Objetivos

Resultados medibles que este proyecto debe alcanzar. Cada objetivo tiene un
criterio de éxito verificable.

| # | Objetivo | Criterio de éxito | Prioridad |
|---|----------|-------------------|-----------|
| O1 | [Qué se quiere lograr] | [Cómo saber que se logró] | Alta |
| O2 | | | Alta |
| O3 | | | Media |
| O4 | | | Baja |

---

## No-objetivos (fuera del alcance)

Explicitar lo que este proyecto NO hace evita scope creep y alinea expectativas.

- **No:** [Funcionalidad que parece relacionada pero está fuera del alcance]
  *Razón: [por qué está fuera]*
- **No:** [Integración o caso de uso que se excluye explícitamente]
  *Razón: [dependencia futura, proyecto separado, etc.]*
- **No:** [Tipo de usuario o mercado que no se atiende en esta fase]
  *Razón: [foco, recursos, etc.]*

---

## Restricciones

Límites no negociables que la solución debe respetar.

### Técnicas
- [Restricción de plataforma, lenguaje o framework mandatorio]
- [Restricción de integración con sistema existente]
- [Restricción de performance o disponibilidad]

### De negocio
- [Restricción regulatoria o de compliance]
- [Restricción de tiempo — fecha de entrega fija]
- [Restricción de presupuesto o recursos]

### Asunciones
[Lo que se asume como verdadero para que el proyecto tenga sentido.
Si alguna asunción resulta falsa, el proyecto requiere revisión.]
- Se asume que [condición del contexto].
- Se asume que [comportamiento del usuario].
- Se asume que [disponibilidad de recurso externo].

---

## Stack tecnológico

| Capa | Tecnología | Versión | Justificación |
|------|-----------|---------|---------------|
| Backend | [ej. FastAPI] | [ej. 0.111] | [por qué] |
| ORM / BD | [ej. SQLAlchemy + PostgreSQL] | [versión] | [por qué] |
| Frontend | [ej. Angular] | [versión] | [por qué] |
| Auth | [ej. JWT + OAuth2] | — | [por qué] |
| Infraestructura | [ej. Docker + Kubernetes] | — | [por qué] |
| CI/CD | [ej. GitHub Actions] | — | [por qué] |
| Observabilidad | [ej. Sentry + Grafana] | — | [por qué] |

Ver investigación detallada en: `research/STACK.md`

---

## Equipo

| Rol | Nombre | Responsabilidad |
|-----|--------|-----------------|
| Tech Lead | [nombre] | Decisiones arquitecturales, reviews |
| Backend Dev | [nombre] | API, base de datos, lógica de negocio |
| Frontend Dev | [nombre] | UI, componentes, integración de API |
| QA | [nombre] | Tests de aceptación, regresión |
| Product Owner | [nombre] | Priorización, criterios de aceptación |
| Stakeholder | [nombre/área] | Aprobación final, presupuesto |

---

## Links y recursos

- Repositorio: [URL]
- Tablero de tareas: [URL]
- Entorno de staging: [URL]
- Documentación API: [URL]
- Canal de comunicación: [Slack/Teams channel]
- ADRs: `docs/adr/`
- Investigación técnica: `research/`