The Launch Lab is pipeline step 6 (Generate playable sandbox). The session composer exists today but produces a completely mocked experience — no real URL, no real launch, nothing playable. This proposal specifies the real implementation: a signed launch URL into the sandbox dispatch namespace, a live session event feed, a Deploy agent transcript, and session history as iterable evidence. It is the moment the game becomes something you can feel.
The current SandboxLaunchLab.tsx component contains a prominent warning that explicitly declares itself a prototype:
This is the component's own banner — it is not a planning document's assessment. The gap between "configured" and "actually playable" is where builds stall. A builder who completes all eight fields in the composer, clicks nothing, watches no real event — they have no felt sense of whether their configuration is right. The following code paths confirm the mock surface:
fakeSignature() function in SandboxLaunchLab.tsx computes an FNV-1a hash of the form-state string and appends .mock — e.g. a3f9c12e.mock. This is explicitly not cryptographic. The real requirement is a server-computed HMAC as documented in architecture.html#edge.
buildPreviewUrl() assembles a URL on https://sandbox-launch.mock.standout.games/launch — a domain that does not exist. The real URL shape is https://play.sandbox.standout.games/launch?session=<id>&sig=<hmac-hex>.
Transcript component generates hardcoded rows timed at +000ms through +103ms from local state — no real agent, no real deploy, no real round-trip measurement.
operator, player, currency, device, jurisdiction, walletBehavior, sessionExpiry) are populated from BUILDER_LAUNCH_LAB in apps/web/src/lib/builderMockData.ts — a static in-app object, not a real catalogue API.
The result: a builder finishes validation, reaches Launch Lab, sees a polished-looking form, fills it out, and receives a fake URL they cannot open and a fake transcript that does not reflect any real outcome. The gap between "configured" and "felt it play" is where builds stall, revisions lose momentum, and the quality of a session-based game is never verified before it reaches operator review.
Three mocks. The first (session composer) is GROUNDED — it mirrors the existing two-card layout from SandboxLaunchLab.tsx truthfully, with one clearly-badged CONCEPT delta added inside it. The second (live session panel) and third (deploy-agent transcript) are CONCEPT — the real implementations these mocks specify.
faults=WALLET_TIMEOUT in the launch parameters. The stub-wallet Worker fires the fault at the configured trigger point. See architecture.html#edge.
builderMockData.ts):
Operators: Operator Demo EU · Apollo Testbook · Maple Sandbox · Certification Lab Runner ·
Players: Maya Stone · casual · Dre Park · high balance · Iris Chen · bonus wallet · Noah Vale · low balance ·
Currencies: EUR · Euro, GBP · Pound sterling, CAD · Canadian dollar, SEK · Swedish krona, RON · Romanian leu ·
Devices: Mobile web · Desktop web · Tablet web ·
Jurisdictions: UK · Ontario · Malta · Sweden · Romania ·
Wallet behaviours: Normal approve/debit/credit · Bonus wallet first · Cash wallet only · Replay-only dry run ·
Session expiries: 2 minutes · 15 minutes · 60 minutes · 24 hours.
sandbox
·
Expires in 14 m 22 s
v0.7.4 → sandboxsandbox/crash-cartel/v0.7.4/bundle.gz · deployed to namespace sandbox
WALLET_TIMEOUT fault injected (as configured) → fault response confirmed
Five states cover the full interaction arc of the Launch Lab. With JavaScript enabled, use the tabs below to switch. With JavaScript disabled, all panels render stacked with their state labels — every panel starts with a visible label identifying which state it depicts.
v0.7.4 → namespace sandbox
WALLET_TIMEOUT and surfaces a "Service unavailable — your stake has been returned" message to the player frame. No debit is recorded. The session remains open; the builder can observe whether the game recovers gracefully or leaves the player in a broken state. This is the primary value of fault injection testing.
These are the files that need to change to implement this proposal. Paths are relative to the repo root on main. New platform pieces are marked "new — see architecture.html#edge".
| File / component | Change |
|---|---|
apps/web/src/components/builder/SandboxLaunchLab.tsx |
The composer goes real: buildPreviewUrl() is replaced by a call to the session signer API, which returns a real HMAC-signed URL (https://play.sandbox.standout.games/launch?session=…&sig=…). The mock-warning banner is removed. The Transcript component is replaced by a live session event feed (WebSocket or SSE). The iframe placeholder is replaced by a real embedded game frame. The fake fakeSignature() function is deleted.
|
apps/web/src/lib/builderMockData.ts |
The BUILDER_LAUNCH_LAB option lists (operators, players, currencies, devices, jurisdictions, walletBehaviors, sessionExpiries) move from a static in-app object to a real catalogue data source — either a /api/sandbox/catalogue endpoint or a typed constant fetched from the platform config. The mock object becomes the fallback for offline/dev only.
|
dispatch Worker |
new — see architecture.html#edge The Cloudflare dispatch Worker for the sandbox namespace: verifies the HMAC on every incoming launch request, routes to the correct game Worker version, and enforces session expiry (SESSION_STALE).
|
stub-wallet Worker |
new — see architecture.html#edge Implements the wallet API interface with configurable fault injection. Activated when a session is launched with a faults=… parameter. Fires WALLET_INSUFFICIENT_FUNDS, WALLET_TIMEOUT, WALLET_DUPLICATE_TXN, WALLET_ROLLBACK_FAILED, or SESSION_STALE at the configured trigger points.
|
session signer |
new — see architecture.html#edge A server-side service (Worker or D1-backed endpoint) that receives the session parameters from the composer, generates a cryptographic HMAC, and returns the signed launch URL. Replaces the client-side FNV-hash mock. |
SandboxLaunchLab.tsx retain their exact options — the values in builderMockData.ts are correct and complete. Only their data source moves from a static object to a real API. The two-card layout and the fault toggle UI remain unchanged.Today, step 5 (Run validation — see vision.html · step 5) ends with a pass/warn/fail report and an inert "Launch sandbox" button that produces no real outcome. After this proposal, that CTA is live. Step 7 (Iterate — see vision.html · step 7) gains session history as evidence for the next build version.
demo namespace share the same stub-wallet Worker as sandbox, or does an operator demo session require operator-shaped mock responses (e.g. the real operator's bet limits, currency config, and session rules, not the stub defaults)? If demos need operator-shaped mocks, the wallet fixture must be per-operator-config, not a single shared stub.
The Launch Lab's live session panel is the gateway into step 7 (Iterate). Once a builder has real session evidence — event logs, replay bundles, fault-path recordings — they have a basis for comparing build versions and making targeted configuration changes. The next proposal in this cadence is Proposal 05 · Iteration Loop, which covers pipeline step 7: version history, config diffs between builds, validation deltas, and how session evidence from the Launch Lab feeds the iteration decision loop.