Files

T

Ilia Denisov 2ca47eb4df ui/phase-25: backend turn-cutoff guard + auto-pause + UI sync protocol

Backend now owns the turn-cutoff and pause guards the order tab
relies on: the scheduler flips runtime_status between
generation_in_progress and running around every engine tick, a
failed tick auto-pauses the game through OnRuntimeSnapshot, and a
new game.paused notification kind fans out alongside
game.turn.ready. The user-games handlers reject submits with
HTTP 409 turn_already_closed or game_paused depending on the
runtime state.

UI delegates auto-sync to a new OrderQueue: offline detection,
single retry on reconnect, conflict / paused classification.
OrderDraftStore surfaces conflictBanner / pausedBanner runes,
clears them on local mutation or on a game.turn.ready push via
resetForNewTurn. The order tab renders the matching banners and
the new conflict per-row badge; i18n bundles cover en + ru.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

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

00001_init.sql

ui/phase-25: backend turn-cutoff guard + auto-pause + UI sync protocol

2026-05-11 22:00:16 +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).