FIT STEP 1: the selector stops advertising a runtime-neutral domain it never served

[gunbai-bot]

Step 1 of the realization-axis cut, authorized by side-chat ruling. Structural reclassification only — no behaviour change, no vLLM path.

Why the old names were a lie

gunbc.model.choice presented ServingChoice, QuantizedCandidate, ServingConstraints, ServingRealizationIdentity and ServingRuntimeIdentity as runtime-neutral. They are not, at every load-bearing position: runtime identity is minted solely from Ollama release authority, the configuration is an ObservedOllamaLaunchConfiguration, the fit evidence is a List<OllamaRunnerMemoryObservation>, and the admissible verdict carries that observation. There is no vLLM reference anywhere in the module.

The consequence established earlier this cycle: the live vLLM service has no constructor here at all — not an unfit candidate, an unrepresentable one.

gunbc.model.choice          -> gunbc.model.ollama_choice
choose_serving_candidate    -> choose_ollama_serving_candidate
ServingChoice               -> OllamaServingChoice
QuantizedCandidate          -> OllamaQuantizedCandidate
ServingConstraints          -> OllamaServingConstraints
ServingRealizationIdentity  -> OllamaServingRealizationIdentity
ServingRuntimeIdentity      -> OllamaServingRuntimeIdentity
CandidateVerdict            -> OllamaCandidateVerdict
evaluate_candidate          -> qualify_ollama_candidate

The entry point stays a chooser

This was the correction I needed from review. I was going to name the module a qualifier. It performs two separable things — runtime-specific qualification, and maximum-quality selection with release-relative rank and tie refusal — and only the first is Ollama-specific by nature. Naming the whole module a qualifier would have misdescribed the second half and quietly asserted a decomposition that has not happened.

So qualify_ollama_candidate names the half that really is qualification, and the top-level function stays a chooser because it still chooses.

Deliberately absent

no neutral kernel extraction        no QualifiedCandidate carrier
no Vllm arm                          no decision-order or verdict change
no FitEvidence coproduct             no compatibility re-export

A central coproduct, or a generically-renamed OllamaRunnerMemoryObservation, would keep realization dispatch inside the selector and make provenance laundering type-correct — the shape this sequence exists to remove. The first common type belongs after realization-specific qualification, never around raw memory evidence.

No compatibility re-export, deliberately: a wrapper preserving the old spelling would retain exactly the misleading public surface this removes, so compile failures at old import sites are the census (DESIGN §3 delete-first — in a fail-closed substrate the deletion is what makes real dependents refuse loudly). I censused first, so the blast radius was known rather than hoped for: every renamed concept was contained to this module and its witness.

The annotation on the entry point states explicitly that the neutral kernel has not been extracted, so this cut cannot later be cited as completing step 2.

Evidence

All 42 witnesses in the choice entry pass, changed only in module and symbol references. Every fixture value, decision ordering, rejection axis, unanswerable outcome, winner and tie result is identical — which is what distinguishes a rename from an edit.

🤖 Generated with Claude Code

https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G

[gunbai-bot]

Review 59813 is right and it is fixed at d56d291. Worth naming the gap rather than just closing it: my pre-rename census covered code — imports, call sites, type references — and missed prose citations of the module. All four are cut over, and I widened the sweep to the renamed symbols in prose as well, not just the module path, since it is the same rule and the same failure. Nothing under the old spellings survives anywhere in the tree.

That gap matters more than its size suggests. DESIGN §3's standing rule says to cite the symbol rather than the position precisely because a stale name is decidable and enforceable while a stale line is not reachable from the namespace tree at all. A rename that leaves symbol citations pointing at a module which no longer exists spends that guarantee without collecting it — the citations are still decidable, they are just now decidably wrong. So the reviewer's framing is exact: the rename was not complete without them.

One is not a mechanical relabel. serving_convergence_withholding carries a paragraph whose entire job is to stop that gate being confused with the fit gate:

gunbc.model.choice decides whether a candidate fits a host's memory. This decides whether a host may receive serving convergence AT ALL.

The rename sharpens that distinction rather than relabelling it, so it now reads that gunbc.model.ollama_choice decides whether an Ollama candidate fits, and states that the gate cannot speak to a vLLM realization at all. The new name makes that paragraph's own point more forcefully than the old one could — which is a small piece of evidence that the reclassification is honest rather than cosmetic.

docs/plans/spark-fleet-hand-edit-gap-analysis.md is hand-authored rather than a generated projection, so it is edited directly rather than through the artifact gate.

All four edits are annotation or markdown only, and annotations are erased before every semantic pass, so no behaviour can change. Executed rather than asserted: 42 of 42 witnesses pass, no failures — same fixtures, same decision ordering, same rejection axes, same winners, same ties as before the rename.

— sent from eager-pike-541

[briansrls]

APPROVE exact head d56d291. This is FIT step 1 only: an Ollama-specific structural reclassification, with the top-level surface still truthfully named as a chooser and only the qualification half named qualify_ollama_candidate. The chooser body, decision order, fixtures, rejection axes, winners, and tie behavior are unchanged; all remaining changed files repair stale prose citations. No neutral kernel, vLLM arm, FitEvidence coproduct, compatibility wrapper, or genericized Ollama memory evidence was introduced. Merge authorization remains conditional on required exact-head CI reaching terminal success and this SHA remaining the head.

Stale by exact-head policy: PR head moved from d56d291 to 76ba0e2 after this review.

[briansrls]

APPROVE exact head 76ba0e2. Re-review scope was the merge from main after the prior exact-head approval became stale. The commit's parents are the previously approved d56d291 and main@ce937d0c4d4eac22e7f16eef5ad75305750fc810. Comparing d56d291 to this head shows only main-side files; none of the PR's six reviewed files changed. Comparing current main to this head yields the same six-file step-1 reclassification, with no interaction in choice.dag/ollama_choice.dag or measure.dag and no added neutral kernel, vLLM arm, FitEvidence coproduct, compatibility surface, or behavior change. Merge authorization remains conditional on required exact-head CI reaching terminal success and this SHA remaining the head.

[gunbai-bot]

review 59866 is correct and the defect is mine. Fixed in 3bc20235fb6.

The rename swept docs/plans/spark-fleet-hand-edit-gap-analysis.md §7 for the module NAME and did not re-read whether the section's CLAIM was still true. It was not: §7 said the module keys a realization on the runner's argv and therefore cannot distinguish two units differing in context ceiling and slot count — while the module's own annotation, in this same PR, says that argv key was replaced. Attaching a live authority name to an obsolete account of it is worse than the stale name it replaced: a stale name is visibly dead, a live name over a dead claim reads as current.

This is the same class as review 59813's four stale prose citations, one level deeper. That was a NAME census; this is a CLAIM census, and a rename does not discharge it. The question at every swept site is not "does this name still resolve" but "is the sentence containing it still true of what it now names".

§7 is now closed in the document's own strikethrough idiom, recording three things the section did not ask for: the carrier was REPLACED rather than widened (argv was never the right subject — extdeps.ollama.server_env already holds the variables as typed axes); the partition is owned by the module rather than supplied by the caller (the predecessor's varied_flags argument let a caller erase a causal axis from the fixed mode and thereby authorize evidence transport across it); and identity runs typed values first, wire second, so the module never parses an observed string.

I also closed ordered item 4 with it, which the review did not flag. It read "This is landing in #9897 rather than waiting", and #9897 has merged — a plan item narrating its own landing in the present tense is stale the moment it lands.

This moves the head off 76ba0e2, so the exact-head approval on that SHA no longer applies. — sent from eager-pike-541

Head moved from the exactly reviewed 76ba0e2 to 3bc2023. The prior approval is stale by its own condition; the new prose correction requires exact-head re-review.

[briansrls]

APPROVE exact head 3bc2023. Re-review scope is the single commit after the previously approved 76ba0e2: only docs/plans/spark-fleet-hand-edit-gap-analysis.md changed. The correction is necessary and accurate: the section no longer attaches the live gunbc.model.ollama_choice name to the obsolete argv-key account; it records the closed ObservedOllamaLaunchConfiguration projection, module-owned partition, and typed-values-before-wire direction, and closes the already-landed plan item rather than describing it in the present tense. The step-1 code and witness diff remain unchanged. Merge authorization remains conditional on terminal required exact-head CI and this SHA remaining the head.

[gunbai-bot]

Pushed a2799aead5a. CI caught a required contribution this PR was missing, and it caught what four dashboard reviews, one exact-head review and I all read past.

required-witnesses-floor failed — and not on a witness. Every witness passed. The refusal was:

FAILED PHASE namespace-wave-admission (255 unadjudicated delta(s), 0 stale, 142 consumed)
adjudication REFUSED standing=measurement_completed blockers=1

All 255 read:

TargetChanged binding test.claim.model.serving_choice_witness_test::<decl> `<spelling>`
  base {gunbc.model.choice} -> head {gunbc.model.ollama_choice}

That is the wall working exactly as gunbc.namespace_wave_admission documents: a run is admitted only when the unadjudicated set is empty, never when the delta set is empty. A rename that moves what a spelling binds to is a namespace wave, and I authored one without its roster contribution.

Every row is enumerated by exact identity, not patterned. The roster's own note says a pattern would admit a genuine rebind that happened to land in the same two modules — and a rename wave is precisely the change that must not be able to hide one. Each row names module, enclosing declaration, spelling and target. Every one is a pure relocation: not one declaration changes what it denotes.

Why only the witness module appears — this looks like an omission and is not. The binding channel resolves authored name occurrences per module, and the witness is the only consumer importing these spellings by bare name. gunbc.model.population, gunbc.spark.serving_convergence_withholding and std/measure.dag carry the old module name only in prose, which the binding channel does not and should not observe. That prose surface is the claim-census defect review 59866 caught on this same PR — the two mechanisms are complementary, and neither substitutes for the other.

Dissolution is mandatory and dated. These rows go when this PR merges: base and head will both carry the rename, no run can produce the deltas, and all 255 report stale — which refuses every unrelated PR. The shrink is the fix, not housekeeping.

cargo check -p v1-compiler --lib is green on the remote runner. This moves the head off 3bc20235fb6, so the exact-head approvals on that SHA no longer apply. — sent from eager-pike-541

[gunbai-bot]

Conflict resolved in 2d1c9bca1fa. Head is now 2d1c9bca1fa.

The conflict was at the head of NAMESPACE_TRANSITION_ADMISSIONS, where main moved in two ways at once:

• added the gunbc.rung_drop rows serialize as multi-kilobyte single-line blobs, so logically disjoint edits to one row are a guaranteed textual conflict — three lanes hit it in one night #10197 rung-drop per-row split rows;
• deleted the SPARK-OOBE: the vendor's interface is NVIDIA's authority, and a receipt names the revision it saw #10254 Spark OOBE vendor-interface rows, dissolved on their own trigger when that PR merged.

Hand-merging the conflicted hunk would have kept my side's copy of the OOBE rows that main had already retired. Those would have been stale admissions the moment they landed — a permission standing over a delta no run can produce — and the wall refuses a stale admission exactly as it refuses an unadjudicated delta. So the resurrection would have blocked every unrelated PR until someone deleted them again. That is the same failure this PR's own rows are dated to avoid.

So I took main's roster wholesale and re-seated my 255 rows on top of it. The authored content is unchanged; what changed is which neighbours it sits beside, which is a fact about main rather than something for me to merge by hand.

The rows are still the correct set. main has not touched dag/test/claim/model/serving_choice_witness_test.dag or dag/gunbc/model/choice.dag since this branch's base, so the wave those rows describe is unchanged — the deltas are a function of what this branch does to that witness, not of what main did elsewhere.

cargo check -p v1-compiler --lib is green on the remote runner after the merge. — sent from eager-pike-541

Superseded by head movement from 3bc2023 to 2d1c9bc; exact-head approval must not remain current after the namespace-wave roster and main merge changed the tree.

[briansrls]

REQUEST_CHANGES on exact head 2d1c9bc.

The namespace wave is real and belongs in #10358. The required-floor receipt on #10370 establishes 255 unadjudicated TargetChanged binding deltas and no witness failure. The 255 exact per-binding TransitionAdmission rows are the correct shape; #10370 must not duplicate them. I also checked the merge resolution: current main's serving_choice witness and old choice module are byte-identical to the measured base, and the head takes current main's namespace roster before adding this cohort, so the newly added #10197 rows remain and the retired #10254 OOBE rows do not return. I found no implementation or row-population blocker.

One content blocker remains in the OLLAMA_CHOICE_RECLASS_LABEL lifecycle annotation. It says that after #10358 merges all 255 rows become stale and refuse every unrelated PR. The implementation says otherwise. A binding admission is consumed when the base binds its (module, declaration, spelling) to exactly the admitted singleton target; after this rename lands, these rows bind exactly to gunbc.model.ollama_choice and therefore become consumed. Consumed rows are blocking only when the admission-roster path is touched (consumed_due = roster_touched && !consumed_admissions.is_empty()); unrelated PRs remain admitted. The source itself renders this as “consumed by its own merge; deletion is owed on the roster's next touch.”

Rewrite the trigger paragraph accordingly: the merge consumes the 255 rows; the first subsequent roster-touching change must delete the cohort, and an immediate post-merge cleanup is appropriate. They cannot be deleted in the same PR tree that needs them to admit the rename. This is prose-only. Do not change the 255 identities and do not add them to #10370.

The old exact-head approval on 3bc2023 has been dismissed. Required exact-head CI is pending; no merge authorization.

[gunbai-bot]

Pushed 4ae0b1f8e03, taking side chat's exact-head REQUEST_CHANGES review 5111479181. Two findings, and only the first was prose.

1. My lifecycle claim was wrong in both halves. I wrote that the 255 rows would report stale once the rename lands, and would then refuse every unrelated PR. Neither is what the mechanism implements:

• A stale row matches no delta in the run. A consumed row is one the base has already satisfied — admission_consumed_at_base holds when the base binds the exact (module, declaration, spelling) to a singleton containing the admitted target. After this lands, every spelling binds to gunbc.model.ollama_choice at the base, so they are consumed, not stale.
• Consumed rows are not globally blocking. The predicate is consumed_due = roster_touched && !consumed_admissions.is_empty(), so they come due on the roster file's own next touch and on no other change. An enrolled unit test names exactly that behaviour.

The wrong version overstated this cohort's blast radius — the same defect class as the argv paragraph this PR already had to repair: a confident sentence about a mechanism, written without reading the mechanism.

2. Not prose — this change owed sixteen deletions and had not made them. Because this PR touches the roster, roster_touched is true, so every already-consumed row in the file comes due. main carries sixteen #10197 rung-drop rows; #10197 is on main at 0c031e6da4e, and gunbc.design_ledgers there already imports rung_drop_roster from gunbc.rung_drop.roster by name — so the base binds each admitted spelling to its admitted target and all sixteen are consumed. Left in place, this run refuses again — on consumed_due rather than on unadjudicated deltas, one blocker traded for another.

They are deleted with their label, and a twenty-sixth dissolution entry records why this change owed it. Carrying consumed rows forward while editing the same file is precisely what the predicate exists to prevent.

Why earlier runs didn't surface it: neither 76ba0e2 nor #10370's head touches namespace_wave_admission.rs, so consumed_due was false there and the 142 consumed rows were reported without blocking. Touching the roster is what makes them due.

The 255 identities are unchanged and none were added to #10370. cargo check -p v1-compiler --lib green on the remote runner. Net +30/-165. — sent from eager-pike-541

[briansrls]

REQUEST_CHANGES on exact head 4ae0b1f.

First, the controlling correction: the stricter interim note was right and my final “prose-only” ruling was materially incomplete. DO NOT restore the sixteen gunbc#10197 rows. This PR touches namespace_wave_admission.rs, so roster_touched is true; every admission already consumed at the base is due on this run.

I rechecked the full base proof rather than extrapolating from gunbc.design_ledgers. #10197's merge 0c031e6 is an ancestor of this PR's base 4f0ad8c, and none of the five relevant consumer files changed in between. The sixteen rows partition 1/2/5/7/1 across gunbc.design_ledgers, deleted_cadence_reference_census_witness_test, rung_drop_declaration_witness_test, rung_drop_standing_partition_witness_test, and tools.ci_gates. At the base, each named declaration still contains the spelling and each module imports that spelling from exactly the admitted target. The candidate set is therefore the admitted singleton for every row, admission_consumed_at_base holds sixteen times, and leaving them would trade the unadjudicated blocker for consumed_due. The deletion and label removal are REQUIRED and ACCEPTED.

The exact-head delta is one file, +30/-165. It removes exactly those sixteen rows and their label, corrects the Ollama cohort lifecycle prose, and does not touch any of the 255 identities or #10370. The 56 KB near-miss did not enter the commit; the existing ledger remains present.

Two prose blockers remain in the new dissolution entry:

1. It creates a duplicate ordinal. The file already contains TWENTY-SIXTH DISSOLUTION (2026-09-04, gunbc#10197) for the 142 #10254 OOBE rows immediately above. The new entry is also TWENTY-SIXTH DISSOLUTION, and there is no TWENTY-SEVENTH entry. Rename the new one to TWENTY-SEVENTH DISSOLUTION (2026-09-04, gunbc#10358). This ledger itself states that the ordinal exists to make an entry citable and records duplicate ordinals as a defect; repeating one here is not harmless numbering.

2. The proof paragraph names only gunbc.design_ledgers importing rung_drop_roster and then concludes that each of sixteen rows is consumed. That evidence establishes one row, not sixteen; the other fifteen span four modules and four additional target/spelling groups. Record the actual grouped join, for example: 1 design_ledgers; 2 deleted-cadence witness; 5 rung-drop-declaration witness; 7 standing-partition witness; 1 tools.ci_gates, with each group's exact imported target. The deletion is correct; the written proof is presently narrower than its conclusion.

These corrections are prose-only. Do not restore the sixteen rows, do not alter the 255-row cohort, and do not add anything to #10370. Run 33860809090 is pending but will become superseded when this head moves; the replacement exact-head run must establish zero unadjudicated, zero stale, and no consumed-due blocker. No merge authorization.

[gunbai-bot]

Pushed 12b0e57810a, taking side chat's exact-head REQUEST_CHANGES review 5111687963. Both remaining findings were prose, and both survived the #10344 merge in altered form.

1. The ordinal. Side chat found my entry duplicating TWENTY-SIXTH. On the merged tree it's worse: #10344 trimmed the ledger, so the highest surviving ordinal is TWENTY-THIRD and my entry was skipping twenty-four and twenty-five. A skipped ordinal is the same defect as a duplicated one — the number exists to make an entry citable by its own name, and it does that only if it's exactly the next one. Now TWENTY-FOURTH.

2. The proof was narrower than its conclusion, and the criticism transferred exactly across the rewrite. Side chat caught my #10197 paragraph citing the design_ledgers row and concluding all sixteen. The entry I then wrote for #10344 reproduced the shape — citing fleet_physical_inventory importing chassis_srv1 and concluding all nineteen.

The real partition, computed rather than assumed:

15  gunbc.fleet_physical_inventory            -> gunbc.fleet_asset_identity
 4  test.claim.cooling_qualification_witness  -> gunbc.fleet_asset_identity

The four are the ones I'd have recorded wrongly. The cooling witness imports cooler_srv3 from gunbc.fleet_physical_inventory, not from the asset authority — so the row reads as naming the wrong target until you follow the binding channel to the module that actually declares the name. Same admitted target, one hop out. The entry states that separately, because a reader checking the row against the witness's import list would otherwise conclude it was mis-authored.

Neither consumer file is in this diff, so base equals head for both and admission_consumed_at_base holds on all nineteen.

Also on the record from that review: the sixteen-row #10197 deletion was required, verified independently across all five consumer modules rather than the single specimen I cited, and restoring them is forbidden. On the current head that deletion is main's (via #10344), not this PR's — the entry says so explicitly rather than double-recording one event.

The 255 identities are untouched and none were added to #10370. cargo check -p v1-compiler --lib green remotely. — sent from eager-pike-541

Superseded by head movement from 2d1c9bc to 12b0e57. The lifecycle correction and subsequent merged-roster disposition are reviewed at the new exact head.

[briansrls]

APPROVE exact head 12b0e57.

Both blockers from review 5111687963 are discharged on the merged ledger actually present at this head. #10344 changed the roster before this branch rejoined main: it deleted the sixteen #10197 rows and introduced nineteen asset-identity admissions. The highest surviving dissolution ordinal at the join is TWENTY-THIRD, so this head correctly records the next event as TWENTY-FOURTH rather than preserving the pre-merge 26/27 prescription.

The consumption proof now owns the full population rather than one specimen: 15 binding identities in gunbc.fleet_physical_inventory resolve directly to gunbc.fleet_asset_identity, and 4 in test.claim.cooling_qualification_witness resolve through the imported fleet namespace to that same declaring authority. The base import carries all 13 asset constants used by the repeated direct binding identities; the witness imports cooler_srv3 through fleet_physical_inventory; neither consumer file is in this PR diff, so base and head agree and admission_consumed_at_base holds for all nineteen. Their deletion on this roster touch is correct. The independently deleted #10197 cohort is not double-narrated.

The Ollama lifecycle paragraph now says consumed rather than stale and scopes the deletion obligation to the next roster-touching run. The 255 exact admission identities remain unchanged, and none were copied to #10370. No implementation, selector behavior, or step-2 content changed.

Required exact-head run 33868113495 is pending. Merge authorization remains conditional on terminal success and this SHA remaining the head.

Superseded by head movement from 12b0e57 to 8ef903f. The new commit corrects the occurrence-count versus moved-constant prose, so exact-head approval must be reissued on the reviewed tree.

[briansrls]

APPROVE exact head 8ef903f.

The sole commit after 12b0e57 changes only the consumption-proof prose in namespace_wave_admission.rs (+22/-7); no TransitionAdmission row changes. It closes the count-versus-grain seam in my superseded review.

The measured populations are distinct and now stated distinctly. The base cohort has 19 exact admission keys: 15 (module, in_declaration, spelling) keys in gunbc.fleet_physical_inventory and 4 in test.claim.cooling_qualification_witness, all targeting gunbc.fleet_asset_identity. The 15 direct keys contain 10 distinct spellings across 8 declarations: repeated uses such as cooler_srv3 in three declarations and chassis_srv1 in two are separate occurrence-grain rows. The four witness keys are one spelling, cooler_srv3, in four declarations. Separately, fleet_asset_identity declares 13 moved PhysicalAssetIdentity constants; ams_01, pi_controller, and printer_01 are in that moved population but in no admitted occurrence. Thus 13 constants moved, 10 names referenced, and 15 direct occurrence keys are three different denominators.

The TWENTY-FOURTH ordinal, grouped 15/4 consumption proof, deletion of the inherited consumed cohort, consumed-not-stale lifecycle, and all previously reviewed FIT step-1 content remain accepted. The 255 Ollama admission identities are unchanged and none are copied to #10370.

Required exact-head run 33869134455 is pending. Merge authorization remains conditional on terminal success and this SHA remaining the head.