Websim is described in the supplied research as an AI coding workspace, browser-playable projects, managed AI/data/multiplayer capabilities, and a publishing/remix community. The useful mental model is describe → build → play → improve → share, not “everything runs on one required React stack.”
The D/O/R/? labels follow index > How to read claims. Hosted-platform evidence below comes from the September 6 research; the later independent-stack sections come from September 10. Neither is a new runtime investigation. The distinction between product lanes is load-bearing: a recommended Nakama/PostgreSQL backend is not evidence of Websim’s database.
Read the inventory without inheriting it
The supplied full-stack poster groups available capabilities; it does not prescribe their use. Local state sits inside the visitor browser. The intentional absence of arrows avoids claiming a verified network or trust topology. “Private infrastructure: unknown” is a knowledge boundary, not another service to buy. Its manifest and generation provenance are explained in artifact-atlas > Full-stack record.
Creator workspace
| Layer | What the sources document | Responsibility and boundary |
|---|---|---|
| Coding AI and Build agent | D: model-driven generation and a live editing agent; ChatGPT-connected Build is described separately from the model/credit route | R: distinguish the AI writing project code from AI that visitors invoke inside the result |
| Files and framework | D: View Source, multifile projects, @filename targeting, and an announcement of modern-framework support | R: preserve a working stack. ?: no exhaustive supported framework/version list, package-manager recipe, SSR guarantee, or arbitrary backend guarantee |
| Assets | D: image, audio, and 3D uploads, an Asset Browser, and @name references; the guide says approved uploads enter the global Asset Browser | R: upload only rights-cleared, public-safe material; reuse and compress rather than regenerate |
| History and collaboration | D: revisions/default versions, remix/adoption, suggestions to the original creator, Merge, and group build | R: accept one change, then replay existing behavior. A successful merge is not proof of correctness |
Evidence: Websim guide, ChatGPT Build, July 16, 2026, and August 21, 2026 update.
Visitor browser
The frontend provides interaction, rendering, and input. The original research reports O: published project HTML on the community API reference included Websim-injected runtime JavaScript and project metadata. A delivered script establishes neither a stable SDK contract nor the technology running behind it.
Local memory and optional browser storage are frontend implementation choices, not Websim managed services. A transient draft is not a save; a same-browser preference is not a cross-device record. state-and-trust explains where those distinctions become consequential.
Creator specification and assets
-> coding agent -> project files and revisions
-> creator chooses a revision to publish
Visitor -> browser interaction
optional branches, only if the outcome requires them:
- local preferences in the browser
- runtime AI
- live shared state
- durable records with enforced permissions
Community feedback -> creator review -> targeted change
-> applicable checks -> creator publicationThis is a conceptual responsibility map. It does not identify network routes, servers, protocols, trust implementations, or a deployed Simp application. Visitors use the experience; they do not own its release process.
Optional managed capabilities
| Capability | D: stated public capability | R: contract the implementer must establish |
|---|---|---|
| Runtime AI | Text generation, image understanding, image generation/editing, and text-to-speech without a personal provider API key | Validate results; retain useful input; handle empty, malformed, limited, and failed responses; prevent duplicate costly requests |
| Identity and metadata | User/project information such as avatars, likes, and projects | Identity answers who; authorization answers what is allowed. A display name is not authority |
| Live multiplayer | Project-scoped WebsimSockets synchronization; later reconnect and publishing improvements | Define presence, shared objects, access, authoritative outcomes, and conflict rules. Do not infer anti-cheat or unlimited clients |
| Persistent data | Records supporting galleries/forums/social features; remembered roles and permission use cases | Name required fields and allowed reads/writes/deletes. Database engine, transactions, quotas, and backup guarantees remain unknown |
| Moderation | View Data search and deletion, plus bans; the guide says a ban also deletes that poster’s entries | Define operator powers and recovery before destructive action; moderation exposure determines the needed controls |
Evidence: AI abilities, October 28, 2025, guide, and August update. Admission to a particular scope is separate from availability: see scopes > Capability admission.
Publishing and community
D: the sources describe fullscreen/share links, Post to feed, comments, likes, remixes, tips, and community suggestions. The August update adds “Suggest to original” followed by creator Merge, and an ideas/voting board whose winning proposals the agent builds.
R: verify the actual posted, visitor-facing revision and intended access, not only the editor preview. Comments and suggested changes are untrusted inputs, not permission to disclose secrets or weaken access controls. See workflow > Improve and recover and state-and-trust > Untrusted content and destructive actions.
What the inventory cannot tell you
D: View Source is documented. A historical August 2024 report describes downloadable HTML/CSS/JS; it does not establish export of hosted services today. Complete backend export, Git sync, custom domains, and equivalent self-hosting remain unverified in this corpus.
O: the original research reports that the public websim-ai organization exposed a local host-router repository, not the full platform. A similarly named Flask “WebSimAI” project was excluded as unattributable. There is no defensible full bill of materials here: do not infer Flask, Next, Postgres, SQLite, Kubernetes, a cloud vendor, or SDK versions from lookalikes.
A small hosted static interaction is a legitimate final choice. The scopes selector determines what is necessary; costs-and-rights > Stay or migrate explains why owning source is different from owning a managed backend.
Source basis: CHEATSHEET.md “30-second answer,” “complete publicly knowable stack,” and architecture subsection; PLAN.md introduction and whole-stack section; websim-full-stack-poster.json zones and constraints. source-coverage provides section-level traceability.
Independent app responsibilities
R — September 10’s Starter Stax recommendation is one lean base, one specialist only when needed, and other capabilities as demand-driven recipes. It recommends an independent Websim-style browser experience, not a drop-in repository for hosted Websim.
| Piece | Responsibility | What not to add by default |
|---|---|---|
| Svelte 5 | Components, ordinary state, interactions | An extra state library for ordinary component state |
| SvelteKit | Routes, layouts, rendering, optional server endpoints | A backend solely because Kit is present |
| TypeScript | Contracts and editor assistance | An incompatible replacement toolchain |
| Vite | Development/build tooling | Treating Vite as the production application server |
| Tailwind 4 | Layout and targeted styling | A competing utility framework |
| daisyUI 5 | Visual vocabulary and themes | Assuming styling supplies every interaction |
| Bits UI | Justified complex headless interaction | Wrapping every native button or input |
| OMP | Development and verification | A visitor-facing runtime or agent broker |
For one browser-only screen, Svelte + Vite may be smaller; for a disposable static experiment, plain HTML can suffice. The source advises against maintaining all three template forms before real consumers exist. Sources: Svelte CLI, daisyUI, Bits UI, OMP.
Choose one specialist
These are six conceptual labels in the source, not published packages, an implemented collection, or the future three strategic approaches.
| Source label | Appropriate interaction | Addition and exclusion |
|---|---|---|
| Stax App | Quiz, calculator, small tool, configurator | Base only; omit accounts/database/orchestration without need |
| Stax Spatial | 3D viewer, toy, scene | three + @threlte/core; not automatic physics/XR/studio/post-processing |
| Stax Canvas | Sprites, particles, interactive 2D visuals | pixi.js; not an automatic full game engine |
| Stax Game | Platformer, arcade, tilemap | Phaser as primary engine; not a second rendering/game-state system |
| Stax Graph | Node editor or visual workflow | @xyflow/svelte; not an execution engine merely because nodes exist |
| Stax Content | Guide, explainer, interactive article | mdsvex when Markdown helps; not an automatic CMS/auth/database |
Pixi solves rendering; Phaser adds game systems such as scenes, loading, physics, input and tilemaps. Native SVG/Canvas may suffice when neither earns its place. Svelte Flow needs its stylesheet and a sized container; the source recommends $state.raw for nodes/edges. A graph does not automatically validate, authorize, execute, or resume work. References: Pixi, Phaser, Svelte Flow, mdsvex.
For Threlte, three and @threlte/core are the minimum; choose Three/types coherently. Extras earn their place for camera controls, 3D text, or helpers; Rapier and its physics dependency for real physical simulation; the GLTF CLI for component generation (generated components need extras); XR for actual AR/VR; studio tooling for a real authoring need. Rotating a model does not require physics. Keep ordinary controls in the DOM and start with one canvas, not a speculative global scene-portal architecture. Threlte package boundaries.
Optional recipes remain optional
CSS/Svelte motion precedes a timeline library. Native audio precedes complex mixing; Tone.js earns its place for transport, scheduling, synths or sequencing, not a click sound. Small non-sensitive preferences precede indexed storage; Dexie can simplify IndexedDB but supplies neither cross-device sync nor backup. Svelte pages precede Markdown tooling; simple tables/SVG precede a chart library unless data/interaction/accessibility warrants it. Runtime AI begins at one controlled server-provider boundary; authentication requires an identity/privacy need; multiplayer requires genuine shared state.
Gaming ownership is explicit
R — Gaming Stax pairs Svelte menus/lobby/HUD/settings with Phaser for 2D OR Three/Threlte for 3D; Pixi may substitute when rendering alone is needed. The official Nakama JS SDK and HTTPS/WSS connect to Nakama, custom authoritative handlers/RPCs, and a private PostgreSQL database. The documented local recipe uses Docker Compose; a public frontend may be static with a separately secured Nakama service and private database/console. No such deployment is performed here.
| Domain | Platform primitive | Application responsibility |
|---|---|---|
| Identity/authentication | Nakama sessions/accounts | Choose allowed operations and keep credentials private |
| Match discovery | Tickets, matchmaking, parties | Explicitly create/assign an authoritative match after matching |
| Rules | Match-handler/RPC execution | Validate intentions and own legal outcomes |
| Physics | Client rendering/physics and server runtime facilities | Establish trusted simulation; client Rapier is not authority |
| Outcomes/ranks | Storage and leaderboard capabilities | Explicit, authorized, duplicate-safe result writes |
| State persistence | Durable storage | Persist checkpoints/results intentionally; match RAM is not automatically saved |
Nakama also offers friends and chat, not a mandate to enable them. Do not add a second backend/auth/socket framework/ORM by default. scope-3-play-together and state-and-trust carry the game-rule, VM, reconnect, and tick boundaries. The September 10 sources cite Nakama JS SDK, authoritative multiplayer, TypeScript runtime, and Docker setup.