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.