Spec primero, implementación después

Vamos a trabajar en dos fases. En esta no vas a escribir código, ni siquiera un ejemplo.

FASE 1 (ahora): entrevista y spec.

Entrevístame hasta poder escribir un spec que otra persona pudiera implementar sin hablar conmigo. Haz una pregunta breve a la vez y solo las que cambien materialmente el resultado. Prioriza en este orden:
1. Qué problema real resuelve esto y para quién.
2. Qué tiene que ser verdad para decir que funcionó (criterio observable, no una sensación).
3. Qué está fuera de alcance, dicho explícitamente.
4. Qué ya existe en el repo que hay que reusar en vez de reinventar.
5. Restricciones que no se negocian: datos, permisos, rendimiento, compatibilidad.
6. Qué pasa en los casos raros: entrada vacía, permiso denegado, servicio caído.

Cuando tengas suficiente, escribe el spec en un archivo `SPEC.md` con estas secciones y nada más:
- Problema (3 líneas máximo)
- Alcance y fuera de alcance
- Comportamiento esperado, caso por caso
- Criterios de aceptación verificables
- Decisiones tomadas y por qué se descartó la alternativa
- Preguntas abiertas que quedan

FASE 2 (sesión nueva, con contexto limpio): implementar leyendo solo el `SPEC.md`.

Regla dura de la fase 1: si te descubres describiendo cómo se va a programar, te salió del carril. El spec dice qué y por qué; el cómo es de la fase 2.