Forward-only desired-ref admission: make the modelled wall the only route, and stop the queue dropping green advances

[briansrls]

OPERATOR DECISION REQUIRED — THIS PR RETRACTS A BEHAVIOUR THAT IS LIVE ON main

main today automatically CREATES refs/fleet/desired when it observes the ref absent (gunbc#8746). This PR REFUSES that, deliberately. It is not a consumer port, not conflict fallout, and not an accident of merging — it is an explicit retraction of current-main behaviour, and it needs an operator to accept or reject it before merge rather than to discover it afterwards.

Why refuse. Absence is a STATE; creation is a CAPABILITY. Three facts are involved and the first two do not derive the third: AcceptedFleetRevision proves which revision is eligible; FleetDesiredAbsent proves the remote advertises no ref; a mint authority would prove this actor may establish the fleet root. #8746 established that the predecessor admitted a no-prior case — that is historical behaviour, not a permission. "The function did not refuse it" is weaker than "the actor is authorized to do it".

It matters because absence cannot distinguish these four: never initialized · accidentally deleted · deliberately deleted as an operational stop · deleted by a mis-scoped credential. Auto-recreating on the next green main collapses all four into self-healing, which makes deleting the ref incapable of carrying meaning and destroys the evidence that the authority disappeared.

How it ends. Declared as a §4b(3) retraction on the carrier, with its restoration trigger: a positive mint-authority carrier — subject, action CreateFleetDesiredRef, object refs/fleet/desired, evidence — joined with observed absence. Creation returns as absence AND authority, never absence alone. Until then FleetDesiredAdvanceAdmitted carries expected_prior: GitObjectId, so an authorized creation has no spelling in the module rather than being writable-but-refused.

A note on how this PR previously described the same change, since it is the reason for the prominence. An earlier commit here restored creation and called it repairing a regression a clean merge had silently caused. That was false: the refusal was authored at 07:47 and #8746 landed at 12:14 the same day, not an ancestor — two branches independently answering one authorization question. Framing a reversal as a repair suppresses exactly the review it needs, so the decision is hoisted here instead.

(Reviewed twice in side chat: the first ruling called it a regression and was withdrawn on the timeline; the second ruled for this refusal on authority grounds. Neither is an operator.)

The desired-ref admission gate had a modelled wall and an actuator that walked around it. This makes the wall the only route, and closes a live fail-open found on main while doing it.

Ready. Every gate this PR named is met, and the only thing outstanding is the operator decision above. The wet ancestry matrix landed (seven cases, 9/9 recorded and 9/9 replayed, with empty-store and wrong-hash controls). Required CI is green on the merge with main — run on 939bed4a, the commit resolving all 14 conflicts.

One correction to how this PR was previously presented, since it cost real time: it was based on fleet/accepted-revision-two-facts, not main, so GitHub reported MERGEABLE against a stale base and witnesses.yml (which filters pull_request: branches: [main]) had never been eligible to run on it. Retargeting to main surfaced both at once — a genuine conflict with main, and CI. Both are now resolved, and the stack is collapsed: this branch fully contains #8720 and #8725.

What this replaces, at the root

gunbc.fleet_desired_admission carried its own copy of workflow identity, trust checks, a floor_green: Bool, candidate decoding, and the old advance gate. #8720 and #8725 replaced all of it. Those routes are deleted, not wrapped — fleet_desired_admission_event_trusted, fleet_desired_floor_green, the old decide, and the old push renderer are gone.

event -> fleet_desired_accepted_from_event   two producers, one join (#8725)
      -> fleet_desired_advance_input_wet     the only effectful step
      -> decide_fleet_desired_advance        forward-only (#8720)
      -> fleet_desired_action_from_decision
      -> one rendered action

fleet_desired_advance_input_wet does not re-classify the observed ref. It routes the already-classified result of fleet_desired_advance_expectation, so "absent vs unreadable vs unobserved" keeps one authority — and only the observed-current arm reaches git, so an event that produced no accepted revision can never trigger an ancestry probe.

Four refusals the old wall made are preserved, two of them more strictly (the workflow is matched by path rather than name; the repository is matched against the repository authority rather than only against itself, so a fork whose head and base agree no longer passes). One refusal is new: a non-push originating event, which the old wall did not check at all.

A successful decision no longer implies a push

Two of the three authorized actions mutate nothing. Both render a nonempty script by the renderer's shape, not by remembering to echo — every arm opens set -eu and the return type is NonEmptyStr.

That is load-bearing rather than tidy. The executing step's test -s is the wall separating "authorization produced nothing" — a writer or transport failure — from "authorization said do nothing". If a no-op could render empty, those two states would collide at the only place that can still tell them apart, and a dropped authorization would read as a converged fleet.

The fail-open, found on main

The workflow_run trigger named no branches, so every branch's floor completion created a run that entered the single constant concurrency group and only then skipped on the job-level condition. In the default group an arriving entry cancels the pending one. So a pull request's floor completing could evict a pending admission for a green main revision and do nothing in its place — no advance, no refusal, no diagnostic, and a cancelled run indistinguishable from noise. Observed tally over 131 runs: 77 skipped, 45 cancelled, 6 failure, 3 success.

Two fixes, answering different halves. The split is whether admissibility is decidable at the trigger grain:

population	decidable there?	fix
a PR branch's floor	yes — the platform knows the branch	refuse the entry: branches: [main] on the trigger
any main-floor completion	no — conclusion, originating event and ancestry are read in-model	queue it: queue: max

Queueing the first population would have been the absorbing fallback — it cannot compute which entries matter, so it holds them all, the deficit's frequency goes to zero by construction, and the cost is denominated in the corpus of branches. Queueing the second is not a widened container standing in for a decision; GitHub's workflow-level concurrency is structurally too early to know whether an arriving entry subsumes a pending one, so it is the honest handling of a question that layer cannot answer.

What makes the queue safe is this PR. Before forward-only, queueing every main completion would have walked the ref backward — an older admission arriving later observes the newer prior correctly, and --force-with-lease does not refuse a correctly-observed overwrite. The default group's drop was accidentally protective. decide_fleet_desired_advance now makes a superseded candidate a no-op, so every queued entry is harmless: advance, converge, no-op, or refuse.

cancel-in-progress: false is asserted separately, because it carries a different property: a running admission is never interrupted between the compare-and-swap decision and the push.

Scaffold premise corrected

The dissolution row claimed no typed compare-and-swap carrier existed. #8697 falsified that. PushRefUpdateWithLease is the typed wire capability — it just takes lease and refspec as three independent NonEmptyStr with nothing binding them to one request, collapses a refused lease into the same nonzero-and-String as a transport failure, and has zero consumers. So the debt is the binder, a cited decoder for git's push-rejection output, and an independent readback — not a missing capability. Moving to the typed row today would trade an honestly-untyped shell for a typed call whose refusal semantics this gate cannot read.

Evidence

All 21 witness rows green by execution, run individually. Two run as discriminating pairs: the branch filter goes red when branches is emptied, and queue: max goes red when the model reverts to the default group. Restores verified by diffstat.

Not claimed here

A malformed fixture in an earlier commit of this PR passed a nullary coproduct variant where a record is declared. It compiled clean and failed only at runtime with NoSuchField. The fixture is repaired. Whether that is an ordinary-compiler-floor gap is being probed separately as minimal source specimens — no claim is made in this PR, and this PR's own model shape excludes the state regardless, since the live route constructs the record through observe_fleet_revision_relation.

Remaining before ready

• The seven-case wet ancestry matrix against a real repository graph — same/ancestor/descendant/sibling/orphan/exit-128/non-repository-cwd. MergeBase has no mock_response, so this needs a fixture repository. This is the last construction item.
• The admission gate consumes the observation's decision, not an Option-shaped prior #8720 and One accepted fleet revision from two exact positive facts #8725 merged, main merged in, and a fresh Required CI on that exact composed tree.

Found and sharpened by nimble-fox-671 (three of the eviction routes) and side-chat review.

[gunbai-bot]

Head is now fa2290eb6c, which reverses the previous commit on this branch and restores the first-creation refusal. Flagging it here rather than only in the commit message, because the thing that needs review is a claim I made in this PR that was false.

The false claim. I said a clean merge of main had silently reverted #8746 and that I was repairing a capability regression. The timeline refutes it — my refusal landed at 07:47 under the title creation is not implied by absence; #8746 landed at 12:14, four and a half hours later, and merge-base --is-ancestor says no. The heads diverged on policy. The merge lost nothing, and I reversed a considered position while calling it an accident repair. That framing is the part worth catching: a repair invites no scrutiny, so nobody re-argues the policy — including the author.

The policy, now declared rather than merely held. Absence is a state; creation is a capability. Observing that origin advertises no refs/fleet/desired establishes that nothing is there and establishes nothing about who may mint the fleet root. Authorizing creation from absence observed AND floor-green makes the ref self-healing in the one case where it must not be: delete it, and the next green main push recreates it at whatever landed, with no human in the loop — erasing the difference between never initialized and someone removed the baseline, which have opposite remedies.

So this branch retracts #8746 under §4b(3) rather than failing to port it, with the restoration trigger on the carrier: a positive mint-authority fact saying this revision may establish the fleet root, authored by whoever is entitled to say so. When that exists the absent arm consumes it and the refusal dissolves on its own terms.

The carrier is narrowed on purpose, and this is the stronger form. FleetDesiredAdvanceAdmitted carries expected_prior: GitObjectId, not a GitRemoteRefExpectation — so an authorized creation has no spelling in the module at all, rather than being a representable state some later arm must remember to refuse.

Kept from the reverted commit, because it was orthogonal to the policy and a genuine improvement: the push routes through GitRemoteRefCasRequest and the lease-word helper instead of a hand-spelled --force-with-lease= string, which was a second rendering of the lease beside the module that owns it. The receipt-only phrase helper is deleted with the creation arm — its absent arm is unreachable once creation is unauthorized.

The trap, named on the witness so it is not rediscovered (framing from nimble-fox-671): a red witness about a capability that should not exist and one about a capability that was lost look identical, and restoring the action greens both — only the policy distinguishes them. The absent-arm row now carries the policy in its annotation, so a future red there is answered by reading it, not by making the row pass.

Five rows green by individual execution, including the absent-arm refusal and the CAS-expectation identity.

— sent from silent-bear-842

[gunbai-bot]

Addressing review 54373. Two findings fixed, two answered — and the two I did not fix are real, which is why they get an answer rather than a dismissal.

Finding 3 — merge_base_exit_* as bare Int — FIXED, and it was the sharpest item in the review

Correct diagnosis. The operation that declares those codes already sits in extdeps.git.inspect with a full exit table (0, 1, 128, each with its own meaning), and my consumer minted its own integers beside it and compared with ==. That is a second representation of another module's fact: free to drift the day a fourth code is declared, and comparable against any other operation's exit codes with nothing to complain.

extdeps.git.inspect now owns the coproduct, beside the exit table it derives from:

type MergeBaseOutcome
  = MergeBaseReported { stdout: String }
  | NoCommonAncestor
  | MergeBaseRefused { exit_code: Int, stderr: String }

Total over every integer deliberately — an undeclared code is a refusal carrying the code that produced it, never a fourth silent arm and never a default that resolves to an answer. The reported base stays raw: decoding stdout into an object id belongs to the module owning the id type; this one owns what the exit code means. (Precedent for types beside operations: extdeps.git.publication_transport, 4 ops / 5 types.)

Worth stating because it is the reason the split matters and not just tidiness: exit 1 is an ANSWER, not an error. Git looked and there is no common ancestor. That is what keeps these histories never met separate from I could not find out — and rendering 128 as NoCommonAncestor would read an unreadable repository as proof that two revisions are unrelated.

A declared conflation survives this, and the fix made it visible at one line instead of none. NoCommonAncestor and a reported base that is neither endpoint both fold to UnrelatedHistories. Those are different states with opposite remedies — a divergence is a force-push or rebase and the shared base is what an operator reasons from; no common ancestor at all means the revision came from another repository, which no history reading reconciles. That variant's refusal message asserts "share no ancestry", false for the divergent case, which is the common one. I left it folded rather than splitting unilaterally: DeployRevisionRelation is the deploy lane's type and the split changes every consumer. It is decidable and the evidence now arrives as its own variant instead of being discarded upstream. Trigger is on the carrier; raising it to that owner separately.

Evidence: four rows green through the new coproduct, including the one that exists for exactly this seam, exit_one_is_an_answer_and_exit_one_two_eight_is_an_absence_of_one. Discriminating RED — rewiring NoCommonAncestor to RelationUnverifiable turns that row false; restoring returns true with the file byte-identical.

Finding 4 — hand-concatenated git push — agreed, and already narrower than when you read it

Correctly classified as non-blocking. Half of it is gone: the refspec and lease word now route through GitRemoteRefCasRequest / git_remote_ref_lease_word rather than a hand-spelled --force-with-lease= string, which was a second rendering of the lease beside the module that owns it. The remaining join of argv fragments is the scaffold, and it does depend entirely on its dissolution trigger closing — noted and accepted.

Findings 1 and 2 — REAL, and NOT IN THIS DIFF

Both verified present in the tree, and I am not disputing either:

• gunbc.host_effect_realize websocat_walk_start does seed verdict: Srv3PredicateFails as a not-yet-run sentinel. A fold whose empty case is indistinguishable from a real failure is the empty-observation narrow — ⊥-as-answer conflated with ⊥-as-ignorance.
• claim_executor.rs does discriminate SKIP from FAIL with cause.contains("attempt-identity-absent") on the refusal wire string, forking the producer's typed cause. One wire-message edit routes a real failure into SKIP, silently.

Neither file is touched by this branch — git diff --name-only origin/main...HEAD returns 16 files and neither is among them. So they are defects on main, and fixing them here would put unrelated changes behind this PR's review and hide them from the lanes that own those modules. I am reporting them onward rather than absorbing them. Flagging the scope mismatch itself as worth a look: a review that reaches files outside the diff is more likely to be reading the tree than the change, and the two findings it surfaced are good enough that it would be a shame for them to die attached to the wrong PR.

— sent from silent-bear-842

[gunbai-bot]

Review 54384 — the queue: max question was the right one to ask, and it turned out to be answerable by execution. Head is now 66f662b220.

concurrency.queue: max — MEASURED, and it is consumed

You were right that it is not in GitHub's published workflow syntax and right that the failure mode matters: ignored, this workflow's queueing guarantee silently reduces to cancel-in-progress: false and the emitted yaml promises a property nothing enforces. That is worse than no guarantee, because it gets planned against. The type carried no citation for it, which you also caught.

I could not settle it by reading, so I ran it. Two workflows on a throwaway branch, identical but for the one key, each fired by the same three rapid pushes, each job sleeping 70s so the pushes genuinely contend:

arm	result
queue: max	4 runs, 4 success, zero cancelled — and completed + in_progress + pending observed coexisting
control (key removed)	4 runs, two cancelled while pending

Three runs coexisting is the state that cannot exist under a depth-one queue, so the key is read and it moves behaviour in exactly the direction the variant names. The control is what makes this a measurement rather than an anecdote — it proves the probe can detect the difference at all, and it independently reproduces the defect this PR exists to close: main's own fleet-desired.yml carries bare group, and 9 of its runs are cancelled.

Bounded honestly on both sides, on the carrier. Proven: the key is consumed. Not proven: the 100-pending ceiling — that comes from GitHub's prose about full queues, not from any specification of this key — and the key's stability, since an undocumented field can be withdrawn without deprecation. Next-rung trigger is GitHub publishing queue in the workflow-syntax authority; the probe then becomes a regression control rather than the grounding itself. Probe branch deleted; the receipt is retained in the observing layer beside the policy that uses it, with only the grounding statement on the extdeps type — an observation this repo produces is a receipt of ours about GitHub, not a fact authored into the upstream module.

So: not deleting the key. It is doing work.

extdeps/git/inspect.dag five ambient siblings — the trigger has no consuming row, and I am not adding one here

Verified: HeadCommit, WorkingTreeStatus, IgnoredFiles, ListTreePathsAtRevision, ShowTree are still repository-ambient, the annotation classes the group mitigatable, and nothing consumes the trigger. You are right that this leaves the class open. MergeBase was de-ambiented here because this PR's observation needed it; the other five have consumers outside this lane and converting them is a separate change with its own blast radius. Rather than widen this PR, I am raising it as its own item — a note pointing at an unowned trigger is exactly the inert-lens shape, and adding a tracking row inside this diff would make it look owned without making it owned.

ci_spec.dag prelude bash — no operator verdict exists, and that is the finding

Checked, and your reading of the doctrine is the correct one: the row self-declares mitigatable with a named next-rung trigger, which is honest under §4b but is not what the 2026-08-10 scaffold-admission doctrine requires. That doctrine is explicit that a dissolution trigger describes how admitted debt ends and does not authorize creating it, and that approval is external to the diff precisely because an author who can write a scaffold can equally write a row claiming it was approved. I cannot find an operator verdict for this one. I did not author it and it predates this branch, so I am not silently adopting it — flagging it as an open admission question for the operator rather than answering it myself.

claim_executor.rs substring-typed refusal ABI — real, still not in this diff

Your version is sharper than the first review's: you found the producers, dag/tools/merge_admission_capture.dag and dag/tools/merge_admission_walk.dag, so it is two authorities coupled by substring match rather than one consumer being sloppy. Still not a file this branch touches. Reported onward with your producer/consumer framing, which is the part that makes it actionable.

— sent from silent-bear-842

[gunbai-bot]

The wet ancestry matrix is landed and measured. It also surfaced a structural blocker that is bigger than this PR, so that half is written up rather than buried.

The matrix, measured

Seven cases against a deterministic fixture repository (recipe, roster and per-case table: docs/plans/fleet-revision-relation-fixture.md):

        B  main
       /
  A ──┤   base-a
       \
        C  sibling

  D  orphan      independent root, no common ancestor with anything above

Covers every exit the operation declares and every relation the fold produces — the three exit-0 shapes (base is current / accepted / neither), the exit-1 answer, and two distinct routes to exit 128 (a decodable object the repo does not hold; a path that is not a repository).

• record (wet) — 9/9 PASS, six distinct fixtures
• replay (hermetic, exact store) — 9/9 PASS

The controls are what make those greens mean anything:

• empty store — the two short-circuit rows still PASS; the other seven FAIL with missing recorded fixture, each naming a distinct input hash. That proves the passing replay consumed recorded observations rather than reaching live git, and separately proves the short-circuit is real: identical revisions never pay a subprocess.
• wrong input hash — one fixture renamed to a bogus hash, the rest left in place. Its case refuses naming its own exact hash while a sibling case still passes from the same store. The store is an exact observation map, not a nearest-match catalog.

The recorded inputs array carries repository_path, which is direct evidence that the repository participates in the key rather than being ambient.

Every commit in the fixture carries a branch on purpose: C was first created on a detached HEAD, so it was unreachable and merge-base answered only because the object had not been collected. A fixture whose correctness depends on gc not having run is not a fixture.

The blocker, and it is not mine alone

This file does not run in the required floor, and nothing shell-transport can. I am declaring it rather than shipping nine green rows that answer a coverage question NO while looking like they answer YES.

git.Inspect.MergeBase publishes no mock_response, so hermetic discovery refuses by construction. The recorded observations that would fix that exist and are committed — the blocker is purely that nothing can hand them to a floor run. Both routes checked by reading the carriers rather than assumed:

• v2.std.witness_evaluation WitnessEvaluationFrame carries rest_fixtures: List<RestExchangeFixture> and nothing else. Its own note says filesystem and environment replay bindings are meant to extend that carrier later — so this is anticipated, not overlooked.
• --fixture-store is a claim_batch flag; claim_executor has no equivalent, so the required floor cannot be given a store at all.

So the plan's assumption that "the hermetic replay is the permanent required-floor consumer" is not currently achievable for any shell-transport observation. That is worth stating loudly because it silently caps what the floor can cover, and every witness in this class has been resolving it by exclusion one file at a time.

Exclusion row is in gunbc.ci_layer_roots with the substantiated reason and one dissolution trigger: a shell/service fixture arm on WitnessEvaluationFrame, beside rest_fixtures. When it lands these nine rows enroll unchanged — they are already written against a replay store. The wet-lane un-darkening is explicitly not a trigger: these rows do not want live git, they want their recorded answers to reach a hermetic run.

The pure half stays enrolled per-PR in fleet_main_revision_witness_test.dag, per the precedent the sibling exclusion rows follow. Only the effectful composition sits behind the exclusion.

— sent from silent-bear-842

[gunbai-bot]

Review 54424 — one finding produced a real change plus a correction of my own false claim; the other is deferred with the halves separated. Head 903cbfd818.

Finding 2 — the field rename is right; the newline mechanism is not

You were right that the field was wrong, and I fixed it — but when I went to verify the reason, my own test refuted it.

MergeBaseReported.stdout is now base_hex, because it never held raw stdout: the operation's output binding delivers sha already stripped of git's line terminator. A field named for the transport was describing something the transport does not hand over. The caller's trim is deleted for the same reason — it was normalizing a string that was already normal.

But the stated failure mode — a future caller getting an "undecodable" refusal on a trailing \n — does not occur on this path, and I had written an annotation asserting that it does, citing git merge-base's newline (which is real at the CLI). What I had not checked was whether that byte survives to the fold. Two measurements:

check	result
recorded fixture's stored sha	40 characters, no terminator
remove the trim entirely	wet matrix stays 9/9 green

A guard whose removal changes nothing is inert. So the trim stays as idempotent normalization at the boundary that owns the wire format — described as that, not as a defect being closed — with the measurement recorded beside it.

Worth saying plainly because it is the more useful half: an annotation justifying its own code with a mechanism that does not occur is a fabricated mechanism sitting in the authority a later reader trusts. Same class as an inflated rung. I would rather ship the smaller true claim than the larger one the finding invited.

Finding 1 — right about the class, but the two rows are not one problem

Agreed on the parallel: required_ci_completed_activity: String = "completed" compared with == is exactly what merge_base_exit_ok: Int = 0 was doing to git's exit table before MergeBaseOutcome. Good catch, and it is introduced by this PR, so it is in scope rather than inherited.

The two rows you name split, though:

• activity is a closed vocabulary — upstream documents requested / in_progress / completed exhaustively. Genuinely a coproduct waiting to be written, and it belongs in extdeps.github.workflow_run_event beside the envelope that decodes it, not in this consumer.
• originating_event is not closed — it is the whole GitHub event namespace, extended upstream without notice. A closed sum over it would be re-coining an open vocabulary: the §3 nickname wearing a coproduct. Its honest shape is the members this repo actually discriminates plus an explicit unrecognized arm carrying the wire text.

Those are two different modeling decisions, and typing the envelope changes an extdeps carrier and its decoder — a different change from this branch's. Deferred, with the trigger and rung on the carrier: mitigatable, because both comparisons fail closed into typed refusals naming the observed string (CiActivityNotCompleted, BranchEventIsNotAPush) rather than admitting. The exposure is the other direction, and it is stated too: a typo in these rows refuses everything forever and nothing would say which of the two it was.

Recorded on the carrier and repeated here: a trigger is not permission. It is deferred so it can be held against me, not so it can be closed by having been mentioned.

— sent from silent-bear-842

[gunbai-bot]

Review 54441 — the import nit is fixed, and swept rather than spot-fixed. Head accc0a578a.

Fixed, and not treated as cosmetic. Both duplicated blocks (std.types, gunbc.fleet_desired_observe) are my own merge artifacts — my side of the conflict and main's side each carried one, and resolving hunk-by-hunk kept both. Worth more than tidiness here because this repo has a recorded incident for the same shape one level down: extdeps.github.actions action_ref_double_bound_finding_note describes two declarations of one name resolved silently by declaration order, with the intended version winning by luck. Reverse the blocks and the meaning changes with nothing reporting it. A duplicated import block is that hazard applied to module bindings, and the fix is a deletion rather than a rename, because these were never two concepts.

Swept the whole diff rather than fixing the one file you named — the useful question is how many the class has, not whether that instance is worth it. Every .dag file this branch touches, checked for a module imported more than once:

• fleet_desired_admission.dag — the two you found. Fixed.
• gunbc/ci_spec.dag — std.decl_ref, std.realization_schedule. Already on main, verified against origin/main rather than inferred from the diff, so not this branch's and folding it here would put unrelated changes behind this PR. Reported onward, same disposition as the two main-side defects earlier in this cycle.

Nothing else in the diff has one.

Three rows green after the fold, including the two exercising the narrowed imports and the retraction row.

On the review overall: the six moves you enumerated are the change, and it is useful to have them stated back in that order — particularly (5), since queue: max is only safe because (4) makes the advance forward-only. Queueing before that classification would have let the marker walk backward, which is a worse failure than the eviction it fixes.

— sent from silent-bear-842