beagle worktree from the local store
be get against the local store (file:/home/gritzko/.be/?/<shard>) restores be/abc cleanly but CANNOT produce a current beagle worktree: every beagle form either errors (SNIFFFAIL) or hands back a stale snapshot missing the just-committed test/bin, test/js. The live beagle is clean at ac4ef2a3 (be status → 1324 ok, includes test/bin/*), so the tip IS in the store — but trunk get won't restore it. This blocks the Issues loop for every beagle-side ticket (SUBS-034, JS-062, JS-063). Found via the worktree setup for those. Method Issues. Drove with ~/journal/beagle/build/bin/be.
be get file:/home/gritzko/.be/?/be (be/beagle-ext trunk, recurses the test sub) and ?/abc (?/libabc).?/beagle, ?/beagle/.beagle-journal, ?/journal, ?beagle → be: worktree from /home/gritzko/.be/ then SNIFFFAIL/BEDOGEXIT.?/beagle#.beagle-journal restores ?trunk and ?/beagle-journal restores beagle@5a95cd15 — both an OLDER beagle MISSING test/bin+test/js (and ?/beagle-journal omits the be submodule entirely). dog/HOME.c in them is byte-identical to live, so only the recent test dirs are absent.~/tmp/beagle-clone, prebuilt be; repo is ~/journal, there is no /journal) — file:/// vs file:/ give DIFFERENT errors for the same bad path, and the journal-projector forms all WIRECLFL: → WIRECLFL`. → WIRECLFL`. → WIRECLFL`. → SNIFFFAIL` "get: cannot restore /journal
— no baseline in .be/wtlog" (single-slash parsed the path differently).
→ BEDOGEXIT` (hangs first) forevery shard tried (beagle, be, libabc, beagle-ext-tests).
.be anchors RECORD an unreplayable get-URI
file:/home/gritzko/.be//?/<shard>#<hash> (double slash); replaying it → SNIFFFAIL "no baseline in .be/wtlog".
be get yields a current, committable beagle worktree from the local store (the tip the live worktree is pinned to, ac4ef2a3, with test/bin+test/js)..be get-URI round-trips: a worktree can be re-gotten from its own anchor.WITH_INET=OFF build; the ?/beagle journal-projector form file:///home/gritzko/journal?/beagle already fails WIRECLFL chasing the github submodule source — must resolve to the LOCAL shard, never the wire).beagle shard trunk ref never pointed at the live tip ac4ef2a3; the original SNIFFFAIL was "no post row", later a divergent older 5a95cd15 (author replicated.live) was the only post, so plain ?/beagle legitimately restored the WRONG older commit (no test/bin/test/js). (2) CODE BUG — be get <store>?/<shard>#<sha> silently DROPPED the explicit #<sha> pin and always took the shard trunk tip.pinned_explicit flag (YES only for a user-typed #<sha> on a bare-store clone) so worktree-source clones (whose hash is the primary's resolved tip) still track+advance their branch — avoids regressing be-get-52/56.beagle/test/be-get-store-shard-pin.sh (+ CMake be-get-store-shard-pin) — clones ?/<proj>#<OLD>, asserts pin honoured + committable trunk-state. RED→GREEN.BE.cli.c be_sub_shard_setup (u->fragment) + sniff/GET.c SNIFFGetURI (pinned_explicit (BE.cli.c l.894/902/1072); gate the query NULL-out on u8csEmpty(u->fragment) (GET.c l.2052). No regressions (ctest: the 8 known fails unchanged, zero new).post ?#ac4ef2a3 so plain ?/beagle restores the current tree with test/bin (verified) — unblocks SUBS-034/JS-062/JS-063.be head ?/<shard> hang; file:///…journal?/<sub> WIRECLFL./home/gritzko/.be/beagle/refs was MUTATED during investigation: post ?#5a95cd15 then post ?#ac4ef2a3 rows appended (the latter an unintended side effect of a be get '?#<sha>' run inside a beagle-anchored wt). Trunk now points at the live tip — arguably correct, but not deliberate. Human to decide keep-vs-clean. (get_fail log rows also grew.)f425d6a8 — landed (posted by the human): BE.cli.c carries the #<sha> fragment + a pinned_explicit scope, sniff/GET.c gates the empty-query NULL-out on u8csEmpty(u->fragment), + repro be-get-store-shard-pin. be get …?/<shard>#<sha> now honours the pin as committable trunk-state. The beagle store trunk ref was also advanced to the live tip so plain ?/beagle restores the current tree (the original "no baseline" blocker is gone).