prefer=scryfall: Scryfall's Own Printing Ordering, as Its Own Score

[daveycodez]

Reworked per review: Scryfall's preference is now a separate score reproducing their full per-card printing ordering, not a reweighting of the curated prefer_score (which this PR no longer touches at all).

The score

scryfall_prefer_score (new real column): 0 for the printing Scryfall itself shows for the card, then −1, −2, … down the card's remaining printings — so DESC reproduces their full ordering under the same higher-wins machinery prefer_score already uses, and the two never mix.

Where the ordering comes from

The two halves come from the two places Scryfall makes its ordering observable:

1. The top is exact by construction. The oracle_cards bulk dump is one card object per oracle_id, and that object IS the representative printing they show. Those ids sync into magic.scryfall_representatives each import — the same table and importer as prefer_score: Pin the Representative Scryfall Itself Names #921, byte-identical, so the two PRs merge cleanly in either order.
2. The rest reproduce the prints listing every card object links as its prints_search_uri (order=released&unique=prints): release date, set code, collector number, all descending. Tie-breaks were verified against the live listing rather than assumed: same set and day orders 305 → 184 → 63 and 1638★ → 1638 (numeric part first, text second); different sets, same day orders pfdn → fdc, mb2 → blc, and fbb → 3ed — the last rules out set name ("Foreign Black Border" < "Revised Edition") in favor of set code (f > 3).

One boundary, stated plainly

When a filter excludes their representative, Scryfall's unique=cards fallback follows unpublished editorial rules, not release order — probed: Lightning Bolt minus its representative's set falls back to clu 141 (2024) over five strictly newer printings. That fallback is not reproducible from any bulk source, so under such filters this ordering yields their prints-listing order instead of their unpublished pick. Named lookups and prints listings — what a /scryfall mount would serve — reproduce exactly.

Selectable everywhere prefers are

• API: prefer=scryfall (PreferOrder.SCRYFALL → scryfall_prefer_score DESC).
• Engine: Prefer::Scryfall reads the stored per-printing score; the store carries the new column, so ARCHIVE_FORMAT_VERSION → 2026082701.
• UI: a Scryfall option in the prefer dropdown.

Import order: representatives sync after art tags; backfill_scryfall_prefer_scores then ranks every printing. LEFT JOIN, so an empty label table degrades to release order rather than failing the import.

Tests

Full ordering against a live schema (pin beats newer printings; set-code tie-break; unlabelled cards still fully ranked; prefer_score untouched), engine prefer=scryfall picking the pinned-not-newest fixture printing, enum + SQL compilation coverage. pytest: 3427 passed. cargo test: 160 passed.

[jbylund]

I think what I'd like to do here is have a separate prefer score which is scryfall's. We can obviously get the top 1 for that, but can we get the full ordering? that way we can reproduce their preference exactly. Then if we mount scryfall routes at /scryfall they can get closer to exact behavior and it would also be available as a prefer elsewhere. Would that work?

[daveycodez]

Agreed — a separate prefer score that is Scryfall's own ordering is the better shape. Reworking this PR to do that: reproduce their full ordering (not just the top-1) so a /scryfall mount can match their choice exactly, and it's available as a prefer everywhere else.

[daveycodez]

Reworked as discussed — the branch is rewritten, the extended-art reweighting is gone, and prefer_score is untouched.

The new scryfall_prefer_score stores Scryfall's full per-card ordering as a score: 0 for the printing they show for the card, counting down from there, so DESC reproduces the ordering. The top-1 comes from the oracle_cards dump (one object per oracle_id, and that object is their representative — same importer/table as #921, byte-identical so either merges first). The rest follow their prints listing (order=released): release date, set code, collector number, all descending — I verified the tie-breaks against their live listing rather than assuming them (the fbb-before-3ed pair is what pins set code over set name).

On "reproduce their preference exactly": named lookups and prints listings reproduce exactly. The one thing that can't be sourced is their fallback pick when a filter excludes the representative — I probed it, and it follows unpublished editorial rules (Bolt minus its rep's set falls back to a 2024 printing past five newer ones), so under such filters you get their prints-listing order instead. Everything needed for a /scryfall mount is here; the routes themselves I left for a follow-up.

It's selectable as prefer=scryfall in the API, the engine (new store column, archive format bumped), and the UI dropdown.