@cesar-richard/git-connector-sdk 4.8.4 → 4.10.0

package/dist/schema.d.ts

@@ -132,6 +132,22 @@ export interface paths {
         patch: operations["patchV1ProjectsBySourceByProjectKeyDelivery-rules"];
         trace?: never;
     };
+    "/v1/applications/{slug}/delivery-rules": {
+        parameters: {
+            query?: never;
+            header?: never;
+            path?: never;
+            cookie?: never;
+        };
+        get: operations["getV1ApplicationsBySlugDelivery-rules"];
+        put?: never;
+        post?: never;
+        delete?: never;
+        options?: never;
+        head?: never;
+        patch: operations["patchV1ApplicationsBySlugDelivery-rules"];
+        trace?: never;
+    };
     "/v1/projects": {
         parameters: {
             query?: never;
@@ -228,6 +244,22 @@ export interface paths {
         patch?: never;
         trace?: never;
     };
+    "/v1/applications": {
+        parameters: {
+            query?: never;
+            header?: never;
+            path?: never;
+            cookie?: never;
+        };
+        get: operations["getV1Applications"];
+        put?: never;
+        post?: never;
+        delete?: never;
+        options?: never;
+        head?: never;
+        patch?: never;
+        trace?: never;
+    };
 }
 export type webhooks = Record<string, never>;
 export interface components {
@@ -288,6 +320,8 @@ export interface components {
                 mergedBy: string | null;
                 /** @description Branch merged INTO. The source side is `branch`. */
                 targetBranch: string | null;
+                /** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
+                applications: string[];
                 number: string | number;
                 title: string;
                 body: string | null;
@@ -393,6 +427,8 @@ export interface components {
             mergedBy: string | null;
             /** @description Branch merged INTO. The source side is `branch`. */
             targetBranch: string | null;
+            /** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
+            applications: string[];
             number: string | number;
             title: string;
             body: string | null;
@@ -450,6 +486,59 @@ export interface components {
             provider: "github" | "gitlab";
             login: string;
         };
+        ApplicationCodeRepoRef: {
+            provider: "github" | "gitlab";
+            projectKey: string;
+        };
+        ApplicationDeliveryRules: {
+            applicationSlug: string;
+            /** @description Labels whose addition marks an issue delivered FOR THIS APPLICATION. Non-empty means these rules replace the tracker's for every issue the application claims; empty means the application declares nothing and its tracker's rules stay in force. */
+            deliveryLabels: string[];
+            /** @description Labels marking an issue in progress for this application. Only read when `deliveryLabels` is non-empty — a rule set with no delivery label cannot decide a delivery and never shadows the tracker's. */
+            openedLabels: string[];
+            updatedAt: string | null;
+        };
+        ApplicationIssueRepoRef: {
+            provider: "github" | "gitlab";
+            projectKey: string;
+            isDefault: boolean;
+        };
+        ApplicationSummary: {
+            slug: string;
+            name: string;
+            /** @description Code repos (PR/MR source) this application owns. */
+            codeRepos: {
+                provider: "github" | "gitlab";
+                projectKey: string;
+            }[];
+            /** @description Issue trackers linked to this application. `isDefault` marks the tracker a bare `#N` in one of its code repos resolves to. */
+            issueRepos: {
+                provider: "github" | "gitlab";
+                projectKey: string;
+                isDefault: boolean;
+            }[];
+            /** @description Issue-tracker labels that claim an issue for this application, independent of any PR/MR link. */
+            labels: string[];
+        };
+        ApplicationsListResponse: {
+            applications: {
+                slug: string;
+                name: string;
+                /** @description Code repos (PR/MR source) this application owns. */
+                codeRepos: {
+                    provider: "github" | "gitlab";
+                    projectKey: string;
+                }[];
+                /** @description Issue trackers linked to this application. `isDefault` marks the tracker a bare `#N` in one of its code repos resolves to. */
+                issueRepos: {
+                    provider: "github" | "gitlab";
+                    projectKey: string;
+                    isDefault: boolean;
+                }[];
+                /** @description Issue-tracker labels that claim an issue for this application, independent of any PR/MR link. */
+                labels: string[];
+            }[];
+        };
         CiPipelineEventMeta: {
             runId?: (string | number) | null;
             sha?: string | null;
@@ -781,6 +870,8 @@ export interface components {
             healthStatus: string | null;
             /** @description Incident severity. Meaningful when `issueType === 'incident'`. */
             severity: string | null;
+            /** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
+            applications: string[];
             iteration: {
                 id: string | number;
                 title: string;
@@ -1052,6 +1143,8 @@ export interface components {
                 healthStatus: string | null;
                 /** @description Incident severity. Meaningful when `issueType === 'incident'`. */
                 severity: string | null;
+                /** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
+                applications: string[];
                 iteration: {
                     id: string | number;
                     title: string;
@@ -1081,6 +1174,10 @@ export interface components {
                     changedBy: string | null;
                 }[];
             }[];
+            /** @description Count of delivered issues matching the window/filters — NOT the page size. A CRA is an activity report: a page quietly presented as the whole answer removes deliveries from it with nothing on screen to say so (GH #72, 349 of 1175 real deliverables silently dropped). Compare against `issues.length` + `offset` to know whether more remains. In the rare case where the server's own internal candidate-loading ceiling was reached (an installation with more matching issues than that ceiling), `total` is a LOWER bound rather than exact — `truncated` is `true` in that case regardless of `limit`/`offset`, which is the signal to trust. */
+            total: string | number;
+            /** @description True when this page is not the whole window (`total > offset + issues.length`), OR when the server's internal candidate-loading ceiling was itself reached (see `total`) — in which case this is `true` even if the page looks complete by the slicing arithmetic alone. Raise `limit`/`offset` to see more. With `?application` set AND no `?limit` passed, candidate loading is already exhaustive (no SQL cap) before window filtering, so this is false and `total` is the exact count; passing `?limit` there opts back into normal paging and `truncated` is computed the same way as everywhere else. */
+            truncated: boolean;
         };
         DeliveryReason: {
             /** @description Discriminator: WHY the deliveryState was set. `rule_label_added` = a delivery label was added in the window; `closed_in_window` = fallback (no rule, issue closed in the window); `in_progress_opened_label_active` = a configured opened-label is currently active; `in_progress_delivered_after_window` = delivery label was added AFTER the window; `in_progress_fallback_open` = fallback (no rule, issue is open). */
@@ -1978,6 +2075,8 @@ export interface components {
             healthStatus: string | null;
             /** @description Incident severity. Meaningful when `issueType === 'incident'`. */
             severity: string | null;
+            /** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
+            applications: string[];
             iteration: {
                 id: string | number;
                 title: string;
@@ -2213,6 +2312,8 @@ export interface components {
                 healthStatus: string | null;
                 /** @description Incident severity. Meaningful when `issueType === 'incident'`. */
                 severity: string | null;
+                /** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
+                applications: string[];
                 iteration: {
                     id: string | number;
                     title: string;
@@ -2428,6 +2529,8 @@ export interface operations {
                 viewer?: string;
                 /** @description Filter by user identity ID (resolves to all aliases). Mutually exclusive with ?author. */
                 identity?: string;
+                /** @description Filter by application slug (see /v1/applications). An unknown slug returns 404, never an empty list. Combines freely with ?author/?identity — orthogonal to them, unlike their mutual exclusivity with each other. */
+                application?: string;
                 /** @description When '1', enriches each item with `authorIdentity: { id, displayName } | null`. */
                 withIdentity?: string;
             };
@@ -2501,6 +2604,8 @@ export interface operations {
                             healthStatus: string | null;
                             /** @description Incident severity. Meaningful when `issueType === 'incident'`. */
                             severity: string | null;
+                            /** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
+                            applications: string[];
                             iteration: {
                                 id: string | number;
                                 title: string;
@@ -2740,6 +2845,8 @@ export interface operations {
                             healthStatus: string | null;
                             /** @description Incident severity. Meaningful when `issueType === 'incident'`. */
                             severity: string | null;
+                            /** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
+                            applications: string[];
                             iteration: {
                                 id: string | number;
                                 title: string;
@@ -2979,6 +3086,8 @@ export interface operations {
                             healthStatus: string | null;
                             /** @description Incident severity. Meaningful when `issueType === 'incident'`. */
                             severity: string | null;
+                            /** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
+                            applications: string[];
                             iteration: {
                                 id: string | number;
                                 title: string;
@@ -3274,6 +3383,8 @@ export interface operations {
                         healthStatus: string | null;
                         /** @description Incident severity. Meaningful when `issueType === 'incident'`. */
                         severity: string | null;
+                        /** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
+                        applications: string[];
                         iteration: {
                             id: string | number;
                             title: string;
@@ -3508,6 +3619,8 @@ export interface operations {
                         healthStatus: string | null;
                         /** @description Incident severity. Meaningful when `issueType === 'incident'`. */
                         severity: string | null;
+                        /** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
+                        applications: string[];
                         iteration: {
                             id: string | number;
                             title: string;
@@ -3742,6 +3855,8 @@ export interface operations {
                         healthStatus: string | null;
                         /** @description Incident severity. Meaningful when `issueType === 'incident'`. */
                         severity: string | null;
+                        /** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
+                        applications: string[];
                         iteration: {
                             id: string | number;
                             title: string;
@@ -4011,6 +4126,8 @@ export interface operations {
                 user?: string;
                 /** @description Filter by user identity ID (resolves to all aliases). Mutually exclusive with ?user. */
                 identity?: string;
+                /** @description Filter by application slug (see /v1/applications): restricts to events whose repo is one of the application's CODE repos ONLY. LIMITATION: an issue claimed solely by a label (no code-repo link) has no events of its own here — events live on code repos, never on the issue tracker — so this filter is narrower than the `applications` field on /v1/work-items and /v1/activities, which also honours the label signal. An unknown slug returns 404, never an empty list. Combines freely with ?user/?identity. */
+                application?: string;
                 /** @description When '1', enriches each event with `authorIdentity: { id, displayName } | null`. */
                 withIdentity?: string;
                 repo?: string;
@@ -4783,6 +4900,8 @@ export interface operations {
                 author?: string;
                 /** @description Filter by user identity ID (resolves to all aliases). Mutually exclusive with ?author. */
                 identity?: string;
+                /** @description Filter by application slug (see /v1/applications). An unknown slug returns 404, never an empty list. Combines freely with ?author/?identity/?requestedReviewer — orthogonal to them. */
+                application?: string;
                 /** @description When '1', enriches each activity with `authorIdentity: { id, displayName } | null`. */
                 withIdentity?: string;
                 /** @description CSV of GitHub/GitLab logins requested as reviewers (case-insensitive, OR within, AND with the other filters). Answers 'what is waiting on this person's review?' — including PR/MR not linked to any issue, which `linkedActivities[]` on /v1/work-items cannot reach. Distinct from /v1/work-items' `reviewerIs`, which matches items ALREADY reviewed rather than awaiting review. Mutually exclusive with ?reviewerIdentity. */
@@ -4874,6 +4993,8 @@ export interface operations {
                             mergedBy: string | null;
                             /** @description Branch merged INTO. The source side is `branch`. */
                             targetBranch: string | null;
+                            /** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
+                            applications: string[];
                             number: string | number;
                             title: string;
                             body: string | null;
@@ -4980,6 +5101,8 @@ export interface operations {
                             mergedBy: string | null;
                             /** @description Branch merged INTO. The source side is `branch`. */
                             targetBranch: string | null;
+                            /** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
+                            applications: string[];
                             number: string | number;
                             title: string;
                             body: string | null;
@@ -5086,6 +5209,8 @@ export interface operations {
                             mergedBy: string | null;
                             /** @description Branch merged INTO. The source side is `branch`. */
                             targetBranch: string | null;
+                            /** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
+                            applications: string[];
                             number: string | number;
                             title: string;
                             body: string | null;
@@ -5185,10 +5310,16 @@ export interface operations {
                 author?: string;
                 /** @description Filter by user identity ID (resolves to all aliases for attribution). Mutually exclusive with ?author. */
                 identity?: string;
+                /** @description Filter by application slug (see /v1/applications). An unknown slug returns 404, never an empty list. Combines freely with ?author/?identity. */
+                application?: string;
                 /** @description When '1', attaches `authorIdentity: null` on each issue (placeholder until deliverablesCompute exposes the attributed login — see CR-553). */
                 withIdentity?: string;
                 /** @description github | gitlab. */
                 source?: string;
+                /** @description Max number of deliverables to return. Default 500, matching the historical (hardcoded) response size — raise it to see more of the window instead of guessing from a silently-capped list (GH #72). 0 is rejected (422): an empty page must never be read as 'nothing was delivered'. Paging does NOT reduce server work: `total` must describe the whole window, so every candidate in the window is loaded and run through `computeDeliverables` before the page is sliced. A consumer paging at limit=50 therefore pays one full window scan PER PAGE — prefer a single large limit. */
+                limit?: string | number;
+                /** @description Number of deliverables to skip, for paging past `limit`. Passing it alone (without `limit`) is enough to opt into pagination — the default limit of 500 then applies. This is a contract change from the historical behaviour: passing EITHER `limit` or `offset`, including `offset=0`, now opts into pagination, so a filtered call (e.g. `?application=x&offset=0`) that used to return its whole window exhaustively is now paged at the default limit. */
+                offset?: string | number;
             };
             header?: never;
             path?: never;
@@ -5443,6 +5574,8 @@ export interface operations {
                             healthStatus: string | null;
                             /** @description Incident severity. Meaningful when `issueType === 'incident'`. */
                             severity: string | null;
+                            /** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
+                            applications: string[];
                             iteration: {
                                 id: string | number;
                                 title: string;
@@ -5472,6 +5605,10 @@ export interface operations {
                                 changedBy: string | null;
                             }[];
                         }[];
+                        /** @description Count of delivered issues matching the window/filters — NOT the page size. A CRA is an activity report: a page quietly presented as the whole answer removes deliveries from it with nothing on screen to say so (GH #72, 349 of 1175 real deliverables silently dropped). Compare against `issues.length` + `offset` to know whether more remains. In the rare case where the server's own internal candidate-loading ceiling was reached (an installation with more matching issues than that ceiling), `total` is a LOWER bound rather than exact — `truncated` is `true` in that case regardless of `limit`/`offset`, which is the signal to trust. */
+                        total: string | number;
+                        /** @description True when this page is not the whole window (`total > offset + issues.length`), OR when the server's internal candidate-loading ceiling was itself reached (see `total`) — in which case this is `true` even if the page looks complete by the slicing arithmetic alone. Raise `limit`/`offset` to see more. With `?application` set AND no `?limit` passed, candidate loading is already exhaustive (no SQL cap) before window filtering, so this is false and `total` is the exact count; passing `?limit` there opts back into normal paging and `truncated` is computed the same way as everywhere else. */
+                        truncated: boolean;
                     };
                     "multipart/form-data": {
                         issues: {
@@ -5715,6 +5852,8 @@ export interface operations {
                             healthStatus: string | null;
                             /** @description Incident severity. Meaningful when `issueType === 'incident'`. */
                             severity: string | null;
+                            /** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
+                            applications: string[];
                             iteration: {
                                 id: string | number;
                                 title: string;
@@ -5744,6 +5883,10 @@ export interface operations {
                                 changedBy: string | null;
                             }[];
                         }[];
+                        /** @description Count of delivered issues matching the window/filters — NOT the page size. A CRA is an activity report: a page quietly presented as the whole answer removes deliveries from it with nothing on screen to say so (GH #72, 349 of 1175 real deliverables silently dropped). Compare against `issues.length` + `offset` to know whether more remains. In the rare case where the server's own internal candidate-loading ceiling was reached (an installation with more matching issues than that ceiling), `total` is a LOWER bound rather than exact — `truncated` is `true` in that case regardless of `limit`/`offset`, which is the signal to trust. */
+                        total: string | number;
+                        /** @description True when this page is not the whole window (`total > offset + issues.length`), OR when the server's internal candidate-loading ceiling was itself reached (see `total`) — in which case this is `true` even if the page looks complete by the slicing arithmetic alone. Raise `limit`/`offset` to see more. With `?application` set AND no `?limit` passed, candidate loading is already exhaustive (no SQL cap) before window filtering, so this is false and `total` is the exact count; passing `?limit` there opts back into normal paging and `truncated` is computed the same way as everywhere else. */
+                        truncated: boolean;
                     };
                     "text/plain": {
                         issues: {
@@ -5987,6 +6130,8 @@ export interface operations {
                             healthStatus: string | null;
                             /** @description Incident severity. Meaningful when `issueType === 'incident'`. */
                             severity: string | null;
+                            /** @description Slugs of the applications (see /v1/applications) that claim this item. A code-repo item (PR/MR) is claimed by the application that declares its repo; an issue is claimed by label match (declared `issueLabels`) OR by being referenced through a CONFIRMED link from a PR/MR in one of the application's code repos OR by being hosted in one of those code repos itself (the GitHub shape where the code repo is also the tracker) — the signals are a union, so the array can hold more than one slug. ORDER IS SIGNIFICANT: the array is sorted by DECREASING attachment-signal strength — a `label` claim first, then a `link` claim, then a `code_repo` claim, the order declared in the application config breaking ties at equal strength — and the FIRST slug is the application whose delivery rules govern this issue (its own rules per field, falling back to the tracker's field by field — see GET /v1/applications/{slug}/delivery-rules). A hand-placed scoped label is an assertion of ownership; an issue merely living in a code repo is an organisational coincidence, so the former governs. Empty array when the item is not attached to any application, in which case the tracker's rules govern. */
+                            applications: string[];
                             iteration: {
                                 id: string | number;
                                 title: string;
@@ -6016,6 +6161,10 @@ export interface operations {
                                 changedBy: string | null;
                             }[];
                         }[];
+                        /** @description Count of delivered issues matching the window/filters — NOT the page size. A CRA is an activity report: a page quietly presented as the whole answer removes deliveries from it with nothing on screen to say so (GH #72, 349 of 1175 real deliverables silently dropped). Compare against `issues.length` + `offset` to know whether more remains. In the rare case where the server's own internal candidate-loading ceiling was reached (an installation with more matching issues than that ceiling), `total` is a LOWER bound rather than exact — `truncated` is `true` in that case regardless of `limit`/`offset`, which is the signal to trust. */
+                        total: string | number;
+                        /** @description True when this page is not the whole window (`total > offset + issues.length`), OR when the server's internal candidate-loading ceiling was itself reached (see `total`) — in which case this is `true` even if the page looks complete by the slicing arithmetic alone. Raise `limit`/`offset` to see more. With `?application` set AND no `?limit` passed, candidate loading is already exhaustive (no SQL cap) before window filtering, so this is false and `total` is the exact count; passing `?limit` there opts back into normal paging and `truncated` is computed the same way as everywhere else. */
+                        truncated: boolean;
                     };
                 };
             };
@@ -6152,6 +6301,173 @@ export interface operations {
             };
         };
     };
+    "getV1ApplicationsBySlugDelivery-rules": {
+        parameters: {
+            query?: never;
+            header?: never;
+            path: {
+                slug: string;
+            };
+            cookie?: never;
+        };
+        requestBody?: never;
+        responses: {
+            200: {
+                headers: {
+                    [name: string]: unknown;
+                };
+                content: {
+                    "application/json": {
+                        applicationSlug: string;
+                        /** @description Labels whose addition marks an issue delivered FOR THIS APPLICATION. Non-empty means these rules replace the tracker's for every issue the application claims; empty means the application declares nothing and its tracker's rules stay in force. */
+                        deliveryLabels: string[];
+                        /** @description Labels marking an issue in progress for this application. Only read when `deliveryLabels` is non-empty — a rule set with no delivery label cannot decide a delivery and never shadows the tracker's. */
+                        openedLabels: string[];
+                        updatedAt: string | null;
+                    };
+                    "multipart/form-data": {
+                        applicationSlug: string;
+                        /** @description Labels whose addition marks an issue delivered FOR THIS APPLICATION. Non-empty means these rules replace the tracker's for every issue the application claims; empty means the application declares nothing and its tracker's rules stay in force. */
+                        deliveryLabels: string[];
+                        /** @description Labels marking an issue in progress for this application. Only read when `deliveryLabels` is non-empty — a rule set with no delivery label cannot decide a delivery and never shadows the tracker's. */
+                        openedLabels: string[];
+                        updatedAt: string | null;
+                    };
+                    "text/plain": {
+                        applicationSlug: string;
+                        /** @description Labels whose addition marks an issue delivered FOR THIS APPLICATION. Non-empty means these rules replace the tracker's for every issue the application claims; empty means the application declares nothing and its tracker's rules stay in force. */
+                        deliveryLabels: string[];
+                        /** @description Labels marking an issue in progress for this application. Only read when `deliveryLabels` is non-empty — a rule set with no delivery label cannot decide a delivery and never shadows the tracker's. */
+                        openedLabels: string[];
+                        updatedAt: string | null;
+                    };
+                };
+            };
+            400: {
+                headers: {
+                    [name: string]: unknown;
+                };
+                content: {
+                    "application/json": {
+                        error: string;
+                    };
+                    "multipart/form-data": {
+                        error: string;
+                    };
+                    "text/plain": {
+                        error: string;
+                    };
+                };
+            };
+            404: {
+                headers: {
+                    [name: string]: unknown;
+                };
+                content: {
+                    "application/json": {
+                        error: string;
+                    };
+                    "multipart/form-data": {
+                        error: string;
+                    };
+                    "text/plain": {
+                        error: string;
+                    };
+                };
+            };
+        };
+    };
+    "patchV1ApplicationsBySlugDelivery-rules": {
+        parameters: {
+            query?: never;
+            header?: never;
+            path: {
+                slug: string;
+            };
+            cookie?: never;
+        };
+        requestBody: {
+            content: {
+                "application/json": {
+                    deliveryLabels?: string[];
+                    openedLabels?: string[];
+                };
+                "multipart/form-data": {
+                    deliveryLabels?: string[];
+                    openedLabels?: string[];
+                };
+                "text/plain": {
+                    deliveryLabels?: string[];
+                    openedLabels?: string[];
+                };
+            };
+        };
+        responses: {
+            200: {
+                headers: {
+                    [name: string]: unknown;
+                };
+                content: {
+                    "application/json": {
+                        applicationSlug: string;
+                        /** @description Labels whose addition marks an issue delivered FOR THIS APPLICATION. Non-empty means these rules replace the tracker's for every issue the application claims; empty means the application declares nothing and its tracker's rules stay in force. */
+                        deliveryLabels: string[];
+                        /** @description Labels marking an issue in progress for this application. Only read when `deliveryLabels` is non-empty — a rule set with no delivery label cannot decide a delivery and never shadows the tracker's. */
+                        openedLabels: string[];
+                        updatedAt: string | null;
+                    };
+                    "multipart/form-data": {
+                        applicationSlug: string;
+                        /** @description Labels whose addition marks an issue delivered FOR THIS APPLICATION. Non-empty means these rules replace the tracker's for every issue the application claims; empty means the application declares nothing and its tracker's rules stay in force. */
+                        deliveryLabels: string[];
+                        /** @description Labels marking an issue in progress for this application. Only read when `deliveryLabels` is non-empty — a rule set with no delivery label cannot decide a delivery and never shadows the tracker's. */
+                        openedLabels: string[];
+                        updatedAt: string | null;
+                    };
+                    "text/plain": {
+                        applicationSlug: string;
+                        /** @description Labels whose addition marks an issue delivered FOR THIS APPLICATION. Non-empty means these rules replace the tracker's for every issue the application claims; empty means the application declares nothing and its tracker's rules stay in force. */
+                        deliveryLabels: string[];
+                        /** @description Labels marking an issue in progress for this application. Only read when `deliveryLabels` is non-empty — a rule set with no delivery label cannot decide a delivery and never shadows the tracker's. */
+                        openedLabels: string[];
+                        updatedAt: string | null;
+                    };
+                };
+            };
+            400: {
+                headers: {
+                    [name: string]: unknown;
+                };
+                content: {
+                    "application/json": {
+                        error: string;
+                    };
+                    "multipart/form-data": {
+                        error: string;
+                    };
+                    "text/plain": {
+                        error: string;
+                    };
+                };
+            };
+            404: {
+                headers: {
+                    [name: string]: unknown;
+                };
+                content: {
+                    "application/json": {
+                        error: string;
+                    };
+                    "multipart/form-data": {
+                        error: string;
+                    };
+                    "text/plain": {
+                        error: string;
+                    };
+                };
+            };
+        };
+    };
     getV1Projects: {
         parameters: {
             query?: never;
@@ -6927,4 +7243,79 @@ export interface operations {
             };
         };
     };
+    getV1Applications: {
+        parameters: {
+            query?: never;
+            header?: never;
+            path?: never;
+            cookie?: never;
+        };
+        requestBody?: never;
+        responses: {
+            200: {
+                headers: {
+                    [name: string]: unknown;
+                };
+                content: {
+                    "application/json": {
+                        applications: {
+                            slug: string;
+                            name: string;
+                            /** @description Code repos (PR/MR source) this application owns. */
+                            codeRepos: {
+                                provider: "github" | "gitlab";
+                                projectKey: string;
+                            }[];
+                            /** @description Issue trackers linked to this application. `isDefault` marks the tracker a bare `#N` in one of its code repos resolves to. */
+                            issueRepos: {
+                                provider: "github" | "gitlab";
+                                projectKey: string;
+                                isDefault: boolean;
+                            }[];
+                            /** @description Issue-tracker labels that claim an issue for this application, independent of any PR/MR link. */
+                            labels: string[];
+                        }[];
+                    };
+                    "multipart/form-data": {
+                        applications: {
+                            slug: string;
+                            name: string;
+                            /** @description Code repos (PR/MR source) this application owns. */
+                            codeRepos: {
+                                provider: "github" | "gitlab";
+                                projectKey: string;
+                            }[];
+                            /** @description Issue trackers linked to this application. `isDefault` marks the tracker a bare `#N` in one of its code repos resolves to. */
+                            issueRepos: {
+                                provider: "github" | "gitlab";
+                                projectKey: string;
+                                isDefault: boolean;
+                            }[];
+                            /** @description Issue-tracker labels that claim an issue for this application, independent of any PR/MR link. */
+                            labels: string[];
+                        }[];
+                    };
+                    "text/plain": {
+                        applications: {
+                            slug: string;
+                            name: string;
+                            /** @description Code repos (PR/MR source) this application owns. */
+                            codeRepos: {
+                                provider: "github" | "gitlab";
+                                projectKey: string;
+                            }[];
+                            /** @description Issue trackers linked to this application. `isDefault` marks the tracker a bare `#N` in one of its code repos resolves to. */
+                            issueRepos: {
+                                provider: "github" | "gitlab";
+                                projectKey: string;
+                                isDefault: boolean;
+                            }[];
+                            /** @description Issue-tracker labels that claim an issue for this application, independent of any PR/MR link. */
+                            labels: string[];
+                        }[];
+                    };
+                };
+            };
+        };
+    };
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cesar-richard/git-connector-sdk",
-  "version": "4.8.4",
+  "version": "4.10.0",
   "description": "TypeScript SDK for the git-connector v1 API (work items + iterations aggregated from GitHub/GitLab). Version published on npm tracks server releases.",
   "license": "MIT",
   "repository": {