[READY][Gameplay] #287-E Realtime phase-event contract for client refresh and route sync #309

New Issue

architecture-bot · 2026-03-16T19:33:44+01:00

architecture-bot commented

2026-03-16 19:33:44 +01:00

Parent epic: #287

Problem statement

Backend currently broadcasts phase events via sync_broadcast_phase_event, while the UI still leans heavily on session-detail polling. We need one explicit child task that defines and verifies what realtime events promise to clients, so they act as acceleration instead of a second, drifting protocol.

Expected value / why now

This makes host/player state updates feel more immediate without moving authority away from Django. It also reduces ambiguity about whether the browser should trust websocket payloads directly or only use them to trigger refresh.

Acceptance criteria

Define the intended contract for realtime phase events: which fields are included, and whether clients should treat them as authoritative payload or as refresh hints.
Add/update tests around websocket/broadcast behaviour for at least phase.lie_started, phase.guess_started, phase.scoreboard, and phase.game_over.
Ensure host/player route or refresh behaviour can be driven consistently from the agreed event contract.
If the chosen design is “events are refresh hints”, the code/tests must make that explicit.
PR references #287 and states the intended browser behaviour when a phase event arrives.

Scope boundary

Not broad realtime infrastructure work.
Not multiplayer presence/chat.
Not replacing session-detail polling entirely in this task.

Parent epic: #287 ## Problem statement Backend currently broadcasts phase events via `sync_broadcast_phase_event`, while the UI still leans heavily on session-detail polling. We need one explicit child task that defines and verifies what realtime events promise to clients, so they act as acceleration instead of a second, drifting protocol. ## Expected value / why now This makes host/player state updates feel more immediate without moving authority away from Django. It also reduces ambiguity about whether the browser should trust websocket payloads directly or only use them to trigger refresh. ## Acceptance criteria - Define the intended contract for realtime phase events: which fields are included, and whether clients should treat them as authoritative payload or as refresh hints. - Add/update tests around websocket/broadcast behaviour for at least `phase.lie_started`, `phase.guess_started`, `phase.scoreboard`, and `phase.game_over`. - Ensure host/player route or refresh behaviour can be driven consistently from the agreed event contract. - If the chosen design is “events are refresh hints”, the code/tests must make that explicit. - PR references #287 and states the intended browser behaviour when a phase event arrives. ## Scope boundary - Not broad realtime infrastructure work. - Not multiplayer presence/chat. - Not replacing session-detail polling entirely in this task.

architecture-bot referenced this issue

2026-03-16 19:33:46 +01:00

[Architect blocker] Epic #287 mangler ny READY child task efter lukning af #288/#289 #307

architecture-bot referenced this issue

2026-03-16 19:33:46 +01:00

[Need-to-have][Gameplay] Canonical FupOgFakta/WPP round flow aligned to bluff/guess/reveal loop #287

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wpp/weirsoe-party-protocol#309