Card Binder #281

New issue

Open

opened 2024-06-30 15:16:30 +01:00 by Vylpes · 0 comments

Vylpes commented

2024-06-30 15:16:30 +01:00

Owner

Summary

Card Binder is a per-user collection view modeled after the existing /series view. Each user has 3 global binder pages. Each page is a fixed 3x3 grid (9 slots). Slots store card instances (the actual cards the user owns), identified by UUID. Users may place or remove instances with slash commands only. Binders are public (anyone can view any user's binder). Cards placed in a binder become unavailable for trading until removed. Binder state is lazily created when first accessed.

This document captures finalized behavior, data model, commands, user stories, acceptance criteria, UI/UX notes, implementation tasks, and resolved choices — now including the client's two notes and the inventory totals decision.

Acceptance Criteria

Given a user owns instances UUID X and Y of design 1001, and X is placed in a binder:
- Inventory should display "1001 x1 (2)" meaning 1 available, 2 overall.
Given a user runs /binder place X 1 3:
- X is recorded in user_id's page 1 slot 3,
- X.in_binder = true,
- Inventory available_total decreases by 1 (reflected on next render).
Given a slot is occupied, /binder place returns an error instructing the user to remove first.
/binder view shows empty slots using the configured empty-slot image and labels slots 1..9.

## Summary Card Binder is a per-user collection view modeled after the existing /series view. Each user has 3 global binder pages. Each page is a fixed 3x3 grid (9 slots). Slots store card instances (the actual cards the user owns), identified by UUID. Users may place or remove instances with slash commands only. Binders are public (anyone can view any user's binder). Cards placed in a binder become unavailable for trading until removed. Binder state is lazily created when first accessed. This document captures finalized behavior, data model, commands, user stories, acceptance criteria, UI/UX notes, implementation tasks, and resolved choices — now including the client's two notes and the inventory totals decision. ## Acceptance Criteria - Given a user owns instances UUID X and Y of design 1001, and X is placed in a binder: - Inventory should display "1001 x1 (2)" meaning 1 available, 2 overall. - Given a user runs /binder place X 1 3: - X is recorded in user_id's page 1 slot 3, - X.in_binder = true, - Inventory available_total decreases by 1 (reflected on next render). - Given a slot is occupied, /binder place returns an error instructing the user to remove first. - /binder view shows empty slots using the configured empty-slot image and labels slots 1..9. --- - [x] #323 - [ ] #495 - [ ] #496 - [ ] #497 - [ ] #498 - [ ] #499 - [ ] #500

323 Card Binder Implementation v1.1.pdf

122 KiB