v2 grammar: a response status class (5xx) parses — 28 service modules stop refusing whole

[gunbai-bot]

XL-2, per quiet-seal-543's ruling: fix the v2 parse refusals across service/transport files, one class per PR. This is the first class, and the largest.

The defect

v2.extdeps.languages.dag dag_grammar_status_pattern_expr admitted an int literal or an identifier. The HTTP status class 5xx lexes as the int 5 followed by the identifier xx, so every response block that writes a status class refused its whole module as parse_g0_tokens_remain, located at xx. v1 reads the pair as one class (v1 02_parse parse_status_pattern: an int followed by the ident xx becomes "{n}xx"), which is why v1 accepted these files.

The change

The status pattern's first alternative is now seq(int_literal, literal_terminal("xx")), tried before the bare int. It follows the dag_grammar_op_modifier_expr literal-terminal precedent. It adds no name terminal, so v2.compiler.occurrence_role's table is unaffected: status_pattern stays NamesAreReferences for its named arm.

Controls (v2.test.claim.parse.status_class_pattern, one parse per claim)

• a_status_class_parses_holds (5xx). Red on main, executed: on main df9cda7220f with only this test added it FAILS, and the three controls beside it pass.
• an_exact_status_code_parses_holds (404) and a_named_status_parses_holds (nonzero): the other two arms still parse.
• a_malformed_status_class_refuses_at_its_suffix_holds: 5yy still refuses, located at yy. The new arm admits exactly xx and nothing wider.

Parse count before and after

Instrument: a v2 parse (conservation_subject_of_text .parsed) of the 116 .dag files that hold a transport member, which is the population #12757's census covered.

	main	this branch
parse	82	111
refuse	34	5

• The 28 5xx refusals are all gone.
• ebay/browse.dag and github/app.dag parse too. I had listed them as separate singletons, but their refusals were downstream of a status class.
• google/sheets.dag still refuses, now at a later point (line 771, data: data,: the keyword data used as a field label). The status class had been masking it.
• The 5 remaining refusals are the next classes, each for its own PR:
  • io from "key" / = default tails: gcp.dag, iam.dag, browser.dag;
  • a keyword used as a label: sheets.dag;
  • a trailing comma before ]: shell/exec.dag:48.

All claims executed with claim_batch on a 30 GB BuildBuddy runner. No emitted Rust changes: the v2 grammar has no stage0 mirror.

Land only via the merge queue.

🤖 Generated with Claude Code

[briansrls]

APPROVE-MERGE at exact head e959875. No findings.

The grammar change is correctly bounded: the status-class arm is seq(int_literal, literal xx) and precedes the existing bare-int arm, matching v1's two-token reading without turning the suffix into a name. Exact numeric statuses and named statuses retain their existing arms, and the 5yy located-refusal control proves the new arm admits exactly xx rather than widening arbitrary suffixes.

This does not create an occurrence-role obligation: the xx token is a literal terminal, while dag_production_status_pattern remains NamesAreReferences for its lexeme-stamped named arm. The 116-file affected-population measurement is appropriate: parse moves 82→111 and refusal 34→5, with the newly reached service modules still refusing later at the tracked service-interface carrier wall rather than being overclaimed as normalized.

All five exact-head checks are green, including floor, generated, emit-build, rust-unit-tests, and witnesses. Authorize merge-queue landing only: require the actual merge_group candidate to pass against then-current main; no direct merge or check bypass.