sdd-es 2.0.0 → 2.5.0

package/commands/sdd.optimizar.md

@@ -0,0 +1,164 @@
+---
+description: Ciclo completo de optimización de tokens para la sesión actual — detecta fan-out, recomienda modelos por fase, comprime memoria si supera umbral, audita oportunidades de caché y proyecta presupuesto. Punto de entrada unificado para uso eficiente de tokens en FORGE.
+allowed-tools: Read, Bash
+---
+
+# /sdd.optimizar — Optimización de Tokens
+
+## Subcomandos disponibles
+
+| Subcomando | Qué ejecuta |
+|---|---|
+| `/sdd.optimizar` | Ciclo completo (PASOes 1-6) |
+| `/sdd.optimizar tokens` | Solo effort-router + cache-audit |
+| `/sdd.optimizar memoria` | Solo memory-compactor |
+| `/sdd.optimizar presupuesto` | Solo token-budget |
+
+---
+
+## PASO 1 — Verificar que el proyecto está inicializado
+
+```bash
+[ ! -d .sdd ] && echo "NO_INICIALIZADO" && exit 0
+[ ! -f .sdd/estado.json ] && echo "SIN_ESTADO" && exit 0
+cat .sdd/estado.json
+```
+
+Si no está inicializado: mostrar `🚫 SDD-ES no inicializado. Ejecuta: /sdd.constitucion` y terminar.
+
+---
+
+## PASO 2 — Leer ledger de consumo (observabilidad)
+
+```bash
+if [ -f .sdd/observabilidad/consumo.jsonl ]; then
+  wc -l .sdd/observabilidad/consumo.jsonl
+  cat .sdd/observabilidad/consumo.jsonl
+else
+  echo "SIN_LEDGER"
+fi
+```
+
+Si `SIN_LEDGER`: marcar PASO 2 como "Sin datos de sesión — ledger vacío" y continuar.
+
+Si hay datos: invocar la skill `observabilidad-consumo` para obtener:
+- Tabla por agente (invocaciones, bytes, archivos únicos)
+- Alertas de fan-out (>5 agentes distintos, >20 invocaciones de un agente, >500KB total)
+
+---
+
+## PASO 3 — Routing de effort (si hay fase activa o alertas de fan-out)
+
+Invocar la skill `effort-router` con la fase del `estado.json`.
+
+Si el subcomando es `/sdd.optimizar presupuesto` o `/sdd.optimizar memoria`, saltar este paso.
+
+Mostrar la tabla de modelos recomendados y el ahorro estimado.
+
+---
+
+## PASO 4 — Comprimir memoria si supera umbral
+
+```bash
+# Verificar tamaño de archivos de memoria
+for f in .sdd/memoria/agente-*.md; do
+  [ -f "$f" ] || continue
+  entradas=$(grep -c "^## " "$f" 2>/dev/null || echo 0)
+  bytes=$(wc -c < "$f" 2>/dev/null || echo 0)
+  echo "MEMORIA:$f:$entradas:$bytes"
+done
+```
+
+Si algún archivo supera **80 entradas** o **50 000 bytes**: invocar la skill `memory-compactor`.
+
+Si el subcomando es `/sdd.optimizar tokens` o `/sdd.optimizar presupuesto`, saltar este paso.
+
+Si ningún archivo supera el umbral: marcar "✅ Memoria dentro del umbral".
+
+---
+
+## PASO 5 — Auditar oportunidades de caché
+
+```bash
+# Detectar agentes instalados en el proyecto
+ls .claude/agents/ 2>/dev/null || echo "SIN_AGENTES_LOCALES"
+
+# Detectar patterns que invalidan caché silenciosamente
+grep -rn "$(date +%Y-%m-%d)\|[0-9a-f]\{8\}-[0-9a-f]\{4\}\|consumo\.jsonl" .claude/agents/ 2>/dev/null || echo "SIN_INVALIDADORES"
+```
+
+Invocar la skill `cache-audit` con los resultados.
+
+Si el subcomando es `/sdd.optimizar memoria` o `/sdd.optimizar presupuesto`, saltar este paso.
+
+---
+
+## PASO 6 — Proyectar presupuesto de fases restantes
+
+```bash
+# Tareas pendientes de la spec activa
+SPEC_ID=$(grep -o '"especificacion_activa": "[^"]*"' .sdd/estado.json 2>/dev/null | cut -d'"' -f4)
+if [ -n "$SPEC_ID" ]; then
+  cat ".sdd/especificaciones/${SPEC_ID}/.estado-tareas.json" 2>/dev/null || echo "SIN_TAREAS"
+fi
+```
+
+Invocar la skill `token-budget` con el estado, tareas pendientes y datos del ledger.
+
+Si el subcomando es `/sdd.optimizar tokens` o `/sdd.optimizar memoria`, saltar este paso.
+
+---
+
+## PASO 7 — Reporte unificado
+
+Generar el reporte final ordenando las acciones por impacto decreciente:
+
+```
+╔══════════════════════════════════════════════════════════════════╗
+║            ⚡ SDD.OPTIMIZAR — Reporte de Eficiencia             ║
+╠══════════════════════════════════════════════════════════════════╣
+║  Proyecto: {nombre}  |  Fase: {fase}  |  {fecha}                ║
+╠══════════════════════════════════════════════════════════════════╣
+║  📊 CONSUMO DE SESIÓN                                            ║
+║                                                                  ║
+║  {tabla por agente o "Sin datos de sesión"}                      ║
+║  {alertas de fan-out o "✅ Sin alertas"}                         ║
+╠══════════════════════════════════════════════════════════════════╣
+║  🎯 ROUTING DE MODELOS (fase: {fase})                            ║
+║                                                                  ║
+║  {tabla effort-router}                                           ║
+║  Ahorro estimado vs. Opus-en-todo: ~{%}%                         ║
+╠══════════════════════════════════════════════════════════════════╣
+║  🧠 MEMORIA DE AGENTES                                           ║
+║                                                                  ║
+║  {estado por agente: OK / comprimido / pendiente}                ║
+╠══════════════════════════════════════════════════════════════════╣
+║  🔄 CACHÉ                                                        ║
+║                                                                  ║
+║  {oportunidades detectadas o "✅ Sin invalidadores detectados"}  ║
+╠══════════════════════════════════════════════════════════════════╣
+║  💰 PRESUPUESTO DE FASES RESTANTES                               ║
+║                                                                  ║
+║  {tabla por fase: costo estimado y recomendación PTC}            ║
+╠══════════════════════════════════════════════════════════════════╣
+║  🚀 ACCIONES RECOMENDADAS (por impacto)                          ║
+║                                                                  ║
+║  1. {acción de mayor impacto con comando concreto}               ║
+║  2. {segunda acción}                                             ║
+║  3. {tercera acción}                                             ║
+╚══════════════════════════════════════════════════════════════════╝
+```
+
+### Lógica de priorización de acciones
+
+Ordenar las recomendaciones así:
+1. **Fan-out activo** (>5 agentes o >20 invocaciones) → acción inmediata con `effort-router`
+2. **Memoria sobre umbral** (>50KB) → `memory-compactor`
+3. **Invalidadores de caché detectados** → `cache-audit` con fix sugerido
+4. **Fases costosas por delante** → `token-budget` + sugerencia de PTC
+
+Si no hay ninguna de estas condiciones:
+```
+✅ La sesión está optimizada. No se detectan acciones de alto impacto.
+   Próximo paso sugerido según fase: {COMANDO_SDD}
+```

package/commands/sdd.planificar.md

@@ -21,6 +21,8 @@ Eres el **Orquestador del Plan**. Coordinas a los agentes especializados configu
 
 **Si el usuario escribió `/sdd.planificar revisar`**: muestra el plan actual y pide cambios específicos.
 
+**Si el usuario escribió `/sdd.planificar cambios [descripción]`**: registra feedback específico, edita el plan, y regresa al PASO 9 (aprobación explícita).
+
 ## VERIFICACIONES PRE-EJECUCIÓN
 
 ```bash
@@ -296,6 +298,68 @@ EOF
 # Actualizar entrada de INDICE.md: "plan: ✅"
 ```
 
+## PASO 8 — Presentar el plan (resumen ejecutivo)
+
+No muestres el plan técnico completo. En su lugar, presenta un **resumen ejecutivo** adaptado al perfil:
+
+**Si perfil == "guiado":**
+
+```
+✅ PLAN LISTO PARA CONSTRUIR
+
+Lo que voy a hacer:
+→ [3-5 frases en lenguaje simple de lo que se construye]
+
+Tecnología que usaré:
+→ [stack elegido, explicado sin jerga. Ej: "JavaScript (lenguaje web), SQLite (base de datos simple y gratis), Node.js (servidor web)"]
+
+Tiempo aproximado:
+→ [estimación legible: "unos 30-45 minutos"]
+
+Archivos que cambiarán:
+→ [lista simple de carpetas/conceptos afectados, no rutas técnicas]
+
+Lo que queda por hacer después:
+→ [QA, deploy, etc.]
+```
+
+**Si perfil == "experto":**
+
+Muestra el plan técnico completo (todas las 17 secciones) con decisiones, riesgos y justificaciones.
+
+## PASO 9 — Solicitar aprobación EXPLÍCITA
+
+**Gate humano:** No avances a tareas sin aprobación clara.
+
+```
+¿Está bien este plan?
+
+Responde:
+  ✅ "sí" → Avanzamos con /sdd.tareas
+  🔄 "cambio [descripción]" → Edito el plan y pregunto de nuevo
+  ❌ "rechazar" → Abortamos y revisamos la especificación
+```
+
+Si usuario responde "cambio X":
+1. Edita solo la sección relevante del plan
+2. Vuelve al PASO 8 (resumen ejecutivo)
+3. Solicita aprobación explícita nuevamente
+
+**Guardar aprobación:**
+
+```bash
+# Si aprobación == "sí"
+cat >> .sdd/estado.json << 'EOF'
+"plan_aprobado": true,
+"plan_aprobacion_timestamp": "$(date -u +%Y-%m-%dT%H:%M:%SZ)",
+"plan_aprobacion_usuario": "usuario",
+EOF
+
+# Mensaje de confirmación
+echo "✅ Plan aprobado. Siguiente: /sdd.tareas"
+echo "💾 Tu aprobación se guardó automáticamente."
+```
+
 ## PASO 8 — Pedir aprobación del plan
 
 Si `comportamiento.requerir_aprobacion_plan: true` en config:

package/commands/sdd.verificar.md

@@ -237,3 +237,13 @@ ACCIONES REQUERIDAS:
 Vuelve a:
    /sdd.implementar    — completar tareas pendientes
 ```
+
+## PASO 13 — Output styles (adaptar el PASO 12 según modo)
+
+Si el argumento contiene `pm`, `arq` o `dev`, adapta el reporte final:
+
+**Modo `pm`:** Muestra solo el veredicto, el % de cobertura y los bloqueos en lenguaje de negocio. Omite tablas de CA y rutas de archivo.
+
+**Modo `arq`:** Enfatiza el cumplimiento de constitución, los ADRs afectados y los requisitos no funcionales. Incluye la tabla de CAs con archivos.
+
+**Modo `dev`:** El reporte completo del PASO 10 con todas las tablas y rutas (comportamiento actual).

package/craft/accessibility-baseline.md

@@ -0,0 +1,216 @@
+# Accessibility Baseline — FORGE Craft
+
+Adoptado de open-design (nexu-io). Referencia para agentes de diseño.
+
+---
+
+## Principio fundamental
+
+**Accesibilidad no es una feature extra — es la calidad mínima.**
+
+Un wireframe inaccesible no es un MVP funcional. Estas reglas se aplican a todos los artefactos HTML generados por FORGE, sin excepción.
+
+---
+
+## Checklist de accesibilidad mínima (WCAG AA)
+
+### Estructura semántica
+
+- [ ] `<html lang="es">` — idioma declarado
+- [ ] Un solo `<h1>` por página — el título principal
+- [ ] Jerarquía de headings sin saltos: h1 → h2 → h3 (no saltar de h1 a h3)
+- [ ] `<main>`, `<header>`, `<nav>`, `<footer>` — landmarks semánticos
+- [ ] `<button>` para acciones, `<a>` para navegación — nunca `<div onclick>`
+- [ ] Formularios con `<label>` asociado a cada `<input>` (via `for` + `id`)
+
+### Contraste de color
+
+- [ ] Texto normal (< 18px no bold): ratio ≥ 4.5:1
+- [ ] Texto grande (≥ 18px o ≥ 14px bold): ratio ≥ 3:1
+- [ ] Iconos y bordes de UI: ratio ≥ 3:1
+- [ ] Texto desactivado (disabled): puede tener ratio menor — es intencional
+
+### Teclado
+
+- [ ] Todos los elementos interactivos son alcanzables con Tab
+- [ ] El foco visible es obvio (no eliminar `outline: none` sin reemplazarlo)
+- [ ] Los dropdowns y modales son navegables con teclado (Enter/Escape/Flechas)
+- [ ] El orden de Tab sigue el flujo visual de izquierda a derecha, arriba a abajo
+
+### Imágenes y medios
+
+- [ ] `<img alt="descripción">` — siempre, aunque sea vacío (`alt=""`) para imágenes decorativas
+- [ ] Iconos SVG con `aria-hidden="true"` si son decorativos, o `aria-label` si comunican algo
+- [ ] No usar solo color para comunicar estado (agregar texto o icono también)
+
+### Formularios
+
+- [ ] Mensajes de error junto al campo (no solo cambio de color del borde)
+- [ ] `required` en campos obligatorios + indicación visual (asterisco + leyenda)
+- [ ] `autocomplete` en campos comunes: `name`, `email`, `tel`, `current-password`
+
+---
+
+## HTML semántico en wireframes FORGE
+
+### Estructura base de cada wireframe
+
+```html
+<!DOCTYPE html>
+<html lang="es">
+<head>
+  <meta charset="UTF-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1.0">
+  <title>[Nombre del producto] — [Nombre de pantalla]</title>
+</head>
+<body>
+  <header>
+    <nav aria-label="Navegación principal">...</nav>
+  </header>
+  <main>
+    <h1>[Título principal de la pantalla]</h1>
+    <!-- contenido -->
+  </main>
+</body>
+</html>
+```
+
+### Botones correctos vs incorrectos
+
+```html
+<!-- ✅ Correcto -->
+<button type="button" class="btn-primary">Crear cita</button>
+<button type="submit" class="btn-primary">Guardar cambios</button>
+
+<!-- ❌ Incorrecto — div no es interactivo por defecto -->
+<div class="btn-primary" onclick="...">Crear cita</div>
+```
+
+### Labels de formularios
+
+```html
+<!-- ✅ Correcto — label asociado por for/id -->
+<label for="paciente-nombre">Nombre del paciente</label>
+<input id="paciente-nombre" type="text" autocomplete="name" required>
+
+<!-- ✅ Correcto — label envolvente -->
+<label>
+  Nombre del paciente
+  <input type="text" autocomplete="name" required>
+</label>
+
+<!-- ❌ Incorrecto — placeholder no reemplaza el label -->
+<input type="text" placeholder="Nombre del paciente">
+```
+
+### Foco visible
+
+```css
+/* ✅ Foco visible con el color de acento */
+:focus-visible {
+  outline: 2px solid var(--accent);
+  outline-offset: 2px;
+  border-radius: 2px;
+}
+
+/* ❌ Nunca eliminar el foco sin reemplazarlo */
+* { outline: none; }
+```
+
+### Iconos SVG
+
+```html
+<!-- ✅ Icono decorativo (acompañado de texto) -->
+<button>
+  <svg aria-hidden="true" focusable="false">...</svg>
+  Crear cita
+</button>
+
+<!-- ✅ Icono solo (sin texto) -->
+<button aria-label="Cerrar menú">
+  <svg aria-hidden="true" focusable="false">...</svg>
+</button>
+
+<!-- ❌ Icono sin descripción -->
+<button>
+  <svg>...</svg>
+</button>
+```
+
+---
+
+## Estado de elementos interactivos
+
+Cada elemento interactivo debe tener estilos para 4 estados:
+
+| Estado | CSS | Cuándo |
+|--------|-----|--------|
+| Normal | (base) | Sin interacción |
+| Hover | `:hover` | Ratón encima (desktop) |
+| Focus | `:focus-visible` | Navegación por teclado |
+| Disabled | `[disabled]`, `aria-disabled="true"` | No disponible |
+| Active | `:active` | Click/tap en progreso |
+
+```css
+.btn-primary { background: var(--accent); color: var(--text-inverse); }
+.btn-primary:hover { background: var(--accent-hover); }
+.btn-primary:focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; }
+.btn-primary:disabled { opacity: 0.45; cursor: not-allowed; }
+.btn-primary:active { transform: translateY(1px); }
+```
+
+---
+
+## ARIA mínimo necesario
+
+No sobrecargar con ARIA. La regla: **si el HTML semántico ya lo comunica, no añadir ARIA**.
+
+```html
+<!-- Necesario: nav con múltiples navs en la página -->
+<nav aria-label="Navegación principal">...</nav>
+<nav aria-label="Breadcrumb">...</nav>
+
+<!-- Necesario: estado de un componente dinámico -->
+<button aria-expanded="false" aria-controls="menu-id">Menú</button>
+<div id="menu-id" hidden>...</div>
+
+<!-- Necesario: live regions para notificaciones -->
+<div role="status" aria-live="polite" id="notifications"></div>
+
+<!-- No necesario: botón ya tiene rol button -->
+<button role="button">No necesario</button>
+```
+
+---
+
+## Responsive mínimo
+
+```css
+/* Viewport meta — siempre */
+<meta name="viewport" content="width=device-width, initial-scale=1.0">
+
+/* Tamaño de tap target mínimo — 44x44px */
+button, a, input[type="checkbox"], input[type="radio"] {
+  min-height: 44px;
+  min-width: 44px;
+}
+
+/* Texto legible en mobile */
+body { font-size: 16px; } /* evita zoom automático en iOS */
+input, textarea, select { font-size: 16px; } /* evita zoom en focus en iOS */
+```
+
+---
+
+## Referencia rápida para agentes
+
+Antes de cerrar el `<artifact>`, verificar:
+
+1. `<html lang="es">` presente
+2. Un solo `<h1>` en la página
+3. Todos los `<input>` tienen `<label>` asociado
+4. Todos los `<button>` tienen texto o `aria-label`
+5. Imágenes tienen `alt`
+6. `:focus-visible` definido con `outline` visible
+7. No usar `<div>` para elementos clicables — usar `<button>` o `<a>`
+8. Contraste de texto verificado mentalmente (colores del DESIGN.md tienen ratio ≥ 4.5:1)

package/craft/anti-ai-slop.md

@@ -0,0 +1,158 @@
+# Anti-AI-Slop Rules
+
+> Reglas cardinales para evitar patrones visuales genéricos de IA. Adoptado de open-design (nexu-io).
+> **P0 = bloqueante**: si el artefacto viola estas reglas, la crítica automática lo rechaza (score < 4).
+
+---
+
+## Las 7 Reglas Cardinales
+
+### Regla 1 — Prohibido el índigo default de Tailwind
+
+❌ **Nunca usar**: `#6366F1`, `#4F46E5`, `#7C3AED`, `#8B5CF6`, `#6D28D9`
+
+Estos colores son la firma del "AI-generated UI" sin dirección. Si el DESIGN.md activo no especifica morado/índigo, no lo uses. Si lo especifica, usa el valor exacto del DESIGN.md.
+
+✅ **En su lugar**: el color de acento definido en el DESIGN.md activo.
+
+---
+
+### Regla 2 — Prohibido el gradiente "trust" de 2 paradas
+
+❌ **Nunca usar en heroes o CTAs**:
+- `linear-gradient(135deg, #6366F1, #2563EB)` (purple → blue)
+- `linear-gradient(135deg, #667EEA, #764BA2)` (lavender → purple)
+- `linear-gradient(90deg, #00B4D8, #90E0EF)` (blue → cyan)
+- Cualquier gradiente de 2 colores en una dirección diagonal sobre el hero
+
+✅ **En su lugar**: fondo sólido del color base del DESIGN.md. Si el diseño requiere gradiente, que tenga intención editorial (ej: warm-editorial puede usar un gradiente de tonos tierra muy sutil).
+
+---
+
+### Regla 3 — Prohibidos los emojis como iconos de features
+
+❌ **Nunca hacer esto**:
+```html
+<div class="feature">
+  <span class="icon">⚡</span>
+  <h3>Rápido y confiable</h3>
+</div>
+```
+
+✅ **En su lugar**: SVG monoline simple, o ningún icono. Si no hay icono SVG disponible, usar texto puro o un elemento decorativo del DESIGN.md.
+
+---
+
+### Regla 4 — Respetar la fuente del DESIGN.md activo
+
+❌ **Nunca mezclar**: si el DESIGN.md dice `font-display: 'Playfair Display'`, no usar sans-serif para headings.
+
+✅ **Regla**: las fuentes del artefacto deben coincidir exactamente con las del DESIGN.md activo. No "mejorar" con fuentes propias.
+
+Si el DESIGN.md no especifica una fuente (raro), usar `system-ui, sans-serif`.
+
+---
+
+### Regla 5 — Prohibido el patrón "AI dashboard tile"
+
+❌ **Nunca hacer esto**:
+```html
+<div style="border-left: 4px solid #6366F1; border-radius: 8px; background: #F9FAFB;">
+  <span>10x más rápido</span>
+</div>
+```
+
+Este patrón — card redondeada con borde izquierdo de color + métrica — es el sello del UI genérico de IA.
+
+✅ **En su lugar**: el estilo de card definido en el DESIGN.md activo. Las métricas deben ser reales o no aparecer.
+
+---
+
+### Regla 6 — Prohibidas las métricas inventadas
+
+❌ **Nunca usar**:
+- "10x más rápido"
+- "99.9% de uptime"
+- "2 millones de usuarios satisfechos"
+- "50% de ahorro de tiempo garantizado"
+
+...a menos que el usuario haya provisto esos números en el IR o el contexto.
+
+✅ **En su lugar**: si se necesita una métrica de ejemplo, usar un placeholder explícito como `[X]% de mejora` o omitirla.
+
+---
+
+### Regla 7 — Prohibido el copy de relleno
+
+❌ **Nunca usar**:
+- Lorem ipsum o variantes
+- "Feature One", "Feature Two", "Feature Three"
+- "Descripción de la feature aquí"
+- "Título del beneficio"
+- "Texto placeholder"
+
+✅ **En su lugar**: copy derivado del IR del proyecto. Si no hay copy real, usar `[Nombre de la feature]` con corchetes para marcar que es un placeholder explícito.
+
+---
+
+## Patrones Adicionales a Evitar (P1 — no bloqueante pero penaliza el score)
+
+### P1-A: Hero con imagen de stock genérica
+- Personas sonriendo frente a pantallas
+- Oficinas modernas con plantas
+- Manos sobre teclados
+
+✅ En su lugar: sin imagen, color de fondo sólido del DESIGN.md, o SVG ilustrativo relacionado al producto.
+
+### P1-B: Navbar con logo "Empresa" y menú genérico
+```html
+<!-- Evitar -->
+<nav>
+  <div class="logo">Empresa</div>
+  <a href="#">Inicio</a>
+  <a href="#">Características</a>
+  <a href="#">Precios</a>
+  <a href="#">Blog</a>
+  <button>Empieza Gratis</button>
+</nav>
+```
+✅ El nombre de la navbar debe venir del `product.name` del IR.
+
+### P1-C: Footer con 4 columnas de links vacíos
+El footer de "AI-slop" tiene 4 columnas (Producto, Empresa, Recursos, Legal) con links que no llevan a ningún lado.
+✅ Si el MVP no tiene esas secciones, el footer es mínimo: copyright + link principal.
+
+### P1-D: Sección "Como funciona" con 3 pasos numerados + iconos genéricos
+El patrón de "1. Regístrate → 2. Configura → 3. Disfruta" con íconos de rocket/check/star es omnipresente.
+✅ Si el producto tiene un flujo real, muéstralo. Si no, omite esta sección.
+
+### P1-E: Testimonials inventados
+```html
+<!-- Evitar -->
+<blockquote>
+  "Este producto cambió mi vida."
+  — María García, CEO de Empresa S.A.
+</blockquote>
+```
+✅ Si no hay testimonials reales del IR, omitir la sección completamente.
+
+---
+
+## Cómo aplicar estas reglas
+
+Los agentes **product-designer** y **wireframe-mvp** deben:
+
+1. Antes de generar cualquier UI, leer este archivo
+2. Generar el artefacto
+3. Hacer auto-checklist: ¿viola alguna de las 7 reglas cardinales?
+4. Si viola alguna P0: corregir antes de entregar
+5. Si viola P1: mencionar en el output y decidir si corregir
+
+La skill **critica-diseno** evalúa explícitamente "Ausencia de AI-slop" como una de sus 5 dimensiones.
+
+---
+
+## Origen
+
+Estas reglas están adaptadas de `open-design` (nexu-io/open-design), proyecto Apache-2.0.
+La lista de colores prohibidos y los patrones fueron identificados por análisis de outputs de modelos de lenguaje entre 2023–2025.