@gitkraken/core-gitlens 0.5.109 → 0.5.111

package/docs/integrations.md

@@ -120,6 +120,7 @@ it with `page` + `hasMore` + `cursor?`. **No read throws for a provider-side fai
 | `listRepos`                  | `ProviderRepositoryShape` | Repos of an `org`, or account-wide user-affiliated repos when `org` is omitted.       |
 | `listPullRequestsPage`       | `PullRequestShape`        | With `repos`: those repos' PRs. Without: the user's PRs account-wide.                 |
 | `searchPullRequestsPage`     | `PullRequestShape`        | PRs involving the user that match structured criteria, optionally repo/org-scoped.    |
+| `countPullRequests`          | `PullRequestCountResult`  | How many PRs match each scope, fetching none of them. See §5.1.                       |
 | `listIssuesPage`             | `IssueShape`              | Same split, for a **git host**'s issues.                                              |
 | `searchIssuesPage`           | `IssueShape`              | Issues matching structured criteria over a repo/org scope — **no** `@me` binding.     |
 | `countIssues`                | `IssueCountResult`        | How many match each scope, fetching none of them. See §5.1.                           |
@@ -280,6 +281,23 @@ const counts = await manager.countIssues({
   double-count overlaps) nor max (it would under-report), so such a scope is refused. Give each relationship
   its own `key`.
 
+**`countPullRequests`** is the PR twin of `countIssues` — same `key`-echo contract, per-scope/per-batch
+isolation, `count: undefined` ≠ zero rule, `exceedsProviderLimit`, and one-relationship-per-scope refusal. It
+takes the same `criteria` as `searchPullRequestsPage` and is validated against the same capability table.
+
+```ts
+const counts = await manager.countPullRequests({
+	providerId: providerId,
+	scopes: [{ key: 'mine-open', repos: repos, criteria: { relationships: [PullRequestFilter.Author] } }],
+});
+```
+
+The one difference is inherent to pull requests: a scope's `states` (open/closed/merged) are counted as
+independent searches, so the reported `count` is the **largest** of them — the same total
+`searchPullRequestsPage` surfaces — not their sum. Because the result ceiling applies per search, that max is
+what `exceedsProviderLimit` compares against. Several states in one scope are therefore fine (they are
+disjoint); only several relationships are refused.
+
 ## 6. Failures: warnings, `fetchFailed`, `truncated`
 
 A per-provider (or per-connection, or per-scope) failure degrades to a **warning attached to a partial
@@ -400,15 +418,21 @@ So intersect against the capability table first:
 
 ```ts
 const supported = manager.getSupportedFilters(providerId); // static, no connection needed
-const capability = repos.length === 0 ? (supported.pullRequestsAccountWide ?? []) : supported.pullRequests;
+const capability = repos.length === 0 ? supported.pullRequestsAccountWide : supported.pullRequests;
 const filters = wanted.filter(f => capability.includes(f));
 ```
 
 - `pullRequests` — the repo-scoped PR read.
-- `pullRequestsAccountWide` — the optional account-wide PR capability. Treat a missing field as empty.
-- `pullRequestSearch` — the filtered PR search (`searchPullRequestsPage`). Always present; empty `relationships`
-  means the provider has no such search. It declares the exact `relationships` and `states`, plus `text`,
-  `includeArchived`, `repositoryScope`, and `organizationScope`.
+- `pullRequestsAccountWide` — the account-wide PR capability. Always reported, empty at worst. Usually
+  the narrower of the two, but **not** a subset of `pullRequests`: `Reviewed` (GitHub `reviewed-by:@me`) is
+  account-wide only, because the repo-scoped read has no reviewed-by axis to constrain. So pick the field by
+  the read you are about to issue rather than intersecting the two.
+- `pullRequestSearch` — the filtered PR search (`searchPullRequestsPage`, and `countPullRequests` over the same
+  criteria). Always present; empty `relationships` means the provider has no such search. It declares the exact
+  `relationships` and `states`, plus `text`, `updatedAfter`, `createdAfter`, `includeArchived`, `draft`,
+  `repositoryScope`, `organizationScope`, and `sorts` — the ordering vocabulary, as `field:direction` keys. A key
+  not in `sorts` refuses the whole read, exactly like an inexpressible filter; `updated:desc` is always in it when
+  the search exists at all, so omitting `criteria.sort` never refuses.
 - `issues` — the **repo-scoped** git-host read, **and** the issue-tracker read
   (`listIssueTrackerIssuesPage` validates against this field).
 - `issuesAccountWide` — the account-wide git-host read only. Usually narrower (GitLab can express
@@ -441,6 +465,11 @@ does the opposite (drops the user scope); passing both on that account-wide read
 them, so requesting both is refused. Note that "all visible issues" is the **omitted** relationship set, not
 `any-assignee` — which excludes unassigned issues.
 
+`ReviewRequested` and `Reviewed` are different questions: the first is a request still waiting on you, the
+second is a PR you have already reviewed (so it is waiting on the author). A "needs my review" surface wants
+both, as separate reads. The review row itself rides along only where the full projection does — the
+filtered search, or a sweep with `includeReviews` — not from `Reviewed` on its own.
+
 `includeReviewRequested` is a legacy account-wide breadth option used only when no explicit `filters` are
 supplied. It remains useful for Bitbucket Cloud, where the reviewer slice requires an expensive
 O(workspaces × repos) fan-out; prefer `filters: [ReviewRequested]` when an exact relationship is required.
@@ -448,6 +477,34 @@ O(workspaces × repos) fan-out; prefer `filters: [ReviewRequested]` when an exac
 Aggregate account-wide PR reads use a lightweight list shape. Stable list fields, body, and branch refs are
 preserved; optional enrichments such as reviews, checks, and stats may be absent.
 
+`includeReviews: true` on an account-wide **sweep** opts back into the full projection (review decision,
+review requests, and `latestReviews` — each with the `commitOid` it was submitted against, so a consumer can
+tell a review still at the tip from one the PR has moved past). GitHub/GHE only: no other provider's
+account-wide read has a projection switch, so those targets return their native shape and the option is a
+breadth request rather than a guarantee — it never refuses. It costs a heavier GraphQL selection, so the read
+drops to the reduced 30-node page and pages for the rest; budget `maxPages` accordingly. That cost is per
+**sweep**, not per relationship: every state × relationship facet uses the heavy selection and each facet is
+its own request per page, and the selection dominates the smaller page. So ask for it on a narrow sweep — the
+relationships that need the review, typically `Reviewed` (plus `ReviewRequested` when the reviewed commit of a
+pending request matters) — and read the rest as a separate lightweight sweep.
+
+It does not change WHICH pull requests come back: every GitHub account-wide read takes the same route
+regardless of the option (the Launchpad ignored-repository and included/ignored-organization qualifiers apply
+either way), so the option is purely projection plus its page cost. What it does scale with is the relationship
+count, since one document holds every facet: five relationships × four states is 20 full-projection selections.
+
+`listPullRequestsPage` has no projection switch. Scoped to `repos` it goes through the provider's repo-scoped
+read, and GitHub's carries `latestReviews` natively; account-wide (no `repos`) it is always the lite shape and
+no option opts it back in. `commitOid` is absent from both: only the full projection populates it.
+
+The paginated read that does carry the full projection is `searchPullRequestsPage` with
+`criteria.relationships` (GitHub/GHE, which is also the only family that exposes a filtered PR search at all):
+its results always include the review projection with `commitOid`, it honors `itemsPerPage`, and one threaded
+cursor page is exactly one upstream request — every relationship × state facet travels in the same query,
+unlike the account-wide read, which spends one request per facet per page. So a surface that pages
+incrementally should ask the search read for `Reviewed` (and `ReviewRequested` as its own read) rather than
+reach for `includeReviews`, which only exists on the all-at-once sweep.
+
 ## 8. Provider capability matrix
 
 Derived from the provider models and `providersMetadata`. ✓ supported · ✗ reported unsupported
@@ -463,6 +520,7 @@ Derived from the provider models and `providersMetadata`. ✓ supported · ✗ r
 | PRs, account-wide            |      ✓       |          ✓           |     ✓     |      ✓       |            ✓            |  ✗   |   ✗    |   ✗    |
 | PR `states` account-wide     |      ✓       |          ✓           |     ✓     |      ✓       |            ✓            |  —   |   —    |   —    |
 | `searchPullRequestsPage`     |      ✓       |          ✗           |     ✗     |      ✗       |            ✗            |  ✗   |   ✗    |   ✗    |
+| `countPullRequests`          |      ✓       |          ✗           |     ✗     |      ✗       |            ✗            |  ✗   |   ✗    |   ✗    |
 | Issues, repo-scoped          |      ✓       |          ✓           |     ✗     |      ✗       |            ✓            |  —   |   —    |   —    |
 | Issues, account-wide         |      ✓       |          ✓           |     ✗     |      ✗       |            ✓            |  —   |   —    |   —    |
 | `searchIssuesPage`           |      ✓       |          ✗           |     ✗     |      ✗       |            ✗            |  ✗   |   ✗    |   ✗    |
@@ -475,13 +533,21 @@ Derived from the provider models and `providersMetadata`. ✓ supported · ✗ r
 Repo-scoped PR filters: GitHub/GHE `Author, Assignee, ReviewRequested, Mention` · GitLab `Author, Assignee,
 ReviewRequested` · Bitbucket + Bitbucket DC `Author, ReviewRequested` · Azure `Author, Assignee,
 ReviewRequested`.
-Account-wide PR filters: GitHub/GHE `Author, Assignee, ReviewRequested, Mention` · GitLab
+Account-wide PR filters: GitHub/GHE `Author, Assignee, ReviewRequested, Reviewed, Mention` · GitLab
 `Author, Assignee, ReviewRequested` · Bitbucket + Bitbucket DC `Author, ReviewRequested` · Azure
-`Author, Assignee, ReviewRequested`.
+`Author, Assignee, ReviewRequested`. `Reviewed` is the one member that is account-wide only — no provider
+exposes a reviewed-by axis on the repo-scoped read, so it is absent from the repo-scoped list above.
 PR **search** capabilities (`getSupportedFilters().pullRequestSearch`): GitHub/GHE express relationships
-`Author, Assignee, ReviewRequested, Mention`, states `open, closed, merged, all`, `text`, `includeArchived`, and
-repository/organization scopes. Every other provider declares empty lists and false flags, so the read is refused
-rather than returning a page that did not apply a requested criterion or scope.
+`Author, Assignee, ReviewRequested, Reviewed, Mention`, states `open, closed, merged, all`, `text`, `updatedAfter`,
+`createdAfter`, `includeArchived`, `draft`, repository/organization scopes, and sorts
+`updated:desc|asc, created:desc|asc`. Every other provider declares empty lists and false flags, so the read is
+refused rather than returning a page that did not apply a requested criterion or scope. `updatedAfter` /
+`createdAfter` are ISO `YYYY-MM-DD` and are the most effective narrowing on a large scope — the way to bound a broad
+closed-PR read, rather than capping page iterations. `draft` is tri-state: `true` returns only drafts, `false` only
+ready-for-review PRs, and omitting it places no constraint — so a consumer sending `draft: false` must not treat it
+as "unset". The sort vocabulary is narrower than the issue search's on purpose: a merged page can only be re-ordered
+by a field a normalized pull request carries, and GitHub PRs have neither a priority nor a relevance that ranks
+stably under the result ceiling.
 Issue filters: GitHub/GHE + Azure + Jira `Author, Assignee, Mention` · GitLab `Author, Assignee` ·
 Linear + Trello `Assignee` · Bitbucket family none.
 Account-wide issue filters: GitHub/GHE `Author, Assignee, Mention` · Azure `Author, Assignee` · GitLab

package/docs/kepler-read-api-parity.md

@@ -159,6 +159,15 @@ refused there rather than serving an unnarrowed list — unimplemented, not impo
 `author_username` compose with AND, so relationships must stay separate drains), and Azure to per-project WIQL.
 `withoutLinkedPullRequest` and free text have no equivalent on either.
 
+**`countPullRequests`** is the PR twin, closing the asymmetry the audit flagged: the PR side had
+`searchPullRequestsPage` but no count probe, so an explicit "search everywhere" on PRs ran blind while the same
+action on issues showed a number. It reuses GitHub's `issueCount`-on-a-zero-node `search` — the same primitive
+`countIssues` uses — over `PullRequestSearchCriteria`, with the same `key`-echo, per-scope isolation, and
+one-relationship-per-scope rules. The one PR-specific decision: a scope's `states` are counted as independent
+searches, so the reported count is the **largest** of them (the total `searchPullRequestsPage` itself surfaces
+via `Math.max` over facets), not their sum, and `exceedsProviderLimit` compares that max against the per-search
+ceiling. GitHub/GHE only, matching `searchPullRequestsPage`.
+
 **Not done, deliberately:** `broadenIssues` was left as-is rather than reimplemented on top of this. It is a
 multi-provider, multi-org fan-out with its own result type and per-org cursor bundle, so only its inner
 per-org read could be swapped; and its "all visible" breadth maps to an OMITTED relationship set, not to

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@gitkraken/core-gitlens",
   "description": "GitLens core — shared Git / AI / GitHub primitives for internal GitKraken consumption",
-  "version": "0.5.109",
+  "version": "0.5.111",
   "license": "SEE LICENSE IN LICENSE",
   "author": {
     "name": "GitKraken",
@@ -217,14 +217,22 @@
     "./utils/env/node/platform.js": {
       "types": "./dist/utils/env/node/platform.d.ts",
       "default": "./dist/utils/env/node/platform.js"
+    },
+    "./utils/keys/chord.js": {
+      "types": "./dist/utils/keys/chord.d.ts",
+      "default": "./dist/utils/keys/chord.js"
+    },
+    "./utils/keys/keybinding.js": {
+      "types": "./dist/utils/keys/keybinding.d.ts",
+      "default": "./dist/utils/keys/keybinding.js"
     }
   },
   "dependencies": {
     "@gitkraken/provider-apis": "0.56.0",
-    "@octokit/graphql": "9.0.3",
-    "@octokit/request": "10.0.11",
-    "@octokit/request-error": "7.1.0",
-    "@octokit/types": "16.0.0",
+    "@octokit/graphql": "9.0.4",
+    "@octokit/request": "10.0.13",
+    "@octokit/request-error": "7.1.1",
+    "@octokit/types": "17.0.0",
     "fast-string-truncated-width": "3.0.3",
     "ignore": "7.0.6",
     "vscode-uri": "3.1.0"