don-cheli-sdd 1.22.0 → 1.23.0

package/CHANGELOG.md

@@ -4,6 +4,12 @@ Todos los cambios notables en Don Cheli SDD Framework.
 
 Formato basado en [Conventional Commits](https://www.conventionalcommits.org/).
 
+## [1.23.0](https://github.com/doncheli/don-cheli-sdd/compare/v1.22.0...v1.23.0) (2026-04-07)
+
+### Nuevas Funcionalidades
+
+* integrar PRD como fase 0 opcional en el pipeline SDD ([6e6fdd2](https://github.com/doncheli/don-cheli-sdd/commit/6e6fdd2e9e595994f343a7943bbd6f753ca061d8))
+
 ## [1.22.0](https://github.com/doncheli/don-cheli-sdd/compare/v1.21.1...v1.22.0) (2026-04-07)
 
 ### Nuevas Funcionalidades

package/README.es.md

@@ -12,7 +12,7 @@
   </p>
   <p align="center">
     <a href="#-instalación"><img src="https://img.shields.io/badge/instalación-2_minutos-brightgreen" alt="Install"></a>
-    <img src="https://img.shields.io/badge/versión-1.22.0-blue" alt="Version">
+    <img src="https://img.shields.io/badge/versión-1.23.0-blue" alt="Version">
     <img src="https://img.shields.io/badge/licencia-Apache%202.0-green" alt="License">
     <img src="https://img.shields.io/badge/idiomas-ES%20|%20EN%20|%20PT-red" alt="Languages">
     <img src="https://img.shields.io/badge/comandos-85+-purple" alt="Commands">
@@ -163,6 +163,7 @@ Paso 4: ✅ Confirmar   → Resumen de todo lo seleccionado
 
 ```mermaid
 flowchart LR
+    P["📋 PRD"] -.->|opcional| B
     A["💡 Idea"] --> B["📄 Especificar"]
     B --> C["🔍 Clarificar"]
     C --> D["🏗 Planificar"]
@@ -170,6 +171,7 @@ flowchart LR
     E --> F["⚡ Implementar"]
     F --> G["✅ Revisar"]
 
+    style P fill:#2d3436,color:#dfe6e9,stroke:#6c5ce7,stroke-dasharray: 5 5
     style B fill:#6c5ce7,color:#fff
     style C fill:#0984e3,color:#fff
     style D fill:#00b894,color:#fff
@@ -178,6 +180,8 @@ flowchart LR
     style G fill:#fd79a8,color:#fff
 ```
 
+> **PRD (opcional):** Si tienes un diseno en Figma, brief de producto o user research, ejecuta `/dc:prd` primero. El PRD alimenta automaticamente a Especificar con user stories, prioridades y riesgos.
+
 | # | Fase | Comando | Qué hace |
 |---|------|---------|----------|
 | 1 | **Especificar** | `/dc:especificar` | Convierte tu idea en especificación Gherkin con escenarios de prueba, prioridades y schema DBML |

package/README.md

@@ -12,7 +12,7 @@
   </p>
   <p align="center">
     <a href="#-installation"><img src="https://img.shields.io/badge/install-2_minutes-brightgreen" alt="Install"></a>
-    <img src="https://img.shields.io/badge/version-1.22.0-blue" alt="Version">
+    <img src="https://img.shields.io/badge/version-1.23.0-blue" alt="Version">
     <img src="https://img.shields.io/badge/license-Apache%202.0-green" alt="License">
     <img src="https://img.shields.io/badge/languages-ES%20|%20EN%20|%20PT-red" alt="Languages">
     <img src="https://img.shields.io/badge/commands-85+-purple" alt="Commands">
@@ -163,6 +163,7 @@ Step 4: ✅ Confirm  → Summary of everything selected
 
 ```mermaid
 flowchart LR
+    P["📋 PRD"] -.->|optional| B
     A["💡 Idea"] --> B["📄 Specify"]
     B --> C["🔍 Clarify"]
     C --> D["🏗 Plan"]
@@ -170,6 +171,7 @@ flowchart LR
     E --> F["⚡ Implement"]
     F --> G["✅ Review"]
 
+    style P fill:#2d3436,color:#dfe6e9,stroke:#6c5ce7,stroke-dasharray: 5 5
     style B fill:#6c5ce7,color:#fff
     style C fill:#0984e3,color:#fff
     style D fill:#00b894,color:#fff
@@ -178,6 +180,8 @@ flowchart LR
     style G fill:#fd79a8,color:#fff
 ```
 
+> **PRD (optional):** If you have a Figma design, product brief or user research, run `/dc:prd` first. The PRD auto-feeds into Specify with user stories, priorities and risks.
+
 | # | Phase | Command | What it does |
 |---|-------|---------|-------------|
 | 1 | **Specify** | `/dc:specify` | Turns your idea into a Gherkin specification with test scenarios, priorities and DBML schema |

package/README.pt.md

@@ -12,7 +12,7 @@
   </p>
   <p align="center">
     <a href="#-instalação"><img src="https://img.shields.io/badge/instalação-2_minutos-brightgreen" alt="Install"></a>
-    <img src="https://img.shields.io/badge/versão-1.22.0-blue" alt="Version">
+    <img src="https://img.shields.io/badge/versão-1.23.0-blue" alt="Version">
     <img src="https://img.shields.io/badge/licença-Apache%202.0-green" alt="License">
     <img src="https://img.shields.io/badge/idiomas-ES%20|%20EN%20|%20PT-red" alt="Languages">
     <img src="https://img.shields.io/badge/comandos-85+-purple" alt="Commands">
@@ -162,6 +162,7 @@ Passo 4: ✅ Confirmar  → Resumo de tudo selecionado
 
 ```mermaid
 flowchart LR
+    P["📋 PRD"] -.->|opcional| B
     A["💡 Ideia"] --> B["📄 Especificar"]
     B --> C["🔍 Clarificar"]
     C --> D["🏗 Planejar"]
@@ -169,6 +170,7 @@ flowchart LR
     E --> F["⚡ Implementar"]
     F --> G["✅ Revisar"]
 
+    style P fill:#2d3436,color:#dfe6e9,stroke:#6c5ce7,stroke-dasharray: 5 5
     style B fill:#6c5ce7,color:#fff
     style C fill:#0984e3,color:#fff
     style D fill:#00b894,color:#fff
@@ -177,6 +179,8 @@ flowchart LR
     style G fill:#fd79a8,color:#fff
 ```
 
+> **PRD (opcional):** Se voce tem um design Figma, brief de produto ou user research, execute `/dc:prd` primeiro. O PRD alimenta automaticamente Especificar com user stories, prioridades e riscos.
+
 | # | Fase | Comando | O que faz |
 |---|------|---------|-----------|
 | 1 | **Especificar** | `/dc:especificar` | Transforma sua ideia em especificação Gherkin com cenários de teste, prioridades e schema DBML |

package/VERSION

@@ -1 +1 @@
-1.22.0
+1.23.0

package/comandos/dc/comenzar.md

@@ -43,12 +43,35 @@ Nivel = max(puntuaciones)  // Conservador: gana la dimensión más alta
 
 ## Comportamiento
 
-1. **Analizar** la descripción de la tarea
-2. **Evaluar** las 4 dimensiones (alcance, incógnitas, riesgo, duración)
-3. **Determinar** nivel de complejidad
-4. **Mostrar** evaluación al usuario
-5. **Preguntar** si está de acuerdo o desea ajustar
-6. **Iniciar** flujo del nivel correspondiente
+1. **Detectar PRD** — ¿Existe `.dc/prd/prd-*.md`? ¿El usuario proporcionó brief, Figma o docs?
+   - Si hay PRD existente → usarlo como input para las fases siguientes
+   - Si hay brief/Figma/docs pero no PRD → preguntar: "¿Quieres generar un PRD primero? (/dc:prd)"
+   - Si no hay nada → continuar sin PRD (flujo normal)
+2. **Analizar** la descripción de la tarea (o el PRD si existe)
+3. **Evaluar** las 4 dimensiones (alcance, incógnitas, riesgo, duración)
+4. **Determinar** nivel de complejidad
+5. **Mostrar** evaluación al usuario
+6. **Preguntar** si está de acuerdo o desea ajustar
+7. **Iniciar** flujo del nivel correspondiente
+
+### Flujo con PRD (niveles 2-4)
+
+```
+¿Se detectó PRD o fuentes de producto?
+  │
+  ├─ SÍ, PRD existe (.dc/prd/prd-*.md)
+  │   → Leer PRD
+  │   → Extraer user stories, prioridades, riesgos
+  │   → Alimentar /dc:especificar automáticamente
+  │
+  ├─ SÍ, hay brief/Figma pero no PRD
+  │   → "Se detectaron fuentes de producto. ¿Generar PRD? (s/n)"
+  │   → Si sí: /dc:prd → luego continúa el pipeline
+  │   → Si no: continuar sin PRD
+  │
+  └─ NO hay fuentes de producto
+      → Flujo normal (el usuario describe la tarea)
+```
 
 ## Ejemplo
 
@@ -85,9 +108,11 @@ Inspirada en el framework BMAD: el nivel de planificación se ajusta automática
 | **0 — Atómico** | implementar → verificar | spec, clarificar, planificar, desglosar |
 | **1 — Micro** | especificar (light) → implementar → revisar | clarificar, planificar, desglosar, pseudocódigo |
 | **P — PoC** | hipótesis → construir → evaluar → veredicto | todo el pipeline formal |
-| **2 — Estándar** | especificar → clarificar → planificar → desglosar → implementar → revisar | pseudocódigo (opcional) |
-| **3 — Complejo** | especificar → clarificar → pseudocódigo → planificar → diseñar → desglosar → implementar → revisar | nada se salta |
-| **4 — Producto** | constitución → proponer → especificar → clarificar → pseudocódigo → planificar → diseñar → desglosar → implementar → revisar | nada se salta |
+| **2 — Estándar** | [PRD →] especificar → clarificar → planificar → desglosar → implementar → revisar | pseudocódigo (opcional) |
+| **3 — Complejo** | [PRD →] especificar → clarificar → pseudocódigo → planificar → diseñar → desglosar → implementar → revisar | nada se salta |
+| **4 — Producto** | [PRD →] constitución → proponer → especificar → clarificar → pseudocódigo → planificar → diseñar → desglosar → implementar → revisar | nada se salta |
+
+> **[PRD]** = Fase 0 opcional. Si existe `.dc/prd/prd-*.md` o el usuario proporciona un brief/Figma, se ejecuta `/dc:prd` primero. El PRD alimenta automáticamente a `/dc:especificar` con user stories, prioridades y riesgos.
 
 **Principio:** No aplicar el mismo proceso a un micro-fix que a una migración de plataforma. La fricción innecesaria es tan dañina como la falta de estructura.
 

package/comandos/dc/especificar.md

@@ -20,6 +20,16 @@ Convertir un requerimiento en lenguaje natural a una especificación Gherkin est
 
 ## Comportamiento
 
+0. **Detectar PRD** — Si existe `.dc/prd/prd-*.md`:
+   - Leer el PRD y extraer automáticamente:
+     - User stories (sección 6.1) → base para escenarios Gherkin
+     - Prioridades MoSCoW → mapear a P1 (Must), P2 (Should), P3+ (Could/Won't)
+     - Riesgos (sección 8) → agregar escenarios de error/edge case por riesgo
+     - Requirements no funcionales (sección 6.2) → anotar como constraints
+     - Data model DBML (sección 6.4) → usar como schema base si existe
+   - Informar al usuario: "PRD detectado — extrayendo X user stories, Y riesgos"
+   - Si no hay PRD → continuar con el flujo normal (input del usuario)
+
 1. **Verificar** si existe `specs/db_schema/<dominio>.dbml`
    - Si **NO existe** → Auto-generar DBML `@provisional` con campos inferidos del requerimiento
    - Si **existe y está ratificado** → Usar como referencia, agregar nuevos campos como `@provisional`

package/comandos/dc/revisar.md

@@ -31,6 +31,10 @@ Verificar:
   - [ ] Edge cases cubiertos con tests
   - [ ] Sin stubs detectados (habilidad detección-stubs)
   - [ ] Criterios de éxito de la spec cumplidos
+  - [ ] Conformidad con PRD (si existe .dc/prd/):
+        - Features Must Have implementadas
+        - Riesgos del PRD mitigados
+        - KPIs del PRD son medibles en el código
 ```
 
 ### 2. Tests y Cobertura

package/comandos/especdev/comenzar.md

@@ -43,12 +43,35 @@ Nivel = max(puntuaciones)  // Conservador: gana la dimensión más alta
 
 ## Comportamiento
 
-1. **Analizar** la descripción de la tarea
-2. **Evaluar** las 4 dimensiones (alcance, incógnitas, riesgo, duración)
-3. **Determinar** nivel de complejidad
-4. **Mostrar** evaluación al usuario
-5. **Preguntar** si está de acuerdo o desea ajustar
-6. **Iniciar** flujo del nivel correspondiente
+1. **Detectar PRD** — ¿Existe `.dc/prd/prd-*.md`? ¿El usuario proporcionó brief, Figma o docs?
+   - Si hay PRD existente → usarlo como input para las fases siguientes
+   - Si hay brief/Figma/docs pero no PRD → preguntar: "¿Quieres generar un PRD primero? (/dc:prd)"
+   - Si no hay nada → continuar sin PRD (flujo normal)
+2. **Analizar** la descripción de la tarea (o el PRD si existe)
+3. **Evaluar** las 4 dimensiones (alcance, incógnitas, riesgo, duración)
+4. **Determinar** nivel de complejidad
+5. **Mostrar** evaluación al usuario
+6. **Preguntar** si está de acuerdo o desea ajustar
+7. **Iniciar** flujo del nivel correspondiente
+
+### Flujo con PRD (niveles 2-4)
+
+```
+¿Se detectó PRD o fuentes de producto?
+  │
+  ├─ SÍ, PRD existe (.dc/prd/prd-*.md)
+  │   → Leer PRD
+  │   → Extraer user stories, prioridades, riesgos
+  │   → Alimentar /dc:especificar automáticamente
+  │
+  ├─ SÍ, hay brief/Figma pero no PRD
+  │   → "Se detectaron fuentes de producto. ¿Generar PRD? (s/n)"
+  │   → Si sí: /dc:prd → luego continúa el pipeline
+  │   → Si no: continuar sin PRD
+  │
+  └─ NO hay fuentes de producto
+      → Flujo normal (el usuario describe la tarea)
+```
 
 ## Ejemplo
 
@@ -85,9 +108,11 @@ Inspirada en el framework BMAD: el nivel de planificación se ajusta automática
 | **0 — Atómico** | implementar → verificar | spec, clarificar, planificar, desglosar |
 | **1 — Micro** | especificar (light) → implementar → revisar | clarificar, planificar, desglosar, pseudocódigo |
 | **P — PoC** | hipótesis → construir → evaluar → veredicto | todo el pipeline formal |
-| **2 — Estándar** | especificar → clarificar → planificar → desglosar → implementar → revisar | pseudocódigo (opcional) |
-| **3 — Complejo** | especificar → clarificar → pseudocódigo → planificar → diseñar → desglosar → implementar → revisar | nada se salta |
-| **4 — Producto** | constitución → proponer → especificar → clarificar → pseudocódigo → planificar → diseñar → desglosar → implementar → revisar | nada se salta |
+| **2 — Estándar** | [PRD →] especificar → clarificar → planificar → desglosar → implementar → revisar | pseudocódigo (opcional) |
+| **3 — Complejo** | [PRD →] especificar → clarificar → pseudocódigo → planificar → diseñar → desglosar → implementar → revisar | nada se salta |
+| **4 — Producto** | [PRD →] constitución → proponer → especificar → clarificar → pseudocódigo → planificar → diseñar → desglosar → implementar → revisar | nada se salta |
+
+> **[PRD]** = Fase 0 opcional. Si existe `.dc/prd/prd-*.md` o el usuario proporciona un brief/Figma, se ejecuta `/dc:prd` primero. El PRD alimenta automáticamente a `/dc:especificar` con user stories, prioridades y riesgos.
 
 **Principio:** No aplicar el mismo proceso a un micro-fix que a una migración de plataforma. La fricción innecesaria es tan dañina como la falta de estructura.
 

package/comandos/especdev/especificar.md

@@ -20,6 +20,16 @@ Convertir un requerimiento en lenguaje natural a una especificación Gherkin est
 
 ## Comportamiento
 
+0. **Detectar PRD** — Si existe `.dc/prd/prd-*.md`:
+   - Leer el PRD y extraer automáticamente:
+     - User stories (sección 6.1) → base para escenarios Gherkin
+     - Prioridades MoSCoW → mapear a P1 (Must), P2 (Should), P3+ (Could/Won't)
+     - Riesgos (sección 8) → agregar escenarios de error/edge case por riesgo
+     - Requirements no funcionales (sección 6.2) → anotar como constraints
+     - Data model DBML (sección 6.4) → usar como schema base si existe
+   - Informar al usuario: "PRD detectado — extrayendo X user stories, Y riesgos"
+   - Si no hay PRD → continuar con el flujo normal (input del usuario)
+
 1. **Verificar** si existe `specs/db_schema/<dominio>.dbml`
    - Si **NO existe** → Auto-generar DBML `@provisional` con campos inferidos del requerimiento
    - Si **existe y está ratificado** → Usar como referencia, agregar nuevos campos como `@provisional`

package/comandos/especdev/revisar.md

@@ -31,6 +31,10 @@ Verificar:
   - [ ] Edge cases cubiertos con tests
   - [ ] Sin stubs detectados (habilidad detección-stubs)
   - [ ] Criterios de éxito de la spec cumplidos
+  - [ ] Conformidad con PRD (si existe .dc/prd/):
+        - Features Must Have implementadas
+        - Riesgos del PRD mitigados
+        - KPIs del PRD son medibles en el código
 ```
 
 ### 2. Tests y Cobertura

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "don-cheli-sdd",
-  "version": "1.22.0",
+  "version": "1.23.0",
   "description": "Framework SDD para Claude Code — 72+ comandos, 43 habilidades, 15 modelos de razonamiento. TDD como ley de hierro. EN/ES/PT.",
   "main": "bin/don-cheli.js",
   "scripts": {

package/scripts/.claude/commands/dc/comenzar.md

@@ -1,5 +1,5 @@
 ---
-description: Iniciar tarea con nivel de complejidad auto-detectado (0-4)
+description: Iniciar tarea nueva SDD con complejidad auto-detectada (0-4). Usa cuando el usuario dice "quiero iniciar tarea", "empezar feature", "nueva historia", "comenzar desarrollo", "start a new task/feature/story", "iniciar un feature". Detecta si es tarea rápida (nivel 1), normal (nivel 2) o compleja (nivel 3-4) y adapta el flujo TDD. No usar para código existente.
 i18n: true
 ---
 
@@ -43,12 +43,35 @@ Nivel = max(puntuaciones)  // Conservador: gana la dimensión más alta
 
 ## Comportamiento
 
-1. **Analizar** la descripción de la tarea
-2. **Evaluar** las 4 dimensiones (alcance, incógnitas, riesgo, duración)
-3. **Determinar** nivel de complejidad
-4. **Mostrar** evaluación al usuario
-5. **Preguntar** si está de acuerdo o desea ajustar
-6. **Iniciar** flujo del nivel correspondiente
+1. **Detectar PRD** — ¿Existe `.dc/prd/prd-*.md`? ¿El usuario proporcionó brief, Figma o docs?
+   - Si hay PRD existente → usarlo como input para las fases siguientes
+   - Si hay brief/Figma/docs pero no PRD → preguntar: "¿Quieres generar un PRD primero? (/dc:prd)"
+   - Si no hay nada → continuar sin PRD (flujo normal)
+2. **Analizar** la descripción de la tarea (o el PRD si existe)
+3. **Evaluar** las 4 dimensiones (alcance, incógnitas, riesgo, duración)
+4. **Determinar** nivel de complejidad
+5. **Mostrar** evaluación al usuario
+6. **Preguntar** si está de acuerdo o desea ajustar
+7. **Iniciar** flujo del nivel correspondiente
+
+### Flujo con PRD (niveles 2-4)
+
+```
+¿Se detectó PRD o fuentes de producto?
+  │
+  ├─ SÍ, PRD existe (.dc/prd/prd-*.md)
+  │   → Leer PRD
+  │   → Extraer user stories, prioridades, riesgos
+  │   → Alimentar /dc:especificar automáticamente
+  │
+  ├─ SÍ, hay brief/Figma pero no PRD
+  │   → "Se detectaron fuentes de producto. ¿Generar PRD? (s/n)"
+  │   → Si sí: /dc:prd → luego continúa el pipeline
+  │   → Si no: continuar sin PRD
+  │
+  └─ NO hay fuentes de producto
+      → Flujo normal (el usuario describe la tarea)
+```
 
 ## Ejemplo
 
@@ -75,3 +98,33 @@ Duración:   2 (días)
 - Si durante la ejecución se detecta mayor complejidad → escalar nivel
 - Si la complejidad resulta menor → des-escalar nivel
 - Regla de Desviación 4 → escalar al menos 1 nivel
+
+## Heurística de Scale-Adaptive Planning
+
+Inspirada en el framework BMAD: el nivel de planificación se ajusta automáticamente según la complejidad detectada.
+
+| Nivel detectado | Fases que se ejecutan | Fases que se SALTAN |
+|-----------------|----------------------|---------------------|
+| **0 — Atómico** | implementar → verificar | spec, clarificar, planificar, desglosar |
+| **1 — Micro** | especificar (light) → implementar → revisar | clarificar, planificar, desglosar, pseudocódigo |
+| **P — PoC** | hipótesis → construir → evaluar → veredicto | todo el pipeline formal |
+| **2 — Estándar** | [PRD →] especificar → clarificar → planificar → desglosar → implementar → revisar | pseudocódigo (opcional) |
+| **3 — Complejo** | [PRD →] especificar → clarificar → pseudocódigo → planificar → diseñar → desglosar → implementar → revisar | nada se salta |
+| **4 — Producto** | [PRD →] constitución → proponer → especificar → clarificar → pseudocódigo → planificar → diseñar → desglosar → implementar → revisar | nada se salta |
+
+> **[PRD]** = Fase 0 opcional. Si existe `.dc/prd/prd-*.md` o el usuario proporciona un brief/Figma, se ejecuta `/dc:prd` primero. El PRD alimenta automáticamente a `/dc:especificar` con user stories, prioridades y riesgos.
+
+**Principio:** No aplicar el mismo proceso a un micro-fix que a una migración de plataforma. La fricción innecesaria es tan dañina como la falta de estructura.
+
+### Señales de detección automática
+
+| Señal | Sube nivel | Baja nivel |
+|-------|-----------|------------|
+| Archivos afectados > 10 | +1 | |
+| Archivos afectados ≤ 2 | | -1 |
+| Cambio cruza módulos | +1 | |
+| Solo 1 módulo | | -1 |
+| Toca auth/pagos/seguridad | +1 | |
+| Solo wording/config | | -1 |
+| Dependencias externas nuevas | +1 | |
+| Sin dependencias nuevas | | 0 |

package/scripts/.claude/commands/dc/especificar.md

@@ -1,5 +1,5 @@
 ---
-description: Crear especificación Gherkin desde un requerimiento con schema DBML auto-generado
+description: Crear especificaciones Gherkin desde un requerimiento/requisito. Usa cuando el usuario dice "escribir specs", "especificar feature", "crear Gherkin", "escribir requerimientos", "write specs", "requirements to Gherkin", "escribir scenarios", "documentar feature en Gherkin". Genera DBML schema auto-máticamente para persistence. Incluye validación contra el schema IEEE 29148.
 i18n: true
 ---
 
@@ -20,6 +20,16 @@ Convertir un requerimiento en lenguaje natural a una especificación Gherkin est
 
 ## Comportamiento
 
+0. **Detectar PRD** — Si existe `.dc/prd/prd-*.md`:
+   - Leer el PRD y extraer automáticamente:
+     - User stories (sección 6.1) → base para escenarios Gherkin
+     - Prioridades MoSCoW → mapear a P1 (Must), P2 (Should), P3+ (Could/Won't)
+     - Riesgos (sección 8) → agregar escenarios de error/edge case por riesgo
+     - Requirements no funcionales (sección 6.2) → anotar como constraints
+     - Data model DBML (sección 6.4) → usar como schema base si existe
+   - Informar al usuario: "PRD detectado — extrayendo X user stories, Y riesgos"
+   - Si no hay PRD → continuar con el flujo normal (input del usuario)
+
 1. **Verificar** si existe `specs/db_schema/<dominio>.dbml`
    - Si **NO existe** → Auto-generar DBML `@provisional` con campos inferidos del requerimiento
    - Si **existe y está ratificado** → Usar como referencia, agregar nuevos campos como `@provisional`

package/scripts/.claude/commands/dc/revisar.md

@@ -1,5 +1,5 @@
 ---
-description: Peer review estricto con análisis de rendimiento, arquitectura, seguridad y cumplimiento
+description: Peer review estricto de código con análisis de rendimiento, arquitectura, seguridad y cumplimiento. Usa cuando el usuario dice "revisar código", "code review", "peer review", "revisame este archivo", "review my code", "analizar código", "revisar PR", "revisar feature". Incluye análisis de performance, security OWASP, architecture smells y compliance con specs.
 i18n: true
 ---
 
@@ -31,6 +31,10 @@ Verificar:
   - [ ] Edge cases cubiertos con tests
   - [ ] Sin stubs detectados (habilidad detección-stubs)
   - [ ] Criterios de éxito de la spec cumplidos
+  - [ ] Conformidad con PRD (si existe .dc/prd/):
+        - Features Must Have implementadas
+        - Riesgos del PRD mitigados
+        - KPIs del PRD son medibles en el código
 ```
 
 ### 2. Tests y Cobertura
@@ -219,3 +223,13 @@ for user in users:
 - **Nunca** ignorar hallazgos de seguridad
 - **Siempre** verificar cumplimiento de constitución
 - **Siempre** documentar hallazgos con archivo + línea + sugerencia
+
+## Regla Adversarial
+
+Inspirada en el framework BMAD: el reviewer DEBE encontrar al menos un hallazgo concreto en cada revisión.
+
+- Si el review produce **cero hallazgos**, se activa una segunda pasada obligatoria con instrucción explícita: "Re-analizar buscando específicamente: N+1 queries, race conditions, edge cases no testeados, datos sensibles en logs, y naming inconsistencies."
+- Si la segunda pasada también produce cero hallazgos, se debe incluir una justificación explícita de por qué el código es excepcionalmente limpio.
+- **Nunca** aprobar con "todo se ve bien" sin evidencia de análisis profundo.
+
+Esto combate la tendencia natural del LLM a aprobar trabajo propio sin challenge suficiente.

package/scripts/.claude/commands/especdev/comenzar.md

@@ -1,5 +1,5 @@
 ---
-description: Iniciar tarea con nivel de complejidad auto-detectado (0-4)
+description: Iniciar tarea nueva SDD con complejidad auto-detectada (0-4). Usa cuando el usuario dice "quiero iniciar tarea", "empezar feature", "nueva historia", "comenzar desarrollo", "start a new task/feature/story", "iniciar un feature". Detecta si es tarea rápida (nivel 1), normal (nivel 2) o compleja (nivel 3-4) y adapta el flujo TDD. No usar para código existente.
 i18n: true
 ---
 
@@ -43,12 +43,35 @@ Nivel = max(puntuaciones)  // Conservador: gana la dimensión más alta
 
 ## Comportamiento
 
-1. **Analizar** la descripción de la tarea
-2. **Evaluar** las 4 dimensiones (alcance, incógnitas, riesgo, duración)
-3. **Determinar** nivel de complejidad
-4. **Mostrar** evaluación al usuario
-5. **Preguntar** si está de acuerdo o desea ajustar
-6. **Iniciar** flujo del nivel correspondiente
+1. **Detectar PRD** — ¿Existe `.dc/prd/prd-*.md`? ¿El usuario proporcionó brief, Figma o docs?
+   - Si hay PRD existente → usarlo como input para las fases siguientes
+   - Si hay brief/Figma/docs pero no PRD → preguntar: "¿Quieres generar un PRD primero? (/dc:prd)"
+   - Si no hay nada → continuar sin PRD (flujo normal)
+2. **Analizar** la descripción de la tarea (o el PRD si existe)
+3. **Evaluar** las 4 dimensiones (alcance, incógnitas, riesgo, duración)
+4. **Determinar** nivel de complejidad
+5. **Mostrar** evaluación al usuario
+6. **Preguntar** si está de acuerdo o desea ajustar
+7. **Iniciar** flujo del nivel correspondiente
+
+### Flujo con PRD (niveles 2-4)
+
+```
+¿Se detectó PRD o fuentes de producto?
+  │
+  ├─ SÍ, PRD existe (.dc/prd/prd-*.md)
+  │   → Leer PRD
+  │   → Extraer user stories, prioridades, riesgos
+  │   → Alimentar /dc:especificar automáticamente
+  │
+  ├─ SÍ, hay brief/Figma pero no PRD
+  │   → "Se detectaron fuentes de producto. ¿Generar PRD? (s/n)"
+  │   → Si sí: /dc:prd → luego continúa el pipeline
+  │   → Si no: continuar sin PRD
+  │
+  └─ NO hay fuentes de producto
+      → Flujo normal (el usuario describe la tarea)
+```
 
 ## Ejemplo
 
@@ -75,3 +98,33 @@ Duración:   2 (días)
 - Si durante la ejecución se detecta mayor complejidad → escalar nivel
 - Si la complejidad resulta menor → des-escalar nivel
 - Regla de Desviación 4 → escalar al menos 1 nivel
+
+## Heurística de Scale-Adaptive Planning
+
+Inspirada en el framework BMAD: el nivel de planificación se ajusta automáticamente según la complejidad detectada.
+
+| Nivel detectado | Fases que se ejecutan | Fases que se SALTAN |
+|-----------------|----------------------|---------------------|
+| **0 — Atómico** | implementar → verificar | spec, clarificar, planificar, desglosar |
+| **1 — Micro** | especificar (light) → implementar → revisar | clarificar, planificar, desglosar, pseudocódigo |
+| **P — PoC** | hipótesis → construir → evaluar → veredicto | todo el pipeline formal |
+| **2 — Estándar** | [PRD →] especificar → clarificar → planificar → desglosar → implementar → revisar | pseudocódigo (opcional) |
+| **3 — Complejo** | [PRD →] especificar → clarificar → pseudocódigo → planificar → diseñar → desglosar → implementar → revisar | nada se salta |
+| **4 — Producto** | [PRD →] constitución → proponer → especificar → clarificar → pseudocódigo → planificar → diseñar → desglosar → implementar → revisar | nada se salta |
+
+> **[PRD]** = Fase 0 opcional. Si existe `.dc/prd/prd-*.md` o el usuario proporciona un brief/Figma, se ejecuta `/dc:prd` primero. El PRD alimenta automáticamente a `/dc:especificar` con user stories, prioridades y riesgos.
+
+**Principio:** No aplicar el mismo proceso a un micro-fix que a una migración de plataforma. La fricción innecesaria es tan dañina como la falta de estructura.
+
+### Señales de detección automática
+
+| Señal | Sube nivel | Baja nivel |
+|-------|-----------|------------|
+| Archivos afectados > 10 | +1 | |
+| Archivos afectados ≤ 2 | | -1 |
+| Cambio cruza módulos | +1 | |
+| Solo 1 módulo | | -1 |
+| Toca auth/pagos/seguridad | +1 | |
+| Solo wording/config | | -1 |
+| Dependencias externas nuevas | +1 | |
+| Sin dependencias nuevas | | 0 |

package/scripts/.claude/commands/especdev/especificar.md

@@ -1,5 +1,5 @@
 ---
-description: Crear especificación Gherkin desde un requerimiento con schema DBML auto-generado
+description: Crear especificaciones Gherkin desde un requerimiento/requisito. Usa cuando el usuario dice "escribir specs", "especificar feature", "crear Gherkin", "escribir requerimientos", "write specs", "requirements to Gherkin", "escribir scenarios", "documentar feature en Gherkin". Genera DBML schema auto-máticamente para persistence. Incluye validación contra el schema IEEE 29148.
 i18n: true
 ---
 
@@ -20,6 +20,16 @@ Convertir un requerimiento en lenguaje natural a una especificación Gherkin est
 
 ## Comportamiento
 
+0. **Detectar PRD** — Si existe `.dc/prd/prd-*.md`:
+   - Leer el PRD y extraer automáticamente:
+     - User stories (sección 6.1) → base para escenarios Gherkin
+     - Prioridades MoSCoW → mapear a P1 (Must), P2 (Should), P3+ (Could/Won't)
+     - Riesgos (sección 8) → agregar escenarios de error/edge case por riesgo
+     - Requirements no funcionales (sección 6.2) → anotar como constraints
+     - Data model DBML (sección 6.4) → usar como schema base si existe
+   - Informar al usuario: "PRD detectado — extrayendo X user stories, Y riesgos"
+   - Si no hay PRD → continuar con el flujo normal (input del usuario)
+
 1. **Verificar** si existe `specs/db_schema/<dominio>.dbml`
    - Si **NO existe** → Auto-generar DBML `@provisional` con campos inferidos del requerimiento
    - Si **existe y está ratificado** → Usar como referencia, agregar nuevos campos como `@provisional`

package/scripts/.claude/commands/especdev/revisar.md

@@ -1,5 +1,5 @@
 ---
-description: Peer review estricto con análisis de rendimiento, arquitectura, seguridad y cumplimiento
+description: Peer review estricto de código con análisis de rendimiento, arquitectura, seguridad y cumplimiento. Usa cuando el usuario dice "revisar código", "code review", "peer review", "revisame este archivo", "review my code", "analizar código", "revisar PR", "revisar feature". Incluye análisis de performance, security OWASP, architecture smells y compliance con specs.
 i18n: true
 ---
 
@@ -31,6 +31,10 @@ Verificar:
   - [ ] Edge cases cubiertos con tests
   - [ ] Sin stubs detectados (habilidad detección-stubs)
   - [ ] Criterios de éxito de la spec cumplidos
+  - [ ] Conformidad con PRD (si existe .dc/prd/):
+        - Features Must Have implementadas
+        - Riesgos del PRD mitigados
+        - KPIs del PRD son medibles en el código
 ```
 
 ### 2. Tests y Cobertura
@@ -219,3 +223,13 @@ for user in users:
 - **Nunca** ignorar hallazgos de seguridad
 - **Siempre** verificar cumplimiento de constitución
 - **Siempre** documentar hallazgos con archivo + línea + sugerencia
+
+## Regla Adversarial
+
+Inspirada en el framework BMAD: el reviewer DEBE encontrar al menos un hallazgo concreto en cada revisión.
+
+- Si el review produce **cero hallazgos**, se activa una segunda pasada obligatoria con instrucción explícita: "Re-analizar buscando específicamente: N+1 queries, race conditions, edge cases no testeados, datos sensibles en logs, y naming inconsistencies."
+- Si la segunda pasada también produce cero hallazgos, se debe incluir una justificación explícita de por qué el código es excepcionalmente limpio.
+- **Nunca** aprobar con "todo se ve bien" sin evidencia de análisis profundo.
+
+Esto combate la tendencia natural del LLM a aprobar trabajo propio sin challenge suficiente.

package/scripts/.claude/don-cheli/VERSION

@@ -1 +1 @@
-1.22.0
+1.23.0

package/scripts/.claude/don-cheli/scripts/instalar.sh

@@ -4,7 +4,7 @@
 
 set -euo pipefail
 
-VERSION="1.22.0"
+VERSION="1.23.0"
 REPO_URL="https://github.com/doncheli/don-cheli-sdd"
 CLEANUP_TMPDIR=""
 

package/scripts/generar-config.sh

@@ -241,7 +241,7 @@ _gen_continue() {
         cat > "$dir/.continue/config/don-cheli.json" 2>/dev/null << 'CONTEOF' || true
 {
   "name": "don-cheli-sdd",
-  "version": "1.22.0",
+  "version": "1.23.0",
   "description": "Don Cheli SDD Framework",
   "rules": [
     "All production code requires tests (TDD: RED → GREEN → REFACTOR)",

package/scripts/instalar.sh

@@ -4,7 +4,7 @@
 
 set -euo pipefail
 
-VERSION="1.22.0"
+VERSION="1.23.0"
 REPO_URL="https://github.com/doncheli/don-cheli-sdd"
 CLEANUP_TMPDIR=""