Feature: Multi-repo support — route issues to different Git repositories from one WORKFLOW.md

[leonagente]

Problem

Today, each Symphony Go instance can only work with one repository. The hooks.after_create hook clones the same repo for every issue, and there's no way to route different issues to different codebases.

Teams that manage multiple repositories under a single project tracker are forced to run N separate Symphony instances — one per repo — each with its own WORKFLOW.md, dashboard port, and process. This adds operational overhead and makes it impossible to see all work across repos in a single Kanban board.

Real-world example

We maintain two repos under one project tracker:

• agente-ai — Next.js cloud platform
• agente-desktop — Electron desktop app

Issues for both live in the same tracker project. Today we'd need two Symphony instances, two dashboards, two configs — even though the issues come from the same source.

Proposal: Project-to-Workspace Mapping

Add a workspace.projects map in WORKFLOW.md that routes issues to different repos based on a label, project, or other issue metadata.

Proposed config

workspace:
  root: ~/.symphony/workspaces
  projects:
    cloud:
      match:
        labels: ["cloud", "api", "web"]   # route by label
      repo: git@github.com:org/agente-ai.git
      branch: staging
    desktop:
      match:
        labels: ["desktop", "electron"]
      repo: git@github.com:org/agente-desktop.git
      branch: main
    default:                               # fallback for unmatched issues
      repo: git@github.com:org/agente-ai.git
      branch: main

How it would work

1. On issue fetch: After fetching candidates, evaluate each issue against workspace.projects[*].match rules (labels, title regex, or tracker-specific metadata like Linear sub-projects)
2. On workspace creation (after_create): Clone the matched project's repo instead of relying on a single hardcoded hook. The existing hooks.after_create becomes the fallback for projects without a repo field.
3. On before_run: Reset to the matched project's branch (e.g., staging vs main)
4. Dashboard: Show a project column or filter in the Kanban board so you can see which repo each issue targets

Prior art: Paperclip AI's project model

Paperclip AI (API docs) solves this at the tracker level — each issue belongs to a project, and each project has a workspace with a Git repo URL and branch:

POST /api/companies/{companyId}/projects
{
  "name": "Auth System",
  "description": "End-to-end authentication",
  "goalIds": ["{goalId}"],
  "status": "planned",
  "workspace": {
    "repoUrl": "git@github.com:org/auth-service.git",
    "branch": "main",
    "path": "/"
  }
}

Issues inherit their project's workspace, so the orchestrator knows which repo to clone per issue without any label-matching heuristics. The same concept could be adopted in Symphony — either by reading project metadata from trackers that support it, or via the label-based routing proposed above for GitHub Issues / Linear.

Key endpoints from Paperclip's model:

• GET /api/companies/{companyId}/projects — list projects with workspace configs
• GET /api/projects/{projectId} — get project with workspace.repoUrl and workspace.branch
• GET /api/companies/{companyId}/issues?projectId={id} — filter issues by project

This shows a clean pattern: projects own workspaces, issues inherit from projects.

Alternatives considered

Approach	Downside
Run N Symphony instances	N dashboards, N configs, can't see unified Kanban
Use after_create hook with conditional logic	Fragile shell scripting, no dashboard awareness
Monorepo everything	Not always feasible for different tech stacks

Scope

This doesn't require a pluggable tracker system — it works with the existing Linear and GitHub trackers. The routing is purely at the workspace/clone layer based on issue metadata that's already available (labels, sub-projects).

Summary

• What: Route issues to different Git repos within a single Symphony instance based on issue metadata
• Why: Teams with multiple repos shouldn't need multiple Symphony instances
• How: workspace.projects config with match rules → clone the right repo per issue
• Inspiration: Paperclip AI's project-workspace model (docs)

[wangneal]

I can do it

[vnovick]

Can work with multiple repos in #41