Which ref you ask decides the answer

worktree-merge-verifier resolved its base to the local main and never fetched. Pick a repo and a base ref below. The branch never changes; only the ref does, and the verdict flips from "fully merged" to "you will lose hundreds of commits".

Repository (measured 2026-08-19)
Base ref the hook asks

The measurements

repolocal main isvs local mainvs origin/main
orchestkit47 commits behind450
hq-ext-plugin587 commits behind731144

In the orchestkit row the branch tip is a verified ancestor of origin/main (git merge-base --is-ancestor cf231c64f origin/main returns 0), so the true count is zero and the entire warning was noise. The hq-ext 144 is a real promote, correctly reported once the ref is right.

Why a false positive here is worse than silence

This advisory exists to make worktree cleanup safe. A confident "731 commits would be lost" on an already-merged branch teaches the reader to dismiss it, which is exactly when a true positive gets dismissed too. It is not hypothetical: a live session measured git log origin/main..HEAD, got the correct empty answer, was contradicted by this hook, and retracted a right conclusion in favour of a wrong instrument.

The fix prefers origin/<base>, falls back to the local ref only when no remote-tracking ref exists, and returns null when nothing resolves so that "could not measure" stays distinct from "measured zero". It does not fetch, because this runs in PreToolUse and must stay fast.