don-cheli-sdd 1.13.0

package/comandos/especdev/planning.md

@@ -0,0 +1,264 @@
+---
+description: Planning semanal de equipo con revisión de RFCs, priorización, asignación por responsable/pareja/squad y seguimiento
+i18n: true
+---
+
+# /especdev:planning
+
+## Objetivo
+
+Facilitar el planning semanal de un equipo de desarrollo: revisar RFCs pendientes, priorizar trabajo, asignar tareas a responsables individuales, parejas o squads, y generar un plan accionable con compromisos claros.
+
+A diferencia de `/especdev:estimar` (esfuerzo por tarea) o `/especdev:debate` (decisiones técnicas), el planning opera a **nivel de equipo y sprint**: qué se hace, quién lo hace, en qué orden, y qué se deja fuera.
+
+## Uso
+
+```
+/especdev:planning                                    # Planning completo (interactivo)
+/especdev:planning --semana "2026-03-24"              # Planning para semana específica
+/especdev:planning --equipo "Ana,Carlos,Luis,María"   # Definir equipo
+/especdev:planning --capacidad "Ana:4d,Carlos:3d"     # Capacidad por persona (días disponibles)
+/especdev:planning --rfcs "RFC-012,RFC-015,RFC-018"   # RFCs a revisar
+/especdev:planning --modo revision                    # Solo revisión de RFCs (sin asignación)
+/especdev:planning --modo asignacion                  # Solo asignación (RFCs ya priorizados)
+/especdev:planning --modo seguimiento                 # Revisar avance del planning anterior
+```
+
+## Proceso (4 Fases)
+
+### Fase 1: Contexto del equipo
+
+Recopilar información del equipo antes de planificar:
+
+```markdown
+## Contexto del equipo
+
+### Miembros y disponibilidad
+| Miembro | Rol | Disponibilidad | Notas |
+|---------|-----|----------------|-------|
+| Ana | Sr. Backend | 4/5 días | Lunes feriado |
+| Carlos | Sr. Frontend | 5/5 días | — |
+| Luis | Fullstack | 3/5 días | 2 días en soporte rotativo |
+| María | Sr. Backend | 5/5 días | — |
+| Diego | Jr. Frontend | 5/5 días | Necesita mentoring |
+
+### Capacidad total del equipo
+- Días disponibles: 22/25 (88%)
+- Factor de foco (reuniones, interrupciones): 0.7
+- **Capacidad efectiva: 15.4 días-persona**
+
+### Arrastre de la semana anterior
+- [ ] RFC-010: Migración de auth — 60% completado (María, bloqueo en revisión de seguridad)
+- [x] RFC-011: Endpoint de reportes — completado
+- [ ] BUG-234: Memory leak en worker — pendiente (Luis no tuvo disponibilidad)
+```
+
+### Fase 2: Revisión de RFCs
+
+Evaluar cada RFC pendiente con criterios estructurados:
+
+```markdown
+## Revisión de RFCs
+
+### RFC-012: Cache distribuido con Redis
+- **Autor:** María | **Estado:** Aprobado | **Tamaño:** L
+- **Dependencias:** Infra debe provisionar Redis cluster
+- **Riesgo técnico:** Medio (equipo no tiene experiencia con Redis Cluster)
+- **Impacto de negocio:** Alto (reduce latencia de catálogo de 800ms a 200ms)
+- **Deuda técnica:** Baja (solución limpia, bien diseñada)
+- **Veredicto:** ✅ Priorizar esta semana
+
+### RFC-015: Migración de Styled Components a Tailwind
+- **Autor:** Carlos | **Estado:** En discusión | **Tamaño:** XL
+- **Dependencias:** Ninguna técnica, pero necesita buy-in del equipo de diseño
+- **Riesgo técnico:** Bajo (migración incremental posible)
+- **Impacto de negocio:** Bajo (mejora DX, no impacta usuario final)
+- **Deuda técnica:** Media (reduce deuda futura pero introduce churn ahora)
+- **Veredicto:** ⏸️ Postergar — no justifica el costo de oportunidad esta semana
+
+### RFC-018: API de notificaciones push
+- **Autor:** Ana | **Estado:** Aprobado | **Tamaño:** M
+- **Dependencias:** RFC-012 (necesita Redis para pub/sub)
+- **Riesgo técnico:** Bajo
+- **Impacto de negocio:** Alto (feature pedido por 3 clientes enterprise)
+- **Veredicto:** ✅ Priorizar después de RFC-012
+```
+
+### Fase 3: Priorización y asignación
+
+Usar matriz de priorización y asignar por modalidad:
+
+```markdown
+## Priorización (Eisenhower + WSJF)
+
+| # | Item | Urgente | Importante | WSJF Score | Decisión |
+|---|------|---------|------------|------------|----------|
+| 1 | BUG-234: Memory leak | ✅ | ✅ | — | **Primero** (producción) |
+| 2 | RFC-010: Auth (arrastre) | ✅ | ✅ | 8.5 | **Completar** (WIP) |
+| 3 | RFC-012: Redis cache | ❌ | ✅ | 7.2 | **Esta semana** |
+| 4 | RFC-018: Push notifications | ❌ | ✅ | 6.8 | **Iniciar si hay capacidad** |
+| 5 | RFC-015: Tailwind migration | ❌ | ❌ | 3.1 | **Backlog** |
+
+### WSJF (Weighted Shortest Job First)
+Score = (Valor de negocio + Urgencia + Reducción de riesgo) / Tamaño del trabajo
+- Valor: 1-5 | Urgencia: 1-5 | Riesgo: 1-5 | Tamaño: 1-5 (Fibonacci: 1,2,3,5,8)
+
+## Asignación
+
+### Modalidad: Individual
+Para tareas bien definidas donde una persona puede avanzar sola.
+
+| Tarea | Responsable | Estimado | Entregable | Deadline |
+|-------|-------------|----------|------------|----------|
+| BUG-234: Memory leak | Luis | 1d | Fix + test + post-mortem | Lunes |
+| RFC-010: Auth (completar) | María | 2d | PR listo para merge | Miércoles |
+
+### Modalidad: Pareja (Pair Programming)
+Para tareas que requieren conocimiento cruzado o mentoring.
+
+| Tarea | Pareja | Razón | Estimado | Entregable |
+|-------|--------|-------|----------|------------|
+| RFC-012: Redis cache (setup) | María + Luis | María diseñó el RFC, Luis aprende Redis | 2d | Infra + tests de integración |
+| RFC-012: Redis cache (frontend) | Carlos + Diego | Diego aprende patterns de caching en frontend, Carlos mentora | 1.5d | Cache invalidation UI + tests |
+
+### Modalidad: Squad
+Para iniciativas que necesitan esfuerzo coordinado multi-disciplina.
+
+| Iniciativa | Squad | Roles | Estimado | Sync |
+|------------|-------|-------|----------|------|
+| RFC-018: Push notifications | Ana (lead) + Carlos + María | Ana: API, Carlos: UI, María: pub/sub | 3d | Daily 15min a las 10:00 |
+```
+
+### Fase 4: Plan semanal consolidado
+
+```markdown
+## Plan Semanal: 2026-03-24 → 2026-03-28
+
+### Compromisos (lo que prometemos entregar)
+1. ✅ BUG-234 resuelto en producción (Lunes)
+2. ✅ RFC-010: Auth migración completada y mergeada (Miércoles)
+3. ✅ RFC-012: Redis cache funcional en staging (Viernes)
+
+### Stretch goals (si hay capacidad)
+4. 🎯 RFC-018: Push notifications — diseño de API + spike de pub/sub
+
+### Lo que NO hacemos esta semana (y por qué)
+- RFC-015: Tailwind migration — WSJF bajo, sin urgencia de negocio
+- TECH-089: Upgrade Node 22 — esperamos que el equipo de plataforma publique guía
+
+### Riesgos y mitigaciones
+| Riesgo | Probabilidad | Impacto | Mitigación |
+|--------|-------------|---------|------------|
+| Redis provisioning se demora | Media | Alto | María hace spike con Docker local primero |
+| Luis no termina BUG-234 el lunes | Baja | Alto | Ana como backup (conoce el worker) |
+| Revisión de seguridad de auth bloquea a María | Alta | Medio | Escalar a Tech Lead el martes si no hay review |
+
+### Ceremonias
+| Ceremonia | Día | Hora | Duración | Quién |
+|-----------|-----|------|----------|-------|
+| Planning (este documento) | Lunes | 09:00 | 45min | Todo el equipo |
+| Daily standup | L-V | 09:30 | 15min | Todo el equipo |
+| RFC-018 sync | M-J | 10:00 | 15min | Squad de push |
+| Demo/Review | Viernes | 16:00 | 30min | Todo el equipo + PM |
+
+### Métricas de la semana
+- Capacidad utilizada: 15.4 / 15.4 días-persona (100%)
+- Items comprometidos: 3
+- Stretch: 1
+- Carry-over anterior: 2 (BUG-234, RFC-010)
+```
+
+## Criterios de evaluación de RFCs
+
+Al revisar un RFC, evaluar cada dimensión con 1-5:
+
+| Dimensión | 1 (Bajo) | 5 (Alto) |
+|-----------|----------|----------|
+| **Impacto de negocio** | Nice-to-have interno | Bloquea revenue o cliente enterprise |
+| **Riesgo técnico** | Tecnología conocida, patrón probado | Stack nuevo, sin experiencia en el equipo |
+| **Tamaño** | < 1 día, 1-2 archivos | > 1 semana, cross-cutting |
+| **Urgencia** | Sin deadline, puede esperar | SLA comprometido o dependencia bloqueante |
+| **Deuda técnica** | Solución limpia | Workaround que acumula deuda |
+
+## Reglas del Planning
+
+### Regla de capacidad
+**NUNCA planificar al 100% de capacidad.** Factor de foco:
+- Equipo maduro con pocos meetings: **0.8**
+- Equipo promedio: **0.7**
+- Equipo con mucho soporte/on-call: **0.5-0.6**
+
+### Regla de WIP
+Máximo **2 items en progreso por persona**. Si alguien tiene 2 tareas activas, no se le asigna una tercera hasta que cierre una.
+
+### Regla de arrastre
+Si un item se arrastra **3 semanas consecutivas**, se debe tomar una decisión:
+1. **Replantear**: dividir en partes más pequeñas
+2. **Escalar**: pedir ayuda o más recursos
+3. **Cancelar**: admitir que no es prioridad y sacarlo del backlog
+
+### Regla de parejas
+Las parejas DEBEN rotar cada semana. Objetivo: ningún conocimiento queda en una sola persona.
+
+### Regla de juniors
+Todo junior DEBE estar asignado en pareja con un senior. Nunca asignar tareas críticas a un junior solo.
+
+## Almacenamiento
+
+```
+.especdev/
+├── plannings/
+│   ├── 2026-W13.md        # Planning semana 13
+│   ├── 2026-W14.md        # Planning semana 14
+│   └── _retrospectiva.md  # Patrones observados entre plannings
+└── rfcs/
+    ├── RFC-012.md          # RFC individual
+    ├── RFC-015.md
+    └── _indice.md          # Índice de todos los RFCs con estado
+```
+
+## Modos especiales
+
+### `--modo revision`
+Solo ejecuta Fases 1 y 2 (contexto + revisión de RFCs). Útil para sesiones de refinamiento mid-week.
+
+### `--modo asignacion`
+Solo ejecuta Fases 3 y 4 (priorización + plan). Asume que los RFCs ya fueron revisados.
+
+### `--modo seguimiento`
+Lee el planning de la semana actual (`.especdev/plannings/`) y genera reporte de avance:
+```markdown
+## Seguimiento: Semana 2026-W13 (Jueves)
+
+### Avance
+| Item | Estado | Progreso | Notas |
+|------|--------|----------|-------|
+| BUG-234 | ✅ Completado | 100% | Mergeado lunes, post-mortem hecho |
+| RFC-010: Auth | 🟡 En progreso | 80% | Review de seguridad pendiente |
+| RFC-012: Redis | 🟢 En progreso | 40% | Setup OK, tests de integración en progreso |
+| RFC-018: Push | ⬜ No iniciado | 0% | Depende de RFC-012, se inicia viernes si hay tiempo |
+
+### Alerta
+- RFC-010 lleva 2 semanas de carry-over. Si no se completa esta semana → regla de arrastre.
+- Capacidad real utilizada: 12/15.4 días (78%) — 2 días perdidos en incidente no planificado.
+```
+
+## Integración con otros comandos
+
+| Comando | Cuándo usarlo junto con planning |
+|---------|----------------------------------|
+| `/especdev:estimar` | Para estimar RFCs grandes antes del planning |
+| `/especdev:debate` | Para resolver desacuerdos técnicos sobre un RFC |
+| `/especdev:mesa-tecnica` | Para profundizar en la implementación de un RFC priorizado |
+| `/especdev:desglosar` | Para dividir un RFC priorizado en tareas TDD |
+| `/especdev:contrato-api` | Para definir interfaces antes de asignar a parejas/squads |
+
+## Modelo recomendado
+
+| Paso | Modelo | Razón |
+|------|--------|-------|
+| Contexto y capacidad | Haiku | Cálculos y formateo |
+| Revisión de RFCs | Sonnet | Juicio técnico para evaluar riesgo/impacto |
+| Priorización WSJF | Sonnet | Razonamiento sobre trade-offs |
+| Asignación | Haiku | Matcheo persona-tarea según datos |
+| Plan consolidado | Haiku | Formateo y consolidación |

package/comandos/especdev/poc.md

@@ -0,0 +1,302 @@
+---
+description: Modo Prueba de Concepto para validar viabilidad técnica antes de comprometer implementación completa
+i18n: true
+---
+
+# /especdev:poc
+
+## Objetivo
+
+Iniciar una Prueba de Concepto (PoC) para validar viabilidad técnica, explorar soluciones o demostrar una idea **antes** de comprometer una implementación completa. El PoC tiene reglas relajadas: prioriza velocidad y aprendizaje sobre calidad de producción.
+
+## Uso
+
+```
+/especdev:poc <descripción de lo que se quiere validar>
+/especdev:poc --hipotesis "<lo que quiero demostrar>"
+/especdev:poc --tiempo 2h                                # Limitar timebox (default: 4h)
+/especdev:poc --graduar                                  # Convertir PoC exitoso en feature real
+```
+
+## Cuándo Usar
+
+| Situación | PoC | Rápido | Completo |
+|-----------|-----|--------|----------|
+| "¿Se puede hacer X con esta librería?" | ✅ | | |
+| "¿Este enfoque escala?" | ✅ | | |
+| "Necesito una demo para el stakeholder" | ✅ | | |
+| "Corregir bug en auth" | | ✅ | |
+| "Implementar feature de pagos" | | | ✅ |
+| "¿WebSockets o SSE para real-time?" | ✅ | | |
+| "Migrar de REST a GraphQL, ¿vale la pena?" | ✅ | | |
+
+**Regla de oro:** Si la pregunta empieza con "¿se puede...?", "¿funciona...?" o "¿vale la pena...?" → es un PoC.
+
+## Diferencias con Modo Rápido y Completo
+
+| Aspecto | PoC | Rápido (N1) | Completo (N3) |
+|---------|-----|-------------|---------------|
+| **Objetivo** | Validar viabilidad | Entregar cambio | Entregar feature |
+| **Output** | Aprendizaje + demo | Código de producción | Sistema completo |
+| **TDD** | Opcional (solo tests de validación) | Obligatorio | Obligatorio |
+| **Coverage** | Sin mínimo | ≥85% | ≥85% |
+| **Lint/Types** | Relajado | Obligatorio | Obligatorio |
+| **Docs** | Veredicto + hallazgos | Descripción PR | spec.md + tech.md |
+| **Código** | Desechable (puede no mergearse) | Producción | Producción |
+| **Timebox** | Fijo (default 4h) | Variable | Variable |
+| **Constitución** | Solo Art. VII (Stop-Loss) | Completa | Completa |
+| **Stubs permitidos** | Sí (con marcador) | No | No |
+| **Contrato UI** | No | Si aplica | Si aplica |
+
+## Proceso (4 fases)
+
+### Fase 1: Hipótesis (10 min)
+
+Definir QUÉ se quiere validar y CÓMO se medirá el éxito/fracaso.
+
+```markdown
+## PoC: [título]
+
+**Hipótesis:** [lo que se quiere demostrar]
+**Criterio de éxito:** [cómo se sabe que funciona]
+**Criterio de fracaso:** [cuándo abandonar]
+**Timebox:** [tiempo máximo, default 4h]
+**Alcance:**
+  - Incluido: [qué se construirá]
+  - Excluido: [qué NO se construirá]
+
+**Preguntas a responder:**
+1. [pregunta técnica 1]
+2. [pregunta técnica 2]
+3. [pregunta técnica 3]
+```
+
+**Ejemplo:**
+
+```markdown
+## PoC: WebSockets vs SSE para notificaciones en tiempo real
+
+**Hipótesis:** WebSockets ofrece menor latencia que SSE para nuestro caso de uso
+  (notificaciones de cambio de estado de pedido, ~100 usuarios concurrentes).
+
+**Criterio de éxito:**
+  - WebSockets entrega notificaciones en < 50ms
+  - Conexión se mantiene estable por > 30 min
+  - Funciona detrás de nuestro reverse proxy (nginx)
+
+**Criterio de fracaso:**
+  - Latencia > 200ms
+  - Requiere cambio de infraestructura (nginx no soporta)
+  - Complejidad de implementación > 3x vs SSE
+
+**Timebox:** 3 horas
+
+**Alcance:**
+  - Incluido: Servidor WS básico, cliente simple, test de latencia
+  - Excluido: Auth, persistencia, UI bonita, reconexión automática
+
+**Preguntas a responder:**
+1. ¿Cuál es la latencia real de WS vs SSE en nuestro stack?
+2. ¿nginx necesita configuración especial para WS?
+3. ¿Cuántas conexiones concurrentes aguanta el servidor?
+```
+
+### Fase 2: Construir (80% del tiempo)
+
+Reglas relajadas para máxima velocidad:
+
+```
+✅ PERMITIDO en PoC:
+  - Hardcoded values (API keys en .env, datos mock)
+  - Código sin tipos estrictos
+  - Sin lint perfecto
+  - Console.log como debugging
+  - Dependencias sin evaluar alternativas
+  - Un solo archivo largo (sin modularizar)
+  - Estilos inline
+  - Sin manejo de errores exhaustivo
+
+❌ PROHIBIDO incluso en PoC:
+  - Credenciales en código (usar .env)
+  - Cambiar código de producción existente
+  - Commitear al branch principal
+  - Ignorar el timebox (Stop-Loss aplica)
+  - Concluir sin evidencia
+```
+
+**Ubicación del código PoC:**
+
+```
+poc/
+├── <nombre-poc>/
+│   ├── README.md          # Hipótesis + veredicto
+│   ├── src/               # Código del PoC
+│   ├── resultados/        # Screenshots, benchmarks, logs
+│   └── .env.example       # Variables requeridas (sin valores)
+```
+
+**Branch:** `poc/<nombre-poc>` (siempre desde la rama actual, nunca main)
+
+### Fase 3: Evaluar (10 min)
+
+Contra los criterios definidos en la hipótesis:
+
+```markdown
+## Evaluación del PoC
+
+### Resultados vs Criterios
+
+| Criterio | Resultado | Veredicto |
+|----------|-----------|-----------|
+| Latencia < 50ms | 12ms promedio | ✅ CUMPLE |
+| Estable > 30 min | 45 min sin desconexión | ✅ CUMPLE |
+| Funciona con nginx | Sí, con `proxy_set_header Upgrade` | ✅ CUMPLE |
+
+### Preguntas Respondidas
+
+1. **Latencia WS vs SSE:** WS = 12ms, SSE = 45ms (WS 3.7x más rápido)
+2. **nginx:** Requiere 3 líneas de config adicional (documentado)
+3. **Conexiones:** Servidor aguanta ~500 concurrentes con 256MB RAM
+
+### Hallazgos Inesperados
+- La librería `ws` tiene memory leak conocido en v8.16 (usar v8.17+)
+- SSE no funciona con HTTP/2 en nuestro setup actual
+
+### Evidencia
+- Benchmark: resultados/benchmark.json
+- Screenshot: resultados/latency-chart.png
+- Logs: resultados/stress-test.log
+```
+
+### Fase 4: Veredicto (5 min)
+
+Uno de 4 resultados posibles:
+
+```markdown
+## Veredicto: ✅ VIABLE — Proceder con implementación
+
+**Recomendación:** Usar WebSockets para notificaciones real-time.
+**Próximo paso:** /especdev:comenzar Implementar notificaciones real-time con WebSockets
+**Hallazgos a preservar:**
+  - Config nginx necesaria → guardar en hallazgos.md
+  - Usar ws@8.17+ (no 8.16) → guardar en hallazgos.md
+  - Benchmark como referencia → guardar en resultados/
+```
+
+| Veredicto | Significado | Acción |
+|-----------|-------------|--------|
+| ✅ **VIABLE** | Hipótesis confirmada, criterios cumplidos | Graduar a feature con `/especdev:poc --graduar` |
+| ⚠️ **VIABLE CON RESERVAS** | Funciona pero con limitaciones | Documentar limitaciones, decidir si proceder |
+| ❌ **NO VIABLE** | Hipótesis refutada | Documentar por qué, explorar alternativas |
+| 🔄 **INCONCLUSO** | Timebox agotado sin evidencia suficiente | Extender timebox o reformular hipótesis |
+
+## Graduación de PoC a Feature
+
+Cuando un PoC es VIABLE, se puede graduar a una feature real:
+
+```bash
+/especdev:poc --graduar
+```
+
+### Flujo de Graduación
+
+```
+PoC VIABLE
+  │
+  ├── 1. Extraer hallazgos → .especdev/hallazgos.md
+  ├── 2. Extraer decisiones técnicas → .especdev/memoria/decisiones.md
+  ├── 3. Crear propuesta desde PoC → /especdev:proponer (auto-generada)
+  ├── 4. Iniciar pipeline completo → /especdev:comenzar
+  │      (con contexto del PoC como input)
+  └── 5. Archivar código PoC → poc/_archivo/<nombre>/
+```
+
+**Importante:** El código del PoC **NO se reutiliza** directamente. Se reescribe con calidad de producción siguiendo el pipeline completo (TDD, constitución, puertas de calidad). El PoC informa las decisiones, no el código.
+
+## Timebox y Stop-Loss
+
+| Timebox | Acción |
+|---------|--------|
+| 50% del tiempo | Checkpoint: ¿avanzando hacia la respuesta? |
+| 75% del tiempo | Warning: empezar a consolidar hallazgos |
+| 100% del tiempo | ⛔ PARAR. Evaluar con lo que hay |
+| >100% (extendido) | Solo si el usuario lo autoriza explícitamente |
+
+**Regla:** Un PoC que no da respuesta en el timebox es un PoC mal definido, no un PoC que necesita más tiempo.
+
+## Integración con Pipeline
+
+```
+/especdev:poc → hipótesis + código + veredicto
+  ├── ✅ VIABLE → /especdev:poc --graduar → /especdev:proponer → pipeline normal
+  ├── ⚠️ CON RESERVAS → documentar → decisión del usuario
+  ├── ❌ NO VIABLE → documentar → explorar alternativa
+  └── 🔄 INCONCLUSO → reformular hipótesis → nuevo PoC
+```
+
+## Almacenamiento
+
+```
+poc/
+├── websockets-vs-sse/
+│   ├── README.md            # Hipótesis + veredicto
+│   ├── src/                 # Código PoC
+│   └── resultados/          # Evidencia
+├── graphql-migration/
+│   ├── README.md
+│   ├── src/
+│   └── resultados/
+└── _archivo/                # PoCs graduados o descartados
+    └── auth-biometrica/
+```
+
+## Ejemplo Completo
+
+```bash
+/especdev:poc --hipotesis "Podemos usar SQLite en vez de PostgreSQL para el MVP"
+
+=== PoC: SQLite para MVP ===
+
+📋 Fase 1: Hipótesis (2 min)
+  Hipótesis: SQLite es suficiente para MVP (< 100 usuarios, < 10K registros)
+  Criterio de éxito: CRUD funciona, queries < 10ms, datos persisten
+  Criterio de fracaso: Concurrencia falla, queries > 100ms
+  Timebox: 2 horas
+
+🔨 Fase 2: Construir (1h 40min)
+  ✅ Setup SQLite con Prisma
+  ✅ Migración de schema existente
+  ✅ CRUD básico funcionando
+  ✅ Test de concurrencia (10 escrituras paralelas)
+
+📊 Fase 3: Evaluar (10 min)
+  ✅ CRUD: funciona idéntico a PostgreSQL
+  ✅ Queries: 2-5ms (vs 5-15ms en PG local)
+  ⚠️ Concurrencia: WAL mode soporta 10 escrituras paralelas
+  ❌ Limitación: Sin full-text search nativo
+
+📝 Fase 4: Veredicto
+  ⚠️ VIABLE CON RESERVAS
+  - Funciona para MVP si no necesitamos full-text search
+  - Migrar a PostgreSQL será necesario antes de escalar
+  - Recomendación: usar SQLite para MVP, planear migración para v2
+```
+
+## Modelo Recomendado
+
+| Paso | Modelo | Razón |
+|------|--------|-------|
+| Hipótesis | Haiku | Solo estructurar la pregunta |
+| Construir | Sonnet | Código funcional rápido |
+| Evaluar | Haiku | Comparar contra criterios |
+| Veredicto | Haiku | Resumir resultados |
+
+## Guardrails
+
+- **Nunca** commitear al branch principal
+- **Nunca** modificar código de producción existente
+- **Nunca** exceder el timebox sin autorización explícita
+- **Nunca** reutilizar código PoC directamente en producción (graduar primero)
+- **Siempre** definir hipótesis y criterios ANTES de construir
+- **Siempre** documentar el veredicto con evidencia
+- **Siempre** archivar PoCs completados (no dejar código abandonado)

package/comandos/especdev/presentar.md

@@ -0,0 +1,75 @@
+---
+description: Generar presentación interactiva HTML desde contenido del proyecto
+i18n: true
+---
+
+# /especdev:presentar
+
+## Objetivo
+
+Generar presentaciones interactivas como archivos HTML autocontenidos — sin PowerPoint, sin Figma, sin dependencias externas.
+
+## Uso
+
+```
+/especdev:presentar <tema o descripción>
+/especdev:presentar --tema "bold-signal"
+/especdev:presentar --desde pptx input.pptx
+/especdev:presentar --actualizar docs/presentacion/mi-presentacion.html
+```
+
+## Parámetros
+
+| Parámetro | Descripción | Default |
+|-----------|-------------|---------|
+| `<tema>` | Descripción del contenido a presentar | — |
+| `--tema` | Tema visual (ver tabla abajo) | `bold-signal` |
+| `--desde` | Formato de entrada (`pptx`, `md`, `texto`) | — |
+| `--actualizar` | Ruta a presentación existente para actualizar | — |
+| `--slides` | Número máximo de slides | `10` |
+
+## Temas Disponibles
+
+| Tema | Estilo | Ideal para |
+|------|--------|-----------|
+| `bold-signal` | Dark, alto contraste, acentos vibrantes | Demos técnicas |
+| `electric-studio` | Dark, profesional, minimalista | Pitches |
+| `neon-cyber` | Dark, futurista, cyan/magenta | Devtools |
+| `terminal-green` | Dark, hacker, monospace | Conferencias dev |
+| `notebook-tabs` | Light, editorial, tabs de color | Workshops |
+| `pastel-geometry` | Light, amigable, redondeado | Onboarding |
+| `swiss-modern` | Bauhaus, geométrico, precisión | Arquitectura |
+
+## Tecnología
+
+- HTML5/CSS3/JavaScript puro (sin frameworks)
+- Un solo archivo `.html` autocontenido
+- Navegación: flechas, espacio, scroll, swipe
+- Animaciones con Intersection Observer
+- Responsive con `clamp()` para todos los tamaños
+
+## Proceso
+
+1. **Analizar contenido** — Leer el tema/archivo de entrada
+2. **Estructurar slides** — Dividir en secciones lógicas (máx. ~15 slides)
+3. **Aplicar tema** — Usar el tema visual seleccionado
+4. **Generar HTML** — Archivo autocontenido con CSS + JS inline
+5. **Verificar** — Cada slide cabe en 100vh, sin scroll interno
+
+## Guardrails
+
+- Cada slide debe caber en 100vh (sin scroll interno)
+- Imágenes con max-height relativo al viewport
+- Máximo ~15 slides para mantener engagement
+- Google Fonts vía CDN (Inter + JetBrains Mono por defecto)
+- Fuentes, colores y estilos consistentes con el tema elegido
+
+## Habilidad Asociada
+
+Lee `habilidades/presentaciones/HABILIDAD.md` para la referencia técnica completa.
+
+## Ejemplo
+
+```
+/especdev:presentar "Demo de Don Cheli para conferencia de devs" --tema terminal-green --slides 12
+```