Engine panic: "accepted reveal cannot clear a buried continuation: UnexpectedTop { expected: AbilityContinuation, actual: BatchDelivery }" (engine_resolution_choices.rs)

[mcbradd]

Assertion

thread 'ai-commander-driver' panicked at crates\engine\src\game\engine_resolution_choices.rs:3413:22:
accepted reveal cannot clear a buried continuation: UnexpectedTop { expected: AbilityContinuation, actual: BatchDelivery }

On the optional && decline_runs_continuation branch of the reveal-choice handler (CR 701.20a), the engine drops the stashed decline continuation via clear_active_ability_continuation(). That call assumes the continuation is the resolution-stack top; here a BatchDelivery frame sits above it, so the clear is refused and the expect aborts the process (exit 101). The assertion is unchanged on main today: crates/engine/src/game/engine_resolution_choices.rs:3762 (@ cbdfa042a).

Like #6867's PromptMismatch, this looks like a detector, not the cause: the stack already had an unexpected frame above the continuation before the reveal was accepted. Suppressing the expect would let the decline branch run against the wrong frame.

Evidence

pod-lab headless 4-player Commander batch, 2000 games, engine pin d960fc8b3, card data f166b930e71c9ccd, K=40 workers, 540 s/game, measurement mode. 38/2000 games (1.9%) exited 101 over 7 distinct assertion sites; 2 of them are this one. Low frequency, but it is a p0-class abort with a recorded seed and a fully saved log for each occurrence, and both candidate decks hit it.

seed	run	difficulty	turn / actions at panic	pod (P0 -> P3)
92000710	plunder	VeryHard	T22 / 400	Smashing Stampede, Angels: They're Just Like Us but Cooler and with Wings, Meren of Clan Nel Toth, Dance of the Elements
93000916	sworn	Hard	T66 / 1800	Ob Nixilis of the Black Oath, Corrupting Influence, Political Puppets, Reap the Tides

Repro shape

ai-commander <card-data-dir> --seed <seed> --difficulty <tier> --feed <4-deck-feed.json>

pod-lab form: bin/ai-commander-single.exe bin/engine-data --seed <seed> --difficulty <tier> --feed <pod>.json, env PHASE_AI_MEASUREMENT=1, one game per process, exit 101 on panic. Exact pod feeds are reconstructable from the recorded seat ids in runs/band-v3/{plunder,sworn}/games.jsonl; happy to attach a feed JSON on request.

Verification status

Recorded deterministically in the 2026-07-28 batch, with the full per-game stdout kept for every one of the 38 panics. Two other seeds from the same evidence pile were re-run today on a newer pin (1b2021e7b) and both still abort with exit 101 in ~8 s solo — seed 92000008 (ChangeZone terminal member, #6209 / #7103) and seed 92000014 (draw bookkeeping, #6822 / #7052) — so the harness and the seed->trajectory mapping are reproducible. The seeds below have not yet been re-run at the newer pin.

Sibling sites from the same batch

#6209 / #7103 (ChangeZone terminal member, 17x) - #6867 (paused-child continuation, 7x) - #6822 / #7052 (draw bookkeeping, 5x) - #6706 (exile-play ledger, 1x).

Filed from pod-lab WS-B4 evidence; no fix attempted.

Claude Code

[mcbradd]

Cross-pin context (and an honest negative)

The 2 occurrences above are from a 2000-game batch at pin d960fc8b3. A second, independent 2000-game batch at the newer pin 1b2021e7b (~500 commits later, card data 4587508ed14801cb) produced 48 panics across 7 sites and zero at this one:

site	@ d960fc8b3 (n=2000)	@ 1b2021e7b (n=2000)	tracking
engine_resolution_choices.rs:3413 (this issue)	2	0	this issue
mana_abilities.rs pending-replacement mana cost	6	17	#7134
effects/mod.rs ChangeZone terminal member	17	14	#6209 / #7103
effects/draw.rs draw bookkeeping	5	8	#6822 / #7052
engine.rs exile-play ledger	1	3	#6706
effects/mod.rs paused-child continuation	7	3	#6867
casting_costs.rs announced entry at finalize	0	2	#4155
types/game_state.rs settlement ordinal overflow	0	1	#7136

Two occurrences in 2000 games is a ~0.1% rate, so zero in the next 2000 games is well within noise and is not evidence of a fix - the two sites that appeared only at one pin each (casting_costs.rs, game_state.rs) show the same pattern in the other direction. The .expect is still present verbatim on main @ cbdfa042a (engine_resolution_choices.rs:3762).

Flagging it so nobody reads "not seen at the newer pin" as "already fixed". If a maintainer would rather close this until it recurs at a current pin, that is a reasonable call - the recorded logs are kept either way.

Claude Code

[mike-theDude]

Triage analysis

Clarified summary
Accepting an optional reveal choice panics when BatchDelivery is above the ability continuation the handler tries to clear.

Expected behavior
The reveal branch removes or resumes only the continuation it owns while preserving intervening delivery frames.

Observed behavior
clear_active_ability_continuation rejects the buried frame layout and the handler's expect aborts.

Reproduction status
Two batch occurrences are recorded with saved stdout. Zero occurrences in a later 2,000-game batch is explicitly not treated as a fix; the exact assertion remains on current origin/main.

Investigation findings
The assertion is a detector of an already-invalid frame ordering, so suppressing it would not be a valid resolution.

Likely scope
Engine resolution-frame ownership around reveal choices and batch delivery.

Acceptance criteria

• Reveal acceptance preserves unrelated frames above its continuation.
• The owned continuation is cleared or resumed deterministically.
• A hostile nested-frame runtime test reaches the former panic path.

Related issues
#6867 is a similar continuation-stack detector but not the same assertion or handler.