config: file issues in target project repos, not in agency

[ooloth]

Problem

All GitHub issues are currently filed in the agency repo, regardless of which project they describe. This is a side effect of how gh issue create works — it operates on the current working directory, and agency is always the working directory when the scan loop posts issues.

The consequences:

• Issues about code in project X are invisible to anyone watching project X. They'd have to know to look in a separate repo they don't own.
• PRs opened by the fix loop live in the target project repo, while the issues they fix live in agency. Every fix PR contains a cross-repo reference (fixes ooloth/agency#N), which is awkward to navigate and breaks GitHub's native issue-closing-on-merge behaviour.
• The groom loop must query agency's issue tracker for work that is conceptually about other projects.

The right model: scan and fix run from agency as the command centre, but issues land where the code lives.

Change Required

Add a github_repo field to each project entry in projects.json:

{
  "id": "my-project",
  "github_repo": "owner/my-project",
  ...
}

Pass --repo <github_repo> to every gh call in github.py that touches issues: create_issue, add_label, remove_label, comment, edit_body, close, get_next_ready_issue, get_open_autonomous_issues, get_approved_issue_count.

Change run.py fix to require a <project-id> argument so the fix loop knows which repo to poll for ready work. Same change for run.py groom.

Known DX Regressions and Risks

1. Loss of single-inbox visibility

Today, gh issue list in agency shows all agent-detected issues across all monitored projects in one place. After this change, that view is empty. Seeing the full picture requires querying each target repo separately.

Mitigation: A run.py issues command that iterates over all configured projects, calls gh issue list --repo <github_repo> --label autonomous on each, and prints a unified table. This restores the unified view as an explicit feature rather than a side effect.

2. Label enforcement across repos

The fix loop and groom loop depend on a specific label taxonomy being present in the target repo: autonomous, ready-for-agent, agent-fix-in-progress, agent-fix-stalled, sev:high, sev:medium, sev:low, and scan-type labels. Today agency controls these labels because it controls the repo. Distributed issues means this becomes a shared contract with each target repo — one that can be violated from outside the system.

Risks:

• A target repo maintainer deletes or renames autonomous, silently breaking the groom loop's queries
• The target repo has a label with a conflicting name and different meaning
• A newly registered project has no agency labels, causing the first scan run to fail at the post step

Mitigation: A run.py bootstrap <project-id> command that creates all required agency labels in the target repo, run once at project registration time. Extend the existing preflight checks to validate that required labels exist in the target repo before each scan, fix, or groom run — not just auth and paths. Document the required label set clearly so target repo owners know not to remove them.

3. Fix loop no longer has a global work queue

Currently run.py fix grabs the next ready-for-agent issue globally across agency. With issues distributed, there is no global queue — the fix loop must be told which project to work on.

Mitigation: run.py fix <project-id> polls the specified project's repo. A separate run.py fix-all (or cron-driven loop) can iterate over all configured projects in priority order if unattended multi-project fixing is needed.

Definition of Done

• projects.json schema includes a required github_repo field
• All gh calls in github.py accept and pass a repo parameter
• run.py fix and run.py groom require a <project-id> argument
• run.py bootstrap <project-id> creates required labels in the target repo
• Preflight checks validate required labels exist in the target repo
• run.py issues prints a unified view of autonomous issues across all configured projects
• Existing agency self-scan issues continue to file in the agency repo (agency is its own target project)

Out of Scope

• Moving existing open issues (file new ones in the right place going forward; close old ones manually)
• Cross-repo GitHub Project board integration
• Supporting projects with no GitHub repo (Linear-only, etc.)