## 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.