[dash0-dev]

Why

The Lore Explorer could sort by Newest or Most chosen, but not by what agents are reading now: a lifetime count cannot tell a lesson fetched forty times last spring from one fetched this morning.

What changed

• The Sort control gains Recent read (?sort=last_opened_at): the last deliberate agent read first — a targeted memory.read / CLI read, never a bulk list/search page or a human opening the dashboard (00099's column).
• Migration 00115 lets lorekit_memory_list order by it desc NULLS LAST (same signature); never-read lessons trail as a tail, so total is unchanged.
• A third cursor codec, last-opened-cursor.ts (edge-mirrored, drift-checked), carries a nullable timestamp so paging continues inside that tail; both list routes accept the new value.
• Docs, plus regenerated llms.txt and BYOD bootstrap.

How to verify

• §115 in supabase/tests/migrations.test.sql pins the order, the total and a 4-page walk across a tie and the read → never-read boundary (Integration smoke runs it).
• Pick Recent read in the Sort control on /lore; the URL gains sort=%22last_opened_at%22 and survives a reload.

Notes for reviewers

Under this sort a NULL p_cursor_ts with a set p_cursor_id means "inside the never-read tail", so the handler passes the id whenever a cursor decodes. The list route has no handler-level test, so that wiring is covered by review and §115's RPC-level walk only.

🧪 UI verification spec — run against the preview deployment

Target: preview
Format: intent

Spec 1: AC-1 — A reader sorts the Explorer by Recent read and the order survives a reload

Changed: the Sort control in the Lore Explorer toolbar (new "Recent read" option)
Start: /lore
Preconditions:

• The signed-in account has at least one lesson, so the Explorer list renders.
• The viewport is desktop width (the mobile Sort control is an icon-sized square with the same native select).
  Steps:

1. Open the Lore Explorer.
2. Open the Sort memories control next to the date picker and note its options.
3. [must-follow] Choose Recent read in the Sort memories control.
4. [must-follow] Reload the page.
5. Choose Newest in the Sort memories control, restoring the default.
   Expected:

• The Sort memories control offers exactly three options, in order: "Newest", "Most chosen", "Recent read".
• POST /functions/v1/memories/list returns 200
• After step 3 the page URL carries sort=%22last_opened_at%22.
• After the reload in step 4 the Sort memories control still shows "Recent read".
• After step 5 the page URL carries no sort parameter.
  Hints:
• {role: "combobox", name: "Sort memories"} — packages/web/src/components/lore/SortSelect.tsx:88
• Option labels — packages/web/src/lib/explorer-sort.ts (EXPLORER_SORT_LABELS)
• The URL value is JSON-encoded (encodeURIComponent(JSON.stringify(value))) — packages/cli/src/shared/deeplink-pure.mjs:111
  Out of scope:
• Which lesson appears first: it depends on the account's agent reads; the order itself is pinned by §115 in supabase/tests/migrations.test.sql.

[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 5:11pm UTC

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

[dash0-dev]

Darkplane Automerge did not approve this pull request. It scored 56.62 of 100, and 75 was required.

• 🟡 Blast radius scored 52.
  The change is additive in intent (a new last_opened_at sort value, null-defaulted cursor, no new signature). But supabase/migrations/00115_explorer_recent_read_sort.sql uses create or replace on the shared lorekit_memory_list function and rebuilds the keyset and ORDER BY for the three existing sorts too. That function backs GET /memories, and the same SQL is duplicated in supabase/byod/bootstrap.sql. The change also touches schemas, the web explorer, the CLI and llms.txt, and a revert needs a forward migration restoring the 00114 function.
• 🔴 Change footprint scored 30.
  The change rewrites the load-bearing lorekit_memory_list SQL function in supabase/migrations/00115_explorer_recent_read_sort.sql. It adds a hand-written nullable keyset (last_opened_at desc nulls last) inside dynamic SQL. The same function is repeated in supabase/byod/bootstrap.sql, and the cursor logic is duplicated in two new last-opened-cursor.ts files plus handlers/list.ts. It follows an existing sort-addition pattern (opened_count in 00113) and has SQL and unit tests, with the rest being docs and small web edits. Even so, the nullable-cursor pagination is new logic on a core read path.

The other criterion

• 🟢 Evidence quality scored 88.
  The PR adds specs for the new cursor codec (last-opened-cursor.spec.ts), the sort (explorer-sort.spec.ts) and the schema. It also adds a 181-line §115 SQL test in migrations.test.sql covering order, total and a 4-page walk across a tie. CI is green, including Integration smoke, Playwright e2e, typecheck and Storybook, and mthines approved the evaluated commit. The one stated gap is that the list handler wiring has no handler-level test.

_{An AI evaluator produced these scores from the diff, the repository history, and the pull request text. The pull request text is author-controlled, so treat the scores as signals rather than proof. Reviewed for commit 3bd5f86.}