@cesar-richard/git-connector-sdk 4.11.0 → 4.12.0

package/dist/schema.d.ts

@@ -148,6 +148,22 @@ export interface paths {
         patch: operations["patchV1ApplicationsBySlugDelivery-rules"];
         trace?: never;
     };
+    "/v1/projects/{source}/{projectKey}/workflow-rules": {
+        parameters: {
+            query?: never;
+            header?: never;
+            path?: never;
+            cookie?: never;
+        };
+        get: operations["getV1ProjectsBySourceByProjectKeyWorkflow-rules"];
+        put: operations["putV1ProjectsBySourceByProjectKeyWorkflow-rules"];
+        post?: never;
+        delete?: never;
+        options?: never;
+        head?: never;
+        patch?: never;
+        trace?: never;
+    };
     "/v1/projects": {
         parameters: {
             query?: never;
@@ -2077,6 +2093,16 @@ export interface components {
             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[];
+            /** @description This issue's position in the delivery flow, computed server-side from the tracker's configured workflow rules (see GET|PUT /v1/projects/{source}/{projectKey}/workflow-rules) so clients stop each recomputing it. Closure is the first stage of the cascade and fires independently of any configuration — a closed issue always returns `origin: 'closed'`, even with zero rules configured for its tracker. Absent any OTHER matching configuration, `origin` falls back to `signals` rather than erroring. */
+            workflow: {
+                state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                /** @description The label (as matched) or native status string that produced `state`, when `origin` is `label` or `status`. `null` when `origin` is `closed` or `signals`. */
+                stage: string | null;
+                /** @description Which stage of the cascade decided `state`: the issue being closed, a matched native-status rule, a matched label rule, or the signals fallback read off linked PR/MR activity. `status` is configured but not yet ingested — reading GitLab's native work-item status and a named field on a GitHub Project v2 are both deferred for want of live credentials, so `_gc.nativeStatus` has no writer today and `origin` cannot currently come back as `status`; a declared `statusSource` is forward-looking configuration for when that ingestion lands. */
+                origin: "closed" | "status" | "label" | "signals";
+                /** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin, not just `status`/`signals`: for `origin: 'closed'` it is the payload's `closed_at`, which can be absent; for `origin: 'label'` it comes from the label history (`_gc.statusHistory`), and GitHub issues carry no `_gc` at all (only `providers/gitlab.ts` writes it), so every GitHub issue resolved by a label rule returns `stateSince: null` — plus roughly 7% of GitLab issues whose activity predates history tracking. A consumer building a "depuis N jours" display should treat `null` as missing data, not as a bug. */
+                stateSince: string | null;
+            };
             iteration: {
                 id: string | number;
                 title: string;
@@ -2314,6 +2340,16 @@ export interface components {
                 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[];
+                /** @description This issue's position in the delivery flow, computed server-side from the tracker's configured workflow rules (see GET|PUT /v1/projects/{source}/{projectKey}/workflow-rules) so clients stop each recomputing it. Closure is the first stage of the cascade and fires independently of any configuration — a closed issue always returns `origin: 'closed'`, even with zero rules configured for its tracker. Absent any OTHER matching configuration, `origin` falls back to `signals` rather than erroring. */
+                workflow: {
+                    state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                    /** @description The label (as matched) or native status string that produced `state`, when `origin` is `label` or `status`. `null` when `origin` is `closed` or `signals`. */
+                    stage: string | null;
+                    /** @description Which stage of the cascade decided `state`: the issue being closed, a matched native-status rule, a matched label rule, or the signals fallback read off linked PR/MR activity. `status` is configured but not yet ingested — reading GitLab's native work-item status and a named field on a GitHub Project v2 are both deferred for want of live credentials, so `_gc.nativeStatus` has no writer today and `origin` cannot currently come back as `status`; a declared `statusSource` is forward-looking configuration for when that ingestion lands. */
+                    origin: "closed" | "status" | "label" | "signals";
+                    /** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin, not just `status`/`signals`: for `origin: 'closed'` it is the payload's `closed_at`, which can be absent; for `origin: 'label'` it comes from the label history (`_gc.statusHistory`), and GitHub issues carry no `_gc` at all (only `providers/gitlab.ts` writes it), so every GitHub issue resolved by a label rule returns `stateSince: null` — plus roughly 7% of GitLab issues whose activity predates history tracking. A consumer building a "depuis N jours" display should treat `null` as missing data, not as a bug. */
+                    stateSince: string | null;
+                };
                 iteration: {
                     id: string | number;
                     title: string;
@@ -2494,6 +2530,76 @@ export interface components {
             limit: string | number;
             offset?: string | number;
         };
+        WorkflowLabelRule: {
+            /** @description Label prefix, matched case-insensitively against the part of the label name before any parenthesis (so a WIP limit like `=::Doing (3)` still matches `=::Doing`). */
+            prefix: string;
+            state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+        };
+        WorkflowRulesPut: {
+            labelRules: {
+                /** @description Label prefix, matched case-insensitively against the part of the label name before any parenthesis (so a WIP limit like `=::Doing (3)` still matches `=::Doing`). */
+                prefix: string;
+                state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+            }[];
+            /** @description Where ingestion WOULD read the issue's native status from — GitLab's own status field, or a named field on a numbered GitHub Project. `null` means no native status is read and the calculation falls through to labels/signals. Configured but not yet ingested: reading GitLab's native work-item status and a named GitHub Project v2 field are both deferred (no live credentials yet), so `_gc.nativeStatus` has no writer today regardless of what is declared here — a non-null `statusSource` is forward-looking configuration for when that ingestion lands, not a live data path. This is NOT read by the calculation itself (`WorkflowRules` in `workflow/computeState.ts` carries no `statusSource`): it is an ingestion concern, stored here only because the config screen edits both together. */
+            statusSource: {
+                /** @constant */
+                kind: "gitlab-native";
+            } | {
+                /** @constant */
+                kind: "github-project";
+                projectNumber: string | number;
+                fieldName: string;
+            } | null;
+            statusRules: {
+                /** @description Matched EXACTLY against the tracker-native status resolved via `statusSource` — no prefix matching, because a structured field carries no WIP-limit suffix to strip. */
+                value: string;
+                state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+            }[];
+            flowFamilies: string[];
+        };
+        WorkflowRulesRow: {
+            source: "github" | "gitlab";
+            projectKey: string;
+            labelRules: {
+                /** @description Label prefix, matched case-insensitively against the part of the label name before any parenthesis (so a WIP limit like `=::Doing (3)` still matches `=::Doing`). */
+                prefix: string;
+                state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+            }[];
+            /** @description Where ingestion WOULD read the issue's native status from — GitLab's own status field, or a named field on a numbered GitHub Project. `null` means no native status is read and the calculation falls through to labels/signals. Configured but not yet ingested: reading GitLab's native work-item status and a named GitHub Project v2 field are both deferred (no live credentials yet), so `_gc.nativeStatus` has no writer today regardless of what is declared here — a non-null `statusSource` is forward-looking configuration for when that ingestion lands, not a live data path. This is NOT read by the calculation itself (`WorkflowRules` in `workflow/computeState.ts` carries no `statusSource`): it is an ingestion concern, stored here only because the config screen edits both together. */
+            statusSource: {
+                /** @constant */
+                kind: "gitlab-native";
+            } | {
+                /** @constant */
+                kind: "github-project";
+                projectNumber: string | number;
+                fieldName: string;
+            } | null;
+            statusRules: {
+                /** @description Matched EXACTLY against the tracker-native status resolved via `statusSource` — no prefix matching, because a structured field carries no WIP-limit suffix to strip. */
+                value: string;
+                state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+            }[];
+            /** @description Label prefixes considered part of the workflow's flow, e.g. a whole column family like `=::`. Without this declaration, a label that is simply not part of the flow (unrelated to workflow state) cannot be told apart from a flow label whose column was renamed and is no longer covered by any `labelRules` — both would just be silently ignored. Declaring the family lets the calculation tell the two apart internally, but that distinction is NOT exposed on any `/v1` response (no `unmatchedFlowLabels` field exists in this API) — it is config-screen information only, surfaced live on the per-tracker workflow-rules editor (`WorkflowRulesCard`) as the list of flow labels no rule currently covers. */
+            flowFamilies: string[];
+        };
+        WorkflowState: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+        WorkflowStatusRule: {
+            /** @description Matched EXACTLY against the tracker-native status resolved via `statusSource` — no prefix matching, because a structured field carries no WIP-limit suffix to strip. */
+            value: string;
+            state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+        };
+        /** @description Where ingestion WOULD read the issue's native status from — GitLab's own status field, or a named field on a numbered GitHub Project. `null` means no native status is read and the calculation falls through to labels/signals. Configured but not yet ingested: reading GitLab's native work-item status and a named GitHub Project v2 field are both deferred (no live credentials yet), so `_gc.nativeStatus` has no writer today regardless of what is declared here — a non-null `statusSource` is forward-looking configuration for when that ingestion lands, not a live data path. This is NOT read by the calculation itself (`WorkflowRules` in `workflow/computeState.ts` carries no `statusSource`): it is an ingestion concern, stored here only because the config screen edits both together. */
+        WorkflowStatusSource: {
+            /** @constant */
+            kind: "gitlab-native";
+        } | {
+            /** @constant */
+            kind: "github-project";
+            projectNumber: string | number;
+            fieldName: string;
+        } | null;
     };
     responses: never;
     parameters: never;
@@ -2509,6 +2615,8 @@ export interface operations {
                 /** @description Filter by iteration. Values: 'current' (the GitLab native iteration in state="current", typically a 2-week sprint — NOT a calendar month), 'none' (work items without any iteration), or a numeric iteration id. For calendar-based filtering (monthly CRA, etc.), use updatedSince + updatedBefore. */
                 iteration?: string;
                 state?: string;
+                /** @description Filters issues by their COMPUTED workflow state (WorkItem.workflow.state: 'todo'|'doing'|'review'|'delivered'|'blocked'|'done') — a different axis from `state` above (issue lifecycle), never folded into it, and the two compose freely (e.g. state=open&workflowState=blocked asks for open issues currently blocked). `workflow.state` is computed by `composeWorkItem` AFTER composition (labels, statusHistory and linked PR/MR signals all feed it), so this switches the request to the EXHAUSTIVE evaluation path (like ?application=) and `total` describes the truly filtered set, never a pre-filter SQL COUNT(*) — the defect #72 shipped on /v1/deliverables. `state` keeps its own default ('open') with no implicit change: `?workflowState=done` alone answers 'open issues whose computed workflow state is done' (work finished on the board but never closed) — pass state=all explicitly to include closed issues too. */
+                workflowState?: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
                 source?: string;
                 projectKey?: string;
                 assignee?: string;
@@ -2606,6 +2714,16 @@ export interface operations {
                             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[];
+                            /** @description This issue's position in the delivery flow, computed server-side from the tracker's configured workflow rules (see GET|PUT /v1/projects/{source}/{projectKey}/workflow-rules) so clients stop each recomputing it. Closure is the first stage of the cascade and fires independently of any configuration — a closed issue always returns `origin: 'closed'`, even with zero rules configured for its tracker. Absent any OTHER matching configuration, `origin` falls back to `signals` rather than erroring. */
+                            workflow: {
+                                state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                                /** @description The label (as matched) or native status string that produced `state`, when `origin` is `label` or `status`. `null` when `origin` is `closed` or `signals`. */
+                                stage: string | null;
+                                /** @description Which stage of the cascade decided `state`: the issue being closed, a matched native-status rule, a matched label rule, or the signals fallback read off linked PR/MR activity. `status` is configured but not yet ingested — reading GitLab's native work-item status and a named field on a GitHub Project v2 are both deferred for want of live credentials, so `_gc.nativeStatus` has no writer today and `origin` cannot currently come back as `status`; a declared `statusSource` is forward-looking configuration for when that ingestion lands. */
+                                origin: "closed" | "status" | "label" | "signals";
+                                /** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin, not just `status`/`signals`: for `origin: 'closed'` it is the payload's `closed_at`, which can be absent; for `origin: 'label'` it comes from the label history (`_gc.statusHistory`), and GitHub issues carry no `_gc` at all (only `providers/gitlab.ts` writes it), so every GitHub issue resolved by a label rule returns `stateSince: null` — plus roughly 7% of GitLab issues whose activity predates history tracking. A consumer building a "depuis N jours" display should treat `null` as missing data, not as a bug. */
+                                stateSince: string | null;
+                            };
                             iteration: {
                                 id: string | number;
                                 title: string;
@@ -2847,6 +2965,16 @@ export interface operations {
                             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[];
+                            /** @description This issue's position in the delivery flow, computed server-side from the tracker's configured workflow rules (see GET|PUT /v1/projects/{source}/{projectKey}/workflow-rules) so clients stop each recomputing it. Closure is the first stage of the cascade and fires independently of any configuration — a closed issue always returns `origin: 'closed'`, even with zero rules configured for its tracker. Absent any OTHER matching configuration, `origin` falls back to `signals` rather than erroring. */
+                            workflow: {
+                                state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                                /** @description The label (as matched) or native status string that produced `state`, when `origin` is `label` or `status`. `null` when `origin` is `closed` or `signals`. */
+                                stage: string | null;
+                                /** @description Which stage of the cascade decided `state`: the issue being closed, a matched native-status rule, a matched label rule, or the signals fallback read off linked PR/MR activity. `status` is configured but not yet ingested — reading GitLab's native work-item status and a named field on a GitHub Project v2 are both deferred for want of live credentials, so `_gc.nativeStatus` has no writer today and `origin` cannot currently come back as `status`; a declared `statusSource` is forward-looking configuration for when that ingestion lands. */
+                                origin: "closed" | "status" | "label" | "signals";
+                                /** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin, not just `status`/`signals`: for `origin: 'closed'` it is the payload's `closed_at`, which can be absent; for `origin: 'label'` it comes from the label history (`_gc.statusHistory`), and GitHub issues carry no `_gc` at all (only `providers/gitlab.ts` writes it), so every GitHub issue resolved by a label rule returns `stateSince: null` — plus roughly 7% of GitLab issues whose activity predates history tracking. A consumer building a "depuis N jours" display should treat `null` as missing data, not as a bug. */
+                                stateSince: string | null;
+                            };
                             iteration: {
                                 id: string | number;
                                 title: string;
@@ -3088,6 +3216,16 @@ export interface operations {
                             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[];
+                            /** @description This issue's position in the delivery flow, computed server-side from the tracker's configured workflow rules (see GET|PUT /v1/projects/{source}/{projectKey}/workflow-rules) so clients stop each recomputing it. Closure is the first stage of the cascade and fires independently of any configuration — a closed issue always returns `origin: 'closed'`, even with zero rules configured for its tracker. Absent any OTHER matching configuration, `origin` falls back to `signals` rather than erroring. */
+                            workflow: {
+                                state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                                /** @description The label (as matched) or native status string that produced `state`, when `origin` is `label` or `status`. `null` when `origin` is `closed` or `signals`. */
+                                stage: string | null;
+                                /** @description Which stage of the cascade decided `state`: the issue being closed, a matched native-status rule, a matched label rule, or the signals fallback read off linked PR/MR activity. `status` is configured but not yet ingested — reading GitLab's native work-item status and a named field on a GitHub Project v2 are both deferred for want of live credentials, so `_gc.nativeStatus` has no writer today and `origin` cannot currently come back as `status`; a declared `statusSource` is forward-looking configuration for when that ingestion lands. */
+                                origin: "closed" | "status" | "label" | "signals";
+                                /** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin, not just `status`/`signals`: for `origin: 'closed'` it is the payload's `closed_at`, which can be absent; for `origin: 'label'` it comes from the label history (`_gc.statusHistory`), and GitHub issues carry no `_gc` at all (only `providers/gitlab.ts` writes it), so every GitHub issue resolved by a label rule returns `stateSince: null` — plus roughly 7% of GitLab issues whose activity predates history tracking. A consumer building a "depuis N jours" display should treat `null` as missing data, not as a bug. */
+                                stateSince: string | null;
+                            };
                             iteration: {
                                 id: string | number;
                                 title: string;
@@ -3385,6 +3523,16 @@ export interface operations {
                         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[];
+                        /** @description This issue's position in the delivery flow, computed server-side from the tracker's configured workflow rules (see GET|PUT /v1/projects/{source}/{projectKey}/workflow-rules) so clients stop each recomputing it. Closure is the first stage of the cascade and fires independently of any configuration — a closed issue always returns `origin: 'closed'`, even with zero rules configured for its tracker. Absent any OTHER matching configuration, `origin` falls back to `signals` rather than erroring. */
+                        workflow: {
+                            state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                            /** @description The label (as matched) or native status string that produced `state`, when `origin` is `label` or `status`. `null` when `origin` is `closed` or `signals`. */
+                            stage: string | null;
+                            /** @description Which stage of the cascade decided `state`: the issue being closed, a matched native-status rule, a matched label rule, or the signals fallback read off linked PR/MR activity. `status` is configured but not yet ingested — reading GitLab's native work-item status and a named field on a GitHub Project v2 are both deferred for want of live credentials, so `_gc.nativeStatus` has no writer today and `origin` cannot currently come back as `status`; a declared `statusSource` is forward-looking configuration for when that ingestion lands. */
+                            origin: "closed" | "status" | "label" | "signals";
+                            /** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin, not just `status`/`signals`: for `origin: 'closed'` it is the payload's `closed_at`, which can be absent; for `origin: 'label'` it comes from the label history (`_gc.statusHistory`), and GitHub issues carry no `_gc` at all (only `providers/gitlab.ts` writes it), so every GitHub issue resolved by a label rule returns `stateSince: null` — plus roughly 7% of GitLab issues whose activity predates history tracking. A consumer building a "depuis N jours" display should treat `null` as missing data, not as a bug. */
+                            stateSince: string | null;
+                        };
                         iteration: {
                             id: string | number;
                             title: string;
@@ -3621,6 +3769,16 @@ export interface operations {
                         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[];
+                        /** @description This issue's position in the delivery flow, computed server-side from the tracker's configured workflow rules (see GET|PUT /v1/projects/{source}/{projectKey}/workflow-rules) so clients stop each recomputing it. Closure is the first stage of the cascade and fires independently of any configuration — a closed issue always returns `origin: 'closed'`, even with zero rules configured for its tracker. Absent any OTHER matching configuration, `origin` falls back to `signals` rather than erroring. */
+                        workflow: {
+                            state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                            /** @description The label (as matched) or native status string that produced `state`, when `origin` is `label` or `status`. `null` when `origin` is `closed` or `signals`. */
+                            stage: string | null;
+                            /** @description Which stage of the cascade decided `state`: the issue being closed, a matched native-status rule, a matched label rule, or the signals fallback read off linked PR/MR activity. `status` is configured but not yet ingested — reading GitLab's native work-item status and a named field on a GitHub Project v2 are both deferred for want of live credentials, so `_gc.nativeStatus` has no writer today and `origin` cannot currently come back as `status`; a declared `statusSource` is forward-looking configuration for when that ingestion lands. */
+                            origin: "closed" | "status" | "label" | "signals";
+                            /** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin, not just `status`/`signals`: for `origin: 'closed'` it is the payload's `closed_at`, which can be absent; for `origin: 'label'` it comes from the label history (`_gc.statusHistory`), and GitHub issues carry no `_gc` at all (only `providers/gitlab.ts` writes it), so every GitHub issue resolved by a label rule returns `stateSince: null` — plus roughly 7% of GitLab issues whose activity predates history tracking. A consumer building a "depuis N jours" display should treat `null` as missing data, not as a bug. */
+                            stateSince: string | null;
+                        };
                         iteration: {
                             id: string | number;
                             title: string;
@@ -3857,6 +4015,16 @@ export interface operations {
                         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[];
+                        /** @description This issue's position in the delivery flow, computed server-side from the tracker's configured workflow rules (see GET|PUT /v1/projects/{source}/{projectKey}/workflow-rules) so clients stop each recomputing it. Closure is the first stage of the cascade and fires independently of any configuration — a closed issue always returns `origin: 'closed'`, even with zero rules configured for its tracker. Absent any OTHER matching configuration, `origin` falls back to `signals` rather than erroring. */
+                        workflow: {
+                            state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                            /** @description The label (as matched) or native status string that produced `state`, when `origin` is `label` or `status`. `null` when `origin` is `closed` or `signals`. */
+                            stage: string | null;
+                            /** @description Which stage of the cascade decided `state`: the issue being closed, a matched native-status rule, a matched label rule, or the signals fallback read off linked PR/MR activity. `status` is configured but not yet ingested — reading GitLab's native work-item status and a named field on a GitHub Project v2 are both deferred for want of live credentials, so `_gc.nativeStatus` has no writer today and `origin` cannot currently come back as `status`; a declared `statusSource` is forward-looking configuration for when that ingestion lands. */
+                            origin: "closed" | "status" | "label" | "signals";
+                            /** @description When the current state began. `null` means the underlying source said nothing — never a default — and this can happen on EVERY origin, not just `status`/`signals`: for `origin: 'closed'` it is the payload's `closed_at`, which can be absent; for `origin: 'label'` it comes from the label history (`_gc.statusHistory`), and GitHub issues carry no `_gc` at all (only `providers/gitlab.ts` writes it), so every GitHub issue resolved by a label rule returns `stateSince: null` — plus roughly 7% of GitLab issues whose activity predates history tracking. A consumer building a "depuis N jours" display should treat `null` as missing data, not as a bug. */
+                            stateSince: string | null;
+                        };
                         iteration: {
                             id: string | number;
                             title: string;
@@ -6468,6 +6636,292 @@ export interface operations {
             };
         };
     };
+    "getV1ProjectsBySourceByProjectKeyWorkflow-rules": {
+        parameters: {
+            query?: never;
+            header?: never;
+            path: {
+                source: string;
+                projectKey: string;
+            };
+            cookie?: never;
+        };
+        requestBody?: never;
+        responses: {
+            200: {
+                headers: {
+                    [name: string]: unknown;
+                };
+                content: {
+                    "application/json": {
+                        source: "github" | "gitlab";
+                        projectKey: string;
+                        labelRules: {
+                            /** @description Label prefix, matched case-insensitively against the part of the label name before any parenthesis (so a WIP limit like `=::Doing (3)` still matches `=::Doing`). */
+                            prefix: string;
+                            state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                        }[];
+                        /** @description Where ingestion WOULD read the issue's native status from — GitLab's own status field, or a named field on a numbered GitHub Project. `null` means no native status is read and the calculation falls through to labels/signals. Configured but not yet ingested: reading GitLab's native work-item status and a named GitHub Project v2 field are both deferred (no live credentials yet), so `_gc.nativeStatus` has no writer today regardless of what is declared here — a non-null `statusSource` is forward-looking configuration for when that ingestion lands, not a live data path. This is NOT read by the calculation itself (`WorkflowRules` in `workflow/computeState.ts` carries no `statusSource`): it is an ingestion concern, stored here only because the config screen edits both together. */
+                        statusSource: {
+                            /** @constant */
+                            kind: "gitlab-native";
+                        } | {
+                            /** @constant */
+                            kind: "github-project";
+                            projectNumber: string | number;
+                            fieldName: string;
+                        } | null;
+                        statusRules: {
+                            /** @description Matched EXACTLY against the tracker-native status resolved via `statusSource` — no prefix matching, because a structured field carries no WIP-limit suffix to strip. */
+                            value: string;
+                            state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                        }[];
+                        /** @description Label prefixes considered part of the workflow's flow, e.g. a whole column family like `=::`. Without this declaration, a label that is simply not part of the flow (unrelated to workflow state) cannot be told apart from a flow label whose column was renamed and is no longer covered by any `labelRules` — both would just be silently ignored. Declaring the family lets the calculation tell the two apart internally, but that distinction is NOT exposed on any `/v1` response (no `unmatchedFlowLabels` field exists in this API) — it is config-screen information only, surfaced live on the per-tracker workflow-rules editor (`WorkflowRulesCard`) as the list of flow labels no rule currently covers. */
+                        flowFamilies: string[];
+                    };
+                    "multipart/form-data": {
+                        source: "github" | "gitlab";
+                        projectKey: string;
+                        labelRules: {
+                            /** @description Label prefix, matched case-insensitively against the part of the label name before any parenthesis (so a WIP limit like `=::Doing (3)` still matches `=::Doing`). */
+                            prefix: string;
+                            state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                        }[];
+                        /** @description Where ingestion WOULD read the issue's native status from — GitLab's own status field, or a named field on a numbered GitHub Project. `null` means no native status is read and the calculation falls through to labels/signals. Configured but not yet ingested: reading GitLab's native work-item status and a named GitHub Project v2 field are both deferred (no live credentials yet), so `_gc.nativeStatus` has no writer today regardless of what is declared here — a non-null `statusSource` is forward-looking configuration for when that ingestion lands, not a live data path. This is NOT read by the calculation itself (`WorkflowRules` in `workflow/computeState.ts` carries no `statusSource`): it is an ingestion concern, stored here only because the config screen edits both together. */
+                        statusSource: {
+                            /** @constant */
+                            kind: "gitlab-native";
+                        } | {
+                            /** @constant */
+                            kind: "github-project";
+                            projectNumber: string | number;
+                            fieldName: string;
+                        } | null;
+                        statusRules: {
+                            /** @description Matched EXACTLY against the tracker-native status resolved via `statusSource` — no prefix matching, because a structured field carries no WIP-limit suffix to strip. */
+                            value: string;
+                            state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                        }[];
+                        /** @description Label prefixes considered part of the workflow's flow, e.g. a whole column family like `=::`. Without this declaration, a label that is simply not part of the flow (unrelated to workflow state) cannot be told apart from a flow label whose column was renamed and is no longer covered by any `labelRules` — both would just be silently ignored. Declaring the family lets the calculation tell the two apart internally, but that distinction is NOT exposed on any `/v1` response (no `unmatchedFlowLabels` field exists in this API) — it is config-screen information only, surfaced live on the per-tracker workflow-rules editor (`WorkflowRulesCard`) as the list of flow labels no rule currently covers. */
+                        flowFamilies: string[];
+                    };
+                    "text/plain": {
+                        source: "github" | "gitlab";
+                        projectKey: string;
+                        labelRules: {
+                            /** @description Label prefix, matched case-insensitively against the part of the label name before any parenthesis (so a WIP limit like `=::Doing (3)` still matches `=::Doing`). */
+                            prefix: string;
+                            state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                        }[];
+                        /** @description Where ingestion WOULD read the issue's native status from — GitLab's own status field, or a named field on a numbered GitHub Project. `null` means no native status is read and the calculation falls through to labels/signals. Configured but not yet ingested: reading GitLab's native work-item status and a named GitHub Project v2 field are both deferred (no live credentials yet), so `_gc.nativeStatus` has no writer today regardless of what is declared here — a non-null `statusSource` is forward-looking configuration for when that ingestion lands, not a live data path. This is NOT read by the calculation itself (`WorkflowRules` in `workflow/computeState.ts` carries no `statusSource`): it is an ingestion concern, stored here only because the config screen edits both together. */
+                        statusSource: {
+                            /** @constant */
+                            kind: "gitlab-native";
+                        } | {
+                            /** @constant */
+                            kind: "github-project";
+                            projectNumber: string | number;
+                            fieldName: string;
+                        } | null;
+                        statusRules: {
+                            /** @description Matched EXACTLY against the tracker-native status resolved via `statusSource` — no prefix matching, because a structured field carries no WIP-limit suffix to strip. */
+                            value: string;
+                            state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                        }[];
+                        /** @description Label prefixes considered part of the workflow's flow, e.g. a whole column family like `=::`. Without this declaration, a label that is simply not part of the flow (unrelated to workflow state) cannot be told apart from a flow label whose column was renamed and is no longer covered by any `labelRules` — both would just be silently ignored. Declaring the family lets the calculation tell the two apart internally, but that distinction is NOT exposed on any `/v1` response (no `unmatchedFlowLabels` field exists in this API) — it is config-screen information only, surfaced live on the per-tracker workflow-rules editor (`WorkflowRulesCard`) as the list of flow labels no rule currently covers. */
+                        flowFamilies: string[];
+                    };
+                };
+            };
+        };
+    };
+    "putV1ProjectsBySourceByProjectKeyWorkflow-rules": {
+        parameters: {
+            query?: never;
+            header?: never;
+            path: {
+                source: string;
+                projectKey: string;
+            };
+            cookie?: never;
+        };
+        requestBody: {
+            content: {
+                "application/json": {
+                    labelRules: {
+                        /** @description Label prefix, matched case-insensitively against the part of the label name before any parenthesis (so a WIP limit like `=::Doing (3)` still matches `=::Doing`). */
+                        prefix: string;
+                        state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                    }[];
+                    /** @description Where ingestion WOULD read the issue's native status from — GitLab's own status field, or a named field on a numbered GitHub Project. `null` means no native status is read and the calculation falls through to labels/signals. Configured but not yet ingested: reading GitLab's native work-item status and a named GitHub Project v2 field are both deferred (no live credentials yet), so `_gc.nativeStatus` has no writer today regardless of what is declared here — a non-null `statusSource` is forward-looking configuration for when that ingestion lands, not a live data path. This is NOT read by the calculation itself (`WorkflowRules` in `workflow/computeState.ts` carries no `statusSource`): it is an ingestion concern, stored here only because the config screen edits both together. */
+                    statusSource: {
+                        /** @constant */
+                        kind: "gitlab-native";
+                    } | {
+                        /** @constant */
+                        kind: "github-project";
+                        projectNumber: string | number;
+                        fieldName: string;
+                    } | null;
+                    statusRules: {
+                        /** @description Matched EXACTLY against the tracker-native status resolved via `statusSource` — no prefix matching, because a structured field carries no WIP-limit suffix to strip. */
+                        value: string;
+                        state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                    }[];
+                    flowFamilies: string[];
+                };
+                "multipart/form-data": {
+                    labelRules: {
+                        /** @description Label prefix, matched case-insensitively against the part of the label name before any parenthesis (so a WIP limit like `=::Doing (3)` still matches `=::Doing`). */
+                        prefix: string;
+                        state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                    }[];
+                    /** @description Where ingestion WOULD read the issue's native status from — GitLab's own status field, or a named field on a numbered GitHub Project. `null` means no native status is read and the calculation falls through to labels/signals. Configured but not yet ingested: reading GitLab's native work-item status and a named GitHub Project v2 field are both deferred (no live credentials yet), so `_gc.nativeStatus` has no writer today regardless of what is declared here — a non-null `statusSource` is forward-looking configuration for when that ingestion lands, not a live data path. This is NOT read by the calculation itself (`WorkflowRules` in `workflow/computeState.ts` carries no `statusSource`): it is an ingestion concern, stored here only because the config screen edits both together. */
+                    statusSource: {
+                        /** @constant */
+                        kind: "gitlab-native";
+                    } | {
+                        /** @constant */
+                        kind: "github-project";
+                        projectNumber: string | number;
+                        fieldName: string;
+                    } | null;
+                    statusRules: {
+                        /** @description Matched EXACTLY against the tracker-native status resolved via `statusSource` — no prefix matching, because a structured field carries no WIP-limit suffix to strip. */
+                        value: string;
+                        state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                    }[];
+                    flowFamilies: string[];
+                };
+                "text/plain": {
+                    labelRules: {
+                        /** @description Label prefix, matched case-insensitively against the part of the label name before any parenthesis (so a WIP limit like `=::Doing (3)` still matches `=::Doing`). */
+                        prefix: string;
+                        state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                    }[];
+                    /** @description Where ingestion WOULD read the issue's native status from — GitLab's own status field, or a named field on a numbered GitHub Project. `null` means no native status is read and the calculation falls through to labels/signals. Configured but not yet ingested: reading GitLab's native work-item status and a named GitHub Project v2 field are both deferred (no live credentials yet), so `_gc.nativeStatus` has no writer today regardless of what is declared here — a non-null `statusSource` is forward-looking configuration for when that ingestion lands, not a live data path. This is NOT read by the calculation itself (`WorkflowRules` in `workflow/computeState.ts` carries no `statusSource`): it is an ingestion concern, stored here only because the config screen edits both together. */
+                    statusSource: {
+                        /** @constant */
+                        kind: "gitlab-native";
+                    } | {
+                        /** @constant */
+                        kind: "github-project";
+                        projectNumber: string | number;
+                        fieldName: string;
+                    } | null;
+                    statusRules: {
+                        /** @description Matched EXACTLY against the tracker-native status resolved via `statusSource` — no prefix matching, because a structured field carries no WIP-limit suffix to strip. */
+                        value: string;
+                        state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                    }[];
+                    flowFamilies: string[];
+                };
+            };
+        };
+        responses: {
+            200: {
+                headers: {
+                    [name: string]: unknown;
+                };
+                content: {
+                    "application/json": {
+                        source: "github" | "gitlab";
+                        projectKey: string;
+                        labelRules: {
+                            /** @description Label prefix, matched case-insensitively against the part of the label name before any parenthesis (so a WIP limit like `=::Doing (3)` still matches `=::Doing`). */
+                            prefix: string;
+                            state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                        }[];
+                        /** @description Where ingestion WOULD read the issue's native status from — GitLab's own status field, or a named field on a numbered GitHub Project. `null` means no native status is read and the calculation falls through to labels/signals. Configured but not yet ingested: reading GitLab's native work-item status and a named GitHub Project v2 field are both deferred (no live credentials yet), so `_gc.nativeStatus` has no writer today regardless of what is declared here — a non-null `statusSource` is forward-looking configuration for when that ingestion lands, not a live data path. This is NOT read by the calculation itself (`WorkflowRules` in `workflow/computeState.ts` carries no `statusSource`): it is an ingestion concern, stored here only because the config screen edits both together. */
+                        statusSource: {
+                            /** @constant */
+                            kind: "gitlab-native";
+                        } | {
+                            /** @constant */
+                            kind: "github-project";
+                            projectNumber: string | number;
+                            fieldName: string;
+                        } | null;
+                        statusRules: {
+                            /** @description Matched EXACTLY against the tracker-native status resolved via `statusSource` — no prefix matching, because a structured field carries no WIP-limit suffix to strip. */
+                            value: string;
+                            state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                        }[];
+                        /** @description Label prefixes considered part of the workflow's flow, e.g. a whole column family like `=::`. Without this declaration, a label that is simply not part of the flow (unrelated to workflow state) cannot be told apart from a flow label whose column was renamed and is no longer covered by any `labelRules` — both would just be silently ignored. Declaring the family lets the calculation tell the two apart internally, but that distinction is NOT exposed on any `/v1` response (no `unmatchedFlowLabels` field exists in this API) — it is config-screen information only, surfaced live on the per-tracker workflow-rules editor (`WorkflowRulesCard`) as the list of flow labels no rule currently covers. */
+                        flowFamilies: string[];
+                    };
+                    "multipart/form-data": {
+                        source: "github" | "gitlab";
+                        projectKey: string;
+                        labelRules: {
+                            /** @description Label prefix, matched case-insensitively against the part of the label name before any parenthesis (so a WIP limit like `=::Doing (3)` still matches `=::Doing`). */
+                            prefix: string;
+                            state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                        }[];
+                        /** @description Where ingestion WOULD read the issue's native status from — GitLab's own status field, or a named field on a numbered GitHub Project. `null` means no native status is read and the calculation falls through to labels/signals. Configured but not yet ingested: reading GitLab's native work-item status and a named GitHub Project v2 field are both deferred (no live credentials yet), so `_gc.nativeStatus` has no writer today regardless of what is declared here — a non-null `statusSource` is forward-looking configuration for when that ingestion lands, not a live data path. This is NOT read by the calculation itself (`WorkflowRules` in `workflow/computeState.ts` carries no `statusSource`): it is an ingestion concern, stored here only because the config screen edits both together. */
+                        statusSource: {
+                            /** @constant */
+                            kind: "gitlab-native";
+                        } | {
+                            /** @constant */
+                            kind: "github-project";
+                            projectNumber: string | number;
+                            fieldName: string;
+                        } | null;
+                        statusRules: {
+                            /** @description Matched EXACTLY against the tracker-native status resolved via `statusSource` — no prefix matching, because a structured field carries no WIP-limit suffix to strip. */
+                            value: string;
+                            state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                        }[];
+                        /** @description Label prefixes considered part of the workflow's flow, e.g. a whole column family like `=::`. Without this declaration, a label that is simply not part of the flow (unrelated to workflow state) cannot be told apart from a flow label whose column was renamed and is no longer covered by any `labelRules` — both would just be silently ignored. Declaring the family lets the calculation tell the two apart internally, but that distinction is NOT exposed on any `/v1` response (no `unmatchedFlowLabels` field exists in this API) — it is config-screen information only, surfaced live on the per-tracker workflow-rules editor (`WorkflowRulesCard`) as the list of flow labels no rule currently covers. */
+                        flowFamilies: string[];
+                    };
+                    "text/plain": {
+                        source: "github" | "gitlab";
+                        projectKey: string;
+                        labelRules: {
+                            /** @description Label prefix, matched case-insensitively against the part of the label name before any parenthesis (so a WIP limit like `=::Doing (3)` still matches `=::Doing`). */
+                            prefix: string;
+                            state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                        }[];
+                        /** @description Where ingestion WOULD read the issue's native status from — GitLab's own status field, or a named field on a numbered GitHub Project. `null` means no native status is read and the calculation falls through to labels/signals. Configured but not yet ingested: reading GitLab's native work-item status and a named GitHub Project v2 field are both deferred (no live credentials yet), so `_gc.nativeStatus` has no writer today regardless of what is declared here — a non-null `statusSource` is forward-looking configuration for when that ingestion lands, not a live data path. This is NOT read by the calculation itself (`WorkflowRules` in `workflow/computeState.ts` carries no `statusSource`): it is an ingestion concern, stored here only because the config screen edits both together. */
+                        statusSource: {
+                            /** @constant */
+                            kind: "gitlab-native";
+                        } | {
+                            /** @constant */
+                            kind: "github-project";
+                            projectNumber: string | number;
+                            fieldName: string;
+                        } | null;
+                        statusRules: {
+                            /** @description Matched EXACTLY against the tracker-native status resolved via `statusSource` — no prefix matching, because a structured field carries no WIP-limit suffix to strip. */
+                            value: string;
+                            state: "todo" | "doing" | "review" | "delivered" | "blocked" | "done";
+                        }[];
+                        /** @description Label prefixes considered part of the workflow's flow, e.g. a whole column family like `=::`. Without this declaration, a label that is simply not part of the flow (unrelated to workflow state) cannot be told apart from a flow label whose column was renamed and is no longer covered by any `labelRules` — both would just be silently ignored. Declaring the family lets the calculation tell the two apart internally, but that distinction is NOT exposed on any `/v1` response (no `unmatchedFlowLabels` field exists in this API) — it is config-screen information only, surfaced live on the per-tracker workflow-rules editor (`WorkflowRulesCard`) as the list of flow labels no rule currently covers. */
+                        flowFamilies: string[];
+                    };
+                };
+            };
+            400: {
+                headers: {
+                    [name: string]: unknown;
+                };
+                content: {
+                    "application/json": {
+                        error: string;
+                    };
+                    "multipart/form-data": {
+                        error: string;
+                    };
+                    "text/plain": {
+                        error: string;
+                    };
+                };
+            };
+        };
+    };
     getV1Projects: {
         parameters: {
             query?: never;

package/package.json

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