Three strategy-different plans, all proposed and unimplemented. This comparison does not select a winner, authorize implementation or publication, or establish a showcase. No acceptance gate has run for these proposals. Read the linked plans for their full contracts; this page compares them rather than replacing their requirements.
These are not the S1/S2/S3 scope posters, the starter product lanes, the six conceptual starter labels, or the existing educational artifacts. S1/S2/S3 describe capability scopes, not products or a compulsory release ladder. The plans make different product and authority choices within those scopes. Darkroom’s recorded replay/local history and Gaming Stax’s local referee remain dated teaching material, not evidence that any proposed app works.
What each strategy buys—and costs
| Decision axis | A — Local loop: approach-a-local-loop | B — Durable records: approach-b-durable-records | C — Authoritative play: approach-c-authoritative-play |
|---|---|---|---|
| Promised outcome, if implemented and proved | One visitor explicitly splits available minutes into work blocks, edits, repeats and resets. | One owner explicitly saves private text work cards and retrieves accepted content on return or another device. | Two invited players join one server-refereed collect race, act simultaneously, reconnect under a bounded policy and see an agreed result. |
| Optimizes | Fast useful first result, inspectable portable source and the fewest failure boundaries. | Smallest credible account-wide record service with enforceable access and bounded recovery. | Agreement on legal actions and outcomes under concurrent input, with truthful reconnection and result status. |
| Deliberately gives up | Accounts, durable history, cross-device saves, shared state, runtime AI and installable/offline-first guarantees. | Account-free durable saving, offline sync, collaborative editing, live rooms, public sharing and unlimited history. | Static-only operation, offline core play, broad personal workspaces, peer authority, seamless node failover and large-world scale. |
| Visitor steering versus automation | Visitor chooses minutes/blocks and submits or resets; browser only validates, divides and renders. It does not prioritize work or start a timer. | Owner chooses content, Save, conflict resolution, export/import and deletion; service validates, authorizes, commits and reads back. No hidden autosave, automatic merge or implicit account transfer. | Players send movement intentions; trusted handlers decide movement, collection, clock and outcome under disclosed rules. Operator controls admission, bans, retention and exposure; reconnect cannot invent authority. |
| Proposed service boundary | Self-contained HTML/CSS/JavaScript on an approved static host, plus a separately proven local copy. No app server, storage, account, API or specialist dependency. Preserve an existing Svelte target only if that later target warrants it. | Independent SvelteKit/TypeScript app with adapter-node, one request-time service, private persistent SQLite and a maintained OIDC integration. Static-only or ephemeral hosting is insufficient. | Svelte/SvelteKit DOM interface plus Phaser as the sole world specialist; official Nakama SDK/socket, custom authoritative Nakama handlers and private PostgreSQL. A static frontend does not make the product static. |
| Trust and state boundary | Browser owns disposable in-memory input/result. Local tampering affects only that visitor; client output is not a trusted shared fact. Hosting requests remain distinct from app input collection. | Trusted session establishes identity; every operation enforces owner authorization. Memory drafts are not saved records; operators can access service data, so owner-only rules are not end-to-end encryption. | Browser visuals/prediction are not authority. Server validates authenticated intentions and owns hot match state; explicitly committed results are separate from RAM, reconnect and leaderboard projection. Database/admin access stays private. |
| Recovery bargain | Refresh starts fresh; browser-history restoration may retain transient state but is not persistence. Code rollback restores an artifact, not user records. | Revision conflicts need human resolution; bounded operation receipts resolve ambiguous saves. Export, off-volume backup restore and identity recovery are different obligations; unsaved memory drafts can still be lost. | Full authorized snapshot restores a live match connection. Proposed pause is bounded; expiry, repeat disconnect or node loss can abort a round. Durable final results do not make unfinished matches resumable. |
| Future evidence burden | Actual arithmetic and state transitions, keyboard/touch/accessibility, fresh-session served revision, runtime network/storage inspection, copied-file/offline behavior and code rollback. Static packaging alone proves none of these. | A’s applicable usability/revision checks, plus independent same-owner return, second-account/direct-request denial, interrupted writes, one committed retry effect, stale-device conflict and separate data/code restores. A refresh or Saved label is insufficient. | Two independent clients plus correlated server/record evidence: simultaneous contention, forged/duplicate intents, admission, snapshot rejoin, creation/result races, partial commits, node loss, moderation, release compatibility and measured operating limits. A same-page relay or green build is insufficient. |
| Fused source grounding | Sep06 S1 loop, minimal capability and A1–A4/A12 guidance; Sep10 lean browser base/native controls, earned specialists and OMP as development-only. The calculator, arithmetic bounds and no-storage packaging are new choices. | Sep06 S2 access-before-records and A5/A6/A7 guidance; Sep10 request-time app responsibilities and Darkroom’s explicit save/read-back lessons, qualified by bounded local history. Work cards, SQLite/OIDC, receipt policy and recovery targets are new choices. | Sep06 S3 shared-project edges and A8/A9 guidance; Sep10 Gaming/Nakama responsibility split, two-player first playable, custom rules and explicit persistence/reconnect. Phaser collect race, private room, pause policy and result projection are new choices. |
The dated foundations are shared inputs: scopes, platform, state-and-trust, experience-and-acceptance, artifact-atlas and source-coverage. September 6 supplies outcome/capability and acceptance framing; September 10 qualifies it with independent-app recommendations and educational examples. Neither establishes Websim’s private backend, current package compatibility, or runtime proof for these plans. Exact source locators and the separation of source guidance from new decisions remain in each plan.
Decision checklist—not executed checks
Choose by the indispensable outcome, not by framework preference or a desire to use every service. B is not an automatic upgrade from A; C is not B with a multiplayer skin. C retains only records its own result/admission promise needs, not a general S2 workspace. If the required outcome falls outside these contracts, reopen the decision with the owner rather than silently combining them or inventing another lane here.
decision:
status: "PLAN ONLY; no selected approach, implementation authorization or passed gates"
checklist_meaning: "[ ] means an unresolved decision or future obligation, never completion"
allowed_choices: ["A local loop", "B durable records", "C authoritative play"]
outcome_first:
- "[ ] State one visitor outcome and the concrete reason any retained or shared state is indispensable."
- "[ ] Choose A only when a useful disposable browser result is sufficient."
- "[ ] Choose B when owner-authorized return to meaningful records is essential, without simultaneous shared play."
- "[ ] Choose C when concurrent participants need a trusted common outcome, not merely saved work or local animation."
- "[ ] Accept the chosen plan's explicit exclusions; stop and revisit selection if the required outcome contradicts them."
human_authority:
- "[ ] Owner approves the outcome, scope, dependencies, data policy and future implementation target."
- "[ ] Visitors retain the explicit choices described in the selected plan; automation executes bounded rules, not consent."
- "[ ] Keep OMP development-only and runtime AI absent in all three proposed loops."
- "[ ] Owner separately authorizes spend, hosting exposure, publication and any later showcase claim."
unresolved_before_dependent_work:
A_local_loop:
- "[ ] Establish that the timebox outcome is useful; its demand is a design assumption."
- "[ ] Identify the implementation target, final host/path, intended access and supported browser/device matrix."
- "[ ] Prove local-copy portability, session lifetime and performance before advertising them."
B_durable_records:
- "[ ] Select host, persistent-volume contract, OIDC provider/integration and supported versions; none is provisioned by the plan."
- "[ ] Establish stable identity/revocation behavior, SQLite durability and transactional receipt/conflict semantics."
- "[ ] Name the recovery operator, backup destination/key custody and deletion-safe restore procedure."
- "[ ] Agree limits and retention; proposed recovery targets are not measured guarantees."
C_authoritative_play:
- "[ ] Select compatible runtime/SDK versions and prove room creation, conditional writes, leaderboard and session APIs."
- "[ ] Approve tester admission, host/region, retention, backup objectives, resource/spend limits and operator responsibility."
- "[ ] Measure tick cadence, network envelope, device performance and reconnect convergence; do not infer capacity from two-client correctness."
- "[ ] Accept bounded pause/abort and single-node loss limits; reject any implied cheat-proof or seamless-failover guarantee."
evidence_before_real:
- "[ ] Implement only after the later authorization; keep proposal, implementation and observed-result labels separate."
- "[ ] Attach exact revision, environment, actors, steps, expected/observed outcomes and failures to the chosen plan's applicable gates."
- "[ ] Use fresh evidence from the actual proposed product, not posters, educational demos or their historical receipts."
- "[ ] Exercise visible interaction and the real trust/recovery boundaries; screenshots and builds cannot substitute for them."
- "[ ] Record unrun cases and justified N/A cases honestly; no claim can exceed the exercised conditions."
- "[ ] Stop at the selected complete loop; additional capabilities require renewed steering, not automatic expansion."Present evidence: three written strategy proposals grounded in the fused research. Not established: a selected strategy, working prototype, accepted operational guarantee, deployment or showcase. Their implementation questions remain open; this comparison does not resolve them by relabeling recommendations as facts.