Show only ready PRs in the inbox Pull requests tab

[Twixes]

Problem

The inbox Pull requests tab listed and counted PRs of every status, so merged/closed (resolved) PRs piled up alongside active ones. A user saw 4 PR reports when only 1 was actually actionable — the other 3 were already-merged PRs. The count should reflect only what's worth acting on.

(Supersedes #2757, which aligned Code with Cloud by showing resolved PRs — wrong direction. Cloud is being changed to match this instead.)

Changes

Restrict the Pull requests tab's list and its count to ready PRs (a Responder draft awaiting review):

• isPullRequestReport now requires status === "ready".
• The list query (pullRequestsOnly) and the count query use a new INBOX_PULL_REQUEST_STATUS_FILTER = "ready".
• isReportTabReport excludes any report carrying a PR (including resolved/merged), so done PRs drop out of the inbox rather than reappearing as a Report.

Resolved/merged and still-running PRs no longer inflate the tab or its badge. The Reports and Runs tabs are unchanged.

How did you test this?

• Updated/added unit tests in reportMembership.test.ts (ready PR shown; resolved and in-progress PRs excluded; resolved PRs kept out of Reports).
• Ran vitest run src/inbox/reportMembership.test.ts src/inbox/reportFiltering.test.ts src/inbox/engagement.test.ts — 64 tests pass.
• Biome check clean on the changed files.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

---

Created with PostHog Code from a Slack thread

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit 5bb732d.}

[greptile-apps]

Comments Outside Diff (1)

1. packages/ui/src/features/inbox/hooks/useInboxAllReports.ts, line 116-139 (link)

   Reports count can drift when non-ready PRs exceed the first loaded page

   pullRequestCountQuery now uses INBOX_PULL_REQUEST_STATUS_FILTER = "ready", so the server-side total no longer covers in_progress/pending_input reports that already have has_implementation_pr=true. Those items still appear in query.totalCount (the broad pipeline filter includes them), but they are only subtracted from the Reports count via loadedOtherNonReport — a client-side term that only covers pages that have been fetched. Any such report sitting past the first page will silently inflate the Reports badge until it is scrolled into view.

   Before this PR, those in-progress PRs were subtracted via the broader pullRequestTotal (which used INBOX_PIPELINE_STATUS_FILTER), so the formula was correct regardless of pagination. If has_implementation_pr=true + in_progress is a valid backend state, a dedicated server-count query (analogous to pullRequestCountQuery) for those reports would restore parity.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: packages/ui/src/features/inbox/hooks/useInboxAllReports.ts
   Line: 116-139
   
   Comment:
   **Reports count can drift when non-ready PRs exceed the first loaded page**
   
   `pullRequestCountQuery` now uses `INBOX_PULL_REQUEST_STATUS_FILTER = "ready"`, so the server-side total no longer covers `in_progress`/`pending_input` reports that already have `has_implementation_pr=true`. Those items still appear in `query.totalCount` (the broad pipeline filter includes them), but they are only subtracted from the Reports count via `loadedOtherNonReport` — a client-side term that only covers pages that have been fetched. Any such report sitting past the first page will silently inflate the Reports badge until it is scrolled into view.
   
   Before this PR, those in-progress PRs were subtracted via the broader `pullRequestTotal` (which used `INBOX_PIPELINE_STATUS_FILTER`), so the formula was correct regardless of pagination. If `has_implementation_pr=true` + `in_progress` is a valid backend state, a dedicated server-count query (analogous to `pullRequestCountQuery`) for those reports would restore parity.
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
packages/core/src/inbox/reportMembership.test.ts:87-127
**Non-parameterised `isPullRequestReport` tests**

The four new cases (`ready+url`, `ready+null`, `resolved+url`, `in_progress+url`) vary only in the `status`/`implementation_pr_url` inputs and the expected boolean. The team style guide prefers `it.each` for exactly this shape: a table of inputs and expected outputs, all exercising the same predicate. Using separate `it` blocks also makes it easy for a future status (e.g. `pending_approval`) to be missed when someone adds a case.

### Issue 2 of 2
packages/ui/src/features/inbox/hooks/useInboxAllReports.ts:116-139
**Reports count can drift when non-ready PRs exceed the first loaded page**

`pullRequestCountQuery` now uses `INBOX_PULL_REQUEST_STATUS_FILTER = "ready"`, so the server-side total no longer covers `in_progress`/`pending_input` reports that already have `has_implementation_pr=true`. Those items still appear in `query.totalCount` (the broad pipeline filter includes them), but they are only subtracted from the Reports count via `loadedOtherNonReport` — a client-side term that only covers pages that have been fetched. Any such report sitting past the first page will silently inflate the Reports badge until it is scrolled into view.

Before this PR, those in-progress PRs were subtracted via the broader `pullRequestTotal` (which used `INBOX_PIPELINE_STATUS_FILTER`), so the formula was correct regardless of pagination. If `has_implementation_pr=true` + `in_progress` is a valid backend state, a dedicated server-count query (analogous to `pullRequestCountQuery`) for those reports would restore parity.

_{Reviews (1): Last reviewed commit: "Show only ready PRs in the inbox Pull re..." | Re-trigger Greptile}

[github-actions]

Clean, focused filter change with matching tests. The logic refactor in isPullRequestReport and isReportTabReport is coherent and well-commented. The only review comment is a bot style suggestion (use it.each) marked resolved on an older commit — that's a style preference, not a correctness concern.

[greptile-apps]

_{Reviews (2): Last reviewed commit: "Update reportFiltering.ts" | Re-trigger Greptile}

New commits pushed (delta classified non_linear_history) — stamphog approval dismissed; re-review running automatically.

[github-actions]

Clean, focused filter fix with coherent logic across server query params, client-side predicates, and count badge. No showstoppers found.

[stamphog]

Retaining stamphog approval — delta since last review classified as trivial_paths.