Console overview
You signed in at console.extension.dev and want to know where everything is. This page is the map: every route the console answers, and the lifecycle those routes carry a project through.
The shape
The console has two layers. Global routes belong to you; everything else belongs to a workspace.
| Route | What it does |
|---|---|
/ | Sends you to your workspace. Signed out, it sends you to the home page, which carries you back here once you sign in |
/new | Create a project from a template. Answered by www.extension.dev/new |
/import | Connect a repository you already have. Answered by www.extension.dev/import |
/templates | Browse the template catalog. Answered by templates.extension.dev |
/shares | Every preview link you have minted, live and dead |
The middle three are addresses the console hands off: type them at console.extension.dev and you land on the surface that owns them, which is why the address bar changes.
A workspace answers at /<workspace>. Its settings live at /<workspace>/settings in six sections: workspace, members, connections, plan, usage, and danger. Each one is its own address at /<workspace>/settings/<section>. plan prints what the plan allows beside what the workspace has spent; usage prints what those builds cost.
A project
A project lives at /<workspace>/<repo> under a five-tab strip:
| Tab | Contents |
|---|---|
| Overview | The manifest, configured browsers, and current state |
| Activity | What happened, in order |
| Builds | One row per build, one artifact per browser |
| Releases | Builds promoted to a channel |
| Stores | Store connections and submissions |
Each tab is a path. Overview is the project root, so the other four hang off it as /activity, /builds, /releases, and /stores.
A build opens at /builds/<buildId> and drills to one browser's artifact at /builds/<buildId>/<browser>. Releases list at /releases, mint at /releases/new, and open at /releases/<releaseId>. Stores list at /stores, a new store connection starts at /stores/new, a store opens at /stores/<store>, its submissions list at /stores/<store>/submissions, a new submission starts at /stores/<store>/submissions/new, and one submission opens at /stores/<store>/submissions/<submissionId>. Store credentials live in project settings, under stores.
A project you just connected also has /onboard, the setup pass the console walks you through once.
Project settings are a dialog with its own address: /<workspace>/<repo>/settings/<section>. Every section is linkable, so you can send a teammate straight to the one that matters. The sections you get today: general, team, environment, build, deployment, github, channels, stores, visibility, access-tokens, and danger. /<workspace>/<repo>/settings on its own redirects to general, and closing the dialog returns you to the project overview.
visibility is the one that decides who can open this project's builds. It offers public and private, there is no unlisted, and only workspace owners and admins may change it. The section states what the change costs before you confirm it, and it warns you when the setting saved but the registry did not accept it, because nothing retries that on its own.
This matters when you mint a share link, because visibility is what decides whether the link carries a token. See Publish from the CLI or an agent and Public project pages.
The lifecycle
Every project moves through the same four verbs.
Connect. /import links a repository, or /new creates one from a template. The console reads the manifest and configures a build per declared browser.
Build. Push a commit. The project builds one artifact per browser and records it under Builds. Open /builds/<buildId>/<browser> for the artifact, its logs, and its integrity hash.
Promote. A build the team agrees on becomes a release at /releases/new, bound to a channel. Channels are configured in project settings under channels.
The release then opens at /releases/<releaseId>, where the release id is the channel name. The page carries the channel's current build and the timeline of what entered the channel and when. A rollback control sits in that header, and it appears only once the channel has an earlier build to return to, so it is absent after a channel's first promotion. See Releases.
Submit. A released build goes to the stores from the Stores tab. Each submission is tracked at /stores/<store>/submissions/<submissionId> until the store answers. Credentials are held by the project under project settings, stores, never by your machine.
When it fails
- A workspace route 404s: you are signed in to an account that is not a member. Check
/<workspace>/settingsunder members from an account that is. - A push builds nothing: the GitHub connection lapsed. Reconnect under project settings, github.
- A release page shows no rollback control: the channel has nothing behind its current build. See Releases.
- A submission sits in review: that wait belongs to the store. The submission page shows the last state the store reported.
- A submission reads Unknown: the run ended without a state we could read from the store. It is not a submission that succeeded. Open the run and read the failure, see Publishing.
- A stranger cannot open a build page you expected to be public: the project is not declared public, or the registry has not refreshed yet. Check Project settings, Visibility, see Public project pages.
Next
- Promote gates for every refusal a cap can name
- Access tokens to drive these routes from CI
- Share an unpublished build for review when a build needs eyes before it needs a release