Pairing: build a rolling waiting room (room bucketing, ghost expiry, odd arrivals)

[htsukamoto5]

Phase 2 — BLOCKED on adapter-multiplayer-firebase publishing. Largest single piece of missing work in the audit.

Two participants must find each other. What exists today is a two-tab-on-one-machine pilot rig, not a waiting room.

Important: a rolling waiting room is not something the Firebase adapter gives us. plugin-multiplayer-sync and plugin-multiplayer-role are per-session barriers, not a matcher. Room assignment has to be written on top.

What has to be built

• Room bucketing — assign arrivals to two-person rooms as they show up, rather than assuming a private session that both partners already share via a pasted URL.
• Stale-room expiry / ghost handling. wait_for counts any group entry carrying a name, and the adapter only removes an entry on an explicit disconnect() — there is no heartbeat and no beforeunload anywhere in the four bundles. A tab closed in the lobby leaves its entry behind. With persistent Firebase room state a live participant will be "matched" with a ghost, assigned a role, and then time out on every single round. Silent, and frequent.
• Odd-arrival handling — currently the overflow spectator path is a dead end with no completion code.
• Concurrency policy. Pair-based studies need participants simultaneously, which Prolific does not guarantee. Launching in a tight burst rather than leaving the study open is the main lever, which makes the waiting room and its timeout policy load-bearing on cost, not just UX.

Related unblocked work: the lobby timeout and payment paths can be done now, independently.

See READINESS.md section 1.

[htsukamoto5]

Caution when fixing ghost entries: beforeunload → disconnect() would truncate transcripts

Flagging an interaction found while verifying the audit against the bundles, because the obvious fix for the ghost-entry bullet above has a non-obvious cost.

Chat messages are written into the sender's own group entry — the send path does T.push({...d, [M]: p}) against the local participant id — and chat_transcript is derived from the group snapshot at round end, not from a locally accumulated array. disconnect() in adapter-multiplayer-local.js removes the participant's entry outright.

So the partner's half of the dialogue survives a dropout today only because a closed tab never calls disconnect() — the same missing beforeunload that causes the ghost entries. The two behaviours are the same gap seen from opposite sides:

	ghost entries	transcript
today (no beforeunload)	❌ stale entry can satisfy wait_for	✅ full dialogue survives
naive beforeunload → disconnect()	✅ entry cleared	❌ partner's messages vanish from the survivor's data

That second failure is silent and lands on exactly the sessions #5 exists to salvage: the survivor's saved rows would carry their own messages and message_count computed over a truncated transcript, with no error.

Implication for the ghost-expiry work: expire entries by staleness (heartbeat/timestamp, ideally Firebase onDisconnect writing a tombstone) rather than by deleting them, so a departed participant's contributed data stays readable while no longer counting toward wait_for / ready. If any beforeunload → disconnect() handler does get added, the round data must be flushed (#3) before the entry goes.

Relates to #3, #5, #11.

[htsukamoto5]

No scheduling shortcut exists — and build this defensively

Two findings that bear on how this gets built.

Prolific has no appointment or slot-booking feature

Checked, because if it existed it would have reduced the scope of this issue. It does not. Prolific's position is explicit:

"Prolific cannot fully support studies that require participation or completion within a specific time window"

— including completion at a particular time of day, and such studies are "conducted at the researcher's own risk." (source, verified 2026-07-30)

The only scheduling control is schedule publish — choosing when the study goes live. That governs when participants can start, not when they do. So burst launch is the entire simultaneity lever, and none of the room-assignment work here can be delegated to the platform.

(For completeness: longitudinal projects provide scheduled waves with guaranteed participant ordering. Not slot booking, but it is the machinery a two-study panel approach would use if that is ever revisited.)

Build defensively — the concurrency test is weak by construction

Pre-launch validation (#12) covers waiting-room logic with 6–8 coordinated testers and scripted arrival patterns, which is genuinely good for correctness bugs. But the staged first tranche is only ~3–4 dyads, so real concurrency gets its first proper test on the first full run.

That asymmetry should shape the implementation rather than the test plan:

• Idempotent room assignment — assigning the same participant twice must be a no-op, not a second room.
• Tolerate duplicate and stale entries rather than assuming they cannot occur. Per the earlier comment on this issue, expire by staleness (timestamp / tombstone) rather than deletion, so a departed participant's contributed data stays readable while no longer counting toward wait_for / ready.
• Fail closed on ambiguity. If room state is inconsistent, route the participant to the no-match exit with a payment path (Pairing: lobby waits unbounded — add timeout, no-match exit, and payment path #6) rather than into a room that may be broken. A paid no-match is cheap; a silently broken dyad costs two payments and produces confounded data.