v1.4.0

Added

• Free-form toolset selection: serve --toolsets — When none of the four named profiles fits a deployment, serve --toolsets issues,planning (or RHIZOME_TOOLSETS) composes the advertised catalog directly from the capability groups every tool already declares (core, issues, planning, review, knowledge, lifecycle, governance, migration, sync); the core pair (open_project, get_project) stays always-on so a client can still route and diagnose a missing tool. Mutually exclusive with --profile/RHIZOME_TOOL_PROFILE: both flags together fail as a usage error, and a mixed flag/environment combination fails startup before any transport opens rather than silently preferring either input. An unsupported, duplicate, or empty group name fails startup with an error naming the valid vocabulary; selecting toolsets from the environment prints the same explicit stderr notice profile selection does. In toolset mode get_project/open_project report "tool_profile": "custom" plus a toolsets array of the advertised groups. Like profiles, toolsets are an exposure and prompt-size control, not an authorization boundary (docs/03 §5.4).

• Claude Code plugin and self-hosted marketplace — /plugin marketplace add Odrin/rhizome-mcp followed by /plugin install rhizome-mcp@rhizome installs the server and both workflow skills into Claude Code in one step, with no manual MCP registration. The plugin launches the server as npx -y rhizome-mcp serve, so nothing has to be on PATH and no Go toolchain is needed; it deliberately passes no --project-root, because routing is stateless and the project is carried by ordinary project_ref arguments (docs/11). The plugin's skills/ tree is a copy of the canonical .github/skills tree — plugin skills are discovered only from the plugin root, while the skills-CLI convention and guide generation target .github/skills — kept identical by plugin_skills_sync_test.go and refreshed with scripts/sync-plugin-skills.sh. The repository root hosts only the marketplace manifest, so the development .mcp.json is never shipped to an install.

• Scripted, reproducible demo assets — A new demo/ directory holds four scenario drivers that talk to a real serve --http-address process with curl and jq, so each one doubles as a living smoke test of the docs/08 HTTP contract, plus the VHS tapes and a record.sh that rebuilds every asset in site/assets/demo/ and fails if a GIF exceeds 2 MiB. The recordings show real server output: a second claim denied with ACTIVE_ATTEMPT_EXISTS, derived in_progress on the board, lease expiry, and a successor resuming from the checkpoint (lease-expiry.gif); an approval refused with REVIEW_REQUEST_REQUIRED because the request was pinned to an older issue version, then re-pinned by replace_review_request (review-superseded.gif); a claim failing atomically on an overlapping reservation that names the holding attempt and its lease (reservation-conflict.gif); and the status board on a seeded project (board.png, board.html).

• Guarantee-framed comparison page — New site/compare.md compares rhizome-mcp with beads, Kata, Guild, and Backlog.md on what each guarantees under failure — crash recovery, double-claim prevention, review staleness, response budgets, attempt resumability, resource reservations, gates — rather than on feature nouns. Every cell is a mechanism claim pinned to a specific competitor release (beads v1.2.2, Kata v0.16.0, Guild v0.3.2, Backlog.md v1.50.1), and every rhizome yes-cell links to the spec section or the integration test that enforces it; the editorial rules for keeping the page honest are embedded in it as a comment header.

• Agent-driven installation guide and discovery metadata — A root llms-install.md gives agent-driven installers (Cline and similar) a non-interactive, idempotent setup path: npx, native binary, or from source; per-client registration; and a verification step. The README badge row gains npm-downloads and MCP Registry badges, and the npm launcher package carries expanded keywords so directory and search listings can find it.

Changed

• The README leads with the guarantee instead of the feature list — It now opens with the outcome — when a coding agent dies mid-task, the task frees itself — followed by the lease-expiry recording and a section table of contents. The Why list promotes the tested token-budget contract to second position, gains a resource-reservations bullet, and embeds the review-superseded and reservation-conflict recordings behind <details>; a new "How it compares" section links the full comparison page; quick start gains the Claude Code plugin install; and the monitoring section shows the board screenshot. Release-verification detail moved to CONTRIBUTING.md, and site/README.md mirrors the new lead.

Fixed

• The first review request for an issue was unreachable over MCP — create_review_request and supersede_review_request were both dropped after their deprecation window on the strength of "the atomic replace_review_request tool provides the combined functionality," but that was only ever true of supersession: replace_review_request requires a predecessor_request_id, so with no create tool advertised there was no way to open the first request for any issue. Nothing else fills the gap — finish_attempt with target_issue_status: "review" does not create a request, and the application/repository create path (purpose coverage, born-stale rejection, content-idempotent duplicates) had been left fully implemented with zero callers. Step 1 of the workflow docs/03 §7.6 and docs/09 describe therefore had no tool behind it, and every existing review test seeded its request through sqlite.ReviewRepository directly, so no test could notice. create_review_request is restored to the review capability group, taking issue_id, target_issue_version, target_event_id, and optional artifact_ids/purposes. It carries no supersedes_id — recording a supersession link without closing the predecessor is exactly the split replace_review_request exists to fix — and no idempotency_key: a repeat matching the target's still-live request replays it, but a cancel resolves that gate without changing the issue, so the guarantee is conditional and idempotentHint stays false (docs/03 §4). A new integration test walks request → discover → claim → resolve using only tools/call, and fails with unknown tool if the registration is ever removed again.

• Re-requesting a review after changes_requested pointed at a tool that rejects it — docs/09 step 5 and its stale-target recovery example told readers to open the follow-up request with replace_review_request, but replacement accepts only an open predecessor: a changes_requested or superseded one fails with REVIEW_REQUEST_NOT_REPLACEABLE. Both paths now name create_review_request, and docs/09, site/workflow.md, and the agent-workflow and issue-lifecycle guides state the split explicitly — create_review_request where no request is live, replace_review_request only to supersede one that is still open. The guide also notes that completing an attempt to review does not open a request on its own.

Internal

• Releases stamp the plugin manifest version — A Claude Code marketplace install reads the plugin manifest from the repository, so the run-local stamping used for server.json cannot version it. After a fully successful release, a new stamp-plugin-manifest job writes the tag version into plugins/rhizome-mcp/.claude-plugin/plugin.json on main through the contents API (the same mechanism the coverage badges already use), skipping when the manifest is already current and skipping entirely for the workflow_dispatch VS Code republish fallback.

Full Changelog: v1.3.3...v1.4.0