ci: wire the FORGE_TEST_FULL_DB trigger-ordering parity sweep into a CI/release gate

[lgray]

🤖 AI text below 🤖

From PR-6.75's cumulative adversarial review (LOW-6, follow-up recommendation).

The trigger-ordering parity sweep in crates/engine/src/game/triggers_ordering_parity_tests.rs carries the PR-6.75 soundness evidence: the under-prompt direction gate (decision_old && !decision_new → asserted-empty unexplained), the mutation-proven non-vacuity floors, and the DOCUMENTED_OVER_PROMPT ledger completeness asserts. All of that only runs at full strength under FORGE_TEST_FULL_DB=1 — default CI executes the fixture-subset sweep, whose floors are dormant (fixture counts sit below the full-DB minima by design).

Consequence: a future change that introduces a same-event/batch under-prompt or silently shrinks a classifier population would pass default CI and only be caught by a manual full-DB run.

Recommendation: add a scheduled (nightly) or release-gate CI job that runs
FORGE_TEST_FULL_DB=1 cargo test -p engine ordering_parity_sweep
against freshly generated card-data, treating any unexplained row, floor trip, or ledger-completeness failure as blocking. Corpus-churn tolerance is already built into the floors (measured −5%), so routine card-data drift should not flap the gate; genuine drift beyond tolerance is exactly what should surface for re-adjudication.

Refs: #5072 (PR-6.75, where the sweep + floors + ledger landed).

🤖 Generated with Claude Code

[lgray]

🤖 AI text below 🤖

Investigated the concern that FORGE_TEST_FULL_DB "may not be functional as intended," specifically the effectiveness of the env flag. Measured findings below (against the current ordering_parity_sweep, byte-identical to main).

TL;DR

The flag logic is functional as intended — it demonstrably swaps the corpus and engages the full-DB-only assertions. The real gap is wiring it as a CI gate: the full-DB export it reads is a gitignored, generated artifact that the Rust test job never produces, so flipping the flag in that job would panic rather than run.

The flag is effective (measured, isolated single test)

invocation	full_db	swept	compared	floors (batch_obs / t1_indep)	runtime
flag off (committed fixture, 961 cards)	false	409	207	15 / 107	0.5s
FORGE_TEST_FULL_DB=1 (full export, 35,396 cards)	true	13,555	6,210	495 / 2,819	12.9s

Flag-on additionally populates the full-DB-only ledgers (se_member_bound_class 1→43, over_prompt_hit 0→18, the 6 genuine same-event exact-set cards). Both pass. The env read in the DB loader (test_support.rs:25, shared_card_db() OnceLock) and the sweep's own full_db (triggers_ordering_parity_tests.rs:476) agree.

It also does not break the suite

FORGE_TEST_FULL_DB=1 cargo test -p engine --lib → 15,311 passed / 0 failed (32s). The process-wide shared_card_db() OnceLock forces the full DB into every inline test, but they resolve cards by name (full DB = safe superset), so nothing fixture-tuned breaks.

Not a model-vs-model check

The sweep feeds the corpus through the production decision functions, not a test re-derivation: profiles_conflict (ability_rw.rs:1003) and ability_rw_profile (:1280) are the same pub(crate) fns the live gate group_is_order_independent → begin_trigger_ordering calls (triggers.rs:3696/3701). What it does not exercise is live, state-dependent group formation — it models the canonical group structure conservatively (fail-closed), as documented in the test.

The actual CI-gate blocker

• The full-DB export client/public/card-data.json is gitignored, generated only by scripts/gen-card-data.sh (run in deploy.yml's card-data job — heavy MTGJSON fetch, weekly-cached). The Rust test job never produces it.
• No CI job runs FORGE_TEST_FULL_DB or the sweep today — so this gate is genuinely unimplemented.
• Therefore adding FORGE_TEST_FULL_DB=1 to the existing test job panics on the missing export (test_support.rs: .expect("card-data export should load")) — it is not a self-contained, CI-runnable mechanism as-is.
• Residual silent fragility: the flag trusts whatever file sits at that path. A missing file panics loudly, but a stale-but-present export runs full_db=true on stale cards with no freshness assertion.

Proposed resolution for this issue

Wire the sweep as an isolated job that first provisions the card-data export (reuse gen-card-data.sh + its weekly cache, as deploy.yml does) and runs exactly ordering_parity_sweep with the flag — rather than flipping the flag on the full test suite. check-test-card-data-load.sh is a precedent: it already reparses the full export in CI, so the artifact-provisioning pattern exists. Adding a freshness assertion (or regenerating rather than trusting a cached file) would close the stale-export gap.

@matthewevans — this matches your read that the env flag isn't functional as a drop-in CI gate; the flag itself works, the missing piece is provisioning the generated card-data export in whatever job runs it. Happy to open a PR wiring the isolated + artifact-provisioned job if that direction looks right.

🤖 Generated with Claude Code

[lgray]

🤖 AI text below 🤖

Follow-up to the effectiveness note above — decomposing what swept=13,555 actually is, since the "13,555 vs 35,396" gap is the crux of whether this is an authoritative gate. Measured by temporarily instrumenting the sweep loop (counters reverted after the run).

The denominator is triggers, not cards

35,397 is card entries; most have no triggered abilities. The relevant universe for a trigger-ordering sweep is triggers, of which the export has 19,035 (across 15,681 cards). swept=13,555 is 13,555 of those 19,035 triggers (71.2%), not of 35,397 cards.

Where all 19,035 triggers go

bucket	count	%	meaning
swept (classified)	13,555	71.2%	production makes an auto-vs-prompt read/write-profile decision here — sweep classifies 100%, unexplained=0
skip — has ordering input	4,479	23.5%	modal / target / division / multi-target (CR 603.3c/3d)
skip — Unimplemented	981	5.2%	parser can't build the AST → can't profile reads/writes
skip — no execute def	20	0.1%	empty trigger

The 4,479 exclusion is correct — it mirrors production

sweep_no_ordering_input skips a trigger when it carries a modal choice, target constraints, multi-target, distribution, or target slots. That is not a coverage hole: production's own group_is_order_independent (triggers.rs:3594) calls the same trigger_has_no_ordering_input (:3518) at :3601 / :3710 and returns false → the group always prompts. Production never auto-orders these either, so the ordering gate cannot mis-decide them — there is nothing for the sweep to check. The sweep tests exactly the domain where production makes an auto-order decision (and uses the same profiles_conflict / ability_rw_profile production uses — ability_rw.rs:1003 / :1280).

The 981 Unimplemented is the one genuine blind spot

For these the parser can't represent the effect, so neither the sweep nor the profile system can classify the ordering. The sweep is authoritative only over the parseable-trigger subset; this 5.2% shrinks as parser coverage grows, and combo-detector work disproportionately targets exactly these complex cards.

Is 13,555 sufficient to vet ongoing combo-detector work?

As an ordering-regression tripwire over its domain: yes — it is exhaustive (not a sample) over every auto-order-candidate trigger, so a parser/profile change that silently flips auto↔prompt is caught (unexplained.is_empty() + measured non-vacuity floors + ledger-completeness asserts).

As the sole vetting for combo correctness: no, for four measured reasons:

1. the 981 Unimplemented (5.2%) blind spot — the sweep lags parser coverage and can't pre-vet a net-new mechanic;
2. it models group formation statically and treats the live half (controller alignment, team pools, LKI, actual co-occurrence) conservatively/fail-closed — so state-dependent and live-ordering bugs are outside its envelope by construction (this is where the PR feat(engine): PR-6.75 — C0-full+C1 read/write conflict profiler; sound CR 603.3b same-event trigger ordering #5072 review found real defects that the green sweep did not surface);
3. the 4,479 always-prompt triggers can still be combo participants, and the sweep says nothing about their loop behavior;
4. it is a per-trigger decision check, not a multi-trigger / multiplayer loop-detection check.

Recommendation: wire it as the tripwire it is (no-silent-ordering-regression over the 13,555-trigger auto-order domain), but keep it accompanied by per-mechanic discriminating tests (esp. live/state-dependent + multiplayer paths), the --fail-on-engine coverage-regression check, the combo-detector's own loop tests, and re-sweep + test-pin each Unimplemented trigger as it becomes parseable. The gate's value is bounding the simple-trigger ordering domain — it is not a combo-correctness certificate.

@matthewevans — this is the full decomposition behind the effectiveness note; net, the flag works and the 13,555 is the right exhaustive number for its domain, with the 5.2% Unimplemented slice as the honest authoritativeness caveat to track as parser coverage grows.

🤖 Generated with Claude Code

[lgray]

🤖 AI text below 🤖

Current measurement (2026-08-21, main-lineage base 8d4f71ea2): the full-DB sweep reports unexplained=21 (was 18 on 2026-07-31, 20 on 2026-07-10) — a 6-card cat1_hit set, 22 over_prompt_hit, 53 se_member_bound_class members; swept 13775 / compared 6256 against the current 35,798-face export. The +3 since July is main-level, not branch-level (a matched two-arm control at base 8d4f71ea2 vs candidate 1a191c95e was byte-identical, same 21 rows), and may be corpus drift from the recent card-data refresh (#7569) rather than a code change.

The gap this issue tracks is now sharper: the identical test without FORGE_TEST_FULL_DB passes green in 2.86s against the committed 3,559-face fixture, because client/public/card-data.json is gitignored and absent in CI. The test labels itself a STRICT PROOF-GATE (triggers_ordering_parity_tests.rs:871), but in CI its green covers roughly a tenth of the corpus. Until the full-DB run is wired in, a cheap interim hardening: have the sweep print a one-line qualifier when it falls back to the fixture, so a narrow run cannot be read as full coverage.

Reproduction: FORGE_TEST_FULL_DB=1 cargo test -p phase-engine --lib ordering_parity_sweep -- --nocapture with a current cargo export-cards output present at client/public/card-data.json.