Four playtest fixes off the Gitea tracker. The submodule pin moves to v0.7.1 and the version follows
it; the downstream digit resets to :0, since v0.7.0 only ended on :3 because three test packs were
played before it was released.
- An empties-only train may couple a caboose again — a caboose carries the crew, not freight.
- The end of a Day is a modal carrying the standings, the Days left and the combined target, instead
of passing between one click and the next inside the automatic phases.
- A Timetabled train may be discarded to a Department pile for a rival to pick up, governed by a new
discardTimetabled setting that appears in both the New Game dialog and the lobby, on by default. An
Extra never may.
- A blocked passenger platform now gives its reason, including the coach shortage and what ends it.
No new version file and no migration: current.ts's migrations.up is empty and nothing is carried from
0.7.0. GAMES IN PROGRESS SURVIVE THIS UPDATE — all three engine-visible changes only widen what is
legal, so every intent a 0.7.0 game recorded still replays, and the server resumes a save by replaying
it rather than by comparing version strings (src/server/index.ts in the game repo).
README.md and instructions.md both named 0.7.0 and carry the three user-visible changes now.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FLnYR4XtXQNamYJXGYT8oC
The submodule pin is the version; nothing else about the package changed. Four game types in the
lobby, the whole rule set readable before taking a seat, leaving and rejoining a game, and sound in
a multiplayer game for the first time — all upstream, all through the same server this package has
always run.
- startos/versions/current.ts — 0.7.0:3, with release notes in all five languages.
- instructions.md — how a game is set up now, and what Leave / Forget mean for a seat.
- README.md — the bundled version, and a limitation spelled out: a player's identity lives in their
browser, so a lost token cannot be recovered from this package.
- UPDATING.md — how to pack a test build from work that is not pushed yet, which is how v0.7.0 was
played before release, and why the downstream digit moves for each one.
The downstream digit is :3 rather than :0 because three test packs were installed on the box while
v0.7.0 was being played; publishing :0 now would be a downgrade it would refuse.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016JczK5i33ZNSf2PtzZqdhS
Pin moves to v0.6.0, package version to 0.6.0:0.
README and instructions.md both promised the opposite of what now happens
and had to be rewritten: an update keeps games in progress unless the rules
actually changed, and a game that genuinely cannot replay is named in the
log rather than described as a version mismatch.
Verified on phoenix.local by doing the thing the release is about. A game
(MAIL-4571) was created on the installed 0.5.6:0, then this build was
installed over it. All four saved games on the volume came back:
Resuming 4 saved game(s)…
Resumed HOPPER-4607 — 37 intents replayed. (written under 0.5.2)
Resumed TRESTLE-5109 — 5 intents replayed. (written under 0.5.3)
Resumed TENDER-8092 — 38 intents replayed. (written under 0.5.5)
Resumed MAIL-4571 — 0 intents replayed. (written under 0.5.6)
The first three had been refused on every boot since the release that
stranded them. They were never damaged, only unreachable, and replaying
them is all it took to get them back — which is the clearest evidence that
the version comparison was answering the wrong question. All four now show
in Games in Progress with the correct Day, Stage and waiting-on player.
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.
icon.png replaces the scaffold placeholder — resized to 512x512 and
palette-quantized (1.9MB source -> 52.9KB) to stay close to the packaging
guide's 40 KiB guidance with no visible quality loss at icon size. Verified
station-master_x86_64.s9pk builds clean with a single icon.* file (the
packer errors on more than one) and `s9pk inspect` confirms icon.png is
packed correctly.
The `ui` interface now opens at `/play.html` instead of `/`. Root serves
index.html, the game's marketing splash — identical to the public static
solitaire site, and with no lobby or Multiplayer button on it; both live on
play.html (src/web/main.ts's `start()`, reached from index.html's door
link). That page is right for a stranger landing on the public site, wrong
for someone who just installed a dedicated multiplayer server and found
what looked like the same solitaire page with no way to host or join a
game. Verified: fetching /play.html from inside the container and over the
service's public address both return the page with the Multiplayer button
present.
Reinstalled on phoenix.local after each change.
Built from source via a git submodule pinned to a tag, not a published image
— the Dockerfile, main.ts, and manifest should never need to change for an
ordinary version bump, only the submodule pin (see UPDATING.md). One volume,
one interface serving the browser client + lobby/intent API + SSE stream
from a single origin, no dependencies. The server-wide join secret (D14) is
seeded on install, exposed via the Get Join Secret action, and blocks start
behind a critical task until retrieved — the same first-set/rotation pattern
as actual-budget-startos's admin password.
Verified on phoenix.local: installs, the critical task correctly blocks an
ordinary start, force-starting confirms the daemon binds its port and serves
the client, and store.json correctly holds the install-seeded join secret.
Not verified: the Get Join Secret action's execution end-to-end — start-cli's
`package action run` fails with a client-side deserialization error that
reproduces identically against actual-budget's already-shipped equivalent
action, so this looks like a start-cli issue rather than a defect here.
icon.svg is still the scaffold's hello-world placeholder — no real Station
Master icon exists yet to ship in its place.
