fix(engine): give each token battlefield entry its own CR 603.2c occurrence index

Token entries were emitted with `turn_zone_change_index` hardcoded to 0, so
every token entry in a turn aliased onto occurrence #0. The CR 603.2c batched
replay guard dedups on `(definition_ref, turn_zone_change_index)`, so a second
same-turn token batch collided with the first and its batched trigger fire was
swallowed.

Route token births through `restrictions::record_zone_change`, the single
authority that assigns the index and performs the CR 403.3 battlefield-entry
bookkeeping. The three co-located `record_battlefield_entry` calls are deleted
in the same change, since the recorder does it and a second call double-counts.

This exposed a live/replay desync in the CR 733 resolved-commands journal: the
live path now pushes a ledger record for a token birth, but
`apply_resolved_token_creation` did not, so a journaled token birth followed by
a same-turn zone change failed closed with `TurnRecordIndexMismatch`. The
replayer now reconstructs the entry record and records it through the same
authority, which also closes a pre-existing gap where replay skipped the
CR 403.3 bookkeeping entirely. Reconstruction rather than a new command field,
so the serialized journal surface is unchanged.

The same applier also skipped token ability injection. It now dispatches on the
body variant, mirroring the live seam: a Copy body gets `finalize_copied_token`
+ the predefined-only injector (CR 707.2 + CR 702.33a strip cast-only
characteristics off a token copy); a Spec body gets the catalog injector.

Known ceiling, documented at the seam: the live journal point precedes entry
counters, `attach_to`, and injection, so a replayed record can still differ from
live for counter-carrying and Role/Aura token births. Closing those requires
moving the live record point and is out of scope here.

Note: `apply_resolved_token_creation` has no production caller yet — this is
replay fidelity ahead of wiring, exercised by the cr733 suites.

Verification (measured):
  cargo test -p engine    21975 passed / 0 failed / 15 ignored
  revert-probe: deleting the body dispatch fails 2 tests; replacing it with a
  blanket injector fails exactly 1, so both arms are separately load-bearing.

Assisted-by: ClaudeCode:claude-opus-4.8

Author: lgray

crates/engine/src/game/effects/incubate.rs

@@ -96,7 +96,8 @@ pub fn resolve(
     // token (escalates to a full pass if it sources effects, carries
     // counters, etc.).
     crate::game::layers::mark_layers_entered(state, obj_id);
-    crate::game::restrictions::record_battlefield_entry(state, obj_id);
+    // CR 403.3 battlefield-entry bookkeeping is done by `record_zone_change` below —
+    // recording it here too would double-count `battlefield_entries_this_turn`.
     crate::game::restrictions::record_token_created(state, obj_id);
 
     // CR 603.6a: The Incubator token enters the battlefield as a zone change
@@ -109,14 +110,21 @@ pub fn resolve(
     // triggers (issue #4238). Mirrors
     // `token.rs::apply_create_token_after_replacement_with_created_ids` and
     // `conjure.rs`'s identical fix for the same bug class.
-    let zone_change_record = state
+    //
+    // CR 400.7 + CR 603.2c: route the record through `restrictions::record_zone_change` — the
+    // single authority that assigns this turn's zone-change index — and write the assigned index
+    // back onto the emitted record. `snapshot_for_zone_change` leaves it at its `0` placeholder,
+    // and the batched zone-change replay guard (`triggers.rs`) dedups on
+    // `(definition_ref, turn_zone_change_index)` read off the EVENT, so an unrouted record aliases
+    // this Incubator onto occurrence `0` and a `batched: true` ETB trigger that already fired for
+    // another entry this turn is swallowed. Same shape as `merge.rs` and `token.rs`.
+    let mut zone_change_record = state
         .objects
         .get(&obj_id)
         .expect("incubator token was just created")
         .snapshot_for_zone_change(obj_id, None, Zone::Battlefield);
-    state
-        .zone_changes_this_turn
-        .push_back(zone_change_record.clone());
+    zone_change_record.turn_zone_change_index =
+        crate::game::restrictions::record_zone_change(state, zone_change_record.clone());
     events.push(GameEvent::ZoneChanged {
         object_id: obj_id,
         from: None,

crates/engine/src/game/effects/token.rs

@@ -950,7 +950,8 @@ pub(crate) fn apply_create_token_after_replacement_with_created_ids(
         // continuous effect / carries counters / etc., or if any active effect
         // reads board population.
         crate::game::layers::mark_layers_entered(state, obj_id);
-        crate::game::restrictions::record_battlefield_entry(state, obj_id);
+        // CR 403.3 battlefield-entry bookkeeping is done by `record_zone_change` inside
+        // `push_committed_token_entry_events` below — recording it here too double-counts.
         crate::game::restrictions::record_token_created(state, obj_id);
 
         // CR 303.4 + CR 303.7: A Role/Aura token created "attached to" a host
@@ -980,25 +981,16 @@ pub(crate) fn apply_create_token_after_replacement_with_created_ids(
         // Battlefield }` so every ETB trigger matcher (Elvish Vanguard, Soul
         // Warden, Panharmonicon) fires for tokens through the same code path
         // used for normal battlefield entry. The accompanying `TokenCreated`
-        // event is preserved below for token-specific consumers (animation,
-        // logging, `LastCreated` target filters).
-        let zone_change_record = state
-            .objects
-            .get(&obj_id)
-            .expect("token just created")
-            .snapshot_for_zone_change(obj_id, None, Zone::Battlefield);
-        events.push(GameEvent::ZoneChanged {
-            object_id: obj_id,
-            from: None,
-            to: Zone::Battlefield,
-            record: Box::new(zone_change_record),
-        });
-
-        events.push(GameEvent::TokenCreated {
-            object_id: obj_id,
-            name: spec.characteristics.display_name.clone(),
-            source_id: spec.source_id,
-        });
+        // event is emitted for token-specific consumers (animation, logging,
+        // `LastCreated` target filters). Single authority for both, and for the
+        // CR 400.7 zone-change index the batched replay guard keys on.
+        push_committed_token_entry_events(
+            state,
+            obj_id,
+            spec.characteristics.display_name.clone(),
+            spec.source_id,
+            events,
+        );
 
         // CR 603.7: Tokens with a limited duration get a delayed sacrifice trigger.
         // Used by Mobilize and similar keywords that create temporary attacking tokens.
@@ -1122,6 +1114,60 @@ pub fn apply_resolved_token_creation(
     state.objects.insert(object_id, object);
     // allow-raw-zone: replay materializes a token birth, which has no from-zone move (CR 111.1 + CR 614.12).
     zones::add_to_zone(state, object_id, Zone::Battlefield, command.owner);
+    // CR 111.3 + CR 111.10: a token's abilities come from the creating effect
+    // and the predefined/catalog tables, NOT from the body the command carries,
+    // so the body alone materializes a Treasure with no "{T}, Sacrifice this
+    // token: Add one mana of any color." Both live paths inject after
+    // materializing and before their entry snapshot (Spec: this file, above the
+    // `push_committed_token_entry_events` call; Copy: `token_copy.rs`'s
+    // `finalize_copied_token` + `inject_predefined_token_abilities`), so replay
+    // does the same here, per body variant. The dispatch mirrors
+    // `finalize_committed_liminal_token_entry_from_action`'s
+    // `LiminalTokenAbilityInjection` match arm-for-arm — a blanket
+    // `inject_resolved_token_abilities` would be wrong for the Copy body, whose
+    // live authority uses the predefined-only injector after
+    // `finalize_copied_token`'s CR 707.2 cast-only strip.
+    match &command.body {
+        ResolvedTokenBody::Copy { copy, .. } => {
+            super::token_copy::finalize_copied_token(state, copy.source_id, object_id);
+            inject_predefined_token_abilities(state, object_id);
+        }
+        ResolvedTokenBody::Spec { .. } => inject_resolved_token_abilities(state, object_id),
+    }
+    // CR 400.7 + CR 403.3: the resolve path records the birth through
+    // `restrictions::record_zone_change` (`push_committed_token_entry_events`),
+    // which appends to this turn's zone-change ledger and assigns the entry's
+    // index. Replay must record the same entry: the ledger length IS the index
+    // allocator, so a birth that records nothing leaves every later replayed
+    // zone change one short of its recorded `turn_zone_change_index` and
+    // `apply_resolved_zone_change` fails closed on `TurnRecordIndexMismatch`.
+    // The record is reconstructed from the materialized object rather than
+    // carried on the command: it is a projection of state this applier has
+    // already installed.
+    //
+    // KNOWN CEILING — two record-visible classes the reconstruction cannot
+    // reproduce, both because the LIVE journal point (`record_token_creation`,
+    // in the resolve path above) runs BEFORE the live mutations and before the
+    // live snapshot, so no call site inside THIS applier can close them; they
+    // would need the live journal-record point moved:
+    //   (i)  `spec.enter_with_counters` — the live snapshot's
+    //        `trigger_source_context.lki.counters` (and P/T, if the counter's
+    //        layer bump landed first) carry the entry counters. Counters replay
+    //        through their own `ObjectCounter` command, journaled AFTER this
+    //        birth, so the reconstructed record here has none.
+    //   (ii) `spec.attach_to` (Role/Aura tokens) — `record.attached_to`. Same
+    //        reason: attachment replays through the Attachment family.
+    // A third class, predefined/catalog ability injection contributing
+    // `record.trigger_definitions`, IS closed — by the injection dispatch
+    // directly above, which runs before this snapshot exactly as the live paths
+    // do. Storing the live record on the command would not close (i) or (ii)
+    // either, for the same ordering reason, so it was not done.
+    let entry_record = state
+        .objects
+        .get(&object_id)
+        .expect("the token was materialized above")
+        .snapshot_for_zone_change(object_id, None, Zone::Battlefield);
+    crate::game::restrictions::record_zone_change(state, entry_record);
     // CR 111.1: replay must not hand the same id out again to a later allocation.
     state.next_object_id = state.next_object_id.max(command.resulting_next_object_id);
     // CR 613.7d: the birth drew an entry timestamp alongside the object id, and
@@ -1475,15 +1521,6 @@ pub(crate) fn continue_liminal_copy_token_batch_after_counter_pause(
     )
 }
 
-pub(crate) fn commit_liminal_token_entry_with_event_emission(
-    state: &mut GameState,
-    event: ProposedEvent,
-    events: &mut Vec<GameEvent>,
-    entry_events: TokenEntryEventEmission,
-) -> bool {
-    commit_liminal_token_entry_with_post_actions(state, event, events, entry_events, Vec::new())
-}
-
 pub(crate) fn commit_liminal_token_entry_with_post_actions(
     state: &mut GameState,
     event: ProposedEvent,
@@ -1662,7 +1699,8 @@ pub(crate) fn finalize_committed_liminal_token_entry_from_action(
         }
     }
     crate::game::layers::mark_layers_entered(state, object_id);
-    crate::game::restrictions::record_battlefield_entry(state, object_id);
+    // CR 403.3 battlefield-entry bookkeeping is done by `record_zone_change` inside
+    // `push_committed_token_entry_events` below — recording it here too double-counts.
     crate::game::restrictions::record_token_created(state, object_id);
 
     if enters_attacking {
@@ -1710,15 +1748,33 @@ pub(crate) fn finalize_committed_liminal_token_entry_from_action(
     true
 }
 
+/// CR 603.6a + CR 400.7: emit a token's battlefield-entry events, recording the entry through
+/// [`crate::game::restrictions::record_zone_change`] — the single authority that assigns this
+/// turn's zone-change index and performs the CR 403.3 battlefield-entry bookkeeping.
+///
+/// The index matters: `GameObject::snapshot_for_zone_change` leaves
+/// `turn_zone_change_index` at its `0` placeholder for the recorder to overwrite, and the
+/// CR 603.2c batched zone-change replay guard (`triggers.rs`) dedups on
+/// `(definition_ref, turn_zone_change_index)`. A token entry that never reached the recorder
+/// therefore shipped index `0` on the wire, so a SECOND same-turn token batch collided with the
+/// first and its batched trigger fire was swallowed.
+///
+/// Callers must NOT also call `record_battlefield_entry` — `record_zone_change` does it, and a
+/// second call double-counts `battlefield_entries_this_turn`.
 pub(crate) fn push_committed_token_entry_events(
-    state: &GameState,
+    state: &mut GameState,
     object_id: ObjectId,
     name: String,
     source_id: ObjectId,
     events: &mut Vec<GameEvent>,
 ) {
-    if let Some(token) = state.objects.get(&object_id) {
-        let zone_change_record = token.snapshot_for_zone_change(object_id, None, Zone::Battlefield);
+    let entry = state
+        .objects
+        .get(&object_id)
+        .map(|token| token.snapshot_for_zone_change(object_id, None, Zone::Battlefield));
+    if let Some(mut zone_change_record) = entry {
+        zone_change_record.turn_zone_change_index =
+            crate::game::restrictions::record_zone_change(state, zone_change_record.clone());
         events.push(GameEvent::ZoneChanged {
             object_id,
             from: None,

crates/engine/src/game/effects/token_copy.rs

@@ -835,6 +835,14 @@ pub(crate) fn apply_copy_token_after_replacement_with_created_ids(
         }
 
         // CR 111.10: Predefined token abilities for known subtypes (Treasure, Food, etc.).
+        //
+        // PAIRED WITH THE REPLAY ARM at `token::apply_resolved_token_creation`'s
+        // `ResolvedTokenBody::Copy` match arm, which must call the same
+        // predefined-only injector. Unlike the liminal path — where one
+        // `copy_resume.is_some()` predicate drives both the live and journaled
+        // matches, so a divergence fails to compile — this branch is coupled to
+        // replay by convention only. Switching it to the catalog-wide
+        // `inject_resolved_token_abilities` would silently desync replay from live.
         super::token::inject_predefined_token_abilities(state, token_id);
         // Battlefield entry of a copy token: request an incremental re-derive
         // for just this token. `flush_layers` escalates to a full pass when

crates/engine/src/game/engine_replacement.rs

@@ -1774,11 +1774,35 @@ pub(super) fn handle_copy_target_choice(
                 }));
             }
         }
-        if !super::effects::token::commit_liminal_token_entry_with_event_emission(
+        // CR 403.3 + CR 603.6a: the commit applies the token's enter-with-counters, which can
+        // PAUSE on a CR 616.1 ordering choice between two AddCounter replacements. On that pause
+        // the only stashed post-action is the entry finalization, and its `Suppress` emission mode
+        // means the finalize tail neither emits the entry events nor (since the entry record is now
+        // written by `record_zone_change` inside `push_committed_token_entry_events`) records the
+        // entry at all — the token would enter invisibly. Hand the emit down as a post-finalize
+        // action so the paused path still performs the entry EMIT the unpaused one performs below.
+        // Only the emit: on a pause this function returns at the `commit_liminal_token_entry_*`
+        // call below, so the unpaused tail's CR 614.12a `BecomeCopy` chain,
+        // `finish_copy_target_choice_entry`, and the copy continuation do not run on that route.
+        // That abandonment is pre-existing and is not what this hand-down addresses. Dropped
+        // unused when the commit does not pause.
+        let paused_entry_emit: Vec<PendingCounterPostAction> = entry_events
+            .clone()
+            .map(
+                |(name, event_source_id)| PendingCounterPostAction::EmitCommittedCopyTokenEntry {
+                    object_id: source_id,
+                    name,
+                    source_id: event_source_id,
+                },
+            )
+            .into_iter()
+            .collect();
+        if !super::effects::token::commit_liminal_token_entry_with_post_actions(
             state,
             resume_event,
             events,
             TokenEntryEventEmission::Suppress,
+            paused_entry_emit,
         ) {
             return Ok(state.waiting_for.clone());
         }

crates/engine/src/game/restrictions.rs

@@ -379,9 +379,9 @@ pub(crate) fn battlefield_entry_record_for(
         subtypes: obj.card_types.subtypes.clone(),
         supertypes: obj.card_types.supertypes.clone(),
         colors: obj.color.clone(),
-        // CR 403.3: snapshot the object's keywords at entry time. This is the
-        // printed/base + counter-granted keyword set (pre-layer; see the field doc
-        // on BattlefieldEntryRecord.keywords for the documented Layer-6 limitation).
+        // CR 403.3: snapshot the object's keywords at entry time — whatever the layer
+        // state is at the caller's record point (pre-flush for most entries, post-flush
+        // for an attached token). See the field doc on `BattlefieldEntryRecord.keywords`.
         keywords: obj.keywords.clone(),
         controller: obj.controller,
     }

crates/engine/src/types/game_state.rs

@@ -1719,10 +1719,15 @@ pub struct BattlefieldEntryRecord {
     /// with flying entered this turn") evaluate via the CR 603.10 last-known-state
     /// against entry-time characteristics (like the existing core_types/colors
     /// snapshots). KNOWN LIMITATION: this captures the object's keywords at record
-    /// time, which is BEFORE the layer system re-evaluates (layers are only marked
-    /// dirty, not recomputed, at zone-change). Printed flyers and keyword-counter /
-    /// intrinsic flyers are counted; a creature granted flying ONLY by a Layer-6
-    /// continuous effect (e.g. an anthem) at the moment it enters is NOT counted.
+    /// time, which for most entries is BEFORE the layer system re-evaluates (layers
+    /// are only marked dirty, not recomputed, at zone-change). Printed flyers and
+    /// keyword-counter / intrinsic flyers are counted; a creature granted flying ONLY
+    /// by a Layer-6 continuous effect (e.g. an anthem) at the moment it enters is NOT
+    /// counted. EXCEPTION — a token created attached to a host (Role/Aura tokens):
+    /// `effects::attach::attach_to` runs `mark_layers_full` + `flush_layers`, and the
+    /// token path records its entry AFTER the attach, so that sub-path's snapshot IS
+    /// post-flush and does see Layer-6 grants. Not a defect: the paired
+    /// `ZoneChangeRecord` has always been taken post-attach, so the two ledgers agree.
     #[serde(default, skip_serializing_if = "Vec::is_empty")]
     pub keywords: Vec<Keyword>,
     pub controller: PlayerId,

crates/engine/tests/integration/combo_infinite_pile.rs

@@ -3076,6 +3076,52 @@ fn opponents_etb_life_gainer_does_not_suppress_your_axis() {
     );
 }
 
+/// R4-C1 COMBINED GATE (4a + 4b together; per-commit green is explicitly insufficient).
+///
+/// The same ETB life gainer as `batched_and_replay_routes_converge_on_the_same_life_total`, but
+/// with `batched: true` — the "Whenever ONE OR MORE creatures you control enter, you gain 1 life"
+/// shape (CR 603.2c). Collapsing at N now produces N SEPARATE same-turn token batches (one per
+/// replayed cycle), so the total is right only if BOTH fixes hold:
+///
+/// * 4a (route): the ETB-sourced axis must take the concrete replay. Reverting it re-introduces
+///   the batched `Life` on top of the real entries ⇒ amplified over-count.
+/// * 4b (index): each replayed cycle's entry must carry its OWN zone-change index. Reverting it
+///   leaves every entry on the `0` placeholder, so `batched_zone_change_already_collected` keys
+///   all N batches to `(def, 0)` and only the FIRST fires ⇒ the trigger-count assertion fails.
+///
+/// Both revert-probes were RUN; observed values are in the assertion messages.
+#[test]
+fn combined_batched_etb_gainer_fires_once_per_replayed_cycle() {
+    const N: u32 = 5;
+    let mut state: GameState = serde_json::from_str(&OFFER_STATE)
+        .expect("the real 4p offer dump must deserialize into the current GameState");
+    strip_life_conditional_cost_static(&mut state);
+    let mut batched_gainer = innkeeper_etb_life_trigger(&state);
+    batched_gainer.batched = true;
+    let host = create_life_gainer(&mut state, P0, "Grafted Batched Innkeeper");
+    graft_trigger(&mut state, host, batched_gainer);
+
+    drive_all_accept_n(&mut state, N);
+    assert_eq!(
+        route_labels(&state, P0),
+        vec!["DriveSequence".to_string()],
+        "4a: a batched ETB life gainer still routes the axis to the concrete replay"
+    );
+
+    let life_before = life_of(&state, P0);
+    let minted = collapse_at(&mut state, N);
+
+    // POSITIVE reach-guard: N cycles really replayed.
+    assert_eq!(minted, N as usize, "the replay minted one token per cycle");
+    // DISCRIMINATOR (needs BOTH fixes): N distinct same-turn batches ⇒ N fires ⇒ +N.
+    // revert 4b ⇒ all N batches collide on `(def, 0)` ⇒ +1. revert 4a ⇒ batched Life on top ⇒ >N.
+    assert_eq!(
+        life_of(&state, P0) - life_before,
+        N as i32,
+        "each replayed cycle is its OWN batch and fires once (revert 4b ⇒ 1, revert 4a ⇒ more)"
+    );
+}
+
 /// NON-`GainLife` LIFE SOURCE (CR 732.2a + CR 603.6a + CR 702.15b): the Terror-of-the-Peaks
 /// shape — an ETB *damage* trigger on a permanent with LIFELINK. The life axis is just as
 /// ETB-sourced as Soul Warden's, but it never passes through `Effect::GainLife`: it reaches