v0.7.0 — four game types, a lobby you can read and leave, and a multiplayer game that makes a sound

The multiplayer set-up, the lobby, the start of a game, and four signals a remote client had never
been sent. Reasoning, the preset table and what was verified how: CHANGELOG.md.

- Co-op, Competitive, Cutthroat, Solitaire and Custom, on both screens, from one shared block —
  they had drifted, and each was missing a question the other asked.
- A player reads the whole rule set before taking a seat, may leave a lobby or a running game, and
  keeps a seat across a reload. The host may clear a chair. The browser remembers every game it is
  in, not just the last one.
- The start of a game is drawn: a handoff beat, an announcement, the code and type in the header.
- Sound, the timetable flash, announcements and the just-drawn badge now reach a remote client;
  justDrawn goes to the seat that drew it and nobody else.
- Played on StartOS, which found the rest: an Extra belongs to the player who played it, the board
  never named the Superintendent, bot seats were reported as absent players, and rule section
  numbers are out of every string a player reads.

Also carries the previous session's Heavy Grade documentation work — asked again, answer unchanged.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016JczK5i33ZNSf2PtzZqdhS

docs/architecture/lobby-and-sessions.md

@@ -44,8 +44,10 @@ Real accounts can be layered on later without touching the rules engine, which i
 ## 2. Creating and joining
 
 ```
-Lobby.Create { secret, config }            →  { gameId, gameCode, token }
-Lobby.Join   { secret, gameCode, displayName }  →  { token, player }
+Lobby.Create  { secret, config, displayName, players, seed }  →  { gameId, gameCode, token, player }
+Lobby.Preview { secret, gameCode }                            →  { gameCode, hostName, config, players, seated }
+Lobby.Join    { secret, gameCode, displayName }               →  { gameId, gameCode, token, player }
+Lobby.Leave   { token, seat? }                                →  { ok, closed? }
 ```
 
 **These four messages are the one family with no types behind them**, because the engine has no
@@ -60,7 +62,28 @@ per-origin, alongside the token.
 
 A **game code** — short, human-speakable, e.g. `RAIL-4471` — is the discovery mechanism *inside* the
 door. No matchmaking, no browsing, no public game list. Players are already talking to each other; the
-code just needs to survive being read aloud.
+code just needs to survive being read aloud. The seating screen also offers it as an invite **link**
+(`…/play.html?lobby&code=RAIL-4471`), which is what a chat message wants — the link carries the code
+and never the join secret, because the secret is the door key and travels out of band by design.
+
+**A player reads the rules before taking a chair.** `Lobby.Preview` answers the same join secret with
+the whole config, the host's name and who is seated, and takes no seat — added 2026-08-23, when the
+alternative was sitting down blind and (until the same pass) having no way back out. **It never
+carries the seed**: the seed decides every shuffle and every roll in the game, so it belongs to the
+host alone.
+
+**Two players may not share a display name.** The name labels the district on the Division map, it is
+what the turn chart means by "waiting on Jesse", and `record()` puts it in front of every line that
+player causes — so two of them make all three ambiguous, and the names lock at `Lobby.Start`. A
+clashing join is refused (`NAME_TAKEN`, compared trimmed and case-insensitively) rather than silently
+suffixed: a player should play under the name they chose, or be asked for another.
+
+**Anybody may leave, and the host may clear a chair.** `Lobby.Leave` frees the seat, drops the token
+from `joinOrder`, and passes host rights on exactly as a dropped connection does. Naming somebody
+else's `seat` is host-only. When the last human leaves, the lobby is deleted outright — code, file and
+index row — rather than left as a table of bots waiting for a host who no longer exists. Before this
+existed a mis-join or a player who wandered off wedged the whole table, since Start needs every chair
+filled and a bot may not be dropped onto an occupied seat.
 
 **One game at a time per person is expected usage and is deliberately not enforced** (`multiplayer.md`
 §10). Enforcing it needs cross-game state whose only job is deciding when to release someone, and
@@ -88,15 +111,27 @@ The cap is about what has been played, not about what the game can do.
 
 ## 3. Configuration, and when it locks
 
-Set before start, immutable after:
+Set before start, immutable after — the whole of `GameConfig` (`state.ts`), which the host fills in
+by choosing a **game type** and then editing whatever they like:
 
 ```
-mode          : solitaire | competitive | coop
-victory       : firstToTarget | highestAfterDays
-length        : short | standard | campaign
-optionalRules : { reducedVisibility, sisterTrains, employeeRotation, emergencyToolbox }
+mode              : solitaire | competitive | coop
+days              : how long the game runs
+minCombinedRevenue, maxCollisionsPerDay, maxCollisionsTotal   (0 = that condition is off)
+pvpCardsAllowed   : a property of the type, not a control — the cards are unbuilt (setup.ts)
+optionalRules     : { reducedVisibility, employeeRotation, emergencyToolbox }
+houseRules        : { startingHand, extraStart, revenue }
 ```
 
+**The four game types** (`src/web/presets.ts`, Jesse's design 2026-08-23) are Co-op, Competitive,
+Cutthroat and Solitaire, plus **Custom** — which is not a fifth type but the state of having edited
+one, and is scored as whichever type it was edited away from. The type is *derived* by comparing a
+config against the four, never stored, so a saved game carries no label that can disagree with its own
+numbers. Seed, player count and Day count sit ABOVE the type on both screens as **parameters**: the
+types are formulas in the table size and the length (the Revenue floor is 3 per player per Day in
+Co-op, 2 in Competitive, nothing in Cutthroat), so changing one re-derives rather than making the game
+Custom.
+
 These must lock at `Lobby.Start`. Changing `length` mid-game would move the finish line; changing
 `mode` would switch which failure floors apply (§3.4, §3.5). Neither has a coherent meaning
 mid-game, so the server should refuse rather than try.
@@ -141,6 +176,12 @@ to hide it. Show the chain forming.
 **Solitaire is unchanged and must stay so:** one player is one seat, seating is trivially `[0]`, and
 every published replay depends on that.
 
+**What a seat is told as the game begins** (2026-08-23). The board used to simply appear, mid-Local
+Operations, with a log already several bot turns deep and nothing marking where the game began. The
+page now holds a deliberate beat on a handoff curtain, announces the game and its type, marks the top
+of the log, and shows the code and the type in the header for the rest of the game — none of which is
+new *data*, only the first time any of it was drawn.
+
 **Employee Rotation** (Appendix B), if enabled, moves every player one seat left at the end of each
 Day, carrying their Revenue and the Fedora with them. **The model supports this as of v0.4.0**:
 offices and districts are keyed by seat, hands and Revenue and the Fedora by player, and `seating[]`
@@ -163,6 +204,16 @@ if it was their turn. Broadcast a disconnect notice so everyone else can see why
 server-layer news about a *connection*, not about the game, so it belongs with the transport rather
 than in `GameEvent`, which must stay replayable from a seed.
 
+**On connect, a client is told about every other seat at once** (2026-08-23). A change notice alone
+answered "who just left", never "who is here" — so a player arriving at a table where two people had
+not opened the game yet was told nothing about them at all, which is precisely the question at the
+moment a game starts. Each entry carries `seen`, separating **was here and dropped** from **has never
+opened the game**: the first will probably be back, the second needs somebody to send them the link.
+`seen` is remembered only for as long as the process runs, so after a restart every absent seat reads
+as "not here yet" — the more cautious of the two. **Bot seats are never reported**: a bot holds no
+connection and never will, and listing one puts "waiting on Bot 1" on every screen for the whole game
+(found by playing a three-seat game, not by reading the code).
+
 **On reconnect:** the client presents its token and the server replies with a **full current view**.
 Not an event tail — a returning client needs the position, not the history of how it got there, and
 the server can always produce the position because it holds the game