v0.35.0 — an install that can tell you it is stale

Everything here came out of running Baron on a real project it did not grow up in — a seven-week-old
install on Azure DevOps — and none of it was visible from the codebase alone.

Your installation can now tell you it is stale

The Claude Code plugin pins its skills and steering to a commit and never moves them, while the
same manifest launches the MCP server with npx @latest, which moves on every restart. Nothing
compared the two. Measured on the install that prompted this: skills frozen at July, server at
0.34.0, and 17 of the 21 tool names those skills use no longer existed — the agent was being
handed instructions to call tools the server does not publish, and every one failed at the moment it
tried to act.

The plugin now declares the release its skills came from, and a newer server says so on a tool
result rather than shouting into a startup log nobody reads. It stays silent when the two agree,
when the client is newer, and when nothing is declared at all — warning every hand-wired
.mcp.json would make this the notice nobody believes on the day it matters.

Installs from before this release declare nothing, so the check begins working from this
plugin version onward. Unavoidable for artifacts already shipped, whatever mechanism we picked.

Upgrading a policy is no longer blind

baron init asked "already exists. Overwrite it?" before the proposal existed — and on "no" it
introspected anyway, built the proposal and threw it away. So the one question an upgrade turns on
could only be answered by agreeing to replace the file you were trying to protect.

The proposal now comes first, then what it does to what is already there, then the question:

Against the policy already here:
  ~ role done: {"state":"Resolved"} -> {"state":"Closed","boardColumn":"Resolved"}
  + type initiative -> Epic
  ~ type subtask: Bug -> Task
Overwrite …/policy.json with this mapping? (y/N)

Removals are called out loudest, because those are what an upgrade actually costs you. An unreadable
policy says so rather than printing an empty diff, which would read as two files agreeing when only
one of them was understood.

The steering block also stops landing in the wrong file: it goes wherever it already is, else into
whichever of AGENTS.md / CLAUDE.md the project already keeps. Writing AGENTS.md unconditionally
gave most Claude Code projects a second steering document — two files disagreeing, with the stale
one being the one the harness loads by name.

task-land guards that actually guard

• It refuses to merge over an explicit rejection. The gate read the checks rollup and nothing
  else, so a pull request a reviewer had rejected merged exactly as readily as an approved one.
• Azure's checks are readable. They are branch-policy evaluations on a separate API this adapter
  did not read, so every rollup came back unknown and every land there proceeded onto an
  unverified state. Same PR, same call, before and after: rollup: unknown, total: 0 became
  rollup: succeeded, total: 1.

review_required deliberately does not block, and that difference was measured rather than
assumed: a repository where nobody casts a formal vote reports it on every pull request, so refusing
on it would make task-land unusable there. A guard that fires on everything is one that gets
removed.

none and unknown stay distinct throughout — a failed read reports unknown with the provider's
own message, never none, because "no checks" tells a caller the merge is unblocked when Baron
simply could not look.

Also

RELEASING's own instructions unpacked the MCP publisher tarball into the repository root — and that
tarball carries a LICENSE and a README.md, which silently replaced Baron's own. One step before a
release, which is exactly when someone runs git add -A.

---

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.34.0...v0.35.0