Support experiment-mode matches with configurable prompts, virtual tokens, and timers

[0xferit]

Summary

Add an experiment mode so this app can host custom Schelling-game variants instead of only the canonical public product.

The goal is to let a project or researcher define a Schelling-point experiment with its own:

• prompt or prompt catalog
• virtual token / point branding and accounting surface
• phase timings

This would let schelling-game evolve into an experimentation ground for projects that want to test game designs built around Schelling-point coordination.

Why

Right now the repo is intentionally optimized around one canonical public mode:

• canonical public prompt catalog
• canonical public token economy
• canonical public phase timings
• canonical public rules documented in docs/game-design.md and ADRs

That is the right default for the live product, but it is too rigid for running bespoke experiments, partner activations, or design research. We should be able to run isolated variants without rewriting the public mode every time.

Product direction

Treat this as a separate experiment configuration path, not a mutation of the canonical public game.

The canonical public mode should remain the default and continue to follow docs/game-design.md. Custom experiments should sit beside it as explicitly scoped, configurable runs.

In scope

• Define an ExperimentConfig model that can describe a custom Schelling experiment.
• Support custom prompt content per experiment.
  • At minimum: prompt text, prompt type, and answer shape/options.
  • Ideally: a prompt set or mini-catalog rather than only one hard-coded prompt.
• Support experiment-specific token configuration.
  • At minimum: token/point display name and isolated accounting surface.
  • If needed: ante or starting-balance knobs, but still as internal virtual units rather than onchain assets.
• Support experiment-specific phase timings.
  • commit
  • reveal
  • results
  • optionally other timing knobs if the runtime needs them later
• Thread the selected experiment config through match creation, persistence, reconnect, and result replay.
• Surface experiment metadata in the client so players can clearly tell they are in a custom run.

Constraints

• Canonical public mode must remain intact and continue to use the current authoritative docs/ADR path.
• Experiment matches must not silently contaminate the public leaderboard or canonical public balances/stats.
• Invalid experiment configs should fail fast with validation errors.
• Durable Object restore/replay must remain deterministic for experiment-backed matches.

Likely implementation areas

• D1 schema for experiment definitions and any experiment-scoped ledger/state
• Worker HTTP/admin API for creating, listing, and launching experiments
• Durable Object match state so a match carries its experiment config instead of relying only on global constants
• domain prompt selection / validation so prompt source can come from an experiment config
• timing/config plumbing so commit/reveal/results durations are not hard-coded for every match
• frontend lobby/play UI so experiment name, prompt set, timer values, and token label are visible

Non-goals

• Replacing the canonical public mode with arbitrary config-by-default behavior
• Turning internal experiment tokens into real-money or onchain assets
• Weakening commit/reveal or settlement guarantees just to make experiments easier to author

Acceptance criteria

• A new experiment definition can be created with custom prompt data, token metadata, and phase timings.
• A match can be launched against that experiment definition and uses the experiment config end to end.
• Public canonical matches continue to behave exactly as they do today when no experiment config is selected.
• Experiment results and balances are isolated from the canonical public leaderboard/stats path.
• Validation rejects malformed prompt specs and unsafe timing values.
• Worker and domain tests cover experiment config loading, match execution, reconnect/restore, and result settlement under a custom config.

Open questions

• Should experiments be invite-only/private at first, or selectable from the main lobby?
• Do we want one prompt per experiment, or a full experiment-owned prompt catalog from day one?
• Which token-economy knobs should actually be configurable beyond display name and isolation?
• Should experiment configs live behind admin-only routes, static seed data, or both?