What problem does it solve? In repos with multiple git worktrees, a user who bookmarks a file:// URL to a deliverable file sees whatever branch that worktree is parked on — not main. After a PR merges, the user reports "the fix isn't there" even though origin/main is correct, because the browser simply reads the stale bytes on disk in that worktree. ## Core Features & Use Cases - Stale-content diagnosis: Confirms via git fetch + git show origin/main:<path> that the fix landed on main, then matches the user's file path against git worktree list to identify which worktree and branch the bookmark actually resolves to. - Canonical worktree setup: Establishes one worktree (usually the primary checkout) as the always-on-main bookmark target, including a safe audit (clean status, no unpushed commits, tracked .claude-memory/) before removing a worktree that holds main. - Use Case: A PM walkthrough HTML file still shows a removed card after PR #911 merged. The bookmark pointed at .claude/worktrees/quick-verify/ on a stale feature branch; the fix was to reclaim main on the primary checkout and hand the user a new bookmark URL. ## Quick Start Ask the assistant to check why a file:// bookmark still shows old content after a PR merged, and have it verify the file on origin/main and inspect git worktree list.