Conformance

Identifiers

The protocol uses opaque string identifiers. The reference encoding is:

Form	Refers to
card-{n}	A card instance — {n} is an integer unique within the session.
player-{n}	A player slot — {n} is the zero-based seat index.
stack-{n}	A stack object — {n} is an integer unique within the session.

Implementations MAY use other encodings provided they are stable strings unique within a session. Clients MUST treat identifiers as opaque and MUST NOT derive game-state meaning from their textual form.

What a conforming engine must do

• Emit prompts whose type is one of the documented variants, or a vendor-extension type that doesn’t collide with a documented one.
• Send game state via the state message (StateUpdate); a prompt itself carries no gameView.
• Use the identifier scheme above, or an alternative that satisfies the per-session uniqueness contract.
• Validate every response against the open prompt: the echoed promptId must match, the action family must match the prompt’s type, and any echoed action id must have been advertised by that prompt. Reject anything else with an error and re-send the open prompt.
• Treat promptId 0 as an engine-internal absent-player default (timeout, disconnect); never interpret it as answering a real prompt.

What a conforming client must do

• Render any state snapshot it receives without assuming engine-specific extensions.
• Treat identifiers as opaque.
• Send a response to every prompt that requires a decision, echoing the prompt’s promptId. (gameOver is terminal and takes no response; acknowledgement prompts like revealCards and diceRolled take a simple “acknowledged” response.)
• Echo only action ids the prompt advertised — never synthesize ids.
• Act only on prompts, errors, and addressed states whose forPlayer is its own seat (see Transport).
• On an error message, treat the re-sent prompt as still open and let the player answer again.
• Treat an unknown prompt type as a soft error — surface it, but never crash on it.