@gitkraken/core-gitlens 0.5.108 → 0.5.110

package/dist/plus/integrations/results.d.ts

@@ -1,3 +1,5 @@
+import type { IssueSorting } from '../../git/models/issue.js';
+import type { PullRequestSorting } from '../../git/models/pullRequest.js';
 import type { IntegrationIds } from './constants.js';
 export interface ConnectionStateChangeEvent {
     key: string;
@@ -70,6 +72,19 @@ export interface ProviderWarningOmission {
     limit?: number;
     /** Total matches the provider reported, when it reports one. Only GitHub's search cap does today. */
     totalCount?: number;
+    /**
+     * The order the reachable window was selected under, as `field:direction`, when the omission is a result
+     * ceiling.
+     *
+     * Present so a consumer can word its own "N matched, showing the first M" without assuming WHICH M: the
+     * provider serves the top M under this key, so the sentence is only true if it names it. Absent for every
+     * omission that isn't a ceiling, where no window was selected by an order.
+     *
+     * A union of both vocabularies rather than the issue one alone: `PullRequestSorting` happens to be a subset
+     * today, so narrowing this to {@link IssueSorting} would still compile while describing only half the reads
+     * that set it — and would break the day the PR search gains a key the issue search has no name for.
+     */
+    sort?: IssueSorting | PullRequestSorting;
     /** Which repository / project / resource was affected, when one is attributed. */
     scope?: ProviderWarningOmissionScope;
 }

package/dist/plus/integrations/results.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"results.d.ts","sourceRoot":"","sources":["../../../src/plus/integrations/results.ts"],"names":[],"mappings":"AACA,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,gBAAgB,CAAC;AAErD,MAAM,WAAW,0BAA0B;IAC1C,GAAG,EAAE,MAAM,CAAC;IACZ,MAAM,EAAE,WAAW,GAAG,cAAc,CAAC;CACrC;AAED;;;;;;GAMG;AACH,MAAM,MAAM,mBAAmB,GAAG,MAAM,GAAG,YAAY,GAAG,WAAW,GAAG,eAAe,GAAG,OAAO,CAAC;AAElG;;;;;;;;;;;;;;GAcG;AACH,MAAM,MAAM,2BAA2B,GAAG,gBAAgB,GAAG,iBAAiB,GAAG,uBAAuB,CAAC;AAEzG;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,MAAM,MAAM,+BAA+B,GAAG,MAAM,GAAG,aAAa,CAAC;AAErE,sHAAsH;AACtH,MAAM,WAAW,4BAA4B;IAC5C,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,YAAY,CAAC,EAAE,MAAM,CAAC;CACtB;AAED,MAAM,WAAW,uBAAuB;IACvC,IAAI,EAAE,2BAA2B,CAAC;IAClC;;;OAGG;IACH,QAAQ,EAAE,+BAA+B,CAAC;IAC1C;;;OAGG;IACH,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,qGAAqG;IACrG,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,kFAAkF;IAClF,KAAK,CAAC,EAAE,4BAA4B,CAAC;CACrC;AAED,MAAM,WAAW,eAAe;IAC/B,UAAU,EAAE,cAAc,CAAC;IAC3B,sGAAsG;IACtG,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,gGAAgG;IAChG,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,OAAO,EAAE,MAAM,CAAC;IAChB,IAAI,EAAE,mBAAmB,CAAC;IAC1B,+CAA+C;IAC/C,MAAM,EAAE,OAAO,CAAC;IAChB;;;;;;;;;;;;;;;;;;;;;OAqBG;IACH,QAAQ,CAAC,EAAE,uBAAuB,CAAC;CACnC;AAED,MAAM,WAAW,gBAAgB;IAChC;;;;;;;;;;;;;;;;OAgBG;IACH,WAAW,EAAE,MAAM,CAAC;IACpB;;;;;;;;;;;OAWG;IACH,YAAY,EAAE,MAAM,CAAC;IACrB;;;;;;;;OAQG;IACH,QAAQ,CAAC,EAAE,OAAO,CAAC;IACnB;;;;;;;;;;;;OAYG;IACH,SAAS,CAAC,EAAE,OAAO,CAAC;CACpB;AAED,MAAM,WAAW,cAAc,CAAC,CAAC;IAChC,KAAK,EAAE,CAAC,EAAE,CAAC;IACX,QAAQ,EAAE,eAAe,EAAE,CAAC;IAC5B;;;;OAIG;IACH,WAAW,CAAC,EAAE,OAAO,CAAC;CACtB;AAED,MAAM,WAAW,mBAAmB,CAAC,CAAC,CAAE,SAAQ,cAAc,CAAC,CAAC,CAAC;IAChE,IAAI,EAAE,gBAAgB,CAAC;IACvB,OAAO,EAAE,OAAO,CAAC;IACjB;;;;;OAKG;IACH,MAAM,CAAC,EAAE,MAAM,CAAC;CAChB;AAED,MAAM,WAAW,mBAAmB,CAAC,CAAC,CAAE,SAAQ,cAAc,CAAC,CAAC,CAAC;IAChE,IAAI,EAAE,gBAAgB,CAAC;IACvB,OAAO,EAAE,OAAO,CAAC;IACjB;;;OAGG;IACH,iBAAiB,EAAE,cAAc,EAAE,CAAC;IACpC;;;;;;OAMG;IACH,qBAAqB,EAAE,cAAc,EAAE,CAAC;CACxC;AAED,MAAM,WAAW,qBAAqB,CAAC,CAAC,CAAE,SAAQ,mBAAmB,CAAC,CAAC,CAAC;IACvE,oBAAoB,EAAE,cAAc,EAAE,CAAC;IACvC,2EAA2E;IAC3E,iBAAiB,EAAE,cAAc,EAAE,CAAC;IACpC,8FAA8F;IAC9F,qBAAqB,EAAE,cAAc,EAAE,CAAC;IACxC,WAAW,EAAE,MAAM,CAAC;CACpB;AAED,MAAM,MAAM,0BAA0B,GACnC,UAAU,GACV,WAAW,GACX,cAAc,GACd,sBAAsB,GACtB,oBAAoB,GACpB,eAAe,GACf,cAAc,CAAC;AAElB,MAAM,WAAW,kBAAkB;IAClC,UAAU,EAAE,cAAc,CAAC;IAC3B,MAAM,EAAE,MAAM,CAAC;IACf,kHAAkH;IAClH,KAAK,EAAE,MAAM,CAAC;IACd,4GAA4G;IAC5G,IAAI,EAAE,MAAM,CAAC;IACb,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,6GAA6G;IAC7G,SAAS,EAAE,MAAM,CAAC;IAClB;;;;OAIG;IACH,OAAO,EAAE,OAAO,CAAC;CACjB;AAED,MAAM,WAAW,oBAAoB;IACpC,MAAM,EAAE,0BAA0B,CAAC;IACnC,QAAQ,CAAC,EAAE,kBAAkB,CAAC;IAC9B,OAAO,CAAC,EAAE,eAAe,CAAC;CAC1B;AAED,MAAM,WAAW,uBAAuB;IACvC,UAAU,EAAE,oBAAoB,CAAC;CACjC;AA4BD;;;GAGG;AACH,MAAM,WAAW,oBAAoB;IACpC,EAAE,EAAE,MAAM,CAAC;IACX,UAAU,EAAE,cAAc,CAAC;IAC3B,IAAI,EAAE,MAAM,CAAC;IACb,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,GAAG,EAAE,MAAM,CAAC;CACZ;AAED,mEAAmE;AACnE,MAAM,WAAW,uBAAuB;IACvC,EAAE,EAAE,MAAM,CAAC;IACX,SAAS,EAAE,MAAM,CAAC;IAClB,IAAI,EAAE,MAAM,CAAC;IACb,2EAA2E;IAC3E,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,uDAAuD;IACvD,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,uCAAuC;IACvC,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,qCAAqC;IACrC,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,yDAAyD;IACzD,aAAa,CAAC,EAAE,MAAM,CAAC;CACvB;AAED;;;;GAIG;AACH,wBAAgB,iBAAiB,CAChC,UAAU,EAAE,cAAc,EAC1B,MAAM,EAAE,MAAM,GAAG,SAAS,EAC1B,YAAY,EAAE,MAAM,GAAG,SAAS,EAChC,EAAE,EAAE,OAAO,GACT,eAAe,CAoBjB;AAED;;;;;;;;;;GAUG;AACH,wBAAgB,kBAAkB,CAAC,KAAK,EAAE,4BAA4B,GAAG,SAAS,GAAG,MAAM,CAI1F;AAsBD;;;;;;;;;;;;GAYG;AACH,wBAAgB,6BAA6B,CAAC,QAAQ,EAAE,eAAe,EAAE,EAAE,WAAW,EAAE,OAAO,GAAG,IAAI,CAerG;AAmBD;;;GAGG;AACH,wBAAgB,oBAAoB,CAAC,IAAI,EAAE,eAAe,EAAE,EAAE,OAAO,EAAE,eAAe,GAAG,IAAI,CAK5F"}
+{"version":3,"file":"results.d.ts","sourceRoot":"","sources":["../../../src/plus/integrations/results.ts"],"names":[],"mappings":"AACA,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,8BAA8B,CAAC;AACjE,OAAO,KAAK,EAAE,kBAAkB,EAAE,MAAM,oCAAoC,CAAC;AAC7E,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,gBAAgB,CAAC;AAErD,MAAM,WAAW,0BAA0B;IAC1C,GAAG,EAAE,MAAM,CAAC;IACZ,MAAM,EAAE,WAAW,GAAG,cAAc,CAAC;CACrC;AAED;;;;;;GAMG;AACH,MAAM,MAAM,mBAAmB,GAAG,MAAM,GAAG,YAAY,GAAG,WAAW,GAAG,eAAe,GAAG,OAAO,CAAC;AAElG;;;;;;;;;;;;;;GAcG;AACH,MAAM,MAAM,2BAA2B,GAAG,gBAAgB,GAAG,iBAAiB,GAAG,uBAAuB,CAAC;AAEzG;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,MAAM,MAAM,+BAA+B,GAAG,MAAM,GAAG,aAAa,CAAC;AAErE,sHAAsH;AACtH,MAAM,WAAW,4BAA4B;IAC5C,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,YAAY,CAAC,EAAE,MAAM,CAAC;CACtB;AAED,MAAM,WAAW,uBAAuB;IACvC,IAAI,EAAE,2BAA2B,CAAC;IAClC;;;OAGG;IACH,QAAQ,EAAE,+BAA+B,CAAC;IAC1C;;;OAGG;IACH,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,qGAAqG;IACrG,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB;;;;;;;;;;;OAWG;IACH,IAAI,CAAC,EAAE,YAAY,GAAG,kBAAkB,CAAC;IACzC,kFAAkF;IAClF,KAAK,CAAC,EAAE,4BAA4B,CAAC;CACrC;AAED,MAAM,WAAW,eAAe;IAC/B,UAAU,EAAE,cAAc,CAAC;IAC3B,sGAAsG;IACtG,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,gGAAgG;IAChG,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,OAAO,EAAE,MAAM,CAAC;IAChB,IAAI,EAAE,mBAAmB,CAAC;IAC1B,+CAA+C;IAC/C,MAAM,EAAE,OAAO,CAAC;IAChB;;;;;;;;;;;;;;;;;;;;;OAqBG;IACH,QAAQ,CAAC,EAAE,uBAAuB,CAAC;CACnC;AAED,MAAM,WAAW,gBAAgB;IAChC;;;;;;;;;;;;;;;;OAgBG;IACH,WAAW,EAAE,MAAM,CAAC;IACpB;;;;;;;;;;;OAWG;IACH,YAAY,EAAE,MAAM,CAAC;IACrB;;;;;;;;OAQG;IACH,QAAQ,CAAC,EAAE,OAAO,CAAC;IACnB;;;;;;;;;;;;OAYG;IACH,SAAS,CAAC,EAAE,OAAO,CAAC;CACpB;AAED,MAAM,WAAW,cAAc,CAAC,CAAC;IAChC,KAAK,EAAE,CAAC,EAAE,CAAC;IACX,QAAQ,EAAE,eAAe,EAAE,CAAC;IAC5B;;;;OAIG;IACH,WAAW,CAAC,EAAE,OAAO,CAAC;CACtB;AAED,MAAM,WAAW,mBAAmB,CAAC,CAAC,CAAE,SAAQ,cAAc,CAAC,CAAC,CAAC;IAChE,IAAI,EAAE,gBAAgB,CAAC;IACvB,OAAO,EAAE,OAAO,CAAC;IACjB;;;;;OAKG;IACH,MAAM,CAAC,EAAE,MAAM,CAAC;CAChB;AAED,MAAM,WAAW,mBAAmB,CAAC,CAAC,CAAE,SAAQ,cAAc,CAAC,CAAC,CAAC;IAChE,IAAI,EAAE,gBAAgB,CAAC;IACvB,OAAO,EAAE,OAAO,CAAC;IACjB;;;OAGG;IACH,iBAAiB,EAAE,cAAc,EAAE,CAAC;IACpC;;;;;;OAMG;IACH,qBAAqB,EAAE,cAAc,EAAE,CAAC;CACxC;AAED,MAAM,WAAW,qBAAqB,CAAC,CAAC,CAAE,SAAQ,mBAAmB,CAAC,CAAC,CAAC;IACvE,oBAAoB,EAAE,cAAc,EAAE,CAAC;IACvC,2EAA2E;IAC3E,iBAAiB,EAAE,cAAc,EAAE,CAAC;IACpC,8FAA8F;IAC9F,qBAAqB,EAAE,cAAc,EAAE,CAAC;IACxC,WAAW,EAAE,MAAM,CAAC;CACpB;AAED,MAAM,MAAM,0BAA0B,GACnC,UAAU,GACV,WAAW,GACX,cAAc,GACd,sBAAsB,GACtB,oBAAoB,GACpB,eAAe,GACf,cAAc,CAAC;AAElB,MAAM,WAAW,kBAAkB;IAClC,UAAU,EAAE,cAAc,CAAC;IAC3B,MAAM,EAAE,MAAM,CAAC;IACf,kHAAkH;IAClH,KAAK,EAAE,MAAM,CAAC;IACd,4GAA4G;IAC5G,IAAI,EAAE,MAAM,CAAC;IACb,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,6GAA6G;IAC7G,SAAS,EAAE,MAAM,CAAC;IAClB;;;;OAIG;IACH,OAAO,EAAE,OAAO,CAAC;CACjB;AAED,MAAM,WAAW,oBAAoB;IACpC,MAAM,EAAE,0BAA0B,CAAC;IACnC,QAAQ,CAAC,EAAE,kBAAkB,CAAC;IAC9B,OAAO,CAAC,EAAE,eAAe,CAAC;CAC1B;AAED,MAAM,WAAW,uBAAuB;IACvC,UAAU,EAAE,oBAAoB,CAAC;CACjC;AA4BD;;;GAGG;AACH,MAAM,WAAW,oBAAoB;IACpC,EAAE,EAAE,MAAM,CAAC;IACX,UAAU,EAAE,cAAc,CAAC;IAC3B,IAAI,EAAE,MAAM,CAAC;IACb,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,GAAG,EAAE,MAAM,CAAC;CACZ;AAED,mEAAmE;AACnE,MAAM,WAAW,uBAAuB;IACvC,EAAE,EAAE,MAAM,CAAC;IACX,SAAS,EAAE,MAAM,CAAC;IAClB,IAAI,EAAE,MAAM,CAAC;IACb,2EAA2E;IAC3E,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,uDAAuD;IACvD,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,uCAAuC;IACvC,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,qCAAqC;IACrC,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,yDAAyD;IACzD,aAAa,CAAC,EAAE,MAAM,CAAC;CACvB;AAED;;;;GAIG;AACH,wBAAgB,iBAAiB,CAChC,UAAU,EAAE,cAAc,EAC1B,MAAM,EAAE,MAAM,GAAG,SAAS,EAC1B,YAAY,EAAE,MAAM,GAAG,SAAS,EAChC,EAAE,EAAE,OAAO,GACT,eAAe,CAoBjB;AAED;;;;;;;;;;GAUG;AACH,wBAAgB,kBAAkB,CAAC,KAAK,EAAE,4BAA4B,GAAG,SAAS,GAAG,MAAM,CAI1F;AAsBD;;;;;;;;;;;;GAYG;AACH,wBAAgB,6BAA6B,CAAC,QAAQ,EAAE,eAAe,EAAE,EAAE,WAAW,EAAE,OAAO,GAAG,IAAI,CAerG;AAmBD;;;GAGG;AACH,wBAAgB,oBAAoB,CAAC,IAAI,EAAE,eAAe,EAAE,EAAE,OAAO,EAAE,eAAe,GAAG,IAAI,CAK5F"}

package/dist/plus/integrations/results.js.map

@@ -1 +1 @@
-{"version":3,"file":"results.js","sourceRoot":"","sources":["../../../src/plus/integrations/results.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,mBAAmB,EAAE,oBAAoB,EAAE,qBAAqB,EAAE,MAAM,wBAAwB,CAAC;AAuQ1G,MAAM,+BAA+B,GAAG,GAAG,CAAC;AAE5C,SAAS,sBAAsB,CAAC,EAAW;IAC1C,MAAM,GAAG,GAAG,CAAC,EAAE,YAAY,KAAK,CAAC,CAAC,CAAC,EAAE,CAAC,OAAO,CAAC,CAAC,CAAC,MAAM,CAAC,EAAE,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC;IACnE,MAAM,OAAO,GAAG,EAA8E,CAAC;IAC/F,MAAM,MAAM,GACX,OAAO,OAAO,EAAE,MAAM,KAAK,QAAQ;QAClC,CAAC,CAAC,OAAO,CAAC,MAAM;QAChB,CAAC,CAAC,OAAO,OAAO,EAAE,QAAQ,EAAE,MAAM,KAAK,QAAQ;YAC9C,CAAC,CAAC,OAAO,CAAC,QAAQ,CAAC,MAAM;YACzB,CAAC,CAAC,SAAS,CAAC;IAEf,4GAA4G;IAC5G,6GAA6G;IAC7G,IAAI,wCAAwC,CAAC,IAAI,CAAC,GAAG,CAAC,EAAE,CAAC;QACxD,OAAO,MAAM,IAAI,IAAI,CAAC,CAAC,CAAC,uCAAuC,MAAM,GAAG,CAAC,CAAC,CAAC,0BAA0B,CAAC;IACvG,CAAC;IAED,IAAI,CAAC,GAAG,EAAE,CAAC;QACV,OAAO,MAAM,IAAI,IAAI,CAAC,CAAC,CAAC,uCAAuC,MAAM,GAAG,CAAC,CAAC,CAAC,0BAA0B,CAAC;IACvG,CAAC;IACD,OAAO,GAAG,CAAC,MAAM,GAAG,+BAA+B;QAClD,CAAC,CAAC,GAAG,GAAG,CAAC,KAAK,CAAC,CAAC,EAAE,+BAA+B,GAAG,CAAC,CAAC,KAAK;QAC3D,CAAC,CAAC,GAAG,CAAC;AACR,CAAC;AA+BD;;;;GAIG;AACH,MAAM,UAAU,iBAAiB,CAChC,UAA0B,EAC1B,MAA0B,EAC1B,YAAgC,EAChC,EAAW;IAEX,IAAI,IAA6B,CAAC;IAClC,IAAI,EAAE,YAAY,mBAAmB,EAAE,CAAC;QACvC,IAAI,GAAG,MAAM,CAAC;IACf,CAAC;SAAM,IAAI,EAAE,YAAY,qBAAqB,EAAE,CAAC;QAChD,IAAI,GAAG,YAAY,CAAC;IACrB,CAAC;SAAM,IAAI,EAAE,YAAY,oBAAoB,EAAE,CAAC;QAC/C,IAAI,GAAG,WAAW,CAAC;IACpB,CAAC;SAAM,CAAC;QACP,IAAI,GAAG,OAAO,CAAC;IAChB,CAAC;IAED,OAAO;QACN,UAAU,EAAE,UAAU;QACtB,MAAM,EAAE,MAAM;QACd,YAAY,EAAE,YAAY;QAC1B,OAAO,EAAE,sBAAsB,CAAC,EAAE,CAAC;QACnC,IAAI,EAAE,IAAI;QACV,MAAM,EAAE,IAAI,KAAK,MAAM;KACvB,CAAC;AACH,CAAC;AAED;;;;;;;;;;GAUG;AACH,MAAM,UAAU,kBAAkB,CAAC,KAA+C;IACjF,OAAO,CAAC,KAAK,EAAE,UAAU,IAAI,EAAE,EAAE,KAAK,EAAE,UAAU,IAAI,EAAE,EAAE,KAAK,EAAE,SAAS,IAAI,EAAE,EAAE,KAAK,EAAE,YAAY,IAAI,EAAE,CAAC,CAAC,IAAI,CAChH,GAAG,CACH,CAAC;AACH,CAAC;AAED;;;;;;;GAOG;AACH,SAAS,0BAA0B,CAAC,QAA6C;IAChF,IAAI,QAAQ,IAAI,IAAI;QAAE,OAAO,EAAE,CAAC;IAEhC,OAAO;QACN,QAAQ,CAAC,IAAI;QACb,QAAQ,CAAC,QAAQ;QACjB,QAAQ,CAAC,KAAK,IAAI,EAAE;QACpB,QAAQ,CAAC,UAAU,IAAI,EAAE;QACzB,kBAAkB,CAAC,QAAQ,CAAC,KAAK,CAAC;KAClC,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;AACb,CAAC;AAED;;;;;;;;;;;;GAYG;AACH,MAAM,UAAU,6BAA6B,CAAC,QAA2B,EAAE,WAAoB;IAC9F,IAAI,CAAC,WAAW,IAAI,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,QAAQ,IAAI,IAAI,CAAC;QAAE,OAAO;IAEpE,MAAM,UAAU,GAAsB,EAAE,CAAC;IACzC,KAAK,MAAM,OAAO,IAAI,QAAQ,EAAE,CAAC;QAChC,IAAI,OAAO,CAAC,QAAQ,IAAI,IAAI,EAAE,CAAC;YAC9B,oBAAoB,CAAC,UAAU,EAAE,OAAO,CAAC,CAAC;YAC1C,SAAS;QACV,CAAC;QAED,MAAM,EAAE,QAAQ,EAAE,SAAS,EAAE,GAAG,IAAI,EAAE,GAAG,OAAO,CAAC;QACjD,oBAAoB,CAAC,UAAU,EAAE,IAAI,CAAC,CAAC;IACxC,CAAC;IAED,QAAQ,CAAC,MAAM,CAAC,CAAC,EAAE,QAAQ,CAAC,MAAM,EAAE,GAAG,UAAU,CAAC,CAAC;AACpD,CAAC;AAED;;;;;GAKG;AACH,SAAS,kBAAkB,CAAC,OAAwB;IACnD,OAAO;QACN,OAAO,CAAC,UAAU;QAClB,OAAO,CAAC,YAAY,IAAI,EAAE;QAC1B,OAAO,CAAC,MAAM,IAAI,EAAE;QACpB,OAAO,CAAC,IAAI;QACZ,0BAA0B,CAAC,OAAO,CAAC,QAAQ,CAAC;QAC5C,OAAO,CAAC,OAAO;KACf,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;AACb,CAAC;AAED;;;GAGG;AACH,MAAM,UAAU,oBAAoB,CAAC,IAAuB,EAAE,OAAwB;IACrF,MAAM,GAAG,GAAG,kBAAkB,CAAC,OAAO,CAAC,CAAC;IACxC,IAAI,IAAI,CAAC,IAAI,CAAC,QAAQ,CAAC,EAAE,CAAC,kBAAkB,CAAC,QAAQ,CAAC,KAAK,GAAG,CAAC;QAAE,OAAO;IAExE,IAAI,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;AACpB,CAAC"}
+{"version":3,"file":"results.js","sourceRoot":"","sources":["../../../src/plus/integrations/results.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,mBAAmB,EAAE,oBAAoB,EAAE,qBAAqB,EAAE,MAAM,wBAAwB,CAAC;AAsR1G,MAAM,+BAA+B,GAAG,GAAG,CAAC;AAE5C,SAAS,sBAAsB,CAAC,EAAW;IAC1C,MAAM,GAAG,GAAG,CAAC,EAAE,YAAY,KAAK,CAAC,CAAC,CAAC,EAAE,CAAC,OAAO,CAAC,CAAC,CAAC,MAAM,CAAC,EAAE,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC;IACnE,MAAM,OAAO,GAAG,EAA8E,CAAC;IAC/F,MAAM,MAAM,GACX,OAAO,OAAO,EAAE,MAAM,KAAK,QAAQ;QAClC,CAAC,CAAC,OAAO,CAAC,MAAM;QAChB,CAAC,CAAC,OAAO,OAAO,EAAE,QAAQ,EAAE,MAAM,KAAK,QAAQ;YAC9C,CAAC,CAAC,OAAO,CAAC,QAAQ,CAAC,MAAM;YACzB,CAAC,CAAC,SAAS,CAAC;IAEf,4GAA4G;IAC5G,6GAA6G;IAC7G,IAAI,wCAAwC,CAAC,IAAI,CAAC,GAAG,CAAC,EAAE,CAAC;QACxD,OAAO,MAAM,IAAI,IAAI,CAAC,CAAC,CAAC,uCAAuC,MAAM,GAAG,CAAC,CAAC,CAAC,0BAA0B,CAAC;IACvG,CAAC;IAED,IAAI,CAAC,GAAG,EAAE,CAAC;QACV,OAAO,MAAM,IAAI,IAAI,CAAC,CAAC,CAAC,uCAAuC,MAAM,GAAG,CAAC,CAAC,CAAC,0BAA0B,CAAC;IACvG,CAAC;IACD,OAAO,GAAG,CAAC,MAAM,GAAG,+BAA+B;QAClD,CAAC,CAAC,GAAG,GAAG,CAAC,KAAK,CAAC,CAAC,EAAE,+BAA+B,GAAG,CAAC,CAAC,KAAK;QAC3D,CAAC,CAAC,GAAG,CAAC;AACR,CAAC;AA+BD;;;;GAIG;AACH,MAAM,UAAU,iBAAiB,CAChC,UAA0B,EAC1B,MAA0B,EAC1B,YAAgC,EAChC,EAAW;IAEX,IAAI,IAA6B,CAAC;IAClC,IAAI,EAAE,YAAY,mBAAmB,EAAE,CAAC;QACvC,IAAI,GAAG,MAAM,CAAC;IACf,CAAC;SAAM,IAAI,EAAE,YAAY,qBAAqB,EAAE,CAAC;QAChD,IAAI,GAAG,YAAY,CAAC;IACrB,CAAC;SAAM,IAAI,EAAE,YAAY,oBAAoB,EAAE,CAAC;QAC/C,IAAI,GAAG,WAAW,CAAC;IACpB,CAAC;SAAM,CAAC;QACP,IAAI,GAAG,OAAO,CAAC;IAChB,CAAC;IAED,OAAO;QACN,UAAU,EAAE,UAAU;QACtB,MAAM,EAAE,MAAM;QACd,YAAY,EAAE,YAAY;QAC1B,OAAO,EAAE,sBAAsB,CAAC,EAAE,CAAC;QACnC,IAAI,EAAE,IAAI;QACV,MAAM,EAAE,IAAI,KAAK,MAAM;KACvB,CAAC;AACH,CAAC;AAED;;;;;;;;;;GAUG;AACH,MAAM,UAAU,kBAAkB,CAAC,KAA+C;IACjF,OAAO,CAAC,KAAK,EAAE,UAAU,IAAI,EAAE,EAAE,KAAK,EAAE,UAAU,IAAI,EAAE,EAAE,KAAK,EAAE,SAAS,IAAI,EAAE,EAAE,KAAK,EAAE,YAAY,IAAI,EAAE,CAAC,CAAC,IAAI,CAChH,GAAG,CACH,CAAC;AACH,CAAC;AAED;;;;;;;GAOG;AACH,SAAS,0BAA0B,CAAC,QAA6C;IAChF,IAAI,QAAQ,IAAI,IAAI;QAAE,OAAO,EAAE,CAAC;IAEhC,OAAO;QACN,QAAQ,CAAC,IAAI;QACb,QAAQ,CAAC,QAAQ;QACjB,QAAQ,CAAC,KAAK,IAAI,EAAE;QACpB,QAAQ,CAAC,UAAU,IAAI,EAAE;QACzB,kBAAkB,CAAC,QAAQ,CAAC,KAAK,CAAC;KAClC,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;AACb,CAAC;AAED;;;;;;;;;;;;GAYG;AACH,MAAM,UAAU,6BAA6B,CAAC,QAA2B,EAAE,WAAoB;IAC9F,IAAI,CAAC,WAAW,IAAI,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,QAAQ,IAAI,IAAI,CAAC;QAAE,OAAO;IAEpE,MAAM,UAAU,GAAsB,EAAE,CAAC;IACzC,KAAK,MAAM,OAAO,IAAI,QAAQ,EAAE,CAAC;QAChC,IAAI,OAAO,CAAC,QAAQ,IAAI,IAAI,EAAE,CAAC;YAC9B,oBAAoB,CAAC,UAAU,EAAE,OAAO,CAAC,CAAC;YAC1C,SAAS;QACV,CAAC;QAED,MAAM,EAAE,QAAQ,EAAE,SAAS,EAAE,GAAG,IAAI,EAAE,GAAG,OAAO,CAAC;QACjD,oBAAoB,CAAC,UAAU,EAAE,IAAI,CAAC,CAAC;IACxC,CAAC;IAED,QAAQ,CAAC,MAAM,CAAC,CAAC,EAAE,QAAQ,CAAC,MAAM,EAAE,GAAG,UAAU,CAAC,CAAC;AACpD,CAAC;AAED;;;;;GAKG;AACH,SAAS,kBAAkB,CAAC,OAAwB;IACnD,OAAO;QACN,OAAO,CAAC,UAAU;QAClB,OAAO,CAAC,YAAY,IAAI,EAAE;QAC1B,OAAO,CAAC,MAAM,IAAI,EAAE;QACpB,OAAO,CAAC,IAAI;QACZ,0BAA0B,CAAC,OAAO,CAAC,QAAQ,CAAC;QAC5C,OAAO,CAAC,OAAO;KACf,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;AACb,CAAC;AAED;;;GAGG;AACH,MAAM,UAAU,oBAAoB,CAAC,IAAuB,EAAE,OAAwB;IACrF,MAAM,GAAG,GAAG,kBAAkB,CAAC,OAAO,CAAC,CAAC;IACxC,IAAI,IAAI,CAAC,IAAI,CAAC,QAAQ,CAAC,EAAE,CAAC,kBAAkB,CAAC,QAAQ,CAAC,KAAK,GAAG,CAAC;QAAE,OAAO;IAExE,IAAI,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;AACpB,CAAC"}

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.108",
+  "version": "0.5.110",
   "license": "SEE LICENSE IN LICENSE",
   "author": {
     "name": "GitKraken",
@@ -220,7 +220,7 @@
     }
   },
   "dependencies": {
-    "@gitkraken/provider-apis": "0.55.0",
+    "@gitkraken/provider-apis": "0.56.0",
     "@octokit/graphql": "9.0.3",
     "@octokit/request": "10.0.11",
     "@octokit/request-error": "7.1.0",

package/src/git/models/issue.ts

@@ -25,6 +25,60 @@ export type IssueSearchRelationship =
 	/** Assigned to nobody. The complement of `any-assignee`, not a broadening of it. */
 	| 'unassigned';
 
+/**
+ * A field an issue read can be ordered by, provider-neutral. No provider expresses all of them: each read
+ * validates the requested key against the capability its provider declares and refuses one it can't express
+ * server-side, rather than serving a differently-ordered list under the name of the one that was asked for.
+ *
+ * `closed` and `resolved` are deliberately SEPARATE, not two names for the same date. Azure DevOps tracks both
+ * and they differ (an issue can be closed without being resolved and resolved without being closed), and Jira
+ * has no close date at all — it models the equivalent as `resolutiondate`. Collapsing them would force one of
+ * those two providers to lie about which date it ordered by.
+ */
+export type IssueSortField =
+	/** Creation date. */
+	| 'created'
+	/** Last activity. */
+	| 'updated'
+	/** Close date. Only where the provider orders by it server-side — notably NOT GitHub. */
+	| 'closed'
+	/** Resolution date (Jira `resolutiondate`, Azure `ResolvedDate`). Distinct from `closed`. */
+	| 'resolved'
+	/** Number of comments. */
+	| 'comments'
+	/** Reactions/upvotes. */
+	| 'reactions'
+	/** The provider's own priority field. */
+	| 'priority'
+	/** Due date. */
+	| 'dueDate'
+	/** Alphabetical by title. */
+	| 'title';
+
+/**
+ * How an issue read is ordered, as `field:direction` — the same shape `BranchSorting`/`TagSorting` already use,
+ * so it is one serializable string a consumer can persist, compare, or bind straight to a setting or a dropdown.
+ */
+export type IssueSorting = `${IssueSortField}:asc` | `${IssueSortField}:desc`;
+
+/**
+ * The order every issue read that HAS a default applies when the caller asks for none: most recently updated
+ * first, which is what those reads served before ordering was an option.
+ *
+ * One definition rather than one per layer, because it is a promise made in several places at once — the criteria
+ * model documents it, the GitHub query emits it, and the result-ceiling warning quotes it — and three copies would
+ * be free to disagree about what "the default" is.
+ *
+ * Note it is not a default every read has, and the two layers differ. The API client's account-wide "my issues"
+ * search (`GitHubApi.searchMyIssues`) never requested an order, so a direct caller omitting `sort` still gets
+ * GitHub's relevance order — the default is opt-in there, to keep that read's already-shipped results unchanged.
+ * The FACADE does apply it: GitHub declares `updated:desc` among its account-wide keys, so
+ * `readAccountWideIssuesPage` resolves the omission to this default and forwards it, and that read's emitted query
+ * gained a `sort:updated` qualifier it did not have before. A read whose surface cannot express even this key is
+ * the only one the facade leaves in the provider's own order.
+ */
+export const defaultIssueSort: IssueSorting = 'updated:desc';
+
 /**
  * What a filtered issue search narrows on: a provider-neutral criteria set, translated to each provider's own
  * query language by its integration.
@@ -67,6 +121,19 @@ export interface IssueSearchCriteria {
 	withoutLinkedPullRequest?: boolean;
 	/** Includes issues in archived repositories, which are excluded by default. */
 	includeArchived?: boolean;
+	/**
+	 * How to order the results. Omitted means `updated:desc`, which is what this search has always served.
+	 *
+	 * Validated like every other criterion — all-or-nothing against {@link IssueSearchCapabilities.sorts}: a key
+	 * the provider can't express server-side refuses the WHOLE read rather than falling back to the default.
+	 * Serving another order is not a smaller error than serving a wider result: combined with the provider's
+	 * result ceiling it returns a different subset than was asked for, and the paging that comes with it describes
+	 * that other subset.
+	 *
+	 * Do not change it mid-pagination. A cursor carries the sort it was produced under, and threading it under a
+	 * different key is refused rather than serving a sequence with gaps and repeats: drop the cursor instead.
+	 */
+	sort?: IssueSorting;
 }
 
 /**
@@ -86,6 +153,12 @@ export interface IssueSearchCapabilities {
 	withoutLinkedPullRequest: boolean;
 	/** Whether {@link IssueSearchCriteria.state} can select anything other than the provider's default (open). */
 	states: boolean;
+	/**
+	 * Sort keys the search can express IN SERVER. Always contains at least `updated:desc` — the historical default
+	 * — when the search exists at all, so it is never empty for a usable surface; a provider without a filtered
+	 * search reports an empty `relationships`, which is already the signal that there is no surface to order.
+	 */
+	sorts: IssueSorting[];
 }
 
 export interface IssueShape extends IssueOrPullRequest {

package/src/git/models/pullRequest.ts

@@ -26,6 +26,15 @@ export interface PullRequestShape extends IssueOrPullRequest {
 	readonly mergeableState?: PullRequestMergeableState;
 	readonly reviewDecision?: PullRequestReviewDecision;
 	readonly reviewRequests?: PullRequestReviewer[];
+	/**
+	 * Reviews already submitted, as opposed to the still-pending {@link reviewRequests}. Absent means the read
+	 * didn't fetch reviews; empty means nobody has reviewed. Those are different answers and neither substitutes
+	 * for the other, so which one you get is provider- and read-dependent: GitHub/GHE carry reviews on the
+	 * repo-scoped read and the filtered search, and on the account-wide read only where `includeReviews` opts
+	 * into the full projection, while GitLab never populates the field at all.
+	 * {@link PullRequestReviewer.commitOid} is the narrower promise: only the full GitHub/GHE projection has it.
+	 */
+	readonly latestReviews?: PullRequestReviewer[];
 	readonly assignees?: PullRequestMember[];
 	readonly project?: IssueProject;
 	readonly number?: number;
@@ -154,12 +163,50 @@ export enum PullRequestFilter {
 	Author = 'author',
 	Assignee = 'assignee',
 	ReviewRequested = 'review-requested',
+	/**
+	 * PRs the user has already reviewed (GitHub `reviewed-by:@me`), as opposed to `ReviewRequested` (a
+	 * still-pending request). Distinguishes "waiting on the author after my review" from "waiting for my
+	 * review". Not expressible on the repo-scoped listing — no provider SDK exposes a reviewed-by axis there —
+	 * so it is advertised for the account-wide read and for the filtered search (which can still bound itself
+	 * to repositories or an org), never under `supportedPullRequestFilters`.
+	 */
+	Reviewed = 'reviewed-by',
 	Mention = 'mention',
 }
 
 /** Selects which pull request states a read should include. `all` covers open + closed + merged. */
 export type PullRequestStateFilter = 'open' | 'closed' | 'merged' | 'all';
 
+/**
+ * A field a pull-request read can be ordered by, provider-neutral.
+ *
+ * Only two, and deliberately so — unlike {@link IssueSortField} this is the INTERSECTION of what GitHub's PR
+ * search can order by server-side and what a {@link PullRequestShape} carries, because the filtered PR search
+ * always merges its relationship × state facets in the facade and so must re-order the union itself (see
+ * `getPullRequestComparator`). `created` and `updated` are both. A field GitHub cannot order PRs by, or one a
+ * merged page can't reproduce, is left out rather than advertised and then approximated: relevance is unstable
+ * and has no comparable value on a merge, and priority is not a pull-request concept on any provider that has PRs.
+ */
+export type PullRequestSortField =
+	/** Creation date. */
+	| 'created'
+	/** Last activity. */
+	| 'updated';
+
+/**
+ * How a pull-request read is ordered, as `field:direction` — the same serializable shape {@link IssueSorting}
+ * and `BranchSorting` use, so a consumer can persist it, compare it, or bind it straight to a setting or dropdown.
+ */
+export type PullRequestSorting = `${PullRequestSortField}:asc` | `${PullRequestSortField}:desc`;
+
+/**
+ * The order the filtered pull-request search applies when the caller asks for none: most recently updated first,
+ * which is what it served before ordering was an option. Named once rather than per layer — the criteria model
+ * documents it, the GitHub query emits it, and the result-ceiling warning quotes it — so the three cannot
+ * disagree about what "the default" is.
+ */
+export const defaultPullRequestSort: PullRequestSorting = 'updated:desc';
+
 /**
  * What the filtered pull-request search narrows on.
  *
@@ -181,8 +228,27 @@ export interface PullRequestSearchCriteria {
 	relationships?: PullRequestFilter[];
 	/** Pull request states to union. Empty/omitted reads open PRs; `all` subsumes every other member. */
 	states?: PullRequestStateFilter[];
+	/** ISO date (`YYYY-MM-DD`). The most effective narrowing criterion by far on a large scope. */
+	updatedAfter?: string;
+	/** ISO date (`YYYY-MM-DD`). */
+	createdAfter?: string;
 	/** Includes PRs from archived repositories. They are excluded by default. */
 	includeArchived?: boolean;
+	/**
+	 * Narrows on draft state: `true` returns only drafts, `false` only ready-for-review PRs. Omitted places no
+	 * constraint. A boolean rather than a truthy flag because `false` is a distinct request, not the absence of one.
+	 */
+	draft?: boolean;
+	/**
+	 * How to order the results. Omitted means `updated:desc`, which is what this search has always served.
+	 *
+	 * Validated all-or-nothing against {@link PullRequestSearchCapabilities.sorts} like every other criterion: a
+	 * key the provider can't express server-side refuses the WHOLE read rather than falling back to the default,
+	 * because combined with the provider's result ceiling another order returns a different subset than was asked
+	 * for and the paging that comes with it describes that other subset. Do not change it mid-pagination — a
+	 * cursor carries the sort it was produced under; drop the cursor instead of threading it under a new key.
+	 */
+	sort?: PullRequestSorting;
 }
 
 /**
@@ -195,11 +261,21 @@ export interface PullRequestSearchCapabilities {
 	/** Individual state values the provider can union in one logical search. */
 	states: PullRequestStateFilter[];
 	text: boolean;
+	updatedAfter: boolean;
+	createdAfter: boolean;
 	includeArchived: boolean;
+	/** Whether the provider can constrain the search by draft state server-side. */
+	draft: boolean;
 	/** Whether the manager's repository-descriptor scope is supported. */
 	repositoryScope: boolean;
 	/** Whether the manager's organization scope is supported. */
 	organizationScope: boolean;
+	/**
+	 * Sort keys the search can express server-side. Always contains at least `updated:desc` — the historical
+	 * default — when the search exists at all, so it is never empty for a usable surface; a provider without a
+	 * filtered PR search reports an empty `relationships`, which is already the signal there is no surface to order.
+	 */
+	sorts: PullRequestSorting[];
 }
 
 export interface PullRequestRef {
@@ -227,6 +303,14 @@ export interface PullRequestReviewer {
 	isCodeOwner?: boolean;
 	reviewer: PullRequestMember;
 	state: PullRequestReviewState;
+	/**
+	 * The head commit oid this review was submitted against (GitHub). Lets a consumer tell "the PR moved past
+	 * my review" (oid !== the PR's current head) from a review still at the tip — without a per-review
+	 * timestamp. Only populated where the full GitHub/GHE projection is selected: the filtered search read, and
+	 * an account-wide sweep that opts in with `includeReviews`. Undefined elsewhere, including reviews the
+	 * repo-scoped read carries natively.
+	 */
+	commitOid?: string;
 }
 
 export type PullRequestRepositoryIdentityDescriptor = RequireSomeWithProps<

package/src/git/utils/issue.utils.ts

@@ -1,4 +1,94 @@
-import type { Issue, IssueRepositoryIdentityDescriptor, IssueShape } from '../models/issue.js';
+import type {
+	Issue,
+	IssueRepositoryIdentityDescriptor,
+	IssueShape,
+	IssueSortField,
+	IssueSorting,
+} from '../models/issue.js';
+import { defaultIssueSort } from '../models/issue.js';
+
+/**
+ * How each sort field is read off an {@link IssueShape}, for the reads that MERGE several provider queries and so
+ * have to order the union themselves instead of letting the provider do it.
+ *
+ * Only the fields the shape actually carries appear. `priority`, `dueDate` and `resolved` are absent because
+ * `IssueOrPullRequest`/`IssueShape` doesn't model them: a provider may well order by them server-side on a
+ * single-query read, but a merged one cannot — which is exactly what {@link getIssueComparator} returning
+ * `undefined` lets its caller refuse, instead of concatenating unordered runs and calling them sorted.
+ */
+const issueSortValues: Partial<Record<IssueSortField, (issue: IssueShape) => number | Date | string | undefined>> = {
+	created: i => i.createdDate,
+	updated: i => i.updatedDate,
+	closed: i => i.closedDate,
+	comments: i => i.commentsCount,
+	reactions: i => i.thumbsUpCount,
+	title: i => i.title,
+};
+
+/**
+ * The order a read that ALWAYS orders is being made under: the caller's key, or the facade's default.
+ *
+ * The one place `?? defaultIssueSort` may be written. Several things downstream must agree on the answer — the
+ * emitted provider qualifier, the fingerprint sealed into a cursor, the comparator that re-sorts a merged page and
+ * the ceiling warning that names the order — and re-deriving the fallback at each is how they come to disagree,
+ * which is not cosmetic: a cursor sealed with a key its query wasn't built with makes the fingerprint check refuse
+ * valid resumptions.
+ *
+ * Note this is for a surface that CAN always order. A read whose provider may not express even the default resolves
+ * through `resolveIssueSort` instead, which can answer "leave the provider's own order".
+ */
+export function effectiveIssueSort(sort: IssueSorting | undefined): IssueSorting {
+	return sort ?? defaultIssueSort;
+}
+
+/**
+ * A comparator for one sort key over normalized issues, or `undefined` when the field isn't derivable from an
+ * {@link IssueShape} — the signal that the key is only honorable on a SINGLE-origin read, where the provider
+ * already ordered the page.
+ *
+ * `@gitkraken/provider-apis` carries a twin of this over its own `Issue` shape (`src/issueSort.ts`), which it uses
+ * for the merges it performs itself. It is not importable — the SDK does not export it, and it takes a different
+ * shape — so the two are separate implementations of one rule, and the rule below is the part that must not drift.
+ *
+ * Missing values sort LAST in both directions. That is deliberately not the same as negating the descending
+ * comparator (which would float them to the front when ascending), and it is why they're partitioned before any
+ * arithmetic rather than mapped to an infinite sentinel: two missing values have to compare equal, and
+ * `-Infinity - -Infinity` is `NaN`, which makes the comparator inconsistent and the resulting order
+ * implementation-defined.
+ *
+ * Note it orders whatever it is handed. Sorting a page that was already capped does not make it the top N.
+ *
+ * KNOWN DIVERGENCE, `title` only: strings are compared by code unit, so `'B' < 'a'`. A single-scope read is
+ * ordered by the provider's own database instead — case-insensitive and accent-aware — so the same `title:asc`
+ * yields "Banana, apple, ábaco" from a merged page and "ábaco, apple, Banana" from one repository. Deliberately
+ * NOT fixed with `localeCompare`: the SDK's twin comparator (which performs the merges core doesn't, notably
+ * GitLab's repo-ids aggregate) compares by code unit, so switching here would make two paths of the SAME
+ * multi-repo read disagree — a worse divergence than the one it closes, and it would break the parity test in
+ * `issueSortCapabilities.test.ts`. Closing this properly means changing the rule on BOTH sides at once; until
+ * then it is a cosmetic ordering difference on one key, not wrong data.
+ */
+export function getIssueComparator(sort: IssueSorting): ((a: IssueShape, b: IssueShape) => number) | undefined {
+	// The union's shape guarantees both halves, so this needs no validation — only the cast tsc can't infer.
+	const [field, direction] = sort.split(':') as [IssueSortField, 'asc' | 'desc'];
+	const getValue = issueSortValues[field];
+	if (getValue == null) return undefined;
+
+	return (a, b) => {
+		const left = toComparable(getValue(a));
+		const right = toComparable(getValue(b));
+		if (left == null || right == null) {
+			if (left == null && right == null) return 0;
+			return left == null ? 1 : -1;
+		}
+
+		const ordered = left < right ? -1 : left > right ? 1 : 0;
+		return direction === 'asc' ? ordered : -ordered;
+	};
+}
+
+function toComparable(value: number | Date | string | undefined): number | string | undefined {
+	return value instanceof Date ? value.getTime() : value;
+}
 
 export function getRepositoryIdentityForIssue(issue: IssueShape | Issue): IssueRepositoryIdentityDescriptor {
 	if (issue.repository == null) throw new Error('Missing repository');

package/src/git/utils/pullRequest.utils.ts

@@ -4,9 +4,58 @@ import type {
 	PullRequestRefs,
 	PullRequestRepositoryIdentityDescriptor,
 	PullRequestShape,
+	PullRequestSortField,
+	PullRequestSorting,
 } from '../models/pullRequest.js';
 import { shortenRevision } from './revision.utils.js';
 
+/**
+ * How each sort field is read off a {@link PullRequestShape}, for the filtered PR search, which MERGES its
+ * relationship × state facets in the facade and so has to order the union itself instead of trusting the
+ * per-facet server order. Only the fields the shape carries appear — the same rule as `getIssueComparator`, and
+ * the reason {@link PullRequestSortField} is just these two.
+ */
+const pullRequestSortValues: Partial<
+	Record<PullRequestSortField, (pr: PullRequestShape) => number | Date | string | undefined>
+> = {
+	created: pr => pr.createdDate,
+	updated: pr => pr.updatedDate,
+};
+
+/**
+ * A comparator for one sort key over normalized pull requests, or `undefined` when the field isn't derivable
+ * from a {@link PullRequestShape} — the signal that the key is only honorable on a SINGLE-origin read where the
+ * provider already ordered the page. Missing values sort LAST in both directions (partitioned before any
+ * arithmetic so two missing values compare equal, exactly as `getIssueComparator` does).
+ *
+ * Note it orders whatever it is handed. Sorting a page already capped at the result ceiling does not make it the
+ * top N.
+ */
+export function getPullRequestComparator(
+	sort: PullRequestSorting,
+): ((a: PullRequestShape, b: PullRequestShape) => number) | undefined {
+	const [field, direction] = sort.split(':') as [PullRequestSortField, 'asc' | 'desc'];
+	const getValue = pullRequestSortValues[field];
+	if (getValue == null) return undefined;
+
+	return (a, b) => {
+		const left = toComparable(getValue(a));
+		const right = toComparable(getValue(b));
+		if (left == null || right == null) {
+			if (left == null && right == null) return 0;
+
+			return left == null ? 1 : -1;
+		}
+
+		const ordered = left < right ? -1 : left > right ? 1 : 0;
+		return direction === 'asc' ? ordered : -ordered;
+	};
+}
+
+function toComparable(value: number | Date | string | undefined): number | string | undefined {
+	return value instanceof Date ? value.getTime() : value;
+}
+
 export interface PullRequestUrlIdentity<TProvider extends string = string> {
 	provider?: TProvider;
 
@@ -143,6 +192,7 @@ export function serializePullRequest(value: PullRequest): PullRequestShape {
 		thumbsUpCount: value.thumbsUpCount,
 		reviewDecision: value.reviewDecision,
 		reviewRequests: value.reviewRequests,
+		latestReviews: value.latestReviews,
 		assignees: value.assignees,
 		authoredByMe: value.authoredByMe,
 		project: value.project