fix(parser): Weathered Wayfarer activation when opponent has more lands

[kiannidev]

Summary

• Parse "an opponent controls more [type] than you" as an existential opponent check (at least one opponent strictly exceeds your count) instead of comparing aggregate opponent permanents to yours.
• Add integration tests covering Weathered Wayfarer activation when land counts differ and when they are tied.

Test plan

• Activate Weathered Wayfarer when you control one land and an opponent controls three.
• Confirm activation is blocked when each player controls the same number of lands.
• In a three-player game, verify activation requires a single opponent with more lands, not a combined opponent total.

Fixes #859

Made with Cursor

[gemini-code-assist]

Code Review

This pull request addresses issue #859 by updating the parser for "an opponent controls more [type] than you" to correctly perform an existential check over individual opponents rather than aggregating their permanents. It also adds integration tests for Weathered Wayfarer. Feedback on the changes highlights a missing three-player integration test to fully verify the existential logic, an incorrect Magic Comprehensive Rules (CR) citation in the comments, and an opportunity to use the existing inject_controller_you helper for more idiomatic Rust code.

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.

[gemini-code-assist]

[HIGH] Missing 3-player integration test.

Why it matters: The PR description's test plan explicitly mentions verifying activation in a three-player game to ensure it requires a single opponent with more lands (existential check) rather than a combined opponent total, but no such test was implemented.

Suggested fix: Append a 3-player integration test to verify this behavior.

}

#[test]
fn weathered_wayfarer_blocked_in_three_player_game_when_no_single_opponent_has_more_lands() {
    use engine::game::scenario::P2;
    let mut scenario = GameScenario::new();
    scenario.at_phase(Phase::PreCombatMain);

    let wayfarer = scenario
        .add_creature_from_oracle(P0, "Weathered Wayfarer", 1, 1, WEATHERED_WAYFARER)
        .id();
    scenario.add_basic_land(P0, ManaColor::White);
    scenario.add_basic_land(P0, ManaColor::White);
    scenario.add_basic_land(P1, ManaColor::Blue);
    scenario.add_basic_land(P1, ManaColor::Blue);
    scenario.add_basic_land(P2, ManaColor::Green);

    let runner = scenario.build();
    assert!(
        !can_activate_ability_now(runner.state(), P0, wayfarer, 0),
        "no single opponent has more lands than P0 (P1 has 2, P2 has 1, P0 has 2), even though aggregate is 3"
    );
}

[gemini-code-assist]

[MEDIUM] Incorrect CR citation.

Why it matters: CR 109.4 describes who has a controller on the stack or battlefield, which is unrelated to the definition of an opponent or existential checks.

Suggested fix: Update the citation to CR 102.2 (defining 'opponent') and/or CR 109.5 (defining 'you' and 'your').

Suggested change

	// CR 109.4: "an opponent controls more [type] than you" — existential over
	// opponents (at least one opponent strictly exceeds your count), not an
	// aggregate of all opponent permanents. Weathered Wayfarer, Tithe, etc.
	// CR 102.2 / CR 109.5: "an opponent controls more [type] than you" — existential over
	// opponents (at least one opponent strictly exceeds your count), not an
	// aggregate of all opponent permanents. Weathered Wayfarer, Tithe, etc.

References

1. Every rules-touching line of engine code must carry a comment of the form CR : . A CR annotation where the cited rule's body does not describe what the code is doing is a finding. ^(link)

[gemini-code-assist]

[MEDIUM] Non-idiomatic filter construction.

Why it matters: Manually matching and cloning type_filter to inject the controller is verbose and bypasses the codebase's standard inject_controller_you helper, which also ensures the filter is correctly restricted to the battlefield.

Suggested fix: Reuse the existing inject_controller_you helper.

            let you_filter = inject_controller_you(type_filter.clone());

References

1. Idiomatic Rust pillar: uses the type system, ownership model, and standard library idioms to their fullest. Composable building blocks pillar: reuse existing helpers before writing new manual logic. ^(link)

[matthewevans]

Maintainer review — FIXED, NOW READY

Verdict: Right seam, right building block. parse_inner_condition is the single authority for game-state conditions, and the fix reuses the parameterized PlayerFilter::ControlsCount exactly as its doc comment prescribes for the comparative class ("each player who controls more creatures than you" — Heidegger pattern: { GT, Ref(ObjectCount.controller(You)) }, wrapped in PlayerCount GE 1 for the existential reading). No new variant, no sibling proliferation. The rules reading is correct: "an opponent controls more lands than you" requires a single opponent to individually exceed your count — the old aggregate-all-opponents comparison was wrong in multiplayer.

Discrimination audit (empirical, via revert trick):

• The two shipped integration tests pass unchanged on origin/main's parser — in 2-player, one opponent's count ≡ all opponents' aggregate, so they never discriminated the fix. They're fine as activation-path pins, nothing more.
• I added the discriminating 3-player test (weathered_wayfarer_blocked_when_only_combined_opponents_exceed): two opponents with one land each vs your one land — aggregate (2 > 1) activates under the old parse, existential blocks. Verified: fails with condition.rs reverted to main, passes with the fix.

Gemini findings, confirmed and resolved (pushed f9cf4fe73, 2bc05c267):

1. Missing 3-player test (HIGH) — confirmed; added as above. (Gemini's suggested snippet wouldn't compile: GameScenario::new() is 2-player and P2 isn't exported — new_n_player(3, seed) + a local P2 const is the codebase convention, per belbe_thornbow_life_loss.rs.)
2. CR citation (MEDIUM) — partially valid. Annotated as CR 109.4 + CR 109.5 (controller-of-objects + "you" = ability's controller), matching the existing ControlsCount arms in game/quantity.rs; grep-verified against docs/MagicCompRules.txt. Also swapped the Tithe example for Land Tax — Tithe's "that opponent" is demonstrative and takes a different parse path.
3. inject_controller_you (MEDIUM) — confirmed; the hand-rolled Typed-match/clone duplicated a helper twenty lines up in the same file, and missed its battlefield InZone pin. Delegated.

Note on "Fixes #859": the 2-player activation failure reported in #859 does not reproduce on current main even without this parser change (proven by the revert run) — the runtime blocker was most likely the castability gating fixed in #2788. This PR's real value is the multiplayer rules correction; the issue link is still fine since the parse is now CR-correct for the card.

Verification: cargo fmt, condition.rs unit tests 277/277, issue_859 suite 3/3, cargo check -p engine --all-targets clean.

Not approving/merging — leaving that to the lead.

[matthewevans]

Correct multiplayer-rules fix reusing the documented PlayerFilter::ControlsCount parameterization (no new variants). The added 3-player discriminating test (two opponents with 1 land each vs your 1) fails on revert — it pins the existential-vs-aggregate distinction the 2-player tests couldn't. CR 109.4/109.5 verified in the rules text. condition tests green, CI green.