sdd-es 2.5.0 → 2.6.0

package/commands/sdd.implementar.md

@@ -1,6 +1,6 @@
 ---
 description: Ejecuta las tareas con los agentes especializados configurados. Modos: todas en secuencia (sin args), tarea específica (T003), continuar (continuar). Cada tarea se verifica antes de la siguiente.
-allowed-tools: Read, Write, Edit, Bash, Task, TodoWrite, mcp__sdd-figma__analizar_sistema_diseño, mcp__sdd-figma__evaluar_ui_existente, mcp__sdd-figma__conectar_figma, mcp__sdd-figma__listar_componentes, mcp__sdd-figma__traer_componente, mcp__sdd-figma__mapear_estilos, mcp__sdd-figma__generar_componente, mcp__sdd-figma__sugerir_mejoras
+allowed-tools: Read, Write, Edit, Bash, Task, TodoWrite
 handoffs:
   - etiqueta: "Verificar contra spec"
     comando: sdd.verificar
@@ -210,34 +210,7 @@ Marca la tarea como `en_progreso` en `.estado-tareas.json` y actualiza el TodoWr
 [ -f ".sdd/hooks/antes_cada_tarea.sh" ] && bash .sdd/hooks/antes_cada_tarea.sh "$TAREA_ID"
 ```
 
-### 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:
-
-```
-SI el agente asignado es "desarrollador-frontend"
-O el tipo/área de la tarea contiene: ui, componente, interfaz, diseño, vista, pantalla, layout, figma:
-
-  1. Ejecuta: mcp__sdd-figma__analizar_sistema_diseño({ project_root: "." })
-     → Guarda el perfil en contexto para el agente
-
-  2. SI la constitución o config del proyecto tiene figma_file_key definido:
-     a. Ejecuta: mcp__sdd-figma__conectar_figma({ file_key: "<key>" })
-     b. Si la tarea menciona un componente específico de Figma:
-        - mcp__sdd-figma__traer_componente({ file_key, node_id })
-        - mcp__sdd-figma__mapear_estilos({ file_key, node_id, project_root: "." })
-     c. Inyecta el resultado del mapeo en el contexto del agente
-
-  3. Si hay tokens sin mapear (matchType: "new"), avisa al usuario:
-     > ⚠️ Figma tiene [N] colores sin equivalente en el proyecto.
-     > El agente usará el valor hex directo. ¿Continuar?
-
-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.
-
-### 5.5 — Constitutional AI pre-check
+### 5.4 — Constitutional AI pre-check
 
 Antes de delegar al agente, extrae las restricciones de constitución relevantes para la tarea:
 
@@ -266,14 +239,14 @@ Usa la herramienta `Task` para invocar al agente asignado. El agente recibe:
 - Constitución
 - Tareas ya completadas en este ciclo (contexto)
 - Lista de archivos modificados hasta ahora
-- **[Si es UI]** Perfil del sistema de diseño + mapeo de estilos Figma (del paso 4.4)
+- **[Si es UI]** Perfil del sistema de diseño del proyecto
 
 El agente debe:
 1. Leer el código existente relacionado antes de escribir
 2. Seguir patrones del codebase actual
 3. Implementar SOLO lo que la tarea pide
 4. Respetar la constitución
-5. **[Si es UI]** Usar `mcp__sdd-figma__generar_componente` como punto de partida si hay node_id disponible
+5. **[Si es UI]** Leer el sistema de diseño local antes de generar componentes
 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
 
@@ -365,6 +338,73 @@ Si cualquier nivel falla:
    [N]/[M] tareas completadas ([X]%)
 ```
 
+### 5.10.5 — Gate de calidad automático (antes de marcar DONE)
+
+Antes de marcar cualquier tarea como `completada`, ejecuta este gate en orden. **Los 3 puntos deben pasar**; si alguno falla, la tarea queda en `en_progreso` con el motivo anotado.
+
+**Punto 1 — Tests corren y pasan**
+```bash
+# Detectar framework y correr solo los tests relacionados con los archivos modificados
+TS_FILES=$(echo "$ARCHIVOS_MODIFICADOS" | tr ',' ' ')
+
+# Intento rápido (tests relacionados):
+npx jest --passWithNoTests --findRelatedTests $TS_FILES 2>/dev/null \
+  || python -m pytest $TS_FILES -q 2>/dev/null \
+  || echo "SKIP_NO_FRAMEWORK"
+
+# Si no hay tests relacionados detectables, corre la suite completa en modo quiet:
+# npm test -- --silent 2>/dev/null || echo "NO_TESTS_OK"
+```
+Resultado esperado: exit code 0 o "SKIP_NO_FRAMEWORK" / "NO_TESTS_OK".
+Si hay fallos de test → tarea queda `en_progreso`: `"Tests fallando: [detalle]"`.
+
+**Punto 2 — Linter pasa (o no hay linter configurado)**
+```bash
+# Detectar linter y ejecutar solo sobre archivos modificados
+if [ -f ".eslintrc*" ] || [ -f "eslint.config*" ]; then
+  npx eslint $TS_FILES --max-warnings=0 2>/dev/null
+elif [ -f "pyproject.toml" ] || [ -f ".flake8" ]; then
+  flake8 $TS_FILES 2>/dev/null || ruff check $TS_FILES 2>/dev/null
+else
+  echo "NO_LINTER_CONFIGURADO"
+fi
+```
+Resultado esperado: exit code 0 o "NO_LINTER_CONFIGURADO".
+Si hay errores de linter → tarea queda `en_progreso`: `"Linter fallando: [detalle]"`.
+
+**Punto 3 — Criterio de aceptación de la tarea se cumple**
+
+Lee la sección "Criterio de verificación" de la tarea en `tareas.md` y ejecuta el comando definido ahí. Si no hay comando definido, verifica manualmente que los artefactos esperados existen y exportan correctamente (según paso 5.7 niveles 1 y 2).
+
+Resultado esperado: el comando retorna exit 0 O la inspección manual confirma que el CA está cubierto.
+Si el CA no se cumple → tarea queda `en_progreso`: `"CA no cumplido: [razón]"`.
+
+**Decisión final:**
+```
+SI los 3 puntos pasan  → marcar tarea como `completada` → continuar al paso 5.10
+SI alguno falla        → marcar tarea como `en_progreso` con campo "motivo_bloqueo"
+                       → NO avanzar a tareas dependientes
+                       → Reportar al usuario:
+                         ⚠️ T00X no pasó el gate de calidad: [motivo]
+                         ¿Qué hacemos?
+                         a) Reintentar corrección automática
+                         b) Saltar (no recomendado, registra deuda técnica)
+                         c) Detener y revisar manualmente
+```
+
+### 5.11 — Checkpoint de contexto (compresión automática)
+
+Lleva un contador de tareas completadas en este ciclo. **Tras cada 5 tareas completadas**, ejecuta automáticamente la compresión de contexto para evitar el desbordamiento de la ventana en sesiones largas:
+
+```
+SI (tareas_completadas_en_ciclo % 5 == 0) Y tareas_completadas_en_ciclo > 0:
+  → Notificar: "🧹 Checkpoint de contexto: 5 tareas completadas, comprimiendo contexto…"
+  → Ejecutar: /sdd.comprimir aplicar
+  → Continuar con la siguiente tarea
+```
+
+Esto se hace de forma silenciosa y no requiere confirmación del usuario: es un mantenimiento automático del presupuesto de tokens. Si quedan menos de 5 tareas pendientes, no se fuerza un checkpoint extra (la compresión final ocurre en el PASO 6).
+
 ## VALIDACIÓN DE SALIDA
 
 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.

package/commands/sdd.md

@@ -20,6 +20,20 @@ else
 fi
 ```
 
+**Recuperación de contexto automática:** Si existe `.sdd/estado.json`, antes de pedir nada al usuario muestra un resumen de **exactamente 3 líneas** con:
+
+1. `pipeline_step` actual (campo `pipeline_step` del estado).
+2. Spec activa (campo `spec_activa` o equivalente).
+3. Número de tareas pendientes.
+
+Ejemplo:
+
+```
+Paso del pipeline: implementar
+Spec activa: 2026-06-14-auth
+Tareas pendientes: 3
+```
+
 ## 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:
@@ -45,10 +59,11 @@ Lee el perfil desde el estado o la configuración:
 ```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 ' ')
-echo "PERFIL=${PERFIL:-experto}"
+# Por defecto: modo guiado (sin jerga) — si sdd.config.yaml declara explícitamente "perfil: experto", se respeta
+echo "PERFIL=${PERFIL:-guiado}"
 ```
 
-**Si `PERFIL=guiado`:** activa la skill `modo-guiado` y conduce TODO el resto de la interacción según sus 6 reglas (sin jerga, confirmar antes de actuar, una pregunta a la vez, nunca pedir que edite archivos). En este modo:
+**Si `PERFIL=guiado` (o no hay perfil configurado):** activa la skill `modo-guiado` y conduce TODO el resto de la interacción según sus 6 reglas (sin jerga, confirmar antes de actuar, una pregunta a la vez, nunca pedir que edite archivos). En este modo:
 
 - **Encadenas automáticamente** los pasos del flujo (especificar → planificar → tareas → implementar) pidiendo solo una confirmación simple entre fases, sin exponer los nombres de los comandos. El usuario dice "sí" y tú avanzas.
 - Traduces cada fase a lenguaje natural (ver tabla en la skill `modo-guiado`).
@@ -58,7 +73,7 @@ Ejemplo de conducción en modo guiado:
 
 > Entendido, quieres una lista de tareas. Primero voy a entender bien los detalles, luego lo construyo y lo pruebo. ¿Arrancamos? (responde *sí*)
 
-**Si `PERFIL=experto` (o no hay perfil):** sigue el enrutamiento normal del PASO 2, exponiendo comandos.
+**Si `PERFIL=experto`:** sigue el enrutamiento normal del PASO 2, exponiendo comandos técnicos. Este modo se activa SOLO cuando el archivo `sdd.config.yaml` incluye explícitamente `perfil: experto`.
 
 ## PASO 2 — Interpretar la intención del usuario
 
@@ -92,6 +107,11 @@ El usuario invocó este comando con argumentos en lenguaje natural. Mapea su int
 | "cambia configuración", "ajusta agentes/modelos" | `/sdd.configurar` |
 | "indexa el proyecto", "genera mapa de símbolos" | `/sdd.mapear` |
 | "comprime", "ahorra tokens", "compacta memoria" | `/sdd.comprimir` |
+| "optimiza artefactos", "reduce contexto" | `/sdd.optimizar` |
+| "optimiza memoria", "compacta agente" | `/sdd.optimizar-memoria` |
+| "compliance", "reporte regulatorio", "GDPR", "SOC2" | `/sdd.compliance` |
+| "registra decisión", "ADR", "architecture decision" | `/sdd.adr` |
+| "reporte de bugs", "defect rate", "tasa de defectos" | `/sdd.defect-report` |
 | "haz un release", "nueva versión", "changelog" | `/sdd.release` |
 | "descubre el proyecto", "tengo una idea vaga" | `/sdd.descubrir` |
 | "crea una app", "construye una app", "quiero una app de X" | `/sdd.crear-app [resto]` |

package/commands/sdd.optimizar-memoria.md

@@ -0,0 +1,47 @@
+---
+description: Comprimir manualmente la memoria de agentes (deduplicación + compresión)
+allowed-tools: Read, Write, Bash
+---
+
+# /sdd.optimizar memoria
+
+Comprime automáticamente los archivos de memoria de agentes (`.sdd/memoria/agente-*.md`) cuando superan 50KB.
+
+## Uso
+
+```
+/sdd.optimizar memoria
+```
+
+## Qué Hace
+
+1. **Lee** archivos en `.sdd/memoria/`
+2. **Deduplica** entradas por filepath (guarda solo la más reciente)
+3. **Comprime** aplicando diccionario Caveman Level Full
+4. **Crea backup** `.original.md` antes de sobrescribir
+5. **Reporta** bytes salvados
+
+## Ejemplo
+
+```
+ANTES: agente-arquitecto.md = 150KB (80 entradas)
+
+/sdd.optimizar memoria
+
+✨ [compress] arquitecto: 150KB → 15KB (10%), backup en .original.md
+✨ [compress] critico: 87KB → 8.7KB (10%)
+
+DESPUÉS: memoria total = 24KB
+```
+
+## Seguridad
+
+- Nunca pierdes datos (backup siempre)
+- Idempotente (ejecutar 2 veces = mismo resultado)
+- Reversible: `.original.md` contiene datos originales
+
+## Notas
+
+- Se ejecuta automáticamente vía hook cuando memoria > 50KB
+- Puedes ejecutarla manualmente cuando quieras
+- Segura para ejecutar frecuentemente (sin riesgos)

package/commands/sdd.retro.md

@@ -55,6 +55,80 @@ Si un aprendizaje implica un **principio nuevo** del proyecto, sugiere actualiza
 
 > Este aprendizaje parece una regla general del proyecto. ¿Lo elevo a la constitución con `/sdd.constitucion`?
 
+## PASO 3.5 — Resumen de calidad al cierre
+
+Al final de cada sesión de implementación, antes del resumen de retro, FORGE genera automáticamente un **resumen de calidad en lenguaje de producto** (~5 líneas, sin jerga técnica). El objetivo es que el usuario entienda qué se hizo y en qué estado quedó sin leer tablas ni logs.
+
+### Cómo construirlo
+
+```bash
+# Recopilar señales objetivas del ciclo
+TAREAS_OK=$(grep -c '"estado": "completada"' "$DIR/.estado-tareas.json" 2>/dev/null || echo "?")
+TAREAS_TOTAL=$(grep -c '"estado"' "$DIR/.estado-tareas.json" 2>/dev/null || echo "?")
+
+# Tests: buscar resultado en verificacion.md o qa.md
+TESTS_RESULTADO=$(grep -oE "Pasados: [0-9]+" "$DIR/verificacion.md" 2>/dev/null | head -1)
+TESTS_FALLIDOS=$(grep -oE "Fallidos: [0-9]+" "$DIR/verificacion.md" 2>/dev/null | head -1)
+COBERTURA=$(grep -oE "Cobertura: [0-9]+%" "$DIR/verificacion.md" 2>/dev/null | head -1)
+
+# Seguridad: ¿se invocó el agente seguridad?
+SEGURIDAD=$(grep -q "Gate de seguridad activado\|agente seguridad" "$DIR/verificacion.md" 2>/dev/null \
+  && echo "revisión de seguridad incluida" || echo "sin revisión de seguridad (no aplica)")
+
+# Feature principal: título de la spec
+TITULO=$(grep -m1 "^# " "$DIR/spec.md" 2>/dev/null | sed 's/# //')
+```
+
+### Formato del resumen (adaptar al perfil)
+
+**Perfil `guiado`** (lenguaje de producto, sin jerga):
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+📦 Resumen de lo que se hizo
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Hiciste [TÍTULO en lenguaje natural].
+Pruebas: [✓ N/N pasaron | ✗ N fallaron | no hay pruebas aún].
+[Si hubo seguridad]: Se revisó la seguridad — sin problemas encontrados.
+[Si hay cobertura]: Cobertura: N%.
+Listo para [usar / probar / desplegar].
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+Ejemplo concreto:
+```
+Hiciste el login con email.
+Pruebas: ✓ 12/12 pasaron.
+Se revisó la seguridad — sin vulnerabilidades.
+Cobertura: 87%.
+Listo para usar.
+```
+
+**Perfil `profesional`** (lenguaje técnico compacto):
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+📊 Quality Summary — {SPEC_ID}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Feature:   [TÍTULO]
+Tareas:    [N/M completadas]
+Tests:     [✓ N pasaron | ✗ N fallaron] · Cobertura: [N% | N/A]
+Seguridad: [Auditada — APROBADO | No aplica (sin keywords sensibles)]
+Estado:    [APROBADA | APROBADA CON OBSERVACIONES | RECHAZADA]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+### Cuándo se genera
+
+Este resumen se emite **siempre** al ejecutar `/sdd.retro`, independientemente de si la sesión terminó bien o mal. Si la sesión terminó con tareas bloqueadas o tests fallando, el resumen lo refleja honestamente:
+
+```
+Hiciste el login con email (en progreso).
+Pruebas: ✗ 2 fallaron (ver verificacion.md).
+No se revisó seguridad.
+Pendiente: corregir errores antes de entregar.
+```
+
+El resumen se incluye también en la entrada que se escribe en `.sdd/SNAPSHOT.md` (paso 3).
+
 ## PASO 4 — Resumen
 
 ```

package/commands/sdd.verificar.md

@@ -66,6 +66,77 @@ Lee el código encontrado. ¿Realmente implementa lo que pide el CA?
 
 Repite el proceso para cada RF-XXX de la spec.
 
+## PASO 4.5 — Gate de seguridad automático
+
+**Antes de continuar con los requisitos no funcionales**, escanea la spec y las tareas en busca de keywords sensibles. Si se detecta alguna, invoca al agente `seguridad` automáticamente sin esperar a que el usuario lo solicite.
+
+### Keywords que activan el gate de seguridad
+
+```
+KEYWORDS_AUTH:
+  auth, login, logout, signin, signup, registro, sesión, session,
+  password, contraseña, credenciales, credentials
+
+KEYWORDS_TOKENS:
+  token, jwt, bearer, oauth, api_key, apikey, secret, secreto
+
+KEYWORDS_DATOS:
+  base de datos, bd, database, sql, query, consulta, migration, migracion,
+  postgres, mysql, sqlite, mongodb, redis
+
+KEYWORDS_CONFIG:
+  config, configuracion, .env, environment, variable de entorno,
+  settings, dotenv
+
+KEYWORDS_PAGOS:
+  pago, payment, stripe, checkout, factura, invoice, tarjeta, card,
+  billing, cobro, precio, price
+```
+
+### Lógica de detección
+
+```bash
+SPEC_CONTENT=$(cat "${SPEC_DIR}/spec.md" "${SPEC_DIR}/tareas.md" 2>/dev/null | tr '[:upper:]' '[:lower:]')
+
+KEYWORDS="auth|login|logout|signin|signup|registro|sesión|session|\
+password|contraseña|credenciales|credentials|\
+token|jwt|bearer|oauth|api_key|apikey|secret|secreto|\
+base de datos| bd |database|sql|migration|migracion|\
+postgres|mysql|sqlite|mongodb|redis|\
+config|configuracion|\.env|environment|dotenv|\
+pago|payment|stripe|checkout|factura|tarjeta|billing"
+
+if echo "$SPEC_CONTENT" | grep -qiE "$KEYWORDS"; then
+  KEYWORD_DETECTADA=$(echo "$SPEC_CONTENT" | grep -oiE "$KEYWORDS" | head -1)
+  echo "🔒 Gate de seguridad activado automáticamente (keyword detectada: '$KEYWORD_DETECTADA')"
+  echo "   Invocando agente seguridad..."
+  # → Task("seguridad", prompt_seguridad(spec, plan, diff, keyword))
+  GATE_SEGURIDAD_EJECUTADO=true
+else
+  echo "✅ Gate de seguridad: sin keywords sensibles detectadas. Omitiendo."
+  GATE_SEGURIDAD_EJECUTADO=false
+fi
+```
+
+### Qué hace el agente `seguridad` en este contexto
+
+Recibe: spec completa + plan + diff de archivos modificados + keyword que activó el gate.
+
+Verifica mínimamente:
+- Ausencia de secretos hardcodeados en el diff
+- Validación/sanitización de inputs sensibles
+- Ausencia de SQL dinámico sin parametrizar
+- Tokens/passwords no logueados ni expuestos en respuestas
+- Configuraciones sensibles gestionadas via variables de entorno
+
+Retorna: `APROBADO` | `OBSERVACIONES` | `RECHAZADO` + lista de hallazgos.
+
+Si retorna `RECHAZADO` → la verificación global queda `RECHAZADA` independientemente de los CAs.
+Si retorna `OBSERVACIONES` → se documentan en el reporte de verificación bajo "Hallazgos 🟡 Importantes".
+Si retorna `APROBADO` → continúa normalmente.
+
+> **Nota**: si el agente `seguridad` ya fue invocado durante `sdd.implementar` (paso 6.3 o revisión paralela del paso 4.5), sus resultados se reutilizan y no se invoca de nuevo — se indica en el reporte: `"Seguridad: resultado reutilizado de implementación (fecha/hora)"`.
+
 ## PASO 5 — Verificar requisitos no funcionales
 
 Estos requieren validación específica:

package/configuracion-ejemplo/.claude/CLAUDE.md

@@ -0,0 +1,106 @@
+# Proyecto SDD — Instrucciones para Claude Code
+
+Este proyecto usa el flujo **SDD-ES** (Spec-Driven Development).
+El estado vive en `.sdd/` y se sincroniza con cada comando `/sdd.*`.
+
+## Recuperación de contexto al inicio
+
+Al comenzar cada sesión, antes de pedir nada al usuario:
+
+1. Si existe `.sdd/estado.json`, cárgalo y léelo.
+2. Muestra un resumen breve (máx. 3 líneas) con la fase actual, feature activa y tareas pendientes.
+3. Si no existe, sugiere escribir `/sdd` para empezar.
+
+Ejemplo de resumen:
+```
+Estás en: implementar · feature activa: login con email · 3 pasos pendientes.
+```
+
+## Reglas del proyecto
+
+@.sdd/memoria/constitucion.md
+@.sdd/memoria/reglas-proyecto.md
+
+- No edites `.sdd/estado.json` manualmente; los comandos `/sdd.*` lo gestionan.
+- Respeta la spec activa: no implementes fuera de ella sin avisar.
+- La memoria de cada agente vive en `.sdd/memoria/agente-{nombre}.md`.
+
+## Hooks activos
+
+| Hook | Archivo | Cuándo se ejecuta |
+|------|---------|-------------------|
+| PreToolUse | `claude-hooks/pre-tool-guard.js` | Antes de cada comando Bash/PowerShell |
+| PostToolUse | `claude-hooks/agent-memory.js` | Al finalizar cada herramienta (guarda memoria de agentes) |
+
+Los hooks bloquean operaciones destructivas y protegen secretos automáticamente.
+No es necesario configurarlos — ya están activos.
+
+## Convención de commits
+
+Formato: `[LAYER] ACTION: descripción breve`
+
+| Capa | Cuándo usarla |
+|------|---------------|
+| `[SPEC]` | Cambios en especificaciones o plan |
+| `[IMPL]` | Código de implementación |
+| `[TEST]` | Tests nuevos o modificados |
+| `[INFRA]` | Configuración, CI, dependencias |
+| `[DOCS]` | Documentación |
+
+Ejemplos:
+```
+[IMPL] ADD: login con magic link
+[TEST] FIX: corrige test flaky de autenticación
+[SPEC] UPDATE: aclara criterios de aceptación del módulo de pagos
+```
+
+## Comandos clave
+
+- `/sdd` — punto de entrada: detecta contexto y te guía al siguiente paso.
+- `/sdd.especificar` — define o refina una feature.
+- `/sdd.implementar` — ejecuta las tareas de la feature activa.
+- `/sdd.comprimir aplicar` — reduce el contexto en sesiones largas.
+- `/mejorar-prompt "texto"` — transforma un prompt vago en versión profesional.
+
+---
+
+## Metodología de prompts
+
+Antes de ejecutar cualquier instrucción del usuario que modifique archivos o inicie
+una tarea nueva, comprueba que la petición tiene al menos **3 de los 5 componentes**
+de un prompt profesional:
+
+| Componente | Descripción | Señal de que falta |
+|---|---|---|
+| **Contexto** | Qué proyecto/stack/estado existe ya | El usuario no menciona el proyecto |
+| **Tarea** | Qué hay que hacer exactamente | La instrucción es de 1-2 palabras |
+| **Restricciones** | Qué no tocar, qué no instalar | No se especifica qué preservar |
+| **Formato** | Cómo quiere el resultado | No aplica a todos los casos |
+| **Verificación** | Cómo confirmar que funcionó | No hay criterio de éxito |
+
+Si el prompt tiene **menos de 3 componentes**, responde así:
+
+1. El componente más crítico que falta (solo uno, no todos).
+2. Una pregunta concreta para obtenerlo.
+3. Un ejemplo de cómo quedaría el prompt con ese componente añadido.
+
+**No inicies la implementación sin la respuesta.**
+
+Ejemplo de respuesta cuando falta contexto:
+> "Para implementar esto con precisión necesito saber: ¿qué stack usa el proyecto
+> (Express, FastAPI, Rails...)? Por ejemplo: *'Contexto: Express + TypeScript, ya tiene
+> autenticación JWT, falta el módulo de perfiles de usuario.'*"
+
+---
+
+## Guardia de spec activa
+
+Si existe `.sdd/estado.json` y el usuario pide algo que **no está en el alcance de la
+feature activa**, advierte antes de proceder:
+
+> "⚠️ Esto parece estar fuera de la spec activa (**{feature}**, fase: **{fase}**).
+> ¿Quieres abrir una spec nueva con `/sdd.especificar`, o confirmas que esto sí
+> forma parte de esta feature?"
+
+**No ejecutes sin confirmación explícita.** La spec activa es la fuente de verdad del
+alcance; salir de ella sin avisar introduce deuda técnica invisible.

package/configuracion-ejemplo/sdd.config.yaml

@@ -34,6 +34,16 @@ agentes:
     modelo: opus          # Recomendado: opus (decisiones difíciles de revertir)
     descripcion: "Toma decisiones de arquitectura del sistema y diseño técnico de alto nivel."
 
+  architecture-designer:
+    activo: true
+    modelo: sonnet        # Recomendado: sonnet (stack técnico para MVPs)
+    descripcion: "Recomienda el stack técnico más simple viable: frontend, backend, BD, deploy."
+
+  product-designer:
+    activo: true
+    modelo: opus          # Recomendado: opus (decisiones de producto son difíciles de revertir)
+    descripcion: "Genera el ProductDesign completo: pantallas P0/P1/P2, user flow, mvp_scope."
+
   disenador-api:
     activo: true
     modelo: sonnet        # Recomendado: sonnet (contratos estructurados)