be get fast-forwards the worktree to the TRUNK tip while recording the current branchinRepoSeed'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.