Repository Manager

Heal

rm_lane_heal

Diagnose and repair lane conflicts for concurrent agents and humans, covering worktree, stash, build-cache, and environment collisions with non-mutating checks and safe lifecycle actions.

Instructions

Heal (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 the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false). The description instead spends its length on rationale for lane checks and a claim that "it... mutates nothing" referring to doctor, disclosing nothing about what heal mutates, whether it is reversible, or what auth/state it needs.

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?

The opening is buried under a long anecdotal list of past collisions (refs/stash, CARGO_TARGET_DIR, PRE_COMMIT_HOME, .venv, branch TIP) that does not help an agent select or invoke the tool. Front-loading is inverted: the actionable content is absent while rationale dominates.

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 tool with six parameters, an output schema, and rich annotations, the description should at minimum say what heal does and when to call it. Instead it describes the lane lifecycle and doctor, leaving the actual operation of rm_lane_heal undefined.

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 fully documents env/base/path/repo/force/branch, including the truthful-remote-check nuance for env. The description adds no parameter syntax or meaning beyond the schema, so the baseline of 3 applies.

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 description opens with "Heal (rm_lane)" but never states what the heal action actually does. The bulk of the text is backstory about why lane checks exist and a pointer to a different subcommand (doctor), so an agent cannot form a verb+resource picture of this tool. It reads as a mismatched copy of lane-doctor documentation, not a purpose statement for rm_lane_heal.

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 when-to-use guidance ("doctor is the one to reach for when something behaves impossibly") is attributed to a sibling, not to heal, and no condition for selecting heal over rm_lane_doctor/rm_lane_start/rm_lane_finish is given. There are no exclusions or prerequisites for this tool itself.

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

Deploy Server