Sweep four consumed wave-admission rows that refuse every roster-touching PR

[gunbai-bot]

What this is

A one-file sweep of four consumed rows from NAMESPACE_TRANSITION_ADMISSIONS. It carries nothing else.

Why it is in front of the queue rather than inside the PR that found it

The namespace-wave-admission phase refuses any roster-touching change while a consumed admission stands. It does not refuse the PR that created the rows — that one merged. It refuses whoever next touches this file, which is how this was found: on #10073, whose subject is a clippy gate and has nothing to do with Redfish boot override.

required-floor: verdict=FloorClean unexpected_failures=0 verdict_incomplete=0
required-ci: FAILED PHASE namespace-wave-admission (0 unadjudicated delta(s),
  0 stale admission(s), 4 consumed admission(s) due for deletion on this roster-touching change)

Note the first line: the floor itself was clean. The job died in a later phase of the same lane.

So the obligation is a serialised wall sitting in front of the whole merge queue — either a queue member touches the roster and eats the identical refusal, or nobody does and the rows are still standing for the next one. It is cheaper as its own PR.

The receipt is per row, not per cohort

The rows were born consumed: de531c35496 (#10010) is both the commit that authored them and the commit that performed the move they admit, so no run after it could ever match them. Their dissolve-on trigger — "this change merging" — fired at that merge.

Each row admits TargetChanged binding in gunbc.srv3_boot_once_cd, declaration srv3_boot_once_cd_resolved, base {gunbc.srv3_boot_once_cd} → head {gunbc.srv3_os_install_actuate_workflow}. For each spelling, established separately, on the base:

row	declared in target module	imported from target	occurs in srv3_boot_once_cd_resolved
srv3_boot_cd_target	yes	yes	yes
srv3_boot_cd_enabled	yes	yes	yes
srv3_boot_cd_mode	yes	yes	yes (twice)
srv3_boot_cd_reset_type	yes	yes	yes

The reference exists and resolves to the target on both sides, so the admitted delta cannot be produced. All four fired. None was swept for tidiness — had one lacked a fired trigger it would have been left standing and said so, because four rows swept with three receipts is worse than three rows swept.

Two things done to the ledger's prose, not just its rows

Deleting rows is exactly what makes a ledger's deictic references false, and this ledger's own fifteenth entry established the rule:

• The sixteenth entry said "this change", which after its merge denoted the wrong commit. It now names Scoped just-in-time operator token grant: extend WorkflowApprovalState so a credential grant names scope, resource, expiry and consuming attempt #10010. Tense and position words only.
• That entry predicted these rows would "report stale". They reported CONSUMED. The prediction is left standing and corrected in place rather than edited away — the two are not synonyms, and only CONSUMED carries the deletion obligation onto an unrelated change. Which disposition an author predicts decides who pays.

Verification

cargo check and cargo clippy --all-targets on v1-compiler are clean; cargo fmt --check passed in the pre-commit hook. No test asserts the roster's contents.

Resting state restored to empty — which is not permissive: a run with a real delta still refuses as UNADJUDICATED.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NaYej9KqftabgV7gshZw5j

[gunbai-bot]

Pushed 275072c35f3 in response to review 58780.

The review's remark about the #![allow(...)] block was the finding, though not quite in the sense it was written. It reads the block as honestly rostering "the two lints newly visible after the generated-crate-root allow was tightened" — but nothing in this PR tightens that root. That is #10073's mechanism. The block arrived here by accident: I lifted this sweep's patch with git diff origin/main from a tree that already had #10073 merged into it, and it dragged the roster along with the row deletion.

Left standing it would have been a false claim landing on main. Its own first sentence says "Until this commit the generated crate root allowed clippy::all plus six rustc groups" — true in #10073, false here, where the root still blankets and those findings stay invisible. It would also have landed the identical block twice, once from each PR, and the second would have conflicted.

Clippy is clean on this base without it, which is the confirmation rather than a coincidence: the roster only has content once the blanket it describes is gone.

The rest of the review I have left alone — the per-row receipts and the left-standing "stale" prediction are as described.

— sent from deep-stag-577