0007: Stack and priority

Status: Accepted. Item 3 amended by decision 0016 (priority lines required only while the stack is not empty).

Context

The prototype records objects arriving on the stack (appears on stack), leaving it (gone (resolved)), and loose has priority lines. Stack order can only be reconstructed by reading events in sequence. Once several spells and abilities are stacked, with players responding to each other, a reader has to scroll back through the timeline to work out what is on the stack and what resolves next. Example: in the prototype's Sowing Mycospawn sequence, the spell itself sits on the stack beneath its two cast triggers, which is easy to miss.

Every time priority passes, the stack can change: the other player can respond with a spell or ability, and objects resolve or are countered. Restrictions such as split second or Teferi, Time Raveler limit what a player may do with priority, but the player still receives it.

Decision

1. Stack events are recorded in order. Every object put onto the stack and every object leaving it is an event. Simultaneous triggers are written in the order they were put on the stack, which records the controller's ordering choice.
2. Leaving the stack always has a defined reason, with a cause: resolved, countered, did not resolve because all its targets became illegal, or removed from the stack. "Gone (reason)" free text is replaced.
3. Priority is recorded explicitly. Receiving priority and passing priority are both events. This shows response windows (a player who could have responded and passed) and makes "all players passed, the top object resolves" visible rather than inferred.
4. A stack snapshot accompanies priority when the stack is not empty. Whenever a player receives priority with objects on the stack, a Stack: block lists the full stack, top first. Each entry shows its instance ID, what it is (spell name or ability text), its controller, and its choices and targets.
5. Snapshots are checkable. A stack snapshot MUST equal the stack produced by replaying the events. A mismatch makes the file invalid, unless an incompleteness marker covers the gap.
6. Restrictions are not recorded. The file records what happened, not what was legal. Restrictions like split second come from objects already recorded in the file, and players still receive priority under them.

Illustrative only; exact syntax is defined in the spec:

1:57  PlayerB has priority
      Stack:
        1. #15 trigger of Sowing Mycospawn #2: "When you cast this spell, if it was kicked, exile target land." targets Urza's Tower #11
        2. #14 trigger of Sowing Mycospawn #2: "When you cast this spell, search your library for a land card..."
        3. #2 Sowing Mycospawn, kicked

Rules basis

Checked against the Comprehensive Rules effective 2026-09-25.

• 405.2: "Each time an object is put on the stack, it's put on top of all objects already there." The stack is last in, first out, so it can be rebuilt from events, and a snapshot can be checked against them.
• 405.3, 603.3b: simultaneous objects go on the stack in APNAP order, and each player chooses the relative order of their own triggered abilities. The order of the stack events records that choice.
• 405.5, 117.4, 608.1: when all players pass in succession, the top object resolves (or the step ends if the stack is empty). Passes are the events that cause resolution.
• 117.3b, 117.3c, 117.3d: the active player receives priority after a resolution, a player keeps priority after casting or activating, and passing gives priority to the next player. Priority is a sequence of events that can be recorded.
• 701.6a: a countered spell or ability is removed from the stack without resolving. 608.2b: a spell or ability whose targets have all become illegal does not resolve. 603.3d: a triggered ability with no legal choices is removed from the stack. These are the defined reasons for leaving the stack other than resolving.
• 702.61a, 702.61b: split second stops players from casting spells and activating non-mana abilities, but mana abilities, special actions, and triggered abilities still work, and players still receive priority. Restrictions shape what a player could do, not whether priority events happen.

Alternatives rejected

• No stack snapshots, stack derived from events only. Rejected: correct but unreadable for complicated stacks, which are exactly the moments a replay most needs to explain.
• A separate per-game stack section listing each stack object once with its full history. Rejected as the primary view: it answers "what happened to this spell" but not "what was on the stack together at this moment". Viewers can still build it from events.
• Recording only priority actions, not passes. Rejected: hides response windows and makes resolution an inference.

Consequences

• Files are longer during complicated stack interactions, by one snapshot per priority point.
• The spec must define the stack snapshot grammar, the leave-stack reasons, and priority events, plus conformance fixtures with a snapshot that does not match the events.