You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I’m testing Symphony in a Linear setup where work is not primarily organized around a single Linear Project.
In many teams, the natural dispatch boundary is the Linear team. Projects are temporary or cross-cutting, while the team queue is the stable place where engineering work lands. Labels then define whether an issue is safe for autonomous execution, for example:
agent-ready
agent-blocked
human-only
Today, the Elixir reference implementation polls Linear by tracker.project_slug. That works well for project-centric workflows, but it makes Symphony harder to adopt in teams that use Linear teams + labels as the operating model.
I’d like to propose making Linear scope selection a bit more flexible while preserving the current default behavior.
Proposed config
tracker:
kind: linear# Existing behavior. Still takes precedence when present.project_slug: "..."# New fallback scope when project_slug is absent.team_key: "ENG"# Optional dispatch gates.required_labels: ["agent-ready"]excluded_labels: ["agent-blocked", "human-only"]
Intended behavior
Keep tracker.project_slug as the default and highest-precedence Linear scope.
Use tracker.team_key only when no project slug is configured.
Apply required_labels / excluded_labels before dispatch.
Keep the implementation inside the Linear tracker adapter.
Use a single Linear IssueFilter! shape for both project and team scopes.
Why this matters
This lets Symphony support two common Linear operating models:
Project-based dispatch: “run agents for issues in this Linear Project.”
Team-queue dispatch: “run agents for issues in this Linear Team that are explicitly marked agent-ready.”
The second model is useful when teams want Symphony to continuously watch their normal engineering intake queue without forcing all autonomous work into a dedicated Linear Project.
The main design question is whether tracker.project_slug should remain the only required Linear scope, or whether Symphony should support multiple Linear scope types with project_slug remaining the default.
Would this direction be acceptable for upstream Symphony?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi Symphony maintainers,
I’m testing Symphony in a Linear setup where work is not primarily organized around a single Linear Project.
In many teams, the natural dispatch boundary is the Linear team. Projects are temporary or cross-cutting, while the team queue is the stable place where engineering work lands. Labels then define whether an issue is safe for autonomous execution, for example:
agent-readyagent-blockedhuman-onlyToday, the Elixir reference implementation polls Linear by
tracker.project_slug. That works well for project-centric workflows, but it makes Symphony harder to adopt in teams that use Linear teams + labels as the operating model.I’d like to propose making Linear scope selection a bit more flexible while preserving the current default behavior.
Proposed config
Intended behavior
tracker.project_slugas the default and highest-precedence Linear scope.tracker.team_keyonly when no project slug is configured.required_labels/excluded_labelsbefore dispatch.IssueFilter!shape for both project and team scopes.Why this matters
This lets Symphony support two common Linear operating models:
The second model is useful when teams want Symphony to continuously watch their normal engineering intake queue without forcing all autonomous work into a dedicated Linear Project.
I have an implementation branch here:
Branch:
https://github.com/leandrojo/symphony/tree/linear-team-scoped-issue-polling
Compare:
main...leandrojo:symphony:linear-team-scoped-issue-polling
Validation:
mise exec -- make allThe main design question is whether
tracker.project_slugshould remain the only required Linear scope, or whether Symphony should support multiple Linear scope types withproject_slugremaining the default.Would this direction be acceptable for upstream Symphony?
Beta Was this translation helpful? Give feedback.
All reactions