Start with one useful loop. Add a capability only when removing it would break the promised outcome. Stop when that outcome is safe, clear, and complete.
This is the explanatory foundation for two supplied research corpora: the ten-file Websim research/design package dated 2026-09-06, and the 168-file Starter Stax corpus dated 2026-09-10. The older package explains hosted Websim and minimum capability scopes. The newer material recommends independent browser-app stacks and includes two existing educational HTML demonstrations, source, media, and historical local evidence. Neither corpus reveals Websim’s private servers or establishes an implemented Svelte/Nakama starter collection.
First distinguish the product
| Product lane | What the research recommends | Boundary |
|---|---|---|
| Inside hosted Websim | Use the platform capabilities that actually meet the outcome | No arbitrary SvelteKit import, lossless round-trip, or private-backend knowledge is established |
| Independent Websim-style browser app | September 10 recommends one lean Svelte base plus one justified specialist; OMP is development-only | A recommended stack, not an installed or exercised starter family |
| A Websim-like app-generating builder | Treat generated executable apps as a separate storage, preview, authorization, isolation, and cost-control problem | The Darkroom teaches this using recorded local replay; it is not a live AI service |
These lanes are not the later three strategic approaches. Nor are the S1/S2/S3 scopes, six conceptual starter labels, or three replay examples an approach selection. platform explains responsibility and engine choices; state-and-trust connects both corpora’s authority boundaries.
Start with the decision, not the inventory
| Your intended outcome | Start here | What earns the added complexity |
|---|---|---|
| One visitor gets value during one session | scope-1-play-now | Nothing beyond the browser loop unless the outcome needs it |
| Meaningful records must survive a return visit or move between devices | scope-2-keep-what-matters | Named durable records and enforceable access rules |
| People must participate at the same time | scope-3-play-together | Shared-state rules, synchronization, and safe reconnection |
These are three selectable scopes, not three releases or a compulsory upgrade ladder. S3 does not automatically include a database; S1 can include essential runtime AI without automatically acquiring accounts or multiplayer. Actual runtime access requirements still need checking. The scopes page explains the decision order, capability admission questions, and non-goals.
Read by task
- Understand the platform: platform separates the coding workspace, visitor browser, optional managed capabilities, and community.
- Turn an outcome into bounded work: workflow explains scope, edits, recovery, collaboration, and the source’s reusable prompt contracts.
- Place data and authority correctly: state-and-trust separates transient state, local preferences, durable records, synchronization, identity, and permission.
- Avoid misleading cost and privacy assumptions: costs-and-rights preserves dated pricing evidence, access caveats, asset rights, and migration boundaries.
- Specify observable behavior: experience-and-acceptance explains accessible interaction, nine reachable states, and the future A1–A12 acceptance cases. These are not results.
- Check the evidence boundary: evidence-and-limits records chronology, provenance, historical design rationale, and unresolved platform questions.
- Understand the illustrations and records: artifact-atlas explains the five images and both JSON structures rather than treating them as raw attachments.
- Trace any source section: source-coverage maps every Markdown section and each image or structured record to its explanatory home.
- Read the dated Phase 2 receipt: audit-and-corrections separates inspected foundation evidence, accepted inventory corrections, the required final sync rebuild, and unresolved limits before prototype planning.
- Compare the three Phase 3 proposals: comparison contrasts the local loop, durable records and authoritative play; all remain plan-only, with no selected implementation or showcase.
How to read claims
| Label | Meaning in this wiki | What it does not establish |
|---|---|---|
| D — documented | The supplied research attributes a capability to a named Websim publication or guide | That the capability was exercised successfully, remains unchanged, or meets a particular operational guarantee |
| O — observed in the source research | The original researchers reported a public-source observation, such as injected scripts or a login redirect | A new observation made while writing this foundation, or knowledge of private infrastructure |
| R — recommendation | Design advice, a scope rule, a proposed workflow, or an acceptance requirement | Implemented behavior or a passed check |
| ? — unverified | The supplied evidence does not settle the question | An invitation to fill the gap with a plausible technology choice or invented price |
Descriptions of image content explain what the supplied artwork depicts. Generation and inspection history is attributed to the JSON records; it is not independent application verification.
Dates and present project state
The original research/poster records are dated 2026-09-06; Starter Stax and Gaming Stax research are dated 2026-09-10. This foundation was assembled on 2026-09-15. The writing date is not a fresh check of external capabilities, package versions, terms, prices, or runtime behavior. Newer recommendations qualify overlapping older guidance without becoming evidence of hosted Websim’s implementation.
The current project state is research plus existing educational artifacts and this explanatory foundation. The newer Darkroom is a recorded-generation HTML/CSS/JavaScript demonstrator with a historical local receipt; Gaming Stax contains a local referee simulation, not a connected Nakama game. There is no newly built app, deployed starter family, new runtime acceptance run, selected strategy plan, or completed showcase asserted here. Historical artifacts and receipts are explained with their dates and limits in artifact-atlas and evidence-and-limits.
The source PRD’s promise is narrow: help a creator choose one complete interaction with the fewest necessary services and make risky boundaries visible. Feature count, AI output volume, and moving to a larger scope are not success metrics.
Source basis: CHEATSHEET.md introduction and operating doctrine; PLAN.md request, introduction, and closing doctrine; PRD.md introduction and sections 1, 3, and 9. See source-coverage for exact ranges.