# Spec: [Título de la Feature]

> **Propósito:** Este documento transforma una idea borrosa en una especificación estructurada. Describe **qué** debe pasar, no **cómo**. Si contiene detalles de implementación (lenguajes, frameworks, APIs específicas), está mal escrito.
> **Cuándo usarlo:** Cada vez que una idea o requerimiento vaya a convertirse en trabajo de ingeniería.
> **Cómo usarlo:** Copia este archivo (ej. `specs/042-login-google.md`), completa cada sección reemplazando los campos `[entre corchetes]` y pasa el quality gate (`checklist-template.md`) antes de compartirlo.

## Metadatos

- **Autor:** [Tu Nombre]
- **Estado:** [Borrador | En Revisión | Congelado | Archivado]
- **Fecha:** [YYYY-MM-DD]
- **Versión:** 1.0
- **Feature Branch:** [rama-de-git-ej. 42-login-google]

---

## User Scenarios (Priorizados)

> Escenarios de usuario ordenados por prioridad. P1 es crítico — si solo esto funciona, la feature vale la pena.

**P1 — [Nombre del escenario principal]**
- **Actor:** [Tipo de usuario]
- **Acción:** [Qué hace el usuario]
- **Resultado esperado:** [Qué pasa después]

**P2 — [Nombre del escenario secundario]**
- **Actor:** [Tipo de usuario]
- **Acción:** [Qué hace el usuario]
- **Resultado esperado:** [Qué pasa después]

**P3 — [Nombre del escenario deseable]**
- **Actor:** [Tipo de usuario]
- **Acción:** [Qué hace el usuario]
- **Resultado esperado:** [Qué pasa después]

---

## Edge Cases

> Lo que puede fallar. Si no está escrito aquí, el equipo va a asumir que no pasa.

- [ ] **[Caso borde 1]:** [Descripción del escenario] → [Comportamiento esperado]
- [ ] **[Caso borde 2]:** [Descripción del escenario] → [Comportamiento esperado]
- [ ] **[Caso borde 3]:** [Descripción del escenario] → [Comportamiento esperado]

---

## Functional Requirements

> Lista numerada de lo que el sistema debe hacer. Cada requisito debe ser comprobable (pasa/falla).

- **FR-001:** [El sistema debe...]
- **FR-002:** [El sistema debe...]
- **FR-003:** [El sistema debe...]
- **FR-004:** [El sistema debe...]

---

## Key Entities

> Los datos que esta feature toca o crea. Ayuda a pensar en consistencia de datos y efectos secundarios.

| Entidad | Descripción | ¿Se crea? | ¿Se modifica? | ¿Se elimina? |
|---------|-------------|-----------|---------------|--------------|
| [Entidad 1] | [Descripción breve] | Sí / No | Sí / No | Sí / No |
| [Entidad 2] | [Descripción breve] | Sí / No | Sí / No | Sí / No |

---

## Success Criteria

> Cómo sabemos si la feature está completa. Debe ser medible. Si no se puede medir, no es un criterio de éxito.

1. **Performance:** [Ej. El 95% de las operaciones se completan en < 2 segundos]
2. **Tasa de error:** [Ej. Tasa de error < 1% en condiciones normales]
3. **Adopción:** [Ej. 80% de los usuarios activos usan la feature en la primera semana]
4. **Disponibilidad:** [Ej. La feature está disponible 99.9% del tiempo]

---

## Lo que NO está incluido

> Tan importante como lo que sí está. Define el límite del alcance para evitar scope creep.

- [Fuera de alcance 1]
- [Fuera de alcance 2]
- [Fuera de alcance 3]

---

## Dependencias y Suposiciones

- **Dependencia:** [Algo externo que debe existir para que esto funcione]
- **Suposición:** [Algo que asumimos como cierto para que el spec tenga sentido]

---

## Instrucciones para LLMs

*Esta sección está diseñada para ser leída por asistentes de IA (Claude, ChatGPT, Gemini) antes de procesar este documento.*

**Contexto Cero:** Este es un documento de especificación de producto en estado [Estado]. Como asistente, debes asumir que este es el único contexto disponible sobre el producto. No debes inventar características, usuarios o casos de uso que no estén descritos aquí. Si algo no está especificado, pregunta antes de asumir. Tus respuestas deben mantenerse dentro del alcance definido por este spec.