Plan only — not implemented, exercised, deployed, or a showcase. This is Approach C, one of the three strategic proposals, not a fourth approach or an implementation authorization. It optimizes trusted simultaneous play rather than Approach A’s smallest static/local loop or Approach B’s durable personal workspace. All checklist items below are unexecuted requirements. Numerical settings are proposed starting choices, not source facts or measured guarantees.
Foundation reading: scope-3-play-together, state-and-trust > Gaming authority, persistence, and reconnection, platform, experience-and-acceptance > Acceptance cases, evidence-and-limits, and source-coverage > September 10 starter source coverage. Source locators in the checklist distinguish the two dated corpora; the starter’s host-local paths are provenance, not public downloads. The ten September 6 originals remain untouched.
approach_c:
status:
artifact: "Phase 3 design proposal only; no code, passed gates, runtime evidence, or showcase."
claim_rule: "Source facts describe the research; every proposed application behavior still needs proof."
phase_boundary: "Implementation and showcase wait for the owner's later authorization."
strategy:
name: "S3: two players share one server-refereed 2D round."
optimize:
- "Agreement on legal actions and outcomes under concurrent input."
- "Truthful connection state and authoritative reconstruction after disconnect."
- "Small, explicit browser / game-runtime / durable-data trust boundaries."
gives_up:
- "S1's static-only operation, offline core loop, tiny dependency footprint, and easy whole-app portability."
- "S2's broad personal records, cross-device workspace recovery, rich history, and social features."
- "Client-authoritative shortcuts, peer-to-peer play, seamless node failover, and large-world physics."
distinction: >-
The frontend can be static, but the product cannot: accepted gameplay requires a separately
operated trusted runtime. Nakama replaces custom authentication/socket infrastructure, not custom
game rules. This is not Approach B with a multiplayer skin or a universal app builder.
smallest_useful_loop: >-
Two invited testers enter one shared project, join one match, move simultaneously through a
small tile arena collecting server-owned tokens, see an agreed result, and return to the lobby.
Disconnect/rejoin must work before adding another mode.
proposed_rules:
- "One fixed map; two players; one 60-second active-play round; one point per collected token."
- "Both players move concurrently. No turns, combat, purchases, user-uploaded maps, or real-value rewards."
- "Server advances bounded movement and resolves walls, token collection, score, clock, and finish."
- "Within a tick, unique closest eligible collector wins a token; exact distance tie awards neither."
- "Equal final scores produce a draw. Neither packet arrival order nor a client's claim decides a tie."
- "The shared project is the room/rules context, not a collaborative source editor or project archive."
source_grounding:
sep06_s3:
locators:
- "PRD.md:62-74, 93-128, 138-145: earned capabilities, nine states, A1-A12, creator-controlled release."
- "scoped-posters.json:61-73: S3 question, two sync edges, access/conflicts/reconnect, conditional history/moderation."
- "scope-3-play-together.png, explained by content/scope-3-play-together.md:16-49."
source_fact: >-
The conceptual diagram joins VISITOR A and VISITOR B through SHARED PROJECT, not directly
to each other. It requires trusted confirmation, late join and rejoin; it establishes neither
transport topology nor anti-cheat/capacity guarantees. S3 does not automatically inherit S2 storage.
design_choice: "Instantiate that conceptual shared node as a private room plus one authoritative Nakama match."
sep10_starter:
root: "/home/loca/dev/simp-research-starter/websim-starter/ (read-only research provenance)"
locators:
- "CHEATSHEET.md:93-108, 131-168: engine admission, DOM controls, distinct multiplayer needs, OMP development-only default."
- "GAMING-NAKAMA.md:5-49: Svelte plus one engine, SDK/socket, custom rules, private PostgreSQL, first playable."
- "GAMING-NAKAMA.md:51-60: documentation references and explicit no-implementation/no-runtime-proof limit."
- "Gaming-Stax.html #hero-arena (1813-1820): local educational referee, no server connection."
- "Gaming-Stax.html #boundaries (2036-2043): matchmaker callback, RPC versus match opcodes, explicit persistence, VM, cadence, reconnect."
- "Gaming-Stax.html:2060-2067: Build/Choose/Send/Decide/Remember/Reconnect/Separate/Start-small teaching sequence."
source_fact: >-
The recommendation separates browser presentation from trusted match handlers/RPCs, says to
start with two players, one mode and one node, and requires invalid-action, rejoin and duplicate-result
proof. Gaming Stax's local referee and Darkroom's same-page relay are not real multiplayer evidence.
design_choice: >-
Select Phaser, private direct room creation, a simple collect race, bounded rejoin, and minimal
immutable results plus a best-score projection. These choices are not source-provided implementations.
fusion:
- "Sep06 defines why simultaneity earns complexity and what must be observable."
- "Sep10 supplies a recommended independent-app responsibility split, not Websim's private backend architecture."
- "The fused foundation's authority/persistence/reconnect corrections constrain every step below."
- "Dated registry/docs checks and source screenshots do not establish current versions, prices, deployment, or passing gates."
steering_and_automation:
user_steers:
- "Approve this interaction, the two-tester audience, match rules, retention, and exposure boundary."
- "Choose hosting region/provider and approve spend, accounts, publication, and any expansion beyond private play."
- "Approve bans, record deletion, policy changes, and a rollback that may affect recorded results."
- "Decide whether gathered evidence earns a real prototype/showcase claim; an agent cannot self-authorize it."
development_automation:
- "After authorization, OMP may implement bounded tasks, exercise failures, retain evidence, and propose corrections."
- "No runtime agent broker, AI referee, visitor provider calls, generated-code execution, or autonomous publication."
runtime_automation:
- "Trusted deterministic handlers validate intentions, advance the round, send state, and commit permitted results."
- "Reconnect retries are bounded and visible; they cannot grant access, change rules, or invent an outcome."
- "User movement steers the avatar; automation decides only within the disclosed rules and permissions."
architecture_checklist:
- "[ ] Use Svelte 5 + SvelteKit + TypeScript for entry, lobby, HUD, connection status, settings, results, and access errors."
- "[ ] Use Tailwind/daisyUI for presentation; native controls first; add Bits UI only for an actually required complex interaction."
- "[ ] Choose Phaser as the only world specialist: tilemap scene, sprite loading, camera, pointer/keyboard input, and scene lifecycle earn it."
- "[ ] Keep menus, score text, explanations, and touch controls in the DOM; expose game status without color-only cues."
- "[ ] No Threlte, Three.js, PixiJS, Rapier, second scene owner, or duplicated game state in Svelte stores."
- "[ ] Mount one browser-only Phaser instance; release scene, input, timers and subscriptions on navigation; keep the rest of the app SSR-capable where useful."
- "[ ] Browser prediction/interpolation may improve feel, but a visual position, collision, or score is never authoritative."
- "[ ] Use official @heroiclabs/nakama-js and its realtime socket; do not add another socket framework or authentication service."
- "[ ] Custom Nakama TypeScript handlers own simulation; use embedded-VM-compatible code, not Phaser, browser APIs or Node-dependent libraries on the server."
- "[ ] Simple bounded geometry avoids a dedicated physics service; needing complex trusted physics reopens scope instead of importing client physics into the VM."
- "[ ] PostgreSQL is reachable by Nakama only; no direct browser DB access, custom second backend, or ORM by default."
- "[ ] Keep server/admin/database credentials private; the client SDK serverKey is not an authorization or admin-secret substitute."
two_clients_shared_project_flow:
conceptual_edges:
- "VISITOR A <-> SHARED PROJECT / MATCH"
- "VISITOR B <-> SHARED PROJECT / MATCH"
- "No direct A-to-B authority channel; this proposed transport mapping is a design choice, not a poster fact."
transport_and_operations:
- "HTTPS serves the frontend and authenticated API requests; WSS carries the Nakama realtime socket."
- "RPC is request/response, usable over an active socket as well as HTTP; it is distinct from match-data opcodes."
- "Creation/status/recovery use narrow authenticated RPCs; play uses versioned match-data messages."
- "Only trusted server code writes permitted result records and authoritative leaderboard entries."
lifecycle:
- "[ ] Authenticate two independently provisioned Nakama tester accounts; do not treat display names or a room code as identity."
- "[ ] Restrict admission to the tester allowlist; create no public signup or anonymous-ranked-score promise."
- "[ ] A requests create_room via RPC with a stable request identifier; server binds project/room identity, rules version and two-seat capacity."
- "[ ] The creation RPC explicitly creates one authoritative match and returns the same active assignment on a retry; a client-supplied match ID does not grant a seat."
- "[ ] B presents the invite over the authenticated channel; trusted admission checks invitation, membership, ban state, available seat and protocol version."
- "[ ] Both clients join the returned match through the socket; match admission rechecks membership and binds each player to one controlling presence."
- "[ ] Ready/start waits for both admitted players and server confirmation; late second arrival gets the current waiting-room snapshot."
- "[ ] During active play, both send intentions; server computes and broadcasts accepted state; each client reconciles."
- "[ ] Finish freezes accepted gameplay, records the result explicitly, then confirms recorded status and exposes the minimal leaderboard."
- "[ ] Return to lobby is explicit; a new round gets a new match identity, not a reset of an old result's deduplication key."
match_creation_boundary: >-
Direct private-room creation is the chosen prototype path; matchmaking is not required for two
invited testers. If matchmaking is later admitted, tickets alone are insufficient: custom
registerMatchmakerMatched integration must create/assign the authoritative instance. No automatic
spawning is attributed to Nakama, and no second matchmaking path is included in this plan.
creation_failure_boundary:
- "[ ] Serialize or conditionally claim each room creation; reconcile stale claims and terminate orphan instances after failed assignment."
- "[ ] Reject duplicate active seats and cross-room ticket reuse; never leave a retry silently creating a second playable match."
- "[ ] Prove the exact runtime/storage primitives before claiming creation idempotent; the corpus supplies no implementation."
intentions_not_facts:
request_shape: "Versioned intent with match_id, connection_epoch, increasing sequence, and bounded direction/action; server derives actor from authenticated presence."
forbidden_authority: "Client coordinates, time elapsed, hit/collection claims, score, winner, reward amount, role, and player identity are not trusted facts."
acceptance:
- "[ ] Validate opcode/schema, finite numeric values, payload size, actor membership, active match phase and protocol version."
- "[ ] Enforce input cadence and speed from server time; extra packets cannot purchase extra movement."
- "[ ] Reject stale/duplicate sequences and obsolete connection epochs; bound outstanding messages and per-player processing."
- "[ ] Apply geometry/collection/conflict rules once per server step and send accepted tick, state revision and per-player acknowledgement."
- "[ ] Interpolate remote state; reconcile optional local prediction to accepted state without changing trusted scores."
- "[ ] Choose the lowest server tick rate meeting the measured interaction; client render cadence is independent."
- "[ ] Do not call this cheat-proof: server rule validation mitigates specified exploits, not bots, collusion, account abuse or every denial-of-service attack."
reconnect_snapshot:
proposed_policy: >-
Allow one server-timed 15-second disconnect pause per player per round. Freeze both players and
the active-play clock so the connected player cannot score against an absent opponent. Expiry or
a further disconnect aborts the round without a competitive score. This bounded private-test
policy trades availability for simple fairness and must be visible before starting.
sequence:
- "[ ] Mark disconnected immediately on detected loss; mark connecting, awaiting admission, and awaiting snapshot separately."
- "[ ] Re-establish a valid session and socket, then request the existing assignment; reconnecting transport alone is not joined or synchronized."
- "[ ] Authoritative join handler rechecks account, membership, pause deadline and ban state; returning player identity is not a fresh seat."
- "[ ] Replace the older controlling presence, mint a new connection epoch, and reject stale-session inputs rather than allowing two controllers."
- "[ ] Send a full snapshot containing match/rules/protocol versions, authoritative tick, entities, scores, active time, phase, pause deadline, input acknowledgements, and result status."
- "[ ] Replace client shared state from the snapshot; discard old-epoch queued inputs and ignore older revisions."
- "[ ] Buffer newer deltas until snapshot installation or request another snapshot on a revision gap; never reconstruct authority from a local save."
- "[ ] Enable play only after accepted resynchronization; handle expired session, denied rejoin, finished match and aborted match as distinct exits."
- "[ ] A third visitor arriving mid-round receives a safe capacity denial; no unplanned spectator role. A returning participant receives current state."
node_loss: >-
Transport recovery is supported only while the assigned live match exists. No hot match checkpoint
restoration or seamless node failover is promised. After node loss, recover an already durable final
result if present; otherwise report that the round was interrupted with no confirmed score and offer
a new round. Do not recreate an apparently completed win from browser state.
minimal_durability_and_duplicate_results:
needed_records:
- "Tester identity/admission and minimal room assignment needed to authorize joining and recovering the current round."
- "Immutable final result keyed by server-issued match identity: rules version, participant IDs, scores, outcome and commit status."
- "One server-authoritative best-score leaderboard for the private testers; no additive currency, inventory, clans, chat history or feed."
boundaries:
- "[ ] Keep hot movement/presence in match RAM; explicitly write required final results through trusted Nakama code."
- "[ ] Make terminal result creation conditional and idempotent; repeated finalization reads the same immutable record or rejects a conflicting payload."
- "[ ] Deny client writes to results and leaderboard; result/status RPCs authorize the requester before exposing a record."
- "[ ] Project leaderboard best scores from durable results using a monotonic best-score operation, not retry-sensitive increments."
- "[ ] Do not assume result storage and leaderboard updates are one transaction; show recorded-result / leaderboard-pending separately."
- "[ ] Retry only missing projection work from the authoritative stored result; completion, status recovery and reconnect may repeat safely."
- "[ ] If the result write fails, show result-unconfirmed and retain the pending terminal state while the node lives; never show recorded success."
- "[ ] Exercise crash after result commit but before acknowledgement, and after commit but before leaderboard projection; recover without another award."
- "[ ] Define retention and cleanup before inviting testers; retain deduplication evidence for every still-retryable result and never reuse match identities."
- "[ ] Back up the minimal retained DB if durable results are promised; prove restoration separately from frontend rollback."
unresolved_mechanism: >-
Exact conditional-write/conflict semantics, room-creation concurrency behavior, leaderboard best-score
semantics and crash-recovery repair need implementation-time verification against the selected Nakama
version. At-most-once effects are acceptance requirements here, not a claim of built-in exactly-once delivery.
moderation_and_exposure:
- "[ ] Begin with two invited accounts, fixed map/assets, bounded actions, and generated neutral labels; omit free text, uploads, chat and public discovery."
- "[ ] Enforce connection/action limits and provide a visible leave/report path to the named operator."
- "[ ] Operator may revoke admission, disconnect a player and abort an affected round through a trusted private administrative path."
- "[ ] Ban state blocks new joins and rejoin; UI flags cannot grant or revoke operator privileges."
- "[ ] Revocation does not silently delete results. State blast radius, retention, appeal/contact path and any irreversible deletion before acting."
- "[ ] Treat any displayed user/server-error text as text; validate invite handling and keep session tokens and private invites out of URLs and captured evidence."
- "[ ] Public matchmaking, free-form communication or user assets require a new abuse/moderation review, not a switch flipped after a successful demo."
deployment_choice_and_costs:
chosen_shape: "Static SvelteKit frontend where suitable; separate single-node Nakama plus PostgreSQL, initially on an isolated Docker Compose development environment."
eventual_public_shape: "Owner-approved HTTPS frontend and separately hosted Nakama behind HTTPS/WSS; database, console and administrative access remain private."
checklist:
- "[ ] Pin compatible frontend/SDK/runtime/DB versions and retain lockfiles; dated research versions are not a current compatibility proof."
- "[ ] Build no competing auth service, database service API, socket framework, or default enterprise cluster."
- "[ ] Select provider, region, resource limits, TLS termination, private network, backups and an accountable operator before any deployment."
- "[ ] Define a frontend/protocol release policy: let old compatible rounds drain; otherwise announce a clean abort rather than silently mutating live rules."
- "[ ] Test rollback with stored-record compatibility; rollback of code is not restoration of database contents."
- "[ ] Approve a spend ceiling and overload behavior before a capacity exercise or exposing a link."
unknowns:
- "No selected host/region, current price quote, spend ceiling, egress bill, backup retention, operating schedule or public exposure approval."
- "No measured tick budget, p95/p99 latency, reconnect duration, CPU/RAM per match, bandwidth per player or concurrent-match capacity."
- "Two-client correctness proves only the tested loop; it does not establish scale, anti-cheat completeness, uptime or disaster-recovery guarantees."
- "Single-node Nakama is the proposal; enterprise clustering is separate, not an assumed open-source capability."
- "No runtime AI spend is proposed. OMP/development costs and hosting/operations costs remain separate; a license is not free operation."
acceptance_gates_before_real_claim:
evidence_rule: >-
Every gate is not run. Later evidence must identify revision, pinned versions, rules/protocol version,
environment, two distinct accounts/clients, steps, expected versus observed outcome and timestamp.
Capture sanitized client observations together with correlated server and durable-record evidence.
A cinematic referee, same-page relay, mock socket, diagram or green build cannot satisfy these gates.
gates:
- id: "C1 / A1-A3: usable independent clients"
checklist: "[ ] Open the actual served revision in two independent browser contexts; identify entry, join, move and finish with keyboard and touch."
evidence: "Inspect both live surfaces, focus/labels, 320px and 400% zoom surroundings, reduced motion and non-color status; measure local feedback against the source targets."
- id: "C2 / A6: trust and access"
checklist: "[ ] Exercise signed-out, nonmember, other tester, forged IDs/roles, revoked account, third seat and direct result/leaderboard writes."
evidence: "Trusted denial with no protected state mutation; browser cannot reach DB/admin services. Altering hidden controls is not sufficient evidence."
- id: "C3 / A8: simultaneous legal play"
checklist: "[ ] Send concurrent movement and token contention, including an exact tie and terminal-score tie; delay B's initial join."
evidence: "Both clients converge on the same authoritative revision/outcome under the disclosed rules; no duplicate collection or premature start."
- id: "C4 / A8: malicious and duplicate input"
checklist: "[ ] Send impossible speed, fake score, wrong phase/opcode, malformed/oversized payload, flooding and repeated/stale sequences."
evidence: "Rejected or bounded input leaves accepted game state valid; packet frequency cannot increase speed or award a score."
- id: "C5 / A9: reconnect correctness"
checklist: "[ ] Disconnect before/after an accepted action, rejoin inside the pause, expire it, reconnect a second controller, and drop out a second time."
evidence: "Truthful states, server pause policy, full snapshot convergence, stale-input rejection, no second seat, and explicit expiry/abort."
- id: "C6 / A9: creation and terminal retry"
checklist: "[ ] Retry room creation concurrently; duplicate terminal messages and result/status requests; lose the final acknowledgement."
evidence: "One active playable assignment, one immutable result, unchanged best-score projection, and no false recorded-success message."
- id: "C7 / A9/A12: interrupted persistence and restart"
checklist: "[ ] Interrupt DB writes, crash at both result/projection boundaries, restart the node mid-round, and restore retained records from backup."
evidence: "Durable outcomes recover once; unfinished rounds are explicitly interrupted; partial projection heals without another award; backup restoration is independently demonstrated."
- id: "C8 / A9/A11: live release and moderation"
checklist: "[ ] Change frontend/protocol during active play; revoke a current player; attempt unauthorized moderation and hostile display text."
evidence: "Compatible drain or explained abort, safe rejoin denial, no execution of text, no unauthorized removal, no silent result deletion."
- id: "C9: bounded operational envelope"
checklist: "[ ] After owner approval, measure two clients under delay/loss and a declared bounded concurrency load; observe process and egress usage."
evidence: "Report actual limits, failure rate, percentiles, tick overruns and reconnect distribution; enforce the approved overload/spend boundary rather than extrapolating capacity."
state_coverage:
- "[ ] Cover first-run, empty lobby, connecting/loading, partial result projection, error, offline, no-permission, unavailable/full and confirmed success."
- "[ ] Offline is not local multiplayer success; preserve useful lobby input, but discard stale movement intent rather than replaying it later."
- "[ ] Reset/rematch/Back/leave cannot erase shared state or create a second committed result without the declared server transition."
- "[ ] A4 applies only to optional preferences; A5/A7 apply narrowly to retained result/retry promises, not a claimed personal workspace."
- "[ ] A10 is N/A because runtime AI is omitted; record that reason instead of claiming an AI pass."
risks_and_stop_rule:
primary_risks:
- "Authority code can still contain exploitable rules; validation must be proven against actual bypass attempts."
- "Creation retries, two controlling sessions and partial result commits are race conditions, not UI-only problems."
- "Bounded pause can still be used to disrupt a private round; abort/no-score is the disclosed compromise, not a public competitive policy."
- "Single-node loss sacrifices ongoing rounds; a durable final result does not imply a resumable live simulation."
- "Phaser lifecycle leaks, mobile input and reconciliation may degrade usability even while server state remains correct."
- "Untested conditional writes, retention or repair semantics block trusted-result claims until resolved."
exact_open_facts:
- "Selected runtime/SDK versions and their working conditional-write, match creation, leaderboard and session-recovery APIs."
- "Measured tick cadence, network envelope, reconnect convergence time and target-device performance."
- "Operator-approved retention, backup recovery objective, host/region, resource/spend limits and tester admission method details."
- "Actual authorization, duplicate-effect, recovery, moderation and live-release outcomes: no runtime scenarios have been executed for this plan."
stop_when: >-
Two independent invited players finish one authoritative mode, recover a dropped connection under
the disclosed policy, and observe one confirmed durable outcome with the gates evidenced. Stop there;
do not add economy, friends, clans, tournaments, public chat or broad persistence merely because Nakama offers them.
claim_after_evidence: >-
Describe only the exercised private two-player prototype, its tested conditions and known abort/recovery
limits. A later showcase needs its own authorized implementation and actual visual/interaction evidence;
writing this checklist does not create either deliverable.