sdd-es 2.0.0 → 2.6.0

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:
@@ -237,3 +308,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/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)

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.