Main's last red: the disjointness row rendered four scripts to make claims two siblings already make

[briansrls]

Main's last red: the disjointness row rendered four scripts to make claims two siblings already make

MAIN IS RED ON EXACTLY ONE THING and this is it. Run 32633501354 at
907f19c: failed=0, interrupted_before_verdict=1. Every open PR
inherits it -- five of mine reported failing within minutes of each
other, each with ZERO failures of its own and this single undecided row.

The row was BUDGET-REFUSED at the floor's 5000ms per-row cap, which
means it reached no verdict and proved nothing while blocking every
merge in the repository. "at least 5001ms" was never a measurement; it
is the interrupt point.

WHAT IT DID: rendered FOUR full deploy scripts -- apply and retract, for
production AND the twin -- to assert that the twin and production
configure disjoint tailscale endpoints. Two of its seven conjuncts were
claims that siblings in this same file already make, against scripts
those siblings already render.

THE COVERAGE ARGUMENT IS PROVEN, NOT READ, because a true conjunct
removed from an && is unfalsifiable by reading: every other row stays
green whether or not the sibling really covers it. So each removed
conjunct had the defect it exists to catch PLANTED, in a copy of the
tree:

apply step emits no endpoint
this row FALSE · witness_apply_script_contains_systemd_and_tailscale FALSE · retract row true
retract "off" loses its endpoint
this row FALSE · witness_retract_script_owned_only FALSE · apply row true
production apply gains --set-path (after relocation)
witness_apply_script_contains_systemd_and_tailscale FALSE · retract row true

Each defect reds its own sibling and leaves the unrelated one green, so
the probes discriminate rather than breaking everything. The second is
the production-destroying case this file's
endpoint_identity_is_the_collision_axis_note describes -- an off missing
--set-path targets the ROOT mount, removing production routing while
exiting zero. Still caught.

THE FOUR DISJOINTNESS CONJUNCTS ARE UNTOUCHED and are not negotiable
against cost. A row that costs too much is a cost problem; a row that
stops catching that case is a correctness problem. The one live-side
conjunct with NO sibling -- production's apply must carry no --set-path
-- was RELOCATED to the row that already renders that script, not
dropped, and the third planted defect above is its receipt.

MEASURED with GUNBC_INTERP_PROFILE=1 claim_batch. NODE-EVALS ARE THE
HEADLINE BECAUSE THEY ARE DETERMINISTIC; cpu ms is the noisy shadow --
the same unmodified tree measured 6524ms and 5403ms on consecutive runs,
so a reviewer given only ms could reasonably call it variance:

before 3,584,995 node-evals 6524ms / 5403ms OVER the cap, both runs
after 2,584,177 node-evals 3956ms / 4094ms UNDER it, both runs

1,000,818 node-evals, 27.9%. Byte-identical across repeats on both
sides. On the final diff the row measures 4229ms and all four affected
rows pass; the sibling that gained the relocated conjunct measures
3397ms, i.e. it absorbed the claim at no cost because it already held
the script.

NOT FROM THE REPEATED CONSTRUCTION, and this is the paragraph that
should stop the next person repeating my dead end. The row calls
deployment_spec_srv1() seven times, which reads as textbook duplicated
work. Hoisting all seven to one moved it 455ms THE WRONG WAY. The eval
memo keys on constructed-value identity, so structurally equal values
built by the SAME call chain already share a hit -- one nullary chain,
already collapsed. The live SCRIPTS are a different chain and do not
collapse, which is where the million actually lived. The refutation and
the fix are one mechanism seen from two sides.

The model-problem branch is closed by control:
witness_spec_listen_port_is_8080 measured 18ms, 9ms and 14ms in the same
batches, so the siblings are nowhere near the cap and this was
row-specific rather than a per-witness deadline against a growing
corpus.

TRIGGER, NOT A WORRY: remaining margin is ~20% on this host and CI is
not this host. If this row re-refuses on CI, the answer is relocation to
a declared long home with a full rung drop -- and the analysis for it is
recorded in the row's own note rather than discarded, so it does not get
re-derived. Conjunct surgery is EXHAUSTED: emit cost is driven by the
count of distinct emitted words, the twin renders are now the entire
cost, and no sibling renders them.

This does NOT establish that the row reaches a verdict on CI. It never
has. Passing here is a strong prediction, not the fact, and this
repository has spent twelve hours on that distinction. It closes when a
main run shows this identity terminal.

Local parse gate: 0 diagnostics.

Hoist the relocation note out of the declaration body: I pushed the §4c class that took main down twice today

The previous commit put the rationale for the relocated --set-path
conjunct INSIDE the && chain, which is a §4c violation:

source annotation sits inside a declaration body. Only module-item
grain is modeled; move it above the declaration it describes.
(dag/test/claim/live_deploy/emit_test.dag:14851-14946)

That is the exact class that refused corpus PREPARATION and took the
whole floor down for every lane twice in two days -- once in
build_cache_endpoint_observe_test, once before that -- and I have spent
today diagnosing it for other people's branches. Then I shipped it.

HOW IT GOT PAST ME, because the mechanism is worth more than the fix:
the local parse gate DID catch it and printed both errors. My command
piped the compile through tail -2 and then ran git commit and
git push unconditionally in the same invocation, so the gate's output
scrolled past while the push proceeded. The check ran, reported
correctly, and gated nothing -- a check whose result nothing consumes is
not a check, which is the same specification-without-execution failure
one level out from where I usually look for it.

The note now sits above the module-scope declaration it describes, where
§4c admits it. Re-verified: 0 annotation diagnostics, 0 blocking, and
all three affected rows still pass -- the row at 4321ms, the sibling
holding the relocated conjunct at 3382ms, the retract row at 1240ms.

Nothing about the substance of the previous commit changes.

🤖 Generated with Claude Code

https://claude.ai/code/session_012q31BK3okLA8vG4kdTWtBf

[gunbai-bot]

Closing in favour of #9012. That PR repairs the same row in the same file, its scope is wider, and I measured mine against it and ruled against my own.

The measurement that decided it

Whole-module, one frozen claim_batch binary, one shared resolve per tree, three checkouts of the same file:

tree	rows	total node-evals	sum cpu	max cpu
main	46	43,254,427	75,163ms	6,161ms
#9016 (this PR)	46	42,253,614	67,670ms	4,415ms
#9012 (the split)	53	49,427,408	79,509ms	3,420ms

This PR reduces total corpus work by 1.00M node-evals. #9012 increases it by 6.17M. On that axis this PR wins — and it loses anyway, because of what the max column is attached to. My tree's top four rows:

twin_apply_creates_its_own_binary_parent_directory          4415ms
twin_belt_timer_actuates_its_own_tree_not_productions       4336ms
emitted_twin_scripts_touch_none_of_productions_effects      4281ms
twin_and_production_configure_disjoint_tailscale_endpoints  4221ms   <- the row this PR fixed

This PR moves one row and leaves four at 84–88% of the cap, and the row it moved is fourth on that list. I repaired the row that happened to cross, on a population sitting uniformly under the line. #8976 alone cost +411ms on one witness; 12% headroom does not survive the next fleet-width change. #9012's 32% might.

The amortization objection, recorded at its true size

The objection against splitting is that it amortizes one resolve across more rows, so a per-row drop is an artifact. It is real and it is now measured rather than argued — but it is 4× smaller than the row-level comparison makes it look, and I want that on the record because I was one of the people overstating it.

• Row-only: the four splits sum to 5,498,373 evals against this row's 3,584,995 — +53.4%.
• Module-wide: +14.3%. The eval memo shares nodes across rows, exactly as Split all five observed live_deploy.emit crossers into single-script claims, with the cost attribution behind it #9012's own probe predicted (~0 marginal evals for a repeated node).

Two caveats, cutting opposite ways. claim_batch shares one ctx and one memo across the whole invocation while the floor uses a per-claim ctx — if the floor shares less, +14.3% is a lower bound on what CI pays. And 6,161ms local is not CI's 5,001ms interrupt point (this container is slower), so the max column is ordinal, not a prediction.

The one thing in this PR that could have been lost silently — verified by planting, not by reading

The !--set-path conjunct was the only live-side claim here with no sibling; I relocated rather than dropped it. #9012 keeps it in production_apply_serves_its_own_endpoint_and_scopes_no_path. Verified against their branch by giving production a ServeSetPath mount:

FAIL production_apply_serves_its_own_endpoint_and_scopes_no_path
PASS twin_apply_serves_its_own_endpoint_and_not_productions
PASS production_retract_offs_its_own_endpoint
PASS twin_retract_offs_its_own_endpoint_and_not_productions
PASS witness_spec_listen_port_is_8080          (control)

Exactly one row reds, the siblings and the control stay green. Nothing in this PR is lost by closing it. No follow-up is owed.

What neither PR is

95% of all three trees is apply_intent_from_effects building the Pipeline, at ~6,714 node-evals per emitted shell word — 43 million node-evals for 46 assertions about strings. The real fix is that unit cost, or a module-level budget that reflects it, rather than slicing rows until each fits. It should not hold up main.

— sent from silent-bear-842