don-cheli-sdd 1.13.0

package/scripts/.claude/commands/razonar/segundo-orden.md

@@ -0,0 +1,35 @@
+---
+description: Pensar en las consecuencias de las consecuencias. Ir más allá del efecto inmediato.
+i18n: true
+---
+
+# /razonar:segundo-orden
+
+Pensar en las consecuencias de las consecuencias. Ir más allá del efecto inmediato.
+
+## Uso
+
+```
+/razonar:segundo-orden [decisión]
+```
+
+## Proceso
+
+1. **Decisión**: ¿Qué estamos considerando?
+2. **Primer orden**: ¿Qué pasa inmediatamente?
+3. **Segundo orden**: ¿Qué pasa como resultado de eso?
+4. **Tercer orden**: ¿Y después de eso?
+5. **Evaluación**: ¿Los efectos a largo plazo son aceptables?
+
+## Ejemplo
+
+```
+/razonar:segundo-orden "Agregar caché agresivo para mejorar rendimiento"
+
+1er orden: ✅ Respuestas 10x más rápidas
+2do orden: ⚠️ Datos desactualizados para usuarios
+3er orden: ❌ Usuarios toman decisiones con info vieja
+           ❌ Soporte recibe quejas de inconsistencia
+
+→ Decisión: Caché con TTL corto + invalidación selectiva
+```

package/scripts/.claude/don-cheli/AGENTS.md

@@ -0,0 +1,20 @@
+# Don Cheli — Instrucciones para Codex
+
+## Identidad
+
+Eres un asistente de desarrollo que opera bajo el framework Don Cheli (Desarrollo Dirigido por Especificaciones).
+
+## Contexto
+
+Lee los archivos en `.especdev/` para entender el estado del proyecto.
+
+## Reglas
+
+1. Todo código requiere tests (TDD)
+2. Primero causa raíz, luego corrección
+3. Evidencia antes de afirmaciones
+4. Todo output en español
+
+## Comandos
+
+Ejecuta comandos desde `comandos/` siguiendo las instrucciones de cada archivo.

package/scripts/.claude/don-cheli/CLAUDE.md

@@ -0,0 +1,114 @@
+# Don Cheli — Instrucciones para Claude Code
+
+## Identidad
+
+Eres un asistente de desarrollo que opera bajo el framework Don Cheli (Desarrollo Dirigido por Especificaciones). Todo tu trabajo sigue las 7 fases del ciclo de vida y las leyes de hierro del framework.
+
+## Archivos de Contexto
+
+Al iniciar, lee estos archivos en orden:
+1. `.especdev/config.yaml` — Configuración del proyecto
+2. `.especdev/estado.md` — Estado actual
+3. `.especdev/plan.md` — Plan y fases
+4. `.especdev/hallazgos.md` — Descubrimientos
+5. `.especdev/progreso.md` — Log de sesión
+
+Si el repo tiene un `docs/index.md`, consultarlo como mapa de navegación.
+
+## Leyes de Hierro (No Negociable)
+
+1. **TDD:** Todo código de producción requiere tests
+2. **Debugging:** Primero la causa raíz, luego la corrección
+3. **Verificación:** Evidencia antes de afirmaciones
+
+## Reglas de Desviación
+
+- Regla 1-3: Auto-corregir (bugs, faltantes, bloqueadores)
+- Regla 4: PARAR y preguntar (cambios arquitectónicos)
+- Regla 5: Registrar y continuar (mejoras)
+
+## Reglas de Trabajo Globales
+
+Lee `reglas/reglas-trabajo-globales.md` para reglas de:
+- Idioma (código en inglés, commits/docs en español)
+- Branches (`feature/`, `fix/`, `hotfix/`)
+- Commits (`<type>: <descripción>`)
+- PRs (un cambio lógico, coverage ≥85%)
+- Documentación obligatoria por tipo de PR
+- Verificaciones de calidad (lint, tests, build)
+- Límites de autonomía (>10 archivos → confirmar)
+
+## Selección de Modelos (Optimización de Tokens)
+
+| Tarea | Modelo |
+|-------|--------|
+| Q&A, formateo, scripting, batch | `haiku` |
+| Código, tests, code review | `sonnet` |
+| Arquitectura, seguridad, razonamiento complejo | `opus` |
+
+**Default: Haiku.** Subir solo si la calidad es insuficiente.
+**Nunca usar Opus sin confirmación del usuario.**
+Subtareas independientes → subagentes en paralelo.
+
+Lee `habilidades/optimizacion-tokens/HABILIDAD.md` para la guía completa.
+
+## Comandos Disponibles
+
+**Prefijo corto:** `/dc:*` (alias de `/especdev:*` — ambos funcionan)
+
+- `/dc:*` o `/especdev:*` — Comandos del framework (iniciar, comenzar, estimar, presentar, etc.)
+- `/dc:planning` — Planning semanal de equipo con RFCs, priorización WSJF y asignación
+- `/dc:mesa-tecnica` — Mesa de expertos senior de desarrollo
+- `/dc:analizar-sesiones` — Analizar patrones de uso y generar recomendaciones
+- `/dc:destilar` — Extraer specs compactas desde código existente (Blueprint Distillation)
+- `/dc:minar-referencias` — Buscar repos open-source relevantes como referencia
+- `/dc:contrato-ui` — Bloquear estándares visuales antes de codear frontend
+- `/dc:poc` — Prueba de Concepto con timebox y veredicto (reglas relajadas)
+- `/dc:contrato-api` — Diseñar contratos de API, webhooks e integraciones
+- `/dc:auditar-seguridad` — Auditoría de seguridad estática (OWASP Top 10)
+- `/dc:migrar` — Migración entre stacks tecnológicos o versiones mayores
+- `/dc:actualizar` — Detectar y aplicar actualizaciones del framework
+- `/razonar:*` — 12 modelos de razonamiento + 3 modelos RLM (PrimeIntellect)
+- `/bucle` — Bucle autónomo
+- `/historias-generar` — Generar prd.json
+
+## Verificación de Actualizaciones (Auto-check)
+
+Al inicio de la **primera interacción** de cada sesión, verificar silenciosamente si hay actualizaciones disponibles:
+
+1. Leer `${FRAMEWORK_HOME}/VERSION` para obtener la versión instalada
+2. Obtener la versión remota: `curl -s https://raw.githubusercontent.com/doncheli/don-cheli-sdd/main/VERSION`
+3. Si la versión remota es mayor, notificar al usuario con un mensaje breve:
+
+**Formato de notificación (según idioma configurado):**
+
+- **es:** `⬆️ Don Cheli v{remota} disponible (instalada: v{local}). Ejecuta /dc:actualizar para actualizar.`
+- **en:** `⬆️ Don Cheli v{remote} available (installed: v{local}). Run /dc:update to upgrade.`
+- **pt:** `⬆️ Don Cheli v{remota} disponível (instalada: v{local}). Execute /dc:atualizar para atualizar.`
+
+**Reglas:**
+- Solo notificar **una vez por sesión** (no repetir en cada mensaje)
+- Si no hay conexión o falla el curl, continuar sin notificar (no bloquear)
+- Si las versiones son iguales, no mostrar nada
+- Usar el nombre del comando en el idioma configurado (`/dc:actualizar`, `/dc:update`, `/dc:atualizar`)
+
+## Gestión de Contexto
+
+- Leer archivos **bajo demanda**, no preventivamente.
+- No re-leer lo que ya está en contexto — referenciar.
+- Si un resultado supera ~10K tokens → aislarlo en subagente.
+- System prompts < 500 tokens.
+- Outputs estructurados desde el inicio (JSON, tablas).
+
+## Idioma (i18n)
+
+El framework soporta 3 idiomas: **español (es)**, **English (en)**, **Português (pt)**.
+
+**Detección de idioma (en orden):**
+1. Leer `${FRAMEWORK_HOME}/locale` (archivo de 2 letras: `es`, `en` o `pt`)
+2. Leer `.especdev/config.yaml` → `framework.idioma`
+3. Default: `es`
+
+**Regla:** Toda comunicación, documentación, commits y output del framework debe ser en el idioma configurado. Código (variables, funciones) **siempre en inglés**.
+
+Lee `reglas/i18n.md` para la guía completa de internacionalización.

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

@@ -0,0 +1,17 @@
+Don Cheli — SDD Framework
+Copyright 2026 Jose Luis Oronoz Troconis (@DonCheli)
+
+Este producto incluye software desarrollado por Jose Luis Oronoz Troconis (@DonCheli).
+
+Inspirado y adaptado de:
+- ArtChiTech (ciclo de vida 7 fases, razonamiento, hooks, agentes)
+- BMO (bucle de contexto fresco, PRD-creator, soporte multi-LLM)
+- Specular (pipeline Gherkin, BDD/TDD, artefactos trazables, constitución)
+- DeepCode / HKUDS (CodeRAG, Blueprint Distillation, detección de loops)
+- Get Shit Done / gsd-build (Nyquist validation, stub detection, UI contracts, checkpoints)
+- spec-kit / GitHub (prioridades P1/P2/P3+, constitution check, complexity tracking)
+- superpowers / obra (brainstorming estructurado, git worktrees)
+- ui-ux-pro-max / nextlevelbuilder (design system multi-dominio)
+- LightRAG / HKUDS (retrieval dual-level con grafo de entidades)
+- obsidian-skills / kepano (markdown Obsidian-flavored, JSON canvas)
+- frontend-slides / zarazhangrui (presentaciones HTML interactivas)

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

@@ -0,0 +1 @@
+1.8.0

package/scripts/.claude/don-cheli/agentes/README.md

@@ -0,0 +1,28 @@
+# Sistema de Agentes Don Cheli
+
+## Agentes Disponibles
+
+| Agente | Modelo | Rol | Costo |
+|--------|--------|-----|-------|
+| `planificador` | opus | Planificación, descomposición | $$$ |
+| `arquitecto` | opus | Diseño de sistemas | $$$ |
+| `ejecutor` | sonnet | Implementación | $$ |
+| `revisor` | opus | Revisión de código | $$$ |
+| `tester` | sonnet | Tests | $$ |
+| `documentador` | haiku | Documentación | $ |
+| `estimador` | opus | Estimados de desarrollo | $$$ |
+
+## Flujo de Trabajo
+
+```
+Modo Completo: planificador → arquitecto → ejecutor ↔ tester → revisor → documentador
+Modo Rápido:   ejecutor → tester → documentador
+```
+
+## Estrategia de Costos
+
+```
+Opus   = PIENSA y DECIDE  ($$$ - para decisiones críticas)
+Sonnet = EJECUTA           ($$ - para implementación)
+Haiku  = LEE y DOCUMENTA   ($ - para tareas simples)
+```

package/scripts/.claude/don-cheli/agentes/prompts/estimador.md

@@ -0,0 +1,29 @@
+# Agente: Estimador
+
+**Modelo:** opus
+**Rol:** Generación de estimados de desarrollo
+
+## Instrucciones
+
+Eres un agente estimador. Tu rol es generar estimados de desarrollo precisos y profesionales.
+
+## Comportamiento
+
+1. Analizar el input (PRD, feature o tarea)
+2. Identificar componentes estimables
+3. Aplicar los 4 modelos de estimación:
+   - Puntos de Función
+   - Planning Poker IA
+   - COCOMO Simplificado
+   - Histórico
+4. Calcular consenso y rango optimista/esperado/pesimista
+5. Identificar riesgos que afectan la estimación
+6. Generar documento de estimado usando la plantilla
+
+## Reglas
+
+- Nunca dar un número exacto sin rango
+- Siempre incluir supuestos
+- Siempre identificar al menos 2 riesgos
+- Si no hay datos históricos, indicar "N/A"
+- Expresar confianza como porcentaje

package/scripts/.claude/don-cheli/folder-map.json

@@ -0,0 +1,19 @@
+{
+  "locale": "es",
+  "dirs": {
+    "skills": "habilidades",
+    "rules": "reglas",
+    "templates": "plantillas",
+    "hooks": "ganchos",
+    "agents": "agentes",
+    "scripts": "scripts"
+  },
+  "files": {
+    "status": "estado.md",
+    "findings": "hallazgos.md",
+    "plan": "plan.md",
+    "progress": "progreso.md",
+    "proposal": "propuesta.md",
+    "config": "config.yaml"
+  }
+}

package/scripts/.claude/don-cheli/ganchos/parar.md

@@ -0,0 +1,10 @@
+# Hook: Parar
+
+**Disparador:** Antes de completar/terminar una tarea
+
+## Comportamiento
+
+1. Verificar que todas las fases tienen evidencia
+2. Verificar que tests pasan
+3. Verificar que `.especdev/progreso.md` está actualizado
+4. Si falta evidencia → no permitir completar

package/scripts/.claude/don-cheli/ganchos/post-herramienta.md

@@ -0,0 +1,9 @@
+# Hook: Post-Herramienta
+
+**Disparador:** Después de cualquier acción de escritura/edición
+
+## Comportamiento
+
+1. Actualizar `.especdev/progreso.md` con la acción realizada
+2. Registrar archivos modificados
+3. Verificar que el progreso está alineado con el plan

package/scripts/.claude/don-cheli/ganchos/pre-herramienta.md

@@ -0,0 +1,19 @@
+# Hook: Pre-Herramienta
+
+**Disparador:** Antes de cualquier acción de escritura/edición/bash
+
+## Comportamiento
+
+1. Leer `.especdev/plan.md` para refrescar metas actuales
+2. Verificar que la acción está alineada con el plan
+3. Si hay archivos adicionales configurados, leerlos también
+
+## Configuración
+
+```json
+{
+  "disparador": "preHerramienta",
+  "archivos": [".especdev/plan.md", ".especdev/estado.md"],
+  "archivosAdicionales": []
+}
+```

package/scripts/.claude/don-cheli/habilidades/arnes-agente/HABILIDAD.md

@@ -0,0 +1,155 @@
+# Habilidad: Arnés del Agente (Agent Harness)
+
+**Versión:** 1.0.0
+**Categoría:** Configuración
+**Tipo:** Rígida
+
+> Basado en las prácticas de MELI para 20,000 developers y GitHub Spec Kit.
+
+## Cómo Mejora el Framework
+
+El "arnés del agente" es el conjunto de configuraciones que controla el comportamiento de la IA. Sin un arnés bien diseñado, el agente pierde efectividad a medida que el contexto crece.
+
+### El Problema: Context Rot
+
+> La precisión del agente cae cuando la ventana de contexto supera ~60% de utilización.
+> — Julian de Angelis, MELI
+
+Un CLAUDE.md monolítico de 2,000 líneas **contamina** el contexto. La solución de MELI: **reglas modulares**.
+
+## Las 4 Palancas del Arnés
+
+### 1. Reglas Modulares (Custom Rules)
+
+En vez de un archivo gigante, divide las reglas por concern:
+
+```
+.especdev/
+├── reglas/
+│   ├── arquitectura.md     # Patrones, capas, inyección de deps
+│   ├── testing.md          # Cobertura, mocking, fixtures
+│   ├── seguridad.md        # .env, secrets, OWASP
+│   ├── ui.md               # Componentes, estilos, accesibilidad
+│   ├── bd.md               # Queries, migraciones, transacciones
+│   └── api.md              # REST, versionado, paginación
+```
+
+**Regla de oro:** Cada archivo de reglas < **500 líneas**.
+
+El framework carga SOLO las reglas relevantes para la tarea actual:
+- Si trabajas en UI → carga `ui.md` + `testing.md`
+- Si trabajas en BD → carga `bd.md` + `seguridad.md`
+- Si trabajas en API → carga `api.md` + `testing.md` + `seguridad.md`
+
+### 2. Servidores MCP
+
+Puente entre conocimiento organizacional y el agente:
+- Schemas de BD → via MCP, no pegados en el prompt
+- Docs internos → via MCP, no copy-paste
+- APIs internas → contratos via MCP
+
+### 3. Skills Bajo Demanda
+
+Habilidades que se cargan SOLO cuando son relevantes:
+- No cargar TODAS las habilidades al inicio
+- Usar subagentes aislados para tareas pesadas
+- El contexto principal se mantiene limpio
+
+### 4. Stop Hooks (Verificaciones de Parada)
+
+Puertas de validación automáticas que DEBEN pasar antes de que el agente pueda marcar una tarea como "completa":
+
+```yaml
+# .especdev/hooks/parar.yml
+hooks_parar:
+  - nombre: "Lint"
+    comando: "npm run lint"
+    obligatorio: true
+    
+  - nombre: "Type Check"
+    comando: "npx tsc --noEmit"
+    obligatorio: true
+    
+  - nombre: "Tests"
+    comando: "npm test"
+    obligatorio: true
+    
+  - nombre: "Coverage"
+    comando: "npm run coverage"
+    umbral: 85
+    obligatorio: false
+    
+  - nombre: "Build"
+    comando: "npm run build"
+    obligatorio: true
+```
+
+**Flujo:**
+```
+Implementar → ¿Todos los stop hooks pasan?
+├── ✅ SÍ → Tarea marcada como completa
+└── ❌ NO → Tarea BLOQUEADA, mostrar qué falló
+```
+
+## Niveles de Madurez de Specs
+
+MELI define 3 niveles de madurez en el uso de specs:
+
+### Nivel 1: Spec-First (Básico)
+- La spec se escribe como input
+- Se descarta después de implementar
+- El código es la única fuente de verdad
+- **⚠️ Problema:** La spec se desincroniza
+
+### Nivel 2: Spec-Anchored (Intermedio) ← **Recomendado**
+- La spec vive en el repositorio
+- Se actualiza cuando el código cambia
+- Es documentación viva
+- **✅ Beneficio:** Spec y código siempre alineados
+
+### Nivel 3: Spec-as-Source (Avanzado)
+- La spec ES la fuente primaria
+- Editar la spec regenera el código
+- La spec es ejecutable
+- **🚀 Beneficio:** Cambios desde la spec, no el código
+
+### Cómo Alcanzar Cada Nivel en Don Cheli
+
+| Nivel | Comando | Acción |
+|-------|---------|--------|
+| 1 | `/especdev:especificar` → `/especdev:implementar` | Spec → código (spec se archiva) |
+| 2 | Agregar regla en hooks/parar.yml | Verificar que spec se actualiza con cada cambio |
+| 3 | `/especdev:implementar --desde-spec` | Re-generar código desde spec actualizada |
+
+## Prevención de Context Rot
+
+### Regla del 60%
+
+> Si la ventana de contexto está >60% llena, la precisión cae significativamente.
+
+**Estrategias de prevención:**
+
+1. **Cargar reglas bajo demanda** — No todo de golpe
+2. **Subagentes para tareas pesadas** — Mantener contexto principal limpio
+3. **System prompts < 500 tokens** — Conciso y enfocado
+4. **Outputs estructurados** — JSON/tablas desde el inicio
+5. **No re-leer archivos en contexto** — Referenciar, no duplicar
+
+## Integración con Don Cheli
+
+```yaml
+# .especdev/config.yaml
+arnes:
+  reglas_modulares: true
+  max_lineas_por_regla: 500
+  hooks_parar:
+    - lint
+    - tests
+    - types
+    - build
+  nivel_madurez: 2  # spec-anchored
+  prevencion_context_rot:
+    umbral_contexto: 60
+    subagentes_para_tareas_pesadas: true
+    carga_bajo_demanda: true
+```

package/scripts/.claude/don-cheli/habilidades/auto-correccion/HABILIDAD.md

@@ -0,0 +1,105 @@
+# Habilidad: Bucle de Auto-Corrección
+
+**Versión:** 1.0.0
+**Categoría:** Aprendizaje
+**Tipo:** Rígida
+
+> Adaptado de `learn-rule` de Pro-Workflow — "Las correcciones se acumulan."
+
+## Cómo Mejora el Framework
+
+> "Después de 50 sesiones, el agente casi no necesita corrección."
+> — Pro-Workflow
+
+Cada error del agente se convierte en una **regla persistente** que previene futuros errores. Las correcciones se acumulan multiplicativamente.
+
+## El Concepto
+
+```
+Sesión 1: Agente comete 10 errores
+Sesión 2: 8 errores (2 ya son reglas)
+Sesión 5: 4 errores
+Sesión 10: 2 errores
+Sesión 50: ~0 errores — el agente aprendió
+```
+
+## Formato de Regla
+
+```
+[APRENDER] Categoría: Regla de una línea
+Error: Qué salió mal
+Corrección: Cómo se corrigió
+```
+
+### Ejemplo Real
+
+```
+[APRENDER] Navegación: Confirmar ruta completa cuando hay archivos con nombre igual.
+Error: Editó src/utils.ts en vez de src/auth/utils.ts
+Corrección: Siempre verificar la ruta absoluta antes de editar
+```
+
+## Categorías
+
+| Categoría | Ejemplos |
+|-----------|----------|
+| **Navegación** | Rutas incorrectas, archivo equivocado |
+| **Edición** | Enfoque erróneo, patrón incorrecto |
+| **Testing** | Cobertura faltante, tests frágiles |
+| **Git** | Commits, branches, conflictos |
+| **Calidad** | Lint, tipos, estilo |
+| **Contexto** | Requisitos faltantes, ambigüedad |
+| **Arquitectura** | Abstracción incorrecta, acoplamiento |
+| **Performance** | O(n²), memoria, queries N+1 |
+
+## Activación
+
+El agente detecta automáticamente cuándo aprender:
+- Usuario dice "recuerda esto", "no hagas eso", "aprende de esto"
+- Se identifica un error y su corrección
+- El wrap-up captura learnings
+
+### Flujo
+
+```
+1. Detectar error o corrección
+2. Formatear como regla de una línea
+3. PROPONER al usuario (nunca auto-guardar)
+4. Si aprueba → persistir en memoria
+5. Próxima sesión → cargar reglas
+```
+
+## Almacenamiento
+
+Las reglas se guardan en `.especdev/memoria/aprendizajes.md`:
+
+```markdown
+# Aprendizajes Acumulados
+
+## Navegación (3 reglas)
+- Confirmar ruta completa cuando hay archivos con nombre igual
+- Usar `find` antes de editar archivos en monorepos
+- Las rutas de tests siguen la misma estructura que src/
+
+## Testing (2 reglas)
+- Siempre mockear servicios externos en unit tests
+- No usar `any` en mocks — define tipos parciales
+
+## Arquitectura (1 regla)
+- Servicios de pago van en su propio módulo, no en utils/
+```
+
+## Búsqueda de Reglas
+
+```
+/especdev:buscar-regla testing           # Reglas de testing
+/especdev:buscar-regla "rutas archivos"  # Búsqueda exacta
+/especdev:buscar-regla --todas           # Listar todas
+```
+
+## Guardrails
+
+- **Siempre esperar aprobación** — No auto-guardar
+- **Una línea, específica y accionable** — No "escribir buen código"
+- **Incluir contexto del error** — Para que la regla tenga sentido después
+- **Evitar duplicados** — Verificar si ya existe una regla similar

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

@@ -0,0 +1,79 @@
+# Habilidad: Brainstorming Estructurado
+
+**Versión:** 1.0.0
+**Categoría:** Descubrimiento
+**Tipo:** Flexible
+
+> Adaptado de [superpowers](https://github.com/obra/superpowers) — Ideación visual con companion.
+
+## Propósito
+
+Sesión de ideación estructurada con descubrimiento visual. En vez de preguntas abstractas, se muestran opciones concretas para que el usuario elija.
+
+## Principio
+
+> "Show, don't tell" — Mostrar 3 opciones concretas en vez de hacer preguntas abiertas.
+
+## Flujo (4 fases)
+
+### Fase 1: Encuadre (2 min)
+
+```
+¿Qué problema resolvemos?
+¿Para quién?
+¿Qué restricciones existen?
+```
+
+### Fase 2: Divergencia (10 min)
+
+Generar ideas sin filtrar:
+- Mínimo 5 ideas por ronda
+- Sin juicio ni evaluación
+- Combinar ideas libremente
+- Provocar con inversión ("¿qué pasa si hacemos lo contrario?")
+
+### Fase 3: Convergencia (5 min)
+
+Evaluar cada idea en 3 dimensiones:
+
+| Dimensión | Pregunta |
+|-----------|----------|
+| **Viabilidad** | ¿Se puede construir con los recursos actuales? |
+| **Impacto** | ¿Resuelve el problema central? |
+| **Riesgo** | ¿Qué puede salir mal? |
+
+### Fase 4: Decisión (3 min)
+
+Presentar las top 3 ideas con:
+- Nombre descriptivo
+- 1 oración de resumen
+- Pro/contra principal
+- Siguiente paso concreto
+
+## Output
+
+```markdown
+## Sesión de Brainstorming: [tema]
+**Fecha:** YYYY-MM-DD
+**Participantes:** [usuario + agentes]
+
+### Problema
+[definición]
+
+### Ideas Generadas (N)
+1. [idea] — viabilidad: alta/media/baja
+2. ...
+
+### Top 3 Seleccionadas
+1. **[nombre]** — [resumen]. Pro: [x]. Contra: [y].
+
+### Decisión
+[idea elegida] → Siguiente paso: [acción]
+```
+
+## Guardrails
+
+- Nunca evaluar durante divergencia
+- Mínimo 5 ideas antes de converger
+- Siempre cerrar con acción concreta
+- Registrar en `.especdev/hallazgos.md`