@toloka-platform/sdk 0.16.0 → 0.17.1

package/dist/cli/toloka.js.jsc.sha256

@@ -1 +1 @@
-d657cb43672cd6deb574d75ed2a1c7b4a14d36d5b02a833d118bb0cd8d6634e7  toloka.js.jsc
+a7a6b3868d2f0f14340b150ed0d9efedb8278c047f82f0afff0243fd9fe9046a  toloka.js.jsc

package/dist/cli/toloka.js.sha256

@@ -1 +1 @@
-59d0e496f8f496fc0fe031360beb5ee033d0eff186c7004914a659d904483cf6  toloka.js
+7d9c82a638b5ff48a9896b460a80a1b63b1aeda82890520f735f248ad5403422  toloka.js

package/docs/cli.md

@@ -343,7 +343,7 @@ toloka pipeline run [name] [--wait] [--timeout <ms>]
 toloka pipeline status [name]
 toloka pipeline runs [name] [--limit <n>]
 toloka pipeline cost [name] [--item-limit <n>]
-toloka pipeline cancel <runId>
+toloka pipeline cancel <runId> [--accept-without-review]
 toloka pipeline results <runId> [--limit <n>] [--failed]
 ```
 

package/openapi/gen/api.schemas.ts

@@ -3865,6 +3865,11 @@ export type ListPipelineRuns200 = {
   pagination: Pagination;
 };
 
+export type CancelPipelineRunBodyPendingHumanQa = 'accept_without_review' | 'wait_for_review';
+export type CancelPipelineRunBody = {
+  pendingHumanQa?: CancelPipelineRunBodyPendingHumanQa;
+};
+
 export type SampleDatasetItemsBody = {
   markField: string;
   markValue: string;

package/openapi/gen/api.ts

@@ -6,6 +6,7 @@ import type {
   BaseModelId,
   BatchInferenceRun,
   BatchInferenceRunId,
+  CancelPipelineRunBody,
   CheckJob,
   CheckRunId,
   CopyPipelineBody,
@@ -1702,14 +1703,29 @@ export const getCancelPipelineRunUrl = (runId: RunId,) => {
   return `/api/v2-beta/runs/${runId}/cancel`
 }
 
-export const cancelPipelineRun = async (runId: RunId, options?: Parameters<typeof potatoFetch>[1]): Promise<RunJob> => {
+export const cancelPipelineRun = async (runId: RunId,
+    cancelPipelineRunBody: CancelPipelineRunBody, options?: Parameters<typeof potatoFetch>[1]): Promise<RunJob> => {
 
-  return potatoFetch<RunJob>(getCancelPipelineRunUrl(runId),
+    const getHeaders = (h?: NonNullable<RequestInit['headers']>): Record<string, string | readonly string[]> => {
+    if (!h) return {};
+    if (h instanceof Headers) return Object.fromEntries(h.entries());
+    if (Symbol.iterator in h) {
+      return Object.fromEntries(
+        Array.from(h as Iterable<Iterable<string>>, (entry) => Array.from(entry) as [string, string]),
+      );
+    }
+    const headers: Record<string, string | readonly string[]> = {};
+    for (const [name, value] of Object.entries<string | readonly string[] | undefined>(h)) {
+      if (value !== undefined) headers[name] = value;
+    }
+    return headers;
+  };
+return potatoFetch<RunJob>(getCancelPipelineRunUrl(runId),
   {
     ...options,
-    method: 'POST'
-
-
+    method: 'POST',
+    headers: { 'Content-Type': 'application/json', ...getHeaders(options?.headers) },
+    body: JSON.stringify(cancelPipelineRunBody)
   }
 );}
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@toloka-platform/sdk",
-  "version": "0.16.0",
+  "version": "0.17.1",
   "private": false,
   "description": "Build, inspect, and operate Toloka pipeline projects as TypeScript source. The public API may change between minor versions before 1.0.",
   "license": "Apache-2.0",
@@ -77,6 +77,6 @@
     "bun": ">=1.4.0"
   },
   "tolokaBuild": {
-    "commit": "1b8cbf8c1fd6ce6a32b5c8de98a7772fdcc3afe3"
+    "commit": "df3f866a1ee20326bfdb49cd547690d352447b1d"
   }
 }

package/skills/catalog.json

@@ -11,8 +11,8 @@
         "testing",
         "checks"
       ],
-      "version": "0.16.0",
-      "digest": "d029c12c76c569ad6ed9f12713890344e82c35445ba0f310d3aa2adf6f0610a5",
+      "version": "0.17.1",
+      "digest": "4636c4e21c9fc07a4cb402279574b88d54f7ee2db1e4cc8798c3ef9aeccea70c",
       "files": [
         "SKILL.md",
         "references/human-work.md",
@@ -33,7 +33,7 @@
         "bug",
         "report"
       ],
-      "version": "0.16.0",
+      "version": "0.17.1",
       "digest": "70f0bd2c80b32f87896aeb27c363b8a2d37f40e22424f57fe1aad142e125ad67",
       "files": [
         "SKILL.md",
@@ -50,7 +50,7 @@
         "getting-started",
         "agent"
       ],
-      "version": "0.16.0",
+      "version": "0.17.1",
       "digest": "2278adeb46a792356579395fcf73c42322cb23bcd0c61e20856ccabdad6762d1",
       "files": [
         "SKILL.md"
@@ -67,7 +67,7 @@
         "sft",
         "models"
       ],
-      "version": "0.16.0",
+      "version": "0.17.1",
       "digest": "3ce10dee5d3c283d8b5fdea15134a58fc738c7af2c1bb19eb5a0bf70ea0bca13",
       "files": [
         "SKILL.md"
@@ -84,7 +84,7 @@
         "prompt",
         "models"
       ],
-      "version": "0.16.0",
+      "version": "0.17.1",
       "digest": "be8bce8d9cf7241ccb60d2b2a9b7cc07d7755a76e8ff8ec1b0847c49efbb3469",
       "files": [
         "SKILL.md"

package/skills/toloka-build/references/human-work.md

@@ -49,7 +49,7 @@ Write at least one criterion for every output entity. Each criterion needs an au
 
 Use `llmQaInstruction` only when the evaluator needs a specific verification method, authoritative source, tool, or pinned edge case beyond the thresholds. It is evaluator guidance, not labeler guidance, and has no effect in `human_only` mode.
 
-Default QA is `qualityAssurance: { qaMode: 'llm_only' }`. Keep it when it fits the task. `hybrid` adds sampled Human QA while retaining LLM review; `human_only` is appropriate when LLM grading is prohibited or human review alone is required. Recommend a mode based on the user's quality and privacy requirements, explaining cost and turnaround implications before changing it. Human-bearing modes require `humanQaTimeForTask` in whole seconds: at least 30 and at least 3 per quality criterion of the node, whichever is larger, and at most 359,999 (99:59:59). A reviewer keeps a Human QA task for `humanQaTimeForTask` plus 1 hour, and for at least 8 hours. A dropped task stays with that reviewer until this time ends, then another reviewer can take it; `smartSamplingPercent` defaults to 30 for hybrid and 100 for human-only. Use those defaults unless the task justifies a different rate. Human QA on a node is capped at the node's expected review count from the frozen estimate, which uses the items the estimate expects at that node. Behind a `match`, the estimate assumes an even split across branches, so a branch that receives more items reaches the cap early and its later items skip Human QA; say so in the cost forecast when branch volumes are known to be uneven. Before deploy, the platform counts the QA pool: experts who match the node's audience and hold the platform QA qualification and were active in the last 14 days, or have recent QA experience (at least 1 completed QA task and a recent visit; Smart Search invites these at deploy, except on a node that reuses an earlier audience or keeps its workforce request closed). The data is rebuilt once a day. With none, validation returns a blocking error and the deploy is rejected. The reviewers come from the node's own audience, because a node has no separate reviewer audience. So for that error, offer to widen the audience (drop specializations first, then countries) or to switch to `llm_only`; do not suggest waiting, because the count is refreshed once a day and nothing shows whether more reviewers will become active. When the count is too small for the node's expected reviews (the platform assumes that 1 of 10 of these experts reviews, for up to 12 hours each), `toloka validate` returns a `severity: 'warning'` issue on the node whose message starts with `Human QA on "<node name>" may stall`. The warning does not block the deploy. Tell the user the numbers in the message and offer its remedies: widen the audience or switch to `llm_only` (or to `hybrid` when the node is `human_only`); change none of them without the user's approval. A node that reuses the human reviewers of an earlier deployment skips this count. QA mode applies to the whole node, not individual criteria. The redo cap is platform-controlled and is not an SDK setting.
+Default QA is `qualityAssurance: { qaMode: 'llm_only' }`. Keep it when it fits the task. `hybrid` adds sampled Human QA while retaining LLM review; `human_only` is appropriate when LLM grading is prohibited or human review alone is required. Recommend a mode based on the user's quality and privacy requirements, explaining cost and turnaround implications before changing it. Human-bearing modes require `humanQaTimeForTask` in whole seconds: at least 30 and at least 3 per quality criterion of the node, whichever is larger, and at most 359,999 (99:59:59). A reviewer keeps a Human QA task for `humanQaTimeForTask` plus 1 hour, and for at least 8 hours. A dropped task stays with that reviewer until this time ends, then another reviewer can take it; `smartSamplingPercent` defaults to 30 for hybrid and 100 for human-only. Use those defaults unless the task justifies a different rate. Human QA on a node is capped at the Maximum of its Human QA line in the frozen estimate: 3 reviews for each item of the run. The cap counts every item of the run, so a branch behind a `match` that receives more than its even share still gets Human QA. Before deploy, the platform counts the QA pool: experts who match the node's audience and hold the platform QA qualification and were active in the last 14 days, or have recent QA experience (at least 1 completed QA task and a recent visit; Smart Search invites these at deploy, except on a node that reuses an earlier audience or keeps its workforce request closed). The data is rebuilt once a day. With none, validation returns a blocking error and the deploy is rejected. The reviewers come from the node's own audience, because a node has no separate reviewer audience. So for that error, offer to widen the audience (drop specializations first, then countries) or to switch to `llm_only`; do not suggest waiting, because the count is refreshed once a day and nothing shows whether more reviewers will become active. When the count is too small for the node's expected reviews (the platform assumes that 1 of 10 of these experts reviews, for up to 12 hours each), `toloka validate` returns a `severity: 'warning'` issue on the node whose message starts with `Human QA on "<node name>" may stall`. The warning does not block the deploy. Tell the user the numbers in the message and offer its remedies: widen the audience or switch to `llm_only` (or to `hybrid` when the node is `human_only`); change none of them without the user's approval. A node that reuses the human reviewers of an earlier deployment skips this count. QA mode applies to the whole node, not individual criteria. The redo cap is platform-controlled and is not an SDK setting.
 
 The platform also writes annotator fields on human-expert generation nodes. `<snake_cased node name>_annotator_id` is an optional string: the ID of the expert whose answer was accepted, not of earlier rejected attempts. `<snake_cased node name>_qa_annotator_id` exists only in `human_only` and `hybrid` modes: the ID of the expert who made the last human review decision, missing when sampling skipped human review. Both are missing on canceled items and on items completed before they existed; synthetic nodes have neither. The platform also writes one `*_evaluation_result` field per quality criterion with LLM or Human QA verdicts, `<snake_cased node name>_qa_metadata`, and, on a synthetic node with LLM QA, `<snake_cased node name>_evaluation_summary`. Never declare any of these with `field()`: the platform owns them, and an authored field with that name collides with it. Read them from the dataset with `toloka dataset load`.
 

package/skills/toloka-build/references/workflow-and-cli.md

@@ -42,7 +42,7 @@ Run `toloka --help` and `toloka <command> --help` for the exact commands and opt
 
 `toloka generation-model list` prints the synthetic generation models: `ID`, `NAME`, the supported `REASONING EFFORT` values with the default marked, and the `TYPICAL`, `MIN` and `MAX` cost of one attempt, followed by `Default model:` and, when there are any, `Recommended:` lines (`--json` adds descriptions). Run it before configuring a synthetic node.
 
-`toloka pipeline cost [name] [--item-limit <n>]` forecasts what a run of a live, validated pipeline would bill. It does not start a run or change the graph. If any billed node is marked `skipped`, the displayed total is incomplete and must not be presented as the pipeline price. Compute and label a labor floor for each skipped billed node as `items × pricePerTask × annotations per item`, using `1` for generation and `overlap` for quorum. Also report `maxEntities`, quality-criteria count, and only exclusions applicable to the authored QA and workflow. Apply accepting a rate does not prove its final billed value. If the output lists warnings, include them when you present the forecast.
+`toloka pipeline cost [name] [--item-limit <n>]` forecasts what a run of a live, validated pipeline would bill. It does not start a run or change the graph. If any billed node is marked `skipped`, the displayed total is incomplete and must not be presented as the pipeline price. Compute and label a labor floor for each skipped billed node as `items × pricePerTask × annotations per item`, using `1` for generation and `overlap` for quorum. Also report `maxEntities`, quality-criteria count, and only exclusions applicable to the authored QA and workflow. Apply accepting a rate does not prove its final billed value.
 
 ## Manage model checkpoints
 
@@ -162,9 +162,11 @@ toloka pipeline runs <name> --limit 10
 toloka pipeline status <name>
 toloka pipeline results <runId> --limit 50
 toloka pipeline results <runId> --failed
-toloka pipeline cancel <runId>
+toloka pipeline cancel <runId> [--accept-without-review]
 ```
 
+By default, `toloka pipeline cancel` keeps the items that wait for Human QA in Human QA, and they end with the review result; after 14 days on the node, they are accepted without review. Add `--accept-without-review` only when the user asks to end these items now without review; the user pays for them as for completed items.
+
 `toloka pipeline runs` lists ids and timestamps. `toloka pipeline status` reports the latest run. `toloka status` (no prefix) is project health. When a listing is capped it says so; report the cap rather than presenting a page as the whole picture.
 
 A failed item carries an error, so `toloka pipeline results <runId> --failed` is the fastest path to why a run failed. Report counts and states from that output rather than inferring them from the run having started.

package/src/cli/commands/pipeline.ts

@@ -131,10 +131,18 @@ export const registerPipelineCommands = (program: Command, host: CommandHost): v
   pipeline
     .command("cancel")
     .argument("<runId>", "run to cancel")
+    .option(
+      "--accept-without-review",
+      "accept items in Human QA without review now; you pay for them as for completed items",
+      false,
+    )
     .description("request cancellation of a run")
-    .action(async (runId: string) => {
+    .action(async (runId: string, options: { acceptWithoutReview: boolean }) => {
       const { client } = await resolveContext(globals(), context);
-      const result = await cancelPipelineRun(client, { runId });
+      const result = await cancelPipelineRun(client, {
+        runId,
+        acceptWithoutReview: options.acceptWithoutReview,
+      });
       context.io.stdout(result.output);
     });
   pipeline

package/src/cli/cost.ts

@@ -56,10 +56,9 @@ const collectLineRows = (line: CostLine, depth: number): TableRow[] => {
 
 const collectNodeRows = (
   nodes: PipelineCostEstimate["nodes"],
-): { billed: TableRow[]; unpriced: string[]; warnings: string[] } => {
+): { billed: TableRow[]; unpriced: string[] } => {
   const billed: TableRow[] = [];
   const unpriced: string[] = [];
-  const warnings: string[] = [];
 
   for (const node of nodes) {
     if (node.kind === "priced") {
@@ -67,7 +66,6 @@ const collectNodeRows = (
       for (const line of node.displayBreakdown) {
         if (isCostLine(line)) billed.push(...collectLineRows(line, 1));
       }
-      if (node.warning !== undefined) warnings.push(`  ${node.nodeNameDisplay}: ${node.warning}`);
       continue;
     }
 
@@ -78,7 +76,7 @@ const collectNodeRows = (
     );
   }
 
-  return { billed, unpriced, warnings };
+  return { billed, unpriced };
 };
 
 const collectTotalRows = (total: PipelineCostEstimate["total"]): TableRow[] => {
@@ -102,7 +100,7 @@ export const formatCostEstimate = (
   estimate: PipelineCostEstimate,
   pipelineName: string,
 ): string => {
-  const { billed, unpriced, warnings } = collectNodeRows(estimate.nodes);
+  const { billed, unpriced } = collectNodeRows(estimate.nodes);
   const totals = collectTotalRows(estimate.total);
   const table = formatTable([["Item", "Expected", "Maximum"], ...billed, ...totals]);
   const billedRows = table.slice(0, 1 + billed.length);
@@ -124,10 +122,6 @@ export const formatCostEstimate = (
     output.push("", "Not billed", ...unpriced);
   }
 
-  if (warnings.length > 0) {
-    output.push("", "Warnings", ...warnings);
-  }
-
   if (estimate.isInternalPricing === true) {
     output.push("", "Internal-team pricing.");
   }

package/src/cli/runs.ts

@@ -520,9 +520,12 @@ export async function pipelineRunStatus(
 
 export async function cancelPipelineRun(
   client: PotatoClient,
-  options: { readonly runId: string },
+  options: { readonly runId: string; readonly acceptWithoutReview: boolean },
 ): Promise<RunCommandResult> {
-  const canceled = await client.runs.cancel({ runId: options.runId });
+  const canceled = await client.runs.cancel({
+    runId: options.runId,
+    pendingHumanQa: options.acceptWithoutReview ? "accept_without_review" : undefined,
+  });
 
   return {
     outcome: "canceled",

package/src/client.ts

@@ -5,6 +5,7 @@ import type {
   AddDatasetItemsBody,
   AttachPipelineDatasetBody,
   BatchInferenceRun as GeneratedBatchInferenceRun,
+  CancelPipelineRunBody,
   CheckJob as GeneratedCheckJob,
   CopyPipelineBody,
   CreateBatchInferenceRunBody,
@@ -734,7 +735,8 @@ const createClientImplementation = (config: ClientConfig) => {
     start: ({ pipelineId }: { pipelineId: PipelineId }) =>
       wire.createPipelineRun(pipelineId, requestOptions),
     get: ({ runId }: { runId: RunId }) => wire.getPipelineRun(runId, requestOptions),
-    cancel: ({ runId }: { runId: RunId }) => wire.cancelPipelineRun(runId, requestOptions),
+    cancel: ({ runId, ...body }: { runId: RunId } & CancelPipelineRunBody) =>
+      wire.cancelPipelineRun(runId, body, requestOptions),
     listPage: ({ pipelineId, ...params }: { pipelineId: PipelineId } & ListPipelineRunsParams) =>
       wire.listPipelineRuns(pipelineId, params, requestOptions),
     listAll: ({ pipelineId, ...params }: { pipelineId: PipelineId } & ListPipelineRunsParams) =>