Ilia Denisov
b3f24cc440
Item 7 of the spec wants game-state and membership-state changes to land as durable inbox entries the affected players can re-read after the fact — push alone times out of the 5-minute ring buffer. Stage B adds the admin-kind send matrix (owner-driven via /user, site-admin driven via /admin) plus the lobby lifecycle hooks: paused / cancelled emit a broadcast system mail to active members, kick / ban emit a single-recipient system mail to the affected user (which they keep read access to even after the membership row is revoked, per item 8). Migration relaxes diplomail_messages_kind_sender_chk so an owner sending kind=admin keeps sender_kind=player; the new LifecyclePublisher dep on lobby.Service is wired through a thin adapter in cmd/backend/main, mirroring how lobby's notification publisher is plumbed today. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.sqlbecomes 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).