vscode: editor-tab webview for rich backlog search

[amrmelsayed]

Problem

The current Backlog sidebar tree (+ #809 mine/all toggle + #811 area grouping) is fine at "show me what's on my plate" but offers no real search. #918 will add a Quick Pick command for fast "find one and open it" — but Quick Pick is a single-pick overlay that dismisses on selection. It's not suited to exploratory search: scanning, filtering, sorting, refining, re-querying without re-opening the picker each time.

Examples of what Quick Pick can't comfortably do:

• "Show me every open area/vscode issue, assigned to anyone, sorted by age"
• "Search for 'webview' across titles AND bodies, narrow to area/vscode, sort by most-recent comment"
• "How many open issues are unassigned across all areas?"

Proposal — editor-tab WebviewPanel

A search icon in the Backlog sidebar section header opens a WebviewPanel (full editor tab) titled "Search Backlog." The tab persists until X'd, the sidebar tree stays intact, and the search panel itself is a rich UI with multiple filter dropdowns, text input, type filter, sortable result columns, and a match-count footer. Native dropdown styling, native fonts, theme-aware.

Concretely:

• Trigger: a magnifying-glass icon in the Backlog view's title bar (view/title menu item alongside the existing eye/refresh icons). Command: codev.searchBacklog (renamed/scoped if vscode: Quick Pick command for searching the backlog #918 already claims that name — TBD at plan).
• Surface: vscode.window.createWebviewPanel('codev.backlogSearch', 'Search Backlog', ViewColumn.Beside, {...}). Opens in the editor area, next to whatever the user has open. Single instance — invoking the command while a panel is already open focuses the existing one instead of stacking duplicates.
• Layout (top → bottom):
  • Title: Search Backlog
  • Scope row: 3 native-styled dropdowns — Area: All / area/vscode / area/tower / ..., Assignee: All / Me / Unassigned / @user1 / ..., Author: Anyone / Me / @user1 / ...
  • Query row: free-text input + a Status: Open / Closed / All dropdown + Search button
  • Results table: sortable columns — #, Title, Area, Assignee, Age, with sort indicator arrows on the active column. Click a row → invokes codev.viewBacklogIssue with the issue id (same default action as a sidebar row).
  • Footer: status bar reading N matches found (e.g. 12 matches found · 8 in area/vscode, 4 in area/tower).
• Search semantics: text query matches title + body (substring, case-insensitive). Scope dropdowns AND together. No fuzzy-match — that's Quick Pick's job; here the user is explicit. Empty query + scopes = show all matches in scope. Empty query + empty scopes = show everything (capped at a reasonable N, e.g. 200, with a "load more" affordance).
• Persistence: tab stays open across sidebar interactions. User refines query / scopes without re-opening. Result table updates in place. Tab dies when user X's it; state is not persisted across reloads (first-cut keeps it simple — can revisit if requested).
• Theming: use CSS variables (var(--vscode-foreground), var(--vscode-input-background), var(--vscode-button-background), var(--vscode-list-hoverBackground), etc.) so the panel auto-themes against dark/light/high-contrast without per-theme code. Pattern is the same one used by Tower's web dashboard's VSCode-mode CSS.

How this slots in with everything else

Path	Issue	Surface	When it wins
Sidebar tree (always-on)	Already shipped (#809 + #811)	TreeView in sidebar, no search input	"What's on my plate right now" — at-a-glance
Quick Pick (fast find)	#918 (AIR)	Overlay summoned by command, fuzzy single-pick	"I know it exists, find it, open it, dismiss"
Editor-tab webview (this one)	this issue	WebviewPanel in editor area, opened on demand, persists until X	"Scan, filter, sort, refine — exploratory triage"

All three are complementary. The sidebar tree stays as the always-on summary. Quick Pick is the muscle-memory fast path. This editor-tab panel is the deep-dive.

Supersedes #906

#906 proposed replacing the sidebar TreeView itself with a sidebar WebviewView that hosts search input. That approach loses the always-visible at-a-glance backlog scan the tree provides (the strongest part of the current sidebar) AND inherits all the sidebar-webview theming/sizing friction. The editor-tab pattern in this issue solves the same "we need richer UI than TreeView allows" need without paying #906's cost. #906 should be closed in favor of this one.

Acceptance

• Search icon visible in the Backlog view title bar.
• Click opens a Search Backlog editor tab to the side of whatever's open.
• Tab contains the three scope dropdowns (Area, Assignee, Author), the query row (text + Status + Search button), the results table (sortable), and the match-count footer.
• Typing in the query updates results live (debounced ~150ms) — Search button is for users who prefer explicit submit.
• Empty query with scopes returns scoped matches; empty query + empty scopes returns all (capped at 200 with load-more).
• Clicking a result row invokes codev.viewBacklogIssue — same as clicking a sidebar row.
• Re-invoking the command focuses the existing panel instead of opening a second one.
• Dark, light, and high-contrast themes all render the panel cleanly with no hand-coded colors (CSS variables only).
• No regression to the sidebar tree, Quick Pick (vscode: Quick Pick command for searching the backlog #918), or the mine/all toggle (vscode: backlog view — toggle between 'mine only' (default) and 'all' #809).

Out of scope

• Saved searches / search history.
• Search across closed issues, PRs, reviews, or anything other than the open backlog (could be added behind the Status dropdown later, but v1 keeps the data source the same as the sidebar tree).
• Cross-repo search (single-repo, single-workspace).
• Persisting query/scope state across VSCode reloads.
• Inline issue editing (label changes, assignee changes, comments) from the result row. Row click opens the issue; mutations happen there.

Why PIR

Two design calls genuinely benefit from a plan-approval gate:

1. Exact filter set and column shape — Area/Assignee/Author is my proposal, but Status-in-scope vs Status-in-query-row vs separate-toggle is real design surface. Sortable columns include Age but the precise format ("2d ago" vs "May 26" vs both) and whether Comments-count is a column needs a call.
2. Search semantics — substring vs prefix vs full-text-with-stemming; whether area/vscode typed in the query box should filter same as the dropdown (probably yes); how AND vs OR works across scopes (probably all AND-ed).

And the running UI needs visual verification before PR — multiple themes, multiple result-set sizes, multiple filter combinations. PR diff alone can't catch theme regressions. PIR's dev-approval gate is exactly the right shape for this.

Implementation skeleton

• New file packages/vscode/src/webviews/backlog-search-panel.ts — owns the WebviewPanel lifecycle, message-routing to/from the webview, panel-singleton logic.
• New file packages/vscode/src/webviews/backlog-search.html (or inlined template) — the panel HTML/CSS/JS. CSS variables only.
• Pure helpers in packages/vscode/src/views/backlog-filter.ts (existing file) extended to support multi-filter queries (current filterMine is single-dimension).
• Command registration + view/title menu entry in extension.ts and package.json.
• Tests: pure-helper tests for the multi-filter query in vitest; Playwright/manual at dev-approval for the panel itself.

[amrmelsayed]

On it! Working on this with the PIR protocol (plan + dev-approval gates before PR).