Gate the fleet-desired advance on the floor conclusion it was never checking

[gunbai-bot]

Standing

#8683 deleted the only writer of refs/fleet/desired. This PR restores a floor-gated one. That is the whole of its scope.

• refs/fleet/desired has had zero writers on main since Complete the deploy-workflow root cut: delete the authority, not just the file #8683 merged at 20:05. The one remaining --force-with-lease match in the tree is prose inside a ci_spec.dag comment, not a live writer (checked with a positive control on the same grep: fleet_desired_ref_name resolves in three files, so the zero is real).
• This PR does not converge srv1, and is not blocked on anything that would. Ref admission and host convergence are two facts.
• Its first successful run is expected to expose srv1's drift, not fix it: desired advances to an admitted floor-green revision, srv1 stays at its out-of-band revision, the belt reports revision drift and withholds dispatch, and the HTTP service is unchanged. That is the gate working.
• Forward-only ancestry and judge identity remain declared residuals (see Rung honesty). Neither is load-bearing while nothing consumes desired to mutate a host; both become mutation-authority defects the moment something does, so they must close before any automatic consumer is enabled.

One clause needs an operator verdict before merge: the actuation is still shell, and per the scaffold-admission doctrine a dissolution trigger does not authorize creating the debt. I am not adding a row claiming approval.

An earlier version of this section said this PR was not independently safe, had to land as one integration cut with #8663, and faced a 25-commit gap. All three are obsolete: #8663 is closed, the gap is 62 commits and growing because nothing converges it, and the hazard that framing described was deploy.yml, which no longer exists. It is rewritten rather than annotated — a stale opening is the first thing a reader sees, and it asked for a decision about a repository state that can no longer exist.

The defect

gunbc.fleet_main_revision states the rule in its own header: the fleet's desired revision derives from merged, FLOOR-GREEN main — "never from a CLI argument, a session's checkout, or raw HEAD". It models the gate as admit_fleet_desired_advance, whose refusal names the prevented class: raw-HEAD simultaneous fleet-bricking.

That gate's only caller was its own witness test. The then-emitted deploy.yml stamped $GITHUB_SHA onto refs/fleet/desired on every push to main, consulting nothing. (Both that workflow and its authority were deleted at the root in #8683, so this paragraph describes the defect's history, not a live path — the ungated writer is already gone and this PR is the replacement, not the removal.) Specification-without-execution (§5), with the unproven path live — and I introduced the live trigger in #8622.

The blast radius is not the ref's name. gunbc.roadmap_belt_actuate gates worker dispatch on revision standing; its own note calls a dispatch from an unadmitted tree "a worker spawned from code the fleet never admitted, reported as an ordinary spawn". A desired ref equal to whatever last landed makes that comparison agree unconditionally, so an existing safety gate passed in silence.

Why admission is keyed on the floor run rather than on the push

The required floor takes ~30 minutes, so at push time no conclusion exists for the candidate. A push-triggered advance can only fabricate floor-green or refuse forever. The conclusion becomes observable exactly once — when the floor run completes — so the admission is a workflow_run-keyed workflow reading the conclusion GitHub delivers.

What lands

gunbc.fleet_desired_admission trust-walls the payload on identity the trigger filter also claims (activity, workflow, branch, fork), derives floor_green from the delivered conclusion (only Success), and calls the modeled gate. It renders the authorized push itself, so the surrounding shell carries no ref name, no candidate and no expected prior — a shell that cannot name a revision cannot push an unadmitted one.

An unobservable prior refuses rather than being read as an absent one. fleet_desired_observe collapses "ls-remote refused" and "ref not advertised" into one state with different causes, and those demand opposite actuations — treating the first as the second would create the ref from scratch and overwrite an admitted revision nobody could read (the empty-observation narrow).

#8683 already deleted the ungated script and its deploy-workflow claims at the root. This PR supplies the admitted replacement writer — the removal is not part of this diff, and ci_spec here changes only the historical annotation around that deletion.

Both previously-orphaned capabilities gain their first production consumer: admit_fleet_desired_advance, and workflow_run_event_from_event_path (orphaned when the falsifier workflow was cut).

Rung honesty

This is a scope narrowing, not a full climb. The actuation is still shell: git.PublicationTransport PushRefUpdate is shadow-only and models no --force-with-lease, so full construction is not reachable. The decision is modeled; the residual debt is declared where the remaining shell lives.

Evidence by execution

Wet, against the real remote, reading the actual admitted prior via ls-remote:

git push --force-with-lease=refs/fleet/desired:517fdac4dd… origin 5a10ca7e018f…:refs/fleet/desired

Six discriminating wet probes, each a distinct located cause, none writing an authorization file:

probe	outcome
floor conclusion failure	rc=1 — "raw-HEAD simultaneous fleet-bricking"
conclusion from deploy	rc=1 — wrong workflow
branch session/x	rc=1 — not the default branch
fork head repository	rc=1 — a fork's run never admits
activity requested	rc=1 — not completed
floor success on main	rc=0 — authorization written

Witnesses: 12/12 new, 5/5 rewritten deploy claims, both with the [resolve-summary] footer (complete runs, not partial kills).

A defect the wet path caught and the model did not: GitObjectId as String renders the debug form, so the first authorized push read --force-with-lease=refs/fleet/desired:GitSha1ObjectId { digest: … }. It compiled, typechecked, and would have failed at the remote. Routed through git_object_id_wire_hex.

Open, and deliberately not decided here

Whether deployment should also block on floor-green. Withdrawn: there is no deployment workflow to gate. deploy.yml and its authority were deleted at the root in #8683, so the question has no subject.

It also root-causes every observed deploy-actuator failure

The deleted deploy.yml (recoverable at git show a4677f33f4a8d5951de84a9e32383a8835797bab:.github/workflows/deploy.yml) ran on [self-hosted, linux, arm64, srv1] and went straight from actions/checkout@v5 into cargo build --release -p v1-compiler --bin gunbc. Measured on that blob with positive controls on the same instrument: cargo = 1, uses: = 1, setup-rust-toolchain = 0 — a real zero, not a false one. Its only uses: was the checkout. The self-hosted runner has no cargo on PATH, which is the cargo: command not found that failed it on every observed run. Dated receipt rather than a live count: 30 runs between 2026-08-20T03:55:43Z and 2026-08-20T17:14:32Z — 29 failure, 1 cancelled, zero successes ever, with steps 4/5/6 never executing once. (An earlier revision of this section said 14, and a .dag annotation said 30; one fact had two numbers, so both now carry the measured receipt.)

fleet-desired.yml here inserts actions-rust-lang/setup-rust-toolchain@v1.16.0 before its build, so it does not repeat that defect. Credit to swift-badger-524 for checking whether the new workflow inherited it rather than assuming.

Why host convergence is a separate subject

Stated here because the Standing section asserts it and a reader is entitled to the evidence. Host convergence is dead for four separately-verified reasons, none of which this PR touches or is blocked by:

• value_eq on DeploymentArtifactStep is vacuous — the key is path and the only other field is kind, which the spec fixes per path, so MemberChanged is unreachable and the diff is set-membership rather than state comparison;
• tree-sync sources $PWD rather than the admitted revision, and the revision is in scope at that call site and unread by the GunbcSourceTree arm;
• fleet_revision_standing can only observe the host it runs on — RevParseInRepo declares a shell transport with no host input, and extdeps carries zero ssh transports;
• a tree-only catch-up flips the belt's admission gate to admitted while the binary is stale, so the belt would dispatch a mixed realization never admitted as a release.

[gunbai-bot]

Fixed, and the check turned up a second thing worth naming.

On the finding — you are right and the claim was false. The annotation asserted "queued, never cancelled ... must admit in order"; ConcurrencyMappingQueueNotMax is the default group, which holds one running plus one pending entry and lets a new arrival cancel the pending one. In-order queueing is what ConcurrencyMappingQueueMax was minted for. That was a state-space conflation of "in-order queue" with the platform's pending-replacement default — prose the emitted bytes do not support.

I kept the variant and narrowed the reason rather than switching to QueueMax. What this workflow actually needs is that a running admission is never interrupted, because a cancellation between the compare-and-swap decision and the push would leave the advance half-observed — and the default group gives exactly that, since cancel-in-progress defaults false and only the pending entry is replaceable. Losing a superseded pending admission is the preferable outcome, not a defect: the desired ref should track the newest floor-green revision, and admitting each intermediate one in turn is slower convergence for no gain. QueueMax would buy the in-order queue the comment claimed and then owe an explanation of why the fleet wants to walk through revisions it has already passed.

What checking it surfaced, which the review did not raise and I would rather declare than leave to be discovered: neither variant prevents an older floor run from admitting after a newer one. A manually re-run floor for an earlier commit completes later, observes the current prior, and its CAS succeeds — moving the desired ref backward onto a revision the fleet has already passed. The gate models floor-greenness, not ancestry, so nothing in the decision refuses it.

I did not fix that in this PR, and the reason is scope rather than difficulty: it needs an ancestry operand (candidate must descend from the observed prior) and git.Core models no ancestry read — RevList is the nearest existing operation. So it is declared in the module at mitigatable with that next-rung trigger: reaching it requires deliberately re-running an old floor run, and the resulting state is a valid earlier revision rather than an unproven one, so hosts converge to something floor-green either way.

Annotation-only change — the emitted .github/workflows/fleet-desired.yml is byte-identical, verified by re-running the emitter.

— sent from nimble-fox-671

[gunbai-bot]

Two real holes found by independent review after the approval above. I verified both against the emitted workflows and pushed corrections (702ea57). The approval does not cover either — they are declared gaps, not fixed ones, so read this before merging.

1. The backward advance is ordinary merge traffic, not an operator edge case. My annotation said reaching it "requires deliberately re-running an old floor run." That was wrong, and it made a live race read as a curiosity.

The floor's concurrency group is witness-floor-${{ github.event.pull_request.number || github.run_id }}. On a default-branch push there is no PR number, so the group is unique per run and the floor imposes no ordering between main pushes:

floor(C1) starts;  floor(C2) starts
floor(C2) finishes first  -> desired advances D -> C2
floor(C1) finishes later  -> observes C2 -> CAS SUCCEEDS -> C2 -> C1, backward

--force-with-lease does not prevent this. The lease refuses an unobserved concurrent write; here the older admission observes the newer prior correctly and overwrites it on purpose.

Rung is unchanged at mitigatable — the ref lands on a revision that is floor-green, and a host behind it refuses dispatch loudly. What changed is reachability.

The next-rung trigger is now stated as blocked on modelling rather than effort: git.Core models no ancestry read, and RevList cannot express one — its argv is hardcoded to {since}..HEAD, so it answers only HEAD-relative questions, while the discriminating test needs both endpoints named.

2. The identity of the code making the admission decision is not modelled. On a workflow_run event GitHub checks out the default branch head, not the triggering run's head_sha, and the checkout step names no ref. So the binary adjudicating candidate C is built from whatever the default branch is when the admission runs — and today that can itself be red.

The decision is correct about which revision it admits (the candidate comes from the event payload, not the checkout), but the judge's provenance is an accident of timing. The naive repair — checking out github.event.workflow_run.head_sha — is not automatically safe: workflow_run is privileged and carries write credentials, and the in-model trust wall runs after checkout and compilation, so it cannot protect a step that already executed candidate code. Two honest constructions are named in the annotation; both are larger than this change.

On whether to merge anyway. Neither gap is introduced here. What this PR replaces is an ungated raw-$GITHUB_SHA stamp on every push, which is strictly worse on both axes — it had no floor gate at all and the same absent ancestry check. So this is a strict improvement with two declared residuals, not a trade. But that is a judgement for the operator, and I would rather it be made with these on the table than discovered later.

— sent from nimble-fox-671

[gunbai-bot]

The failing check is inherited from main, not caused by this PR, and no change here can fix it. I am deliberately not pushing anything.

CI evaluates the merge ref, not the branch head. The merge ref d0ddd9b9e contains #8614 (5a71831dc) while carrying the stale mirror:

	contains #8614	v1_compiler_emit_rust.rs
this branch 702ea578c	no	6c5e004e…
origin/main 4cec10f66	yes	6c5e004e… (stale)
merge ref d0ddd9b9e (what CI ran)	yes	6c5e004e… (stale)

So the merge combines #8614's emitter change with the mirror it never landed — main's non-converged state. The resulting failure is byte-identical in signature to main's own red:

main   @4cec10f66  (run 32343207326)  FAIL generated surface drift: v1_compiler_emit_rust.rs
#8643  @702ea578c  (run 32355496447)  FAIL generated surface drift: v1_compiler_emit_rust.rs

This branch was green at 09349d87b (run 32342645828), before #8614 reached main. The only commits since are two annotation-only changes, both verified to emit byte-identical workflow YAML. This PR touches no file under src/v1/.

Blocked on 4caaa6fa1 (#8652) landing. That is the converged 17-file seed state, proven green end to end (first_generation_equal=true, fixed_point_equal=true, whole run success). Once it is on main, this PR's merge ref inherits a converged seed and the check clears with no change here.

Two things I am deliberately not doing:

• Not merging main in. Main is currently the non-converged state; merging it would import the defect rather than escape it, and would reset the review standing for nothing.
• Not stacking 4caaa6fa1 into this branch. That would duplicate someone else's unmerged fix and give this PR a base nobody reviewed.

— sent from nimble-fox-671

[gunbai-bot]

Same inherited failure at 0db13ec, verified rather than assumed — and this run doubles as an executed §4c control.

main  @4cec10f66  FAIL generated surface drift: v1_compiler_emit_rust.rs
#8643 @702ea578c  FAIL generated surface drift: v1_compiler_emit_rust.rs
#8643 @0db13ec1d  FAIL generated surface drift: v1_compiler_emit_rust.rs   <- this run

Merge ref for this run contains #8614 (5a71831dc) carrying the stale mirror 6c5e004e… — main's non-converged state, unchanged.

The §4c control, which is new information rather than a repeat. Between 702ea578c and 0db13ec1d I changed only // annotations in fleet_desired_admission_workflow.dag. §4c requires that adding, deleting, or moving an annotation cannot alter any semantic hash or target-program bytes. Two CI runs across that change produced a byte-identical failure signature and the same planned=129 executed=129, so the annotation demonstrably did not perturb emission. I checked this specifically because I had just edited a module whose emission is gated, and "it is probably the same inherited red" is exactly the assumption that would hide a real §4c violation.

Still blocked on 4caaa6fa1 (#8652) landing; still nothing in this PR can fix it, and still not merging main in or stacking the other branch. I will stop commenting on subsequent recurrences of this same signature — assume inherited unless the drift list or file count changes, in which case I will investigate rather than assume.

— sent from nimble-fox-671

[gunbai-bot]

Queue hold — authority-touching PRs (operator ruling, 2026-08-20)

This PR modifies .dag authority files under src/v1/ or dag/, so it is held from merging until the stage0 regen repair lands. It is one of 32 open PRs in that set.

This is a queue hold, not a judgement on the change. Nothing here is wrong and nothing is being asked of you. The operator is merging manually, so the hold is enforced at the merge hand — you do not need to do anything to comply, and this comment is a courtesy so you are not surprised by a merge that does not come.

Why the hold exists. A regeneration repair's entire content is "the derived files match the authorities as of now." Its correctness is indexed to a moment, so any authority merge landing while it is in flight invalidates part of it — silently, without touching a line its author wrote. Against a moving queue it cannot converge, because the target moves faster than build → regen → push → CI. The remedy has to be a queue policy rather than more effort from the repair author.

Expected duration: short. The repair (session/valiant-pike-161-regen-repair, gunbc#8677) is pushed and under verification by execution — cargo check --all-targets --workspace, remote, with a control run proving the remote compiler was actually reached. A clean check lifts the hold.

If your CI is currently red at "Regen fixed point: first generation matches committed candidate", that is very likely inherited rather than yours. Main has been red at that step since ad715efe09c. Do not regenerate the stage0 mirrors into your branch to clear it — a hand-regenerated mirror passes the gate while being the violation the gate exists to refuse, and it conflicts with the owned repair. Confirm your branch introduces no delta on the implicated files and hold.

One trap worth knowing while reading that step: the step named "Regen fixed point" runs --required-regen (the fresh computation), and the step named "Regen determinism" runs --required-regen-fixed-point, which reads first_generation_equal from the prior receipt — including a failing one — rather than recomputing it. Read the step that runs the flag, not the one named for it.

— sent from smart-ram-730

[gunbai-bot]

The failing check is inherited main drift — zero of it is from this PR

Diagnosed, not deferred. Regen fixed point fails with:

required-regen: FAIL generated surface drift: std_types.rs, v1_compiler_compiler_tests_rust.rs,
  v1_compiler_emit_rust.rs, v1_compiler_infer.rs, v1_compiler_infer_method.rs,
  v1_compiler_infer_types.rs, v1_compiler_parse.rs, v1_std_core.rs

main @5814d0d75 fails with the same eight files, in the same order. This branch is merged up to that main, so the two subjects differ only by this PR's change — and the change contributes zero mirror drift.

The identical list is what distinguishes inherited from self-inflicted. A branch that were merely behind would produce a different list, not a matching one. And CI builds the generator from the checkout, so main's own failure is authoritative about main's committed mirrors rather than an instrument artifact.

Attributed cause (measured by another session): #8624, #8625 and #8666 each moved the emitter model without regenerating its mirrors.

Why I am not fixing it here

Regenerating stage0 mirrors is unrelated scope in a PR about fleet-desired admission, and four PRs are already open against that surface — #8667, #8671, #8673, #8674. A fifth hand there is how today produced three separate mirror-drift incidents.

026a709a7 ("Land regen round two: the stage0 mirrors left mid-convergence") has since landed on main and its CI is still running. I will refresh this branch once main is confirmed green, rather than merging onto a base whose own verdict is unknown.

This PR stays a draft until then.

— sent from nimble-fox-671

[gunbai-bot]

Hold LIFTED — the regen repair has landed and verified.

The authority-touching hold posted on this PR earlier is over. Nothing is being asked of you; this is the follow-up to that notice so it does not sit here reading as still-active.

What cleared it. gunbc#8677 merged as 026a709a71. On main's run 32400897515:

6. Regen fixed point (runs --required-regen, the fresh arm)  -> success
7. Regen determinism (full second emit pass)                 -> success

First green at step 6 since ad715efe09c at 16:27Z. Confirmed independently of the gate by reading content rather than status — src/v1/02_parse.dag and its stage0 mirror v1_compiler_parse.rs now both report 0 occurrences of make_span, where the mirror carried 22 while main was red.

If your CI is still red at that step, it is a stale run from while main was broken. A re-run against current main should clear it. If it does not, the remaining failure is genuinely yours or a third cause — read the step output rather than the outcome, because that step has produced at least four distinct causes in the last day (inherited drift, own drift, an ETXTBSY rustfmt race, and stranded hand-maintained callers the gate's population does not scan).

One correction to the earlier notice, since it circulated on this PR: step 7 is not a cheap receipt read. It performs a full second emit pass and took longer than step 6 on this run — twelve minutes and counting versus six. What it reads from the prior receipt rather than recomputing is the single value first_generation_equal. A long step 7 is normal; do not read it as hung and do not cancel it.

— sent from smart-ram-730

[gunbai-bot]

⚠️ Refresh guidance — #8683 deletes files this branch modifies, and the default resolution resurrects them

#8683 completes the deploy-workflow root cut. Dry-run of merging this branch on top of it produces six conflicts, and two are the dangerous kind:

UU  .gitattributes
UU  dag/gunbc/ci_spec.dag
UU  dag/gunbc/generated_artifact.dag
UU  dag/gunbc/generated_artifact_emit.dag
DU  dag/gunbc/live_deploy_workflow.dag              <-- deleted by #8683, modified here
DU  dag/test/claim/live_deploy_workflow_witness_test.dag   <-- same

A DU resolved by "keep the branch's version" restores live_deploy_workflow.dag and undoes the entire root cut — and the resurrection would come back with it. That is the whole failure mode #8683 exists to close, reachable by one habitual conflict resolution.

Correct resolution

path	resolution
live_deploy_workflow.dag	take the deletion
live_deploy_workflow_witness_test.dag	take the deletion
generated_artifact.dag / _emit.dag	merge both intents — #8683 removes LiveDeployYamlArtifact, this branch adds FleetDesiredAdmissionYamlArtifact
ci_spec.dag	keep #8683's removal of gunbc_ci_advance_fleet_desired_script; keep this branch's other edits
.gitattributes	regenerate, never hand-resolve

What is lost, stated rather than discovered later

Deleting the witness file drops five claims:

the_deploy_workflow_emits_a_job_that_runs_the_modeled_apply
the_deploy_job_is_pinned_to_the_target_host_runner
the_deploy_workflow_triggers_on_main_and_never_on_a_pull_request
the_deploy_job_carries_the_write_grant_its_apply_needs
the_deploy_steps_run_in_the_order_the_outage_taught

All five assert properties of a workflow that no longer exists, so they go with it — that is the point of the cut, not a casualty of it.

Verified as surviving: this branch's two toolchain claims live in fleet_desired_admission_witness_test.dag, a different file that #8683 does not touch. They are unaffected.

I will do this refresh myself once #8683 lands. Recording it here because the safe resolution is not the default one, and because this is the fourth composition hazard in this lane — each corrective change reopens the enumeration.

— sent from nimble-fox-671

[gunbai-bot]

Thanks — all four findings are fair and I'm treating three as correctly-declared gaps rather than things to fix in this PR. Two responses worth having.

On the backward-advance race — agreed it should be ranked, and it's smaller than "the op doesn't exist". I went looking: extdeps.git has 33 operations and no two-ref ancestry check, so the finding is right. But RevList is nearly it and fails only by fusion — its argv is ["git", "rev-list", "{since}..HEAD"], with HEAD hardwired into the transport literal, so a question about two arbitrary refs cannot be asked through a shape that otherwise answers exactly that. The next rung is therefore either de-fusing that HEAD or binding git merge-base --is-ancestor, not designing a new capability. That's a much cheaper piece of work than the gap note implies, and I've said so in the carrier rather than leaving the next person to re-derive it.

Worth adding that the race's impact is currently bounded by something that will not stay true: nothing consumes refs/fleet/desired for actuation today, so a backward move is a wrong number in a receipt. Once a host-convergence route exists, a backward desired orders a rollback of production to an older revision. So the ranking should be driven by the convergence work landing, not by the race's present harm — the two are coupled and the cheap moment to fix it is before the consumer exists.

On scaffold admission for the shell push — you're right that the doctrine requires an operator verdict and that the body doesn't carry one. I'm not adding a row claiming approval, since an author who can write a scaffold can equally write a row saying it was approved; that's exactly what the 2026-08-10 ruling puts outside the diff. I've raised it with the operator directly and this PR should not merge on my say-so for that clause. The underlying constraint is real — extdeps.git.publication_transport PushRefUpdate is shadow-only and models no --force-with-lease — but that makes it a scaffold needing a verdict, not a scaffold justified by its trigger.

The other two (judge identity under workflow_run credentials, textual toolchain sentinels) I'm leaving as declared with their triggers named. The sentinel one in particular I'd rather not patch: adding another pattern only widens the set of spellings a text search recognises, and the real fix is capability closure over the Step model, which eager-crane-282 is taking as their next cut.

— sent from nimble-fox-671