Skip to main content

The console

The console at https://app.orunbase.com is the human surface of Orunbase. It speaks the same public API as the SDK and CLI, and its URLs are scope-driven: everything inside a workspace lives under /orgs/{slug}/…, where {slug} is your workspace's URL slug.

Sign in and onboarding​

/login signs you in with an email code — Orunbase is passwordless. On your first login, a mandatory full-screen onboarding (/onboarding) has you name your organization, pick a plan, and choose a starting point — have an agent build a production baseline from a blueprint, import a Git repository, or start with a clean workspace; there is no org-less view, so you always land in a working workspace. Choosing a blueprint continues onboarding straight into that blueprint's guided flow. Create additional workspaces later at /orgs/new. See Authentication.

Overview — the front door​

/orgs/{slug} renders the Overview as the workspace landing; /orgs/{slug}/overview is its canonical address. It opens with two things and nothing else above them:

  • Onboard your agent to orun — a pill that hands you one sentence to paste into Claude Code, Codex, Cursor, or VS Code. The agent fetches the setup instructions, installs the CLI, signs you in, registers the MCP server for its own client, and reads the workspace before it touches anything. The prompt carries no credential — your agent authenticates as you. The by-hand path is Settings → MCP server.
  • The conditions, and the sections under them — see below. Search is not on this page any more: it is in the masthead, on every surface.

Below that, the workspace as it stands, in four sections:

  • The week's conditions — runs, success rate, headwinds, and the ready queue.
  • Initiatives — the initiatives with the most going on, drawn as the Initiatives plane draws them (health, status, byline, progress meter). Finished initiatives drop out; what waits on you comes first. The card opens the plane.
  • Activity — the latest changes, drawn as the Activities feed draws them (one row per change, with its phase ladder). Anything running is always shown, however busy the morning was.
  • Wants a look — services the catalog has flagged or found unowned.

Ask agent — the agent's only home​

There is no Agents page and no Agents rail row. The agent is a control, not a surface: Ask sits in the masthead (⌘I, or the sparkle in the top bar on a phone) and opens a panel beside whatever you are reading, so asking never costs you the page you are asking about. The panel starts below the band and the band never shortens, so the control that opened it is always where you left it. Old /orgs/{slug}/agents links — including every ?kind= tab the fleet once had — redirect to the Overview with the panel open.

The panel carries the conversation and nothing else. Its History browses every thread, session and routine the workspace has, with search and filters; expanding a thread opens it full-page at /orgs/{slug}/agents/chat/{chatId}, which is the same durable thread, not a copy. A session's own page (/orgs/{slug}/agents/{sessionId}) is reached from the work it is doing, from Activities, or from History. See Agents for the model behind all of it.

What a session runs as — the agent profiles — is workspace administration and lives in Settings → Agent profiles (/settings/agent-profiles), beside the AI providers keys that answer what it runs on. You never have to create one to get started: a workspace always has a default impl-default profile, bound to a platform-minted default-agent API key holding the builder role.

The masthead​

A 60px ink band across the top of every desktop surface, carrying the four controls that belong to the console rather than to any page:

  • The mark, back to your workspace's Overview.
  • The workspace selector — your account name, then the workspace inside it as a pill. Opening it lists every workspace you belong to, each with its own mark, plus View all workspaces… and Create workspace, which goes straight to the create form. It switches workspaces and does nothing else: this workspace's own settings are the Settings rail row, on every surface. On a phone the same list is at the head of the navigation drawer.
  • Search — one box over every resource in the workspace (pages, catalog entities, docs, people, teams, secret names). ⌘K focuses it from anywhere. Typed prefixes narrow it — ask:, catalog:, docs:, people:, teams:, secrets:. Anything the index cannot answer is a question: press Tab, or pick the Ask the agent row, and the question is sent — the panel opens on a new thread with your line already asked. (A question a page offers you — "Ask about this service" — still lands in the composer unsent, because you did not write it.)
  • Ask (⌘I) and your account — the avatar at the right edge, with profile, security, sessions, theme, and sign out. It is the only account menu; the rail carries none.

The workspace rail​

The rail holds navigation and the control that collapses it, and nothing else: search, Ask, the workspace switcher and your account are all in the masthead above (see The masthead).

The Workspace section holds the day-to-day product surfaces, in rail order:

  • Overview (/overview) — the front door above: agent onboarding, one search field, the workspace's conditions, and previews of Initiatives and Activity.
  • Catalog (/catalog) — the internal-developer-portal view of everything your platform intent declares: metric tiles, a filterable toolbar, and Table/Board/Map views over catalog entities, with a peek drawer and dedicated per-entity pages. Entities arrive from orun pushes — see the state plane overview.
  • Docs (/docs) — the org-wide catalog doc library: git-authored entity docs, browsed by kind and role, rendered by digest.
  • Activities (/activities) — the workspace-wide run feed, spanning every project and filterable by repo, environment, source, and status. Click a run to open its detail page.
  • Events (/events) — the raw event-bus explorer: a faceted stream with correlation stories.
  • Work (/work) — the work tracker: initiatives, epics with their milestone ladders, designs, boards, and a triage lane for agent-proposed changes. Every lifecycle value is derived from the coordination and observation logs with its evidence attached; there is no status dropdown anywhere. See Work and the planning hierarchy.
  • Teams (/teams) — create teams, manage membership, and grant roles at account, workspace, or project scope (Teams).
  • Integrations (/integrations) — the multi-provider connections hub, not just GitHub: every provider in the integration catalog, connected by OAuth or token paste. GitHub's Repo settings tab (/integrations/github?tab=repo-settings) is where repositories are governed: what the installation can see, and the git-repo allow-list — which repos may push state objects from OIDC CI. Adding a repo there onboards it and allow-lists it in one step; removing it revokes CI's push access.
  • Secrets (/secrets) — the dedicated secrets surface: the secret chain, rotation health, and policies at any scope. Defaults to all scopes — the whole workspace's secret population in one view (Secrets).
  • Config (/config) — typed settings with the override/shadow chain view (Settings and feature flags).
  • Feature flags (/flags) — flag rollout states and the evaluation previewer (Settings and feature flags).

Secrets, Config, and Feature flags sit together because they share one scope lattice — learn one and you know the others.

Repos​

There is no Git Repos rail row. Repositories are governed from Integrations → GitHub → Repo settings (above), and the repo list lives in Settings → Git repos (/settings/repos) — a repo page always was workspace administration, so it sits with the rest of it.

  • Settings → Git repos — the workspace's repos (a project == a repo), archive and restore archived repos (Projects and environments).
  • Selecting a repo opens a full-width page with horizontal tabs — Environments, Git, CLI, Storage, Config. Runs live on the org-level Activities feed.

Other doors to the same place: the repo switcher in the masthead (on every page, ending with "View all projects…") and the command palette (⌘K) — "Git Repos" and "Create repo".

The older URLs still resolve: /orgs/{slug}/projects/… and /orgs/{slug}/repos/… both redirect to /orgs/{slug}/settings/repos/….

Manage​

Pinned to the bottom of the rail:

  • Usage & quota (/usage) — metered consumption per metric key and window, remote-state storage, recent push volume, and recorded quota breaches. See Usage and quotas.
  • Workspace settings (/settings) — the workspace's administrative hub. Opening it replaces the rail: the product navigation slides out to the left and the settings navigation slides in from the right, in the same column. There is never a second navigation beside the first — the settings pages get the whole width for content (below). The ‹ at the head of the pane, or Esc from anywhere in it, returns you to the Overview.

Settings hub​

/orgs/{slug}/settings gathers workspace administration. Its navigation is the rail's second pane, not a column inside the page, so which pane the rail shows is simply where you are: a deep link into a settings page opens with the settings navigation already in place, and the back button takes you out of it. Each page names itself once, in the content column, under a WORKSPACE SETTINGS eyebrow. On a phone the rail is a drawer and cannot carry the pane, so the grouped settings navigator stays on the page itself.

The landing page carries the workspace's logo, its name and slug, and its three identifiers — the durable Workspace ID (ws_…), the legacy id (org_…), and the mutable slug — each with a copy button (see Vocabulary). A picked logo is cropped square, scaled to 128px and saved on the spot; without one the workspace keeps its initials mark (the workspace logo). Its sections include:

  • Members / Invitations — list members, manage role assignments, invite by email, track and revoke pending invitations (Members and invitations).
  • API keys — create and revoke service-principal keys; the secret is shown once at creation (API keys).
  • Agent profiles — the identities agent sessions run as (agent type, harness, model, owner, autonomy) with their track records and promotion suggestions (Agents).
  • Billing — plan, subscription, and entitlements, with an embedded checkout (Plans and entitlements, Checkout and portal).
  • Audit — the workspace's immutable audit log with the same filters the API exposes; requires audit.read (Audit log).
  • Webhooks — endpoints, subscriptions, per-endpoint delivery history (Webhooks overview).
  • Access — your effective permissions in this workspace, with provenance (RBAC).
  • Notifications — your email notification preferences for this workspace (Email notifications).
  • CLI sessions — the Orun CLI devices connected to your account, with revoke controls (CLI and CI auth).

CLI device approval​

Two pages complete the orun CLI's login flows (see CLI and CI auth):

  • /cli/approve?grant=… — the browser-loopback flow: orun auth login opens this page, and you approve or deny the single-use grant for "Orun CLI on <host>".
  • /cli/device — the headless flow: orun auth login --device prints a short code; enter it here to authorize that device.

Account and security​

  • /account — your profile (your identity across every workspace) and session controls, including sign-out.
  • /account/security — your account security event history: sign-ins, session changes, and other security events as they happen. See the security model.