[Card Bug] Mass zone move feeding a scalar "that much/that many" consumer resolves per-recipient/max instead of the total (Valakut Exploration)

[dan-blanchard]

Card(s)

Valakut Exploration (first witness). Class: any <mass zone move>, then <effect> that much/that many to each player/opponent chain.

Build/version

Current main (14b11cf5b), observed with the parse landed by the Valakut Exploration misparse fix (PR forthcoming, will be linked here).

Actual behavior

When a ChangeZoneAll completes and a chained sub-effect consumes Ref(EventContextAmount), the amount each recipient reads is not the total number of cards moved:

• effects/mod.rs::previous_effect_counts_by_player_from_events (~7411) tallies the completed move's ZoneChanged events per owner;
• install_previous_effect_counts_by_player (~7476) installs that per-player table and sets last_effect_count/last_effect_amount to the per-player max, not the total;
• the parent-effect postlude (~10105–10118) runs this before the sub resolves;
• DamageEachPlayer (deal_damage.rs:~2268) resolves per-recipient via resolve_quantity_scoped_with_targets, whose EventContextAmount cascade (quantity.rs:~3686) consults the per-player table before the scalar channels — so each opponent reads its own swept-card count.

Concretely for Valakut Exploration ("put them into their owner's graveyard, then this enchantment deals that much damage to each opponent"): in the card's native pattern every swept card is the controller's own (impulse-exiled off their library), so each opponent's per-player count is 0 and the chained damage resolves for 0 — while coverage counts the card supported with no warning. A mixed-ownership pool (one P0-owned + one P1-owned card) resolves −1/0 — discriminating the per-player-table mechanism from both scalar candidates (stamped total 2 would give −2/−2; installed max would give −1/−1).

Expected behavior

"That much" is the total number of cards moved by the preceding clause (CR 608.2c — later text reads the earlier action's result; matches the card's official ruling). Two cards swept → each opponent is dealt 2. Note there is currently no QuantityRef that can encode the total after the install (the scalar channel itself holds the max), so this needs an engine-side channel rather than a parser workaround.

Steps to reproduce

crates/engine/tests/integration/valakut_exploration_end_step_exile_sweep.rs (landing in the linked PR) carries three CHARACTERIZATION assertions with explicit update-me markers — they are the acceptance criteria for this issue:

• T1 (mixed-ownership pool, 2 cards): currently −1/0 → should be −2/−2
• T2 (native landfall pattern, 1 controller-owned card): currently 0 → should be −1
• T4 (foreign-link hostile, 1 linked card): currently 0 → should be −1

The sweep/gate/link-tracking semantics around them are fully proven (revert-discriminating); only the amount channel is characterized.

Additional context

Found by a downstream consumer's structural cross-check while fixing the card's parser-side misparse (existential intervening-if + swallowed conjunct). The parse now emits the proven DamageEachPlayer{Ref(EventContextAmount), Opponent} shape (Shadowheart's), which is target-state-correct — the gap is exclusively in how the amount channel aggregates after a mass move.

[mike-theDude]

Triage analysis

Clarified summary
A mass zone move followed by that much/that many installs per-player or maximum counts instead of the total moved-object count, so scalar consumers such as Valakut Exploration deal the wrong amount.

Expected behavior
Every recipient reads the total number of cards moved by the preceding mass move.

Observed behavior
Recipients read their own ownership bucket, while the scalar fallback holds the maximum bucket rather than the total.

Reproduction status
The report supplies three discriminating characterization cases, including mixed ownership and the card's native controller-owned pattern.

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

Valakut Exploration

Landfall — Whenever a land you control enters, exile the top card of your library. You may play that card for as long as it remains exiled.
At the beginning of your end step, if there are cards exiled with this enchantment, put them into their owner's graveyard, then this enchantment deals that much damage to each opponent.

Investigation findings
Coverage explicitly marks the mass_move_total_damage child unsupported. The engine analysis identifies the per-player count installation seam and explains why a parser workaround cannot supply the missing total.

Likely scope
Engine event-context quantity aggregation after ChangeZoneAll.

Acceptance criteria

• The scalar event amount equals the total successful moves.
• Per-player count consumers retain their existing scoped values.
• Mixed-ownership and native Valakut patterns deal the same total to each opponent.

Related issues
No exact duplicate was found.

[mike-theDude]

Classifier analysis

Verdict: unsupported_aspect

Matched clause: At the beginning of your end step, if there are cards exiled with this enchantment, put them into their owner's graveyard, then this enchantment deals that much damage to each opponent. (supported: False)

Reasoning: The matched damage child is explicitly supported:false as mass_move_total_damage, which is the exact amount channel reported here.

---

Posted by bug-coverage-classifier skill.

[matthewevans]

Fixed by merged #7277 (69ce21a8ec): install_previous_effect_counts_by_player now retains recipient buckets while stamping scalar last_effect_count/last_effect_amount as their total. The merged Valakut Exploration integration suite covers the mixed-ownership total, native landfall path, and foreign-link boundary described in this issue.