Workspace

Routing model

Workspace uses query-param navigation rather than nested routes. The default landing view is sites, and once you select a site the URL preserves both the selected site and current view:

This keeps deep links shareable inside the owner workspace without forcing a cross-domain Workspace hop.

Information architecture

Account model

Rover Workspace keeps one active Rover session per browser origin, but now remembers recent Rover accounts on that origin so switching is faster and less destructive.

Sites, Launch/Settings, Install, Quick Test, and analytics

The sites view is the operational control plane. It owns:

• site search, filtering, and pagination
• per-site key maintenance such as enable/disable, rotate, and allowed-domain edits
• site lifecycle actions such as opening Launch or Settings, opening Install or Quick Test, and deleting a site

The setup route is contextual:

• Guided Launch is the default first-run direct-install flow: Connect site, Shape presence and flow, then Review and test. Standard Rover is the recommended package and already includes RoverBook by default.
• Settings is the returning-user control plane: Presence, Task Flow, Inputs & guardrails, Brand / Motion / Publish, and RoverBook.
• Webflow Setup remains the managed onboarding flow for Webflow-owned installs, and now writes the same underlying Rover site-config contract as direct Workspace: business type, sparse Rover V3 experience overrides, greeting, voice, AI access, discovery, and page capture.

Both Guided Launch and Webflow review are now check-and-change surfaces. The review rows are clickable, and if you jump back to edit from review, Rover saves your changes and returns you to review instead of forcing you through the whole step sequence again.

Workspace now writes Rover V3's canonical siteConfig.experience contract as sparse overrides only. Runtime defaults still own the minimized seed/presence, centered stage shell, focus-stream step stack, and attachment-capable bottom dock unless you explicitly override a field.

The new install view owns generated outputs only:

• required production install snippet
• portable test config JSON for Helper, Console, Bookmarklet, and Live Test
• advanced AI discovery artifacts such as rover-site.json, agent-card.json, service-desc, and llms.txt

The RoverBook views remain read-only. They are powered by owner-authenticated Firestore reads, not public raw siteId GET routes.

Install and Quick Test views

After you create or rotate a site key, open install. That page keeps the required production path first and pushes generated testing and advanced discovery lower in the stack:

The separate test view is the Quick Test surface. Use it when you want Rover-managed previews, Helper handoff, console snippets, bookmarklets, or test-specific recovery actions without mixing those flows into production install copy.

If you do not see a visible pk_site_* value yet, rotate or create a key first. Workspace only reveals the full public key when it is issued, and that key is required for the install snippet and test config JSON.

If Live Test tells you This API key is missing capability: roverEmbed, the selected key is not embed-ready yet. Rotate or create an embed-enabled key first.

AI Discovery Outputs

AI discovery now lives behind the advanced section in install. Keep the ordering strict: required snippet first, generated rover-site.json next, generated agent-card.json after that, and only then optional support surfaces.

If you need stronger machine-readable discovery beyond the snippet, start with rover-site.json, then add agent-card.json. For the full decision tree, read AI Discovery.

Path matrix

Shortcut builder

Workspace now treats shortcuts as a builder-first configuration surface instead of a raw JSON textarea. The default editor is a structured builder with required fields up front and an optional advanced JSON mode for power users.

[
  {
    "id": "get_started",
    "label": "Get Started",
    "prompt": "Help me get started and guide me to the best next step.",
    "description": "Short first-run onboarding flow",
    "routing": "planner",
    "enabled": true,
    "order": 1
  }
]

Shortcut IDs in deep links and tasks

The exact saved shortcut ID is what Rover resolves at runtime. Once a site exists, Workspace can copy both a deep link and a public task payload for any saved shortcut.

Use Workspace values in the SDK or helper

Workspace is the source of truth for the open-source Rover clients. For the cleanest path:

1. Create or rotate a Rover site key.
2. Open install and use Copy test config JSON.
3. Open Try on Other Sites or paste the same JSON into the Preview Helper yourself.

The JSON that Workspace exports is built from:

• siteId
• publicKey (pk_site_*)
• optional siteKeyId
• allowedDomains
• domainScopeMode

From there you can either copy the generated production install snippet, or use the same JSON for the Rover website testing tool, the open-source Preview Helper, and the SDK preview helpers.

Authentication model

RoverBook site-tag writes still use signed Rover session auth from the embedded runtime. Workspace reads and settings use owner auth and are scoped to sites you own.

RoverBook notifications

Workspace stores RoverBook notification settings per site. These subscriptions are generic webhooks with event filters, auth, retries, payload presets, and optional HMAC signing.

Slack or Discord are treated as webhook destinations and payload formats rather than separate RoverBook bot products.