Saltar a contenido

Pipelines

Los pipelines son la capa de orquestación de RaiSE. Toman los skills que ya usas (como /rai-story-design o /rai-story-implement) y los conectan en secuencias automatizadas con gates obligatorios. En lugar de invocar cada skill manualmente, un pipeline ejecuta el ciclo de vida completo — pausando solo cuando se necesita juicio humano.

Los comandos de runbook legacy (/rai-story-run, /rai-bugfix-run, /rai-epic-run) están deprecados. Usa el motor de pipelines a través de tu integración de agente en lugar de enseñar nuevos flujos alrededor de esos comandos.

¿Por qué Pipelines?

Sin pipelines, invocas skills uno por uno:

/rai-story-start → /rai-story-design → /rai-story-plan → /rai-story-implement → ...

Esto funciona, pero depende de que recuerdes la secuencia, ejecutes cada skill y no te saltes pasos. Los pipelines codifican la secuencia como datos — un archivo YAML — y el motor la ejecuta, aplicando gates e inyectando contexto en cada fase.

Cómo Usar Pipelines

Interactúas con pipelines a través de la integración de pipelines de tu agente para un ítem de trabajo como RAISE-1234.

Internamente:

  1. El skill de runbook llama a pipeline_start (herramienta MCP) para inicializar la ejecución
  2. En cada fase, la IA lee el SKILL.md del skill y sigue sus pasos
  3. pipeline_advance avanza a la siguiente fase tras completarse
  4. Los gates HITL pausan y te piden aprobación en la conversación
  5. pipeline_restore recupera el estado si la sesión se reinicia

Nunca necesitas llamar a las herramientas MCP directamente — los skills de runbook se encargan de la orquestación. Tu interacción es conversacional: lees el output, apruebas en los gates y das orientación cuando se solicita.

Comandos de runbook legacy (deprecados)

Comando Pipeline Fases Caso de uso
/rai-story-run story 8 Desarrollo de features
/rai-bugfix-run bugfix 7 Corrección de bugs con seguimiento
/rai-epic-run epic 6 Iniciativas multi-story

Anatomía del YAML de Pipeline

Cada pipeline está definido en un archivo YAML que carga el motor:

name: story
description: "Pipeline de ciclo de vida de story en 8 fases"
issue_types:
  - story

defaults:
  story_type: code

execution:
  worktree_isolation: true
  branch_pattern: "story/{issue_id}/pipeline"

phases:
  - id: design
    type: llm
    skill: rai-story-design
    context:
      graph:
        - types: [pattern]
          limit: 3
        - types: [module]
          limit: 2
    validates:
      - pattern: "**/*-design.md"
        description: "Documento de diseño de story"
    gate:
      type: hitl
      level: REVIEW

Campos Principales

Campo Descripción
phases[].type llm (dirigido por IA vía skill) o deterministic (comandos de shell)
phases[].skill Qué SKILL.md cargar como prompt
phases[].context.graph Consultas al knowledge graph inyectadas en el contexto
phases[].validates Patrones glob para artifacts que deben existir tras la ejecución
phases[].gate hitl (revisión humana) o deterministic (verificación automatizada)
phases[].when Expresión de condición (p.ej., "story_type == 'code'")
execution.worktree_isolation Ejecutar en un git worktree separado

Pipelines Incluidos

RaiSE incluye cuatro pipelines de ciclo de vida:

Pipeline Fases Ciclo de vida
story 8 start, design, plan, implement, AR, QR, review, close
epic 6 start, design, plan, story-iteration, docs, close
bugfix 7 start, triage, analyse, plan, fix, review, close
hotfix 3 Correcciones de emergencia mínimas

Gates HITL y Delegación

Los gates son checkpoints donde se requiere una decisión humana. El pipeline pausa y la IA presenta lo que ocurrió — tú decides si continuar, ajustar o rechazar.

En Claude Code, esto se ve como un prompt conversacional:

── GATE: Aprobación de Diseño ──

Story: RAISE-1234 — Agregar notificaciones webhook
Enfoque: Basado en eventos vía sistema de hooks existente
Componentes: hooks/webhook.py (nuevo), esquema de config (modificar)

▸ ¿Aprobar diseño? [y/edit/reject]

Tu nivel de delegación (del perfil de desarrollador) controla cuánta autonomía tiene el pipeline:

Nivel Comportamiento
REVIEW El pipeline pausa en cada gate HITL. Revisas y apruebas. (Por defecto)
NOTIFY El pipeline continúa pero te notifica. Puedes intervenir.
AUTO El pipeline continúa sin pausar. Los gates se registran pero no bloquean.

Esto mapea con ShuHaRi: los desarrolladores Shu usan REVIEW (aprenden el proceso), los Ri usan AUTO (confían en el proceso).

Inyección de Contexto

Cada fase puede declarar qué contexto del knowledge graph necesita. El motor consulta el grafo vía herramientas MCP e incluye los resultados:

context:
  graph:
    - types: [pattern]    # "¿Qué patrones aplican aquí?"
      limit: 5
    - types: [module]     # "¿Qué módulos son relevantes?"
      limit: 2
    - types: [decision]   # "¿Qué ADRs debo conocer?"
      limit: 2

Así es como el pipeline conecta el conocimiento institucional con la ejecución — los patrones de trabajo anterior informan las decisiones actuales automáticamente.

Herramientas MCP (Internamente)

El motor de pipelines expone herramientas MCP que consumen los skills de runbook:

Herramienta MCP Propósito
pipeline_start Inicializar una ejecución de pipeline
pipeline_advance Completar la fase actual, avanzar a la siguiente
pipeline_status Verificar el estado actual de una ejecución
pipeline_restore Recuperar el estado completo tras reiniciar la sesión
pipeline_pause Pausar una ejecución (reanudable)
pipeline_cancel Cancelar una ejecución (no reanudable)
pipeline_list Listar definiciones de pipeline disponibles
pipeline_runs Listar ejecuciones activas y recientes

No llamas a estas directamente en nuevos flujos de trabajo. Se documentan aquí solo como referencia histórica para proyectos más antiguos.

Los Skills No Cambian

Importante: Los skills funcionan exactamente igual si se invocan manualmente (/rai-story-design) o a través de un pipeline. El pipeline solo automatiza la secuencia y agrega inyección de contexto. Siempre puedes volver a la invocación manual de skills.

Próximos Pasos