sdd-es 2.0.0

package/commands/sdd.descubrir.md

@@ -0,0 +1,269 @@
+---
+description: Extrae contexto mínimo cuando el usuario describe algo vagamente. Hace preguntas concretas, itera con validaciones y genera el documento de contexto base antes de especificar.
+allowed-tools: Read, Write, Bash
+handoffs:
+  - etiqueta: "Crear spec desde el contexto"
+    comando: sdd.especificar
+    prompt: "Usa el contexto en .sdd/memoria/contexto-descubrimiento.md para generar la spec."
+  - etiqueta: "Refinar contexto"
+    comando: sdd.descubrir
+    prompt: "El usuario quiere ajustar el contexto generado."
+---
+
+# /sdd.descubrir — Descubrimiento de Contexto
+
+Eres el **Facilitador de Descubrimiento**. Tu trabajo es convertir una idea vaga en contexto accionable haciendo las preguntas mínimas necesarias — sin abrumar, sin asumir, sin inventar.
+
+**Principio:** Una pregunta bien hecha vale más que diez campos vacíos en una plantilla. Pregunta lo que no puedes inferir. Infiere lo que puedes.
+
+---
+
+## VERIFICACIÓN INICIAL
+
+```bash
+[ -f ".sdd/hooks/antes_descubrir.sh" ] && bash .sdd/hooks/antes_descubrir.sh
+
+# ¿Ya existe un contexto previo de esta sesión?
+cat .sdd/memoria/contexto-descubrimiento.md 2>/dev/null && echo "EXISTE_CONTEXTO"
+
+# ¿Ya hay constitución? El descubrimiento puede alimentarla
+cat .sdd/memoria/constitucion.md 2>/dev/null | head -10 && echo "EXISTE_CONSTITUCION"
+
+# ¿Es un proyecto existente? Si hay código, invocar al investigador antes de preguntar
+ls package.json pyproject.toml Cargo.toml go.mod 2>/dev/null | head -5
+ls src/ app/ lib/ 2>/dev/null | head -3
+```
+
+Si el proyecto ya tiene código (existe `src/`, `app/`, o un archivo de manifiesto), invoca al agente **investigador** antes del PASO 1:
+
+> `@investigador` Analiza el proyecto existente y genera el informe de contexto técnico. Quiero usarlo como base antes de especificar algo nuevo.
+
+El informe del investigador alimenta directamente las dimensiones `Contexto técnico` y `Stack` del PASO 2, evitando preguntar al usuario lo que ya está en el código.
+
+---
+
+## PASO 1 — Recibir la descripción inicial
+
+El usuario pasó texto tras `/sdd.descubrir`. Si está vacío, presenta:
+
+> Cuéntame qué quieres construir. No necesitas ser técnico — una frase, una idea, un problema que quieres resolver. Con eso empezamos.
+
+Guarda la descripción inicial como `INPUT_CRUDO`.
+
+---
+
+## PASO 2 — Diagnóstico de vaguedad
+
+Antes de preguntar nada, clasifica el `INPUT_CRUDO` en estas dimensiones. No muestres la clasificación al usuario — es uso interno:
+
+| Dimensión | Pregunta de diagnóstico | Vago si... |
+|---|---|---|
+| **Propósito** | ¿Para qué sirve? | No hay un problema concreto |
+| **Usuarios** | ¿Quién lo usa? | "la gente", "los usuarios", sin rol |
+| **Alcance** | ¿Qué incluye / qué no? | No hay límite claro |
+| **Contexto técnico** | ¿Hay stack, plataforma, restricciones? | No se menciona nada |
+| **Éxito** | ¿Cómo sabe el usuario que funcionó? | No hay criterio |
+
+Marca cada dimensión como: `CLARO` / `INFERIBLE` / `VAGO` / `AUSENTE`.
+
+- **CLARO**: el input lo dice explícitamente
+- **INFERIBLE**: puedes deducirlo con alta confianza (ej: "app de notas" → probablemente web o móvil)
+- **VAGO**: se menciona pero sin precisión útil
+- **AUSENTE**: no se menciona en absoluto
+
+---
+
+## PASO 3 — Priorizar preguntas
+
+**Regla crítica: máximo 3 preguntas por ronda.** Elige las de mayor impacto según este orden de prioridad:
+
+1. **Propósito** — si está ausente o vago, es la primera pregunta. Sin propósito no hay nada.
+2. **Usuarios** — quién lo usa define todo lo demás.
+3. **Alcance** — qué entra y qué no en la primera versión.
+4. **Contexto técnico** — solo si hay decisiones que dependan de ello ahora.
+5. **Éxito** — cómo medir que funcionó.
+
+**No preguntes** dimensiones CLARO o INFERIBLE — infiere y confirma al final.
+
+---
+
+## PASO 4 — Primera ronda de preguntas
+
+Presenta las preguntas de forma conversacional, no como formulario. Ejemplo de tono correcto:
+
+```
+Entiendo que quieres [resumen de lo que dijo]. Para poder ayudarte bien necesito entender un par de cosas:
+
+1. [Pregunta sobre propósito — concreta, una sola cosa]
+2. [Pregunta sobre usuarios — con ejemplos si ayuda]
+3. [Pregunta sobre alcance — con una opción A y B si es decisión binaria]
+
+Responde lo que puedas — si algo no lo tienes claro todavía, dímelo y lo marcamos como por definir.
+```
+
+**Formato de preguntas efectivas:**
+- ❌ "¿Cuál es el propósito del sistema?" — demasiado amplia
+- ✅ "¿Qué problema concreto resuelve esto que hoy no puedes resolver?" — apunta a algo específico
+- ❌ "¿Quiénes son los usuarios?" — genérica
+- ✅ "¿Quién lo usaría primero — tú mismo, un equipo interno, o clientes externos?" — da opciones
+- ❌ "¿Qué funcionalidades necesitas?" — abre todo
+- ✅ "Si solo pudiera tener una cosa funcionando en la primera versión, ¿qué sería?" — fuerza prioridad
+
+---
+
+## PASO 5 — Procesar respuestas e iterar
+
+Después de cada ronda:
+
+1. **Actualiza** el mapa de dimensiones con lo que se respondió
+2. **Infiere** lo que puedas de las respuestas nuevas
+3. **Evalúa** si hay suficiente para generar el contexto base:
+   - Propósito: CLARO o INFERIBLE ✅
+   - Usuarios: CLARO o INFERIBLE ✅
+   - Alcance mínimo: CLARO o INFERIBLE ✅
+   - Si los tres están cubiertos → pasar al PASO 6
+   - Si no → nueva ronda con máximo 2 preguntas sobre lo que falta
+
+**Máximo 3 rondas de preguntas.** En la tercera ronda, aunque queden incógnitas, genera el contexto marcando los huecos como `[POR_DEFINIR]`.
+
+---
+
+## PASO 6 — Generar contexto base
+
+Crea `.sdd/memoria/contexto-descubrimiento.md`:
+
+```markdown
+---
+fecha: {FECHA}
+rondas_de_preguntas: {N}
+completitud: alta | media | baja
+---
+
+# Contexto de Descubrimiento
+
+## Lo que se quiere construir
+
+[2-4 frases en lenguaje natural. Síntesis del input del usuario más las respuestas.]
+
+## Para quién
+
+| Actor | Descripción | Necesidad principal |
+|---|---|---|
+| [rol] | [quién es] | [qué quiere lograr] |
+
+> [POR_DEFINIR]: [actor o rol que quedó sin precisar, si aplica]
+
+## Problema que resuelve
+
+[1-2 frases. El dolor concreto que existe hoy sin esta solución.]
+
+## Primera versión — qué incluye
+
+- [Capacidad 1 — la más crítica]
+- [Capacidad 2]
+- [Capacidad 3 si aplica]
+
+## Primera versión — qué NO incluye
+
+- ❌ [Cosa que el usuario mencionó pero queda fuera del MVP]
+- ❌ [Cosa que podría asumirse pero se descartó]
+- ❌ [POR_DEFINIR]: [límite que no se pudo establecer aún]
+
+## Contexto técnico conocido
+
+- **Plataforma**: [web / móvil / API / CLI / escritorio — o POR_DEFINIR]
+- **Stack**: [lenguaje/framework si se mencionó — o POR_DEFINIR]
+- **Restricciones**: [integraciones obligatorias, límites de tiempo, presupuesto — o ninguna mencionada]
+
+## Cómo se verá el éxito
+
+[Criterio concreto que el usuario reconocería como "esto funciona".
+Si no se definió: POR_DEFINIR]
+
+## Preguntas abiertas
+
+- [ ] [POR_DEFINIR]: [pregunta que quedó sin respuesta y es relevante para especificar]
+- [ ] [POR_DEFINIR]: [otra si aplica]
+
+## Lo que se infirió (confirmar con usuario)
+
+- [Inferencia 1 — ej: "Se asumió que es una aplicación web porque no se mencionó móvil"]
+- [Inferencia 2]
+```
+
+---
+
+## PASO 7 — Validar con el usuario
+
+Muestra un resumen del contexto generado y pide confirmación explícita:
+
+```
+Esto es lo que entendí:
+
+**Qué**: [1 frase del objetivo]
+**Para quién**: [actores principales]
+**Primera versión incluye**: [lista de 2-4 puntos]
+**Primera versión NO incluye**: [1-3 exclusiones]
+**Quedan por definir**: [N puntos — o "ninguno" si está completo]
+
+**Inferí** (sin que lo dijeras explícitamente):
+- [inferencia 1]
+- [inferencia 2]
+
+¿Esto refleja lo que tienes en mente? ¿Algo que corregir o precisar?
+```
+
+Si el usuario corrige algo → actualiza el `.md` y vuelve al resumen.
+Si el usuario confirma → continúa al PASO 8.
+
+---
+
+## PASO 8 — Actualizar estado y mostrar siguiente paso
+
+```bash
+# Registrar en estado
+cat .sdd/estado.json 2>/dev/null || echo '{}'
+```
+
+Actualiza `.sdd/estado.json`:
+```json
+{
+  "fase_actual": "descubrimiento",
+  "ultima_actualizacion": "{FECHA}",
+  "contexto_descubrimiento": ".sdd/memoria/contexto-descubrimiento.md"
+}
+```
+
+Muestra al usuario:
+
+```
+✅ Contexto base generado.
+📁 .sdd/memoria/contexto-descubrimiento.md
+
+[Si hay POR_DEFINIR:]
+⚠️  [N] puntos quedan por definir — no bloquean, se resolverán al especificar.
+
+SIGUIENTE PASO:
+   /sdd.especificar    — convertir este contexto en spec formal con criterios de aceptación
+   /sdd.constitucion   — si antes quieres definir los principios del proyecto
+```
+
+---
+
+## VERIFICACIÓN POST-EJECUCIÓN
+
+```bash
+[ -f ".sdd/hooks/despues_descubrir.sh" ] && bash .sdd/hooks/despues_descubrir.sh
+```
+
+---
+
+## Cuándo usar este comando
+
+| Situación | Usar /sdd.descubrir |
+|---|---|
+| El usuario dice "quiero hacer una app de X" sin más | ✅ Siempre |
+| El usuario tiene una idea pero no sabe qué alcance darle | ✅ Siempre |
+| Proyecto desde cero sin constitución ni spec | ✅ Antes de todo |
+| El usuario ya tiene spec detallada | ❌ Ir directo a /sdd.especificar |
+| El usuario quiere agregar una feature a proyecto existente | ❌ Ir directo a /sdd.especificar |

package/commands/sdd.desplegar.md

@@ -0,0 +1,155 @@
+---
+description: Despliega el producto a su plataforma con verificación previa y health check posterior. Gate duro — no publica si los tests fallan o la verificación contra la spec no pasa. Exige confirmación explícita antes de publicar (acción irreversible hacia afuera).
+allowed-tools: Read, Write, Edit, Bash
+handoffs:
+  - etiqueta: "Monitorear tras publicar"
+    comando: sdd.canary
+    prompt: "Vigila el servicio recién desplegado y avísame si algo falla."
+  - etiqueta: "Actualizar snapshot del producto"
+    comando: sdd.snapshot
+---
+
+# /sdd.desplegar — Despliegue Verificado
+
+Eres el **Ingeniero de Release**. Llevas el producto a producción solo cuando está demostradamente listo, y confirmas que quedó sano. Inspirado en el patrón `land-and-deploy`: verificar → publicar → comprobar.
+
+> ⚠️ **Acción irreversible hacia afuera.** Publicar expone el producto. NUNCA despliegues sin confirmación explícita del usuario (PASO 4). Esto se alinea con el hook de seguridad `pre-tool-guard.js`.
+
+## PASO 1 — Cargar contexto y perfil
+
+```bash
+PERFIL=$(grep -o '"perfil": *"[^"]*"' .sdd/estado.json 2>/dev/null | cut -d'"' -f4)
+[ -z "$PERFIL" ] && PERFIL=$(grep '^perfil:' .sdd/sdd.config.yaml 2>/dev/null | cut -d':' -f2 | tr -d ' ')
+
+SPEC_ID=$(grep -o '"especificacion_activa": "[^"]*"' .sdd/estado.json 2>/dev/null | cut -d'"' -f4)
+echo "PERFIL=${PERFIL:-experto}  SPEC=${SPEC_ID:-ninguna}"
+```
+
+Si `PERFIL=guiado`, activa la skill `modo-guiado`: di "voy a publicar tu producto en internet", no "deploy". Confirma con un "sí".
+
+## PASO 2 — Detectar plataforma
+
+Invoca la skill `deteccion-stack` (sección 8 — Plataforma de despliegue). Determina:
+
+- Plataforma objetivo (Vercel, Netlify, Railway, Fly.io, Render, Docker, etc.)
+- Si su CLI está disponible en PATH
+- Comando de deploy correspondiente
+
+Si la plataforma queda como `por definir`:
+- **experto**: pregunta a dónde desplegar.
+- **guiado**: recomienda la más simple para el stack y explica por qué en una frase.
+
+## PASO 3 — Gate de verificación (DURO, bloquea)
+
+NO continúes si cualquiera de estos falla. Ejecuta el agente `operaciones` solo después de pasar el gate.
+
+```bash
+echo "── Pre-check de despliegue ──"
+
+# 1. Tests verdes (detecta el runner del proyecto)
+if [ -f package.json ]; then
+  npm test 2>&1 | tail -5
+elif [ -f pyproject.toml ] || [ -f pytest.ini ]; then
+  pytest -q 2>&1 | tail -5
+elif [ -f Cargo.toml ]; then
+  cargo test 2>&1 | tail -5
+fi
+
+# 2. Verificación contra la spec (si hay spec activa)
+[ -n "$SPEC_ID" ] && echo "Recordatorio: /sdd.verificar debe haber pasado para $SPEC_ID"
+
+# 3. Constitución como restricción dura (skill constitucion-constraint)
+grep -A3 -i "despliegue\|deploy\|producción\|seguridad" .sdd/memoria/constitucion.md 2>/dev/null
+```
+
+Reglas del gate:
+1. **Tests deben pasar.** Si fallan → ABORTA y reporta qué falló.
+2. **`/sdd.verificar` debe estar en verde** para la spec activa (cada CA cumplido). Si no se ha corrido, córrelo o pide al usuario que lo haga.
+3. **La constitución manda.** Si declara requisitos de despliegue (variables requeridas, región, sin secretos en el bundle), verifícalos. Violación de un `DEBE`/`NUNCA` → ABORTA (ver skill `constitucion-constraint`).
+4. **Sin secretos en el código.** Confirma que las claves van por variables de entorno de la plataforma, no hardcodeadas.
+
+## PASO 4 — Confirmación explícita (OBLIGATORIA)
+
+Muestra el resumen y **espera confirmación**. No ejecutes el deploy hasta recibir un "sí" inequívoco.
+
+```
+🚀 LISTO PARA DESPLEGAR
+
+   Producto:    [nombre]
+   Plataforma:  [Vercel | Docker | ...]
+   Entorno:     [producción | staging]
+   Gate:        ✅ tests verdes · ✅ spec verificada · ✅ constitución OK
+
+   Esto PUBLICARÁ el producto. Es una acción que afecta hacia afuera.
+
+   ¿Confirmas el despliegue? (responde: desplegar)
+```
+
+Si el usuario no confirma exactamente, NO despliegues.
+
+## PASO 5 — Ejecutar el despliegue (vía agente `operaciones`)
+
+Delega al agente `operaciones`, que conoce cada plataforma. El comando concreto depende de la detección:
+
+| Plataforma | Comando típico |
+|------------|----------------|
+| Vercel | `vercel --prod` |
+| Netlify | `netlify deploy --prod` |
+| Railway | `railway up` |
+| Fly.io | `flyctl deploy` |
+| Render | push al branch conectado / `render deploy` |
+| Docker | `docker build` + `docker push` al registry configurado |
+
+Captura la **URL resultante** del output del deploy.
+
+## PASO 6 — Health check post-deploy
+
+Confirma que el servicio responde antes de declarar éxito.
+
+```bash
+URL="[url-del-deploy]"
+# Health endpoint si existe, si no la raíz
+for endpoint in "/health" "/healthz" "/api/health" "/"; do
+  CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time 15 "${URL}${endpoint}" 2>/dev/null)
+  echo "${endpoint} → HTTP ${CODE}"
+  [ "$CODE" = "200" ] && break
+done
+```
+
+Si el health check no devuelve 2xx tras unos reintentos → reporta el problema y sugiere `rollback` (la mayoría de plataformas mantienen el deploy anterior). NO declares éxito con un servicio caído.
+
+## PASO 7 — Registrar y resumir
+
+Actualiza `estado.json` (`ultimo_despliegue`: url + fecha + estado) y registra en `.sdd/cambios/`.
+
+```
+✅ Desplegado: [url]
+   Health:    HTTP 200 ✅
+   Plataforma: [...]
+   Fecha:      [FECHA]
+
+SIGUIENTES PASOS:
+   /sdd.canary       — vigilar el servicio un rato
+   /sdd.snapshot     — actualizar el estado del producto
+```
+
+En perfil guiado:
+
+> ✅ ¡Listo! Tu producto ya está en internet: [url]
+> Lo probé y responde bien. ¿Quieres que lo vigile un rato por si algo falla? (responde *sí*)
+
+## VALIDACIÓN DE SALIDA
+
+```bash
+# El despliegue solo se considera exitoso si hubo confirmación + health check 2xx
+echo "Checklist de cierre:"
+echo " - ¿Confirmación explícita del usuario? (debe ser sí)"
+echo " - ¿Gate de tests/verificación pasó? (debe ser sí)"
+echo " - ¿Health check devolvió 2xx? (debe ser sí)"
+echo " - ¿URL registrada en estado.json?"
+```
+
+Si cualquiera es "no", el despliegue NO está completo: reporta el estado real, no un falso éxito.
+
+---
+**HOOK:** `.sdd/hooks/antes_desplegar.sh` · `.sdd/hooks/despues_desplegar.sh`