Sibling-Tool Switcher

A customer running two or three Orbital tools side by side — OrbitalReg plus Orbital/Lint and/or Orbital/Git — has no way to jump between them except a bookmark. The tool switcher adds a small dropdown to the wordmark in the top nav that links straight to whichever sibling tools an admin has configured.

Without any sibling tools configured, the wordmark renders exactly as it always has — a static "REG" suffix, no chevron, no layout shift. Configure at least one sibling and the suffix becomes a WAI-ARIA menu button: click (or Enter/Space) to open a menu listing OrbitalReg (the current tool, checked and non-interactive) followed by each enabled sibling.

This is a Commercial-tier feature (tool.switcher). See Requires a shared IdP below for why.

Configuring it

Admin → System → Tool switcher (/admin/tool-switcher) lists the two supported sibling keys, each with a default label:

Key	Default label
git	Orbital/Git
lint	Orbital/Lint

For each one, enable it, provide its base URL, and optionally override its label. The URL is validated server-side as well as in the UI:

• enabled=true requires a non-empty base_url.
• base_url must start with https:// — http:// is rejected (400 invalid_url). A tool switch must not downgrade to plaintext, and the browser would block the mixed content anyway.

The label field is a free-text override, useful under a custom brand where "Orbital/Git" or "Orbital/Lint" would look out of place next to your own logo. Leave it blank to keep the default label shown in the table above.

Saving issues one PATCH /api/admin/sibling-tools request per changed row and records an admin.sibling_tool.update audit event (actor + key + enabled + URL) for each one.

Configuration is deployment-global — unlike Orbital/Lint's per-org sibling-tools table, OrbitalReg is single-org-per-deployment, so there is one row per key, not one row per (org_id, key) pair.

Requires a shared IdP

The switcher does not carry a session across tools. If OrbitalReg and the sibling tool aren't wired to the same SAML identity provider, a user who clicks through lands on the sibling's own login screen. The admin page renders this as a callout, not a footnote — treat it as a prerequisite, not a nice-to-have, before turning the feature on.

What every user sees

GET /api/v1/tools is readable by any authenticated user (not just admins) and returns only the sibling tools that are both enabled and have an https:// base_url set:

[
  { "key": "lint", "label": "Orbital/Lint", "base_url": "https://lint.example.com" }
]

The frontend wordmark component polls this via SWR (revalidateOnFocus: false, 30s dedupe) and renders nothing extra until at least one tool comes back.

It survives a custom logo

An operator-uploaded logo (Admin → System → Branding, branding.logo_url) replaces the whole wordmark — there is no "REG" text left to suffix. The switcher does not disappear with it: with a logo set and at least one sibling tool enabled, it renders as a standalone icon-only button (chevron, aria-label="Switch tool") next to the logo instead of as a text suffix. With a logo set but no sibling tool enabled, nothing renders — there is nothing to switch to. Without a logo, the "REG" suffix behavior described above is unchanged.

License degrade is silent, not a 402

GET /api/v1/tools is deliberately not gated the same way the admin routes are. If the license lapses (trial expired, no commercial envelope applied), this endpoint keeps returning 200 with an empty array instead of 402 — the wordmark just goes back to the plain "REG" suffix. Erroring the entire top nav because a trial expired would be worse than quietly hiding one convenience feature. The admin config routes (GET/PATCH /api/admin/sibling-tools) still return 402 while the license is inactive, and the Admin UI disables the enable-toggle and URL inputs accordingly.

Wire format parity with Orbital/Lint

Orbital/Lint shipped this feature first (its own item, T295/T296) and OrbitalReg's port intentionally keeps the GET /api/v1/tools response shape ([{key, label, base_url}]) identical, so the frontend component can eventually be lifted into a shared package instead of diverging between products. Orbital/Lint's own ValidSiblingKeys already covers both git and reg, so no changes were needed on that side to link back to OrbitalReg.