v0.34.0 — Linear, and role maps that know about scope

Baron's fourth provider, and the first one that did not fit the model it was handed.

Linear

Linear is an issues adapter, conformance-green and live-smoke-tested. It is also the first provider
whose workflow states belong to a team rather than to the project — two teams each own an
"In Progress" and they are different rows — so the role map is now written per scope, keyed by
whatever the provider says identifies a state rather than by its name.

That is a contract change, not an adapter detail, and it is why most of this release lives in the
core:

• The role map carries scopes, one target per team, and a scope the map does not know is an
  error rather than a fall back to the unscoped default — that default belongs to no team, so
  falling back would send another team's state id to the provider.
• A transport can report which targets an item can actually reach, and the core checks before it
  writes. Jira will need the same seam.
• A provider can say what identifies its items in a branch name, so a Linear branch reads
  task/bar-12-… instead of carrying a 36-character UUID.
• Querying by role expands to one target per scope, and a scope that maps the role not at all is
  reported rather than silently skipped.

Linear has no source control of its own. baron init now offers to take branches and pull requests
from the GitHub repository your git remote already names, and gathers both providers' credentials in
one pass — so an issues-only provider no longer means hand-editing policy.json before the first
recipe will run.

There is a from-scratch Linear walkthrough,
written from a real run against a real two-team workspace.

Things that were quietly wrong

Dogfooding Baron on its own repository found these, and each fix is held by a test that was seen
failing first:

• doctor reported "no drift" on a scoped provider without checking a single state. It walked
  only the flat states map, which is empty by design on Linear, so a real workspace with seven
  mapped states was reported as six references checked — all of them type roles. A green report that
  checked nothing is worse than a red one.
• baron init --help ran the setup wizard, up to offering to overwrite policy.json and asking
  for a token. --help was matched only as a command, never as a flag on a subcommand.
• The policy-to-config bridge dropped scopes, so a scoped map never reached the resolver and
  every Linear install resolved roles against an empty map — while the policy, the proposal, the
  resolver and the adapter were each correct on their own.
• Baron's labels were created team-scoped and looked up workspace-wide, so they were created
  again on every run.
• The usage line said --recipe <path> though built-in recipes have been accepted by name since
  0.33.0; the README still listed Linear as a roadmap item after it had shipped; and init printed
  "Next steps" before it had finished working.

Release plumbing

Ten package.json versions were bumped by hand each release, and pnpm sync:server-json re-wrote
the mcp-server manifest on any drift — so the documented release step left the repository failing its
own lint. There is now a bump script (the packages on disk are the list) and a test that holds every
package at one version.

---

Install: npx -y @lonca/baron-cli@latest · npx -y @lonca/baron-mcp-server@latest
Claude Code: /plugin marketplace add loncadev/baron then /plugin install baron@baron

Full diff: v0.33.0...v0.34.0