card trees as a top-level primitive

We’ve been pushing Jank toward a simpler idea:

the card tree should be the primary object.

Not the decklist. Not the thread. Not the diff.

The tree.

→ Visit: https://jank.vedh.xyz

The core thought

A deck is not just a flat list of cards.

It usually has structure:

  • packages
  • branches
  • replacements
  • sideboard plans
  • notes about why something is there
  • comparisons between one version and another

Most tools flatten all of that into one list and make you carry the real reasoning in your head, in a Discord thread, or in scattered notes.

A card tree keeps the structure attached to the cards.

What that means in practice

Instead of treating a deck as one blob, Jank can treat it as:

  • a top-level tree
  • with nested packages and branches
  • with cards attached inside those branches
  • with annotations and discussion linked directly to the thing being built

That lets one object support multiple views:

  • forum view for discussion
  • tree view for structure
  • deck view for the familiar list
  • diff view for comparing versions

The important idea is that these are all projections of the same underlying object.

Why this feels better

This model gives us a few things a plain decklist doesn’t:

1. Structure survives

You don’t lose the difference between:

  • core package
  • optional package
  • testing branch
  • sideboard plan
  • replacement line

That context stays in the object.

2. Discussion has a real anchor

Forum discussion stops being loosely attached to a pasted list.

Instead, the discussion can hang off the actual tree — or an existing thread can become the discussion home for that tree.

3. Diffs get more meaningful

The question is no longer just:

  • what cards changed?

It becomes:

  • what package changed?
  • what branch changed?
  • what moved from sideboard to mainboard?
  • what experiment replaced what?

That’s a much better fit for how people actually iterate on lists.

What’s live now

The current Jank slice already supports a lot of this direction:

  • top-level card tree publishing
  • slug-based tree routes
  • forum/tree/deck/diff views
  • nested composer support for package and branch structure
  • attaching a tree discussion to an existing thread
  • package-aware and branch-aware diffing

It’s still early, but the shape is there now.

The bigger point

We’re interested in tools that preserve thought, not just output.

A decklist is output. A card tree is closer to the reasoning process that produced it.

That makes it a better primitive for brewing, discussing, revising, and comparing ideas over time.

Where this goes next

There’s still plenty to improve:

  • better tree composition UX
  • cleaner thread attachment/search
  • stronger diff semantics for complex branch movement
  • richer card-aware helpers around the composer

But the underlying bet feels right:

forum as the default experience, card tree as the real object, and deck/diff as views over that object.

That’s the direction.