Problem
A person can remember a keyword or phrase from an earlier message but cannot use First Tree to locate it inside the current Chat. Web Chat currently fetches and renders only the newest 50 messages, while GET /chats/:chatId/messages accepts only limit and cursor. Browser find or a client-only filter therefore misses older history and can produce a false no-match.
This is distinct from conversation-list search. #1985 and its follow-up #2013 search Work/chat metadata and explicitly exclude full historical message bodies.
Proposed Feature
Add a discoverable search control to the Web Workspace Chat header. Search is scoped to the selected Chat and runs server-side across all messages the current viewer is allowed to read.
Recommended v1 behavior:
- use a bounded, normalized keyword query with Unicode-aware, case-insensitive literal matching so prose, Chinese text, and code identifiers behave predictably;
- search user-visible authored text: text, Markdown, request bodies, and file/image captions; structured cards may participate only through an explicit visible-text projection, never by searching raw hidden metadata;
- return paginated results newest-first with message id, sender, timestamp, and a short highlighted snippet;
- selecting a result loads a bounded timeline window around that message when it is outside the newest-50 page, scrolls to the exact row, and temporarily highlights the message and matching text;
- preserve a clear path back to the latest timeline position and allow moving between matching results without loading the entire history.
The API should reuse the existing Chat access boundary. A direct speaker or watcher, or a manager already allowed to read the Chat, may search it; organization admins must not gain message access merely because they are admins.
Options
- Filter only the mounted timeline — small UI change, but incomplete because only the newest 50 messages are loaded.
- Server-side keyword search within one permitted Chat (recommended) — complete and bounded while preserving the existing Chat privacy boundary.
- Search all messages across the workspace — broader ranking, authorization, and result-grouping work; this should be a separate product decision.
Acceptance Criteria
- Web Workspace Chat exposes an icon-based search entry in the Chat header without displacing rename, participant, or details controls.
- A trimmed, length-bounded query is debounced and superseded requests are canceled; clearing it restores the ordinary Chat view.
- Search covers matching messages beyond the currently loaded 50-message window and paginates the matching set.
- Matching behavior is documented and tested for case, whitespace, Unicode/CJK text, Markdown, code-like tokens, and edited message content.
- Only user-visible message text is searchable. Attachment bytes, OCR, document contents, raw card/reference metadata, and session/runtime traces are excluded.
- Results show sender, timestamp, and a safe text snippet with the matched term highlighted; loading, error, no-match, and additional-page states are explicit.
- Choosing an already-mounted result scrolls directly to it. Choosing an older result fetches a bounded context window around the message, renders the surrounding conversation, and highlights the exact message without requiring every intervening page to load.
- Previous/next result navigation remains stable as more result pages load, and closing search can return the viewer to the latest timeline.
- Search calls the same Chat access guard as message history and returns no result or metadata for a caller who cannot read that Chat. Admin role alone grants no access.
- Search results do not mutate read anchors, unread state, engagement, or message ordering merely by being returned or previewed.
- Automated coverage verifies query validation, full-history matching, pagination, access isolation for speakers/watchers/managers/outsiders, visible-text extraction, result-to-timeline anchoring, highlighting, and state restoration.
Out of Scope
- global message search across multiple Chats;
- semantic/vector search, fuzzy synonyms, or relevance ranking beyond deterministic newest-first ordering;
- searching attachment bytes, OCR output, or referenced document contents;
- session events and runtime traces, which are not Chat history;
- a Mobile Work/Chat-detail UI in this first version. The server contract should remain reusable if mobile search is explicitly admitted later.
Related
#936 proposes fetching one older message by id for document-preview recovery. Message-search navigation needs a bounded context window around a result, but the authorization and exact-message retrieval work may be reusable.
Problem
A person can remember a keyword or phrase from an earlier message but cannot use First Tree to locate it inside the current Chat. Web Chat currently fetches and renders only the newest 50 messages, while GET /chats/:chatId/messages accepts only limit and cursor. Browser find or a client-only filter therefore misses older history and can produce a false no-match.
This is distinct from conversation-list search. #1985 and its follow-up #2013 search Work/chat metadata and explicitly exclude full historical message bodies.
Proposed Feature
Add a discoverable search control to the Web Workspace Chat header. Search is scoped to the selected Chat and runs server-side across all messages the current viewer is allowed to read.
Recommended v1 behavior:
The API should reuse the existing Chat access boundary. A direct speaker or watcher, or a manager already allowed to read the Chat, may search it; organization admins must not gain message access merely because they are admins.
Options
Acceptance Criteria
Out of Scope
Related
#936 proposes fetching one older message by id for document-preview recovery. Message-search navigation needs a bounded context window around a result, but the authorization and exact-message retrieval work may be reusable.