Standout Builder Studio · planning Index reviewUpdated 13 Jun 2026

Builder Studio: from idea to playable on the edge

A user can choose a game type or variant path, configure the mechanics, attach the minimum viable package inputs, validate blockers, and launch a playable sandbox session — with background agents doing the engineering work and humans approving at gates. The target end-state is little to no engineering engagement per game.

How to read this suite

Start with the big picture and work inward: read The walkthrough for the canonical 8-step flow, then open the Mind map to see every direction the studio can grow, then study Architecture for the edge-delivery and agent workforce decisions, then ground it in reality with Variant → Live and see where models do the work in the Generative AI map, then play the journey as four clickable build scenarios and compare three UI treatments per screen, before working through the flow proposals one by one — the first and fourth are full-depth exemplars — and finish with the worked examples for concrete end-to-end traces with real game data — then the roadmap sequences what happens next.

Every page in the suite

Page	Status	Summary
Start here (you are here)	review	Purpose of the suite, reading order, status table, honesty rule, proposal cadence.
The walkthrough	review	The 8-step build flow, step by step, with inline mocks and what exists today vs proposed.
Mind map	review	Every direction the studio can go, collapsible and filterable, deep-linking into the suite.
Architecture	review	Edge delivery on Workers for Platforms, the agent workforce, and the data model.
Variant → Live	review	The reality deep-dive: every component between a saved spec and a live game, today on GCP — scaffold CLI, manual gaps, deploy pipeline, launch runtime, and what to change.
Generative AI map	review	Every point where a model acts in game creation — inputs, outputs, owning agent, autonomy level — plus the creative cluster, guardrails, and UI surfacing.
Journey simulator	review	Play the guided flow end-to-end as four build scenarios — a reskin, a tune that hits the math gate, an import that forks, and a new game that waits on the engineer merge. Click through all eight steps and feel the gates bite.
UI variants	review	Three UI treatments for each key surface — path picker, mechanics config, validation — side by side with trade-offs and a recommendation, so the interface direction is chosen deliberately.
01 · Build Path Picker	review	Full-depth exemplar: five path cards, state variants, high-fidelity mock, affected files, open questions.
02 · Mechanic Setup	draft	Mechanic-specific config panels, inherited-variant diffs, live RTP/volatility notes — awaiting full proposal.
03 · Package Checklist	draft	Asset and input checklist with sandbox vs operator-handoff thresholds — awaiting full proposal.
04 · Launch Lab	review	Full-depth exemplar: composer → real signed URL → live session panel → Deploy agent transcript.
05 · Iteration Loop	draft	Version history, config diff between builds, validation delta, sandbox session history — awaiting full proposal.
06 · Promote / Handoff	draft	Promotion gates from prototype through to certification package — awaiting full proposal.
Mechanics library	review	Mechanic record schema, taxonomy, and full entries for the three real mechanics plus two proposed.
Example · Reskin	review	Crash → "Neon Heist" traced end to end: fastest path, all green validation, time-to-playable measured.
Example · Variant	review	Config-only Trunk Raider variant with Math-Sim RTP delta report and math-owner approval gate.
Example · Import	review	Screenshot + PDF info sheet → Info-Sheet agent extraction → mechanics matching → prefilled spec.
Roadmap	review	Five phases from today's pipeline to zero-engineering — dependencies, decision gates, exit criteria, and what to do literally next.
Glossary	review	Every term the suite uses, defined once for external Game Builders, each linked to the page where it does its real work.

The honesty rule

Every mock in this suite carries one of two badges so you always know which world you are looking at. GROUNDED · matches main means the mock recreates a screen that already exists on the main branch — pixel-faithful to what the dashboard actually shows today. CONCEPT · proposed means the mock proposes new UI that does not exist yet. Concepts are welcome and encouraged; they just must be clearly labelled so readers never mistake a proposal for the current state of the product.

The proposal cadence

Each proposal improves exactly one step of the canonical 8-step flow. A complete proposal must include all of the following:

User problem — what friction or gap exists in that step today.
Proposed UI — what the new screen or interaction looks like (mock required).
Affected current files — the exact source files in apps/ or packages/ that would change.
Mock — a GROUNDED or CONCEPT badge inline HTML mock using standout.css.
What changes in the build flow — how the step's inputs, outputs, or agent actions differ.
Open questions — unresolved decisions or blockers that need a human answer.
What to tackle next — the natural follow-on proposal or action.

flow/01 · Build Path Picker and flow/04 · Launch Lab are the two full-depth exemplars — copy their structure for subsequent proposals. The four draft pages (02, 03, 05, 06) each hold the user problem and step role already; they are awaiting their turn in the daily cadence to be elevated to full depth.

Branch & process notes

This suite lives on branch planning-html. The docs/superpowers/ directory holds the process specification, implementation plan, and task files that drive the authoring work; it is deliberately not linked from anywhere in the suite itself and is not intended for external readers.