@leaflow/sdk 0.0.0-dev.35.g30ba751 → 0.0.0-dev.352.g85966ed

package/dist/assistant/v1/generated/schemas.zod.js

@@ -0,0 +1,476 @@
+/**
+ * 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 * as zod from "zod";
+import { AnswerRequestBody } from "./validators/answerRequestBody.zod.js";
+import { CreateChannelRequestBody } from "./validators/createChannelRequestBody.zod.js";
+import { CreateFolderRequestBody } from "./validators/createFolderRequestBody.zod.js";
+import { CreateThreadRequestBody } from "./validators/createThreadRequestBody.zod.js";
+import { DecideRequestBody } from "./validators/decideRequestBody.zod.js";
+import { DynamicCallResultRequestBody } from "./validators/dynamicCallResultRequestBody.zod.js";
+import { RevertRequestBody } from "./validators/revertRequestBody.zod.js";
+import { RotateSecretRequestBody } from "./validators/rotateSecretRequestBody.zod.js";
+import { SendMessageRequestBody } from "./validators/sendMessageRequestBody.zod.js";
+import { SkillEnabledRequestBody } from "./validators/skillEnabledRequestBody.zod.js";
+import { SkillRequestBody } from "./validators/skillRequestBody.zod.js";
+import { UpdateChannelRequestBody } from "./validators/updateChannelRequestBody.zod.js";
+import { UpdateFolderRequestBody } from "./validators/updateFolderRequestBody.zod.js";
+import { UpdateThreadRequestBody } from "./validators/updateThreadRequestBody.zod.js";
+import { VerifyCodeRequestBody } from "./validators/verifyCodeRequestBody.zod.js";
+/**
+ * The body is the file bytes themselves, not multipart, one file per request. The kind is determined from the content, not from Content-Type or from the name. Put the returned id in attachmentIds when sending a message.
+ *
+ * An upload that no message ever references is a draft, and drafts are collected — `draftExpiresAt` in the response says when this one goes. Sending a message with the id makes it permanent.
+ *
+ * The returned `kind` says how the assistant will see it. An `image` is read directly, and only by models that accept image input. A small `text` file is placed inline in the message. A large `text` file, and anything `binary`, arrives as a reference the assistant reads on demand — for a binary that usually means downloading it onto one of the project's cloud instances.
+ * @summary Upload a file
+ */
+export const uploadAttachmentQueryFilenameMax = 255;
+export const UploadAttachmentQueryParams = zod.strictObject({
+    filename: zod
+        .string()
+        .max(uploadAttachmentQueryFilenameMax)
+        .optional()
+        .describe("The name to show and to give the assistant. Images do not need one; anything else does, because the name is most of what says what the file is. Falls back to a generated name."),
+});
+/**
+ * Returns the original bytes for an attachment id. The response carries long-lived cache headers because the content never changes. Returns 404 when the attachment does not exist or does not belong to the current user.
+ *
+ * Only an attachment whose `kind` is `image` comes back with its own image type and is usable as the address of an `<img>`. Everything else is served as `application/octet-stream` with `Content-Disposition: attachment`, deliberately: an uploaded file is arbitrary bytes under a name its uploader chose, and serving it back inline would run it on this origin.
+ * @summary Download a file
+ */
+export const DownloadAttachmentParams = zod.strictObject({
+    attachment: zod.string(),
+});
+/**
+ * Filter by channelId to show, per channel, who is bound to it.
+ * @summary List bindings
+ */
+export const listBindingsQueryLimitDefault = 50;
+export const listBindingsQueryLimitMax = 200;
+export const listBindingsQueryOffsetDefault = 0;
+export const listBindingsQueryOffsetMin = 0;
+export const listBindingsQueryOffsetMax = 10000;
+export const ListBindingsQueryParams = zod.strictObject({
+    limit: zod
+        .int()
+        .min(1)
+        .max(listBindingsQueryLimitMax)
+        .default(listBindingsQueryLimitDefault)
+        .describe("Items returned in this page. Defaults to 50; at most 200."),
+    offset: zod
+        .int()
+        .min(listBindingsQueryOffsetMin)
+        .max(listBindingsQueryOffsetMax)
+        .default(listBindingsQueryOffsetDefault)
+        .describe("Items to skip. Defaults to 0; at most 10000."),
+    platform: zod.string().optional(),
+    channelId: zod.uuid().optional(),
+    active: zod.boolean().optional().describe("Return only bindings that are active"),
+});
+/**
+ * @summary Get a binding
+ */
+export const GetBindingParams = zod.strictObject({
+    binding: zod.uuid(),
+});
+/**
+ * @summary Remove a binding
+ */
+export const DeleteBindingParams = zod.strictObject({
+    binding: zod.uuid(),
+});
+/**
+ * @summary List channels
+ */
+export const listChannelsQueryLimitDefault = 50;
+export const listChannelsQueryLimitMax = 200;
+export const listChannelsQueryOffsetDefault = 0;
+export const listChannelsQueryOffsetMin = 0;
+export const listChannelsQueryOffsetMax = 10000;
+export const ListChannelsQueryParams = zod.strictObject({
+    limit: zod
+        .int()
+        .min(1)
+        .max(listChannelsQueryLimitMax)
+        .default(listChannelsQueryLimitDefault)
+        .describe("Items returned in this page. Defaults to 50; at most 200."),
+    offset: zod
+        .int()
+        .min(listChannelsQueryOffsetMin)
+        .max(listChannelsQueryOffsetMax)
+        .default(listChannelsQueryOffsetDefault)
+        .describe("Items to skip. Defaults to 0; at most 10000."),
+    platform: zod.string().optional(),
+    active: zod.boolean().optional().describe("Return only channels that are enabled"),
+});
+/**
+ * Which side owns the webhook secret is decided by the platform; see secretSource on list-platforms. For a `generated` platform, do not send webhookSecret — the one we generate is returned exactly once in this response and cannot be retrieved again; miss it and the only way forward is rotating to a new one. For a `supplied` platform you must pass the secret from that platform's own console, and webhookSecret in the response is null.
+ * @summary Create a channel
+ */
+export const CreateChannelBody = CreateChannelRequestBody;
+/**
+ * @summary Get a channel
+ */
+export const GetChannelParams = zod.strictObject({
+    channel: zod.uuid(),
+});
+/**
+ * Only the fields present are changed. senderPolicy and allowFrom go together, and senderPolicy decides whether they are replaced. For platforms held open by a long-lived connection the change applies once that connection is rebuilt; for webhook platforms it applies at once.
+ * @summary Update a channel
+ */
+export const UpdateChannelParams = zod.strictObject({
+    channel: zod.uuid(),
+});
+export const UpdateChannelBody = UpdateChannelRequestBody;
+/**
+ * The channel stops accepting inbound messages and every binding on it stops working. This operation remains available while the project is suspended or being cleaned up.
+ * @summary Delete a channel
+ */
+export const DeleteChannelParams = zod.strictObject({
+    channel: zod.uuid(),
+});
+/**
+ * Produces a single-use code to hand to the person being bound. They send that code to the assistant from their own account on that platform, which completes the binding. A binding can only be established this way, by the person themselves — a platform account cannot be named directly. Codes expire and have to be reissued.
+ * @summary Issue a binding code
+ */
+export const CreateBindingCodeParams = zod.strictObject({
+    channel: zod.uuid(),
+});
+/**
+ * For diagnosing "I sent a message and the assistant never answered". Returns the inbound messages this channel rejected most recently, newest first, each with its reason. The most common reason is that the sender is not bound yet.
+ * @summary List recently rejected inbound messages
+ */
+export const ListChannelRejectionsParams = zod.strictObject({
+    channel: zod.uuid(),
+});
+export const listChannelRejectionsQueryLimitDefault = 50;
+export const listChannelRejectionsQueryLimitMin = 0;
+export const listChannelRejectionsQueryLimitMax = 100;
+export const ListChannelRejectionsQueryParams = zod.strictObject({
+    limit: zod
+        .int()
+        .min(listChannelRejectionsQueryLimitMin)
+        .max(listChannelRejectionsQueryLimitMax)
+        .default(listChannelRejectionsQueryLimitDefault),
+});
+/**
+ * Replaces the webhook secret. The old one stops working immediately and the channel drops back to awaiting confirmation from the platform. Which side owns the secret is decided by the platform; see secretSource on list-platforms. For a `generated` platform, send no body — the new secret is returned in this response only and cannot be retrieved again. For a `supplied` platform you must pass the new secret from that platform's own console.
+ * @summary Rotate the webhook secret
+ */
+export const RotateChannelSecretParams = zod.strictObject({
+    channel: zod.uuid(),
+});
+export const RotateChannelSecretBody = RotateSecretRequestBody;
+/**
+ * For checking a sender policy after changing it. Sends nothing and changes nothing: it runs exactly the same decision a real inbound message goes through, and says which rule produced the answer. The binding-code rule cannot be tested this way — whether something is a binding code depends on what the sender actually wrote.
+ * @summary Test whether a sender would be let through
+ */
+export const CheckSenderParams = zod.strictObject({
+    channel: zod.uuid(),
+});
+export const CheckSenderQueryParams = zod.strictObject({
+    peerId: zod
+        .string()
+        .describe("That person's id on the platform, the same value that appears in bindings and rejections"),
+    username: zod
+        .string()
+        .optional()
+        .describe("Only platforms with usernames, such as Telegram, can supply this. Without the @. Leave it empty to mean there is no username"),
+});
+/**
+ * A personal WeChat channel can only send and receive once its owner has signed in by scanning a QR code. This returns that code; poll `GET /v1/weixin-logins/{login}` for progress, and when the status asks for a verification code, submit it with `POST /v1/weixin-logins/{login}/verify-code`.
+ * @summary Begin a WeChat QR login
+ */
+export const BeginWeixinLoginParams = zod.strictObject({
+    channel: zod.uuid(),
+});
+/**
+ * Poll this until the status is success or failure. When the status asks for a verification code, submit it with the verification-code operation.
+ * @summary Get the state of a QR login
+ */
+export const GetWeixinLoginParams = zod.strictObject({
+    login: zod.uuid(),
+});
+/**
+ * For when WeChat asks for an SMS or device code after the scan. The person who started the login gets that code on their own phone.
+ * @summary Submit a login verification code
+ */
+export const SubmitWeixinVerifyCodeParams = zod.strictObject({
+    login: zod.uuid(),
+});
+export const SubmitWeixinVerifyCodeBody = VerifyCodeRequestBody;
+/**
+ * The assistant asks the client to run an action by adding a tool call to the conversation
+ * with the namespace `dynamic`; the client acts when that entry turns in_progress and reports
+ * back here.
+ *
+ * The first result is the one that counts. A later one is refused rather than replacing it.
+ * @summary Report what an action produced
+ */
+export const SubmitDynamicCallResultParams = zod.strictObject({
+    call: zod.string().describe("The id of the tool call entry in the conversation."),
+});
+export const SubmitDynamicCallResultBody = DynamicCallResultRequestBody;
+/**
+ * A folder groups conversations in the sidebar and does nothing else. The assistant is never told which folder a conversation is in, and a conversation behaves exactly the same inside one as outside: no shared instructions, no shared files, no shared memory.
+ *
+ * Names are unique within an account's folders in this project, because the only way to aim at a folder is to read its name.
+ * @summary Create a folder
+ */
+export const CreateFolderBody = CreateFolderRequestBody;
+/**
+ * The list returns every folder at once, so this is for the case the list does not cover: a page opened straight at a folder, holding nothing but the id from the address bar. Its conversations are a separate request — `GET /api/v1/threads?folder=<id>`.
+ * @summary Fetch one folder
+ */
+export const GetFolderParams = zod.strictObject({
+    folder: zod.string(),
+});
+/**
+ * The conversations in it are untouched, and none of them move in the list — a folder's name is not part of what any conversation is about.
+ * @summary Rename a folder
+ */
+export const UpdateFolderParams = zod.strictObject({
+    folder: zod.string(),
+});
+export const UpdateFolderBody = UpdateFolderRequestBody;
+/**
+ * The conversations inside are **not** deleted. They leave the folder and go back to the ungrouped list, where they can be filed again. Emptying a shelf is not the same as throwing out what was on it, and deleting a conversation is a different request.
+ *
+ * Idempotent: deleting a folder that is already gone succeeds and changes nothing.
+ * @summary Delete a folder
+ */
+export const DeleteFolderParams = zod.strictObject({
+    folder: zod.string(),
+});
+/**
+ * The assistant stops remembering this. It takes effect at once, so the next conversation will not carry it. The assistant may well learn the same thing again.
+ * @summary Delete one memory
+ */
+export const DeleteMemoryParams = zod.strictObject({
+    memory: zod.string(),
+});
+/**
+ * Creates it, or replaces the project's skill of that name. The whole package goes in each
+ * time: files left out of a write are removed, so the stored skill is what was sent and not
+ * what accumulated.
+ *
+ * A project skill takes precedence over a built-in one of the same name for this project only.
+ * The built-in is untouched and reappears if the project's is deleted.
+ * @summary Write a skill for this project
+ */
+export const PutSkillBody = SkillRequestBody;
+/**
+ * Works for built-in skills too; they simply cannot be written.
+ * @summary Read one skill, with its files
+ */
+export const GetSkillParams = zod.strictObject({
+    skill: zod.string().describe("The skill's name, as `list-skills` returned it."),
+});
+/**
+ * Separate from writing it, because this is the frequent one: a skill that is off costs
+ * nothing and stays where it is.
+ *
+ * Only skills belonging to the project can be switched. To keep a built-in one out of the
+ * way, write a project skill of the same name and turn that off.
+ * @summary Turn a skill on or off
+ */
+export const SetSkillEnabledParams = zod.strictObject({
+    skill: zod.string(),
+});
+export const SetSkillEnabledBody = SkillEnabledRequestBody;
+/**
+ * A built-in skill of the same name, if there was one, becomes visible again.
+ * @summary Delete this project's skill
+ */
+export const DeleteSkillParams = zod.strictObject({
+    skill: zod.string(),
+});
+/**
+ * Ordered by most recent activity, limited to the current account's conversations in the current project. `archived` selects between two sets rather than widening one: archived conversations are absent from the default list, and turning the flag on shows those instead.
+ *
+ * Pass the returned nextCursor as cursor; omit cursor on the first page. Continue with the same q, archived and folder filters. The cursor marks a position in the activity order, so changing filters between pages does not continue the same list.
+ * @summary List conversations
+ */
+export const listThreadsQueryQMax = 100;
+export const listThreadsQueryFolderMax = 64;
+export const listThreadsQueryCursorMax = 1024;
+export const listThreadsQueryLimitDefault = 50;
+export const listThreadsQueryLimitMax = 200;
+export const ListThreadsQueryParams = zod.strictObject({
+    q: zod
+        .string()
+        .max(listThreadsQueryQMax)
+        .optional()
+        .describe("Search titles, case-insensitively. Leave it empty for the most recent conversations"),
+    archived: zod
+        .boolean()
+        .optional()
+        .describe("When true, returns **only** archived conversations; otherwise only unarchived ones"),
+    folder: zod
+        .string()
+        .max(listThreadsQueryFolderMax)
+        .optional()
+        .describe('Narrow the list to one folder. Omitting it returns conversations from every folder and from none; a folder id returns that folder\'s; the empty value (`?folder=`) returns the ones that are in no folder at all. Empty is not the same as omitted, and a sidebar needs both: "chats" is exactly the ungrouped set, and asking for everything would let filed conversations crowd it out of the limit.'),
+    cursor: zod
+        .string()
+        .min(1)
+        .max(listThreadsQueryCursorMax)
+        .optional()
+        .describe("The next_cursor returned by the previous page. Omit it for the first page."),
+    limit: zod
+        .int()
+        .min(1)
+        .max(listThreadsQueryLimitMax)
+        .default(listThreadsQueryLimitDefault)
+        .describe("Items returned in this page. Defaults to 50; at most 200."),
+});
+/**
+ * Omit preferredModelId or set it to null to follow the platform default. A non-null preference is accepted only while model selection is enabled; otherwise the request fails with 403 and code MODEL_SELECTION_DISABLED.
+ *
+ * A well-formed preference for a Canopy model that is no longer allowed or has been retired or removed is retained and uses the default when a turn starts. This also handles a catalogue change between displaying the selector and submitting the choice. Creating a conversation does not contact a model provider and remains possible when generation is unavailable.
+ * @summary Create a conversation
+ */
+export const CreateThreadBody = CreateThreadRequestBody;
+/**
+ * The complete current state of a conversation, for the first render. Its `stream` gives the address and admission ticket for live output, and what that stream pushes are incremental edits to this same document, so the same rendering logic applies.
+ * @summary Fetch the conversation document
+ */
+export const GetThreadParams = zod.strictObject({
+    thread: zod.string(),
+});
+/**
+ * Changes the title, folder, approval mode, model preference, and whether the conversation is archived. Approval and model preference changes take effect from the next turn; a turn already running keeps the settings it started with.
+ *
+ * Omit preferredModelId to leave the preference unchanged, or set it to null to follow the platform default. A non-null preference is accepted only while model selection is enabled; otherwise the whole request fails with 403 and code MODEL_SELECTION_DISABLED and none of its fields are changed. Clearing a preference remains allowed while selection is disabled. A well-formed preference for a disallowed, retired or removed Canopy model is retained and falls back to the default when used.
+ *
+ * Model switching is allowed on an existing conversation, including while a turn is generating or waiting for approval or an answer. The response immediately returns the saved preferredModelId, while model continues to identify the running turn's effective model until it finishes. Messages queued into that running turn also keep its captured model choices. The next turn uses the latest saved preference.
+ *
+ * Changing the preference does not create a new conversation, start a turn, call a model provider, clear the transcript, or rewrite historical model attribution. Before the next turn sends its first request to the selected model, the service checks that model's input capabilities and usable context budget. A switch to a smaller window may require compaction under the compaction policy above; saving the preference alone does not establish that the conversation fits.
+ *
+ * Archiving makes a conversation read-only: it stays in the list under "archived", stays readable, and the assistant can still find it when it searches past conversations — it just takes no new input. Unarchive it to continue. Archiving fails while a turn is running; stop it first.
+ * @summary Update conversation settings
+ */
+export const UpdateThreadParams = zod.strictObject({
+    thread: zod.string(),
+});
+export const UpdateThreadBody = UpdateThreadRequestBody;
+/**
+ * Removes the conversation from every list and makes it unreachable by id. The assistant can no longer find it either — neither by searching past conversations nor by reading one back.
+ *
+ * Deleting is not the same as archiving, and the two are not degrees of the same thing. An archived conversation is still there and still readable, it just takes no new input; a deleted one is gone from view. Archiving can be undone; this cannot.
+ *
+ * What survives is the record itself, because a conversation with this assistant is an account of what was done to real infrastructure — which machine was changed, which disk was removed. That record is kept even though nobody can reach it here.
+ *
+ * Fails while a turn is running: stop it first. Deleting an already deleted conversation succeeds and changes nothing.
+ * @summary Delete a conversation
+ */
+export const DeleteThreadParams = zod.strictObject({
+    thread: zod.string(),
+});
+/**
+ * The batch id comes from the conversation document's `wait`. This is idempotent: submitting the same batch again neither changes a decision already in effect nor reports an error. Returns 404 when the batch does not belong to that conversation.
+ * @summary Approve or decline a batch of tool calls
+ */
+export const DecideApprovalParams = zod.strictObject({
+    thread: zod.string(),
+    batch: zod.string(),
+});
+export const DecideApprovalBody = DecideRequestBody;
+/**
+ * The first render only carries the latest stretch of a conversation; anything above it is fetched here, one stretch at a time. Pass the document's earlier.before as `before`; the `earlier` in the response is the cursor for the stretch above that, and null means the top has been reached. The entries have the same shape and the same order (oldest first) as `items` in the document, so they can be prepended as they are.
+ * @summary Fetch earlier parts of a conversation
+ */
+export const ListEarlierItemsParams = zod.strictObject({
+    thread: zod.string(),
+});
+export const listEarlierItemsQueryBeforeMin = 0;
+export const ListEarlierItemsQueryParams = zod.strictObject({
+    before: zod
+        .int()
+        .min(listEarlierItemsQueryBeforeMin)
+        .describe("From the document's earlier.before; returns entries before this ordinal"),
+});
+/**
+ * Calling this on a conversation with no running turn also returns 204 rather than an error — the user pressing stop races with the turn finishing on its own, and both outcomes are the same. This operation remains available while the project is suspended or being cleaned up.
+ * @summary Interrupt a running turn
+ */
+export const InterruptThreadParams = zod.strictObject({
+    thread: zod.string(),
+});
+/**
+ * Returns a turnId immediately without waiting for execution — a turn can run for tens of minutes. Progress arrives on the live stream the conversation document's `stream` points at, not in this response. Sending while the assistant is still working is allowed: the message is put in line and `queued` comes back true, to be read at the next step of the turn already running — so the editor should stay open rather than blocking on a busy conversation.
+ * @summary Send a message and start a turn
+ */
+export const SendMessageParams = zod.strictObject({
+    thread: zod.string(),
+});
+export const SendMessageBody = SendMessageRequestBody;
+/**
+ * The question id comes from the conversation document's `wait`. An already-answered question also returns 204 — another tab may have submitted first, or the auto-answer window may have expired, and in both cases the turn has already continued with an answer.
+ * @summary Answer the assistant's questions
+ */
+export const AnswerQuestionParams = zod.strictObject({
+    thread: zod.string(),
+    item: zod.string(),
+});
+export const AnswerQuestionBody = AnswerRequestBody;
+/**
+ * @summary Mark a conversation as read
+ */
+export const MarkThreadReadParams = zod.strictObject({
+    thread: zod.string(),
+});
+/**
+ * Reverts the entry at `ordinal` and everything after it. Reverted entries stay in the transcript marked `reverted`, and ordinals are not renumbered. Returns how many were actually reverted.
+ * @summary Revert from a given point
+ */
+export const RevertThreadParams = zod.strictObject({
+    thread: zod.string(),
+});
+export const RevertThreadBody = RevertRequestBody;

package/dist/assistant/v1/generated/validators/answerRequestBody.zod.d.ts

@@ -0,0 +1,54 @@
+/**
+ * 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 * as zod from "zod";
+export declare const AnswerRequestBody: zod.ZodObject<{
+    answers: zod.ZodRecord<zod.ZodString, zod.ZodString>;
+}, zod.z.core.$strict>;
+export type AnswerRequestBody = zod.input<typeof AnswerRequestBody>;
+export type AnswerRequestBodyOutput = zod.output<typeof AnswerRequestBody>;

package/dist/assistant/v1/generated/validators/answerRequestBody.zod.js

@@ -0,0 +1,54 @@
+/**
+ * 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 * as zod from "zod";
+export const AnswerRequestBody = zod.strictObject({
+    answers: zod
+        .record(zod.string(), zod.string())
+        .describe("A map from question id to the answer chosen"),
+});