@leaflow/sdk 0.106.0 → 0.108.0

package/dist/assistant/v1/generated/models/clientContextPartData.js

@@ -0,0 +1,49 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Assistant API
+ * The AI assistant inside the console: conversations, messages, tool calls and their approval, attachments, and connecting the assistant to instant messaging platforms such as WeChat, Feishu and Telegram.
+ *
+ * ## A conversation
+ *
+ * The path one conversation takes, end to end. It names the operations that path needs, not all of them — the full list is below, and it also covers folders, attachments, memories, skills and the instant messaging side.
+ *
+ * 1. `POST /api/v1/threads` creates one;
+ * 2. `POST /api/v1/threads/{thread}/messages` sends a message and returns a `turnId` at once; the assistant runs in the background;
+ * 3. `GET /api/v1/threads/{thread}` returns the conversation document to render, whose `stream` is where live output arrives;
+ * 4. When the assistant needs the user, the document's `wait` says which kind: approving a batch of tool calls (`POST /api/v1/threads/{thread}/approvals/{batch}`), or answering a few questions (`POST /api/v1/threads/{thread}/questions/{item}`). It continues on its own once that is handled.
+ *
+ * Sending a file takes two steps: `POST /api/v1/attachments` for an id, then put that id in `attachmentIds` when sending the message. Images, text and arbitrary binaries all go through the same two steps; what differs is how the assistant reads them afterwards, which the upload response's `kind` says.
+ *
+ * ## Models
+ *
+ * Canopy owns the model catalogue and capabilities. Model ids in this API, conversation preferences and historical entries are Canopy model ids, with no separate assistant model registration. GET /api/v1/models returns the allowed, usable choices and allowModelSelection. Hide the selector when selection is disabled; the service enforces the same rule.
+ *
+ * preferredModelId is the user's choice. Null follows the platform default, including later changes. Disabled selection preserves but ignores preferences for new turns. A model removed from the allowlist, retired in Canopy or otherwise unusable falls back to the default without clearing the preference.
+ *
+ * Users can switch an existing conversation through PATCH /api/v1/threads/{thread} with preferredModelId. This preserves the transcript, starts no turn and makes no inference request. Null returns to following the default. Changes apply from the next turn; a running or waiting turn and messages queued into it retain their captured choices and fallback policy.
+ *
+ * If the chosen model cannot serve a request, the service may safely fall back to the default without confirmation or an additional switching message. If the default also fails, the turn fails normally; no third model is selected for ordinary answers. Fallback preserves executed tool results and never splices answers from different models. Invalid input, cancellation and a declined tool call do not trigger model fallback. Each entry's model records its actual Canopy author, not the saved preference.
+ *
+ * Users cannot choose a compaction model. Normal compaction reuses the effective model and reasoning settings for context-cache reuse. Only if that model cannot handle the compaction request or produce a summary fitting the target window may the service automatically use another allowed Canopy model with suitable capabilities. This does not change the preference or ordinary answer model, and is permitted even when user model selection is disabled.
+ *
+ * After compaction, the full next request, including instructions, tools and retained messages, must fit the target's usable prompt budget with room left for an answer, respecting its output limit. If still too large, further compaction attempts are bounded; exhaustion fails with CANNOT_FOLD instead of sending an oversized request or silently discarding history or images. The same checks apply when switching models or falling back. Each compaction entry records its actual author.
+ *
+ * An empty allowlist or unavailable default does not prevent reading conversations or saving permitted preference changes. A failed Canopy catalogue read is not evidence that a model was removed: use a valid cached snapshot or return MODEL_CATALOG_UNAVAILABLE, without deleting references or inventing capabilities. Catalogue presence is configuration information, not a live provider health check.
+ *
+ * ## Live output
+ *
+ * ```
+ * GET /api/v1/turns/{turn}/stream?ticket=<ticket>&cursor=<cursor>
+ * ```
+ *
+ * This is a Server-Sent Events stream, which is why it is not in the operation list below and why generated clients have no method for it. Open it with `EventSource`, or any SSE client. It is how live output arrives; polling the document on a timer is not the intended way to follow a conversation.
+ *
+ * - `path` and `ticket` both come from the conversation document's `stream`. `path` is relative, resolved against the address the document was fetched from;
+ * - `cursor` is where to start, from the document's `cursor`. Omit it to start at the beginning of what is still available;
+ * - every event is one incremental edit to that same document, so the same rendering logic applies;
+ * - the connection has a lifetime and closes cleanly when it ends. With `EventSource` the browser reconnects with `Last-Event-ID` and resumes by itself, so nothing needs handling;
+ * - three terminal events: `done` this turn finished (carrying its final status), `paused` the assistant is waiting on the user (fetch the document again and read `wait`), `stalled` execution was interrupted and will not resume — do not reconnect.
+ * OpenAPI spec version: 1.0.0
+ */
+export {};

package/dist/assistant/v1/generated/models/clientContextRequest.d.ts

@@ -0,0 +1,79 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Assistant API
+ * The AI assistant inside the console: conversations, messages, tool calls and their approval, attachments, and connecting the assistant to instant messaging platforms such as WeChat, Feishu and Telegram.
+ *
+ * ## A conversation
+ *
+ * The path one conversation takes, end to end. It names the operations that path needs, not all of them — the full list is below, and it also covers folders, attachments, memories, skills and the instant messaging side.
+ *
+ * 1. `POST /api/v1/threads` creates one;
+ * 2. `POST /api/v1/threads/{thread}/messages` sends a message and returns a `turnId` at once; the assistant runs in the background;
+ * 3. `GET /api/v1/threads/{thread}` returns the conversation document to render, whose `stream` is where live output arrives;
+ * 4. When the assistant needs the user, the document's `wait` says which kind: approving a batch of tool calls (`POST /api/v1/threads/{thread}/approvals/{batch}`), or answering a few questions (`POST /api/v1/threads/{thread}/questions/{item}`). It continues on its own once that is handled.
+ *
+ * Sending a file takes two steps: `POST /api/v1/attachments` for an id, then put that id in `attachmentIds` when sending the message. Images, text and arbitrary binaries all go through the same two steps; what differs is how the assistant reads them afterwards, which the upload response's `kind` says.
+ *
+ * ## Models
+ *
+ * Canopy owns the model catalogue and capabilities. Model ids in this API, conversation preferences and historical entries are Canopy model ids, with no separate assistant model registration. GET /api/v1/models returns the allowed, usable choices and allowModelSelection. Hide the selector when selection is disabled; the service enforces the same rule.
+ *
+ * preferredModelId is the user's choice. Null follows the platform default, including later changes. Disabled selection preserves but ignores preferences for new turns. A model removed from the allowlist, retired in Canopy or otherwise unusable falls back to the default without clearing the preference.
+ *
+ * Users can switch an existing conversation through PATCH /api/v1/threads/{thread} with preferredModelId. This preserves the transcript, starts no turn and makes no inference request. Null returns to following the default. Changes apply from the next turn; a running or waiting turn and messages queued into it retain their captured choices and fallback policy.
+ *
+ * If the chosen model cannot serve a request, the service may safely fall back to the default without confirmation or an additional switching message. If the default also fails, the turn fails normally; no third model is selected for ordinary answers. Fallback preserves executed tool results and never splices answers from different models. Invalid input, cancellation and a declined tool call do not trigger model fallback. Each entry's model records its actual Canopy author, not the saved preference.
+ *
+ * Users cannot choose a compaction model. Normal compaction reuses the effective model and reasoning settings for context-cache reuse. Only if that model cannot handle the compaction request or produce a summary fitting the target window may the service automatically use another allowed Canopy model with suitable capabilities. This does not change the preference or ordinary answer model, and is permitted even when user model selection is disabled.
+ *
+ * After compaction, the full next request, including instructions, tools and retained messages, must fit the target's usable prompt budget with room left for an answer, respecting its output limit. If still too large, further compaction attempts are bounded; exhaustion fails with CANNOT_FOLD instead of sending an oversized request or silently discarding history or images. The same checks apply when switching models or falling back. Each compaction entry records its actual author.
+ *
+ * An empty allowlist or unavailable default does not prevent reading conversations or saving permitted preference changes. A failed Canopy catalogue read is not evidence that a model was removed: use a valid cached snapshot or return MODEL_CATALOG_UNAVAILABLE, without deleting references or inventing capabilities. Catalogue presence is configuration information, not a live provider health check.
+ *
+ * ## Live output
+ *
+ * ```
+ * GET /api/v1/turns/{turn}/stream?ticket=<ticket>&cursor=<cursor>
+ * ```
+ *
+ * This is a Server-Sent Events stream, which is why it is not in the operation list below and why generated clients have no method for it. Open it with `EventSource`, or any SSE client. It is how live output arrives; polling the document on a timer is not the intended way to follow a conversation.
+ *
+ * - `path` and `ticket` both come from the conversation document's `stream`. `path` is relative, resolved against the address the document was fetched from;
+ * - `cursor` is where to start, from the document's `cursor`. Omit it to start at the beginning of what is still available;
+ * - every event is one incremental edit to that same document, so the same rendering logic applies;
+ * - the connection has a lifetime and closes cleanly when it ends. With `EventSource` the browser reconnects with `Last-Event-ID` and resumes by itself, so nothing needs handling;
+ * - three terminal events: `done` this turn finished (carrying its final status), `paused` the assistant is waiting on the user (fetch the document again and read `wait`), `stalled` execution was interrupted and will not resume — do not reconnect.
+ * OpenAPI spec version: 1.0.0
+ */
+import type { ClientActionRequest } from "./clientActionRequest.js";
+/**
+ * Which client this is and what it can do, so the assistant can ask it to do those things
+ * while it answers. What the operator is looking at travels as `data-*` parts on the message.
+ *
+ * Send `actions` only when they differ from the last message on this conversation. Sending the
+ * block without `actions` keeps whatever was declared before.
+ */
+export interface ClientContextRequest {
+    /**
+     * The actions on offer right now.
+     *
+     * Omit it when nothing changed since the last message. Send `[]` to say there is nothing
+     * on offer — those are different: a client that moves off the page it was attached to has
+     * to be able to say so, or the assistant keeps calling actions that no longer make sense.
+     * @maxItems 32
+     * @nullable
+     */
+    actions?: ClientActionRequest[] | null;
+    /**
+     * Identifies this client while it stays open. Any stable string; one per tab or process.
+     * @minLength 1
+     * @maxLength 128
+     */
+    clientId: string;
+    /**
+     * How the client calls itself, for example "Leaflow console (web)".
+     * @maxLength 64
+     */
+    label?: string;
+}

package/dist/assistant/v1/generated/models/clientContextRequest.js

@@ -0,0 +1 @@
+export {};

package/dist/assistant/v1/generated/models/clientFunctionRequest.d.ts

@@ -0,0 +1,76 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Assistant API
+ * The AI assistant inside the console: conversations, messages, tool calls and their approval, attachments, and connecting the assistant to instant messaging platforms such as WeChat, Feishu and Telegram.
+ *
+ * ## A conversation
+ *
+ * The path one conversation takes, end to end. It names the operations that path needs, not all of them — the full list is below, and it also covers folders, attachments, memories, skills and the instant messaging side.
+ *
+ * 1. `POST /api/v1/threads` creates one;
+ * 2. `POST /api/v1/threads/{thread}/messages` sends a message and returns a `turnId` at once; the assistant runs in the background;
+ * 3. `GET /api/v1/threads/{thread}` returns the conversation document to render, whose `stream` is where live output arrives;
+ * 4. When the assistant needs the user, the document's `wait` says which kind: approving a batch of tool calls (`POST /api/v1/threads/{thread}/approvals/{batch}`), or answering a few questions (`POST /api/v1/threads/{thread}/questions/{item}`). It continues on its own once that is handled.
+ *
+ * Sending a file takes two steps: `POST /api/v1/attachments` for an id, then put that id in `attachmentIds` when sending the message. Images, text and arbitrary binaries all go through the same two steps; what differs is how the assistant reads them afterwards, which the upload response's `kind` says.
+ *
+ * ## Models
+ *
+ * Canopy owns the model catalogue and capabilities. Model ids in this API, conversation preferences and historical entries are Canopy model ids, with no separate assistant model registration. GET /api/v1/models returns the allowed, usable choices and allowModelSelection. Hide the selector when selection is disabled; the service enforces the same rule.
+ *
+ * preferredModelId is the user's choice. Null follows the platform default, including later changes. Disabled selection preserves but ignores preferences for new turns. A model removed from the allowlist, retired in Canopy or otherwise unusable falls back to the default without clearing the preference.
+ *
+ * Users can switch an existing conversation through PATCH /api/v1/threads/{thread} with preferredModelId. This preserves the transcript, starts no turn and makes no inference request. Null returns to following the default. Changes apply from the next turn; a running or waiting turn and messages queued into it retain their captured choices and fallback policy.
+ *
+ * If the chosen model cannot serve a request, the service may safely fall back to the default without confirmation or an additional switching message. If the default also fails, the turn fails normally; no third model is selected for ordinary answers. Fallback preserves executed tool results and never splices answers from different models. Invalid input, cancellation and a declined tool call do not trigger model fallback. Each entry's model records its actual Canopy author, not the saved preference.
+ *
+ * Users cannot choose a compaction model. Normal compaction reuses the effective model and reasoning settings for context-cache reuse. Only if that model cannot handle the compaction request or produce a summary fitting the target window may the service automatically use another allowed Canopy model with suitable capabilities. This does not change the preference or ordinary answer model, and is permitted even when user model selection is disabled.
+ *
+ * After compaction, the full next request, including instructions, tools and retained messages, must fit the target's usable prompt budget with room left for an answer, respecting its output limit. If still too large, further compaction attempts are bounded; exhaustion fails with CANNOT_FOLD instead of sending an oversized request or silently discarding history or images. The same checks apply when switching models or falling back. Each compaction entry records its actual author.
+ *
+ * An empty allowlist or unavailable default does not prevent reading conversations or saving permitted preference changes. A failed Canopy catalogue read is not evidence that a model was removed: use a valid cached snapshot or return MODEL_CATALOG_UNAVAILABLE, without deleting references or inventing capabilities. Catalogue presence is configuration information, not a live provider health check.
+ *
+ * ## Live output
+ *
+ * ```
+ * GET /api/v1/turns/{turn}/stream?ticket=<ticket>&cursor=<cursor>
+ * ```
+ *
+ * This is a Server-Sent Events stream, which is why it is not in the operation list below and why generated clients have no method for it. Open it with `EventSource`, or any SSE client. It is how live output arrives; polling the document on a timer is not the intended way to follow a conversation.
+ *
+ * - `path` and `ticket` both come from the conversation document's `stream`. `path` is relative, resolved against the address the document was fetched from;
+ * - `cursor` is where to start, from the document's `cursor`. Omit it to start at the beginning of what is still available;
+ * - every event is one incremental edit to that same document, so the same rendering logic applies;
+ * - the connection has a lifetime and closes cleanly when it ends. With `EventSource` the browser reconnects with `Last-Event-ID` and resumes by itself, so nothing needs handling;
+ * - three terminal events: `done` this turn finished (carrying its final status), `paused` the assistant is waiting on the user (fetch the document again and read `wait`), `stalled` execution was interrupted and will not resume — do not reconnect.
+ * OpenAPI spec version: 1.0.0
+ */
+import type { ClientFunctionRequestInputSchema } from "./clientFunctionRequestInputSchema.js";
+import type { ClientFunctionRequestParameters } from "./clientFunctionRequestParameters.js";
+/**
+ * The function object from the OpenAI tools format.
+ */
+export interface ClientFunctionRequest {
+    /**
+     * What the action does, written for the model. An action without one can only be guessed at from its name. The 1024 ceiling is OpenAI's own limit on `tools[].function.description`, not a number chosen here: over it the upstream call fails with `string_above_max_length`, and refusing at submission is the clearer of the two places to refuse. It was 500, which ran out at about six enumerated entries — an action that must list what it accepts had nowhere to put the list.
+     * @minLength 1
+     * @maxLength 1024
+     */
+    description: string;
+    /**
+     * The MCP and Anthropic spelling of `parameters`. Give one or the other, not both.
+     * @nullable
+     */
+    inputSchema?: ClientFunctionRequestInputSchema;
+    /**
+     * @minLength 1
+     * @maxLength 64
+     */
+    name: string;
+    /**
+     * JSON Schema for the arguments. Omit for an action that takes none.
+     * @nullable
+     */
+    parameters?: ClientFunctionRequestParameters;
+}

package/dist/assistant/v1/generated/models/clientFunctionRequest.js

@@ -0,0 +1 @@
+export {};

package/dist/assistant/v1/generated/models/clientFunctionRequestInputSchema.d.ts

@@ -0,0 +1,55 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Assistant API
+ * The AI assistant inside the console: conversations, messages, tool calls and their approval, attachments, and connecting the assistant to instant messaging platforms such as WeChat, Feishu and Telegram.
+ *
+ * ## A conversation
+ *
+ * The path one conversation takes, end to end. It names the operations that path needs, not all of them — the full list is below, and it also covers folders, attachments, memories, skills and the instant messaging side.
+ *
+ * 1. `POST /api/v1/threads` creates one;
+ * 2. `POST /api/v1/threads/{thread}/messages` sends a message and returns a `turnId` at once; the assistant runs in the background;
+ * 3. `GET /api/v1/threads/{thread}` returns the conversation document to render, whose `stream` is where live output arrives;
+ * 4. When the assistant needs the user, the document's `wait` says which kind: approving a batch of tool calls (`POST /api/v1/threads/{thread}/approvals/{batch}`), or answering a few questions (`POST /api/v1/threads/{thread}/questions/{item}`). It continues on its own once that is handled.
+ *
+ * Sending a file takes two steps: `POST /api/v1/attachments` for an id, then put that id in `attachmentIds` when sending the message. Images, text and arbitrary binaries all go through the same two steps; what differs is how the assistant reads them afterwards, which the upload response's `kind` says.
+ *
+ * ## Models
+ *
+ * Canopy owns the model catalogue and capabilities. Model ids in this API, conversation preferences and historical entries are Canopy model ids, with no separate assistant model registration. GET /api/v1/models returns the allowed, usable choices and allowModelSelection. Hide the selector when selection is disabled; the service enforces the same rule.
+ *
+ * preferredModelId is the user's choice. Null follows the platform default, including later changes. Disabled selection preserves but ignores preferences for new turns. A model removed from the allowlist, retired in Canopy or otherwise unusable falls back to the default without clearing the preference.
+ *
+ * Users can switch an existing conversation through PATCH /api/v1/threads/{thread} with preferredModelId. This preserves the transcript, starts no turn and makes no inference request. Null returns to following the default. Changes apply from the next turn; a running or waiting turn and messages queued into it retain their captured choices and fallback policy.
+ *
+ * If the chosen model cannot serve a request, the service may safely fall back to the default without confirmation or an additional switching message. If the default also fails, the turn fails normally; no third model is selected for ordinary answers. Fallback preserves executed tool results and never splices answers from different models. Invalid input, cancellation and a declined tool call do not trigger model fallback. Each entry's model records its actual Canopy author, not the saved preference.
+ *
+ * Users cannot choose a compaction model. Normal compaction reuses the effective model and reasoning settings for context-cache reuse. Only if that model cannot handle the compaction request or produce a summary fitting the target window may the service automatically use another allowed Canopy model with suitable capabilities. This does not change the preference or ordinary answer model, and is permitted even when user model selection is disabled.
+ *
+ * After compaction, the full next request, including instructions, tools and retained messages, must fit the target's usable prompt budget with room left for an answer, respecting its output limit. If still too large, further compaction attempts are bounded; exhaustion fails with CANNOT_FOLD instead of sending an oversized request or silently discarding history or images. The same checks apply when switching models or falling back. Each compaction entry records its actual author.
+ *
+ * An empty allowlist or unavailable default does not prevent reading conversations or saving permitted preference changes. A failed Canopy catalogue read is not evidence that a model was removed: use a valid cached snapshot or return MODEL_CATALOG_UNAVAILABLE, without deleting references or inventing capabilities. Catalogue presence is configuration information, not a live provider health check.
+ *
+ * ## Live output
+ *
+ * ```
+ * GET /api/v1/turns/{turn}/stream?ticket=<ticket>&cursor=<cursor>
+ * ```
+ *
+ * This is a Server-Sent Events stream, which is why it is not in the operation list below and why generated clients have no method for it. Open it with `EventSource`, or any SSE client. It is how live output arrives; polling the document on a timer is not the intended way to follow a conversation.
+ *
+ * - `path` and `ticket` both come from the conversation document's `stream`. `path` is relative, resolved against the address the document was fetched from;
+ * - `cursor` is where to start, from the document's `cursor`. Omit it to start at the beginning of what is still available;
+ * - every event is one incremental edit to that same document, so the same rendering logic applies;
+ * - the connection has a lifetime and closes cleanly when it ends. With `EventSource` the browser reconnects with `Last-Event-ID` and resumes by itself, so nothing needs handling;
+ * - three terminal events: `done` this turn finished (carrying its final status), `paused` the assistant is waiting on the user (fetch the document again and read `wait`), `stalled` execution was interrupted and will not resume — do not reconnect.
+ * OpenAPI spec version: 1.0.0
+ */
+/**
+ * The MCP and Anthropic spelling of `parameters`. Give one or the other, not both.
+ * @nullable
+ */
+export type ClientFunctionRequestInputSchema = {
+    [key: string]: unknown;
+} | null;

package/dist/assistant/v1/generated/models/clientFunctionRequestInputSchema.js

@@ -0,0 +1,49 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Assistant API
+ * The AI assistant inside the console: conversations, messages, tool calls and their approval, attachments, and connecting the assistant to instant messaging platforms such as WeChat, Feishu and Telegram.
+ *
+ * ## A conversation
+ *
+ * The path one conversation takes, end to end. It names the operations that path needs, not all of them — the full list is below, and it also covers folders, attachments, memories, skills and the instant messaging side.
+ *
+ * 1. `POST /api/v1/threads` creates one;
+ * 2. `POST /api/v1/threads/{thread}/messages` sends a message and returns a `turnId` at once; the assistant runs in the background;
+ * 3. `GET /api/v1/threads/{thread}` returns the conversation document to render, whose `stream` is where live output arrives;
+ * 4. When the assistant needs the user, the document's `wait` says which kind: approving a batch of tool calls (`POST /api/v1/threads/{thread}/approvals/{batch}`), or answering a few questions (`POST /api/v1/threads/{thread}/questions/{item}`). It continues on its own once that is handled.
+ *
+ * Sending a file takes two steps: `POST /api/v1/attachments` for an id, then put that id in `attachmentIds` when sending the message. Images, text and arbitrary binaries all go through the same two steps; what differs is how the assistant reads them afterwards, which the upload response's `kind` says.
+ *
+ * ## Models
+ *
+ * Canopy owns the model catalogue and capabilities. Model ids in this API, conversation preferences and historical entries are Canopy model ids, with no separate assistant model registration. GET /api/v1/models returns the allowed, usable choices and allowModelSelection. Hide the selector when selection is disabled; the service enforces the same rule.
+ *
+ * preferredModelId is the user's choice. Null follows the platform default, including later changes. Disabled selection preserves but ignores preferences for new turns. A model removed from the allowlist, retired in Canopy or otherwise unusable falls back to the default without clearing the preference.
+ *
+ * Users can switch an existing conversation through PATCH /api/v1/threads/{thread} with preferredModelId. This preserves the transcript, starts no turn and makes no inference request. Null returns to following the default. Changes apply from the next turn; a running or waiting turn and messages queued into it retain their captured choices and fallback policy.
+ *
+ * If the chosen model cannot serve a request, the service may safely fall back to the default without confirmation or an additional switching message. If the default also fails, the turn fails normally; no third model is selected for ordinary answers. Fallback preserves executed tool results and never splices answers from different models. Invalid input, cancellation and a declined tool call do not trigger model fallback. Each entry's model records its actual Canopy author, not the saved preference.
+ *
+ * Users cannot choose a compaction model. Normal compaction reuses the effective model and reasoning settings for context-cache reuse. Only if that model cannot handle the compaction request or produce a summary fitting the target window may the service automatically use another allowed Canopy model with suitable capabilities. This does not change the preference or ordinary answer model, and is permitted even when user model selection is disabled.
+ *
+ * After compaction, the full next request, including instructions, tools and retained messages, must fit the target's usable prompt budget with room left for an answer, respecting its output limit. If still too large, further compaction attempts are bounded; exhaustion fails with CANNOT_FOLD instead of sending an oversized request or silently discarding history or images. The same checks apply when switching models or falling back. Each compaction entry records its actual author.
+ *
+ * An empty allowlist or unavailable default does not prevent reading conversations or saving permitted preference changes. A failed Canopy catalogue read is not evidence that a model was removed: use a valid cached snapshot or return MODEL_CATALOG_UNAVAILABLE, without deleting references or inventing capabilities. Catalogue presence is configuration information, not a live provider health check.
+ *
+ * ## Live output
+ *
+ * ```
+ * GET /api/v1/turns/{turn}/stream?ticket=<ticket>&cursor=<cursor>
+ * ```
+ *
+ * This is a Server-Sent Events stream, which is why it is not in the operation list below and why generated clients have no method for it. Open it with `EventSource`, or any SSE client. It is how live output arrives; polling the document on a timer is not the intended way to follow a conversation.
+ *
+ * - `path` and `ticket` both come from the conversation document's `stream`. `path` is relative, resolved against the address the document was fetched from;
+ * - `cursor` is where to start, from the document's `cursor`. Omit it to start at the beginning of what is still available;
+ * - every event is one incremental edit to that same document, so the same rendering logic applies;
+ * - the connection has a lifetime and closes cleanly when it ends. With `EventSource` the browser reconnects with `Last-Event-ID` and resumes by itself, so nothing needs handling;
+ * - three terminal events: `done` this turn finished (carrying its final status), `paused` the assistant is waiting on the user (fetch the document again and read `wait`), `stalled` execution was interrupted and will not resume — do not reconnect.
+ * OpenAPI spec version: 1.0.0
+ */
+export {};

package/dist/assistant/v1/generated/models/clientFunctionRequestParameters.d.ts

@@ -0,0 +1,55 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Assistant API
+ * The AI assistant inside the console: conversations, messages, tool calls and their approval, attachments, and connecting the assistant to instant messaging platforms such as WeChat, Feishu and Telegram.
+ *
+ * ## A conversation
+ *
+ * The path one conversation takes, end to end. It names the operations that path needs, not all of them — the full list is below, and it also covers folders, attachments, memories, skills and the instant messaging side.
+ *
+ * 1. `POST /api/v1/threads` creates one;
+ * 2. `POST /api/v1/threads/{thread}/messages` sends a message and returns a `turnId` at once; the assistant runs in the background;
+ * 3. `GET /api/v1/threads/{thread}` returns the conversation document to render, whose `stream` is where live output arrives;
+ * 4. When the assistant needs the user, the document's `wait` says which kind: approving a batch of tool calls (`POST /api/v1/threads/{thread}/approvals/{batch}`), or answering a few questions (`POST /api/v1/threads/{thread}/questions/{item}`). It continues on its own once that is handled.
+ *
+ * Sending a file takes two steps: `POST /api/v1/attachments` for an id, then put that id in `attachmentIds` when sending the message. Images, text and arbitrary binaries all go through the same two steps; what differs is how the assistant reads them afterwards, which the upload response's `kind` says.
+ *
+ * ## Models
+ *
+ * Canopy owns the model catalogue and capabilities. Model ids in this API, conversation preferences and historical entries are Canopy model ids, with no separate assistant model registration. GET /api/v1/models returns the allowed, usable choices and allowModelSelection. Hide the selector when selection is disabled; the service enforces the same rule.
+ *
+ * preferredModelId is the user's choice. Null follows the platform default, including later changes. Disabled selection preserves but ignores preferences for new turns. A model removed from the allowlist, retired in Canopy or otherwise unusable falls back to the default without clearing the preference.
+ *
+ * Users can switch an existing conversation through PATCH /api/v1/threads/{thread} with preferredModelId. This preserves the transcript, starts no turn and makes no inference request. Null returns to following the default. Changes apply from the next turn; a running or waiting turn and messages queued into it retain their captured choices and fallback policy.
+ *
+ * If the chosen model cannot serve a request, the service may safely fall back to the default without confirmation or an additional switching message. If the default also fails, the turn fails normally; no third model is selected for ordinary answers. Fallback preserves executed tool results and never splices answers from different models. Invalid input, cancellation and a declined tool call do not trigger model fallback. Each entry's model records its actual Canopy author, not the saved preference.
+ *
+ * Users cannot choose a compaction model. Normal compaction reuses the effective model and reasoning settings for context-cache reuse. Only if that model cannot handle the compaction request or produce a summary fitting the target window may the service automatically use another allowed Canopy model with suitable capabilities. This does not change the preference or ordinary answer model, and is permitted even when user model selection is disabled.
+ *
+ * After compaction, the full next request, including instructions, tools and retained messages, must fit the target's usable prompt budget with room left for an answer, respecting its output limit. If still too large, further compaction attempts are bounded; exhaustion fails with CANNOT_FOLD instead of sending an oversized request or silently discarding history or images. The same checks apply when switching models or falling back. Each compaction entry records its actual author.
+ *
+ * An empty allowlist or unavailable default does not prevent reading conversations or saving permitted preference changes. A failed Canopy catalogue read is not evidence that a model was removed: use a valid cached snapshot or return MODEL_CATALOG_UNAVAILABLE, without deleting references or inventing capabilities. Catalogue presence is configuration information, not a live provider health check.
+ *
+ * ## Live output
+ *
+ * ```
+ * GET /api/v1/turns/{turn}/stream?ticket=<ticket>&cursor=<cursor>
+ * ```
+ *
+ * This is a Server-Sent Events stream, which is why it is not in the operation list below and why generated clients have no method for it. Open it with `EventSource`, or any SSE client. It is how live output arrives; polling the document on a timer is not the intended way to follow a conversation.
+ *
+ * - `path` and `ticket` both come from the conversation document's `stream`. `path` is relative, resolved against the address the document was fetched from;
+ * - `cursor` is where to start, from the document's `cursor`. Omit it to start at the beginning of what is still available;
+ * - every event is one incremental edit to that same document, so the same rendering logic applies;
+ * - the connection has a lifetime and closes cleanly when it ends. With `EventSource` the browser reconnects with `Last-Event-ID` and resumes by itself, so nothing needs handling;
+ * - three terminal events: `done` this turn finished (carrying its final status), `paused` the assistant is waiting on the user (fetch the document again and read `wait`), `stalled` execution was interrupted and will not resume — do not reconnect.
+ * OpenAPI spec version: 1.0.0
+ */
+/**
+ * JSON Schema for the arguments. Omit for an action that takes none.
+ * @nullable
+ */
+export type ClientFunctionRequestParameters = {
+    [key: string]: unknown;
+} | null;

package/dist/assistant/v1/generated/models/clientFunctionRequestParameters.js

@@ -0,0 +1,49 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Assistant API
+ * The AI assistant inside the console: conversations, messages, tool calls and their approval, attachments, and connecting the assistant to instant messaging platforms such as WeChat, Feishu and Telegram.
+ *
+ * ## A conversation
+ *
+ * The path one conversation takes, end to end. It names the operations that path needs, not all of them — the full list is below, and it also covers folders, attachments, memories, skills and the instant messaging side.
+ *
+ * 1. `POST /api/v1/threads` creates one;
+ * 2. `POST /api/v1/threads/{thread}/messages` sends a message and returns a `turnId` at once; the assistant runs in the background;
+ * 3. `GET /api/v1/threads/{thread}` returns the conversation document to render, whose `stream` is where live output arrives;
+ * 4. When the assistant needs the user, the document's `wait` says which kind: approving a batch of tool calls (`POST /api/v1/threads/{thread}/approvals/{batch}`), or answering a few questions (`POST /api/v1/threads/{thread}/questions/{item}`). It continues on its own once that is handled.
+ *
+ * Sending a file takes two steps: `POST /api/v1/attachments` for an id, then put that id in `attachmentIds` when sending the message. Images, text and arbitrary binaries all go through the same two steps; what differs is how the assistant reads them afterwards, which the upload response's `kind` says.
+ *
+ * ## Models
+ *
+ * Canopy owns the model catalogue and capabilities. Model ids in this API, conversation preferences and historical entries are Canopy model ids, with no separate assistant model registration. GET /api/v1/models returns the allowed, usable choices and allowModelSelection. Hide the selector when selection is disabled; the service enforces the same rule.
+ *
+ * preferredModelId is the user's choice. Null follows the platform default, including later changes. Disabled selection preserves but ignores preferences for new turns. A model removed from the allowlist, retired in Canopy or otherwise unusable falls back to the default without clearing the preference.
+ *
+ * Users can switch an existing conversation through PATCH /api/v1/threads/{thread} with preferredModelId. This preserves the transcript, starts no turn and makes no inference request. Null returns to following the default. Changes apply from the next turn; a running or waiting turn and messages queued into it retain their captured choices and fallback policy.
+ *
+ * If the chosen model cannot serve a request, the service may safely fall back to the default without confirmation or an additional switching message. If the default also fails, the turn fails normally; no third model is selected for ordinary answers. Fallback preserves executed tool results and never splices answers from different models. Invalid input, cancellation and a declined tool call do not trigger model fallback. Each entry's model records its actual Canopy author, not the saved preference.
+ *
+ * Users cannot choose a compaction model. Normal compaction reuses the effective model and reasoning settings for context-cache reuse. Only if that model cannot handle the compaction request or produce a summary fitting the target window may the service automatically use another allowed Canopy model with suitable capabilities. This does not change the preference or ordinary answer model, and is permitted even when user model selection is disabled.
+ *
+ * After compaction, the full next request, including instructions, tools and retained messages, must fit the target's usable prompt budget with room left for an answer, respecting its output limit. If still too large, further compaction attempts are bounded; exhaustion fails with CANNOT_FOLD instead of sending an oversized request or silently discarding history or images. The same checks apply when switching models or falling back. Each compaction entry records its actual author.
+ *
+ * An empty allowlist or unavailable default does not prevent reading conversations or saving permitted preference changes. A failed Canopy catalogue read is not evidence that a model was removed: use a valid cached snapshot or return MODEL_CATALOG_UNAVAILABLE, without deleting references or inventing capabilities. Catalogue presence is configuration information, not a live provider health check.
+ *
+ * ## Live output
+ *
+ * ```
+ * GET /api/v1/turns/{turn}/stream?ticket=<ticket>&cursor=<cursor>
+ * ```
+ *
+ * This is a Server-Sent Events stream, which is why it is not in the operation list below and why generated clients have no method for it. Open it with `EventSource`, or any SSE client. It is how live output arrives; polling the document on a timer is not the intended way to follow a conversation.
+ *
+ * - `path` and `ticket` both come from the conversation document's `stream`. `path` is relative, resolved against the address the document was fetched from;
+ * - `cursor` is where to start, from the document's `cursor`. Omit it to start at the beginning of what is still available;
+ * - every event is one incremental edit to that same document, so the same rendering logic applies;
+ * - the connection has a lifetime and closes cleanly when it ends. With `EventSource` the browser reconnects with `Last-Event-ID` and resumes by itself, so nothing needs handling;
+ * - three terminal events: `done` this turn finished (carrying its final status), `paused` the assistant is waiting on the user (fetch the document again and read `wait`), `stalled` execution was interrupted and will not resume — do not reconnect.
+ * OpenAPI spec version: 1.0.0
+ */
+export {};

package/dist/assistant/v1/generated/models/contextResource.d.ts

@@ -0,0 +1,70 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Assistant API
+ * The AI assistant inside the console: conversations, messages, tool calls and their approval, attachments, and connecting the assistant to instant messaging platforms such as WeChat, Feishu and Telegram.
+ *
+ * ## A conversation
+ *
+ * The path one conversation takes, end to end. It names the operations that path needs, not all of them — the full list is below, and it also covers folders, attachments, memories, skills and the instant messaging side.
+ *
+ * 1. `POST /api/v1/threads` creates one;
+ * 2. `POST /api/v1/threads/{thread}/messages` sends a message and returns a `turnId` at once; the assistant runs in the background;
+ * 3. `GET /api/v1/threads/{thread}` returns the conversation document to render, whose `stream` is where live output arrives;
+ * 4. When the assistant needs the user, the document's `wait` says which kind: approving a batch of tool calls (`POST /api/v1/threads/{thread}/approvals/{batch}`), or answering a few questions (`POST /api/v1/threads/{thread}/questions/{item}`). It continues on its own once that is handled.
+ *
+ * Sending a file takes two steps: `POST /api/v1/attachments` for an id, then put that id in `attachmentIds` when sending the message. Images, text and arbitrary binaries all go through the same two steps; what differs is how the assistant reads them afterwards, which the upload response's `kind` says.
+ *
+ * ## Models
+ *
+ * Canopy owns the model catalogue and capabilities. Model ids in this API, conversation preferences and historical entries are Canopy model ids, with no separate assistant model registration. GET /api/v1/models returns the allowed, usable choices and allowModelSelection. Hide the selector when selection is disabled; the service enforces the same rule.
+ *
+ * preferredModelId is the user's choice. Null follows the platform default, including later changes. Disabled selection preserves but ignores preferences for new turns. A model removed from the allowlist, retired in Canopy or otherwise unusable falls back to the default without clearing the preference.
+ *
+ * Users can switch an existing conversation through PATCH /api/v1/threads/{thread} with preferredModelId. This preserves the transcript, starts no turn and makes no inference request. Null returns to following the default. Changes apply from the next turn; a running or waiting turn and messages queued into it retain their captured choices and fallback policy.
+ *
+ * If the chosen model cannot serve a request, the service may safely fall back to the default without confirmation or an additional switching message. If the default also fails, the turn fails normally; no third model is selected for ordinary answers. Fallback preserves executed tool results and never splices answers from different models. Invalid input, cancellation and a declined tool call do not trigger model fallback. Each entry's model records its actual Canopy author, not the saved preference.
+ *
+ * Users cannot choose a compaction model. Normal compaction reuses the effective model and reasoning settings for context-cache reuse. Only if that model cannot handle the compaction request or produce a summary fitting the target window may the service automatically use another allowed Canopy model with suitable capabilities. This does not change the preference or ordinary answer model, and is permitted even when user model selection is disabled.
+ *
+ * After compaction, the full next request, including instructions, tools and retained messages, must fit the target's usable prompt budget with room left for an answer, respecting its output limit. If still too large, further compaction attempts are bounded; exhaustion fails with CANNOT_FOLD instead of sending an oversized request or silently discarding history or images. The same checks apply when switching models or falling back. Each compaction entry records its actual author.
+ *
+ * An empty allowlist or unavailable default does not prevent reading conversations or saving permitted preference changes. A failed Canopy catalogue read is not evidence that a model was removed: use a valid cached snapshot or return MODEL_CATALOG_UNAVAILABLE, without deleting references or inventing capabilities. Catalogue presence is configuration information, not a live provider health check.
+ *
+ * ## Live output
+ *
+ * ```
+ * GET /api/v1/turns/{turn}/stream?ticket=<ticket>&cursor=<cursor>
+ * ```
+ *
+ * This is a Server-Sent Events stream, which is why it is not in the operation list below and why generated clients have no method for it. Open it with `EventSource`, or any SSE client. It is how live output arrives; polling the document on a timer is not the intended way to follow a conversation.
+ *
+ * - `path` and `ticket` both come from the conversation document's `stream`. `path` is relative, resolved against the address the document was fetched from;
+ * - `cursor` is where to start, from the document's `cursor`. Omit it to start at the beginning of what is still available;
+ * - every event is one incremental edit to that same document, so the same rendering logic applies;
+ * - the connection has a lifetime and closes cleanly when it ends. With `EventSource` the browser reconnects with `Last-Event-ID` and resumes by itself, so nothing needs handling;
+ * - three terminal events: `done` this turn finished (carrying its final status), `paused` the assistant is waiting on the user (fetch the document again and read `wait`), `stalled` execution was interrupted and will not resume — do not reconnect.
+ * OpenAPI spec version: 1.0.0
+ */
+export interface ContextResource {
+    /** @nullable */
+    compactAt: number | null;
+    /**
+     * What kinds of input the model behind this conversation accepts, as modality names: text, image.
+     *
+     * This governs images and nothing else. Text and binary attachments reach every model: a small text file is placed inline, a large one is read on demand, and a binary is downloaded onto a cloud instance — none of which asks the model to see a picture. So this decides whether pasting a screenshot does anything, not whether the attach control exists. Hiding file upload on a text-only model takes away something that would have worked.
+     *
+     * This describes the effective model, including a replacement chosen through fallback, rather than the saved preference. An empty list means no effective model is available to describe; it is not a claim that every model rejects files.
+     */
+    inputModalities: string[];
+    /**
+     * The effective Canopy model id, matching the conversation summary's model. Null when no model can be selected; window and compactAt are then null and inputModalities is empty.
+     * @nullable
+     */
+    model: string | null;
+    /** @nullable */
+    used: number | null;
+    warnAt: number;
+    /** @nullable */
+    window: number | null;
+}

package/dist/assistant/v1/generated/models/contextResource.js

@@ -0,0 +1,49 @@
+/**
+ * Generated by orval 🍺
+ * Do not edit manually.
+ * Leaflow Assistant API
+ * The AI assistant inside the console: conversations, messages, tool calls and their approval, attachments, and connecting the assistant to instant messaging platforms such as WeChat, Feishu and Telegram.
+ *
+ * ## A conversation
+ *
+ * The path one conversation takes, end to end. It names the operations that path needs, not all of them — the full list is below, and it also covers folders, attachments, memories, skills and the instant messaging side.
+ *
+ * 1. `POST /api/v1/threads` creates one;
+ * 2. `POST /api/v1/threads/{thread}/messages` sends a message and returns a `turnId` at once; the assistant runs in the background;
+ * 3. `GET /api/v1/threads/{thread}` returns the conversation document to render, whose `stream` is where live output arrives;
+ * 4. When the assistant needs the user, the document's `wait` says which kind: approving a batch of tool calls (`POST /api/v1/threads/{thread}/approvals/{batch}`), or answering a few questions (`POST /api/v1/threads/{thread}/questions/{item}`). It continues on its own once that is handled.
+ *
+ * Sending a file takes two steps: `POST /api/v1/attachments` for an id, then put that id in `attachmentIds` when sending the message. Images, text and arbitrary binaries all go through the same two steps; what differs is how the assistant reads them afterwards, which the upload response's `kind` says.
+ *
+ * ## Models
+ *
+ * Canopy owns the model catalogue and capabilities. Model ids in this API, conversation preferences and historical entries are Canopy model ids, with no separate assistant model registration. GET /api/v1/models returns the allowed, usable choices and allowModelSelection. Hide the selector when selection is disabled; the service enforces the same rule.
+ *
+ * preferredModelId is the user's choice. Null follows the platform default, including later changes. Disabled selection preserves but ignores preferences for new turns. A model removed from the allowlist, retired in Canopy or otherwise unusable falls back to the default without clearing the preference.
+ *
+ * Users can switch an existing conversation through PATCH /api/v1/threads/{thread} with preferredModelId. This preserves the transcript, starts no turn and makes no inference request. Null returns to following the default. Changes apply from the next turn; a running or waiting turn and messages queued into it retain their captured choices and fallback policy.
+ *
+ * If the chosen model cannot serve a request, the service may safely fall back to the default without confirmation or an additional switching message. If the default also fails, the turn fails normally; no third model is selected for ordinary answers. Fallback preserves executed tool results and never splices answers from different models. Invalid input, cancellation and a declined tool call do not trigger model fallback. Each entry's model records its actual Canopy author, not the saved preference.
+ *
+ * Users cannot choose a compaction model. Normal compaction reuses the effective model and reasoning settings for context-cache reuse. Only if that model cannot handle the compaction request or produce a summary fitting the target window may the service automatically use another allowed Canopy model with suitable capabilities. This does not change the preference or ordinary answer model, and is permitted even when user model selection is disabled.
+ *
+ * After compaction, the full next request, including instructions, tools and retained messages, must fit the target's usable prompt budget with room left for an answer, respecting its output limit. If still too large, further compaction attempts are bounded; exhaustion fails with CANNOT_FOLD instead of sending an oversized request or silently discarding history or images. The same checks apply when switching models or falling back. Each compaction entry records its actual author.
+ *
+ * An empty allowlist or unavailable default does not prevent reading conversations or saving permitted preference changes. A failed Canopy catalogue read is not evidence that a model was removed: use a valid cached snapshot or return MODEL_CATALOG_UNAVAILABLE, without deleting references or inventing capabilities. Catalogue presence is configuration information, not a live provider health check.
+ *
+ * ## Live output
+ *
+ * ```
+ * GET /api/v1/turns/{turn}/stream?ticket=<ticket>&cursor=<cursor>
+ * ```
+ *
+ * This is a Server-Sent Events stream, which is why it is not in the operation list below and why generated clients have no method for it. Open it with `EventSource`, or any SSE client. It is how live output arrives; polling the document on a timer is not the intended way to follow a conversation.
+ *
+ * - `path` and `ticket` both come from the conversation document's `stream`. `path` is relative, resolved against the address the document was fetched from;
+ * - `cursor` is where to start, from the document's `cursor`. Omit it to start at the beginning of what is still available;
+ * - every event is one incremental edit to that same document, so the same rendering logic applies;
+ * - the connection has a lifetime and closes cleanly when it ends. With `EventSource` the browser reconnects with `Last-Event-ID` and resumes by itself, so nothing needs handling;
+ * - three terminal events: `done` this turn finished (carrying its final status), `paused` the assistant is waiting on the user (fetch the document again and read `wait`), `stalled` execution was interrupted and will not resume — do not reconnect.
+ * OpenAPI spec version: 1.0.0
+ */
+export {};