Changelog

Server requests use the signed Session snapshot for up to 60 seconds, avoiding one session statement on a todo.list cache hit. In the local scenario B measurement, median call latency was 199 ms before and 177 ms after. Revocation on another device can take up to a minute for ordinary data. Membership removal remains immediate. Webhook endpoint changes and OAuth connection revocation read the current database session. The files gateway reads the membership directly. See Session reads and PR #195.

Two design defaults are now rules, stated in AGENTS.md, CODING_STANDARDS.md and on Design patterns. Every chart, sparkline and KPI or stat card on the web comes from Bklit UI, through the @bklit registry and the bklit-ui, bklit-ui-design and bklit-ui-migrate skills. Faux product UI on landing, marketing and docs pages (stills, feature cards, cursor demos, bento grids) is built with Stageshow and ships only after its loop passes film.mjs --gate.

The shadcn chart wrapper in packages/ui and the recharts dependency of apps/web and packages/ui are removed. Nothing imported them, so the built client and Worker are byte-identical, and an install fetches 35 fewer packages. scripts/web-chart-library.test.mjs runs in pnpm test and fails when apps/web/src or packages/ui/src imports Recharts, Chart.js, Nivo, Victory, visx, ECharts, ApexCharts, Highcharts, Tremor or a similar library, or when their package.json lists one. It is a test rather than a lint rule because an oxlint entry would replace the client boundary; see Enforcement. The Stageshow rule is held in review, with a new item in the Review checklist.

Bklit renders for React on the web only, so the Expo app is outside the rule. Its charts use victory-native, or Swift Charts through @expo/ui on an iOS-only screen. The dashboard KPI cards and the hand-built fragments of the landing feature board predate the rules and move to Bklit and Stageshow when they are reworked.

Three changes from issue #189. They were measured on the built Worker in local workerd with a production-like latency profile: the browser 120 ms from the Worker, the database 20 ms away. A second profile put the database 110 ms away. Medians of 3 rounds.

• The /_auth guard is stale-while-revalidate. Once the cached session was older than 15 s, every signed-in navigation waited for GET /api/auth/get-session before the page's own loaders started. The guard now lets the navigation start on a cached signed-in session and re-reads it in the background; a signed-out answer sends the layout to /login. A navigation after 20 s idle went from about 220 ms to about 45 ms, and from about 820 ms to about 45 ms with the distant database. (c38e801)

• GET /get-session runs outside the request transaction. Every auth request ran in db.transaction, so a session read cost BEGIN, the read and COMMIT. It is now one statement; every other auth request keeps its transaction. (f987550)

• The browser's session read comes from Better Auth's cookie snapshot. session.cookieCache is on (compact, 60 s). The browser's presentation read no longer sends disableCookieCache, so a tab focus or a background revalidation costs no database statement. With the distant database, get-session dropped from about 290 ms to 8 ms. Authorization never uses the snapshot:

  • SSR, the oRPC context, the files gateway and admin still read the database;
  • the auth handler strips the snapshot from every other /api/auth/* request;
  • the web app re-reads from the database after its own session changes.

  Creating an Organization on the web now switches to it, as Better Auth and the native app already did. A session revoked on another device can keep the UI shell for up to 60 s, and its first data request is refused with 401. See Session reads.