R — state placement and authority are design decisions, not properties established by a successful-looking interface. D: the September 6 sources describe managed data, identity, and multiplayer capabilities. September 10 adds independent-app recommendations and O: local educational source examples, not evidence of any app’s enforcement, recovery, or synchronization. Labels follow index > How to read claims.
Choose a state lifetime
| Need | Recommended home | Boundary |
|---|---|---|
| Open menu, animation, temporary input/draft | In-memory browser state | Not a save system; no implied refresh survival |
| Theme, volume, non-sensitive preference | Browser localStorage, with failure handling | Origin-specific, not cross-device or confidential; private-browsing data is cleared |
| Online presence, cursor, live movement | Multiplayer with explicit transient-presence semantics | Not automatically durable or authoritative against cheating |
| Posts, gallery entries, roles, durable progress | Database with explicit read/write/delete rules | Client-side admin booleans do not secure records |
| Payments, secrets, regulated records, valuable scores | Verified trusted execution plus operational/security review | Generated UI or an agent’s assurance is not evidence of safety |
The MDN storage reference grounds browser-storage behavior. The Websim guide and August update ground the stated managed capabilities. This table selects responsibilities, not API signatures.
Identity is not authorization
Identity answers who is acting; authorization decides which operation that actor may perform. Specify allowed guest, user, moderator, and owner operations only where those actors are actually needed. Deny unspecified actions at the trusted data boundary, not merely by hiding a control. Do not grant rights through display-name equality or place secrets in browser code.
For S2, the scope-2-keep-what-matters sequence is draft → access check → allowed records. For S3, scope-3-play-together requires declared access, conflicts, and authoritative outcomes. Neither illustration establishes how Websim enforces the boundary.
R: exercise owner, another user, and signed-out access separately; alter UI state and record identifiers to ensure protected operations remain denied. This follows OWASP authorization guidance. These are future acceptance requirements, not tests performed for this wiki.
Truthful confirmation and continuity
A local, reversible, private change may be optimistic. “Saved,” “joined,” and a shared authoritative result must wait for trusted confirmation. An offline or interrupted request must not be represented as committed.
Preserve useful input on failure; explain partial completion; retry only missing work. Prevent duplicate costly AI calls and duplicate committed data/shared actions. Distinguish a recoverable draft from a durable record. Deep-link useful public navigable state only when appropriate, never secrets or private drafts.
For multiplayer, define shared objects, presence, conflict resolution, late-join behavior, and rejoin semantics. D: the August update describes improved reconnect/publishing behavior; ?: the corpus establishes no latency, client capacity, anti-cheat, or transaction guarantee. S3’s synchronization is not a reason to persist unnecessary history.
Untrusted content and destructive actions
- Treat user/AI text as text. Escape for the actual output context, use a maintained sanitizer when HTML is truly necessary, and validate URLs. Do not execute ordinary untrusted output in the app’s trusted context. The source cites OWASP XSS prevention. A builder deliberately running generated applications has the separate isolation obligations below.
- Comments, remixes, and group-build suggestions are untrusted requests. They cannot authorize secret disclosure, weakened permissions, or record deletion, even if the agent can read and act on them.
- Define operator powers and a proportionate restriction/removal path where participants can harm others or publish unwanted content. D: the guide says banning a poster also deletes their entries. Understand blast radius and recovery before destructive moderation.
- Do not confuse code history with data recovery. A known-good revision can recover code;
/clearonly resets agent context. Neither is a documented database restore mechanism.
Boundaries that can block a scope
If required enforcement, authority, or recovery cannot be established, narrow the promised outcome or choose another platform. Do not fabricate safety with interface controls. A missing database guarantee blocks the dependent data feature, not an unrelated S1 local loop.
The specific future checks are A5–A9, A11, and A12 in experience-and-acceptance > Acceptance cases. Cost, asset privacy, rights, and supported export have separate boundaries in costs-and-rights.
Source basis: CHEATSHEET.md state table, safety rules and ship gate; PLAN.md sections 2–5; PRD.md capability gates, principles, nine states and acceptance contract; both poster records’ trust constraints. source-coverage maps each section.
Local records and version history
R — September 10 extends the lifetime decision without changing it: IndexedDB, optionally through Dexie, can hold structured offline records, but neither supplies cloud synchronization, backup, shared authorization, or guaranteed retention. Choose those capabilities separately. A browser-only S2-like return journey is not automatically an account-wide record service.
O — the Darkroom source demonstrates content-derived version identifiers, parent/child lineage, explicit save with immediate read-back, deduplication, comparison, selection, deletion and undo. Its localStorage history is capped at 20 versions and storage may be denied. The taught 12-hex-character digest prefix is an identifier convention, not proof of collision-free or permanent storage. “Every version is preserved” is therefore too strong a reading of its narration.
R — describe what is actually retained, acknowledge saving only after the required confirmation, and distinguish selecting old source from restoring durable user data. O: the existing demonstration teaches this locally; it does not implement a shared project archive. See artifact-atlas > Darkroom chapters for the Fix/Reprint lessons and source-coverage > September 10 source and build lineage for the responsible source files.
Generated applications introduce a new boundary
R — AI-assisted development, a runtime AI feature, and a service that executes visitors’ generated applications are three different trust problems. OMP belongs to development in the starter recommendation. A runtime provider integration needs server-held secrets, request validation, bounded usage/cost and honest cancellation/failure behavior. A public app-generating builder additionally needs isolated execution, project ownership, preview permissions, resource limits and enforced egress policy.
O — the Darkroom is prerecorded HTML replay, not a provider call. Its source compares completion-only, every-chunk and lexical-checkpoint previews. A lexical checkpoint avoids some incomplete syntax; it cannot prove a generated program correct or safe. Its sandbox uses double-buffered allow-scripts frames without allow-same-origin, injected CSP, and a rate-limited postMessage bridge that checks the sending window.
? — those local mechanisms and the historical receipt do not establish universal navigation/network isolation, production quotas, authenticated project storage, upstream cancellation or billing behavior. The instructional streaming route is not a complete authenticated, body-limited production endpoint. Stronger narration such as “no network” must be read with the explicit qualifications in evidence-and-limits > Historical Darkroom evidence.
Gaming authority, persistence, and reconnection
R — the September 10 Gaming-Nakama recommendation gives the browser presentation and prediction, not authority. Custom server rules decide legal actions and own trusted rewards/scores. The Nakama authoritative-match documentation is the source’s platform reference; this is not a statement about hosted Websim’s implementation.
| Boundary | R: required division of responsibility |
|---|---|
| Intent versus outcome | Clients send intentions through the JS SDK; custom authoritative match handlers/RPCs validate them and send accepted state. Relaying messages alone does not validate gameplay |
| Prediction versus authority | A client may predict responsiveness, then reconcile with accepted server state. Client Rapier/Phaser physics does not make an outcome trusted; complex trusted physics may need a dedicated simulation process |
| Match discovery versus lifecycle | Matchmaker groups tickets; the taught architecture uses custom registerMatchmakerMatched integration to create/assign the authoritative match |
| Transport versus operation | HTTPS/WSS carries client traffic, never direct browser database writes. RPC can also use an active socket; match-data opcodes are a separate operation |
| Runtime versus browser/Node | Nakama’s TypeScript runtime is an embedded VM, not Node or a browser. Browser/Node-dependent packages are not drop-in server modules |
| Match RAM versus durable records | Explicitly persist required checkpoints/results and authorized leaderboard updates. Storage availability does not automatically save live match state |
| Reconnection versus recovery | Restore transport, admit the returning presence, send an authoritative snapshot, reconcile the client, and prevent duplicate results/rewards |
| Rendering, cadence, and operations | Rendering rate is not server tick rate; choose the lowest sufficient gameplay cadence. Start with one Nakama node; enterprise clustering is separate. Keep database, console, administration and server secrets private |
R — the first playable slice is two players, one mode: authenticate → join one authoritative match → play → reconnect/resynchronize → server records result → leaderboard. Invalid-action rejection, disconnect/rejoin and duplicate-result handling come before inventory, economy, clans or tournaments. This is a future contract, not a selected strategy or an implemented game.
O — Gaming Stax’s referee is explicitly a local teaching simulation with no Nakama connection. The Darkroom’s RoomHub is a same-page relay with heartbeat presence, ordered updates and latest-state restoration, not remote networking, real identity or anti-cheat. Neither substitutes for two independent clients exercising a trusted server.
Source basis: September 10 CHEATSHEET.md:135–168, GAMING-NAKAMA.md:34–60, the corrected Gaming-Stax.html boundaries, and Darkroom sandbox.js / playground.js. source-coverage disambiguates the two dated CHEATSHEET files; scope-3-play-together relates the first slice to S3.