@saulwade/swl-ses 1.4.1 → 1.4.2

package/habilidades/doubt-driven-review/SKILL.md

@@ -1,171 +1,171 @@
----
-name: doubt-driven-review
-description: >
-  Adversarial peer review de decisiones técnicas antes de comprometerlas.
-  Cuestiona supuestos, fuerza la articulación de alternativas descartadas y
-  detecta confianza injustificada. Cargar antes de decidir arquitecturas
-  irreversibles, elegir un framework crítico, definir un contrato de API
-  público o aprobar un PR de alto impacto. NO cubre adversarial review de
-  memoria (eso lo hace red-team-swl) ni de seguridad de código (eso lo hace
-  revisor-seguridad-swl) — este skill se especializa en decisiones técnicas
-  con costo de cambio alto.
----
-
-# Doubt-Driven Review
-
-## Cuándo cargar
-
-- Antes de aprobar un ADR que toma una decisión irreversible.
-- Antes de comprometer un contrato público de API o un schema de BD que afecta integraciones externas.
-- Antes de elegir un framework, librería o patrón con costo de migración alto.
-- Antes de fusionar un PR cuyo blast radius incluye módulos críticos.
-- Cuando el equipo o el agente exhibe **alta confianza con baja evidencia** sobre una decisión técnica.
-
-## Cuándo NO cargar
-
-- Para revisar código por calidad — eso es `revisor-codigo-swl` con `Skill("checklist-calidad")`.
-- Para revisar seguridad — eso es `revisor-seguridad-swl` con `Skill("checklist-seguridad")`.
-- Para validar memoria contra prompt injection o privacidad — eso es `red-team-swl`.
-- Para discutir alcances con el usuario — eso es `Skill("brainstorming")` o `swl:discutir-fase`.
-- Para fixes triviales o decisiones reversibles en menos de 10 minutos.
-
-## Principio
-
-> Una decisión cuya alternativa no se ha articulado, no es una decisión:
-> es una preferencia. Toda decisión técnica con costo de cambio alto debe
-> sobrevivir a un round adversarial antes de comprometerse.
-
-El skill ejecuta un protocolo en 5 pasos. Cada paso produce evidencia en
-texto. La salida del skill NO aprueba ni rechaza — produce un reporte que
-el agente o usuario humano usa para decidir.
-
-## Protocolo
-
-### Paso 1 — Articular la decisión y su irreversibilidad
-
-Pedir explícitamente:
-
-- **Qué se decide**: 1-3 oraciones, sin jerga ambigua.
-- **Qué se descarta**: la decisión opuesta concreta.
-- **Costo de revertir**: estimación en turnos / archivos / horas si en 3 meses se concluye que fue incorrecta.
-
-Si el costo de revertir es < 4 horas y < 5 archivos: la decisión NO es candidata
-a doubt-driven review. Cerrar el skill y proceder.
-
-### Paso 2 — Forzar 3 alternativas descartadas
-
-El agente o usuario debe articular las 3 alternativas más fuertes que NO se eligieron, con:
-
-- Por qué cada una es plausible (≥ 1 razón concreta).
-- Qué tradeoff la hace inferior a la elegida (sin frase genérica como "menos flexible").
-
-Si la persona/agente no puede articular 3 alternativas: **señal de decisión bajo-evidencia**.
-Reportar: "Decisión propuesta sin alternativas articuladas. Riesgo de selección por inercia."
-
-### Paso 3 — Buscar contraevidencia activamente
-
-Para la decisión propuesta:
-
-- Listar 3 escenarios donde la decisión **fallaría** o produciría costos no anticipados.
-- Listar 1 caso histórico (dentro o fuera del proyecto) donde una decisión similar resultó incorrecta.
-- Identificar 1 supuesto de la decisión que NO está validado con evidencia (corre el riesgo de ser falso).
-
-Si los 3 escenarios de falla son improbables Y el supuesto está validado: la decisión gana robustez.
-Si ≥ 1 escenario tiene probabilidad ≥ 30%: documentar el riesgo en el reporte.
-
-### Paso 4 — Detectar confianza injustificada
-
-Patrones a marcar como red flags:
-
-- "Es la mejor práctica" sin citar fuente o caso.
-- "Siempre se hace así" sin verificar el contexto del proyecto actual.
-- "Es lo que recomienda <autoridad>" sin verificar que la recomendación aplica al stack/escala/dominio.
-- "No hay otra opción razonable" cuando el paso 2 ya forzó 3 alternativas.
-- Cita de un blog post o tweet como evidencia única.
-- Argumentos de tipo "todo el mundo lo usa" sin métrica concreta.
-
-Por cada red flag detectado: 1 línea en el reporte con cita textual del argumento.
-
-### Paso 5 — Trigger de reversión
-
-Toda decisión que pase doubt-driven review debe incluir:
-
-- **Trigger de reversión**: condición observable que, de cumplirse, obliga a reabrir la decisión.
-  Ejemplos válidos: "p95 de latencia > 800ms en producción durante 7 días",
-  "≥3 reportes de bugs relacionados con la limitación X en 30 días", "vendor X
-  publica deprecation notice", "costo mensual de infra excede $Y".
-- **Fecha de reevaluación automática**: 6-12 meses desde la fecha de decisión.
-
-Si la decisión NO puede tener trigger observable: es una decisión **basada en preferencia**,
-no en hipótesis falsable. Documentarla como tal en el reporte.
-
-## Formato del reporte
-
-```markdown
-## Doubt-Driven Review — [decisión] — [fecha]
-
-### Decisión articulada
-- Qué se decide: [...]
-- Qué se descarta: [...]
-- Costo de revertir: [estimación]
-
-### Alternativas articuladas
-1. [alt-1]: plausible porque [...]; descartada porque [tradeoff concreto]
-2. [alt-2]: ...
-3. [alt-3]: ...
-
-### Contraevidencia
-- Escenario de falla 1 [prob: alta/media/baja]: [...]
-- Escenario de falla 2 [prob: ...]: [...]
-- Escenario de falla 3 [prob: ...]: [...]
-- Caso histórico relevante: [...]
-- Supuesto sin validar: [...]
-
-### Red flags detectados
-- [línea N: cita textual del argumento débil]
-- [...]
-- (o "Ninguno")
-
-### Trigger de reversión
-- Condición: [observable falsable]
-- Fecha de reevaluación: [YYYY-MM-DD]
-
-### Veredicto
-- ROBUSTA — pasó los 5 pasos sin red flags y con trigger claro
-- ACEPTABLE — pasó con 1-2 red flags documentados y trigger claro
-- BAJO-EVIDENCIA — falla en pasos 2, 4 o 5; reabrir antes de comprometer
-```
-
-## Anti-patrones del skill
-
-- **Auto-revisión**: el agente que tomó la decisión ejecuta el skill sobre sí mismo.
-  Pierde el efecto adversarial. Cargar el skill desde un agente distinto al
-  decisor (ej: `arquitecto-swl` decidió → `revisor-codigo-swl` ejecuta el skill
-  con foco en la decisión).
-- **Trigger inverificable**: "cuando el sistema deje de escalar" no es trigger.
-  Debe ser una métrica observable con valor numérico o evento concreto.
-- **Alternativas de paja**: las 3 alternativas no pueden ser opciones triviales
-  inferiores a propósito. Si las 3 son obviamente peores, el skill perdió su valor
-  — pedir 3 alternativas reales o aceptar que la decisión es bajo-evidencia.
-- **Convertirlo en proceso burocrático**: aplicar doubt-driven a decisiones
-  reversibles es overhead. El paso 1 filtra esto explícitamente.
-
-## Relación con otras capacidades del sistema
-
-- `red-team-swl`: cubre adversarial review de **memoria del sistema** (perfil-usuario,
-  instintos, APRENDIZAJES). Doubt-driven cubre **decisiones técnicas**. NO duplicación.
-- `arquitecto-swl`: produce ADRs. Doubt-driven se carga ANTES de aceptar el ADR.
-- `revisor-codigo-swl`: revisa calidad de código ya escrito. Doubt-driven revisa
-  decisiones ANTES de escribir código.
-- `Skill("verificar-trabajo")`: verificación goal-backward del resultado.
-  Doubt-driven es goal-backward del **diseño**, no del resultado.
-
-## Origen
-
-Patrón observado en `temp/agent-skills-main/skills/doubt-driven-development`
-(2026-05-09). Adaptado al sistema swl-ses: en español, con trigger de
-reversión obligatorio (alineado con `reglas/arquitectura.md` § ADRs en estado
-Propuesto), y con relación explícita a `red-team-swl` para evitar duplicar
-funciones que ya existen en el sistema.
-
-Para ejemplos concretos de aplicación, ver [`recursos/EXAMPLES.md`](recursos/EXAMPLES.md).
+---
+name: doubt-driven-review
+description: >
+  Adversarial peer review de decisiones técnicas antes de comprometerlas.
+  Cuestiona supuestos, fuerza la articulación de alternativas descartadas y
+  detecta confianza injustificada. Cargar antes de decidir arquitecturas
+  irreversibles, elegir un framework crítico, definir un contrato de API
+  público o aprobar un PR de alto impacto. NO cubre adversarial review de
+  memoria (eso lo hace red-team-swl) ni de seguridad de código (eso lo hace
+  revisor-seguridad-swl) — este skill se especializa en decisiones técnicas
+  con costo de cambio alto.
+---
+
+# Doubt-Driven Review
+
+## Cuándo cargar
+
+- Antes de aprobar un ADR que toma una decisión irreversible.
+- Antes de comprometer un contrato público de API o un schema de BD que afecta integraciones externas.
+- Antes de elegir un framework, librería o patrón con costo de migración alto.
+- Antes de fusionar un PR cuyo blast radius incluye módulos críticos.
+- Cuando el equipo o el agente exhibe **alta confianza con baja evidencia** sobre una decisión técnica.
+
+## Cuándo NO cargar
+
+- Para revisar código por calidad — eso es `revisor-codigo-swl` con `Skill("checklist-calidad")`.
+- Para revisar seguridad — eso es `revisor-seguridad-swl` con `Skill("checklist-seguridad")`.
+- Para validar memoria contra prompt injection o privacidad — eso es `red-team-swl`.
+- Para discutir alcances con el usuario — eso es `Skill("brainstorming")` o `swl:discutir-fase`.
+- Para fixes triviales o decisiones reversibles en menos de 10 minutos.
+
+## Principio
+
+> Una decisión cuya alternativa no se ha articulado, no es una decisión:
+> es una preferencia. Toda decisión técnica con costo de cambio alto debe
+> sobrevivir a un round adversarial antes de comprometerse.
+
+El skill ejecuta un protocolo en 5 pasos. Cada paso produce evidencia en
+texto. La salida del skill NO aprueba ni rechaza — produce un reporte que
+el agente o usuario humano usa para decidir.
+
+## Protocolo
+
+### Paso 1 — Articular la decisión y su irreversibilidad
+
+Pedir explícitamente:
+
+- **Qué se decide**: 1-3 oraciones, sin jerga ambigua.
+- **Qué se descarta**: la decisión opuesta concreta.
+- **Costo de revertir**: estimación en turnos / archivos / horas si en 3 meses se concluye que fue incorrecta.
+
+Si el costo de revertir es < 4 horas y < 5 archivos: la decisión NO es candidata
+a doubt-driven review. Cerrar el skill y proceder.
+
+### Paso 2 — Forzar 3 alternativas descartadas
+
+El agente o usuario debe articular las 3 alternativas más fuertes que NO se eligieron, con:
+
+- Por qué cada una es plausible (≥ 1 razón concreta).
+- Qué tradeoff la hace inferior a la elegida (sin frase genérica como "menos flexible").
+
+Si la persona/agente no puede articular 3 alternativas: **señal de decisión bajo-evidencia**.
+Reportar: "Decisión propuesta sin alternativas articuladas. Riesgo de selección por inercia."
+
+### Paso 3 — Buscar contraevidencia activamente
+
+Para la decisión propuesta:
+
+- Listar 3 escenarios donde la decisión **fallaría** o produciría costos no anticipados.
+- Listar 1 caso histórico (dentro o fuera del proyecto) donde una decisión similar resultó incorrecta.
+- Identificar 1 supuesto de la decisión que NO está validado con evidencia (corre el riesgo de ser falso).
+
+Si los 3 escenarios de falla son improbables Y el supuesto está validado: la decisión gana robustez.
+Si ≥ 1 escenario tiene probabilidad ≥ 30%: documentar el riesgo en el reporte.
+
+### Paso 4 — Detectar confianza injustificada
+
+Patrones a marcar como red flags:
+
+- "Es la mejor práctica" sin citar fuente o caso.
+- "Siempre se hace así" sin verificar el contexto del proyecto actual.
+- "Es lo que recomienda <autoridad>" sin verificar que la recomendación aplica al stack/escala/dominio.
+- "No hay otra opción razonable" cuando el paso 2 ya forzó 3 alternativas.
+- Cita de un blog post o tweet como evidencia única.
+- Argumentos de tipo "todo el mundo lo usa" sin métrica concreta.
+
+Por cada red flag detectado: 1 línea en el reporte con cita textual del argumento.
+
+### Paso 5 — Trigger de reversión
+
+Toda decisión que pase doubt-driven review debe incluir:
+
+- **Trigger de reversión**: condición observable que, de cumplirse, obliga a reabrir la decisión.
+  Ejemplos válidos: "p95 de latencia > 800ms en producción durante 7 días",
+  "≥3 reportes de bugs relacionados con la limitación X en 30 días", "vendor X
+  publica deprecation notice", "costo mensual de infra excede $Y".
+- **Fecha de reevaluación automática**: 6-12 meses desde la fecha de decisión.
+
+Si la decisión NO puede tener trigger observable: es una decisión **basada en preferencia**,
+no en hipótesis falsable. Documentarla como tal en el reporte.
+
+## Formato del reporte
+
+```markdown
+## Doubt-Driven Review — [decisión] — [fecha]
+
+### Decisión articulada
+- Qué se decide: [...]
+- Qué se descarta: [...]
+- Costo de revertir: [estimación]
+
+### Alternativas articuladas
+1. [alt-1]: plausible porque [...]; descartada porque [tradeoff concreto]
+2. [alt-2]: ...
+3. [alt-3]: ...
+
+### Contraevidencia
+- Escenario de falla 1 [prob: alta/media/baja]: [...]
+- Escenario de falla 2 [prob: ...]: [...]
+- Escenario de falla 3 [prob: ...]: [...]
+- Caso histórico relevante: [...]
+- Supuesto sin validar: [...]
+
+### Red flags detectados
+- [línea N: cita textual del argumento débil]
+- [...]
+- (o "Ninguno")
+
+### Trigger de reversión
+- Condición: [observable falsable]
+- Fecha de reevaluación: [YYYY-MM-DD]
+
+### Veredicto
+- ROBUSTA — pasó los 5 pasos sin red flags y con trigger claro
+- ACEPTABLE — pasó con 1-2 red flags documentados y trigger claro
+- BAJO-EVIDENCIA — falla en pasos 2, 4 o 5; reabrir antes de comprometer
+```
+
+## Anti-patrones del skill
+
+- **Auto-revisión**: el agente que tomó la decisión ejecuta el skill sobre sí mismo.
+  Pierde el efecto adversarial. Cargar el skill desde un agente distinto al
+  decisor (ej: `arquitecto-swl` decidió → `revisor-codigo-swl` ejecuta el skill
+  con foco en la decisión).
+- **Trigger inverificable**: "cuando el sistema deje de escalar" no es trigger.
+  Debe ser una métrica observable con valor numérico o evento concreto.
+- **Alternativas de paja**: las 3 alternativas no pueden ser opciones triviales
+  inferiores a propósito. Si las 3 son obviamente peores, el skill perdió su valor
+  — pedir 3 alternativas reales o aceptar que la decisión es bajo-evidencia.
+- **Convertirlo en proceso burocrático**: aplicar doubt-driven a decisiones
+  reversibles es overhead. El paso 1 filtra esto explícitamente.
+
+## Relación con otras capacidades del sistema
+
+- `red-team-swl`: cubre adversarial review de **memoria del sistema** (perfil-usuario,
+  instintos, APRENDIZAJES). Doubt-driven cubre **decisiones técnicas**. NO duplicación.
+- `arquitecto-swl`: produce ADRs. Doubt-driven se carga ANTES de aceptar el ADR.
+- `revisor-codigo-swl`: revisa calidad de código ya escrito. Doubt-driven revisa
+  decisiones ANTES de escribir código.
+- `Skill("verificar-trabajo")`: verificación goal-backward del resultado.
+  Doubt-driven es goal-backward del **diseño**, no del resultado.
+
+## Origen
+
+Patrón observado en `temp/agent-skills-main/skills/doubt-driven-development`
+(2026-05-09). Adaptado al sistema swl-ses: en español, con trigger de
+reversión obligatorio (alineado con `reglas/arquitectura.md` § ADRs en estado
+Propuesto), y con relación explícita a `red-team-swl` para evitar duplicar
+funciones que ya existen en el sistema.
+
+Para ejemplos concretos de aplicación, ver [`recursos/EXAMPLES.md`](recursos/EXAMPLES.md).

package/habilidades/doubt-driven-review/recursos/EXAMPLES.md

@@ -1,130 +1,130 @@
-# 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).
+# 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).