- Register keyboard shortcuts with
useHotkey/useHotkeySequencefrom@tanstack/react-hotkeys. Do not hand-rollwindow.addEventListener("keydown", ...)handlers. Use theignoreInputsoption to skip shortcuts while typing in inputs/textareas/contenteditable instead of checkinge.target.tagNamemanually. - Wrap async user actions (anything with pending/loading/error state) in
@tanstack/react-queryuseMutation; drive UI withmutation.isPending/mutation.mutate(). Do not hand-roll auseStateloading flag with try/catch/setState. - Derive state during render instead of syncing it with
useEffect. Do not useuseEffectfor derived state or as a general escape hatch. If you believe an effect is genuinely unavoidable and cannot find another option, stop and ask the user for guidance before adding one. - The frontend build embedded into
rivet-enginemust usepnpm build:engine/npx turbo build:engine -F @rivetkit/engine-frontend, which setsBASE_URL=/ui/. Do not compensate for a root/assets/*build by adding root asset routes to the engine; fix the embedded build base instead. - The dashboard serves multiple deployment flavors (cloud / OSS / enterprise) from one build via
features.*. Test frontend changes in more than one flavor before calling them done. OSS especially, since it disablesauth/platform/acland takes different code paths (context switcher, sidebar, onboarding, data providers) that the cloud default never exercises. Switch flavors in the browser console withlocalStorage.setItem("FEATURE_FLAGS", "")(OSS) /localStorage.removeItem("FEATURE_FLAGS")then reload. See Feature flags. - OSS and platform (cloud/EE) layouts must not visually diverge. The same screens take different code paths per flavor (engine vs cloud routes/data providers), but they should look the same. Known parallel pairs that must be kept in sync: the namespace landing (engine src/app/engine-namespace-landing.tsx vs cloud src/app/actors-grid.tsx, sharing
ActorBuildCard/ActorGridCardSkeleton) and the namespace settings drawer (one flavor-aware src/app/settings-drawer.tsx where engine shows only the Namespace section). When you change one side of a pair, mirror the other, and prefer sharing the presentational component over duplicating markup. - Engine and cloud namespace index routes both render the Actor-grid landing when no Actor name (
n) is selected; do not auto-redirect into the first build/actor. Selecting a build setsnand shows the Actor list/detail. - Ship a Ladle story alongside any new UI component, but only when the story would teach something a reader can't see from the component's source or the design system's existing stories. Run with
pnpm dev:ladlefromfrontend/. Existing example: src/app/runner-pool-error-popover.stories.tsx.- Story the integration unit, not the wrapper. If a component is a thin wrapper over a primitive (e.g. a
<Badge>with three label variants), do not write a story for it — story the parent that combines it with other state. The interesting states live where data shapes interact: row + cell + tooltip, form + validation + submit. A trivial wrapper's "three near-identical renders" is noise, not coverage. - Drive stories from realistic data fixtures, not prop permutations. Build fixtures that mirror real API responses (empty result, single item, multi-region, partial failure, mixed kinds). Each story should answer "what does this look like when the backend returns X?" Listing every prop combination produces stories that pass design review but miss bugs like an empty endpoint set falling through to "Multiple endpoints".
- Cover the states that produced real bugs in this component. When you fix a visual bug, the regression case becomes a story. If you can't articulate a state that would change behavior, you don't need another story.
- Skip the story if it would require mocking route loaders, auth, or the full data-provider stack. Either refactor the component to accept its inputs as props (preferred — the story falls out for free), or test it through the parent route in the running dashboard. Do not stub
useLoaderData/useRouteContextinside a story; that path rots fast.
- Story the integration unit, not the wrapper. If a component is a thin wrapper over a primitive (e.g. a
- HTTP responses can be mocked end-to-end in dev via MSW. Append
?mock=1to any dashboard URL (dev only, gated byimport.meta.env.DEVin src/lib/agent-mocks.ts) to boot the worker. Then in DevTools / agent-browser console:window.__rivetMock("*/actors/:id/kv/keys/*", { status: 503, body: { group: "guard", code: "service_unavailable", message: "..." } }). Mocks persist across reloads via sessionStorage;window.__rivetClearMocks()resets. Use this to exercise error UIs without standing up real engine state. Prod bundle is unaffected (dynamicimport("msw/browser")behind the dev gate). To inspect a loading skeleton, adddelayMsto hold the response open and keep the query pending:window.__rivetMock("*/actors/names", { status: 200, body: { names: {} }, delayMs: 10000 }).