Files

T

Ilia Denisov 5b07bb4e14 ui/phase-24: push events, turn-ready toast, single SubscribeEvents consumer

Wires the gateway's signed SubscribeEvents stream end-to-end:

- backend: emit game.turn.ready from lobby.OnRuntimeSnapshot on every
  current_turn advance, addressed to every active membership, push-only
  channel, idempotency key turn-ready:<game_id>:<turn>;
- ui: single EventStream singleton replaces revocation-watcher.ts and
  carries both per-event dispatch and revocation detection; toast
  primitive (store + host) lives in lib/; GameStateStore gains
  pendingTurn/markPendingTurn/advanceToPending and a persisted
  lastViewedTurn so a return after multiple turns surfaces the same
  "view now" affordance as a live push event;
- mandatory event-signature verification through ui/core
  (verifyPayloadHash + verifyEvent), full-jitter exponential backoff
  1s -> 30s on transient failure, signOut("revoked") on
  Unauthenticated or clean end-of-stream;
- catalog and migration accept the new kind; tests cover producer
  (testcontainers + capturing publisher), consumer (Vitest event
  stream, toast, game-state extensions), and a Playwright e2e
  delivering a signed frame to the live UI.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

2026-05-11 16:16:31 +02:00

00001_init.sql

ui/phase-24: push events, turn-ready toast, single SubscribeEvents consumer

2026-05-11 16:16:31 +02:00

embed.go

feat: backend service

2026-05-06 10:14:55 +03:00

README.md

docs: reorder & testing

2026-05-07 00:58:53 +03:00

README.md

Backend migrations

Goose migrations embedded into the backend binary by embed.go. Applied at startup before any listener opens (see internal/postgres).

Pre-production single-file rule

While the platform is not yet in production, every schema change goes into the existing 00001_init.sql file rather than a new 00002_*-prefixed file. The intent is to keep the schema in one canonical place so reviewers and developers do not have to reconstruct the latest shape from a chain of incremental migrations.

Operationally this means that pulling a branch with schema changes requires a fresh database — the only consumer today is local development and integration tests, both of which spin up disposable Postgres instances.

Remove this rule before the first production deployment. From that point on every schema change must be a new migration file with a monotonically increasing prefix, and 00001_init.sql becomes immutable history.

If you need to make a change, edit 00001_init.sql directly. Down migrations should still be kept in sync (they live at the bottom of the file — currently a single DROP SCHEMA backend CASCADE).