DIS-039: bare be get is a no-op status per GET.mkd, but the Issues loop's "be get --nosub to update first" assumes it FFs — the two specs contradict, so the documented update step silently does nothing

GET-017's worker repro'd the original premise (a .be-switch-shape FF gap) as false: a store-backed switch-shaped worktree FFs perfectly in place via be get ? (empty ? = trunk) and via be get ?#<tip>. The actual gap is a spec contradiction: GET.mkd line 23 mandates "bare be get is a no-op status (≡ bare be)", and the impl honors it — sniff/SNIFF.exe.c:1124-1132 routes a URI-less get to SNIFFGetSummary (prints branches:/remotes:), so it never reaches the resume-checkout path sniff/GET.c:2204-2224 already implements ("Bare be get … resume the worktree's current branch", currently dead for the bare path). But the Issues skill line 31 prescribes "be get --nosub to update first" for the fix-and-land loop — so that step lists status and exits 0 without advancing the ref, the "stuck at base, forced fresh-clone salvage" symptom GET-017 described. Confirmed live during today's merge: be get '?' (with the ?) FFs the canonical tree correctly; bare be get does not. See GET, Issues.

Issues

The bare-get-is-status spec and the loop's update-first instruction directly contradict; impl follows the former.

Planned

Rule on the contradiction; deferred per the orchestrator's call (file-and-defer).