R — this page explains the supplied execution guidance. It is not a prototype plan for Simp, an active task list, or a record of actions already performed. The source PLAN.md is a condensed reusable checklist derived from CHEATSHEET.md; its checkboxes do not establish completed work.
The quickstart’s four stages summarize a creator’s workflow: one audience and three success checks; the smallest supported build; visitor and failure checks; then the creator publishes the tested revision. Its footer explicitly leaves app checks to the reader. The filename does not prove an image provider; no generation manifest is supplied for this WebP. See artifact-atlas > Quickstart illustration.
Scope before implementation
The PRD asks a future builder to record six inputs before work begins:
- The intended visitor.
- The useful result.
- The input → action → visible result → repeat/reset loop.
- The selected scope and a reason for every capability admitted.
- The permitted data and operations.
- Three observable success cases.
These inputs belong to the next actual experience. The corpus deliberately does not invent a game, audience, or record schema. Choose scopes on the outcome, not on a poster’s feature count.
Start and establish access
Choose a blank project, a close-fitting template, or a remix. Inspect the existing behavior and preserve supported patterns before requesting a change. Declare the permitted assets and capabilities, and rule out unrelated features and unnecessary image/audio generation.
D: the sources distinguish the current model picker from Build/hammer → Connect ChatGPT. The July 2026 setup describes Free/Plus/Pro accounts and notes that enabling device-code authorization for Codex in ChatGPT Security and login may be required, followed by a fresh sign-in. Codes last 15 minutes in that documented setup.
R: only enter a code for a connection you initiated, never a code someone sends you. Do not place credentials in project code. Check the actual route, connected account, displayed costs, and limits; connecting ChatGPT does not fund every visitor operation. See costs-and-rights > Choose the bill before the build and the official setup.
Implement the smallest complete loop
R: build input, action, useful result, and repeat/reset before decorative or unrelated features. Include readable labels, keyboard/touch operation, honest empty/loading/error states, and user-controlled audio. Reuse existing behavior and consolidate genuine duplicates without breaking working features.
Assign each state a home using state-and-trust > Choose a state lifetime. Then add runtime AI, persistence, or multiplayer separately only when admitted by scopes > Capability admission. For each addition, name its data, allowed operations, failure behavior, and relevant conflicts before moving on. Managed built-ins are preferable when they satisfy the required contract, not simply because they exist.
Improve and recover
Use @filename or @asset to target the responsible area, and use Tweaks for exposed parameters. Say what must change and what must remain. The source’s efficiency order is reuse assets → tweak values → targeted edits → a stronger model for a specific hard problem → a major refactor only when necessary. Never trigger AI generation from a render loop.
When repairs repeatedly fail, reproduce the error, return to a working revision, and change the prompt or model rather than layering speculative fixes. D: /clear starts fresh agent context without touching files. It is neither rollback nor database reset. The guide warns that Refactor may effectively rewrite the project.
For community contributions, review before accepting a suggestion or Merge, integrate one change, and replay the original loop. The ideas/voting board does not make a winning suggestion authoritative or safe. D: View Data can delete records and ban posters, and the guide says bans delete the poster’s entries; establish consequences and recovery before using it.
Evidence: guide and August update. The trust implications are in state-and-trust.
Reusable prompt contracts
These are source-derived specifications, not assurances that generated code complies. Bracketed fields below are deliberate template inputs, not missing Simp implementation.
First build
Build [one useful experience] for [audience].
Core loop: [input] -> [action] -> [visible result] -> [restart].
Success checks: [three observable outcomes].
Use the simplest supported implementation and preserve the existing stack.
Support touch, keyboard, readable labels, and reachable loading/empty/error states.
Use only [listed assets and capabilities]; no unrelated image/audio generation.
Do not simulate success or invent APIs. Complete the core before decoration.Add persistence securely
Persist [required records and fields]; keep [temporary state] transient.
Define guest reads, user-owned changes, specific moderator powers, and owner actions.
Deny unspecified operations at the trusted data boundary, not only in the UI.
Show denied or failed writes honestly. Do not claim saved before confirmation.
Exercise owner, another user, and signed-out access separately.
Use current supported APIs and identify unsupported requirements.Repair without a rewrite
Start from revision [version]. Reproduce [steps].
Expected: [result]. Actual: [result or exact error].
Change the responsible behavior only; preserve [invariants].
Target @filename where applicable and explain cause and changed files.
Replay the failing scenario and the original loop; report what remains untested.One reusable change contract
The condensed PLAN.md combines those patterns: state the audience/outcome/revision; define the loop and three observable checks; name files/assets/capabilities and preserved behavior; classify state as temporary/local/shared/durable; state who may do what; handle empty/error/limited responses and duplicate costly actions; keep implementation small; and report untested requirements. It expressly forbids invented APIs, simulated success, and unrun checks reported as passed.
Shipping is a decision, not a poster label
The source ship gate covers the actual visitor loop, access, narrow screens and input modes, AI failures, data recovery, permissions, multiplayer, safe content, and revision recovery. experience-and-acceptance > Release questions and its A1–A12 table preserve those requirements in detail.
R: once applicable scenarios succeed and failures are resolved, the creator chooses the tested revision, intended visibility, and default version; posts it; and opens the share link as a visitor. Visitors receive the link, not responsibility for the release pipeline. Code rollback is separate from data restoration. Mark an unused capability N/A with a reason, never “passed.”
Critical use needs verified operational controls; a successful demo is insufficient. If an exit is needed, costs-and-rights > Stay or migrate explains supported export, replacement dependencies, and data migration. Stop when the named outcome is complete; a larger scope alone is not a reason to expand.
Source basis: CHEATSHEET.md start-to-ship steps, three prompt sections, efficiency advice and ship gate; PLAN.md request, five numbered workflow sections and reusable prompt; PRD.md sections 3 and 8; quickstart artwork. source-coverage maps the exact sections.
Independent setup without a universal install list
September 10 extends the workflow to a locally developed Websim-style app. Its recommended base is Svelte 5/SvelteKit/TypeScript/Vite with Tailwind 4 and daisyUI 5. The source recipe uses the minimal TypeScript Svelte CLI template with the Tailwind add-on, then installs daisyUI as a development dependency. Those commands are documented instructions, not commands run for this foundation.
Register the daisyUI plugin in the stylesheet the Tailwind add-on already initialized. The source notes layout.css in current Svelte CLI guidance and src/app.css in a daisyUI example; the filename is not the contract. Do not create competing stylesheets to copy an example literally.
Select Bits UI for justified complex interaction, Three plus Threlte core for 3D, Svelte Flow for node editing, Pixi for 2D rendering, Phaser for game systems, or mdsvex for needed Markdown authoring. This is a menu, not an instruction to install everything. Preserve compatible scaffold choices, Three/types alignment, and the lockfile; evidence-and-limits > September 10 package snapshot retains the dated peer/version evidence.
A static-only experience can use SvelteKit’s static adapter; request-time logic and private keys require an appropriate server or separately secured backend. Initialize browser-only graphics locally rather than disabling SSR across the application preemptively. This is a deployment decision rule, not evidence that a service is deployed.
Build with AI without making AI the product
The newer OMP brief keeps one complete interaction, one state owner, native controls first, daisyUI appearance, and one justified specialist. OMP stays outside the app runtime. Accounts, databases, multiplayer, runtime AI, plugins, and orchestration need explicit requirements. Secrets remain server-side, reset and failure states stay truthful, and changed paths must be exercised on actual target input/device modes.
The recommended development loop is define → implement → run → inspect → fix observed failure → save a known-good revision. Parallel development can help independent work; it is not a reason to embed an agent broker in a browser toy.
The Darkroom illustrates streaming and local version lineage using prerecorded HTML. It compares completion-only, every-chunk, and lexical-checkpoint rendering; its 250ms checkpoint throttle is demonstration code, not behavioral correctness or a latency guarantee. Cancellation keeps the last rendered preview. Local save/read-back and comparison teach recovery, but bounded local history is not a shared backup service. state-and-trust > Generated applications introduce a new boundary explains the security distinction.
Lifecycle belongs in the useful-loop contract
For a spatial interaction, the source’s future smoke scenario is load a scene, act on one object, change a property through DOM controls, reset, leave and return without duplicate resources, then check the target mobile device. Graphics/audio initialization and teardown, keyboard/touch behavior, storage failure, another identity’s permissions, and the selected production/deployment route all require real exercise before a starter claim. Source existence, a screenshot, and a historical Darkroom receipt do not satisfy those new obligations.