@shipeasy/openapi 3.0.0 → 3.1.0

package/dist/schemas.d.ts

@@ -2754,13 +2754,11 @@ declare const zApproveEventResponse: z.ZodObject<{
     id: z.ZodString;
 }, z.core.$strip>;
 /**
- * Lifecycle status of a queue item. The working flow is `open` → `triaged` → `in_progress` → `ready_for_qa` → `resolved` (or `wont_fix`, terminal from any earlier stage). `blocked` marks an item that can't progress until an external dependency clears — a working state a human sets and clears. `ready_for_qa` is what a developer sets once a fix lands; `resolved` is the QA sign-off, normally flipped in the dashboard after verification — set it directly from code only when the fix has been verified end-to-end. `investigating_by_ai` is a system-owned display state — set when the AI agent (Jarvis) picks an item up to investigate, never chosen by a human — so it is shown but not offered as a manual choice. Two human-gated holding states park an item OUT of the work queue until a human promotes it to `open` in the dashboard, so `GET /api/admin/ops` excludes them under `status=all`/default and returns them only when requested as an exact `status`: `pending_approval` is the pre-open approval gate for untriaged inbound (e.g. connector requests filed from a customer's connectors panel) so it never gets auto-implemented — approving = flipping the status to `open`; `triage` is the onboarding-help bucket — questions/errors submitted to the "Stuck in onboarding?" assistant are funnelled into the platform project as `triage` rows so the team can see where people get stuck and follow up, keeping onboarding chatter out of the work queue until a human moves real items to `open`.
+ * Lifecycle status of a queue item. The working flow is `open` → `in_progress` → `ready_for_qa` → `resolved` (or `wont_fix`, terminal from any earlier stage). `blocked` marks an item that can't progress until an external dependency clears — a working state a human sets and clears. `ready_for_qa` is what a developer sets once a fix lands; `resolved` is the QA sign-off, normally flipped in the dashboard after verification — set it directly from code only when the fix has been verified end-to-end. `investigating_by_ai` is a system-owned display state — set when the AI agent (Jarvis) picks an item up to investigate, never chosen by a human — so it is shown but not offered as a manual choice. `pending_approval` is the one human-gated holding state: it parks an item OUT of the work queue until a human promotes it to `open` in the dashboard, so `GET /api/admin/ops` excludes it under `status=all`/default and returns it only when requested as an exact `status`. It covers untriaged inbound that must never be auto-implemented — connector requests filed from a customer's connectors panel, and questions funnelled in from the "Stuck in onboarding?" assistant — where approving means flipping the status to `open`. Two earlier values were removed in favour of this single gate: `triage` (the onboarding-help bucket, now `pending_approval`) and `triaged` (a redundant "looked at but not started" step, now plain `open`).
  */
 declare const zOpsItemStatus: z.ZodEnum<{
     open: "open";
     pending_approval: "pending_approval";
-    triage: "triage";
-    triaged: "triaged";
     investigating_by_ai: "investigating_by_ai";
     in_progress: "in_progress";
     blocked: "blocked";
@@ -2778,18 +2776,17 @@ declare const zOpsItemPriority: z.ZodEnum<{
     critical: "critical";
 }>;
 /**
- * Where automation has taken an item in the investigation lifecycle — the signal the ops cockpit renders as "what AI did" plus the one action expected of the user. It is **written as a side-effect of the actions that already happen**, never authored on its own: linking a PR sets `pr_ready`, moving to `in_progress` sets `working`, `ready_for_qa` sets `ready_for_qa`, a system/assistant reply sets `question`, resolving clears it, and creation seeds `needs_triage`/`backlog` (by priority) or `investigated`/`detected` for auto-filed error/alert tickets. `triaged_low` marks a low-signal item AI has looked at but that nothing is moving. Absent on rows filed before the field existed — consumers should treat a missing value as "derive from the other fields".
+ * Where automation has taken an item in the investigation lifecycle — the signal the ops cockpit renders as "what AI did" plus the one action expected of the user. It is **written as a side-effect of the actions that already happen**, never authored on its own: linking a PR sets `pr_ready`, moving to `in_progress` sets `working`, `ready_for_qa` sets `ready_for_qa`, a system/assistant reply sets `question`, resolving clears it, and creation seeds `backlog` or `investigated`/`detected` for auto-filed error/alert tickets. `backlog` is the single "nothing has happened yet" state — how urgent that is reads off `priority`, not off a separate state, and its one action is to hand the item to an agent. `pr_merged` is derived client-side by scanning the linked pull request on GitHub, so it is accepted on write but not currently emitted by the API. Absent on rows filed before the field existed — consumers should treat a missing value as "derive from the other fields".
  */
 declare const zOpsInvestigationState: z.ZodEnum<{
     pending_approval: "pending_approval";
     ready_for_qa: "ready_for_qa";
     pr_ready: "pr_ready";
+    pr_merged: "pr_merged";
     investigated: "investigated";
     detected: "detected";
     question: "question";
-    needs_triage: "needs_triage";
     working: "working";
-    triaged_low: "triaged_low";
     backlog: "backlog";
 }>;
 /**
@@ -3213,8 +3210,6 @@ declare const zListOpsItemsResponse: z.ZodArray<z.ZodObject<{
     status: z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";
@@ -3233,12 +3228,11 @@ declare const zListOpsItemsResponse: z.ZodArray<z.ZodObject<{
         pending_approval: "pending_approval";
         ready_for_qa: "ready_for_qa";
         pr_ready: "pr_ready";
+        pr_merged: "pr_merged";
         investigated: "investigated";
         detected: "detected";
         question: "question";
-        needs_triage: "needs_triage";
         working: "working";
-        triaged_low: "triaged_low";
         backlog: "backlog";
     }>>>;
     source: z.ZodEnum<{
@@ -3470,8 +3464,6 @@ declare const zCreateBugRequest: z.ZodObject<{
     status: z.ZodOptional<z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";
@@ -3514,8 +3506,6 @@ declare const zCreateFeatureRequestRequest: z.ZodObject<{
     status: z.ZodOptional<z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";
@@ -3555,8 +3545,6 @@ declare const zCreateOpsItemRequest: z.ZodDiscriminatedUnion<[z.ZodObject<{
     status: z.ZodOptional<z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";
@@ -3593,8 +3581,6 @@ declare const zCreateOpsItemRequest: z.ZodDiscriminatedUnion<[z.ZodObject<{
     status: z.ZodOptional<z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";
@@ -3664,8 +3650,6 @@ declare const zGetOpsItemResponse: z.ZodObject<{
     status: z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";
@@ -3688,12 +3672,11 @@ declare const zGetOpsItemResponse: z.ZodObject<{
         pending_approval: "pending_approval";
         ready_for_qa: "ready_for_qa";
         pr_ready: "pr_ready";
+        pr_merged: "pr_merged";
         investigated: "investigated";
         detected: "detected";
         question: "question";
-        needs_triage: "needs_triage";
         working: "working";
-        triaged_low: "triaged_low";
         backlog: "backlog";
     }>>>;
     reporterEmail: z.ZodOptional<z.ZodNullable<z.ZodString>>;
@@ -3917,8 +3900,6 @@ declare const zUpdateBugRequest: z.ZodObject<{
     status: z.ZodOptional<z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";
@@ -3951,8 +3932,6 @@ declare const zUpdateFeatureRequestRequest: z.ZodObject<{
     status: z.ZodOptional<z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";
@@ -3982,8 +3961,6 @@ declare const zUpdateOpsItemStatusRequest: z.ZodObject<{
     status: z.ZodOptional<z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";
@@ -4016,8 +3993,6 @@ declare const zUpdateOpsItemRequest: z.ZodUnion<readonly [z.ZodObject<{
     status: z.ZodOptional<z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";
@@ -4046,8 +4021,6 @@ declare const zUpdateOpsItemRequest: z.ZodUnion<readonly [z.ZodObject<{
     status: z.ZodOptional<z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";
@@ -4073,8 +4046,6 @@ declare const zUpdateOpsItemRequest: z.ZodUnion<readonly [z.ZodObject<{
     status: z.ZodOptional<z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";
@@ -8535,8 +8506,6 @@ declare const zListOpsItemsQuery: z.ZodObject<{
     status: z.ZodOptional<z.ZodUnion<readonly [z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";
@@ -8564,8 +8533,6 @@ declare const zListOpsItemsResponse2: z.ZodArray<z.ZodObject<{
     status: z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";
@@ -8584,12 +8551,11 @@ declare const zListOpsItemsResponse2: z.ZodArray<z.ZodObject<{
         pending_approval: "pending_approval";
         ready_for_qa: "ready_for_qa";
         pr_ready: "pr_ready";
+        pr_merged: "pr_merged";
         investigated: "investigated";
         detected: "detected";
         question: "question";
-        needs_triage: "needs_triage";
         working: "working";
-        triaged_low: "triaged_low";
         backlog: "backlog";
     }>>>;
     source: z.ZodEnum<{
@@ -8815,8 +8781,6 @@ declare const zCreateOpsItemBody: z.ZodDiscriminatedUnion<[z.ZodObject<{
     status: z.ZodOptional<z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";
@@ -8853,8 +8817,6 @@ declare const zCreateOpsItemBody: z.ZodDiscriminatedUnion<[z.ZodObject<{
     status: z.ZodOptional<z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";
@@ -8923,8 +8885,6 @@ declare const zGetOpsItemResponse2: z.ZodObject<{
     status: z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";
@@ -8947,12 +8907,11 @@ declare const zGetOpsItemResponse2: z.ZodObject<{
         pending_approval: "pending_approval";
         ready_for_qa: "ready_for_qa";
         pr_ready: "pr_ready";
+        pr_merged: "pr_merged";
         investigated: "investigated";
         detected: "detected";
         question: "question";
-        needs_triage: "needs_triage";
         working: "working";
-        triaged_low: "triaged_low";
         backlog: "backlog";
     }>>>;
     reporterEmail: z.ZodOptional<z.ZodNullable<z.ZodString>>;
@@ -9148,8 +9107,6 @@ declare const zUpdateOpsItemBody: z.ZodUnion<readonly [z.ZodObject<{
     status: z.ZodOptional<z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";
@@ -9178,8 +9135,6 @@ declare const zUpdateOpsItemBody: z.ZodUnion<readonly [z.ZodObject<{
     status: z.ZodOptional<z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";
@@ -9205,8 +9160,6 @@ declare const zUpdateOpsItemBody: z.ZodUnion<readonly [z.ZodObject<{
     status: z.ZodOptional<z.ZodEnum<{
         open: "open";
         pending_approval: "pending_approval";
-        triage: "triage";
-        triaged: "triaged";
         investigating_by_ai: "investigating_by_ai";
         in_progress: "in_progress";
         blocked: "blocked";

package/dist/schemas.js

@@ -678,7 +678,7 @@ import {
   zUpsertProjectRequest,
   zUpsertProjectResponse,
   zUpsertProjectResponse2
-} from "./chunk-7T77D5YO.js";
+} from "./chunk-UV333BIK.js";
 export {
   zAckOpsItemBody,
   zAckOpsItemHeaders,

package/openapi.json

@@ -6939,7 +6939,7 @@
             "name": "status",
             "in": "query",
             "required": false,
-            "description": "Filter by lifecycle status, or `all`. The human-gated holding states (`pending_approval`, `triage`) are excluded from `all`/default and returned only when requested as the exact status.",
+            "description": "Filter by lifecycle status, or `all`. The human-gated holding state (`pending_approval`) is excluded from `all`/default and returned only when requested as the exact status.",
             "schema": {
               "anyOf": [
                 {
@@ -19272,8 +19272,6 @@
         "enum": [
           "open",
           "pending_approval",
-          "triage",
-          "triaged",
           "investigating_by_ai",
           "in_progress",
           "blocked",
@@ -19281,7 +19279,7 @@
           "resolved",
           "wont_fix"
         ],
-        "description": "Lifecycle status of a queue item. The working flow is `open` → `triaged` → `in_progress` → `ready_for_qa` → `resolved` (or `wont_fix`, terminal from any earlier stage). `blocked` marks an item that can't progress until an external dependency clears — a working state a human sets and clears. `ready_for_qa` is what a developer sets once a fix lands; `resolved` is the QA sign-off, normally flipped in the dashboard after verification — set it directly from code only when the fix has been verified end-to-end. `investigating_by_ai` is a system-owned display state — set when the AI agent (Jarvis) picks an item up to investigate, never chosen by a human — so it is shown but not offered as a manual choice. Two human-gated holding states park an item OUT of the work queue until a human promotes it to `open` in the dashboard, so `GET /api/admin/ops` excludes them under `status=all`/default and returns them only when requested as an exact `status`: `pending_approval` is the pre-open approval gate for untriaged inbound (e.g. connector requests filed from a customer's connectors panel) so it never gets auto-implemented — approving = flipping the status to `open`; `triage` is the onboarding-help bucket — questions/errors submitted to the \"Stuck in onboarding?\" assistant are funnelled into the platform project as `triage` rows so the team can see where people get stuck and follow up, keeping onboarding chatter out of the work queue until a human moves real items to `open`."
+        "description": "Lifecycle status of a queue item. The working flow is `open` → `in_progress` → `ready_for_qa` → `resolved` (or `wont_fix`, terminal from any earlier stage). `blocked` marks an item that can't progress until an external dependency clears — a working state a human sets and clears. `ready_for_qa` is what a developer sets once a fix lands; `resolved` is the QA sign-off, normally flipped in the dashboard after verification — set it directly from code only when the fix has been verified end-to-end. `investigating_by_ai` is a system-owned display state — set when the AI agent (Jarvis) picks an item up to investigate, never chosen by a human — so it is shown but not offered as a manual choice. `pending_approval` is the one human-gated holding state: it parks an item OUT of the work queue until a human promotes it to `open` in the dashboard, so `GET /api/admin/ops` excludes it under `status=all`/default and returns it only when requested as an exact `status`. It covers untriaged inbound that must never be auto-implemented — connector requests filed from a customer's connectors panel, and questions funnelled in from the \"Stuck in onboarding?\" assistant — where approving means flipping the status to `open`. Two earlier values were removed in favour of this single gate: `triage` (the onboarding-help bucket, now `pending_approval`) and `triaged` (a redundant \"looked at but not started\" step, now plain `open`)."
       },
       "OpsItemPriority": {
         "type": "string",
@@ -19297,17 +19295,16 @@
         "type": "string",
         "enum": [
           "pr_ready",
+          "pr_merged",
           "investigated",
           "detected",
           "question",
           "ready_for_qa",
           "pending_approval",
-          "needs_triage",
           "working",
-          "triaged_low",
           "backlog"
         ],
-        "description": "Where automation has taken an item in the investigation lifecycle — the signal the ops cockpit renders as \"what AI did\" plus the one action expected of the user. It is **written as a side-effect of the actions that already happen**, never authored on its own: linking a PR sets `pr_ready`, moving to `in_progress` sets `working`, `ready_for_qa` sets `ready_for_qa`, a system/assistant reply sets `question`, resolving clears it, and creation seeds `needs_triage`/`backlog` (by priority) or `investigated`/`detected` for auto-filed error/alert tickets. `triaged_low` marks a low-signal item AI has looked at but that nothing is moving. Absent on rows filed before the field existed — consumers should treat a missing value as \"derive from the other fields\"."
+        "description": "Where automation has taken an item in the investigation lifecycle — the signal the ops cockpit renders as \"what AI did\" plus the one action expected of the user. It is **written as a side-effect of the actions that already happen**, never authored on its own: linking a PR sets `pr_ready`, moving to `in_progress` sets `working`, `ready_for_qa` sets `ready_for_qa`, a system/assistant reply sets `question`, resolving clears it, and creation seeds `backlog` or `investigated`/`detected` for auto-filed error/alert tickets. `backlog` is the single \"nothing has happened yet\" state — how urgent that is reads off `priority`, not off a separate state, and its one action is to hand the item to an agent. `pr_merged` is derived client-side by scanning the linked pull request on GitHub, so it is accepted on write but not currently emitted by the API. Absent on rows filed before the field existed — consumers should treat a missing value as \"derive from the other fields\"."
       },
       "OpsBrowserContext": {
         "type": "object",

package/openapi.yaml

@@ -5078,7 +5078,7 @@ paths:
         - name: status
           in: query
           required: false
-          description: Filter by lifecycle status, or `all`. The human-gated holding states (`pending_approval`, `triage`) are excluded from `all`/default and returned only when requested as the exact status.
+          description: Filter by lifecycle status, or `all`. The human-gated holding state (`pending_approval`) is excluded from `all`/default and returned only when requested as the exact status.
           schema:
             anyOf:
               - $ref: '#/components/schemas/OpsItemStatus'
@@ -13925,15 +13925,13 @@ components:
       enum:
         - open
         - pending_approval
-        - triage
-        - triaged
         - investigating_by_ai
         - in_progress
         - blocked
         - ready_for_qa
         - resolved
         - wont_fix
-      description: 'Lifecycle status of a queue item. The working flow is `open` → `triaged` → `in_progress` → `ready_for_qa` → `resolved` (or `wont_fix`, terminal from any earlier stage). `blocked` marks an item that can''t progress until an external dependency clears — a working state a human sets and clears. `ready_for_qa` is what a developer sets once a fix lands; `resolved` is the QA sign-off, normally flipped in the dashboard after verification — set it directly from code only when the fix has been verified end-to-end. `investigating_by_ai` is a system-owned display state — set when the AI agent (Jarvis) picks an item up to investigate, never chosen by a human — so it is shown but not offered as a manual choice. Two human-gated holding states park an item OUT of the work queue until a human promotes it to `open` in the dashboard, so `GET /api/admin/ops` excludes them under `status=all`/default and returns them only when requested as an exact `status`: `pending_approval` is the pre-open approval gate for untriaged inbound (e.g. connector requests filed from a customer''s connectors panel) so it never gets auto-implemented — approving = flipping the status to `open`; `triage` is the onboarding-help bucket — questions/errors submitted to the "Stuck in onboarding?" assistant are funnelled into the platform project as `triage` rows so the team can see where people get stuck and follow up, keeping onboarding chatter out of the work queue until a human moves real items to `open`.'
+      description: 'Lifecycle status of a queue item. The working flow is `open` → `in_progress` → `ready_for_qa` → `resolved` (or `wont_fix`, terminal from any earlier stage). `blocked` marks an item that can''t progress until an external dependency clears — a working state a human sets and clears. `ready_for_qa` is what a developer sets once a fix lands; `resolved` is the QA sign-off, normally flipped in the dashboard after verification — set it directly from code only when the fix has been verified end-to-end. `investigating_by_ai` is a system-owned display state — set when the AI agent (Jarvis) picks an item up to investigate, never chosen by a human — so it is shown but not offered as a manual choice. `pending_approval` is the one human-gated holding state: it parks an item OUT of the work queue until a human promotes it to `open` in the dashboard, so `GET /api/admin/ops` excludes it under `status=all`/default and returns it only when requested as an exact `status`. It covers untriaged inbound that must never be auto-implemented — connector requests filed from a customer''s connectors panel, and questions funnelled in from the "Stuck in onboarding?" assistant — where approving means flipping the status to `open`. Two earlier values were removed in favour of this single gate: `triage` (the onboarding-help bucket, now `pending_approval`) and `triaged` (a redundant "looked at but not started" step, now plain `open`).'
     OpsItemPriority:
       type: string
       enum:
@@ -13946,16 +13944,15 @@ components:
       type: string
       enum:
         - pr_ready
+        - pr_merged
         - investigated
         - detected
         - question
         - ready_for_qa
         - pending_approval
-        - needs_triage
         - working
-        - triaged_low
         - backlog
-      description: 'Where automation has taken an item in the investigation lifecycle — the signal the ops cockpit renders as "what AI did" plus the one action expected of the user. It is **written as a side-effect of the actions that already happen**, never authored on its own: linking a PR sets `pr_ready`, moving to `in_progress` sets `working`, `ready_for_qa` sets `ready_for_qa`, a system/assistant reply sets `question`, resolving clears it, and creation seeds `needs_triage`/`backlog` (by priority) or `investigated`/`detected` for auto-filed error/alert tickets. `triaged_low` marks a low-signal item AI has looked at but that nothing is moving. Absent on rows filed before the field existed — consumers should treat a missing value as "derive from the other fields".'
+      description: 'Where automation has taken an item in the investigation lifecycle — the signal the ops cockpit renders as "what AI did" plus the one action expected of the user. It is **written as a side-effect of the actions that already happen**, never authored on its own: linking a PR sets `pr_ready`, moving to `in_progress` sets `working`, `ready_for_qa` sets `ready_for_qa`, a system/assistant reply sets `question`, resolving clears it, and creation seeds `backlog` or `investigated`/`detected` for auto-filed error/alert tickets. `backlog` is the single "nothing has happened yet" state — how urgent that is reads off `priority`, not off a separate state, and its one action is to hand the item to an agent. `pr_merged` is derived client-side by scanning the linked pull request on GitHub, so it is accepted on write but not currently emitted by the API. Absent on rows filed before the field existed — consumers should treat a missing value as "derive from the other fields".'
     OpsBrowserContext:
       type: object
       properties:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shipeasy/openapi",
-  "version": "3.0.0",
+  "version": "3.1.0",
   "description": "Shipeasy admin OpenAPI 3.2 spec (hand-authored, single source of truth) + the generated TypeScript client, Zod schemas, and types. Consumed by @shipeasy/cli and @shipeasy/mcp.",
   "type": "module",
   "main": "./dist/index.js",

package/spec/components/schemas/ops.yaml

@@ -1093,8 +1093,6 @@ OpsItemStatus:
   enum:
     - open
     - pending_approval
-    - triage
-    - triaged
     - investigating_by_ai
     - in_progress
     - blocked
@@ -1102,7 +1100,7 @@ OpsItemStatus:
     - resolved
     - wont_fix
   description: >-
-    Lifecycle status of a queue item. The working flow is `open` → `triaged` →
+    Lifecycle status of a queue item. The working flow is `open` →
     `in_progress` → `ready_for_qa` → `resolved` (or `wont_fix`, terminal from
     any earlier stage). `blocked` marks an item that can't progress until an
     external dependency clears — a working state a human sets and clears.
@@ -1111,18 +1109,17 @@ OpsItemStatus:
     after verification — set it directly from code only when the fix has been
     verified end-to-end. `investigating_by_ai` is a system-owned display state —
     set when the AI agent (Jarvis) picks an item up to investigate, never chosen
-    by a human — so it is shown but not offered as a manual choice. Two
-    human-gated holding states park an item OUT of the work queue until a human
-    promotes it to `open` in the dashboard, so `GET /api/admin/ops` excludes
-    them under `status=all`/default and returns them only when requested as an
-    exact `status`: `pending_approval` is the pre-open approval gate for
-    untriaged inbound (e.g. connector requests filed from a customer's
-    connectors panel) so it never gets auto-implemented — approving = flipping
-    the status to `open`; `triage` is the onboarding-help bucket —
-    questions/errors submitted to the "Stuck in onboarding?" assistant are
-    funnelled into the platform project as `triage` rows so the team can see
-    where people get stuck and follow up, keeping onboarding chatter out of the
-    work queue until a human moves real items to `open`.
+    by a human — so it is shown but not offered as a manual choice.
+    `pending_approval` is the one human-gated holding state: it parks an item
+    OUT of the work queue until a human promotes it to `open` in the dashboard,
+    so `GET /api/admin/ops` excludes it under `status=all`/default and returns
+    it only when requested as an exact `status`. It covers untriaged inbound
+    that must never be auto-implemented — connector requests filed from a
+    customer's connectors panel, and questions funnelled in from the "Stuck in
+    onboarding?" assistant — where approving means flipping the status to
+    `open`. Two earlier values were removed in favour of this single gate:
+    `triage` (the onboarding-help bucket, now `pending_approval`) and `triaged`
+    (a redundant "looked at but not started" step, now plain `open`).
 OpsItemPriority:
   type: string
   enum:
@@ -1138,14 +1135,13 @@ OpsInvestigationState:
   type: string
   enum:
     - pr_ready
+    - pr_merged
     - investigated
     - detected
     - question
     - ready_for_qa
     - pending_approval
-    - needs_triage
     - working
-    - triaged_low
     - backlog
   description: >-
     Where automation has taken an item in the investigation lifecycle — the
@@ -1154,11 +1150,14 @@ OpsInvestigationState:
     happen**, never authored on its own: linking a PR sets `pr_ready`, moving to
     `in_progress` sets `working`, `ready_for_qa` sets `ready_for_qa`, a
     system/assistant reply sets `question`, resolving clears it, and creation
-    seeds `needs_triage`/`backlog` (by priority) or `investigated`/`detected`
-    for auto-filed error/alert tickets. `triaged_low` marks a low-signal item AI
-    has looked at but that nothing is moving. Absent on rows filed before the
-    field existed — consumers should treat a missing value as "derive from the
-    other fields".
+    seeds `backlog` or `investigated`/`detected` for auto-filed error/alert
+    tickets. `backlog` is the single "nothing has happened yet" state — how
+    urgent that is reads off `priority`, not off a separate state, and its one
+    action is to hand the item to an agent. `pr_merged` is derived client-side
+    by scanning the linked pull request on GitHub, so it is accepted on write
+    but not currently emitted by the API. Absent on rows filed before the field
+    existed — consumers should treat a missing value as "derive from the other
+    fields".
 OpsItemPriorityOrNull:
   anyOf:
     - $ref: "#/OpsItemPriority"

package/spec/paths/ops.yaml

@@ -29,9 +29,9 @@
         in: query
         required: false
         description: >-
-          Filter by lifecycle status, or `all`. The human-gated holding states
-          (`pending_approval`, `triage`) are excluded from `all`/default and
-          returned only when requested as the exact status.
+          Filter by lifecycle status, or `all`. The human-gated holding state
+          (`pending_approval`) is excluded from `all`/default and returned only
+          when requested as the exact status.
         schema:
           anyOf:
             - $ref: ../components/schemas/ops.yaml#/OpsItemStatus