be get fast-forwards the worktree to the TRUNK tip while recording the current branch
inRepoSeed's D3' arm resolves the tip from the RAW query, not from the branch it is about to record: branch = query is "" for a bare get (also for ! and ?), so tip = k.resolveRef(branch || "") returns the TRUNK tip (store.js:420-442 keys "" to the trunk and has no "current branch" key), while wantBranch = branch || curBranch — and the appended row is get ?<curBranch>#<trunk-tip> (get.js:514-520). On any non-trunk worktree a bare be get therefore checks out the TRUNK and mislabels the base as the branch's, silently: post then takes its parent from that base (post.js:581), status computes divergence against it, and the classifier reads it as the ours baseline (classify.js:226). The comment two lines above states the intended behavior ("an empty/absent query folds to the current branch", get.js:511-513) and worktree:44-48 + GET:32 agree ("bare: FF the wt to cur's branch tip") — a plain defect, not a spec gap. Invisible on a trunk wt (curBranch "" → the trunk IS correct), which is why the test set misses it.
The resolve reads branch, the record writes wantBranch; the two differ exactly when the worktree is not on the trunk.
resolveRef(branch) but records wantBranch = branch || curBranch — and the curSha fallback only fires when the trunk ref is ABSENT.resolveRef("") matches the empty-query row = the trunk; there is no key meaning "whatever cur tracks".?<wantBranch>#<tip> — track says the branch, base is the trunk's tip; every later reader trusts the pair.? (an explicit trunk switch) and a bare be get are INDISTINGUISHABLE: get.js:465 u.query || "" collapses the URI-009 absent-vs-empty slot the comment at get.js:459-462 relies on.
Resolve what you are about to record; keep ? an explicit trunk switch.
get and ! resolve the tip from the tracked branch (resolveRef(wantBranch) in today's terms; the track URI once DIS-071 lands).get and ? stay separable without href string matching.?feature behind the trunk; bare be get FFs to feature's tip, and the record's track and base agree.Minimal fix, D3' only — this arm is load-bearing for every other verb's baseline.
?br#sha), D2 (?<sha>), D3 (#~N) and D4 (restore) alone — minimal fix, end-to-end verify.href === "?" string matching (the shape the old code carried).jab get file:<path> (the working wt-clone form).be get → trunk contamination (track/base disagree in the recorded row)? still switches to the trunk! (force) FFs the tracked branch too, not the trunk?br source resolve (get.js:540-543) for the same read-one-write-another classcc531c5f "DIS-073: base/track unification" — the D3' arm resolves wantBranch (the tracked branch), and queryPresent keeps URI-009's absent-vs-empty so ? stays an explicit trunk switch.test/get/branch-bare (be-js-get-branch-bare) — a wt on ?feat behind feat's tip (advanced by a sibling wt off the same store); verified RED before / GREEN after, so it pins the defect, not the fix.?br audit (TODO 4) was declined as out of the "D3' arm only" scope — no confirmed bug there, so no ticket; re-check when DIS-071 touches get's resolve paths.#<sha> (detached) vs ?#<sha> (trunk) needs.