fix(parser): support definite-article back-reference reveal ("Reveal the card")

[e11734937-beep]

Summary

Bare back-reference reveal clauses using the definite article — Reveal the card. / Reveal the cards. — fell through to Effect::Unimplemented in the oracle-text parser, even though the semantically identical pronoun/demonstrative forms (Reveal it. / Reveal that card. / Reveal those cards.) were already supported and lower to Effect::Reveal { target: ParentTarget } (CR 701.20a).

This was surfaced by the repo's own cargo parser-gaps audit (A_verb_variation / reveal), which reports reveal the card and reveal the cards as distinct unsupported patterns. The sequence.rs::is_search_result_reveal_clause continuation recognizer already lists reveal the card in its vocabulary, so the imperative recognizer parse_hand_reveal_ast was simply inconsistent with it.

Change

In parse_hand_reveal_ast (crates/engine/src/parser/oracle_effect/imperative.rs), add the definite-article forms so a bare Reveal the card. / Reveal the cards. clause lowers to the same Effect::Reveal { target: ParentTarget } back-reference as the existing pronoun forms.

These forms are matched as a whole-clause (anchored) match, not a prefix. The pronoun forms can stay loose prefix matches because no real card continues them divergently, but the definite-article forms are highly collision-prone at the prefix — e.g.:

• reveal the cards you want to splice onto it (splice selection)
• reveal the cards in your library (library reveal)

These are distinct effects that merely share the reveal the card(s) prefix. Anchoring restricts the new lowering to a bare back-reference clause and leaves compound clauses to their own recognizers.

Tests

crates/engine/src/parser/oracle_effect/tests.rs:

• reveal_the_card_backref_lowers_to_reveal_parent_target — the definite-article forms lower to Effect::Reveal { ParentTarget }, and the pre-existing pronoun/demonstrative forms keep working (regression anchors).
• reveal_the_card_backref_does_not_hijack_compound_clauses — compound clauses that start with reveal the card(s) are not misclassified as a bare back-reference.

Verified against the full engine unit-test suite (cargo test -p engine --lib): the new positive test fails before the change (Reveal the card. → Unimplemented) and passes after, with no regressions across the suite.

[gemini-code-assist]

Code Review

This pull request updates the back-reference reveal parsing logic in crates/engine/src/parser/oracle_effect/imperative.rs to support definite-article forms ("the card" / "the cards") as whole-clause matches. Feedback on this change highlights a violation of repository style guides: the implementation uses verbatim string matching with matches! instead of the required nom combinators (Rule R1) and lacks the mandatory CR annotation (Rule R6). Refactoring using nom combinators is recommended to align with the project's architectural rules.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[matthewevans]

[HIGH] Definite-article reveal is implemented with exact string matching instead of parser combinators. Evidence: crates/engine/src/parser/oracle_effect/imperative.rs:2858. Why it matters: parser dispatch in this repo is required to compose nom axes rather than add verbatim Oracle string matches, and this branch can be expressed with the already-imported all_consuming/alt/tag combinators while preserving the whole-clause anti-hijack behavior. Suggested fix: replace the matches!(after_reveal_lower.trim().trim_end_matches('.').trim(), "the card" | "the cards") branch with an all_consuming nom parser for the card/the cards plus optional period/trimming.

Reviewed current head 7e22e7d10b4afd84cb68c8857d9d1088d7283c62.

[matthewevans]

[HIGH] Definite-article reveal is still implemented with exact string matching instead of nom combinators. Evidence: crates/engine/src/parser/oracle_effect/imperative.rs:2858. Why it matters: parser dispatch in this repo requires composable nom axes, and this branch still uses matches!(after_reveal_lower.trim().trim_end_matches('.').trim(), "the card" | "the cards") for the new grammar form. Suggested fix: replace this branch with an all_consuming nom parser for the card / the cards plus optional trailing punctuation/space handling.

[e11734937-beep]

Thanks for the review — addressed both points in b1d96ef:

• R1 (nom combinators): replaced the verbatim matches! comparison with all_consuming((alt((tag("the cards"), tag("the card"))), opt(tag(".")))) on the trimmed remainder. This keeps the whole-clause anti-hijack anchoring — compound clauses like reveal the cards you want to splice onto it and reveal the cards in your library still fall through to their own recognizers (covered by the reveal_the_card_backref_does_not_hijack_compound_clauses guard test).
• R6 (CR annotation): the branch now leads with the CR 701.20a citation, consistent with the sibling pronoun arm.

No behavior change; full engine suite green (14460 passed, 0 failed).

[matthewevans]

Approved at this head. The definite-article reveal back-reference is now anchored as a whole-clause nom parse, so bare "Reveal the card/cards." lowers to Reveal { ParentTarget } without hijacking compound reveal clauses. The positive and negative parser tests cover the regression shape.