Notifications, Status & UX Patterns

Alert model & inbox (app-notifications.jsx)

A single content model drives both in-app alerts and the notification inbox. Five canonical alert types (ALERT_TYPES):

Inbox panel opens from the SVG bell in the top nav: grouped, "mark all read", deep-links to the related case/entity/source/session. A type filter row (All / Unread / Session / Merge / Entity / Source / Case). Seed alerts are project-keyed and include the Spire onboarding merge-review item ("Incoming 'NORD STAR' scored 0.71 against VESSEL-1180 — confirm merge or keep separate").

/settings/notifications is the rule editor backing this model (see 08-settings-and-admin.md). Doctrine Q6: injects flow into this same model — there is no standalone inject queue in the live product.

---

The status / toast system (app-toast.jsx)

A global, theme-aware notification system so every meaningful action confirms success or failure (UX best practice). A single <ToastHost/> is mounted in App; any component fires window.toast.{success|error|warn|info|loading}(title, detail, opts) — no prop-drilling — via a insigz:toast CustomEvent.

Each toast: icon, title, optional detail line, optional action link ({action, route} deep-links and dismisses), manual ✕ close, slide-in animation, stack capped at the latest few. Position: top-right on desktop (below the nav), bottom full-width on mobile; zIndex 4000 (above modals).

Wired across the platform (representative, not exhaustive): account save / password / session-revoke; security posture configure + support-access revoke; team invite/save/remove; notification rule create/edit/delete; Ontology Agent Steward approval ("Source committed"); report draft-save + PDF export; case/report creation; Workshop save/delete; API key create/rotate/revoke; org new/switch/settings; connector add; billing upgrade/change; audit export; project invite; new-session guidance. Grounded chat answers still stream normally; only navigational/confirmation actions use toasts.

---

Dead-end-closure pattern (how "every button does something" was achieved)

The prototype was swept repeatedly for controls with no handler. Each was closed with the lightest best-practice affordance:

• List actions (OPEN / INSPECT / VIEW / EDIT) → navigate to a real detail view (/sessions/:id, /sources/:id, /reports/:id).
• Configure / manage (security posture, MFA, team member) → an adaptive modal or inline disclosure with a SAVE that toasts.
• Create (invite, new rule, new key, draft report, new case) → a form modal or a confirming toast.
• Destructive (revoke, remove, delete) → a warn toast (and state change where applicable).
• Export / async (PDF, CSV) → an info/loading toast. The principle: no silent buttons — a click always produces navigation, a modal, or a status toast.

---

Responsive & accessibility patterns

• App top nav — the OverflowNav (measure-and-collapse-to-MORE) on desktop/tablet; a hamburger drawer below the mobile breakpoint.
• Marketing top nav — a JS-injected hamburger (subpage.js) below 880px across all 18 pages + the standalone homepage; the Docs page collapses its 3-column layout into a "Browse docs" disclosure below 1100px.
• Onboarding wizard — two panes stack with an AGENT/ARTIFACT toggle on mobile; stepper scrolls.
• Chat — right panel (desktop) ↔ bottom sheet (mobile), both resizable; the floating launcher bubble bottom-right.
• Accessibility — 2px focus rings at 3:1 contrast, prefers-reduced-motion kills ambient animation, 44px minimum touch targets, skip-to-content link, SVG icons (not emoji) in app chrome.
• D/E/L/E view-state previews — list surfaces carry a Default/Empty/Loading/Error toggle that swaps in <EmptyState>/<SkeletonTable>/<ErrorState> for design review (these are intentional preview affordances, not dead buttons).