don-cheli-sdd 1.13.0

package/comandos/especdev/crear-skill.md

@@ -0,0 +1,148 @@
+---
+description: Crear, probar y mejorar habilidades (skills) de forma iterativa
+i18n: true
+---
+
+# /especdev:crear-skill
+
+## Objetivo
+
+Meta-skill que permite crear nuevas habilidades para Don Cheli de forma iterativa. Genera el SKILL.md, lo prueba con un prompt de test, evalúa el resultado, y propone mejoras — repitiendo el ciclo hasta lograr calidad óptima.
+
+Compatible con el formato oficial de Anthropic Skills y con el formato HABILIDAD.md de Don Cheli.
+
+## Uso
+
+```
+/especdev:crear-skill "Generador de reportes semanales del equipo"
+/especdev:crear-skill --desde-patron           # Detectar tarea repetitiva y convertirla en skill
+/especdev:crear-skill --formato anthropic       # Generar solo SKILL.md (formato Anthropic)
+/especdev:crear-skill --formato doncheli        # Generar HABILIDAD.md (formato Don Cheli, default)
+/especdev:crear-skill --formato dual            # Generar ambos formatos
+```
+
+## Proceso (5 fases iterativas)
+
+### Fase 1: Descubrimiento (1 min)
+Preguntar al usuario:
+1. **¿Qué tarea quieres automatizar?** — Descripción en lenguaje natural
+2. **¿Con qué frecuencia la haces?** — Diaria, semanal, por PR, etc.
+3. **¿Qué inputs necesita?** — Archivos, datos, contexto
+4. **¿Qué output esperas?** — Formato, estructura, destino
+5. **¿Qué grado de libertad tiene?** — Alto (texto libre), medio (pseudocódigo), bajo (script exacto)
+
+### Fase 2: Generación del Draft (2 min)
+Generar automáticamente:
+- Metadata YAML (name, description) — **optimizada para matching** (esto es lo más importante)
+- Instrucciones paso a paso en el body
+- Ejemplos concretos con inputs/outputs reales
+- Referencias a archivos adicionales si > 500 líneas
+
+**Principio clave:** Solo incluir lo que Claude NO sabe. Omitir conocimiento general, lenguajes, librerías comunes. Enfocarse en reglas específicas del proyecto/empresa.
+
+### Fase 3: Test con Prompt Real (1 min)
+- Ejecutar la skill con un prompt de prueba proporcionado por el usuario
+- Capturar el output completo
+- Medir: tokens consumidos, tiempo de ejecución, calidad del resultado
+
+### Fase 4: Evaluación (1 min)
+Evaluar contra criterios:
+| Criterio | Peso | Cómo se mide |
+|----------|------|-------------|
+| Accuracy | 40% | ¿El output es correcto y completo? |
+| Token efficiency | 20% | ¿Cuántos tokens consumió? ¿Hay contenido innecesario? |
+| Consistency | 20% | ¿Produce resultados consistentes con diferentes inputs? |
+| Metadata match | 20% | ¿Se activa con los prompts correctos? ¿Falsos positivos? |
+
+### Fase 5: Iteración (repetir hasta satisfactorio)
+- Proponer mejoras específicas al SKILL.md
+- Aplicar cambios
+- Re-testear
+- **Máximo 3 iteraciones** — si no converge, pedir feedback del usuario
+
+## Formato de Salida — SKILL.md (Anthropic Compatible)
+
+```yaml
+---
+name: Weekly Team Report Generator
+description: Generates a structured weekly team report from standup notes and PR activity. Activate when user mentions "weekly report", "team update", or "sprint summary".
+---
+```
+
+```markdown
+# Weekly Team Report Generator
+
+## Instructions
+1. Gather standup notes from the current week
+2. Pull PR merge activity from git log
+3. Structure the report in three sections:
+   - Accomplishments (from merged PRs + standup highlights)
+   - Blockers (from standup blockers + open issues)
+   - Next Week (from upcoming sprint items)
+4. Apply the team's formatting template
+
+## Examples
+
+### Input
+"Generate this week's team report"
+
+### Output
+[Structured report following the template]
+
+## References
+- See `templates/weekly-report.md` for the formatting template
+- See `reference.md` for the team's style guide
+```
+
+## Formato de Salida — HABILIDAD.md (Don Cheli)
+
+```yaml
+---
+nombre: Generador de Reportes Semanales
+descripcion: Genera reportes semanales del equipo desde notas de standup y actividad de PRs
+version: 1.0.0
+autor: [usuario]
+tags: [reportes, equipo, productividad]
+activacion: "reporte semanal", "actualización del equipo", "resumen de sprint"
+grado_libertad: medio
+---
+```
+
+## Best Practices (del post de Anthropic)
+
+### Progressive Disclosure
+La skill usa 3 capas de información:
+1. **Metadata (YAML)** — Siempre cargada al inicio (pocos tokens). Define CUÁNDO activar.
+2. **Body (Markdown)** — Cargada bajo demanda cuando se activa. Define QUÉ hacer.
+3. **File References** — Cargadas solo si se necesitan. Detalles adicionales.
+
+### Límite de 500 líneas
+Si el SKILL.md supera 500 líneas, separar material de referencia:
+```
+.claude/skills/
+  mi-skill/
+    SKILL.md          ← Instrucciones principales (< 500 líneas)
+    templates/        ← Archivos de plantilla
+    reference.md      ← Material de referencia detallado
+```
+
+### Solo incluir lo que Claude no sabe
+- ❌ No explicar cómo funciona JavaScript/Python/etc.
+- ❌ No incluir documentación de librerías comunes
+- ✅ Incluir reglas específicas de la empresa
+- ✅ Incluir formatos y templates propios
+- ✅ Incluir quirks de herramientas internas
+- ✅ Incluir workflow steps específicos del equipo
+
+### Grado de libertad
+| Grado | Cuándo | Formato de instrucciones |
+|-------|--------|-------------------------|
+| **Alto** | Tareas creativas (redacción, diseño) | Texto libre con guidelines |
+| **Medio** | Workflows con variaciones | Pseudocódigo con parámetros |
+| **Bajo** | Procesos críticos sin margen de error | Scripts exactos, pocos parámetros |
+
+## Integración
+
+- Las skills creadas se guardan en `.claude/skills/` (formato Anthropic) o en `habilidades/` (formato Don Cheli)
+- Compatible con el marketplace oficial de Anthropic: `https://github.com/anthropics/skills`
+- Se pueden compartir vía `/especdev:archivar` o exportar como ZIP

package/comandos/especdev/debate.md

@@ -0,0 +1,119 @@
+---
+description: Deliberación multi-rol con tensiones explícitas para decisiones de arquitectura y trade-offs
+i18n: true
+---
+
+# /especdev:debate
+
+## Objetivo
+
+Invocar una deliberación entre múltiples perspectivas en conflicto sobre una decisión técnica, de producto o de negocio. Diferente de brainstorming (generar ideas) y de mesa-redonda (explorar opciones): el debate busca TENSIÓN entre roles senior para sacar a la luz riesgos que un solo agente no genera.
+
+Inspirado en el "Party Mode" del framework BMAD.
+
+## Uso
+
+```
+/especdev:debate "¿Monolito o microservicios para el MVP?"
+/especdev:debate "¿PostgreSQL o MongoDB para este caso de uso?"
+/especdev:debate --roles "CPO,Arquitecto,UX,Negocio"
+```
+
+## Comportamiento
+
+1. **Definir** la pregunta y los roles participantes (default: CPO, Arquitecto, UX)
+2. **Cada rol presenta** su posición con argumentos concretos, datos y experiencia
+3. **Cada rol critica** las posiciones de los demás (adversarial)
+4. **Se identifican** los puntos de tensión irresolubles
+5. **Se documenta** la decisión con trade-offs explícitos
+6. **Se guarda** en `.especdev/decisiones.md`
+
+## Roles Disponibles
+
+### Roles de Negocio y Producto (Senior)
+
+| Rol | Perspectiva | Prioriza |
+|-----|-------------|----------|
+| **CPO** (Chief Product Officer) | Visión de producto, estrategia y mercado | Product-market fit, roadmap, priorización basada en impacto, métricas de adopción |
+| **UX Lead** | Experiencia de usuario y diseño | Usabilidad, accesibilidad (WCAG), research con usuarios, design systems, conversion funnels |
+| **Negocio** (VP/Director) | Viabilidad comercial y estrategia | ROI, unit economics, time to revenue, ventaja competitiva, riesgos regulatorios |
+
+### Roles Técnicos (Senior)
+
+| Rol | Perspectiva | Prioriza |
+|-----|-------------|----------|
+| **Arquitecto** | Sistema y escalabilidad | Mantenibilidad, performance, extensibilidad, deuda técnica |
+| **QA Lead** | Calidad y testing | Testability, edge cases, regression, automatización |
+| **Seguridad** (CISO) | Protección y compliance | OWASP, datos sensibles, auth, regulaciones (GDPR, SOC2) |
+| **DevOps** | Operaciones y deploy | Observabilidad, CI/CD, costos infra, SLAs |
+| **DBA** | Datos y persistencia | Consistencia, queries, migraciones, backup/recovery |
+
+### Presets de Roles
+
+| Preset | Roles incluidos | Mejor para |
+|--------|----------------|------------|
+| `--preset tech` | Arquitecto, QA Lead, Seguridad, DevOps | Decisiones puramente técnicas |
+| `--preset product` | CPO, UX Lead, Negocio | Decisiones de producto y estrategia |
+| `--preset full` | CPO, UX Lead, Negocio, Arquitecto, QA Lead, Seguridad | Decisiones cross-funcionales |
+| (default) | CPO, Arquitecto, UX Lead | Balance producto-técnico |
+
+## Reglas de Engagement
+
+### Regla Adversarial
+Cada rol DEBE encontrar al menos un problema con cada propuesta de los demás. "No tengo objeciones" no es una respuesta válida — obliga a buscar más profundo.
+
+### Regla de Evidencia
+Cada argumento DEBE estar respaldado por al menos uno de:
+- **Dato concreto**: métrica, benchmark, caso de estudio real
+- **Experiencia**: patrón observado en proyectos similares con resultado conocido
+- **Principio establecido**: ley, heurística o framework reconocido en la industria
+
+Opiniones sin respaldo se marcan como `[sin evidencia]` y tienen menor peso en la decisión.
+
+### Regla de Impacto
+Cada rol DEBE cuantificar el impacto de su posición cuando sea posible:
+- Negocio: revenue, costos, timeline
+- Técnico: latencia, throughput, horas de desarrollo
+- UX: tasa de conversión, NPS, task completion rate
+- Producto: adoption rate, churn, time to value
+
+## Output
+
+```markdown
+## Debate: ¿Monolito o microservicios?
+
+### CPO dice: Monolito
+- Time to market es 2-3x más rápido para MVP (dato: empresas en etapa seed con monolito lanzan en promedio 40% antes — Startup Genome Report)
+- Un solo producto coherente para los primeros 1000 usuarios
+- ⚠️ Riesgo: si product-market fit requiere pivotar rápido, un monolito acoplado frena los cambios
+
+### Arquitecto dice: Monolito modular
+- Shopify procesó $5.1B en Black Friday 2023 con un monolito Ruby — la escala no requiere microservicios
+- Módulos bien definidos permiten extraer servicios después con datos reales de carga
+- ⚠️ Riesgo: sin disciplina en boundaries, los módulos se acoplan y la extracción futura se vuelve rewrite
+
+### UX Lead dice: Monolito
+- UI consistente es más fácil con un solo codebase y design system centralizado
+- Latencia percibida menor sin hops entre servicios (p95 < 200ms vs 400ms+ con microservicios)
+- ⚠️ Riesgo: si el monolito crece, el frontend se acopla al backend y los cambios de UX requieren deploys full
+
+### Negocio dice: Monolito con plan de migración
+- Costo operativo de microservicios para un equipo < 10 personas: +$3-5K/mes en infra + 30% más tiempo en DevOps
+- Inversores en Serie A quieren ver tracción, no arquitectura — priorizar velocidad
+- ⚠️ Riesgo: si se escala sin plan, la deuda técnica se convierte en deuda financiera (caso: Segment revirtió microservicios a monolito en 2018)
+
+### Tensiones irresolubles
+1. Velocidad ahora (CPO/Negocio) vs Flexibilidad futura (Arquitecto)
+2. Consistencia de UX (UX Lead) vs Independencia de deploy (Arquitecto)
+3. Costo operativo (Negocio) vs Escalabilidad técnica (Arquitecto)
+
+### Decisión: Monolito modular con boundaries explícitos
+Monolito con módulos bien separados, contratos internos entre módulos, y métricas de acoplamiento. Revisión de arquitectura al llegar a 10K usuarios o 10 developers.
+
+### Trade-offs aceptados
+- ✅ Time to market agresivo (CPO + Negocio satisfechos)
+- ✅ UX consistente (UX Lead satisfecho)
+- ✅ Testability simple (QA satisfecho)
+- ⚠️ Requiere disciplina de boundaries desde día 1 (Arquitecto advierte)
+- ⚠️ Punto de revisión obligatorio al escalar (Negocio + Arquitecto acuerdan)
+```

package/comandos/especdev/desglosar.md

@@ -0,0 +1,172 @@
+---
+description: Dividir un blueprint técnico en tareas con TDD (RED→GREEN) y marcadores de paralelismo
+i18n: true
+---
+
+# /especdev:desglosar
+
+## Objetivo
+
+Convertir un blueprint técnico en una lista de tareas ordenadas con enfoque TDD (RED → GREEN → REFACTOR), marcadores de paralelismo `[P]` y fases de ejecución estandarizadas.
+
+> Alineado con spec-kit (github/spec-kit) — formato `[ID] [P?] [Story] Descripción` y 5 fases de ejecución
+
+## Uso
+
+```
+/especdev:desglosar @specs/features/<dominio>/<Feature>.plan.md
+```
+
+## Formato de Tareas
+
+```
+[TID] [P?] [Historia] Descripción
+```
+
+| Campo | Significado | Ejemplo |
+|-------|-------------|---------|
+| `TID` | ID único de tarea | `T001` |
+| `[P]` | Paralelizable (puede ejecutarse en paralelo con otras `[P]` de la misma fase) | `[P]` o vacío |
+| `[Historia]` | Historia de usuario asociada | `[US1]` |
+| Descripción | Qué hacer | Crear modelo de Usuario |
+
+## Output
+
+Genera `specs/features/<dominio>/<Feature>.tasks.md`:
+
+```markdown
+# Tareas: CrearUsuario
+
+**Feature:** usuario/CrearUsuario
+**Plan:** specs/features/usuario/CrearUsuario.plan.md
+**Creado:** 2026-03-21
+
+## Formato: [TID] [P?] [Historia] Descripción
+
+---
+
+## Fase 1: Setup (Paralelizable)
+
+Inicialización del entorno y estructura del proyecto.
+
+- [T001] [P] Setup: Crear estructura de directorios del módulo usuario
+- [T002] [P] Setup: Inicializar configuración de testing
+- [T003] [P] Setup: Configurar Docker compose para tests
+
+---
+
+## Fase 2: Fundación (Secuencial después de Setup)
+
+Infraestructura crítica que el resto del código necesita.
+
+- [T004] [US1] RED: Escribir test para modelo Usuario
+- [T005] [US1] GREEN: Implementar modelo Usuario con validaciones
+  - Archivos: `models/usuario.py`, `tests/unit/test_usuario.py`
+
+- [T006] [US1] RED: Escribir test para UsuarioRepository (crear/buscar)
+- [T007] [US1] GREEN: Implementar UsuarioRepository
+  - Archivos: `repositories/usuario_repo.py`, `tests/unit/test_usuario_repo.py`
+
+---
+
+## Fase 3: Historias de Usuario (Por prioridad)
+
+### P1: Camino Crítico
+
+- [T008] [US1] RED: Test para registro exitoso (happy path)
+- [T009] [US1] RED: Test para email duplicado (sad path)
+- [T010] [US1] GREEN: Implementar UsuarioService.crear()
+  - Archivos: `services/usuario_service.py`, `tests/unit/test_usuario_service.py`
+- [T011] [P] [US1] RED: Test de integración para POST /usuarios
+- [T012] [P] [US1] RED: Test BDD desde escenarios Gherkin P1
+- [T013] [US1] GREEN: Implementar UsuarioController
+  - Archivos: `controllers/usuario_controller.py`, `tests/integration/test_crear_usuario.py`
+
+### P2: Importante
+
+- [T014] [US2] RED: Test para campo obligatorio vacío
+- [T015] [US2] RED: Test para contraseña débil
+- [T016] [US2] GREEN: Implementar validaciones adicionales
+- [T017] [P] [US2] RED: Test BDD desde escenarios Gherkin P2
+
+---
+
+## Fase 4: Polish (Paralelizable)
+
+Refinamientos transversales.
+
+- [T018] [P] Refactor: Extraer validaciones a módulo compartido (si aplica)
+- [T019] [P] Docs: Actualizar API docs con nuevo endpoint
+- [T020] [P] Lint: Ejecutar linter y corregir warnings
+
+---
+
+## Fase 5: Verificación Final
+
+- [T021] Ejecutar suite completa de tests
+- [T022] Verificar coverage ≥ 85% sobre código nuevo
+- [T023] Verificar lint y type-check sin errores
+- [T024] Verificar build exitoso
+
+---
+
+## Orden de Ejecución
+
+```
+Fase 1: T001 ║ T002 ║ T003  (paralelo)
+              ↓
+Fase 2: T004 → T005 → T006 → T007  (secuencial)
+              ↓
+Fase 3: T008 → T009 → T010 → T011 ║ T012 → T013  (mixto)
+         T014 → T015 → T016 → T017  (secuencial)
+              ↓
+Fase 4: T018 ║ T019 ║ T020  (paralelo)
+              ↓
+Fase 5: T021 → T022 → T023 → T024  (secuencial)
+```
+
+**Leyenda:** `→` secuencial | `║` paralelo
+```
+
+## Las 5 Fases de Ejecución
+
+| Fase | Nombre | Tipo | Propósito |
+|------|--------|------|-----------|
+| 1 | **Setup** | Paralelo | Inicialización de entorno y estructura |
+| 2 | **Fundación** | Secuencial | Modelos, repos, infraestructura base |
+| 3 | **Historias de Usuario** | Por prioridad | Features P1 → P2 → P3+ con TDD |
+| 4 | **Polish** | Paralelo | Refactoring, docs, limpieza |
+| 5 | **Verificación Final** | Secuencial | Tests, coverage, lint, build |
+
+## Reglas de Paralelismo
+
+- Tareas marcadas con `[P]` pueden ejecutarse en paralelo con otras `[P]` **de la misma fase**
+- Tareas sin `[P]` son secuenciales y dependen de la tarea anterior
+- **Nunca** ejecutar tareas de fases diferentes en paralelo
+- Las fases 1 y 4 son predominantemente paralelas
+- Las fases 2 y 5 son predominantemente secuenciales
+- La fase 3 es mixta: secuencial dentro de cada historia, potencialmente paralelo entre historias independientes
+
+## Ciclo TDD por Tarea
+
+```
+RED:   Escribir test que FALLA
+       → Ejecutar: verificar que falla por la razón correcta
+
+GREEN: Implementar el código MÍNIMO para que el test pase
+       → Ejecutar: verificar que PASA
+
+REFACTOR: Limpiar sin cambiar comportamiento (solo en Fase 4)
+       → Ejecutar: verificar que sigue pasando
+```
+
+## Puerta de Calidad
+
+Este comando implementa la **Puerta 5 (Preparación de Tareas)**:
+
+- Todas las tareas tienen IDs únicos (`T###`)
+- Todas las tareas de implementación tienen rutas exactas de archivos
+- Tareas paralelizables marcadas con `[P]`
+- Historias asociadas con `[US#]`
+- Las 5 fases están presentes
+- Orden de ejecución documentado

package/comandos/especdev/destilar.md

@@ -0,0 +1,211 @@
+---
+description: Extraer especificaciones compactas desde código existente (Blueprint Distillation)
+i18n: true
+---
+
+# /especdev:destilar
+
+## Objetivo
+
+Analizar un codebase existente y extraer un **blueprint compacto**: especificaciones, contratos, reglas de negocio y decisiones arquitectónicas implícitas en el código. Es ingeniería inversa de specs, no de arquitectura (para eso existe `/especdev:reversa`).
+
+> Adaptado de DeepCode (HKUDS/DeepCode) — Blueprint Distillation: "comprimir código fuente para extraer especificaciones esenciales, filtrando ruido y preservando patrones críticos."
+
+## Uso
+
+```
+/especdev:destilar                             # Destilar el proyecto actual
+/especdev:destilar @ruta/al/modulo             # Destilar un módulo específico
+/especdev:destilar --formato gherkin           # Output en formato Gherkin
+/especdev:destilar --formato resumen           # Output como resumen ejecutivo
+/especdev:destilar --formato contratos         # Solo interfaces y contratos
+```
+
+## Por Qué Existe
+
+| Situación | Sin Destilar | Con Destilar |
+|-----------|-------------|--------------|
+| Proyecto heredado sin docs | Leer todo el código | Blueprint de 200 líneas |
+| Migración a nueva versión | Riesgo de perder reglas implícitas | Spec explícita para validar |
+| Onboarding de nuevo dev | Semanas entendiendo el código | Blueprint + mapa en 1 hora |
+| Rewrite parcial | ¿Qué comportamiento preservar? | Contratos explícitos |
+
+## Diferencia con `/especdev:reversa`
+
+| Aspecto | `/especdev:reversa` | `/especdev:destilar` |
+|---------|--------------------|--------------------|
+| **Foco** | Arquitectura (componentes, conexiones) | Comportamiento (reglas, contratos) |
+| **Output** | Mapa de componentes | Especificaciones compactas |
+| **Pregunta** | "¿Cómo está construido?" | "¿Qué hace y por qué?" |
+| **Formato** | Diagrama + tabla | Gherkin / contratos / resumen |
+
+Se complementan: `reversa` te da el **mapa**, `destilar` te da las **reglas**.
+
+## Comportamiento
+
+### Paso 1: Análisis de Superficie
+
+```
+Escaneando módulo src/services/payment/...
+├── 8 archivos, 1,247 líneas de código
+├── 23 funciones exportadas
+├── 4 interfaces/tipos públicos
+├── 12 tests encontrados
+└── 3 dependencias externas (Stripe, Redis, Logger)
+```
+
+### Paso 2: Extracción de Reglas de Negocio
+
+El destilador busca reglas implícitas en:
+
+| Fuente | Qué Extrae | Ejemplo |
+|--------|-----------|---------|
+| **Validaciones** | Reglas de dominio | "Monto mínimo: $1.00, máximo: $999,999" |
+| **Condicionales** | Lógica de negocio | "Si el usuario es premium, no cobra comisión" |
+| **Error handling** | Casos límite | "Reintentar 3 veces si Stripe devuelve 429" |
+| **Tests** | Comportamiento esperado | "Webhook debe ser idempotente" |
+| **Tipos/Interfaces** | Contratos | "PaymentIntent requiere: amount, currency, customerId" |
+| **Comentarios** | Intención del dev original | "// HACK: Stripe no soporta ARS, convertir a USD" |
+
+### Paso 3: Compresión
+
+Eliminar ruido, preservar esencia:
+
+```
+Código original: 1,247 líneas
+├── Boilerplate eliminado: 400 líneas (imports, exports, logging)
+├── Implementación interna eliminada: 500 líneas
+├── Duplicación eliminada: 100 líneas
+└── Blueprint resultante: ~247 líneas (ratio 5:1)
+```
+
+**Regla de compresión:** El blueprint debe ser ≤20% del código original.
+
+### Paso 4: Formato de Output
+
+#### Formato Gherkin (default)
+
+```gherkin
+Feature: Procesamiento de Pagos
+  El sistema procesa pagos a través de Stripe
+  con reintentos automáticos y manejo de moneda.
+
+  Reglas de Negocio:
+  - Monto mínimo: $1.00 USD
+  - Monto máximo: $999,999.00 USD
+  - Monedas soportadas: USD, EUR, BRL
+  - Usuarios premium: sin comisión de procesamiento
+  - Comisión estándar: 2.9% + $0.30
+
+  Escenario: Pago exitoso
+    Dado un usuario con customerId válido en Stripe
+    Y un monto de $50.00 USD
+    Cuando se procesa el pago
+    Entonces se crea un PaymentIntent en Stripe
+    Y se registra la transacción en la base de datos
+    Y se emite el evento "payment.completed"
+
+  Escenario: Reintento por rate limit
+    Dado que Stripe responde con HTTP 429
+    Cuando se procesa el pago
+    Entonces se reintenta hasta 3 veces con backoff exponencial
+    Y si todos fallan, se marca como "payment.failed"
+    Y se notifica al equipo de soporte
+
+  Escenario: Moneda no soportada
+    Dado un monto en ARS (peso argentino)
+    Cuando se procesa el pago
+    Entonces se convierte a USD usando el tipo de cambio del día
+    Y se procesa en USD
+    Y se registra el tipo de cambio usado
+```
+
+#### Formato Contratos
+
+```typescript
+// Blueprint: Contratos del Módulo de Pagos
+// Extraído de: src/services/payment/ (8 archivos, 1,247 LOC)
+// Fecha: 2026-03-21
+
+interface PaymentIntent {
+  amount: number;        // centavos, min: 100, max: 99999900
+  currency: 'USD' | 'EUR' | 'BRL';
+  customerId: string;    // Stripe customer ID
+  metadata?: Record<string, string>;
+}
+
+interface PaymentResult {
+  id: string;
+  status: 'succeeded' | 'failed' | 'pending';
+  stripePaymentIntentId: string;
+  amount: number;
+  fee: number;           // 0 para premium, 2.9% + 30 para estándar
+  createdAt: Date;
+}
+
+// Contratos de servicio
+type ProcessPayment = (intent: PaymentIntent) => Promise<PaymentResult>;
+type RefundPayment = (paymentId: string, amount?: number) => Promise<RefundResult>;
+type GetPaymentStatus = (paymentId: string) => Promise<PaymentResult>;
+
+// Invariantes
+// - ProcessPayment es idempotente (mismo intent = mismo resultado)
+// - RefundPayment parcial: amount <= payment.amount
+// - Retry policy: 3 intentos, backoff exponencial (1s, 2s, 4s)
+```
+
+#### Formato Resumen
+
+```markdown
+## Blueprint: Módulo de Pagos
+
+### Responsabilidad
+Procesar pagos a través de Stripe con reintentos y conversión de moneda.
+
+### Reglas de Negocio
+1. Montos: $1.00 - $999,999.00 USD
+2. Monedas: USD, EUR, BRL (ARS se convierte a USD)
+3. Comisión: 2.9% + $0.30 (premium: 0%)
+4. Reintentos: 3x con backoff exponencial ante rate limit
+5. Idempotencia: mismo PaymentIntent = mismo resultado
+
+### Dependencias Externas
+- Stripe API v3 (pagos, reembolsos)
+- Redis (cache de tipos de cambio, idempotency keys)
+
+### Riesgos Identificados
+- Conversión ARS→USD usa hack manual (comentario en código)
+- No hay circuit breaker para Stripe
+- Tests no cubren reembolsos parciales
+```
+
+## Integración con Pipeline
+
+```
+/especdev:destilar → blueprint
+  → /especdev:especificar → .feature (informada por blueprint)
+  → /especdev:clarificar → validar contra blueprint
+  → /especdev:planificar-tecnico → usar contratos como base
+```
+
+El blueprint alimenta el pipeline de specs, cerrando el ciclo:
+**Código existente → Blueprint → Spec → Nuevo código validado**
+
+## Almacenamiento
+
+El blueprint se guarda en:
+
+```
+.especdev/blueprints/
+├── payment.blueprint.md      # Blueprint del módulo de pagos
+├── auth.blueprint.md         # Blueprint del módulo de auth
+└── _index.md                 # Índice de blueprints
+```
+
+## Guardrails
+
+- **Nunca** incluir credenciales o secretos en el blueprint
+- **Nunca** exceder 20% del tamaño del código original
+- **Siempre** indicar qué archivos se analizaron
+- **Siempre** marcar los "hacks" o workarounds encontrados como riesgos
+- **Siempre** distinguir entre reglas de negocio confirmadas (por tests) y supuestas (por código)