be get --nosub won't advance a store-backed switch-worktree's ref at all (stuck at its base), forcing fresh-clone salvage to land
Distinct from GET-016 (there the ref advances without the tree; here the ref does not advance at all). In certain store-backed worktrees be get --nosub does NOT fast-forward the local branch ref: this session MEM-041's and MEM-042's worktrees stayed pinned at 5104a855 across repeated be get --nosub, never pulling d857a9cc/91f215a4, while a sibling worktree (MEM-044) advanced normally. The stuck ones carried a 105-byte .be switch file vs MEM-044's 223-byte — pointing at a .be-switch-shape fast-forward gap (the GET-012 cwd-.be disambiguation: absent→worktree, dir→clone, file→switch). .refs.idx was fresh (not the stale-idx trap). Consequence: such worktrees can't update onto trunk in place, the Issues.mkd "update-first" step fails, and MEM-041/042/044 had to be landed by recreating fresh clones at the current tip. See GET, GET-012, GET-016, Issues.
.be is the small switch-file shape; land newer commits on trunk; be get --nosub in the worktree.be log tip stays at the old base and the newer commits are never pulled — repeatedly. Confirm .refs.idx is fresh (rules out DIS-033-style stale-idx). Pin the trigger to the .be switch shape..be = file) worktree's be get not FF its ref, when a clone-shaped (.be = dir) one does? Compare the ref-advance / FF path for the two shapes; GET-012 introduced the cwd-.be-shape branch.be get --nosub advanced the in-store branch ref but did NOT re-anchor the worktree's .be wtlog base; an explicit be get --nosub '?#<tip-sha>' (naming the target sha) DID re-anchor the wtlog and merged the intervening commits. So the gap is in the bare/implicit-tip path's wtlog re-anchor, not the fetch — the explicit-?#<sha> form is a usable workaround and a strong bisect lead..be shape; fix so a switch-worktree FFs onto trunk like a clone-worktree (then the Issues loop's in-place update works and fresh-clone salvage is no longer required).