Skip to main content

Reviews

The tenant dashboard is where the desktop surfaces your hosted tenant: its reviews, and — on a separate tab — the tenant's own registration state.

Reviews tab​

The tenant dashboard's Reviews tab lists every review for the signed-in tenant — status, source and target branch, and its Threads count — with a color badge that always carries a text label alongside it. The Threads cell reports how many of that review's threads are still open, so which reviews still have discussion is visible without opening anything: All resolved when none are, the count when some are, and Unknown when the count could not be read. Opening a review's detail refreshes its row, so the row and the dialog over it always report the same number. Open a row for that review's own detail: its recorded builds, its position in its target branch's merge queue, and its comment threads. Reply to an existing thread from there; the reply is attributed to you and, if the submit fails, your draft text stays put so you don't lose it. New review opens one without leaving the app: it names the environment it acts in, commits and pushes that environment's current branch as two steps you trigger yourself (skip the commit when the branch is already committed), then proposes it into a target branch offered from the ones your reviews already use. The same dialog also opens directly from an environment's diff panel — its own Start a review button prefills the environment and the target branch from what the diff panel is already showing, so nothing visible there needs retyping; push still stays a step you trigger, and a failed push names the reason and leaves the button ready to retry. If your account may not create reviews for that tenant, the dialog says so instead of only failing once you submit.

Reviewers​

A review's own detail carries a Reviewers section: everyone currently assigned, with Add reviewer and, on each assigned row, a remove action behind a confirm step. The picker offers the tenant's enrolled users the review does not already name, so you choose a reviewer by name instead of typing an id — the CLI and the MCP review_reviewers_* tools name the same assignment by userId instead. Both actions degrade the way the rest of the surface does: an account without the permission is told which access it is missing rather than being shown a button that fails on submit, and a review that already names everyone enrolled says so instead of opening an empty picker. Assigning a reviewer gates no status transition — it is what makes erun review list --waiting-on-me return that review for them. See Reviews § Author, reviewers, and discovery.

Reviewers​

A review's own detail carries a Reviewers section: everyone currently assigned, with Add reviewer and, on each assigned row, a remove action behind a confirm step. The picker offers the tenant's enrolled users the review does not already name, so you choose a reviewer by name instead of typing an id — the CLI and the MCP review_reviewers_* tools name the same assignment by userId instead. Both actions degrade the way the rest of the surface does: an account without the permission is told which access it is missing rather than being shown a button that fails on submit, and a review that already names everyone enrolled says so instead of opening an empty picker. Assigning a reviewer gates no status transition — it is what makes erun review list --waiting-on-me return that review for them. See Reviews § Author, reviewers, and discovery.

Merge queue and comment threads​

A review's own detail adds Close review, and the Merge queue tab an Advance queue action — each behind a confirm step, and each replaced by the access you are missing when your account may not use it. If the queue head still has unresolved comment threads, advancing is refused and names the count and the review, with View discussion to open it directly; an account with the separate override permission can instead bypass the check by stating a reason, which is recorded against your identity. Advancing is refused just as specifically while another review already holds that target branch's single MERGE slot — only one review may be at MERGE per branch — and the refusal names that review and its source branch so you can wait for it or free it with erun review requeue from the CLI, which has no button here yet. Only a thread's own root-comment author can resolve or reopen it — this dashboard included — so if that refusal names a thread you didn't open, ask its author or use the override rather than trying to close it yourself. To start a new comment thread rather than reply to one, hover a line in the review panel's diff and use the comment affordance that appears; the thread is anchored to that file and line. See erun review for the same actions from the CLI, and Merge queue for the full mechanics — including recovering a merge whose gate build gets stuck, which has no button here yet.

Gates tab​

The Gates tab answers, without you knowing any job id: what is being gated right now, and what recent gates decided — independent of whether the change gated is even one of this tenant's own reviews. Each row names the branch, the prospective merge commit actually tested, the target, and the verdict. A RUNNING row is being gated right now; an INCONCLUSIVE one is not a failure — it means the gate never reached a real verdict at all (a wrapper hitting its own timeout, or an environment fault), so it renders with its own distinct color rather than looking like a red build. A FAILED row names which step failed and, when available, where to read its output. See Merge queue for the full mechanics, and erun gate list for the same view from the CLI. The hosted console's own Gate runs section shows the identical queue for anyone without the desktop open.

Builds tab​

The Builds tab lists every recorded build for the tenant — not only the ones attached to a review. An ordinary erun build run reports itself here automatically (see erun build), so a row's Source column names either the review it gates or (for a build with no review) the environment it ran in, prefixed env:. See Builds for the full resource shape.

Keyboard shortcuts in the review surface​

The diff panel and a review's comment threads are fully keyboard-operable, not just mouse-driven. In the diff panel: ↓ / ↑ move to the next or previous hunk (crossing into the next file once you pass the last one), ] / [ jump straight to the next or previous changed file, and S starts a review for the environment section you're focused in. In a review's comment threads: ↓ / ↑ move between threads, R replies to the focused one, and Enter resolves or reopens it. A Keyboard shortcuts button — beside Refresh diff in the changed-files panel, and in the review detail dialog's own header — lists the same bindings without you needing to leave the keyboard to find them.

Getting the tenant dashboard connected​

Opening a tenant's dashboard resolves the same platform identity erun platform uses, and names exactly what is missing rather than one generic sign-in error: not connected offers a Connect field (prefilled with the tenant's likely address) that attaches the platform and signs you in in one step; not signed in offers Log in for the same device-code/browser flow erun cloud login runs; not enrolled — your sign-in succeeded but this tenant doesn't recognize you yet — shows the exact erun platform user enroll command an administrator needs, with a one-click copy, and a Try to enroll myself action for the rare case your account already has that access; and a plain permission refusal just names who to ask. Signing in successfully re-fetches the dashboard on its own — no Refresh click needed. The dashboard header also names the platform tenant its rows belong to, under the local tenant's own name: a local tenant is bound to a platform tenant only by whichever alias its credential reaches, so the two can differ. The line is shown whenever the platform reports a name — its absence means the platform reported none, not that the two tenants agree. When the platform names a different tenant than the one you opened, the dashboard loads none of that tenant's rows — its reviews, merge queue, users and audit are another tenant's, and the actions here (create a review, advance the merge queue, approve an invitation) would act on them under your tenant's heading. The card names both tenants and offers the route back: Connect this tenant to the platform that serves it, or open the dashboard for the local tenant the platform named. This is a refusal, not a permission error: the identity resolved and the platform answered, and what it answered with is not this tenant. A platform that reports no tenant name at all leaves nothing to compare, and its dashboard loads as it always did. The same alias also has its own home in Settings → Cloud aliases, alongside your AWS and Cloudflare aliases — an Add erun platform action there asks for the platform's API URL and connects and signs in the same way, so you can attach a hosted platform without opening a tenant dashboard first.

Registration tab​

The tenant dashboard's Registration tab is where a tenant/environment you created in the desktop gets its hosted counterpart — the local sidebar and the platform's own tenant/environment rows are separate objects, and this tab names that plainly and lists what is already registered on the platform. Cloud contexts: Preview context plan resolves the bootstrap plan before Register context creates anything for real. Hosted environments: Preview provisioning plan resolves quota, placement, namespace, and deploy order for a drafted environment before Register environment commits to it; each registered row then carries its own Deploy (with an optional version field), Stop, and Delete — Delete asks you to type the environment's name to confirm, the same as every other unrecoverable action in the app. Hitting your tenant's environment-count cap shows the platform's own message inline rather than a raw error, naming the fix (delete or stop another environment first) instead of just failing. Registering a new tenant, or enrolling its first user, still needs erun platform tenant create/erun platform user enroll from a terminal or the console — the tab explains this and does not attempt to half-configure it through a form. See Managing hosted environments for the same actions from the CLI.

Where next​