Standout Builder Studio · planning Index / Flow / 03 · Package Checklist draft Updated 12 Jun 2026

Proposal 03 · Package Checklist

This proposal covers pipeline steps 2 and 4 — packaging concerns (Define the game package; Attach assets & theme). Today the manifest, assets, operator copy, and jurisdiction state required to assemble a complete game package live in separate tabs inside GameWorkspace.tsx, with no unified view of what remains outstanding for sandbox access versus full handoff. This stub captures the problem, sketches one wireframe, and lists the open questions that must be resolved before a full proposal can be written.

1 Choose build path 2 Define the game package 3 Configure mechanics 4 Attach assets & theme 5 Run validation 6 Generate playable sandbox 7 Iterate 8 Promote toward handoff

Draft stub — structure and problem statement only.

Copy the full-depth anatomy of Proposal 01 / Proposal 04 when writing this proposal.

User problem

The workspace for a game build in apps/web/src/components/builder/GameWorkspace.tsx exposes manifest metadata, asset uploads, and reviewer notes as three separate tabs — Manifest, Assets, and Reviewer Notes — with no aggregate signal about what is still missing. A builder who wants to know whether the game is ready for sandbox access must click between tabs and mentally tally what is complete, what is absent, and what is blocked on a third party (e.g. jurisdiction approval).

The mock data in apps/web/src/lib/builderMockData.ts tracks submissionState strings per build, but there is no UI that translates these strings into a gate-by-gate checklist or distinguishes between items required for sandbox access and items required only at handoff. A builder advancing from step 2 to step 4 — from defining the package to attaching assets — has no single view that shows their progress across both steps simultaneously.

Proposed UI

The workspace gains a Package Checklist panel — a checklist grouped by gate family (Manifest, Assets, Copy & localisation, Jurisdictions) with two gate columns: Sandbox (required before a playable is generated) and Handoff (required before the build can be promoted to an operator or certification body).

Package Checklist — gate-family rows with sandbox vs handoff columns CONCEPT · proposed

Item

Sandbox

Handoff

Manifest

Game title & slug

✓ done

RTP target declared

✓ done

Jurisdiction scope set

— optional

✗ required

Assets 2 missing for sandbox

Game icon (512 × 512)

✗ missing

Thumbnail (16:9)

✗ missing

Background & theme sprite sheet

— optional

✗ required

Copy & localisation

Operator-facing description (EN)

✓ done

Additional locale strings

— n/a

— if applicable

Jurisdictions

Jurisdiction matrix confirmed

— optional

✗ required

Sandbox: 2 items missing | Handoff: 4 items missing

State variants

State variants to be designed in the full proposal

early (mostly missing) — most checklist items are absent; sandbox CTA disabled; handoff column entirely red; no progress indicators yet meaningful.
sandbox-ready — all sandbox-required items are complete; sandbox CTA becomes active; handoff column still has outstanding items shown in amber/red.
handoff-ready — all items in both columns complete; a "Ready for promotion" banner replaces the outstanding-items summary; no blocking items remain.
blocked — one or more items are in a blocked state (e.g. awaiting jurisdiction approval from a third party); blocked items show a distinct chip with an owner label and no resolution action available to the builder.

Affected current files

File	Change
`apps/web/src/components/builder/GameWorkspace.tsx`	Add a Package Checklist panel alongside (or replacing) the existing Manifest / Assets / Reviewer Notes tab set; the panel aggregates state from all three tabs into a single gate-family checklist view with sandbox vs handoff columns.
`apps/web/src/lib/builderMockData.ts`	The `submissionState` string and the versions arrays must be extended (or supplemented) with per-item gate status so the checklist can accurately reflect which items are complete, missing, or blocked — rather than deriving state from a single top-level string.

What changes in the build flow

Today a builder navigates between three separate tabs to mentally reconstruct package completeness; after this proposal they have a single checklist surface that makes sandbox readiness and handoff readiness immediately visible, with the sandbox CTA gated directly on checklist completion so the relationship between assembling the package and generating a playable is explicit.

Open questions

Decisions needed before implementation

Who owns jurisdiction matrix data? The jurisdiction scope for a game (which regulated markets it targets) is needed to determine what the handoff column requires, but today no source of truth for this exists in the codebase — it lives only as free-text notes. Deciding whether jurisdiction data is a builder-entered field, an operator-driven configuration, or sourced from a shared registry determines the checklist's completeness signal for that gate family.
How do uploads attach to checklist items? The wireframe shows asset items (icon, thumbnail, sprite sheet) with missing/done states, but the current assets tab in GameWorkspace.tsx renders upload slots independently of any gate model. The proposal needs to decide whether uploads write directly to checklist item state, or whether a separate validation step confirms an uploaded file meets the required spec (dimensions, format, file size) before marking the item done.

What to tackle next

Once the open questions above are resolved, the checklist gate model can be specced in full. The next proposal in this reading order is Proposal 04 · Launch Lab, which covers pipeline step 6 (Generate playable sandbox): composing the sandbox session, selecting scenario parameters, and generating the signed-URL playable that the Package Checklist's sandbox CTA feeds into.