feat: new-user onboarding overhaul + realtime-signal & mobile fixes

.changeset/ai-ask-operator-chips.md

@@ -0,0 +1,17 @@
+---
+"@checkstack/ai-backend": minor
+"@checkstack/ai-frontend": minor
+---
+
+feat(ai): clickable answer options in chat (askOperator)
+
+Add an `askOperator` tool the assistant calls to ask a question with clickable
+answer chips (plus an optional free-text box) instead of a plaintext list.
+Clicking a chip sends that answer as the operator's next message. The chat
+renders the chips from a `__question` tool-output card, mirroring the existing
+confirm-card pattern, and calling the tool ends the turn (the operator's choice
+arrives as their next message).
+
+The system prompt now steers the model to use `askOperator` for discrete-choice
+clarifications (which system, which protocol, how often, which environment),
+reserving prose questions for free-form values like a URL.

.changeset/ai-onboarding-playbook.md

@@ -0,0 +1,12 @@
+---
+"@checkstack/ai-backend": minor
+---
+
+feat(ai): add an onboarding playbook to the chat assistant
+
+When a monitoring-setup tool is in scope this turn (creating a system, proposing
+a health check, or managing environments), the chat system prompt now injects an
+onboarding section that steers the model to prefer the HTTP strategy for a URL,
+ask before guessing, create-and-assign a check in one step, and use environments
+instead of cloning a system per deployment stage. Like the automation playbook,
+it stays out of the always-on prompt on pure read turns.

.changeset/catalog-environment-ai-tools.md

@@ -0,0 +1,11 @@
+---
+"@checkstack/catalog-backend": minor
+---
+
+feat(catalog): AI tools for environments
+
+Add `catalog.createEnvironment` and `catalog.setSystemEnvironments` AI tools plus
+a `catalog.listEnvironments` read projection, so the assistant can model
+one-system-many-environments instead of suggesting a separate system per
+environment. The `catalog.createSystem` tool description now teaches the 1-1
+system/check pairing and points to environments for modelling dev/staging/prod.

.changeset/catalog-realtime-signal.md

@@ -0,0 +1,19 @@
+---
+"@checkstack/catalog-common": minor
+"@checkstack/catalog-backend": minor
+---
+
+fix(catalog): emit a realtime signal on catalog mutations so clients refresh
+
+Catalog was the only domain plugin that never broadcast a realtime signal, so
+any out-of-band write - the AI assistant (which mutates on the backend, with no
+frontend mutation to invalidate), GitOps reconcile, or another pod/user - left
+every other client's catalog cache stale until a hard reload. Most visibly, a
+system created via the assistant 404'd on the catalog detail page (which
+resolves a system by finding it in the cached `getSystems` list) until reload.
+
+Add a `CATALOG_CHANGED` signal (`catalog.changed`) and broadcast it from every
+catalog mutation (system, group, environment CRUD and membership changes). The
+frontend signal auto-invalidator refreshes the `[[catalog]]` react-query cache
+on every connected client, so out-of-band catalog changes now appear without a
+reload.

.changeset/common-environments-doc-slug.md

@@ -0,0 +1,9 @@
+---
+"@checkstack/common": minor
+---
+
+feat(common): add the environments docs slug to APP_DOC_SLUGS
+
+Expose `APP_DOC_SLUGS.environments` so in-app deep links can point to the
+Environments concept page (used by the onboarding wizard's environments hint).
+Guarded by the existing docs-links contract test.

.changeset/frontend-first-check-wizard.md

@@ -0,0 +1,18 @@
+---
+"@checkstack/healthcheck-frontend": minor
+"@checkstack/catalog-frontend": minor
+---
+
+feat(frontend): guided "create your first check" wizard and onboarding nudges
+
+Add a `FirstCheckWizard`, reachable both from the Health Checks empty state and
+an always-available "Quick start" header button: the user picks a system (a new
+one or an existing one), pastes a URL, and the wizard creates the HTTP health
+check and the assignment (started immediately) in one guided flow, built on the
+new `@checkstack/ui` Stepper. This makes guided setup usable when onboarding into
+an instance that already has systems and checks, not only on first run.
+
+Also add two in-product nudges: an inline "one system, many environments" hint
+on the Create System form (so new users stop cloning a system per stage), and a
+clear "what an assignment is and why a check needs one" explainer on the
+assignment screen's empty state.

.changeset/healthcheck-config-changed-signal.md

@@ -0,0 +1,17 @@
+---
+"@checkstack/healthcheck-common": minor
+"@checkstack/healthcheck-backend": minor
+---
+
+fix(healthcheck): emit a realtime signal on config/assignment changes
+
+The health-check executor broadcasts run/status signals, but config and
+assignment CRUD (create/update/delete/pause/resume, associate/disassociate,
+create-and-assign) emitted nothing - so a check created or edited out-of-band
+(the AI assistant, GitOps, another pod/user) did not appear in an open Health
+Checks list until the first run fired a status signal, up to an interval later.
+
+Add a `HEALTHCHECK_CONFIG_CHANGED` (`healthcheck.config.changed`) signal,
+broadcast from every config/assignment mutation, so the frontend signal
+auto-invalidator refreshes the `[[healthcheck]]` cache on every connected client
+immediately.

.changeset/healthcheck-create-and-assign.md

@@ -0,0 +1,19 @@
+---
+"@checkstack/healthcheck-common": minor
+"@checkstack/healthcheck-backend": minor
+---
+
+feat(healthcheck): atomically create and assign a health check in one step
+
+Add a `createAndAssign` RPC that creates a health-check configuration and
+assigns it to a system in a single transaction, so the common "one system, one
+check" case can never leave a dormant, unassigned check that runs nothing. When
+the assignment is enabled it is scheduled immediately, exactly like
+`associateSystem`.
+
+The AI `healthcheck.propose` tool now prefers the HTTP strategy for a URL
+(instead of authoring a script health check) and, when given `assignToSystemId`,
+creates, assigns, and starts the check in the same approval.
+
+Also fixes a latent bug where the `associateSystem` handler silently dropped the
+per-assignment `notificationPolicy` before it reached the database.

.changeset/mobile-nav-layout.md

@@ -0,0 +1,16 @@
+---
+"@checkstack/ui": minor
+"@checkstack/frontend": minor
+---
+
+fix(mobile): make the nav drawer fully scrollable and de-clutter the navbar
+
+The mobile navigation drawer (`Sheet`) spanned the layout viewport
+(`inset-y-0 ... h-full`), so on a phone its bottom - and the last menu items -
+sat behind the browser URL bar and could not be reached. The sheet is now bound
+to the dynamic viewport (`h-[100dvh]`, top-anchored), so it ends at the visible
+bottom and scrolls to the last item.
+
+The "Checkstack" wordmark in the navbar is now hidden below the `sm` breakpoint
+(the logo still anchors the home link), freeing space on the cramped mobile
+navbar.

.changeset/ui-stepper.md

@@ -0,0 +1,11 @@
+---
+"@checkstack/ui": minor
+---
+
+feat(ui): add a Stepper primitive
+
+Add a presentational `Stepper` step-indicator component and a `useStepper` state
+hook for building guided multi-step flows (used by the new "create your first
+check" onboarding wizard). Completed steps are navigable; the active step is
+highlighted; future steps are muted. Animations are disabled on low-power
+devices via `usePerformance`.