This page preserves the supplied sources’ evidence and historical reasoning. It is not a new audit, independent-review verdict, or claim that external statements were rechecked while preparing this wiki. The foundation research is dated 2026-09-06; the additional starter research and local demonstrations are dated 2026-09-10; the foundation writing date is 2026-09-15.
Evidence chronology
| Evidence | What the source uses it for | Qualification |
|---|---|---|
| Terms, dated August 29, 2024 in the research | Ownership, broad platform license, and automation restrictions | Not a new legal/current-terms review |
| Historical export report, August 14, 2024 | Reports HTML/CSS/JS downloads | Does not establish current export format or hosted-backend export |
| AI abilities, October 28, 2025 | Runtime text, vision, image, speech capabilities; free-access language with a 100-credit image-to-image exception | Current payer and caps remain unresolved |
| January credit update | Discontinued free daily credits, sponsorship/creator program, and video rewards; retained engagement/tips/purchases | Read alongside the later August video-reward return, not as a timeless policy |
| ChatGPT Build, July 16, 2026 | Connected-account build limits, not Websim credits; connection setup | Does not establish funding of visitors’ runtime operations |
| Websim update, August 21, 2026 | Modern frameworks, persistent roles, multiplayer recovery, Merge, group build, video rewards, /clear | Not a transaction, backup, anti-cheat, capacity, or complete framework-support guarantee |
| Main guide | Workflow, files/assets, visibility, moderation, revisions and managed capabilities | Source records canonical @websim, revision 70; undated guide with older details/2025 screenshots; newer dated statements take precedence |
| API reference | Public-source observation of runtime scripts/metadata; integration leads | Source records canonical @fsx/websim-api-docs, revision 199: community reference, not a verified official SDK contract |
| Public organization and plan page | Scope of public code and account-access boundary | Source reports a local host-router repo rather than platform source, and plan-page login redirection |
The platform overview grounds the creator/community description. OWASP authorization, OWASP XSS prevention, and MDN localStorage ground recommendations, not claims that a Websim app has passed security checks.
How the original research handled contradictions
The evidence sheet describes three passes: provenance, chronology/contradictions, and claim/link review. The condensed PLAN describes evidence rechecking, coverage, and artifact/link structure. These are source-reported research processes, not new verification runs for this foundation.
The guide’s Gemini 2.0 Flash name, 20 runtime requests/minute, separate daily pool, standard 100-credit generation runs, and premium tiers were not promoted to current model/limit/price guarantees. January’s video-reward removal and August’s return were both retained; other discontinued programs were not silently restored. A Flask-based repository called “WebSimAI” was excluded because a similar name does not establish platform provenance. Untested community endpoints/signatures were not copied as official contracts.
Prior artwork rationale, not a new audit
PRD section 2 contains a dated critique of the earlier inventory. It explicitly separates observed layout/content from inferred reader costs and says these are improvement judgments, not measured usability failures. The following preserves that rationale without claiming a later audit or new corrections have occurred.
| Source concern | Inferred cost described in the PRD | Source design response |
|---|---|---|
| Inventory looked compulsory; no default recommendation | Readers may add unnecessary services or have to architect before receiving value | Minimum/exclusion/stop per scope; S1 default with outcome-based reasons for more |
| Public capabilities looked like deployment facts; availability looked like proof | False confidence in infrastructure or an implemented app | Conceptual labels and explicit future acceptance checks |
| Trust boundary lacked a visible role; AI had equal service weight | UI identity may seem sufficient; build and runtime costs may blur | Access before records, trusted shared confirmation, independent AI gate and cost check |
| Strong border on every card; unknown infrastructure had strongest accent | Containers compete with the concept and caution displaces the outcome | Larger primary figure, whitespace grouping, fewer boxes, outcome/shared-experience accent |
| Dense small text; local and hosted state had equal weight | Full-size reading required and transient/durable/live data blur | Short scope question and proof line; separate local loop, gated records, shared state |
| No concise exclusions; caveats detached from decisions; no completion condition | Unnecessary growth, missed safety, endless upgrade expectations | Explicit omissions, safety notes beside the relevant scope, stop condition per image |
| Review provenance overly complex; repeated title/source chrome | Tool routing and repeated framing take space from the decision | Actual provider recorded in manifest; concise user-facing explanation and one title/question/footer |
| Bitmap-only delivery | Limited zoom, reflow, and screen-reader usefulness | Markdown text equivalent; never call a poster an accessible application |
The PRD retained creator/browser/managed-service separation, source links, honest infrastructure unknowns, rights/cost caveats, and no forced framework. It states the delivered earlier inventory had no arrows: rejected generation drafts are not defects in that final file. Its brainstorm triage and non-goals are preserved in scopes > Product promise and non-goals.
Package provenance and limits
The source PRD lists the three scope images and scoped-posters.json as its deliverables. It requires distinct minima, readable copy, declared edges, conditional AI/persistence, stop conditions, and agreement among files/links/manifest. It describes inspecting generated artwork and rejecting malformed drafts rather than redefining the specification to fit them.
Both JSON records report visual inspection of their final images. The scoped record attributes the actual image provider to xAI and model to grok-imagine-image, despite a requested openai-codex provider. The quickstart WebP has no supplied generation record. Full details are in artifact-atlas. These histories are not application results.
The evidence sheet reports that three research subagents failed at harness initialization and returned no findings; research continued directly. The PRD separately reports two delegated writers failing at initialization and identifies itself as integrator-authored, not independent-review consensus. Those are distinct source accounts, not an independent review to combine or inflate.
September 10 historical receipts and corrections
STARTER_CORPUS_MAP.yaml records static mining of /home/loca/dev/simp-research-starter/websim-starter (assignment-supplied commit d12614a, not newly verified). Its inventory and the chapter/media explanations in artifact-atlas are local source observations, not fresh runtime results. The newer CHEATSHEET.md and GAMING-NAKAMA.md recommend independent-app stacks; they do not reveal hosted Websim’s private infrastructure or establish arbitrary SvelteKit import compatibility.
| Read-only source (relative to that tree) | What it records; what it does not prove here |
|---|---|
websim-stax/verification.json | Receipt dated 2026-09-10T04:29:52.552Z reports 16 engine tests, deterministic build/media matching, scoped sandbox checks, local versions/RoomHub, player/keyboard behavior and screenshots at 1440×1000, 390×844 and 320×844. No check was rerun, no image freshly inspected, no audio played and no hash/byte parity independently established during this integration. |
websim-stax/test/engine.test.mjs | Sixteen test declarations cover scheduling, lexical states, rendering policies, document composition, diffs and sentence spans. Their existence is not a current pass or full browser/backend/security/accessibility coverage. |
websim-stax/build.mjs and embedded build manifest | Source describes assembly and source/vendor/media hashes. Even --check can fetch/write vendor files and rewrite LICENSES.txt before comparison: it must not be run against the read-only input. |
websim-stax/dist/proof/blueprint.json, print.pdf, websim-stax/dist/audit-projection.html | Historical Blueprint report: one audited file, zero issues, eight warnings (color density, four image-layout warnings, table overflow, inline icons, license-banner emoji). Print completeness is receipt-reported; the audit projection omits base64 media. Neither substitutes for the complete artifact or current visual acceptance. |
websim-stax/media/{provenance,cues}.json, websim-stax/narration/chapters.json, gaming embedded manifests | Preserve media attribution, transcripts, timing and reported digests. Metadata does not prove decode/listening quality, word alignment, underlying model identity or complete asset rights. Vendor license obligations are retained in artifact-atlas > Third-party vendor attribution. |
The earlier receipt itself qualifies its results: sandbox checks cover tested fetch/subresources and unknown-window rejection, not every navigation/egress path; checkpoint boundaries are lexical, not behavioral correctness. Visibility used a synthetic event and Snake arrow input was synthetic; subjective audio quality was not assessed. Same-page room recovery is not real networking. No historical Darkroom pass transfers to this foundation, the recommended starter family, a Nakama backend or future approaches.
Source precedence is scoped, not simply “newest wins.” September 10 qualifies overlapping September 6 recommendations while retaining the older dated history and hosted-platform unknowns. Within the starter material, explicit corrected boundaries in Gaming-Stax.html take precedence over contradicted GamingStax_full-txt.bkp.html prose; the backup filename does not establish its exact revision chronology:
- Corrected gaming material identifies Nakama as Apache-2.0, superseding the backup’s AGPLv3 label within this corpus; this is not a fresh upstream legal audit.
- Matchmaker groups tickets; custom
registerMatchmakerMatchedintegration creates/assigns the authoritative match. Matchmaking does not automatically implement that lifecycle. - RPC can also use an active socket; match-data opcodes are separate. Reconnect admission, snapshot delivery and duplicate-result handling are application obligations.
- Custom validation, not the platform name alone, constrains cheating. Component styling does not establish accessibility; Darkroom “no network” narration is narrower in the receipt, and its local version store is capped at 20 with deletion/storage-failure possibilities.
The backup’s six-domain ownership matrix (identity, discovery, rules, physics, outcomes/ranks, persistence), browser/server/private-database conveyor and authority/prediction/reconciliation glossary remain useful historical explanations. Correct the claims above before reusing them; never promote obsolete local navigation paths or sample endpoint/stylesheet choices to current deployment contracts.
No package.json, lockfile, Svelte components, Nakama runtime modules, Compose deployment, video files or independent gaming build/test/proof directory are supplied in this tree. Educational HTML exists, but the recommended Svelte/Nakama starter collection was not implemented by that research. Current dependency compatibility/security, complete gaming/media rights and public download routes remain unestablished.
What remains unverified
- Current signed-in prices, entitlements, quotas, live model roster, runtime payer and operation caps.
- Precise supported SDK contracts/versions, framework/version coverage, package-manager commands, SSR, or arbitrary backend support.
- Private infrastructure, database engine, transactions, anti-cheat, capacity/SLA, backup/restore policy, availability/support guarantees.
- Complete backend export, current complete export format, custom-domain guarantees, Git sync, and self-hosted service equivalence.
- Actual-app usability, WCAG conformance, performance, security, multiplayer correctness, and production readiness.
The September 6 research reports no account connected, app created or exercised, purchase, runtime AI invocation, or permission/multiplayer test. Its PRD likewise says no app was built or exercised. September 10 adds separate educational demonstrations and an attributed historical Darkroom receipt, not a reversal of those older limits or a newly verified application.
PRD’s external doctrine references leave the supplied corpus. They are identified by name in experience-and-acceptance > Experience principles, not linked to nonexistent wiki routes or treated as newly inspected sources. source-coverage records all included files and section destinations.