Collections and a second card game
Proposal, October 12, 2026. The released app still has one Pokémon collection. Magic support and a collection selector are not implemented.
Multiple collections should live above Cards, Decks and Play. A parent could create “Blue’s Pokémon cards” and another collection for Magic. Each collection has its own owned cards, decks, favorites, In-store candidates, and game sessions.
| Record | Shared fields | Game-specific data |
|---|---|---|
| Collection | id, name, game (POKEMON or MAGIC), createdAt, updatedAt, schemaVersion |
catalog/rules versions |
| Owned card | id, collectionId, printingId, quantity, favorite, createdAt, updatedAt | exact printing metadata |
| Deck | id, collectionId, name, style, createdAt, updatedAt | selected cards and game-specific checks |
| Candidate | id, collectionId, printingId, quantity, createdAt, updatedAt | purchase notes and deck fit |
| Play session | id, collectionId, deckId, createdAt, updatedAt | Pokémon Prizes and conditions, or Magic turn resources |
Use game-qualified printing IDs. A Magic card and a Pokémon card with the same provider ID must not collide. Every deck belongs to one collection, and its cards must belong to the same collection and game. A removal affects decks in that collection only. Each collection keeps independent selected-card snapshots, as decks do today.
The app shell, readable card view, pagination, favorites, camera input and local storage can be shared. The catalog adapter, OCR name/number matching, filters, deck rules, deck suggestions, teaching resources and game session must be separate. Pokémon evolution, Energy and Prizes must never be used to explain a Magic deck.
Before adding Magic, choose one format and learning path. The current Pokémon builder cannot be reused as Magic’s rules engine. Start with one bounded Magic catalog and a beginner deck style, then verify switching, backups, removals and play sessions across both games. The earlier D&D proposal remains on hold.
Migration should create one Pokémon collection around the current workspace. Do not discard old storage until the new write succeeds. Backups need a versioned collections array and activeCollectionId. Import old backups into a new collection, so a restore does not overwrite another child’s collection by accident. Offer explicit replace, merge or new-collection actions only after their behavior is implemented and tested.
Local collections do not require an account or paid service. Cross-device synchronization is separate work: authenticated ownership, access controls, durable storage and backup recovery. The existing backend proposal covers that direction.