Sidebar: show when a thread's pull request needs you, with a "Needs attention" filter

[filipgutica]

I'd like agreement on direction and scope before I write any code.

Problem

When I run several agents, the sidebar tells me when a thread needs an answer or an approval, but not when the thread's pull request needs me. Failing checks, a "changes requested" review, and new review threads only show up on GitHub, and then I have to find the thread that owns the PR. #16459, #19085 and #21251 each describe part of the same gap.

I also can't filter down to the threads that need me. With 20+ threads, I end up scanning every row for Input or Approval.

Proposal

1. Use the row's existing status slot

The top line of a sidebar row already shows Input, Approval, Failed, Working and Done. I'd add four reasons to that slot:

• Checks failed, when a linked open PR has failing checks.
• Feedback, when a linked PR has changes requested or unresolved review threads.
• Plan ready, when a proposed plan is waiting for review.
• Ready to merge, when a linked open PR is approved, its checks pass, and GitHub would merge it now.

The most urgent reason takes the slot, and +N counts the other kinds. Working still takes the slot and its timer while the agent runs, so a thread whose agent is fixing its failed checks shows "Working 4m +1".

Ready to merge is the least urgent reason, so it only takes the slot when nothing else needs the thread. A thread with an approved PR and an open review thread shows "Feedback +1".

When a thread has several reasons at once, the slot shows the top one plus the count:

2. Attention card

The badge is a button. It stays visible when you hover the row, with Snooze and Settle beside it, the same way the "Woke" badge does when a snoozed thread wakes up. Clicking it opens a card with every reason, grouped by the thread and each linked PR. Each reason has one action: Open thread, View review, View threads, or View PR. Each unresolved review thread lists its file and line, the opening comment, and who replied last, so you can tell an answered thread from a new one before opening the PR. Opening the thread clears the thread's own reasons. PR reasons clear when the PR changes: checks pass, threads get resolved, or the PR merges or closes. Ready to merge also clears when the PR stops being mergeable, for example when a new push resets a required check. The row's existing details card on hover doesn't change.

3. "Needs attention" filter

The filter is a switch at the top of the existing project filter menu, and it combines with the project scope. While it's on, a chip under Search shows it, and the chip's × turns it off. When nothing needs attention, the list says so and offers a way back to all threads.

Scope

Web and desktop only. Ready to merge needs one small, optional contract field; the other reasons need none.

Failed checks and changes requested come from checksState and reviewDecision. The thread shell already carries both for each linked PR, and PullRequestSyncReactor keeps them current, so these two need no new reads. Unresolved review threads need the PR activity read, which means one cached read per open linked PR on unsettled threads.

Ready to merge can't be derived from what clients receive today. Approved, passing checks, and no conflicts can still be blocked on GitHub. On one of my PRs, a required status never reported on the head commit: GitHub said BLOCKED, but the check list looked all green, because a required check that never ran isn't in that list at all. Only GitHub's mergeStateStatus reflects this.

The GitHub provider already reads mergeStateStatus in its detail query and derives canMergeNow from it, but only uses that internally to decide whether to offer auto-merge. I'd expose it as an optional canMergeNow on PullRequestDetail, which is roughly 12 lines across contracts, the provider interface, the GitHub provider, and PullRequestService, with no GraphQL or codegen changes. Other providers leave it absent, which means unknown, and older clients ignore it.

The client reads the detail only for candidates: linked open PRs whose thread snapshot already shows approved, passing checks, mergeable and not a draft. The snapshot already carries reviewDecision, checksState, mergeability and isDraft, so most PRs never trigger the extra read.

Seen state uses the server-side lastVisitedAt, so opening a thread on one device clears it on the others.

This adds no OS or push notifications and leaves the existing notification paths alone.

I've used a version of this every day in a fork for a few weeks. This proposal leaves out the fork-specific parts and uses only the native thread and PR data.

Questions

1. Is the status slot the right place, or should PR state stay off the row?
2. Is the project filter menu the right home for the switch?
3. Should unresolved review threads be in v1, given the extra activity read, or should v1 ship only checks and review decision?
4. Is a mobile follow-up wanted? It would build on Mobile: show checks, review and watch state for linked pull requests, like desktop #20212.
5. Should Ready to merge count toward the "Needs attention" filter? It's a call to act, but a positive one, unlike the other reasons.
6. Is exposing canMergeNow on the PR detail acceptable, or should Ready to merge wait until the summary read carries a merge state?