[dash0-dev]

Summary

On /lore the TopBar activity bar could stay on for seconds after everything on screen had loaded. Three reads were Next.js server actions: the memory badge, the pending-invites query and the Explorer list. The app router runs server actions one at a time per client, and they can't take an AbortSignal, so on every load and every window focus they queued in a fixed order: plan usage → invites → list. This PR moves all three off server actions so they run in parallel with the other reads and can be cancelled.

Changes

• Explorer list: useMemories now calls POST /memories/list from the browser (fetchMemoryPage) and passes React Query's signal, the same way the scope tree and facets already work. The body building moved unchanged from the listMemories action into the pure lib/memory-list.ts, and the action was removed.
• Memory badge and pending invites: useMemoryTotal and usePendingInvitesForMe now read new GET route handlers, /api/plan/usage and /api/invites/pending. These wrap the existing getPlanUsage / listPendingInvitesForMe with the same contract (null / [] when signed out). They have no REST endpoint yet, so a route handler is the step that removes the queue without a schema/handler/OpenAPI change. The browser reads them through getAppRoute(path, signal) (lib/app-route.ts). The server-rendered pages still call the functions directly.
• Behaviour change: a failed list read now retries (retryUnlessSignedOut) and, when nothing is loaded yet, shows the Explorer's existing "Failed to load memories" state. A failed "Load more" keeps the loaded rows and offers "Try again" beside the button. Before, the action failed closed to an empty page, so an outage read as "No memories".
• Analytics: lore.results_paged is now sent only when the requested page actually lands, so a failed attempt, its retry, or a page cancelled by a filter change mid-load no longer counts as an appended page.
• Tests:
  • parallel-reads.spec.ts checks that each hook sends an ordinary request with the signal and never calls a server action. The action modules are mocked to throw, and all 9 cases fail against main.
  • read-routes.spec.ts checks the route contracts and no-store.
  • memory-list.spec.ts pins the list body.
• Docs: a new rule in packages/web/CLAUDE.md ("A client read is never a server action") plus the matching docs/decisions.md entry and CLAUDE.md key-decision line. docs/key-files.md and docs/storybook.md are updated.

User-facing docs / llms.txt: none apply. Nothing a user can do or configure changed; only the transport behind three dashboard reads did.

Context

Measured from the web service's RUM and server spans (2026-10-20, www.lorekit.io):

• Back-to-back calls: each POST /lore started the millisecond the previous one ended. Server spans show the order never changed: lorekit.plan.get_usage → org_invites read → memories/list.
• Typical cost: on a page load, the chain ran about 6.6 s past the last parallel REST response. Window-focus refetches added about 2 s each.
• Worst case: a 50.6 s Supabase auth/v1/user call inside the list action, plus a focus refetch queued behind it, kept the bar on for about 85 s after the visible data had loaded.
• First paint: on a cold load, LCP landed 0.5 s after the list action, which was third in the queue. The list itself waited about 10 s behind the two top-bar reads.

Needs you

• Comment /update-baselines (it only runs for a maintainer's comment). The Pages/Lore Explorer → Default story now renders the populated list from the MSW fixtures instead of "No memories in this scope", so LorePage.stories.tsx/Default-1-chromium-linux.png changes (960×720 → 960×1793). Empty is unchanged. The baseline commit is pushed with the workflow token, so re-run CI (or push a commit) afterwards to turn the Storybook job and CI Summary green.
• Optional follow-up: move plan usage and "invites for me" onto real edge endpoints (the backlog in packages/web/CLAUDE.md). Four other client surfaces still read through actions, off the /lore refresh path: useAuditLog, LessonDetailSheet, OrganizationManager and InviteDetailsDialog (listed in packages/web/CLAUDE.md).

Verification

• npx vitest run --root packages/web: 116 files, 1647 tests pass.
• npx tsc --noEmit -p packages/web/tsconfig.json: clean.
• eslint on the changed files: 0 errors (one existing warning in mocks/memories.ts).
• Not run in the sandbox: the Storybook browser suite and the Playwright e2e run. In CI, Playwright e2e passes and the Storybook job fails only on the Default baseline above.

[github-actions]

The dashboard preview for this PR — redeployed on each push that changes the web app.

Project	Deployment	Actions	Updated
lorekit	Ready	Preview	Oct 21, 2026 7:31am UTC

_{Preview always points at this PR's latest commit; Deployment is the immutable build of abb2666. · Comment /web-preview to force a redeploy. · Workflow logs}

[dash0-dev]

⚪ 1 non-blocking finding

Moves the /lore list, plan-usage and invites reads off server actions. Since the last review only CI's baseline commit landed (44 PNGs, no code); one doc gap on the plan-usage backlog claim.

Warnings: Says only LorePage Default baseline moves; 659361a rewrote 44 PNGs (Empty + 42 untouched stories, 3 clash with #708)

_{1 advisory finding below the confidence bar — see Less certain below.}

Progress: open review threads 2 → 0 → 1 → 0 → 1 across the last 5 reviews

	Finding	Where
⚪ 1	Plan usage missing from the backlog list it cites Fix: Add plan usage (getPlanUsage → lorekit_memory_count) to the backlog list at packages/web/CLAUDE.md:82-83.	packages/web/src/lib/app-route.ts:6

Less certain (1) — advisory, below the confidence bar

	Finding	Where
2	suggestion: No spec, story or e2e covers loadMoreFailed (rows kept, Try again) or the page-landed lore.results_paged gate; both changed across three pushes here. Confidence 75	packages/web/src/components/lore/LoreExplorer.tsx:1163

Review details

Gate		Details
Description vs. code	⚠️	Says only LorePage Default baseline moves; 659361a rewrote 44 PNGs (Empty + 42 untouched stories, 3 clash with #708)
Prior review feedback	✅	Earlier review comments are resolved.
Documentation	✅	New CLAUDE.md rule, decisions entry, key-files rows and JSDoc explain the transport change and its interim routes
Self-review signals	✅	No debug logs, leftover TODOs, or unreviewed stubs.
Code review	⚠️	1 non-blocking finding — see inline comments.

Run	Details
Mode	full · 0 lines in delta · tier deep · depth checkout · delta since 3201be9 is CI's 44-baseline commit (0 text lines); routed deep on blast radius, so the whole PR was re-read
Anomaly	⚠️ no sub-agent dispatch available — the intent finder ran in-context with the other finders at effective thoroughness 0.95, instead of as its own sub-agent — 1 prepare-time anomaly (gh pr checks unreadable — CI state is informational only, so this never grades)
Checked	20 of 20 changed files read · 6 possible issues → 1 confirmed → 1 posted
Reach	13 changed exports · 9 dependent files · 9 checked · 2 changed files imported by 24 files, not traced MemoryFilters — 1 consumer file · 1 checked MemoryPage — 1 consumer file · 1 checked useMemories — 3 consumer files · 3 checked PENDING_INVITES_QUERY_KEY — 1 consumer file · 1 checked getAppRoute — 2 consumer files · 2 checked +8 more packages/web/src/mocks/memories.ts — imported by 23 files packages/web/src/components/lore/LoreExplorer.tsx — imported by 1 file
Found	produced 6 → posted inline 1 · cleared 1 · carried forward 0 · deferred 0 · below-bar 1
Dropped	1 below-bar
Severity	⚪ 1 low
CI	no checks on 659361a (the baselines commit was pushed with GITHUB_TOKEN, which re-triggers nothing); at 3201be9: red Web — Storybook interaction + visual tests (changed), CI Summary · 5 passed
Memories	77 indexed · 5 used (2 knowledge · 3 hotspots)

Memories used

• knowledge knowledge::getAppRoute@packages/web/src/lib/app-route.ts — finder pointer (re-verified at 659361a: code unchanged since 3201be9; consumer-default fact cleared the Storybook candidate)
• knowledge knowledge::useMemories@packages/web/src/lib/queries/lore.ts — finder pointer (re-verified at 659361a: retry and scope-guard facts hold; led to the retry trace)
• hotspot hotspot::packages/web/src/components/lore/LoreExplorer.tsx — quality + correctness checklist line (test-gap, edge-case) — led to the Load-more test-gap re-check
• hotspot hotspot::packages/web/src/lib/queries/lore.ts — correctness checklist line (error-path) — led to the list retry-policy trace
• hotspot hotspot::packages/web/CLAUDE.md — quality checklist line (missing-update) — led to the backlog-list cross-check

^{Nothing to report — standards (2 docs), measurability (11 paths classified), integrations (not activated), 0 files skipped.}

^{pr-reviewer · commit 659361a · full review · how these findings are produced · updated Oct 21, 2026 7:40am UTC}

[mthines]

/update-baselines

[github-actions]

✅ Update visual baselines: committed 44 updated baseline(s) as 659361aba81039f5f94191c4fbf34e6a282082ea.

ℹ️ This commit was pushed with GITHUB_TOKEN, so web-test will not re-run automatically — push a follow-up commit if you need CI to re-verify.

[dash0-dev]

suggestion (low): ⚪ Plan usage missing from the backlog list it cites (non-blocking)

This says packages/web/CLAUDE.md lists plan usage as backlog, but that list (line 82) names only orgs, invites, tokens and audit log, so /api/plan/usage's direct RPC has no exemption.

Evidence: packages/web/CLAUDE.md:82 (backlog list) · docs/decisions.md:863 (same claim)

  (sign-in, session, password), and the server actions covering surfaces the REST
  API does not expose yet (orgs, invites, plan usage, tokens, audit log). Those server actions

^{pr-reviewer · commit 659361a}