Evelyn, the Covetous cast cards from exile isn't working with enemy cards — Card: Evelyn, the Covetous Problem: After E…

[matthewevans]

Reported in Discord: https://discord.com/channels/1485498006781427802/1506886234989924434/1506886234989924434

Thread: Evelyn, the Covetous cast cards from exile isn't working with enemy cards
Cards: evelyn, the covetous
Parser status: has_gaps
Extraction confidence: 0.90

Summary

Card: Evelyn, the Covetous

Problem: After Evenlyn or another vampire enters the battlefield, the top card of each player’s library is exiled, but on

Oracle text (verified from client/public/card-data.json)

evelyn, the covetous

Flash
Whenever Evelyn or another Vampire you control enters, exile the top card of each player's library with a collection counter on it.
Once each turn, you may play a card from exile with a collection counter on it if it was exiled by an ability you controlled, and you may spend mana as though it were mana of any color to cast it.

---

_{report_id: discord:1506886234989924434:1506886234989924434:0 · discord: 1506886234989924434/1506886234989924434}

[matthewevans]

🤖 Implementation Plan — #696 (Evelyn, the Covetous)

Investigated by Claude Code; not yet implemented.

TL;DR — the triage premise was wrong, and the real bug is the one triage ruled out

The triage said Evelyn's card-data shows abilities:[] / parse_details:null and concluded the ETB trigger + play-permission static "are NOT synthesized." That is incorrect. The parser fully synthesizes both. The break is a runtime owner/controller-scoping bug introduced by the player_scope: All iteration — the exact failure mode triage explicitly dismissed ("the break is that Evelyn's abilities never get synthesized, not owner-scoping"). It is owner-scoping, just not on the cast side.

---

1. Confirmed root cause

1a. The abilities ARE synthesized. abilities:[] is empty because Evelyn's content lives in the triggers and static_abilities arrays, not the generic abilities array. From client/public/card-data.json:

"triggers":[{ "mode":"ChangesZone",
  "execute":{ "kind":"Spell",
    "effect":{"type":"ExileTop","player":{"type":"Controller"},"count":{"type":"Fixed","value":1}},
    "sub_ability":{ "effect":{"type":"PutCounterAll","counter_type":"collection","target":{"type":"TrackedSet","id":0}},
      "sub_ability":{ "effect":{"type":"GrantCastingPermission",
        "permission":{"type":"PlayFromExile","granted_to":0,"frequency":"OncePerTurn","mana_spend_permission":"AnyTypeOrColor"},
        "target":{"type":"TrackedSet","id":0}} } },
    ... "player_scope":{"type":"All"} } ],
"static_abilities":[{"mode":{"Other":"LinkedCollectionCounterPlayPermission"}, ...}]

The full chain ExileTop → PutCounterAll(collection, TrackedSet 0) → GrantCastingPermission(PlayFromExile, TrackedSet 0) is present, the static LinkedCollectionCounterPlayPermission is present, and the parser test at crates/engine/src/parser/oracle_trigger.rs:15978 (trigger_evelyn_exiles_each_library_with_collection_counter_and_permission) already asserts exactly this shape — including execute.player_scope == Some(PlayerFilter::All) and Effect::ExileTop { player: TargetFilter::Controller }. There is no parse failure and nothing is Unimplemented. (The SwallowedClause / Condition_If parse_warnings entry is benign noise — the "if it was exiled by an ability you controlled" sub-clause — and does not block synthesis.)

1b. The design is correct — player_scope: All + player: Controller is the intended "each player's library" lowering. The engine iterates player_scope: All over every player in APNAP order and, per iteration, rebinds the acting controller so ExileTop { player: Controller } exiles from each player's library:

• crates/engine/src/game/effects/mod.rs:4132–4139 — collects matching_players (all players for PlayerFilter::All).
• crates/engine/src/game/effects/mod.rs:4169 — scoped.set_original_controller_recursive(controller) preserves Evelyn's printed controller.
• crates/engine/src/game/effects/mod.rs:4178 — scoped.set_controller_recursive(*pid) rebinds the acting controller to the iterated player.

So ExileTop correctly fires once per player — the controller's AND the opponent's top card both get exiled. So far so good.

1c. The actual bug — GrantCastingPermission binds the grant to the iterated library-owner, not to Evelyn's controller. Because step 1b rebinds ability.controller to the iterated player, the chained grant resolves against the wrong "you":

• crates/engine/src/game/effects/grant_permission.rs:104–105 — grantee: AbilityController ⇒ constant_grantee = Some(ability.controller), which during the opponent's iteration is the opponent (PlayerId 1), not Evelyn's controller (PlayerId 0).
• crates/engine/src/game/effects/grant_permission.rs:138 — *granted_to = granted_to_pid ⇒ granted_to = opponent.
• crates/engine/src/game/effects/grant_permission.rs:140 — *exiled_by_ability_controller = Some(ability.controller) ⇒ Some(opponent).

Result on the opponent's exiled card: granted_to = PlayerId(1), exiled_by_ability_controller = Some(PlayerId(1)).

1d. The cast side is correct and correctly rejects it. crates/engine/src/game/casting.rs:1600–1644 (play_from_exile_permission_source) gates on *granted_to == player (line 1610). When Evelyn's controller (PlayerId 0) tries to play the opponent's exiled card, granted_to == PlayerId(1) != 0 ⇒ the find_map arm doesn't match ⇒ not castable. This is exactly the user's report: "playing the exiled enemy cards doesn't work." The controller's own exiled card works (that iteration binds granted_to = 0), which is why the bug looks like "only enemy cards are broken."

1e. Why the existing tests pass anyway (test gap). The casting tests at crates/engine/src/game/casting.rs:24569–24601 and :24639+ hand-construct the permission with granted_to: PlayerId(0) / exiled_by_ability_controller: Some(PlayerId(0)) already correct, and never drive Evelyn's ETB trigger through the player_scope: All iteration. They are SHAPE tests (cf. feedback_runtime_tests_must_drive_pipeline), so they never exercise the controller-rebind that corrupts the binding. Green tests, broken runtime.

Root cause (one line): during player_scope: All fan-out, GrantCastingPermission reads the rebound iterating-player controller instead of the printed original_controller, so the "you may play it" grant on each player's exiled card binds to the library-owner rather than to Evelyn's controller — and the cast-side granted_to == player check then correctly refuses it for everyone but the owner.

---

2. File-set

File	Change
crates/engine/src/game/effects/grant_permission.rs	Bind PlayFromExile granted_to / exiled_by_ability_controller to original_controller.unwrap_or(controller) for the AbilityController grantee, so the grant follows "you" (CR 109.5) and is stable across player_scope iteration.
crates/engine/src/game/casting.rs (tests)	Replace/augment the two hand-built SHAPE tests with a runtime test that drives Evelyn's ETB trigger end-to-end (see §5).
(verify only, likely no change) crates/engine/src/types/ability.rs:3092	Confirm the original_controller.unwrap_or(controller) accessor is the canonical "printed you" resolver and reuse it rather than open-coding the unwrap_or.

No parser changes, no card-data regen, no new enum variant. The infra (LinkedCollectionCounterPlayPermission static, PlayFromExile { exiled_by_ability_controller }, live_collection_counter_play_permission_source) is all in place and honored — only the binding source in the grant resolver is wrong.

---

3. Approach

The grant must resolve "you" (the controller of the triggered ability, CR 109.5) — which is stable across the player_scope fan-out — not the iterating library-owner. The engine already preserves that value: set_original_controller_recursive(controller) (effects/mod.rs:4169) stamps Evelyn's printed controller into ResolvedAbility.original_controller precisely so "you"-references survive the rebind.

In grant_permission::resolve, change the AbilityController grantee resolution (and the *exiled_by_ability_controller = Some(...) assignment) to use the printed controller:

// CR 109.5 + CR 608.2c: "you may play a card... it was exiled by an ability you
// controlled" — "you" is the triggered ability's controller, which is STABLE
// across a `player_scope: All` fan-out. During iteration `ability.controller`
// is rebound to each library's owner (effects/mod.rs:4178); the printed
// controller is preserved in `original_controller` (effects/mod.rs:4169). Bind
// the grant to that, not to the iterating owner, or Evelyn grants each player
// the right to play only their OWN exiled card (issue #696).
let printed_controller = ability.original_controller.unwrap_or(ability.controller);
let constant_grantee: Option<PlayerId> = match grantee {
    PermissionGrantee::AbilityController => Some(printed_controller),
    ...
};
...
*exiled_by_ability_controller = Some(printed_controller);

original_controller is None outside a player_scope iteration, so unwrap_or(ability.controller) keeps every non-iterated grant (Airbending, Foretell, Suspend, single-target Plot, etc.) byte-identical — strictly additive, zero regression surface for the non-fan-out path.

Scope guard: ParentTargetController and ObjectOwner grantees are intentionally NOT changed — those are per-iteration/per-object bindings by design (Jeleva-class "each opponent's library, grant to each owner" uses ObjectOwner). Only the AbilityController ("you") arm and its paired exiled_by_ability_controller stamp move to the printed controller. This is the CR 109.5 boundary: "you" is controller-stable; owner-scoped grants are not.

---

4. CR annotations (grep-verified against docs/MagicCompRules.txt)

• CR 109.5 (line 610): "The words 'you' and 'your' on an object refer to the object's controller... For a triggered ability, this is the controller of the object when the ability triggered." → "an ability you controlled" / "you may play" binds to Evelyn's controller, not the iterated library-owner. This is the rule the fix enforces.
• CR 608.2c (line 2789): "The controller of the spell or ability follows its instructions..." → the grant clause is resolved by the ability's controller; the player_scope iteration changes which library ExileTop reads, not who "you" is.
• CR 611.2a (line 2900): "A continuous effect... lasts as long as stated... If no duration is stated, it lasts until the end of the game." → matches the parsed duration: Permanent on the PlayFromExile grant (collection-counter permission persists).
• CR 609.4b (line 2851): "If an effect allows a player to spend mana 'as though it were mana of any [type or color],' this affects only how the player may pay a cost." → backs the mana_spend_permission: AnyTypeOrColor leg; assert it in the runtime test (§5).
• CR 122.1 (line 1176): "A counter is a marker placed on an object or player that modifies its characteristics..." → the generic collection counter (PutCounterAll { counter_type: Generic("collection") }); a collection counter has no intrinsic rules meaning beyond being the linkage key the play-permission references, consistent with CR 122.1 (named counters with card-defined meaning).

(No CR 701.x "exile" keyword-action annotation is needed — ExileTop is a card-defined "exile the top card" instruction, not the Exile keyword action; "collect evidence" does not appear in Evelyn's text and is unrelated.)

---

5. Discriminating runtime test

Add to crates/engine/src/game/casting.rs tests (drives the real pipeline; fails today, passes after the fix):

/// CR 109.5 + CR 609.4b + issue #696: Evelyn's ETB exiles the top card of EACH
/// player's library with a collection counter and grants HER CONTROLLER (not the
/// library owner) the right to play it. Drive the trigger through the
/// `player_scope: All` fan-out — do NOT hand-build the permission — so the
/// controller-rebind that corrupts `granted_to` to the opponent is exercised.
#[test]
fn evelyn_etb_lets_controller_play_opponents_exiled_card() {
    // P0 controls Evelyn; seed a known opponent (P1) top-of-library card.
    // Resolve Evelyn's ETB ChangesZone trigger (synthesized from card-data) so:
    //   - P1's top card moves to Exile with a `collection` counter, and
    //   - GrantCastingPermission runs in the P1 iteration of player_scope: All.
    // Then, as P0:
    let exiled_opp_card = /* P1's exiled top card */;
    let perm = state.objects[&exiled_opp_card]
        .casting_permissions.iter()
        .find_map(|p| match p {
            CastingPermission::PlayFromExile { granted_to, exiled_by_ability_controller, .. }
                => Some((*granted_to, *exiled_by_ability_controller)),
            _ => None,
        }).expect("opponent's exiled card carries a PlayFromExile grant");
    // Today: granted_to == PlayerId(1), exiled_by_ability_controller == Some(PlayerId(1)) → BUG.
    assert_eq!(perm.0, PlayerId(0), "grant must bind to Evelyn's controller, not the library owner");
    assert_eq!(perm.1, Some(PlayerId(0)));
    assert!(has_collection_counter(&state.objects[&exiled_opp_card]));
    // End-to-end: P0 can actually cast it...
    assert!(spell_objects_available_to_cast(&state, PlayerId(0)).contains(&exiled_opp_card));
    // ...and spend any-color mana (CR 609.4b): cast it paying off-color mana, assert success.
}

Use GameScenario + GameRunner per the card-test skill to drive the ETB rather than hand-rolling ResolvedAbility (which would re-introduce the SHAPE-test blind spot). The assertion that fails today is granted_to == PlayerId(0) on the opponent-owned card.

---

6. Risks

• Blast radius of the grantee change. Every AbilityController PlayFromExile/Plot/Foretell grant flows through this path. Mitigation: original_controller is None for all non-player_scope grants, so unwrap_or(ability.controller) is a no-op for them — the change is observable only inside a player_scope fan-out. Verify the existing grant_permission.rs tests (grantee_ability_controller_binds_to_caster, the single-use/tracked-set tests) stay green; they construct abilities with original_controller: None.
• ObjectOwner / ParentTargetController must NOT change. Jeleva-class cards rely on per-owner/per-target binding. The fix touches only the AbilityController arm and its paired exiled_by_ability_controller stamp; leave the other two grantees untouched. Add a brief code comment marking the CR 109.5 vs CR 108.3 boundary so a future edit doesn't "unify" them.
• Once-per-turn slot accounting. live_collection_counter_play_permission_source (casting.rs:1574) and exile_play_permissions_used already key off the live battlefield source and are controller-correct; the fix doesn't touch them. Confirm collection_counter_play_permission_is_once_per_turn (casting.rs:24618) still passes.
• Multiplayer (3–4 player). With player_scope: All over 3+ players, every non-controller library now grants to P0. Worth one assertion in a 3-player variant that P2's exiled card is also P0-playable (and that P1/P2 cannot play it). Low risk — same code path — but cheap to cover.

---

7. ROI — the play-from-exile-marked-cards class

This is not a one-card fix. The corrupted-binding pattern hits every card whose grant runs inside a player_scope/per-opponent fan-out where "you" should stay the controller:

• Evelyn, the Covetous (collection counters, each player's library) — the report.
• Jeleva, Nephalia's Scourge and similar "exile from each opponent's library, you may play them" cards that route through AbilityController rather than ObjectOwner.
• Future "exile the top card of each player's library, you may play those cards" designs (a recurring WotC template) — they all lower to player_scope: All + Controller-scoped exile + a you-scoped grant, so they all share this binding.

Fixing the grantee-resolution-during-fan-out at the building-block layer (grant_permission::resolve) covers the whole class, not just Evelyn. The companion test-quality fix (drive the trigger, don't hand-build the permission) closes the SHAPE-test blind spot that let this ship green.