@gitkraken/core-gitlens 0.15.2 → 0.15.3

package/CHANGELOG.md

@@ -6,6 +6,12 @@ The format is based on [Keep a Changelog](http://keepachangelog.com/) and this p
 
 ## [Unreleased]
 
+## [0.15.3] - 2026-10-21
+
+### Fixed
+
+- Fixes Azure DevOps work items reporting an open state when their workflow category is unavailable and no closed date is known, including cheap etag reads. Filtered work item searches and counts now select by workflow category, so Removed work items without closed dates appear under Closed ([#6041](https://github.com/gitkraken/vscode-gitlens/issues/6041)).
+
 ## [0.15.2] - 2026-10-20
 
 ### Changed
@@ -798,7 +804,8 @@ The format is based on [Keep a Changelog](http://keepachangelog.com/) and this p
 
 - Initial release. Bundles `@gitlens/utils`, `@gitlens/git`, `@gitlens/git-cli`, `@gitlens/ai`, and `@gitlens/git-github` into a single core npm package with subpath exports.
 
-[unreleased]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.15.2...HEAD
+[unreleased]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.15.3...HEAD
+[0.15.3]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.15.2...gitkraken:releases/core/v0.15.3
 [0.15.2]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.15.1...gitkraken:releases/core/v0.15.2
 [0.15.1]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.15.0...gitkraken:releases/core/v0.15.1
 [0.15.0]: https://github.com/gitkraken/vscode-gitlens/compare/releases/core/v0.14.0...gitkraken:releases/core/v0.15.0

package/dist/git/models/issue.d.ts

@@ -200,7 +200,7 @@ export declare class Issue implements IssueShape {
   readonly createdDate: Date;
   readonly updatedDate: Date;
   readonly closed: boolean;
-  readonly state: IssueOrPullRequestState;
+  readonly state: IssueOrPullRequestState | undefined;
   readonly author: IssueMember | undefined;
   readonly assignees: IssueMember[];
   readonly repository?: IssueRepository | undefined;
@@ -217,7 +217,7 @@ export declare class Issue implements IssueShape {
   readonly iterations?: IssueIteration[] | undefined;
   readonly projection?: IssueProjection | undefined;
   readonly type = "issue";
-  constructor(provider: ProviderReference, id: string, nodeId: string | undefined, title: string, url: string, createdDate: Date, updatedDate: Date, closed: boolean, state: IssueOrPullRequestState, author: IssueMember | undefined, assignees: IssueMember[], repository?: IssueRepository | undefined, closedDate?: Date | undefined, labels?: IssueLabel[] | undefined, commentsCount?: number | undefined, thumbsUpCount?: number | undefined, body?: string | undefined, project?: IssueProject | undefined, number?: string | undefined, issueType?: string | undefined, providerState?: IssueProviderState | undefined, bodyFormat?: IssueBodyFormat | undefined, iterations?: IssueIteration[] | undefined, projection?: IssueProjection | undefined);
+  constructor(provider: ProviderReference, id: string, nodeId: string | undefined, title: string, url: string, createdDate: Date, updatedDate: Date, closed: boolean, state: IssueOrPullRequestState | undefined, author: IssueMember | undefined, assignees: IssueMember[], repository?: IssueRepository | undefined, closedDate?: Date | undefined, labels?: IssueLabel[] | undefined, commentsCount?: number | undefined, thumbsUpCount?: number | undefined, body?: string | undefined, project?: IssueProject | undefined, number?: string | undefined, issueType?: string | undefined, providerState?: IssueProviderState | undefined, bodyFormat?: IssueBodyFormat | undefined, iterations?: IssueIteration[] | undefined, projection?: IssueProjection | undefined);
   static is(issue: unknown): issue is Issue;
 }
 export type IssueBodyFormat = 'markdown' | 'jira-wiki';

package/dist/git/models/issue.js.map

@@ -1 +1 @@
-{"version":3,"file":"issue.js","names":[],"sources":["../../../../git/src/models/issue.ts"],"sourcesContent":["import { loggable } from '@gitlens/utils/decorators/log.js';\nimport type { RequireSome, RequireSomeWithProps } from '@gitlens/utils/types.js';\nimport type { IssueOrPullRequest, IssueOrPullRequestState } from './issueOrPullRequest.js';\nimport type { ProviderReference } from './remoteProvider.js';\nimport type { RepositoryIdentityDescriptor } from './repositoryIdentities.js';\n\n/** Selects which issue states a read should include. `all` covers open + closed. */\nexport type IssueStateFilter = 'open' | 'closed' | 'all';\n\n/**\n * One relationship a filtered issue search can constrain on.\n *\n * The last two are USER-INDEPENDENT — they describe the issue, not the caller — and neither is a SCOPE: either\n * one alone matches every such issue on the host, so a search using one still needs a repository/org scope.\n */\nexport type IssueSearchRelationship =\n\t/** Authored by the current user. */\n\t| 'authored'\n\t/** Assigned to the current user. */\n\t| 'assigned'\n\t/** Mentions the current user. */\n\t| 'mentioned'\n\t/** Assigned to ANYONE. Excludes unassigned issues — see {@link IssueSearchCriteria.relationships}. */\n\t| 'any-assignee'\n\t/** Assigned to nobody. The complement of `any-assignee`, not a broadening of it. */\n\t| 'unassigned';\n\n/**\n * A field an issue read can be ordered by, provider-neutral. No provider expresses all of them: each read\n * validates the requested key against the capability its provider declares and refuses one it can't express\n * server-side, rather than serving a differently-ordered list under the name of the one that was asked for.\n *\n * `closed` and `resolved` are deliberately SEPARATE, not two names for the same date. Azure DevOps tracks both\n * and they differ (an issue can be closed without being resolved and resolved without being closed), and Jira\n * has no close date at all — it models the equivalent as `resolutiondate`. Collapsing them would force one of\n * those two providers to lie about which date it ordered by.\n */\nexport type IssueSortField =\n\t/** Creation date. */\n\t| 'created'\n\t/** Last activity. */\n\t| 'updated'\n\t/** Close date. Only where the provider orders by it server-side — notably NOT GitHub. */\n\t| 'closed'\n\t/** Resolution date (Jira `resolutiondate`, Azure `ResolvedDate`). Distinct from `closed`. */\n\t| 'resolved'\n\t/** Number of comments. */\n\t| 'comments'\n\t/** Reactions/upvotes. */\n\t| 'reactions'\n\t/** The provider's own priority field. */\n\t| 'priority'\n\t/** Due date. */\n\t| 'dueDate'\n\t/** Alphabetical by title. */\n\t| 'title';\n\n/**\n * How an issue read is ordered, as `field:direction` — the same shape `BranchSorting`/`TagSorting` already use,\n * so it is one serializable string a consumer can persist, compare, or bind straight to a setting or a dropdown.\n */\nexport type IssueSorting = `${IssueSortField}:asc` | `${IssueSortField}:desc`;\n\n/**\n * The order every issue read that HAS a default applies when the caller asks for none: most recently updated\n * first, which is what those reads served before ordering was an option.\n *\n * One definition rather than one per layer, because it is a promise made in several places at once — the criteria\n * model documents it, the GitHub query emits it, and the result-ceiling warning quotes it — and three copies would\n * be free to disagree about what \"the default\" is.\n *\n * Note it is not a default every read has, and the two layers differ. The API client's account-wide \"my issues\"\n * search (`GitHubApi.searchMyIssues`) never requested an order, so a direct caller omitting `sort` still gets\n * GitHub's relevance order — the default is opt-in there, to keep that read's already-shipped results unchanged.\n * The FACADE does apply it: GitHub declares `updated:desc` among its account-wide keys, so\n * `readAccountWideIssuesPage` resolves the omission to this default and forwards it, and that read's emitted query\n * gained a `sort:updated` qualifier it did not have before. A read whose surface cannot express even this key is\n * the only one the facade leaves in the provider's own order.\n */\nexport const defaultIssueSort: IssueSorting = 'updated:desc';\n\n/**\n * What a filtered issue search narrows on: a provider-neutral criteria set, translated to each provider's own\n * query language by its integration.\n *\n * Structured rather than a provider query string so a consumer can render filter chips and hide the ones a\n * provider can't express, and so the same criteria mean the same thing on a provider whose query language looks\n * nothing like GitHub's search syntax. Every field is validated against the provider's declared capability\n * BEFORE the read runs, all-or-nothing: a criterion the provider can't express server-side refuses the whole\n * read rather than serving a list that was never narrowed. Client-side narrowing is not an option — the dropped\n * items still counted toward the page and cursor the provider produced, so a post-filter would leave the items\n * describing a different result set than the paging that came with them.\n */\nexport interface IssueSearchCriteria {\n\t/**\n\t * Relationships to constrain on, OR-ed together (each becomes its own provider query, unioned and deduped).\n\t * Omitted means NO relationship constraint at all — every issue in scope, assigned or not — which requires a\n\t * repository/org scope.\n\t *\n\t * `any-assignee` and `unassigned` partition the scope between them and are mutually exclusive; passing both is\n\t * refused rather than silently dropping one. Note that \"all visible issues\" is the OMITTED case, NOT\n\t * `any-assignee`, which excludes unassigned issues.\n\t */\n\trelationships?: IssueSearchRelationship[];\n\t/**\n\t * Free text, matched by the provider's own relevance rules — NOT a substring match, and not a way to smuggle\n\t * qualifiers: a token that would read as one is dropped, as are quotes and control characters, so text can\n\t * never re-scope the search. The structured criteria are the qualifier channel.\n\t */\n\ttext?: string;\n\t/** Issue states to include. Omitted reads open issues only. */\n\tstate?: IssueStateFilter;\n\t/** Labels the issue must carry — AND-ed, matching GitHub's own `label:` semantics. */\n\tlabels?: string[];\n\tmilestone?: string;\n\t/** ISO date (`YYYY-MM-DD`). The most effective narrowing criterion by far on a large scope. */\n\tupdatedAfter?: string;\n\t/** ISO date (`YYYY-MM-DD`). */\n\tcreatedAfter?: string;\n\t/** Issues with no linked pull request. */\n\twithoutLinkedPullRequest?: boolean;\n\t/** Includes issues in archived repositories, which are excluded by default. */\n\tincludeArchived?: boolean;\n\t/**\n\t * How to order the results. Omitted means `updated:desc`, which is what this search has always served.\n\t *\n\t * Validated like every other criterion — all-or-nothing against {@link IssueSearchCapabilities.sorts}: a key\n\t * the provider can't express server-side refuses the WHOLE read rather than falling back to the default.\n\t * Serving another order is not a smaller error than serving a wider result: combined with the provider's\n\t * result ceiling it returns a different subset than was asked for, and the paging that comes with it describes\n\t * that other subset.\n\t *\n\t * Do not change it mid-pagination. A cursor carries the sort it was produced under, and threading it under a\n\t * different key is refused rather than serving a sequence with gaps and repeats: drop the cursor instead.\n\t */\n\tsort?: IssueSorting;\n}\n\n/**\n * Which {@link IssueSearchCriteria} fields a provider's filtered issue search can express server-side.\n *\n * An empty `relationships` with every flag false means the provider has NO filtered issue search — the read is\n * refused outright, so a consumer should offer neither the surface nor its chips.\n */\nexport interface IssueSearchCapabilities {\n\t/** Relationships the search can constrain on. Empty means the search itself is unsupported. */\n\trelationships: IssueSearchRelationship[];\n\ttext: boolean;\n\tlabels: boolean;\n\tmilestone: boolean;\n\tupdatedAfter: boolean;\n\tcreatedAfter: boolean;\n\twithoutLinkedPullRequest: boolean;\n\t/** Whether {@link IssueSearchCriteria.state} can select anything other than the provider's default (open). */\n\tstates: boolean;\n\t/**\n\t * Sort keys the search can express IN SERVER. Always contains at least `updated:desc` — the historical default\n\t * — when the search exists at all, so it is never empty for a usable surface; a provider without a filtered\n\t * search reports an empty `relationships`, which is already the signal that there is no surface to order.\n\t */\n\tsorts: IssueSorting[];\n}\n\n/**\n * The read that produced an issue row, as a key for `getIssueFieldPresence` (`@gitlens/integrations`). It names a\n * READ, not a field set: the same tag can carry different fields on different providers.\n */\nexport type IssueProjection =\n\t/** A single-item read. */\n\t| 'point'\n\t/** The filtered search. */\n\t| 'search'\n\t/** The account-wide list, and the trackers' \"my issues\". */\n\t| 'account'\n\t/** A repository-scoped list. */\n\t| 'repos'\n\t/** A tracker project's issues (`listIssueTrackerIssuesPage`, `getIssuesForProject`). */\n\t| 'project'\n\t/** The batch read. */\n\t| 'batch';\n\nexport interface IssueShape extends IssueOrPullRequest {\n\t/** `undefined` when the provider can't resolve the author, e.g. a deleted GitHub account */\n\tauthor: IssueMember | undefined;\n\tassignees: IssueMember[];\n\t/** The provider's own workflow state, when it exposes one beyond the normalized open/closed state. */\n\tproviderState?: IssueProviderState;\n\trepository?: IssueRepository;\n\tlabels?: IssueLabel[];\n\tbody?: string;\n\t/**\n\t * The syntax used by `body`. When omitted, consumers should treat `body` as Markdown — except that Azure DevOps\n\t * work items and Bitbucket Cloud issues carry HTML with no `bodyFormat` set.\n\t */\n\tbodyFormat?: IssueBodyFormat;\n\tproject?: IssueProject;\n\tissueType?: string;\n\t/** An issue can belong to several Jira sprints; Azure reports one iteration. */\n\titerations?: IssueIteration[];\n\t/** The read that produced this row. Absent means unknown: a legacy row, or a provider or read not yet tagged. */\n\treadonly projection?: IssueProjection;\n}\n\n@loggable(i => i.id)\nexport class Issue implements IssueShape {\n\treadonly type = 'issue';\n\n\tconstructor(\n\t\tpublic readonly provider: ProviderReference,\n\t\tpublic readonly id: string,\n\t\tpublic readonly nodeId: string | undefined,\n\t\tpublic readonly title: string,\n\t\tpublic readonly url: string,\n\t\tpublic readonly createdDate: Date,\n\t\tpublic readonly updatedDate: Date,\n\t\tpublic readonly closed: boolean,\n\t\tpublic readonly state: IssueOrPullRequestState,\n\t\tpublic readonly author: IssueMember | undefined,\n\t\tpublic readonly assignees: IssueMember[],\n\t\tpublic readonly repository?: IssueRepository,\n\t\tpublic readonly closedDate?: Date,\n\t\tpublic readonly labels?: IssueLabel[],\n\t\tpublic readonly commentsCount?: number,\n\t\tpublic readonly thumbsUpCount?: number,\n\t\tpublic readonly body?: string,\n\t\tpublic readonly project?: IssueProject,\n\t\tpublic readonly number?: string,\n\t\tpublic readonly issueType?: string,\n\t\tpublic readonly providerState?: IssueProviderState,\n\t\tpublic readonly bodyFormat?: IssueBodyFormat,\n\t\tpublic readonly iterations?: IssueIteration[],\n\t\tpublic readonly projection?: IssueProjection,\n\t) {}\n\n\tstatic is(issue: unknown): issue is Issue {\n\t\treturn issue instanceof Issue;\n\t}\n}\n\nexport type IssueBodyFormat = 'markdown' | 'jira-wiki';\n\nexport const enum RepositoryAccessLevel {\n\tAdmin = 100,\n\tMaintain = 40,\n\tWrite = 30,\n\tTriage = 20,\n\tRead = 10,\n\tNone = 0,\n}\n\nexport interface IssueLabel {\n\tcolor?: string;\n\tname: string;\n}\n\n/**\n * Sprint metadata is optional because some providers only report an iteration path. An absent `isActive`\n * means unknown, not inactive, so consumers must not use it to exclude those iterations by default.\n */\nexport interface IssueIteration {\n\t/**\n\t * A sprint id on Jira, the verbatim iteration path on Azure — so it is only meaningful within the provider's\n\t * project, never across providers. Unique at read time but NOT durable: Azure rewrites the path when an\n\t * iteration node is renamed or re-parented, so don't persist it as a long-lived id.\n\t */\n\tid: string;\n\tname: string;\n\tisActive?: boolean;\n\tstartDate?: Date;\n\tendDate?: Date;\n}\n\nexport interface IssueMember {\n\tid: string;\n\t/**\n\t * Absent when the provider exposes no display name for the member. Optional on purpose: a fallback string\n\t * invented here (`'unknown'`, `''`) can't be told apart from a real name downstream, so it can't be undone by a\n\t * consumer that needs to render something else — or nothing at all, as when the member feeds an AI prompt.\n\t * Each consumer picks its own presentation.\n\t */\n\tname?: string;\n\t/** The provider's handle for this person, when it has one — GitHub's login, Azure's `uniqueName` (a UPN,\n\t *  so an email), Bitbucket's mutable `nickname`. Display/labelling only: it is neither guaranteed present\n\t *  (GitLab's native mapper has none) nor a stable identity, so never key a match off it. */\n\tusername?: string;\n\tavatarUrl?: string;\n\turl?: string;\n}\n\nexport type IssueProviderState = {\n\tid?: string;\n\tname: string;\n\tcolor?: string;\n\t/** The provider's workflow category. `CANCELED` is abandoned work (Linear's canceled and duplicate states, Azure's\n\t *  `Removed` category): closed like `DONE`, kept apart so a consumer can tell the two outcomes apart. */\n\tcategory?: 'TO_DO' | 'IN_PROGRESS' | 'DONE' | 'CANCELED';\n};\n\nexport interface IssueProject {\n\tid: string;\n\tname: string;\n\tresourceId: string;\n\tresourceName: string;\n}\n\nexport interface IssueRepository {\n\towner: string;\n\trepo: string;\n\taccessLevel?: RepositoryAccessLevel;\n\turl?: string;\n\tid?: string;\n}\n\nexport type IssueRepositoryIdentityDescriptor = RequireSomeWithProps<\n\tRequireSome<RepositoryIdentityDescriptor<string>, 'provider'>,\n\t'provider',\n\t'id' | 'domain' | 'repoDomain' | 'repoName'\n> &\n\tRequireSomeWithProps<RequireSome<RepositoryIdentityDescriptor<string>, 'remote'>, 'remote', 'domain'>;\n"],"mappings":";;;;;;;;;;;;;;;;;;;;AA+EA,MAAa,mBAAiC;AA6HvC,IAAM,QAAA,SAAN,MAAM,MAA4B;CAIvB;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CA1BjB,OAAgB;CAEhB,YACC,UACA,IACA,QACA,OACA,KACA,aACA,aACA,QACA,OACA,QACA,WACA,YACA,YACA,QACA,eACA,eACA,MACA,SACA,QACA,WACA,eACA,YACA,YACA,YACC;EAxBe,KAAA,WAAA;EACA,KAAA,KAAA;EACA,KAAA,SAAA;EACA,KAAA,QAAA;EACA,KAAA,MAAA;EACA,KAAA,cAAA;EACA,KAAA,cAAA;EACA,KAAA,SAAA;EACA,KAAA,QAAA;EACA,KAAA,SAAA;EACA,KAAA,YAAA;EACA,KAAA,aAAA;EACA,KAAA,aAAA;EACA,KAAA,SAAA;EACA,KAAA,gBAAA;EACA,KAAA,gBAAA;EACA,KAAA,OAAA;EACA,KAAA,UAAA;EACA,KAAA,SAAA;EACA,KAAA,YAAA;EACA,KAAA,gBAAA;EACA,KAAA,aAAA;EACA,KAAA,aAAA;EACA,KAAA,aAAA;CACd;CAEH,OAAO,GAAG,OAAgC;EACzC,OAAO,iBAAA;CACR;AACD;AAlCC,QAAA,SAAA,WAAA,CAAA,UAAS,MAAK,EAAE,EAAE,CAAA,GAAA,KAAA;AAsCnB,IAAkB,wBAAX,yBAAA,uBAAA;CACN,sBAAA,sBAAA,WAAA,OAAA;CACA,sBAAA,sBAAA,cAAA,MAAA;CACA,sBAAA,sBAAA,WAAA,MAAA;CACA,sBAAA,sBAAA,YAAA,MAAA;CACA,sBAAA,sBAAA,UAAA,MAAA;CACA,sBAAA,sBAAA,UAAA,KAAA;;AACD,EAAA,CAAA,CAAA"}
+{"version":3,"file":"issue.js","names":[],"sources":["../../../../git/src/models/issue.ts"],"sourcesContent":["import { loggable } from '@gitlens/utils/decorators/log.js';\nimport type { RequireSome, RequireSomeWithProps } from '@gitlens/utils/types.js';\nimport type { IssueOrPullRequest, IssueOrPullRequestState } from './issueOrPullRequest.js';\nimport type { ProviderReference } from './remoteProvider.js';\nimport type { RepositoryIdentityDescriptor } from './repositoryIdentities.js';\n\n/** Selects which issue states a read should include. `all` covers open + closed. */\nexport type IssueStateFilter = 'open' | 'closed' | 'all';\n\n/**\n * One relationship a filtered issue search can constrain on.\n *\n * The last two are USER-INDEPENDENT — they describe the issue, not the caller — and neither is a SCOPE: either\n * one alone matches every such issue on the host, so a search using one still needs a repository/org scope.\n */\nexport type IssueSearchRelationship =\n\t/** Authored by the current user. */\n\t| 'authored'\n\t/** Assigned to the current user. */\n\t| 'assigned'\n\t/** Mentions the current user. */\n\t| 'mentioned'\n\t/** Assigned to ANYONE. Excludes unassigned issues — see {@link IssueSearchCriteria.relationships}. */\n\t| 'any-assignee'\n\t/** Assigned to nobody. The complement of `any-assignee`, not a broadening of it. */\n\t| 'unassigned';\n\n/**\n * A field an issue read can be ordered by, provider-neutral. No provider expresses all of them: each read\n * validates the requested key against the capability its provider declares and refuses one it can't express\n * server-side, rather than serving a differently-ordered list under the name of the one that was asked for.\n *\n * `closed` and `resolved` are deliberately SEPARATE, not two names for the same date. Azure DevOps tracks both\n * and they differ (an issue can be closed without being resolved and resolved without being closed), and Jira\n * has no close date at all — it models the equivalent as `resolutiondate`. Collapsing them would force one of\n * those two providers to lie about which date it ordered by.\n */\nexport type IssueSortField =\n\t/** Creation date. */\n\t| 'created'\n\t/** Last activity. */\n\t| 'updated'\n\t/** Close date. Only where the provider orders by it server-side — notably NOT GitHub. */\n\t| 'closed'\n\t/** Resolution date (Jira `resolutiondate`, Azure `ResolvedDate`). Distinct from `closed`. */\n\t| 'resolved'\n\t/** Number of comments. */\n\t| 'comments'\n\t/** Reactions/upvotes. */\n\t| 'reactions'\n\t/** The provider's own priority field. */\n\t| 'priority'\n\t/** Due date. */\n\t| 'dueDate'\n\t/** Alphabetical by title. */\n\t| 'title';\n\n/**\n * How an issue read is ordered, as `field:direction` — the same shape `BranchSorting`/`TagSorting` already use,\n * so it is one serializable string a consumer can persist, compare, or bind straight to a setting or a dropdown.\n */\nexport type IssueSorting = `${IssueSortField}:asc` | `${IssueSortField}:desc`;\n\n/**\n * The order every issue read that HAS a default applies when the caller asks for none: most recently updated\n * first, which is what those reads served before ordering was an option.\n *\n * One definition rather than one per layer, because it is a promise made in several places at once — the criteria\n * model documents it, the GitHub query emits it, and the result-ceiling warning quotes it — and three copies would\n * be free to disagree about what \"the default\" is.\n *\n * Note it is not a default every read has, and the two layers differ. The API client's account-wide \"my issues\"\n * search (`GitHubApi.searchMyIssues`) never requested an order, so a direct caller omitting `sort` still gets\n * GitHub's relevance order — the default is opt-in there, to keep that read's already-shipped results unchanged.\n * The FACADE does apply it: GitHub declares `updated:desc` among its account-wide keys, so\n * `readAccountWideIssuesPage` resolves the omission to this default and forwards it, and that read's emitted query\n * gained a `sort:updated` qualifier it did not have before. A read whose surface cannot express even this key is\n * the only one the facade leaves in the provider's own order.\n */\nexport const defaultIssueSort: IssueSorting = 'updated:desc';\n\n/**\n * What a filtered issue search narrows on: a provider-neutral criteria set, translated to each provider's own\n * query language by its integration.\n *\n * Structured rather than a provider query string so a consumer can render filter chips and hide the ones a\n * provider can't express, and so the same criteria mean the same thing on a provider whose query language looks\n * nothing like GitHub's search syntax. Every field is validated against the provider's declared capability\n * BEFORE the read runs, all-or-nothing: a criterion the provider can't express server-side refuses the whole\n * read rather than serving a list that was never narrowed. Client-side narrowing is not an option — the dropped\n * items still counted toward the page and cursor the provider produced, so a post-filter would leave the items\n * describing a different result set than the paging that came with them.\n */\nexport interface IssueSearchCriteria {\n\t/**\n\t * Relationships to constrain on, OR-ed together (each becomes its own provider query, unioned and deduped).\n\t * Omitted means NO relationship constraint at all — every issue in scope, assigned or not — which requires a\n\t * repository/org scope.\n\t *\n\t * `any-assignee` and `unassigned` partition the scope between them and are mutually exclusive; passing both is\n\t * refused rather than silently dropping one. Note that \"all visible issues\" is the OMITTED case, NOT\n\t * `any-assignee`, which excludes unassigned issues.\n\t */\n\trelationships?: IssueSearchRelationship[];\n\t/**\n\t * Free text, matched by the provider's own relevance rules — NOT a substring match, and not a way to smuggle\n\t * qualifiers: a token that would read as one is dropped, as are quotes and control characters, so text can\n\t * never re-scope the search. The structured criteria are the qualifier channel.\n\t */\n\ttext?: string;\n\t/** Issue states to include. Omitted reads open issues only. */\n\tstate?: IssueStateFilter;\n\t/** Labels the issue must carry — AND-ed, matching GitHub's own `label:` semantics. */\n\tlabels?: string[];\n\tmilestone?: string;\n\t/** ISO date (`YYYY-MM-DD`). The most effective narrowing criterion by far on a large scope. */\n\tupdatedAfter?: string;\n\t/** ISO date (`YYYY-MM-DD`). */\n\tcreatedAfter?: string;\n\t/** Issues with no linked pull request. */\n\twithoutLinkedPullRequest?: boolean;\n\t/** Includes issues in archived repositories, which are excluded by default. */\n\tincludeArchived?: boolean;\n\t/**\n\t * How to order the results. Omitted means `updated:desc`, which is what this search has always served.\n\t *\n\t * Validated like every other criterion — all-or-nothing against {@link IssueSearchCapabilities.sorts}: a key\n\t * the provider can't express server-side refuses the WHOLE read rather than falling back to the default.\n\t * Serving another order is not a smaller error than serving a wider result: combined with the provider's\n\t * result ceiling it returns a different subset than was asked for, and the paging that comes with it describes\n\t * that other subset.\n\t *\n\t * Do not change it mid-pagination. A cursor carries the sort it was produced under, and threading it under a\n\t * different key is refused rather than serving a sequence with gaps and repeats: drop the cursor instead.\n\t */\n\tsort?: IssueSorting;\n}\n\n/**\n * Which {@link IssueSearchCriteria} fields a provider's filtered issue search can express server-side.\n *\n * An empty `relationships` with every flag false means the provider has NO filtered issue search — the read is\n * refused outright, so a consumer should offer neither the surface nor its chips.\n */\nexport interface IssueSearchCapabilities {\n\t/** Relationships the search can constrain on. Empty means the search itself is unsupported. */\n\trelationships: IssueSearchRelationship[];\n\ttext: boolean;\n\tlabels: boolean;\n\tmilestone: boolean;\n\tupdatedAfter: boolean;\n\tcreatedAfter: boolean;\n\twithoutLinkedPullRequest: boolean;\n\t/** Whether {@link IssueSearchCriteria.state} can select anything other than the provider's default (open). */\n\tstates: boolean;\n\t/**\n\t * Sort keys the search can express IN SERVER. Always contains at least `updated:desc` — the historical default\n\t * — when the search exists at all, so it is never empty for a usable surface; a provider without a filtered\n\t * search reports an empty `relationships`, which is already the signal that there is no surface to order.\n\t */\n\tsorts: IssueSorting[];\n}\n\n/**\n * The read that produced an issue row, as a key for `getIssueFieldPresence` (`@gitlens/integrations`). It names a\n * READ, not a field set: the same tag can carry different fields on different providers.\n */\nexport type IssueProjection =\n\t/** A single-item read. */\n\t| 'point'\n\t/** The filtered search. */\n\t| 'search'\n\t/** The account-wide list, and the trackers' \"my issues\". */\n\t| 'account'\n\t/** A repository-scoped list. */\n\t| 'repos'\n\t/** A tracker project's issues (`listIssueTrackerIssuesPage`, `getIssuesForProject`). */\n\t| 'project'\n\t/** The batch read. */\n\t| 'batch';\n\nexport interface IssueShape extends IssueOrPullRequest {\n\t/** `undefined` when the provider can't resolve the author, e.g. a deleted GitHub account */\n\tauthor: IssueMember | undefined;\n\tassignees: IssueMember[];\n\t/** The provider's own workflow state, when it exposes one beyond the normalized open/closed state. */\n\tproviderState?: IssueProviderState;\n\trepository?: IssueRepository;\n\tlabels?: IssueLabel[];\n\tbody?: string;\n\t/**\n\t * The syntax used by `body`. When omitted, consumers should treat `body` as Markdown — except that Azure DevOps\n\t * work items and Bitbucket Cloud issues carry HTML with no `bodyFormat` set.\n\t */\n\tbodyFormat?: IssueBodyFormat;\n\tproject?: IssueProject;\n\tissueType?: string;\n\t/** An issue can belong to several Jira sprints; Azure reports one iteration. */\n\titerations?: IssueIteration[];\n\t/** The read that produced this row. Absent means unknown: a legacy row, or a provider or read not yet tagged. */\n\treadonly projection?: IssueProjection;\n}\n\n@loggable(i => i.id)\nexport class Issue implements IssueShape {\n\treadonly type = 'issue';\n\n\tconstructor(\n\t\tpublic readonly provider: ProviderReference,\n\t\tpublic readonly id: string,\n\t\tpublic readonly nodeId: string | undefined,\n\t\tpublic readonly title: string,\n\t\tpublic readonly url: string,\n\t\tpublic readonly createdDate: Date,\n\t\tpublic readonly updatedDate: Date,\n\t\tpublic readonly closed: boolean,\n\t\tpublic readonly state: IssueOrPullRequestState | undefined,\n\t\tpublic readonly author: IssueMember | undefined,\n\t\tpublic readonly assignees: IssueMember[],\n\t\tpublic readonly repository?: IssueRepository,\n\t\tpublic readonly closedDate?: Date,\n\t\tpublic readonly labels?: IssueLabel[],\n\t\tpublic readonly commentsCount?: number,\n\t\tpublic readonly thumbsUpCount?: number,\n\t\tpublic readonly body?: string,\n\t\tpublic readonly project?: IssueProject,\n\t\tpublic readonly number?: string,\n\t\tpublic readonly issueType?: string,\n\t\tpublic readonly providerState?: IssueProviderState,\n\t\tpublic readonly bodyFormat?: IssueBodyFormat,\n\t\tpublic readonly iterations?: IssueIteration[],\n\t\tpublic readonly projection?: IssueProjection,\n\t) {}\n\n\tstatic is(issue: unknown): issue is Issue {\n\t\treturn issue instanceof Issue;\n\t}\n}\n\nexport type IssueBodyFormat = 'markdown' | 'jira-wiki';\n\nexport const enum RepositoryAccessLevel {\n\tAdmin = 100,\n\tMaintain = 40,\n\tWrite = 30,\n\tTriage = 20,\n\tRead = 10,\n\tNone = 0,\n}\n\nexport interface IssueLabel {\n\tcolor?: string;\n\tname: string;\n}\n\n/**\n * Sprint metadata is optional because some providers only report an iteration path. An absent `isActive`\n * means unknown, not inactive, so consumers must not use it to exclude those iterations by default.\n */\nexport interface IssueIteration {\n\t/**\n\t * A sprint id on Jira, the verbatim iteration path on Azure — so it is only meaningful within the provider's\n\t * project, never across providers. Unique at read time but NOT durable: Azure rewrites the path when an\n\t * iteration node is renamed or re-parented, so don't persist it as a long-lived id.\n\t */\n\tid: string;\n\tname: string;\n\tisActive?: boolean;\n\tstartDate?: Date;\n\tendDate?: Date;\n}\n\nexport interface IssueMember {\n\tid: string;\n\t/**\n\t * Absent when the provider exposes no display name for the member. Optional on purpose: a fallback string\n\t * invented here (`'unknown'`, `''`) can't be told apart from a real name downstream, so it can't be undone by a\n\t * consumer that needs to render something else — or nothing at all, as when the member feeds an AI prompt.\n\t * Each consumer picks its own presentation.\n\t */\n\tname?: string;\n\t/** The provider's handle for this person, when it has one — GitHub's login, Azure's `uniqueName` (a UPN,\n\t *  so an email), Bitbucket's mutable `nickname`. Display/labelling only: it is neither guaranteed present\n\t *  (GitLab's native mapper has none) nor a stable identity, so never key a match off it. */\n\tusername?: string;\n\tavatarUrl?: string;\n\turl?: string;\n}\n\nexport type IssueProviderState = {\n\tid?: string;\n\tname: string;\n\tcolor?: string;\n\t/** The provider's workflow category. `CANCELED` is abandoned work (Linear's canceled and duplicate states, Azure's\n\t *  `Removed` category): closed like `DONE`, kept apart so a consumer can tell the two outcomes apart. */\n\tcategory?: 'TO_DO' | 'IN_PROGRESS' | 'DONE' | 'CANCELED';\n};\n\nexport interface IssueProject {\n\tid: string;\n\tname: string;\n\tresourceId: string;\n\tresourceName: string;\n}\n\nexport interface IssueRepository {\n\towner: string;\n\trepo: string;\n\taccessLevel?: RepositoryAccessLevel;\n\turl?: string;\n\tid?: string;\n}\n\nexport type IssueRepositoryIdentityDescriptor = RequireSomeWithProps<\n\tRequireSome<RepositoryIdentityDescriptor<string>, 'provider'>,\n\t'provider',\n\t'id' | 'domain' | 'repoDomain' | 'repoName'\n> &\n\tRequireSomeWithProps<RequireSome<RepositoryIdentityDescriptor<string>, 'remote'>, 'remote', 'domain'>;\n"],"mappings":";;;;;;;;;;;;;;;;;;;;AA+EA,MAAa,mBAAiC;AA6HvC,IAAM,QAAA,SAAN,MAAM,MAA4B;CAIvB;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CA1BjB,OAAgB;CAEhB,YACC,UACA,IACA,QACA,OACA,KACA,aACA,aACA,QACA,OACA,QACA,WACA,YACA,YACA,QACA,eACA,eACA,MACA,SACA,QACA,WACA,eACA,YACA,YACA,YACC;EAxBe,KAAA,WAAA;EACA,KAAA,KAAA;EACA,KAAA,SAAA;EACA,KAAA,QAAA;EACA,KAAA,MAAA;EACA,KAAA,cAAA;EACA,KAAA,cAAA;EACA,KAAA,SAAA;EACA,KAAA,QAAA;EACA,KAAA,SAAA;EACA,KAAA,YAAA;EACA,KAAA,aAAA;EACA,KAAA,aAAA;EACA,KAAA,SAAA;EACA,KAAA,gBAAA;EACA,KAAA,gBAAA;EACA,KAAA,OAAA;EACA,KAAA,UAAA;EACA,KAAA,SAAA;EACA,KAAA,YAAA;EACA,KAAA,gBAAA;EACA,KAAA,aAAA;EACA,KAAA,aAAA;EACA,KAAA,aAAA;CACd;CAEH,OAAO,GAAG,OAAgC;EACzC,OAAO,iBAAA;CACR;AACD;AAlCC,QAAA,SAAA,WAAA,CAAA,UAAS,MAAK,EAAE,EAAE,CAAA,GAAA,KAAA;AAsCnB,IAAkB,wBAAX,yBAAA,uBAAA;CACN,sBAAA,sBAAA,WAAA,OAAA;CACA,sBAAA,sBAAA,cAAA,MAAA;CACA,sBAAA,sBAAA,WAAA,MAAA;CACA,sBAAA,sBAAA,YAAA,MAAA;CACA,sBAAA,sBAAA,UAAA,MAAA;CACA,sBAAA,sBAAA,UAAA,KAAA;;AACD,EAAA,CAAA,CAAA"}

package/dist/git/models/issueOrPullRequest.d.ts

@@ -11,7 +11,8 @@ export interface IssueOrPullRequest {
   readonly updatedDate: Date;
   readonly closedDate?: Date;
   readonly closed: boolean;
-  readonly state: IssueOrPullRequestState;
+  /** Unset when the provider cannot classify the workflow state and supplies no closed date. */
+  readonly state: IssueOrPullRequestState | undefined;
   readonly commentsCount?: number;
   readonly thumbsUpCount?: number;
 }

package/dist/git/models/pullRequest.d.ts

@@ -28,6 +28,7 @@ export type PullRequestProjection =
 /** The coordinate and branch batch reads. */
 'batch';
 export interface PullRequestShape extends IssueOrPullRequest {
+  readonly state: IssueOrPullRequestState;
   readonly author: PullRequestMember;
   /**
    * Canonical base-repository identity returned by the provider. Some providers

package/dist/git/models/pullRequest.js.map

@@ -1 +1 @@
-{"version":3,"file":"pullRequest.js","names":[],"sources":["../../../../git/src/models/pullRequest.ts"],"sourcesContent":["import { formatDate, fromNow } from '@gitlens/utils/date.js';\nimport { loggable } from '@gitlens/utils/decorators/log.js';\nimport { serializable } from '@gitlens/utils/decorators/serializable.js';\nimport type { RequireSome, RequireSomeWithProps } from '@gitlens/utils/types.js';\nimport type { IssueProject, IssueRepository } from './issue.js';\nimport type { IssueOrPullRequest, IssueOrPullRequestState as PullRequestState } from './issueOrPullRequest.js';\nimport type { ProviderReference } from './remoteProvider.js';\nimport type { RepositoryIdentityDescriptor } from './repositoryIdentities.js';\n\nexport type { PullRequestState };\n\n/**\n * The read that produced a pull request row, as a key for `getPullRequestFieldPresence` (`@gitlens/integrations`). It\n * names a READ, not a field set: the same tag can carry different fields on different providers.\n */\nexport type PullRequestProjection =\n\t/** A single-item read: by number, for a branch, or for a commit. */\n\t| 'point'\n\t/** The filtered search with the full projection, and the host's \"my pull requests\" search. */\n\t| 'search'\n\t/** The filtered search with `summary`. */\n\t| 'search-summary'\n\t/** The free-text search (`searchPullRequests`). */\n\t| 'text-search'\n\t/** An account-wide sweep with the full projection (`includeReviews`). */\n\t| 'account'\n\t/** An account-wide list or sweep with the lightweight projection. */\n\t| 'account-summary'\n\t/** A repository-scoped list or sweep. */\n\t| 'repos'\n\t/** A repository-scoped list with `summary`. */\n\t| 'repos-summary'\n\t/** The coordinate and branch batch reads. */\n\t| 'batch';\n\nexport interface PullRequestShape extends IssueOrPullRequest {\n\treadonly author: PullRequestMember;\n\t/**\n\t * Canonical base-repository identity returned by the provider. Some providers\n\t * scope pull-request ids to a repository, so consumers must not have to infer\n\t * identity from optional refs or URLs.\n\t */\n\treadonly repository?: IssueRepository;\n\treadonly mergedDate?: Date;\n\treadonly refs?: PullRequestRefs;\n\treadonly isDraft?: boolean;\n\treadonly additions?: number;\n\treadonly deletions?: number;\n\treadonly filesChanged?: number;\n\treadonly body?: string;\n\treadonly mergeableState?: PullRequestMergeableState;\n\treadonly reviewDecision?: PullRequestReviewDecision;\n\treadonly reviewRequests?: PullRequestReviewer[];\n\t/**\n\t * Reviews already submitted, as opposed to the still-pending {@link reviewRequests}. Absent means the read\n\t * didn't fetch reviews; empty means nobody has reviewed — but only where the read actually fetched them, which\n\t * is provider- and read-dependent: ask `getPullRequestFieldPresence` (`@gitlens/integrations`) for the row's\n\t * `reviews` group rather than trusting an empty array.\n\t * {@link PullRequestReviewer.commitOid} is the narrower promise: only the full GitHub/GHE projection has it.\n\t */\n\treadonly latestReviews?: PullRequestReviewer[];\n\treadonly assignees?: PullRequestMember[];\n\treadonly project?: IssueProject;\n\treadonly stack?: PullRequestStackInfo;\n\treadonly number?: number;\n\treadonly authoredByMe?: boolean;\n\t/**\n\t * The current account as this pull request's members identify it: the identity {@link authoredByMe} was matched\n\t * against, present exactly when that was. A consumer matching {@link reviewRequests} or {@link latestReviews}\n\t * entries to the current user compares against this, not the account `getCurrentAccount` returns: Azure DevOps\n\t * Server gives one person a different id in each collection than at the server level, and the members carry the\n\t * collection's. Core matches `username` too only on GitHub and GitHub Enterprise, whose rows key people by login.\n\t */\n\treadonly viewer?: { readonly id: string; readonly username?: string };\n\t/** The read that produced this row. Absent means unknown: a legacy row, or a provider or read not yet tagged. */\n\treadonly projection?: PullRequestProjection;\n}\n\n@loggable(i => i.id)\n@serializable\nexport class PullRequest implements PullRequestShape {\n\treadonly type = 'pullrequest';\n\n\tconstructor(\n\t\tpublic readonly provider: ProviderReference,\n\t\tpublic readonly author: PullRequestMember,\n\t\tpublic readonly id: string,\n\t\tpublic readonly nodeId: string | undefined,\n\t\tpublic readonly title: string,\n\t\tpublic readonly url: string,\n\t\tpublic readonly repository: IssueRepository,\n\t\tpublic readonly state: PullRequestState,\n\t\tpublic readonly createdDate: Date,\n\t\tpublic readonly updatedDate: Date,\n\t\tpublic readonly closedDate?: Date,\n\t\tpublic readonly mergedDate?: Date,\n\t\tpublic readonly mergeableState?: PullRequestMergeableState,\n\t\tpublic readonly viewerCanUpdate?: boolean,\n\t\tpublic readonly refs?: PullRequestRefs,\n\t\tpublic readonly isDraft?: boolean,\n\t\tpublic readonly additions?: number,\n\t\tpublic readonly deletions?: number,\n\t\tpublic readonly commentsCount?: number,\n\t\tpublic readonly thumbsUpCount?: number,\n\t\tpublic readonly reviewDecision?: PullRequestReviewDecision,\n\t\tpublic readonly reviewRequests?: PullRequestReviewer[],\n\t\tpublic readonly latestReviews?: PullRequestReviewer[],\n\t\tpublic readonly assignees?: PullRequestMember[],\n\t\tpublic readonly statusCheckRollupState?: PullRequestStatusCheckRollupState,\n\t\tpublic readonly project?: IssueProject,\n\t\tpublic readonly version?: number,\n\t\t/** Commits on the head that aren't on the base. Appended rather than slotted with the other counts:\n\t\t *  this constructor is positional and every mapper passes through it. */\n\t\tpublic readonly commitCount?: number,\n\t\tpublic readonly stack?: PullRequestStackInfo,\n\t\tpublic readonly filesChanged?: number,\n\t\t/** The pull request's description, as markdown. */\n\t\tpublic readonly body?: string,\n\t\tpublic readonly number?: number,\n\t\tpublic readonly authoredByMe?: boolean,\n\t\tpublic readonly projection?: PullRequestProjection,\n\t\tpublic readonly viewer?: { readonly id: string; readonly username?: string },\n\t) {}\n\n\tget closed(): boolean {\n\t\treturn this.state === 'closed';\n\t}\n\n\tstatic is(pr: unknown): pr is PullRequest {\n\t\treturn pr instanceof PullRequest;\n\t}\n\n\tstatic formatDate(pr: PullRequestShape, format?: string | null): string {\n\t\treturn formatDate(pr.mergedDate ?? pr.closedDate ?? pr.updatedDate, format ?? 'MMMM Do, YYYY h:mma');\n\t}\n\n\tstatic formatDateFromNow(pr: PullRequestShape): string {\n\t\treturn fromNow(pr.mergedDate ?? pr.closedDate ?? pr.updatedDate);\n\t}\n\n\tstatic formatDateWithStyle(\n\t\tpr: PullRequestShape,\n\t\tformatting: { dateStyle: string; dateFormat: string | null },\n\t): string {\n\t\treturn formatting.dateStyle === 'absolute'\n\t\t\t? PullRequest.formatDate(pr, formatting.dateFormat)\n\t\t\t: PullRequest.formatDateFromNow(pr);\n\t}\n}\n\nexport const enum PullRequestReviewDecision {\n\tApproved = 'Approved',\n\tChangesRequested = 'ChangesRequested',\n\tReviewRequired = 'ReviewRequired',\n}\n\nexport const enum PullRequestMergeableState {\n\tUnknown = 'Unknown',\n\tMergeable = 'Mergeable',\n\tConflicting = 'Conflicting',\n\tFailingChecks = 'FailingChecks',\n\tBlockedByPolicy = 'BlockedByPolicy',\n}\n\nexport const enum PullRequestStatusCheckRollupState {\n\tSuccess = 'success',\n\tPending = 'pending',\n\tFailed = 'failed',\n}\n\nexport const enum PullRequestMergeMethod {\n\tMerge = 'merge',\n\tSquash = 'squash',\n\tRebase = 'rebase',\n}\n\nexport const enum PullRequestReviewState {\n\tApproved = 'APPROVED',\n\tChangesRequested = 'CHANGES_REQUESTED',\n\tCommented = 'COMMENTED',\n\tDismissed = 'DISMISSED',\n\tPending = 'PENDING',\n\tReviewRequested = 'REVIEW_REQUESTED',\n}\n\nexport interface PullRequestComparisonRefs {\n\trepoPath: string;\n\tbase: { ref: string; label: string };\n\thead: { ref: string; label: string };\n}\n\nexport interface PullRequestMember {\n\tid: string;\n\t/**\n\t * Absent when the provider exposes no display name for the member — same contract as `IssueMember.name`: a\n\t * fallback invented here can't be told apart from a real name downstream, so each consumer picks its own\n\t * presentation.\n\t */\n\tname?: string;\n\t/** The provider's handle for this person, when it has one — GitHub's login, Azure's `uniqueName` (a UPN,\n\t *  so an email), Bitbucket's mutable `nickname`. Display/labelling only: it is neither guaranteed present\n\t *  (GitLab's native mapper has none) nor a stable identity, so never key a match off it. */\n\tusername?: string;\n\tavatarUrl?: string;\n\turl?: string;\n}\n\n/** Provider-neutral relationship facets shared by PR listings and filtered PR search. */\nexport enum PullRequestFilter {\n\tAuthor = 'author',\n\tAssignee = 'assignee',\n\tReviewRequested = 'review-requested',\n\t/**\n\t * PRs the user has already reviewed (GitHub `reviewed-by:@me`), as opposed to `ReviewRequested` (a\n\t * still-pending request). Distinguishes \"waiting on the author after my review\" from \"waiting for my\n\t * review\". Not expressible on the repo-scoped listing — no provider SDK exposes a reviewed-by axis there —\n\t * so it is advertised for the account-wide read and for the filtered search (which can still bound itself\n\t * to repositories or an org), never under `supportedPullRequestFilters`.\n\t */\n\tReviewed = 'reviewed-by',\n\tMention = 'mention',\n}\n\n/** Selects which pull request states a read should include. `all` covers open + closed + merged. */\nexport type PullRequestStateFilter = 'open' | 'closed' | 'merged' | 'all';\n\n/**\n * A field a pull-request read can be ordered by, provider-neutral.\n *\n * Only two, and deliberately so — unlike {@link IssueSortField} this is the INTERSECTION of what GitHub's PR\n * search can order by server-side and what a {@link PullRequestShape} carries, because the filtered PR search\n * always merges its relationship × state facets in the facade and so must re-order the union itself (see\n * `getPullRequestComparator`). `created` and `updated` are both. A field GitHub cannot order PRs by, or one a\n * merged page can't reproduce, is left out rather than advertised and then approximated: relevance is unstable\n * and has no comparable value on a merge, and priority is not a pull-request concept on any provider that has PRs.\n */\nexport type PullRequestSortField =\n\t/** Creation date. */\n\t| 'created'\n\t/** Last activity. */\n\t| 'updated';\n\n/**\n * How a pull-request read is ordered, as `field:direction` — the same serializable shape {@link IssueSorting}\n * and `BranchSorting` use, so a consumer can persist it, compare it, or bind it straight to a setting or dropdown.\n */\nexport type PullRequestSorting = `${PullRequestSortField}:asc` | `${PullRequestSortField}:desc`;\n\n/**\n * The order the filtered pull-request search applies when the caller asks for none: most recently updated first,\n * which is what it served before ordering was an option. Named once rather than per layer — the criteria model\n * documents it, the GitHub query emits it, and the result-ceiling warning quotes it — so the three cannot\n * disagree about what \"the default\" is.\n */\nexport const defaultPullRequestSort: PullRequestSorting = 'updated:desc';\n\n/**\n * What the filtered pull-request search narrows on.\n *\n * Structured rather than a provider query string so callers can send free text without giving it a qualifier\n * channel, and can check {@link PullRequestSearchCapabilities} before issuing a read. Every requested criterion\n * is validated all-or-nothing before the provider runs; unsupported criteria never fall through to a wider\n * result set whose paging would no longer describe the returned items.\n *\n * Relationships are OR-ed, as are states. Omitting `relationships` removes the current-user constraint, which is\n * only safe when the manager call supplies a repository or organization scope. Omitting `states` reads open PRs.\n */\nexport interface PullRequestSearchCriteria {\n\t/**\n\t * Free text matched by the provider's own relevance rules. Tokens that look like provider qualifiers are\n\t * removed before the query is built, so text cannot change the search's scope or state.\n\t */\n\ttext?: string;\n\t/** Current-user relationship facets to union. Empty/omitted means no relationship constraint. */\n\trelationships?: PullRequestFilter[];\n\t/** Pull request states to union. Empty/omitted reads open PRs; `all` subsumes every other member. */\n\tstates?: PullRequestStateFilter[];\n\t/** ISO date (`YYYY-MM-DD`). The most effective narrowing criterion by far on a large scope. */\n\tupdatedAfter?: string;\n\t/** ISO date (`YYYY-MM-DD`). */\n\tcreatedAfter?: string;\n\t/** Includes PRs from archived repositories. They are excluded by default. */\n\tincludeArchived?: boolean;\n\t/**\n\t * Narrows on draft state: `true` returns only drafts, `false` only ready-for-review PRs. Omitted places no\n\t * constraint. A boolean rather than a truthy flag because `false` is a distinct request, not the absence of one.\n\t */\n\tdraft?: boolean;\n\t/**\n\t * How to order the results. Omitted means `updated:desc`, which is what this search has always served.\n\t *\n\t * Validated all-or-nothing against {@link PullRequestSearchCapabilities.sorts} like every other criterion: a\n\t * key the provider can't express server-side refuses the WHOLE read rather than falling back to the default,\n\t * because combined with the provider's result ceiling another order returns a different subset than was asked\n\t * for and the paging that comes with it describes that other subset. Do not change it mid-pagination — a\n\t * cursor carries the sort it was produced under; drop the cursor instead of threading it under a new key.\n\t */\n\tsort?: PullRequestSorting;\n}\n\n/**\n * Which {@link PullRequestSearchCriteria} fields and manager-level scopes a provider can express server-side.\n * An empty `relationships` means the provider has no filtered PR search at all.\n */\nexport interface PullRequestSearchCapabilities {\n\t/** Current-user relationship facets the provider can union. Empty means the search itself is unsupported. */\n\trelationships: PullRequestFilter[];\n\t/** Individual state values the provider can union in one logical search. */\n\tstates: PullRequestStateFilter[];\n\ttext: boolean;\n\tupdatedAfter: boolean;\n\tcreatedAfter: boolean;\n\tincludeArchived: boolean;\n\t/** Whether the provider can constrain the search by draft state server-side. */\n\tdraft: boolean;\n\t/** Whether the manager's repository-descriptor scope is supported. */\n\trepositoryScope: boolean;\n\t/** Whether the manager's organization scope is supported. */\n\torganizationScope: boolean;\n\t/**\n\t * Sort keys the search can express server-side. Always contains at least `updated:desc` — the historical\n\t * default — when the search exists at all, so it is never empty for a usable surface; a provider without a\n\t * filtered PR search reports an empty `relationships`, which is already the signal there is no surface to order.\n\t */\n\tsorts: PullRequestSorting[];\n}\n\nexport interface PullRequestRef {\n\t/**\n\t * `undefined` when the ref's repository was deleted (a removed fork): GitHub's rows say so, with `exists` false.\n\t * provider-apis' converters fill `''` instead, so test for a value rather than for `undefined`.\n\t */\n\towner: string | undefined;\n\t/** `undefined` (or `''`) when the ref's repository was deleted, as {@link owner}. */\n\trepo: string | undefined;\n\tbranch: string;\n\tsha: string;\n\texists: boolean;\n\t/**\n\t * Web URL of the ref's repository. `undefined` when the provider cannot resolve it — Azure DevOps embeds an\n\t * abbreviated repository reference in a pull request, so a fork's URL may need a lookup that can fail.\n\t */\n\turl: string | undefined;\n\t/** HTTPS clone URL of the ref's repository, when the provider exposes it. */\n\tcloneHttps?: string;\n\t/** SSH clone URL of the ref's repository, when the provider exposes it. */\n\tcloneSsh?: string;\n\t/** Best-effort flag: whether the ref's repository is a fork. `undefined` when the provider can't tell. */\n\tisFork?: boolean;\n}\n\nexport interface PullRequestRefs {\n\tbase: PullRequestRef & { url: string };\n\thead: PullRequestRef;\n\tisCrossRepository: boolean;\n}\n\n/**\n * A pull request's membership in a stack — an ordered chain of dependent pull requests where each\n * targets the branch of the one below it.\n *\n * `baseRef` is the stack's ultimate target (its trunk) and is NOT the same as `refs.base`, which for\n * anything above the bottom layer names the layer below. Use `refs.base` to diff a single layer; use\n * `baseRef` to answer where the work ultimately lands.\n */\nexport interface PullRequestStackInfo {\n\t/**\n\t * Opaque, and NOT comparable across read paths: GitHub's GraphQL selection returns a node id\n\t * (`PRS_kwDO…`) while its REST stacks endpoint returns a numeric id (`1347135`) that we stringify —\n\t * both verified against the same live stack. Use {@link number} to identify a stack; two views of one\n\t * stack agree there and will not agree here.\n\t */\n\tid: string;\n\t/** Identifies the stack within its repository. */\n\tnumber: number;\n\t/** Total pull requests in the stack. */\n\tsize: number;\n\t/** This pull request's layer, 1-based, where 1 is closest to `baseRef`. */\n\tposition: number;\n\t/** The branch the bottom of the stack targets. */\n\tbaseRef: string;\n}\n\n/**\n * One layer of a stack — the pull request occupying it, and the head ref a rebase or push needs to act\n * on. Unlike {@link PullRequestStackInfo}, which locates a single pull request within a stack, this is\n * the per-layer detail a caller walking the whole stack needs, e.g. to cascade a rebase bottom to top.\n */\nexport interface PullRequestStackLayer {\n\t/** The pull request's number. */\n\tnumber: number;\n\t/** The pull request's head branch name, without a remote prefix. */\n\theadRef: string;\n\t/** The head branch's tip when the stack was read. */\n\theadSha: string;\n\t/** `true` once this layer has landed. */\n\tmerged: boolean;\n\t/** `true` while this layer is still a draft. */\n\tdraft: boolean;\n}\n\n/**\n * A stack's layers, ordered bottom to top. `baseRef` is the stack's ultimate target (its trunk), the\n * same distinction drawn on {@link PullRequestStackInfo} — it is NOT the base of any individual layer\n * above the bottom, which targets the layer below it instead.\n */\nexport interface PullRequestStackLayers {\n\t/** Opaque and not comparable across read paths — see {@link PullRequestStackInfo.id}. */\n\tid: string;\n\tnumber: number;\n\t/** The branch the bottom of the stack targets. */\n\tbaseRef: string;\n\t/** The stack's layers, ordered bottom (closest to {@link baseRef}) to top. */\n\tlayers: PullRequestStackLayer[];\n}\n\nexport interface PullRequestReviewer {\n\tisCodeOwner?: boolean;\n\treviewer: PullRequestMember;\n\tstate: PullRequestReviewState;\n\t/**\n\t * The head commit oid this review was submitted against (GitHub). Lets a consumer tell \"the PR moved past\n\t * my review\" (oid !== the PR's current head) from a review still at the tip — without a per-review\n\t * timestamp. Only populated where the full GitHub/GHE projection is selected: the filtered search read, and\n\t * an account-wide sweep that opts in with `includeReviews`. Undefined elsewhere, including reviews the\n\t * repo-scoped read carries natively.\n\t */\n\tcommitOid?: string;\n\t/**\n\t * The reviewer is a group the current user is a member of (a team or another group, directly or through a group\n\t * nested in it) rather than a person: a request to it is one the user can answer as a member, not one addressed to\n\t * them by name. Only the Azure DevOps reads that resolve the user's groups set it; absent elsewhere, including for\n\t * groups a read could not tell the user belongs to.\n\t */\n\tisMyGroup?: boolean;\n}\n\nexport type PullRequestRepositoryIdentityDescriptor = RequireSomeWithProps<\n\tRequireSome<RepositoryIdentityDescriptor<string>, 'provider'>,\n\t'provider',\n\t'id' | 'domain' | 'repoDomain' | 'repoName'\n> &\n\tRequireSomeWithProps<RequireSome<RepositoryIdentityDescriptor<string>, 'remote'>, 'remote', 'domain'>;\n"],"mappings":";;;;;;AAgFO,IAAM,cAAA,eAAN,MAAM,YAAwC;CAInC;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CAGA;CACA;CACA;CAEA;CACA;CACA;CACA;CACA;CAxCjB,OAAgB;CAEhB,YACC,UACA,QACA,IACA,QACA,OACA,KACA,YACA,OACA,aACA,aACA,YACA,YACA,gBACA,iBACA,MACA,SACA,WACA,WACA,eACA,eACA,gBACA,gBACA,eACA,WACA,wBACA,SACA,SAGA,aACA,OACA,cAEA,MACA,QACA,cACA,YACA,QACC;EAtCe,KAAA,WAAA;EACA,KAAA,SAAA;EACA,KAAA,KAAA;EACA,KAAA,SAAA;EACA,KAAA,QAAA;EACA,KAAA,MAAA;EACA,KAAA,aAAA;EACA,KAAA,QAAA;EACA,KAAA,cAAA;EACA,KAAA,cAAA;EACA,KAAA,aAAA;EACA,KAAA,aAAA;EACA,KAAA,iBAAA;EACA,KAAA,kBAAA;EACA,KAAA,OAAA;EACA,KAAA,UAAA;EACA,KAAA,YAAA;EACA,KAAA,YAAA;EACA,KAAA,gBAAA;EACA,KAAA,gBAAA;EACA,KAAA,iBAAA;EACA,KAAA,iBAAA;EACA,KAAA,gBAAA;EACA,KAAA,YAAA;EACA,KAAA,yBAAA;EACA,KAAA,UAAA;EACA,KAAA,UAAA;EAGA,KAAA,cAAA;EACA,KAAA,QAAA;EACA,KAAA,eAAA;EAEA,KAAA,OAAA;EACA,KAAA,SAAA;EACA,KAAA,eAAA;EACA,KAAA,aAAA;EACA,KAAA,SAAA;CACd;CAEH,IAAI,SAAkB;EACrB,OAAO,KAAK,UAAU;CACvB;CAEA,OAAO,GAAG,IAAgC;EACzC,OAAO,cAAA;CACR;CAEA,OAAO,WAAW,IAAsB,QAAgC;EACvE,OAAO,WAAW,GAAG,cAAc,GAAG,cAAc,GAAG,aAAa,UAAU,qBAAqB;CACpG;CAEA,OAAO,kBAAkB,IAA8B;EACtD,OAAO,QAAQ,GAAG,cAAc,GAAG,cAAc,GAAG,WAAW;CAChE;CAEA,OAAO,oBACN,IACA,YACS;EACT,OAAO,WAAW,cAAc,aAAA,aACjB,WAAW,IAAI,WAAW,UAAU,IAAA,aACpC,kBAAkB,EAAE;CACpC;AACD;AAtEC,cAAA,eAAA,WAAA,CAAA,UAAS,MAAK,EAAE,EAAE,GAClB,YAAA,GAAA,WAAA;AAuED,IAAkB,4BAAX,yBAAA,2BAAA;CACN,0BAAA,cAAA;CACA,0BAAA,sBAAA;CACA,0BAAA,oBAAA;;AACD,EAAA,CAAA,CAAA;AAEA,IAAkB,4BAAX,yBAAA,2BAAA;CACN,0BAAA,aAAA;CACA,0BAAA,eAAA;CACA,0BAAA,iBAAA;CACA,0BAAA,mBAAA;CACA,0BAAA,qBAAA;;AACD,EAAA,CAAA,CAAA;AAEA,IAAkB,oCAAX,yBAAA,mCAAA;CACN,kCAAA,aAAA;CACA,kCAAA,aAAA;CACA,kCAAA,YAAA;;AACD,EAAA,CAAA,CAAA;AAEA,IAAkB,yBAAX,yBAAA,wBAAA;CACN,uBAAA,WAAA;CACA,uBAAA,YAAA;CACA,uBAAA,YAAA;;AACD,EAAA,CAAA,CAAA;AAEA,IAAkB,yBAAX,yBAAA,wBAAA;CACN,uBAAA,cAAA;CACA,uBAAA,sBAAA;CACA,uBAAA,eAAA;CACA,uBAAA,eAAA;CACA,uBAAA,aAAA;CACA,uBAAA,qBAAA;;AACD,EAAA,CAAA,CAAA;;AAyBA,IAAY,oBAAL,yBAAA,mBAAA;CACN,kBAAA,YAAA;CACA,kBAAA,cAAA;CACA,kBAAA,qBAAA;;;;;;;;CAQA,kBAAA,cAAA;CACA,kBAAA,aAAA;;AACD,EAAA,CAAA,CAAA;;;;;;;AAiCA,MAAa,yBAA6C"}
+{"version":3,"file":"pullRequest.js","names":[],"sources":["../../../../git/src/models/pullRequest.ts"],"sourcesContent":["import { formatDate, fromNow } from '@gitlens/utils/date.js';\nimport { loggable } from '@gitlens/utils/decorators/log.js';\nimport { serializable } from '@gitlens/utils/decorators/serializable.js';\nimport type { RequireSome, RequireSomeWithProps } from '@gitlens/utils/types.js';\nimport type { IssueProject, IssueRepository } from './issue.js';\nimport type { IssueOrPullRequest, IssueOrPullRequestState as PullRequestState } from './issueOrPullRequest.js';\nimport type { ProviderReference } from './remoteProvider.js';\nimport type { RepositoryIdentityDescriptor } from './repositoryIdentities.js';\n\nexport type { PullRequestState };\n\n/**\n * The read that produced a pull request row, as a key for `getPullRequestFieldPresence` (`@gitlens/integrations`). It\n * names a READ, not a field set: the same tag can carry different fields on different providers.\n */\nexport type PullRequestProjection =\n\t/** A single-item read: by number, for a branch, or for a commit. */\n\t| 'point'\n\t/** The filtered search with the full projection, and the host's \"my pull requests\" search. */\n\t| 'search'\n\t/** The filtered search with `summary`. */\n\t| 'search-summary'\n\t/** The free-text search (`searchPullRequests`). */\n\t| 'text-search'\n\t/** An account-wide sweep with the full projection (`includeReviews`). */\n\t| 'account'\n\t/** An account-wide list or sweep with the lightweight projection. */\n\t| 'account-summary'\n\t/** A repository-scoped list or sweep. */\n\t| 'repos'\n\t/** A repository-scoped list with `summary`. */\n\t| 'repos-summary'\n\t/** The coordinate and branch batch reads. */\n\t| 'batch';\n\nexport interface PullRequestShape extends IssueOrPullRequest {\n\treadonly state: PullRequestState;\n\treadonly author: PullRequestMember;\n\t/**\n\t * Canonical base-repository identity returned by the provider. Some providers\n\t * scope pull-request ids to a repository, so consumers must not have to infer\n\t * identity from optional refs or URLs.\n\t */\n\treadonly repository?: IssueRepository;\n\treadonly mergedDate?: Date;\n\treadonly refs?: PullRequestRefs;\n\treadonly isDraft?: boolean;\n\treadonly additions?: number;\n\treadonly deletions?: number;\n\treadonly filesChanged?: number;\n\treadonly body?: string;\n\treadonly mergeableState?: PullRequestMergeableState;\n\treadonly reviewDecision?: PullRequestReviewDecision;\n\treadonly reviewRequests?: PullRequestReviewer[];\n\t/**\n\t * Reviews already submitted, as opposed to the still-pending {@link reviewRequests}. Absent means the read\n\t * didn't fetch reviews; empty means nobody has reviewed — but only where the read actually fetched them, which\n\t * is provider- and read-dependent: ask `getPullRequestFieldPresence` (`@gitlens/integrations`) for the row's\n\t * `reviews` group rather than trusting an empty array.\n\t * {@link PullRequestReviewer.commitOid} is the narrower promise: only the full GitHub/GHE projection has it.\n\t */\n\treadonly latestReviews?: PullRequestReviewer[];\n\treadonly assignees?: PullRequestMember[];\n\treadonly project?: IssueProject;\n\treadonly stack?: PullRequestStackInfo;\n\treadonly number?: number;\n\treadonly authoredByMe?: boolean;\n\t/**\n\t * The current account as this pull request's members identify it: the identity {@link authoredByMe} was matched\n\t * against, present exactly when that was. A consumer matching {@link reviewRequests} or {@link latestReviews}\n\t * entries to the current user compares against this, not the account `getCurrentAccount` returns: Azure DevOps\n\t * Server gives one person a different id in each collection than at the server level, and the members carry the\n\t * collection's. Core matches `username` too only on GitHub and GitHub Enterprise, whose rows key people by login.\n\t */\n\treadonly viewer?: { readonly id: string; readonly username?: string };\n\t/** The read that produced this row. Absent means unknown: a legacy row, or a provider or read not yet tagged. */\n\treadonly projection?: PullRequestProjection;\n}\n\n@loggable(i => i.id)\n@serializable\nexport class PullRequest implements PullRequestShape {\n\treadonly type = 'pullrequest';\n\n\tconstructor(\n\t\tpublic readonly provider: ProviderReference,\n\t\tpublic readonly author: PullRequestMember,\n\t\tpublic readonly id: string,\n\t\tpublic readonly nodeId: string | undefined,\n\t\tpublic readonly title: string,\n\t\tpublic readonly url: string,\n\t\tpublic readonly repository: IssueRepository,\n\t\tpublic readonly state: PullRequestState,\n\t\tpublic readonly createdDate: Date,\n\t\tpublic readonly updatedDate: Date,\n\t\tpublic readonly closedDate?: Date,\n\t\tpublic readonly mergedDate?: Date,\n\t\tpublic readonly mergeableState?: PullRequestMergeableState,\n\t\tpublic readonly viewerCanUpdate?: boolean,\n\t\tpublic readonly refs?: PullRequestRefs,\n\t\tpublic readonly isDraft?: boolean,\n\t\tpublic readonly additions?: number,\n\t\tpublic readonly deletions?: number,\n\t\tpublic readonly commentsCount?: number,\n\t\tpublic readonly thumbsUpCount?: number,\n\t\tpublic readonly reviewDecision?: PullRequestReviewDecision,\n\t\tpublic readonly reviewRequests?: PullRequestReviewer[],\n\t\tpublic readonly latestReviews?: PullRequestReviewer[],\n\t\tpublic readonly assignees?: PullRequestMember[],\n\t\tpublic readonly statusCheckRollupState?: PullRequestStatusCheckRollupState,\n\t\tpublic readonly project?: IssueProject,\n\t\tpublic readonly version?: number,\n\t\t/** Commits on the head that aren't on the base. Appended rather than slotted with the other counts:\n\t\t *  this constructor is positional and every mapper passes through it. */\n\t\tpublic readonly commitCount?: number,\n\t\tpublic readonly stack?: PullRequestStackInfo,\n\t\tpublic readonly filesChanged?: number,\n\t\t/** The pull request's description, as markdown. */\n\t\tpublic readonly body?: string,\n\t\tpublic readonly number?: number,\n\t\tpublic readonly authoredByMe?: boolean,\n\t\tpublic readonly projection?: PullRequestProjection,\n\t\tpublic readonly viewer?: { readonly id: string; readonly username?: string },\n\t) {}\n\n\tget closed(): boolean {\n\t\treturn this.state === 'closed';\n\t}\n\n\tstatic is(pr: unknown): pr is PullRequest {\n\t\treturn pr instanceof PullRequest;\n\t}\n\n\tstatic formatDate(pr: PullRequestShape, format?: string | null): string {\n\t\treturn formatDate(pr.mergedDate ?? pr.closedDate ?? pr.updatedDate, format ?? 'MMMM Do, YYYY h:mma');\n\t}\n\n\tstatic formatDateFromNow(pr: PullRequestShape): string {\n\t\treturn fromNow(pr.mergedDate ?? pr.closedDate ?? pr.updatedDate);\n\t}\n\n\tstatic formatDateWithStyle(\n\t\tpr: PullRequestShape,\n\t\tformatting: { dateStyle: string; dateFormat: string | null },\n\t): string {\n\t\treturn formatting.dateStyle === 'absolute'\n\t\t\t? PullRequest.formatDate(pr, formatting.dateFormat)\n\t\t\t: PullRequest.formatDateFromNow(pr);\n\t}\n}\n\nexport const enum PullRequestReviewDecision {\n\tApproved = 'Approved',\n\tChangesRequested = 'ChangesRequested',\n\tReviewRequired = 'ReviewRequired',\n}\n\nexport const enum PullRequestMergeableState {\n\tUnknown = 'Unknown',\n\tMergeable = 'Mergeable',\n\tConflicting = 'Conflicting',\n\tFailingChecks = 'FailingChecks',\n\tBlockedByPolicy = 'BlockedByPolicy',\n}\n\nexport const enum PullRequestStatusCheckRollupState {\n\tSuccess = 'success',\n\tPending = 'pending',\n\tFailed = 'failed',\n}\n\nexport const enum PullRequestMergeMethod {\n\tMerge = 'merge',\n\tSquash = 'squash',\n\tRebase = 'rebase',\n}\n\nexport const enum PullRequestReviewState {\n\tApproved = 'APPROVED',\n\tChangesRequested = 'CHANGES_REQUESTED',\n\tCommented = 'COMMENTED',\n\tDismissed = 'DISMISSED',\n\tPending = 'PENDING',\n\tReviewRequested = 'REVIEW_REQUESTED',\n}\n\nexport interface PullRequestComparisonRefs {\n\trepoPath: string;\n\tbase: { ref: string; label: string };\n\thead: { ref: string; label: string };\n}\n\nexport interface PullRequestMember {\n\tid: string;\n\t/**\n\t * Absent when the provider exposes no display name for the member — same contract as `IssueMember.name`: a\n\t * fallback invented here can't be told apart from a real name downstream, so each consumer picks its own\n\t * presentation.\n\t */\n\tname?: string;\n\t/** The provider's handle for this person, when it has one — GitHub's login, Azure's `uniqueName` (a UPN,\n\t *  so an email), Bitbucket's mutable `nickname`. Display/labelling only: it is neither guaranteed present\n\t *  (GitLab's native mapper has none) nor a stable identity, so never key a match off it. */\n\tusername?: string;\n\tavatarUrl?: string;\n\turl?: string;\n}\n\n/** Provider-neutral relationship facets shared by PR listings and filtered PR search. */\nexport enum PullRequestFilter {\n\tAuthor = 'author',\n\tAssignee = 'assignee',\n\tReviewRequested = 'review-requested',\n\t/**\n\t * PRs the user has already reviewed (GitHub `reviewed-by:@me`), as opposed to `ReviewRequested` (a\n\t * still-pending request). Distinguishes \"waiting on the author after my review\" from \"waiting for my\n\t * review\". Not expressible on the repo-scoped listing — no provider SDK exposes a reviewed-by axis there —\n\t * so it is advertised for the account-wide read and for the filtered search (which can still bound itself\n\t * to repositories or an org), never under `supportedPullRequestFilters`.\n\t */\n\tReviewed = 'reviewed-by',\n\tMention = 'mention',\n}\n\n/** Selects which pull request states a read should include. `all` covers open + closed + merged. */\nexport type PullRequestStateFilter = 'open' | 'closed' | 'merged' | 'all';\n\n/**\n * A field a pull-request read can be ordered by, provider-neutral.\n *\n * Only two, and deliberately so — unlike {@link IssueSortField} this is the INTERSECTION of what GitHub's PR\n * search can order by server-side and what a {@link PullRequestShape} carries, because the filtered PR search\n * always merges its relationship × state facets in the facade and so must re-order the union itself (see\n * `getPullRequestComparator`). `created` and `updated` are both. A field GitHub cannot order PRs by, or one a\n * merged page can't reproduce, is left out rather than advertised and then approximated: relevance is unstable\n * and has no comparable value on a merge, and priority is not a pull-request concept on any provider that has PRs.\n */\nexport type PullRequestSortField =\n\t/** Creation date. */\n\t| 'created'\n\t/** Last activity. */\n\t| 'updated';\n\n/**\n * How a pull-request read is ordered, as `field:direction` — the same serializable shape {@link IssueSorting}\n * and `BranchSorting` use, so a consumer can persist it, compare it, or bind it straight to a setting or dropdown.\n */\nexport type PullRequestSorting = `${PullRequestSortField}:asc` | `${PullRequestSortField}:desc`;\n\n/**\n * The order the filtered pull-request search applies when the caller asks for none: most recently updated first,\n * which is what it served before ordering was an option. Named once rather than per layer — the criteria model\n * documents it, the GitHub query emits it, and the result-ceiling warning quotes it — so the three cannot\n * disagree about what \"the default\" is.\n */\nexport const defaultPullRequestSort: PullRequestSorting = 'updated:desc';\n\n/**\n * What the filtered pull-request search narrows on.\n *\n * Structured rather than a provider query string so callers can send free text without giving it a qualifier\n * channel, and can check {@link PullRequestSearchCapabilities} before issuing a read. Every requested criterion\n * is validated all-or-nothing before the provider runs; unsupported criteria never fall through to a wider\n * result set whose paging would no longer describe the returned items.\n *\n * Relationships are OR-ed, as are states. Omitting `relationships` removes the current-user constraint, which is\n * only safe when the manager call supplies a repository or organization scope. Omitting `states` reads open PRs.\n */\nexport interface PullRequestSearchCriteria {\n\t/**\n\t * Free text matched by the provider's own relevance rules. Tokens that look like provider qualifiers are\n\t * removed before the query is built, so text cannot change the search's scope or state.\n\t */\n\ttext?: string;\n\t/** Current-user relationship facets to union. Empty/omitted means no relationship constraint. */\n\trelationships?: PullRequestFilter[];\n\t/** Pull request states to union. Empty/omitted reads open PRs; `all` subsumes every other member. */\n\tstates?: PullRequestStateFilter[];\n\t/** ISO date (`YYYY-MM-DD`). The most effective narrowing criterion by far on a large scope. */\n\tupdatedAfter?: string;\n\t/** ISO date (`YYYY-MM-DD`). */\n\tcreatedAfter?: string;\n\t/** Includes PRs from archived repositories. They are excluded by default. */\n\tincludeArchived?: boolean;\n\t/**\n\t * Narrows on draft state: `true` returns only drafts, `false` only ready-for-review PRs. Omitted places no\n\t * constraint. A boolean rather than a truthy flag because `false` is a distinct request, not the absence of one.\n\t */\n\tdraft?: boolean;\n\t/**\n\t * How to order the results. Omitted means `updated:desc`, which is what this search has always served.\n\t *\n\t * Validated all-or-nothing against {@link PullRequestSearchCapabilities.sorts} like every other criterion: a\n\t * key the provider can't express server-side refuses the WHOLE read rather than falling back to the default,\n\t * because combined with the provider's result ceiling another order returns a different subset than was asked\n\t * for and the paging that comes with it describes that other subset. Do not change it mid-pagination — a\n\t * cursor carries the sort it was produced under; drop the cursor instead of threading it under a new key.\n\t */\n\tsort?: PullRequestSorting;\n}\n\n/**\n * Which {@link PullRequestSearchCriteria} fields and manager-level scopes a provider can express server-side.\n * An empty `relationships` means the provider has no filtered PR search at all.\n */\nexport interface PullRequestSearchCapabilities {\n\t/** Current-user relationship facets the provider can union. Empty means the search itself is unsupported. */\n\trelationships: PullRequestFilter[];\n\t/** Individual state values the provider can union in one logical search. */\n\tstates: PullRequestStateFilter[];\n\ttext: boolean;\n\tupdatedAfter: boolean;\n\tcreatedAfter: boolean;\n\tincludeArchived: boolean;\n\t/** Whether the provider can constrain the search by draft state server-side. */\n\tdraft: boolean;\n\t/** Whether the manager's repository-descriptor scope is supported. */\n\trepositoryScope: boolean;\n\t/** Whether the manager's organization scope is supported. */\n\torganizationScope: boolean;\n\t/**\n\t * Sort keys the search can express server-side. Always contains at least `updated:desc` — the historical\n\t * default — when the search exists at all, so it is never empty for a usable surface; a provider without a\n\t * filtered PR search reports an empty `relationships`, which is already the signal there is no surface to order.\n\t */\n\tsorts: PullRequestSorting[];\n}\n\nexport interface PullRequestRef {\n\t/**\n\t * `undefined` when the ref's repository was deleted (a removed fork): GitHub's rows say so, with `exists` false.\n\t * provider-apis' converters fill `''` instead, so test for a value rather than for `undefined`.\n\t */\n\towner: string | undefined;\n\t/** `undefined` (or `''`) when the ref's repository was deleted, as {@link owner}. */\n\trepo: string | undefined;\n\tbranch: string;\n\tsha: string;\n\texists: boolean;\n\t/**\n\t * Web URL of the ref's repository. `undefined` when the provider cannot resolve it — Azure DevOps embeds an\n\t * abbreviated repository reference in a pull request, so a fork's URL may need a lookup that can fail.\n\t */\n\turl: string | undefined;\n\t/** HTTPS clone URL of the ref's repository, when the provider exposes it. */\n\tcloneHttps?: string;\n\t/** SSH clone URL of the ref's repository, when the provider exposes it. */\n\tcloneSsh?: string;\n\t/** Best-effort flag: whether the ref's repository is a fork. `undefined` when the provider can't tell. */\n\tisFork?: boolean;\n}\n\nexport interface PullRequestRefs {\n\tbase: PullRequestRef & { url: string };\n\thead: PullRequestRef;\n\tisCrossRepository: boolean;\n}\n\n/**\n * A pull request's membership in a stack — an ordered chain of dependent pull requests where each\n * targets the branch of the one below it.\n *\n * `baseRef` is the stack's ultimate target (its trunk) and is NOT the same as `refs.base`, which for\n * anything above the bottom layer names the layer below. Use `refs.base` to diff a single layer; use\n * `baseRef` to answer where the work ultimately lands.\n */\nexport interface PullRequestStackInfo {\n\t/**\n\t * Opaque, and NOT comparable across read paths: GitHub's GraphQL selection returns a node id\n\t * (`PRS_kwDO…`) while its REST stacks endpoint returns a numeric id (`1347135`) that we stringify —\n\t * both verified against the same live stack. Use {@link number} to identify a stack; two views of one\n\t * stack agree there and will not agree here.\n\t */\n\tid: string;\n\t/** Identifies the stack within its repository. */\n\tnumber: number;\n\t/** Total pull requests in the stack. */\n\tsize: number;\n\t/** This pull request's layer, 1-based, where 1 is closest to `baseRef`. */\n\tposition: number;\n\t/** The branch the bottom of the stack targets. */\n\tbaseRef: string;\n}\n\n/**\n * One layer of a stack — the pull request occupying it, and the head ref a rebase or push needs to act\n * on. Unlike {@link PullRequestStackInfo}, which locates a single pull request within a stack, this is\n * the per-layer detail a caller walking the whole stack needs, e.g. to cascade a rebase bottom to top.\n */\nexport interface PullRequestStackLayer {\n\t/** The pull request's number. */\n\tnumber: number;\n\t/** The pull request's head branch name, without a remote prefix. */\n\theadRef: string;\n\t/** The head branch's tip when the stack was read. */\n\theadSha: string;\n\t/** `true` once this layer has landed. */\n\tmerged: boolean;\n\t/** `true` while this layer is still a draft. */\n\tdraft: boolean;\n}\n\n/**\n * A stack's layers, ordered bottom to top. `baseRef` is the stack's ultimate target (its trunk), the\n * same distinction drawn on {@link PullRequestStackInfo} — it is NOT the base of any individual layer\n * above the bottom, which targets the layer below it instead.\n */\nexport interface PullRequestStackLayers {\n\t/** Opaque and not comparable across read paths — see {@link PullRequestStackInfo.id}. */\n\tid: string;\n\tnumber: number;\n\t/** The branch the bottom of the stack targets. */\n\tbaseRef: string;\n\t/** The stack's layers, ordered bottom (closest to {@link baseRef}) to top. */\n\tlayers: PullRequestStackLayer[];\n}\n\nexport interface PullRequestReviewer {\n\tisCodeOwner?: boolean;\n\treviewer: PullRequestMember;\n\tstate: PullRequestReviewState;\n\t/**\n\t * The head commit oid this review was submitted against (GitHub). Lets a consumer tell \"the PR moved past\n\t * my review\" (oid !== the PR's current head) from a review still at the tip — without a per-review\n\t * timestamp. Only populated where the full GitHub/GHE projection is selected: the filtered search read, and\n\t * an account-wide sweep that opts in with `includeReviews`. Undefined elsewhere, including reviews the\n\t * repo-scoped read carries natively.\n\t */\n\tcommitOid?: string;\n\t/**\n\t * The reviewer is a group the current user is a member of (a team or another group, directly or through a group\n\t * nested in it) rather than a person: a request to it is one the user can answer as a member, not one addressed to\n\t * them by name. Only the Azure DevOps reads that resolve the user's groups set it; absent elsewhere, including for\n\t * groups a read could not tell the user belongs to.\n\t */\n\tisMyGroup?: boolean;\n}\n\nexport type PullRequestRepositoryIdentityDescriptor = RequireSomeWithProps<\n\tRequireSome<RepositoryIdentityDescriptor<string>, 'provider'>,\n\t'provider',\n\t'id' | 'domain' | 'repoDomain' | 'repoName'\n> &\n\tRequireSomeWithProps<RequireSome<RepositoryIdentityDescriptor<string>, 'remote'>, 'remote', 'domain'>;\n"],"mappings":";;;;;;AAiFO,IAAM,cAAA,eAAN,MAAM,YAAwC;CAInC;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CACA;CAGA;CACA;CACA;CAEA;CACA;CACA;CACA;CACA;CAxCjB,OAAgB;CAEhB,YACC,UACA,QACA,IACA,QACA,OACA,KACA,YACA,OACA,aACA,aACA,YACA,YACA,gBACA,iBACA,MACA,SACA,WACA,WACA,eACA,eACA,gBACA,gBACA,eACA,WACA,wBACA,SACA,SAGA,aACA,OACA,cAEA,MACA,QACA,cACA,YACA,QACC;EAtCe,KAAA,WAAA;EACA,KAAA,SAAA;EACA,KAAA,KAAA;EACA,KAAA,SAAA;EACA,KAAA,QAAA;EACA,KAAA,MAAA;EACA,KAAA,aAAA;EACA,KAAA,QAAA;EACA,KAAA,cAAA;EACA,KAAA,cAAA;EACA,KAAA,aAAA;EACA,KAAA,aAAA;EACA,KAAA,iBAAA;EACA,KAAA,kBAAA;EACA,KAAA,OAAA;EACA,KAAA,UAAA;EACA,KAAA,YAAA;EACA,KAAA,YAAA;EACA,KAAA,gBAAA;EACA,KAAA,gBAAA;EACA,KAAA,iBAAA;EACA,KAAA,iBAAA;EACA,KAAA,gBAAA;EACA,KAAA,YAAA;EACA,KAAA,yBAAA;EACA,KAAA,UAAA;EACA,KAAA,UAAA;EAGA,KAAA,cAAA;EACA,KAAA,QAAA;EACA,KAAA,eAAA;EAEA,KAAA,OAAA;EACA,KAAA,SAAA;EACA,KAAA,eAAA;EACA,KAAA,aAAA;EACA,KAAA,SAAA;CACd;CAEH,IAAI,SAAkB;EACrB,OAAO,KAAK,UAAU;CACvB;CAEA,OAAO,GAAG,IAAgC;EACzC,OAAO,cAAA;CACR;CAEA,OAAO,WAAW,IAAsB,QAAgC;EACvE,OAAO,WAAW,GAAG,cAAc,GAAG,cAAc,GAAG,aAAa,UAAU,qBAAqB;CACpG;CAEA,OAAO,kBAAkB,IAA8B;EACtD,OAAO,QAAQ,GAAG,cAAc,GAAG,cAAc,GAAG,WAAW;CAChE;CAEA,OAAO,oBACN,IACA,YACS;EACT,OAAO,WAAW,cAAc,aAAA,aACjB,WAAW,IAAI,WAAW,UAAU,IAAA,aACpC,kBAAkB,EAAE;CACpC;AACD;AAtEC,cAAA,eAAA,WAAA,CAAA,UAAS,MAAK,EAAE,EAAE,GAClB,YAAA,GAAA,WAAA;AAuED,IAAkB,4BAAX,yBAAA,2BAAA;CACN,0BAAA,cAAA;CACA,0BAAA,sBAAA;CACA,0BAAA,oBAAA;;AACD,EAAA,CAAA,CAAA;AAEA,IAAkB,4BAAX,yBAAA,2BAAA;CACN,0BAAA,aAAA;CACA,0BAAA,eAAA;CACA,0BAAA,iBAAA;CACA,0BAAA,mBAAA;CACA,0BAAA,qBAAA;;AACD,EAAA,CAAA,CAAA;AAEA,IAAkB,oCAAX,yBAAA,mCAAA;CACN,kCAAA,aAAA;CACA,kCAAA,aAAA;CACA,kCAAA,YAAA;;AACD,EAAA,CAAA,CAAA;AAEA,IAAkB,yBAAX,yBAAA,wBAAA;CACN,uBAAA,WAAA;CACA,uBAAA,YAAA;CACA,uBAAA,YAAA;;AACD,EAAA,CAAA,CAAA;AAEA,IAAkB,yBAAX,yBAAA,wBAAA;CACN,uBAAA,cAAA;CACA,uBAAA,sBAAA;CACA,uBAAA,eAAA;CACA,uBAAA,eAAA;CACA,uBAAA,aAAA;CACA,uBAAA,qBAAA;;AACD,EAAA,CAAA,CAAA;;AAyBA,IAAY,oBAAL,yBAAA,mBAAA;CACN,kBAAA,YAAA;CACA,kBAAA,cAAA;CACA,kBAAA,qBAAA;;;;;;;;CAQA,kBAAA,cAAA;CACA,kBAAA,aAAA;;AACD,EAAA,CAAA,CAAA;;;;;;;AAiCA,MAAa,yBAA6C"}

package/dist/plus/integrations/models/integration.d.ts

@@ -114,7 +114,7 @@ export type IssueEtagInclude = 'reactions';
 export declare const issueEtagIncludes: readonly IssueEtagInclude[];
 /** The issue twin of {@link PullRequestEtagFields}, in {@link IssueShape}'s normalized vocabulary. */
 export interface IssueEtagFields {
-  state: IssueOrPullRequestState;
+  state: IssueOrPullRequestState | undefined;
   updatedDate: Date;
   /** Counts only when `'reactions'` is requested, and only from a row whose read fetched reactions. */
   thumbsUpCount?: number;