feat(engine): drive & collapse accepted CR 732.2a infinite-loop shortcuts at the phase boundary

[lgray]

I've fully playtested this branch end to end and confirmed it correctly offers CR 732.2a loop shortcuts to the user in a live 4-player game: the Witherbloom / Sprout Swarm object-growth loop and the Kilo, Apogee Mind + Freed from the Real + Relic of Legends + Pentad Prism counter loop both surface the shortcut prompt and resolve to the correct board state (naming ~500 counters resolves quickly). The next tasks are to widen the scope of combos that we trigger on and accept.

🤖 AI text below 🤖

Summary

Delivers the acceptance + materialization half of the CR 732.2a loop-shortcut feature. When a player accepts an offered infinite loop at the phase boundary (the offer / opponent response window landed in PR-7 #5672), the engine now drives the loop to a player-named finite count and collapses the unbounded growth axis — copy-token piles, +1/+1 (and other) counters, life, and mana — into the correct terminal board state, rendering ∞ on the affected resource. Covers object-growth loops (tapped token piles) and persistent-axis loops (counters / life / mana) with APNAP accept + interruptibility, a zone-gated object-growth census firewall (CR 603.4 / 603.6a / 113.6), and multi-action loop-shortcut driving for infinite-mana combos.

Multi-commit epic (24 commits) developed on the fork; each component was built through /engine-implementer (plan → review-engine-plan → implement → review-impl).

Implementation method (required)

Method: /engine-implementer

CR references

Core: CR 732.2a / CR 732.2b / CR 732.6 (loop shortcuts + response window), CR 500.4 / CR 500.5 (phase-boundary auto-advance / SBA), CR 603.4 / CR 603.6a / CR 113.6 (zone-gated loop-firewall observer scans), CR 704.5a / CR 704.5f / CR 704.5j (mandatory-loop winner / state-based actions), CR 608.2b–CR 608.2d (per-iteration re-check + predictability). Plus supporting annotations for counters (CR 122.1), life (CR 119), and keyword/interaction rules — ~89 unique CR annotations in the diff, each grepped against docs/MagicCompRules.txt.

Verification

• Required checks ran clean locally, or the exact CI-owned alternative is stated below.
• Gate A output below is for the current committed head.
• Final review-impl below is clean for the current committed head (recent components; note below).
• Both anchors cite existing analogous code at the same seam.

Rebased onto upstream/main (v0.31.0, f4287548f) — clean, no conflicts; branch is 0 behind / 24 ahead. Measured on the rebased head 90ad9da0d:

• Live 4-player playtest (ground truth) — both combos offer the shortcut and resolve to the correct board state; ~500-counter collapse is fast. Confirmed by the maintainer (on the pre-rebase content-equivalent tip; the rebase pulled only upstream parser/card-data/CI changes, which don't touch the loop-shortcut path).
• cargo clippy -p engine --all-targets — clean (0 warnings/errors) post-rebase — the semantic-drift check a clean 3-way merge can hide.
• cargo test -p engine --test integration combo_infinite_pile — 19 passed; 0 failed post-rebase (both real-4p fixture tests ok, including the regenerated Witherbloom untapped-precast dump).
• scripts/build-wasm.sh assert_wasm_stack — PASS: engine_wasm_bg.wasm initial memory min = 365 pages (~22 MiB) — the 16 MiB WASM shadow-stack fix; guards against the accept-time loop-replay stack overflow that dropped the browser engine ("connection lost").
• scripts/check-parser-combinators.sh — Gate A + Gate G PASS (below).
• cargo fmt --all --check — clean.

Full clippy --all-targets --workspace / test / frontend / card-data-coverage / FORGE run on this PR.

Gate A

Gate A PASS head=90ad9da0da8974f468c233e1ab61e1db9388bd45 base=836ff312ae2073c99af28d286b0c4915faa8a458

Anchored on

• crates/engine/src/game/engine_resolution_choices.rs — the SubmitPayAmount LoopCollapse materialization mirrors the pre-existing copy-token batch mint (drive_copy_token_batches) for the counter / life / mana axes.
• crates/engine/src/analysis/resource.rs (+ DerivedViews) — the ∞ render extends PR-6's (feat(engine): ∞ unbounded-resource display for confirmed infinite loops (combo PR-6) #4603) engine-owned unbounded_resources projection over the ResourceAxis class.

Final review-impl

Final review-impl PASS head=90ad9da0da8974f468c233e1ab61e1db9388bd45

(The two most recent components — the WASM shadow-stack fix and the axis-labelled LoopCollapse prompt — ran /review-impl to clean this session; earlier epic components were reviewed through the same pipeline across prior sessions.)

Claimed parse impact

None — engine game-logic (loop-shortcut acceptance + boundary collapse), not parser card-coverage.

Combo-detector series

Pos	PR	Delivers
PR-0	#4092	ResourceVector + modulo-resource loop equality.
PR-1	#4097	Analysis sim harness feeding ResourceVector.
PR-2	#4119	Net-progress detect_loop → LoopCertificate + corpus harness.
PR-3	#4480	Live mandatory-loop winner shortcut (drain-cascade, CR 704.5a).
PR-4a	#4493	Engine B static ability-graph extractor.
PR-4b	#4534	Engine B effect/trigger breadth + life-symmetry cost.
PR-5	#4547	cargo combo-verify CLI over the corpus.
PR-6	#4603	∞ unbounded-resource display (engine-owned DerivedViews projection).
PR-6.75	#5072	C0-full + C1 read/write conflict-profile precision pass.
PR-7	#5672	Loop shortcut offer + APNAP accept-or-shorten response window (CR 732.2a–c).
this PR	(this PR)	Loop-shortcut acceptance + phase-boundary collapse/materialization — drive an accepted loop to a finite N and collapse the unbounded axis (tokens / counters / life / mana) to the correct terminal board, rendering ∞.

Predecessor: PR-7 — #5672 — #5672 — delivered the CR 732.2a offer + opponent accept-or-shorten window; this PR executes an accepted offer by driving the loop to the player-named count and materializing the collapsed result at the CR 500.5 boundary.

[matthewevans]

Blocked — protected workflow changes require explicit maintainer review; no implementation diff was reviewed.

🔴 Blocker

.github/workflows/deploy.yml: this PR modifies a protected deployment-workflow path. Repository policy treats workflow edits as a hard stop, so this sweep does not evaluate, approve, or enqueue the implementation while that path is present.

Recommendation: remove the protected workflow change into an explicitly maintainer-owned review, then resubmit the implementation-only scope for normal review.

[gemini-code-assist]

Code Review

This pull request implements comprehensive support for CR 732.2a loop-collapse shortcuts and display updates, including rendering the infinity symbol (∞) for unbounded piles and counters on the frontend, and updating the loop-collapse prompt to dynamically name the collapsed axis (Tokens, Counters, Life, or Mixed). It unifies recast and activation loops under a new LoopAction enum, optimizes liminal copy-token creation to prevent stack overflows, and introduces a load migration to clean up stale transient loop sequences. A critical bug was identified in the iterative token-creation logic where created_ids is overwritten rather than accumulated across iterations, which should be resolved using the suggested extend fix.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

There appears to be a bug in the iterative logic for creating liminal tokens. The created_ids vector is being overwritten in each iteration of the loop instead of accumulating the IDs of all created tokens.

Specifically, created_ids = state.last_created_token_ids.clone(); replaces the list of created IDs with a new list containing only the most recently created token's ID. Since commit_liminal_copy_token_entry clears state.last_created_token_ids on each call, this function will incorrectly report that only one token was created for the entire batch.

The fix is to append the new token ID to the created_ids vector in each iteration, for instance by using extend.

Suggested change

	if !super::token::commit_liminal_copy_token_entry(state, event, events) {
	created_ids = state.last_created_token_ids.clone();
	return CopyTokenApplyStatus {
	created_ids,
	completion: CopyTokenApplyCompletion::Paused,
	};
	}
	// CR 707.2: this copy committed; iterate to the next token in the
	// batch (O(1) stack). Terminal drain runs once after the loop.
	created_ids = state.last_created_token_ids.clone();
	if !super::token::commit_liminal_copy_token_entry(state, event, events) {
	created_ids.extend(state.last_created_token_ids.iter().copied());
	return CopyTokenApplyStatus {
	created_ids,
	completion: CopyTokenApplyCompletion::Paused,
	};
	}
	// CR 707.2: this copy committed; iterate to the next token in the
	// batch (O(1) stack). Terminal drain runs once after the loop.
	created_ids.extend(state.last_created_token_ids.iter().copied());

[github-actions]

Parse changes introduced by this PR

✓ No card-parse changes detected.

[lgray]

🤖 AI text below 🤖

CI timeout fix pushed (04d289c69) — and the two AI gates are a ceiling issue, not a feat regression

Both Paired-seed AI gate and Decision-cost perf gate failed on run 29772981579 by hitting the job timeout-minutes: 30 (both cancelled at 30m2x — a wall-clock overrun, not an assertion failure).

Root cause (measured)

The 30m ceiling is too tight for the gates' own debug workload on a slow hosted runner — this PR just triggers the workflow (via .cargo/config.toml), it does not slow the gates. Budget from the failing log:

• Generate card data step alone = ~6.5m on a cache miss (5m03s tool-profile build + 1m27s gen).
• Cold debug build of the gate binary.
• The run itself: paired gate drives 30 games (--games 10 × 3 scenarios) ≈ 34m at the slow-runner ~1.1m/game seen on this run (red-mirror alone was 11.4m); perf gate runs 5 cold child processes × 3 scenarios × 3000 actions ≈ 21m in debug.

Hosted-runner speed varies ~2× (recent passing runs ranged 8m41s–16m06s for the same fixed workload), so a fast runner finishes under 30m while a slow one overruns.

This PR does not regress AI decision cost (measured)

• git diff v0.31.0..HEAD touches zero AI-cost files: crates/phase-ai/** = 0 lines, data/card-data.json unchanged, perf-baseline.json unchanged.
• The engine changes are all loop_detection.samples()-gated → Off in GameState::new_two_player (the gate's constructor), so the CR 732.2a detector never runs in these games.
• Ran cargo ai-perf-gate locally against the committed baseline: 0 FAIL, 28 PASS, 0 NEW, 0 REMOVED — every per-counter median is within tolerance (all deltas ≤ 0).

The fix

04d289c69 raises both PR quick gates timeout-minutes: 30 → 60, with a comment documenting the budget. Coverage (--games 10) and the fixed perf workload are unchanged; the higher ceiling only bills the failure case — same rationale the nightly drift monitor already carries. Nightly variants (300m / 30m) untouched.

On the protected-workflow-path block

Understood that .github/workflows/deploy.yml (and now .github/workflows/ai-gate.yml) are protected paths you gate on. For context on why they're in the branch:

• deploy.yml (+7, actions/setup-node@v4 node-22) is load-bearing for the crash fix: scripts/build-wasm.sh's assert_wasm_stack guard parses the shipped wasm's memory section with node to verify the 16 MiB shadow stack that stops the accept-time loop-replay overflow. release.yml already sets up node for its build-wasm job; this mirrors it for deploy.
• ai-gate.yml (+14) is the timeout raise above — the minimal change to stop the flaky 30m overrun.

These are yours to apply/approve. If you'd prefer the workflow edits land through a maintainer-owned change instead of this feature PR, say the word and I'll drop them here and hand you the exact diffs (deploy.yml node setup + the two timeout-minutes: 60 bumps) to apply separately — the non-workflow parts of the crash fix (.cargo/config.toml stack size, build-wasm.sh guard) would need your workflow change to land first so deploy stays green.

[matthewevans]

Maintainer review complete — no actionable finding on the current head.

✅ Clean

• The protected deployment edit is a bounded prerequisite: .github/workflows/deploy.yml:310-315 installs Node 22 immediately before scripts/build-wasm.sh release, and scripts/build-wasm.sh:39-70 runs the new memory assertion after the engine artifact has passed through wasm-bindgen and optional wasm-opt.
• .github/workflows/ai-gate.yml:26-32,106-112 changes only the two PR-job wall-clock ceilings. The gate commands, game count, perf sample count, and assertion logic are unchanged.
• Gemini's open token_copy.rs:605 concern does not reproduce on this head. Each liminal entry carries the accumulated created_ids into finalization (token.rs:1343); finalization appends the just-committed object and writes the complete ledger (token.rs:1425-1426) before the loop reloads it at token_copy.rs:605. That is accumulation, not overwrite.

Recommendation: approve this head; do not enqueue it from this review.

[matthewevans]

Independent review-impl — head 04d289c69f

Reviewed the full diff (63 files, +13.4k/−1.2k) in a worktree via five parallel deep-reads (game-state threading + migration + serde; loop-drive/phase-boundary; LoopCollapse materialization; the ability_scan.rs census firewall; and the ∞ projection + frontend), plus personal verification of every finding at MED or above. Findings-only; silence = LGTM on a surface.

Confirmed clean (with evidence)

• Gemini's token_copy.rs:605 CRITICAL is refuted — independently, and agreeing with your maintainer review. The batch ledger is carried through LiminalEntry.created_ids (seeded with the running accumulation at token_copy.rs:542) and rebuilt as entry.created_ids + [object_id] in finalization (token.rs:1425-1426), so line 605 reloads the full accumulated list, not a single ID. commit_liminal_copy_token_entry does not clear the vector — Gemini's premise is false.
• New-field / rename threading + serde migration: clean. The RecastContext → LoopActionContext rename is compiler-enforced total (partition destructure at game_state.rs:806); migrate_transient_loop_sequence funnels through every restore path (WASM decode_restored_game_state, both wire decoders); new GameState fields are all #[serde(default, skip_serializing_if)] with back-compat aliases, so old saves deserialize. adapter/types.ts matches the Rust serialized shape for all four new surfaces (LoopCollapseAxis, PayableResource::LoopCollapse, DecisionPointKind::ManaColor, unbounded_counters).
• Census firewall (ability_scan.rs, +3250): clean. No wildcard match arms (fail-closed to CONSERVATIVE); classification is structural, not card-tuned (card names live only in doc-comment exemplars); zone-gating is sound; ~40 CR base numbers all resolve and describe their code; linear AST walk, no O(bf²); the AI candidate arm correctly bounds a 1000-wide prompt to one N=1 candidate.
• CR foundation verified — 732.2a/b/c, 500.4/500.5, 603.4/603.6a/113.6 all grep-clean against docs/MagicCompRules.txt and describe the annotated behavior.
• ∞ wire contract: clean. Represented as membership sets (unbounded_pile: Vec<ObjectId>, unbounded_counters: HashMap<ObjectId, Vec<CounterType>>), never a numeric sentinel; the frontend renders engine membership only and does no arithmetic on ∞ (no NaN/overflow path). Display-only architecture rule holds.
• Tests are non-vacuous — the new integration tests drive through apply() / GameRunner / real GameAction::{DeclareShortcut,RespondToShortcut} and carry documented revert-flip reach-guards (combo_infinite_pile.rs §non-vacuity note; kilo_interruptibility_tests len()==2 anchors before negatives).
• Parse-diff sticky comment: "No card-parse changes detected" — consistent with the engine-only claimed scope; no parser blast radius.

Findings

[MED] The Tokens boundary-mint arm ignores a possible pause from drive_copy_token_batches, then unconditionally drains the phase transition. Evidence: crates/engine/src/game/engine_resolution_choices.rs:2196-2225 (mints count: amount, discards the drive result, collapsed.push) followed by the unconditional drain_pending_phase_transition_progress at :2290, whereas the copy resolver can set pending_copy_token_resolution = Some(..) and a replacement waiting_for mid-batch and return. The sibling Counters/Life/DriveSequence arms are observer-checked or pause-safe; only Tokens has no guard. Why it matters: if the mint ever pauses (a token/ETB replacement requiring a choice), the immediate drain advances the phase and overwrites waiting_for = Priority, corrupting state with a half-minted batch and an orphaned replacement choice. Reachability is gated by the offer-time firewall (a CR 732.2a shortcut can't contain a choice action), so this is latent today — but the seam is undefended if that invariant ever weakens. Suggested fix: after the mint, early-return WaitingFor when state.pending_copy_token_resolution.is_some() (or waiting_for is a replacement choice), mirroring the pause-aware returns elsewhere.

[LOW] Accept→boundary observer-drift orphans a declined axis's ∞ marks. Evidence: engine_resolution_choices.rs:2168 takes the whole stash, :2228/:2255 continue a now-observed Counters/Life item (never pushed to collapsed), and :2287 clear_collapsed_materializations clears only collapsed axes (game_state.rs:15556) — so the declined axis's entry in unbounded_resources / unbounded_counter_targets survives with its stash gone. The code comment (:2181) states leaving it ∞ for manual play is intentional (CR 732.2b never forces a shortcut) and game totals stay correct, so this is cosmetic — but I couldn't find a path that ever reclaims that ∞ badge or re-offers the declined axis. Please confirm the intended lifecycle: does the detector re-offer it, or is the badge stuck until clear_unbounded_loop? If stuck, either clear the declined axis marks here or re-route it to a DriveSequence replay.

[LOW] The Tokens axis assumes exactly one fodder token per loop period. Evidence: game_state.rs:3383 (Tokens(Box<CopiableValues>) carries no per-cycle count) minted as count: amount at engine_resolution_choices.rs:2202. A certified period whose net token production is k>1 per cycle collapses to N tokens instead of k·N. (Token-doubler replacements are handled correctly via replace_event on the batch; this is only the intrinsic "create two tokens per cycle" case.) Suggested fix: capture the per-period fodder count and mint count · amount, or assert the certified period is single-fodder so the limitation is explicit rather than a silent undercount.

[LOW] No end-to-end test exercises accept-time production routing for a real counter- or life-growth loop. Evidence: combo_infinite_pile.rs:1621-1635 (and :1753, :1883, :1907) graft the Counters/Life stash via register_pending_materialization onto a real token loop; the consumption path is production-driven and well-probed, but the accept-time batched-vs-DriveSequence decision at engine.rs:~2429 for a genuine counter/life loop is never reached. A misroute in that branch selection would not be caught. Suggested fix: add one scenario that accepts a real counter- (or life-) growth loop and asserts the resulting stash shape/axis.

[LOW] The counter tooltip leaks the finite count while the pill shows ∞. Evidence: client/src/components/board/PermanentCard.tsx:918-933 and client/src/components/card/ArtCropCard.tsx:214-226 wrap the ∞ pill in <CounterTooltip count={count}>, and formatCounterTooltip (client/src/viewmodel/cardProps.ts:178-184) interpolates the raw finite count. Hovering an unbounded counter shows e.g. "…: 4", contradicting the ∞ pill — and the PR's own tests deliberately hide that count elsewhere (not.toContain("x4")). Suggested fix: thread isUnbounded into CounterTooltip and render ∞/"unbounded" in the summary instead of the finite count.

[LOW] Hardcoded plural renders "Create 1 tokens" at value=1 in all 7 locales. Evidence: client/src/i18n/locales/en/game.json loopCollapseAmountTokens: "Create {{value}} tokens" (+ parallel de/es/fr/it/pl/pt). The stepper min can be low (tests use min: 0), so value=1 is reachable. Suggested fix: use i18next plural keys (loopCollapseAmountTokens_one/_other with {{count}}). (The ×N unit-framed variants are unaffected.)

Notes

• Browser verification of the ∞ glyph rendering / badge positioning / z-index was not performed — UI correctness there is unverifiable from code alone; the vitest coverage is strong (matched marked/unmarked pairs at every display site + the count=1 singleton trap).
• One weaker signal not filed as a finding: broadening per-activation last_loop_action_sequence recording (engine.rs) makes the empty-stack offer-drive hook fire after ordinary mana taps — but it's gated behind the samples() opt-in that is off in production, so no prod perf regression. Worth a glance if that gate ever defaults on.

Net: the architecture (threading, migration, census firewall, CR grounding, wire contract, test rigor) is solid; residual risk is concentrated in the newest boundary-materialization seam. Only the MED is worth a code change before merge (defense-in-depth guard); the rest are LOW polish/robustness/coverage items.

[lgray]

I'll create a followup PR that takes care of the medium and five lows. Let's go ahead and get this merged. @matthewevans