Multi-Repo, Multi-Label Design

How one watcher handles many repos × labels, with resource limits

Per-label pipeline files
pipelines/
  ai-feature.yaml    ← full PM→Arch→Eng→QA
  ai-fix.yaml        ← minimal Eng→Review
  ai-docs.yaml       ← DocOrchestrator
  ai-refactor.yaml   ← Engineer only
  ai-custom.yaml     ← your pipeline.yaml
main.py impact: Add --pipeline ai-feature flag.
No flag → uses default (first pipeline or a config default).
Dev can also pass --label ai-fix to simulate a label trigger.
Concurrency: Work Queue + Semaphore
# repos.yaml / config
max_concurrent: 1 ← safe for Ollama
max_concurrent: 3 ← fine for OpenAI
max_concurrent: 10 ← hosted APIs
Flow:
  1. Watcher polls all repos (single thread)
  2. Found issues → pushed to a work queue
  3. N worker threads pull from queue
  4. Each worker acquires a semaphore slot
  5. LLM call runs; slot released when done
Full flow diagram
Watcher poll
Every N minutes
Scans repos.yaml
repos × labels
issues found
Work Queue
{ repo, label, issue_number }
{ repo, label, issue_number }
...
dequeue
Semaphore (max_concurrent)
Worker 1 ▶ pipelines/ai-feature.yaml
Worker 2 ▶ pipelines/ai-fix.yaml
Worker 3 ⏸ waiting...
load
Pipeline runner
Reads pipelines/<label>.yaml
Runs stages in order
Falls back to built-in if no file
Ollama-safe: max_concurrent=1

With max_concurrent: 1, only one pipeline runs at a time. The queue ensures no work is lost — issues pile up in the queue and are processed one by one. No parallel LLM calls.