Non-fatal engine panic: discard provenance must name the active continuation's discard parent

[pascalberger]

What happened
I casted Celebrate the Mountain King

game-state-turn-30-2026-08-10T17-30-22-473Z.json

Diagnostic

Build: v0.50.0 (9dc3970)
Diagnostic tag: ai-getAction-panic
User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Safari/537.36

Panic (engine recovered):
panicked at crates/engine/src/game/zone_pipeline.rs:2411:26: discard provenance must name the active continuation's discard parent

[mike-theDude]

Triage analysis

Clarified summary
Resolving Celebrate the Mountain-king's Recruit trigger can hit the engine assertion that discard provenance must identify the active continuation's discard parent. The engine recovers from the panic, but the action is not safely resolved.

Expected behavior
The draw-discard Recruit chain should associate the delivered discard zone change with its own discard frame, evaluate the discarded-card condition, and continue without a panic.

Observed behavior
The attached build reports the assertion at zone_pipeline.rs. The saved state contains Celebrate the Mountain-king's enter triggers, including the Draw -> Discard -> conditional token Recruit chain, while another enter trigger is also on the stack.

Reproduction status
Confirmed from the diagnostic and attached persisted state. Three exact follow-up reports (#7222, #7223, #7226) reproduce the same assertion on builds 8879b91 and adb0d70.

Investigation findings
The current main branch still requires the active ability continuation to have the exact discard frame as its immediate parent and panics when that positional invariant is not met. This is the successor assertion introduced by the fix for #7087 / #7088, so the earlier repair did not cover this resolution-stack shape.

Likely scope
Engine resolution-stack ownership and terminal discard zone-change provenance for Recruit-style continuations.

Acceptance criteria

• Replaying the attached state completes the Recruit discard without a panic.
• The discard result is recorded on the exact owning discard operation even with sibling or nested trigger work present.
• The conditional Recruit payoff observes the discarded card and priority resumes normally.

Related issues
#7087 is the earlier assertion shape fixed by #7088. #7222, #7223, and #7226 are exact duplicates of this report.

[matthewevans]

Fixed by merged PR #7284 (f5fefdb, 2026-08-12). The fix is specifically titled “Fix Recruit discard provenance,” matching this issue’s active-continuation discard-parent assertion.