R — choose S2 when meaningful work must survive return visits or move between devices. The recommendation is to add only the records needed for that return journey, not to save everything.
The two zones distinguish temporary input from durable records. The central access check asks who may read or change them; the second arrow is explicitly conditional. The detached AI note avoids suggesting that persistence requires AI. This is a conceptual scope illustration dated 2026-09-06, not an implemented security boundary.
The question and the minimum
“Must meaningful work survive return visits or move between devices?” Keep S1’s interaction principles, add required durable records, and define their access policy. Name only necessary fields and allowed read/write/delete operations.
Identity is needed when ownership or a distinguishable actor is needed. Extra roles belong only where powers genuinely differ. A client-side admin flag, hidden button, or matching display name is not permission enforcement.
Show “saved” only after trusted confirmation. Preserve recoverable input through interrupted writes, and do not turn retries or double activation into unintended duplicate records. The corpus supplies no particular record schema or tested API.
Declared nodes and edges
| From | To | Meaning |
|---|---|---|
| BROWSER DRAFT | CHECK ACCESS | Solid “request” edge: temporary input requests an operation |
| CHECK ACCESS | SAVED RECORDS | Solid “allowed only” edge: durable access is conditional |
The record declares two edges and three nodes. Its artwork checks require permission before durable access, no implication of unconditional writes, a distinct temporary draft, a separate optional AI note, no implied multiplayer, and no invented database engine or API. The figure is a responsibility model; it does not specify or prove a server implementation.
Independent options and exclusions
The poster says to skip live rooms, feeds, and extra roles unless an actual task admits them. AI is an independent opt-in: determine the operation’s current cost and failure behavior, rather than assuming a database or connected build account supplies runtime funding.
S2 does not require simultaneous participation. If that is the core outcome, scope-3-play-together is the appropriate decision even when durable history is unnecessary.
Required outcome before stopping
A permitted person must recover the correct work, and an unauthorized person must not. The poster’s compact checks are refresh, second account, and denied access. In experience-and-acceptance > Acceptance cases, A5 requires the right saved record on refresh/return, A6 denies protected operations after UI/record-ID tampering, and A7 preserves input without false success or duplication after interruption/retry.
The all-scope cases still apply, and AI/content cases apply only when admitted. Database engines, transactions, quotas, and backups remain unverified; a missing trust or recovery guarantee can block this dependent scope without blocking a simpler S1 outcome.
Source basis: PRD.md sections 1, 4, 6–8; scoped-posters.json scope S2; scope-2-keep-what-matters.png. Continue with state-and-trust, costs-and-rights, or the scopes selector.
Local records are not automatically shared durability
September 10 adds an intermediate implementation choice: IndexedDB, optionally simplified by Dexie, can hold offline browser-local records. It does not create cross-device sync, shared authorization, or backup. Choose the required recovery boundary before calling local storage “durable” in a broader user promise.
The historical Darkroom illustrates explicit local saves, read-back, parent-child versions, and a selected default. Its store is capped at 20 versions, supports deletion, and can fail when storage is denied. Short content-derived IDs and immediate read-back do not establish permanent history, collision-free identity, shared records, or database restoration. Gaming results/checkpoints likewise require explicit trusted writes; live match state is not automatically persisted by installing Nakama.