feat(engine): PR-6.5 — growing-cascade multiplayer win detector (ω-coverability modulo growth)

[lgray]

🤖 AI text below 🤖

Summary

PR-6.5 teaches the combo detector to certify growing mandatory cascades — loops whose state strictly grows each iteration (Karp–Miller-style ω-coverability) rather than repeating byte-identically — and to shortcut them as multiplayer-correct wins (CR 104.2a / 104.4a / 800.4a). All new behavior is gated behind the existing loop_detection opt-in; default OFF is byte-exact pre-feature behavior.

1. C0 fail-closed ability-scan walker (game/ability_scan.rs, new): compiler-exhaustive classification of every ability-AST node along three axes (event-context / sibling-mutable / projected-resource). No wildcard arms — a new enum variant is a compile error, not a silent fail-open; unknown shapes classify conservative. The add-engine-variant skill checklist now requires classifying new variants here.
2. C2 gated order-independent trigger auto-resolve (game/triggers.rs): removes no-op OrderTriggers prompts for provably order-independent same-event trigger groups — only when loop_detection is ON (project policy: gameplay-experience changes are user-opt-in). OFF-path keeps the legacy allowlist byte-exact.
3. Growing-cascade detector (analysis/resource.rs, analysis/loop_check.rs): loop_states_cover_modulo_growth — order-preserving bottom-up subsequence embedding with strict growth admitted only on prior-occupied places; projection restricted to player-level monotone resources + journals (all object/board state strict-compared); a two-surface fail-closed read guard (on-stack entries + off-stack fire-time intervening-if conditions); exactly-one-non-faller multiplayer winner predicate; controller_life_never_dips and a pairwise-equal-faller-lives simultaneity floor (CR 800.4a / 104.2a).
4. Granted-keyword soundness closure: a compiler-exhaustive guard test surfaced that granted-keyword synthesized fire-time conditions can read projected resources (Dethrone, CR 702.105a, reads LifeTotal) while the off-stack guard scanned only printed trigger_definitions. Loop (iv) now scans granted-keyword defs through the same synthesis authority the trigger-collection path uses (granted_keyword_triggers_in_zone). Traced latent-not-live today (Layer 6 installs battlefield-granted defs before the sample state), landed as strictly fail-safe structural closure — it can only add rejections, never false WINs.

Combo-detector series

Pos	PR	Delivers
PR-0	#4092	ResourceVector + modulo-resource loop equality (additive).
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 (scaffold + 5 families + SCC).
PR-4b	#4534	Engine B effect/trigger breadth + life-symmetry cost.
PR-5	#4547	cargo combo-verify CLI over the 53-row corpus.
PR-6	#4603	∞ unbounded-resource display — generalize infinite-mana to the whole ResourceAxis class (engine-owned DerivedViews projection).
PR-6.25	(deferred)	Order-independence soundness fix for group_is_order_independent (latent CR 603.3b); folded into PR-6.75 planning.
PR-6.5	(this PR)	Growing-cascade detector for multiplayer win-acceleration (ω-coverability modulo growth) + C0 fail-closed walker + C2 gated order-independent auto-resolve.

Predecessor: PR-6 — #4603 — #4603 — wired the detector's ∞ unbounded-resource display behind the loop_detection opt-in; this PR extends that same gated detector from exact-repetition loops to strictly-growing cascades.

Verification

• cargo test -p engine: 16751 passed / 0 failed (rebased tree). N-series discriminating tests: N1(a–n) + N1(kg), N2, N3 on both toggle arms, N5 life-dip discriminators — with executed revert-fail protocol on every load-bearing helper (each revert turned the suite red, tree restored byte-identical).
• cargo clippy --workspace --all-targets -- -D warnings: 0 warnings. cargo fmt --check: clean.
• Rebased onto 6cefafb21 (zero conflicts). Workspace tests green except 6 pre-existing mtgish-import golden_structural ETB failures also present on clean main (stale goldens from Fix Zenith Chronicler draw on first multicolored spell (fixes #4829) #4851's converter change; this series touches zero mtgish/parser/types files).
• Multiplayer-correct: winner predicate is exactly-one-non-faller (2p is the len-2 special case, never the general shape).

Deferred to PR-6.75 (plan in progress)

C0-full + C1 precision pass (read/write conflict-profile module ability_rw.rs; C1 = latent CR 603.3b same-event fix), the 38 event/sibling-only variant-.. walker arms, and the inc2a EventSource comment correction. Tracked in .planning/combo-detection/.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CwQE5oyMqZ9T4BPMsih3Kj

[gemini-code-assist]

Code Review

This pull request implements a growing-cascade loop detector for multiplayer games, introducing Karp–Miller-style coverability checking (loop_states_cover_modulo_growth) and a generalized multiplayer winner predicate (live_mandatory_loop_winner) to handle unbounded stack growth. It also adds safety checks for transient life dips and simultaneous faller elimination, alongside a fail-closed AST walker to prevent projected resource reads. The review feedback suggests renaming controller_life_never_dips to winner_life_never_dips to prevent misleading terminology, optimizing the O(N^2) stack comparison complexity in stack_covers to O(C + P), and correcting several bare-number CR citations to comply with the repository's style guide (Rule R6).

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]

[MEDIUM] O(N^2) stack comparison complexity in stack_covers.

Evidence: crates/engine/src/analysis/resource.rs:833-848.

Why it matters: The current implementation of stack_covers counts occurrences of each stack entry kind by performing nested linear scans over current and prior for every element in current. Since this is used for growing cascades where the stack can grow very large before detection, this O(C^2 + C*P) complexity can become a performance bottleneck. We can optimize this to O(C + P) by pre-counting unique elements using a simple Vec of unique elements and their counts.

Suggested fix: Pre-count the occurrences of each unique stack entry kind in prior and current before performing the comparison.

    let mut prior_counts: Vec<(&StackEntry, usize)> = Vec::new();
    for pe in prior {
        if let Some(slot) = prior_counts.iter_mut().find(|(e, _)| *e == pe) {
            slot.1 += 1;
        } else {
            prior_counts.push((pe, 1));
        }
    }

    let mut current_counts: Vec<(&StackEntry, usize)> = Vec::new();
    for ce in current {
        if let Some(slot) = current_counts.iter_mut().find(|(e, _)| *e == ce) {
            slot.1 += 1;
        } else {
            current_counts.push((ce, 1));
        }
    }

    let mut any_growth = false;
    for (ce, cn) in current_counts {
        let pn = prior_counts
            .iter()
            .find(|(e, _)| *e == ce)
            .map(|(_, count)| *count)
            .unwrap_or(0);
        if cn > pn {
            if pn == 0 {
                return false;
            }
            any_growth = true;
        }
    }
    any_growth

[matthewevans]

[HIGH] This PR modifies repository agent/skill instructions, which is a sweep hard-stop.

Evidence: the diff includes .claude/skills/add-engine-variant/SKILL.md. Instruction and skill files steer future automated review/implementation behavior, so external contributor PRs cannot change them through the normal PR review loop, even when the rest of the engine work is green.

Please remove the .claude/skills/add-engine-variant/SKILL.md change from this PR. If that skill update is intentional, it needs separate direct maintainer handling outside the contributor sweep.

[lgray]

🤖 AI text below 🤖

All review feedback addressed in cceeeb4f2 + 2e7ad800c (HEAD 2e7ad800c):

@matthewevans [HIGH] skill-file change — removed. cceeeb4f2 reverts .claude/skills/add-engine-variant/SKILL.md to the upstream/main version; the PR's net diff no longer touches any instruction/skill file. The checklist addition was intentional (it documents the walker-classification step this PR's C0 walker introduces), so per your note it has been re-proposed as a separate docs-only PR for direct maintainer handling: #4905.

[MEDIUM] controller_life_never_dips naming — renamed to winner_life_never_dips (fn, param, call site, tests, doc comment now explains why the winner — a mandatory-loop trigger can be controlled by a faller). No behavior change.

[MEDIUM] stack_covers O(n²) — declined, with rationale. The growth-count block is indeed order-insensitive multiset counting, so a count-map would be semantically equivalent — but StackEntry is Eq and not Hash/Ord, so a keyed count would require deriving Hash across StackEntryKind and the full ResolvedAbility AST graph: a large change to shared serialized types, disproportionate to a detection-time stack that is small (documented n = stack depth). No correctness benefit, real blast radius; keeping the current form.

[MEDIUM ×6] bare-number CR citations — fixed, plus 3 more the sweep found (loop_check.rs:271, resource.rs:669 second pair, ability_scan.rs headers). All rule numbers preserved verbatim and grep-verified against the Comprehensive Rules text (19/19 present); the established CR 704.5f/g/i subrule shorthand used across the codebase was left as-is.

Verification on the updated branch: cargo test -p engine 16751/0, clippy -D warnings clean, fmt clean.

[github-actions]

Parse changes introduced by this PR

✓ No card-parse changes detected.

[lgray]

FYI - Multani's Presence flip is from #4903 - not this PR (i.e. from base drift since main moves so fast).

[matthewevans]

[HIGH] The new growing-cascade shortcut can classify stack growth as no-input even when the grown entries can still open resolution-time player choices. loop_states_cover_modulo_growth only gates grown entries through stack_entry_has_no_ordering_input, which checks triggered-ability kind plus empty targets / multi-target / distribution / target constraints. That does not prove resolving the ability cannot enter a non-priority WaitingFor later. The new scanner marks variants like Explore, Proliferate, Populate, and Clash as no projected-resource reads, but their production resolvers can still prompt for choices such as proliferate target selection, populate token selection, and clash decisions.

That means the shortcut can set WaitingFor::GameOver from a priority-window stack-cover match before the unresolved grown entries have a chance to produce their required resolution choices. CR 732.5 only lets us shortcut a loop that no player can make choices to break; these resolution choices are exactly future player input the current C2/no-ordering-input gate does not model.

Please add an explicit “requires no resolution-time player choice” axis, or conservatively reject these effect variants from the coverability shortcut, and add hostile tests with an unresolved growing stack entry containing one of those choice-producing effects. The current tests cover target/distribution/order inputs and resource reads, but not this resolution-time WaitingFor surface.

The earlier instruction-file hard-stop appears resolved in the current diff; I only see crates/engine/... files now. This remaining blocker is behavioral soundness of the loop shortcut.

[lgray]

🤖 AI text below 🤖

Thanks — confirmed real, fixed in 41f8cf3 (branch rebased onto current main; the fix rides on top of the prior series unchanged). You're right on both counts: stack_entry_has_no_ordering_input gates only announcement-time ordering input and proves nothing about resolution-time prompts, and observed auto-resolution doesn't transfer to grown states (choice-freeness is state-dependent — e.g. proliferate's prompt-vs-auto turns on eligibility over player counters, a projected axis that grows along the extrapolation).

The fix adds the explicit axis you asked for, fail-closed and structural (for all states, not observed windows): a compiler-exhaustive resolution-choice classifier over every Effect variant (a new variant fails to compile until classified; unknown ⇒ MayPrompt) plus a no-.. destructure of ResolvedAbility that rejects optional/"may", unless-pay, resolution-time target slots (TargetChoiceTiming::Resolution entries pass targets.is_empty() today — also closed), modal and controller-choice repeat wrappers. It's wired as a new item (6) in loop_states_cover_modulo_growth over EVERY current-stack entry, not just grown ones, since an observed kind re-runs in states differing on projected axes. Only GainLife/LoseLife are classified choice-free, each pinned by a resolver trace — and because even those can prompt through the replacement pipeline (single optional candidate; CR 616.1 ordering with ≥2 candidates; execute/runtime_execute continuations), they additionally require an environmental guard that rejects the cover when any life-class replacement definition (registry-derived: GainLife / LoseLife / LifeReduced / PayLife) is optional, body-bearing, or ≥2 per proposed-event class, scanning object-attached and floating stores.

Tests: a pinned classifier guard test (same standard as the granted-keyword pin), a grown-proliferate-at-zero-counters fixture for the state-dependent case, an un-grown choice-kind fixture pinning the all-entries scope, five guard-arm fixtures each proven load-bearing by executed revert-fail mutations, and a resolution-timing fixture. The shipped drain-cascade win fixtures still certify, and default-OFF behavior is unchanged.

One small cite note: CR 732.5 is the "no player can be forced to perform an action that would end a loop" rule; the annotation basis we used is CR 732.2a — a shortcut "can't include conditional actions, where the outcome of a game event determines the next action a player takes," which is precisely what these resolution-time choices are. The new code cites CR 732.2a (+ CR 608.2d for resolution-time choice announcement, CR 616.1 for replacement-ordering choices).

[matthewevans]

Maintainer review: current head addresses the growing-cascade resolution-choice blocker; independent current-head review found no remaining actionable findings. Approving for merge queue.