Separate Tasks and Pull Requests into dedicated sidebar destinations #5974

Activity

1. github-actions commented on Jul 26, 2026

   

   github-actionsBot

   on Jul 26, 2026 – with GitHub Actions

   Contributor

   More actions

   Triage: no reproducible bug — this is a feature request

   I picked this up in automated bug triage (reproduce with a test, fix if scoped). Stopping without a PR, because there's no defect to reproduce here: this is an enhancement/UX-restructuring proposal, and the current code behaves as designed.

   What I checked. The issue's description of today's behaviour is accurate, and everything it describes is intentional:

   • Single combined destination in the left rail, labelled Tasks & PRs — DashboardSidebarHeader.tsx:423 (expanded) and :260 (collapsed tooltip). Active state is one fuzzy match on /tasks (:103).
   • One route, /tasks, with the surface selected by a type search param (tasks/prs/issues) — tasks/layout.tsx.
   • Page-level type tabs re-stating that choice — TYPE_TABS in TasksTopBar.tsx:52-56, branched in TasksView.tsx:260-262.
   • One shared filter store for all three surfaces, including a shared search and typeTab — tasks-filter-state.ts. Restoring filters on sidebar click already works, via tasksSearchFromFilters in handleTasksClick.
   • PR detail already lives at /tasks/pr/$prNumber, so the "compatibility redirect" criterion is about a route that doesn't exist yet.

   Why I didn't write a reproduction test. A test here could only assert the desired end state — e.g. "the left rail exposes a Pull Requests destination" — which fails because the feature is unbuilt, not because of a bug. That's a feature spec, not a reproduction, and committing it as a failing test would misrepresent triage findings. Nothing in the acceptance criteria describes a behaviour that is currently broken.

   Scope note for whoever implements it. This is a multi-part change, not a triage-sized fix:

   1. A new /pull-requests route (extracting PullRequestsContent) plus its own persisted repo/state/search store, since tasks-filter-state currently keys everything off one shared object.
   2. Splitting the sidebar item in both variants, with per-destination active state — the current single fuzzy /tasks match would light up both.
   3. Redirects from legacy /tasks?type=prs and /tasks/pr/$prNumber URLs, including persisted store values that still hold typeTab: "prs" after upgrade (worth a migration, given version: 1 in the persist config).
   4. Removing the now-redundant prs entry from TYPE_TABS and the showPRs branch.

   Acceptance criterion 5 also requires verification in the real Electron app at wide and compact viewports, which needs a running dev stack over CDP — out of reach for this automated pass.

   Happy to take a pass at the implementation if it's scoped into its own task; flagging it as a feature rather than silently opening a speculative PR.
2. saddlepaddle

   closed this as completedin #5975on Aug 4, 2026