scm status: the unresolvable-checkout refusal names the commit it cannot resolve

[gunbai-bot]

gunbc scm status on an unresolvable checkout prints:

the checked-out selection names a commit this repository does not contain

Which commit? The arm bound its reference to _ and threw the identity away. The reader is told a selection is unresolvable and not which selection — they cannot tell whether they mistyped, and no care on their part recovers an identity the renderer discarded. That is unactionable by construction, and a refusal that does not locate leaves the diagnostic half of DESIGN §5 unmet: the refusal is typed and located in the code, and located nowhere for the person reading it.

It now reads:

the checked-out selection names commit 7, which this repository does not contain

Why the ordinal, and why it is not a leak

repository_envelope's encoder already spells a commit's identity on the wire as json_kv(key: "id", value: json_int(n: minted_id_ordinal(...))). So this number is the one the persisted document shows, and it is what checkout_repository_at consumes. Printing it repeats the naming scheme the model already publishes rather than inventing a second one (§3).

The sibling arm is deliberately left alone

CheckedOutCommit names no commit either, and I am not fixing it here. It carries a root ObjectId and no reference, so the only identity in reach is the content hash — which status_does_not_report_store_representation states this surface must not report, on the ground that below-boundary representation is opaque. Naming that commit by its ordinal requires StatusCheckout to carry the reference, which is a change to the carrier, not to its rendering.

That change is small — status_checkout_of already binds reference in scope at the exact site that constructs CheckedOutCommit and discards it — but it touches a type and its consumers, so it goes in a follow-up rather than being smuggled in here. The identity is not unavailable; it is dropped at the constructor. Repaired where the fact is already present; the other arm is left stating a known gap rather than closed by printing the one identity this surface must not expose.

Evidence

Baseline — all 7 claims in the file, by execution:

a_fresh_repository_reports_nothing_checked_out_and_is_resolvable  true
a_dangling_checkout_is_reported_as_missing_not_as_ordinary        true
a_resolvable_checkout_carries_its_commit_message                  true
stated_absence_not_stated_and_stated_binding_are_three_distinct_renderings true
nothing_staged_is_stated_rather_than_rendered_as_silence          true
status_does_not_report_store_representation                       true
a_dangling_checkout_names_the_commit_it_cannot_resolve            true

Mutation receipt — drop the identity again, keep everything else:

	new claim	reported_as_missing	nothing_staged
fix present	pass	pass	pass
identity dropped	FAIL	pass	pass
restored	pass	—	—

The two controls staying green are the load-bearing part: they show the mutation is targeted rather than destructive, so the red is the identity and not collateral.

The claim drives ordinals 1 AND 7 through the same arm. A single case is satisfied by a renderer that prints a constant — which is the defect being repaired, wearing a number. Two ordinals make the assertion about the selection: the only implementation that passes both is one that reads reference.

How the omission survived

This arm's text was pinned by nothing, beside two sibling arms that were pinned exactly. The file otherwise documents every shape decision it makes, and render_status_checkout is the one function nearby carrying no rationale — the omission was never decided, just never noticed. (The _ bindings in status_checkout_is_resolvable are correct by contrast: it returns Bool, so the identity genuinely is not needed there.)

Note on CI

Main is red on the floor lane on each of its last six runs across six distinct SHAs, so a red here is expected and is not from this change; main's build lane passes. Measure base against branch rather than reading the red as this PR's, and note a FAILED-line grep undercounts by exactly the errored rows.

[gunbai-bot]

The failing check is a cancelled floor lane, not a defect in this change. No fix to push; re-run is in flight as attempt 2.

Attempt 1 (33189439592): required-witnesses-build success, required-witnesses-floor cancelled mid-execution at 17:10:04 after ~49 minutes with the orphan claim_executor terminated. The witnesses aggregator then correctly reported red — a lane that is not success must not produce a green required context, which is the always() behaviour working as designed rather than a second failure.

It is not the ordinary supersession. There was no superseding push on this branch, only one run existed, and the concurrency group is correctly keyed witness-floor-${{ github.event.pull_request.number || github.run_id }} — per-PR, so another branch cannot cancel this one. I checked that specifically, because a too-broad key would have been a real defect. Runner-side is the remaining explanation and I cannot evidence it from what I can query, so I am flagging it rather than filing it as noise.

Context for reading this red at all: across the last 100 witness runs today (07:32Z–17:08Z) there are 51 cancelled, 41 failure, 8 in flight, and zero successes — on any branch, not just main. No PR can currently satisfy the checks-not-failing criterion regardless of content.

This PR's own lanes: build passes, and it carries no regen obligation — only five gunbc.* modules have emitted stage0 mirrors, there is no scm mirror, and nothing in stage0 references gunbc.scm.status. (That is the check I ran before pushing, having just been caught by the opposite case on #9603, where cli_dispatch_surface is one of the five.)

I captured the attempt-1 record before re-running, since a re-run overwrites the run-level conclusion and the evidence stops being reconstructible at that level.

— sent from gentle-eagle-360

[gunbai-bot]

Infrastructure note for whoever picks this up — the attempt-1 cancellation was an anomaly, not a defect in this PR.

This PR's floor run was cancelled once at ~49 minutes with no superseding push, only one run on the branch, and the per-PR concurrency key ruling out a cross-branch cause. That matched a recorded "floor dies alone while build survives" signature, so a prediction was registered before re-running: if the signature were real and time-based, attempt 2's floor would die in the same 43–51 minute band.

It did not. Attempt 2's floor started 17:12:15Z and was still running at 18:15:46Z — 63 minutes, past the predicted window and 14 minutes past attempt 1's death point, with build already green. The prediction is refuted and the systematic reading is withdrawn.

So attempt 1 remains unexplained but is not part of a demonstrated pattern, and nothing about it indicates a problem with this change. Noted rather than chased.

Separately, and this does affect the numbers here: main moved three times around 17:41–17:56Z — #9591 merged, and #9517 restored the per-claim CPU ceiling from 5000ms to 500ms while withholding 276 identities from the floor plan. Any floor result on a run created before that tested a tree that no longer exists. This PR needs a fresh run against the new base before its floor numbers mean anything.

Build lane was green and the change itself was approved.