new-spec

Crea una nueva especificación de cambio cuyo nombre está en $ARGUMENTS.

1. Lee specs/README.md para conocer el flujo de trabajo de las especificaciones, la convención de nombres de carpeta y qué espera cada sección de la plantilla. Sigue ese documento si difiere de los pasos siguientes.
2. Convierte $ARGUMENTS en <change-name> con formato slug (minúsculas, separado por guiones).
3. Calcula NNNN: el mayor prefijo numérico de 4 dígitos existente en specs/ y specs/archive/ (si existe), más uno; si no hay ninguna, 0001.
4. Copia todo el directorio specs/_template/ a specs/NNNN-<change-name>/ (conserva cada archivo de la plantilla).
5. En los archivos copiados, completa los metadatos obvios:
   • El título del cambio (la forma legible de $ARGUMENTS)
   • Estado: Borrador
   • Fecha: la fecha de hoy (YYYY-MM-DD)
   • Deja problem, goals, non-goals y approach como indicaciones para la persona autora.
6. Rellena «Evidencia» antes que el objetivo: quién pagaría y qué lo respalda, si ya existe, y qué experimento se hizo. Mira primero docs/product/roadmap.md — puede que la respuesta ya esté. En una fix/* o de tooling, escribe «No aplica: corrección»: la sección existe para decidir qué construir, no para dar teatro a lo que ya está roto.
7. Ata la spec al roadmap. Lee docs/product/roadmap.md y rellena el campo Ítem de roadmap de proposal.md con la versión y el ítem literal que esta spec completa. Si hay varios candidatos, pregunta con AskUserQuestion en vez de elegir por tu cuenta. Si no existe ningún ítem que encaje, dilo: o se añade al roadmap ahora, o el cambio debería contrastarse antes contra el roadmap (¿entra en esta versión?, ¿qué sale a cambio?). Anota también la spec junto al ítem en el roadmap ((specs/NNNN-<slug>/)).
8. Si specs/README.md mantiene un índice de especificaciones, añade una entrada para la nueva especificación.
9. Informa la ruta del directorio creado y enumera los archivos que la persona autora aún debe completar.

Ejemplo: /new-spec rediseño del checkout → specs/0007-checkout-redesign/ (si la última especificación era la 0006).

Rama ↔ spec: la rama que implemente esta spec debe llamarse feat/<change-name> (o fix/<change-name>) — mismo slug. El hook spec-guardrails.sh bloquea editar código en ramas feat/*/fix/* cuya spec no exista, así que crea la spec ANTES de crear la rama de implementación (o desde la rama, antes de tocar código). El hook también bloquea mientras proposal.md, design.md o tasks.md conserven líneas de la plantilla sin rellenar: deja los archivos completos (o borra las secciones que no apliquen) antes de implementar.

NO empieces a implementar el cambio, y NO elimines ni sobrescribas una carpeta de especificación existente — si ya existe alguna specs/*-<change-name>/ (con cualquier prefijo NNNN-; el nombre sin prefijo no va a existir nunca), detente y pregunta.