sdd-es 2.0.0 → 2.5.0

package/docs/SEGURIDAD-PARA-NOTECNICOS.md

@@ -0,0 +1,280 @@
+# 🔐 Seguridad para No-Técnicos
+
+> SDD-ES maneja tokens de GitHub y Vercel. Esta guía te explica qué son, cómo protegerlos, y qué hacer si cometes un error.
+
+---
+
+## ¿Qué es un "token"?
+
+Un **token** es como una **contraseña especial** que funciona solo para una cosa.
+
+### Comparación
+
+```
+Contraseña normal:
+├─ Acceso a: email, redes sociales, archivos, TODO
+└─ Riesgo: si alguien la roba, controla tu cuenta
+
+Token:
+├─ Acceso a: SOLO GitHub (o SOLO Vercel)
+├─ Duración: puedes ponerle límite de tiempo
+└─ Riesgo: si alguien lo roba, SOLO puede hacer lo que le diste permiso
+```
+
+**Ejemplo real:**
+```
+Token de GitHub para SDD-ES:
+├─ ✅ PUEDE: crear repositorio, hacer commits, pushear código
+├─ ✅ PUEDE: leer público el repositorio
+└─ ❌ NO PUEDE: ver tus emails privados, cambiar contraseña, acceder a otros proyectos
+```
+
+---
+
+## ¿Por qué SDD-ES pide tokens?
+
+SDD-ES necesita tokens para:
+
+1. **GitHub:** Crear tu repositorio automáticamente (sin que escribas `git init`)
+2. **Vercel:** Publicar tu app en internet (sin que escribas `vercel deploy`)
+
+Sin tokens, tendrías que hacer todo manualmente (comandos, CLI, etc.).
+
+**Con tokens:** SDD-ES lo hace automáticamente por ti.
+
+---
+
+## 🚨 NUNCA hagas ESTO con tokens
+
+### ❌ NO 1: No compartas tu token
+
+```
+❌ MALO:
+- Enviar token por Whatsapp a un amigo
+- Pegar token en Slack o Discord
+- Guardar token en Notas o Google Docs
+- Decirle a alguien tu token
+```
+
+**¿Por qué?** Si alguien tiene tu token, puede:
+- Acceder a tu GitHub/Vercel
+- Hacer commits en tu nombre
+- Borrar repositorios
+- Cambiar configuración de apps
+
+---
+
+### ❌ NO 2: No guardes token en archivos
+
+```
+❌ MALO (SDD-ES NO hace esto):
+- No guardes token en .env
+- No lo guardes en un archivo de texto
+- No lo commitess a GitHub
+
+✅ BIEN (SDD-ES SÍ hace esto):
+- Token se usa en memoria mientras se necesita
+- Cuando termina, se borra automáticamente
+- Nunca se escribe en archivos persistentes
+```
+
+---
+
+### ❌ NO 3: No commitess archivos sensibles
+
+```
+❌ MALO:
+git add .
+git commit -m "Mi proyecto"
+[Si accidentalmente commiteas .env o credenciales]
+
+✅ BIEN:
+SDD-ES usa .gitignore para proteger:
+- .sdd/.vercel-deploy.json (metadata de deploy)
+- .env (variables de entorno)
+- Cualquier archivo con secretos
+
+[Git automáticamente ignora estos archivos]
+```
+
+---
+
+## 📋 ¿Cómo generar un token SEGURO?
+
+### Token de GitHub (para SDD-ES)
+
+**Paso 1:** Abre https://github.com/settings/tokens?type=pat
+
+**Paso 2:** Click "Generate new token" → "Fine-grained tokens"
+
+**Paso 3:** Configura permisos **MÍNIMOS**:
+```
+Repository access:
+  ✅ All repositories (SDD-ES creará uno nuevo)
+  
+Permissions:
+  ✅ Repository: READ + WRITE (crear repo, hacer commits)
+  ✅ Administration: NONE (no cambiar settings)
+  ✅ Secrets: NONE (no leer otros secrets)
+  ❌ User: NONE (no acceder emails)
+```
+
+**Paso 4:** Expiration:
+```
+⚠️ IMPORTANTE: Pon un límite de 90 días
+(No "No expiration" — riesgo si token se roba)
+```
+
+**Paso 5:** Click "Generate token", copia y **úsalo INMEDIATAMENTE**
+
+**Paso 6:** En SDD-ES, pega el token cuando pida
+
+---
+
+### Token de Vercel (para SDD-ES)
+
+**Paso 1:** Abre https://vercel.com/account/tokens
+
+**Paso 2:** Click "Create Token"
+
+**Paso 3:** Configura:
+```
+Token Name: "SDD-ES [nombre-proyecto]" (ej: SDD-ES Mi Tienda)
+Scope: Todos los equipos (o tu equipo)
+Expiration: 90 días (NO "No expiration")
+```
+
+**Paso 4:** Click "Create", copia y **úsalo INMEDIATAMENTE**
+
+---
+
+## ✅ Si generaste token correctamente
+
+```
+Después de pegar el token en SDD-ES:
+
+Sistema: "✅ Token válido"
+Sistema: "[invoca skill de GitHub/Vercel]"
+Sistema: "✅ Tu proyecto está en GitHub/Vercel"
+
+El token se BORRA de la memoria automáticamente.
+Ya NO lo necesitas más.
+```
+
+---
+
+## 🚨 Si cometiste un error (compartiste token accidentalmente)
+
+### Escenario 1: Compartiste token por Whatsapp/Slack
+
+**¿Qué hacer?**
+
+1. **IMMEDIATO — Revoca el token:**
+   - GitHub: https://github.com/settings/tokens
+   - Busca el token
+   - Click "Delete"
+
+2. **Genera uno NUEVO:**
+   - Sigue los pasos de arriba
+   - USA el nuevo en SDD-ES
+
+3. **Chequea que no pasó nada malo:**
+   - GitHub: Mira el repositorio, ¿alguien cambió código?
+   - Vercel: ¿Apps raras desplegadas?
+
+4. **Si sospechas actividad extraña:**
+   - Cambia contraseña de GitHub/Vercel
+   - Activa 2FA (autenticación de dos factores)
+
+---
+
+### Escenario 2: Accidentalmente commitease token a GitHub
+
+```
+(SDD-ES NO hace esto, pero si ocurre por error)
+
+❌ MALO: El token está en GitHub público
+         Cualquiera puede verlo en git log
+
+✅ RECUPERACIÓN:
+1. Revoca el token INMEDIATAMENTE (arriba)
+2. Borra el archivo de histórico de git:
+   git filter-branch --tree-filter 'rm -f .env' HEAD
+3. Force push: git push --force
+4. Avisa a GitHub (https://github.com/security/advisories)
+```
+
+---
+
+## 🔒 SDD-ES protege tu seguridad
+
+### Cómo SDD-ES cuida los tokens
+
+```
+✅ TOKENS EN VARIABLES DE ENTORNO (memoria)
+   └─ No se escriben en archivos
+   └─ Se borran cuando termina el script
+
+✅ VALIDACIÓN INMEDIATA
+   └─ Si token es inválido, sale rápido
+   └─ No continúa si hay problema
+
+✅ .gitignore AUTOMÁTICO
+   └─ Protege archivos sensibles
+   └─ Aunque hagas "git add .", no se commitean
+
+✅ SIN GUARDAR CREDENTIALS
+   └─ sdd.config.yaml SOLO guarda URLs, no tokens
+   └─ Tokens se usan ONCE y desaparecen
+```
+
+---
+
+## 📋 Checklist de Seguridad
+
+Antes de usar SDD-ES, asegúrate de:
+
+```
+[ ] Generé un token NUEVO (no uno viejo)
+[ ] Token tiene expiración 90 días (no "No expiration")
+[ ] Token tiene permisos MÍNIMOS (solo repo, no everything)
+[ ] Guardé el token en un lugar SEGURO temporalmente (1Password, Bitwarden)
+[ ] Voy a pegar el token INMEDIATAMENTE en SDD-ES
+[ ] NO voy a guardar el token en archivos
+[ ] NO voy a compartir el token en mensajes
+```
+
+---
+
+## 🆘 Emergencia: Creo que mi token fue robado
+
+```
+ACCIÓN: REVOCA INMEDIATAMENTE
+
+1. GitHub: https://github.com/settings/tokens
+   → Busca token → Click "Delete"
+
+2. Vercel: https://vercel.com/account/tokens
+   → Click "Delete"
+
+3. Genera NUEVOS tokens
+
+4. IMPORTANTE: Cambia contraseña GitHub/Vercel
+   (por si alguien también robó contraseña)
+```
+
+---
+
+## 📚 Más información
+
+- **GitHub Security:** https://docs.github.com/en/authentication/keeping-your-account-and-data-secure
+- **Vercel Security:** https://vercel.com/docs/security
+- **OWASP (Seguridad general):** https://owasp.org/
+
+---
+
+## 💬 ¿Preguntas?
+
+Si no estás seguro sobre algo de seguridad, **mejor pregunta que arreglar después.**
+
+Abre un issue en GitHub: https://github.com/carlos060798/sdd-lite/issues

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sdd-es",
-  "version": "2.0.0",
+  "version": "2.5.0",
   "description": "Spec-Driven Development en español para Claude Code. Fábrica de software: de la idea al despliegue, agnóstica al stack. Instalador multiplataforma.",
   "type": "module",
   "bin": {
@@ -20,6 +20,8 @@
     "commands/",
     "agents/",
     "skills/",
+    "craft/",
+    "design-systems/",
     "plantillas/",
     "presets/",
     "claude-hooks/",
@@ -42,9 +44,9 @@
     "plugin"
   ],
   "license": "MIT",
-  "homepage": "https://github.com/carlos060798/sdd-lite",
+  "homepage": "https://github.com/carlos060798/FORGE",
   "repository": {
     "type": "git",
-    "url": "https://github.com/carlos060798/sdd-lite.git"
+    "url": "https://github.com/carlos060798/FORGE.git"
   }
 }

package/skills/cache-audit/SKILL.md

@@ -0,0 +1,163 @@
+---
+description: Audita los archivos de agentes (.claude/agents/*.md) para detectar bloques estables susceptibles de cache_control y los 3 patrones que invalidan caché silenciosamente (timestamps dinámicos, UUIDs, contenido JSONL embebido). Produce una lista de oportunidades de caché ordenadas por impacto.
+model: claude-haiku-4-5-20251001
+allowed-tools: Read, Bash
+---
+
+# Skill: Cache Audit
+
+## Propósito
+
+El prompt caching de Claude reduce el costo de tokens de entrada hasta un 90% para bloques de contexto que no cambian entre invocaciones. Sin embargo, tres patrones comunes invalidan el caché silenciosamente — el modelo re-paga el precio completo sin que nadie se dé cuenta.
+
+Esta skill detecta esos patrones en los archivos de agentes del proyecto activo y produce recomendaciones concretas.
+
+---
+
+## Lo que lees
+
+```bash
+# Agentes instalados en el proyecto (instalados localmente, no en el plugin)
+ls .claude/agents/ 2>/dev/null || echo "SIN_AGENTES_LOCALES"
+
+# Agentes del plugin (si existe {PLUGIN_DIR})
+ls {PLUGIN_DIR}/agents/ 2>/dev/null | head -20
+
+# Contenido de cada archivo de agente
+for f in .claude/agents/*.md {PLUGIN_DIR}/agents/*.md; do
+  [ -f "$f" ] || continue
+  echo "=== AGENTE: $f ==="
+  cat "$f"
+  echo "---"
+done
+```
+
+---
+
+## Los 3 invalidadores de caché
+
+### Invalidador 1 — Timestamps dinámicos en el system prompt
+
+Un timestamp que cambia en cada sesión rompe el caché de todo el bloque que lo contiene y todos los bloques siguientes.
+
+**Patrones a detectar:**
+```bash
+grep -n "\b[0-9]\{4\}-[0-9]\{2\}-[0-9]\{2\}\b" .claude/agents/*.md {PLUGIN_DIR}/agents/*.md 2>/dev/null
+```
+
+**Severidad:** ALTA — invalida el caché en cada nueva sesión (cada día).
+
+**Fix:** Mover el timestamp al final del prompt, en un bloque marcado como dinámico separado del bloque estable. O eliminarlo si no es necesario.
+
+---
+
+### Invalidador 2 — UUIDs / IDs únicos por sesión
+
+Hashes o IDs generados en cada invocación invalidan todo el bloque donde aparecen.
+
+**Patrones a detectar:**
+```bash
+grep -nE "[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}" \
+  .claude/agents/*.md {PLUGIN_DIR}/agents/*.md 2>/dev/null
+```
+
+**Severidad:** ALTA — invalida en cada invocación.
+
+**Fix:** Sacar el ID del bloque estable. Si el agente necesita el ID, inyectarlo como variable de entorno o como argumento de la invocación, no como parte del system prompt fijo.
+
+---
+
+### Invalidador 3 — Contenido JSONL o ledger embebido directamente
+
+Si el system prompt incluye el contenido del `consumo.jsonl` u otro archivo que cambia frecuentemente, el bloque se invalida en cada escritura del hook.
+
+**Patrones a detectar:**
+```bash
+grep -n "consumo\.jsonl\|\.jsonl\|\"ts\":\|\"agente\":\|\"bytes\":" \
+  .claude/agents/*.md {PLUGIN_DIR}/agents/*.md 2>/dev/null
+```
+
+**Severidad:** MEDIA — invalida con cada invocación de agente.
+
+**Fix:** En lugar de embeber el JSONL en el prompt, hacer que el agente lo lea con la tool `Read` cuando necesite esa información.
+
+---
+
+## Análisis de ratio estable/dinámico
+
+Para cada archivo de agente, calcular:
+
+```bash
+node -e "
+const fs = require('fs');
+const archivos = process.argv.slice(1);
+
+for (const f of archivos) {
+  if (!fs.existsSync(f)) continue;
+  const contenido = fs.readFileSync(f, 'utf8');
+  const lineas = contenido.split('\n');
+  const total = lineas.length;
+  
+  // Líneas sospechosas de ser dinámicas
+  const dinamicas = lineas.filter(l =>
+    /\d{4}-\d{2}-\d{2}/.test(l) ||           // fechas
+    /[0-9a-f]{8}-[0-9a-f]{4}/.test(l) ||     // UUIDs
+    /\"ts\":/.test(l) ||                       // JSONL
+    /consumo\.jsonl/.test(l)
+  ).length;
+  
+  const pct_estatico = Math.round((1 - dinamicas/total) * 100);
+  console.log(f + ': ' + pct_estatico + '% estático (' + dinamicas + '/' + total + ' líneas dinámicas)');
+}
+" .claude/agents/*.md {PLUGIN_DIR}/agents/*.md 2>/dev/null || echo "node no disponible"
+```
+
+---
+
+## Output que produces
+
+```
+╔══════════════════════════════════════════════════════════════════╗
+║           🔄 CACHE AUDIT — Oportunidades de Caché               ║
+╠══════════════════════════════════════════════════════════════════╣
+║  AGENTE              | % ESTÁTICO | INVALIDADORES | SEVERIDAD   ║
+║  ────────────────────┼────────────┼───────────────┼──────────── ║
+║  arquitecto          | 98%        | Ninguno       | ✅ OK       ║
+║  desarrollador-back  | 95%        | Ninguno       | ✅ OK       ║
+║  {agente con prob}   | 72%        | Timestamp L34 | ⚠️  MEDIO  ║
+║  {agente con prob}   | 45%        | UUID L12, L67 | 🔴 ALTO    ║
+╠══════════════════════════════════════════════════════════════════╣
+║  HALLAZGOS CONCRETOS                                             ║
+║                                                                  ║
+║  🔴 {agente}.md:12 — UUID detectado en bloque estable           ║
+║     Fix: mover a argumento de invocación o variable de entorno   ║
+║                                                                  ║
+║  ⚠️  {agente}.md:34 — Timestamp 2026-06-14 en system prompt     ║
+║     Fix: mover al final del prompt, separar en bloque dinámico   ║
+╠══════════════════════════════════════════════════════════════════╣
+║  💰 AHORRO POTENCIAL                                             ║
+║                                                                  ║
+║  Los agentes con >90% contenido estático son candidatos          ║
+║  para cache_control: la primera invocación escribe el caché      ║
+║  y las siguientes pagan ~10% del costo original de input.        ║
+║                                                                  ║
+║  Para activar: separar el system prompt en bloque estable        ║
+║  (primero) + bloque dinámico (al final). El modelo detecta       ║
+║  automáticamente el prefijo estable y lo cachea.                 ║
+╚══════════════════════════════════════════════════════════════════╝
+```
+
+---
+
+## Cuándo usar esta skill
+
+- Antes de `/sdd.implementar` en proyectos con >5 tareas (sesiones largas = más valor del caché)
+- Cuando `/sdd.estado consumo` reporta >1MB de bytes escritos (la sesión es larga)
+- Cuando un agente tarda más de lo esperado en responder (el caché podría no estar activo)
+- Desde `/sdd.optimizar tokens` (se ejecuta automáticamente como parte del ciclo)
+
+## Notas
+
+- El prompt caching es automático en Claude Code — no requiere cambios en el código del hook.
+- Lo que sí requiere intervención manual son los invalidadores: un UUID en línea 1 del prompt hace que el modelo no pueda cachear nada de lo que sigue.
+- Esta skill audita; no modifica archivos. Los fixes los aplica el usuario (o un agente dedicado con permiso de Edit).

package/skills/critica-diseno/SKILL.md

@@ -0,0 +1,193 @@
+---
+description: Auto-crítica del wireframe generado. Evalúa en 5 dimensiones con score 1-5. Si score < 4 y iteraciones < 3, refina el artefacto y repite. Adaptado de critique-theater de open-design.
+model: claude-sonnet-4-6
+allowed-tools: Read, Write
+---
+
+# Skill: Crítica de Diseño
+
+## Propósito
+
+Después de generar el wireframe, esta skill lo evalúa en **5 dimensiones** y da un **score 1–5**. Si el score es bajo, refina el wireframe automáticamente y lo re-evalúa. El ciclo se repite hasta score ≥ 4 o 3 iteraciones.
+
+Inspirado en `critique-theater` de open-design (nexu-io).
+
+---
+
+## Lo que lees antes de empezar
+
+```bash
+# El wireframe generado
+cat .sdd/diseño/wireframe-pantalla-principal.html
+
+# El DESIGN.md activo (para verificar fidelidad)
+cat "$(cat .sdd/estado.json | node -e "
+  const d = JSON.parse(require('fs').readFileSync('/dev/stdin','utf8'));
+  console.log(d.design_system_path || '{PLUGIN_DIR}/design-systems/neutral-modern/DESIGN.md');
+")"
+
+# Las reglas anti-slop
+cat "{PLUGIN_DIR}/craft/anti-ai-slop.md"
+```
+
+---
+
+## Las 5 Dimensiones de Evaluación
+
+### Dimensión 1: Jerarquía Visual (1–5)
+¿El ojo del usuario sabe a dónde ir primero?
+
+| Score | Criterio |
+|-------|----------|
+| 5 | Jerarquía clara: un elemento domina, luego soporte, luego detalle |
+| 4 | Jerarquía buena con algún elemento secundario algo fuerte |
+| 3 | Dos elementos compiten por atención principal |
+| 2 | Múltiples elementos con el mismo peso visual |
+| 1 | Sin jerarquía — todo tiene el mismo peso |
+
+### Dimensión 2: Fidelidad al DESIGN.md (1–5)
+¿El wireframe usa los tokens del sistema activo?
+
+| Score | Criterio |
+|-------|----------|
+| 5 | Todos los colores, fuentes y componentes corresponden exactamente al DESIGN.md |
+| 4 | Pequeñas desviaciones (un color ligeramente diferente, borde-radius incorrecto) |
+| 3 | Usa el sistema general pero con elementos fuera del DESIGN.md |
+| 2 | Sistema visual mixto — algunos tokens del DESIGN.md, otros no |
+| 1 | Ignora el DESIGN.md activo completamente |
+
+### Dimensión 3: Funcionalidad del MVP (1–5)
+¿La pantalla permite hacer la acción principal del MVP?
+
+| Score | Criterio |
+|-------|----------|
+| 5 | El usuario puede realizar la acción principal en ≤3 clicks desde esta pantalla |
+| 4 | La acción principal está presente, quizás con un paso de más |
+| 3 | La acción existe pero no es el elemento más prominente |
+| 2 | La acción existe pero está perdida entre otros elementos |
+| 1 | La pantalla no permite realizar la acción principal |
+
+### Dimensión 4: Ausencia de AI-Slop (1–5)
+¿El wireframe evita los patrones genéricos de IA?
+
+| Score | Criterio |
+|-------|----------|
+| 5 | Cero violaciones de las 7 reglas cardinales + cero patrones P1 |
+| 4 | Sin violaciones P0, máximo 1 patrón P1 |
+| 3 | Sin violaciones P0, 2–3 patrones P1 |
+| 2 | 1 violación P0 |
+| 1 | 2+ violaciones P0 |
+
+### Dimensión 5: Innovación Contextual (1–5)
+¿El diseño tiene algo específico de este producto, o es completamente genérico?
+
+| Score | Criterio |
+|-------|----------|
+| 5 | El copy, los datos de ejemplo y los elementos reflejan exactamente el dominio del producto |
+| 4 | Mayoría de elementos son específicos del dominio, alguno genérico |
+| 3 | Mezcla: algunos elementos específicos, otros genéricos |
+| 2 | Solo el nombre del producto es específico — el resto es genérico |
+| 1 | El wireframe podría ser de cualquier producto |
+
+---
+
+## Flujo de Crítica
+
+### Iteración 1
+
+1. Lee el wireframe
+2. Evalúa las 5 dimensiones
+3. Calcula el score promedio: `(D1 + D2 + D3 + D4 + D5) / 5`
+4. Muestra el resultado:
+
+```
+CRÍTICA DEL DISEÑO (iteración 1/3)
+─────────────────────────────────
+Jerarquía visual:      [score]/5  [comentario breve]
+Fidelidad al sistema:  [score]/5  [comentario breve]
+Funcionalidad MVP:     [score]/5  [comentario breve]
+Ausencia de AI-slop:   [score]/5  [comentario breve]
+Innovación contextual: [score]/5  [comentario breve]
+─────────────────────────────────
+SCORE TOTAL: [promedio]/5
+
+[Si score ≥ 4]: ✅ El diseño está listo.
+[Si score < 4]: 🔄 Refinando... (iteración 1 → 2)
+```
+
+### Si score < 4 y iteraciones < 3
+
+Genera una versión mejorada del wireframe corrigiendo los problemas detectados:
+
+```
+Mejoras aplicadas:
+  → [problema D1 → solución aplicada]
+  → [problema D4 → corrección aplicada]
+```
+
+Luego re-evalúa. Repite el proceso.
+
+### Si score ≥ 4 (en cualquier iteración)
+
+```
+✅ DISEÑO APROBADO (score [X]/5, iteración [N]/3)
+
+El wireframe de [screen.name] está listo.
+```
+
+### Si iteración 3 y aún < 4
+
+```
+⚠️ Score final: [X]/5 (después de 3 iteraciones)
+
+El diseño es funcional pero tiene áreas de mejora.
+Puedes continuar o decirme qué cambiar manualmente.
+```
+
+Continúa de todos modos — no bloquea el pipeline.
+
+---
+
+## Output del wireframe refinado
+
+Si se hicieron mejoras, el wireframe refinado **reemplaza** el anterior usando la tool `Write`:
+- Ruta: `.sdd/diseño/wireframe-pantalla-principal.html` (sobreescribe el anterior)
+- Contenido: HTML completo refinado
+
+---
+
+## Guardar resultado de la crítica
+
+```bash
+cat > .sdd/diseño/critica-wireframe.md << 'CRITICA'
+# Crítica del Wireframe — [product.name]
+
+**Fecha**: [timestamp]
+**Iteraciones**: [N]
+**Score final**: [X]/5
+
+## Dimensiones
+
+| Dimensión | Score | Comentario |
+|-----------|-------|-----------|
+| Jerarquía visual | [N]/5 | [texto] |
+| Fidelidad DESIGN.md | [N]/5 | [texto] |
+| Funcionalidad MVP | [N]/5 | [texto] |
+| Ausencia AI-slop | [N]/5 | [texto] |
+| Innovación contextual | [N]/5 | [texto] |
+
+## Mejoras aplicadas
+
+[lista de mejoras si hubo iteraciones]
+CRITICA
+```
+
+---
+
+## Notas
+
+- **No hay evaluación de colores "bonitos"** — solo fidelidad al DESIGN.md
+- **No hay evaluación de creatividad** — solo funcionalidad y ausencia de slop
+- La dimensión "Innovación Contextual" evalúa especificidad del dominio, no creatividad artística
+- El score mínimo para continuar sin comentario es 4/5
+- Si el usuario quiere saltarse la crítica: `/sdd.diseñar --sin-critica` (disponible en el comando)