GitHub tracker integration for Symphony Elixir

[mpuig]

Hi all, I’ve been working on adding GitHub as an alternative tracker for the Symphony Elixir runtime alongside the existing Linear integration.

The goal is to preserve Symphony’s current orchestration model while making it possible to use:

• GitHub Issues as work items
• GitHub Projects v2 Status as the workflow state
• GitHub PRs as the implementation and review artifact

I’ve opened a PR in my fork here:

mpuig#1

It adds:

• a GitHub tracker adapter and client
• config/schema support for tracker.kind: github
• GitHub Issues / Projects v2 status mapping
• Symphony-native GitHub tools for issue/project operations
• Symphony-native GitHub tools for PR/review/check operations
• preserved dispatch semantics, including blocked Todo handling
• dashboard support for GitHub project links

A few constraints I tried to preserve:

• keep the Linear path unchanged
• avoid changing the core Symphony orchestration model
• keep GitHub support additive rather than invasive
• preserve documented local codex.command behavior

I’d appreciate feedback on whether GitHub is a useful upstream direction for Symphony, and whether this implementation is aligned with the intended tracker/tool architecture.

[zack-nova]

Hi all, I have a related fork here:

https://github.com/zack-nova/symphony

It explores the same broad direction as this discussion, but with a smaller first GitHub slice: GitHub Issues with label-based state rather than GitHub Projects v2 status.

The fork currently adds:

• A tracker-neutral orchestration layer, with shared tracker adapter contracts and normalized issue records so the orchestrator is not Linear-specific.
• A GitHub label-state tracker adapter using an explicit tracker scope, one project: scope label, and exactly one state: label per managed issue.
• GitHub issue comment and label-state update support while preserving the existing Linear path.
• agent.state_prompts, which lets workflows attach state-specific Codex guidance for states like state:ready-for-dev, state:to-rework, or state:to-merge.
• Active state guidance refresh: when a running issue moves between active states, Symphony can deliver the matching state prompt to the current Codex session instead of waiting for a fresh run.
• Setup/readiness terminology and docs around smoke mode, live mode, protocol preflight, capability preflight, setup secrets, and operator handoff.
• Additional regression coverage for the tracker adapter path, prompt rendering, Codex app-server behavior, and workflow config.

I am not assuming this should land upstream as one large PR. I wanted to ask maintainers first:

1. Is tracker-neutral orchestration a direction you would want in the reference Elixir implementation, or should this remain a fork-level experiment?
2. If GitHub support is welcome, would you prefer a minimal label-state GitHub Issues adapter first, or should upstream only consider a GitHub Projects v2 status model?
3. If this is aligned, what split would be easiest to review? My current assumption is:
   • tracker adapter abstraction and normalized issue model
   • minimal GitHub label-state adapter
   • state-specific prompts
   • active state guidance refresh
   • setup/readiness documentation and preflight contracts
4. Since non-collaborator PR creation appears restricted on this repo, what is the preferred path for contributing a patch series if maintainers want any of this upstream?

Happy to keep this as a fork if it is outside the intended scope. The main goal is to avoid drifting silently if parts of the work line up with the upstream roadmap.