Campaign search has no results page: a kind stops at ten with no way to the rest, and a rules hit opens nothing

claude-bot commented

2026-10-02 04:27:22 +00:00

Collaborator

Found while checking #667 against main (2b077778), 2 October. The app bar search is built and #667 is closed; these two pieces of it are not.

1. No results page (catalogue surface SH-9, "Search results")

webapp/frontend/src/shell/AppFrame.jsx mounts <Search> with this comment:

No results page yet, so neither "All N in Sessions" nor "See all" is offered: lane 3 builds the one they would lead to.

Lane 3 did not build it, and App.jsx has no search route. The panel shows at most PER_KIND_CAP (10) per kind. The server already returns the true counts in by_kind, and Search already takes seeAllHref and groupHref and draws "All N in …" and "See all" when given them. So today a search with more than ten matches of a kind silently stops at ten.

Smallest build: a /campaigns/:id/search?q=…&kind=… page that reuses searchCampaign (same ranking, same audience filtering, same transcript opt-in for a GM), grouped by kind with every match, and pass seeAllHref / groupHref from AppFrame.jsx. The wiki front page's search (useWikiSearch, kinds wiki + rule) wants the same link.

Needs a ledger row and a drawing check: every UI feature needs a surface in docs/design/redesign-surfaces/CATALOGUE.md.

2. A rules hit has nowhere to go

SearchItem.href is null for a rule (the app has no page for a rule entry), and onOpen={(r) => r.href && navigate(r.href)} makes choosing one do nothing. To check in a browser: whether the row looks and behaves as something you can choose. Options: open the rule in the same preview the prep drawers use (Peek, #1026), or draw the row as not choosable.

Refs #667.

Found while checking #667 against main (2b077778), 2 October. The app bar search is built and #667 is closed; these two pieces of it are not. ## 1. No results page (catalogue surface SH-9, "Search results") `webapp/frontend/src/shell/AppFrame.jsx` mounts `<Search>` with this comment: > No results page yet, so neither "All N in Sessions" nor "See all" is offered: lane 3 builds the one they would lead to. Lane 3 did not build it, and `App.jsx` has no search route. The panel shows at most `PER_KIND_CAP` (10) per kind. The server already returns the true counts in `by_kind`, and `Search` already takes `seeAllHref` and `groupHref` and draws "All N in …" and "See all" when given them. So today a search with more than ten matches of a kind silently stops at ten. Smallest build: a `/campaigns/:id/search?q=…&kind=…` page that reuses `searchCampaign` (same ranking, same audience filtering, same transcript opt-in for a GM), grouped by kind with every match, and pass `seeAllHref` / `groupHref` from `AppFrame.jsx`. The wiki front page's search (`useWikiSearch`, kinds wiki + rule) wants the same link. Needs a ledger row and a drawing check: every UI feature needs a surface in `docs/design/redesign-surfaces/CATALOGUE.md`. ## 2. A rules hit has nowhere to go `SearchItem.href` is `null` for a rule (the app has no page for a rule entry), and `onOpen={(r) => r.href && navigate(r.href)}` makes choosing one do nothing. To check in a browser: whether the row looks and behaves as something you can choose. Options: open the rule in the same preview the prep drawers use (`Peek`, #1026), or draw the row as not choosable. Refs #667.

claude-bot referenced this issue

2026-10-02 04:27:30 +00:00

[UX] Campaign-wide search in the app bar #667

claude-bot commented

2026-10-02 04:31:48 +00:00

Author

Collaborator

Picking this up (2 October), branch feat/1033-search-results-page.

Approach: the page asks the same route for every match of the kinds it names (an optional parameter lifts the per-kind cap to a bound; same ranking, audience filtering and transcript rule), at /campaigns/:id/search?q=…&kind=…. No second search box (#593): the app bar's box stays the only one, and its panel gets the drawn "three per kind, then a way into the rest". A rules hit opens the preview the prep drawers already use. The page behind "All N" is added to lane 1's SH-9 drawing, with a ledger row.

Picking this up (2 October), branch `feat/1033-search-results-page`. Approach: the page asks the same route for every match of the kinds it names (an optional parameter lifts the per-kind cap to a bound; same ranking, audience filtering and transcript rule), at `/campaigns/:id/search?q=…&kind=…`. No second search box (#593): the app bar's box stays the only one, and its panel gets the drawn "three per kind, then a way into the rest". A rules hit opens the preview the prep drawers already use. The page behind "All N" is added to lane 1's SH-9 drawing, with a ledger row.