veratown-prototype

Staged Table

Staged Table is a disabled-by-default, room-scoped five-card-draw party game. Players opt in to each session, use fictional score chips and markers, and may choose optional private prompts or separately consented BC-avatar appearance progression. The game never requests a physical action or records a prompt answer.

Release and safety gates

The room config in prototypePartyGameConfigs is keyed by <roomKey>:staged-table. It must be enabled and have adultsOnlyConfirmed: true; this is an operator attestation, not age verification. Defaults remain disabled and unconfirmed. Startup seeds ten short, fictional English prompts without replacing existing config or moderation edits. Global and scoped help, including the admin setup commands, is shown only while the room config is enabled. The commands remain registered so room admins can use the documented configuration paths to enable the feature.

Configuration and session updates use revision compare-and-set writes. The Mongo adapter shares conflict re-reads and optional-field clearing with Hot Seat, while this feature retains its own validation and revision requirements.

Appearance progression remains off by default. Operators may enable it only after configuring a validated ordered plan of one to ten {stripGroup, itemSetKey, revision} stages. Its stage count is independent of the four-marker spotlight threshold. The dry-run-first npm run provision:party-games workflow seeds six enabled, strip-only stage itemsets when explicitly applied: table.stage.set.one (Shoes), .two (ClothOuter), .three (Cloth), .four (ClothLower), .five (Bra), and .six (Panties). Existing definitions are validated and preserved. These defaults do not enable appearance mode or configure a stage plan; appearance still requires the separate, validated emergency-release itemset and each participant’s disclosed opt-in. Each enabled stage set must strip exactly its selected catalogued removable clothing/equipment group, with no ItemNeck, lock, variant, or non-owner-lock removal. The enabled, revision-pinned emergency.release.clothing itemset must strip every stage group, cover every group that a stage adds items to, and affect no undisclosed groups. The admin workspace provides a guided catalog-backed editor; both admin writes and bot startup/consent revalidate the plan. Direct database edits are not a safe substitute for this validation.

The private rules disclosure lists the complete ordered stages, added items, release outfit, pinned revisions, and cleanup delay. An appearance join or solo start requires that disclosure within 15 minutes. A different config revision or changed itemset/release plan prevents consent or start. Chat-only players remain unaffected when appearance is enabled.

After warm-up, each appearance participant’s loss of a non-tied hand advances their own next stage. The first post-warm-up hand that reduces a positive score chip balance to zero also advances one stage; if both triggers happen on the same hand, only one stage advances. This appearance progression is separate from markers, so losses can continue advancing stages after the marker cap and spotlight threshold. Chat-only participants are never changed. Each stage is applied through the shared guarded BC appearance action, and the counter advances only when the itemset’s removals and additions are observed or already satisfied from current BC state. A partial, unobserved, or failed result blocks further stages for that participant; no blind retry follows. A crash during a stage can resume only against a fresh BC appearance observation.

/bot table appearance stop withdraws appearance consent without a card-game penalty and requests immediate emergency release. Leaving the table or using /bot safeword also requests immediate release for affected participants; the safeword aborts undispatched appearance work before stopping the session. Natural end uses the configured restraintRemovalDelayMs. Each participant’s release deadline and pending status are persisted independently. Terminal sessions with pending cleanup have no TTL until every release is confirmed; recovery reschedules future deadlines and retries pending work only after a fresh BC observation. If a member is absent, disconnected, or BC rejects a mutation, cleanup remains pending; exact-deadline completion cannot be guaranteed offline. Participants can use /bot emergency-release or BC’s own removal controls at any time. No pre-game appearance snapshot is stored or restored.

/bot safeword is a private shared command backed by SafetyStopRegistry. Staged Table registers its stop handler during plugin start; it persists the terminal state before notifications, voids/refunds an unresolved hand, cancels offers and timers, and does not identify the caller publicly.

Session flow

Players privately review /bot table rules and explicitly join with /bot table join accept chat or, when enabled, /bot table join accept appearance. The first eligible join opens a lobby when none exists; a room admin may also open one early. The rules disclosure must match the current config revision and be no more than 15 minutes old.
Joined players privately use /bot table ready. The round starts automatically when the configured minimum number of present players is reached and every present joined player is ready. The room-admin /bot table start command applies the same readiness checks. The roster is frozen; later arrivals cannot join.
Each participant starts with ten non-transferable score chips. Every hand antes one chip when available, privately deals five cards, and permits up to three unique discards. A tie carries the pot.
A timeout or participant departure voids the current hand, refunds antes, reveals no cards, and adds no markers. A disconnected player remains in the frozen roster; play pauses between hands until quorum returns. /bot table leave is an explicit withdrawal.
After the configured warm-up, each human non-winner receives one fictional marker up to the configured cap. Only a participant at the threshold can privately confirm /bot table spotlight; play otherwise continues.
In spotlight, a participant may enable prompts separately. They can draw a private prompt or receive a winner-funded peer offer. Offers expire without penalty; recipients may decline, pass, or privately attest completion. Answers are never requested or stored. Only the most recent hand’s human winner may spend one score chip to offer a prompt.
Admin close, the round/session limit, all-player withdrawal, or safeword ends the session. Safeword and close void/refund any current hand. A terminal record expires after 30 days only once appearance cleanup is complete. The round cap is set at game start to the lower of the configured cap and (frozen player seats × 10) - 1; solo sessions count simulated seats. This reserves at least one of the maximum ten appearance stages for a winner. The configured cap defaults to 59, the maximum for a six-seat game.

The public hand summary reports only the winning rank and chip movement. Scoreboards use anonymous seat labels and show session-only chips, markers, simulated-seat totals, and the carried pot; no member numbers or cards are published.

Solo play is opt-in through the disabled-by-default soloEnabled setting. /bot table solo start chat (or appearance when configured) starts one human seat against two to five local simulated opponents. Their fixed strategies use the same deck and ranking rules; they are not BC characters and receive no messages or effects.

Commands

Command	Access and effect
`/bot table rules`	Privately disclose the current rules and consent flow.
`/bot table open`	Room admin opens a multiplayer lobby early.
`/bot table join accept chat`	Explicitly join a lobby in chat-only mode.
`/bot table join accept appearance`	Consent to the fully disclosed pinned avatar plan.
`/bot table ready [no]`	Privately mark yourself ready or not ready; readiness auto-starts play.
`/bot table start`	Room admin starts with the same checks; normal play auto-starts.
`/bot table solo start chat`	Start solo play when the room’s solo setting is enabled.
`/bot table solo start appearance`	Consent to the same pinned plan in solo play.
`/bot table appearance stop`	Opt out and request immediate release without leaving the game.
`/bot table hand`	Privately review the current hand.
`/bot table discard <positions>` or `none`	Submit one private discard choice.
`/bot table scoreboard`	Privately review current session-only scores and markers.
`/bot table prompt enable/disable`	Opt into or withdraw from prompt invitations.
`/bot table prompt draw/offer/accept/decline/pass/complete`	Draw, offer, or respond to optional prompts.
`/bot table spotlight`	Voluntarily confirm the spotlight transition at the marker threshold.
`/bot table steward accept/leave`	Volunteer for or revoke the optional steward role.
`/bot table leave`	Withdraw without score or marker penalty.
`/bot table close`	Room admin ends the session.
`/bot safeword` or `/bot table stop`	Immediately stop an active registered activity.

Table commands accept only native /bot input or private Whisper. Public emotes are not gameplay commands: discards, passes, readiness, consent, offers, and prompt outcomes remain private. Public announcements do not reveal private cards, prompt answers, the safeword caller, or member identifiers.

Configuration and persistence

The admin workspace supports revision-checked room config and prompt moderation. Staged Table prompt edits append <promptId>:rN records; the previous revision is retired without changing its prompt text. Activation requires ten valid, approved English prompts and the adults-only attestation. The dry-run-first npm run provision:party-games workflow includes this game; activation requires --enable --confirm-adults-only --apply.

prototypeStagedTableSessions uses a unique sparse active-room key and revision-checked writes. It persists the frozen roster, consent flags, pinned config/prompt/itemset revisions, per-member stage and cleanup deadlines, score chips, markers, and only the in-progress hand’s cards. Resolved/voided hands remove their cards. It stores no shuffle seed, prompt answer, transcript, or appearance payload. Active sessions have no TTL; terminal sessions expire after 30 days. Recovery resumes a saved hand and deadline rather than dealing a replacement. Unsafe or expired hands are voided and reconciled without penalties. Active sessions and terminal sessions with pending cleanup remain durable without TTL; fully released terminal sessions expire after 30 days.

See the design proposal for the full consent and qualification rationale.