The terminal sees the rooms this deployment is holding: a tab for live rooms, with the age of what it is showing #337

A person can make a room on the page. On the app's terminal they cannot tell that a single one exists — src/tty.ts cycles standings, matches, the policy card, the day's board and the range's runs, and knows nothing about src/rooms/. Rooms are the only live state this app holds: twenty of them at the cap, each a world stepped 64 times a second, each holding people. An operator asking "is the box busy, and with what?" has no answer, and AGENTS.md says what a person can do on the page they should be able to do here too.

The honest difficulty, which is most of this issue: the terminal is a second process. ssh runs bun run src/tty.ts beside the server, not inside it, so it cannot read the hub's memory. The room's code is also the only thing protecting a room, so the answer is not an HTTP listing.

Done looks like

• [ ] The hub publishes a snapshot of itself through the writer seam #318 gives it — handed in, so src/rooms/ stays database-free — written on the sweep and never per tick: the code, the map, the phase and clock, how many people and how many bots, and how long the room has been idle.
• [ ] A rooms view in src/terminal/screen.ts, reached by tab in the shape the other tabs have: one row a room, a header saying how many of ROOM_CAP are open, and the age of the snapshot on the screen, so a stale view reads as stale rather than as truth.
• [ ] Rooms die with the process, so a snapshot older than the run is not shown as live: cleared or aged at start-up, with the rule stated where it is written.
• [ ] No rooms is a sentence, not an empty box. Every number on it is read from the thing it describes (#306's rule), including ROOM_CAP itself.
• [ ] Read-only, and the docstring says that was a choice: closing a room from the terminal needs the seam in the other direction and is its own issue.
• [ ] src/tty.test.ts and src/terminal/screen.test.ts drive the tab against a database under a temporary directory — no server, no socket.
• [ ] What it costs is stated: how often it writes, how many bytes a write is, and what the tab shows when nothing has ever written.
• [ ] bun test green.

Files

src/rooms/hub.ts (the reporter call), src/server.ts (hands the reporter in, beside #318's match writer), src/db.ts and src/db.test.ts (where the snapshot lands), src/terminal/screen.ts and its test, src/tty.ts and src/tty.test.ts.

Risks

• Do not add an HTTP endpoint that lists rooms. A six-character code is a room's only secret; a public listing hands every open room to anyone who asks. The terminal is behind ssh and the database is on disk beside it — that is the whole reason this goes through storage.
• Writing per tick would put 64 writes a second per room on the same sqlite file the leaderboard uses. Write on the sweep, state the interval, and measure it.
• #318 introduces the writer the hub is handed; land it first or two different seams arrive for the same idea.

Suggested: Torque — it is a measured, read-only view of live state with its own staleness stated.

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

Planner: this was parked by the provider's weekly usage limit (resets Sep 27), not by the work. The run pushed nothing, so nothing in the issue is disproven. It stands as written and is ready again.