don-cheli-sdd 1.13.0

package/habilidades/reflexion/HABILIDAD.md

@@ -0,0 +1,37 @@
+---
+nombre: Reflexión
+descripcion: "Auto-evaluar la calidad del trabajo antes de entregar. Mejora calidad en +8-21%"
+version: 1.0.0
+autor: Don Cheli
+tags: [calidad, reflexión, auto-evaluación, revisión]
+activacion: "reflexionar", "auto-evaluar", "revisar mi trabajo"
+---
+
+# Habilidad: Reflexión
+
+**Versión:** 1.0.0
+**Categoría:** Calidad
+
+## Propósito
+
+Mejorar calidad de output (+8-21%) mediante auto-reflexión estructurada.
+
+## Las 4 Preguntas
+
+1. ¿Qué funcionó bien?
+2. ¿Qué se puede mejorar?
+3. ¿Qué aprendí?
+4. ¿Qué haría diferente?
+
+## Modo Adversarial
+
+Cuando se activa el modo adversarial (automáticamente en `/especdev:revisar` o manualmente con `--adversarial`):
+
+1. **Obligación de hallazgo:** DEBE encontrar al menos 1 problema concreto. "Todo bien" no es aceptable.
+2. **Re-examinación forzada:** Si la primera pasada no encuentra nada, ejecutar una segunda con estos ángulos:
+   - ¿Hay race conditions en operaciones concurrentes?
+   - ¿Hay N+1 queries en loops con DB?
+   - ¿Hay edge cases no cubiertos por tests?
+   - ¿Hay datos sensibles en logs o responses?
+   - ¿Hay naming inconsistente con el resto del codebase?
+3. **Justificación obligatoria:** Si genuinamente no hay problemas, documentar por qué con evidencia específica (no genérica).

package/habilidades/rigor-progresivo/HABILIDAD.md

@@ -0,0 +1,109 @@
+---
+nombre: Rigor Progresivo
+descripcion: "Ajustar automáticamente el nivel de rigor (tests, docs, review) según la complejidad de la tarea"
+version: 1.0.0
+autor: Don Cheli
+tags: [specs, rigor, calidad, especificación]
+activacion: "nivel de rigor", "cuánto testing", "qué tan estricto"
+---
+
+# Habilidad: Rigor Progresivo en Specs
+
+**Versión:** 1.0.0
+**Categoría:** Especificación
+**Tipo:** Flexible
+
+> Adaptado de OpenSpec — "Keep It Lightweight: Progressive Rigor"
+
+## Cómo Mejora el Framework
+
+No todos los cambios necesitan el mismo nivel de detalle en la spec. Un bugfix de una línea no necesita 3 páginas de especificación. Este concepto evita burocracia innecesaria.
+
+## Dos Niveles de Rigor
+
+### 📝 Spec Ligera (Default — la mayoría de cambios)
+
+```markdown
+# Spec: Corregir timeout en login
+
+## Propósito
+El login falla con timeout después de 30 segundos en conexiones lentas.
+
+## Requisito
+El sistema DEBE esperar hasta 60 segundos antes de timeout.
+
+## Aceptación
+- Login funciona en conexión de 3G
+- No hay timeout antes de 60 segundos
+- Se muestra spinner durante la espera
+```
+
+**Usar para:** Bugfixes, features pequeñas, refactors internos, mejoras de UI.
+
+### 📋 Spec Completa (Para cambios de alto riesgo)
+
+```markdown
+# Spec: Migrar sistema de pagos a Stripe
+
+## Propósito
+Reemplazar el procesador de pagos actual por Stripe para soportar
+pagos internacionales y suscripciones.
+
+## Requisitos
+
+### Requisito: Procesamiento de Pagos
+El sistema DEBE procesar pagos via Stripe API v3.
+
+#### Escenario: Pago exitoso
+- DADO un usuario con tarjeta válida
+- CUANDO confirma el pago de $50 USD
+- ENTONCES se crea un PaymentIntent en Stripe
+- Y el pedido cambia a estado "pagado"
+- Y se envía receipt por email
+
+#### Escenario: Tarjeta rechazada
+- DADO un usuario con tarjeta expirada
+- CUANDO intenta pagar
+- ENTONCES recibe error "Tarjeta rechazada"
+- Y el pedido permanece en "pendiente"
+- Y NO se cobra nada
+
+### Requisito: Suscripciones
+El sistema DEBE soportar planes mensuales y anuales.
+
+(... más requisitos detallados ...)
+
+## No-Objetivos
+- NO migrar pagos históricos
+- NO soportar crypto en esta fase
+
+## Restricciones
+- PCI-DSS compliance obligatorio
+- No almacenar datos de tarjeta en BD propia
+```
+
+**Usar para:** Cambios cross-equipo, APIs contractuales, migraciones, seguridad/privacidad, cambios donde la ambigüedad causa retrabajo costoso.
+
+## Palabras Clave RFC 2119
+
+En specs, usar keywords formales para comunicar intensidad:
+
+| Keyword | Significado | Ejemplo |
+|---------|------------|---------|
+| **DEBE** (MUST/SHALL) | Requisito absoluto | "El sistema DEBE encriptar passwords" |
+| **DEBERÍA** (SHOULD) | Recomendado, excepciones posibles | "El response DEBERÍA incluir paginación" |
+| **PUEDE** (MAY) | Opcional | "El usuario PUEDE agregar avatar" |
+| **NO DEBE** (MUST NOT) | Prohibición absoluta | "NO DEBE almacenar tokens en plain text" |
+
+## Auto-Detección de Rigor
+
+Don Cheli auto-detecta el rigor necesario:
+
+| Indicador | Rigor |
+|-----------|-------|
+| Nivel 0-1 (Atómico/Micro) | 📝 Ligera |
+| Nivel 2 (Estándar) | 📝 Ligera o 📋 Completa |
+| Nivel 3-4 (Complejo/Producto) | 📋 Completa |
+| Toca seguridad/pagos/auth | 📋 Completa siempre |
+| Cambia API pública | 📋 Completa siempre |
+| Refactor interno | 📝 Ligera |

package/habilidades/rlm/HABILIDAD.md

@@ -0,0 +1,85 @@
+---
+nombre: RLM — Modelo de Lenguaje Recursivo
+descripcion: "Recursive Language Model: verificar, razonar en cadena y descomponer problemas con sub-LLMs"
+version: 1.0.0
+autor: Don Cheli
+tags: [rlm, razonamiento, sub-llm, recursivo]
+activacion: "RLM", "verificar con otro modelo", "razonamiento recursivo", "sub-LLM"
+---
+
+# Habilidad: RLM — Modelo de Lenguaje Recursivo
+
+**Versión:** 1.0.0
+**Categoría:** Razonamiento Avanzado
+**Tipo:** Flexible
+
+> Basado en el paradigma **Recursive Language Model** de [PrimeIntellect](https://www.primeintellect.ai/blog/rlm) (2026)
+
+## Qué es el RLM
+
+El RLM permite a un LLM **gestionar activamente su propio contexto**. En vez de ingerir directamente datos potencialmente enormes, el modelo usa un **REPL Python persistente** para:
+
+1. **Inspeccionar y transformar** datos de entrada programáticamente
+2. **Llamar sub-LLMs** frescos desde el REPL via `llm_batch()`
+3. **Delegar herramientas** solo a los sub-LLMs (mantener el contexto principal limpio)
+4. **Construir la respuesta** iterativamente via variable `respuesta`
+
+## Arquitectura Central
+
+```
+┌──────────────────────────────────────────┐
+│            RLM Principal                  │
+│         (Orquestador — contexto limpio)   │
+│                                           │
+│  ┌────────────────────────────────────┐  │
+│  │         REPL Python Persistente    │  │
+│  │                                     │  │
+│  │  datos = env.input_data             │  │
+│  │  resultados = llm_batch([...])      │  │
+│  │  respuesta["contenido"] = ...       │  │
+│  │  respuesta["lista"] = True          │  │
+│  └────────────────────────────────────┘  │
+│                                           │
+│  ┌──────┐  ┌──────┐  ┌──────┐           │
+│  │SubLLM│  │SubLLM│  │SubLLM│  FRESCOS  │
+│  │+tools│  │+tools│  │+tools│  PARALELO │
+│  └──────┘  └──────┘  └──────┘           │
+└──────────────────────────────────────────┘
+```
+
+## Principios Clave
+
+| Principio | Descripción |
+|-----------|-------------|
+| **Datos al entorno, no al contexto** | Los datos van al REPL Python, no al prompt del LLM |
+| **Herramientas solo para sub-LLMs** | El RLM principal NO usa herramientas directamente |
+| **Context folding > summarization** | Delegar ≠ resumir. No se pierde información |
+| **Contexto fresco por sub-LLM** | Cada sub-LLM es una instancia nueva sin context rot |
+| **Respuesta por difusión** | Se construye y edita iterativamente |
+| **`llm_batch()` paralelo** | Sub-tareas independientes se despachan en paralelo |
+
+## Los 3 Modelos RLM
+
+| Modelo | Comando | Caso de Uso |
+|--------|---------|-------------|
+| Verificación | `/razonar:rlm-verificacion` | Verificar código contra specs con sub-LLMs |
+| Cadena de Pensamiento | `/razonar:rlm-cadena-pensamiento` | Razonamiento multi-paso con context folding |
+| Descomposición | `/razonar:rlm-descomposicion` | Codebases grandes, inputs masivos |
+
+## Árbol de Decisión
+
+```
+¿El problema involucra inputs masivos o contexto muy largo?
+├── SÍ → rlm-descomposicion (Map-Reduce / Divide-Conquista)
+└── NO → ¿Necesita verificación contra criterios?
+          ├── SÍ → rlm-verificacion (sub-LLMs con tests/tools)
+          └── NO → ¿Es razonamiento multi-paso?
+                    ├── SÍ → rlm-cadena-pensamiento (context folding)
+                    └── NO → Usar modelo de razonamiento clásico
+```
+
+## Referencia
+
+- [PrimeIntellect: Recursive Language Models](https://www.primeintellect.ai/blog/rlm)
+- [Alex Zhang (MIT): Paper original RLM](https://arxiv.org/abs/2512.24601)
+- [Context Rot Research](https://research.trychroma.com/context-rot)

package/habilidades/routing-modelos/HABILIDAD.md

@@ -0,0 +1,79 @@
+---
+nombre: Routing Dinámico de Modelos
+descripcion: Seleccionar automáticamente el modelo más eficiente para cada tarea basándose en heurísticas
+version: 1.0.0
+autor: Don Cheli
+tags: [optimizacion, tokens, modelos, costos]
+---
+
+# Routing Dinámico de Modelos
+
+## Propósito
+
+Seleccionar automáticamente el modelo de IA más eficiente (haiku/sonnet/opus) para cada tarea, sin intervención del usuario. Downgrade-only: nunca sube de modelo automáticamente, solo baja.
+
+## Heurísticas de Clasificación
+
+### Por tipo de tarea (keywords)
+
+| Keywords detectados | Modelo sugerido | Razón |
+|---------------------|-----------------|-------|
+| "format", "rename", "reorder", "sort", "lint" | haiku | Transformación mecánica |
+| "summarize", "extract", "list", "count" | haiku | Extracción de información |
+| "generate test", "scaffold", "boilerplate" | haiku→sonnet | Generación con template |
+| "implement", "fix bug", "add feature", "refactor" | sonnet | Generación de código |
+| "review", "analyze", "audit", "design" | sonnet | Análisis |
+| "architecture", "security", "migration", "concurrency" | opus | Razonamiento complejo |
+
+### Por métricas cuantitativas
+
+| Métrica | haiku | sonnet | opus |
+|---------|-------|--------|------|
+| Archivos afectados | 1-2 | 3-10 | 10+ |
+| Steps en el plan | 1-3 | 4-8 | 8+ |
+| Dependencias cruzadas | 0 | 1-3 | 3+ |
+
+### Por presión de budget
+
+| % budget usado | Acción |
+|----------------|--------|
+| < 50% | Sin cambio |
+| 50-75% | Downgrade: opus→sonnet donde posible |
+| 75-90% | Downgrade: sonnet→haiku donde posible |
+| > 90% | Solo haiku (salvo seguridad/arquitectura) |
+
+## Escalation on Failure
+
+Si una tarea falla con el modelo seleccionado (e.g., haiku genera código incorrecto):
+1. Registrar fallo en `.especdev/routing-history.json`
+2. Reintentar con el siguiente modelo superior
+3. Actualizar heurística para esa categoría de tarea
+
+## Historial de Routing
+
+```json
+{
+  "decisions": [
+    {
+      "task": "T045",
+      "description": "Implementar matches.controller",
+      "suggested": "sonnet",
+      "actual": "sonnet",
+      "success": true,
+      "tokens": 4200
+    }
+  ],
+  "failure_rate_by_tier": {
+    "haiku": 0.12,
+    "sonnet": 0.03,
+    "opus": 0.01
+  }
+}
+```
+
+## Integración
+
+- Se ejecuta automáticamente al inicio de cada tarea en `/especdev:implementar`
+- El usuario puede override con `--modelo opus` en cualquier comando
+- Se reporta en `/especdev:cerrar-sesion` y `proyecciones-costo`
+- Nunca overridea la regla: "Opus requiere confirmación del usuario"

package/habilidades/salud-habilidades/HABILIDAD.md

@@ -0,0 +1,63 @@
+---
+nombre: Salud de Habilidades
+descripcion: Monitorear el rendimiento y uso de habilidades del framework
+version: 1.0.0
+autor: Don Cheli
+tags: [observabilidad, optimizacion, telemetria]
+---
+
+# Salud de Habilidades
+
+## Propósito
+
+Trackear qué habilidades se usan, su tasa de éxito, consumo de tokens, y detectar instruction drift. Permite optimizar el framework basándose en datos reales.
+
+## Métricas Trackeadas
+
+| Métrica | Cómo se mide | Umbral |
+|---------|--------------|--------|
+| Success rate | Resultado exitoso / intentos totales | < 70% → review |
+| Token consumption | Tokens por invocación (promedio) | > 20K → optimizar |
+| Usage frequency | Invocaciones por sesión | 0 en 10 sesiones → considerar deprecar |
+| Instruction drift | Desviación del comportamiento esperado | Cualquier desviación → queue |
+
+## Implementación
+
+### Registro de telemetría
+
+Después de cada uso de habilidad, registrar en `.especdev/metricas.json`:
+
+```json
+{
+  "habilidad": "deteccion-stubs",
+  "timestamp": "2026-03-22T14:30:00Z",
+  "exito": true,
+  "tokens_consumidos": 3200,
+  "duracion_ms": 8500,
+  "contexto": "implementar fase 3"
+}
+```
+
+### Reporte de salud
+
+```
+📊 Salud de Habilidades — Últimas 10 sesiones
+
+| Habilidad | Usos | Éxito | Tokens/uso | Estado |
+|-----------|------|-------|------------|--------|
+| deteccion-stubs | 12 | 92% | 3.2K | ✅ Saludable |
+| optimizacion-tokens | 8 | 75% | 8.1K | ⚠️ Review (tokens altos) |
+| brainstorming | 2 | 100% | 5.0K | ✅ Saludable |
+| code-rag | 0 | — | — | 📉 Sin uso |
+
+Recomendaciones:
+- optimizacion-tokens: reducir contexto cargado (actualmente carga 3 archivos completos)
+- code-rag: considerar activar automáticamente en /especdev:minar-referencias
+```
+
+## Integración
+
+- Se activa automáticamente si `metricas.habilitado: true` en config.yaml
+- Los datos se guardan en `.especdev/metricas.json`
+- Se reporta con `/especdev:diagnostico --habilidades` o `/especdev:doctor`
+- Las habilidades con < 70% success rate se agregan a `.especdev/skill-review-queue.md`

package/habilidades/schemas-dbml/HABILIDAD.md

@@ -0,0 +1,101 @@
+---
+nombre: Schemas DBML (Verdad Viva)
+descripcion: "Generar y mantener schemas de base de datos en formato DBML sincronizados con las specs Gherkin"
+version: 1.0.0
+autor: Don Cheli
+tags: [dbml, schema, base-de-datos, especificacion]
+activacion: "schema DBML", "modelo de datos", "base de datos", "tablas"
+---
+
+# Habilidad: Schemas DBML (Verdad Viva)
+
+**Versión:** 1.0.0
+**Categoría:** Especificación
+**Tipo:** Rígida
+
+> Adaptado de Specular (pei9564/Specular → constitution.md §I-B)
+
+## Cómo Mejora el Framework
+
+Sin DBML, el schema de base de datos se define de forma ad-hoc y se pierde sincronía con el código. Con DBML:
+
+- El schema es la **verdad absoluta** para nombres y tipos de campos
+- Los Gherkin scenarios usan los MISMOS nombres que el DBML
+- El pipeline detecta inconsistencias automáticamente
+
+## Qué es DBML
+
+[DBML (Database Markup Language)](https://dbml.dbdiagram.io/) es un lenguaje simple para modelar schemas de BD.
+
+```dbml
+// specs/db_schema/usuario.dbml
+Table usuario {
+  id uuid [pk, default: `gen_random_uuid()`]
+  email varchar(255) [unique, not null]
+  password_hash varchar(255) [not null]
+  nombre varchar(100) [not null]
+  created_at timestamp [not null, default: `now()`]
+  updated_at timestamp [not null, default: `now()`]
+}
+```
+
+## Ciclo de Vida
+
+### 1. Provisional (`@provisional`)
+
+```dbml
+// @provisional — Auto-generado por /especdev:especificar
+Table orden @provisional {
+  id uuid [pk]
+  usuario_id uuid [ref: > usuario.id]
+  total decimal [not null]
+  estado varchar(20) [not null]
+}
+```
+
+- Se genera automáticamente al crear una spec si no existe
+- Es un **borrador** que necesita revisión
+- Los scenarios Gherkin DEBEN usar estos nombres tal como están
+
+### 2. Ratificado (sin tag)
+
+```dbml
+// Ratificado — Revisado en fase Clarify
+Table orden {
+  id uuid [pk, default: `gen_random_uuid()`]
+  usuario_id uuid [ref: > usuario.id, not null]
+  total decimal(10,2) [not null]
+  estado varchar(20) [not null, default: 'pendiente']
+  created_at timestamp [not null, default: `now()`]
+}
+```
+
+- Revisado durante `/especdev:clarificar` o `/especdev:planificar-tecnico`
+- Se convierte en **Verdad Absoluta**
+- Extensión solo con `@provisional` en las NUEVAS partes
+- Renombrar campos requiere nota de migración
+
+## Estructura
+
+```
+specs/
+└── db_schema/
+    ├── _proyecto.dbml        # Metadata del proyecto
+    ├── _relaciones.dbml      # Relaciones cross-dominio
+    ├── usuario.dbml           # Schema de usuarios
+    ├── orden.dbml             # Schema de órdenes
+    └── ...
+```
+
+## Integración con el Pipeline
+
+```
+especificar → ¿Existe DBML? 
+├── NO → Generar DBML @provisional → Incluir en .feature
+└── SÍ → Usar DBML existente como referencia
+
+clarificar → Verificar consistencia Schema↔Gherkin
+             → Ratificar @provisional si está correcto
+
+planificar-tecnico → Generar modelos Pydantic/TypeScript DESDE el DBML
+```

package/habilidades/trazabilidad/HABILIDAD.md

@@ -0,0 +1,63 @@
+---
+nombre: Pipeline de Trazabilidad
+descripcion: "Mantener trazabilidad completa entre requisitos, specs, código y tests en todo el pipeline"
+version: 1.0.0
+autor: Don Cheli
+tags: [trazabilidad, calidad, gherkin, pipeline]
+activacion: "trazabilidad", "de dónde viene este requisito", "rastrear cambio"
+---
+
+# Habilidad: Pipeline de Trazabilidad
+
+**Versión:** 1.0.0
+**Categoría:** Calidad
+**Tipo:** Rígida
+
+> Adaptado de Specular: "Cada línea de código se traza hasta un escenario Gherkin."
+
+## Cómo Mejora el Framework
+
+La trazabilidad garantiza que **nada se inventa de la nada**. Cada línea de código puede rastrearse hasta:
+1. Un Escenario Gherkin (`.feature`)
+2. Que a su vez viene de un Requerimiento del usuario
+3. Que a su vez fue clarificado (sin ambigüedades)
+
+## Matriz de Trazabilidad
+
+```
+Requerimiento → .feature (Gherkin) → .plan.md (Blueprint) → .tasks.md (Tareas) → Código → Tests
+      │                │                    │                      │              │        │
+      └────────────────┴────────────────────┴──────────────────────┴──────────────┴────────┘
+                    Todo se traza hacia atrás hasta el requerimiento original
+```
+
+## Artefactos Trazables
+
+| Artefacto | Formato | Trazable a |
+|-----------|---------|------------|
+| `Feature.feature` | Gherkin | Requerimiento original |
+| `Feature.plan.md` | Markdown | Escenarios en .feature |
+| `Feature.tasks.md` | Markdown | Contratos en .plan.md |
+| Código fuente | Lenguaje | Tareas en .tasks.md |
+| Tests | Frameworks | Escenarios en .feature |
+| `review.md` | Markdown | Todo lo anterior |
+
+## Tags de Estado
+
+| Tag | Significado | Quién lo Pone |
+|-----|-------------|---------------|
+| `@borrador` | Spec en progreso, no lista | `/especdev:especificar` |
+| `@clarificada` | Ambigüedades resueltas | `/especdev:clarificar` |
+| `@lista` | Aprobada para implementación | Puerta de Calidad |
+| `@implementada` | Código escrito y tests pasan | `/especdev:implementar` |
+| `@provisional` | Schema DBML no ratificado | Auto-generado |
+
+## Propiedad de Archivos
+
+| El Framework Posee | Tú Posees |
+|---------------------|-----------|
+| `.especdev/` (config, templates) | `specs/features/*` (tus specs) |
+| `comandos/` (slash commands) | `specs/db_schema/*` (tus schemas) |
+| `habilidades/` (skills) | `app/*` / `src/*` (tu código) |
+| `reglas/` (rules) | `tests/*` (tus tests) |
+| `plantillas/` (templates) | `CLAUDE.md` (tus instrucciones) |

package/habilidades/ui-ux-design/HABILIDAD.md

@@ -0,0 +1,76 @@
+---
+nombre: UI/UX Design System
+descripcion: "Aplicar sistema de diseño con 67 estilos y 161 paletas de colores para interfaces consistentes"
+version: 1.0.0
+autor: Don Cheli
+tags: [diseño, ui, ux, design-system, colores]
+activacion: "diseño UI", "paleta de colores", "design system", "estilos", "UX"
+---
+
+# Habilidad: UI/UX Design System
+
+**Versión:** 1.0.0
+**Categoría:** Diseño
+**Tipo:** Flexible
+
+> Adaptado de [ui-ux-pro-max](https://github.com/nextlevelbuilder/ui-ux-pro-max-skill) — Motor de razonamiento multi-dominio para diseño.
+
+## Propósito
+
+Generar sistemas de diseño completos (estilos, colores, tipografía, patrones) a partir de la descripción del producto. Complementa `/especdev:contrato-ui` que **bloquea** estándares — esta habilidad **genera** las opciones.
+
+## Relación con contrato-ui
+
+```
+ui-ux-design (GENERAR)  →  contrato-ui (BLOQUEAR)  →  implementar (CODEAR)
+     ↑                          ↑                          ↑
+  "¿Qué estilo?"         "Este es el estándar"      "Codear con estándar"
+```
+
+## Dominios de Búsqueda (5 paralelos)
+
+| Dominio | Qué evalúa | Datos |
+|---------|-----------|-------|
+| **Estilo** | Tendencia visual | 67 estilos UI |
+| **Color** | Paleta por industria | 161 paletas |
+| **Tipografía** | Par de fuentes | 57 pares Google Fonts |
+| **Patrones** | Componentes y layouts | Por stack técnico |
+| **UX** | Accesibilidad y usabilidad | 99 guidelines |
+
+## Flujo
+
+```
+1. Describir producto (tipo, audiencia, tono)
+2. Ejecutar búsqueda multi-dominio (5 en paralelo)
+3. Presentar 3 opciones de sistema de diseño
+4. Usuario elige
+5. Generar tokens CSS + guía de componentes
+6. (Opcional) Bloquear con /especdev:contrato-ui
+```
+
+## Output
+
+```
+specs/ui/
+├── design-system.md       # Documento del sistema elegido
+├── tokens.css             # Variables CSS generadas
+└── componentes.md         # Guía de componentes
+```
+
+## Estilos Más Usados
+
+| Estilo | Cuándo Usar |
+|--------|------------|
+| Glassmorphism | Apps modernas, dashboards |
+| Neumorphism | Interfaces suaves, settings |
+| Brutalism | Portfolios, creativos |
+| Material 3 | Apps Android, consistencia |
+| Flat Design | SaaS, enterprise |
+| Skeuomorphism | Apps de nicho, juegos |
+
+## Guardrails
+
+- Siempre verificar contraste WCAG AA (4.5:1 texto, 3:1 UI)
+- Google Fonts únicamente (disponibilidad garantizada)
+- Tokens CSS con custom properties (`--color-primary`, `--font-heading`)
+- Si existe `contrato-ui.yaml` → respetar como constraint, no sobreescribir