Setup Assistant card (post-onboarding guided setup)

What it is

When a brand-new user finishes onboarding, Omniscio can leave them one optional inbox card offering a guided tour of setup. It is deliberately one-time and dismissible — an offer, not a gate — and it is the entry point to the Setup Assistant, a conversational walkthrough rather than a wizard.

Accepting it opens a fresh Ask Omniscio session, preloaded with the bundled setup-assistant super prompt. That session is where the guidance actually lives, and the ground it covers is:

• connecting an AI provider,
• adding API keys,
• integrations,
• automations,
• agent autonomy,
• backups.

The assistant never sees a raw API key. The card is a launcher; the session it opens talks the user through the provider and key steps without reading the secret itself.

Where to find it

It is not visible yet. The feature is in-development and its setting (onboardingSetupAssistantCardEnabled) defaults to off, so the card does not appear on a normal install. It is revealed through the Lab toggle for the onboarding-setup-assistant-card unreleased feature (or that feature's environment switch), and the toggle also gates the card's appearance for a user who has just completed onboarding.

How it behaves

The card

A one-time inbox card, offered after onboarding completes. It is a normal inbox alert with an action attached, so it carries the usual inbox behaviour — dismiss it and it is gone, and the one-time nature is the point: this is a first-run surface, not a recurring nudge.

The launch

Clicking the action invokes LAUNCH_SETUP_ASSISTANT. The main process — not the renderer — resolves the __ask_amc__ sentinel and reads the bundled super prompt, then creates a fresh Ask Omniscio session carrying it. The request only names the action; it cannot name a prompt or a project, so the card can never be pointed somewhere else.

The spawn is desktop-only, and the bridge enforces it. LAUNCH_SETUP_ASSISTANT sits in the BLOCKED list of the web/mobile WS bridge: a paired phone has no post-onboarding setup card, and must never spawn a desktop Ask Omniscio session over that bridge. The desktop IPC is unaffected — the refusal is scoped to the WS path (src/main/services/web/web-access-ws-channels.ts), and the renderer action degrades gracefully when the call is refused.

For agents

Key files

• The gate — onboarding-setup-assistant-card in src/shared/unreleased-features/ (setting onboardingSetupAssistantCardEnabled, default false).
• The card producer — src/main/services/onboarding/setup-assistant-card.ts, the reconciler that raises the one-time inbox card. Fire-once is ledgered by the reconciled-alert row (active OR archived), so no config marker is needed and it never re-surfaces after a launch or dismiss.
• The launch logic — src/main/services/onboarding/setup-assistant-launch.ts, which resolves the __ask_amc__ sentinel, reads the bundled prompt, and creates the session.
• The IPC — a thin LAUNCH_SETUP_ASSISTANT registration in src/main/ipc/setup-assistant-handlers.ts that calls the launch service and then records the setup_assistant / launched event (after the await, so a launch that threw records nothing).
• The card's action — declared in src/shared/alert-actions/types.ts and invoked from src/renderer/src/features/alerts/use-alert-actions.ts.
• The prompt — the bundled setup-assistant entry in resources/super-prompts.json.
• Telemetry — the setup_assistant feature-registry entry (src/shared/feature-registry/core.ts), status instrumented, with a single launched action. It is scoped to this one launch and is NOT the onboarding funnel: activation milestones are recorded separately through recordActivationMilestone.

Related

• onboarding-guardian.md — the onboarding flow this card follows.
• first-time-setup.md — the setup ground the assistant walks a new user through.