don-cheli-sdd 1.13.0

package/scripts/.claude/commands/especdev/limpiar-slop.md

@@ -0,0 +1,88 @@
+---
+description: Eliminar slop de código generado por IA antes de commits
+i18n: true
+---
+
+# /especdev:limpiar-slop
+
+## Objetivo
+
+Detectar y eliminar **slop** — código innecesario, verbose, o sobre-ingenierizado que los modelos de IA generan frecuentemente. Se ejecuta sobre el diff del branch actual vs main.
+
+> Adaptado de `deslop` de Pro-Workflow (rohitg00/pro-workflow).
+
+## Uso
+
+```
+/especdev:limpiar-slop                    # Limpiar branch actual
+/especdev:limpiar-slop --preview          # Solo mostrar, no editar
+/especdev:limpiar-slop --archivo archivo  # Limpiar un solo archivo
+```
+
+## Qué es Slop
+
+Código que la IA genera pero que un dev senior eliminaría:
+
+| Patrón de Slop | Ejemplo | Corrección |
+|----------------|---------|------------|
+| **Comentarios obvios** | `// Get the user` antes de `getUser()` | Eliminar |
+| **Try/catch defensivo** | Try/catch en código interno confiable | Eliminar si no es boundary |
+| **Cast a `any`** | `(data as any).name` | Tipar correctamente |
+| **Abstracciones prematuras** | Factory para un solo uso | Inlinear |
+| **Nesting profundo** | 4+ niveles de if/else | Early returns |
+| **Re-exports innecesarios** | `export { thing } from './thing'` solo para "limpiar" | Eliminar |
+| **Scope creep** | Refactors no solicitados | Revertir |
+| **Docstrings en código no tocado** | JSDoc nuevo en funciones existentes | Eliminar |
+| **Error handling imposible** | Catch de errores que no pueden ocurrir | Eliminar |
+
+## Comportamiento
+
+1. **Obtener diff** contra main
+2. **Escanear** los 9 patrones de slop
+3. **Proponer** edits mínimos y focalizados
+4. **Verificar** que el comportamiento no cambia (tests)
+5. **Resumir** lo limpiado
+
+## Output
+
+```
+=== Limpieza de Slop ===
+
+Archivos escaneados: 8
+Patrones encontrados: 12
+
+🧹 Comentarios obvios: 5
+  - src/services/auth.ts:24 — "// Authenticate the user"
+  - src/services/auth.ts:38 — "// Return the token"
+  - src/utils/format.ts:12 — "// Format the date"
+  ...
+
+🧹 Try/catch defensivo: 3
+  - src/services/payment.ts:45 — try/catch en helper interno
+  - src/db/queries.ts:23 — catch vacío
+  ...
+
+🧹 Abstracciones prematuras: 2
+  - src/utils/createHandler.ts — Factory usado 1 sola vez
+  - src/helpers/wrapResponse.ts — Wrapper innecesario
+  ...
+
+🧹 Scope creep: 2
+  - src/middleware/cors.ts — Refactor no solicitado
+  ...
+
+Tests después de limpieza: ✅ 47/47 pasan
+Líneas eliminadas: 34
+Comportamiento: sin cambios
+
+Resumen: Eliminados 5 comentarios obvios, 3 try/catch defensivos,
+         2 abstracciones prematuras, y 2 cambios fuera de scope.
+```
+
+## Guardrails
+
+- **NO cambiar comportamiento** — Solo eliminar ruido
+- **Edits mínimos** — No reescribir, solo limpiar
+- **3 líneas similares > abstracción prematura** — Duplicar es ok
+- **Verificar antes de borrar** — Confirmar que no se usa
+- **Ejecutar tests** — Si fallan, revertir

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

@@ -0,0 +1,31 @@
+---
+description: Guardar insights importantes para referencia futura
+i18n: true
+---
+
+# /especdev:memorizar
+
+## Objetivo
+
+Guardar un insight o aprendizaje importante en `.especdev/hallazgos.md` para que persista entre sesiones.
+
+## Uso
+
+```
+/especdev:memorizar <insight>
+```
+
+## Ejemplo
+
+```bash
+/especdev:memorizar "Los índices compuestos en MongoDB mejoran 10x las consultas de búsqueda con filtros múltiples"
+```
+
+Agrega al archivo `.especdev/hallazgos.md`:
+
+```markdown
+### 2026-03-21 15:30
+**Insight:** Los índices compuestos en MongoDB mejoran 10x las consultas de búsqueda con filtros múltiples
+**Contexto:** Implementación de API de búsqueda en Fase 4
+**Categoría:** Rendimiento
+```

package/scripts/.claude/commands/especdev/mesa-redonda.md

@@ -0,0 +1,60 @@
+---
+description: Discusión multi-perspectiva exploratoria con roles senior sobre un tema
+i18n: true
+---
+
+# /especdev:mesa-redonda
+
+## Objetivo
+
+Iniciar una discusión exploratoria multi-perspectiva donde roles senior comparten su visión sobre un tema. A diferencia de `/especdev:debate` (que busca tensión adversarial), la mesa redonda busca **explorar opciones** y construir sobre las ideas de los demás.
+
+## Uso
+
+```
+/especdev:mesa-redonda "<tema>"
+/especdev:mesa-redonda --roles "CPO,Arquitecto,Negocio" "<tema>"
+```
+
+## Roles Disponibles
+
+| Rol | Perspectiva | Enfoque |
+|-----|-------------|---------|
+| **CPO** | Visión de producto | Roadmap, priorización, métricas de adopción |
+| **Arquitecto** | Sistema y escalabilidad | Performance, mantenibilidad, deuda técnica |
+| **UX Lead** | Experiencia de usuario | Usabilidad, accesibilidad, research, conversión |
+| **Negocio** | Viabilidad comercial | ROI, unit economics, ventaja competitiva |
+| **QA Lead** | Calidad y testing | Testability, edge cases, automatización |
+| **Seguridad** | Protección y compliance | OWASP, regulaciones, datos sensibles |
+| **DevOps** | Operaciones | Observabilidad, CI/CD, costos infra |
+
+Default: CPO, Arquitecto, UX Lead, Negocio.
+
+## Ejemplo
+
+```bash
+/especdev:mesa-redonda "¿Deberíamos usar microservicios o monolito?"
+
+=== Mesa Redonda ===
+Tema: ¿Microservicios o monolito?
+
+📦 CPO: Con un equipo de 5 personas y sin product-market fit confirmado,
+   la velocidad de iteración es más valiosa que la escalabilidad.
+   Un monolito nos deja lanzar features 2-3x más rápido...
+
+🏗️ Arquitecto: Dado nuestro equipo de 5 personas, un monolito modular
+   nos permite movernos más rápido sin la complejidad operacional.
+   Shopify escala con monolito — no es limitante...
+
+🎨 UX Lead: Un solo codebase significa design system centralizado y
+   latencia consistente. La experiencia del usuario es más predecible
+   cuando no hay hops entre servicios...
+
+💼 Negocio: Microservicios agregarían ~$3-5K/mes en infra y 30% más
+   tiempo en DevOps. Para pre-Serie A, cada mes de runway cuenta.
+   Los inversores quieren tracción, no arquitectura...
+
+=== Consenso ===
+Monolito modular con interfaces claras. Revisión de arquitectura
+al llegar a 10K usuarios o 10 developers.
+```

package/scripts/.claude/commands/especdev/mesa-tecnica.md

@@ -0,0 +1,144 @@
+---
+description: Mesa técnica de expertos senior de desarrollo para decisiones de implementación, stack y código
+i18n: true
+---
+
+# /especdev:mesa-tecnica
+
+## Objetivo
+
+Convocar una mesa de expertos técnicos senior — todos con +15 años de experiencia en su área — para discutir decisiones de implementación, patrones de código, elección de stack, performance, y problemas técnicos complejos. Cada experto aporta desde la trinchera: código real, incidentes vividos, y lecciones aprendidas.
+
+A diferencia de `/especdev:debate` (tensión adversarial cross-funcional) y `/especdev:mesa-redonda` (exploración producto-negocio), la mesa técnica es **100% ingeniería**: cómo se construye, cómo escala, cómo se mantiene.
+
+## Uso
+
+```
+/especdev:mesa-tecnica "<tema>"
+/especdev:mesa-tecnica --roles "Backend,Frontend,Arquitecto" "<tema>"
+/especdev:mesa-tecnica --preset infra "<tema>"
+```
+
+## Roles Disponibles
+
+### Core (participan por default)
+
+| Rol | Perfil | Dominio | Aporta |
+|-----|--------|---------|--------|
+| **Tech Lead** | +15 años liderando equipos técnicos | Decisiones cross-cutting, trade-offs de equipo, priorización técnica | Visión holística, impacto en velocity del equipo, deuda técnica vs entrega, estándares de código |
+| **Arquitecto** | +15 años diseñando sistemas distribuidos | System design, patrones de integración, evolución de arquitectura | Diagramas C4, ADRs, patterns (CQRS, Event Sourcing, Saga), anti-patterns, boundaries |
+| **Sr. Backend** | +15 años en sistemas de alta concurrencia | APIs, bases de datos, colas, caching, concurrencia | Patrones de resiliencia (circuit breaker, retry, bulkhead), optimización de queries, connection pooling, race conditions |
+| **Sr. Frontend** | +15 años en aplicaciones web/mobile complejas | UI frameworks, state management, rendering, bundle optimization | Performance (Core Web Vitals, LCP < 2.5s), SSR vs CSR vs ISR, accesibilidad, design systems, micro-frontends |
+| **Sr. DevOps/SRE** | +15 años en infraestructura y operaciones | CI/CD, containers, observabilidad, incident response | IaC (Terraform/Pulumi), SLOs/SLIs, runbooks, cost optimization, zero-downtime deploys |
+
+### Especialistas (invocables con --roles)
+
+| Rol | Perfil | Dominio | Aporta |
+|-----|--------|---------|--------|
+| **Sr. DBA** | +15 años en modelado y optimización de datos | SQL/NoSQL, sharding, replicación, migraciones | Explain plans, índices, partitioning, connection limits, backup/recovery, CAP theorem en la práctica |
+| **Sr. Seguridad** | +15 años en AppSec y pentesting | OWASP, threat modeling, criptografía aplicada | Vectores de ataque, auth flows (OAuth2/OIDC), secrets management, supply chain security |
+| **Sr. QA/SDET** | +15 años en testing y calidad de software | Test strategy, automation frameworks, performance testing | Pirámide de tests, contract testing, chaos engineering, load testing (k6, Gatling), flaky tests |
+| **Sr. Mobile** | +15 años en desarrollo nativo y cross-platform | iOS/Android, React Native, Flutter | Offline-first, push notifications, deep linking, app size, battery/memory optimization |
+| **Sr. Data/ML** | +15 años en pipelines de datos e ML en producción | ETL, feature stores, model serving, data quality | Batch vs streaming, data contracts, model drift, A/B testing infrastructure |
+
+### Presets
+
+| Preset | Roles incluidos | Mejor para |
+|--------|----------------|------------|
+| (default) | Tech Lead, Arquitecto, Sr. Backend, Sr. Frontend, Sr. DevOps | Decisiones de implementación generales |
+| `--preset backend` | Tech Lead, Arquitecto, Sr. Backend, Sr. DBA, Sr. Seguridad | APIs, servicios, bases de datos |
+| `--preset frontend` | Tech Lead, Sr. Frontend, Sr. UX/UI, Sr. QA | UI, performance web, design systems |
+| `--preset infra` | Tech Lead, Arquitecto, Sr. DevOps, Sr. DBA, Sr. Seguridad | Infraestructura, deploys, escalabilidad |
+| `--preset fullstack` | Tech Lead, Arquitecto, Sr. Backend, Sr. Frontend, Sr. DevOps, Sr. DBA | Decisiones end-to-end |
+
+## Reglas de Engagement
+
+### Regla de Código
+Los expertos DEBEN ilustrar sus puntos con pseudocódigo, snippets, o configuración concreta cuando aplique. No basta con decir "usar caching" — hay que mostrar dónde, cómo, y con qué TTL.
+
+### Regla de Incidentes
+Cada experto DEBE respaldar sus argumentos con al menos uno de:
+- **Incidente real**: "En producción con 50K RPM, este patrón causó..." (propio o documentado públicamente)
+- **Benchmark**: dato medido de performance, throughput, o latencia
+- **Post-mortem público**: referencia a un caso conocido de la industria (Cloudflare, GitHub, Stripe, etc.)
+
+Argumentos sin respaldo práctico se marcan como `[teórico]`.
+
+### Regla de Complejidad
+Antes de proponer una solución, cada experto DEBE evaluar:
+- **Complejidad accidental** que introduce (configuración, dependencias, cognitive load)
+- **Costo operativo** a 6 meses (quién lo mantiene, quién lo debugea a las 3am)
+- **Alternativa más simple** que resuelve el 80% del problema
+
+### Regla de Consenso Técnico
+La mesa NO busca unanimidad. Busca:
+1. **Decisión clara** con owner responsable
+2. **Trade-offs explícitos** que todos entienden
+3. **Señales de alerta** (métricas que indican cuándo revisar la decisión)
+4. **Plan B documentado** si la decisión no funciona
+
+## Output
+
+```markdown
+## Mesa Técnica: ¿Redis o Memcached para caching de sesiones?
+
+### Tech Lead — Contexto y constraints
+- Equipo de 8 devs, 3 con experiencia en Redis, 0 en Memcached
+- SLA actual: p99 < 500ms, target: p99 < 200ms
+- Budget: no queremos agregar más de $200/mes en infra
+- **Prioridad**: simplicidad operativa > features avanzadas
+- ⚠️ Cualquier solución que requiera expertise que no tenemos es un riesgo de bus factor
+
+### Arquitecto — System design
+- Redis como cache + session store simplifica la topología (1 sistema menos)
+- Patrón recomendado: cache-aside con TTL de 15min para sesiones
+- ```
+  Client → API Gateway → App Server → Redis (cache-aside)
+                                     ↘ PostgreSQL (source of truth)
+  ```
+- Memcached es stateless y más fácil de escalar horizontalmente, pero perdemos pub/sub que necesitaremos para invalidación de cache distribuida
+- ⚠️ Redis single-threaded: con >100K ops/s considerar Redis Cluster
+
+### Sr. Backend — Implementación
+- Redis con connection pooling (max 20 conns por instancia):
+  ```python
+  redis_pool = redis.ConnectionPool(
+      host='redis-primary', port=6379,
+      max_connections=20, socket_timeout=0.1,
+      retry_on_timeout=True
+  )
+  ```
+- Patrón de fallback: si Redis cae, sesiones se recrean desde DB (graceful degradation)
+- Incidente propio: sin socket_timeout, un Redis lento cascadeó y tumbó 3 servicios (2022)
+- ⚠️ Serialización: usar msgpack (3x más rápido que JSON para session payloads de ~2KB)
+
+### Sr. Frontend — Impacto en UX
+- Sesiones de 15min TTL implican re-auth frecuente — medir tasa de "session expired" en analytics
+- Si caching reduce p99 de 500ms a 200ms, el LCP mejora ~300ms (medido con RUM, correlación directa)
+- ⚠️ Sliding window en TTL (renovar en cada request) evita UX de "me sacó de la sesión" pero complica invalidación
+
+### Sr. DevOps — Operaciones
+- Redis en managed service (ElastiCache/Upstash): ~$50/mes para nuestro volumen
+- Monitoring: redis_connected_clients, redis_memory_used, cache_hit_ratio (target >95%)
+- Runbook: si hit ratio < 80%, investigar TTL o key eviction policy
+- Post-mortem relevante: GitHub degraded performance (2023) por Redis memory fragmentation sin monitoreo
+- ⚠️ Backup: Redis RDB snapshots cada 6h, no confiar en Redis como source of truth
+
+### Tensiones técnicas
+1. TTL fijo (Arquitecto: simple) vs sliding window (Frontend: mejor UX) → **Decisión: sliding con cap de 2h**
+2. Managed service (DevOps: menos ops) vs self-hosted (Backend: más control) → **Decisión: managed**
+3. Single node (simple) vs cluster (resiliente) → **Decisión: single node ahora, cluster cuando >50K RPM**
+
+### Decisión: Redis managed (ElastiCache) con cache-aside
+- **Owner**: Sr. Backend implementa, Sr. DevOps configura infra y monitoring
+- **Timeline**: 3 días de implementación + 2 días de load testing
+- **Métricas de éxito**: p99 < 200ms, hit ratio > 95%, zero session-related incidents/mes
+
+### Señales de alerta (cuándo revisitar)
+- Cache hit ratio < 85% sostenido por 1 semana
+- Redis memory > 70% del allocated
+- Más de 50K RPM sostenido → evaluar cluster
+
+### Plan B
+Si Redis introduce más problemas que los que resuelve en los primeros 30 días, rollback a sesiones en PostgreSQL con pgbouncer + prepared statements (ya testeado, p99 ~350ms).
+```

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

@@ -0,0 +1,237 @@
+---
+description: Planificar y ejecutar migración entre stacks tecnológicos o versiones mayores
+i18n: true
+---
+
+# /especdev:migrar
+
+## Objetivo
+
+Planificar y ejecutar migraciones de stacks tecnológicos (Vue→React, Express→Fastify) o actualizaciones de versiones mayores (Next.js 14→15, Python 3.9→3.12), minimizando riesgo de regresión.
+
+## Uso
+
+```
+/especdev:migrar --de "Vue 3" --a "React 19"
+/especdev:migrar --de "Express 4" --a "Fastify 5"
+/especdev:migrar --de "Next.js 14" --a "Next.js 15"
+/especdev:migrar --de "Python 3.9" --a "Python 3.12"
+/especdev:migrar --de "REST" --a "GraphQL"
+/especdev:migrar --de "JavaScript" --a "TypeScript"
+/especdev:migrar --solo-plan                          # Solo generar plan, no ejecutar
+```
+
+## Tipos de Migración
+
+| Tipo | Ejemplo | Riesgo | Enfoque |
+|------|---------|--------|---------|
+| **Framework** | Vue→React, Django→FastAPI | Alto | Rewrite incremental |
+| **Versión mayor** | Next 14→15, Angular 17→19 | Medio | Upgrade guiado por changelog |
+| **Lenguaje** | JS→TS, Python 2→3 | Alto | Codemods + revisión manual |
+| **Paradigma** | REST→GraphQL, Monolito→Micro | Muy alto | Strangler Fig pattern |
+| **Base de datos** | MySQL→PostgreSQL, Mongo→PG | Alto | Dual-write + migración |
+
+## Proceso (6 fases)
+
+### Fase 1: Inventario (automático)
+
+Mapear el estado actual del proyecto:
+
+```markdown
+## Inventario de Migración: Vue 3 → React 19
+
+### Stack Actual
+- Framework: Vue 3.4 + Composition API
+- Estado: Pinia 2.1
+- Router: vue-router 4.3
+- UI: Vuetify 3
+- Build: Vite 5
+- Tests: Vitest + Vue Test Utils
+
+### Alcance
+- Componentes: 47
+- Stores: 8
+- Rutas: 23
+- Tests: 112
+- LOC: 12,400
+
+### Dependencias Vue-Específicas
+| Dependencia | Alternativa React | Complejidad |
+|-------------|-------------------|-------------|
+| Pinia | Zustand / Redux Toolkit | Baja |
+| vue-router | React Router v7 | Media |
+| Vuetify | shadcn/ui + TailwindCSS | Alta |
+| Vue Test Utils | React Testing Library | Media |
+| Composables (12) | Custom hooks | Baja |
+```
+
+### Fase 2: Mapa de Equivalencias
+
+Traducir conceptos entre ecosistemas:
+
+```markdown
+## Equivalencias Vue → React
+
+| Vue | React | Notas |
+|-----|-------|-------|
+| `<template>` | JSX | Diferente sintaxis, misma función |
+| `ref()` / `reactive()` | `useState()` | Reactividad automática vs explícita |
+| `computed()` | `useMemo()` | Semántica similar |
+| `watch()` / `watchEffect()` | `useEffect()` | Cuidado con el array de deps |
+| `onMounted()` | `useEffect(() => {}, [])` | Lifecycle → effects |
+| `provide/inject` | `Context API` | Para estado compartido profundo |
+| `v-if` / `v-for` | `{condition && ...}` / `.map()` | JSX condicional |
+| `v-model` | `value` + `onChange` | Two-way vs one-way binding |
+| Pinia store | Zustand store | API muy similar |
+| `<slot>` | `children` / `render props` | Composición de componentes |
+| Directive (`v-tooltip`) | HOC o hook | Sin equivalente directo |
+| `<Transition>` | `framer-motion` | Animaciones |
+```
+
+### Fase 3: Estrategia de Migración
+
+Elegir enfoque según riesgo:
+
+#### Opción A: Big Bang (riesgo alto, rápido)
+```
+Reescribir todo de una vez.
+✅ Para: proyectos pequeños (< 20 componentes)
+❌ No para: proyectos en producción con usuarios activos
+```
+
+#### Opción B: Strangler Fig (riesgo bajo, gradual) ← Recomendado
+```
+Migrar componente por componente, coexistiendo ambos frameworks.
+
+Fase 1: Setup React junto a Vue (micro-frontend o iframe)
+Fase 2: Migrar componentes leaf (sin hijos Vue)
+Fase 3: Migrar componentes intermedios
+Fase 4: Migrar componentes root
+Fase 5: Remover Vue
+```
+
+#### Opción C: Parallel Run (riesgo medio)
+```
+Construir la versión React en paralelo, switchear cuando esté lista.
+✅ Para: aplicaciones críticas que no pueden tener downtime
+❌ Costoso en tiempo (mantener dos codebases)
+```
+
+### Fase 4: Plan de Migración
+
+Genera `.especdev/migracion/plan-migracion.md`:
+
+```markdown
+## Plan de Migración: Vue → React
+
+### Orden de Migración (por dependencias)
+
+#### Wave 1: Infraestructura (sin UI)
+- [ ] M001: Setup React + Vite + TypeScript
+- [ ] M002: Configurar React Router (mapear rutas existentes)
+- [ ] M003: Configurar Zustand (mapear stores Pinia)
+- [ ] M004: Setup React Testing Library
+
+#### Wave 2: Componentes Atómicos (sin dependencias internas)
+- [ ] M005: Migrar Button, Input, Modal (Vuetify → shadcn/ui)
+- [ ] M006: Migrar layout components (Header, Sidebar, Footer)
+- [ ] M007: Tests para componentes migrados
+
+#### Wave 3: Componentes con Estado
+- [ ] M008: Migrar stores Pinia → Zustand (uno por uno)
+- [ ] M009: Migrar composables → custom hooks
+- [ ] M010: Migrar formularios con validación
+
+#### Wave 4: Páginas y Rutas
+- [ ] M011: Migrar páginas leaf (sin sub-rutas)
+- [ ] M012: Migrar páginas con sub-rutas
+- [ ] M013: Migrar guards de ruta → loader/middleware
+
+#### Wave 5: Cleanup
+- [ ] M014: Remover dependencias Vue
+- [ ] M015: Actualizar CI/CD
+- [ ] M016: Actualizar documentación
+
+### Tests de Regresión por Wave
+Cada wave ejecuta:
+1. Tests unitarios de componentes migrados
+2. Tests de integración de rutas migradas
+3. Tests end-to-end del flujo completo
+4. Comparación visual (screenshot diff) si aplica
+```
+
+### Fase 5: Ejecución
+
+Cada tarea de migración sigue el ciclo:
+
+```
+1. Leer componente/módulo Vue
+2. Mapear a equivalencia React
+3. Escribir test React (RED)
+4. Implementar componente React (GREEN)
+5. Verificar paridad funcional
+6. Commit atómico: "migrate: ComponentName Vue→React"
+```
+
+### Fase 6: Verificación Post-Migración
+
+```markdown
+## Checklist Post-Migración
+
+### Funcionalidad
+- [ ] Todas las rutas funcionan
+- [ ] Formularios envían datos correctamente
+- [ ] Estado se persiste entre navegaciones
+- [ ] Auth flow completo funciona
+
+### Rendimiento
+- [ ] Bundle size ≤ original (o justificar)
+- [ ] LCP ≤ original
+- [ ] No memory leaks en SPA navigation
+
+### Calidad
+- [ ] Coverage de tests ≥ original
+- [ ] 0 dependencias Vue restantes
+- [ ] Sin TODOs de migración pendientes
+- [ ] CI/CD actualizado y pasando
+```
+
+## Formato de Commits de Migración
+
+```
+migrate: <componente/módulo> <origen>→<destino>
+migrate: Button component Vue→React
+migrate: auth store Pinia→Zustand
+migrate: /dashboard route vue-router→react-router
+```
+
+## Almacenamiento
+
+```
+.especdev/migracion/
+├── inventario.md          # Estado actual del proyecto
+├── equivalencias.md       # Mapa de traducciones
+├── plan-migracion.md      # Plan con waves y tareas
+├── progreso-migracion.md  # Tracking de avance
+└── post-migracion.md      # Checklist de verificación
+```
+
+## Integración con Pipeline
+
+```
+/especdev:migrar → inventario + equivalencias + plan
+  → /especdev:poc (opcional) → validar enfoque en módulo piloto
+  → /especdev:implementar → ejecutar por waves
+  → /especdev:auditar-seguridad → verificar que migración no introduce vulnerabilidades
+  → /especdev:revisar → review final
+```
+
+## Guardrails
+
+- **Nunca** migrar sin tests de regresión del sistema original
+- **Nunca** migrar todo de una vez en proyectos en producción (usar Strangler Fig)
+- **Siempre** mantener paridad funcional (no agregar features durante migración)
+- **Siempre** commit atómico por componente/módulo migrado
+- **Siempre** verificar rendimiento post-migración (bundle size, LCP)
+- **Siempre** ejecutar tests e2e del flujo completo después de cada wave
+- Si la migración afecta > 30% del codebase → confirmar con usuario antes de cada wave