@cesar-richard/git-connector-sdk 4.19.1 → 4.20.0

package/dist/schema.d.ts

@@ -1216,6 +1216,34 @@ export interface components {
             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;
+            /** @description MERGED PR/MRs in the window that no issue bills — the second kind of deliverable (a dependabot bump, a hotfix with no ticket), which until now counted in no CRA line at all. Disjoint from `issues` by construction: a PR/MR effectively billed by an issue (see `linkedActivities[].attributable`) is never listed here, which is what makes double billing impossible. Filtered by the same `?author`/`?identity` (on the RESOLVED attribution, so on the merger when the author is a bot), `?projectKey` (the CODE repo here), `?source` and `?application` (by repo ownership alone, never by issue claim) as `issues`. */
+            standalone: {
+                source: "github" | "gitlab";
+                /** @description Dépôt de CODE de la MR/PR (`owner/repo` sur GitHub, `group/sub/project` sur GitLab) — jamais un tracker d'issues, contrairement au `projectKey` de `DeliverableIssue`. */
+                projectKey: string;
+                /** @description Numéro de la PR/MR dans son dépôt de code. À ne PAS confondre avec un numéro d'issue : les deux espaces de numérotation sont disjoints. */
+                number: string | number;
+                title: string;
+                url: string;
+                /** @description Horodatage du merge, et seul ancrage de fenêtre de ce livrable. Non nullable : une PR/MR non mergée n'est pas un livrable autonome du tout (même porte que pour les issues — fermée sans merge n'a rien livré). */
+                mergedAt: string;
+                author: string | null;
+                /** @description Login de qui a mergé. Peuplé par la liste des MR sur GitLab et par l'enrichissement GraphQL sur GitHub ; `null` sur les PR GitHub synchronisées avant ce champ, tant qu'un backfill complet n'a pas tourné. */
+                mergedBy: string | null;
+                /** @description Qui est crédité. `null` quand la requête ne porte ni `?author` ni `?identity` — même convention que `issues[].attribution` : sans personne à qui imputer, la question n'est pas posée. Avec un filtre de personne, l'objet est toujours présent (voir `kind: "none"` pour « personne n'est résolvable »). */
+                attribution: {
+                    /** @description Login crédité, ou null quand aucun des deux candidats n'est une personne résolvable. Jamais un nom d'affichage — même règle stricte que `author` partout ailleurs. */
+                    login: string | null;
+                    /** @description Quel signal a produit `login`. `author` = l'auteur de la PR/MR, le cas normal. `merger` = l'auteur est un bot (login suffixé `[bot]`), donc le travail réel est la relecture et le merge. `none` = ni l'un ni l'autre n'est une personne résolvable, et `login` est null. */
+                    kind: "author" | "merger" | "none";
+                } | 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[];
+            }[];
+            /** @description Count of standalone deliverables matching the window/filters — NOT the page size, and deliberately NOT merged into `total`, which keeps describing `issues` alone. Compare against `standalone.length` + `offset` to know whether more remains. */
+            standaloneTotal: string | number;
+            /** @description True when this page is not the whole window for `standalone` (`standaloneTotal > offset + standalone.length`). Independent of `truncated`: `limit`/`offset` page the two arrays separately, so one can be complete while the other is not — a partial page must say so for each (the lesson of #72, and it holds for both arrays). */
+            standaloneTruncated: 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). `rule_status_set` = a delivery STATUS was set in the window; `in_progress_opened_status_active` = an opened status is currently set; `in_progress_status_after_window` = the delivery status was set AFTER the window. */
@@ -2029,6 +2057,35 @@ export interface components {
                 url: string | null;
             }[];
         };
+        StandaloneAttribution: {
+            /** @description Login crédité, ou null quand aucun des deux candidats n'est une personne résolvable. Jamais un nom d'affichage — même règle stricte que `author` partout ailleurs. */
+            login: string | null;
+            /** @description Quel signal a produit `login`. `author` = l'auteur de la PR/MR, le cas normal. `merger` = l'auteur est un bot (login suffixé `[bot]`), donc le travail réel est la relecture et le merge. `none` = ni l'un ni l'autre n'est une personne résolvable, et `login` est null. */
+            kind: "author" | "merger" | "none";
+        };
+        StandaloneDeliverable: {
+            source: "github" | "gitlab";
+            /** @description Dépôt de CODE de la MR/PR (`owner/repo` sur GitHub, `group/sub/project` sur GitLab) — jamais un tracker d'issues, contrairement au `projectKey` de `DeliverableIssue`. */
+            projectKey: string;
+            /** @description Numéro de la PR/MR dans son dépôt de code. À ne PAS confondre avec un numéro d'issue : les deux espaces de numérotation sont disjoints. */
+            number: string | number;
+            title: string;
+            url: string;
+            /** @description Horodatage du merge, et seul ancrage de fenêtre de ce livrable. Non nullable : une PR/MR non mergée n'est pas un livrable autonome du tout (même porte que pour les issues — fermée sans merge n'a rien livré). */
+            mergedAt: string;
+            author: string | null;
+            /** @description Login de qui a mergé. Peuplé par la liste des MR sur GitLab et par l'enrichissement GraphQL sur GitHub ; `null` sur les PR GitHub synchronisées avant ce champ, tant qu'un backfill complet n'a pas tourné. */
+            mergedBy: string | null;
+            /** @description Qui est crédité. `null` quand la requête ne porte ni `?author` ni `?identity` — même convention que `issues[].attribution` : sans personne à qui imputer, la question n'est pas posée. Avec un filtre de personne, l'objet est toujours présent (voir `kind: "none"` pour « personne n'est résolvable »). */
+            attribution: {
+                /** @description Login crédité, ou null quand aucun des deux candidats n'est une personne résolvable. Jamais un nom d'affichage — même règle stricte que `author` partout ailleurs. */
+                login: string | null;
+                /** @description Quel signal a produit `login`. `author` = l'auteur de la PR/MR, le cas normal. `merger` = l'auteur est un bot (login suffixé `[bot]`), donc le travail réel est la relecture et le merge. `none` = ni l'un ni l'autre n'est une personne résolvable, et `login` est null. */
+                kind: "author" | "merger" | "none";
+            } | 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[];
+        };
         StateTransitionEventMeta: {
             prevState?: string | null;
         } & {
@@ -5591,19 +5648,19 @@ export interface operations {
                 from?: string;
                 /** @description Window end, ISO date (YYYY-MM-DD, inclusive end-of-day) or datetime. Required. */
                 to?: string;
-                /** @description CSV of project keys to restrict to. */
+                /** @description CSV of project keys to restrict to. On `issues` these are issue TRACKERS; on `standalone` the same values are matched against the CODE repo of the PR/MR (the two arrays do not share a key space). */
                 projectKey?: string;
-                /** @description CSV of author login aliases (case-insensitive). When set, only issues attributable to one of the aliases are returned and `attribution` is populated; when absent, all window deliverables are returned with `attribution: null`. */
+                /** @description CSV of author login aliases (case-insensitive). When set, only issues attributable to one of the aliases are returned and `attribution` is populated; when absent, all window deliverables are returned with `attribution: null`. Applies to `standalone` too, on its RESOLVED attribution — so on the MERGER when the PR's author is a bot, which is the whole point of counting dependabot bumps at all. */
                 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. */
+                /** @description Filter by application slug (see /v1/applications). An unknown slug returns 404, never an empty list. Combines freely with ?author/?identity. On `issues` the three-signal issue claim applies; on `standalone` a PR/MR is claimed by REPO OWNERSHIP alone, so only PR/MRs living in the application's code repos are kept. */
                 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. */
+                /** @description Max number of deliverables to return — applied to `issues` and `standalone` INDEPENDENTLY (each array is sliced to this many, and each reports its own total/truncated flag). 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;
@@ -5896,6 +5953,34 @@ export interface operations {
                         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;
+                        /** @description MERGED PR/MRs in the window that no issue bills — the second kind of deliverable (a dependabot bump, a hotfix with no ticket), which until now counted in no CRA line at all. Disjoint from `issues` by construction: a PR/MR effectively billed by an issue (see `linkedActivities[].attributable`) is never listed here, which is what makes double billing impossible. Filtered by the same `?author`/`?identity` (on the RESOLVED attribution, so on the merger when the author is a bot), `?projectKey` (the CODE repo here), `?source` and `?application` (by repo ownership alone, never by issue claim) as `issues`. */
+                        standalone: {
+                            source: "github" | "gitlab";
+                            /** @description Dépôt de CODE de la MR/PR (`owner/repo` sur GitHub, `group/sub/project` sur GitLab) — jamais un tracker d'issues, contrairement au `projectKey` de `DeliverableIssue`. */
+                            projectKey: string;
+                            /** @description Numéro de la PR/MR dans son dépôt de code. À ne PAS confondre avec un numéro d'issue : les deux espaces de numérotation sont disjoints. */
+                            number: string | number;
+                            title: string;
+                            url: string;
+                            /** @description Horodatage du merge, et seul ancrage de fenêtre de ce livrable. Non nullable : une PR/MR non mergée n'est pas un livrable autonome du tout (même porte que pour les issues — fermée sans merge n'a rien livré). */
+                            mergedAt: string;
+                            author: string | null;
+                            /** @description Login de qui a mergé. Peuplé par la liste des MR sur GitLab et par l'enrichissement GraphQL sur GitHub ; `null` sur les PR GitHub synchronisées avant ce champ, tant qu'un backfill complet n'a pas tourné. */
+                            mergedBy: string | null;
+                            /** @description Qui est crédité. `null` quand la requête ne porte ni `?author` ni `?identity` — même convention que `issues[].attribution` : sans personne à qui imputer, la question n'est pas posée. Avec un filtre de personne, l'objet est toujours présent (voir `kind: "none"` pour « personne n'est résolvable »). */
+                            attribution: {
+                                /** @description Login crédité, ou null quand aucun des deux candidats n'est une personne résolvable. Jamais un nom d'affichage — même règle stricte que `author` partout ailleurs. */
+                                login: string | null;
+                                /** @description Quel signal a produit `login`. `author` = l'auteur de la PR/MR, le cas normal. `merger` = l'auteur est un bot (login suffixé `[bot]`), donc le travail réel est la relecture et le merge. `none` = ni l'un ni l'autre n'est une personne résolvable, et `login` est null. */
+                                kind: "author" | "merger" | "none";
+                            } | 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[];
+                        }[];
+                        /** @description Count of standalone deliverables matching the window/filters — NOT the page size, and deliberately NOT merged into `total`, which keeps describing `issues` alone. Compare against `standalone.length` + `offset` to know whether more remains. */
+                        standaloneTotal: string | number;
+                        /** @description True when this page is not the whole window for `standalone` (`standaloneTotal > offset + standalone.length`). Independent of `truncated`: `limit`/`offset` page the two arrays separately, so one can be complete while the other is not — a partial page must say so for each (the lesson of #72, and it holds for both arrays). */
+                        standaloneTruncated: boolean;
                     };
                     "multipart/form-data": {
                         issues: {
@@ -6174,6 +6259,34 @@ export interface operations {
                         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;
+                        /** @description MERGED PR/MRs in the window that no issue bills — the second kind of deliverable (a dependabot bump, a hotfix with no ticket), which until now counted in no CRA line at all. Disjoint from `issues` by construction: a PR/MR effectively billed by an issue (see `linkedActivities[].attributable`) is never listed here, which is what makes double billing impossible. Filtered by the same `?author`/`?identity` (on the RESOLVED attribution, so on the merger when the author is a bot), `?projectKey` (the CODE repo here), `?source` and `?application` (by repo ownership alone, never by issue claim) as `issues`. */
+                        standalone: {
+                            source: "github" | "gitlab";
+                            /** @description Dépôt de CODE de la MR/PR (`owner/repo` sur GitHub, `group/sub/project` sur GitLab) — jamais un tracker d'issues, contrairement au `projectKey` de `DeliverableIssue`. */
+                            projectKey: string;
+                            /** @description Numéro de la PR/MR dans son dépôt de code. À ne PAS confondre avec un numéro d'issue : les deux espaces de numérotation sont disjoints. */
+                            number: string | number;
+                            title: string;
+                            url: string;
+                            /** @description Horodatage du merge, et seul ancrage de fenêtre de ce livrable. Non nullable : une PR/MR non mergée n'est pas un livrable autonome du tout (même porte que pour les issues — fermée sans merge n'a rien livré). */
+                            mergedAt: string;
+                            author: string | null;
+                            /** @description Login de qui a mergé. Peuplé par la liste des MR sur GitLab et par l'enrichissement GraphQL sur GitHub ; `null` sur les PR GitHub synchronisées avant ce champ, tant qu'un backfill complet n'a pas tourné. */
+                            mergedBy: string | null;
+                            /** @description Qui est crédité. `null` quand la requête ne porte ni `?author` ni `?identity` — même convention que `issues[].attribution` : sans personne à qui imputer, la question n'est pas posée. Avec un filtre de personne, l'objet est toujours présent (voir `kind: "none"` pour « personne n'est résolvable »). */
+                            attribution: {
+                                /** @description Login crédité, ou null quand aucun des deux candidats n'est une personne résolvable. Jamais un nom d'affichage — même règle stricte que `author` partout ailleurs. */
+                                login: string | null;
+                                /** @description Quel signal a produit `login`. `author` = l'auteur de la PR/MR, le cas normal. `merger` = l'auteur est un bot (login suffixé `[bot]`), donc le travail réel est la relecture et le merge. `none` = ni l'un ni l'autre n'est une personne résolvable, et `login` est null. */
+                                kind: "author" | "merger" | "none";
+                            } | 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[];
+                        }[];
+                        /** @description Count of standalone deliverables matching the window/filters — NOT the page size, and deliberately NOT merged into `total`, which keeps describing `issues` alone. Compare against `standalone.length` + `offset` to know whether more remains. */
+                        standaloneTotal: string | number;
+                        /** @description True when this page is not the whole window for `standalone` (`standaloneTotal > offset + standalone.length`). Independent of `truncated`: `limit`/`offset` page the two arrays separately, so one can be complete while the other is not — a partial page must say so for each (the lesson of #72, and it holds for both arrays). */
+                        standaloneTruncated: boolean;
                     };
                     "text/plain": {
                         issues: {
@@ -6452,6 +6565,34 @@ export interface operations {
                         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;
+                        /** @description MERGED PR/MRs in the window that no issue bills — the second kind of deliverable (a dependabot bump, a hotfix with no ticket), which until now counted in no CRA line at all. Disjoint from `issues` by construction: a PR/MR effectively billed by an issue (see `linkedActivities[].attributable`) is never listed here, which is what makes double billing impossible. Filtered by the same `?author`/`?identity` (on the RESOLVED attribution, so on the merger when the author is a bot), `?projectKey` (the CODE repo here), `?source` and `?application` (by repo ownership alone, never by issue claim) as `issues`. */
+                        standalone: {
+                            source: "github" | "gitlab";
+                            /** @description Dépôt de CODE de la MR/PR (`owner/repo` sur GitHub, `group/sub/project` sur GitLab) — jamais un tracker d'issues, contrairement au `projectKey` de `DeliverableIssue`. */
+                            projectKey: string;
+                            /** @description Numéro de la PR/MR dans son dépôt de code. À ne PAS confondre avec un numéro d'issue : les deux espaces de numérotation sont disjoints. */
+                            number: string | number;
+                            title: string;
+                            url: string;
+                            /** @description Horodatage du merge, et seul ancrage de fenêtre de ce livrable. Non nullable : une PR/MR non mergée n'est pas un livrable autonome du tout (même porte que pour les issues — fermée sans merge n'a rien livré). */
+                            mergedAt: string;
+                            author: string | null;
+                            /** @description Login de qui a mergé. Peuplé par la liste des MR sur GitLab et par l'enrichissement GraphQL sur GitHub ; `null` sur les PR GitHub synchronisées avant ce champ, tant qu'un backfill complet n'a pas tourné. */
+                            mergedBy: string | null;
+                            /** @description Qui est crédité. `null` quand la requête ne porte ni `?author` ni `?identity` — même convention que `issues[].attribution` : sans personne à qui imputer, la question n'est pas posée. Avec un filtre de personne, l'objet est toujours présent (voir `kind: "none"` pour « personne n'est résolvable »). */
+                            attribution: {
+                                /** @description Login crédité, ou null quand aucun des deux candidats n'est une personne résolvable. Jamais un nom d'affichage — même règle stricte que `author` partout ailleurs. */
+                                login: string | null;
+                                /** @description Quel signal a produit `login`. `author` = l'auteur de la PR/MR, le cas normal. `merger` = l'auteur est un bot (login suffixé `[bot]`), donc le travail réel est la relecture et le merge. `none` = ni l'un ni l'autre n'est une personne résolvable, et `login` est null. */
+                                kind: "author" | "merger" | "none";
+                            } | 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[];
+                        }[];
+                        /** @description Count of standalone deliverables matching the window/filters — NOT the page size, and deliberately NOT merged into `total`, which keeps describing `issues` alone. Compare against `standalone.length` + `offset` to know whether more remains. */
+                        standaloneTotal: string | number;
+                        /** @description True when this page is not the whole window for `standalone` (`standaloneTotal > offset + standalone.length`). Independent of `truncated`: `limit`/`offset` page the two arrays separately, so one can be complete while the other is not — a partial page must say so for each (the lesson of #72, and it holds for both arrays). */
+                        standaloneTruncated: boolean;
                     };
                 };
             };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cesar-richard/git-connector-sdk",
-  "version": "4.19.1",
+  "version": "4.20.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": {