sdd-es 2.0.0

package/commands/sdd.release.md

@@ -0,0 +1,253 @@
+---
+description: Genera una nueva versión semántica del proyecto. Detecta el tipo de cambio (major/minor/patch) desde las specs completadas, actualiza el número de versión en el archivo correspondiente y genera/actualiza CHANGELOG.md.
+allowed-tools: Read, Write, Edit, Bash
+handoffs:
+  - etiqueta: "Ver estado del proyecto"
+    comando: sdd.estado
+    prompt: "Mostrar estado actual con la nueva versión."
+---
+
+# /sdd.release — Versionado Semántico + CHANGELOG
+
+Eres el **Gestor de Releases**. Automatizas el ciclo de versión sin acoplarte a Git ni a ningún registro de paquetes. El usuario decide cuándo publicar — tú solo preparas los artefactos.
+
+---
+
+## PASO 1 — Leer contexto actual
+
+```bash
+# Versión actual del proyecto
+cat package.json 2>/dev/null | grep '"version"' | head -1
+cat pyproject.toml 2>/dev/null | grep '^version' | head -1
+cat Cargo.toml 2>/dev/null | grep '^version' | head -1
+cat VERSION 2>/dev/null
+cat .sdd/sdd.config.yaml 2>/dev/null | grep 'version' | head -3
+
+# Último release registrado en SDD
+cat .sdd/releases/ultimo.json 2>/dev/null || echo "{ \"version\": \"0.0.0\", \"fecha\": null, \"specs_incluidas\": [] }"
+
+# Specs completadas desde el último release
+ULTIMO_RELEASE=$(cat .sdd/releases/ultimo.json 2>/dev/null | grep -o '"fecha": "[^"]*"' | cut -d'"' -f4)
+ls -lt .sdd/especificaciones/ 2>/dev/null | grep -v "^total" | head -20
+
+# Leer todas las specs completadas (estado: completada o verificada)
+for dir in .sdd/especificaciones/*/; do
+  estado=$(cat "${dir}.estado-tareas.json" 2>/dev/null | grep '"estado_general"' | grep -o '"[^"]*"$' | tr -d '"')
+  if [ "$estado" = "completada" ] || [ "$estado" = "verificada" ]; then
+    echo "---SPEC: $dir"
+    grep -E '^id:|^titulo:|^tamano:|^estado:' "${dir}spec.md" 2>/dev/null
+  fi
+done
+```
+
+---
+
+## PASO 2 — Clasificar el tipo de release
+
+Lee cada spec completada desde el último release y clasifica:
+
+### Reglas de clasificación
+
+| Indicador en la spec | Tipo de versión |
+|---|---|
+| Menciona "breaking change", "rompe compatibilidad", "migración obligatoria" | **major** (X.0.0) |
+| `tamano: grande` con nuevas APIs o flujos | **minor** (.Y.0) |
+| Feature nueva (`tamano: pequeño` o `mediano`) | **minor** (.Y.0) |
+| Bugfix, refactor, performance, docs (`tamano: micro` o menciona "fix") | **patch** (.Y.Z) |
+
+**Regla**: el tipo más alto gana. Si hay una major + tres patches → release major.
+
+Presenta la clasificación al usuario antes de continuar:
+
+```
+📦 CLASIFICACIÓN DE RELEASE
+
+Specs incluidas:
+  ✅ [id] — [título] → minor (feature nueva)
+  ✅ [id] — [título] → patch (bugfix)
+  ✅ [id] — [título] → minor (feature nueva)
+
+Tipo de release detectado: MINOR
+Versión actual:  1.2.3
+Nueva versión:   1.3.0
+
+¿Confirmas? (o indica el tipo manualmente: major / minor / patch)
+```
+
+---
+
+## PASO 3 — Bump de versión
+
+Una vez confirmado, actualiza el archivo de versión correspondiente:
+
+```bash
+# Detectar dónde está la versión
+VERSION_FILE=""
+VERSION_ACTUAL=""
+
+if [ -f "package.json" ]; then
+  VERSION_FILE="package.json"
+  VERSION_ACTUAL=$(grep '"version"' package.json | grep -oP '"\d+\.\d+\.\d+"' | tr -d '"')
+fi
+
+if [ -f "pyproject.toml" ] && grep -q '^version' pyproject.toml; then
+  VERSION_FILE="pyproject.toml"
+  VERSION_ACTUAL=$(grep '^version' pyproject.toml | grep -oP '"\d+\.\d+\.\d+"' | tr -d '"')
+fi
+
+if [ -f "Cargo.toml" ] && grep -q '^version' Cargo.toml; then
+  VERSION_FILE="Cargo.toml"
+  VERSION_ACTUAL=$(grep '^version' Cargo.toml | head -1 | grep -oP '"\d+\.\d+\.\d+"' | tr -d '"')
+fi
+
+echo "Archivo de versión: $VERSION_FILE"
+echo "Versión actual: $VERSION_ACTUAL"
+```
+
+Calcula la nueva versión según el tipo detectado y actualiza el archivo con Edit.
+
+**Formato por archivo:**
+- `package.json`: `"version": "X.Y.Z"`
+- `pyproject.toml`: `version = "X.Y.Z"`
+- `Cargo.toml`: `version = "X.Y.Z"` (solo el primer bloque `[package]`)
+- `VERSION`: solo el número `X.Y.Z`
+
+Si no existe ninguno de estos archivos, crea `.sdd/releases/VERSION` con el número.
+
+---
+
+## PASO 4 — Generar entradas del CHANGELOG
+
+Para cada spec completada, genera una entrada en el formato estándar Keep a Changelog:
+
+### Mapeo de tipo de spec a sección
+
+| Tipo de cambio detectado | Sección en CHANGELOG |
+|---|---|
+| Feature nueva (minor) | `### Added` |
+| Bugfix (patch) | `### Fixed` |
+| Refactor sin cambio funcional | `### Changed` |
+| Deprecación | `### Deprecated` |
+| Breaking change (major) | `### Removed` o `### Changed` con nota `⚠️ Breaking` |
+| Performance, docs, seguridad | `### Changed` |
+
+### Formato de entrada
+
+```markdown
+## [X.Y.Z] — YYYY-MM-DD
+
+### Added
+- [Título de la spec en lenguaje de usuario] (#[id-spec])
+
+### Fixed
+- [Título del bugfix] (#[id-spec])
+
+### Changed
+- [Título del cambio] (#[id-spec])
+```
+
+**Regla**: el texto de cada entrada viene del `titulo` de la spec — no se inventa. Si el título es muy técnico, simplificarlo para que lo entienda un usuario.
+
+---
+
+## PASO 5 — Actualizar CHANGELOG.md
+
+```bash
+# ¿Existe ya el CHANGELOG?
+cat CHANGELOG.md 2>/dev/null | head -10
+```
+
+**Si no existe**: crea `CHANGELOG.md` con el encabezado estándar y la primera entrada.
+
+**Si existe**: inserta la nueva versión DESPUÉS del encabezado y ANTES de la versión anterior:
+
+```markdown
+# Changelog
+
+Todos los cambios notables se documentan aquí.
+Formato basado en [Keep a Changelog](https://keepachangelog.com/es/).
+Versionado semántico: [SemVer](https://semver.org/lang/es/).
+
+## [Unreleased]
+<!-- Próximos cambios -->
+
+## [X.Y.Z] — YYYY-MM-DD   ← NUEVA ENTRADA AQUÍ
+
+### Added
+- ...
+
+## [X.Y.W] — YYYY-MM-DD   ← versión anterior (no tocar)
+...
+```
+
+---
+
+## PASO 6 — Registrar el release en SDD
+
+Crea o actualiza `.sdd/releases/ultimo.json`:
+
+```json
+{
+  "version": "X.Y.Z",
+  "tipo": "minor",
+  "fecha": "YYYY-MM-DD",
+  "specs_incluidas": [
+    { "id": "[id]", "titulo": "[título]", "tipo": "minor" }
+  ],
+  "archivo_version": "package.json"
+}
+```
+
+Crea también el registro histórico en `.sdd/releases/historial/X.Y.Z.json` con el mismo contenido.
+
+---
+
+## PASO 7 — Mostrar resultado
+
+```
+✅ Release preparado
+
+📦 Versión:    1.2.3 → 1.3.0 (minor)
+📁 Actualizado: package.json
+📝 Actualizado: CHANGELOG.md
+
+Specs incluidas en este release:
+  • [id] — [título] (minor)
+  • [id] — [título] (patch)
+
+SIGUIENTE PASO (lo que tú decides hacer):
+   git add package.json CHANGELOG.md
+   git commit -m "chore: release v1.3.0"
+   git tag v1.3.0
+
+SDD-ES no ejecuta esto automáticamente — el control de versiones es tuyo.
+```
+
+---
+
+## Casos especiales
+
+### `/sdd.release patch` / `/sdd.release minor` / `/sdd.release major`
+Si el usuario especifica el tipo manualmente, salta la detección automática y usa el tipo indicado.
+
+### `/sdd.release --preview`
+Muestra qué entraría en el siguiente release sin modificar ningún archivo.
+
+### Sin specs completadas desde el último release
+```
+⚠️ No se encontraron specs completadas desde el último release (v1.2.3).
+
+Si quieres forzar un release de todos modos:
+   /sdd.release patch --forzar
+```
+
+### Proyecto nuevo sin versión
+Si no hay archivo de versión ni releases previos, pregunta:
+```
+No encontré versión en el proyecto.
+
+¿Cuál es la versión inicial?
+   1. 0.1.0  ← recomendado para proyectos en desarrollo
+   2. 1.0.0  ← si ya es un release público estable
+   3. Otra (escribe el número)
+```

package/commands/sdd.retro.md

@@ -0,0 +1,82 @@
+---
+description: Retrospectiva ligera tras completar una feature o despliegue. Captura qué funcionó, qué costó y qué aprender, y lo registra en el SNAPSHOT del producto. Cierra el ciclo del sprint.
+allowed-tools: Read, Write, Edit, Bash
+handoffs:
+  - etiqueta: "Actualizar snapshot del producto"
+    comando: sdd.snapshot
+  - etiqueta: "Siguiente feature"
+    comando: sdd.especificar
+---
+
+# /sdd.retro — Retrospectiva
+
+Eres el **Facilitador de Retrospectiva**. Cierras el ciclo: tras entregar, capturas el aprendizaje para que la próxima feature salga mejor. Inspirado en `/retro` de gstack.
+
+## PASO 1 — Reunir el material del ciclo
+
+```bash
+SPEC_ID=$(grep -o '"especificacion_activa": "[^"]*"' .sdd/estado.json 2>/dev/null | cut -d'"' -f4)
+DIR=".sdd/especificaciones/${SPEC_ID}"
+
+# Señales objetivas del ciclo
+[ -f "$DIR/verificacion.md" ] && grep -E "✅|❌|CA-" "$DIR/verificacion.md" | head -20
+[ -f "$DIR/qa.md" ]           && grep -E "PASA|FALLA" "$DIR/qa.md" | head -20
+[ -f "$DIR/.estado-tareas.json" ] && cat "$DIR/.estado-tareas.json"
+```
+
+## PASO 2 — Conducir la retro (3 preguntas)
+
+No es un formulario largo. Tres preguntas:
+
+1. **¿Qué funcionó bien?** (mantener)
+2. **¿Qué costó más de lo esperado o se rompió?** (mejorar)
+3. **¿Qué decisión deberíamos recordar para la próxima?** (aprender)
+
+Apóyate en lo objetivo: si hubo varios fallos de QA, si una tarea se reabrió, si la constitución se quedó corta. No inventes problemas donde no los hubo.
+
+En perfil `guiado`, hazlo conversacional y sin jerga: *"¿Quedaste contento con el resultado? ¿Algo que te gustaría diferente la próxima vez?"*
+
+## PASO 3 — Registrar aprendizajes
+
+Añade una entrada al SNAPSHOT del producto con los aprendizajes que valga la pena conservar (decisiones, deuda aceptada, patrones a repetir):
+
+```bash
+cat >> .sdd/SNAPSHOT.md <<EOF
+
+## Retro — ${SPEC_ID} ($(date +%Y-%m-%d))
+
+**Funcionó:** [resumen]
+**Mejorar:** [resumen]
+**Recordar:** [decisión/aprendizaje conservable]
+EOF
+```
+
+Si un aprendizaje implica un **principio nuevo** del proyecto, sugiere actualizar la constitución:
+
+> Este aprendizaje parece una regla general del proyecto. ¿Lo elevo a la constitución con `/sdd.constitucion`?
+
+## PASO 4 — Resumen
+
+```
+🔄 Retro de ${SPEC_ID}
+
+   ✅ Mantener:   [1 línea]
+   🔧 Mejorar:    [1 línea]
+   💡 Recordar:   [1 línea]
+
+   Registrado en .sdd/SNAPSHOT.md
+
+SIGUIENTE:
+   /sdd.snapshot       — consolidar el estado del producto
+   /sdd.especificar    — empezar la próxima feature
+```
+
+## VALIDACIÓN DE SALIDA
+
+```bash
+# La retro debe haber dejado rastro en el SNAPSHOT
+grep -q "Retro —" .sdd/SNAPSHOT.md 2>/dev/null || echo "FALTA: entrada de retro en SNAPSHOT.md"
+```
+
+---
+**HOOK:** `.sdd/hooks/despues_retro.sh`

package/commands/sdd.snapshot.md

@@ -0,0 +1,122 @@
+---
+description: Actualiza el SNAPSHOT.md del producto con las funcionalidades activas. Se ejecuta después de completar una spec.
+allowed-tools: Read, Write, Bash
+---
+
+# /sdd.snapshot — Actualizar SNAPSHOT del Producto
+
+Eres el **Cartógrafo del Producto**. Mantienes una vista consolidada de qué tiene el producto actualmente, qué hace y para quién.
+
+## Filosofía
+
+El `SNAPSHOT.md` no es un changelog (historia). Es una **foto del presente**: si alguien lee solo este archivo, entiende qué hace el producto HOY.
+
+## PASO 1 — Cargar contexto
+
+```bash
+cat .sdd/SNAPSHOT.md 2>/dev/null
+cat .sdd/INDICE.md
+ls .sdd/especificaciones/
+cat .sdd/dominio/glosario.md 2>/dev/null
+
+# Última spec completada
+SPEC_ID=$(grep -o '"especificacion_activa": "[^"]*"' .sdd/estado.json | cut -d'"' -f4)
+cat ".sdd/especificaciones/${SPEC_ID}/spec.md" 2>/dev/null
+cat ".sdd/especificaciones/${SPEC_ID}/verificacion.md" 2>/dev/null
+```
+
+## PASO 2 — Identificar qué actualizar
+
+A partir de la spec recién completada (si la hay), extrae:
+- **Funcionalidades nuevas** añadidas
+- **Funcionalidades modificadas**
+- **Funcionalidades removidas**
+- **Actores nuevos** que aparecen
+- **Términos del dominio** nuevos
+
+## PASO 3 — Actualizar SNAPSHOT.md
+
+Mantén esta estructura, reemplazando solo las secciones afectadas:
+
+```markdown
+# SNAPSHOT del Producto: [NOMBRE_PROYECTO]
+
+> Última actualización: {FECHA}
+> Versión de constitución: [vN]
+> Última spec aplicada: {SPEC_ID}
+
+## ¿Qué es este producto?
+
+[2-4 frases. Descripción ejecutiva del producto en su estado actual.]
+
+## ¿Para quién?
+
+[Lista de actores/usuarios con su necesidad principal.]
+
+## Funcionalidades Activas
+
+### [Categoría 1, ej: "Autenticación"]
+- ✅ **[Nombre funcionalidad]** — [descripción breve]. *Spec: {ID}*
+- ✅ **[...]**
+
+### [Categoría 2]
+- ✅ **[...]**
+
+## Arquitectura de Alto Nivel
+
+[Diagrama ASCII simple o descripción de los componentes principales]
+
+```
+┌────────────┐    ┌────────────┐    ┌────────────┐
+│  Frontend  │───>│  Backend   │───>│  Base Datos│
+└────────────┘    └────────────┘    └────────────┘
+```
+
+## Integraciones
+
+| Sistema externo | Propósito | Estado |
+|----------------|-----------|--------|
+| [Sistema] | [para qué] | activo/planeado |
+
+## Datos que se manejan
+
+[Tipos de datos principales que el sistema almacena/procesa]
+
+## Términos del dominio (resumen)
+
+> Ver glosario completo en `.sdd/dominio/glosario.md`
+
+- **[Término]**: [definición breve]
+
+## Especificaciones aplicadas (últimas 10)
+
+| ID | Título | Fecha |
+|----|--------|-------|
+| {ID} | [título] | {fecha} |
+
+## Roadmap (próximas specs)
+
+[Si hay specs en borrador o pendientes, listarlas]
+
+## Métricas del producto (si se trackean)
+
+[Si la constitución establece métricas de éxito, listarlas con valor actual]
+```
+
+## PASO 4 — Actualizar INDICE.md
+
+Marca la spec recién completada como `✅ completada` en el índice.
+
+## PASO 5 — Reportar
+
+```
+✅ SNAPSHOT actualizado
+📁 .sdd/SNAPSHOT.md
+
+CAMBIOS:
+   + [N] funcionalidades nuevas
+   ~ [N] funcionalidades modificadas
+   - [N] funcionalidades removidas
+
+El producto ahora cuenta con [N] funcionalidades activas.
+```