fold_shape_visible_to_no_lens is positional, not spelling-bound: the by-name DFS finds the site erased before any lens runs by briansrls · Pull Request #11315 · gunb-ai/gunbc

briansrls · 2026-09-13T21:37:02Z

Residue of gunbc.recurring_failure_mode fold_shape_visible_to_no_lens after #11314 (this branch carries #11314's commits; it should land after it). The brief ordered a DFS: establish whether a lens-side read of the referenced step declaration is available at lens time before proposing a Loop. This PR is that DFS, answered by execution, plus the enrolled evidence it produced. No lowering is changed and no lens arm is added — neither candidate construction survives the measurement.

The answer, in two halves

Declaration half — available. For fn step(acc: Int, x: Int) { .. } in the same module, the normalized root carries step as a named Conj member → lowered Arrow, first domain binding acc (v2.std.node_query arrow_domain_named_param_bindings reads it), body on ^arrow_body_edge. Nothing new is needed to resolve a name to its declaration inside one root.

Site half — not available, and not for a lens-side reason. Dumped on the tokenize / parse_module / normalize route:

body	normalized shape	`folds_seen`
`{ fold(xs, init: 0, f: step) }`	`Transform [ Atom {, Atom int_literal, Atom step ]`	0
`{ g(xs, init: 0, f: step) }` (not a fold)	identical	0
`{ let seed = 0 \n fold(xs, init: seed, f: fn(acc, x) {..}) }`	Bind whose body is a bare L/R spine, leftmost `Atom fold`, every right projection an empty Conj	0

The callee is gone (or, after a let, the arguments are gone). That is gunbc.recurring_failure_mode call_expression_erased_at_v2_body_lowering (#11207) seen from the consumer side. There is no fold head to key on and no argument position to read a step name from; recognising the site by the residue of the erasure would be reading a defect as a fact (§5 workaround = line-stop). So (B) is blocked on that class's trigger and on nothing else, and (A) — the seam Loop over a step reference — remains fierce-lark-661's ruling and would not reach the let / match / if positions anyway.

The class is positional, not spelling-bound — the finding that changes the plan

Same planted fold / list_append copy the gate refuses (gate_red_quadratic_rejects), moved between body positions, nothing else changed:

position	fn-literal step	by-name step
sole body statement	Loop, suspect minted	erased → silent
after one `let`	erased → silent	erased → silent
`match` arm	erased → silent	erased → silent
`if` branch	erased → silent	(not measured separately)
nested inside a sole-body fold's step	surface call inside retained Loop body, seen (folds_seen 2)	—

So the "~2198 arrow-form sites now covered" of #11314 holds for the sole-body position only. A single-line floor over dag/ + src/v2 (fold-family call lines whose preceding non-blank line is an fn header ending in {) puts roughly two in five fold-family call lines in that position — the rest sit in this class. The nested row also refutes the second-specimen receipt on the row (surface arm reachable on no route): it fires inside retained Loop bodies.

What lands

src/v2/test/claim/long/accumulator_copy_fold_analysis_test.dag: four position specimens; test fn witnesses let_prefixed_fold_copy_is_caught, match_arm_fold_copy_is_caught, declared_named_step_fold_copy_is_caught (RED, executed) and nested_fold_inside_a_sole_body_fold_is_visible (green positive control).
gunbc.explicit_witness_admission: the three RED probes rostered, each with a dissolution naming the erasure class's trigger as the capability; the by-name row subsumes the two existing weaker rows (named_step_fold_refuses_accumulator_unread, report_counters_state_the_domain), which stay until it fires.
Receipts on fold_shape_visible_to_no_lens (DFS result, positional bound, restated trigger with the dependency) and on call_expression_erased_at_v2_body_lowering (fold-family calls erase too; the let form is a second shape losing the argument half; the compile-door consumer it silences; trigger clause (iii) gains the let-prefixed shape).

Executed under claim_batch on a locally built interpreter at this head: let_prefixed FAIL, match_arm FAIL, declared_named_step FAIL, nested PASS, named_step_fold_refuses_accumulator_unread FAIL, report_counters_state_the_domain FAIL, quadratic_fold_has_suspect PASS. explicit_witness_admission_duplicate_count = 0; docs projection regen runs clean.

Supersedes #11314 (ruling eager-raven-113, 2026-09-13)

This branch carries #11314's full content (merged through fbe971b2), so it lands as the single PR; #11314 closes as superseded.

Review 65763's finding, and its resolution. The reviewer read fold_call_step_form as an unrestricted first-match DFS that would take a lambda from a non-step argument as the step. Confirmed by execution on the head that review saw (fcd4e6d6, carrying #11314 at 42e5937): fold(map(xs, f: (a, b) => list_append(left: b, right: a)), init: 0, f: step) lowered to a seam Loop with loop_carrier_edge = a. still-bee's later a5f5585 reads the step only at the callee-declared slot (f: / cons: / snoc: / algebra:) through dag_call_named_arg_value_optional, which stops at the first arg shell without descending. Re-measured on the merged head: positional-nested, named-nested and the fold_node record form all produce no Loop and no carrier; the control with the step in its slot beside the same decoy still lowers and catches the copy. So the fix holds and no further fold_lowering edit is made here.

Enrolled: a_lambda_in_a_non_step_argument_mints_no_carrier (red control — loop=yes on 42e5937, loop=no at the slot read) and an_inline_step_beside_a_decoy_lambda_is_still_caught (positive twin), both executed PASS under claim_batch, plain fns on the enrolment-margin standing recorded in the file.

Review-driven changes (all on this head)

review 65787 — the positive controls are plain fns no lane plans and were called "enrolled": wording corrected on the row and the corpus-path file, and the §4b(3) drop gunbc.rung_drop accumulator_copy_positive_controls_off_every_lane landed as a typed row (previous MechanicallyPreventable → temporary Mitigatable, LostAsPassenger of the falsifier long-lane executor deleted at FLOOR-Y cutover: delete the CI floor, rebuild from the run_required_floor seed #8283, six-identity population, restoration = an executing lane with a declared ceiling for an ingest-reaching hermetic witness, observed at retirement). Every refused enrolment route is recorded on the row by execution or by the authority that closes it.
review 65812 — fold_family_head now derives from fold_step_argument_name, so family membership and the step slot are one row set.
review 65763 — see "Supersedes Total fold-step lowering: an arrow-lambda step reaches the same seam Loop the fn literal does #11314" above: the decoy-lambda specimen is a red control with a positive twin.

What lands next, not here

On merges of this head with #11322 (012911ab), let_prefixed_fold_copy_is_caught and match_arm_fold_copy_is_caught flip green with no regressions, and a lens arm that treats a fold-family combiner Transform as a counted, ^fold_accumulator_unread-refused site greens the row's two original exit witnesses. That arm cannot execute on this head (the shape does not exist without #11322), so it is a follow-up PR on top of #11322; declared_named_step_fold_copy_is_caught stays RED until named actuals reach the lowered call envelope, which zesty-fox-514 has classified as its own admission.

A green required run here is not evidence of a clean corpus

The corpus and roster gates of this lens sit in gunbc.ci_layer_roots witness_exclusion_frontier (priced out), so no required lane asks whether any real file now reds under the widened lens. #11314's brief step 3 — census the corpus, file every newly-red site with its population, never allow-list — is an undischarged obligation that travels with those commits. still-bee-353 ran a bounded attempt (24 arrow-form files at fbe971b2, gate-identical to this tree: all 24 read, none unreadable) and stopped it honestly: the baseline arm did not resolve, so the newly-red difference set is unknown, and the total was carried in a process exit code, which wraps at 256 and is therefore not a number. Measured cost ~612s per file interpreted, ~91h single-threaded for the ~538-file population — a sharded batch job from a clean origin/main checkout, not a session job. Filed as node://adhoc-5f6e169c-19b under eager-raven-113 with both instrument defects named. Not a hold on this PR; a reason not to read its green as a corpus verdict.

What this does NOT do

Does not retire the row, does not green the exit witnesses, does not touch fold_lowering / body_lowering_fold / the lens (no srv2 closure receipt owed). The row's next-rung trigger now names its dependency honestly: it cannot climb ahead of call_expression_erased_at_v2_body_lowering.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RVFnQtBLTJd1ufJFr2hQKq

…Loop the fn literal does 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 therefore read as "no step form present" and shared one state with a step passed BY NAME, which is a different fact: 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 differing only in lambda spelling (scratch A/B over count_fold_sites / accumulator_copy_findings): baseline repaired arrow_seen 0 1 arrow_bound 0 1 arrow_suspect 0 1 fn_seen/bound/suspect 1/1/1 1/1/1 The arrow site was INVISIBLE to the traversal, not merely unbound: with no Loop produced and no surface fold call surviving normalize, nothing reached the lens to be refused about -- so a planted quadratic identical to one the gate catches was admitted in silence. Population: ~2198 arrow-form step sites across ~538 files. THE SHAPE OF THE REPAIR. A closed FoldStepForm = StepFnLiteral | StepArrowLambda | StepByName, with 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, and 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. DELIBERATELY NOT GIVEN A CARRIER: the bare single-binder form `acc => e`. A fold step takes (accumulator, item), and 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. WHAT THIS DOES NOT DISCHARGE, stated because the row's trigger is a capability and this is not all of it: the BY-NAME population (~18 sites / 14 files) is still invisible -- named_seen is 0 both before and after -- so ^fold_accumulator_unread remains unreachable and gunbc.recurring_failure_mode fold_shape_visible_to_no_lens does NOT retire here. The measurement above also shows why it is a different problem: no surface fold call survives normalize for ANY spelling, so visibility depends entirely on producing a Loop, and a named step has no inline body from which to build one honestly. Escalated separately rather than decided here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014tbjacTtGDpN2UHpBUrfoG

…a second specimen Appends to gunbc.recurring_failure_mode fold_shape_visible_to_no_lens, per fierce-lark-661 and eager-raven-113 rulings 2026-09-13. Four receipts, no prose restated elsewhere: REPAIR RECEIPT for the arrow half, with the measurement and with the PREDICTION THAT FAILED recorded beside it -- the repairing lane predicted from structure that the arrow site would be SEEN-but-unbound (recognition reads the callee head, not the lambda) and it is invisible outright. That is the fact the next reader needs, so it is in the row. NARROWED POPULATION: the row now carries the by-name step alone, ~18 sites / 14 files, against ~2198 arrow sites / ~538 files covered. The trigger is restated as the CAPABILITY -- a by-name fold step's accumulator flow is visible to the complexity lens -- not as "a Loop", and the row is deliberately uncommitted between the two candidate constructions, with the lens-side read DFS-first by ruling (a lens is a pure reader; lowering is not changed to suit it). SECOND SPECIMEN, the class from the other end: count_fold_sites' SURFACE arm is reachable on no ingest route. tree_contains_surface_fold_call is false for all three spellings, so the arm has never fired and visibility depends entirely on a Loop. A permanently-green check in the DESIGN 4b sense -- it reads as a second independent way to see a fold and is not one. Owner named as the lens authority. BARE SINGLE-BINDER ARROW as a refusal by construction rather than an omission: a fold step takes (accumulator, item), so `acc => e` gets no carrier and the reading refuses rather than falling through to a DFS for the first plausible ident. The citation for the arrow measurement names the scratch entry point that produced the numbers AND the enrolled fixtures that re-derive them, rather than implying the census produced them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014tbjacTtGDpN2UHpBUrfoG

…ion/deep-newt-301

…s, and the class is positional, not spelling-bound Answers the ordered question on gunbc.recurring_failure_mode fold_shape_visible_to_no_lens (is a lens-side read of the referenced step declaration available at lens time) by execution, in two halves. The declaration half is available: a module-scope step's Arrow member and its first domain binding sit in the normalized root. The site half is not: `fold(xs, init: 0, f: step)` lowers to a Transform whose operator is the brace token with the callee dropped -- the shape call_expression_erased_at_v2_body_lowering already records -- so there is nothing for a reader to resolve from. Neither candidate construction is built. The same measurement shows the class is wider than the by-name residue: the planted fn-literal copy the gate refuses as a sole body statement is admitted in silence after a let, in a match arm and in an if branch, so the arrow-half coverage of #11314 holds for the sole-body position only. A nested fold inside a sole-body fold IS seen, which refutes the surface-arm specimen. Three RED witnesses enrolled and rostered with dissolution on the erasure class's trigger, one green positive control, receipts on both class rows. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RVFnQtBLTJd1ufJFr2hQKq

…ll subtree (review 65699) parse_subtree_find_production_captured (v2.extdeps.languages.dag, delegating to ..._under_children) is a whole-subtree PRE-ORDER FIRST MATCH, not a read of the step argument. So `fold(xs, init: 0, f: (acc, x) => ... fold(x, init: acc, f: fn(a, b) { a }) ...)` classified on the INNER fn literal and built a seam Loop whose body and carrier belong to the inner lambda. The copy planted on the OUTER carrier then goes unseen, because `acc` is not the carrier the lens was handed -- a fabricated, plausible lowering answering confidently about the wrong accumulator (DESIGN section 5). Worse than the invisibility this lane repaired: an invisible site is silent; this one answers. THREE ARMS, one binary, the nested case committed as a fixture: main first cut this cut arrow_seen 0 1 1 arrow_bound 0 1 1 arrow_suspect 0 1 1 fn_seen/bound/suspect 1/1/1 1/1/1 1/1/1 nested_outer_suspect 0 0 1 named_seen 0 0 0 The narrower reading still finds arrow lambdas -- measured, because a reading positioned at one argument could plausibly have stopped finding them at all, and a green on the nested case would be worthless if arrow_seen had fallen back to 0. TWO INSTANCES BEYOND THE ONE REVIEWED. The same search reached 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 this lane's, not inherited. THE READING. 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 an argument belonging to a nested call inside an argument value is unreachable. Naming fold_node's step as `algebra` is what keeps the reading out of that record. Constructor note: a bare `Present { value: ^f }` inside an if-chain resolves to Primitive(String) against Optional<Symbol>; the symbols themselves resolve fine (isolated with a separate probe). It sits behind a typed helper now, the idiom the lens already uses for some_finding / some_let_binding_fact. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014tbjacTtGDpN2UHpBUrfoG

…dded an instance main refused Two distinguishing facts per eager-raven-113's ruling, recorded on gunbc.recurring_failure_mode fold_shape_visible_to_no_lens rather than left in the PR. THE SEARCH GRAIN, found by review 65699 on the repair itself. A whole-subtree pre-order first-match reads the INNER fn literal of an arrow step's body and builds a seam Loop from it, so the lens is handed the wrong accumulator and answers about it CONFIDENTLY. That ranks ABOVE the invisibility this row was opened for: a silent subject at least leaves a counter reading 0, while a wrong carrier leaves a clean verdict nobody has reason to doubt. Right grain: read at the argument the CALLEE declares and descend only the captured-child chain. Instrument named (planted_copy_nested_arrow.dag, outer carrier acc, inner a). THE FIRST CUT ADDED AN INSTANCE THE UNREPAIRED CORPUS REFUSED, which is the general form worth carrying: when the fix for an invisible shape is a BROADER search, the search acquires the neighbouring shapes too and must be RE-POSITIONED rather than widened, or the repair converts silence into a confident wrong answer. Prose braces avoided in both receipts -- a .dag string interpolates `{ }`, so `fn(a, b) { a }` written literally resolves as a variable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014tbjacTtGDpN2UHpBUrfoG

…aching identity is refused at enrolment margin Run 34786156711 refused nested_fold_inside_a_sole_body_fold_is_visible at 1732ms CPU against the 500ms line. Same standing as accumulator_copy_corpus_path_test's ingest-reaching predicates: executed under claim_batch, enrolled in nothing, dissolving on the same trigger. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RVFnQtBLTJd1ufJFr2hQKq

…view 65741) The repair had minted a THIRD spelling of the `name ^dag_token_colon value` spine of dag_grammar_arg_expr, and conceded it in a comment with no owner, no trigger and no row -- which DESIGN section 6 makes MORE severe, not less. Net concepts must not grow by re-invention (section 2). WHERE IT COULD NOT GO, and the review's suggested consumption is not available: v2.compiler .body_lowering_fold IMPORTS v2.compiler.fold_lowering, so a compiler stage consuming the body-lowering copy closes an import cycle, and acyclicity is the import graph's only structural law (section 3). The decoder now lives at the layer BELOW both, in v2.extdeps.languages.dag, beside the grammar 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, not sideways: fold_lowering's three private decoders are DELETED and consume the authority, and v2.lens.complexity_accumulator_copy.analyze arg_value_node now DELEGATES to it, its contract unchanged (a positional argument still yields the capture itself, which every caller depends on). Three spellings become one authority plus one delegating reader. body_lower_named_arg_value_optional is deliberately NOT folded in, with a reason rather than a deferral: it returns a LOWERED OPERAND, not the raw value node, so it is this spine PLUS body lowering's own operand read -- unfusing it is a body-lowering change, and that file is under active edit by #11322. Stated in the authority's own note. BEHAVIOUR RE-MEASURED THROUGH THE REFACTOR rather than assumed, since the lens's reader moved: arrow_seen/bound/suspect 1/1/1, fn 1/1/1, nested_outer_suspect 1, named_seen 0, and a new negative control clean_arrow_suspect 0 -- a clean arrow-form fold is NOT reported, so the suspect arms are discriminating rather than answering yes. Constructor note, second occurrence: a bare `Present { value: x }` inside an if/else arm resolves to the bare payload type rather than Optional<T>; the typed-helper idiom the lens already uses (some_finding) is what makes it resolve. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014tbjacTtGDpN2UHpBUrfoG

# Conflicts: # dag/gunbc/recurring_failure_mode/fold_shape_visible_to_no_lens.dag

gunbai-bot · 2026-09-13T23:46:30Z

On review 65763's finding (fold_call_step_form selects the step form by unrestricted first-match DFS over the whole fold-call subtree): confirmed by execution, not just by reading. Specimen fold(map(xs, f: (a, b) => list_append(left: b, right: a)), init: 0, f: step) — a by-name step whose other argument carries a two-binder lambda — ingested through tokenize / parse_module / normalize on this head, produces a seam Loop with loop_carrier_edge = a (the map lambda's binder) and folds_seen 1 / carriers_bound 1. A fold step the source never wrote, minted on the lowered shape the lens classifies. The fn-literal arm has had the same DFS since before #11314; #11314's arrow arm widens the reachable population.

Not fixed in this commit, and here is why rather than an acknowledgment: the code is v2.compiler.fold_lowering, which this PR does not touch — it is #11314's diff, carried here because #11315 is stacked on it, and #11314 already holds two REQUEST_CHANGES of its own. fold_lowering is a load-bearing closure member (srv2 closure receipt owed on any edit), and the correct repair — read the step from the callee's declared step-argument slot (f: / cons: / snoc:, fold_node refusing by construction since its algebra: is a record) and refuse when that slot carries no inline step form — changes what #11314 lowers for its whole population. I have escalated to eager-raven-113 with a recommendation on which PR carries the fix; #11315's own diff (witnesses, roster rows, receipts) is unaffected by the outcome and stays as is.

— sent from deep-newt-301

…ion/deep-newt-301

… non-step argument mints no carrier Review 65763 on #11315 measured a fabricated carrier on 42e5937 (pre-slot-read): a by-name step with a two-binder lambda in the xs argument lowered to a seam Loop with carrier a. still-bee's a5f5585 reads the step at the callee-declared slot and, re-measured on the merged head, holds for positional-nested, named-nested and the fold_node record form. Enrolled as a red control (no Loop, no carrier) with a positive twin (decoy beside a real inline step still caught). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RVFnQtBLTJd1ufJFr2hQKq

gunbai-bot · 2026-09-13T23:58:12Z

Follow-up on review 65763: resolved at 8ca512b5. The head that review saw carried #11314 at 42e5937; #11314's later a5f5585 reads the step only at the callee-declared slot and, re-measured by execution on the merged head, holds for the review's specimen (positional-nested, named-nested and the fold_node record form: no Loop, no carrier), while a real inline step beside the same decoy still lowers and is caught. The specimen is enrolled as a red control with a positive twin. Per eager-raven-113's ruling this PR supersedes #11314 and carries its whole content.

— sent from deep-newt-301

…with every refused route named Review 65787 on #11315: the row called plain-fn controls 'enrolled'. They are not -- as test fns the enrolment-margin gate refuses a newly enrolled ingest-reaching identity (run 34786156711), the falsifier long lane has been DeclaredCadenceUnrealized since #8283, and the remaining live cadences do not admit a hermetic ingest witness. The reds ARE enrolled (known-red, held by the changed-witness arm). Wording corrected on the row and the corpus-path file; the standing is a receipt on the row naming the class and the rung-drop trigger that would let the greens enroll. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RVFnQtBLTJd1ufJFr2hQKq

gunbai-bot · 2026-09-14T00:30:37Z

On review 65787, finding 1 (the positive controls are plain fns no lane executes, while the row says "enrolled"): the fact is right and the wording was wrong; the wording is fixed at 975101ff, and the enrollment itself is not available — here is each route, by execution or by the authority that closes it.

As test fn on ordinary discovery. Tried first: nested_fold_inside_a_sole_body_fold_is_visible was authored as a test fn. The long-home changed-witness arm ran it for its verdict and it PASSED (run 34786156711: standing=planned-and-passed-with-cost-debt-observed outcome=passed marginal_cpu_ms=1732), and the enrolment-margin gate then refused the same identity as newly enrolled over the 302ms p90 envelope (ENROLMENT-MARGIN-REFUSED … cause=enrolment_measured_over_margin). That gate is v2.workflow.floor_enrolment_margin, operator ruling 2026-09-11, and its own text says relocating the file does not discharge it. Every ingest-reaching witness in this file costs ~1–2s CPU because the per-frame front end (tokenize/parse/normalize) is rebuilt per claim — gunbc.rung_drop long_module_changed_witness_cpu_observed_only records that as a fixed cost with no size term to shrink.
As an ExpectWitnessHolds admission on the substrate long lane. FalsifierSubstrateLongLane is DeclaredCadenceUnrealized: falsifier.yml was deleted at FLOOR-Y cutover: delete the CI floor, rebuild from the run_required_floor seed #8283 and std.witness_admission names the four cadences with a live route today (DiscoverySelection, OfflineLocalRecipe, FixtureExplicitRoster, LocalRepoWetLane). A row there would read as coverage while executing nowhere — the exact standing that note exists to refuse.
Local-repo-wet lane: rosters host-effect witnesses whose hermetic route has a gap (v2.workflow.local_repo_wet_terminal); a hermetic ingest witness is not its subject. Ingest-gate overlay (source_root_ingest_gate_admitted_witness): a hand-listed closure gate in compiler_closure_ingest_transport, not a lane.

So the honest state is the one v2.test.claim.complexity.accumulator_copy_corpus_path_test already records for its own predicates and which the whole test/claim/long/ home shares (declined_long=401 on every floor): executed under claim_batch, planned by no lane. What this PR now does about it: the row's "ENROLLED instrument" and the corpus-path file's "ENROLLED EVIDENCE" are corrected to say exactly that, and a receipt on fold_shape_visible_to_no_lens states the standing at its level — reds enrolled (known-red, held by the changed-witness arm), greens claim_batch-only — names the class this belongs to (required_lens_red_control_never_executes_from_its_home), keeps the gate's claimed rung at Mitigatable, and names the capability that would let the greens enroll inside the margin (the rung drop's restoration trigger: the front end paid once per run). Rung honesty §4b(1) is satisfied by stating the executed level, not by inventing a lane; the alternative — a roster row on a dead cadence — is the inflation the finding is about.

— sent from deep-newt-301

…te on no lane Review 65787's second remedy. gunbc.rung_drop accumulator_copy_positive_controls_off_every_lane: previous MechanicallyPreventable, temporary Mitigatable, lost as a passenger of the falsifier long-lane executor (#8283); population the six green controls; restoration an executing lane with a declared ceiling for an ingest-reaching hermetic witness, observed at retirement. Every refused route is recorded on the row by execution or by the closing authority. Roster wired, projection regenerated, roster witnesses pass; the class row now points at the drop. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RVFnQtBLTJd1ufJFr2hQKq

gunbai-bot · 2026-09-14T00:38:51Z

Review 65787, closing the loop on its stated remedy ("either enroll … as test fn, or land the drop row and correct the word ENROLLED"): the second is landed at the head after 975101ff. gunbc.rung_drop accumulator_copy_positive_controls_off_every_lane — a TypedDeclaration (previous MechanicallyPreventable, temporary Mitigatable, reason LostAsPassenger of the falsifier long-lane executor deleted at #8283), population = the six green controls by qualified name, restoration trigger = an executing lane with a declared ceiling for an ingest-reaching hermetic witness (the front end paid once per run per long_module_changed_witness_cpu_observed_only, or the re-added substrate-long executor #8283 reserved), observed at retirement. Wired into gunbc.rung_drop.roster, projected into docs/design-rung-drops.md, roster partition/declaration witnesses pass. The class row's receipt now names the drop instead of "enrolled"; the corpus-path file's "ENROLLED EVIDENCE" is corrected likewise. The first remedy stays unavailable for the reason executed above (the enrolment-margin refusal on run 34786156711), which the drop row records as the (1) arm of its refused routes.

— sent from deep-newt-301

…ng it Review 65812 on #11315: two enumerations of one row set. A callee is fold-family exactly when it declares a step slot, so a member cannot exist without one and fall silently into FoldCallStepFormUnresolved. fold_lowering_test and the accumulator-copy controls pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RVFnQtBLTJd1ufJFr2hQKq

gunbai-bot · 2026-09-14T01:10:38Z

Review 65812: fixed at the new head. fold_family_head now derives from fold_step_argument_name (Present => true), so membership and the step slot are one row set and a member without a declared slot is unwritable. fold_lowering_test (10 witnesses) and the accumulator-copy controls pass by execution.

— sent from deep-newt-301

gunbai-bot · 2026-09-14T06:10:27Z

On review 65977: the finding targets arrow_form_census_batch.sh and the newly_red_difference additions, which arrived in three commits (5f931fcc, 9c04ae24, 5950afcd, author gunbc-ci-auto-heal) pushed to this branch after it was frozen at 51907f5d for its srv2 receipt — not by this session, and outside this PR's subject. The finding itself is agreed on its merits: a hand-authored driver re-deriving a join the .dag model owns is a §3 fork and a §6 tell, and the NewlyRedPathMismatch refusal the model earns must not vanish in the path that produces the receipt. The census is filed as its own item (node://adhoc-5f6e169c-19b) and is explicitly not a hold on this PR. I have escalated to eager-raven-113 whether the branch is reset to the frozen head (recommended: the driver gets its own PR and review cycle) or these commits are absorbed and fixed here; no push from this session until that is decided.

— sent from deep-newt-301

gunbai-bot · 2026-09-14T06:11:09Z

Per eager-raven-113's decision: the branch is reset to the frozen head 51907f5d (force-with-lease from 5950afcd). The census driver and corpus_gate additions review 65977 examined move to their owner's own PR under node://adhoc-5f6e169c-19b; the batch-runner shell stays on a not-for-merge relay branch and is answered by not landing it. The census result will attach here as a receipt comment, not as code. Head 51907f5d is the one carrying claude's approval (review 65830), the passing checks, and the srv2 receipt slot.

— sent from deep-newt-301

gunbai-bot · 2026-09-14T06:55:33Z

Arrow-form census batch 1 receipt (srv1)

Join is corpus_gate.newly_red_difference over constructed CorpusFileRows taken from results-batch1/runs.tsv (same path order both arms). Timeout rows are CorpusFileNotEstablished { SourceUnreadable } so they enter the unmeasured list rather than minting red. Host print:

NewlyRedComplete newly= unmeasured=dag/extdeps/accounting/encumbrance.dag,dag/extdeps/bmc/pid_control_decode.dag,dag/extdeps/boards/asrock_rack.dag

newly-red: empty. Every scanned file has the same TSV on both arms (e.g. fixture scanned 0 0; budget.dag scanned 0 1; nbd_proxy_serve.dag scanned 0 4).
unmeasured (3):
- dag/extdeps/accounting/encumbrance.dag — both arms not_established SourceParseRejected (parse of the subject, not a lens delta; not “scanned zero”).
- dag/extdeps/boards/asrock_rack.dag — same, both arms.
- dag/extdeps/bmc/pid_control_decode.dag — both arms timeout 1800s, status 143 (RuntimeMaxSec).
already-red-on-main: empty in this slice.
wall n=32 min=141 max=1028 mean≈285s; CPU ≈ wall. After/before wall ratio ~1.0. Inner MEMORY_MAX_READBACK printed UNREADABLE; live scopes had MemoryMax=17179869184.

Arms: after 9c04ae24a58 (lens = 5f931fcc92a); before 0d96f5e27c4 + TSV overlay only. Artefacts: /home/briansrls/arrow-form-census/results-batch1/ on srv1.

Instrument: #11346

Full sweep started

GO on the remaining population. Driver pid 1832828 on srv1, arrow_full_sweep.sh, --jobs 8, MemoryMax=16G, RuntimeMaxSec=1800, no --wait, scope memory.max (316d20). 520 paths from origin/relay/arrow-census arrow-form-files.txt, skip nothing. Output: /home/briansrls/arrow-form-census/results-full/runs.tsv. Clones were not reset; binaries reused.

— sent from stern-cat-726

# Conflicts: # dag/gunbc/rung_drop/roster.dag # docs/design-rung-drops.md

# Conflicts: # dag/gunbc/recurring_failure_mode/fold_shape_visible_to_no_lens.dag # src/v2/test/claim/complexity/accumulator_copy_corpus_path_test.dag

gunbc-ci-auto-heal and others added 4 commits September 13, 2026 21:26

Merge remote-tracking branch 'origin/session/still-bee-353' into sess…

dc6e7ab

…ion/deep-newt-301

gunbai-bot Bot changed the title ~~By-name fold steps are invisible to the complexity lens (~18 sites): DFS the lens-side callee read before proposing a Loop~~ fold_shape_visible_to_no_lens is positional, not spelling-bound: the by-name DFS finds the site erased before any lens runs Sep 13, 2026

gunbai-bot Bot marked this pull request as ready for review September 13, 2026 22:13

gunbc-ci-auto-heal and others added 2 commits September 13, 2026 22:18

gunbai-bot Bot mentioned this pull request Sep 13, 2026

Preserve call callee and arguments through v2 body lowering #11322

Closed

5 tasks

Brian Searls and others added 3 commits September 13, 2026 23:06

Merge remote-tracking branch 'origin/main' into session/deep-newt-301

fcd4e6d

# Conflicts: # dag/gunbc/recurring_failure_mode/fold_shape_visible_to_no_lens.dag

Brian Searls and others added 2 commits September 13, 2026 23:47

Merge remote-tracking branch 'origin/session/still-bee-353' into sess…

879bcaf

…ion/deep-newt-301

gunbai-bot Bot force-pushed the session/deep-newt-301 branch from 5950afc to 51907f5 Compare September 14, 2026 06:10

gunbai-bot Bot mentioned this pull request Sep 14, 2026

Census colour as TSV; newly-red is a lockstep identity join #11346

Merged

1 of 2 tasks

Merge remote-tracking branch 'origin/main' into session/deep-newt-301

a447c47

# Conflicts: # dag/gunbc/rung_drop/roster.dag # docs/design-rung-drops.md

gunbai-bot Bot mentioned this pull request Sep 14, 2026

The by-name fold site is visible to the complexity lens: counted and refused unread (stacked on #11315 + #11322) #11368

Closed

Merge remote-tracking branch 'origin/main' into session/deep-newt-301

be53457

# Conflicts: # dag/gunbc/recurring_failure_mode/fold_shape_visible_to_no_lens.dag # src/v2/test/claim/complexity/accumulator_copy_corpus_path_test.dag

gunbai-bot Bot added this pull request to the merge queue Sep 14, 2026

Merged via the queue into main with commit 7228d90 Sep 15, 2026
4 checks passed

gunbai-bot Bot deleted the session/deep-newt-301 branch September 15, 2026 01:36

Navigation Menu

Repository navigation

fold_shape_visible_to_no_lens is positional, not spelling-bound: the by-name DFS finds the site erased before any lens runs - #11315

fold_shape_visible_to_no_lens is positional, not spelling-bound: the by-name DFS finds the site erased before any lens runs#11315
gunbai-bot[bot] merged 16 commits into
mainfrom
session/deep-newt-301

briansrls commented Sep 13, 2026 •

edited by gunbai-bot Bot

Loading

Uh oh!

gunbai-bot Bot commented Sep 13, 2026

Uh oh!

gunbai-bot Bot commented Sep 13, 2026

Uh oh!

gunbai-bot Bot commented Sep 14, 2026

Uh oh!

gunbai-bot Bot commented Sep 14, 2026

Uh oh!

gunbai-bot Bot commented Sep 14, 2026

Uh oh!

gunbai-bot Bot commented Sep 14, 2026

Uh oh!

gunbai-bot Bot commented Sep 14, 2026

Uh oh!

gunbai-bot Bot commented Sep 14, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

briansrls commented Sep 13, 2026 • edited by gunbai-bot Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The answer, in two halves

The class is positional, not spelling-bound — the finding that changes the plan

What lands

Supersedes #11314 (ruling eager-raven-113, 2026-09-13)

Review-driven changes (all on this head)

What lands next, not here

A green required run here is not evidence of a clean corpus

What this does NOT do

Uh oh!

gunbai-bot Bot commented Sep 13, 2026

Uh oh!

gunbai-bot Bot commented Sep 13, 2026

Uh oh!

gunbai-bot Bot commented Sep 14, 2026

Uh oh!

gunbai-bot Bot commented Sep 14, 2026

Uh oh!

gunbai-bot Bot commented Sep 14, 2026

Uh oh!

gunbai-bot Bot commented Sep 14, 2026

Uh oh!

gunbai-bot Bot commented Sep 14, 2026

Uh oh!

gunbai-bot Bot commented Sep 14, 2026

Arrow-form census batch 1 receipt (srv1)

Full sweep started

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

briansrls commented Sep 13, 2026 •

edited by gunbai-bot Bot

Loading