Route the fold-lowering witnesses into the executing floor: their first execution ever was 1/15 green, and the decline was hiding rot, not parking evidence

[briansrls]

1 of 15 of these claims passed the first time anyone ran them, and thirteen of the failures were older than the PR that added the last seven. That is the reason for this change. Routing them onto the executing floor is the mechanism; the number is the justification.

What was true before

#8801 split fold lowering's malformed arm from its not-applicable one and added seven witnesses as the split's evidence. They were authored into module v2.test.long.fold_lowering, which the required floor DECLINES by authored module name (v2.workflow.required_floor long_home_prefixes). Proven from both directions by one number: main run 32515441229 reported declined_long=551; the branch carrying them reported 558. Discovery reaches them. They do not run.

What the first execution said

Measured with claim_batch against the long entry as it stood on main: 1 of 15 PASS. Thirteen died with no field 'kind' on type 'NormalizedTree'; one returned false.

So these claims were not parked-but-fine. They were RED, and had been since #8256 (BL-1) sealed NormalizedTree behind an admission door — the alias they were written against became a record, every consumer that mattered was updated, and this file was not, because nothing runs it.

A declined home does not freeze a witness's verdict. It freezes the last time anyone knew it. The decline was not parking working evidence; it was hiding rot, and the rot was invisible precisely because the mechanism that would have shown it was the mechanism that was switched off.

Three defects, all in the witness, none in the subject

1. ingest returned the sealed carrier where a Node was wanted. Projecting .root clears the runtime error.

2. ingest ran normalize between parse and the locate. Measured both ways on the same snippet: WITH normalize the well-formed fold reaches fold_call_lowering as FoldCallNotAFold and ^fold is not among the tree's atom identities at all; WITHOUT it, FoldCallLowered. v2.compiler.fold_lowering's own contract says its input is the surface ^dag_surface_primary_expr capture, read via ^grammar_sequence_left_node_projection — normalize's output is past that seam. The witness was handing the desugaring an input from the wrong side of it, and the refusal it produced was correct. The ingest now stops where the subject's input lives.

3. A binder destructured from a GENERIC coproduct is usable in ARGUMENT position but not as the receiver of a field projection. l.children off Present { value: l } of Optional<Node> fails with error type cascade at the projection, while four sibling claims pass using the same binder as an argument. This is a v2 inference deficit, not a fact about these claims. It is now filed as gunbc.generic_binder_field_projection_deficit — invalid state, harm, rung found at (mitigatable), ceiling (structurally impossible; the class is decidable and unbuilt), next-rung trigger, and the two located sites — and named in an annotation at each site whose shape it dictates. The projection is performed where the type is concrete (a Node parameter); both claims assert exactly what they asserted before, and the helpers dissolve when the deficit closes.

The home

The routed home already existed: src/v2/test/claim/fold_lowering_test.dag, module v2.test.claim.fold_lowering, one unit claim over the same subject. This merges into it rather than minting a third name for one concept (DESIGN.md §3).

An explicit import block in a witness entry REPLACES the ambient witness pool rather than adding to it. Measured: with that file's two import rows present, every end-to-end claim fails no such function: tokenize. The rows are removed, not relocated; the one claim that used them still passes without them. That is a statement about how import blocks behave in witness entries, not a note about this file.

Result

16 of 16 PASS, measured in one claim_batch process (the 15 plus the unit claim already in the routed home).

Per-claim cost 1231–2209ms CPU, median ~1340ms, against the floor's enforced required_floor_claim_cpu_safety_limit_ms=5000 and required_floor_claim_wall_safety_limit_ms=10000. One row (2209ms) sits over required_floor_claim_cost_line_ms=1552, which is diagnostic only and refuses nothing. Nothing here approaches an admission limit.

Separately worth a line, because it is the class DESIGN.md keeps correcting itself for: required_floor.dag's prose still narrates a 500ms hard / 100ms warn tier pair. Those are stale narrative, not the values the host reads — the host reads the three functions above. Not changed here, flagged as found.

The floor's declined_long should fall by 15 and its routed population rise by 15.

Secondary effect

The FrozenPathDeferral row naming the departed entry and its 8 pre-existing functions is deleted with it. That roster counts witnesses admitted with no executing consumer, and these now have one — so the frozen population goes DOWN by one entry rather than up, which is the direction a freeze carrier is supposed to move.

🤖 Generated with Claude Code