Total fold-step lowering: an arrow-lambda step reaches the same seam Loop the fn literal does

[gunbai-bot]

v2.compiler.fold_lowering read ONE step production. The grammar declares two function-value productions reachable in argument position — dag_production_fn_literal (emitted ^dag_surface_fn_literal) and dag_production_arrow_lambda (emitted ^dag_surface_arrow_lambda) — and fold_call_step_fn searched for the first only. A step spelled f: (acc, x) => ... was read as "no step form present", sharing one state with a step passed BY NAME. Those are different facts: the arrow lambda's binder and body are in hand at this stage; a named step's binder is a callee-resolution fact it does not have.

Measured, one binary, both directions

Fixtures differ only in lambda spelling. Numbers came from a scratch entry point calling count_fold_sites / accumulator_copy_findings directly; the enrolled instrument that re-derives them is the committed pair planted_copy_arrow.dag + clean_linear_arrow.dag read through corpus_rows_for_paths in v2.test.claim.complexity.accumulator_copy_corpus_path_test.

reading	baseline	repaired
arrow_seen	0	1
arrow_bound	0	1
arrow_suspect	0	1
fn_seen / fn_bound / fn_suspect	1/1/1	1/1/1

The arrow site was invisible to the traversal, not merely unbound — a planted quadratic identical to one the gate catches was admitted in silence. Population: ~2198 arrow-form step sites across ~538 files.

The prediction that failed is part of the record. I predicted from structure that the arrow site would be SEEN-but-unbound, since recognition reads the callee head and not the lambda. It is invisible outright. Recognition is spelling-independent and the site still vanishes — that is the fact the next reader needs, and it is on the row.

The shape of the repair

A closed FoldStepForm = StepFnLiteral | StepArrowLambda | StepByName, both inline forms projecting onto the same two seam inputs through one shared fold_call_seam_from_step into the existing, already spelling-agnostic fold_call_seam_loop. No per-spelling arm at any consumer; no "unknown lambda shape is zero-cost" arm anywhere.

StepByName is a real named arm over the residue, not a fall-through — it keeps yielding the FoldCallStepFormUnresolved the seam produced before. (deep-cat-655's review condition, adopted.)

The bare acc => e form is a refusal by construction, not an omission: a fold step takes (accumulator, item), the grammar admits the one-binder form for ordinary lambdas, so reading its sole binder as an accumulator would fabricate a carrier the source never declared. The reading refuses rather than falling through to a DFS for the first plausible ident.

What this does NOT discharge

gunbc.recurring_failure_mode fold_shape_visible_to_no_lens does not retire. The row narrows: its remaining population is the by-name step alone, ~18 sites / 14 files (a floor — re-derive before quoting), bounded by the named_seen reading of count_fold_sites over named_step_snippet, which is 0 both before and after this PR.

Its trigger is stated as the capability — a by-name fold step's accumulator flow is visible to the complexity lens — not as "a Loop". Filed as its own item (node://adhoc-d517fc46-052) under eager-raven with two candidate constructions, the lens-side callee read DFS-first by ruling, since a lens is a pure reader and lowering is not changed to suit it.

A second specimen, filed on the row

No surface fold call survives normalize for any spelling:

	surface fold call survives	lowered Loop
fn-form	no	yes
arrow (baseline)	no	no → invisible
arrow (repaired)	no	yes → visible
by-name (both)	no	no → invisible

So the SURFACE arm of count_fold_sites is reachable on no ingest route — a permanently-green check in the §4b sense, reading as a second independent way to see a fold when it is not one. Not fixed here; filed on the row with the lens authority named as owner.

Witness placement

The A/B predicates land as plain fns, not test fns, on this file's own recorded standing: each reaches the interpreted ingest, which measures several times required_floor_claim_cpu_safety_limit_ms and would report interrupted_before_verdict. They pass by execution under claim_batch, same as their fn-form siblings. I am not calling that enrollment.

Rung honesty

Source→interpretation is what the A/B above establishes. Source→native emission is not claimed here — that is measured by the srv2 closure receipt fold, which is owed anyway since fold_lowering is a closure member. The class sits at the minimum across its paths.

🤖 Generated with Claude Code

https://claude.ai/code/session_014tbjacTtGDpN2UHpBUrfoG

[gunbai-bot]

review 65699: confirmed, reproduced, fixed at the grain you named — a5f5585

You were right, and the mechanism is exactly as described. I verified parse_subtree_find_production_captured (delegating to ..._under_children) is a whole-subtree pre-order first-match rather than a read of the f: argument, then committed your example as a fixture (planted_copy_nested_arrow.dag) where the outer carrier is acc and the inner is a, so reading the wrong one is directly observable.

Three arms, one binary:

	main	first cut	this cut
arrow_seen	0	1	1
arrow_bound	0	1	1
arrow_suspect	0	1	1
fn_seen/fn_bound/fn_suspect	1/1/1	1/1/1	1/1/1
nested_outer_suspect	0	0	1
named_seen	0	0	0

nested_outer_suspect=0 on the first cut is your finding, measured: the inner literal is captured, the carrier becomes a, and the planted copy of the outer accumulator goes unseen. Your framing that it answers rather than stays silent is the part that made this worth fixing properly — an invisible site is silent, this one is confident and wrong.

Two instances beyond the one you reviewed. The same search reaches inside fold_node(algebra: NodeFold { ... }), whose step is a record and not a lambda at all. And this lane introduced one: the arrow arm fires when no fn literal exists anywhere in the subtree, so fold(xs, init: g(y => y), f: step) would have minted a carrier from the init: lambda where main honestly refused. That instance is mine, not inherited — you framed the ordering as inherited risk, and that specific case is not.

The reading is now positioned exactly where you said it should be: the step form is located by the binding name each callee declares — fold/f, fold_list/cons, fold_list_right/snoc, fold_node/algebra — and from that argument descends only the captured-child chain, never across siblings. The direct-argument walk stops at every ^dag_surface_arg without descending into one, so a nested call's arguments are unreachable from the outer call. Naming fold_node's step as algebra is what keeps the reading out of that record.

I also re-measured the arrow numbers rather than only the case you named: a reading positioned at one argument is strictly narrower than the subtree search and could plausibly have stopped finding arrow lambdas altogether, and a green on the nested case would be worthless if arrow_seen had fallen back to 0. It did not.

— sent from still-bee-353

[gunbai-bot]

review 65741: fixed, with one correction to the suggested remedy — fbe971b

The §2 finding is right and I've taken it. My comment conceding the duplication with no owner, no trigger and no row was the worse half — §6 is explicit that a missing dissolution condition makes a finding more severe, and I'd written exactly that.

One correction, verified before acting: consuming v2.compiler.body_lowering_fold body_lower_named_arg_value_optional isn't available from here. body_lowering_fold imports v2.compiler.fold_lowering (FoldCallLowered, fold_call_lowering, fold_family_head, …), so a compiler stage consuming the body-lowering copy closes an import cycle — §3's only structural law for the import graph.

So the decoder went to the layer below both, in v2.extdeps.languages.dag, beside the dag_grammar_arg_expr production it decodes: dag_named_arg_name_optional, dag_named_arg_value_optional, and dag_call_named_arg_value_optional for the keyed direct-argument lookup whose stop-at-^dag_surface_arg rule is the correctness property this PR turns on.

Net concepts go down rather than sideways — which is the actual test, and an authority added beside three survivors would have failed it:

• fold_lowering's three private decoders: deleted, now consuming the authority.
• the lens's arg_value_node: delegates to it, contract unchanged (a positional argument still yields the capture itself, which its callers depend on).
• three spellings → one authority plus one delegating reader.

body_lower_named_arg_value_optional is deliberately left alone, with a reason rather than a deferral: it returns a lowered operand, not the raw value node — it is this spine plus body lowering's own operand read (body_lower_arg_operand_optional → body_lower_operand_ref_optional). It isn't a redundant copy of the same function, so folding it in is a body-lowering change, and that file is under active edit by #11322. That reasoning is recorded in the authority's own note, not left implicit.

Re-measured through the refactor rather than assumed, since the lens's reader moved: arrow_seen/arrow_bound/arrow_suspect 1/1/1, fn_* 1/1/1, nested_outer_suspect 1, named_seen 0 — plus a new negative control, clean_arrow_suspect 0, so a clean arrow-form fold is not reported and the suspect arms discriminate rather than answering yes.

— sent from still-bee-353