Repository navigation
Extract the runtime-neutral maximum: quality is ordinal within a release, and that law is not Ollama's - #10370
Conversation
…t never served Structural reclassification only, authorized by side-chat ruling as step 1 of the realization-axis cut. No behaviour changes and no vLLM path appears. WHY IT WAS A LIE BY NAME. 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, and that is the correction I needed. I was going to call 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. WHAT IS DELIBERATELY ABSENT. No neutral kernel extraction, no Vllm arm, no FitEvidence coproduct, no QualifiedCandidate carrier, no decision-order or verdict change. 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 qualification. NO COMPATIBILITY RE-EXPORT. A wrapper preserving the old spelling would retain exactly the misleading public surface this removes, so the compile failures at old import sites are the census (DESIGN section 3 delete-first: in a fail-closed substrate the deletion is what makes real dependents refuse loudly). Censused first -- every renamed concept was contained to this module and its witness, so the blast radius was known before the rename, not hoped for. The annotation on the entry point states 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. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G
…ead name is cited Review 59813. My census before the rename covered code -- imports, call sites, type references -- and missed PROSE citations of the module. Four sites still named the dead authority: dag/std/measure.dag dag/gunbc/model/population.dag dag/gunbc/spark/serving_convergence_withholding.dag docs/plans/spark-fleet-hand-edit-gap-analysis.md These are exactly what DESIGN section 3's standing rule protects. It says to cite the SYMBOL rather than the position, on the grounds that 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. Swept in one motion, and the sweep was widened to the renamed SYMBOLS in prose as well, not only the module path -- same rule, same failure. Nothing under the old spellings survives anywhere in the tree. ONE OF THEM IS NOT A MECHANICAL RELABEL. serving_convergence_withholding carries a paragraph whose whole job is to stop that gate being mistaken for 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 merely relabelling it, so the paragraph now says 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 point more forcefully than the old one could. The docs/plans file 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 -- annotations are erased before every semantic pass, so no behaviour can change. Executed rather than asserted: 42 of 42 witnesses pass, no failures. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G
…1-ollama-choice-reclass
…ase, and that law is not Ollama's gunbc.model.ollama_choice did two separable things -- it QUALIFIED candidates against Ollama-specific evidence, and it then SELECTED a maximum under a release-relative order. Only the first is realization-specific. Leaving the second inside the Ollama module meant a second realization could only duplicate the maximum-and-tie policy or reach into an Ollama authority for it, and both roads end at one selector dispatching on runtime -- the shape the realization-axis cut exists to remove. The boundary is exact in both directions. Earlier would drag memory observations, launch configuration, realization identity and missing-fact classification into a module claiming to be neutral -- the same lie gunbc#10358 removed, re-introduced one layer down. Later would leave maximum and tie policy duplicated per realization. WHAT MOVED, and it moved rather than being copied: WithinReleaseQuality, compare_within_release, and the maximum/tie fold. Two spellings of WithinReleaseQuality, one per realization, would be the meaning fork DESIGN section 3 forbids -- forking at exactly the point where two realizations must agree to be comparable at all. WHAT THE KERNEL MAY SEE is a release identity, an ordinal rank, and an opaque payload. It never matches on the payload, never projects a field out of it, never compares two, never serializes or reconstructs one; it returns the exact payload value it was handed. A kernel that could inspect T would be a realization dispatcher wearing a type parameter. WHY THE CARRIER IS "ReleaseRanked" AND NOT "QualifiedCandidate". It promises exactly one thing: a payload associated with a release-relative ordering key. It does not assert the payload passed anyone's admission test. gunbc#10335 taught this the expensive way -- a lookup helper took its POPULATION as a parameter and trusted it, so any caller could mint the canonical carrier from a list of its own choosing. A public generic type named for the property its consumer wants rather than the property it actually promises is that same defect in generic form: a counterfeit qualification mint, type-correct and freely constructible by anyone who can name the type. UniqueReleaseRelativeMaximum has four arms because four things are genuinely different: nothing ranked, a unique maximum, no common release scale, and a shared top rank. Ties are refused rather than broken, and the empty list is its own arm rather than a fabricated sentinel row. WHAT REMAINS OLLAMA'S: ollama_ranked_admissible, the projection deciding what an Ollama artifact's release-relative quality IS, absent for anything not admissible. Qualification authority never leaves this module even though maximum-and-tie policy now does. No compatibility re-export was left behind. verdict_quality, quality_maximum, verdicts_at_quality, distinct_release_count, verdict_release and QualityMaximum are deleted, so every real dependent refuses loudly. The two annotations in ollama_choice asserting the kernel had NOT been extracted are corrected in the same commit -- leaving them would have been a false claim about this module's own decomposition. This does NOT make a vLLM path exist. A second realization still owes its own qualifier, its own evidence carriers and its own projection into ReleaseRanked. What it no longer owes is a duplicate maximum policy; what it must never be given is an arm inside choose_ollama_serving_candidate. Evidence by execution, not by typecheck: all eight selection witnesses in dag/test/claim/model/serving_choice_witness_test.dag pass against the delegated path, including the two discriminating refusals -- w_tied_quality_ranks_refuse_in_both_roster_orders and w_two_admissible_releases_refuse_for_want_of_a_cross_release_order. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G
gunbai-bot
Bot
changed the title
|
READING THIS DIFF: it is STACKED ON #10358, so seven files appear against
The other five ( I briefly retargeted the base onto #10358's branch to make that split mechanical, and reverted it: This PR must not merge before #10358. — sent from eager-pike-541 |
briansrls
left a comment
briansrls
left a comment
There was a problem hiding this comment.
REQUEST_CHANGES on exact head 58db847.
The extraction is architecturally pointed at the right seam: the commit is a single child of #10358 head 76ba0e2, the PR diff is exactly ollama_choice plus the new release_relative_selection authority, qualification remains Ollama-local, every candidate is still qualified eagerly, and the kernel carries only ReleaseIdentity, rank, and opaque T. No runtime coproduct or compatibility selector appeared. Four blockers remain.
-
compare_within_release is not total over the type it accepts. WithinReleaseQuality.rank is unrestricted Int, and Int realizes as i64, but the function derives ordering with
a.rank - b.rank. For example MAX - (-1) is outside i64, so the shared authority can wrap or refuse and reverse a legitimate ordering. It also turns an ordinal comparison into an interval-valued result whose magnitude the domain never licensed. ReturnOrdering?(std.algebra Less/Equal/Greater) or branch directly on <, ==, >; do not subtract. Add a boundary-valued control, not only small positive ranks. -
The new shared authority has no direct witness. serving_choice_witness_test does not import release_relative_selection; it only proves that the present Ollama adapter still reaches familiar outcomes. That cannot hold the generic contract or the new arms independently. Add a release_relative_selection witness covering at least: empty input; one alternative returning the exact opaque payload; same-release unequal ranks in both orders including negative ranks; cross-release refusal in both orders with the complete distinct count; equal top rank in both orders; a lower-rank tie beneath one unique higher alternative; and the exact same top alternative supplied twice remaining MaximumNotUnique. This was part of the authorized step-2 bar, not an optional expansion.
-
The declared boundary is one statement earlier than the implementation. choose_ollama_serving_candidate currently builds
rankedbefore testinglength(unresolved) > 0. All qualification correctly happens first, but the neutral ReleaseRanked population is still constructed on a roster whose unresolved member should already have caused refusal. Move therankedfold into the false arm of the unresolved match, then call the kernel. That makes the implemented order match the stated exact boundary: verdicts -> unresolved refusal -> admissible projection -> maximum. -
Several annotations overstate or miscite the mechanism.
vllm_source_revision_readis inextdeps.vllm.server, notgunbc.extdeps.vllm. “THE KERNEL NEVER SEES A VERDICT IT DID NOT RECEIVE THROUGH HERE” is false as a universal: ReleaseRanked and the generic kernel are intentionally public and any caller can construct an input; the true claim is that this Ollama production path supplies ranked verdicts only through ollama_ranked_admissible. Likewise, the neutral module does not generally select “already-qualified artifacts,” because ReleaseRanked deliberately does not assert qualification; scope that sentence to realization-local callers. Finally, “two candidates at equal rank have no maximum” contradicts the immediately preceding, correct distinction: a maximum quality exists, but no unique maximum payload does.
No request to add vLLM, alter qualification order, or widen the kernel. CI on this SHA is still pending; even after these content blockers are fixed, approval will require terminal exact-head success.
briansrls
left a comment
briansrls
left a comment
There was a problem hiding this comment.
BASE-STATE CORRECTION to my REQUEST_CHANGES review: my first fetch saw this PR based on session/eager-pike-541-ollama-choice-reclass at 76ba0e2, and the commit itself is still a single child of that SHA. During review, the PR base was changed back to main; GitHub now reports seven changed files, not the two-file child delta. The four content blockers in review 5110286270 remain findings on this exact head, but its statement that the current PR diff is exactly two files is no longer true. Separately, #10358 moved to 3bc2023 and has now been re-reviewed there. Before #10370 can be merge-shaped, its dependency/base must be reconciled with that exact parent head; no merge authorization exists for #10370.
… structural Side chat flagged that the rank projection ran BEFORE the unresolved gate. The result was never wrong -- the unresolved arm does not read `ranked` -- but the ordering was incidental rather than structural: it held because of which arm happened to consume the binding, and a later edit could have consumed it on the refusal path with nothing objecting. Moving the fold inside the `false` arm makes the answerability gate a real precondition of ranking. It also stops materializing a demand nothing reads, which is DESIGN section 2's rule that the demand graph is minimized before its answers are materialized. The predecessor had the same shape -- it computed `admissible` above the gate -- so this is not a regression introduced by the extraction; it is a defect the extraction made visible and did not have to inherit. Qualification order is unchanged and still total: `qualify_ollama_candidate` maps over EVERY candidate before either arm is chosen, so the unresolved count is computed from a fully qualified population and no candidate is skipped by moving the ranking later. All eight selection witnesses in dag/test/claim/model/serving_choice_witness_test.dag pass unchanged, including w_selection_refuses_while_an_unresolved_candidate_could_win, which is the witness that owns this exact gate. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G
|
Pushed Side chat flagged that the fold ran before the unresolved gate. The result was never wrong — the unresolved arm does not read Qualification order is unchanged and still total. Worth noting the predecessor had the same shape (it computed All eight selection witnesses pass unchanged, including |
…Ordering, and witness the kernel directly Takes side chat's exact-head review 5110286270 on #10370. Three blockers; the fourth (ranking before the unresolved gate) was already discharged in ac3762f. BLOCKER 1 -- COMPARISON BY SUBTRACTION IS NOT TOTAL OVER Int. compare_within_release returned `a.rank - b.rank`. Int realizes as signed i64, so a pair as ordinary as rank 9223372036854775807 against rank -9223372036854775807 demands a difference outside the represented domain. It is now Ordering? -- Less, Equal, Greater from std.algebra, branched directly over `<` and `>` with no arithmetic at all. It was the wrong codomain semantically as well. Quality rank is ORDINAL: the established fact is less, equal or greater, and the magnitude of the interval between two ranks is not a fact this domain has. Subtraction answered a question nobody asked and could not answer it safely. THE RED IS EXECUTED, not asserted. Mutating the comparator back to subtraction makes w_the_comparator_is_total_at_the_bounds_of_int fail with `runtime error [integer-overflow]: 9223372036854775807 - -9223372036854775807 does not fit in a 64-bit Int`, while w_the_higher_rank_wins_in_both_roster_orders stays GREEN under the same mutation. That pair is the whole argument for blocker 2 below: the defect is invisible to any fixture whose ranks are small. BLOCKER 2 -- THE NEW AUTHORITY HAD NO DIRECT WITNESS. The Ollama rows prove one ADAPTER still returns familiar end results; they cannot hold this authority's four arms, payload preservation, duplicate behaviour or ordering law, because their fixtures never reach those states. A generic contract that only an integration row exercises can be weakened while every such row stays green -- specification-without-execution with a green consumer attached. test.claim.model.release_relative_selection_witness_test adds ten rows: empty input, exact payload preservation, both roster orders, negative ranks, the Int bounds, cross-release refusal with a complete count, tie refusal in both orders, a tie BENEATH a unique maximum (uniqueness is a property of the top rank alone), no silent deduplication of an identical top alternative, and the comparator refusing at its own grain beneath the fold. The payload is deliberately an Int rather than a verdict. This module promises never to look inside T, so if a future edit starts reading the payload, an Int cannot satisfy it and the result is a compile error rather than a quietly different answer. BLOCKER 4 -- FOUR PROSE CLAIMS OVERSTATED THE MECHANISM. - The source-revision citation named gunbc.extdeps.vllm; the declaration is in extdeps.vllm.server. - "THE KERNEL NEVER SEES A VERDICT IT DID NOT RECEIVE THROUGH HERE" is false about a public generic kernel -- any caller may construct a ReleaseRanked and invoke it. The true claim is narrower and is now stated as such: the production path supplies ranked Ollama verdicts only through ollama_ranked_admissible. - The neutral module described itself as selecting among "already-qualified artifacts", contradicting the naming discipline recorded on ReleaseRanked directly below it. Qualification is the caller's expectation, not this module's subject. - "Two candidates at equal rank have no maximum" is wrong: a maximum QUALITY exists and is carried on MaximumNotUnique. What does not exist is a unique maximum PAYLOAD. All eleven new witnesses pass, and the eight existing selection witnesses in dag/test/claim/model/serving_choice_witness_test.dag are unaffected. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G
|
Pushed Blocker 1 — comparison by subtraction is not total over The RED is executed, not asserted. Mutating the comparator back to subtraction produces: That second line is the point. The ordinary-rank row stays green under the same mutation, which is the whole argument for blocker 2: this defect is invisible to any fixture whose ranks are small, and every Ollama rank is small and positive. Blocker 2 — the new authority had no direct witness. Added Blocker 4 — four prose claims. All eleven new witnesses pass; the eight existing selection witnesses are unaffected. — sent from eager-pike-541 |
briansrls
left a comment
briansrls
left a comment
There was a problem hiding this comment.
REQUEST_CHANGES on exact head ac3762f.
The one-commit delta from 58db847 is accepted: construction of the ReleaseRanked population now occurs only inside the no-unresolved arm, while qualify_ollama_candidate still maps over every candidate before the gate. This discharges the answerability-before-ranking blocker without changing qualification order or outcomes.
Three content blockers from the prior review remain unchanged:
-
compare_within_release still computes a.rank - b.rank over unrestricted Int. Int realizes as signed i64, so valid boundary inputs can overflow, and subtraction exposes an interval magnitude the ordinal law never licenses. Return Ordering? or branch on < / == / >, and add boundary-valued plus negative-rank controls.
-
gunbc.model.release_relative_selection still has no direct authority witness. The existing Ollama integration rows do not independently hold empty input, exact opaque-payload return, both roster orders, negative and boundary ranks, complete cross-release count, top-tie multiplicity, a lower tie beneath a unique maximum, or the same top row supplied twice remaining non-unique.
-
The annotation corrections remain: cite extdeps.vllm.server rather than gunbc.extdeps.vllm; scope “the kernel never sees a verdict…” to this Ollama production path because the generic public kernel accepts caller-constructed ReleaseRanked; do not generally describe ReleaseRanked inputs as already qualified; and say equal top rank has a maximum quality but no unique maximum payload.
Base/ancestry note, not an additional implementation blocker: this head descends from #1035876ba0e2, while #10358 is now 3bc2023. Those heads diverge at 76ba0e2. Therefore git diff 3bc20235..ac3762fe also contains the absence/reversal of #10358's new documentation correction; the current two-file authored step-2 delta is measured from the common parent 76ba0e2. Keeping this PR based on main for CI enrollment is sound, and merging main after #10358 squash-merges is the correct way to reconcile it before merge.
Required exact-head CI is pending. No merge authorization.
briansrls
left a comment
briansrls
left a comment
There was a problem hiding this comment.
REQUEST_CHANGES on exact head ef85243.
The head moved during review, so the ac3762f review is stale. The new commit correctly discharges all three remaining findings from that review: compare_within_release now returns Ordering? by direct comparison with a boundary-valued mutation control; the neutral authority has a direct generic witness battery; and all four overbroad or incorrect annotations are repaired. The earlier gate fix remains intact: every candidate is qualified before branching, while ReleaseRanked construction occurs only in the no-unresolved arm.
One narrow witness blocker remains. w_two_releases_have_no_common_scale_in_both_orders supplies exactly two alternatives from exactly two releases and expects distinct_release_count == 2. That does not discriminate a distinct-release count from the raw alternative count: replacing distinct_ranking_releases(alternatives) with length(alternatives) leaves every current witness green. The duplicate-top witness stays on one release and never reaches NoCommonReleaseScale, so it does not close this gap.
Add a cross-release population containing repeated alternatives from one release, for example A1, A2, B1, and require NoCommonReleaseScale { distinct_release_count: 2 } in at least both release-block orders. A three-release control is useful but not required. This makes the diagnostic field's named property—distinct releases—load-bearing rather than merely checking the current 2-row fixture.
No implementation change is otherwise requested. Required exact-head CI run 11090 is pending, and the branch still requires integration of #10358 after it lands, so no merge authorization exists.
…-release witness Takes the single blocker on side chat's exact-head review 5110417876. The cross-release row asserted distinct_release_count == 2 over a population of two alternatives, one per release. With one alternative per release the row count and the distinct count COINCIDE, so the assertion could not tell them apart: replacing distinct_ranking_releases with `length(alternatives)` left the entire battery green. The duplicate-top row does not cover it either, because that population contains a single release and therefore never reaches NoCommonReleaseScale at all. That is a witness cited as coverage while carrying no information about the property it names -- the decoration DESIGN section 4b warns about, and it was mine. The new row gives one release two alternatives: [A1, A2, B1], where a row count reports 3 and the distinct count reports 2. Both release-block orders are exercised because the dedupe is a fold, and an accumulator that only checked the immediately preceding entry, or seeded itself from the head, would answer correctly in one order and not the other. THE RED IS EXECUTED. Under `distinct_ranking_releases = length(alternatives)`: FAIL w_the_release_count_counts_releases_and_not_rows PASS w_two_releases_have_no_common_scale_in_both_orders PASS w_a_duplicated_top_alternative_is_not_silently_deduplicated The two green lines are the point: they are the rows that already existed, and neither notices the mutation. Restored, all twelve pass. No implementation change was requested and none was made. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G
|
Pushed The finding is correct and the defect was mine. The cross-release row asserted That is a witness cited as coverage while carrying no information about the property it names — the decoration DESIGN §4b warns about, landed in the very commit that was supposed to fix a coverage gap. The new row gives one release two alternatives, The RED is executed. Under The two green lines are the point — they are the rows that already existed, and neither notices the mutation. Restored, all twelve pass. No implementation change was requested and none was made. One correction to my earlier comment on this PR: I wrote that |
briansrls
left a comment
briansrls
left a comment
There was a problem hiding this comment.
APPROVE exact head 2c571df. The sole delta from ef85243 is the direct-kernel witness repair requested by review 5110417876: one release contributes two rows and a second release contributes one, while NoCommonReleaseScale must report distinct_release_count = 2 in both release-block orders. This makes distinct releases differ from raw row count, so the stated mutation to length(alternatives) is now discriminating; the two earlier controls remaining green under that mutation establishes why this row is necessary. No implementation changed. All earlier blockers remain discharged: Ordering? comparison is arithmetic-free with boundary coverage, the neutral authority has a direct generic battery, ranking occurs only after the unresolved refusal, and the annotations are scoped accurately. Content is approved. Merge authorization still requires terminal required exact-head CI, #10358 landing first, integration of that landed main into this branch, and re-review of the necessarily moved head.
|
The The refusal was All 255 are I fixed it where it belongs — #10358 Nothing about this PR's own content is implicated. Its new module and witness module bind names that have no base binding, so they produce no When the integration head is created, three things land together on it: merged |
… due Takes side chat's exact-head REQUEST_CHANGES review 5111479181 on #10358. Two findings, and only the first is prose. ONE: THE LIFECYCLE CLAIM WAS WRONG IN BOTH HALVES. My trigger paragraph said 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 set containing the admitted target. After #10358 lands, every one of these spellings binds to gunbc.model.ollama_choice at the base, so they are consumed. Different states, different reporters. Consumed rows are NOT globally blocking. The predicate is consumed_due = roster_touched && !consumed_admissions.is_empty(), so a consumed row comes 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, which is 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. TWO, AND IT IS 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 gunbc#10197 rung-drop per-row split rows; #10197 is on main at 0c031e6, 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 the earlier runs did not show this: 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 is green on the remote runner. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G
…rrate the #10197 deletion main moved again while this branch was open: gunbc#10344 landed (61274d0) and did BOTH halves of the roster treadmill in one change -- it deleted the sixteen gunbc#10197 rows that its own roster touch had made due, and added nineteen of its own for the asset-identity extraction. TWO CONSEQUENCES, AND NEITHER IS A PLAIN MERGE. FIRST, #10344's NINETEEN ROWS ARE NOW CONSUMED AT THIS BRANCH'S BASE, so this change owes their deletion for the same reason it owed #10197's. gunbc.fleet_physical_inventory on main already imports chassis_srv1 and its twelve siblings from gunbc.fleet_asset_identity -- the admitted target -- and that file is not in this diff, so base equals head for it and admission_consumed_at_base holds on every row. consumed_due is roster_touched && !consumed.is_empty(), this change touches the roster, so leaving them refuses the run. Deleted. The treadmill is deliberate, not an accident of timing: each roster-touching change discharges the cohort the previous one left consumed. #10344 did exactly this to #10197, and the next roster-touching change will do it to the cohort below. SECOND, MY OWN TWENTY-SIXTH ENTRY HAD TO BE REWRITTEN RATHER THAN CARRIED. The previous head of this branch deleted the #10197 rows and narrated that deletion. main deleted the same sixteen independently. Carrying my entry would double-record one event -- the failure the TWENTY-THIRD and TWENTY-FOURTH entries in this same ledger already call out and refuse. My entry is dropped in favour of main's action, and the rewritten entry records the #10344 discharge with a sentence saying explicitly why #10197 is not narrated here. RESOLUTION SHAPE, unchanged from the previous merge and for the same reason: main's roster is taken WHOLESALE and the 255-row cohort is re-seated on it. Hand-merging the hunk would have preserved my side's copy of rows main had already retired, which is how a resolution manufactures stale admissions. The 255 identities are untouched and none were added to #10370. cargo check -p v1-compiler --lib is green on the remote runner after the merge. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G
…rdinal was wrong twice over Takes side chat's exact-head REQUEST_CHANGES review 5111687963. It also confirms the sixteen-row deletion was REQUIRED -- it re-derived consumption across all five consumer modules rather than the one specimen I cited -- and forbids restoring them. Both remaining findings are prose, and both survived the #10344 merge in altered form. ONE: THE ORDINAL. Side chat found my entry duplicating TWENTY-SIXTH. On the merged tree it is 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 is exactly the next one. Now TWENTY-FOURTH. TWO: 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 wrote for #10344 reproduced the shape, citing fleet_physical_inventory importing chassis_srv1 and concluding all nineteen. Establishing one row and asserting nineteen is precisely what this ledger refuses. The actual 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 fifteen resolve directly. The four are the ones I would have recorded wrongly: the cooling witness imports cooler_srv3 from gunbc.fleet_physical_inventory, NOT from the asset authority, so the row looks like it names the wrong target until the binding channel is read correctly -- it follows the re-export chain to the module that actually DECLARES the name. Same admitted target, one hop further out. The entry now states that separately, because a reader checking the row against the witness's import list would otherwise conclude the row 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. The 255 identities are untouched and none were added to #10370. cargo check -p v1-compiler --lib is green on the remote runner. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G
…t never served (#10358) * FIT STEP 1: the selector stops advertising a runtime-neutral domain it never served Structural reclassification only, authorized by side-chat ruling as step 1 of the realization-axis cut. No behaviour changes and no vLLM path appears. WHY IT WAS A LIE BY NAME. 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, and that is the correction I needed. I was going to call 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. WHAT IS DELIBERATELY ABSENT. No neutral kernel extraction, no Vllm arm, no FitEvidence coproduct, no QualifiedCandidate carrier, no decision-order or verdict change. 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 qualification. NO COMPATIBILITY RE-EXPORT. A wrapper preserving the old spelling would retain exactly the misleading public surface this removes, so the compile failures at old import sites are the census (DESIGN section 3 delete-first: in a fail-closed substrate the deletion is what makes real dependents refuse loudly). Censused first -- every renamed concept was contained to this module and its witness, so the blast radius was known before the rename, not hoped for. The annotation on the entry point states 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. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G * Cut the four prose citations over too: a rename is not done while a dead name is cited Review 59813. My census before the rename covered code -- imports, call sites, type references -- and missed PROSE citations of the module. Four sites still named the dead authority: dag/std/measure.dag dag/gunbc/model/population.dag dag/gunbc/spark/serving_convergence_withholding.dag docs/plans/spark-fleet-hand-edit-gap-analysis.md These are exactly what DESIGN section 3's standing rule protects. It says to cite the SYMBOL rather than the position, on the grounds that 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. Swept in one motion, and the sweep was widened to the renamed SYMBOLS in prose as well, not only the module path -- same rule, same failure. Nothing under the old spellings survives anywhere in the tree. ONE OF THEM IS NOT A MECHANICAL RELABEL. serving_convergence_withholding carries a paragraph whose whole job is to stop that gate being mistaken for 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 merely relabelling it, so the paragraph now says 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 point more forcefully than the old one could. The docs/plans file 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 -- annotations are erased before every semantic pass, so no behaviour can change. Executed rather than asserted: 42 of 42 witnesses pass, no failures. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G * Close the two sections the rename attached a live authority name to a dead account of review 59866 is correct and the defect is mine. The rename swept docs/plans/spark-fleet-hand-edit-gap-analysis.md section 7 for the module NAME and did not re-read whether the section's CLAIM was still true. It was not. Section 7 said gunbc.model.ollama_choice keys a realization on the runner's argv and therefore cannot distinguish two units differing in context ceiling and slot count -- and the module's own annotation, in the same PR, says that argv key was replaced. Attaching the current authority's name to an obsolete account of it is worse than the stale name it replaced: a stale name is visibly dead, while 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 one was a name census; this one is a CLAIM census, and a rename does not discharge it. The question a rename must ask at every site is not "does this name still resolve" but "is the sentence containing it still true of what it now names". Section 7 is closed in the document's own idiom, recording three things it did not ask for: the carrier was REPLACED rather than widened, because argv was never the right subject and extdeps.ollama.server_env already holds the variables as typed axes; the partition is owned by the module rather than supplied by the caller, where 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 and wire second, so the module never parses an observed string. Ordered item 4 is closed with it. It read "This is landing in #9897 rather than waiting", and #9897 has merged -- a plan item describing its own landing in the present tense is stale the moment it lands. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G * A rename is a namespace wave: admit the 255 relocated bindings by exact identity CI caught what four dashboard reviews, one exact-head review and I all missed. The floor lane refused, and NOT on a witness -- every witness passed: FAILED PHASE namespace-wave-admission (255 unadjudicated delta(s), 0 stale, 142 consumed) adjudication REFUSED standing=measurement_completed blockers=1 Every one of the 255 reads TargetChanged binding test.claim.model.serving_choice_witness_test::<decl> `<spelling>` base {gunbc.model.choice} -> head {gunbc.model.ollama_choice} which 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. WHY EVERY ROW IS ENUMERATED RATHER THAN PATTERNED. The module carrying this roster 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. So each row names module, enclosing declaration, spelling and target exactly. Every one is a PURE RELOCATION: not one declaration changes what it denotes. WHY ONLY THE WITNESS MODULE APPEARS, which is worth recording because it looks like an omission and is not. The wall's binding channel is authored NAME OCCURRENCES resolved per module, and test.claim.model.serving_choice_witness_test is the only consumer importing these spellings by bare name. The other three touched files -- gunbc.model.population, gunbc.spark.serving_convergence_withholding and std.measure -- carry the old module name only in PROSE. The binding channel does not observe prose, and should not; that surface is the claim-census class this same PR already had to repair by hand, and the two are complementary rather than redundant. DISSOLUTION IS MANDATORY AND DATED. These rows go when #10358 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. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G * Consumed is not stale, and a roster touch owes the deletions it makes due Takes side chat's exact-head REQUEST_CHANGES review 5111479181 on #10358. Two findings, and only the first is prose. ONE: THE LIFECYCLE CLAIM WAS WRONG IN BOTH HALVES. My trigger paragraph said 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 set containing the admitted target. After #10358 lands, every one of these spellings binds to gunbc.model.ollama_choice at the base, so they are consumed. Different states, different reporters. Consumed rows are NOT globally blocking. The predicate is consumed_due = roster_touched && !consumed_admissions.is_empty(), so a consumed row comes 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, which is 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. TWO, AND IT IS 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 gunbc#10197 rung-drop per-row split rows; #10197 is on main at 0c031e6, 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 the earlier runs did not show this: 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 is green on the remote runner. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G * A proof that establishes one row may not conclude nineteen, and the ordinal was wrong twice over Takes side chat's exact-head REQUEST_CHANGES review 5111687963. It also confirms the sixteen-row deletion was REQUIRED -- it re-derived consumption across all five consumer modules rather than the one specimen I cited -- and forbids restoring them. Both remaining findings are prose, and both survived the #10344 merge in altered form. ONE: THE ORDINAL. Side chat found my entry duplicating TWENTY-SIXTH. On the merged tree it is 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 is exactly the next one. Now TWENTY-FOURTH. TWO: 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 wrote for #10344 reproduced the shape, citing fleet_physical_inventory importing chassis_srv1 and concluding all nineteen. Establishing one row and asserting nineteen is precisely what this ledger refuses. The actual 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 fifteen resolve directly. The four are the ones I would have recorded wrongly: the cooling witness imports cooler_srv3 from gunbc.fleet_physical_inventory, NOT from the asset authority, so the row looks like it names the wrong target until the binding channel is read correctly -- it follows the re-export chain to the module that actually DECLARES the name. Same admitted target, one hop further out. The entry now states that separately, because a reader checking the row against the witness's import list would otherwise conclude the row 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. The 255 identities are untouched and none were added to #10370. cargo check -p v1-compiler --lib is green on the remote runner. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G * 13, 10 and 15 count three different things The grouped 15/4 partition is correct -- verified against the base roster, which holds exactly 19 rows: 15 in gunbc.fleet_physical_inventory and 4 in test.claim.cooling_qualification_witness, both targeting gunbc.fleet_asset_identity. The prose around it was not. It said the fifteen were `chassis_srv1` "and its twelve siblings". That is 13, not 15, and it silently reintroduced the grain error this entry exists to refuse -- counting CONSTANTS where the admission key counts OCCURRENCES. The key is (module, in_declaration, spelling), so one constant referenced from two declarations is two rows. Measured: the fifteen are 10 distinct spellings across 8 declarations. cooler_srv3 alone contributes three rows (installed_cooler_containments, installed_cooling_realizations, srv3_cooler_asset) and chassis_srv1 two (fleet_host_spatial_facts, srv1_chassis_asset). The four cooling-witness rows are the same grain from the opposite direction: one spelling, cooler_srv3, in four different declarations. The label's "13 PhysicalAssetIdentity constants" is the moved population, not this cohort. All ten admitted spellings are among the thirteen; the three that never appear -- ams_01, pi_controller, printer_01 -- moved with the others but are referenced by no admitted occurrence. So 13, 10 and 15 count constants moved, names referenced, and occurrences admitted, and none is a restatement of another. No admission row changes; the 255-row Ollama cohort is untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G --------- Co-authored-by: gunbc-ci-auto-heal <gunbc-ci-auto-heal@users.noreply.github.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
…action shape #10358 renamed gunbc.model.choice -> gunbc.model.ollama_choice on main. Git tracked the rename, so this branch's kernel extraction landed in the renamed file and only the hunks where the two changes genuinely disagree conflicted. dag/gunbc/model/ollama_choice.dag -- four hunks, resolved to THIS BRANCH. Main carries the pre-extraction body because #10358 was a rename and nothing else: it still declares WithinReleaseQuality, compare_within_release, verdict_quality and the distinct_release_count diagnostic. This branch deleted all of them when the runtime-neutral maximum moved to gunbc.model.release_relative_selection. Taking main's side would have restored the very duplication step 2 exists to remove, so the extracted form wins every conflicting hunk. Verified after resolution: verdict_quality, quality_maximum, verdicts_at_quality, distinct_release_count, verdict_release, QualityMaximum, compare_within_release and WithinReleaseQuality are all absent from this module, the kernel import is present, and ollama_ranked_admissible remains the sole Ollama contribution to selection. Main's own sentence in that file -- "THE RUNTIME-NEUTRAL MAXIMUM/TIE KERNEL HAS NOT YET BEEN EXTRACTED, and this sentence exists so that the rename cannot be cited as though it had been" -- was written to be deleted by exactly this commit. It is now false, and it is gone. docs/plans/spark-fleet-hand-edit-gap-analysis.md -- one hunk, resolved to MAIN. This branch still carried the superseded argv-keyed claim about section 7; main carries the CLOSED correction that #10358 landed, naming ObservedOllamaLaunchConfiguration and ExactRuntimeConfigurationIdentity. Keeping this branch's side would have re-opened the exact defect that review 59866 caught and that #10403 files as a_live_authority_name_carries_a_superseded_claim. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G
The distinct-releases-vs-rows row carried an annotation claiming its two
block orders caught "an accumulator that only checked the immediately
preceding entry". That was false, and measured to be false rather than
argued.
In BOTH existing rosters -- [A,A,B] and [B,A,A] -- the two A-rows are
ADJACENT. A previous-entry-only accumulator compares A against A, dedupes
correctly, and reports 2. Block order varies which release is seen first;
it never separates the repeats, so it cannot discriminate this mutant at
all.
Added the interleaved arm [A,B,A], where the second A's predecessor is B,
so a one-entry accumulator admits it as new and reports 3 against a
distinct count of 2.
MUTATION EVIDENCE, run on this tree. Replacing the fold's
any(acc, ...) membership with a previous-entry-only test
(match last(acc) { Absent => false; Present { value: e } => ... }):
adjacent rosters alone ([A,A,B], [B,A,A]) PASS <- does not discriminate
interleaved roster ([A,B,A]) FAIL <- discriminates
and with the kernel restored, all 13 rows PASS. A first mutant attempt
using `last(acc)` directly as an `any` argument was DISCARDED rather than
reported: it died on name resolution, not on semantics, and a mutant that
fails for the wrong reason establishes nothing.
The annotation now states what the fixtures actually hold: two orders for
head-seeding, interleaving for previous-entry-only membership. The new arm
is its own row so a failure names the interleaving rather than a three-way
conjunction.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G
Superseded by integrated head 09dc566; replacing the pre-integration approval with an exact-head review of the merge and new interleaved witness.
briansrls
left a comment
briansrls
left a comment
There was a problem hiding this comment.
REQUEST_CHANGES on exact head 09dc566.
The integration itself is accepted. The head is based on landed #10358 main@97345e55; the final PR diff is only ollama_choice.dag, the new release_relative_selection.dag, and its dedicated witness. The conflict resolution keeps the extracted form in ollama_choice, does not restore WithinReleaseQuality, compare_within_release, verdict_quality, quality_maximum, verdicts_at_quality, distinct_release_count, verdict_release, or QualityMaximum there, removes the now-false “kernel has not yet been extracted” sentence, and preserves main's corrected section 7 in the gap analysis. Qualification remains Ollama-local; every candidate is qualified before the unresolved gate; ReleaseRanked construction remains inside the no-unresolved arm; and the neutral kernel still sees only release identity, rank, and opaque payload. No integration or kernel-implementation defect remains.
The new [A,B,A] control is the right discriminant for a previous-entry-only deduper, and the reported semantic mutant is valid. One exact witness-ownership defect remains: w_the_release_count_counts_releases_and_not_rows() still ends by calling w_a_repeated_release_is_counted_once_when_its_rows_are_not_adjacent(), while the latter's annotation says it is held “as its own row rather than folded into the arm above,” and w_all_release_relative_selection_claims_hold() calls both named rows again. Under the previous-entry-only mutant, the interleaved fact therefore makes both named non-aggregate rows fail; it is not localized to its own row, and the prose is false about the executable dependency graph.
Repair narrowly: remove the && w_a_repeated_release_is_counted_once_when_its_rows_are_not_adjacent() conjunct from w_the_release_count_counts_releases_and_not_rows(). Keep the two adjacent block-order rosters in that row, keep the interleaved fixture in its own row, and keep both rows in the explicit aggregate. Then the former owns row-count-vs-distinct and block-order/head-seed discrimination, while the latter alone owns previous-entry-only membership discrimination.
The PR body's evidence section is also stale relative to the solution now present. It names only the eight Ollama integration selection witnesses, even though this head's dedicated witness explicitly states that the integration battery cannot hold the generic contract and adds the direct authority battery for that reason. Update the body to record the landed/integrated #10358 base, the direct release-relative-selection battery (12 property rows plus its aggregate, 13/13 in the reported local run), the 42/42 serving-choice integration run, and the semantic mutation result: adjacent block rosters stay green while [A,B,A] goes red. Tie local evidence to this head and replace it with the exact-head CI receipt when terminal.
Required run 33880953907 names this SHA and is currently queued/nonterminal. No merge authorization. No change to the kernel, Ollama adapter, conflict resolution, or selection policy is requested.
w_the_release_count_counts_releases_and_not_rows ended by calling
w_a_repeated_release_is_counted_once_when_its_rows_are_not_adjacent, while
that row's own annotation said it was held "as its own row rather than
folded into the arm above". Both cannot be true. Under the
previous-entry-only mutant the interleaved fact failed BOTH named rows, so
a failure named two causes instead of one and the prose was false about the
executable dependency graph.
The tell was in my own evidence and I did not act on it: to measure the
adjacent rosters cleanly I had to TEMPORARILY DETACH that conjunct. Needing
to detach a call to take an honest measurement is the signal that the call
does not belong.
Removed the conjunct. Both rows remain in the explicit aggregate
w_all_release_relative_selection_claims_hold, so nothing stops executing.
Ownership is now disjoint: this row owns rows-vs-distinct counting and
block-order/head-seeding; the interleaved row alone owns previous-entry-only
membership. The annotation now states that split and says why the conjunct
is deliberately absent, so it is not helpfully restored later.
RE-MEASURED after the change, previous-entry-only mutant
(match last(acc) { Absent => false; Present { value: e } => ... }):
w_the_release_count_counts_releases_and_not_rows PASS
w_a_repeated_release_is_counted_once_when_its_rows_.. FAIL
w_two_releases_have_no_common_scale_in_both_orders PASS
w_all_release_relative_selection_claims_hold FAIL (roll-up)
Exactly one property row reds, and it is the row that owns the property.
Kernel restored: 13/13 PASS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G
|
Both blockers from review 1. Witness-ownership defect — fixed, and the tell was in my own evidence.
What I should have caught: to measure the adjacent rosters cleanly I had to temporarily detach that conjunct. Needing to detach a call in order to take an honest measurement is the signal that the call does not belong — I detached it, measured, and then put it back. Removed the conjunct. Both rows stay in the explicit aggregate, so nothing stops executing. Re-measured under the same previous-entry-only mutant:
Exactly one property row reds, and it is the row that owns the property. Kernel restored: 13/13 PASS. The annotation now states the ownership split and says the conjunct is deliberately absent, so it is not helpfully restored later. 2. Stale body — rewritten. It now records the landed/integrated #10358 base ( On the required run: — sent from eager-pike-541 |
Superseded by exact-head re-review on a48b41d after both requested fixes.
briansrls
left a comment
briansrls
left a comment
There was a problem hiding this comment.
REQUEST_CHANGES on exact head a48b41d.
Both blockers from review 5113956621 are discharged in source. The adjacent/block-order row no longer calls the interleaved row; [A,A,B] and [B,A,A] remain owned by w_the_release_count_counts_releases_and_not_rows, [A,B,A] is owned by w_a_repeated_release_is_counted_once_when_its_rows_are_not_adjacent, and the aggregate calls each named row once. Under the reported previous-entry-only mutant, exactly the interleaved property row goes red while the adjacent row stays green; the aggregate goes red only as roll-up. The annotation now matches the executable dependency graph.
The canonical body also now records the landed #10358 base, why the dedicated generic battery is required, 12 property rows plus aggregate at 13/13, the 42/42 Ollama integration run, and the valid semantic mutation result. The integration, neutral kernel, Ollama adapter, conflict resolutions, and witness design are accepted. No source change remains requested.
One body-only evidence-currency blocker remains. The CI section says Required run on this head fails, but the failed run 33880953907 names the superseded head 09dc566. The actual exact-head run for a48b41d is 33884730038 and is currently nonterminal: required build and floor are still executing. The inherited main diagnosis is credible and the source is unrelated, but a verdict measured on 09dc cannot be presented as a verdict on a48b.
Repair without moving source: identify 33880953907@09dc566b66c2 as historical evidence of the inherited main parse failure; identify 33884730038@a48b41daa91d as the current exact-head run; and replace its status only after it is terminal. If current main makes it red, do not alter this PR's content—land #10425's corrected parser repair and obtain exact-head revalidation on unmoved a48b.
No merge authorization until the body names the right subjects, a replacement exact-head review is filed, and exact-head CI is terminally successful.
…1-release-relative-kernel
1 participant
Step 2 of the realization-axis cut. Step 1 (#10358) has landed (
main@97345e55), and this branch is integrated on top of it.gunbc.model.choicewas renamed in step 1 to stop advertising a runtime-neutral domain it never served. But the actual runtime-neutral law was still sitting inside the Ollama module: quality is ordinal within one release, and that law is not Ollama's. This extracts it.What moves
gunbc.model.release_relative_selection— the maximum/tie kernel, generic over an opaque payloadT:WithinReleaseQuality { identity, rank }— pairing the rank with the release it is ordinal under moves the guard into one primitive instead of "whichever function remembers".compare_within_release -> Ordering?— absent across releases, because that is the absence of a common scale, not a tie. The predecessor returnedInt?viaa.rank - b.rank, which is not total overInt: i64 subtraction overflows at the bounds. That is a correctness fix, not a cosmetic one.UniqueReleaseRelativeMaximum<T>— four arms for four genuinely different outcomes, preserving every refusal the predecessor made.gunbc.model.ollama_choicekeeps qualification and delegates selection. Its only remaining contribution isollama_ranked_admissible, the projection deciding what an Ollama artifact's release-relative quality is. The kernel cannot read the payload, so no realization dispatch can migrate there even by accident.ReleaseRankedis deliberately not namedQualifiedCandidate: a carrier named for a property it does not enforce is a freely-constructible counterfeit mint.Integration with landed #10358
Four hunks conflicted in
ollama_choice.dag; all four resolved to this branch. Main carried the pre-extraction body (WithinReleaseQuality,compare_within_release,verdict_quality, thedistinct_release_countdiagnostic) because step 1 was a rename and nothing else — taking main's side would have restored the duplication this PR exists to remove. Verified absent after resolution:verdict_quality,quality_maximum,verdicts_at_quality,distinct_release_count,verdict_release,QualityMaximum,compare_within_release,WithinReleaseQuality.Main's sentence "the runtime-neutral maximum/tie kernel has not yet been extracted, and this sentence exists so that the rename cannot be cited as though it had been" was written to be deleted by this commit. It is now false, and it is gone.
The one gap-analysis hunk resolved to main, which carries the CLOSED §7 correction; this branch still held the superseded argv-keyed claim.
Evidence
Why a dedicated battery exists. The Ollama integration fixtures cannot reach the generic contract — every fixture rank is small and positive, so no integration row could exercise i64 bounds, an empty roster, or cross-release incomparability. An integration row cannot hold a contract its fixtures never reach.
release_relative_selection_witness_test— 12 property rows + explicit aggregateserving_choice_witness_test(Ollama integration)Payload is deliberately
T = Int, so any future arm that reads inside the payload fails to compile.Semantic mutation — measured, not argued. Replacing the fold's membership test with a previous-entry-only one (
match last(acc) { Absent => false; Present { value: e } => … }):w_the_release_count_counts_releases_and_not_rows(adjacent[A,A,B],[B,A,A])w_a_repeated_release_is_counted_once_when_its_rows_are_not_adjacent(interleaved[A,B,A])w_all_release_relative_selection_claims_holdExactly one property row reds, and it is the row that owns the property. An earlier revision had the adjacent row call the interleaved one, which made both fail together; that conjunct is removed so a failure names one cause. A first mutant attempt was discarded rather than reported — it died on name resolution, not semantics, and a mutant that fails for the wrong reason establishes nothing.
Local runs on this head. Exact-head CI receipt replaces them when terminal.
CI status
Required run on this head fails with
FAILED PHASE parse (16 error(s))+namespace-wave-admission (no head index). That is not this PR. All 16 errors are indag/test/claim/emit_copy_qualification_witness_test.dag, a file this PR does not touch;mainhas been red since #10390 left a trailing annotation at scope end. The floor itself is clean in the same job (FloorClean,unexpected_failures=0). Fixed by #10425; this PR goes green once that lands.🤖 Generated with Claude Code
https://claude.ai/code/session_01U397y4s3dSBof7vGPAX87G