[codex] fix(parser): parse repeated named control conditions

[ntindle]

Summary

Fixes the Root #30 subcluster for repeated named-control conditions where each list item carries its own type phrase.

Root cause: parse_control_named_pair handled you control [type] named A and B, where the type applies to both names, but the parser had no combinator for the sibling shape you control [type] named A and/or [type] named B. As a result, High Marshal Arguel absorbed a land named ... into the first named filter, and Liu Bei treated the or a permanent named ... clause as part of the first literal name.

This PR adds a prefix-dispatched nom parser for repeated named-control items before the shared-type named-pair parser. Each item is parsed through parse_type_phrase, keeps its own type filter, and only treats and/or as a name boundary when the following text is another valid [type] named ... item, preserving comma-bearing names like Guan Yu, Sainted Warrior.

Backlog update: removes High Marshal Arguel and Liu Bei, Lord of Shu from docs/parser-misparse-backlog.md Root #30, changing the branch-local count from 12 to 10.

Parsed-card diff audit

Targeted baseline/after exports:

• Before: /tmp/phase-root30-namelists-baseline.json
• After: /tmp/phase-root30-namelists-after.json
• Filter: High Marshal Arguel|Liu Bei, Lord of Shu

Raw parsed card keys changed exactly:

• high marshal arguel
• liu bei, lord of shu

Expected parse movements:

• High Marshal Arguel: the second condition changes from an enchantment named a land named temple of aclazotz to a land named temple of aclazotz.
• Liu Bei, Lord of Shu: the condition changes from one permanent named guan yu, sainted warrior or a permanent named zhang fei, fierce warrior to an Or of two permanent-named predicates.

Sibling scan against current MTGJSON found exactly these two repeated named-control condition texts:

jq -r '.data | to_entries[] | .key as $name | .value[] | select(.text? and (.text | test("you control .*named .* (and|or) .*named"; "i"))) | $name + " :: " + (.text | gsub("\\n"; " / "))' data/mtgjson/AtomicCards.json

coverage-parse-diff reported no support-signature clusters (oracle_changed: 0), so the expected raw AST repairs are confined to the two audited cards.

Validation

• cargo fmt --all
• ./scripts/check-parser-combinators.sh
• git diff --check
• cargo test -p engine --features cli --lib repeated_named_control_presence -- --nocapture
• cargo test -p engine --features cli --lib inverted_liu_bei_condition_lowers_to_named_or_condition -- --nocapture
• cargo test -p engine --features cli --lib test_you_control_named_pair -- --nocapture
• cargo run -p engine --features cli --bin oracle-gen -- data --filter "High Marshal Arguel|Liu Bei, Lord of Shu" --output /tmp/phase-root30-namelists-after.json
• cargo run -p engine --features cli --bin card-data-validate -- /tmp/phase-root30-namelists-after.json
• cargo run -p engine --features cli --bin coverage-parse-diff -- /tmp/phase-root30-namelists-baseline.json /tmp/phase-root30-namelists-after.json --markdown /tmp/phase-root30-namelists-parse-diff.md --json /tmp/phase-root30-namelists-parse-diff.json

Tilt was not running in this checkout (No tilt apiserver found: tilt-default), so I used the direct cargo fallback allowed by the repo instructions.

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[matthewevans]

Reviewed current head fbe497a0a0f9ab42d90a2a916504116bc019b35c.

I inspected the parser/test diff and did not find a code blocker in the repeated named-control parser path, but I’m holding approval/enqueue for live evidence: this parser PR does not yet have the required coverage-parse-diff comment, Rust/card-data checks are still in progress, and GitHub currently reports the branch as BEHIND. I’ll re-check once the parse-diff and fresh checks are available on the current head.

[github-actions]

Parse changes introduced by this PR · 2 card(s), 2 signature(s) (baseline: main 3bea252fd808)

1 card(s) · static/Continuous · field conditional: named "guan yu, sainted warrior or a permanent named zhang fei, fierce warrior" in battlefield you control permanent is… → named "guan yu, sainted warrior" in battlefield you control permanent is present or named "zhang fei, fierce warrior" i…

Examples: Liu Bei, Lord of Shu

1 card(s) · ability/Token · field conditional: instead if (# of named "arguel's blood fast" in battlefield you control enchantment ≥ 1 and # of named "a land named te… → instead if (# of named "arguel's blood fast" in battlefield you control enchantment ≥ 1 and # of named "temple of aclaz…

Examples: High Marshal Arguel

1 card(s) had Oracle-text changes (errata/reprint) — excluded as non-parser.

[matthewevans]

[MED] The new repeated named-control helper cites the wrong Comprehensive Rule for static-condition users. Evidence: crates/engine/src/parser/oracle_nom/condition.rs adds parse_repeated_named_control_presence with CR 201.2 + CR 603.4, but docs/MagicCompRules.txt defines CR 603.4 only as the intervening-if triggered-ability rule; the parse-diff shows this helper is also lowering Liu Bei's static "as long as" condition, where CR 603.4 does not apply. Why it matters: this repo treats verified CR comments as review evidence, and a wrong CR citation is worse than no citation around rules-sensitive parser code. Suggested fix: keep the CR 201.2 named-object grounding here and either remove CR 603.4 from this new helper comment or split the wording so triggered/static uses are not both justified by the intervening-if rule.