d905c86e69cf0f017eb3dcca4deb9b176a5e0ae3
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 JesseandClaude Opus 5
|
d905c86e69 |
0.8.1.0:0 — bundle Station Master v0.8.1.0, and date the games in Manage Game
A table pass over 0.8.0.17. The second-digit bump is deliberate: 0.8.1 had been reserved for the seatless display table, which is getting more thought, and this batch earned the number on its own. GAMES IN PROGRESS RESUME, AND IT WAS MEASURED BEFORE RELEASE rather than argued from the diff. The bundled release changes what sits in the yards, so the risk was real. All twelve saves on the test box were pulled and replayed through `tryResumeSession` — the server's own boot check — against the new build: six resume, six refuse, and the six refusals are the SAME six, at the same moves, with the same codes, that 0.8.0.17 already logged. Nothing new was stranded. That replay is the check worth repeating on any release that touches state, because it answers before the install rather than after. THE GAME'S OWN FIX, for the README's benefit: the Freight Agent's "clear the red Inbound box" returned the car to the Classification Yard still marked loaded, carrying a load already delivered and already paid for. `pooled()` strips a load's `origin` stamp and keeps `loaded` on purpose — a train can retire at a Division Point with freight aboard — so the call site's comment, "a car back in a yard is back in the common supply, carrying nothing", described something it never did. Coaches suffered worst: detraining takes `coach && !loaded` out of the Division Yard, so a cleared coach came back as stock that could never unload a passenger. 18 loaded coaches against 6 empty over five measured games. THIS PACKAGE'S OWN CHANGE IS THE MANAGE GAME DROPDOWN. It listed each game's code, seat count and position and nothing about when the game was last touched, so four games on a server looked alike — reported 2026-09-22: "I've got four games out there, but I have no idea which one's which or how old they are." `lastMoveAt` was already on the wire from the server's `summary()` and simply unused. Each option now carries both an age and a timestamp, because they answer different questions: "5h ago" answers the one that was asked, and the date beside it is what you quote when deciding to end a game. A lobby has had no move, so it reports when it was created and says so. `when()` moved out of `gamesInProgress.ts` into `utils.ts` alongside a new `ago()`, shared by both actions so an administrator sees one date format wherever a game is named — the second copy would have been the one that drifted. No route, file model or interface changed. README and instructions.md carry the release, and the notes in all five locales say games in progress are unaffected. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MUizFYCMHRWhbWwXhp7WPR |
||
|
Jesse
|
c95620d566 |
Bundle Station Master v0.5.3: games in progress, and a way to end one
Pin moves to v0.5.3, package version to 0.5.3:0.
The health check no longer just probes a port. It fetches the server's own
/api/health and reports what it says — "Multiplayer server is ready — 3
games in progress", with ", 1 waiting to start" appended only when a lobby
exists and "no games in progress" on an idle server. A server that doesn't
answer is reported as STARTING, never failed: the server replays its saved
games before binding its port, so a boot legitimately looks like nothing is
listening, and calling that a failure makes an ordinary restart look like a
crash.
Two new actions, both only-running. Games in Progress is read-only and
lists every game and lobby with players, Day/Stage/phase, who it waits on,
when it started and when it last moved. Manage Game picks one from a
dropdown built live from the server and either exports it or ends it —
ending being the only way a game finishes other than being played out,
since an abandoned game otherwise stays active and is resumed on every
restart forever. Ending always returns the deleted game's save, so nothing
is destroyed without being handed back first.
They are only-running because none of it is readable from disk: a save is a
seed plus a list of moves, so whose-turn-it-is exists only after a replay
through the engine, which lives in the game repo rather than here. The
running server has already done that work and is asked for the answer.
startos/serverApi.ts is the single place that asks.
store.json gained adminSecret (32 chars) beside joinSecret, seeded on
install and backfilled on update for a volume written before the field
existed. It is deliberately NOT the join secret: every player holds that
one, so gating a delete with it would let anyone at the table destroy
anyone else's game. init/generateJoinSecret.ts is renamed generateSecrets.ts
now that it mints both.
Also brought getJoinSecret's result strings under i18n(). They shipped as
plain strings two commits ago, which actions.md is explicit about — every
user-facing string including result titles, messages and thrown errors.
The new actions follow it, so the old one shouldn't be the odd one out.
Verified on phoenix.local, installed as an UPDATE from 0.5.2:0 rather than
a fresh install, which exercised three things at once: the boot log line
("Resuming 1 saved game(s)…"), the engine-version refusal firing for real
on a game recorded under 0.5.2, and the adminSecret backfill (store.json
came out with both secrets, 24 and 32 chars). Then, from inside the
container: the package-generated admin secret authenticating against
/api/games (200) while a wrong one is refused (403), health counts tracking
0 -> lobby 1 -> active 1 through a create/bot/start, and every field the
actions render present and correct on the listing.
NOT verified: the actions' own forms and result rendering. `start-cli
package action run` fails with a client-side deserialization error on every
action on this box — including the already-shipped get-join-secret and
actual-budget's equivalent — so it is a start-cli problem, not this
package's. The data path underneath them is verified above; the SDK
form/result rendering needs the web UI.
A test game (TRESTLE-3221, Alice + a bot) is left running on the box so
there is something for Games in Progress to show.
|