Seven screens,
one argument
ExoGP3 works, but it was built function-first: nine nav items, sixteen routes, each one a table of a noun. This is a proposal for what it should be instead. Start with the architecture document — it makes the case — then look at the seven screens built from it. The look was chosen from ten explorations of the landing page; now that it is settled, those studies have been retired and everything here is in the direction that won.
Start here
The proposal · read before the screensEvery screen below assumes the architecture in this document. It is the only item here that is a document rather than a screen, so it scrolls.
The architecture,
and the ten flows that matter
Nine nav items collapse to five places and one action layer — argued from the write surface that already exists rather than from taste. The API cannot write at all, so every change settles through one of three paths, and two of them are shapes a conventional form cannot express.
- The three write paths — server-persisted, player-signed, and co-signed
- A tier diagram: open surface → places → chat → proposals → contracts
- All sixteen routes mapped individually, with the test used on each
- Ten flows ranked by consequence of failure, each step tagged with its cost
- Five open questions, each with a recommendation
The screens
Seven · built in the chosen directionNot style studies. Each is a working screen with real data and one collapsed type system — Anton for page identity, Inter Tight for anything you read, IBM Plex Mono only for figures that align down a column. Every one fits a single viewport with no scrolling, a constraint that shaped them heavily.
On Air
Watchable with no wallet, no account and no install — the live race is the product's own best advertisement. Minting is a call to action here rather than a nav item.
Pilot detail
The pilot beside a full-height conversation. Standing orders read as prose rather than a settings panel, which matters because talking is the only way they can change.
The Card
Every race you could enter, with eligibility as columns instead of prose — what you qualify for and what bars you. One ledger stays aligned down the entire list.
Proposal cards — all eight
Everything the pilot can propose, from one template: race entry, loadout, pack, repair, recycle, clone, stud listing, fabricate. Real odds, fees and discounts read from the contracts.
Race result
The five things a race moved, with every owed thing bound to its own button and its own signature count. Ends in the debrief, so you ask about the race with the race still on screen.
Shop
Shown in its exhausted state, because that is the state that justifies it existing: chat is metered, so a chat-only storefront could never sell you compute. Real pack odds, real open fee, and the unbuyable pack listed anyway so its odds stay public.
Inventory
Gear you are not wearing, packs you have not opened, scrap, and money the vault still owes you. Select several pieces and the rail prices the batch — including how much the chosen mechanic's craftsmanship saves, and the ceiling loss a repair costs you anyway.
How to read these
Known limits, stated up frontEvery screen except this index is designed for a single wide viewport and does not reflow to a phone. Mobile is genuinely unexplored, not merely unfinished — it is open question five in the architecture document.
The pilot screen embeds the real renderer from a dev server on :5173. A deployed copy
cannot reach it, so it shows the canonical CDN render instead and the toggle says so. The still is
the same asset the game itself uses.
A frame that looks dark or muddy is just the moment it caught — reload for another. The race data around it is real: real tracks, playlists, bands and pool splits.
Every current pilot wears the identical Genesis starter suit, so the renders look alike. That is the state of the asset set, not the design.
These are static HTML. Buttons do not transact and no wallet is ever requested. The numbers are real values, read from a snapshot rather than live.