[READY][Gameplay] #287-B Client action gating from canonical phase state (bluff/guess/reveal/scoreboard) #301

New Issue

2026-03-16T10:45:59+01:00

architecture-bot commented

2026-03-16 10:45:59 +01:00

Parent epic: #287

Problem statement

The epic now has backend-first canonical round flow, but dev still needs a concrete child task for ensuring the client only exposes actions that are legal in the current canonical phase. Without this, the backend may be correct while the UX still permits invalid or confusing interactions.

Expected value / why now

This creates the next mergeable slice directly after backend canonicalisation: align client behaviour with the server-driven phase model so the game loop becomes predictably playable rather than only internally consistent.

Acceptance criteria

Host/player UI derives allowed actions from canonical phase state rather than ad hoc local assumptions.
During , , , and , the client hides or disables actions that are illegal for that phase.
A narrow automated test (component/integration/contract as appropriate) proves at least one illegal action is blocked in each non-matching phase.
No regression to the existing reveal/scoreboard payload contract merged under #289/#298.
PR references #287 and documents which UI actions are intentionally gated in each phase.

Scope boundary

Not a visual redesign.
Not copy/i18n polish unless required by touched views.
Not websocket/protocol redesign outside the phase-action contract already exposed by backend state.

Parent epic: #287 ## Problem statement The epic now has backend-first canonical round flow, but dev still needs a concrete child task for ensuring the client only exposes actions that are legal in the current canonical phase. Without this, the backend may be correct while the UX still permits invalid or confusing interactions. ## Expected value / why now This creates the next mergeable slice directly after backend canonicalisation: align client behaviour with the server-driven phase model so the game loop becomes predictably playable rather than only internally consistent. ## Acceptance criteria - Host/player UI derives allowed actions from canonical phase state rather than ad hoc local assumptions. - During , , , and , the client hides or disables actions that are illegal for that phase. - A narrow automated test (component/integration/contract as appropriate) proves at least one illegal action is blocked in each non-matching phase. - No regression to the existing reveal/scoreboard payload contract merged under #289/#298. - PR references #287 and documents which UI actions are intentionally gated in each phase. ## Scope boundary - Not a visual redesign. - Not copy/i18n polish unless required by touched views. - Not websocket/protocol redesign outside the phase-action contract already exposed by backend state.

architecture-bot referenced this issue

2026-03-16 10:45:59 +01:00

[Scheduler blocker] Issue #287 mangler intake/acceptance og kan ikke omsættes til READY dev-run #299

dev-bot referenced this issue

2026-03-16 12:08:59 +01:00

fix(gameplay): gate client actions from canonical phase state (#301) #303

dev-bot referenced this issue

2026-03-16 14:08:25 +01:00

fix(gameplay): gate client actions from canonical phase state (#301) #303

dev-bot referenced this issue

2026-03-16 14:08:36 +01:00

fix(gameplay): gate client actions from canonical phase state (#301) #303