Summary
IssueSearchCriteria carries updatedAfter / createdAfter (ISO YYYY-MM-DD), translated to updated:>= / created:>= qualifiers in packages/plus/git-github/src/api/issueSearchQuery.ts and declared per provider in getSupportedFilters().issueSearch. PullRequestSearchCriteria (packages/git/src/models/pullRequest.ts) has no date channel at all — it is { text, relationships, states, includeArchived }.
Why it matters
A date window is the most effective narrowing on a large scope (the issue-side model comment says exactly that), and it is what lets a consumer bound a broad PR read instead of draining every page. The two halves of one search box diverge today: issue search can constrain by recency, PR search cannot. It is also the sharper bound the closed-PR read wants — a recency window (updated:>=) is currently not expressible for PRs, so callers fall back to capping page iterations.
What we need
updatedAfter? / createdAfter? on PullRequestSearchCriteria, mirroring IssueSearchCriteria (ISO YYYY-MM-DD).- Emission in the PR query builder (
updated:>= / created:>=), the way issueSearchQuery.ts does for issues.
- A per-provider entry in
PullRequestSearchCapabilities / getSupportedFilters().pullRequestSearch, so a consumer can predict a refusal rather than discover it — the same all-or-nothing validation the issue side relies on.
Provider coverage
GitHub/GHE express updated: / created: natively; other providers declare it unsupported in the capability table (the read refuses, not degrades — matching the PR-search coverage contract established in #5665).
Follow-up to #5665, which shipped the PR search base (searchPullRequestsPage + structured criteria + capability table). This adds the date channel the issue side already has.
Summary
IssueSearchCriteriacarriesupdatedAfter/createdAfter(ISOYYYY-MM-DD), translated toupdated:>=/created:>=qualifiers inpackages/plus/git-github/src/api/issueSearchQuery.tsand declared per provider ingetSupportedFilters().issueSearch.PullRequestSearchCriteria(packages/git/src/models/pullRequest.ts) has no date channel at all — it is{ text, relationships, states, includeArchived }.Why it matters
A date window is the most effective narrowing on a large scope (the issue-side model comment says exactly that), and it is what lets a consumer bound a broad PR read instead of draining every page. The two halves of one search box diverge today: issue search can constrain by recency, PR search cannot. It is also the sharper bound the closed-PR read wants — a recency window (
updated:>=) is currently not expressible for PRs, so callers fall back to capping page iterations.What we need
updatedAfter?/createdAfter?onPullRequestSearchCriteria, mirroringIssueSearchCriteria(ISOYYYY-MM-DD).updated:>=/created:>=), the wayissueSearchQuery.tsdoes for issues.PullRequestSearchCapabilities/getSupportedFilters().pullRequestSearch, so a consumer can predict a refusal rather than discover it — the same all-or-nothing validation the issue side relies on.Provider coverage
GitHub/GHE express
updated:/created:natively; other providers declare it unsupported in the capability table (the read refuses, not degrades — matching the PR-search coverage contract established in #5665).Follow-up to #5665, which shipped the PR search base (
searchPullRequestsPage+ structured criteria + capability table). This adds the date channel the issue side already has.