Ark of Hunger Doesn't Let You Play from the Yard — Ark of Hunger can be tapped to mill a card and then you can play tha…

[matthewevans]

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

Thread: Ark of Hunger Doesn't Let You Play from the Yard
Cards: ark of hunger
Parser status: fully_parsed
Extraction confidence: 0.90

Summary

Ark of Hunger can be tapped to mill a card and then you can play that card from the graveyard this turn.

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

ark of hunger

Whenever one or more cards leave your graveyard, this artifact deals 1 damage to each opponent and you gain 1 life.
{T}: Mill a card. You may play that card this turn.

---

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

[matthewevans]

🤖 Implementation Plan

Summary / Verdict

Confirmed bug. Ark of Hunger parses fully and correctly — the failure is purely in the runtime cast/play machinery. The card mills a card to the graveyard and grants a PlayFromExile permission attached to that graveyard card, but every site that consults PlayFromExile is hard-gated to obj.zone == Zone::Exile. The milled card therefore carries a live, correct permission that is never inspected, so it never appears as castable/playable.

This is a class bug, not a one-off. The parser emits the identical Mill → GrantCastingPermission(PlayFromExile, TrackedSet 0) shape for every "mill … you may play that card this turn" card.

Root-cause analysis (file:line evidence)

1. The parse is correct. jq '."ark of hunger".abilities' shows:

{T}: Mill 1 (Controller, → Graveyard).
  sub: GrantCastingPermission { permission: PlayFromExile { duration: UntilEndOfTurn }, target: TrackedSet { id: 0 } }

The grant target is TrackedSet { id: 0 } — the sentinel that binds to the set the immediately-preceding effect published.

2. Mill publishes its tracked set, so the permission lands on the right object. crates/engine/src/game/effects/mod.rs:2707 maps Effect::Mill → ThisWayCause::Milled and :2815 records the milled card's destination, feeding publish_tracked_set_with_causes (mod.rs:3029). grant_permission::resolve (crates/engine/src/game/effects/grant_permission.rs:45-52) reads the highest tracked-set id and attaches the PlayFromExile permission to the milled card in the graveyard. So far, fully correct (CR 701.17d — see below).

3. The permission is never consulted because the consult sites gate on Zone::Exile:

• crates/engine/src/game/casting.rs:1399-1405 — exile_object_can_enter_cast_path() requires obj.zone == Zone::Exile.
• crates/engine/src/game/casting.rs:1412-1413 — exile_object_castable_by_permission() (the spell legal-actions filter, called at :521-526) is gated by that helper.
• crates/engine/src/game/casting.rs:3100-3101 — prepare_spell_cast sets has_exile_permission = obj.zone == Zone::Exile && has_exile_cast_permission(...), so a graveyard card with PlayFromExile fails the castable_zone check at :3159-3176 and returns "Card is not in a castable zone".
• crates/engine/src/game/casting.rs:2465-2492 — exile_lands_playable_by_permission() iterates state.exile only, so a milled land with PlayFromExile is also invisible to the land-play path.

The checker itself (play_from_exile_permission_source, casting.rs:1594-1647) is already zone-agnostic — it only inspects obj.casting_permissions. Only the callers impose the exile-zone restriction.

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

• CR 701.17d (line 3408): "If that effect grants a player permission to cast or play 'that' card, the permission applies to each of the milled cards." — This is the controlling rule. A mill-then-play grant must apply to the milled card in the graveyard. This is the exact authority the fix implements.
• CR 701.17a (line 3402): milled cards go from library to graveyard.
• CR 701.17c (line 3406): an effect referring to a milled card finds it in the graveyard (public zone).
• CR 400.7g/h (lines 1962-1964): a granted cast permission follows the card to the stack — already handled by the existing PlayFromExile finalize path; no change.
• CR 601.2a (line 2455): proposing a cast moves the card from its current zone (here, graveyard) to the stack.

Files & functions to change

The fix makes the object-tagged PlayFromExile consult sites zone-aware so they admit graveyard cards, mirroring how the exile sites already work. The permission, checker, parser, and Mill resolver are all correct and need no changes.

1. crates/engine/src/game/casting.rs — exile_object_can_enter_cast_path (~1399)
   This is the central spell-path gate. Generalize it to also admit graveyard cards that carry an object-tagged PlayFromExile permission (still excluding lands per CR 305.1, which are played not cast). Concretely: accept obj.zone == Zone::Exile OR (obj.zone == Zone::Graveyard AND the card has a PlayFromExile permission), retaining the non-land guard. This single change flows into both exile_object_castable_by_permission (legal actions, :1407) and the prepare_spell_cast has_exile_permission branch.

2. crates/engine/src/game/casting.rs — prepare_spell_cast has_exile_permission (~3100)
   The local has_exile_permission = obj.zone == Zone::Exile && … must be widened to the same zone predicate (exile OR graveyard-with-PlayFromExile). Rename to reflect that it is now an object-tagged play-permission, not exile-specific. Verify the milled card flows through the existing alt-cost/mana-cost machinery unchanged (it casts at full mana cost — PlayFromExile grants permission, not a cost reduction).

3. crates/engine/src/game/casting.rs — spell legal-actions surface (~521-544)
   The state.exile.iter() extension at :521 will now cover graveyard cards only if they live in state.exile, which they don't. Add a parallel sweep that, for graveyard objects owned by player, admits those whose play_from_exile_permission_source(...) is Some and which pass exile_object_can_enter_cast_path. Cleanest seam: fold this into graveyard_spell_objects_available_to_cast (:593), which already iterates the player's graveyard — add a branch alongside the keyword / static-permission / timed-alt-cost branches that checks the object-tagged PlayFromExile.

4. crates/engine/src/game/casting.rs — exile_lands_playable_by_permission (~2465)
   Rename/extend (or add a sibling graveyard_lands_playable_by_permission) so a milled land carrying PlayFromExile is playable from the graveyard. It currently only iterates state.exile; add a graveyard sweep using the same play_from_exile_permission_source check. Wire the new source into the play-land legal-actions + execution path the same way the exile source is wired.

Building-block discipline: Do not special-case Ark of Hunger. The fix is "object-tagged PlayFromExile is consultable from graveyard as well as exile," expressed once in the shared zone predicate and reused by the cast path, the spell legal-actions surface, and the land-play path. No new enum variant is required (add-engine-variant filter: this is a zone-scope generalization of an existing permission's consult sites, not a new leaf — do not add a PlayFromGraveyard sibling, which would be a sibling-cluster smell against the existing PlayFromExile).

Class coverage (build for the class, not the card)

jq over client/public/card-data.json confirms two current cards emit the broken Mill → GrantCastingPermission(PlayFromExile, TrackedSet 0) shape, both fixed by this single change:

• ark of hunger ({T}: Mill a card. You may play that card this turn.) — verified parse shows Mill (→ Graveyard) then PlayFromExile { TrackedSet 0 }.
• tablet of discovery (ETB trigger: mill a card. You may play that card this turn.) — verified identical broken shape.

(Note: dogmeat, ever loyal matches a naive "mill"+"play that card" text grep, but its play-permission belongs to its Junk token's exile clause, which already works — it is not part of this class. The class predicate is specifically "the play grant binds to a tracked set published by a Mill/graveyard move.")

The fix is forward-compatible with any future "mill N … you may play [those cards] this turn" card and with land cards milled this way.

Test strategy (runtime test driving the real pipeline)

Add a runtime integration test (e.g. crates/engine/tests/ark_of_hunger_play_from_graveyard_751.rs) using the GameScenario / GameRunner cast-pipeline harness (see card-test skill; model on existing impulse-draw integration tests under crates/engine/tests/integration/). The test must drive the real engine, not assert AST shape:

1. Put Ark of Hunger on the battlefield under the active player; stack the library so the top card is a known non-land spell (e.g. a cheap creature) the player can afford.
2. Activate {T} → resolve the Mill + grant.
3. Assert the milled card is now in the graveyard and carries a PlayFromExile permission (state assertion).
4. Assert the milled card appears in the player's legal cast actions (the bug surface — currently absent).
5. Cast it from the graveyard through the pipeline; assert it moves graveyard → stack → resolves, and that mana was paid at full cost.
6. Negative/duration test: after UntilEndOfTurn cleanup prune, the permission is gone and the card is no longer castable from the graveyard (CR 514.2 — the existing prune_end_of_turn_casting_permissions already handles UntilEndOfTurn; confirm it still fires on a graveyard object).
7. Land variant: a second test milling a land and confirming it is playable via the land-play path (covers change chore: update coverage stats and badges #4) and that the milled land never enters the spell-cast path (CR 305.1).

Also add a building-block unit test that exile_object_can_enter_cast_path (or its renamed generalization) returns true for a graveyard non-land with PlayFromExile and false for a graveyard land, mirroring the existing exile-zone unit coverage.

Risk / scope notes

• Blast radius is contained to the object-tagged PlayFromExile consult sites in casting.rs. The permission type, parser, grant_permission::resolve, and Mill resolver are untouched.
• Do not touch the static graveyard-permission path (graveyard_permission_source, Lurrus class) — that is a separate, already-correct mechanism. The new branch must be additive alongside it.
• Grafdigger's Cage / Drannith Magistrate interaction: the existing is_blocked_from_casting_from_zone check (casting.rs:3187) already runs after the castable_zone gate and covers "can't cast from graveyards." Since milled-card casting now legitimately originates from the graveyard, verify Grafdigger's Cage correctly blocks it (it should — CR 601.3 "can't beats can"). Add an assertion or note in the test plan.
• AI / multiplayer: the spell legal-actions surface change automatically exposes the new option to the AI legal-action enumeration and the multiplayer server's legal_actions.contains gate; no separate adapter change needed (engine-owns-all-logic). Confirm the AI does not regress by panicking on a graveyard-origin cast (it routes through the same CastSpell action).
• Frontend: no change — the card surfaces through the standard playable/castable legal-action lists the client already renders.

Verification cadence

cargo fmt --all, then check the test-engine and card-data Tilt resources (this is shared-casting.rs engine plumbing, so use full Rust verification, not the parser-only loop). No parser or card-data regeneration is needed since the parse is already correct.