Runner width is derived-or-unresolved-with-cause; unknown stops reading as zero

[gunbai-bot]

What this is

gunbc.runner_slot_allocation gunbc_runner_slots_per_host is deleted. The canonical committed-width answer is gunbc_runner_committed_width -> RunnerWidthResolution (RunnerWidthDerived { slots } | RunnerWidthUnresolved { cause }), and every production call site carries or refuses the cause instead of reading an Int.

That Int's own note declared this gap on 2026-09-19 and named this type as its capability trigger, adding that landing half of it would mint one silent default per un-migrated site. So it lands in one motion: 22 production call sites across 13 modules, plus the carriers downstream of them.

Why now — the conflation stopped being latent

Chain, re-derived from the root rather than from the symptom:

host_runner_memory_envelope_bytes → 0 for srv2 (session reservation unestablished) → host_memory_admitted_width 0 → width 0 → srv2 contributes no members to fleet_committed_slot_identities → decode_registration_slot answers RegistrationNamesNoCommittedSlot for every srv2 registration → accumulate_decoded_registration → GitHubSlotPopulationForeignRegistration → plan_runner_capacity_host refuses with "resolves to no committed fleet slot".

That fold runs over the whole org roster for every host it plans, and it is not filtered by host. The live roster read landed in #11711, and the 2026-09-19 org read (runs 35450620333, 35458738938) shows srv2-02 (251463) and srv2-05 (251484) present. So every host's plan — srv1, srv3, srv4 included — refused, citing a sentence that is true about the derivation and false about the fleet: a registration on a host whose width does not resolve is not established as surplus.

What changed, by carrier

Each of these could previously say only "empty", which reads as a positive claim:

carrier	new arm
committed_slot_identities	CommittedSlotPopulation = Derived | CommittedPopulationWidthUnresolved
RunnerSlotMembership	SlotMembershipWidthUnresolved
RegistrationSlotDecoding	RegistrationHostWidthUnresolved { registration_name, host, cause }
ObservedGitHubSlotPopulation	GitHubSlotPopulationHostWidthUnresolved
FabricCellDiscoveredSubject	DiscoveredHostWidthUnresolved
RunnerSlotEnumerationPostcondition	RunnerSlotEnumerationWidthUnresolved
host_converge_slice1 cross-check	HostConvergeSlice1EnumerationCrossCheck (3 states, was an Option)
gunbc_committed_host_runner_slot_allocation	HostRunnerSlotAllocationStanding — srv2 has no allocation row at all
fleet_committed_slot_identities	carries unresolved_hosts beside its members
fleet_committed_slot_total (panel)	carries unresolved_hosts; renders "(incomplete: srv2 unresolved)"
HostRunnerDeploymentRefusal (placement)	CommittedWidthUnresolved { cause }
runner_slot_lifecycle_for	RunnerSlotLifecycle? — the caller already had OwnerContextUndecided

The most dangerous one was the census: with an empty desired set every running unit classifies as RetiringSlot, so a host whose width did not resolve would have been converged to zero runners by a fold that never saw anything wrong. It now REFUSES.

The two constraints from the side chat, and where they are met

1. A typed unresolved width does not settle srv2's live registrations. It does not, and nothing here pretends it does. Planning still refuses; what changed is the reason. It names the host, quotes the reservation policy's own cause, and says explicitly that the registration "can be neither accounted for as a committed slot nor called surplus… retiring it would be acting on a derivation that did not run." No arm returns PlanReady for that roster.
2. No filtering of srv2 out of the organization observation. The roster is untouched. The fleet population keeps every member it could derive and names the hosts it could not, the same direction RosterObservedPartial takes for a page that fails. A missing allocation answer becomes neither an empty population nor an instruction to delete.

Two nicknames dissolve with it (DESIGN §3)

gunbc.fleet_host_budget gunbc_runner_pool_budget_for was gunbc_runner_slice_cap_declared(host: host) and nothing else — one concept, two names, and it was the name the conservation wall read, so the wall and the deploy row reached the width by two routes kept agreeing by hand. Both are replaced by gunbc_runner_slice_cap_for_width(slots), which takes the width its caller already resolved. fleet_desired_width_total is deleted: it had no consumer (§3c).

One climb: the allocation wall's a.slots_per_host > 0 || !host_memory_width_is_established(host: a.host) disjunct is gone. It was validation re-stating, per row, the condition under which the row should not exist; the refused host now has no row, so the conjunct is just > 0 and the discriminating red is unchanged.

Witnesses re-derived, and three were already stale

the_whole_org_corpus_is_refused_while_srv2_holds_unaccounted_registrations (#11708, in the required gate) is re-derived rather than weakened: it still requires a refusal naming srv2-01, and now also requires the refusal to name the host and cause and not to say "resolves to no committed fleet slot". Red in both directions.

Three rows were asserting literals the fleet had left behind, each re-stated as the relation it was for:

• witness_srv3_srv4_committed_width_agrees_with_the_derivation pinned 21 on all four conjuncts; the 26/25 GiB row commits 17.
• srv4_commits_memory_width_disk_gated_at_apply pinned memory admission 29 and committed 21; both are 17.
• srv1_is_axis_bound_while_srv2_is_held pinned "bound by cores"; the 2026-09-19 one-core-per-slot ruling put srv1 back on memory.

The held-width row is deleted with its subject (host_held_runner_width had one arm returning none, so its red was unauthorable — DESIGN §4b) and replaced by one asserting srv2's width comes back UNRESOLVED naming its denominator. runner_slot_allocation_unknown_host_refuses_a_width asserted == 0 and called that a refusal — the conflation written down as the expected answer; an unknown host now yields a cause.

Evidence, and its boundary

• claim_executor --required-regen --source-root dag --source-root src/v2, run locally on this tree after merging main: compile.frontend / normalize / reconcile / analyses green, zero diagnostics. Declarations, names and types resolve across all 35 changed files.
• An earlier run reported 11 diagnostics; those were my branch's stale base, not this change — origin/main passes clean and the 11 sites are in std/extdeps files this change never touches, fixed by the .first()-Optional work that landed in the meantime. Merged main; they are gone.
• Witness closures are checked with gunbc compile --source-root dag --source-root src/v2 --entry <witness> --target dag, which is the only instrument that reads dag/test/claim at all. --required-regen does not compile it — measured with a deliberately undefined function planted in a witness, which it passed. The compile-per-closure caught two type errors a reviewer also found, five body-position annotations and two non-exhaustive matches.
• Witnesses DO execute in CI, and these pass — which corrects my own earlier statement here twice over. When I first measured this (head 0dd2892), .github/workflows/witnesses.yml had three jobs — compiler (a cargo build), clippy, and a 3-second job named witnesses that was an aggregator over those two and ran no witness — so I wrote that no assertion in this diff had been executed anywhere. gunbc#11791 landed a floor job on main at 05:18 that runs claim_executor --required-ci --source-root dag --source-root src/v2 --required-lane witnesses, and because CI evaluates the merge ref this PR gets it even though my branch's own copy of the workflow predates it. On head 710cedc that job passes, its Nominal witnesses (one prepared subject, one fold) step succeeds, and its judged-module-identities roster includes six modules this change rewrites: gunbc.runner_slot_allocation, gunbc.ci_runner_placement, gunbc.fleet_capacity_panel, gunbc.fleet_host_budget, gunbc.fleet_runner_connectivity, gunbc.runner_lifecycle. So the claim in this bullet's earlier version — first that CI executed the witnesses, then that nothing did — is replaced by the measurement: it did not, then the gate landed, and now it does and is green.

Finding reported separately to deep-owl-720: the mislabel is a semantic loss, not a string, and the fix belonged at the width authority rather than at runner_capacity_plan's refusal text (DESIGN §6b: the symptom link is not the earliest unjustified boundary).

🤖 Generated with Claude Code

[gunbai-bot]

All four source-hold items and both dashboard reviews are addressed in 959eac2 (plus 19ac99a/e37fbfb merges). Verified against the code, not acknowledged.

RW-1 — the unresolved obligation now survives the projection, in both of its instances

transition_required_retirees no longer answers []. RequiredRetirees = RetireesKnown { units } | RetireesUnresolved { host, cause } (gunbc.runner_width_transition), and the three consumers each withhold rather than reading it as nothing to do: runner_slot_retirement yields SlotRetirementEvidenceAbsent for both the standings read and the interruption-coverage admission (coverage over an underivable set was arriving as TransitionFullyPermitted — the strongest answer, reached because nothing could be asked); runner_slot_provision emits a withheld line and contributes no actuation; host_effect_realize returns CapConvergeWithheld. transition_baseline_rows emits a required-unresolved: row so a plan built under an underivable obligation does not fingerprint identically to one built after convergence. transition_population_agreement gains TransitionPopulationUndecidable.

The cap instance is repaired at its own decision boundary, as asked: runner_slot_service_units_for_host returns RunnerSlotServiceUnits, and cap_converge_decision refuses a target set it cannot derive instead of constructing CapConvergeAuthorized around an empty one. You were right not to lean on the downstream script guard — deploy_memory_cap_apply_script_for_host now emits a refusal line too rather than an empty script.

The discriminator you asked for is enrolled in the direction that is authorable, and the other half is stated rather than implied. srv4's derived target yields its real prior-minus-target obligation (an_open_transition_derives_the_prior_minus_target_obligation); srv2 with no transition row yields a derived empty obligation, asserted as RetireesKnown [] rather than as a length. The unresolved arm has no executed red: the three transition rows name srv1/srv3/srv4, all of whose widths resolve, srv2 has no transition row, and RunnerWidthTransition is a sole-constructor type so a witness cannot author the combination. Authoring a transition row for srv2 would be a fleet policy change smuggled in as test data. That is recorded in the witness with its next trigger, per DESIGN §4b, instead of being papered over.

RW-2 — the cross-host mislabel is gone

fabric_cell_fleet_committed_members is deleted. fabric_cell_observe reads fleet_runner_connectivity's FleetCommittedSlotPopulation standing rather than maintaining a second fold that strips its unresolved half, and fabric_cell_classify_uncommitted_here initializes to DiscoveredHostWidthUnresolved when the name is one an unresolved host could own — by the same host-prefix necessary condition the registration decoder uses, read fail-closed in one direction only. Your counterexample (srv2-02 observed on srv4, CellRootRendering) now takes that arm; srv3-99 stays DiscoveredForeignArtifact; a positive cross-host match from a derived population still wins, because the fold overwrites the initial value. The refusal names both hosts, since they are usually different.

RW-3 — all three

consumer	now
runner_capacity_realize reapply	answers false on an unresolved population. Inability to plan is not evidence of successful reapplication.
build_cache_endpoint_observe	RunnerSlotLifecycleResolution carries the width cause into OwnerContextUndecided instead of discarding it and re-describing it generically.
fleet_capacity_withdrawn_line	reports the withdrawn amount as unestablished when either total carries an unresolved host, instead of vanishing because an unresolved host contributes zero to both sides.

RW-4 — the three false-positive paths

• Nonemptiness at the concrete grain. The launch-environment control now requires the concrete slot population to be derived and nonempty before the template is added. You were right: [template] + concrete stayed nonempty with every concrete slot gone.
• The −1 adapters are deleted, not relocated. A row that needs a live derived width matches the resolution and fails on unresolved (live_derived_width_or_fail, derived_width_or_fail, runner_count_is_the_derived_width). The two srv2 rows in fleet_show_effective_read are re-derived rather than adapted: srv2 declares no width, so they assert that, and each keeps its comparison coverage by supplying the expectation at the interface the row is really about. One width_contribution_to_the_total helper remains and is renamed to say why: there zero is the production rule being asserted, and the row's unresolved-set conjunct is what keeps it from being an agreement between two zeros.
• Cause preservation. The Admit the runner capacity planner witnesses to the required gate; supply the managed-pair roster at the interface #11708 tripwire and the root srv2 witness now both require the reservation policy's own sentence — "the managed-slice peak cannot be read as a whole-host aggregate" — to survive into the rendered refusal. A renderer that kept "is UNRESOLVED, not zero" and dropped the suffix reds both.

One order correction you did not ask for, reported because it changes a refusal

Resolving the width at the top of host_deployment_standing refused srv2 with the derived cause and left SessionReservationUnestablished with no production producer — a specific refusal replaced by a general one. The width now resolves after the session slice and before host_allocation_verdict, which is where RW-1 needs it.

Reviews 68767 and 68802

Both correct, both fixed: observed_prefix folding CommittedSlotPopulation as a list and host_fabric_slot_count compared to an Int literal (68767); the runner_host_deploy annotation still saying the width authority "answers zero slots for an unknown host" (68802) — the exact conflation this change deletes, left as prose in the module that turns a width into a provisioning target.

Ledger

gunbc.recurring_failure_mode.state_space_conflation gains RUNNER-WIDTH-1. The recognition rule it adds: when an underivable quantity is projected to its type's neutral element — zero for a count, empty for a population — the count of readers is the count of wrong answers, and none of them will report one. With the corollary this lane earned twice: a refusal correct at ONE consumer does not make a sentinel a refusal — admit_or_refuse_zero_width was cited for a year as evidence the zero was safe.

Evidence, and a measured instrument boundary worth passing on

claim_executor --required-regen does not compile dag/test/claim. Measured: a deliberately undefined function planted in a witness passed it. Witness closures are checked with gunbc compile --source-root dag --source-root src/v2 --entry <witness> --target dag, which is what caught both review findings, five body-position annotations and two non-exhaustive matches. Remaining blocking errors in those closures are pre-existing on origin/main — the same six Optional<T> diagnostics in fleet_show_effective_read appear identically on a clean main checkout.

One unplanned receipt: CI's auto-heal regenerated provisioning/srv2/gunbc-ghrunner.sudoers on this branch, and its # WIDTH REFUSED: header now carries the reservation policy's sentence end to end. That is the route executing into a generated artifact, not a claim about it.

— sent from snappy-crab-140

[gunbai-bot]

Correction to my own evidence claim in this PR

My PR body and my reply above both said witness execution is CI's. That is false, and I measured it rather than assuming it.

.github/workflows/witnesses.yml is now generated by gunbc.compiler_gate_workflow compiler_gate_workflow and contains no claim_executor invocation on any trigger (pull_request, merge_group, workflow_dispatch). Its three jobs on this PR's head 0dd2892:

job	what it actually ran
compiler (5m19s)	cargo build --release -p v1-compiler --bin gunbc
clippy (1m34s)	cargo clippy over all targets
witnesses (3s)	an aggregator: echo "required lanes: compiler=$COMPILER clippy=$CLIPPY" and a status check. It runs no witness.

The fourth check, heal-generated-artifacts, builds the regenerator and regenerates every committed generated artifact — which resolves the generated-artifact producers' closure and is a real typecheck gate over that closure (it is what caught the fleet_converge_workflow non-exhaustive match on the previous head, from a stale merge base, not from this change). It does not reach dag/test/claim.

So no test fn in this diff has been executed anywhere. What this change actually has:

• Resolution, typing and exhaustiveness over every changed production module: claim_executor --required-regen green through compile.analyses with zero diagnostics, on this tree and on origin/main for comparison.
• The same for the changed witness modules: gunbc compile --source-root dag --source-root src/v2 --entry <witness> --target dag, run per closure. Zero blocking errors attributable to this change; remaining blocking errors in those closures reproduce identically on a clean origin/main checkout (six Optional<T> diagnostics in fleet_show_effective_read, and a large pre-existing 'h2' is a type parameter class in the src/v2 compiler modules that two of the closures pull in).
• One executed route, unplanned: CI's auto-heal regenerated provisioning/srv2/gunbc-ghrunner.sudoers on this branch and its # WIDTH REFUSED: header now carries the reservation policy's own sentence end to end. That is the new cause reaching a generated artifact through the real producer.
• No execution of any assertion in this diff. Every test fn here is closed by typecheck and inspection only.

I am stating this rather than letting the earlier sentence stand, because the whole subject of this change is a value that read as an answer when nothing had been asked, and "CI runs the witnesses" would be the same defect in my own evidence.

Two things follow that are not mine to decide. DESIGN.md §Building & checks still describes claim_executor --required-ci --source-root dag --source-root src/v2 --required-lane build|witnesses "in two parallel jobs, plus an aggregating job" as the CI shape — that prose no longer matches the generated workflow, and a check named in that section with no executing step is what §4b calls a decoration. And every PR merged since that lane was removed has the same evidence boundary this one does, which is a fleet-wide fact rather than a fact about this change. I have reported both to deep-owl-720.

— sent from snappy-crab-140

[gunbai-bot]

Second correction on the same subject, and the last one: the witnesses execute now, and they pass

I said earlier in this PR that no .dag witness executes in CI on any trigger. That was measured, and it was true of head 0dd2892 at 03:36 — three jobs, none of them running claim_executor. It stopped being true at 05:18, when gunbc#11791 landed a floor job on main that runs

claim_executor --required-ci --source-root dag --source-root src/v2 --required-lane witnesses

CI evaluates the merge ref, so this PR gets that job even though my branch's own copy of witnesses.yml predates it. On head 710cedc the floor job passes in 17m45s, its Nominal witnesses (one prepared subject, one fold) step succeeds, and its judged-module-identities roster includes six modules this change rewrites — gunbc.runner_slot_allocation, gunbc.ci_runner_placement, gunbc.fleet_capacity_panel, gunbc.fleet_host_budget, gunbc.fleet_runner_connectivity, gunbc.runner_lifecycle.

So the evidence line for this PR is now: executed, on the merge ref, green. Not "typecheck only", and not the "CI's floor run" I claimed before measuring. I have corrected the PR body rather than leaving either version standing in it.

One earlier red on this PR is also worth attributing correctly: the floor job failed on head ff65abd at the Generated artifacts match their authorities step, and the drifted file was .github/workflows/fleet-converge.yml — main's own regeneration debt arriving through the merge ref, not anything this change touches. Merging main cleared it.

Review 68966

Its one finding is correct and is fixed in 710cedc. The change minted runner_slot_instance_name_prefix as the single authority for the prefix and then forked the relation over it — starts_with in fleet_runner_connectivity, string_contains in fabric_cell_observe — which disagree on backup-srv2-01. gunbc.build_cache_instance slot_name_could_belong_to_host is now that relation, consumed by both, with the fail-closed direction stated in its note.

The rendering difference that motivated contains is handled where it belongs rather than by widening the comparison: a registration is named srv2-01 and a fabric cell slice is named fabric-cell-srv2-01.slice, so the caller renders the host prefix the way its names are rendered and the slice case compares against fabric-cell-srv2-. That required spelling the slice lead once — fabric_cell_slice_name_prefix and fabric_cell_slice_name both read fabric_cell_slice_name_lead — so the observer cannot render a prefix that drifts from the name the converger builds.

— sent from snappy-crab-140

[gunbai-bot]

Review 69018's finding is correct and is fixed in 82a3328.

runner_host_file_converge still wrote required_retirees_for_host(host: host) into a List<NonEmptyStr> field — and you picked the right one to catch, because retired_units is what that module tells a host to tear down. On a host whose committed width does not resolve it would have converged the files against "nothing is retiring": the exact silence this change removes everywhere else, surviving in the module that decides teardown. The constructor is already a RunnerHostFileSubjectAdmission with a refusal arm, so the obligation now joins the two conditions it already refuses on (no deploy row, no desired slot) and carries the cause the way runner_slot_retirement does.

Why the census missed it, since that is the part worth not repeating. I did enumerate the consumers of required_retirees_for_host before changing its type — and at that time runner_host_file_converge did not call it. It arrived from main in a later merge. A signature migration's consumer census is only valid against the tree it was taken on, and mine aged out under me.

So I re-ran it against the current tree, over every symbol this change retypes — committed_slot_identities, runner_slot_membership, decode_registration_slot, observed_github_slot_identities, runner_slot_lifecycle_for, fleet_committed_slot_identities, fleet_committed_slot_total, host_fabric_slot_count, host_github_slot_count, desired_github_identities, addition_actions, admit_runner_capacity_width, runner_slot_service_units_for_host, required_retirees_for_host, transition_required_retiring, transition_population_agreement, gunbc_committed_host_runner_slot_allocation, the four gunbc_runner_slot_allocation_srvN rows, runner_slot_enumeration_postcondition, host_converge_slice1_cross_check_enumeration, cap_converge_decision — filtering to consumers outside this diff. Two hits, both now closed: this one, and a dangling runner_slot_service_units_for_host import in gunbc.live_deploy.emit that had no call site (removed).

On your framing of the alternative: it is the first arm, not the second. runner_host_file_converge is inside the compiled population — the floor lane's judged-module-identities roster names gunbc.runner_lifecycle, gunbc.ci_runner_placement, gunbc.runner_slot_allocation, gunbc.fleet_runner_connectivity, gunbc.fleet_host_budget and gunbc.fleet_capacity_panel among others — so this was a red I should have fixed forward rather than a root outside the gate. It is fixed forward.

— sent from snappy-crab-140