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

Workspace keeps one active session per browser origin, but remembers recent 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 analytics by default. Shape presence and flow exposes the Experience preset, Action Spotlight default/color, voice narration, greeting, voice input, and presence controls.
• Settingsis the returning-user control plane: Presence, Task Flow, Inputs & guardrails, Brand / Motion / Publish, and 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 writes the same underlying site-config contract as direct Workspace: business type, sparse Dayside 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 check-and-change surfaces. The review rows are clickable, and if you jump back to edit from review, Dayside saves your changes and returns you to review instead of forcing you through the whole step sequence again.

Workspace writes Dayside 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. New direct and Webflow installs explicitly include ui.experience.experienceMode, ui.experience.audio.narration, ui.experience.motion.actionSpotlightRunKinds, ui.experience.motion.actionSpotlightColor, and pageConfig.disableAutoScroll: true so generated scripts show guide-flow narration, highlighting, and scroll-off behavior clearly.

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.

Presentation mode is resolved once when the run starts. Shortcut launches use the saved shortcut runKind, explicit launch/query metadata wins over heuristics, and raw ?rover=prompts only become guided when they read like demos, tours, onboarding, sign-ups, trials, or "show me how" flows. Marketing or share links can force the guided experience on any prompt or shortcut by appending &rover_guide=1 to the URL.

Runtime UX keeps selected file attachments visible as removable chips in both the full panel and minimized bar. The conversation drawer is backed by conversation metadata plus a transcript blob, so prior chats can be listed quickly and loaded lazily instead of disappearing when the widget resets.

The 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 A2W Link header, and llms.txt

The 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:

The separate test view is the Quick Test surface. Use it when you want 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 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 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",
    "runKind": "guide",
    "enabled": true,
    "order": 1
  }
]

Shortcut IDs in deep links and A2W runs

The exact saved shortcut ID is what Dayside resolves at runtime. Once a site exists, Workspace can copy a dual-mode browser deep link with rover_exec, a cloud executor URL for chatbots, and an A2W run payload for any saved shortcut.

Use Workspace values in the SDK or helper

Workspace is the source of truth for Dayside client setup. For the cleanest path:

1. Create a site key, or reuse an existing active one that already has the right domains and policy.
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 website testing tool, the Preview Helper, and the SDK preview helpers.

Authentication model

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

Analytics notifications

Workspace stores 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.

Related docs