refactor(parser): promote replicator SpecialClause variants to ClauseDisposition::ReplicatePerKeyword (U5-M2)#5565
Conversation
…Disposition::ReplicatePerKeyword (U5-M2)
Third U5-M2 increment. SameIsTrueFor + RepeatProcessForKeywords (CR 702 / CR
608.2c per-keyword template replication) fold into
`ClauseDisposition::ReplicatePerKeyword { keywords, kind: ReplicateKind }`, where
`kind` (StaticGrant | CounterPlacement) selects the replication helper — the two
handlers share the same call shape but distinct rules concepts, kept typed rather
than collapsed. Both SpecialClause variants are deleted.
Faithful-by-construction (ClauseDisposition never reaches a serialized snapshot).
Parity tests — Odric, Lunarch Marshal (StaticGrant, 12-keyword grant) and Kathril,
Aspect Warper (CounterPlacement) — exercise the multi-keyword replication loop with
zero snapshot drift.
There was a problem hiding this comment.
Code Review
This pull request refactors per-keyword replication logic by introducing ClauseDisposition::ReplicatePerKeyword and the ReplicateKind enum, replacing the previous SpecialClause variants for static grants and counter placements. It also adds corresponding snapshot tests. The review feedback highlights that several of the newly introduced CR annotations violate the strict formatting rule (R6) by combining multiple rules on a single line, and suggests splitting them into separate, single-rule annotations.
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.
| // CR 702 / CR 608.2c: replicate the antecedent template clause once | ||
| // per listed keyword. `kind` selects which template shape (and thus | ||
| // helper); the keyword-swap logic lives unchanged in the helpers. |
There was a problem hiding this comment.
[MEDIUM] Non-compliant CR annotation format. Evidence: crates/engine/src/parser/oracle_effect/lower.rs:1440.
Why it matters: Every rules-touching line of engine code must carry a single, strictly formatted CR comment matching the regex CR \\d{3}(\\.\\d+[a-z]?)? to ensure automated verification against the Comprehensive Rules.
Suggested fix: Split the combined CR comment into separate, single-rule annotations.
| // CR 702 / CR 608.2c: replicate the antecedent template clause once | |
| // per listed keyword. `kind` selects which template shape (and thus | |
| // helper); the keyword-swap logic lives unchanged in the helpers. | |
| // CR 702: Replicate the antecedent template clause once per listed keyword for static grants. | |
| // CR 608.2c: Replicate the antecedent template clause once per listed keyword for counter placement. |
References
- Every rules-touching line of engine code must carry a comment of the form CR : (regex CR \d{3}(\.\d+[a-z]?)?). (link)
| else_def: Box<AbilityDefinition>, | ||
| kind: OtherwiseKind, | ||
| }, | ||
| /// CR 608.2c / CR 702: replicate an antecedent template clause once per listed |
There was a problem hiding this comment.
[MEDIUM] Non-compliant CR annotation format. Evidence: crates/engine/src/parser/oracle_ir/effect_chain.rs:238.
Why it matters: Every rules-touching line of engine code must carry a single, strictly formatted CR comment matching the regex CR \\d{3}(\\.\\d+[a-z]?)? to ensure automated verification against the Comprehensive Rules.
Suggested fix: Split the combined CR comment into separate, single-rule annotations.
| /// CR 608.2c / CR 702: replicate an antecedent template clause once per listed | |
| /// CR 702: Replicate an antecedent template clause once per listed keyword for static grants. | |
| /// CR 608.2c: Replicate an antecedent template clause once per listed keyword for counter placement. |
References
- Every rules-touching line of engine code must carry a comment of the form CR : (regex CR \d{3}(\.\d+[a-z]?)?). (link)
| Fallback, | ||
| } | ||
|
|
||
| /// CR 608.2c / CR 702: which per-keyword replication is performed. Both replicate |
There was a problem hiding this comment.
[MEDIUM] Non-compliant CR annotation format. Evidence: crates/engine/src/parser/oracle_ir/effect_chain.rs:289.
Why it matters: Every rules-touching line of engine code must carry a single, strictly formatted CR comment matching the regex CR \\d{3}(\\.\\d+[a-z]?)? to ensure automated verification against the Comprehensive Rules.
Suggested fix: Split the combined CR comment into separate, single-rule annotations.
| /// CR 608.2c / CR 702: which per-keyword replication is performed. Both replicate | |
| /// CR 702: Replicate an antecedent template clause once per listed keyword for static grants. | |
| /// CR 608.2c: Replicate an antecedent template clause once per listed keyword for counter placement. |
References
- Every rules-touching line of engine code must carry a comment of the form CR : (regex CR \d{3}(\.\d+[a-z]?)?). (link)
Parse changes introduced by this PR✓ No card-parse changes detected. |
Third U5-M2 increment. SameIsTrueFor + RepeatProcessForKeywords (CR 702 / CR
608.2c per-keyword template replication) fold into
ClauseDisposition::ReplicatePerKeyword { keywords, kind: ReplicateKind }, wherekind(StaticGrant | CounterPlacement) selects the replication helper — the twohandlers share the same call shape but distinct rules concepts, kept typed rather
than collapsed. Both SpecialClause variants are deleted.
Faithful-by-construction (ClauseDisposition never reaches a serialized snapshot).
Parity tests — Odric, Lunarch Marshal (StaticGrant, 12-keyword grant) and Kathril,
Aspect Warper (CounterPlacement) — exercise the multi-keyword replication loop with
zero snapshot drift.