decision(client): three open design questions that block the frame, the hand, and the lobby

[ninthworld]

Part of #652. Blocks the frame, the hand, and the lobby. No code.

Objective

Get three design decisions made that docs/client-design.md §9 leaves open. Each one changes what
gets built, and none of them can be defaulted by an implementer without inventing product design.

These are questions for the maintainer. An agent picking up this issue should present the
options and the trade-offs and then stop — do not choose.

Decision 1 — the seat bar at the Tall and Short bands

Life must never degrade (§3, "what never degrades"). But a seat bar at 360px wide cannot carry
name + life + library/hand/graveyard/exile counts + status marks + the commander state.

• Proposal in the spec: life and status stay always-visible; zone counts fold into one
  expandable control.
• Alternatives: counts move into a per-seat drawer; counts become icon+number with no labels; the
  opponent's bar degrades further than yours.
• What it changes: PlayerPanel.tsx, and whether ZonePanel has a compact form at all.

Decision 2 — where the action affordance sits on touch

Tier 1 requires a fixed, known place to act. On a phone the hand is also tier 1 and also
bottom-anchored, and they compete for the only comfortably reachable region.

• Options: a bar above the hand (matches desktop, costs hand height); a floating primary control
  over the hand's edge; the hand collapsing to a peek strip whenever an action is pending.
• What it changes: ActionDock.tsx, Hand.tsx, and the Short/Tall arrangements in §4.

Decision 3 — the lobby's register

"Styled forms" is not an answer, and the maintainer has said the current lobby needs a complete
redesign. What should the lobby be?

• A room you walk into (spatial, continuous with the table)

• A table you sit down at (the table itself, pre-game)

• A modern client shell (rows, filters, a deck locker — continuous with the deck builder)

• What it changes: everything in clients/web/src/ui/lobby/, and whether the lobby shares the
  scene model or is a conventional responsive layout.

Plan for whoever picks this up

1. Present each decision with a concrete mock or ASCII sketch per option — the maintainer has said
   design decisions must be made before code, and options are easier to judge drawn than described.
2. Record the answers in docs/client-design.md §9, converting each open question into a stated
   rule in the relevant section.
3. Close this issue by unblocking the three children that depend on it.

Guard rails

• Do not implement anything. Do not pick a default and proceed.
• Do not widen the question set — three decisions, no more.

Acceptance criteria

• Each of the three has a stated answer in docs/client-design.md, in the section it belongs
  to rather than in the open-questions list.
• §9 is empty, or contains only questions raised after this issue.

Done when

The frame, hand, and lobby issues can be implemented without asking anything.

[ninthworld]

Answered by the maintainer. All three are now stated rules in docs/client-design.md rather than open questions, and §10 is empty. They land with #665.

Decision 1 — the seat bar at Tall and Short

Life and status marks are always drawn. The five zone counts fold into one control that expands in one gesture. Life stays tier 1; the counts drop to tier 2, which is where they belonged — a library count is something you check, not something you read continuously.

The fold is symmetric. Keeping your own counts longer than the opponent's was on the table and has a real argument behind it — your counts are the ones you act on — but it costs a player learning two different bars and then working out which one they are looking at. One bar read the same way at both ends of the table is worth more than the extra count.

Recorded in §2, "The seat bar". Affects PlayerPanel.tsx and gives ZonePanel a compact form.

Decision 2 — the action affordance on touch

The hand is full height while the game is not asking anything. The moment there is something to answer, the hand collapses to a peek strip and the dock takes the space it freed. One gesture restores the hand, which is what a player does when the action is about a card in it.

This is a deliberate rejection of a permanently-reserved dock. A fixed bar costs hand height at every size — including the sizes where the hand is already tightest — and spends it on controls that are blank most of the time. The affordance is still in a fixed, known place: the bottom band. What changes is how much of that band it takes, and it only grows when there is something to take.

At Wide, Ultrawide, and Square there is room for both and the dock sits above the hand permanently, as it does today. The trade applies at Tall and Short only.

Recorded in §2, "The action affordance and the hand", and in the §4 band table. Affects ActionDock.tsx and Hand.tsx.

Decision 3 — the lobby's register

A client shell. A persistent navigation region, a content region beside it, and the pre-game surfaces as content within it: tables as rows, decks as a locker, the catalog as the builder's own space.

The other two were tempting and both lose to the same fact. A pre-game table — the board seen empty, with chairs you take — is continuous with the game and reuses the scene model outright; a room you walk into gives the strongest sense of place. But the deck builder is the densest surface in the product, it is unavoidably a list of hundreds of cards with filters over it, and it lives here. A spatial lobby has to hand off to a conventional one the moment a player builds a deck, and that seam is worse than not having the metaphor.

The atmosphere comes from the drawing, not the register: same dark ground, same card component, same type. A catalog card and a battlefield card are the same card — that is what makes the front door read as the same product as the table, and it is the part the current lobby fails.

Two consequences worth stating separately, both now in §9:

• The lobby does not use scene(). It is a conventional responsive composition, and it is the one place where that is correct — its content is a list whose length the server decides, not a board whose geometry a viewport decides.
• A list in the shell may scroll. The board may not. These are not in tension: §3's rule is about the board, and the shell is not the board. Say which one a region is before deciding.

Everything else in the spec still applies to the lobby: nothing clipped, nothing below the type floor, text fitted rather than truncated, no native form control.

---

#659, #661, and #664 are unblocked. #664 still opens with a design pass — the register is settled, the composition is not.

[ninthworld]

All three decisions answered and recorded as stated rules in docs/client-design.md (#665, on main). §10 is empty. #659, #661, and #664 are unblocked.