@cesar-richard/git-connector-sdk 4.13.0 → 4.15.0

package/dist/schema.d.ts

@@ -196,6 +196,23 @@ export interface paths {
         patch?: never;
         trace?: never;
     };
+    "/v1/projects/{source}/{projectKey}/statuses": {
+        parameters: {
+            query?: never;
+            header?: never;
+            path?: never;
+            cookie?: never;
+        };
+        /** @description Every value the tracker's native Status field can take, with its colour — the list a `workflow_rules.statusRules[].value` must be picked from. GitLab only: the GitHub Project v2 field has no reader, and that returns 400 rather than an empty list. */
+        get: operations["getV1ProjectsBySourceByProjectKeyStatuses"];
+        put?: never;
+        post?: never;
+        delete?: never;
+        options?: never;
+        head?: never;
+        patch?: never;
+        trace?: never;
+    };
     "/v1/identities": {
         parameters: {
             query?: never;
@@ -1920,6 +1937,26 @@ export interface components {
             }[];
             fetchedAt: string;
         };
+        ProjectStatus: {
+            /** @description Status value exactly as the tracker spells it — this is what `workflow_rules.statusRules[].value` must match, since the native-status stage of the cascade compares EXACTLY (no prefix stripping, unlike flow labels). */
+            name: string;
+            /** @description Raw provider form (`#1f75cb` on GitLab), `null` when the tracker gives none. Same convention as label colours: not normalized here, because `/v1` has always exposed the upstream form and a consumer that normalizes would break if this endpoint alone pre-normalized. */
+            color: string | null;
+            /** @description Rank the tracker gives the status, `null` when upstream says nothing. Applied to the array order, BUT measured on a real self-hosted GitLab (2026-10-07) every status came back with `position: 0` — so in practice the order falls back to the status name, alphabetically. Do not read this field as a board order: it is what the provider said, which may well be no ordering at all. A consumer re-sorting a filtered subset should expect to tie on 0 and break the tie the same way. */
+            position: number | null;
+        };
+        ProjectStatusesResponse: {
+            /** @description Every value the tracker's native Status field can take, in board order — the UNION over its work item types (issue, task, incident, test case), deduped by name, because GitLab serves all of them through the same project issues endpoint and any of their statuses can therefore reach an ingested payload. Empty array = the tracker genuinely declares no status; a failed read is an error status, never an empty list. */
+            statuses: {
+                /** @description Status value exactly as the tracker spells it — this is what `workflow_rules.statusRules[].value` must match, since the native-status stage of the cascade compares EXACTLY (no prefix stripping, unlike flow labels). */
+                name: string;
+                /** @description Raw provider form (`#1f75cb` on GitLab), `null` when the tracker gives none. Same convention as label colours: not normalized here, because `/v1` has always exposed the upstream form and a consumer that normalizes would break if this endpoint alone pre-normalized. */
+                color: string | null;
+                /** @description Rank the tracker gives the status, `null` when upstream says nothing. Applied to the array order, BUT measured on a real self-hosted GitLab (2026-10-07) every status came back with `position: 0` — so in practice the order falls back to the status name, alphabetically. Do not read this field as a board order: it is what the provider said, which may well be no ordering at all. A consumer re-sorting a filtered subset should expect to tie on 0 and break the tie the same way. */
+                position: number | null;
+            }[];
+            fetchedAt: string;
+        };
         ProjectsListResponse: {
             /** @description Every project the operator tracks, sorted by (source, projectKey). Sourced from the operator config, so a tracked project with no activity in any window still appears — do NOT derive this list by paginating /v1/work-items or /v1/activities, which silently omits quiet projects. */
             projects: {
@@ -7094,6 +7131,127 @@ export interface operations {
             };
         };
     };
+    getV1ProjectsBySourceByProjectKeyStatuses: {
+        parameters: {
+            query?: never;
+            header?: never;
+            path: {
+                source: string;
+                projectKey: string;
+            };
+            cookie?: never;
+        };
+        requestBody?: never;
+        responses: {
+            200: {
+                headers: {
+                    [name: string]: unknown;
+                };
+                content: {
+                    "application/json": {
+                        /** @description Every value the tracker's native Status field can take, in board order — the UNION over its work item types (issue, task, incident, test case), deduped by name, because GitLab serves all of them through the same project issues endpoint and any of their statuses can therefore reach an ingested payload. Empty array = the tracker genuinely declares no status; a failed read is an error status, never an empty list. */
+                        statuses: {
+                            /** @description Status value exactly as the tracker spells it — this is what `workflow_rules.statusRules[].value` must match, since the native-status stage of the cascade compares EXACTLY (no prefix stripping, unlike flow labels). */
+                            name: string;
+                            /** @description Raw provider form (`#1f75cb` on GitLab), `null` when the tracker gives none. Same convention as label colours: not normalized here, because `/v1` has always exposed the upstream form and a consumer that normalizes would break if this endpoint alone pre-normalized. */
+                            color: string | null;
+                            /** @description Rank the tracker gives the status, `null` when upstream says nothing. Applied to the array order, BUT measured on a real self-hosted GitLab (2026-10-07) every status came back with `position: 0` — so in practice the order falls back to the status name, alphabetically. Do not read this field as a board order: it is what the provider said, which may well be no ordering at all. A consumer re-sorting a filtered subset should expect to tie on 0 and break the tie the same way. */
+                            position: number | null;
+                        }[];
+                        fetchedAt: string;
+                    };
+                    "multipart/form-data": {
+                        /** @description Every value the tracker's native Status field can take, in board order — the UNION over its work item types (issue, task, incident, test case), deduped by name, because GitLab serves all of them through the same project issues endpoint and any of their statuses can therefore reach an ingested payload. Empty array = the tracker genuinely declares no status; a failed read is an error status, never an empty list. */
+                        statuses: {
+                            /** @description Status value exactly as the tracker spells it — this is what `workflow_rules.statusRules[].value` must match, since the native-status stage of the cascade compares EXACTLY (no prefix stripping, unlike flow labels). */
+                            name: string;
+                            /** @description Raw provider form (`#1f75cb` on GitLab), `null` when the tracker gives none. Same convention as label colours: not normalized here, because `/v1` has always exposed the upstream form and a consumer that normalizes would break if this endpoint alone pre-normalized. */
+                            color: string | null;
+                            /** @description Rank the tracker gives the status, `null` when upstream says nothing. Applied to the array order, BUT measured on a real self-hosted GitLab (2026-10-07) every status came back with `position: 0` — so in practice the order falls back to the status name, alphabetically. Do not read this field as a board order: it is what the provider said, which may well be no ordering at all. A consumer re-sorting a filtered subset should expect to tie on 0 and break the tie the same way. */
+                            position: number | null;
+                        }[];
+                        fetchedAt: string;
+                    };
+                    "text/plain": {
+                        /** @description Every value the tracker's native Status field can take, in board order — the UNION over its work item types (issue, task, incident, test case), deduped by name, because GitLab serves all of them through the same project issues endpoint and any of their statuses can therefore reach an ingested payload. Empty array = the tracker genuinely declares no status; a failed read is an error status, never an empty list. */
+                        statuses: {
+                            /** @description Status value exactly as the tracker spells it — this is what `workflow_rules.statusRules[].value` must match, since the native-status stage of the cascade compares EXACTLY (no prefix stripping, unlike flow labels). */
+                            name: string;
+                            /** @description Raw provider form (`#1f75cb` on GitLab), `null` when the tracker gives none. Same convention as label colours: not normalized here, because `/v1` has always exposed the upstream form and a consumer that normalizes would break if this endpoint alone pre-normalized. */
+                            color: string | null;
+                            /** @description Rank the tracker gives the status, `null` when upstream says nothing. Applied to the array order, BUT measured on a real self-hosted GitLab (2026-10-07) every status came back with `position: 0` — so in practice the order falls back to the status name, alphabetically. Do not read this field as a board order: it is what the provider said, which may well be no ordering at all. A consumer re-sorting a filtered subset should expect to tie on 0 and break the tie the same way. */
+                            position: number | null;
+                        }[];
+                        fetchedAt: string;
+                    };
+                };
+            };
+            400: {
+                headers: {
+                    [name: string]: unknown;
+                };
+                content: {
+                    "application/json": {
+                        error: string;
+                    };
+                    "multipart/form-data": {
+                        error: string;
+                    };
+                    "text/plain": {
+                        error: string;
+                    };
+                };
+            };
+            403: {
+                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;
+                    };
+                };
+            };
+            502: {
+                headers: {
+                    [name: string]: unknown;
+                };
+                content: {
+                    "application/json": {
+                        error: string;
+                    };
+                    "multipart/form-data": {
+                        error: string;
+                    };
+                    "text/plain": {
+                        error: string;
+                    };
+                };
+            };
+        };
+    };
     getV1Identities: {
         parameters: {
             query?: {

package/package.json

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