Release v0.73.0

[max-sixty]

Version bump and changelog for 0.73.0.

Minor bump: cargo-semver-checks fails four lints, so patch is disallowed pre-1.0. GitError gained two variants (shifting seven later discriminants) and a field on DetachedHead, ResolvedWorktree gained NoWorktreeAtPath, and Repository::resolve_worktree_name was removed.

Seven user-facing entries, led by #3785's ownership guard on removal. Two the drafting pass added beyond the obvious set:

• fix(env): drop Intel macOS from the flake, and install pwsh and jq for web setup #3776's flake change drops x86_64-darwin, so nix run/nix build and the home-manager module stop resolving on Intel macOS. Released binaries still ship for it.
• fix(gitlab): forward glab's verdict when the project lookup fails #3799 merged after the cut-from tip (91b7beff5) and so lands under the tag via the squash. Folded in rather than left to a follow-up squash PR — thanks to worktrunk-bot for catching it. chore: bump taiki-e/install-action from 2.85.10 to 2.85.11 #3801 and test(docs): drop the command-page sync test its docs file outlived #3802 also drifted in; both are CI/test-only.

Gates

• Local hook pre-merge --yes: 4599 tests, green.
• nightly.yaml dispatched on 91b7beff5 and fully green — full-tests on linux/macOS/windows, feature-powerset, release-target ×3, nix-flake, minimal-versions. It predates fix(gitlab): forward glab's verdict when the project lookup fails #3799, but this PR's own full-tests build the merge commit, so src/git/remote_ref/gitlab.rs is covered there.

Data-loss surface review

Four independent finders over v0.72.0..HEAD, then adjudication. One confirmed residual, reproduced against a build:

ensure_belongs_to_repo compares the occupant's git dir against the repository (<common> or <common>/worktrees/…), while git validates that the directory points back at this registration. So a directory holding a sibling worktree of the same repo passes the guard, and wt remove --force renames it into trash — git refuses the identical removal with validation failed … does not point back to '.git/worktrees/…'.

It is pre-existing and strictly narrowed by this release (0.72.0 had no check at all and deleted foreign clones too), so the decision was to ship and fix separately; a session is writing that fix now. There is no issue or PR for it yet — worktrunk-bot is right that nothing public records it.

Everything else adjudicated as acceptable: the selector normalization widens which tokens reach a removal but keeps the documented branch-first model; probe_timeout()'s WORKTRUNK_TEST_PROBE_TIMEOUT_MS can only suppress reaping; the shipped hooks, skills, and config.example.toml are byte-identical.

This was written by Claude Code on behalf of max-sixty

[worktrunk-bot]

The diff itself checks out — Cargo.toml and Cargo.lock agree, minor is right for the four semver-checks breaks (I confirmed WorktreeNotFoundAtPath/WorktreePathNotOurs, the worktree field on DetachedHead, ResolvedWorktree::NoWorktreeAtPath, and that resolve_worktree_name is gone), and each Fixed entry traces to code that does what it says. Two things around it:

#3799 will ship under the tag, undocumented. The release commit's parent is 91b7beff5, but main is at 1636b78dd — #3799 (fix(gitlab): forward glab's verdict when the project lookup fails) merged at 05:39, about three and a half hours before the release commit was authored, so the squash puts it below the tag rather than it drifting in during the CI wait. It's user-facing — the error wt switch mr:<n> prints when a fork MR's project lookup fails, with snapshot tests — so step 12's coverage check would want it folded in via a follow-up squash PR. Cheaper to add it here; inline suggestion below, placed last in Fixed since it reaches the fewest readers. Minor corollary: the nightly gate ran on 91b7beff5, so src/git/remote_ref/gitlab.rs isn't covered by this release's full-matrix run (it did get ci.yaml on its own PR).

"Tracked as a follow-up" doesn't resolve to anything yet. I couldn't find an open issue or PR for the ensure_belongs_to_repo residual described in the body. The gap is real in the shipped code — git_dir.starts_with(common_dir.join("worktrees")) accepts any of this repo's linked worktrees, not just this registration's, so a sibling's directory passes the guard and wt remove --force renames what git refuses to touch. Since it's a deletion-surface candidate and the release skill's rule is not to lose one, worth filing before the tag rather than after it, while the reproduction is still to hand.