don-cheli-sdd 1.13.0

package/comandos/especdev/incorporar.md

@@ -0,0 +1,71 @@
+---
+description: Incorporar nuevo desarrollador al proyecto con contexto completo
+i18n: true
+---
+
+# /especdev:incorporar
+
+## Objetivo
+
+Generar un briefing completo del proyecto para incorporar a un nuevo desarrollador (humano o agente IA) con el contexto necesario para ser productivo inmediatamente.
+
+> Adaptado de `/opsx:onboard` de OpenSpec.
+
+## Uso
+
+```
+/especdev:incorporar
+/especdev:incorporar --rol <backend|frontend|fullstack|devops>
+/especdev:incorporar --profundidad <rapido|completo>
+```
+
+## Output (modo rápido)
+
+```markdown
+# Briefing del Proyecto: Mi-App
+
+## Tech Stack
+- Framework: Next.js 15 + TypeScript 5.7
+- BD: PostgreSQL 16 + Prisma
+- Auth: NextAuth.js v5
+- Tests: Vitest + Playwright
+
+## Arquitectura
+app/
+├── (auth)/          → Rutas de autenticación
+├── (dashboard)/     → Panel principal
+├── api/             → API routes
+└── components/      → UI compartida
+
+## Convenciones
+- Código en inglés, commits en español
+- Branches: feature/, fix/, hotfix/
+- Tests obligatorios para lógica de negocio
+- PR máximo 400 líneas
+
+## Estado Actual
+- Fase: Desarrollo (4 de 7)
+- Cambios activos: 2
+  - agregar-oauth (70% completado)
+  - corregir-timeout (pendiente)
+
+## Para Empezar
+1. `npm install`
+2. `cp .env.example .env.local`
+3. `docker compose up -d` (PostgreSQL)
+4. `npx prisma migrate dev`
+5. `npm run dev`
+
+## Specs Activas
+Ver specs/ para documentación de comportamiento.
+Ver .especdev/cambios/ para cambios en progreso.
+```
+
+## Output (modo completo)
+
+Agrega adicionalmente:
+- Decisiones arquitectónicas (ADRs) desde memoria
+- Errores conocidos y workarounds
+- Guía de debugging
+- Patrones de código con ejemplos
+- Flujo completo de un feature típico

package/comandos/especdev/iniciar.md

@@ -0,0 +1,82 @@
+---
+description: Inicializar Don Cheli en un proyecto nuevo o existente
+i18n: true
+---
+
+# /especdev:iniciar
+
+## Objetivo
+
+Crear el directorio `.especdev/` con todos los archivos de contexto necesarios para comenzar a trabajar con el framework.
+
+## Uso
+
+```
+/especdev:iniciar [opciones]
+```
+
+### Opciones
+
+| Opción | Descripción | Ejemplo |
+|--------|-------------|---------|
+| `--tipo` | Tipo de proyecto | `--tipo cli` |
+| `--nombre` | Nombre del proyecto | `--nombre "mi-app"` |
+| `--gitignore` | Agregar .gitignore template | `--gitignore` |
+| `--con-hooks` | Inicializar hooks locales | `--con-hooks` |
+| `--reparar` | Reparar archivos faltantes | `--reparar` |
+
+## Comportamiento
+
+1. **Detectar idioma** — Leer `${FRAMEWORK_HOME}/locale` (set durante instalación). Si no existe, preguntar al usuario.
+2. **Verificar** si `.especdev/` ya existe
+   - Si existe: preguntar si desea sobrescribir o reparar
+   - Si no existe: continuar
+3. **Crear** directorio `.especdev/`
+4. **Copiar** plantillas desde `plantillas/especdev/`
+5. **Configurar** `config.yaml` con nombre, tipo de proyecto y `framework.idioma` (del locale detectado)
+6. **Inicializar** `estado.md`, `plan.md`, `hallazgos.md`, `progreso.md` — todos en el idioma configurado
+7. **Opcionalmente** crear hooks locales (`--con-hooks`)
+
+**IMPORTANTE:** Todos los archivos generados (.md) deben usar la terminología del idioma configurado. Consultar `locales/{locale}.json` para las traducciones correctas de fases, estados, tipos de proyecto, etc.
+
+## Archivos Creados
+
+```
+.especdev/
+├── config.yaml      # Configuración del proyecto
+├── estado.md        # Estado actual → Fase 1
+├── plan.md          # Plan vacío listo para definir
+├── hallazgos.md     # Descubrimientos (vacío)
+├── progreso.md      # Log de sesión (vacío)
+└── sesion/          # Directorio para PRD y datos de sesión
+```
+
+## Tipos de Proyecto
+
+| Tipo | Descripción |
+|------|-------------|
+| `producto` | Producto completo nuevo |
+| `cli` | Aplicación de línea de comandos |
+| `app` | Aplicación desktop/móvil |
+| `libreria` | Paquete reutilizable |
+| `servicio` | Microservicio/API |
+| `refactor` | Refactoring existente |
+| `correccion` | Corrección de bug |
+
+## Ejemplo
+
+```bash
+/especdev:iniciar --tipo servicio --nombre "api-pagos" --gitignore
+```
+
+Output:
+```
+✅ Don Cheli inicializado
+
+Proyecto: api-pagos
+Tipo: servicio
+Directorio: .especdev/
+Archivos: 5 creados
+
+Próximo paso: edita .especdev/plan.md para definir tus fases
+```

package/comandos/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/comandos/especdev/marketplace.md

@@ -0,0 +1,109 @@
+---
+description: Instalar y gestionar skills desde el marketplace de Anthropic y la comunidad
+i18n: true
+---
+
+# /especdev:marketplace
+
+## Objetivo
+
+Conectar Don Cheli con el ecosystem de Skills de Anthropic y la comunidad. Permite instalar, actualizar y compartir skills desde múltiples fuentes.
+
+## Uso
+
+```
+/especdev:marketplace                              # Listar skills disponibles
+/especdev:marketplace --instalar <nombre>          # Instalar skill específica
+/especdev:marketplace --buscar "weekly report"     # Buscar skills
+/especdev:marketplace --fuente anthropic            # Solo skills oficiales
+/especdev:marketplace --fuente comunidad            # Solo skills de la comunidad
+/especdev:marketplace --exportar <skill>           # Exportar skill para compartir
+/especdev:marketplace --verificar                  # Verificar integridad de skills instaladas
+```
+
+## Fuentes de Skills
+
+### 1. Anthropic Official
+- **Repo:** `https://github.com/anthropics/skills`
+- **Incluye:** document-skills, example-skills (skill-creator, MCP builder, visual design, web testing, etc.)
+- **Instalación:** Automática vía `git clone` selectivo
+
+### 2. Don Cheli Built-in
+- **Ubicación:** `habilidades/` del framework
+- **Incluye:** 42 habilidades especializadas en SDD
+- **Formato:** HABILIDAD.md (compatible con SKILL.md)
+
+### 3. Comunidad
+- **Fuentes:**
+  - `https://skillsmp.com/`
+  - `https://www.aitmpl.com/skills`
+- **Seguridad:** Las skills de la comunidad se instalan en sandbox y requieren revisión manual antes de activar
+
+## Comportamiento
+
+### Instalar desde Anthropic
+```bash
+/especdev:marketplace --instalar document-skills --fuente anthropic
+```
+1. Clonar el repo oficial (o fetch selectivo)
+2. Copiar la skill a `.claude/skills/`
+3. Verificar que el SKILL.md tenga metadata válida
+4. Registrar en el inventario local
+
+### Instalar desde Comunidad
+```bash
+/especdev:marketplace --instalar weekly-report-generator --fuente comunidad
+```
+1. Descargar la skill
+2. **Escaneo de seguridad:** Verificar que no contenga scripts maliciosos
+3. Mostrar el contenido del SKILL.md al usuario para revisión
+4. Instalar solo si el usuario aprueba
+
+### Exportar skill propia
+```bash
+/especdev:marketplace --exportar mi-skill
+```
+1. Empaquetar la skill como ZIP
+2. Generar README con instrucciones de instalación
+3. Opcionalmente publicar como Gist de GitHub
+
+## Compatibilidad de Formatos
+
+| Formato | Extensión | Don Cheli | Anthropic | Comunidad |
+|---------|-----------|-----------|-----------|-----------|
+| HABILIDAD.md | `.md` | Nativo | Requiere conversión | No |
+| SKILL.md | `.md` | Compatible | Nativo | Nativo |
+
+Don Cheli lee ambos formatos automáticamente. Al instalar una skill en formato SKILL.md, se mantiene tal cual (no se convierte).
+
+## Inventario Local
+
+```bash
+/especdev:marketplace --listar
+```
+
+```
+Skills Instaladas
+
+Built-in (Don Cheli):
+  42 habilidades en habilidades/
+
+Anthropic Official:
+  document-skills (v2.1.0)
+  example-skills (v1.5.0)
+
+Comunidad:
+  weekly-report-gen (por @user123) — verificada
+  competitor-analysis (por @user456) — pendiente de revisión
+
+Total: 46 skills activas
+```
+
+## Seguridad
+
+- Skills oficiales de Anthropic: **confianza total**
+- Skills de Don Cheli: **confianza total**
+- Skills de comunidad: **requieren revisión manual**
+  - No ejecutar scripts sin inspección
+  - Verificar que no acceda a archivos fuera del proyecto
+  - Verificar que no envíe datos a servicios externos

package/comandos/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/comandos/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/comandos/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).
+```