Workspace
Rover Workspace is the owner control plane for Rover runtime launch, settings, and Rover Analytics. It keeps configuration and analytics in one persistent route shell on both supported Rover hosts.
Voice narration and Action Spotlight are explicit owner controls in both direct Workspace setup and managed Webflow onboarding: the Guided preset defaults guide flows to narration plus highlights, uses the SDK narrator with browser speech or entitled Rover narration audio, and gives visitors local Guidance and Voice & language controls for that site. Mascot audio remains a separate setting.
Routing model
Workspace uses nested section routes. The URL preserves the selected site and section while the shell stays mounted:
/rover/workspace/all/home/rover/workspace/new?flowId=…/rover/workspace/travel-demo-T3DkiA/journeys/rover/workspace/travel-demo-T3DkiA/deploy/workspace/travel-demo-T3DkiA/analyticsOld ?view= links redirect deterministically to these routes.
Information architecture
HomeActivation checklist, install health, the highest-priority next action, and recent changes.
JourneysJourney drafts, triggers, proactive rules, owner preview, rollout controls, and deterministic manual editing.
KnowledgeProduct knowledge, catalog content, Scout scans, and imports.
ActionsOwner actions, private agent tools, handoffs, validation, and security constraints.
AudienceVerified identity, personalization, visitor intelligence, and bounded account/site memory.
AppearanceTheme, mascot, spotlight, voice, narration, motion, and accessibility.
DeployInstall material, domain policy, verification, discovery artifacts, and site-scoped AI connections.
AnalyticsOverview, visits, trajectories, journey outcomes, reviews, interviews, discussions, and memory.
PlanUsage, credits, forecast, billing, site bindings, and AppSumo-specific guidance.
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.
Get Started from the Rover landing page to open Workspace on the current Rover host.Use another Google account.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 Rover Analytics by default. Shape presence and flow exposes the Experience preset, Action Spotlight default/color, voice narration, greeting, voice input, and presence controls.
- Settings is the returning-user control plane: Presence, Task Flow, Inputs & guardrails, Brand / Motion / Publish, and Rover Analytics. Experience / Motion owns the preset, Action Spotlight default/color, and voice narration, while Inputs & guardrails owns the off-by-default automatic page scrolling control.
- 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 narration, voice input, AI access, discovery, Action Spotlight default/color, 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 writes Rover's canonical siteConfig.experience contract as sparse overrides. Runtime defaults still own the minimized seed, centered stage, focus stream, and attachment-capable dock unless you override a field. Voice, captions, spotlight, and engagement kind are independent; explicit visitor voice-off always wins.
Guided action narration is emitted in-band as response-level roverPresentation by the same ACT or planner model response that chooses the tool/action. The shipped browser runtime consumes that presentation locally for captions, voice, and Action Spotlight; it does not make a separate narration-compose request and the presentation layer never changes tool argument schemas.
Saved journey, playbook, SDK, and URL engagementKind metadata is authoritative. For an untyped natural-language request, the first existing planner or ACT response supplies the canonical Demo, Onboarding, Support, or Task kind from live context. Share links use only ?rover_kind=demo|onboarding|support|task.
Runtime UX now keeps selected file attachments visible as removable chips in both the full panel and minimized bar. The conversation drawer is backed by Rover conversation metadata plus a transcript blob, so prior chats can be listed quickly and loaded lazily instead of disappearing when the widget resets.
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, the full A2WLinkheader, andllms.txt
The Rover Analytics 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 replace a site key, open install. That page keeps the required production path first and pushes generated testing and advanced discovery lower in the stack:
test or Live Test for Helper, Console, or Bookmarklet flows.rover-site.json first as the rich profile, agent-card.json next as the interop card, and the rest clearly marked optional.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.
Workspace keeps the full owner-readable pk_site_* install material available for authenticated owners whenever you reopen Install, Scripts, or Quick Test. Rotate only when you want to replace the key, or when a truly old legacy key never stored its public value.
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.
rover-site.json to /.well-known/rover-site.json.agent-card.json to /.well-known/agent-card.json. It includes POST A2W, chatbot GET, and A2W GET guidance.Link header or generated HTML discovery links so generic agents can find the interop card, docs, and A2W run endpoint.llms.txt stays supplemental but includes the same POST, GET, and A2W GET instructions.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
| Path | What Workspace provides | When to use it |
|---|---|---|
| Hosted Preview | Nothing. Rover makes the temporary preview for you. | Fast Rover-managed demos. |
| Preview Helper | Test config JSON. | Best multi-page desktop testing path. |
| Console | Test config JSON. | Quick current-page DevTools testing. |
| Bookmarklet | Test config JSON. | Drag-and-click current-page testing. |
| Production install | Install snippet. | Your real site, not arbitrary test targets. |
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, label, promptdescription, icon, routing, engagementKind, legacy engagementKind, enabled, orderengagementKind to explicitly select Demo, Onboarding, Support, or Task behavior. Voice is configured separately and visitor voice-off always wins.snake_case, but stay editable. Exact IDs are what deep links and A2W run calls use.Persisted shape
[
{
"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",
"engagementKind": "onboarding",
"enabled": true,
"order": 1
}
]Shortcut IDs in deep links and A2W runs
The exact saved journey ID is what Rover resolves at runtime. Launch & share provides three separate outputs: a browser link for visitors, a compact A2W GET link for URL-fetch chatbots, and a strict A2W POST payload for API agents.
https://example.com?rover_shortcut=get_startedhttps://example.com?rover_shortcut=get_started&rover_kind=onboardinghttps://agent.rtrvr.ai/v2/a2w/runs?url=https%3A%2F%2Fexample.com&shortcutId=get_started&engagementKind=onboarding{ "url": "https://example.com", "shortcutId": "get_started" }Use Workspace values in the SDK or helper
Workspace is the source of truth for Rover client setup. For the cleanest path:
- Create a Rover site key, or reuse an existing active one that already has the right domains and policy.
- Open
installand useCopy test config JSON. - Open Try on Other Sites or paste the same JSON into the Preview Helper yourself.
The JSON that Workspace exports is built from:
siteIdpublicKey(pk_site_*)- optional
siteKeyId allowedDomainsdomainScopeMode
From there you can either copy the generated production install snippet, or use the same JSON for the Rover website testing tool, the Preview Helper, and the SDK preview helpers.
Authentication model
Rover Analytics 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.
Rover Analytics notifications
Workspace stores Rover Analytics 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 analytics bot products.