Repository Manager

Finish

rm_lane_finish

Finish a repository lane: land its branch onto a base branch and enqueue the result, optionally forcing past blocking preflight checks.

Instructions

Finish (rm_lane). The lane lifecycle for concurrent agents and humans (CONCEPT:RM-LANE-DOCTOR).

Every check behind this tool exists because a specific collision destroyed real work while the rule that would have prevented it was written down, in prose, in front of the actor who broke it: editing a canonical checkout a background git reset then discarded; a git stash into the ONE refs/stash shared by ~54 worktrees; a shared CARGO_TARGET_DIR that corrupts rather than merely serializes; an unset PRE_COMMIT_HOME whose shared store swallows unstaged work; a foreign or stale worktree-local .venv worth ~167 phantom failures; and measuring a branch TIP that will never be the tree that lands. The exact all-extras environment managed by scripts/uv_workspace.py is accepted because it is lane-partitioned and synchronized before execution.

doctor is the one to reach for when something behaves impossibly — a test failing that cannot fail, a build that will not go green, a merge that keeps being refused. It answers in under a second and mutates nothing.

Input Schema

Name	Required	Description
`env`	No	For 'doctor': the CALLER's own exported environment (at least PRE_COMMIT_HOME/CARGO_TARGET_DIR/PYTEST_ADDOPTS). Required for a truthful remote check (D-CDX-61) — this server process's own environment is not the lane process's, so omitting this evaluates the checks against server-internal state that has nothing to do with what the caller will actually run with.
`base`	No	Base branch to fork from / land onto (default main).
`path`	No	The lane's working tree for doctor/env/finish (default: cwd).
`repo`	No	Repo basename or absolute path. Required for 'start'.
`force`	No	For 'finish': enqueue despite a blocking preflight check. Recorded in the result.
`branch`	No	Branch for 'start'/'finish' ('finish' defaults to that tree's HEAD).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.5.1Oct 19, 2026

TDQS

C2.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false. The description adds nothing about this tool's own behavior — what finishing mutates, where the branch goes, what happens when preflight blocks, or what `force` records. Its behavioral content (worktree/stash/target-dir hazards) describes why checks exist, not what finish does.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A long historical essay enumerating past collisions (canonical checkout, refs/stash, CARGO_TARGET_DIR, PRE_COMMIT_HOME, .venv, branch TIP) crowds out the one line that matters. The final paragraph is entirely about a sibling tool, so a large share of the text does not earn its place for invoking rm_lane_finish.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a non-read-only lifecycle mutation with six optional parameters, the description omits what finishing actually does, the ordering relative to gating/merge-queue tools, and the consequence of `force`. Output schema exists, so return values need not be explained — but the action itself is never described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents `env`, `force`, `base`, `path`, `repo`, and `branch`. The description adds no parameter meaning of its own, so the baseline 3 applies rather than any credit or penalty.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The body opens with "Finish (rm_lane)" and then spends every sentence on the rationale for the collision checks rather than stating the action. It never says plainly that finishing lands/enqueues the lane's branch onto `base` after preflight; the closest hints ("the tree that lands", "a merge that keeps being refused") are incidental. An agent reads a manifesto, not a purpose statement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only explicit "when to use" guidance points at a different tool: "`doctor` is the one to reach for when something behaves impossibly." There is no guidance on when to call finish versus rm_lane_doctor, rm_lane_heal, or rm_merge_queue_enqueue/run, nor any prerequisite (e.g. preflight pass, force semantics).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server