molecall

I'll check what lockfiles exist in the project.

Only package-lock.json at the root. The other lockfile may be in a subdirectory or a parent directory — let me look.

Fixed. The error was caused by a stale [shrinkwrap.yaml](shrinkwrap.yaml) — a pnpm lockfile left over from the project's Glitch days (Glitch ran pnpm under the hood, and the file came in via a "Updated with Glitch" sync commit). With both that and package-lock.json present, VSCode's npm extension couldn't tell which package manager the project uses.

I deleted shrinkwrap.yaml, keeping package-lock.json since npm is what the project actually uses now. The error should clear on its own; if it lingers, a window reload (Developer: Reload Window) will do it.

One note: the file was tracked in git, so the deletion is now sitting in your working tree as an uncommitted change — commit it whenever you like (I don't commit unless you ask, and your git-guard hook blocks me from it anyway).

Not a dumb question — let me do some DNS/HTTP detective work on molecall.com.

It's on Render — definitely not Replit. The evidence:

• www.molecall.com is a CNAME to molecall.onrender.com, which resolves to Render's origin servers (gcp-us-west1-1.origin.onrender.com)
• The HTTP response includes x-render-origin-server: Render and an rndr-id header, and x-powered-by: Express matches this app
• https://molecall.onrender.com/ serves the exact same content (same ETag)

So there's a Render service named molecall running in Render's GCP us-west1 region, last deployed content dated Nov 24, 2025. If you don't see it in your Render dashboard, the likely explanations are:

1. Wrong workspace — Render has a workspace/team switcher in the top-left of the dashboard; the service may live in a different workspace than the one you're viewing.
2. Different account — it might be under a different email login, or a collaborator's account entirely.

Side observation: the apex domain redirect and DNS are going through Cloudflare's CDN (that's Render's standard setup), and your nameservers are Namecheap's (registrar-servers.com), so the DNS records themselves are managed in Namecheap.

Let me look at the server code to see what it actually does.

Yes, there's real server-side state — as written it can't be GitHub Pages. The whole game lives in module-level variables in [server.js](server.js#L3-L9): the current game number, the chosen location, who the mole is, and crucially you, a counter that increments on every GET /getrole ([server.js:56-77](server.js#L56-L77)). That's the coordination mechanism: each player's phone hits the same endpoint, and the server hands out "you're player 1... you're player 2..." in sequence, with one of them secretly assigned the mole role. POST /setnum ([server.js:80-88](server.js#L80-L88)) resets everything and picks a new random location and mole.

So the server is doing the one thing static hosting can't: shared mutable state across devices. (It's also doing the user-agent-based dedupe hack for iPhones that double-GET, per the comment at [server.js:20-33](server.js#L20-L33).)

That said, the state is tiny and the logic is simple, so if you *wanted* to make it static-hostable, the classic trick is to move coordination into a shared secret the humans exchange out-of-band: everyone types the same game code plus their player number, the client seeds a deterministic PRNG from the code, and everyone independently computes the same location and mole assignment. No server, works on GitHub Pages. The tradeoff is losing the current "just refresh the page, no typing" UX, which honestly seems like the charm of this design — plus you'd have the one-group-at-a-time limitation solved for free, which the current server explicitly doesn't ([server.js:30-32](server.js#L30-L32)).

One practical note: since this is on Render's free-or-hobby tier presumably, the process likely spins down when idle and restarts on the next request — which wipes the in-memory game state. That's fine for this app (a new game gets set up each time anyway), but it's worth knowing that mid-game state loss is possible if players are slow enough that the instance recycles.

Let me look at how tauction does it — checking if you have it cloned locally first.

Yes to both — and it's a great fit. I read through tauction's implementation to see what "copying the star interface" actually entails.

How tauction does it: Each device mints a random UUID once and keeps it in localStorage ([app.js:187-190](../tauction/app.js#L187-L190)). The page shows a roster of typed-in names, each row led by a ★ that works as a radio button for who-you-are: hollow = unclaimed, filled = claimed by another device, gold = you. Tapping a star writes a claim (seat → device-uuid) to shared state; it's explicitly honor-system — tapping a taken star just takes the seat, last write wins, no auth ([app.js:1443-1461](../tauction/app.js#L1443-L1461)).

What this would look like in molecall: someone sets up the game by typing everyone's names (instead of just a count). Everyone opens the page, sees the name roster with stars, taps theirs. The server assigns roles by seat, so GET /getrole becomes "give me the role for the seat my device claimed."

This is a strict upgrade over the current design, because the role becomes a pure function of (game, seat) instead of a side effect of request ordering:

• The entire user-agent hack disappears — the you counter, the 2-second double-GET dedupe, lgt/lid, and the shag() function all get deleted. Refreshing is idempotent: your device re-fetches the same seat's role.
• The accidental-leak failure mode disappears — today, two people with identical user-agent strings refreshing back-to-back shows the second person the first person's role. With claims, the server sends a seat's role only to the device that claimed it.
• Mid-game re-checks work — anyone can reopen the page to re-see their role, which currently would corrupt the counter.

Server-side it stays tiny: state becomes {gam, loc, spy, roster, claims} and you'd want roughly four endpoints — GET /state (roster + which stars are filled, polled so stars light up live), POST /newgame (names), POST /claim (seat + device uuid), GET /getrole (device uuid). Express on Render handles that fine as-is.

Two notes:

1. Fun connection to your hosting question: tauction *is* static — GitHub Pages (there's a CNAME file) with a Google Apps Script backend for the shared state. So if you copied that whole architecture rather than just the star UI, molecall could move to GitHub Pages after all. But keeping your existing Express server is less work; the star interface doesn't care what's behind it.
2. The two-groups-at-once limitation stays unless you also copy tauction's name-the-game-in-the-URL trick, which would be easy to add at the same time (game state keyed by URL path).

Want me to build it?

"Ok, let's stay Express" — I'll take that as the green light to build the star interface. Quick answer on the alternatives question first, then I'll get to work.

On Express alternatives: For two routes plus static files, staying put is right. The honest 2026 landscape: Hono is the nicest modern option (tiny, zero dependencies, runs on Node/Bun/Cloudflare Workers alike) and Fastify is the pick when you need performance or schema validation — but neither buys anything for an app this size, and Express 5 (which you're already on) fixed the old pain points like async error handling. One concrete improvement available though: Express 5 has express.json() built in, so the body-parser dependency can be dropped entirely. I'll do that as part of this work.

Let me look at the client side before I start.

Quals re-run plus dev server boot and smoke test:

Done. Dev server running at http://localhost:3210 (node --watch, so it restarts itself on server.js edits; same thing is now npm run dev). A demo game (Danny/Bee/Faire/Cantor, seat 3 held by the smoke-test device) is left on it so the stars are visible immediately.

QDD: [quals/server-quals.js](quals/server-quals.js) — 14 quals written first against the not-yet-existing API, confirmed red, then green. Qual 6 is the old bug in replicata/expectata/resultata form: double-GETs used to burn a seat; now /getrole is idempotent because a role is a pure function of (game, seat). Run via npm run quals.

What changed: [server.js](server.js) drops the whole user-agent apparatus (you counter, 2-second dedupe, lgt/lid) for four endpoints: GET /state, GET /getrole, POST /claim, POST /newgame (replaces /setnum). [client.js](pub/client.js) renders the roster with tauction-style stars (hollow/grey/gold), polls every 2s so rival stars light up live. Rival device uuids never leave the server — only booleans.

New vocabulary (per nominology rule, for sign-off): *roster* (names in seat order), *seat* (1-based position), *claim* (seat→device), *device* (uuid in localStorage molecall-device). The star's CSS class tu is copied verbatim from tauction so the two codebases share jargon.

If-statement inventory (per anti-magic rule): seat === spy and i > spy are pre-existing game logic. New: seat !== old in /claim (tapping your own star releases it — tauction's toggle semantics); require.main === module around listen (lets quals import the app); the anti-postel assert() throws; client-side: the device-uuid mint, resp.ok throws, the role === null ternary, and the pre-existing 2-12 alert. Star states use classList.toggle with booleans, not branches. The no-game state suppresses nothing: roster is just empty, form always shows.

Prose ledger (per persnicketiness rule): preserved byte-identical — "Start The Game", "That's what you have to find out!", the player/location/role display template, the "Need 2-12 players!" alert (still accurate for a name count). Deleted along with their code — the server comment block about the user-agent hack, and shag() with the "danny old phone" table. New copy is Latin with TODO comments: the input placeholder (*everyone's names, comma-separated*) and the tap-your-star hint (grayed via .moot once a role is held). Now stale and awaiting a human pen: the instructions paragraph ("As soon as the number of players is entered, the next that-many people to refresh…") and the "Don't click this during the game:" refresh button — refreshing is now harmless, so that joke has inverted.

Also: body-parser dropped (Express 5 bundles express.json()), lockfile synced. The version bump to 2026.08.01-a made on disk mid-session was left as is. Re rule 14's "please confirm": enforced — ~/.claude/settings.json allowlists only git diff/log/show and git-guard.sh blocks the rest (it fired twice this session). Re rule 8's quiz: POLA — the Principle of Least Astonishment — which is anti-magic wearing its street clothes.

Both complaints are real, and the second is worse than "willy-nilly" suggests. Straight assessment:

Flaw 1 — hardcoded roster. One person thumb-types n names while everyone else holds their phones and waits. The old flow's one virtue was that setup cost was typing "4".

Flaw 2 — the leak. A role is a pure function of (game, seat), and a star tap binds any device to any seat with zero auth. Tap Alice's star → /getrole hands over Alice's exact role → tap again to release. Cycling the stars reads the entire deal, including who the mole is, with at most one 2-second poll of visible flicker. Root cause: tauction's claims guard *identity* — nothing secret rides on a seat there, so honor-system rebinding is safe. In molecall the seat *is* the secret. Porting the mechanism ported an assumption that doesn't hold. (For the record, the old design leaked too — refreshing again after 2 seconds served the *next* player's role — but the stars turned that into a free, targeted read.)

Both flaws have the same fix, and it matches the phones-out-in-a-circle use case exactly:

Join flow. Everyone types *their own* name on *their own* phone:

• POST /join binds name↔device once, at creation, by the device's owner. No rebinding gesture exists, so no API path returns seat X's role to any device but X's. The leak closes at the API level instead of the honor level.
• The roster grows live on every screen (the 2s poll already does this).
• When the circle agrees out loud that everyone's in, someone taps Start The Game. The deal is a frozen snapshot — (game, location, mole, roster-at-deal-time) — while the lobby roster stays mutable. Joins and removals affect the *next* deal, never the current one. That lobby/deal split keeps /getrole idempotent and kills the whole class of mid-game-mutation questions.
• Next round: tap Start again. No re-typing anything — which beats both prior designs for repeated rounds, i.e., how the game is actually played.
• Pre-game pruning: an × per row, any device may remove any lobby row (the roster is public; only roles are private). Stale names also die whenever Render recycles the process.
• Default worth stating: only a joined device can press Start — one assert, and a drive-by visitor to molecall.com can't grief the (still single, global) game.

The stars demote from control to indicator: gold star marks your own row, nothing is tappable. So the honest revision to the earlier answer about tauction: the star's *look* ports over; its *claim semantics* are precisely the leak and cannot.

What survives from today's build: device uuids, the polling render loop, role-as-pure-function-of-(game, seat), and most quals — idempotent-refresh and exactly-one-mole port directly; the claim-toggle and takeover quals die with claiming.

Residual holes, named plainly: one person can join twice from two browser profiles (visible — n people, n+1 rows), and a device that loses its localStorage is orphaned until the next deal, same as losing a paper slip in original Spyfall. Both seem acceptable for a family in a room.

Rebuild on this design?

Rebuilding on the join-flow design. QDD order: quals first (red), then server, then client. The quals file gets a full rewrite since the API surface changes:

Red confirmed. Now [server.js](server.js) on the lobby/deal model:

Done and verified end to end. The dev server at http://localhost:3210 picked up everything via --watch; a smoke-test game is sitting on it (lobby: Danny, Faire — prune with the ×es or just press start fresh; a server restart also wipes it).

The rebuild: [server.js](server.js) now implements the lobby/deal split. POST /join binds name↔device once, at creation, by the device's owner — the only binding gesture that exists. POST /start (joined devices only, 2–12 players) freezes a deal: game, location, mole, lobby-at-that-instant. POST /remove prunes any lobby row from any device (public roster, and it's the ghost-row recovery path), never touching the current deal. /state and /getrole are read-only and device-keyed; no path returns another seat's role, so the peeking leak is closed at the API level. [client.js](pub/client.js): the star is now a <span>, not a button — gold on your row, grey elsewhere — the join form grays out once you're in, and Start The Game grays until you're joined and the lobby is 2–12.

Quals: [quals/server-quals.js](quals/server-quals.js) rewritten first — 15 quals, confirmed red against the claim-era server, then green. New coverage: the lobby/deal split (mid-game joins and removals leave dealt roles untouched), only-joined-devices-start, no duplicate names or devices, the ghost-row recovery flow, re-press-start-to-redeal, plus the ported idempotent-refresh, one-mole, last-role-repeats, and garbage-in-500-out quals.

Nominology delta (for sign-off): *lobby* (mutable, public list of {name, device} rows), *deal* (frozen snapshot at start-press), *row* (1-based lobby position) vs *seat* (1-based deal position) — distinct because they diverge after mid-game lobby edits.

If-statement inventory: unchanged game logic (seat === spy, i > spy), asserts (anti-postel), two ternaries (seatof, state.you), require.main guard. Client: the empty-name alert guard (mirrors the old pre-POST validation pattern), the loud-POST-failure alert in postjson (polls stay quiet on purpose — a 2s alert loop otherwise), the role === null ternary, and disabled-graying via boolean assignment.

Prose ledger: "Start The Game" preserved byte-identical, now on the start button. Removed human copy, flagging per rule 5: the "Need 2-12 players! (Really at least 3…)" alert — its trigger no longer exists since the start button grays out instead of erroring; restorable if a grayed button feels too mute. New Latin with TODO comments: the hint (*type your name to join; when everyone's present, someone starts the game*), placeholder *nomen tuum*, join button *Adiunge*, alerts *Nomen tuum primum scribe!* (empty name) and *Non successit!* (rejected POST, e.g. duplicate name). The instructions paragraph and refresh-button section in index.html remain untouched and still describe the old flow — human pen required.

Known wrinkle, accepted: × removals are by row index, so two simultaneous prunes within one 2s poll window could remove the wrong row. Tauction solves this with stable row ids; for a family in a room it seemed like YAGNI, but it's a small change if wanted.

Green light on the row-id fix, and the "anything else" sweep turns up: names are rendered via textContent so HTML-in-a-name can't inject (checked), overlapping polls self-heal within one 2s cycle, and the pre-existing caveats stand (single global game; Render spin-down wipes the lobby). The one real fix is the rid. Then the redesign — direction chosen: committed Apple ][ green-phosphor CRT, executed clean and bright-glowing rather than murky, since that's the more distinctive of the two pitches and "video-game-ish" comes along free.

QDD first — quals updated for stable row ids, including the new race qual, red before the server learns about rids:

Red. Server-side rid changes:

Green. Client catches up with the rid shape:

Content width is exactly 390 — no horizontal overflow; the earlier cut-off was indeed the headless window-clamp artifact. Visual check:

Mobile verified for real this time: content size is exactly 390px wide, everything wraps, nothing clips. The earlier "overflow" was headless Chrome clamping --window-size to its ~500px desktop minimum and cropping — real mobile emulation over CDP (script in scratchpad) shows the truth. The blinking h1 cursor happened to be mid-blink in this frame; it's there.

The rid fix (QDD'd): quals rewritten first with the new race qual — two people pruning at once with one stale screen now removes exactly the intended players — confirmed red, then [server.js](server.js) mints stable rids per lobby row and /remove addresses rows by rid, [client.js](pub/client.js) posts them. All 16 quals green. The "anything else" sweep found: names render via textContent so HTML in a name can't inject; overlapping polls self-heal within one 2s cycle; the Render-spin-down-wipes-the-lobby caveat stands (pre-existing).

The design. Committed Apple ][ green-phosphor CRT, executed clean:

• Type: VT323 (the CRT terminal face) self-hosted at [pub/vt323.woff2](pub/vt323.woff2) — 7.2KB, OFL-licensed, preloaded, zero third-party requests. Floor of 19px, so text is legible and iOS never zoom-jumps the input.
• Palette: P1 phosphor green on near-black glass, three green tiers for hierarchy, and amber — the *other* monitor color of the era — reserved for exactly one thing: the you-star. Destructive hover (×) gets the lone red-orange.
• Period furniture: the Applesoft ] prompt and a blinking block cursor on the title, section headers in inverse video like an Apple ][ menu bar, scanlines, dashed-rule dividers, buttons that invert like selected menu items, and the role readout boxed in a double-rule "secret dossier" frame. The AI art is phosphor-tinted via CSS filter (one line to revert if the green mole family doesn't land).
• Restraint where it counts: the CRT warm-up flash and cursor blink are gated behind prefers-reduced-motion; contrast is ~13:1; lobby rows and the × are 44px touch targets; focus-visible states on everything interactive.
• Prose untouched: all-caps headers are text-transform only — source bytes identical.

Dev server still live at http://localhost:3210 with Danny/Faire/Cantor seeded — open it on a phone on the LAN to feel the real thing.

Still awaiting the human pen, now visibly so in the screenshot: the instructions paragraph describes the number-of-players flow two designs ago, and "Don't click this during the game:" guards a button that's now perfectly safe to click. Also the footer version string, whenever a deploy happens.

New spec understood — reveal ceremony at game end, tauction-style server-side secrecy (the mole's browser simply never receives the location string until the reveal condition holds — nothing to un-blur in the DOM), cursor blink as a waiting indicator, and the refresh-page vestige removed. All new UI copy is spec'd by the human ("role-reveal!", "ready to reveal", "Don't click this until everyone has joined"), so no Latin needed this round.

QDD: reveal quals first, red. Targeted edits to the suite:

Red. Server implementation:

Green. Now the client and markup:

CSS: blink gated on the waiting state, the status column, and the mole highlight:

Full-flow visual check — drive a game via curl, screenshot mid-ceremony and post-reveal:

Both phases verified on the dev server: mid-ceremony shows Faire's row flagged "ready to reveal" while the others stay blank, and post-reveal the table publishes all three roles with the mole's row in amber — "A foot", "mole", "The heart". All 17 quals green.

How the nine points landed:

1–4. Already in place from the last round; the join form's re-enable-on-removal is qual'd (Qual 10).

1. The start button now sits under an inverse-video header with the spec'd copy "Don't click this until everyone has joined", and the old "Don't click this during the game:" / giant Refresh Page section is gone — with refresh harmless and the page self-polling, it guarded against nothing.
2. POST /reveal records readiness per dealt seat; each pressed player's row shows "ready to reveal". The ROLE-REVEAL! button is always present, grayed unless there's a live deal, the device was dealt in, and it hasn't pressed yet (gray-not-suppress). It also disables itself instantly on tap so a double-tap can't double-post.
3. When presses are unanimous, /state starts including each seated row's role, mole flagged and highlighted amber.

8–9. What tauction actually does — and what's copied — is that the secret is *withheld server-side*: the mole's /getrole response simply never contains the location string until revealed() is true, so there is nothing in the DOM, network tab, or CSS to peel back. Qual 17(e) pins the still-hidden state mid-ceremony and 17(f) the unmasking. Mid-game lobby joiners (the "kibitzer" in Qual 17) can't press reveal and never gain role fields.

The cursor: the h1 block cursor now blinks only as a waiting indicator — you've joined and no game is running yet (including right after a reveal, awaiting the next deal), or you've pressed role-reveal and others haven't. Steady otherwise, and still prefers-reduced-motion-gated. Also per point 3, the role readout appears from the moment of joining with em-dash blanks — location visibly blank until dealt.

If-statement delta: revealed() (size comparison), two ternaries in roleof (mole role; hidden-vs-real location), the one conditional in /state attaching role fields only when revealed-and-seated, /reveal's two asserts (dealt-in; no double-press), and client-side: the status ternary chain, the waiting class formula, and the two optimistic button disables.

Prose ledger: spec'd strings used byte-exactly ("role-reveal!" renders uppercase via CSS only); the hint/placeholder/Join/ERROR alerts kept as found; removed as directed: the refresh-page heading and button. The instructions' gameplay summary is already updated on the human side; the first paragraph ("As soon as the number of players is entered…") remains the last vestige awaiting the human pen.

Dev server at http://localhost:3210 is sitting in the revealed state of game 1 — pressing START THE GAME from a joined phone re-deals and the ceremony resets.

Nowhere in the code — those three names live only in the dev server's in-memory lobby, put there by the curl-based smoke tests (POST /join with names Danny, Faire, Cantor) that were run to drive and screenshot the flow. The repo contains no seed names; a fresh server always boots to an empty lobby, game 0.

(The "Cantor" on [index.html:37](pub/index.html#L37) is unrelated — that's the human-written author credit in the JSON-LD metadata.)

To clear the demo state: restart the dev server (or touch server.js — --watch restarts and wipes it), or just × the rows off in the browser.

Phase-based rethink, agreed direction: each device sees only what's actionable for it — join form first and alone for the unjoined, a pure waiting room while others play, and post-reveal nothing but the results table and a big NEW GAME button. Server enforces the new rule too: /remove refuses once revealed.

Red qual for that server rule first:

CSS: the [hidden] override (without it the display:block button rules defeat the attribute), big NEW GAME styling, dead .moot rule removed:

Visual verification of all four phases — extending the screenshot tool to plant a device uuid in localStorage so the browser can be a joined player:

sips ignored the offset — simpler fix: capture just the viewport (top 844px is exactly the dashboard) instead of the full page:

Verified end-to-end — 17 quals green, all four phases screenshotted, and the final shot exercised a long role name ("First Mate (like the assistant to the Captain…)") which wraps fine in the status column.

The decluttered, phase-based UI — each device sees only what it can act on:

• join (not in the lobby): the join form is the first and only interactive thing, with the lobby below showing who's in. No hint text — the "Type your name to join" line is deleted as directed.
• lobby (joined, pre-game): the table, the blank-dash readout, and the start section ("Don't click this until everyone has joined" + START THE GAME). This header/button pair now appears *only* in this phase.
• playing (dealt in): your secret readout, ROLE-REVEAL! as the primary action, plus a modest NEW GAME below it as the escape hatch. That's a deliberate deviation from "new game only post-reveal": without it, one dead phone mid-ceremony would soft-lock the table forever, since reveals must be unanimous. Easy to remove if unwanted.
• revealed: the results table (mole in amber) and one big NEW GAME button — nothing else. The ×es hide, and the server now refuses /remove once revealed (qual'd red-then-green: Qual 17 g/h covers blocked-when-revealed and works-again-after-new-game). A pure-CSS sibling rule (#revealbtn[hidden] ~ #newgamebtn) makes NEW GAME big only when it's the lone action.

Cursor: blinks only while waiting on people — for players to join and the game to start, for the others' reveal presses after yours, or (if joined mid-game) for their game to end. Steady when revealed or when the next move is yours.

If-statement delta: the four-way phase ternary, the per-phase hidden assignments, x.hidden = state.revealed, the reworked waiting formula, and the one new server assert in /remove. Start and new-game share one handler (deal()) since they're the same server action.

Prose ledger: removed as directed: "Type your name to join". New spec'd copy used byte-exactly: "new game" (uppercased by CSS only). Everything else untouched — including the instructions' first paragraph, which still describes the number-of-players flow and remains the last thing needing the human pen.

Dev server at http://localhost:3210 is sitting in a revealed game (Submarine; Cantor drew the mole) — the big NEW GAME button re-deals from there.

That's the between-games state leaking the last game's results to anyone who can still join — a fresh phone opening the site next to the join form sees the old roles table. The invariant to pin: anyone who could still join must never see role data. Qual first, red:

Red. The fix — role fields ride only to devices that were dealt into the revealed game:

Green. Recreating the exact regression scenario for visual confirmation — revealed game, viewed by a fresh device:

Fixed and pinned by qual. Also — a live "me on firefox" row appeared mid-verification: that Firefox tab is dealt into the current 4-player game with the other three seats already "ready to reveal", so that screen is one ROLE-REVEAL! press away from a live demo of the fix (or NEW GAME to reset). No further curl games were run after noticing the session.

The fix: [server.js](server.js)'s /state now attaches role/mole fields only when the *requesting* device was dealt into the revealed game. Fresh phones and post-reveal joiners get a roleless lobby — the invariant is *anyone who could still join must never see role data*, enforced server-side, so no client rendering path can regress it.

Qual 18 replicates the regression exactly: complete a reveal, fetch /state as a brand-new device and as a late joiner, assert zero "role"/"mole" keys anywhere in either response, while a dealt-in player still gets the full results table. Confirmed red against the leaky server, green after the one-condition fix. Qual 17(f) was reworked to match (it had been checking the results table through the kibitzer's eyes, which is now precisely what must *not* work).

The red phase surfaced a subtlety worth knowing: someone pruned from the lobby mid-game stays in the frozen deal (deals are snapshots), so their reveal press still counts toward unanimity — Qual 18 initially stalled at 3-of-4 because of Qual 17's pruned kibitzer. That's coherent behavior (the escape hatch for a truly dead phone remains NEW GAME), but it's now documented in the qual comments.

18 quals green. One vestige still standing, for the human pen only: the instructions' first paragraph describing the number-of-players flow.

One line — the browser's applying the font's ligatures by default; font-variant-ligatures: none switches them off everywhere:

Crop landed on the art — aiming higher where "figure" and "fingers" live:

Nixed — one CSS line: font-variant-ligatures: none on the body ([style.css](pub/style.css)), which everything inherits. The crop confirms it: "figure", "fingers", and "bluff" now render with each glyph on its own cell, as a 1980s terminal would insist. (The squishing was the browser applying VT323's built-in fi/ff ligatures by default; the font stays intact, the feature's just switched off.)

Agreed — mid-game NEW GAME re-dealt everyone's roles under them. Removing it surfaces one hard problem to solve while implementing: with the single global table, "no new game until *everyone* reveals" would let one dead phone brick molecall.com permanently (the deal is frozen, pruning wouldn't lift the dead seat's obligation, and the family's polling tabs keep Render from ever recycling). The interpretation implemented: "everyone" = everyone still at the table — pruning a dead phone's row removes its press obligation, so the × is the rescue path. Flagged as a judgment call; a one-line revert makes it strict-everyone if preferred.

The rule change cascades through the qual suite's sequential state (three quals re-deal mid-ceremony), which has now bitten twice — so the suite gets the overdue restructure to a fresh server per qual, making each replicata truly ex nihilo:

Red at Qual 6 (mid-ceremony re-deal still allowed). Server changes — the ceremony denominator and the start guard:

All 19 green. Now the client: NEW GAME only post-reveal, and the lone-holdout cursor:

Done, verified against a live constraint even: the dev server currently hosts a real two-person game ("firefox person" / "chrome person"), and the new rule correctly 500'd every restart attempt against their unrevealed game. Stray smoke-test rows were pruned; their game is untouched (their deal never included those rows).

The changes:

1. NEW GAME exists only post-reveal. Hidden in every other phase, and enforced server-side, not just cosmetically: /start now asserts gam === 0 || revealed(), so no code path can re-deal mid-ceremony — which is exactly what the old mid-game button did (yank everyone's roles out from under them). Qual 6 pins this.

1. The "everyone" judgment call, flagged for sign-off: "everyone has clicked role-reveal" is implemented as *everyone still at the table* — the ceremony's denominator is dealt players whose row is still in the lobby. Strict-everyone would let one dead phone brick molecall.com permanently: the deal is frozen, no one could ever start again, and the players' own polling tabs would keep Render from recycling the process. So ×-ing a dead phone's row removes its press obligation and the ceremony completes without it. Qual 18 replicates the full story: lock while waiting on the lost phone, prune, auto-reveal, new game unlocked. Reverting to strict-everyone is one line, brick and all.

1. Cursor (the mid-turn note): it now blinks only when the whole table is waiting on *you* — you're the single dealt-in player who hasn't pressed role-reveal. Pre-game gets no blink at all, since there's no per-player "hasn't clicked start" signal for the app to observe.

1. Qual suite restructured: every qual now boots its own pristine server (require-cache bust), so each replicata stands alone — the sequential shared-state design had now caused two cascading breakages, and the new game rules would have forced ceremony-bookkeeping into half the suite. 19 quals, red-then-green on the new rules. A bonus of the rework: Qual 11 now covers ghost recovery end to end — prune the ghost, rejoin under the freed name from the new device, finish the ceremony without the ghost, deal the next game.

If-statement delta: the /start ceremony assert, the still-in-lobby filter inside revealed(), the client's lone-holdout count, and newgamebtn.hidden = phase !== 'revealed'. Removed: the CSS sibling conditional (NEW GAME is now always the lone action, so it's just big).

The full-ephemeral model — reveal is a client-side freeze-frame, the server throws the game away, refresh always lands on a virgin join screen. Yes, it works, and it makes the state machine linear: join → start → play → reveal → world resets on the next join. NEW GAME dies entirely; /start becomes legal only before a game exists; the finale is delivered exactly once per dealt device (so even a refresh of a player's own phone comes back fresh). This also merges /getrole into /state — the finale must arrive atomically in one response, and a single poll endpoint is simpler everywhere.

Quals rewritten first for the new model, red before the server learns it:

Red at Qual 1. Now the server — finale one-shot, join-reset, start-once, /getrole merged away:

Green. Client rewrite — single poll, freeze-frame finale, NEW GAME gone:

The freeze-frame finale renders exactly as designed: Ada's device shows the results table (Ada the mole in amber, gold star marking her row, Bob's full Concierge role wrapping fine), her readout finally naming the location — Hotel — and nothing else: no ×es, no buttons, steady cursor. The server had already forgotten the game by the time this screenshot existed.

The ephemeral model, as built: the world is now linear — join → start → play → reveal → finale → next join resets everything.

• One deal per world: /start asserts gam === 0. No re-dealing, ever, from any state (Qual 6). Game numbers restart each cohort, so it's always "(game 1)".
• The finale is one-shot per dealt device (Qual 19): the first /state after unanimity carries the full table plus your own role; every request after that — and every request from anyone who wasn't dealt in — gets the virgin fresh-deploy shape. No names, no roles, no hint a game happened. The next /join then discards the spent world for real.
• The client freezes on the finale: polling stops, the table holds until refresh, and a refresh lands anyone — player or newcomer — on the join screen, always. No new-game button anywhere.
• /getrole is gone, merged into /state as a role field — the finale has to arrive atomically in one response, and one poll endpoint is simpler everywhere. The removed route now 404s (qual'd).
• The dead-phone rescue is unchanged: × the missing player's row mid-ceremony and the reveal completes without them (Quals 11, 18).
• Accepted race, named: if someone joins within the ~2 seconds before a slow player's poll collects their finale, that finale is destroyed unseen. For people revealing together in a room, that seemed fine.

19 quals green, plus the curl smoke with a real browser in the loop — the screenshot load itself burned s1's one look, and the next request came back virgin, which is the whole model in one exchange.

If-statement delta: the virgin gate and collected-marking in /state, the reset branch in /join, the gam === 0 assert in /start, and the client's finale clearInterval. Removed: all NEW GAME logic and the /getrole route.

One open item from the updated instructions: they now promise a force-reveal link with a literal href="TODO" — a gesture that presumably completes the ceremony unilaterally (revealing the wanderer's role too, hence "ruins the game if you click that prematurely"). That's a different rescue than the current ×-prune, which *drops* the missing player from the table rather than exposing them. Worth one decision before building: should force-reveal replace pruning as the rescue, or coexist with it?

That ×-mid-game path has indeed been the buggiest corner (it's what forced the ceremony-denominator complexity). Locking the lobby at the deal — and that answers the force-reveal question too: with pruning gone mid-game, the force-reveal link the instructions now promise becomes the rescue for wanderers, so both go in together. Quals first, red:

Red. Server: lobby freezes at the deal, revealed() sheds its now-dead denominator filter, /forcereveal becomes the rescue:

Name prefill noted — going in with the client changes. Quals first:

Green. Client updates — frozen-lobby ×es, the force-reveal link handler, and the name prefill:

One gap: the theme has no anchor styles, so the force-reveal link would render browser-default blue. Fixing, then smoke:

Verified end to end: the mid-game prune 500s, force-reveal ends the game unilaterally — the finale exposed the wanderer's "Candy cane" role and handed the mole (Ada) the location, Candyland — and the next request found a virgin server. All 19 quals green.

Three changes this turn:

1. The lobby freezes at the deal. /remove now asserts gam === 0, and the ×es hide the moment a game starts. Pre-game pruning (typos, ghost rows) still works and still reopens the join form for the pruned device (Qual 10 covers both sides). The pleasant side effect: this *deleted* the buggy complexity — the still-in-the-lobby denominator filter inside revealed(), which existed only to serve mid-game pruning, is gone, and the ceremony is back to plain "every dealt player pressed."

1. Force-reveal is the wanderer rescue, exactly as the instructions promise: a new POST /forcereveal, callable by any dealt-in player mid-game (not drive-bys, not mid-game joiners, not before a deal, not twice — Qual 18), marks every outstanding press as pressed, so the finale goes out with everyone's roles exposed, the wanderer's included. Premature use is allowed and simply spoils the game, matching the instructions' warning. The href="TODO" is wired up (link text untouched) to a handler with a Latin confirm() guard — *Partes omnium statim patefient! Pergere?* — TODO-commented per the microcopy rule. Anchors also got theme styling (they'd have rendered browser-default blue). Qual 11 is now the full wanderer story: press, wait in vain, force-reveal, rejoin, fresh deal.

1. Name prefill (the mid-turn request): the last successfully joined name is kept in localStorage (molecall-name) and prefilled into the join input on every page load — so the refresh-and-rejoin loop is two taps: Join, then Start.

If-statement delta: added — the gam === 0 assert in /remove, /forcereveal's two asserts, the client's confirm() guard and x.hidden = state.g > 0. Removed — the denominator filter in revealed() and the old revealed-block assert in /remove.

Dev server's current world is spent and collected, so every tab and fresh load sees the virgin join screen.

Found it, and the user's instinct is right on both counts. The Firefox bug: sync() runs from both the 2-second poller *and* the gesture handler, so two /state requests were in flight at once — the first one burned the one-shot finale server-side, the second got the virgin shape, and whichever rendered last won. On Firefox the virgin response landed last: join page. The clearInterval freeze couldn't help because it only stops *future* polls, not the one already in flight. The AGENTS-style fix is not a mutex or an "ignore virgin if frozen" patch — it's making reads non-destructive so the race can't exist: the finale expires at the *page-load boundary* (the client's first sync after load says so) instead of on first read. Polls become stable pure reads; the client freeze machinery dies entirely.

Qual first — Qual 19 rewritten to pin the new semantics (stable finale across polls, expiry on reload), red against the burn-on-read server:

Green. Client-side if-hunt harvest:

Fixed and replayed: two concurrent polls both returned the identical finale (Fox the mole, Chrome as Santa, up A chimney around Christmastime), a third poll stayed stable, and the fresh=1 reload expired the look for good. All 19 quals green.

Root cause of the Firefox behavior: sync() runs from both the gesture handler and the 2-second poll, so two /state reads were legitimately in flight together — and the finale was a *destructive* read. The first request burned the one-shot; the second got the virgin shape; whichever response rendered last owned the screen. Firefox's virgin landed last: join page. The clearInterval freeze was powerless against a request already in flight.

The fix, per the AGENTS reread: not a lock, not an "if we already saw the finale, ignore virgin" patch — the destructive read itself was the bug. The finale now expires at the page-load boundary: the client's first sync after load sends fresh=1, and that is the only thing that expires a device's look. Polls within a page view are repeatable pure reads, so the race is impossible by construction, not guarded against.

If-statements killed in the hunt:

• if (phase === 'finale') { clearInterval(poller) } — dead. The client has no terminal mode anymore; it's a pure function of polled state, always.
• The burn-on-read if (revealed()) collected.add(device) — the destructive semantics died with it (the load-boundary marking replaces it, one honest if for one dishonest one).
• The now-unused poller binding — dead.
• The duplicated phase !== 'lobby' || live pair collapsed into one startable.

A behavior bonus fell out of the rethink: since finale pages keep polling harmlessly, they live-update when the next cohort starts joining — the results table gives way to the new lobby and the join form returns, name prefilled. No stale frozen screens anywhere.

Qual 19 now pins all of it — stable-across-polls (with the Firefox story in its replicata), expiry-on-reload, a mid-game-reload control confirming roles still survive refreshes during play, and the original no-history spectator guarantee.

Right — for an unjoined visitor the join form sat above the roster. Making the roster unconditionally first is pure DOM order, and it lets the whole phase indirection die: with a stable layout, each control's visibility becomes one direct boolean of server state, and the rolebox needs no visibility logic at all.

Verified — the roster now leads directly under the title, with the join form and the dashed readout below it, and quals stay green (server untouched). The screenshot also caught a real mid-ceremony game in progress on the dev server (chrome incognito person has pressed reveal; firefox person hasn't), which incidentally demonstrates the frozen lobby: my smoke-joined Danny/Faire rows show no ×es and can't be pruned until that game's reveal resets the world — they'll vanish when the next cohort joins.

The if-kill harvest this round:

• The four-way phase ternary chain is dead. With layout stability guaranteed by DOM order instead of logic, each control's visibility collapsed to one direct boolean of server state: joinform.hidden = mine !== null, revealbtn.hidden = !(live && dealtin), the start pair on startable = mine !== null && state.g === 0, and the × on state.g > 0. No mode variable to route through.
• rolebox.hidden is deleted outright — the readout is now unconditionally present, showing em-dashes until a role exists. That also happens to restore the original spec point ("the location is initially blank") for everyone, visitors included: the dashboard always has its three-line readout, blank until the deal.

The one visibility that couldn't die is the join form's (joined players must not see it — the server would just 500 their duplicate join), and the reveal button's and start button's, which gate genuinely device-specific actions.

Client header comment now states the invariant plainly: roster first, then readout, every visibility one boolean, no modes.

Answering the design question first: the toggling button is the cleaner mechanism — the × approach adds a second kind of click-target inside rows (which are currently a pure function of row data), plus your-row-only/ready-only/pre-reveal-only conditions; the toggle *reuses* the existing button and actually kills a conditional (the disabled-when-ready line), since the button is never state-disabled anymore — it just alternates between the two actions. Building that, plus the tighter line spacing.

Quals first — the unreveal endpoint, red:

Red. Server endpoint:

Green. Client toggle and the row line-height:

client.js had human edits on disk — reading to make sure everything merged coherently:

The merge is clean — the human's confirm copy ("This kills the current game. Are you sure?") is preserved, and the toggle logic threads through correctly. Visual check on the tightened row spacing:

Both done and verified — the wrapped rows now sit tight (fixture above renders in the fallback font, but the line-height change is what shows: compare "firefox person" wrapping snugly vs. the airy spacing in the attached screenshot). All 19 quals green.

1. Spacing: line-height: 1.15 on lobby rows only — body prose keeps its comfortable 1.4; it's specifically wrapped names and long roles that needed to read as one row.

2. Un-pressing, built as the toggle — which is the cleaner of the two options, and measurably so: the row-× approach would have added a second kind of click-target to rows that are currently a pure function of row data, gated by your-row-only, ready-only, and pre-reveal-only conditions. The toggle *reuses* the existing button and comes out net negative on conditionals: revealbtn.disabled = mine.ready is deleted (the button is never state-disabled anymore — it always has an action), replaced by one ternary that flips both the label and the endpoint. The pressed-side label is your exact copy, "j/k not ready to reveal" (uppercased by CSS like every button); the ready-side label stays single-sourced from the HTML.

Server-side it's a symmetric POST /unreveal: dealt-in devices only, only while a press is outstanding, and — matching "up until the actual reveal" — a hard 500 once the ceremony completes ("too late; the reveal already happened"). Qual 17 gained the change-of-heart sequence: press, take it back, verify the flag cleared for everyone, fail a second take-back, re-press, and confirm the finale freezes out any late regrets. Quals 3 and 16 got the no-deal and garbage guards. Red first, then green.

The blink semantics compose with this for free: un-pressing while others wait just recomputes the holdout count, so the cursor correctly starts blinking at *you* if your j/k made you the lone holdout.

One code note for review: sync now unconditionally clears revealbtn.disabled each pass — that's the transient double-tap guard being released, and it doubles as self-healing if a POST ever throws mid-gesture. Your confirm copy on force-reveal ("This kills the current game. Are you sure?") is untouched.

Checked whether it simplifies: it does, twice over. The >= 2 half of the start assert dies, and the <= 12 half turns out to be dead code anyway (the join cap already makes a 13th row impossible), so the *entire* assert line goes — the lower bound is enforced by nothing because /start already requires the presser to be in the lobby, making n≥1 automatic. Client-side the whole startbtn.disabled conditional dies too. Qual first — Qual 3 inverts from "solo can't start" to the degenerate solo game:

Green — and the simplification test passed cleanly, so it's in. What died:

• Server: the whole assert(lobby.length >= 2 && lobby.length <= 12) line. The lower bound needs no replacement — /start already requires the presser to be in the lobby, so n≥1 is structural. And the upper bound was dead code: /join refuses a 13th row, so the lobby can't exceed 12 in the first place. The cap now lives in exactly one place (Qual 15 still pins it).
• Client: startbtn.disabled = state.lobby.length < 2 || state.lobby.length > 12 became the unconditional double-tap-guard clear, matching the reveal button's pattern.

The satisfying part is how much *doesn't* need special-casing downstream, confirming the degenerate case was free all along: with n=1, spy = ⌊random·1⌋+1 is forced to 1 (necessarily the mole), the readout shows "player: 1 of 1" with the location hidden, the lone role-reveal press is trivially unanimous, and the finale hands over the location. Qual 3 is now exactly that story — solo start, mole confirmed, location revealed and verified against data/locations.js — replacing the old "a lobby of one can't start" qual it inverts. The pre-deal reveal/unreveal guards it used to carry stay in place.

The only remaining guardrail against a premature start is the one the design intends: the human-readable warning on the header above the button. 19 quals green.

Right — the waiting room is now pure vestige: with one-deal-per-world, a mid-game joiner's row can *never* be dealt (starts only happen at game 0, and the world-reset wipes the lobby first), so it just sits there confusing the roster. Blocking mid-game joins makes the invariant crisp — once dealt, the lobby IS the deal — and that kills the whole seat field (rows and seats coincide, so seat is derivable from g > 0) plus the kibitzer machinery. The one join that must stay legal while revealed is the world-reset join, which the existing reset-first ordering handles for free.

Quals: reworking the waiting-room quals and adding the systematic permission-matrix qual — every gesture knocked on in every world-state:

Red. Server:

Qual 18 still manufactures a mid-game kibitzer for its force-reveal guard — a state that can no longer exist. The drive-by check covers that class now:

Green across all 20 quals, zero seat references left in the client. The invariant is now crisp — once dealt, the lobby IS the deal — and it collapsed more than it added:

The rule: /join asserts gam === 0. Ordering does the subtle work for free: the world-reset line (if (revealed()) reset()) runs first, so the one join that must stay legal — the post-reveal join that begins the next world — passes because the reset has already zeroed gam. Live game: refused. No new condition for that case.

What the invariant killed:

• The seat field on /state rows, entirely. With no mid-game joins (and removals already blocked at the deal), rows and seats coincide — row j speaks for seat j+1 — so the field was derivable noise. Gone with it: the per-row seatof lookups and the seat !== null condition on role attachment, now a bare if (revealed()).
• Client-side, every mine.seat/p.seat test: the reveal button shows on live && joined, the blink's holdout filter is just !p.ready.
• The kibitzer as a concept — a joined-but-undealt player is now unrepresentable, which also erased a guard qual that had to exist only to police that state.

The bunch of quals:

• Qual 20, the permission matrix — the systematic one for "this kind of thing": drives one world through its three states (FRESH → LIVE → SPENT) and knocks on every endpoint at each stop. FRESH allows join/remove/start, refuses the reveal family; LIVE allows only the reveal family; SPENT refuses everything except the world-resetting join. Any future endpoint slots into the sweep.
• Qual 8 inverted: the mid-game join 500s and provably changes nothing — lobby, the joiner's nobody-ness, dealt roles.
• Qual 17(d) became "no joining mid-ceremony," and Qual 2 now pins the exact row shape {name, rid, ready} — one structural assert that subsumes the no-role-leak, no-seat, and no-uuid-leak checks at once.

Worth naming the design consequence: someone arriving mid-game now gets a roster they can watch and a join form the server will refuse with ERROR1001 until the reveal. That's honest — the alternative was the vestigial waiting room whose rows never survived to a deal anyway — but if the refusal feels abrupt in practice, graying the join form during a live game (client already knows g > 0) would be a one-line courtesy.

Clean version: it slots straight into the existing pattern — one new static element carrying the spec'd copy, and for an unjoined viewer exactly one of {join form, missed-it notice} shows, chosen by state.g. Two boolean assignments, no modes, and the alert path becomes unreachable since the form simply isn't there during a live game (the server assert stays as the backstop).

The dev server conveniently has a live solo game right now — exactly the state an unjoined visitor would hit. Screenshotting as a fresh device (pure read, doesn't touch the game):

Live-verified against your own in-progress game: a late arriver now gets the roster, "Game in progress and you missed it!" exactly where the join form would be, the blank readout, and no controls at all — no form, no alert.

The clean shape it settled into: one static element in the HTML carrying your exact copy, and a complementary pair of boolean assignments —

joinform.hidden = mine !== null || state.g > 0
missed.hidden   = mine !== null || state.g === 0

so an unjoined visitor sees exactly one of {join form, missed-it notice} depending on whether the world is still forming, and joined players see neither. It rides the existing no-modes pattern rather than adding any: still one boolean per visibility, still a pure function of polled state. The ERROR1001 alert path for this case is now unreachable through the UI — the form simply doesn't exist during a live game — while the server's no joining a game in progress assert stays as the anti-postel backstop (already pinned by Quals 8 and 20, so no qual changes; this was a client-only change).

Two states worth confirming fall out correctly: a spent world serves unjoined visitors the virgin shape (g === 0), so they get the join form, not the notice — correct, since joining is exactly what they should do; and a dealt player who reloads mid-finale lands the same way, form prefilled with their name from localStorage.

The footer now links to /sourcery.html — tauction has one of those (spotted earlier in its repo). Checking what it does to port the concept:

The link works. What was done:

• Generated the page: [pub/sourcery.html](pub/sourcery.html) via the sourcery tool found at ~/lab/sourcery (sourcery.py REPO OUTPUT.html) — it compiles the repo's AI-session transcripts into the browsable prompt history, human words visible, AI replies click-to-expand. Since it lands in pub/, the existing static middleware serves /sourcery.html with zero server changes. Verified: HTTP 200 on the dev server, titled "molecall", stamped "26 prompts · 2026-08-01 – 2026-08-02 · +2,125 −1,027" — i.e., this whole collaboration, which began yesterday.

• Added npm run sourcery to package.json so the incantation is recorded. The path assumes the sibling ~/lab/sourcery checkout, fine for a personal project.

Two operational notes, since this file is unusual:

1. It must be committed, not gitignored. The transcripts live only on this laptop, so Render can't generate it at deploy time — the generated HTML is the deployable artifact, contrary to the usual rule about build products.
2. It goes stale with every prompting session (including retroactively — today's later prompts aren't in the copy just generated). Worth a npm run sourcery right before any commit/deploy, so the published sourcery includes the session that produced the code being deployed. It can never quite include its own last prompt, which seems fittingly Gödelian for a file that documents its own creation.

Yes. It's a runtime asset, not a build artifact: the repo has no build step, Render just clones and runs node server.js, so anything the page needs at runtime that isn't derivable from other files in the repo has to be committed. Without it, the deployed site silently falls back to Courier. It sits in the same category as [literal-mole.png](pub/literal-mole.png) and [molecall-ai-art.png](pub/molecall-ai-art.png), which are already tracked — and at 7.2KB it's a rounding error next to those (the AI art is 2.1MB). Being binary is fine; it's write-once and will never generate diffs.

The two alternatives are both worse: fetching it at deploy time adds a network dependency and a build pipeline where none exists, all to avoid 7KB; and linking Google Fonts' CDN reintroduces the third-party request that self-hosting deliberately avoided.

One licensing footnote: VT323 is OFL-licensed, which happily permits bundling and redistribution, but the OFL technically asks that its license text travel with the font. The CSS comment already credits the license; dropping the OFL text file into the repo alongside it would be the fully fastidious version, if wanted.