feat(favourites): search-led workspace, no ModeHome (#164)

docs/branch-review-records/ccf620aa5c3871b3787e29f50511d79a9a9ba43bc3591b8d0e1bd117ed930ea5.record.md

@@ -0,0 +1 @@
+| 2026-08-15 | claude/favourites-hybrid-164 | 02672320db5a0b5b57b589e8d19d19c8c66483d4 | Favourites search-led workspace: retire marketing H1 and library nav, live in-place filter, dashboard band (#164) | Shipped; no P0-P2 findings | verify:pr-local all 10 selected gates passed — unit suite 607 files / 6584 passed, 4 skipped; check:design-system-contract passed with edgeOwnershipConflicts 25 to 24 from the deleted nav module; UI delegated to CI Production UI — chromium-1194 vs pinned 1234 (#255/#312) |

docs/outstanding-issues-inbox/0a052268-97e1-4d4a-9ad7-033003aa486c.json

@@ -0,0 +1,13 @@
+{
+ "version": 1,
+ "id": "0a052268-97e1-4d4a-9ad7-033003aa486c",
+ "createdOn": "2026-08-15",
+ "action": "add",
+ "payload": {
+ "pri": "P2",
+ "type": "task",
+ "summary": "Favourites Continue and Recent are driven by hard-coded demo timestamps; real saved items have no last-opened data",
+ "detail": "Surfaced while shipping #164 (PR #1983), which made both surfaces prominent. src/components/clinical-dashboard/favourites-command-library-page.tsx derives 'most recently used' from lastUsedScore(item.lastUsed), and item.lastUsed comes from lastUsedByItemId — a hard-coded five-entry literal keyed to demo slugs ('Today 08:44', 'Yesterday 16:12', ...). Anything else, including every real registry favourite, falls back to the literal string 'Saved', which lastUsedScore buckets at 1000. pinnedItemIds is likewise a hard-coded two-item Set. The consequence after #164: for a signed-in user with real favourites, the Continue card and the Recent panel are effectively arbitrary — every item ties at the same score and the order is whatever the source array happened to be. Note that recentQueries in the shell is search-query history, not viewed-item history, so it cannot back this. Next: add a per-favourite last-opened timestamp. Cheapest is a client-side recents store keyed by favourite id written on open; the durable version is a column on the account favourites record so it survives a device change, which is a schema plus /api/account/favourites change and needs the usual migration review. Either way, pinning should stop being a hard-coded id set. Stop: do not fabricate a timestamp at render time from anything other than a recorded open event — an invented 'last used' on a clinical reference list is worse than an honest absence.",
+ "source": "session 2026-08-15; PR #1983; favourites-command-library-page.tsx lastUsedByItemId/pinnedItemIds"
+ }
+}

docs/outstanding-issues-inbox/5cf244c3-1b68-4214-8097-767b11a49e13.json

@@ -0,0 +1,10 @@
+{
+ "version": 1,
+ "id": "5cf244c3-1b68-4214-8097-767b11a49e13",
+ "createdOn": "2026-08-15",
+ "action": "done",
+ "payload": {
+ "id": "#164",
+ "outcome": "CLOSED 2026-08-15 by PR #1983. /favourites is one dashboard+search workspace; no ModeHome was reintroduced and no separate Favourites home route exists. DELIVERED: the 'Favourites command library' marketing H1, its heart icon tile and its explanatory subtitle are retired for a plain Favourites heading with the item count beside it as non-heading text; the desktop FavouritesSidebar plus the phone FavouritesMobileQuickViews and FavouritesMobileBrowseRail collapse into one chip rail carrying sets, Pinned/Source-backed and types with counts, after which favourites-library-nav.tsx had no callers and was deleted (529 lines, and it paid down one gate-8 edge conflict as a side effect: 25 to 24); the empty query shows Continue then Recent and Your sets side by side, a typed query demotes that band to a collapsed disclosure and filters the table in place with an 'N matches for ...' header; and the redundant filter computation is gone — filteredItems and the table's own tableRows were derived independently from identical inputs, so the band count and the table count were two answers to one question, and the page now derives rows once and passes them down. IN-PLACE FILTERING IS REAL, not just same-surface: the page reads the shared composer's live draft via useSearchCommand seeded from the route's submitted ?q=, the same pattern tools-search-results-page already uses, so typing filters without navigating and without a second input and the one-composer contract is untouched. NOT DONE, deliberately and worth knowing: Continue and Recent still render from the existing derivation, where lastUsedByItemId and pinnedItemIds are hard-coded five-entry literals for demo slugs and real registry items fall back to the literal string 'Saved'. Direction B leads with both surfaces, so they want a genuine per-item last-opened timestamp; that is a data-layer change and building it here would have silently rescoped this row. Captured as its own row. Verification: verify:pr-local all ten selected gates passed, unit suite 607 files / 6584 passed; UI proof delegated to CI Production UI (chromium-1194 vs pinned 1234, #255/#312)."
+ }
+}