v0.7.9.4 — Gitea#20 step 1, and a Red Flag you can see

Step 1 of the common board done as its own release rather than as the
first hour of 0.8.0, since both halves of it are worth having whether or
not anything is ever published to a call.

#95 — the public projection helpers. `projectDistrict(state, seat)`,
`projectDivision(state)`, `projectSharedTable(state)`,
`publicSnapshot(state)` and `currentActorOfState(state)`, with
`snapshot()` REBUILT to compose from the same helpers rather than keeping
a second copy of the shared table, so a player's frame and a spectator's
cannot come to disagree about the clock, the phase, whose turn it is or
the score. Behaviour-neutral; the 897 existing tests passing unchanged is
the proof.

The public view is composed UPWARD, never by calling `snapshot()` once
per seat. That shortcut is the trap the plan names: `snapshot` assembles
one player's view, so a public view made of player views builds every
private field and then has to remember to strip it — and it defaults its
viewer to player zero, so a careless spectator call would have served
seat 0's hand. Districts are keyed by SEAT with the player resolved
through `playerAtSeat`, because Employee Rotation moves players between
districts and a board that treated seat and player index as
interchangeable would relabel every district the first time anybody
rotated.

One plan finding is struck off rather than fixed: it warns a display
reading `clock.currentActor` could highlight the wrong district during a
decision. Measured over six seeds and 3,600 decision points, that field
and `actingPlayer` never disagreed. `currentActorOfState` exists anyway,
as one place for the next reader to ask.

#91 — the redaction net, systematically. v0.7.9.2's two leaks were found
by reading a plan, not by a test, which is the whole argument for this: a
suite made of the leaks somebody happened to notice proves nothing about
the next one. Serialise a seat's Frame, the PublicFrame a spectator gets
and the narration they receive, then search all three for every opponent
card id, every card name unique to one opponent's hand, the seed and any
private decision or menu data — across a fresh game, a blind draw,
mid-game, a pending decision, Employee Rotation before and after the
seating moves, a reconnect push (a full Frame, and its own opportunity to
leak) and a played-out game. And the allow-list, which is the plan's
stated acceptance bar rather than the tests: every property of
`publicSnapshot` is written down with its reason and compared on every
run, so adding a field fails the suite until somebody has said out loud
that a spectator may see it. Both v0.7.9.2 leaks were fields nobody had
ever asked that question about.

Proved by mutation rather than by passing: restoring the seed line fails
6 tests, restoring the blind-draw card name fails 1, adding a private
field to the public projection fails 7, and making `players[]` carry hand
contents instead of a count fails 5.

Two false failures were worth the lesson. A card NAME is a type, not an
identity — "right-hand curve" names a dozen cards and one is legitimately
a cell label the moment anybody lays track, so searching for it fails on
correct code, which is worse than not searching; a name is evidence only
when every card bearing it is in the one hand. And a one-digit seed makes
the seed check meaningless: seed 7 matched "Train 7". One item on the
plan's list has no test because it has no referent — there is no secret
objective in this game, `objectiveOf` deriving from
`config.minCombinedRevenue` and the player's own Revenue, both public.

#94 — a Red Flag standing at an Office's Limits is on the map. It is a
token set out ON the board that holds the next train arriving from that
side, and it was announced once in the log and drawn nowhere, so a train
stops short three Stages later with its only explanation scrolled out of
the panel. `DivisionView`'s office node carries `redFlag` and the map
draws a staff and pennant AT THE END IT GUARDS — west on the left, east
on the right — because which approach it covers is the whole of the
information; a flag in the middle of the cell would say one is out and
leave the reader to hover for the half that decides whether to run a
train. The tooltip leads with it, ahead of everything that merely
describes the cell.

The third of these in a row after Gitea#21 and #22: when the engine gains
something that changes what a train may do, the question to ask is where
it is drawn, not whether it works.

909 tests pass, up from 897.

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

src/sim/board-svg.ts

@@ -144,6 +144,12 @@ export function divisionSvg(nodes: DivisionView[], roster?: DivisionRoster | nul
      * register under the rail (Gitea#18).
      */
     below?: Cell['trains'];
+    /**
+     * Office cells only: a Red Flag standing at this Office's Limits, and which approach it guards
+     * (#94). A token set out ON the board that holds the next train arriving from that side, so it
+     * is drawn like the other things standing on the map rather than left to the log.
+     */
+    redFlag?: string | null;
     /** Mainline cards only: §2.1 divides one into two regions. 0 elsewhere — no bars are drawn. */
     regions: number;
     /**
@@ -223,10 +229,17 @@ export function divisionSvg(nodes: DivisionView[], roster?: DivisionRoster | nul
           (owner?.isYou ? ' — this is your railroad' : '') +
           // "their move" is wrong when the reader is the one being waited on.
           (owner?.isTurn ? (owner.isYou ? ' — it is your move' : ' — it is their move') : '') +
+          // #94 — first, and in full, because it is the one thing here that CHANGES what a train
+          // may do. Everything below it describes the cell; this describes a rule in force.
+          (n.redFlag === 'east' || n.redFlag === 'west'
+            ? `\n\nRED FLAG set out at the ${n.redFlag === 'east' ? 'East' : 'West'} Limits — the ` +
+              `next train arriving from the ${n.redFlag} is held short, and the flag is spent doing it.`
+            : '') +
           `\n\nThe district itself is drawn on the Office map — this cell is the whole of it, with the ` +
           `trains standing in it: those holding an A/D track on the rail, and any crew switching in ` +
           `the district below it.`,
         seat: n.seat ?? null,
+        redFlag: n.redFlag ?? null,
         // No regions in a district: a crew moves by Moves there, not by Stages, so it occupies a
         // card outright rather than a part of one.
         regions: 0,
@@ -364,6 +377,30 @@ export function divisionSvg(nodes: DivisionView[], roster?: DivisionRoster | nul
       out += `<line class="bs-region" x1="${c.x + 6 + RW * r}" y1="${c.y + RAIL_Y - 14}" x2="${c.x + 6 + RW * r}" y2="${c.y + RAIL_Y + 10}"/>`;
     }
 
+    /**
+     * A RED FLAG STANDING AT THE LIMITS (#94).
+     *
+     * Drawn at the END IT GUARDS — west on the left, east on the right, since east is right on this
+     * map — because which approach it covers is the whole of the information. A flag in the middle
+     * of the cell would say a flag is out and leave the reader to hover for the half that decides
+     * whether to run a train.
+     *
+     * A staff with a pennant, at rail height, standing clear of the chips: it is beside the rail,
+     * which is where a flag is. Red is otherwise unused on this map (`bs-full` tints a cell, it does
+     * not draw), so the mark does not compete with anything for meaning.
+     */
+    if (c.redFlag === 'east' || c.redFlag === 'west') {
+      const west = c.redFlag === 'west';
+      const fx = west ? c.x + 9 : c.x + c.w - 9;
+      const top = c.y + RAIL_Y - 22;
+      const dir = west ? 1 : -1;
+      out += `<g class="bs-flag">`;
+      out += `<line x1="${fx}" y1="${top}" x2="${fx}" y2="${c.y + RAIL_Y + 4}"/>`;
+      // The pennant flies INTO the cell, so it can never overhang the card edge at either end.
+      out += `<polygon points="${fx},${top} ${fx + dir * 13},${top + 5} ${fx},${top + 10}"/>`;
+      out += `</g>`;
+    }
+
     /**
      * WHICH WAY A HEAVY GRADE CLIMBS, drawn rather than only said.
      *
@@ -1205,6 +1242,9 @@ export const BOARD_CSS = `
 /* The vertical bars a Mainline card is divided into (§2.1). Drawn faint: they are the ruler the
    train is measured against, not something to look at instead of the train. */
 .bs-region{stroke:#4a5361;stroke-width:1.2;stroke-dasharray:3 3}
+/* #94 — the one red mark on the Division map, so it reads as a stop rather than as decoration. */
+.bs-flag line{stroke:#9aa3b0;stroke-width:1.6}
+.bs-flag polygon{fill:#d2453f;stroke:#7d211d;stroke-width:0.8}
 /* THE HEAVY GRADE WEDGE. Terrain, so it is coloured as terrain rather than as a warning.
    SOLID BROWN, fill and border the same (Jesse, 2026-08-30) — the first pass paired a desaturated
    fill with an amber arrow and the pair read reddish, which on a map that spends amber on "it is