Found while implementing #9450 (PR #10494). Filing rather than folding in: that PR's surface is .github/workflows/cut-rc.yml, and this is the producer half of the same question, in a different file.
The site
scripts/bump-objectui.sh:
if [[ -n "$EXPLICIT_SHA" ]]; then
NEW_SHA="$(git -C "$OBJECTUI_ROOT" rev-parse "$EXPLICIT_SHA^{commit}")"
else
NEW_SHA="$(git -C "$OBJECTUI_ROOT" rev-parse HEAD)"
fiHEAD of the operator's local objectui checkout — whatever branch that happens to be. Nothing between here and .objectui-sha asks whether the commit is reachable from objectui main. An operator who bumps with a feature branch checked out (or passes a branch name as the explicit argument) writes a pin naming a revision that is not on main, and the script reports success.
Why this is worth a card even though the release now fails closed
PR #10494 gives cut-rc.yml the reachability test it was only claiming to have, so a non-main pin is now caught — at release time, by a workflow that is workflow_dispatch-only and run a handful of times a month. The gap between "the bad pin was written" and "someone finds out" is therefore however long it takes to cut the next RC, and in between the pin is merged, and pnpm sdui:manifest (ADR-0082 D4) will have ratcheted spec↔registry parity against a tree that is not on main.
The check is one line at the point of writing, and it is the same predicate the release path now uses:
git -C "$OBJECTUI_ROOT" merge-base --is-ancestor "$NEW_SHA" origin/main
with the usual care that --is-ancestor exits 128 on an absent object rather than returning a verdict, and that a checkout with no origin/main cannot answer the question at all and must say so rather than guess.
Open design question for whoever takes it
Whether this should be a hard failure or a confirmable warning. The script is deliberately usable offline and on a machine that cannot run the full procedure (see the print_sdui_next_step rationale — it is a reminder, not a gate, on purpose), and origin/main in a local checkout is only as fresh as the last fetch, so a hard failure would reject a legitimately-just-merged commit whose origin/main is stale. A loud warning naming the branch the commit is on, plus the hard gate at cut time from #10494, may be the right split.
Scale of the thing it guards against
Measured on a fresh --no-tags clone of objectui, 2026-08-21: 941 remote branches, 118 branch tips not reachable from main, 291 commits present and not on main. Any of those is a rev-parse HEAD away from being the pin.
Related: #9450 / PR #10494 (the release-time half), #10134 (the pin is objectstack's decision, not a resolution of objectui main), #9408 (the other measured case of a git predicate answering a narrower question than the message claimed).
Generated by Claude Code
Found while implementing #9450 (PR #10494). Filing rather than folding in: that PR's surface is
.github/workflows/cut-rc.yml, and this is the producer half of the same question, in a different file.The site
scripts/bump-objectui.sh:HEADof the operator's local objectui checkout — whatever branch that happens to be. Nothing between here and.objectui-shaasks whether the commit is reachable from objectuimain. An operator who bumps with a feature branch checked out (or passes a branch name as the explicit argument) writes a pin naming a revision that is not on main, and the script reports success.Why this is worth a card even though the release now fails closed
PR #10494 gives
cut-rc.ymlthe reachability test it was only claiming to have, so a non-main pin is now caught — at release time, by a workflow that isworkflow_dispatch-only and run a handful of times a month. The gap between "the bad pin was written" and "someone finds out" is therefore however long it takes to cut the next RC, and in between the pin is merged, andpnpm sdui:manifest(ADR-0082 D4) will have ratcheted spec↔registry parity against a tree that is not on main.The check is one line at the point of writing, and it is the same predicate the release path now uses:
with the usual care that
--is-ancestorexits 128 on an absent object rather than returning a verdict, and that a checkout with noorigin/maincannot answer the question at all and must say so rather than guess.Open design question for whoever takes it
Whether this should be a hard failure or a confirmable warning. The script is deliberately usable offline and on a machine that cannot run the full procedure (see the
print_sdui_next_steprationale — it is a reminder, not a gate, on purpose), andorigin/mainin a local checkout is only as fresh as the last fetch, so a hard failure would reject a legitimately-just-merged commit whoseorigin/mainis stale. A loud warning naming the branch the commit is on, plus the hard gate at cut time from #10494, may be the right split.Scale of the thing it guards against
Measured on a fresh
--no-tagsclone of objectui, 2026-08-21: 941 remote branches, 118 branch tips not reachable frommain, 291 commits present and not on main. Any of those is arev-parse HEADaway from being the pin.Related: #9450 / PR #10494 (the release-time half), #10134 (the pin is objectstack's decision, not a resolution of objectui main), #9408 (the other measured case of a git predicate answering a narrower question than the message claimed).
Generated by Claude Code