Re-emit the deploy actuation: nothing has deployed srv1 or advanced the fleet ref since the floor cut

[gunbai-bot]

The 2026-08-15 floor cut deleted ci.yml, and with it the only thing that ever actuated a deployment or advanced the fleet's admitted revision. Both stayed modeled and neither ran — gunbc.ci_spec gunbc_ci_deploy_srv1_stage described a deploy nothing performed, and gunbc_ci_advance_fleet_desired_script described a ref advance nothing performed. That is specification-without-execution, which DESIGN §5 calls the deepest trap here.

Measured cost (2026-08-19/20)

symptom	cause
srv1 served a revision from weeks earlier	no merge ever reached it
every belt tick refused wholesale	refs/fleet/desired pinned at a sha from the deleted green slot
every spawn refused at its first gate	pinned Codex bundle absent from /opt/gunbc/provider-runtime/codex

Three symptoms, one cause: the host had no scheduled convergence at all. All three were repaired by hand — exactly the manual-application debt §6 counts against us.

Re-derived, not restored

Per the floor cut's own re-add rule. The deleted job was one stage inside a composed ci.yml that also carried gates, batching and a scheduler. This authors only the actuation that had no other home: one job, five steps, against the host it targets. The gates are not reinstated and remain their own re-adds.

Order is load-bearing

provider runtime  →  deploy  →  advance refs/fleet/desired

Provider runtime first, because a deployment whose provider binary is missing serves a dashboard that cannot dispatch — srv1's exact state. The ref advance last, because that ref is the belt's admission gate: advancing it before the deploy converges would announce a revision as desired while the host serving it is still mid-apply. A failed deploy leaves the ref where it was, and the belt keeps refusing against the last revision that actually landed.

Two further properties are deliberate and witnessed rather than incidental:

• No pull_request trigger. A deploy is a host mutation; a proposed change is not an admitted one. The claim asserts the absence, because that's the dangerous direction to add by accident.
• Concurrency queues, never cancels. Cancelling a half-applied deploy leaves the host between two revisions.

Two defects caught before merge — both mine

• The compiler refused the first regen with a non-exhaustive match. Adding the artifact variant censused every match over GeneratedArtifact and found a second site (artifact_extra_valid) I'd missed. Addition is censused the same way deletion is.
• The first emission carried contents: read while the last step pushes a ref. That would have 403'd after the deploy converged — leaving the host serving a revision the fleet does not admit, precisely the state being repaired. Now contents: write, witnessed against the emitted permission rather than the model field.

Neither would have been visible in a hand-written YAML.

Evidence

6/6 witnesses green by execution, complete run (footer present). Two regen passes, then a third after the permission fix. .gitattributes picked up the merge-driver row for the new path on its own — the registry wiring proving itself.

The order claim is asserted by splitting the emitted text at the apply step and interrogating the prefix, not by three independent containment checks: presence cannot see order, and order is the claim.

Not claimed

This does not close the remaining belt work. Nodes still need execution contracts, provider standing still needs recorded observations for production selection, and GITHUB_TOKEN is still absent from the belt unit. What this closes is the recurrence root — after it, a merge reaches srv1, the ref advances behind it, and the provider runtime is re-materialized every time.

🤖 Generated with Claude Code

[gunbai-bot]

Both findings in review 53944 verified and addressed in 5fd141a — and the first one led somewhere worse than the review stated.

On the medium-as-string finding: correct, and the repair is neither remedy suggested.

Checking it surfaced a defect the review did not name, and it is the deeper one: gunbc.ci_spec already owns this script. gunbc_ci_advance_fleet_desired_script exists and does exactly this, so my module was a byte-for-byte re-derivation — the §3 fork. Drift there means two different opinions about how the fleet's admitted revision advances, which is the one fact every host reads before deciding whether to act.

That reframes the fix. The existing function is already admitted debt: gunbc_ci_advance_fleet_desired_shell_emit_scaffold declares it a Scaffold dissolving to SingleAuthority, and its trigger names this exact concat-built foreign-executor CAS advance. So:

• marking my copy as a scaffold would be an author admitting their own debt, which §6 explicitly forbids — this is the same objection your second finding raises, and it applies to that remedy too
• hand-rolling a bash AST would put a second rendering beside the one that trigger already tracks, re-forking at the mechanism layer instead of the text layer

Consuming the authority removes the fork, introduces no new hand-shell so it needs no new operator verdict, and lets one existing trigger carry the conversion for both consumers when the SCM ref-update realization lands.

Visible consequence, and the right direction: the shared script prefixes itself with its own dissolution description, so deploy.yml now carries the debt marker inline. The generated artifact declares the scaffold it came from rather than laundering it into anonymous YAML.

On the operator-approval gate: agreed, and it dissolves. I am no longer introducing hand-shell, so there is nothing new for an operator to admit. You were right that the module header is not a substitute for an external verdict — that is exactly why I did not write myself one.

The witness was forked too, and I would have missed it without this. It asserted against my re-derivation, so it would have stayed green while the two spellings drifted — a claim over a fork proves the fork self-consistent and nothing about the authority. It now reads gunbc.ci_spec directly, plus a new claim joining the emitted bytes to the authority's own dissolution marker, which only that module can produce. A future local copy would have to re-declare debt it does not own to satisfy it.

That join went red on its first construction, correctly: a run: block emits as a YAML block scalar, so every line is indented and the raw script is not a substring of the document. Joining on the single marker line survives the serializer's indentation. Recorded in the claim rather than quietly corrected.

Separately, the floor caught five annotations sitting inside the Job body (run 32324870744) — §4c is module-item grain only. Moved; emission byte-identical, 7/7 green.

— sent from nimble-fox-671

[gunbai-bot]

Moving this to draft. The operator challenged it with "we already have fleet converge — why are you adding this new deploy route?", and checking it properly, they are right and I was wrong in a way the approvals did not catch.

One of the three steps is a straight duplication of existing converge membership. converge_provider_runtime_codex_receipt / ProvisionCodexRuntime already exists in gunbc.fleet_converge_cli, and the commit that introduced it (1561d624b) is titled "Codex runtime bundle as a converged fleet member". My "Materialize the pinned provider runtime" step re-derives it. That is the §3 fork, and it is the exact violation I raised against my own earlier PR in review 53944.

What is NOT duplicated, stated precisely so the boundary is not overstated: fleet converge does not deploy the dashboard today. Its only import from gunbc.live_deploy.spec is the two fleet-converge unit NAMES, used for timer retirement — it never reads deployment_owned_steps, the systemd unit, the serve binary, the tree, or the tailscale mapping. On srv1 its receipt read applied=0 drifted=0 verdict=absent while the host sat weeks stale. So the deployment genuinely had no actuator; that part of the diagnosis stands.

But the right repair is one spine, not a second route. Deleting blue/green removed the obstacle: a deployment is now one in-place converge of one spec, which is exactly membership-reconciliation shaped. Slot selection and route flipping were what converges membership model could not express, and they are gone.

So the plan I would rather land:

1. dashboard deployment becomes converge membership, rather than a parallel workflow
2. the provider runtime step disappears entirely — converge already owns it
3. the refs/fleet/desired advance keeps gunbc.ci_spec as its authority and finds a trigger that is not a second deploy route

What I am not willing to leave standing either way is the status quo this PR was reacting to: a deploy stage modeled since the floor cut with nothing invoking it, and me advancing the admitted fleet revision by hand — twice tonight, the second time because the deploy I had just run left the ref stale.

Draft until the operator picks the shape. The witnesses and the emission machinery here are reusable for the converge-member version.

— sent from nimble-fox-671

[gunbai-bot]

Correction to my previous comment, which over-called the finding. It claimed the provider-runtime step duplicates converge membership and is a §3 fork. Having traced it, that is wrong, and I would rather retract it than let a false defect claim stand on a merged PR.

Both routes emit the same ProvisionCodexRuntime {} HostEffect through the same realizer, gunbc.host_effect_realize realize_provision_codex_runtime. gunbc.host_codex_runtime_provision provision_codex_runtime_effect constructs that effect; gunbc.fleet_converge_cli converge_provider_runtime_codex_receipt constructs the same one. Two callers of one authority is what §2 means by one concept and many uses — a fork would be re-deriving the provisioning logic, and nothing here re-derives anything.

What is actually true, narrower and still worth acting on: there are two triggers for the same host state, not two models of it. The operators question — should deployment ride one convergence spine — is a real question about trigger topology, and it is not answered by anything in this diff.

The facts that bear on it, so the decision rests on measurements rather than on my framing:

• fleet converge does not deploy the dashboard today. Its only import from gunbc.live_deploy.spec is the two fleet-converge unit names, used for timer retirement; it never reads deployment_owned_steps, the systemd unit, the serve binary, the tree, or the tailscale mapping.
• converge is deliberately human-gated — plan, operator reviews typed hunks, apply — workflow_dispatch only, with a plan hash and lease generation, by operator directive (sleek-heron-218). A deploy-on-merge cannot route through a flow that requires plan review first.
• converges own fleet-converge host timers were deliberately retired, and the converge plan actively removes them. So converge is invoked from CI, not from a cadence on the host.
• on srv1 converges receipt read applied=0 drifted=0 verdict=absent while the host sat weeks stale.

So the deployment genuinely had no actuator, which is what this PR supplies. Whether it should instead become converge membership — now expressible, since deleting blue/green removed the slot-selection and route-flip semantics converge could not model — remains open and is the operators call, not something I should decide by leaving a second route in place or by ripping one out unilaterally.

Sorry for the noise on a merged PR. The prior comments conclusion was wrong; its underlying question was not.

— sent from nimble-fox-671