Module repair 

Package-manager and toolchain repair after a worktree is created. What: Package-manager and toolchain repair after a worktree is created. Why: Repair runs after worktree creation and has its own report.

In TS you’d write (pseudocode):

// repair/index.ts: one `export * from './file'` per module below.

Modules

package_repair

The repair of a new worktree’s package-manager state after a rung filled it and the ignored files were copied. What: The repair of a new worktree’s package-manager state: after a rung filled the worktree and the ignored files were copied, run each tool’s own offline repair so the state it keeps for the old location works at the new one. Why: A copy keeps links and build state exactly as they were. pnpm’s links climb out of the tree by a fixed number of levels, Cargo’s build state bakes in the source’s paths, and the toolchain launchers name the source’s lock. Each tool knows how to rebuild its own layout, so the wrapper starts it (the owner’s exemption, 2026-11-03) and never edits its files itself. A repair never fails the add: it ends in a line that names the command to run, and a tool the environment does not provide is a verdict, not an error. Another process changing the files while they are copied or repaired is the person’s risk and is not defended against.

package_repair_cargo

The Cargo repair of a new worktree: clone external build state, then clean the worktree’s own crates. What: The Cargo repair: for each Cargo workspace of a new worktree, clone the source workspace’s build state when Cargo keeps it outside the worktree, then cargo clean --package <member> for every member so only the worktree’s own crates rebuild. Why: Cargo bakes absolute paths into what it builds (CARGO_MANIFEST_DIR, build script output), so build state copied from another location is wrong for the worktree’s own crates, but registry and git dependencies hold nothing path-specific and can be reused. The owner chose this on 2026-11-03: “Reuse deps, rebuild own”, done with “Run cargo clean -p”. Where build-dir is outside the worktree (the person’s ~/.cargo/config.toml keys it by workspace path) a copy of ignored files does not carry it, so it is cloned; under Cargo’s default layout it is inside target/, which is already copied. cargo metadata names both directories, so no configuration is read by the wrapper.

package_repair_command

Starting one package-manager program for a worktree repair: finding it, running it with a limit, saying how it ended. What: Starting one package-manager program for a worktree repair: finding it on a search path, running it in a directory with its output captured and a quiet window, and saying how it ended. Why: The repairs of a new worktree (package_repair.rs) start tools the repository uses (pnpm, Cargo, mpm-shadow). Each one must end in a plain verdict the add can word for the person: the program is missing, it failed with a reason, it showed no sign of work for its window, or it worked. A tool that works is never ended for being slow (owner, 2026-11-03: “Install online during the add”; pick 9 of doc/planning/cli-git-shipped-limits-audit.md, the coordinator’s under the owner’s delegation and open to the owner’s veto), with the signs of work the push reads (push_progress.rs). Nothing here decides which tool runs or what its output means.

package_repair_pnpm

The pnpm repair of a new worktree: relink the copied node_modules offline against the frozen lockfile. What: The pnpm repair: pnpm install --offline --frozen-lockfile in a new worktree whose node_modules was copied. Why: pnpm’s links reach its store by a path counted in directory levels from the project, so a copy at another depth holds links that are dead or, worse, resolve through a parent directory’s node_modules to the source’s packages. pnpm rewrites its own layout for the new location in about the time of a no-op install.

package_repair_report

What a worktree repair prints: one line for success, one plain line per repair that could not finish. What: What a worktree repair tells the person: one line when the repairs worked, and one plain line per repair that could not finish, each naming the command that finishes it. Why: A repair never fails the add. The person must still learn that a worktree needs one more command, and which, so a failure is always printed (even under --quiet, which silences only the report of success).

package_repair_toolchain

The toolchain repair of a new worktree: rebuild the links and launchers that name another checkout’s lock. What: The toolchain repair: when the launchers copied into a new worktree’s .cache/toolchain-launchers still name another checkout’s toolchain.lock.json, rebuild the worktree’s own links and launchers with mpm-shadow install --frozen-lockfile. Why: mpm-shadow owns toolchain.plan.jsonc, toolchain.lock.json and the pinned tools. Its exposed links and launcher records hold absolute paths, so a copy would run the source checkout’s tool versions and guard, and a branch that changes the lock would silently use the source’s. The install is lock-constrained: it relinks what is installed and, when this worktree’s lock names tools that are not installed, downloads them. The owner chose that on 2026-11-03 (“Install online during the add”), knowing an add can then download and can retire tool copies another checkout still links. The summary line mpm-shadow prints says what was installed. A failed install never fails the add: it prints the reason and mise run toolchain:install.

package_repair_tree_clone

Cloning one directory tree with its modes, times and links, for the build state Cargo keeps outside a worktree. What: Cloning one directory tree for a worktree repair: every file cloned (or copied when the filesystem cannot clone), every directory recreated with its mode, every link recreated with its exact target, modes and times kept. Why: Cargo keeps its build state outside the worktree when the person’s configuration says so, so a copy of the worktree’s ignored files does not carry it. The state is reused by the new worktree’s registry and git dependencies, and Cargo decides what is fresh from file times, so the clone keeps them. The destination must not exist: nothing is overwritten.