don-cheli-sdd 1.13.0

package/scripts/.claude/don-cheli/habilidades/refactorizacion-solid/HABILIDAD.md

@@ -0,0 +1,173 @@
+# Habilidad: Refactorización SOLID y Clean Code
+
+**Versión:** 1.0.0
+**Categoría:** Calidad
+**Tipo:** Flexible
+
+## Cómo Mejora el Framework
+
+Don Cheli tiene la Constitución (Art. II: Precisión Quirúrgica, Art. III: Plug-and-Play) que define principios, pero no provee un proceso estructurado para refactorizar código existente aplicando patrones de diseño y principios SOLID.
+
+## Cuándo Activar
+
+- Al detectar code smells durante `/especdev:revisar`
+- Cuando un módulo supera umbrales de complejidad
+- Antes de agregar funcionalidad a código legacy
+- Cuando el usuario solicita refactorización explícitamente
+
+## Los 5 Principios SOLID como Checklist
+
+### S — Single Responsibility (Responsabilidad Única)
+
+```
+Verificar: ¿Tiene la clase/módulo una sola razón para cambiar?
+
+Smells:
+  ❌ Clase con > 200 líneas
+  ❌ Más de 3 dependencias inyectadas
+  ❌ Nombre genérico (Manager, Helper, Utils, Handler)
+  ❌ Múltiples secciones con comentarios "// --- Sección X ---"
+
+Fix: Extraer a clases/módulos especializados
+  UserService → UserCreator + UserValidator + UserNotifier
+```
+
+### O — Open/Closed (Abierto/Cerrado)
+
+```
+Verificar: ¿Se puede extender sin modificar código existente?
+
+Smells:
+  ❌ Cadenas if/else o switch crecientes
+  ❌ Modificar clase existente para cada nueva variante
+  ❌ Parámetros booleanos que cambian comportamiento
+
+Fix: Strategy pattern, Plugin pattern, Registry pattern
+  if (type === 'credit') {...} else if (type === 'debit') {...}
+  → paymentStrategies[type].process(data)
+```
+
+### L — Liskov Substitution (Sustitución de Liskov)
+
+```
+Verificar: ¿Las subclases pueden reemplazar a la clase padre sin romper nada?
+
+Smells:
+  ❌ Subclase que lanza NotImplementedError en método heredado
+  ❌ instanceof checks en código que usa la abstracción
+  ❌ Override que cambia la semántica del método padre
+
+Fix: Rediseñar jerarquía, usar composición sobre herencia
+  Square extends Rectangle (rompe Liskov)
+  → Shape interface con área() independiente
+```
+
+### I — Interface Segregation (Segregación de Interfaces)
+
+```
+Verificar: ¿Las interfaces son específicas o fuerzan a implementar métodos innecesarios?
+
+Smells:
+  ❌ Interfaces con > 5 métodos
+  ❌ Implementaciones con métodos vacíos o throw
+  ❌ "God interface" que mezcla concerns
+
+Fix: Dividir en interfaces específicas
+  IUserService (create, read, update, delete, sendEmail, generateReport)
+  → IUserCRUD + IUserNotification + IUserReporting
+```
+
+### D — Dependency Inversion (Inversión de Dependencias)
+
+```
+Verificar: ¿Los módulos de alto nivel dependen de abstracciones, no de implementaciones?
+
+Smells:
+  ❌ new ConcreteService() dentro de otra clase
+  ❌ Import directo de implementación concreta
+  ❌ Tests que requieren infraestructura real
+
+Fix: Inyección de dependencias
+  class AuthService { db = new PostgresDB() }
+  → class AuthService { constructor(private db: IDatabase) }
+```
+
+## Patrones de Diseño — Cuándo Aplicar
+
+| Patrón | Cuándo Usar | Ejemplo |
+|--------|------------|---------|
+| **Factory** | Creación de objetos con lógica condicional | `createPaymentProcessor(type)` |
+| **Strategy** | Algoritmos intercambiables | Múltiples métodos de envío |
+| **Observer** | Notificación de cambios sin acoplamiento | Eventos de dominio |
+| **Adapter** | Integrar interfaces incompatibles | Wrapper para API externa |
+| **Repository** | Abstraer acceso a datos | `UserRepository` interface |
+| **Decorator** | Agregar comportamiento sin modificar | Logging, caching, retry |
+| **Builder** | Construir objetos complejos paso a paso | Query builder, config builder |
+| **Facade** | Simplificar subsistema complejo | `PaymentFacade` sobre Stripe+Tax+Invoice |
+
+**Regla:** Aplicar un patrón solo cuando el smell existe. Nunca aplicar preventivamente.
+
+## Proceso de Refactorización
+
+```
+1. IDENTIFICAR — Detectar smells con análisis estático
+   └── Complejidad ciclomática, acoplamiento, cohesión
+
+2. PLANIFICAR — Definir qué principio/patrón aplicar
+   └── [REGLA 4: Si cambia arquitectura → PARAR Y PREGUNTAR]
+
+3. PROTEGER — Asegurar que hay tests antes de refactorizar
+   └── Si no hay tests → escribirlos primero (Ley de Hierro #1)
+
+4. REFACTORIZAR — Aplicar cambio mínimo viable (Art. II Constitución)
+   └── Un patrón a la vez, nunca varios simultáneos
+
+5. VERIFICAR — Ejecutar tests, verificar que pasan
+   └── Cero cambio de comportamiento (Ley de Hierro #3)
+```
+
+## Métricas de Código
+
+| Métrica | Umbral Aceptable | Umbral Refactorizar |
+|---------|------------------|---------------------|
+| Complejidad ciclomática | ≤ 10 | > 15 |
+| Líneas por función | ≤ 30 | > 50 |
+| Líneas por archivo | ≤ 300 | > 500 |
+| Profundidad de anidamiento | ≤ 3 | > 4 |
+| Parámetros por función | ≤ 3 | > 5 |
+| Dependencias por módulo | ≤ 5 | > 7 |
+
+## Output del Análisis
+
+```markdown
+## Análisis de Refactorización: src/services/order_service.py
+
+### Smells Detectados
+
+| # | Smell | Principio | Severidad | Líneas |
+|---|-------|-----------|-----------|--------|
+| 1 | Clase de 450 líneas con 12 métodos | S (SRP) | ❌ Alto | 1-450 |
+| 2 | Switch de 8 casos para tipo de pago | O (OCP) | ⚠️ Medio | 120-180 |
+| 3 | `new StripeClient()` hardcoded | D (DIP) | ⚠️ Medio | 45 |
+
+### Plan de Refactorización
+
+1. **Extraer** validaciones → `OrderValidator` (SRP)
+2. **Extraer** cálculos → `OrderCalculator` (SRP)
+3. **Strategy** para tipos de pago → `PaymentStrategy` interface (OCP)
+4. **Inyectar** StripeClient via constructor (DIP)
+
+### Impacto Estimado
+- Archivos afectados: 4 (crear 3 nuevos, modificar 1)
+- Tests a actualizar: 6
+- Riesgo: Bajo (cambio de estructura, no de comportamiento)
+```
+
+## Guardrails
+
+- **Nunca** refactorizar sin tests existentes — escribirlos primero
+- **Nunca** aplicar múltiples patrones en un solo PR
+- **Nunca** refactorizar "de paso" junto a una feature (Art. II)
+- **Siempre** verificar cero cambio de comportamiento post-refactor
+- **Siempre** pedir confirmación si afecta > 5 archivos (Regla 4)
+- **Siempre** justificar el patrón elegido vs alternativa más simple

package/scripts/.claude/don-cheli/habilidades/reflexion/HABILIDAD.md

@@ -0,0 +1,15 @@
+# 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?

package/scripts/.claude/don-cheli/habilidades/rigor-progresivo/HABILIDAD.md

@@ -0,0 +1,100 @@
+# 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/scripts/.claude/don-cheli/habilidades/rlm/HABILIDAD.md

@@ -0,0 +1,76 @@
+# 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/scripts/.claude/don-cheli/habilidades/schemas-dbml/HABILIDAD.md

@@ -0,0 +1,92 @@
+# 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/scripts/.claude/don-cheli/habilidades/trazabilidad/HABILIDAD.md

@@ -0,0 +1,54 @@
+# 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/scripts/.claude/don-cheli/habilidades/ui-ux-design/HABILIDAD.md

@@ -0,0 +1,67 @@
+# 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