Pular para o conteúdo
Pegasus Docs

Manage deck versions

Este conteúdo não está disponível em sua língua ainda.

What you’ll accomplish

Deck versioning helps you understand whether a change actually improved a list. By the end of this workflow you can save versions intentionally, compare them with analysis (not just card diff), and treat your testing history as a record you can learn from instead of a write-only stream.

Before you start

  • A target deck with at least one analysis run — see Build decks and Analyze decks and scores.
  • A change you want to try (a ratio shift, a tech swap, a side deck rebuild, a post-banlist update).

Steps

  1. Snapshot before you tinker

    The moment you decide to test a change, save the current list as a version. Naming matters — v2 more starters tells future-you what you were testing; v2 test doesn’t.

    Good version names explain intent:

    • v1 import
    • v2 more starters
    • v3 locals side plan
    • v4 post-banlist
    • v5 budget cut, sub Pot of Greed

    Small typo fixes or card-name corrections don’t need a new version — they’re not decisions, they’re hygiene.

    Future-you reading this in three months will thank present-you for the labels.

  2. Run Quick Analysis on both versions

    After making the change in a new version, run Quick Analysis on both versions. The point is the comparison — a single analysis tells you the current state but not whether the change helped.

    Always analyze both versions before drawing a conclusion. One analysis is a number; two analyses are a delta.

  3. Compare side-by-side

    Open the Compare view with both versions selected. The page shows:

    • Strategic takeaways at the top — “starter density up”, “answer density down”, “brick risk increased”
    • Coverage delta — the 5-dimension change visualized
    • Simulation delta — observed-rate changes
    • Raw card diff — at the bottom

    Read top to bottom. The takeaways are the conclusion; the raw diff is just the evidence.

    Strategic takeaways first. The raw card diff is for confirming the read, not forming it.

  4. Keep or revert

    The change improved structure → archive the old version with a note explaining why, promote the new one to active.

    The change hurt → revert. Keep the failed version around with a note about WHY it failed; future-you may have the same idea and need the receipt.

    The result is ambiguous (small numerical change, simulation noisy) → leave both, test in play, decide afterwards.

    Numerical noise: a 2% simulation rate change inside a 10K-hand sample is often signal you can't lean on.

What success looks like

The deck’s version history reads as a coherent story — each version’s name explains why it exists, and any reverted versions have a note saying what didn’t work and why. Six months from now you can answer “why did I take this card out?” without re-deriving the reasoning from scratch.

Going deeper

Versioning interacts with readiness — a new version may have different shortage shape than the old one. The acquisition plan respects whichever version is currently active. Coverage and simulation deltas use the same model documented in Scoring model.

For the recommended cadence (when to version, when to just edit), see Recommended workflow.

For the field-by-field reference of the versioning surface — timeline, intent labels, compare picker — see Deck versions (reference).

Next steps

Compare and improve decks Use compare not just on your own versions but against benchmark lists.
Analyze decks and scores Re-read the analysis page with versioning context in mind.