@gitkraken/core-gitlens 0.6.0 → 0.7.1

package/dist/plus/integrations/providers/azure/search.d.ts

@@ -0,0 +1,144 @@
+import { IssueSearchCriteria, IssueSearchRelationship, IssueSorting } from "../../../../git/models/issue.js";
+import { PullRequestSearchCriteria, PullRequestSorting } from "../../../../git/models/pullRequest.js";
+import { ProviderPullRequest } from "../models.js";
+//#region ../plus/integrations/src/providers/azure/search.d.ts
+/**
+ * The most work items one filtered search can reach, however it is paged.
+ *
+ * Azure DevOps documents 20,000 work items as its query result limit, and may refuse a larger WIQL result set
+ * (`VS402337`) rather than truncate it. The page read therefore asks for a window bounded by `$top`, the first
+ * 20,000 matches under the requested order. Azure DevOps Server 2020 answers that bounded query with 20,014 matches
+ * (it even answered one without `$top`), so the ceiling is this read's, kept at the documented limit.
+ */
+export declare const azureWorkItemSearchResultLimit = 20000;
+/** The work items one detail read can resolve: `workitemsbatch` rejects more than 200 ids. */
+export declare const azureWorkItemBatchLimit = 200;
+/**
+ * A search page size from a caller's `itemsPerPage`, within `[1, max]`. A value that isn't a finite number takes the
+ * default: `NaN` would survive the clamp and serve empty pages that never advance.
+ */
+export declare function toAzureSearchPageSize(value: number | undefined, fallback: number, max: number): number;
+/** The relationships {@link toAzureWorkItemSearchWiql} can express. */
+export declare const azureWorkItemSearchRelationships: IssueSearchRelationship[];
+/** The sort keys {@link toAzureWorkItemSearchWiql} can express. */
+export declare const azureWorkItemSearchSorts: IssueSorting[];
+/**
+ * Translates filtered-search criteria into ONE WIQL query over a collection.
+ *
+ * Relationships are OR-ed inside one parenthesized group rather than run as separate queries, which is what lets a
+ * single query both page and count their union exactly: an item matching two relationships is one row, never two.
+ * The projects bound the query by name through `[System.TeamProject]`, so a repository scope reaches the work items
+ * of its project; with no project the collection itself is the scope.
+ *
+ * The open/closed split mirrors the SDK's WIQL, so this search and the ordinary project read agree on which work
+ * items are open. Free text is a `Contains` substring match on the title, and each label a `Contains` over the
+ * tags, which Azure matches against whole tags — AND-ed, like the criteria model's labels.
+ *
+ * Throws for a relationship or sort key it cannot express. The facade validates both against the declared
+ * capability first, so reaching here with one means the declaration and this translation disagree.
+ */
+export declare function toAzureWorkItemSearchWiql(criteria: IssueSearchCriteria | undefined, sort: IssueSorting, projects: readonly string[] | undefined): string;
+/**
+ * Why a search's dates can't be applied, or `undefined` when they can. The search checks this before any request,
+ * so a date it would refuse costs nothing, and in a count refuses only its own scope.
+ */
+export declare function getInvalidAzureSearchDate(criteria: {
+  updatedAfter?: string;
+  createdAfter?: string;
+} | undefined): string | undefined;
+/**
+ * The criteria a pull-request search applies AFTER the provider read, as one predicate.
+ *
+ * Azure's pull request query takes a creator, a reviewer, a status and a repository, and nothing else, so text,
+ * draft state and dates are matched here against each fully drained facet. Applying them to a complete facet is
+ * exact rather than a post-filter of a page: nothing the predicate removes was ever counted toward a page or a
+ * total, so a count and its list always agree.
+ *
+ * What each criterion matches is bounded by what the list endpoint returns, which is narrower than the web UI:
+ * - text is a case-insensitive substring of the title or of the description — which Azure truncates to its first
+ *   400 characters in a pull request list, so a term only found past that is not matched;
+ * - `updatedAfter` compares Azure's `updatedDate`, which the SDK derives from the close date, or the creation date
+ *   for a pull request still open, since Azure reports no last-activity date. An old but active pull request is
+ *   therefore matched by its creation date.
+ */
+export declare function toAzurePullRequestSearchFilter(criteria: PullRequestSearchCriteria | undefined): (pr: ProviderPullRequest) => boolean;
+/** The pull-request sort keys the search can order its merged facets by. */
+export declare const azurePullRequestSearchSorts: PullRequestSorting[];
+/**
+ * A pull request's position in the merged search result: the sort date plus the identity that breaks ties.
+ *
+ * The identity makes the order TOTAL, which is what lets a cursor resume strictly after the last row served rather
+ * than at a numeric offset. An offset would skip or repeat rows whenever a pull request changes state or date
+ * between two pages; a keyset position only moves past rows that sort before it.
+ */
+export interface AzurePullRequestSearchPosition {
+  time: number;
+  identity: string;
+}
+export declare function toAzurePullRequestSearchPosition(pr: ProviderPullRequest, sort: PullRequestSorting, identity: string): AzurePullRequestSearchPosition;
+/** Orders two positions under `sort`, ties broken by identity so no two rows ever compare equal. */
+export declare function compareAzurePullRequestSearchPositions(a: AzurePullRequestSearchPosition, b: AzurePullRequestSearchPosition, sort: PullRequestSorting): number;
+/**
+ * Where a filtered pull-request search resumes: after `after`, in the drain its first page read, under the query
+ * `key` fingerprints. Bound to its query and served only from its own drain for the same reasons
+ * {@link AzureWorkItemSearchCursor} is bound to its query and snapshot.
+ */
+export interface AzurePullRequestSearchCursor {
+  key: string;
+  drain: string;
+  page: number;
+  after: AzurePullRequestSearchPosition;
+}
+/**
+ * The fingerprint {@link AzurePullRequestSearchCursor.key} carries for a query.
+ *
+ * It only guards a caller threading a cursor under a different query, and keeps the query itself out of the opaque
+ * cursor. It never selects cached results: those are keyed by the full query (see the callers), so a fingerprint
+ * collision can at worst accept a cursor, never serve another query's rows.
+ */
+export declare function toAzurePullRequestSearchCursorKey(query: unknown): string;
+/** Reads a caller-supplied cursor for the query fingerprinted as `key`; see {@link parseAzureWorkItemSearchCursor}. */
+export declare function parseAzurePullRequestSearchCursor(cursor: string | undefined, key: string): AzurePullRequestSearchCursor | undefined;
+/**
+ * Where a filtered work-item search resumes: an offset into the id snapshot its first page queried, the id of that
+ * snapshot, and the fingerprint of the query that produced it.
+ *
+ * A continuation is only served from ITS snapshot, where the offset is exact. Each first page queries a snapshot of
+ * its own, so a pagination of the same query started later never replaces the one an earlier pagination is reading.
+ * The snapshot is kept for as long as the pagination keeps reading it; once it is gone the continuation is REFUSED
+ * rather than resumed against a fresh query, since under an `updated` order a re-query can move an unseen work item
+ * ahead of the offset, where it would be skipped without anything saying so. A cursor without a `snapshot` is the
+ * facade's own page marker, which names a page by number with no snapshot behind it and is read against a fresh
+ * query as exactly that.
+ *
+ * The fingerprint binds the cursor to its query (scope, criteria and order) without publishing any of them inside
+ * the opaque cursor. A cursor for another query is REFUSED rather than silently restarted: this read is cursor-only,
+ * so a restart would be served under the page number the caller supplied alongside it — page 1's rows labelled as
+ * page N.
+ */
+export interface AzureWorkItemSearchCursor {
+  key: string;
+  snapshot?: string;
+  offset: number;
+  page: number;
+}
+/** The fingerprint {@link AzureWorkItemSearchCursor.key} carries for a query; see {@link toAzurePullRequestSearchCursorKey}. */
+export declare function toAzureWorkItemSearchCursorKey(collection: string, wiql: string): string;
+/**
+ * Whether `cursor` starts a work-item search's first page: none at all, or the facade's page-1 marker, which
+ * {@link parseAzureWorkItemSearchCursor} reads the same way.
+ */
+export declare function isAzureWorkItemSearchFirstPage(cursor: string | undefined): boolean;
+/**
+ * Reads a caller-supplied cursor for the query fingerprinted as `key`.
+ *
+ * Returns `undefined` when there is no cursor, and throws when there is one this query can't resume, since treating
+ * a foreign or malformed cursor as page 1 would publish the first page's rows as the page the caller asked for.
+ *
+ * The one cursor it accepts without a fingerprint is the facade's own page marker (`{ value, type: 'page' }`), which
+ * `broadenIssues` sends to retry or reach a numbered page it holds no cursor for. It names a position rather than a
+ * query, so it is honored as the offset of that page at `pageSize` — page 1 being no cursor at all.
+ */
+export declare function parseAzureWorkItemSearchCursor(cursor: string | undefined, key: string, pageSize: number): AzureWorkItemSearchCursor | undefined;
+//#endregion
+//# sourceMappingURL=search.d.ts.map

package/dist/plus/integrations/providers/azure/search.js

@@ -0,0 +1,250 @@
+import { fnv1aHash64 } from "../../../../utils/hash.js";
+import { parsePageCursor } from "../utils/providerPaging.js";
+import { escapeWiqlString } from "@gitkraken/provider-apis";
+//#region ../plus/integrations/src/providers/azure/search.ts
+/**
+* The most work items one filtered search can reach, however it is paged.
+*
+* Azure DevOps documents 20,000 work items as its query result limit, and may refuse a larger WIQL result set
+* (`VS402337`) rather than truncate it. The page read therefore asks for a window bounded by `$top`, the first
+* 20,000 matches under the requested order. Azure DevOps Server 2020 answers that bounded query with 20,014 matches
+* (it even answered one without `$top`), so the ceiling is this read's, kept at the documented limit.
+*/
+const azureWorkItemSearchResultLimit = 2e4;
+/** The work items one detail read can resolve: `workitemsbatch` rejects more than 200 ids. */
+const azureWorkItemBatchLimit = 200;
+/**
+* A search page size from a caller's `itemsPerPage`, within `[1, max]`. A value that isn't a finite number takes the
+* default: `NaN` would survive the clamp and serve empty pages that never advance.
+*/
+function toAzureSearchPageSize(value, fallback, max) {
+	return Math.min(max, Math.max(1, value != null && Number.isFinite(value) ? Math.trunc(value) : fallback));
+}
+/**
+* Each filtered-search relationship as the WIQL clause that expresses it.
+*
+* `@Me` rather than an identity looked up per read: Azure resolves the macro to the identity the credential
+* authenticates as, which is exactly the "current user" the relationship names, and needs no account read.
+* `mentioned` is absent. `@RecentMentions` only covers the last 30 days, so declaring it would serve an arbitrary
+* window under a relationship that promises every mention.
+*/
+const relationshipClauses = {
+	authored: "[System.CreatedBy] = @Me",
+	assigned: "[System.AssignedTo] = @Me",
+	"any-assignee": "[System.AssignedTo] <> ''",
+	unassigned: "[System.AssignedTo] = ''"
+};
+/** The relationships {@link toAzureWorkItemSearchWiql} can express. */
+const azureWorkItemSearchRelationships = Object.keys(relationshipClauses);
+/**
+* Each orderable key as its WIQL `ORDER BY` column.
+*
+* A strict subset of the SDK's WIQL columns: `priority` and `resolved` are left out because their columns are
+* process-template fields. On an on-premises collection running the XML process model, a field its process never
+* declared fails the whole query with `TF51005` rather than ordering nothing, so declaring them would turn a
+* working search into a refused one on exactly the installations this search exists for. Every key kept orders a
+* system field, except `closed`, whose column the open/closed filter below already depends on.
+*/
+const sortColumns = {
+	"updated:desc": "[System.ChangedDate] Desc",
+	"updated:asc": "[System.ChangedDate] Asc",
+	"created:desc": "[System.CreatedDate] Desc",
+	"created:asc": "[System.CreatedDate] Asc",
+	"closed:desc": "[Microsoft.VSTS.Common.ClosedDate] Desc",
+	"closed:asc": "[Microsoft.VSTS.Common.ClosedDate] Asc",
+	"comments:desc": "[System.CommentCount] Desc",
+	"comments:asc": "[System.CommentCount] Asc",
+	"title:desc": "[System.Title] Desc",
+	"title:asc": "[System.Title] Asc"
+};
+/** The sort keys {@link toAzureWorkItemSearchWiql} can express. */
+const azureWorkItemSearchSorts = Object.keys(sortColumns);
+/**
+* Translates filtered-search criteria into ONE WIQL query over a collection.
+*
+* Relationships are OR-ed inside one parenthesized group rather than run as separate queries, which is what lets a
+* single query both page and count their union exactly: an item matching two relationships is one row, never two.
+* The projects bound the query by name through `[System.TeamProject]`, so a repository scope reaches the work items
+* of its project; with no project the collection itself is the scope.
+*
+* The open/closed split mirrors the SDK's WIQL, so this search and the ordinary project read agree on which work
+* items are open. Free text is a `Contains` substring match on the title, and each label a `Contains` over the
+* tags, which Azure matches against whole tags — AND-ed, like the criteria model's labels.
+*
+* Throws for a relationship or sort key it cannot express. The facade validates both against the declared
+* capability first, so reaching here with one means the declaration and this translation disagree.
+*/
+function toAzureWorkItemSearchWiql(criteria, sort, projects) {
+	const clauses = [];
+	if (projects?.length) clauses.push(`[System.TeamProject] IN (${projects.map((p) => `'${escapeWiqlString(p)}'`).join(", ")})`);
+	switch (criteria?.state ?? "open") {
+		case "open":
+			clauses.push("[Microsoft.VSTS.Common.ClosedDate] = ''", "[Microsoft.VSTS.Common.ResolvedDate] = ''");
+			break;
+		case "closed": clauses.push("([Microsoft.VSTS.Common.ClosedDate] <> '' OR [Microsoft.VSTS.Common.ResolvedDate] <> '')");
+	}
+	const relationships = [...new Set(criteria?.relationships ?? [])];
+	if (relationships.length > 0) {
+		const expressions = relationships.map((r) => {
+			const clause = relationshipClauses[r];
+			if (clause == null) throw new Error(`Azure DevOps cannot search work items by the '${r}' relationship`);
+			return clause;
+		});
+		clauses.push(`(${expressions.join(" OR ")})`);
+	}
+	const text = criteria?.text?.trim();
+	if (text) clauses.push(`[System.Title] Contains '${escapeWiqlString(text)}'`);
+	for (const label of criteria?.labels ?? []) clauses.push(`[System.Tags] Contains '${escapeWiqlString(label)}'`);
+	if (criteria?.updatedAfter != null) clauses.push(`[System.ChangedDate] >= '${toWiqlDate(criteria.updatedAfter, "updatedAfter")}'`);
+	if (criteria?.createdAfter != null) clauses.push(`[System.CreatedDate] >= '${toWiqlDate(criteria.createdAfter, "createdAfter")}'`);
+	const column = sortColumns[sort];
+	if (column == null) throw new Error(`Azure DevOps cannot order a work item search by '${sort}'`);
+	return `SELECT [System.Id] FROM WorkItems${clauses.length > 0 ? ` WHERE ${clauses.join(" AND ")}` : ""} ORDER BY ${column}, [System.Id] Desc`;
+}
+/**
+* A criteria date as the UTC-midnight literal WIQL compares against. A literal with a time is only accepted by a
+* query sent with `timePrecision=true`, which is how the search sends every query: without it WIQL compares whole
+* days in the server's time zone, and the instant would differ from the one the pull request filter applies.
+*/
+function toWiqlDate(value, name) {
+	return parseCriteriaDate(value, name).toISOString().replace(".000Z", "Z");
+}
+/**
+* A criteria date as UTC midnight.
+*
+* Validated to the `YYYY-MM-DD` the criteria model documents rather than parsed leniently: the WIQL value lands
+* inside a quoted literal, where any other shape is either refused or read in the server's locale, and the pull
+* request filter must apply the same instant the work-item query does.
+*/
+function parseCriteriaDate(value, name) {
+	const date = toCriteriaDate(value);
+	if (date == null) throw new Error(`Invalid ${name} '${value}'; expected an ISO date (YYYY-MM-DD)`);
+	return date;
+}
+function toCriteriaDate(value) {
+	const trimmed = value.trim();
+	const match = /^(\d{4})-(\d{2})-(\d{2})$/.exec(trimmed);
+	const date = match != null ? new Date(Date.UTC(Number(match[1]), Number(match[2]) - 1, Number(match[3]))) : null;
+	return date == null || Number.isNaN(date.getTime()) || date.toISOString().slice(0, 10) !== trimmed ? void 0 : date;
+}
+/**
+* Why a search's dates can't be applied, or `undefined` when they can. The search checks this before any request,
+* so a date it would refuse costs nothing, and in a count refuses only its own scope.
+*/
+function getInvalidAzureSearchDate(criteria) {
+	for (const [name, value] of [["updatedAfter", criteria?.updatedAfter], ["createdAfter", criteria?.createdAfter]]) if (value != null && toCriteriaDate(value) == null) return `invalid ${name} '${value}'; expected an ISO date (YYYY-MM-DD)`;
+}
+/**
+* The criteria a pull-request search applies AFTER the provider read, as one predicate.
+*
+* Azure's pull request query takes a creator, a reviewer, a status and a repository, and nothing else, so text,
+* draft state and dates are matched here against each fully drained facet. Applying them to a complete facet is
+* exact rather than a post-filter of a page: nothing the predicate removes was ever counted toward a page or a
+* total, so a count and its list always agree.
+*
+* What each criterion matches is bounded by what the list endpoint returns, which is narrower than the web UI:
+* - text is a case-insensitive substring of the title or of the description — which Azure truncates to its first
+*   400 characters in a pull request list, so a term only found past that is not matched;
+* - `updatedAfter` compares Azure's `updatedDate`, which the SDK derives from the close date, or the creation date
+*   for a pull request still open, since Azure reports no last-activity date. An old but active pull request is
+*   therefore matched by its creation date.
+*/
+function toAzurePullRequestSearchFilter(criteria) {
+	const text = criteria?.text?.trim().toLowerCase();
+	const draft = criteria?.draft;
+	const updatedAfter = criteria?.updatedAfter != null ? parseCriteriaDate(criteria.updatedAfter, "updatedAfter") : void 0;
+	const createdAfter = criteria?.createdAfter != null ? parseCriteriaDate(criteria.createdAfter, "createdAfter") : void 0;
+	return (pr) => (!text || pr.title.toLowerCase().includes(text) || (pr.description?.toLowerCase().includes(text) ?? false)) && (draft == null || pr.isDraft === draft) && (updatedAfter == null || pr.updatedDate >= updatedAfter) && (createdAfter == null || pr.createdDate >= createdAfter);
+}
+/** The pull-request sort keys the search can order its merged facets by. */
+const azurePullRequestSearchSorts = [
+	"updated:desc",
+	"updated:asc",
+	"created:desc",
+	"created:asc"
+];
+function toAzurePullRequestSearchPosition(pr, sort, identity) {
+	return {
+		time: (sort.startsWith("created") ? pr.createdDate : pr.updatedDate).getTime(),
+		identity
+	};
+}
+/** Orders two positions under `sort`, ties broken by identity so no two rows ever compare equal. */
+function compareAzurePullRequestSearchPositions(a, b, sort) {
+	if (a.time !== b.time) return sort.endsWith(":asc") ? a.time - b.time : b.time - a.time;
+	return a.identity < b.identity ? -1 : a.identity > b.identity ? 1 : 0;
+}
+/**
+* The fingerprint {@link AzurePullRequestSearchCursor.key} carries for a query.
+*
+* It only guards a caller threading a cursor under a different query, and keeps the query itself out of the opaque
+* cursor. It never selects cached results: those are keyed by the full query (see the callers), so a fingerprint
+* collision can at worst accept a cursor, never serve another query's rows.
+*/
+function toAzurePullRequestSearchCursorKey(query) {
+	return fnv1aHash64(JSON.stringify(query));
+}
+/** Reads a caller-supplied cursor for the query fingerprinted as `key`; see {@link parseAzureWorkItemSearchCursor}. */
+function parseAzurePullRequestSearchCursor(cursor, key) {
+	if (cursor == null) return void 0;
+	let parsed;
+	try {
+		parsed = JSON.parse(cursor);
+	} catch {}
+	const after = parsed?.after;
+	if (parsed?.key !== key || typeof parsed.drain !== "string" || !parsed.drain || !Number.isSafeInteger(parsed.page) || parsed.page < 1 || typeof after?.time !== "number" || !Number.isFinite(after.time) || typeof after.identity !== "string") throw new Error("Pull request search cursor was produced by a different query; restart the read without a cursor");
+	return {
+		key,
+		drain: parsed.drain,
+		page: parsed.page,
+		after: {
+			time: after.time,
+			identity: after.identity
+		}
+	};
+}
+/** The fingerprint {@link AzureWorkItemSearchCursor.key} carries for a query; see {@link toAzurePullRequestSearchCursorKey}. */
+function toAzureWorkItemSearchCursorKey(collection, wiql) {
+	return fnv1aHash64(JSON.stringify([collection, wiql]));
+}
+/**
+* Whether `cursor` starts a work-item search's first page: none at all, or the facade's page-1 marker, which
+* {@link parseAzureWorkItemSearchCursor} reads the same way.
+*/
+function isAzureWorkItemSearchFirstPage(cursor) {
+	return cursor == null || parsePageCursor(cursor) === 1;
+}
+/**
+* Reads a caller-supplied cursor for the query fingerprinted as `key`.
+*
+* Returns `undefined` when there is no cursor, and throws when there is one this query can't resume, since treating
+* a foreign or malformed cursor as page 1 would publish the first page's rows as the page the caller asked for.
+*
+* The one cursor it accepts without a fingerprint is the facade's own page marker (`{ value, type: 'page' }`), which
+* `broadenIssues` sends to retry or reach a numbered page it holds no cursor for. It names a position rather than a
+* query, so it is honored as the offset of that page at `pageSize` — page 1 being no cursor at all.
+*/
+function parseAzureWorkItemSearchCursor(cursor, key, pageSize) {
+	if (cursor == null) return void 0;
+	const pageMarker = parsePageCursor(cursor);
+	if (pageMarker != null && Number.isSafeInteger(pageMarker) && pageMarker >= 1) return pageMarker === 1 ? void 0 : {
+		key,
+		offset: (pageMarker - 1) * pageSize,
+		page: pageMarker
+	};
+	let parsed;
+	try {
+		parsed = JSON.parse(cursor);
+	} catch {}
+	if (parsed?.key !== key || typeof parsed.snapshot !== "string" || !parsed.snapshot || !Number.isSafeInteger(parsed.offset) || parsed.offset < 0 || !Number.isSafeInteger(parsed.page) || parsed.page < 1) throw new Error("Work item search cursor was produced by a different query; restart the read without a cursor");
+	return {
+		key,
+		snapshot: parsed.snapshot,
+		offset: parsed.offset,
+		page: parsed.page
+	};
+}
+//#endregion
+export { azurePullRequestSearchSorts, azureWorkItemBatchLimit, azureWorkItemSearchRelationships, azureWorkItemSearchResultLimit, azureWorkItemSearchSorts, compareAzurePullRequestSearchPositions, getInvalidAzureSearchDate, isAzureWorkItemSearchFirstPage, parseAzurePullRequestSearchCursor, parseAzureWorkItemSearchCursor, toAzurePullRequestSearchCursorKey, toAzurePullRequestSearchFilter, toAzurePullRequestSearchPosition, toAzureSearchPageSize, toAzureWorkItemSearchCursorKey, toAzureWorkItemSearchWiql };
+
+//# sourceMappingURL=search.js.map

package/dist/plus/integrations/providers/azure/search.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"search.js","names":[],"sources":["../../../../../../plus/integrations/src/providers/azure/search.ts"],"sourcesContent":["import { escapeWiqlString } from '@gitkraken/provider-apis';\nimport type { IssueSearchCriteria, IssueSearchRelationship, IssueSorting } from '@gitlens/git/models/issue.js';\nimport type { PullRequestSearchCriteria, PullRequestSorting } from '@gitlens/git/models/pullRequest.js';\nimport { fnv1aHash64 } from '@gitlens/utils/hash.js';\nimport type { ProviderPullRequest } from '../models.js';\nimport { parsePageCursor } from '../utils/providerPaging.js';\n\n/**\n * The most work items one filtered search can reach, however it is paged.\n *\n * Azure DevOps documents 20,000 work items as its query result limit, and may refuse a larger WIQL result set\n * (`VS402337`) rather than truncate it. The page read therefore asks for a window bounded by `$top`, the first\n * 20,000 matches under the requested order. Azure DevOps Server 2020 answers that bounded query with 20,014 matches\n * (it even answered one without `$top`), so the ceiling is this read's, kept at the documented limit.\n */\nexport const azureWorkItemSearchResultLimit = 20000;\n\n/** The work items one detail read can resolve: `workitemsbatch` rejects more than 200 ids. */\nexport const azureWorkItemBatchLimit = 200;\n\n/**\n * A search page size from a caller's `itemsPerPage`, within `[1, max]`. A value that isn't a finite number takes the\n * default: `NaN` would survive the clamp and serve empty pages that never advance.\n */\nexport function toAzureSearchPageSize(value: number | undefined, fallback: number, max: number): number {\n\tconst size = value != null && Number.isFinite(value) ? Math.trunc(value) : fallback;\n\treturn Math.min(max, Math.max(1, size));\n}\n\n/**\n * Each filtered-search relationship as the WIQL clause that expresses it.\n *\n * `@Me` rather than an identity looked up per read: Azure resolves the macro to the identity the credential\n * authenticates as, which is exactly the \"current user\" the relationship names, and needs no account read.\n * `mentioned` is absent. `@RecentMentions` only covers the last 30 days, so declaring it would serve an arbitrary\n * window under a relationship that promises every mention.\n */\nconst relationshipClauses: Partial<Record<IssueSearchRelationship, string>> = {\n\tauthored: '[System.CreatedBy] = @Me',\n\tassigned: '[System.AssignedTo] = @Me',\n\t'any-assignee': \"[System.AssignedTo] <> ''\",\n\tunassigned: \"[System.AssignedTo] = ''\",\n};\n\n/** The relationships {@link toAzureWorkItemSearchWiql} can express. */\nexport const azureWorkItemSearchRelationships = Object.keys(relationshipClauses) as IssueSearchRelationship[];\n\n/**\n * Each orderable key as its WIQL `ORDER BY` column.\n *\n * A strict subset of the SDK's WIQL columns: `priority` and `resolved` are left out because their columns are\n * process-template fields. On an on-premises collection running the XML process model, a field its process never\n * declared fails the whole query with `TF51005` rather than ordering nothing, so declaring them would turn a\n * working search into a refused one on exactly the installations this search exists for. Every key kept orders a\n * system field, except `closed`, whose column the open/closed filter below already depends on.\n */\nconst sortColumns: Partial<Record<IssueSorting, string>> = {\n\t'updated:desc': '[System.ChangedDate] Desc',\n\t'updated:asc': '[System.ChangedDate] Asc',\n\t'created:desc': '[System.CreatedDate] Desc',\n\t'created:asc': '[System.CreatedDate] Asc',\n\t'closed:desc': '[Microsoft.VSTS.Common.ClosedDate] Desc',\n\t'closed:asc': '[Microsoft.VSTS.Common.ClosedDate] Asc',\n\t'comments:desc': '[System.CommentCount] Desc',\n\t'comments:asc': '[System.CommentCount] Asc',\n\t'title:desc': '[System.Title] Desc',\n\t'title:asc': '[System.Title] Asc',\n};\n\n/** The sort keys {@link toAzureWorkItemSearchWiql} can express. */\nexport const azureWorkItemSearchSorts = Object.keys(sortColumns) as IssueSorting[];\n\n/**\n * Translates filtered-search criteria into ONE WIQL query over a collection.\n *\n * Relationships are OR-ed inside one parenthesized group rather than run as separate queries, which is what lets a\n * single query both page and count their union exactly: an item matching two relationships is one row, never two.\n * The projects bound the query by name through `[System.TeamProject]`, so a repository scope reaches the work items\n * of its project; with no project the collection itself is the scope.\n *\n * The open/closed split mirrors the SDK's WIQL, so this search and the ordinary project read agree on which work\n * items are open. Free text is a `Contains` substring match on the title, and each label a `Contains` over the\n * tags, which Azure matches against whole tags — AND-ed, like the criteria model's labels.\n *\n * Throws for a relationship or sort key it cannot express. The facade validates both against the declared\n * capability first, so reaching here with one means the declaration and this translation disagree.\n */\nexport function toAzureWorkItemSearchWiql(\n\tcriteria: IssueSearchCriteria | undefined,\n\tsort: IssueSorting,\n\tprojects: readonly string[] | undefined,\n): string {\n\tconst clauses: string[] = [];\n\tif (projects?.length) {\n\t\tclauses.push(`[System.TeamProject] IN (${projects.map(p => `'${escapeWiqlString(p)}'`).join(', ')})`);\n\t}\n\n\tswitch (criteria?.state ?? 'open') {\n\t\tcase 'open':\n\t\t\tclauses.push(\"[Microsoft.VSTS.Common.ClosedDate] = ''\", \"[Microsoft.VSTS.Common.ResolvedDate] = ''\");\n\t\t\tbreak;\n\t\tcase 'closed':\n\t\t\tclauses.push(\"([Microsoft.VSTS.Common.ClosedDate] <> '' OR [Microsoft.VSTS.Common.ResolvedDate] <> '')\");\n\t\t\tbreak;\n\t\tcase 'all':\n\t\t\tbreak;\n\t}\n\n\tconst relationships = [...new Set(criteria?.relationships ?? [])];\n\tif (relationships.length > 0) {\n\t\tconst expressions = relationships.map(r => {\n\t\t\tconst clause = relationshipClauses[r];\n\t\t\tif (clause == null) throw new Error(`Azure DevOps cannot search work items by the '${r}' relationship`);\n\n\t\t\treturn clause;\n\t\t});\n\t\tclauses.push(`(${expressions.join(' OR ')})`);\n\t}\n\n\tconst text = criteria?.text?.trim();\n\tif (text) {\n\t\tclauses.push(`[System.Title] Contains '${escapeWiqlString(text)}'`);\n\t}\n\tfor (const label of criteria?.labels ?? []) {\n\t\tclauses.push(`[System.Tags] Contains '${escapeWiqlString(label)}'`);\n\t}\n\tif (criteria?.updatedAfter != null) {\n\t\tclauses.push(`[System.ChangedDate] >= '${toWiqlDate(criteria.updatedAfter, 'updatedAfter')}'`);\n\t}\n\tif (criteria?.createdAfter != null) {\n\t\tclauses.push(`[System.CreatedDate] >= '${toWiqlDate(criteria.createdAfter, 'createdAfter')}'`);\n\t}\n\n\tconst column = sortColumns[sort];\n\tif (column == null) throw new Error(`Azure DevOps cannot order a work item search by '${sort}'`);\n\n\t// `[System.Id]` makes the order total, so a work item tying on the sort column can't cross a page boundary\n\t// between two requests and be served twice or never.\n\tconst where = clauses.length > 0 ? ` WHERE ${clauses.join(' AND ')}` : '';\n\treturn `SELECT [System.Id] FROM WorkItems${where} ORDER BY ${column}, [System.Id] Desc`;\n}\n\n/**\n * A criteria date as the UTC-midnight literal WIQL compares against. A literal with a time is only accepted by a\n * query sent with `timePrecision=true`, which is how the search sends every query: without it WIQL compares whole\n * days in the server's time zone, and the instant would differ from the one the pull request filter applies.\n */\nfunction toWiqlDate(value: string, name: string): string {\n\treturn parseCriteriaDate(value, name).toISOString().replace('.000Z', 'Z');\n}\n\n/**\n * A criteria date as UTC midnight.\n *\n * Validated to the `YYYY-MM-DD` the criteria model documents rather than parsed leniently: the WIQL value lands\n * inside a quoted literal, where any other shape is either refused or read in the server's locale, and the pull\n * request filter must apply the same instant the work-item query does.\n */\nfunction parseCriteriaDate(value: string, name: string): Date {\n\tconst date = toCriteriaDate(value);\n\tif (date == null) throw new Error(`Invalid ${name} '${value}'; expected an ISO date (YYYY-MM-DD)`);\n\n\treturn date;\n}\n\nfunction toCriteriaDate(value: string): Date | undefined {\n\tconst trimmed = value.trim();\n\tconst match = /^(\\d{4})-(\\d{2})-(\\d{2})$/.exec(trimmed);\n\tconst date = match != null ? new Date(Date.UTC(Number(match[1]), Number(match[2]) - 1, Number(match[3]))) : null;\n\treturn date == null || Number.isNaN(date.getTime()) || date.toISOString().slice(0, 10) !== trimmed\n\t\t? undefined\n\t\t: date;\n}\n\n/**\n * Why a search's dates can't be applied, or `undefined` when they can. The search checks this before any request,\n * so a date it would refuse costs nothing, and in a count refuses only its own scope.\n */\nexport function getInvalidAzureSearchDate(\n\tcriteria: { updatedAfter?: string; createdAfter?: string } | undefined,\n): string | undefined {\n\tfor (const [name, value] of [\n\t\t['updatedAfter', criteria?.updatedAfter],\n\t\t['createdAfter', criteria?.createdAfter],\n\t] as const) {\n\t\tif (value != null && toCriteriaDate(value) == null) {\n\t\t\treturn `invalid ${name} '${value}'; expected an ISO date (YYYY-MM-DD)`;\n\t\t}\n\t}\n\treturn undefined;\n}\n\n/**\n * The criteria a pull-request search applies AFTER the provider read, as one predicate.\n *\n * Azure's pull request query takes a creator, a reviewer, a status and a repository, and nothing else, so text,\n * draft state and dates are matched here against each fully drained facet. Applying them to a complete facet is\n * exact rather than a post-filter of a page: nothing the predicate removes was ever counted toward a page or a\n * total, so a count and its list always agree.\n *\n * What each criterion matches is bounded by what the list endpoint returns, which is narrower than the web UI:\n * - text is a case-insensitive substring of the title or of the description — which Azure truncates to its first\n *   400 characters in a pull request list, so a term only found past that is not matched;\n * - `updatedAfter` compares Azure's `updatedDate`, which the SDK derives from the close date, or the creation date\n *   for a pull request still open, since Azure reports no last-activity date. An old but active pull request is\n *   therefore matched by its creation date.\n */\nexport function toAzurePullRequestSearchFilter(\n\tcriteria: PullRequestSearchCriteria | undefined,\n): (pr: ProviderPullRequest) => boolean {\n\tconst text = criteria?.text?.trim().toLowerCase();\n\tconst draft = criteria?.draft;\n\tconst updatedAfter =\n\t\tcriteria?.updatedAfter != null ? parseCriteriaDate(criteria.updatedAfter, 'updatedAfter') : undefined;\n\tconst createdAfter =\n\t\tcriteria?.createdAfter != null ? parseCriteriaDate(criteria.createdAfter, 'createdAfter') : undefined;\n\n\treturn pr =>\n\t\t(!text || pr.title.toLowerCase().includes(text) || (pr.description?.toLowerCase().includes(text) ?? false)) &&\n\t\t(draft == null || pr.isDraft === draft) &&\n\t\t(updatedAfter == null || pr.updatedDate >= updatedAfter) &&\n\t\t(createdAfter == null || pr.createdDate >= createdAfter);\n}\n\n/** The pull-request sort keys the search can order its merged facets by. */\nexport const azurePullRequestSearchSorts: PullRequestSorting[] = [\n\t'updated:desc',\n\t'updated:asc',\n\t'created:desc',\n\t'created:asc',\n];\n\n/**\n * A pull request's position in the merged search result: the sort date plus the identity that breaks ties.\n *\n * The identity makes the order TOTAL, which is what lets a cursor resume strictly after the last row served rather\n * than at a numeric offset. An offset would skip or repeat rows whenever a pull request changes state or date\n * between two pages; a keyset position only moves past rows that sort before it.\n */\nexport interface AzurePullRequestSearchPosition {\n\ttime: number;\n\tidentity: string;\n}\n\nexport function toAzurePullRequestSearchPosition(\n\tpr: ProviderPullRequest,\n\tsort: PullRequestSorting,\n\tidentity: string,\n): AzurePullRequestSearchPosition {\n\treturn { time: (sort.startsWith('created') ? pr.createdDate : pr.updatedDate).getTime(), identity: identity };\n}\n\n/** Orders two positions under `sort`, ties broken by identity so no two rows ever compare equal. */\nexport function compareAzurePullRequestSearchPositions(\n\ta: AzurePullRequestSearchPosition,\n\tb: AzurePullRequestSearchPosition,\n\tsort: PullRequestSorting,\n): number {\n\tif (a.time !== b.time) return sort.endsWith(':asc') ? a.time - b.time : b.time - a.time;\n\n\treturn a.identity < b.identity ? -1 : a.identity > b.identity ? 1 : 0;\n}\n\n/**\n * Where a filtered pull-request search resumes: after `after`, in the drain its first page read, under the query\n * `key` fingerprints. Bound to its query and served only from its own drain for the same reasons\n * {@link AzureWorkItemSearchCursor} is bound to its query and snapshot.\n */\nexport interface AzurePullRequestSearchCursor {\n\tkey: string;\n\tdrain: string;\n\tpage: number;\n\tafter: AzurePullRequestSearchPosition;\n}\n\n/**\n * The fingerprint {@link AzurePullRequestSearchCursor.key} carries for a query.\n *\n * It only guards a caller threading a cursor under a different query, and keeps the query itself out of the opaque\n * cursor. It never selects cached results: those are keyed by the full query (see the callers), so a fingerprint\n * collision can at worst accept a cursor, never serve another query's rows.\n */\nexport function toAzurePullRequestSearchCursorKey(query: unknown): string {\n\treturn fnv1aHash64(JSON.stringify(query));\n}\n\n/** Reads a caller-supplied cursor for the query fingerprinted as `key`; see {@link parseAzureWorkItemSearchCursor}. */\nexport function parseAzurePullRequestSearchCursor(\n\tcursor: string | undefined,\n\tkey: string,\n): AzurePullRequestSearchCursor | undefined {\n\tif (cursor == null) return undefined;\n\n\tlet parsed: Partial<AzurePullRequestSearchCursor> | undefined;\n\ttry {\n\t\tparsed = JSON.parse(cursor) as Partial<AzurePullRequestSearchCursor>;\n\t} catch {}\n\n\tconst after = parsed?.after;\n\tif (\n\t\tparsed?.key !== key ||\n\t\ttypeof parsed.drain !== 'string' ||\n\t\t!parsed.drain ||\n\t\t!Number.isSafeInteger(parsed.page) ||\n\t\tparsed.page! < 1 ||\n\t\ttypeof after?.time !== 'number' ||\n\t\t!Number.isFinite(after.time) ||\n\t\ttypeof after.identity !== 'string'\n\t) {\n\t\tthrow new Error(\n\t\t\t'Pull request search cursor was produced by a different query; restart the read without a cursor',\n\t\t);\n\t}\n\n\treturn { key: key, drain: parsed.drain, page: parsed.page!, after: { time: after.time, identity: after.identity } };\n}\n\n/**\n * Where a filtered work-item search resumes: an offset into the id snapshot its first page queried, the id of that\n * snapshot, and the fingerprint of the query that produced it.\n *\n * A continuation is only served from ITS snapshot, where the offset is exact. Each first page queries a snapshot of\n * its own, so a pagination of the same query started later never replaces the one an earlier pagination is reading.\n * The snapshot is kept for as long as the pagination keeps reading it; once it is gone the continuation is REFUSED\n * rather than resumed against a fresh query, since under an `updated` order a re-query can move an unseen work item\n * ahead of the offset, where it would be skipped without anything saying so. A cursor without a `snapshot` is the\n * facade's own page marker, which names a page by number with no snapshot behind it and is read against a fresh\n * query as exactly that.\n *\n * The fingerprint binds the cursor to its query (scope, criteria and order) without publishing any of them inside\n * the opaque cursor. A cursor for another query is REFUSED rather than silently restarted: this read is cursor-only,\n * so a restart would be served under the page number the caller supplied alongside it — page 1's rows labelled as\n * page N.\n */\nexport interface AzureWorkItemSearchCursor {\n\tkey: string;\n\tsnapshot?: string;\n\toffset: number;\n\tpage: number;\n}\n\n/** The fingerprint {@link AzureWorkItemSearchCursor.key} carries for a query; see {@link toAzurePullRequestSearchCursorKey}. */\nexport function toAzureWorkItemSearchCursorKey(collection: string, wiql: string): string {\n\treturn fnv1aHash64(JSON.stringify([collection, wiql]));\n}\n\n/**\n * Whether `cursor` starts a work-item search's first page: none at all, or the facade's page-1 marker, which\n * {@link parseAzureWorkItemSearchCursor} reads the same way.\n */\nexport function isAzureWorkItemSearchFirstPage(cursor: string | undefined): boolean {\n\treturn cursor == null || parsePageCursor(cursor) === 1;\n}\n\n/**\n * Reads a caller-supplied cursor for the query fingerprinted as `key`.\n *\n * Returns `undefined` when there is no cursor, and throws when there is one this query can't resume, since treating\n * a foreign or malformed cursor as page 1 would publish the first page's rows as the page the caller asked for.\n *\n * The one cursor it accepts without a fingerprint is the facade's own page marker (`{ value, type: 'page' }`), which\n * `broadenIssues` sends to retry or reach a numbered page it holds no cursor for. It names a position rather than a\n * query, so it is honored as the offset of that page at `pageSize` — page 1 being no cursor at all.\n */\nexport function parseAzureWorkItemSearchCursor(\n\tcursor: string | undefined,\n\tkey: string,\n\tpageSize: number,\n): AzureWorkItemSearchCursor | undefined {\n\tif (cursor == null) return undefined;\n\n\tconst pageMarker = parsePageCursor(cursor);\n\tif (pageMarker != null && Number.isSafeInteger(pageMarker) && pageMarker >= 1) {\n\t\treturn pageMarker === 1 ? undefined : { key: key, offset: (pageMarker - 1) * pageSize, page: pageMarker };\n\t}\n\n\tlet parsed: Partial<AzureWorkItemSearchCursor> | undefined;\n\ttry {\n\t\tparsed = JSON.parse(cursor) as Partial<AzureWorkItemSearchCursor>;\n\t} catch {}\n\n\tif (\n\t\tparsed?.key !== key ||\n\t\ttypeof parsed.snapshot !== 'string' ||\n\t\t!parsed.snapshot ||\n\t\t!Number.isSafeInteger(parsed.offset) ||\n\t\tparsed.offset! < 0 ||\n\t\t!Number.isSafeInteger(parsed.page) ||\n\t\tparsed.page! < 1\n\t) {\n\t\tthrow new Error('Work item search cursor was produced by a different query; restart the read without a cursor');\n\t}\n\n\treturn { key: key, snapshot: parsed.snapshot, offset: parsed.offset!, page: parsed.page! };\n}\n"],"mappings":";;;;;;;;;;;;AAeA,MAAa,iCAAiC;;AAG9C,MAAa,0BAA0B;;;;;AAMvC,SAAgB,sBAAsB,OAA2B,UAAkB,KAAqB;CAEvG,OAAO,KAAK,IAAI,KAAK,KAAK,IAAI,GADjB,SAAS,QAAQ,OAAO,SAAS,KAAK,IAAI,KAAK,MAAM,KAAK,IAAI,QACtC,CAAC;AACvC;;;;;;;;;AAUA,MAAM,sBAAwE;CAC7E,UAAU;CACV,UAAU;CACV,gBAAgB;CAChB,YAAY;AACb;;AAGA,MAAa,mCAAmC,OAAO,KAAK,mBAAmB;;;;;;;;;;AAW/E,MAAM,cAAqD;CAC1D,gBAAgB;CAChB,eAAe;CACf,gBAAgB;CAChB,eAAe;CACf,eAAe;CACf,cAAc;CACd,iBAAiB;CACjB,gBAAgB;CAChB,cAAc;CACd,aAAa;AACd;;AAGA,MAAa,2BAA2B,OAAO,KAAK,WAAW;;;;;;;;;;;;;;;;AAiB/D,SAAgB,0BACf,UACA,MACA,UACS;CACT,MAAM,UAAoB,CAAC;CAC3B,IAAI,UAAU,QACb,QAAQ,KAAK,4BAA4B,SAAS,KAAI,MAAK,IAAI,iBAAiB,CAAC,EAAE,EAAE,CAAC,CAAC,KAAK,IAAI,EAAE,EAAE;CAGrG,QAAQ,UAAU,SAAS,QAA3B;EACC,KAAK;GACJ,QAAQ,KAAK,2CAA2C,2CAA2C;GACnG;EACD,KAAK,UACJ,QAAQ,KAAK,0FAA0F;CAIzG;CAEA,MAAM,gBAAgB,CAAC,GAAG,IAAI,IAAI,UAAU,iBAAiB,CAAC,CAAC,CAAC;CAChE,IAAI,cAAc,SAAS,GAAG;EAC7B,MAAM,cAAc,cAAc,KAAI,MAAK;GAC1C,MAAM,SAAS,oBAAoB;GACnC,IAAI,UAAU,MAAM,MAAM,IAAI,MAAM,iDAAiD,EAAE,eAAe;GAEtG,OAAO;EACR,CAAC;EACD,QAAQ,KAAK,IAAI,YAAY,KAAK,MAAM,EAAE,EAAE;CAC7C;CAEA,MAAM,OAAO,UAAU,MAAM,KAAK;CAClC,IAAI,MACH,QAAQ,KAAK,4BAA4B,iBAAiB,IAAI,EAAE,EAAE;CAEnE,KAAK,MAAM,SAAS,UAAU,UAAU,CAAC,GACxC,QAAQ,KAAK,2BAA2B,iBAAiB,KAAK,EAAE,EAAE;CAEnE,IAAI,UAAU,gBAAgB,MAC7B,QAAQ,KAAK,4BAA4B,WAAW,SAAS,cAAc,cAAc,EAAE,EAAE;CAE9F,IAAI,UAAU,gBAAgB,MAC7B,QAAQ,KAAK,4BAA4B,WAAW,SAAS,cAAc,cAAc,EAAE,EAAE;CAG9F,MAAM,SAAS,YAAY;CAC3B,IAAI,UAAU,MAAM,MAAM,IAAI,MAAM,oDAAoD,KAAK,EAAE;CAK/F,OAAO,oCADO,QAAQ,SAAS,IAAI,UAAU,QAAQ,KAAK,OAAO,MAAM,GACtB,YAAY,OAAO;AACrE;;;;;;AAOA,SAAS,WAAW,OAAe,MAAsB;CACxD,OAAO,kBAAkB,OAAO,IAAI,CAAC,CAAC,YAAY,CAAC,CAAC,QAAQ,SAAS,GAAG;AACzE;;;;;;;;AASA,SAAS,kBAAkB,OAAe,MAAoB;CAC7D,MAAM,OAAO,eAAe,KAAK;CACjC,IAAI,QAAQ,MAAM,MAAM,IAAI,MAAM,WAAW,KAAK,IAAI,MAAM,qCAAqC;CAEjG,OAAO;AACR;AAEA,SAAS,eAAe,OAAiC;CACxD,MAAM,UAAU,MAAM,KAAK;CAC3B,MAAM,QAAQ,4BAA4B,KAAK,OAAO;CACtD,MAAM,OAAO,SAAS,OAAO,IAAI,KAAK,KAAK,IAAI,OAAO,MAAM,EAAE,GAAG,OAAO,MAAM,EAAE,IAAI,GAAG,OAAO,MAAM,EAAE,CAAC,CAAC,IAAI;CAC5G,OAAO,QAAQ,QAAQ,OAAO,MAAM,KAAK,QAAQ,CAAC,KAAK,KAAK,YAAY,CAAC,CAAC,MAAM,GAAG,EAAE,MAAM,UACxF,KAAA,IACA;AACJ;;;;;AAMA,SAAgB,0BACf,UACqB;CACrB,KAAK,MAAM,CAAC,MAAM,UAAU,CAC3B,CAAC,gBAAgB,UAAU,YAAY,GACvC,CAAC,gBAAgB,UAAU,YAAY,CACxC,GACC,IAAI,SAAS,QAAQ,eAAe,KAAK,KAAK,MAC7C,OAAO,WAAW,KAAK,IAAI,MAAM;AAIpC;;;;;;;;;;;;;;;;AAiBA,SAAgB,+BACf,UACuC;CACvC,MAAM,OAAO,UAAU,MAAM,KAAK,CAAC,CAAC,YAAY;CAChD,MAAM,QAAQ,UAAU;CACxB,MAAM,eACL,UAAU,gBAAgB,OAAO,kBAAkB,SAAS,cAAc,cAAc,IAAI,KAAA;CAC7F,MAAM,eACL,UAAU,gBAAgB,OAAO,kBAAkB,SAAS,cAAc,cAAc,IAAI,KAAA;CAE7F,QAAO,QACL,CAAC,QAAQ,GAAG,MAAM,YAAY,CAAC,CAAC,SAAS,IAAI,MAAM,GAAG,aAAa,YAAY,CAAC,CAAC,SAAS,IAAI,KAAK,YACnG,SAAS,QAAQ,GAAG,YAAY,WAChC,gBAAgB,QAAQ,GAAG,eAAe,kBAC1C,gBAAgB,QAAQ,GAAG,eAAe;AAC7C;;AAGA,MAAa,8BAAoD;CAChE;CACA;CACA;CACA;AACD;AAcA,SAAgB,iCACf,IACA,MACA,UACiC;CACjC,OAAO;EAAE,OAAO,KAAK,WAAW,SAAS,IAAI,GAAG,cAAc,GAAG,YAAA,CAAa,QAAQ;EAAa;CAAS;AAC7G;;AAGA,SAAgB,uCACf,GACA,GACA,MACS;CACT,IAAI,EAAE,SAAS,EAAE,MAAM,OAAO,KAAK,SAAS,MAAM,IAAI,EAAE,OAAO,EAAE,OAAO,EAAE,OAAO,EAAE;CAEnF,OAAO,EAAE,WAAW,EAAE,WAAW,KAAK,EAAE,WAAW,EAAE,WAAW,IAAI;AACrE;;;;;;;;AAqBA,SAAgB,kCAAkC,OAAwB;CACzE,OAAO,YAAY,KAAK,UAAU,KAAK,CAAC;AACzC;;AAGA,SAAgB,kCACf,QACA,KAC2C;CAC3C,IAAI,UAAU,MAAM,OAAO,KAAA;CAE3B,IAAI;CACJ,IAAI;EACH,SAAS,KAAK,MAAM,MAAM;CAC3B,QAAQ,CAAC;CAET,MAAM,QAAQ,QAAQ;CACtB,IACC,QAAQ,QAAQ,OAChB,OAAO,OAAO,UAAU,YACxB,CAAC,OAAO,SACR,CAAC,OAAO,cAAc,OAAO,IAAI,KACjC,OAAO,OAAQ,KACf,OAAO,OAAO,SAAS,YACvB,CAAC,OAAO,SAAS,MAAM,IAAI,KAC3B,OAAO,MAAM,aAAa,UAE1B,MAAM,IAAI,MACT,iGACD;CAGD,OAAO;EAAO;EAAK,OAAO,OAAO;EAAO,MAAM,OAAO;EAAO,OAAO;GAAE,MAAM,MAAM;GAAM,UAAU,MAAM;EAAS;CAAE;AACnH;;AA2BA,SAAgB,+BAA+B,YAAoB,MAAsB;CACxF,OAAO,YAAY,KAAK,UAAU,CAAC,YAAY,IAAI,CAAC,CAAC;AACtD;;;;;AAMA,SAAgB,+BAA+B,QAAqC;CACnF,OAAO,UAAU,QAAQ,gBAAgB,MAAM,MAAM;AACtD;;;;;;;;;;;AAYA,SAAgB,+BACf,QACA,KACA,UACwC;CACxC,IAAI,UAAU,MAAM,OAAO,KAAA;CAE3B,MAAM,aAAa,gBAAgB,MAAM;CACzC,IAAI,cAAc,QAAQ,OAAO,cAAc,UAAU,KAAK,cAAc,GAC3E,OAAO,eAAe,IAAI,KAAA,IAAY;EAAO;EAAK,SAAS,aAAa,KAAK;EAAU,MAAM;CAAW;CAGzG,IAAI;CACJ,IAAI;EACH,SAAS,KAAK,MAAM,MAAM;CAC3B,QAAQ,CAAC;CAET,IACC,QAAQ,QAAQ,OAChB,OAAO,OAAO,aAAa,YAC3B,CAAC,OAAO,YACR,CAAC,OAAO,cAAc,OAAO,MAAM,KACnC,OAAO,SAAU,KACjB,CAAC,OAAO,cAAc,OAAO,IAAI,KACjC,OAAO,OAAQ,GAEf,MAAM,IAAI,MAAM,8FAA8F;CAG/G,OAAO;EAAO;EAAK,UAAU,OAAO;EAAU,QAAQ,OAAO;EAAS,MAAM,OAAO;CAAM;AAC1F"}