Mobile Web App software

Player interaction

The intended flow is join game, establish player identity, obtain the authorized view, and send commands for the player's choices. The phone can show resource holdings, development cards, trade offers and responses, build/bank actions, robber choices, and private notifications.

The app should make pending choices clear while allowing attention to return to the physical board. Physical placements are confirmed through reconciliation, not just a phone button.

State and interfaces

A conceptual client state includes game/session identity, authorized player view, current prompt, connection state, and pending command outcomes. The API and WebSocket contract must distinguish accepted, rejected, and still-pending requests.

A reconnect should obtain a fresh authorized snapshot. Retries must not double-spend resources or duplicate trades; command identifiers and deduplication are open design work. Server validation remains authoritative even when the UI disables illegal choices.

Privacy and lifecycle

The exact authentication mechanism is TBD. Whatever mechanism is chosen must bind requests to a player and prevent one client from selecting another player's private data without authorization. Filtering must happen before sending payloads.

Session persistence, rejoining from a replacement phone, browser storage, multiple tabs, and loss of connectivity need definition. No offline mutation of authoritative game state is assumed.

React and TypeScript are likely technologies but not fixed. Web/API version compatibility is separate from the hardware protocol. See game engine and the public display.