v0.37.0 — a transition can ask for fields

Baron's role contract now covers the provider it was hardest to fit, and a credential form can no
longer hide a credential file.

A transition can ask for fields

Jira cannot be told a status. You read the transitions its workflow permits from the issue's current
state, perform one, and answer whatever its transition screen demands — resolution, fixVersions
— fields that have nothing to do with the role. The first half (reachable targets, refused with
TRANSITION_NOT_PERMITTED naming what the provider would accept) shipped in 0.34. This release adds
the second.

A transport can now report the fields a move demands, each with required and any allowedValues.
The core checks presence before writing and refuses with TRANSITION_FIELDS_REQUIRED naming
every missing field at once, so a caller asks once and retries rather than learning them one
provider rejection at a time. It checks presence and nothing else: what a field means, and whether a
value is acceptable, stays the provider's.

// baron_issue_move { op: "transition", id, role: "done" }
// -> isError, code TRANSITION_FIELDS_REQUIRED
// structuredContent.details.fields:
//   [{ "name": "resolution", "required": true, "allowedValues": ["Fixed", "Won't Do"] }]
// baron_issue_move { op: "transition", id, role: "done", fields: { "resolution": "Fixed" } }
// -> moved

Recipes take the same fields on issue.transition. Both transport methods are optional, so a
provider that asks nothing implements nothing, and a recipe written for Jira runs unchanged on
GitHub. The in-memory conformance provider now refuses the way Jira does, so the suite can tell a
core that checked from one that got lucky. With this, Gate 3's contract work in the roadmap is done;
the Jira adapter is the first thing to build on it (#173).

Refusals carry data, not only prose

BaronError gained details, and the MCP server puts it in structuredContent. A
TRANSITION_NOT_PERMITTED lists the permitted targets; a TRANSITION_FIELDS_REQUIRED lists the
fields. An agent branches on the payload instead of regexing the message.

A blank credential no longer masks the file

Hosts that present credentials as a form — Docker Desktop's MCP Toolkit among them — pass every
declared variable whether or not the user filled it in. A blank GITHUB_TOKEN used to win over the
value sitting in the mounted project's .baron/credentials, and the server failed for want of a
token it had. An empty variable is now a gap the file may fill; a non-empty one still wins.

This is the groundwork for Baron's Docker MCP Catalog entry, submitted as
docker/mcp-registry#4925. Once it is in, Docker
builds and hosts the image as mcp/baron; docs/mcp.md describes the Toolkit path.

The update notice speaks in both directions

The stale-companion check reported a plugin older than the server and said nothing when it was
newer. 0.36.0 disproved the reasoning behind that: skills ship through the plugin marketplace and the
recipes they call ship through npm, so a plugin ahead of its server is the ordinary state between two
updates — and a 0.36 skill calling a recipe a 0.35 server has never heard of fails with an error that
explains nothing. Both directions now speak, with opposite remedies.

For contributors

The toolchain moved to pnpm 11. Developing needs Node 22+; the runtime floor for the published
packages stays Node 20.