sdd-es 2.0.0 → 2.5.0

package/commands/sdd.implementar.md

@@ -42,11 +42,94 @@ cat .sdd/memoria/constitucion.md
 | `fase A` | **Por fase**: solo las tareas de la Fase A |
 | `revisar` | **Revisión**: invocar revisor sobre tareas completadas |
 
-## PASO 3 — Crear TODO list para visualización
+## PASO 3 — Gate Humano (aprobación antes de ejecutar)
+
+Antes de tocar cualquier archivo, muestra este resumen al usuario y espera confirmación:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+🏗️  PLAN DE IMPLEMENTACIÓN — {SPEC_ID}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+📋 Tareas en cola:       [N] tareas
+🤖 Agentes que activarán: [lista única de agentes]
+📁 Archivos a modificar:  [lista de rutas, deducida de tareas.md]
+⏱️  Tiempo estimado:      [S: <15min / M: 15-45min / L: >45min]
+💡 Modo de ejecución:     [PTC paralelo / Secuencial]
+
+⚡ Nivel de esfuerzo recomendado: [según agentes activos]
+   • Si hay agentes OPUS (arquitecto/critico/seguridad/asesor-datos):
+     Escribe `/effort xhigh` en Claude Code antes de responder sí.
+   • Si solo hay agentes SONNET: `/effort medium` (o el default está bien)
+   • Si solo hay agentes HAIKU: `/effort low`
+   Puedes ignorar esto si ya lo configuraste o si prefieres el default.
+
+¿Procedo con la implementación?
+→ Responde **sí** para comenzar
+→ Responde **editar** para ajustar tareas antes
+→ Responde **cancelar** para salir
+```
+
+**Bypass automático** (no pide confirmación) cuando:
+- La variable de entorno `SDD_AUTO=1` está definida
+- El argumento incluye la palabra `forzar` (ej: `/sdd.implementar forzar`)
+- El modo es `continuar` (ya hubo confirmación previa)
+
+Si el usuario responde `editar` → detente y ofrece abrir `tareas.md` con un editor.
+Si responde `cancelar` → detente con mensaje: "Implementación cancelada. Cuando quieras continuar: `/sdd.implementar`"
+
+## PASO 3.5 — Crear TODO list para visualización
 
 Usa `TodoWrite` para mostrar el progreso en tiempo real al usuario. Crea un TODO por tarea pendiente.
 
-## PASO 3.5 — Planificación PTC (Programmatic Tool Calling)
+## PASO 4 — Model routing (asignación de modelo por agente)
+
+Antes de despachar cada agente, aplica esta tabla de routing. El modelo correcto se inyecta en el prompt del agente:
+
+```
+ROUTING DE MODELOS:
+
+Grupo OPUS (decisiones de alto impacto, razonamiento extendido):
+  → arquitecto, critico, seguridad, asesor-datos
+  → Modelo: claude-opus-4-8
+
+Grupo SONNET (implementación estándar, análisis medio):
+  → desarrollador-backend, desarrollador-frontend, tester
+  → desarrollador-mobile, operaciones, disenador-api, revisor
+  → Modelo: claude-sonnet-4-6
+
+Grupo HAIKU (búsqueda, resumen, tareas de baja complejidad):
+  → investigador, documentador
+  → Modelo: claude-haiku-4-5-20251001
+
+Override: si userConfig.modelo_principal está definido en plugin.json,
+aplícalo solo al Grupo OPUS (respeta preferencia del usuario para
+decisiones críticas sin afectar el costo de tareas rutinarias).
+```
+
+## PASO 4.5 — Planificación PTC (Programmatic Tool Calling) + revisión paralela
+
+Antes de ejecutar, clasifica las tareas seleccionadas según la skill `orquestacion-ptc`.
+
+**Revisión paralela post-implementación (B3):** Al terminar todas las tareas de implementación, si la spec toca áreas sensibles (auth, datos, APIs externas, seguridad), despacha revisor + crítico + seguridad en paralelo con PTC — los tres reciben el mismo diff y sus reportes se agregan en el reporte final. Esto es más barato que invocarlos secuencialmente.
+
+```javascript
+// PTC revisión paralela (solo si la spec toca áreas sensibles)
+const revisores = [
+  { agente: "revisor",   prompt: promptRevision(diff, spec, plan) },
+  { agente: "critico",   prompt: promptCritico(diff, spec, plan) },
+  { agente: "seguridad", prompt: promptSeguridad(diff, spec) },
+];
+const reportes = await Promise.all(
+  revisores.map(r => Task(r.agente, r.prompt))
+);
+// Agregar solo veredictos + hallazgos bloqueantes
+return reportes.map((r, i) => ({
+  agente:      revisores[i].agente,
+  veredicto:   r.veredicto,       // APROBADO | OBSERVACIONES | RECHAZADO
+  bloqueantes: r.bloqueantes,     // array de strings, vacío si no hay
+}));
+```
 
 Antes de ejecutar, clasifica las tareas seleccionadas según la skill `orquestacion-ptc`:
 
@@ -95,11 +178,11 @@ Tras el bloque PTC, **procesa las tareas del siguiente nivel del grafo** de form
 
 ---
 
-## PASO 4 — Ciclo por tarea
+## PASO 5 — Ciclo por tarea
 
 Para CADA tarea seleccionada, ejecuta este ciclo:
 
-### 4.1 — Verificar precondiciones
+### 5.1 — Verificar precondiciones
 
 ```bash
 # La tarea no debe estar completada/bloqueada
@@ -109,7 +192,7 @@ Para CADA tarea seleccionada, ejecuta este ciclo:
 Si una dependencia no está completa:
 > ⏸️ T00X depende de T00Y (no completada). Cambio el orden y ejecuto T00Y primero.
 
-### 4.2 — Anunciar inicio
+### 5.2 — Anunciar inicio
 
 ```
 🔧 T00X — [Nombre]
@@ -121,13 +204,13 @@ Si una dependencia no está completa:
 
 Marca la tarea como `en_progreso` en `.estado-tareas.json` y actualiza el TodoWrite.
 
-### 4.3 — Hook por tarea (opcional)
+### 5.3 — Hook por tarea (opcional)
 
 ```bash
 [ -f ".sdd/hooks/antes_cada_tarea.sh" ] && bash .sdd/hooks/antes_cada_tarea.sh "$TAREA_ID"
 ```
 
-### 4.4 — Activar MCP de Figma si la tarea es de UI/frontend
+### 5.4 — Activar MCP de Figma si la tarea es de UI/frontend
 
 **Antes de delegar al agente frontend**, verifica si la tarea es de tipo UI:
 
@@ -154,7 +237,7 @@ SI el agente NO es frontend → salta este paso
 
 > **Sin PAT / sin Figma:** Si `FIGMA_PAT` no está definido o la conexión falla, continúa sin el MCP — no bloquea la implementación.
 
-### 4.5 — Constitutional AI pre-check
+### 5.5 — Constitutional AI pre-check
 
 Antes de delegar al agente, extrae las restricciones de constitución relevantes para la tarea:
 
@@ -173,7 +256,7 @@ esac
 
 Inyecta el resultado en el contexto del agente como **restricciones explícitas**, no como contexto de fondo.
 
-### 4.6 — Delegar al agente
+### 5.6 — Delegar al agente
 
 Usa la herramienta `Task` para invocar al agente asignado. El agente recibe:
 
@@ -194,7 +277,7 @@ El agente debe:
 6. Devolver lista de archivos modificados
 7. **NUNCA modificar `package.json` ni instalar paquetes** salvo que la spec lo indique de forma explícita — usar exclusivamente las dependencias ya presentes en el proyecto
 
-### 4.6 — Checkpoint de salida por tarea
+### 5.7 — Checkpoint de salida + Evaluator-Optimizer
 
 Antes de marcar la tarea como completada, verifica en dos niveles:
 
@@ -219,6 +302,35 @@ Antes de marcar la tarea como completada, verifica en dos niveles:
 # Python: python -m pytest [directorio_afectado] -q
 ```
 
+**Nivel 4 — Evaluator-Optimizer (solo para agentes del Grupo OPUS: arquitecto, critico, seguridad, asesor-datos)**
+
+Si el agente de la tarea es del Grupo OPUS, activa el ciclo Evaluador-Optimizador:
+
+```
+CICLO EVALUADOR-OPTIMIZADOR (máx. 3 iteraciones):
+
+1. El agente implementador entrega su output (iteración actual)
+
+2. El agente REVISOR evalúa el output contra los CAs de la tarea:
+   - Puntúa cada CA de 0 a 10
+   - Score final = promedio
+   - Umbral de aprobación: 8/10
+
+3. Si score ≥ 8 → PASA directamente (el output es aceptable)
+
+4. Si score < 8 e iteraciones < 3:
+   - El revisor devuelve feedback específico al agente implementador
+   - El agente implementador mejora el output incorporando el feedback
+   - Repetir desde paso 2
+
+5. Si score < 8 tras la 3ª iteración:
+   → FALLA con reporte detallado (score, CAs que no pasan, razón)
+   → No se hacen más intentos automáticos
+
+Importante: el ciclo NO se aplica a agentes del Grupo SONNET ni HAIKU
+para evitar consumo excesivo de tokens en tareas rutinarias.
+```
+
 Si cualquier nivel falla:
 1. Marca como `bloqueada` con descripción del fallo
 2. **NO continúa con tareas dependientes**
@@ -230,7 +342,7 @@ Si cualquier nivel falla:
    > b) Saltar y continuar (no recomendado)
    > c) Detener y revisar manualmente
 
-### 4.7 — Actualizar estado
+### 5.8 — Actualizar estado
 
 ```bash
 # .estado-tareas.json: T00X → completada
@@ -238,13 +350,13 @@ Si cualquier nivel falla:
 # .sdd/estado.json: ultima_actualizacion
 ```
 
-### 4.8 — Hook post-tarea (opcional)
+### 5.9 — Hook post-tarea (opcional)
 
 ```bash
 [ -f ".sdd/hooks/despues_cada_tarea.sh" ] && bash .sdd/hooks/despues_cada_tarea.sh "$TAREA_ID"
 ```
 
-### 4.9 — Reportar
+### 5.10 — Reportar
 
 ```
 ✅ T00X completada
@@ -255,13 +367,13 @@ Si cualquier nivel falla:
 
 ## VALIDACIÓN DE SALIDA
 
-El checkpoint de salida se aplica por tarea (ver paso 4.6 — tres niveles: criterio de tarea, artefactos esperados, no regresión). Al final de todas las tareas, la validación global se ejecuta en el PASO 5 mediante el revisor y la suite de tests completa.
+El checkpoint de salida se aplica por tarea (ver paso 5.7 — cuatro niveles: criterio de tarea, artefactos esperados, no regresión, Evaluator-Optimizer para agentes OPUS). Al final de todas las tareas, la validación global se ejecuta en el PASO 6 mediante el revisor y la suite de tests completa.
 
 **Condición de bloqueo**: si cualquier checkpoint individual falla y el usuario no elige continuar explícitamente, la implementación se detiene y no avanza a `/sdd.verificar`.
 
-## PASO 5 — Al terminar todas las tareas
+## PASO 6 — Al terminar todas las tareas
 
-### 5.1 — Invocar revisor
+### 6.1 — Invocar revisor
 
 ```bash
 # Usar el agente revisor con modelo de su config (recomendado: opus)
@@ -272,7 +384,7 @@ El revisor cruza el código generado contra:
 - Las decisiones del plan
 - Los principios de la constitución
 
-### 5.2 — Invocar tester para correr toda la suite
+### 6.2 — Invocar tester para correr toda la suite
 
 ```bash
 # Detectar framework de tests automáticamente y correr
@@ -284,11 +396,11 @@ npm test 2>/dev/null || pnpm test 2>/dev/null || yarn test 2>/dev/null || \
   echo "NO_FRAMEWORK_DETECTADO"
 ```
 
-### 5.3 — Invocar seguridad (si la tarea tocaba área sensible)
+### 6.3 — Invocar seguridad (si la tarea tocaba área sensible)
 
 Auditoría automática si la implementación tocó: autenticación, manejo de datos personales, queries dinámicas, APIs externas, manejo de archivos.
 
-## PASO 6 — Reporte final exhaustivo
+## PASO 7 — Reporte final exhaustivo
 
 ```markdown
 ## 📊 Implementación Completada: {ID}
@@ -342,7 +454,7 @@ Cubre: {Lista de CAs}
 ```
 ```
 
-## PASO 7 — Actualizar estado global
+## PASO 8 — Actualizar estado global
 
 ```json
 {
@@ -356,13 +468,81 @@ Cubre: {Lista de CAs}
 }
 ```
 
-## PASO 8 — Hook post-ejecución
+## PASO 9 — Hook post-ejecución
 
 ```bash
 [ -f ".sdd/hooks/despues_implementar.sh" ] && bash .sdd/hooks/despues_implementar.sh
 ```
 
-## PASO 9 — Siguientes pasos
+## PASO 10 — Deploy automático (si está configurado)
+
+**Solo si perfil == "guiado" Y vercel configurado:**
+
+```bash
+# Verificar si Vercel está configurado
+if grep -q "deploy.platform: vercel" .sdd/sdd.config.yaml; then
+  echo ""
+  echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
+  echo "🚀 DESPLIEGUE AUTOMÁTICO"
+  echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
+  echo ""
+  echo "✅ Tu app está lista para internet."
+  echo ""
+  echo "CHECKLIST PRE-DEPLOY:"
+  echo "  ✅ Código construido y verificado"
+  echo "  ✅ Tests pasando"
+  echo "  ✅ Sin secretos en el código"
+  echo ""
+  echo "¿Publico tu app en internet?"
+  echo "(Responde: sí / cambio algo / después)"
+  echo ""
+  
+  read -p "Tu respuesta: " DEPLOY_CHOICE
+  
+  if [ "$DEPLOY_CHOICE" = "sí" ]; then
+    echo ""
+    echo "⏳ Publicando en Vercel..."
+    echo ""
+    
+    # Invocar skill vercel-deploy
+    bash "$(dirname "$0")/../skills/vercel-deploy/vercel-deploy.sh" \
+      --spec-id "$SPEC_ID" \
+      --profile "guiado"
+    
+    if [ $? -eq 0 ]; then
+      echo ""
+      echo "✅ ¡Tu app está en internet!"
+      echo ""
+      # Leer URL del archivo de estado de Vercel
+      VERCEL_URL=$(grep "app_url" .sdd/.vercel-deploy.json 2>/dev/null | cut -d'"' -f4)
+      if [ -n "$VERCEL_URL" ]; then
+        echo "   Acceso: $VERCEL_URL"
+        echo ""
+        echo "Puedes compartir este link con quien quieras."
+      fi
+    else
+      echo ""
+      echo "⚠️  Hubo un problema publicando."
+      echo ""
+      echo "Opciones:"
+      echo "  1. Reintentar: /sdd.desplegar"
+      echo "  2. Cambiar algo: edita y ejecuta /sdd.implementar continuar"
+      echo "  3. Dejar para después: los cambios están en GitHub"
+    fi
+  elif [ "$DEPLOY_CHOICE" = "cambio algo" ]; then
+    echo ""
+    echo "✅ Esos cambios se guardarán automáticamente."
+    echo "Cuando estés listo, ejecuta: /sdd.implementar continuar"
+  else
+    echo ""
+    echo "✅ Sin problema. Cuando quieras publicar, ejecuta: /sdd.desplegar"
+  fi
+fi
+```
+
+---
+
+## PASO 11 — Siguientes pasos
 
 ```
 🎉 Implementación terminada
@@ -370,7 +550,7 @@ Cubre: {Lista de CAs}
 SIGUIENTES PASOS RECOMENDADOS:
    /sdd.verificar       — verificación final contra spec original
    /sdd.snapshot        — actualizar SNAPSHOT.md del producto
-   (commit a tu sistema de control de versiones manualmente)
+   /sdd.retro           — retrospectiva: qué aprendimos
 
 ¿Quieres empezar otra feature?
    /sdd.especificar [descripción]

package/commands/sdd.interpretar.md

@@ -0,0 +1,239 @@
+---
+description: Punto de entrada de FORGE. Convierte una idea en texto libre a un IR JSON validado. Orquesta discovery + interpreter + validación. Primer comando para cualquier proyecto nuevo.
+allowed-tools: Read, Write, Bash
+---
+
+# /sdd.interpretar — Entrada a FORGE
+
+**Uso:**
+```
+/sdd.interpretar [idea en texto libre]
+```
+
+**Ejemplos:**
+```
+/sdd.interpretar Quiero una app para que mis clientes reserven citas
+/sdd.interpretar Necesito algo para organizar los pedidos de mi restaurante
+/sdd.interpretar Plataforma de cursos online con pagos y certificados
+/sdd.interpretar confirmar
+/sdd.interpretar corregir "es para múltiples negocios, no solo uno"
+```
+
+---
+
+## PASO 1 — Detectar modo de invocación
+
+```bash
+ARGS="$*"
+```
+
+Detecta el caso:
+
+| Argumento | Modo |
+|-----------|------|
+| `confirmar` o `sí` | Confirmar IR pendiente → guardar |
+| `corregir [qué]` | Corregir campo del IR pendiente |
+| `ver` | Mostrar IR actual en `.sdd/ir.json` |
+| `[texto libre]` | Nueva idea → flujo completo |
+| *(vacío)* | Pedir que escriba su idea |
+
+---
+
+## PASO 2 — Si es texto libre: flujo completo
+
+### 2.1 — Verificar si hay IR anterior
+
+```bash
+if [ -f ".sdd/ir.json" ]; then
+  echo "HAY_IR_ANTERIOR"
+  cat .sdd/ir.json | grep '"name"' | head -1
+fi
+```
+
+Si hay IR anterior, pregunta:
+```
+Ya tienes un proyecto en curso: [product.name]
+
+¿Qué quieres hacer?
+  1) Continuar con ese proyecto → escribe /sdd.diseñar
+  2) Actualizar la idea de ese proyecto → escribe /sdd.interpretar corregir [qué]
+  3) Empezar un proyecto nuevo → escribe /sdd.interpretar nuevo [idea]
+```
+
+Si no hay IR anterior, continúa.
+
+### 2.2 — Crear carpeta .sdd/
+
+```bash
+mkdir -p .sdd
+```
+
+### 2.3 — Invocar skill `descubrir-idea`
+
+Activa la skill de discovery. La skill hace las 5 preguntas y guarda `.sdd/descubrimiento.md`.
+
+Después de que el usuario responda las 5 preguntas, continúa al paso 2.4.
+
+### 2.4 — Invocar skill `interpretar-idea`
+
+Activa la skill con la idea original del usuario + contexto de `.sdd/descubrimiento.md`.
+
+La skill genera el IR JSON en 2 fases (razonamiento libre + extracción JSON) y lo muestra al usuario.
+
+**Si la skill requiere clarificación** (`confidence < 0.7`): el usuario responde la pregunta, y la skill re-genera el IR. Luego continúa.
+
+---
+
+## PASO 3 — Si es `confirmar` o `sí`
+
+```bash
+# Verificar que hay un IR pendiente de confirmar
+if [ ! -f ".sdd/ir-pendiente.json" ] && [ ! -f ".sdd/ir.json" ]; then
+  echo "No hay ningún IR pendiente. Escribe tu idea primero:"
+  echo "  /sdd.interpretar [tu idea]"
+  exit 0
+fi
+```
+
+Guarda el IR:
+
+```bash
+cp .sdd/ir-pendiente.json .sdd/ir.json 2>/dev/null || true
+```
+
+Actualiza `.sdd/estado.json`:
+
+```bash
+# Leer estado actual o crear si no existe
+if [ -f ".sdd/estado.json" ]; then
+  # Agregar campo ir_generado: true
+  node -e "
+    const fs = require('fs');
+    const estado = JSON.parse(fs.readFileSync('.sdd/estado.json', 'utf8'));
+    estado.ir_generado = true;
+    estado.ir_id = JSON.parse(fs.readFileSync('.sdd/ir.json', 'utf8')).id;
+    estado.ultima_actualizacion = new Date().toISOString();
+    fs.writeFileSync('.sdd/estado.json', JSON.stringify(estado, null, 2));
+  " 2>/dev/null || echo "{ \"ir_generado\": true, \"ultima_actualizacion\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\" }" > .sdd/estado.json
+fi
+```
+
+Muestra confirmación y siguiente paso:
+
+```
+✅ IR guardado en .sdd/ir.json
+
+Siguiente paso → Diseño de pantallas y arquitectura:
+  /sdd.diseñar
+
+O si quieres ir directo al código (diseño automático):
+  /sdd.construir
+```
+
+---
+
+## PASO 4 — Si es `corregir [qué]`
+
+Extrae la corrección del argumento. Por ejemplo:
+- `/sdd.interpretar corregir "es para múltiples negocios"` → actualizar `product.target_users` y/o `assumptions`
+
+Lee el IR actual:
+
+```bash
+cat .sdd/ir.json 2>/dev/null || cat .sdd/ir-pendiente.json 2>/dev/null
+```
+
+Aplica la corrección al campo correspondiente del IR. Re-valida. Muestra el IR actualizado y pide confirmación de nuevo.
+
+---
+
+## PASO 5 — Si es `ver`
+
+```bash
+cat .sdd/ir.json 2>/dev/null || echo "No hay IR guardado todavía."
+```
+
+Muestra el IR en formato legible (igual que la skill `interpretar-idea`).
+
+---
+
+## PASO 6 — Si argumento vacío
+
+```
+¿Cuál es tu idea?
+
+Cuéntamela en una frase o párrafo. No te preocupes por el formato.
+
+Ejemplos:
+  /sdd.interpretar Quiero una app para gestionar turnos de mi peluquería
+  /sdd.interpretar Sistema para que mis empleados registren sus horas de trabajo
+  /sdd.interpretar Marketplace de servicios para freelancers
+```
+
+---
+
+## Estructura de archivos generados
+
+```
+.sdd/
+  descubrimiento.md      ← Respuestas del discovery (5 preguntas)
+  ir-analysis.md         ← Análisis libre de la Fase A del Interpreter
+  ir-pendiente.json      ← IR generado, esperando confirmación del usuario
+  ir.json                ← IR confirmado (se crea solo tras "confirmar")
+  estado.json            ← Estado global del proyecto (ir_generado: true)
+```
+
+---
+
+## Integración con el pipeline
+
+Después de `/sdd.interpretar confirmar`:
+
+```
+/sdd.diseñar     → Diseña pantallas, elige dirección visual, genera wireframe
+/sdd.construir   → Pipeline completo: diseño + spec + plan + tareas + código
+/sdd.estado      → Ver estado actual del proyecto
+```
+
+---
+
+## Opciones avanzadas
+
+### Modo silencioso (sin discovery)
+
+Si el usuario ya dio suficiente contexto en la idea:
+
+```
+/sdd.interpretar --rapido [idea detallada]
+```
+
+Salta el discovery y va directo al Interpreter.
+
+### Actualizar proyecto existente
+
+```
+/sdd.interpretar actualizar "quiero agregar pagos en línea"
+```
+
+1. Lee IR actual
+2. Interpreta el cambio
+3. Fusiona (agrega feature, actualiza assumptions)
+4. Re-valida y pide confirmación
+
+### Nuevo proyecto (ignorar IR anterior)
+
+```
+/sdd.interpretar nuevo [idea]
+```
+
+Archiva el IR anterior en `.sdd/ir-anterior-[timestamp].json` y empieza desde cero.
+
+---
+
+## Notas de implementación
+
+- Este comando es el **único punto de entrada** para usuarios no técnicos
+- El IR es la **fuente de verdad** del proyecto — todo lo demás se deriva de él
+- La skill `descubrir-idea` y la skill `interpretar-idea` son los módulos reales — este comando las orquesta
+- Si el usuario dice "sí" o "confirmar" en cualquier momento durante el flujo, se guarda el IR actual
+- El modelo **nunca inventa** datos del usuario — todo en `assumptions[]` debe ser explícito

package/commands/sdd.md

@@ -20,6 +20,24 @@ else
 fi
 ```
 
+## PASO 1.2 — Detectar modo de output
+
+Si el argumento del comando contiene un modo de output (`pm`, `arq`, `dev`), actívalo globalmente para esta sesión:
+
+| Argumento | Modo | Descripción |
+|-----------|------|-------------|
+| `pm` o `producto` | **Product Manager** | Lenguaje de negocio, sin código, bullets ejecutivos. Oculta detalles técnicos. |
+| `arq` o `arquitectura` | **Arquitecto** | Diagramas, decisiones técnicas, trade-offs. Para revisiones de diseño. |
+| `dev` o `desarrollo` | **Desarrollador** | Código, diffs, comandos. Modo por defecto. |
+
+Ejemplos:
+- `/sdd.estado pm` → dashboard en lenguaje de negocio
+- `/sdd.verificar arq` → reporte técnico con diagramas
+- `/sdd.analizar dev` → análisis con código y rutas de archivo
+
+El modo se guarda en `MODO_OUTPUT` y lo usan todos los comandos que producen reportes.  
+Si no se especifica, usa `dev` (comportamiento actual).
+
 ## PASO 1.5 — Detectar el perfil y ajustar el modo de conducción
 
 Lee el perfil desde el estado o la configuración:
@@ -48,6 +66,11 @@ El usuario invocó este comando con argumentos en lenguaje natural. Mapea su int
 
 | Intención del usuario | Comando a ejecutar |
 |----------------------|--------------------|
+| "tengo una idea", "quiero crear", "quiero construir X desde cero", "dame una app de X" | `/sdd.interpretar [idea]` |
+| "interpreta mi idea", "analiza lo que quiero hacer" | `/sdd.interpretar` |
+| "diseña el producto", "elige el estilo", "quiero ver el wireframe" | `/sdd.diseñar` |
+| "construye todo", "haz el código completo", "pipeline completo" | `/sdd.construir` |
+| "exporta el bundle", "empaqueta el proyecto" | `/sdd.exportar` |
 | "quiero inicializar", "configurar el proyecto", "empezar" | `/sdd.constitucion` |
 | "quiero crear una feature", "nueva spec", "voy a hacer X" | `/sdd.especificar [resto]` |
 | "quiero importar una spec externa" | `/sdd.importar [resto]` |
@@ -75,9 +98,45 @@ El usuario invocó este comando con argumentos en lenguaje natural. Mapea su int
 | "crea un MCP", "quiero una herramienta para Claude", "genera un servidor MCP" | `/sdd.crear-mcp [resto]` |
 | "ayuda", "qué puedes hacer" | `/sdd.ayuda` |
 
+## PASO 2.5 — Detectar IR sin spec activa (FORGE)
+
+Si hay `.sdd/ir.json` pero NO hay spec activa, sugiere el siguiente paso del pipeline de FORGE:
+
+```bash
+HAS_IR=$([ -f ".sdd/ir.json" ] && echo "yes" || echo "no")
+HAS_DESIGN=$([ -f ".sdd/product-design.json" ] && echo "yes" || echo "no")
+SPEC_ACTIVA=$(cat .sdd/estado.json 2>/dev/null | grep -o '"spec_activa": *"[^"]*"' | cut -d'"' -f4)
+```
+
+Si `HAS_IR=yes` y sin spec activa:
+
+> Ya tienes una idea interpretada: **[product.name]**.
+>
+> ¿Qué quieres hacer?
+> - `/sdd.diseñar` → elegir estilo visual y generar wireframe
+> - `/sdd.construir` → pipeline completo automático (diseño + código)
+> - `/sdd.exportar` → empaquetar lo que hay ahora
+
+---
+
 ## PASO 3 — Si no está inicializado
 
-Si el proyecto NO está inicializado, no importa qué pidió el usuario — responde:
+Si el proyecto NO está inicializado, primero verifica si la intención del usuario es FORGE (idea → MVP):
+
+```bash
+TIENE_IDEA=$(echo "$ARGS" | grep -iE "tengo una idea|quiero crear|quiero construir|quiero una app|necesito|idea" && echo "yes" || echo "no")
+TIENE_INTERPRETAR=$(echo "$ARGS" | grep -iE "interpreta|interpretar" && echo "yes" || echo "no")
+```
+
+**Si la intención es FORGE** (tiene idea, quiere crear algo desde cero):
+
+> 👋 Empecemos. No necesitas inicializar nada primero.
+>
+> Cuéntame tu idea y FORGE la convierte en un producto.
+
+Llama directamente a `/sdd.interpretar [idea del usuario]`. FORGE crea `.sdd/` automáticamente.
+
+**Si la intención NO es FORGE** (quiere usar sdd-lite para una feature de código existente):
 
 > 👋 Bienvenido a SDD-ES.
 >
@@ -87,6 +146,16 @@ Si el proyecto NO está inicializado, no importa qué pidió el usuario — resp
 
 Luego llama internamente a `/sdd.constitucion`.
 
+**Si no hay argumentos** (usuario escribió solo `/sdd` en proyecto no inicializado):
+
+> 👋 Bienvenido. ¿Qué quieres hacer?
+>
+> **Tengo una idea y quiero construirla**
+> → `/sdd.interpretar [tu idea]`
+>
+> **Tengo un proyecto de código y quiero especificar features**
+> → `/sdd.constitucion` (configura el proyecto primero)
+
 ## PASO 4 — Si ya está inicializado pero hay una spec activa incompleta
 
 Lee `estado.json` y `.estado-tareas.json` de la spec activa.