Skip to content

Delete a four-crossing conjunction and cross the one uncovered arm once - #9269

Merged
briansrls merged 2 commits into
mainfrom
fix/fold-lowering-witness-cost
Aug 26, 2026
Merged

briansrls merged 2 commits into
mainfrom
fix/fold-lowering-witness-cost

Conversation

@gunbai-bot

@gunbai-bot gunbai-bot Bot commented Aug 26, 2026 •

Copy link
Copy Markdown
Contributor

Delete a four-crossing conjunction and cross the one uncovered arm once

split_dispositions_fabricate_no_loop re-ingested four snippets to ask whether fold_call_to_loop rejects them — four crossings of the ingest and lowering apparatus, and the corpus's second most expensive witness at cpu_ms=4058 against a 1552ms disclosure line and a 5000ms fail-stop (measured from the required floor's own [over-cost] line, run 32915551049).

This PR previously split it into four witnesses. That was the wrong shape and is withdrawn. Review argued the point and is right on the merits; the reasoning is worth keeping because it isn't obvious.

Why four witnesses was wrong

fold_call_to_loop is an exhaustive projection over FoldCallLowering with no fixture-dependent behaviour once the variant is selected. Three of the four snippets select the same variant:

fixture variant selected
named_step FoldCallStepFormUnresolved
algebra FoldCallStepFormUnresolved
bodyless FoldCallStepFormUnresolved
paramless FoldCallStepShapeInvalid

So three of the four witnesses would have re-proven one arm — the redundancy DESIGN §2 prices, not a subject each. "Name the failing subject" buys almost nothing when three subjects name one variant. And splitting divides the cost across four rows; deleting the conjunction removes it. Four crossings become one.

The arm that was actually uncovered — verified, not assumed

A conjunction cannot object to its own deletion, and the case for deleting this one rested entirely on claims asserted to already exist. So every claim in the file was read:

projection arm covered by
FoldCallLowered → Accepted fold_call_lowers_to_terminating_loop
FoldCallNotAFold → Rejected non_fold_call_refuses
FoldCallStepFormUnresolved → Rejected bodyless_fold_call_refuses_no_loop_fabricated
FoldCallStepShapeInvalid → Rejected nothing — only the conjunction being deleted

Three were covered. One was not. The conjunction was carrying that distinction alone, so deleting it without a replacement would have lost a live arm while looking like it removed a redundancy. paramless_step_fold_refuses_no_loop_fabricated is that arm, crossed once.

Selection coverage checked separately

"The disposition claims already cover selection" is exactly the kind of assertion that needs executing rather than reading. is_step_form_unresolved and is_step_shape_invalid are total matches over all four variants — true for the named one, false for the other three — so each of the four snippets keeps a claim that goes red if it starts selecting a different variant. Nothing in the new shape leans on the deleted conjunction for that.

Execution

Six arms executed against the edited file, all returning true: the new claim, the three retained projection arms, and two selection controls.

Local wall times are not quoted as floor costs — a standalone run is dominated by corpus startup and runs memo-disabled, 2–3× off the floor's per-claim cost. The cost figure above comes from the required run's own instrument.

This is a specific repair, not a precedent for splitting on shape

A census of all 150 rows on the [over-cost] list refutes the generalization that motivated the original split: 128 of 150 assert exactly one subject, and the corpus-wide median gap (multi 3372ms vs single 2198ms) is module-confounded — 15 of the 22 multi-subject rows live in test.claim.live_deploy.emit, and within that module single-subject median is 3358ms against multi-subject 3375ms, identical. The sharper hypothesis fails too: rows reaching a compile/emit check median 1890ms against 2540ms for those that don't. Corpus-wide the shape is common and cheap — 3,700 of 12,635 test fn declarations are multi-subject.

Nothing further was split, and on the evidence there is no reason to split anything on this shape. The better-supported lead is per-family fixture cost; that is logged, not started.

— sent from cool-hawk-324

…utor's fail-stop

`split_dispositions_fabricate_no_loop` lowered FOUR snippets in one witness while every
neighbouring witness in the file lowers one, so it cost roughly four times its siblings by
construction and was the only witness in the corpus sitting at the required floor's 5000ms
fail-stop. Measured on one witness across four runs inside one hour, on essentially one tree:
3320ms pass, 3799ms pass, 5002ms budget-refused, 5011ms budget-refused. Its own line budget is
1552ms, so the overshoot is the four subjects rather than the assertion.

The split is strictly STRONGER than the conjunction it replaces, which is why this is a repair
and not a cost dodge. `a && b && c && d` reports one verdict for four subjects: when it goes
red, nothing says which subject fabricated a loop, and the three that held are indistinguishable
from the one that did not. Four witnesses name the failing subject in the failure itself.
Nothing is weakened -- the same four properties are asserted over the same four snippets with
the same predicate.

All four executed locally and returned `true`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SAQiYQiQ7SsdxvotAFbUFc
…vered arm once

SUPERSEDES THIS PR'S OWN FIRST COMMIT. That commit split
`split_dispositions_fabricate_no_loop` into four witnesses. Review argued the split was the
wrong shape, and on the merits it is right, so the split is withdrawn rather than defended.

WHY FOUR WITNESSES WAS WRONG. `fold_call_to_loop` is an exhaustive projection over
`FoldCallLowering` with no fixture-dependent behaviour once the variant is selected, and three
of the four snippets select the SAME variant (`FoldCallStepFormUnresolved`); only the
paramless one reaches `FoldCallStepShapeInvalid`. So three of my four witnesses would have
re-proven one arm, which is the §2 redundancy rather than a subject each -- and "name the
failing subject" buys almost nothing when three subjects name one variant. Splitting also
DIVIDED the cost across four rows instead of removing it; deleting the conjunction removes it.

THE ARM THAT WAS ACTUALLY UNCOVERED, verified rather than assumed. A conjunction cannot object
to its own deletion, and the case for deleting this one rested entirely on claims asserted to
already exist, so every claim in the file was read:

    FoldCallLowered            -> Accepted   fold_call_lowers_to_terminating_loop
    FoldCallNotAFold           -> Rejected   non_fold_call_refuses
    FoldCallStepFormUnresolved -> Rejected   bodyless_fold_call_refuses_no_loop_fabricated
    FoldCallStepShapeInvalid   -> Rejected   NOTHING -- only the conjunction being deleted

Three were covered. One was not. So the conjunction was carrying a distinction alone, and
deleting it without the replacement below would have lost an arm while looking like it removed
a redundancy. `paramless_step_fold_refuses_no_loop_fabricated` is that arm, crossed once.

SELECTION COVERAGE CHECKED SEPARATELY, because "the disposition claims already cover
selection" is the kind of assertion that needs executing rather than reading.
`is_step_form_unresolved` and `is_step_shape_invalid` are TOTAL matches over all four variants
-- true for the named one, false for the other three -- so each of the four snippets keeps a
claim that goes red if it starts selecting a different variant.

EXECUTED against this edited file, all returning `true`: the new claim, the three retained
projection arms, and two selection controls. Six for six.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SAQiYQiQ7SsdxvotAFbUFc
@gunbai-bot gunbai-bot Bot changed the title One witness per subject where a conjunction over four sat at the executor's fail-stop Delete a four-crossing conjunction and cross the one uncovered arm once Aug 26, 2026
@gunbai-bot

gunbai-bot Bot commented Aug 26, 2026

Copy link
Copy Markdown
Contributor Author

The failing check is a cancellation, not a red — there is nothing in this diff to fix

The dashboard reports "CI FAILING @ 36a9e72 (1 failing)". Diagnosed before changing anything, because "failure" here conflates several states and only one of them is a defect.

What actually happened:

job conclusion duration
build success 21:40
floor cancelled 45:05
witnesses (aggregator) failure 0:03

The aggregator is correct and is doing its job: it requires both lanes to be success, and cancelled is not success, so it reports red. That is the fail-closed behaviour the aggregator exists for — it must not go green over a lane that never answered.

But the floor never reached a verdict. Its log ends with Terminate orphan process: pid (95849) (claim_executor) and carries no required-floor: planned=… executed=… summary line at all. No witness failed. Nothing was measured.

It is not this branch. Six runs across six different branches were cancelled in an 18-minute window (02:58–03:16Z): session/scm-log-verb, session/gentle-bee-495, session/royal-cat-509 (×2), session/crisp-swift-16, and this one. 32 runs are in flight concurrently. The branch head has not moved since the run started (36a9e7299, unchanged), and the workflow's concurrency group is witness-floor-${{ github.event.pull_request.number || github.run_id }} — correctly keyed per-PR, so another PR's push cannot cancel this one.

Consequence for this PR's status, stated plainly: #9269 has never completed a floor run. Both of its runs were cancelled — the earlier one on the superseded four-way-split commit, this one on the current head. So there is no floor evidence for this change in either direction, and I am not claiming any.

I am not pushing a no-op commit to re-trigger, and not re-running, without a decision from the lane owner: a cancelled run has no verdict, so re-running it is obtaining a first measurement rather than retrying an unfavourable one — but that distinction is exactly the one worth being explicit about rather than assuming.

— sent from cool-hawk-324

@briansrls
briansrls merged commit 60d62a0 into main Aug 26, 2026
5 of 9 checks passed
@briansrls
briansrls deleted the fix/fold-lowering-witness-cost branch August 26, 2026 15:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant