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