The artwork carries two kinds of knowledge: an overview of public capabilities and recommendations about which capabilities to leave out. The JSON files are content/provenance manifests, not application configuration, API schemas, runtime telemetry, or execution receipts.

The explanation below covers every record field. For exact original values, use the full-stack JSON record and the scoped JSON record. Both are preserved as readable, formatted JSON attachments; this page is their human-facing interpretation.

Five images, five roles

Original filenameExplanatory homeMeaning and provenance boundary
websim-quickstart-poster-astra.webpworkflowFour-stage creator workflow; no supplied generation manifest; provider/model unknown
websim-full-stack-poster-grok.pngplatformPublic capability inventory without edges; full-stack record attributes generation to xAI/Grok
scope-1-play-now.pngscope-1-play-nowOne local visitor loop, three declared edges; scoped record supplies provenance
scope-2-keep-what-matters.pngscope-2-keep-what-mattersTemporary draft, permission gate, required records; two declared edges
scope-3-play-together.pngscope-3-play-togetherTwo visitors sharing a project through two bidirectional links; persistence and AI remain conditional

Each image is embedded with meaningful alternative text and an explanatory caption in its home page, not merely linked as an unexplained file. Scope pages provide text equivalents of the question, decision, nodes, edge semantics, conditional capabilities, short ship checks, and stop conditions. Bitmaps alone do not establish accessible UI or WCAG conformance.

Quickstart illustration

The WebP reads “One useful loop. From idea to verified release.” It depicts scope → build → verify → publish, with feedback → review → improve returning toward scope. Scope names one audience, one interaction, and three checks. Build preserves the existing stack, targets @filename, and treats AI/data/multiplayer as optional. Verify replays the loop, distinguishes owner/user/guest, and checks errors/reconnects. Publish chooses the tested revision and visibility, then opens the link as a visitor.

The three cautions separate build usage from runtime AI funding, project/link visibility from upload privacy, and /clear context reset from file recovery. Its footer attributes the content to PLAN.md, dates the research 2026-09-06, and says application checks are the reader’s to run. “Astra” in a filename is not enough to name the generation provider, model, request route, or reviewer. No supplied JSON covers that history.

Full-stack record

websim-full-stack-poster.json identifies its title as “WEBSIM: THE FULL STACK,” its source as CHEATSHEET.md, date as 2026-09-06, image as websim-full-stack-poster-grok.png, and scope as a grouped public capability inventory, not proprietary deployment topology. The image footer also names PLAN.md; the record’s narrower source value is preserved rather than silently rewritten.

Record fieldReadable meaning
title, source, scope, date, imageIdentity, provenance, knowledge boundary, dated context, and the exact asset relationship described above
requestedProvideropenai-codex: what was requested, not what actually generated the file
actualProvider, actualModelxai, grok-imagine-image: generation identity reported by the record
zonesFive named conceptual groups, expanded below
edgesEmpty array: no arrows or implied verified connections
layoutDecisionInventory without arrows so grouping does not masquerade as network/trust topology
verificationSource-reported inspection of the final labels/zones, lack of arrows, local-state position and boundaries; records rejection of an earlier corrupt-text/incorrect-arrow draft
constraintsFour boundaries: local state belongs in the browser; identity is not authorization; build usage is separate from runtime funding; no invented framework/engine/cloud/SDK/backend-export guarantee

Five zones

Zone name in JSONLayers and their purpose
CREATOR WORKSPACECoding AI/Build agent, files/framework, assets, history/collaboration: how the creator changes a project
VISITOR BROWSERFrontend UI, runtime integration, optional local state: where the visitor interacts
MANAGED CAPABILITIESRuntime AI, identity/metadata, live multiplayer, persistent data, moderation: distinct possible dependencies, not compulsory defaults
PUBLISH AND COMMUNITYHosting/discovery: how work reaches visitors and receives feedback
BOUNDARIESPortability and unknown private infrastructure: what the inventory cannot establish

platform explains every layer and the relevant evidence. The record’s visual-inspection statement remains attributed history, not this wiki’s independent runtime proof.

Scoped record

scoped-posters.json is titled “Websim: the smallest sufficient stack,” dated 2026-09-06, and names CHEATSHEET.md, PLAN.md, and PRD.md as its sources. Its kind explicitly says these are conceptual design recommendations, not deployed architecture or tested applications.

Provenance and inspection fields

FieldRecorded value or interpretation
imageProvenance.requestedProvideropenai-codex
imageProvenance.actualProvider / actualModelxai / grok-imagine-image
imageProvenance.format / dimensionsPNG, 2496 × 1664 pixels
imageProvenance.methodGenerated images with corrective image edits; actual provider reported by the tool, not inferred from the request
verification.methodSource reports individual final-image inspection for title, copy, node identity, arrow direction, and scope boundaries
verification.acceptedEdgeCountsS1: 3; S2: 2; S3: 2
verification.scope3CopyDecisionRedundant “Presence + live state” caption omitted to retain the safety-complete render; sync links already express live sharing
verification.limitsNot tested applications, a network topology, accessibility certification, or independent review

Six global rules

  1. The scopes are alternatives, not a mandatory upgrade roadmap; each can be final.
  2. AI is independently optional in every scope; services are not automatically inherited.
  3. The creator publishes tested revisions; visitors in diagrams show use, not publishing ownership.
  4. The outcome gets one visual accent, neutral supporting information, and proximity rather than enclosing boxes everywhere.
  5. The artwork palette is illustration styling, not a hardcoded implemented theme.
  6. No invented framework, SDK, database engine, cloud service, or capacity guarantee.

Anatomy of each scope record

JSON fieldWhat a reader learnsExplanatory location
id, title, filenameStable S1/S2/S3 identity, visible title, and corresponding imageIndividual scope page and asset table above
question, decisionWhy to choose the scope and when to stop adding capabilityscopes and each scope’s opening sections
compositionVisual grouping: one browser; draft versus records through access; two browsers around a shared projectEach image caption and scope explanation
nodes, edgesExact conceptual endpoints, direction/kind, and labelsEach scope’s “Declared nodes and edges” table
copyPoster text: outcome, scope exclusions, safety caveats, conditional AI/persistence, ship check, date and conceptual labelScope-page text equivalents; exact wording retained in the JSON attachment
checksSource artwork acceptance criteria, not app execution resultsEach scope’s edge explanation and scope boundary notes

S1 has solid INPUT → ACTION → RESULT and a dotted RESULT → INPUT “try again” return. S2 has BROWSER DRAFT → CHECK ACCESS “request” and CHECK ACCESS → SAVED RECORDS “allowed only.” S3 has VISITOR A ↔ SHARED PROJECT and VISITOR B ↔ SHARED PROJECT, both “sync”; no direct visitor-to-visitor edge. These describe meaning, not an asserted network implementation.

September 10 local demonstration inventory

The newer corpus is separate from the five September 6 illustrations above. STARTER_CORPUS_MAP.yaml inventories the read-only source tree /home/loca/dev/simp-research-starter/websim-starter: 168 physical files / 34,800,940 bytes, including ignored dist artifacts. Its 101 image files comprise 42 PNG, 3 JPG, 4 WebP and 52 SVG; there are 9 MP3 files. Embedded media slots and repeated references do not increase those totals. Paths below are relative to that read-only tree, not public download URLs.

Artifact familyInventory and readable meaning
Educational HTMLWebsim-Stax.html is the Darkroom recorded-generation demonstrator, built in plain HTML/CSS/JavaScript, not a live model or Svelte runtime. Gaming-Stax.html teaches browser/Nakama responsibilities with a local referee simulation, not a server connection. GamingStax_full-txt.bkp.html preserves a text-rich ownership matrix and glossary with corrections described in evidence-and-limits.
Source and assemblyEight files under websim-stax/src/: index.html, theme.css, and js/{engine.mjs,sandbox.js,playground.js,story.js,player.js,main.js} cover the shell, styling, replay/checkpoints, sandbox, local versions/RoomHub, chapter state, narration and boot wiring. websim-stax/build.mjs assembles source, media, vendor notices and embedded build/source-hash manifests into Websim-Stax.html.
Recorded generationswebsim-stax/recordings/{pomodoro,snake,tictactoe}/ each contains meta.json, v1.html and v2.html: six replay HTML files plus three metadata records. Follow-ups add a dark progress ring, score/restart, and turn/online display respectively. These are stored text generations, not videos or arbitrary-prompt generation proof.
Narrationwebsim-stax/narration/chapters.json contains eight chapters/transcripts. websim-stax/media/narration.mp3 is the full track; media/clips/ holds eight chapter MP3s. media/cues.json supplies chapter timings; media/provenance.json reports Iris narration, 165.288 seconds for the full track, dates and digests. Sentence highlighting is approximate, not word-aligned transcription; no fresh playback or hash check is claimed.
Darkroom artworkwebsim-stax/media/art/ holds four artwork identities, each as original PNG and WebP derivative: hero-darkroom, tray, drying-line, contact-sheet. Provenance records prompts, alt descriptions, dimensions and hashes, attributing generation to xAI / grok-imagine-image; eight files do not mean eight independent illustrations.
Historical proof imageswebsim-stax/dist/proof/ contains 41 images: 24 chapter PNGs = eight chapters × viewport-width labels 1440/390/320; 12 free-play PNGs = empty/streaming/compare/together × those widths; final-desktop.png, final-mobile.png; and three contact-{1440,390,320}.jpg boards. These are inventoried historical Darkroom captures, not newly inspected pixels or gaming evidence.
Other proof artifactswebsim-stax/verification.json, websim-stax/test/engine.test.mjs, websim-stax/dist/proof/blueprint.json and print.pdf preserve an earlier receipt, test source, audit report and print artifact. websim-stax/dist/audit-projection.html strips inline audio/image payloads for static audit; it is not the media-complete deliverable. See evidence-and-limits > September 10 historical receipts and corrections.

Gaming media remain embedded: Gaming-Stax.html has eight MP3/transcript slots (script#chapter-data and script#media-provenance) and four WebP artwork slots (script#art-data): arena-2d, arena-3d, referee, vault. Its reported openai-codex / gpt-5.5 values identify tool routing, not an independently identified underlying image model. Darkroom embeds one full-track MP3 and four WebPs from its disk media. None of these embedded slots are additional physical files.

Chapter knowledge, not runtime receipts

The two eight-part tours extend the same workflow, state and trust themes used throughout this foundation:

Darkroom chapter (Websim-Stax.html, ws-tour)Gaming Stax scene (Gaming-Stax.html, story-stage)
Ask: separate a proposed server-held provider secret from a replay requiring no provider.Build: OMP develops; DOM UI and graphics remain distinct browser responsibilities.
Stream: show incremental text, cancellation and failures; upstream billing/cancellation remains provider-specific.Choose: Phaser 2D or Three.js/Threlte 3D; admit specialists only for a real need.
Develop: compare completion-only, every-chunk and lexical checkpoints; the demo’s 250 ms throttle is no correctness guarantee.Send: SDK HTTPS/WSS carries intentions, not trusted outcomes or direct database writes.
Safelight: opaque-origin script-only frames, CSP and source-checked messages illustrate isolation, not universal egress prevention.Decide: custom trusted rules validate actions and reconcile client predictions.
Fix: content-derived local version IDs and save read-back do not establish shared durable storage.Remember: accounts, matchmaking, parties, friends, chat, storage and leaderboards are platform capabilities; rules/result writes remain application work.
Reprint: parent-child versions, compare and remix explain lineage; bounded/deletable history is not permanent archival storage.Reconnect: restore transport, admit rejoining presence, send authoritative state and avoid duplicate rewards.
Together: same-page RoomHub models ordering, presence and latest-state restoration, not remote authentication or anti-cheat.Separate: Nakama’s embedded TypeScript VM is not Node/browser; keep secrets server-side and use dedicated simulation when required.
Ship: deliberately test/select a revision before future publication; the supplied demo is not a deployed builder.Start small: two players, one mode, one node; authenticate/join/play/reconnect/record before economy or clans.

Third-party vendor attribution

websim-stax/vendor/ contains 24 daisyUI CSS files, 52 Lucide SVGs, two LICENSE files and combined LICENSES.txt (79 files total). These are third-party components, not our authored research artwork. The 52 icons account for every disk SVG in the inventory.

  • daisyUI 5.7.32: MIT, Copyright (c) 2020 Pouya Saadeghi; retain websim-stax/vendor/daisyui/LICENSE and the complete copyright/permission notice in copied or embedded CSS.
  • lucide-static 1.43.0: ISC plus MIT terms for listed Feather-derived icons; Copyright (c) 2026 Lucide Icons and Contributors and Copyright (c) 2013-present Cole Bemis. Preserve all of websim-stax/vendor/lucide/LICENSE, including the Feather list and MIT section, not merely a brand credit.
  • Preserve websim-stax/vendor/LICENSES.txt and embedded notices in any later copies/extractions. The build source combines notices and retains CSS license banners; no build was run here. This Darkroom inventory does not establish all embedded gaming vendor versions or rights, and software licenses do not clear unrelated narration/generated-art rights.

Source-preserving copy strategy

The ten supplied September 6 root files remain the original foundation corpus; the September 10 tree named above is a separate read-only source. Wiki pages live under the repository’s content/ directory. The five foundation images are copied without re-encoding to content/assets/ using their original filenames; both JSON records are copied without rewriting to content/records/. All pages are at the content root, so embeds use assets/<filename> and record links use records/<filename>, not paths outside the published content tree.

The copies are publication assets, not new independent sources. If an original changes later, its corresponding copy and explanatory mapping must change together; no automatic synchronization is claimed. Original Markdown is synthesized into pages rather than exposed as raw duplicate routes. See source-coverage for the complete mapping and evidence-and-limits for the original package-inspection boundary.

The newer HTML/media inventory does not imply public copies or download routes exist. Host-local paths identify provenance only; old file:///Users/mbp/... links are not website navigation. No source HTML is executed in this wiki’s origin, and no historical screenshot, manifest or audio file is promoted to fresh runtime proof.