Ciclo de Bugfix

RaiSE usa un pipeline estructurado de bugfix: 7 skills atómicos orquestados por el motor de pipeline MCP, con 3 gates de human-in-the-loop que previenen errores en cascada.

¿Por Qué un Pipeline?

Los bugs fallan diferente que las features. Una feature puede construirse incrementalmente; una corrección de bug que parte de la causa raíz incorrecta desperdicia todo el esfuerzo. El pipeline aborda esto con gates en los puntos de decisión críticos:

1. Tras el scoping — ¿Es este el problema correcto?
2. Tras el análisis — ¿Es esta la causa raíz y estrategia correctas?
3. Tras la corrección — ¿Funciona realmente la corrección?

Quick Start

Dentro de Claude Code, pídele a Rai que inicie el pipeline de bugfix:

Inicia el pipeline de bugfix para RAISE-251

Rai llama a pipeline_start con pipeline: bugfix, detecta desde qué fase iniciar (o retoma desde donde te quedaste), y pausa en cada gate para tu revisión.

Nota: /rai-bugfix-run fue eliminado en 3.0. Usa el motor de pipeline MCP en su lugar. Ver Migrando desde 2.x.

Las 7 Fases

/rai-bugfix-start     → Reproducir, acotar el bug
/rai-bugfix-triage    → Clasificar en 4 dimensiones
                      ── GATE 1: Scope y Clasificación ──
/rai-bugfix-analyse   → Análisis de causa raíz (5 Porqués, Ishikawa, o directo)
                      ── GATE 2: Causa Raíz y Estrategia ──
/rai-bugfix-plan      → Descomponer la corrección en tareas TDD
/rai-bugfix-fix       → Ejecutar corrección con tests
                      ── GATE 3: Verificación de Corrección ──
/rai-bugfix-review    → Retrospectiva, extracción de patrones
/rai-bugfix-close     → Push de branch, crear MR, verificar artifacts

Fase 1: Start

Crea work/bugs/RAISE-{N}/scope.md con pasos de reproducción, detalles del entorno y comportamiento esperado vs. actual.

Fase 2: Triage

Clasifica el bug en 4 dimensiones:

Dimensión	Valores	Propósito
Tipo de Bug	Logic, Data, Integration, Config, Regression, Performance	Qué tipo de defecto
Severidad	Critical, High, Medium, Low	Impacto en usuarios
Origen	Design, Implementation, Environment, External	Dónde se introdujo el defecto
Calificador	Flaky, Edge-case, Silent, Blocking, Cascading	Característica de comportamiento

Fase 3: Analyse

Análisis de causa raíz usando selección de método basada en señales:

• Direct — La causa es obvia desde la reproducción
• 5 Porqués — La causa no es obvia, necesita cuestionamiento iterativo
• Ishikawa — Múltiples causas potenciales, necesita exploración sistemática

Produce analysis.md con causa raíz, evidencia y múltiples enfoques de corrección con trade-offs.

Fase 4: Plan

Descompone el enfoque de corrección seleccionado en tareas TDD atómicas — cada tarea tiene un test a escribir primero (RED), implementación (GREEN) y refactor opcional.

Fase 5: Fix

Ejecuta el plan: escribe tests, implementa la corrección, verifica que el bug ya no se reproduce. Hace commits después de cada tarea.

Fase 6: Review

Retrospectiva: qué causó el bug, qué aprendimos, ¿hay patrones que extraer? Produce retro.md y opcionalmente agrega patrones via rai pattern add.

Fase 7: Close

Hace push de la branch de bug, crea un merge request, transiciona Jira a Done, verifica que todos los artifacts existen.

Los 3 Gates

Los gates son obligatorios — no pueden omitirse, ni siquiera en nivel de maestría Ri.

Gate 1: Scope y Clasificación

Se presenta tras las fases 1-2. Verificas:

• ¿Es este el problema correcto?
• ¿Coincide la reproducción con lo que reportaron los usuarios?
• ¿Es correcta la clasificación?

Respuestas: y (continuar) · edit (corregir scope/clasificación) · reject (detener)

Gate 2: Causa Raíz y Estrategia

Se presenta tras la fase 3. Este es el gate de mayor valor — presenta múltiples enfoques de corrección con trade-offs. Rai se sesga hacia el enfoque más simple que aborda completamente la causa raíz.

Enfoques de corrección:
  A: Agregar entrada en gitignore para archivo de cache — simple, 1 línea
  B: Agregar validación de cache + limpieza al inicio — completo, 40 LOC
  C: Rediseñar almacenamiento de cache para usar directorio temp — más robusto, 200 LOC

Recomendado: A porque la causa raíz es una entrada de gitignore faltante

Respuestas: a/b/c (seleccionar enfoque) · adjust (refinar estrategia) · reject (re-analizar)

Gate 3: Verificación de Corrección

Se presenta tras la fase 5. Verificas:

• Los tests pasan
• El bug ya no se reproduce
• Los archivos modificados se ven correctos

Respuestas: y (continuar a review + close) · reject (revisar código, identificar problemas)

Soporte de Resume

El orquestador detecta artifacts existentes y retoma desde la fase más avanzada. Si una sesión se interrumpe, pídele a Rai nuevamente: "Retoma el pipeline de bugfix para RAISE-251" — llama a pipeline_restore y continúa donde se quedó.

Usar Skills Individuales

Cada fase es invocable independientemente para trabajo dirigido:

/rai-bugfix-triage      # Re-clasificar un bug ya acotado
/rai-bugfix-review      # Ejecutar retrospectiva en un bug ya corregido

Artifacts

Todos los artifacts viven en work/bugs/RAISE-{N}/:

Archivo	Fase	Contenido
scope.md	start + triage	Reproducción, clasificación
analysis.md	analyse	Causa raíz, evidencia, enfoques
plan.md	plan	Desglose de tareas TDD
retro.md	review	Retrospectiva, patrones