@toloka-platform/sdk 0.15.0 → 0.16.0

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

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

package/dist/cli/toloka.js.sha256

@@ -1 +1 @@
-c42abdb877c4bca4d85c8d2faf266f640cbcf0b283d725482d1da3dfc753487f  toloka.js
+59d0e496f8f496fc0fe031360beb5ee033d0eff186c7004914a659d904483cf6  toloka.js

package/docs/cli.md

@@ -286,7 +286,7 @@ toloka validate [--wait]
 
 It prints one line per pipeline with its status, then its issues: `valid`; `invalid`; `checks-pending` when only check state is open, such as a stored test case or a lint that has not run on this graph; `checks-running` when `--wait` gave up on running checks; or `skipped` when the pipeline or its dataset is not on the platform yet. A `note:` line explains what to do next when `--wait` could not finish. Exits `1` when any submitted graph is invalid or its checks were still running at the `--wait` deadline.
 
-The platform lints a pipeline a few seconds after every apply. While a lint or a check is running, or a lint is about to start after an apply, validate lists it as `running running_node_check`; a lint that has not run on this graph and is no longer expected to start is `pending not_ran_node_check`, and the user runs it from the node's Checks tab. `--wait` validates again every 5 seconds until nothing is running, for up to 5 minutes, then prints the final report; a pipeline whose source differs from the applied graph is not waited on, because its lints start only after `toloka apply`. Right after an apply, plain `toloka validate` can print `valid` and exit `0` while lints are still running, so run `toloka validate --wait` before treating an applied pipeline as valid.
+The platform lints a pipeline a few seconds after every apply. While a lint or a check is running, or a lint is about to start after an apply, validate lists it as `running running_node_check`; a lint that has not run on this graph and is no longer expected to start is `pending not_ran_node_check`; start it with `toloka pipeline lint`. `--wait` validates again every 5 seconds until nothing is running, for up to 5 minutes, then prints the final report; a pipeline whose source differs from the applied graph is not waited on, because its lints start only after `toloka apply`. Right after an apply, plain `toloka validate` can print `valid` and exit `0` while lints are still running, so run `toloka validate --wait` before treating an applied pipeline as valid.
 
 ## check
 
@@ -338,6 +338,7 @@ Operate on a live pipeline in the selected project. Name or id is required unles
 
 ```sh
 toloka pipeline list [--limit <n>]
+toloka pipeline lint [name] [--wait] [--timeout <ms>]
 toloka pipeline run [name] [--wait] [--timeout <ms>]
 toloka pipeline status [name]
 toloka pipeline runs [name] [--limit <n>]
@@ -350,6 +351,10 @@ toloka pipeline results <runId> [--limit <n>] [--failed]
 
 `pipeline run` without `--wait` prints `Started run <id> is <status> for <name>.` and a follow-up that uses the pipeline id. Exit code `0` means only that the run was accepted. With `--wait`, it prints `Run <id> succeeded.` or `Run <id> failed.` and sets the exit code accordingly; see [Exit codes](#exit-codes).
 
+The platform rejects a run until the built-in lints of every node on the path from Start to End have finished. Lints start a few seconds after every `apply`, but not when dataset items or their values change, and a lint that runs for more than 5 minutes or waits more than 15 minutes to start fails as timed out. `pipeline lint` starts every lint without a current result: one that has not run on the current graph and dataset items, or whose last run failed. It always runs the lints that check dataset contents again, because edits to item values do not invalidate their results. It leaves running lints and the other finished lints alone and prints one line per lint. With `--wait` it waits for them, 5 minutes by default; exit code `0` means every lint finished, `1` that one failed or could not start, and `2` that one was still running when the wait ended. Read the findings with `toloka validate`.
+
+`pipeline run` does the same before it starts a run, then waits only for the lints of nodes on the path from Start to End, up to 5 minutes or the `--timeout` you pass, which bounds the whole command including the wait for the run. When a lint is still running when that time is up, it prints the lints, starts nothing, and exits `2`. Otherwise it asks the platform to start the run, and the platform rejects it if a lint on a connected node failed.
+
 A run needs at least one dataset item that matches the root node's dataset and filter. Otherwise `pipeline run` fails with `No dataset items match, so a run would have nothing to process.` and starts nothing. `apply` and `validate` still succeed over an empty dataset, so upload items or widen the filter, then run again.
 
 `pipeline status` reports the latest run of that pipeline. `pipeline runs` lists recent runs (default 10). `pipeline cost` forecasts what a run would bill. `pipeline cancel` and `pipeline results` take a run id.
@@ -508,11 +513,13 @@ The catalog is bound to the installed CLI version, so a skill that a newer relea
 
 `toloka pipeline run --wait` maps the run outcome to the process exit code.
 
-| Code | `pipeline run --wait`                           | `check` / apply local gate                        |
-| ---- | ----------------------------------------------- | ------------------------------------------------- |
-| 0    | Run succeeded, or was accepted without `--wait` | All required local checks passed                  |
-| 1    | Run failed                                      | Source, types, tests, or required coverage failed |
-| 2    | Run remained active when the wait window closed | A required checker could not run                  |
+| Code | `pipeline run --wait`                                                                                   | `check` / apply local gate                        |
+| ---- | ------------------------------------------------------------------------------------------------------- | ------------------------------------------------- |
+| 0    | Run succeeded, or was accepted without `--wait`                                                         | All required local checks passed                  |
+| 1    | Run failed, or the platform refused to start it                                                        | Source, types, tests, or required coverage failed |
+| 2    | Run remained active when the wait window closed, or lints were still running and no run was started | A required checker could not run                  |
+
+The output tells the two exit-`2` cases apart: `Did not start a run of <name>: its lints are still running` means no run exists yet, so run `pipeline run` again later instead of polling `pipeline status`.
 
 Every other failure exits non-zero with a message on stderr: missing project identity, a rejected login, an unauthenticated `auth-status`, or a failed `secret set`.
 

package/docs/troubleshooting.md

@@ -79,7 +79,11 @@ If it lists no new run, retry. The same call has succeeded minutes later with no
 
 ## Exit code 2 from toloka pipeline run
 
-The timeout closed while the run was still in progress. That is not a failure of the run and not a failure of your pipeline. A queue with no one working it stays in progress indefinitely, so report what you observed — item counts and current states — rather than waiting unbounded:
+Read the output first: exit `2` has two causes.
+
+If it says `Did not start a run of <name>: its lints are still running`, no run was created. The platform rejects a run until the lints of the nodes on the path from Start to End have finished. Do not look for a run with `toloka pipeline status`: wait for the lints with `toloka pipeline lint <name> --wait`, then run `toloka pipeline run` again.
+
+Otherwise the timeout closed while the run was still in progress. That is not a failure of the run and not a failure of your pipeline. A queue with no one working it stays in progress indefinitely, so report what you observed — item counts and current states — rather than waiting unbounded:
 
 ```sh
 toloka pipeline status <name>

package/openapi/gen/api.schemas.ts

@@ -2323,6 +2323,18 @@ export interface RunItem {
   state: RunItemState;
 }
 
+export type RunLintsResultRejectedItem = {
+  nodeId: string;
+  checkId: string;
+  message: string;
+};
+
+export interface RunLintsResult {
+  checks: CheckJob[];
+  rejected: RunLintsResultRejectedItem[];
+  nodesInUse: string[];
+}
+
 export type BatchInferenceModel = {
   type: 'base_model';
   baseModelId: 'qwen3-4b' | 'qwen3-8b' | 'qwen3-32b' | 'qwen3-235b';

package/openapi/gen/api.ts

@@ -102,6 +102,7 @@ import type {
   RunItem,
   RunItemId,
   RunJob,
+  RunLintsResult,
   SampleDatasetItemsBody,
   SampleJob,
   SampleResult,
@@ -2521,6 +2522,27 @@ return potatoFetch<CheckJob>(getCreatePipelineCheckUrl(pipelineId),
 
 
 
+export const getRunPipelineLintsUrl = (pipelineId: PipelineId,) => {
+
+
+
+
+  return `/api/v2-beta/pipelines/${pipelineId}/lints`
+}
+
+export const runPipelineLints = async (pipelineId: PipelineId, options?: Parameters<typeof potatoFetch>[1]): Promise<RunLintsResult> => {
+
+  return potatoFetch<RunLintsResult>(getRunPipelineLintsUrl(pipelineId),
+  {
+    ...options,
+    method: 'POST'
+
+
+  }
+);}
+
+
+
 export const getGetPipelineCheckUrl = (checkRunId: CheckRunId,) => {
 
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@toloka-platform/sdk",
-  "version": "0.15.0",
+  "version": "0.16.0",
   "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": "292c25ce81e0c8520df4f62a4c38a57d11f09300"
+    "commit": "1b8cbf8c1fd6ce6a32b5c8de98a7772fdcc3afe3"
   }
 }

package/skills/catalog.json

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

package/skills/toloka-build/SKILL.md

@@ -87,12 +87,12 @@ Let constructors mint IDs for new declarations. Preserve `id` options generated
 | Status | Meaning |
 | --- | --- |
 | `valid` | No blocking error. Warnings are informational. |
-| `checks-pending` | The only remaining issues are stored test cases or lints that have not run on this graph (`not_ran_node_check`). The user runs them from the node's Checks tab; they do not replace a passing local gate. |
+| `checks-pending` | The only remaining issues are stored test cases or lints that have not run on this graph (`not_ran_node_check`). Run the lints with `toloka pipeline lint <name> --wait`; the user runs stored test cases from the node's Checks tab. Neither replaces a passing local gate. |
 | `invalid` | A source/spec error, a failed check (`failed_node_check`), or a lint error. Fix source/spec errors before plan or apply. Failed checks and lint errors do not block apply, so you can apply a fix for them and validate again, but a run cannot start until they are gone. |
 | `checks-running` | Only with `--wait`: a lint was still running when the wait ended. |
 | `skipped` | The pipeline or its dataset is not on the platform yet; `toloka apply` creates it. |
 
-The platform's lints, such as the Task UI interface lint and the quality-criteria lint, start by themselves a few seconds after every apply and take about a minute. Until they finish, plain `toloka validate` lists each as a `running_node_check` warning and can still print `valid` with exit 0, so it does not prove the lints passed. After applying a change, run `toloka validate --wait`: it validates again every 5 seconds, for up to 5 minutes, until no lint is running, and does not wait for a pipeline whose source has unapplied changes. Report the pipeline as valid only after that. When a reviewed plan adds a dataset field already bound by an existing live pipeline, pre-apply validation can report that exact field as missing; apply only the reviewed additive plan, then require post-apply validation to clear source/spec errors. Never rewrite valid source because a stored test case on the Checks tab has not run.
+The platform's lints, such as the Task UI interface lint and the quality-criteria lint, start by themselves a few seconds after every apply and take about a minute. Until they finish, plain `toloka validate` lists each as a `running_node_check` warning and can still print `valid` with exit 0, so it does not prove the lints passed. After applying a change, run `toloka validate --wait`: it validates again every 5 seconds, for up to 5 minutes, until no lint is running, and does not wait for a pipeline whose source has unapplied changes. Report the pipeline as valid only after that. A lint does not restart by itself when dataset items or their values change, or after it fails or times out (after 5 minutes running or 15 minutes waiting to start): run `toloka pipeline lint <name> --wait`, which starts every lint without a current result and waits for it, then validate again. When a reviewed plan adds a dataset field already bound by an existing live pipeline, pre-apply validation can report that exact field as missing; apply only the reviewed additive plan, then require post-apply validation to clear source/spec errors. Never rewrite valid source because a stored test case on the Checks tab has not run.
 
 Register every code-node behavior with `test.code(pipeline, node, name, callback)`; its callback receives a bound `run(inputs, options?)` helper with the node's Python execution contract, and the test counts only after `run` executes, an assertion runs, and the callback passes. Register required human-work behavior with `test.ui(pipeline, node, name, callback)`; its callback receives a bound `render(options?)`, and the test counts only after a successful `submit`, at least one assertion, and a passing callback. Add at least one `test.pipeline(pipeline, name, callback)` scenario: treat the fixture as `root.started` item state, execute connected nodes in order with the callback's bound `runCode` and `renderUi` helpers, merge only each node's declared outputs, and assert the final `root.completed` fields. Cover meaningful match branches, optional paths, and failures as well as the happy path.
 
@@ -109,11 +109,11 @@ When plan, apply, or validate fails, follow [Recover safely](references/workflow
 
 ## Run an applied pipeline
 
-Before starting a run, require a passing `toloka check` and no blocking error from `toloka validate`. A `not_ran_node_check` or `running_node_check` warning does not block a run. Run `toloka pipeline cost <name>` and present the forecast for user approval before starting the run. If it skips a billed node, report the authored rate and a labeled labor floor instead of presenting `$0.00` as the price; make the missing pricing evidence clear when seeking approval.
+Before starting a run, require a passing `toloka check` and no blocking error from `toloka validate`. A run cannot start until every lint of the pipeline has finished: `toloka pipeline run` first starts the lints without a current result and waits for them, up to 5 minutes or its `--timeout`, which bounds the whole command. It exits `2` without starting the run when a lint is still running at the end of that wait, and the platform rejects the run when a lint on a connected node failed. Run `toloka pipeline cost <name>` and present the forecast for user approval before starting the run. If it skips a billed node, report the authored rate and a labeled labor floor instead of presenting `$0.00` as the price; make the missing pricing evidence clear when seeking approval.
 
-Start a run with `toloka pipeline run <name> --wait --timeout <ms>`, then read its exit code: `0` succeeded, `1` reached a failed terminal state, `2` still running when the window closed. Without `--wait`, exit `0` only means the run was accepted. Nothing reports back later, so never describe a started run as a finished one. Name the live pipeline; there is no implicit only-pipeline.
+Start a run with `toloka pipeline run <name> --wait --timeout <ms>`, then read its exit code: `0` succeeded, `1` reached a failed terminal state or the platform refused to start the run, `2` still running when the window closed. Exit `2` with `Did not start a run of <name>: its lints are still running` means no run was created: do not poll `toloka pipeline status` for it, run `toloka pipeline lint <name> --wait`, then start the run again. Without `--wait`, exit `0` only means the run was accepted. Nothing reports back later, so never describe a started run as a finished one. Name the live pipeline; there is no implicit only-pipeline.
 
-Keep monitoring bounded so the user receives a useful update even when expert work or queues take time. On exit `2`, report the observed item counts and states and say the run is still in progress; choose a further bounded check only when it serves the request. Use `toloka pipeline status <name>` and `toloka pipeline results <runId> --failed` for counts, states, and errors. `toloka status` (no prefix) is project health, not the latest run.
+Keep monitoring bounded so the user receives a useful update even when expert work or queues take time. On exit `2` after the command printed a run id, report the observed item counts and states and say the run is still in progress; choose a further bounded check only when it serves the request. Use `toloka pipeline status <name>` and `toloka pipeline results <runId> --failed` for counts, states, and errors. `toloka status` (no prefix) is project health, not the latest run.
 
 ## Report with evidence
 

package/skills/toloka-build/references/node-semantics.md

@@ -82,7 +82,9 @@ The platform generates `main_types.py` from the bound fields when it runs the no
 
 The platform runs code nodes on Python 3.12 with the standard library only, and a node cannot install packages. Call HTTP and LLM APIs with `urllib.request` or another standard module, not a vendor SDK. `test.code` runs your local Python, so an import of a package that happens to be installed locally passes `toloka check` and still fails on the platform.
 
-Bind every environment variable the code reads in `envVars`. Reference project secrets by name and set their values separately with `toloka secret set <name>`; use `os.environ['NAME']` in Python. The node's runtime has no ambient credentials.
+Bind every environment variable the code reads in `envVars`. Reference project secrets by name and set their values separately with `toloka secret set <name>`; use `os.environ['NAME']` in Python. The node's runtime has no ambient credentials: a key that your own environment happens to hold, such as a coding agent's model credentials, is not available on the platform, so never use one in node code, test cases or scripts.
+
+Claude Opus 4.7 and later and Claude Sonnet 5 and later reject sampling parameters: when a code node calls one of them, omit `temperature`, `top_p` and `top_k`. Claude 5.5 models also reject forced tool use, so do not set `tool_choice` to `any` or to a specific tool.
 
 ### Traps
 

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

@@ -70,6 +70,7 @@ Run the complete local gate first, then validate every bound pipeline remotely:
 toloka check
 toloka validate          # before apply
 toloka validate --wait   # after apply: waits for the platform's lints
+toloka pipeline lint <name> --wait   # after dataset changes or a failed lint: reruns the lints
 ```
 
 `toloka check` requires no credentials or live pipeline; SKILL.md describes what it runs and what its statuses mean. Use `toloka check <pipeline> --node <name-or-id>` for a focused edit loop, `--watch` for serialized reruns, and `--json` for automation.

package/src/cli/commands/pipeline.ts

@@ -8,6 +8,7 @@ import {
   listPipelineRuns,
   pipelineRunResults,
   pipelineRunStatus,
+  runPipelineLints,
   startPipelineRun,
 } from "../runs";
 
@@ -37,7 +38,11 @@ export const registerPipelineCommands = (program: Command, host: CommandHost): v
     .command("run")
     .argument("[name]", pipelineNameHelp)
     .option("--wait", "wait for the run to reach a terminal state", false)
-    .option("--timeout <ms>", "how long to wait", positiveInteger)
+    .option(
+      "--timeout <ms>",
+      "how long the command may wait in total, for the lints and, with --wait, for the run",
+      positiveInteger,
+    )
     .description("start a run on an applied pipeline")
     .action(async (name: string | undefined, options: { wait: boolean; timeout?: number }) => {
       const { client, state, projectId } = await resolveContext(globals(), context);
@@ -53,6 +58,26 @@ export const registerPipelineCommands = (program: Command, host: CommandHost): v
       context.io.stdout(result.output);
       exitCode.value = exitCodeForOutcome(result.outcome);
     });
+  pipeline
+    .command("lint")
+    .argument("[name]", pipelineNameHelp)
+    .option("--wait", "wait for the lints to finish", false)
+    .option("--timeout <ms>", "how long to wait", positiveInteger)
+    .description("run the pipeline's lints that have no current result")
+    .action(async (name: string | undefined, options: { wait: boolean; timeout?: number }) => {
+      const { client, state, projectId } = await resolveContext(globals(), context);
+      assertProjectSelected(projectId);
+      const result = await runPipelineLints(client, {
+        projectId,
+        state,
+        ...(name === undefined ? {} : { pipeline: name }),
+        wait: options.wait,
+        ...(options.timeout === undefined ? {} : { timeoutMs: options.timeout }),
+        ...(context.io.select === undefined ? {} : { select: context.io.select }),
+      });
+      context.io.stdout(result.output);
+      exitCode.value = exitCodeForOutcome(result.outcome);
+    });
   pipeline
     .command("status")
     .argument("[name]", pipelineNameHelp)

package/src/cli/runs.ts

@@ -4,6 +4,7 @@ import { PotatoApiError } from "../errors";
 import type { TolokaState } from "../state";
 import type { RunItem, RunJob } from "../index";
 import { assertCli } from "./cli-error";
+import { apiErrorDetails } from "./format-error";
 
 export type PipelineRef = {
   readonly pipelineId: string;
@@ -249,6 +250,144 @@ type PipelineCommandOptions = {
   readonly select?: (choices: readonly { name: string; value: string }[]) => Promise<string>;
 };
 
+const LINT_WAIT_TIMEOUT_MS = 5 * 60_000;
+const LINT_POLL_INTERVAL_MS = 5_000;
+
+type LintJob = Awaited<ReturnType<PotatoClient["checks"]["runLints"]>>["checks"][number];
+
+const isLintFinished = (job: LintJob) => job.status === "succeeded" || job.status === "failed";
+
+const waitForLints = async (
+  client: PotatoClient,
+  jobs: readonly LintJob[],
+  timeoutMs: number,
+  intervalMs: number,
+): Promise<readonly LintJob[]> => {
+  const deadline = Date.now() + timeoutMs;
+  let current = jobs;
+  while (!current.every(isLintFinished) && Date.now() < deadline) {
+    await new Promise<void>((resolve) => {
+      setTimeout(resolve, Math.min(intervalMs, deadline - Date.now()));
+    });
+    current = await Promise.all(
+      current.map(async (job) => (isLintFinished(job) ? job : client.checks.get({ checkRunId: job.id }))),
+    );
+  }
+  return current;
+};
+
+const runLints = async (
+  client: PotatoClient,
+  pipelineId: string,
+  options: {
+    readonly wait: boolean;
+    readonly nodesInUseOnly: boolean;
+    readonly timeoutMs?: number;
+    readonly intervalMs?: number;
+  },
+): Promise<{ readonly outcome: RunOutcome; readonly lines: readonly string[] }> => {
+  const result = await client.checks.runLints({ pipelineId });
+  const inScope = (nodeId: string) => !options.nodesInUseOnly || result.nodesInUse.includes(nodeId);
+  const checks = result.checks.filter((job) => inScope(job.nodeId));
+  const rejected = result.rejected.filter((entry) => inScope(entry.nodeId));
+  const jobs = options.wait
+    ? await waitForLints(
+        client,
+        checks,
+        options.timeoutMs ?? LINT_WAIT_TIMEOUT_MS,
+        options.intervalMs ?? LINT_POLL_INTERVAL_MS,
+      )
+    : checks;
+  const outcome: RunOutcome =
+    options.wait && !jobs.every(isLintFinished)
+      ? "timedOut"
+      : rejected.length > 0 || jobs.some((job) => job.status === "failed")
+        ? "failed"
+        : jobs.every(isLintFinished)
+          ? "succeeded"
+          : "started";
+  return {
+    outcome,
+    lines: [
+      ...jobs.map(
+        (job) =>
+          `  ${job.status} ${job.nodeId}/${job.checkId}${job.error === undefined || job.error === null ? "" : `: ${job.error}`}`,
+      ),
+      ...rejected.map((entry) => `  rejected ${entry.nodeId}/${entry.checkId}: ${entry.message}`),
+    ],
+  };
+};
+
+export async function runPipelineLints(
+  client: PotatoClient,
+  options: PipelineCommandOptions & {
+    readonly wait?: boolean;
+    readonly timeoutMs?: number;
+    readonly intervalMs?: number;
+  },
+): Promise<RunCommandResult> {
+  const ref = await resolvePipelineRef({ client, ...options });
+  const { outcome, lines } = await runLints(client, ref.pipelineId, {
+    wait: options.wait === true,
+    nodesInUseOnly: false,
+    ...(options.timeoutMs === undefined ? {} : { timeoutMs: options.timeoutMs }),
+    ...(options.intervalMs === undefined ? {} : { intervalMs: options.intervalMs }),
+  });
+  const summary =
+    outcome === "succeeded"
+      ? `All lints of ${ref.name} have finished. Run toloka validate to read their findings.`
+      : outcome === "failed"
+        ? `Some lints of ${ref.name} failed or could not start. Fix the reported problems, then run toloka pipeline lint again.`
+        : outcome === "timedOut"
+          ? `Some lints of ${ref.name} are still running. Run toloka pipeline lint --wait again.`
+          : `Started the lints of ${ref.name}. Follow them with toloka pipeline lint --wait.`;
+  return { outcome, output: [summary, ...lines].join("\n") };
+}
+
+const startRunAfterLints = async (
+  client: PotatoClient,
+  ref: PipelineRef,
+  options: { readonly timeoutMs?: number; readonly intervalMs?: number },
+): Promise<{ readonly run: RunJob } | { readonly result: RunCommandResult }> => {
+  const lints = await runLints(client, ref.pipelineId, {
+    wait: true,
+    nodesInUseOnly: true,
+    ...(options.timeoutMs === undefined ? {} : { timeoutMs: options.timeoutMs }),
+    ...(options.intervalMs === undefined ? {} : { intervalMs: options.intervalMs }),
+  }).catch((error: unknown) => {
+    if (error instanceof PotatoApiError && error.status === 403) return undefined;
+    throw error;
+  });
+
+  if (lints?.outcome === "timedOut") {
+    return {
+      result: {
+        outcome: "timedOut",
+        output: [
+          `Did not start a run of ${ref.name}: its lints are still running. Run toloka pipeline run again once toloka pipeline lint --wait reports them finished.`,
+          ...lints.lines,
+        ].join("\n"),
+      },
+    };
+  }
+
+  try {
+    return { run: await client.runs.start({ pipelineId: ref.pipelineId }) };
+  } catch (error) {
+    if (lints?.outcome !== "failed" || !(error instanceof PotatoApiError) || error.status === undefined) throw error;
+    return {
+      result: {
+        outcome: "failed",
+        output: [
+          `Could not start a run of ${ref.name}: ${apiErrorDetails(error) ?? error.message}`,
+          "Its lints:",
+          ...lints.lines,
+        ].join("\n"),
+      },
+    };
+  }
+};
+
 export async function startPipelineRun(
   client: PotatoClient,
   options: PipelineCommandOptions & {
@@ -258,7 +397,12 @@ export async function startPipelineRun(
   },
 ): Promise<RunCommandResult> {
   const ref = await resolvePipelineRef({ client, ...options });
-  const started = await client.runs.start({ pipelineId: ref.pipelineId });
+  const startedAt = Date.now();
+  const preparation = await startRunAfterLints(client, ref, options);
+
+  if ("result" in preparation) return preparation.result;
+
+  const started = preparation.run;
 
   if (options.wait !== true) {
     return {
@@ -274,7 +418,9 @@ export async function startPipelineRun(
     const finished = await client.waitFor(
       { type: "pipelineRun", runId: started.id },
       {
-        ...(options.timeoutMs === undefined ? {} : { timeoutMs: options.timeoutMs }),
+        ...(options.timeoutMs === undefined
+          ? {}
+          : { timeoutMs: Math.max(0, options.timeoutMs - (Date.now() - startedAt)) }),
         ...(options.intervalMs === undefined ? {} : { intervalMs: options.intervalMs }),
       },
     );

package/src/client.ts

@@ -790,6 +790,8 @@ const createClientImplementation = (config: ClientConfig) => {
       wire.createPipelineCheck(pipelineId, body, requestOptions),
     get: ({ checkRunId }: { checkRunId: CheckRunId }) =>
       wire.getPipelineCheck(checkRunId, requestOptions),
+    runLints: ({ pipelineId }: { pipelineId: PipelineId }) =>
+      wire.runPipelineLints(pipelineId, requestOptions),
   };
 
   const deliveryOrders = {

package/src/pipeline-graph-v1.contract.json

@@ -1478,7 +1478,8 @@
                         },
                         "required": [
                           "qaMode"
-                        ]
+                        ],
+                        "additionalProperties": false
                       },
                       {
                         "type": "object",
@@ -1513,7 +1514,8 @@
                         },
                         "required": [
                           "qaMode"
-                        ]
+                        ],
+                        "additionalProperties": false
                       }
                     ]
                   },