Design: Unified Pipeline Architecture

Section 1 of 4 — Unified Orchestrator

Files Deleted

❌ bug_fix_orchestrator.py
absorbed into orchestrator.py
❌ doc_orchestrator.py
absorbed into orchestrator.py

Files Added / Modified

📝 orchestrator.py
gains bug-fix and doc logic as built-in stages
📁 pipelines/
new directory, one YAML per label
📄 pipelines/ai-feature.yaml
full PM→Arch→Eng→QA sequence
📄 pipelines/ai-fix.yaml
Eng→Review sequence (bug fix)
📄 pipelines/ai-docs.yaml
Doc generation sequence

How Orchestrator handles pipeline.yaml selection

Priority (highest to lowest):
1. Custom pipeline.yaml at project root (already implemented)
2. pipelines/.yaml in ai-software-house/
3. Built-in default (current hardcoded feature pipeline)

repos.yaml entry:
  - repo: owner/my-repo
    labels:
      ai-feature: {}          # uses pipelines/ai-feature.yaml
      ai-fix: {}              # uses pipelines/ai-fix.yaml
      ai-custom: {}           # uses pipelines/ai-custom.yaml (create your own!)

Stage registry stays as single source of truth

The existing _make_stage_registry() in orchestrator.py already lists every available stage (pm, architect, engineer, test, review, etc.). pipeline.yaml just references stages by name. Bug-fix stages and doc stages are added to that same registry — no new dispatching logic needed.