Pkg11b batch 2: five grammar rows with their lowering consumers, and parse-tree projection edges as a parser-owned closed roster

[gunbai-bot]

What this is

Pkg11b batch 2, rescued from an archived session. Two commits were pushed to session/loyal-bear-675 and no PR was ever opened for them; this opens the review surface. Authored by the Pkg11b lane (loyal-bear-675), filed by its manager after the lane closed — the body below is that lane's own report, kept in its own terms including the parts that do not favour the change.

• fd3475c5c81 — grammar rows in src/v2/extdeps/languages/dag.dag for: int literal as a generic argument, the module keyword as a value, anonymous record type expression, the admit_callers clause, and else-less if refused at lowering with its cause; plus the body_lowering_fold / compile_door_cause_ownership consumers and a declared rung drop admit_callers_discarded_on_the_native_route.
• 9d3dcd1f562 — parse-tree projection edges become a closed roster owned by the parser; namespace_graft consumes it instead of testing for a _node_projection name suffix. That suffix test was dissolving an authored declaration named *_node_projection in v2.std.runtime at the module body: one silently, two into an ill-formed Conj.

Evidence, and what it does NOT establish

src/v2/test/claim/parse/closure_parse_batch_two_test.dag, 12 claims, plus an in-session mutation control matrix (mutations B, C, D, E, A, W, F) in which each mutation reds exactly its own claim and nothing else.

The brief's done criterion is NOT met, and this PR does not claim it. The brief said the native parser refuses dag/std/content_hash.dag with parse_g0_tokens_remain. On a full lane run (claim_executor --v2-native-route --source-root dag --source-root src/v2, GITHUB_SHA set) the route never reaches parse — it refuses one stage earlier:

cause=EmittedCompilerBuildFailed, status=101
error[E0425]: cannot find type `UInt8` in this scope
  src/extdeps_numeric_base16.rs:115, :139 (x2), :173   -- four errors, one class

So the grammar half is done and controlled; the closure was never observed parsing natively, because no buildable native binary was produced. That is a specification-without-execution gap (DESIGN §5) and it is stated here rather than papered over.

The emitter defect this surfaced — not fixed here

dag/extdeps/numeric/base16.dag authors import std.integer { UInt8 }; the emitted module gets no use line for it, while its signatures still render UInt8. Closure edge extdeps.languages.json.emit -> extdeps.numeric.base16, long-standing. This branch has zero diff in dag/ or src/v1/, so it reads as a main / integration-branch defect that the native lane has not caught because the route is off the merge path (gunbc.rung_drop v2_native_route_off_the_merge_path).

Attribution is UNPROVEN and should be treated as such: a control emit+build at the integ base (b52c7b56528) was running to settle attribution by execution rather than by that reasoning, and did not finish before the lane closed.

Suspected mechanism, not proven by execution: the use line is dropped by an import filter in v1.compiler.emit_rust emit_specific_import_block — imported_name_is_non_emittable_type or import_name_resolves_to_host_realized_kernel_scalar — judging UInt8 non-emittable while the emitter renders UInt8 into base16 signatures anyway. One module contradicting itself. That contradiction is the terminal shape reference_derived_use_lines_note in that module already names: derive use lines from the emitted reference set rather than from source references. Whoever takes it should re-derive that slice rather than patch base16. It is staffed separately as Pkg13.

Landing order

#11998 is closed as superseded by #12033 (merry-lark-444 adopted both). After merging main, its only surviving delta was one citation line in the coproduct parse test, which now rides here.

Re-merge onto main (adopted by merry-lark-444)

I merged main at 44a910c. That merge commit's message lists, path by path, which side I kept and which main superseded:

• Union of both sides: the rung_drop roster, the grammar root in languages/dag.dag, the structure-preserved set in body_lowering_fold, and compile_door_cause_ownership.
• Main's version: the variant_fields_unlowered_on_the_native_route row and the fielded-type skip in namespace_graft. Both were superseded by Pkg11c: lower variant and record fields into declared field identities on the native route, and bind match-arm binders #12033.
• This branch's version: the projection-roster consumer (parse_tree_projection_edge).
• Untouched: XL-2 P1: call arguments survive v2 body lowering and reach the resolve denominator #12108's call-arg path and P4's resolve.

02ea6fd repairs two defects in that merge:

• Fused cause rows: the union joined two CauseOwnership records into one, giving it a duplicate cause field. That was the floor and emit-build red on 44a910c. They are two records again.
• Batch-two helpers: batch-two imported its text-taking helpers from the coproduct test, which main had changed to supplied token streams. The stream→parse→normalize route now lives once in v2.test.parse.supplied_token_stream_support (supplied_stream_parse / supplied_stream_normalize). Batch-two supplies a stream per specimen, produced by running the real tokenizer, and checks each one with a cb2_fidelity_* claim.

docs/design-rung-drops.md is regenerated by heal, not by hand.

Out-of-gate receipt: neat-boar-16 ran both files on srv2 at 02ea6fd. claim_batch was rebuilt from that tree and run in a MemoryMax=14G scope with a private TMPDIR. Result: 47/47 PASS, exit 0 — closure_parse_batch_two 23/23 (including cb2_fidelity_0..10), coproduct_leading_pipe_and_positional_payload_parse 24/24.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-22T05:09:32.406073Z	9d3dcd1	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[gunbai-bot]

Both findings from review 69969 addressed at cc56c58c746. Context a reviewer should have: this branch's authoring session archived before opening a PR, so I (its manager) opened #12050 to give the work a review surface and am now carrying it.

1. docs/design-rung-drops.md stale in both directions — fixed by merging main and deferring to heal, not by hand.

Confirmed exactly as reported: the branch adds variant_fields_unlowered_on_the_native_route and admit_callers_discarded_on_the_native_route to the roster, the projection gained neither, and its only edit reverted a standing drop's section against a pre-live-pair base. Net +1/-5 against +2 rows.

I did not regenerate locally. The generated-artifact merge driver refused this path on the merge (GeneratedArtifactConcurrentDivergence) precisely because both sides had moved since the merge base, and its declared repair route says to take the base side verbatim and let heal derive the projection from the merged authorities. That is what this commit does. Regenerating by hand here would have produced the "hand-authored projection the model should generate" that the finding cites (§6), one layer down.

Verified by set difference over row identities, not by count, that no row from either side went dark — using an extractor that names both row forms, since a failure mode is a `slug` bullet and a rung drop is a ### Title — declared … heading, and a single-form extractor reads zero rows on the file it cannot parse and reports a pass it never measured:

comm -23 <(git show origin/main:docs/design-rung-drops.md | rows) <(rows < docs/design-rung-drops.md)   # empty
comm -23 <(git show 9d3dcd1f562:docs/design-rung-drops.md | rows) <(rows < docs/design-rung-drops.md)   # empty

The two new rows are expected to arrive from heal, since they were never in the projection on either side. The gate must agree on the healed head — this is not green until it does.

2. Symbol unimported at closure_parse_batch_two_test.dag:846 — bound.

Correct, and worth stating why the green proved nothing: a .dag import list does not bind today. Resolution falls through to a global spelling search, so the name resolved with nothing importing it. That is rostered as shadowing_body_local_bypassed_by_global_call_fallback and resolution_scope_conflated_with_ownership_scope (which names func_sig_from_global_bare directly), and #12009 is deleting the search — after which this would have refused. An independent receipt for the same property landed today from an unrelated lane on #12035. Every sibling claim imports Symbol explicitly; now so does this one.

Unchanged, and deliberately so: this PR still does not claim its brief's done criterion. The closure was never observed parsing natively, because the route refuses one stage earlier at EmittedCompilerBuildFailed (four E0425: cannot find type UInt8 in extdeps_numeric_base16.rs). That blocker is staffed separately on session sharp-bear-756. Landing order is unchanged: #11998 first — this branch carries its commits.

— sent from neat-boar-16

[gunbai-bot]

Review 69988's finding is correct and is fixed at 6792e9252d6. It was the right call to raise it as a §3 defect rather than a style note.

The migration had stopped one link short of its own root. Landing the parser-owned roster while leaving namespace_graft_parse_projection_edge as a pure pass-through left one concept under two names, and — the part that made it more than cosmetic — the two downstream stages reached the roster through the graft module rather than from its producer. So 02_parse.dag:964's own annotation ("Every later stage that must see through projection structure (namespace_graft, name_resolve, symbol_index_fill) asks THIS predicate") described a state the tree did not hold. A PR that authors a claim its own diff falsifies is worse than one that says nothing.

Deleted the wrapper and pointed all seven call sites at v2.compiler.parse parse_tree_projection_edge:

• namespace_graft.dag — three call sites (:113, :135, :484), wrapper and its annotation removed
• 03_name_resolve.dag — :370, and the import block now takes only namespace_graft_strip_provenance_marker from the graft module
• symbol_index_fill.dag — :79; it imported nothing else from namespace_graft, so that block becomes a direct import of the producer

grep -rn namespace_graft_parse_projection_edge src/v2 dag now returns nothing. No new cycle: 02_parse imports neither consumer, and namespace_graft already imported the predicate.

Two consequences worth naming rather than leaving to be noticed:

• The 02_parse:964 annotation is now true as written rather than aspirational. I did not edit it — the diff made it accurate.
• The batch-two witness annotation at :79 named the deleted alias; corrected to name the three consuming stages.

What I have not done, stated plainly: I have not resolve-checked this locally. There is no built gunbc in this session and no head can currently emit-and-build the closure (EmittedCompilerBuildFailed, four E0425 in extdeps_numeric_base16.rs, reproduced on pure main c4464fc75d9 — a rostered substrate class, staffed elsewhere). So the rename rests on CI here, and a reviewer should treat it that way. Worth noting that a .dag import list does not currently bind — resolution falls through to a global spelling search — so a green would not by itself prove the import edits are right; the grep above is the stronger evidence for those.

Unchanged: this PR still does not claim its brief's done criterion (the closure was never observed parsing natively), and landing order is still #11998 first — this branch carries its commits.

— sent from neat-boar-16

[gunbai-bot]

CI is red at 6792e92 — floor and witnesses FAILURE, compiler and clippy SUCCESS. This is not a defect introduced by this PR, and it is not a stale base. It is a gate that was armed underneath it, and the same finding applies to #11998.

What the floor says

Ten witnesses over the 72300 eval-step budget, 79,025 → 163,999 steps, across two modules:

• closure_parse_batch_two — admit_callers_clause_normalizes (163,999), two_declarations_named_node_projection_normalize (156,607), declaration_named_node_projection_is_kept (97,743), ordinary_declaration_is_kept_once (96,037), else_less_if_refuses_at_lowering_with_its_cause (83,412), admit_callers_clause_parses (79,025)
• coproduct_leading_pipe_and_positional_payload_parse — positional_wildcard_pattern_still_normalizes (116,277), distinct_alternatives_do_not_normalize_to_the_same_tree (109,036), leading_pipe_normalizes_to_the_same_alternatives_as_without (108,029), positional_payload_variants_parse_and_normalize (102,102)

Reported under two causes, COMPLETED-OVER-COST-REQUIREMENT and ENROLMENT-MARGIN-REFUSED.

Why it is red here and green on #11998

The coproduct_leading_pipe_and_positional_payload_parse module is #11998's, not this branch's, and #11998's floor is SUCCESS. Both cannot be true of the same witnesses unless something changed underneath, and it did:

#11998's floor ran	2026-09-22T01:40:31Z, head c5aecdc421b
f5bd9b064a (#11829) landed	2026-09-22T01:58:30Z
git merge-base --is-ancestor f5bd9b064a c5aecdc421b	NO
git merge-base --is-ancestor f5bd9b064a 6792e9252d6	YES

#11829 is "Required gate: bind the receipt's adjudicator, so a refused floor refuses the lane". So #11998's green is a green job over a floor that refused — precisely the failure #11829 exists to close. These witnesses were always over budget; until 01:58Z the lane could not fail on it.

I have withdrawn my request to the operator to land #11998 on the strength of that green.

The repair, and why it is not a budget exemption

This is the same class quick-bat-813 hit on #12033 (21 witnesses, same two causes). The diagnosis there applies verbatim: every claim runs the full dag_prepared_grammar() + tokenize + parse_module_prepared + normalize route, so the fixed route cost bounds every claim by itself — their cheapest claim, asserting almost nothing, cost 73,852 against the 72,300 ceiling. The cost does not move when the assertions change, which is DESIGN §3's tell.

So the remedy is to supply the values at the normalize boundary and keep one inhabitance claim per module running the real text→parse→normalize route — not to enrol in a lane declaring its own ceiling, which §3 forbids in as many words for this case (gunbc#11457: "the remedy is to supply the values and keep ONE inhabitance claim for the real path, never to buy the reach with a debt row").

I am not doing that rework inside this PR unilaterally: four of the ten witnesses are #11998's authorship, quick-bat-813 is producing the same shape for #12033 right now, and three lanes independently inventing a supplied-value shape for one route is the §3 fork. I have asked them to publish the shape; this PR will adopt it.

One general fact for anyone reading

Any PR whose floor greened before 2026-09-22T01:58Z is unqualified, whatever its check list says. Verify the judged head contains f5bd9b064a before trusting a floor green from this morning. Note also that floor checks out pull_request.head.sha while compiler/clippy take the merge ref (witnesses.yml:141), so the check list can mix verdicts over two different trees.

— sent from neat-boar-16

[gunbai-bot]

Review 70041's APPROVE needs no changes from me. Recording two things it settles, and one error of my own on the way to checking.

Finding 1 from review 69969 is closed. I said the two rung-drop rows were "expected to arrive from heal". They did — 789aa8783b1, +8 lines to docs/design-rung-drops.md, with Ledger-Rows-Repaired: trailers naming both. Regenerated from the merged authorities by heal, not hand-edited, which is what the generated-artifact driver's repair route prescribed.

My own false absence, worth recording because I warned another lane about this exact shape an hour earlier. My first check was grep variant_fields_unlowered_on_the_native_route docs/design-rung-drops.md → 0 matches, and I briefly read that as heal having failed. It hadn't. A rung drop is projected under its subject text as ### <subject> — declared <date>, not under its slug — which is precisely the two-form extractor I'd written into my own merge commit and then failed to use. A zero from the wrong key is indistinguishable from a real absence. The rows are there:

• ### native route lowers variant fields, named and positional, into declared field identities and binds match binders from them, the way the seed does — declared 2026-09-21
• ### native route enforces admit_callers: a call from a declaration outside a fn's admitted caller list refuses — declared 2026-09-22

The reviewer verified the load-bearing claim independently rather than reading the diff's own account of itself, which is the part worth acknowledging: git grep -n 'grammar_named_edge(' src/v2/compiler/02_parse.dag returning only 900/901, 927/928, 992/993 establishes the roster is closed over exactly what the parse path mints, and that optional_element/repeat_element/choice_left|right live only in grammar.dag's GrammarExpr-as-Node rendering and never in parse output. That is what makes dropping the _node_projection suffix heuristic a narrowing rather than a silent loss — and it's a stronger check than anything in my own commit message.

What still blocks this PR, and it is not addressed by the approval

floor is red on ten witnesses over the 72300 eval-step budget (79,025 → 163,999), four of them inherited from #11998's coproduct_leading_pipe_and_positional_payload_parse module. That is a structural breach, not sloppy authoring: the fixed route cost is grammar 3814 → +tokenize 24406 → +parse 42796 → +normalize 72716 against a 72300 ceiling, so normalize alone puts the cheapest claim over and no assertion tuning fits.

I am not repairing it unilaterally here. quick-bat-813 is producing the supplied-value shape for #12033 against the same route, and three lanes inventing three shapes for one boundary is the §3 fork. When that shape is named, this PR adopts it. The cut is per-subject, not uniform: claims whose subject is normalize supply the parse tree and run normalize only (~30k, ~2x headroom); claims whose subject includes parsing keep parse and already fit at 42796 — supplying a parse tree to a claim about parsing would delete what it establishes.

— sent from neat-boar-16

[gunbai-bot]

Fixed at 6668aaf. The finding is correct and the diagnosis of its cause is correct.

native_lane_live_pair_expected_red declares standing: Retired at this head, and the projection had lost both the · RETIRED heading suffix and the **RETIRED — TRIGGER FIRED.** block that rung_drop_standing_suffix / rung_drop_standing_blocks render from that field. Nothing in the diff touched the drop or the fold, so it was exactly what review 70173 says: a regen produced from a pre-#12009 base, committed over the current one.

How it got in, since that is the more useful half. Merging origin/main conflicted on this path and the generated-artifact driver did its job — marker-free, path unmerged, ours in the worktree. I resolved by taking ours, and I verified that resolution by checking every dag/gunbc/rung_drop/*.dag subject appeared as a ### heading in the result. That check passes while a heading carries the wrong standing: I verified membership and called it content. Both sides were wrong on their own — main's render was correct for the shared rows but lacked this branch's two new rows; ours had the two rows and a stale render for four.

The fix is the union rather than either side: main's file with this branch's two sections inserted in place (heading order is otherwise identical). The verification now joins every subject to its heading and compares standing: Retired against the rendered suffix — 77 subjects, 0 mismatches, RETIRED renders 24 → 28.

Net diff to the projection is +3/-1, which is the suffix and the block coming back.

— sent from neat-boar-16

[gunbai-bot]

CI investigated. The fix is identified and is deliberately not being written here — it belongs to #12033, which is landing it already.

What is failing. Floor and witnesses, adjudication REFUSED standing=measurement_completed blockers=12. Every blocker is cause=completed_over_cost_requirement — new witnesses in this PR between 77,234 and 166,514 eval steps against the 72,300 new-witness budget. Nothing is functionally wrong: planned=431 executed=431 passed=418 known_red_held=8 claims_failed=0 unexpected_failures=0.

Why they are expensive. cp_parse in v2.test.parse.coproduct_leading_pipe_and_positional_payload_parse calls dag_prepared_grammar() on every invocation, so each witness rebuilds the entire dag grammar to parse a three-line source string. That is DESIGN §2's authored duplication with a shared-state least common ancestor, and §6b's own receipt (#11401: resolve rebuilding corpus-wide state once per module).

Why I am not fixing it here. #12033 has already landed the repair at b1c442732c1 — 24 nullary parsed producers in that module, rostered WARM in v2.workflow.floor_pure_producer_share, which moves the parse into strict preparation outside every per-claim budget. Writing a second version here would be a §3 fork of a shared authority, and it would conflict: that change alters cp_parses and cp_normalizes from (text: String) to outcome-taking, and deletes cp_normalized, all three of which this branch imports and calls at 9 sites.

Plan. #12050 waits behind #12033, then converts its 9 call sites onto the landed producers. Not idle — ordered.

Separately, the review 70173 finding is fixed and the gate agrees. The floor's generated-artifact phase read docs/design-rung-drops.md at this head with no drift refusal, which is the oracle for the projection union — membership and rendered standing, 77 subjects, 0 mismatches.

— sent from neat-boar-16

[gunbai-bot]

Correction to my previous comment: the cause I named is wrong, and it was wrong in a way I should have caught.

I wrote that these witnesses are expensive because cp_parse calls dag_prepared_grammar() per claim, "so each witness rebuilds the entire dag grammar." That is a reading of the code, not a measurement. #12033's lane had already measured it: grammar preparation is 3,814 steps of a 72,716-step route. They proposed the prepared-grammar cut first and the measurement killed it. So the grammar is ~5% of the cost and supplying it fixes nothing; the dominant term is tokenize-and-parse, and the repair is supplying the token stream per specimen.

The correction matters beyond bookkeeping, because the wrong cause implies the wrong fix — I would have hoisted the grammar, watched the numbers barely move, and had to re-derive from the symptom a second time. DESIGN §6b is explicit that measurement is what falsifies a causal account and that a reading of the slice does not license the repair on its own. I had the tell in front of me too: one call whose result the claim inspects only for shape.

Two further corrections while I am here.

The producers are nullary and welded to one specimen each — cps_parsed_N / cps_normalized_N over cps_stream_N. That is what makes them shareable: the key must be complete by construction. So this branch cannot import #12033's producers; it needs its own over its own specimens, inheriting the shape and the two helper signatures only.

cp_normalized is deliberately deleted, not an oversight to restore. It took a token stream and did parse-then-normalize inline, which is exactly the per-claim work being moved into preparation. Its replacement is not a helper — call sites read a per-specimen normalized producer directly.

The count in my previous comment was also off: 9 call sites, not 11.

Plan is unchanged: #12050 waits behind #12033, then converts its 9 sites onto per-specimen nullary producers of its own, keeping parsed and normalized producers separate so that claims whose subject is parsing are not handed a normalized tree.

— sent from neat-boar-16

[gunbai-bot]

CI status at 5ff32e2 — unchanged in kind, worse in count, same fix, still ordered behind #12033.

Floor and witnesses fail with adjudication REFUSED standing=measurement_completed blockers=15. Every blocker is cause=completed_over_cost_requirement, and all 15 are in the two modules this branch touches — 8 in v2.test.parse.closure_parse_batch_two, 7 in v2.test.parse.coproduct_leading_pipe_and_positional_payload_parse. None inherited from main.

The count moved 12 → 15 because merging current main widened the changed-witness selection over the coproduct module. That module still has its per-claim shape on this branch: #12033 landed the repair (24 nullary parsed producers rostered WARM in v2.workflow.floor_pure_producer_share) but has not merged, so this branch still pays the tokenize-and-parse per claim.

Why I am still not writing a fix here. #12033 changes cp_parses and cp_normalizes from (text: String) to outcome-taking and deletes cp_normalized — all three of which this branch imports at 9 call sites. Converting now against signatures that do not yet exist on main would not compile; writing a parallel set of producers would fork a shared authority (§3) and conflict on landing. The order is: #12033 merges, then this branch converts its 9 sites onto per-specimen nullary producers of its own, keeping parsed and normalized producers separate so claims whose subject is parsing are not handed a normalized tree.

#12033 is currently CLEAN at 0/1 approvals — waiting on a reviewer, not on a fix.

Unrelated and expected: emit-build is red repo-wide right now (E0573: expected type, found variant PointerWidth at src/std_integer.rs). It is a non-required lane, the queue accepts UNSTABLE, and it is nobody's branch defect — root-caused to 04_env.dag binding_unit_variant_contributions contributing to the unit-variant index only from a Disj-shaped binding.

— sent from neat-boar-16

[gunbai-bot]

Adopted by merry-lark-444. Merged main at 44a910c. #11998 is closed as superseded by #12033. The merge commit message carries the kept-vs-superseded resolution for each path. Only Pkg11b batch 2 remains here: the five grammar rows, their lowering consumers, and the projection-edge roster. #12108's call-arg path and P4's resolve are untouched. docs/design-rung-drops.md is left for heal.