# EXAMPLES — Doubt-Driven Review

Tres aplicaciones concretas del skill, dos exitosas y una que detectó decisión bajo-evidencia.

---

## Ejemplo 1 — Decisión que pasó como ROBUSTA

**Contexto**: equipo evalúa migrar de PostgreSQL local a un servicio managed (RDS).

### ❌ Sin doubt-driven (hipotético)

> "RDS es la mejor opción porque AWS lo recomienda y todos lo usan."

Costo de revertir no estimado, alternativas no articuladas, cero contraevidencia.
Decisión se toma. 8 meses después se descubre que la latencia p95 desde el
único cluster on-premise legacy del cliente sube 40ms y rompe SLA.

### ✓ Con doubt-driven

**Paso 1 — Articular**:
- Qué se decide: migrar a RDS Aurora PostgreSQL en us-east-1.
- Qué se descarta: mantener PostgreSQL self-hosted en EC2.
- Costo de revertir: ~3 semanas (migrar datos de vuelta, reconfigurar backups, ajustar IAM).

**Paso 2 — 3 alternativas**:
1. **Self-hosted PostgreSQL en EC2**: control total de versión y extensiones; descartada
   por costo operativo (on-call para BD).
2. **Cloud SQL en GCP**: feature parity con RDS; descartada porque el resto del
   stack ya está en AWS y multi-cloud agrega complejidad de red.
3. **Supabase managed**: incluye Auth + Realtime gratis; descartada porque el
   equipo no necesita Realtime y el lock-in en API propietario es alto.

**Paso 3 — Contraevidencia**:
- Falla 1 (prob: media): vendor lock-in si Aurora introduce features no portables → mitigación: limitar uso a SQL estándar.
- Falla 2 (prob: baja): outage regional de us-east-1 → mitigación: read replica en us-west-2.
- Falla 3 (prob: baja): costo de I/O excede presupuesto → mitigación: alertas de costo en CloudWatch.
- Caso histórico: cliente X migró a RDS, descubrió que `pg_cron` no estaba disponible y refactoró 3 jobs.
- Supuesto sin validar: "la latencia desde nuestros clientes on-premise será aceptable" — necesita pruebas reales.

**Paso 4 — Red flags**: ninguno. Cada argumento está respaldado con caso o métrica.

**Paso 5 — Trigger**:
- Condición: "p95 de latencia desde el cliente legacy excede 200ms durante 7 días consecutivos" o "costo mensual supera $1500".
- Fecha de reevaluación: 2026-11-15 (6 meses).

**Veredicto**: ROBUSTA con 1 supuesto pendiente de validar (latencia on-premise → ejecutar prueba antes de migrar).

---

## Ejemplo 2 — Decisión BAJO-EVIDENCIA detectada

**Contexto**: agente propone "vamos a usar Kafka para todos los flujos asíncronos del sistema."

**Paso 1 — Articular**:
- Qué se decide: introducir Apache Kafka como broker único.
- Qué se descarta: Redis Streams + RabbitMQ ya existentes en el stack.
- Costo de revertir: alto — requiere rehacer 12 productores y 8 consumidores.

**Paso 2 — 3 alternativas**: el agente solo articula 1 (RabbitMQ) y dice "los demás
no son comparables." → **Red flag**: incapacidad de articular 3 alternativas reales.

**Paso 3 — Contraevidencia**: el agente dice "Kafka nunca falla en producción
porque tiene replication." → **Red flag**: argumento sin caso histórico.

**Paso 4 — Red flags**:
- "Es la mejor práctica para event-driven architectures" (sin fuente).
- "Todo el mundo lo usa a escala" (sin métrica del proyecto actual).
- "No hay otra opción razonable" (contradicho por el paso 2 incompleto).

**Paso 5 — Trigger**: "cuando lo necesitemos a más escala" — **Trigger inverificable**.
Reescribir como "throughput supera 10k msg/s sostenido durante 14 días."

**Veredicto**: BAJO-EVIDENCIA. Reabrir antes de comprometer.

Resultado real: la decisión se difiere; al revisar, se descubre que el throughput
actual del sistema es ~80 msg/s — Kafka habría sido sobre-ingeniería con costo
operativo de un cluster que el equipo no tiene capacidad de mantener.

---

## Ejemplo 3 — Decisión ACEPTABLE con red flag documentado

**Contexto**: elegir framework frontend para un dashboard interno nuevo.

**Paso 1**:
- Qué se decide: Next.js App Router + Server Components.
- Qué se descarta: SPA con Vite + React Query.
- Costo de revertir: medio — 2 semanas de migración + reescritura de data fetching.

**Paso 2 — 3 alternativas**:
1. **SPA Vite + React Query**: más simple, menos magia; descartada porque queremos SSR para SEO interno y autenticación server-side.
2. **Remix**: nested routing nativo; descartada porque el equipo ya tiene experiencia con Next.js y la curva de Remix agrega 2 semanas.
3. **Astro con islands**: ideal si fuera contenido estático; descartada porque el dashboard es 80% interactivo.

**Paso 3 — Contraevidencia**:
- Falla 1 (prob: media): App Router introduce breaking changes y rompe el build (ya pasó con v13→v14).
- Falla 2 (prob: baja): RSC mental model genera bugs sutiles de hidratación.
- Falla 3 (prob: baja): vendor lock-in con Vercel — mitigación: deploy en Cloudflare Workers o self-hosted.
- Caso histórico: equipo Y adoptó App Router en beta y tardó 3 meses en estabilizar.
- Supuesto: "el equipo aprenderá RSC en 2 sprints" — moderadamente optimista.

**Paso 4 — Red flags**:
- "App Router es el futuro" (cita de blog post de Vercel — sesgo de fuente).

**Paso 5 — Trigger**:
- Condición: "≥3 bugs de hidratación reportados por usuarios en sprint 5" O "Vercel
  anuncia deprecation de App Router".
- Fecha de reevaluación: 2026-08-15 (3 meses, periodo corto por uso de feature reciente).

**Veredicto**: ACEPTABLE — 1 red flag documentado (cita de Vercel como fuente única
para "futuro"). El equipo procede con awareness del sesgo.

---

## Patrón de aplicación

| Ejemplo | Costo revertir | Alternativas articuladas | Red flags | Trigger | Veredicto |
|---|---|---|---|---|---|
| 1 — RDS | 3 semanas | 3 sólidas | 0 | Métrico claro | ROBUSTA |
| 2 — Kafka | 12+8 servicios | 1 (incompleto) | 3 | Inverificable | BAJO-EVIDENCIA |
| 3 — Next.js | 2 semanas | 3 sólidas | 1 (sesgo de fuente) | Métrico + evento externo | ACEPTABLE |

El skill es útil cuando:
- El costo de revertir es alto Y
- Hay tendencia a saltar al "qué" sin articular el "por qué no las otras".

Es overhead cuando:
- La decisión es reversible en horas O
- La decisión ya fue auditada por un proceso equivalente (ADR formal con contexto + alternativas + consecuencias).
