R — these are requirements for a future experience, not a report that any test has passed. Scope gates are pass/fail; an attractive image or visual score cannot compensate for a safety failure. This foundation does not establish usability, accessibility conformance, performance, security, cost, or multiplayer correctness.
Experience principles
The PRD attributes these principles to external Funday design documents, D0-ZERO-DISTANCE.md and OVERSTANDING.md, especially sections 1–3 and 6. Those documents are outside the ten-file supplied corpus; their contents are not independently imported or verified here. The requirements below are the PRD’s stated adaptation, not Funday platform machinery imposed on Websim.
| Principle | Observable requirement |
|---|---|
| Experience first | A fresh visitor identifies the primary action and expected result without reading architecture notes; value precedes setup except where safety/access requires otherwise |
| One primary action | One accent-filled primary control at rest; quieter secondary actions; warnings and infrastructure are not the hero |
| Clarity before density | Plain verbs, meaningful grouping, no essential hover-only instruction or redundant label/card layers; borders mark actual boundaries and controls |
| Accessible operation | Keyboard/touch parity, visible focus, textual names and non-color status; text contrast at least 4.5:1, control/focus cues 3:1; targets at least 24px, primary/touch targets 44px |
| Truthful responsiveness | Prompt feedback, with source targets below 100ms and INP at most 200ms p75; never claim saved/joined/shared outcomes before trusted confirmation; private reversible local changes may be optimistic |
| Escape and continuity | Esc closes one present layer, focus returns sensibly, and Back does not silently discard meaningful work; Undo only when restoration works; disclose irreversible consequences; no modal required if inline UI suffices |
| Meaningful motion | Motion explains change or teaches a gesture; otherwise omit it. Sound is off by default; reduced-motion use is complete; no compulsory celebration, bounce, or animation framework |
| Proportionate state and URLs | Restore meaningful drafts where warranted; deep-link useful public state, never secrets/private drafts; do not add a router or persistence service merely for checklist compliance |
The numeric values are source requirements, not measurements. Test only reachable themes; do not build a theme picker merely to create another compliance task. Funday bridge protocols, runtime stack, density modes, platform laws, and deployment gates are not Websim requirements. Poster colors are illustration choices; implemented UI should use semantic theme roles.
Nine reachable states
Considering a state does not require inventing a new screen or service. Mark unreachable states N/A with a reason.
| State | Required response when reachable |
|---|---|
| First-run | A real entry action or example, not a configuration tour before value |
| Empty | Explain what belongs here and provide the action that creates it |
| Loading | Acknowledge the request, preserve input, prevent duplicate effects, and do not trap navigation |
| Partial | Identify completed and incomplete work; retry only the missing part |
| Error | Explain what happened and the next useful action; retain recoverable work |
| Offline | Distinguish local operation from unavailable networking; unsent writes are not saved |
| No-permission | Deny safely and offer a permitted exit/access route without leaking protected data |
| Disabled or unavailable | Explain why in accessible text; do not bury validation behind an unexplained disabled submit |
| Success | Show the actual result and one sensible next action, without redundant toasts or retention bait |
For example, a fully loaded local S1 loop has no database-save state; its initial hosting/network access still exists. Do not add a database just to make that state applicable.
Acceptance cases
Every row below preserves the source PRD’s future contract. None is a completed result.
| ID and applicability | Scenario | Required outcome |
|---|---|---|
| A1 — all | A new visitor opens the published link | Correct revision, intentional visibility/login behavior, clear first action and result |
| A2 — all | Repeat, reset, Back, keyboard and touch | Original behavior survives; no unintended destructive reset, inaccessible control, or lost meaningful work |
| A3 — all | Narrow viewport, zoom, reduced motion | Meaning and operation remain at 320px and 400% zoom; necessary two-dimensional game content may remain two-dimensional without losing surrounding controls |
| A4 — S1 | Refresh; deny browser storage if used | Documented session reset; optional preference storage failure does not break the core loop |
| A5 — S2 | Create permitted record, refresh, return from intended account/device | Correct saved work returns; saving is not acknowledged before confirmation |
| A6 — S2/S3 ownership | Guest or second account changes UI or record ID | Protected operations fail at the trusted boundary, not only in the interface |
| A7 — S2 | Interrupt saving, retry, double-click | No false success or unintended duplicate record; recoverable input preserved |
| A8 — S3 | Two visitors act, another arrives late | Participants see valid shared state under the declared conflict rule |
| A9 — S3 | Disconnect, rejoin, publish during use | Truthful connection status; no invented authoritative outcome, duplicate committed action, or unexplained loss |
| A10 — AI enabled | Empty/malformed output, limit/error, repeated activation | Actionable failure, no fake result or accidental duplicate costly call; output cannot execute untrusted code |
| A11 — content/moderation enabled | Adversarial text/URL; deletion or ban | Safe content handling, enforced operator authority, understood blast radius and recovery |
| A12 — all | Restore a known-good revision | Intended code recovery; neither rollback nor /clear mistaken for database restoration |
No account/data feature means the corresponding cases are N/A, not passed. Critical unknowns block only the dependent scope; they do not justify speculative infrastructure in S1.
Release questions
The CHEATSHEET.md ship gate and PLAN.md release section make the same contract operational:
- Does the loop work on first use, repeat, restart, and refresh?
- Does a fresh visitor session reach the intended revision and intentional access boundary?
- Are keyboard/focus, touch, labels, narrow screens, and audio start/mute usable?
- Are empty/malformed AI output, errors, limits, and duplicate costly activations recoverable?
- Do actual saves survive refresh without pretending local preferences are account-wide records?
- Do owner, second account, and guest get exactly allowed reads/writes despite changed UI or identifiers?
- Do clients agree through late join, reconnect, and publication without important loss or duplication?
- Are content execution, asset rights, visibility, and destructive moderation handled safely?
- Is the tested revision chosen, and is code rollback understood separately from database recovery?
These questions describe how a creator would decide to ship, not a claim that this foundation was published or an application operated. The source package’s own artwork requirements and inspection limits are separately attributed in artifact-atlas and evidence-and-limits.
Source basis: PRD.md sections 5–6 and 9; CHEATSHEET.md ship gate and safety references; PLAN.md implementation and release sections. Continue with workflow, state-and-trust, or scopes.