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.