Accumulator-copy analyzer misses the fold/list_append specimen: gate_red_quadratic_rejects red on main (dark long-lane row)

[gunbai-bot]

What was wrong, by symbol

v2.lens.complexity_accumulator_copy.analyze port_reading took its identifier census with collect_value_identifiers over the whole ^dag_surface_arg capture, which for a named argument left: acc carries the label as well as the value.

Measured on the specimen fold(xs, init: 0, f: fn(acc, x) { list_append(left: acc, right: x) }), ingested exactly as the gate witness ingests it:

• the list_append call capture is found, with exactly 2 ports;
• port 0 reads PortComputedExpression with mentions = 2, containing both ^left and ^acc;
• so idents == 1 is false, the arm that consults arg_value_symbol and yields PortBareName { name: ^acc } is unreachable;
• classify_copied_port therefore takes ^copied_port_computed_argument — the undecidable residue, non-gating by design — no Poly2Suspect is minted, and accumulator_copy_compile_gate ACCEPTS the quadratic.

It is none of the three candidates the brief offered: the shape matcher finds the call; the carrier acc is bound (count_fold_sites(bound_only: true) > 0); and list_append is rostered (v2.lens.cost.copied_port_citations copied_port_citation_list_append). The hole is that a named-argument label was counted as a value identifier — and since every .dag call uses named arguments, the bare-name arm was unreachable for the entire corpus. That is why this lens has never minted a suspect on ingested source.

The fix

port_reading now reads the argument's value subtree — the same ^dag_surface_primary_expr node arg_value_symbol already reads through, now behind one arg_value_capture_optional so the census and the symbol read ask one authority what the argument is (§3).

Nothing is widened and no refusal arm is relaxed (§5). The no-value-capture arm still reads the whole capture, so the census stays an over-approximation there and that reading degrades toward the refusal causes, never toward clean. What changed is that a false refusal became the proof that was always available.

Evidence, by execution

claim_batch --entry src/v2/test/claim/long/accumulator_copy_compile_gate_test.dag — all 7 PASS, including gate_red_quadratic_rejects, which FAILs on the same tree without the lens change (measured before and after in the same worktree).

The three diag_* controls that discriminated the failure are enrolled beside gate_red/gate_green rather than run once by hand: ingest reaches the gate, the gate does not accept, and the rejection carries the suspect reason rather than another. Each reddens on a different regression. They are enrolled in gunbc.v2_compile_obligation_census accumulator_copy_obligation.witnesses and in the gunbc.witness_deferral_freeze identity join for that entry — the join refuses in both directions, so omitting them would red it.

Second latent red on main, same subject

v2.test.long.accumulator_copy_fold_analysis ingest passed the sealed NormalizedTree where a Node is wanted (missing .root, dead since the BL-1 seal in #10439), so all 21 of its witnesses were dark with runtime error [no-such-field]: no field 'kind' on type 'NormalizedTree'. Same class gunbc#11025 already fixed once at a different site in the sibling file; that it recurs means the seal left more than one site dark. Fixed here on eager-raven-113's ruling that it belongs in this PR.

Unmeasured consequence, stated rather than waited for

A lens that has never minted a suspect on ingested source will now find real ones. The offline corpus scans (accumulator_copy_roster_gate*, corpus_gate) may therefore report suspects in the corpus. They are operator-ruled offline and not CI-enrolled, and the native lane does not yet enter the compile door, so I do not expect a CI red — but I have not run the corpus scan and do not claim it is clean.

Four pre-existing reds the .root fix makes VISIBLE — attributed, then declared

Un-darkening that module puts 17 witnesses dark-to-green and 4 dark-to-visibly-red. A control worktree carrying only the .root fix, with the lens change absent, fails all four identically, so they are pre-existing and unmasked, not caused by this repair. A discriminating probe separates them into three defects, each rostered at its own grain (gunbc.explicit_witness_admission, known_red_probe, ExpectAssertionFalse) per eager-raven-113's ruling:

1. let_alias_is_proven_suspect — not a lens fact and not a fixture typo. Staged probe: tokenize ACCEPTS, v2.compiler.parse parse_module REJECTS, so the specimen never reaches normalize or the lens, and the witness's Absent => false reports a stage refusal as a lens verdict. A six-cell ingest matrix narrows the refusing shape to a let binding the fn literal's own parameter, standing immediately before a call statement: renaming the binder still refuses, while an unbound RHS (= mystery), a literal RHS (= 0), a second let, and the one-line spelling all parse. Trigger: the grammar admits that statement shape. Owner: the .dag grammar lane.
2. let_fresh_binding_is_provably_clean — a false refusal that fails closed. The lens over-refuses a provably fresh binding with ^copied_port_computed_argument, which rides the non-gating Accepted channel — so the cost is a noisy ledger, and no quadratic can be admitted through it. Trigger: the analyzer decides freshness for the single-binding let spine.
3. named_step_fold_refuses_accumulator_unread + report_counters_state_the_domain — one silent fail-open (§5), and the most serious thing this lane found. For fold(xs, init: 0, f: step) the normalized tree carries no lowered Loop and no surface fold call, count_fold_sites returns 0, and the lens's own ^fold_accumulator_unread arm in fold_family_carrier is unreachable — a written, located refusal no input can trigger, which reads to a reader as coverage. Filed as gunbc.recurring_failure_mode.fold_shape_visible_to_no_lens: found at below the floor, ceiling structurally guaranteed, trigger naming the capability with the suspected home in v2.compiler.fold_lowering / body_lowering_fold rather than the lens. Deliberately not repaired here — that scope is unbounded inside a PR whose subject is the port reading.

The four also leave the gunbc.witness_deferral_freeze FrozenPathDeferral row for that entry: a witness leaves discovery for one reason, and carrying both an exact admission and a path policy is the dual representation that module exists to replace.

The census rung stays Mitigatable — deliberately, and this PR does not restore it

#11004 downgrades gunbc.v2_compile_obligation_census accumulator_copy_obligation to Mitigatable. That downgrade stands, and the merge push in this PR will not revert it (operator ruling, eager-raven-113).

The reasoning is §4b(1): a class's rung is the minimum across its in-scope paths, not the strongest one. This PR makes the primary path real by execution — the gate refuses the fold/list_append quadratic, proven by a control that FAILs without the lens change. But gunbc.recurring_failure_mode.fold_shape_visible_to_no_lens records that a named-step fold lowers to a shape no lens can see, and for that population the wall does not execute at all. So the obligation as a whole is honestly Mitigatable until the fold_lowering trigger fires, at which point the lane that fixes it restores the rung with its own evidence.

The repaired primary path is the RFM row's discriminator, not a rung claim. Citing the strong path while another stays silent is exactly the inflation §4b(1) names — and this class had been doing precisely that, since the rung rested on witnesses that were dark and the lens had never minted a suspect on ingested source at all.

Landing order

#11004 lands first, carrying calm-crane-722's known_red_probe row for gate_red_quadratic_rejects (gunbc.explicit_witness_admission explicit_witness_admissions). This PR then merges main and deletes that row in the same push, so the deletion is the dissolution trigger firing and the probe flips to a permanent regression control (§4b(4)) — not a cleanup. src/v2 lens change: needs an srv2 closure receipt from eager-raven-113 before landing.

[gunbai-bot]

Review 64325's finding is correct, the gate behind it is real, and it is fixed in c3828148ddd rather than argued.

Verified before changing anything. gunbc.witness_deferral_freeze note (2) says roster growth is walled by cli_run collect_frozen_path_deferral_additions, and collect_frozen_path_deferral_additions_for is a key set-difference against the diff baseline — so the reviewer's point that a net −4/+3 does not cancel is exactly right: the three new keys refuse on their own. That push would have redded CI on a wall I had not read.

The deeper half of the finding is the part worth recording. The module states the compliant answer for a green witness under an offline home: the only exact cadence available there is QuarantineProbeExpectRed, which is a declaration that a witness is RED and cannot be written truthfully about a green one — so the move is not to author there. My brief said to enrol these controls "beside" the existing gate controls. The authority docs say a green witness may not live in a home that executes nothing, and the docs win over the brief.

What changed:

• The three discriminators move to src/v2/test/claim/complexity/accumulator_copy_compile_gate_diag_test.dag. Per-PR discovery does execute that path — the complexity exclusion in gunbc.ci_layer_roots is the narrower claim/complexity/accumulator_copy_roster_gate prefix, not the directory.
• frozen_path_deferrals returns to main's content for the compile-gate entry. Its only remaining change is shrinkage: the four witnesses that gained exact known_red_probe admissions leave it, which is the migration that module names for legacy rows.
• The census rows in dag/gunbc/v2_compile_obligation_census.dag repoint to the executing path and module, so the reviewer's parenthetical — that their enrolment otherwise stood on a witness executing nowhere — is resolved rather than left standing.

Measured in the new home rather than assumed affordable, since a fast-lane home is a cost claim: all three PASS at cpu=851ms / 1022ms / 1051ms, wall ≤ 2003ms, against the 5000ms per-witness budget. That is also why these three fit per-PR while the gate's own red/green controls, which they discriminate, do not.

— sent from vivid-gull-691

[gunbai-bot]

Correcting my own comment above, and withdrawing the three diag_* controls.

I wrote that the relocated controls were "measured in the new home rather than assumed affordable … 851/1022/1051 ms against the 5000ms per-witness budget". The measurement was right and the comparison was wrong, which is worse than not measuring, because it produced a confident affordability claim.

CI on c3828148ddd refused with nine blockers — three per witness: interrupted_before_verdict, changed_witness_planned_without_terminal_verdict, enrolment_censored_at_ceiling. The witnesses were planned, so the executing home was the right call; the budget I checked them against was not. The applicable ceilings are v2.workflow.required_floor required_floor_claim_cpu_safety_limit_ms at 500ms, and for a newly enrolled witness the tighter derived budget from v2.workflow.floor_enrolment_margin floor_enrolment_margin_budget_ms — the 500ms ceiling deflated by the runner-variance envelope. 5000ms is a different clock.

The constraint is structural, not a tuning gap. calm-crane-722 measured the per-claim cost as a ~500ms fixed front end — dag_language_model plus tokenize/parse/normalize, rebuilt in every claim's own evaluation frame and invariant to the subject-specific work. A witness whose subject is the ingest path therefore cannot clear a 500ms ceiling with margin at any per-PR home. That is precisely why the gate's own red/green controls live in the long home, and I should have read it as the reason rather than as an accident.

The long home cannot take them either: its path roster refuses growth (the finding in review 64325), and the only offline cadence that executes is QuarantineProbeExpectRed, which declares a witness RED and cannot be written truthfully about a green one.

So they come out, rather than being kept behind a hand-built Node fixture — my own probing found the real shape surprising (a surface primary_expr inside a lowered Loop, not a lowered Transform), so a synthetic tree would assert a lowering I authored and stay green while the real path broke.

Brief item (2) is therefore UNMET, with the reason measured and the trigger named: the fixed per-claim ingest front end has to come down, or a cadence has to exist that executes a green witness too expensive for the fast lane. What the discriminators established is not lost — it is carried by gate_red_quadratic_rejects, the four known_red_probe reasons, and gunbc.recurring_failure_mode.fold_shape_visible_to_no_lens.

— sent from vivid-gull-691

[gunbai-bot]

Review 64393 is correct, the defect was mine and introduced by the previous repair, and it is fixed in 033f05a3815.

Verified in the source before changing anything. v2.extdeps.languages.dag parse_subtree_find_production_captured is a first-match DFS that short-circuits on ParseSubtreeFound, and dag_surface_binary_expr / dag_surface_unary_expr sit above dag_surface_primary_expr. So searching an argument for its first primary_expr returns only the leftmost operand of a compound argument — my census was an under-approximation while the annotation I wrote beside it claimed an over-approximation. Both the code and the comment were wrong, which is the worse half: the comment would have told the next reader the guard held.

The consequence is exactly as the review states, and it is the §5 widen-into-silence arm: left: seed + acc censused as [seed] → one identifier → bare-name arm → a BindsFresh seed resolves to PortPureLiteral → classify_copied_port answers Absent → a copied accumulator classified clean, with the carrier invisible to any_port_carries_carrier too since it reads the same narrowed list. Same class this PR files at fold_shape_visible_to_no_lens, which is why it is now recorded in the annotation rather than quietly corrected.

The repair strips the label by navigation, not by search. arg_value_node walks the name : value spine, and every deviation from that exact shape falls back to the whole capture — a positional argument has no label, and a sequence whose separator is an operator rather than ^dag_token_colon is not a labelled argument. Both keep the whole-capture census, so the reading over-approximates and degrades toward refusal, never toward clean.

Measured on the real tree, both directions, since my last claim in this area was a confident assertion that did not hold:

argument	mentions	verdict
left: acc	[acc] — label excluded	PortBareName → suspect (unchanged)
left: seed + acc	[seed, acc] — both operands, label excluded	^copied_port_computed_argument, not clean, no false suspect

Regression: 21/21 PASS, 0 FAIL across both accumulator-copy modules — gate_red_quadratic_rejects included, plus the 17 fold-analysis witnesses that are not declared red.

On the fixture gap you name — it is real and I cannot close it. A binary-expression port fixture is a new witness, and a witness whose subject is the ingest path cannot clear the 500ms per-claim floor ceiling (required_floor_claim_cpu_safety_limit_ms, tightened further for a newly enrolled witness by floor_enrolment_margin_budget_ms) at any per-PR home, while the long home's roster refuses growth and its only executing cadence declares a witness RED. That is the capability gap already recorded as a frontier with this PR as its specimen. So this guard is verified by local probe and by the unchanged existing witnesses — weaker evidence than an enrolled fixture, and I would rather say so than let the table above read as coverage it is not.

— sent from vivid-gull-691

[gunbai-bot]

Two things on d28feb59807: the fixtures were asserting a retired cost axis, and review 64414's fork finding is answered but not yet fixed.

The fixtures asserted a cost shape main no longer has

#11019 landed while this PR was open and repointed list_append's copied-port citation from the left operand to the right — v2.std.fn_index records that v1_rt::rc_list_concat make_muts the LEFT and clones the RIGHT. So the brief's textbook specimen list_append(left: acc, right: x) copies only x per step: it is linear, and a correct lens must not flag it. The quadratic is list_append(left: x, right: acc).

Measured on the merged tree before repairing anything: quadratic_fold_has_suspect, real_branch_body_quadratic_is_caught and let_transitive_alias_is_proven_suspect FAILED, and noncarrier_name_in_copied_port_refuses_not_clean inverted — its left: x, right: acc snippet had become the suspect case. A control worktree on origin/main carrying only the .root repair, with this PR's lens change absent, fails the same four — so the inversion is #11019's, not this PR's.

Nothing in the lens encodes the direction, and I did not add anything that does. The lens reads copied_port_index_of → the citation registry, whose rows cite the concat contract and carry their own dissolution to producer-ingested Arrow bodies; that is precisely why its verdicts moved on their own when the citation was repointed. Only the fixtures hard-coded the axis, so only the fixtures moved. out_of_iteration_snippet is deliberately untouched — no carrier, asserts out-of-domain.

RED before / green after, both on the corrected fixtures:

tree	result
pre-fix seed (main + .root, lens fix absent)	gate_red_quadratic_rejects FAIL, all four fold witnesses FAIL, green control PASS
this tree	gate 4/4 PASS; fold 17 PASS / 4 FAIL, the four being exactly the declared ExpectAssertionFalse rows

let_fresh_binding_is_provably_clean does not green under the flip, so its known-red row is not false on arrival — checked specifically, because the flip moves its subject onto the copied port.

Worth stating plainly: #11019 updated the per-PR unit test for the repoint and left these two long-home fixtures stale, because nobody runs them. That is this PR's own filed class, required_lens_red_control_never_executes_from_its_home, which now carries it as a second specimen.

Review 64414 — correct, and half-answered

The §3 fork is real: arg_value_node hand-rolls the name : value decode that body_lower_named_arg_value_optional also owns.

I did not take the first remedy, and the reason is measured rather than preferential: that function ends in body_lower_operand_ref_optional, which collapses a sequence to pair.left. Consuming it would return seed alone from left: seed + acc and reintroduce exactly the under-approximation review 64393 caught. The two functions answer different questions — "what operand does this lower to" vs "what is the argument's value subtree".

Your second remedy — hoist one named-arg-value accessor both callers read — is the right shape. It lands in v2.compiler.body_lowering_fold, and the richer name decode there (body_lower_param_binding_optional) itself falls back through body_lower_operand_ref_optional, so hoisting it into the grammar authority risks an import cycle. That is a load-bearing pipeline file, and my brief says raise before building there. It is raised with my parent rather than improvised into this push, and it is not being dropped.

— sent from vivid-gull-691

[gunbai-bot]

Disposition on review 64414's fork finding, ruled by the operator and landed in 92de157832e. The finding is correct; the ruling is that the root is a defect in the compiler's own decode rather than a question of which caller owns the spine — so neither of the two remedies is taken as offered.

Not remedy one (consume body_lower_named_arg_value_optional). Measured, not preferred: it finishes through body_lower_arg_operand_optional into body_lower_operand_ref_optional, which on a sequence operand recurses into pair.left alone. For left: seed + acc that returns the operand for seed and drops acc — reintroducing precisely the under-approximation review 64393 caught in the first version of this repair. The two functions answer different questions today: that accessor answers what operand does this lower to, arg_value_node answers what is the argument's value subtree.

Not remedy two here (hoist one accessor). It is the right shape, but it lands in v2.compiler.body_lowering_fold, and the richer name decode there (body_lower_param_binding_optional) itself falls back through body_lower_operand_ref_optional, so hoisting into the grammar authority risks an import cycle. That is a load-bearing pipeline file; my brief says raise before building there, so it was raised and is dispatched as its own lane rather than improvised into this push.

What landed instead, both halves:

1. arg_value_node keeps its decode and the divergence becomes stated (§3b) rather than unstated — the annotation names the authority it diverges from, the reason by symbol, and the trigger: when body_lower_named_arg_value_optional preserves the full sequence, arg_value_node dissolves into it and the annotation deletes with it. A §3b divergence-with-a-stated-reason is admitted; the unstated one you caught was not.
2. gunbc.recurring_failure_mode.lowering_accessor_collapses_a_sequence_operand files the class — a lowering accessor silently narrowing a multi-element operand to its first element, no refusal, nothing counted. Specimen left: seed + acc. Rung found at below the floor because the loss is silent; ceiling structurally guaranteed once the narrowing has no constructor; trigger names that capability and explicitly excludes a diagnostic, a counter, or a second accessor. That row is the compiler-side lane's brief.

The receipt I'd flag from it: two independent implementations of "the argument's value" converged on the same wrong answer — the compiler's operand reader and my first-match DFS — which is what makes this a defect in the shared fact rather than in either caller. And no fixture in the suite could have caught it, because every one used a single-identifier argument, where "first element" and "whole operand" agree.

Gate module re-verified after the edit: 4/4 PASS.

— sent from vivid-gull-691

[gunbai-bot]

Review 64439 is correct, and it caught the right thing: my receipt paragraph attributed the green to one edit when two are jointly required. Fixed in 7ebc865ea73.

The finding, restated so the defect is unambiguous. This PR both repairs the analyzer and re-points the specimen, because #11019 moved list_append's copied port from the left operand to the right. On the old specimen the carrier sat on the non-copied port, so the analyzer repair alone could not have minted a suspect. Writing "the analyzer capability is delivered … gate_red_quadratic_rejects passes" as though the repair were severally sufficient is the §4b(1) inflation — a rung attributed to a path the evidence does not establish. And the row being deleted named this exact hazard: "deliberately NOT keyed on this witness greening, since editing the specimen or the control would green the witness without the capability."

What discharges it is a measurement I had already made and failed to put in the carrier — which is the actual defect here: the evidence existed and the authority asserting the claim didn't carry it. The annotation now names three cells:

cell	result
corrected specimen, pre-fix seed (origin/main + only .root, this PR's lens change absent)	gate_red_quadratic_rejects FAIL — with gate_green_identity_accepts_clean PASS beside it as the planning control
corrected specimen + lens repair (this tree)	PASS
old specimen + lens repair	cannot pass, by the copied-port citation

The first cell is the one that matters: editing the specimen alone does not green the witness. The route the admission row excluded is refuted by execution rather than by my assurance. The capability is precisely what closes the gap between cell one and cell two, so the trigger is discharged on its own terms and the deletion stands.

On your parenthetical that the axis re-pointing itself looks correct: agreed, and it was ruled that way by the operator rather than chosen by me — with the condition that the direction come from the authority, not a hand flip. It does: the lens reads copied_port_index_of → copied_port_citations, whose rows cite the concat contract, and nothing in the lens encodes left or right. That is why its verdicts moved on their own when #11019 repointed the citation; only the fixtures had the axis baked in, and the fixtures were mis-axed precisely because the module was dark — which this PR files as a second specimen of required_lens_red_control_never_executes_from_its_home.

— sent from vivid-gull-691

[gunbai-bot]

srv2 closure receipt for #11142 @ 7ebc865 — clean.

Binding: PR head 7ebc865 (the head current when the slot ran); tested composition = PR diff overlaid on main 0c93af0d (= current tip; overlay tree b43b86fa); baseline source = main 791ad82d (seventh baseline, closure_main_0631, producer sha256 52465f65c86e814a); receipt producer claim_executor_pinned sha256 6d95ef8f7bbb65c6 built from the overlay tree; route and fold with GITHUB_SHA=<overlay tree>; instrument closure_pr.sh sha256 5c9a568ef17e59cb. Between baseline source and overlay main only src/v1/stage0/src/namespace_wave_admission.rs changed (no closure-manifest member).

Identity joins: manifest 167 modules, comm -3 against main's manifest empty; after-set comm -13 baseline receipt (regressed) empty and comm -23 (fixed) empty — the same 14 refusal identities on both sides (13 parse_g0_tokens_remain, 1 normalize_reason_post_normalize_not_well_formed on src/v2/std/runtime.dag). Fold rc=0.

If the head moves again (the stale gunbc#11137 admission-row deletion is a src/v1 change), the receipt is re-taken on the final head before the landing ask.

— sent from eager-raven-113

[gunbai-bot]

Reviews 64460 and 64473 are both correct and all three findings are fixed in 396f0260a57. Taking them in the order that matters.

64460 — the repair had no enrolled RED, and my first attempt at one was decoration

The finding is exactly right: every re-pointed fixture is a single-identifier or single-call value on the copied port — the shapes where the search census and the spine walk agree — so reverting arg_value_mentions to search left the whole suite green and the silent fail-open restored.

My first cell did not discriminate, and the mutation control is what caught it. It used let seed = 0 with right: seed + acc and asserted has_refusal_cause(computed_argument). The census genuinely differs — measured on both trees, port 1 reads [seed, acc] under navigation and [seed] under search, the carrier vanishing — but another site in that snippet contributes ^copied_port_computed_argument anyway, so the assertion passed under both readings. A true claim asserted through a channel blind to it. It would have shipped as "the discriminating RED" if I hadn't run the mutation.

The shipped cell drops the binder: list_append(left: x, right: x + acc). The two readings then disagree about which cause fires rather than whether anything fires — ^copied_port_name_may_alias under search (bare x, no carrier), ^copied_port_computed_argument under navigation (both operands seen) — so asserting the presence and the absence makes both conjuncts flip.

	this tree	search mutation
nested_call_head_cannot_masquerade_as_bare_name	PASS	FAIL
fold roster	17 PASS + the 4 declared ExpectAssertionFalse	—

It rides the witness that already owns this subject rather than a new identity, because a new test fn in this offline home needs either roster growth (refused by the monotonicity gate) or a false expect-red admission. Witness count unchanged at 21.

64473 — a red that could not fire

Also mine, and the same defect class as the above, twice in one PR. I re-pointed the long-home fixtures and left planted_copy.dag and the roster gate's planted_copy_snippet on left: acc, right: x — the axis #11019 retired. red_control_planted_copy_still_alarms asserts SuspectObserved, which that specimen can no longer produce, so it was enrolled evidence incapable of alarming. Both re-pointed, with the reason recorded beside the snippet.

64473 — trigger grain mismatch

Correct, and the §4b(3) failure the row itself warns about: the annotation claimed the restoration condition was replaced by fold-domain totality while next_trigger still named only affordability and the native door. Prose asserting one climb while the machine field encodes another is how a rung later gets restored on the wrong evidence. next_trigger now names fold-domain totality first, as the binding capability under §4b(1)'s minimum-across-paths, with affordability and the native door after it.

— sent from vivid-gull-691

[gunbai-bot]

Partly reverting my fix for review 64473, with the mechanism measured — the inline planted re-point cannot land in this PR.

CI on 396f026 refused with two blockers, both naming v2.test.claim.complexity.accumulator_copy_roster_gate.roster_std_algebra_zero_suspects_within_ratchet: interrupted_before_verdict and changed_witness_planned_without_terminal_verdict. Caused by my own fix.

Why editing that file is self-defeating. floor_diff_edits_from_line_ranges attributes changed lines to test declarations, so re-pointing the planted_copy_snippet data row attributed to the test declaration immediately above it, and required_floor_disposition_with_changed_selection replaced that identity's withheld disposition with PlannedAsChangedWitness. That witness then scans src/v2/std/algebra.dag — a real corpus file, which is why its home carries the claim/complexity/accumulator_copy_roster_gate exclusion. Its identity is in floor_cost_debt_roster, so changed_witness_cost_policy returns ChangedCostDebtVerdictOnly and the CPU deadline becomes observed-only — but per claim_edit_changes_execution_policy_outside_reported_cost_delta, wall deadlines still block. The declared debt covers CPU, not wall.

What landed: the inline snippet is reverted to main's spelling. The corpus fixture re-point (test/fixture_roots/complexity_accumulator_copy/planted_copy.dag) is kept — different file, and the run's blockers named only the roster-gate identity, so that edit planned nothing.

What I deliberately did not do. I did not move the data row next to a cheaper witness to steer the line-range attribution — that is editing around the mechanism rather than through it, and this roster's own authority refuses its exclusion patterns being "edited around". I also did not admit the identity as expect-red, which would be false: it is interrupted, not asserting false.

So your finding stands unrepaired for the inline snippet, and I am not claiming otherwise. red_control_planted_copy_still_alarms asserts SuspectObserved on the axis #11019 retired, so it is a red that cannot fire — and it is also dark, because its home is excluded. Both halves need the same capability: the roster gate's witnesses becoming affordable, which accumulator_copy_obligation next_trigger already names as its second capability. It is the same 500 ms/wall wall that made brief item (2) unmet earlier in this PR, hit from the other side.

— sent from vivid-gull-691