be head reports ahead/behind against a phantom ?trunk; URI-less be get --nosub regresses a submodule worktree to its stale .be pin
A store-backed submodule worktree (be/test, beagle-ext-tests) at its posted tip c0b8ffed was refreshed with a URI-less be get --nosub; instead of FF-ing forward it RE-APPLIED the stale .be-recorded pin ?#b8dc7f52 (1 behind the tip), detaching HEAD and REVERTING the committed+posted CMakeLists.txt and bro/lib/brocase.sh in the working tree. be get ? recovered files+commit (trunk ? tip IS c0b8ffed, per be log ?), but be head then reports ?trunk: 2 ahead, 0 behind — comparing against a NON-EXISTENT ?trunk (the trunk is ?, abs ?/beagle-ext-tests); an at-tip HEAD must read 0 ahead, 0 behind. No data lost (the commit was posted), but both the update and the status report misbehave. Hit live 2026-06-25 while refreshing be/test. Related DIS-039 (bare get = status no-op), DIS-022 (log empty in a sub/detached wt), DIS-038 (bogus ahead-count from a non-DAG tip), SUBS-026; rules in /meta/work.
be head's baseline resolves to a literal ?trunk that does not exist instead of trunk ? / the synthetic ?/project/.parent/pbranch, and URI-less get re-pins the last .be hash rather than FF-ing.
be head prints ?trunk: N ahead — there is no ?trunk; trunk is ? (abs
?/beagle-ext-tests). HEAD==trunk tip c0b8ffed wrongly reads 2 ahead, 0 behind.
?.beagle-ext/.journal: 1 ahead; once knocked off that synthetic
branch the baseline stays ?trunk, and be get ? does not restore it.
be get --nosub re-applied .be's last pin ?#b8dc7f52 (behind the tip),reverting committed+posted files — regressive, not the FF the Issues loop expects.
be get ?.beagle-ext/.journal and the abs ?/beagle-ext-tests/.beagle-ext/.journal
both SNIFFFAIL, so there is no CLI route to re-bind a sub to its synthetic branch.
None; data is safe — c0b8ffed is posted to ?/beagle-ext-tests/.beagle-ext/.journal and is the trunk ? tip. Re-attaching the wt to the synthetic branch is a commit-the-parent action per /meta/work.
Both defects share a root cause: the sub at its posted tip sits on its SYNTHETIC dot-branch, but head/get fell back to the sub shard's stale trunk ?.
OWN tip (REFS key ?/<proj>/<br>), not trunk ? → at-tip = 0/0.
?-trunk re-sync whose target is an ANCESTOR of thesynthetic cur tip is a forward NO-OP — never a backward revert.
? (no phantom ?trunk); the JS refs.js
in be/ still spells ?trunk (own follow-up; refs-parity normalises).
no CLI be get to the synthetic branch is needed/added.
-v head baseline: synthetic-branch tip target — graf/LOG.c:851. -v head trunk label ?trunk→? — graf/LOG.c:1138. -v bare get no backward revert on synthetic tip — sniff/GET.c:1321. -v repro test (file://, no ssh) — test/get/66-dis053-sub-tip-no-revert. -v be/ refs.js trunk label ?trunk→? (JS-side parity follow-up).
LANDED (audited 2026-07-07): d6f7e138 "DIS-053 be head synth baseline; URI-less get no revert" (beagle, 26Jun) + the be/ follow-up cf077a19 "DIS-053 refs.js: bare trunk sigil not literal trunk" (be, 26Jun).
graf_head_resolve_target resolved the implicit
target to trunk ? even when cur was on a synthetic dot-branch → sub at its tip read N ahead vs the stale pin; label printed ?trunk.
on trunk (empty query); a synthetic-branch cur (?/<sub>/.<par>#sha) skipped it, so bare get checked out the trunk pin backward.
graf/LOG.c:851 head target + :1138 ? label; sniff/GET.c:889
helper + :1321 synthetic no-op arm; refs-parity trunk-label normalise.
test/get/66-dis053-sub-tip-no-revert — FAILS on prebuilt
build/bin/be, PASSES on rebuilt build-debug; full ctest 378/378 green.
cf077a19): views/refs/refs.js:26
cur.branch || "trunk" → || "", so trunk emits bare ? not ?trunk, matching C be head. Test test/refs/trunk-sigil (FAILS pre-fix on ?trunk, PASSES post-fix; cross-checks be head oracle); be ctest green.