@toloka-platform/sdk 0.1.0-preview.5 → 0.1.0-preview.7

package/openapi/gen/models/sampleDatasetItemsBodyAnyOfOnethreeItemFilterFieldValuesItemValue.ts

@@ -0,0 +1,2 @@
+
+export type SampleDatasetItemsBodyAnyOfOnethreeItemFilterFieldValuesItemValue = string | number | boolean | null;

package/openapi/gen/models/sampleJob.ts

@@ -0,0 +1,13 @@
+import type { DatasetId } from './datasetId';
+import type { SampleJobStatus } from './sampleJobStatus';
+
+export interface SampleJob {
+  id: string;
+  datasetId: DatasetId;
+  fieldId: string;
+  markerValue: string;
+  status: SampleJobStatus;
+  target: number;
+  marked: number;
+  createdAt: string;
+}

package/openapi/gen/models/sampleJobStatus.ts

@@ -0,0 +1,2 @@
+
+export type SampleJobStatus = 'running' | 'succeeded';

package/openapi/gen/models/sampleResult.ts

@@ -0,0 +1,5 @@
+
+export interface SampleResult {
+  id: string;
+  target: number;
+}

package/openapi/gen/models/validatePipelineGraphBodyGraphNodesItemOneOfThreeoneSettingsAudienceAndPricingOneOfOneone.ts

@@ -6,4 +6,5 @@ export type ValidatePipelineGraphBodyGraphNodesItemOneOfThreeoneSettingsAudience
   generationModelId?: ValidatePipelineGraphBodyGraphNodesItemOneOfThreeoneSettingsAudienceAndPricingOneOfOneoneGenerationModelId;
   reasoningEffort?: ValidatePipelineGraphBodyGraphNodesItemOneOfThreeoneSettingsAudienceAndPricingOneOfOneoneReasoningEffort;
   llmInstruction?: string;
+  maxCostPerAttempt: number;
 };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@toloka-platform/sdk",
-  "version": "0.1.0-preview.5",
+  "version": "0.1.0-preview.7",
   "private": false,
   "description": "Preview. Build, inspect, and operate Toloka pipeline projects as TypeScript source. The public API may change.",
   "license": "Apache-2.0",
@@ -21,6 +21,8 @@
   "main": "./src/index.ts",
   "exports": {
     ".": "./src/index.ts",
+    "./testing": "./src/testing/index.ts",
+    "./checks": "./src/checks/index.ts",
     "./examples/face-image-collection": "./examples/face-image-collection/pipeline.ts"
   },
   "publishConfig": {
@@ -33,24 +35,43 @@
     "generate": "orval --config ./openapi/orval.config.js",
     "prepack": "bun run build",
     "sync-skill-catalog": "bun ./scripts/sync-skill-catalog.ts",
+    "sync-task-ui-declarations": "bun ./scripts/sync-task-ui-declarations.ts",
     "test": "vitest run",
+    "test:browser": "vitest run --config vitest.browser.config.ts",
     "typecheck": "tsc --noEmit"
   },
   "dependencies": {
     "@inquirer/select": "5.2.1",
+    "@typescript/vfs": "1.6.2",
     "ajv": "8.17.1",
     "ajv-formats": "3.0.1",
     "commander": "15.0.0",
     "es-toolkit": "1.42.0",
-    "posthog-node": "5.46.1"
+    "jsonpath-rfc9535": "1.3.0",
+    "oxc-parser": "0.138.0",
+    "posthog-node": "5.46.1",
+    "typescript-api": "npm:typescript@6.0.3"
   },
   "devDependencies": {
     "@types/node": "24.10.1",
     "orval": "7.17.0",
+    "playwright": "1.56.1",
     "typescript": "7.0.2",
     "vitest": "4.1.0",
     "yaml": "2.9.0"
   },
+  "peerDependencies": {
+    "playwright": ">=1.56.1 <2",
+    "vitest": ">=4.1.0 <5"
+  },
+  "peerDependenciesMeta": {
+    "playwright": {
+      "optional": true
+    },
+    "vitest": {
+      "optional": true
+    }
+  },
   "engines": {
     "bun": "1.4.0"
   }

package/skills/catalog.json

@@ -3,10 +3,18 @@
     {
       "id": "toloka-build",
       "name": "Build Toloka pipelines as code",
-      "description": "Build, inspect, and change Toloka platform pipeline projects as TypeScript source with @toloka-platform/sdk and toloka. Use when the user wants to create, adopt, inspect, plan, or apply a pipeline project as code.",
-      "tags": ["pipelines", "authoring", "sdk"],
-      "version": "0.1.0-preview.5",
-      "digest": "135d0b6ff6aa7bf26782bc26e6adbe7ee70c9db1565722ee356618211543d0bc",
+      "description": "Onboard users and build, test, inspect, or change Toloka platform pipeline projects as TypeScript source with @toloka-platform/sdk, toloka check, and toloka apply. Use when the user wants to get started, create, adopt, inspect, plan, apply, test, check, or run a pipeline project as code.",
+      "tags": [
+        "pipelines",
+        "authoring",
+        "sdk",
+        "onboarding",
+        "getting-started",
+        "testing",
+        "checks"
+      ],
+      "version": "0.1.0-preview.7",
+      "digest": "f1d2920113dba10f9decd3c65457c2bdd84227754aece441182ed9bb9eed0eee",
       "files": ["SKILL.md", "references/node-semantics.md", "references/workflow-and-cli.md"]
     },
     {
@@ -14,8 +22,8 @@
       "name": "Report a Toloka problem",
       "description": "Report a problem with the Toloka platform, CLI, or SDK as a redacted Markdown issue report sent through the toloka CLI only after explicit approval. Use when the user hits unexpected behavior, an error, or a bug and wants Toloka engineers to investigate.",
       "tags": ["support", "issue", "bug", "report"],
-      "version": "0.1.0-preview.5",
-      "digest": "9a673337ad1cbbcec7c2fadb2d49d38e923c797d049818fdaa15ff30ffd153f3",
+      "version": "0.1.0-preview.7",
+      "digest": "400d1e37dec535ccbf975086a5df1678a3c1c555a27548de4ffc90242fdfe6fd",
       "files": ["SKILL.md", "references/report-template.md"]
     }
   ]

package/skills/toloka-build/SKILL.md

@@ -1,25 +1,31 @@
 ---
 name: toloka-build
-description: Build, inspect, and change Toloka platform pipeline projects as TypeScript source with @toloka-platform/sdk and toloka. Use when the user wants to create, adopt, inspect, plan, or apply a pipeline project as code.
+description: Onboard users and build, test, inspect, or change Toloka platform pipeline projects as TypeScript source with @toloka-platform/sdk, toloka check, and toloka apply. Use when the user wants to get started, create, adopt, inspect, plan, apply, test, check, or run a pipeline project as code.
 ---
 
 # Build Toloka pipelines as code
 
 This SDK is Preview software. The authoring API, the CLI, and generated source can change. Do not invent helpers or flags that are not in the installed package.
 
-Use this skill when the user wants to create, inspect, or change a Toloka pipeline project as code. Work in the project source tree; do not translate the request into direct platform API calls.
+Use this skill when the user wants to get started or to create, inspect, test, or change a Toloka pipeline project as code. Work in the project source tree; do not translate the request into direct platform API calls.
+
+## Guide a first-time user
+
+When the user asks to get started or points to `https://platform.toloka.ai/onboarding.md`, read that guide before acting. The guide owns the session order and its user checkpoints. This skill owns authoring semantics, local test requirements, recovery, and evidence reporting.
+
+Do not replace the guide's quick demo with another example, and do not run the demo when the user chooses their own task. Never cross its API-key, project-creation, plan, or run-cost checkpoint without the user's required action or approval.
 
 ## Follow the reconciliation loop
 
 1. Read `toloka.json` when present, then read the relevant `pipelines/**/pipeline.ts` module and everything it imports.
 2. Edit the TypeScript source. Treat it as authoritative desired state.
-3. Run the project's typecheck, then validate each changed pipeline against the platform:
+3. Run the complete local gate, then validate each changed pipeline against the platform:
    ```sh
-   bunx tsc --noEmit
+   toloka check
    toloka validate
    ```
 4. Run `toloka plan`. Read the complete diff and resolve every conflict or missing prerequisite.
-5. Run `toloka apply`. Apply only after the plan matches the request.
+5. Run `toloka apply`. Apply reruns the complete local gate and proceeds only when it passes. Apply only after the plan matches the request.
 6. Run `toloka plan` again and require `No changes.`
 
 The CLI reads source, compares it with live state, and reconciles the platform. Edit files; never mutate a pipeline through raw HTTP, SDK client methods, or internal platform tool calls. Do not make a live edit and then reverse-engineer it into source.
@@ -28,17 +34,23 @@ The CLI reads source, compares it with live state, and reconciles the platform.
 
 Use the directory containing `toloka.json` as the source root. Commands default to the current directory; use `--source-root <directory>` from elsewhere.
 
-- If `toloka.json` exists, read it as CLI-managed identity state. It maps the project, pipeline source directories, and dataset names to live IDs. Do not hand-edit it.
-- If it is absent and the user is adopting an existing project, run `toloka project add <alias> <projectId>`, then `toloka import` in the intended source root. Import refuses an existing `pipelines/` directory unless you pass `--force`.
-- If it is absent and the user is authoring from scratch, run `toloka project create <alias>`. Create `pipelines/<name>/pipeline.ts`, then run `toloka plan` and `toloka apply`.
+- If `toloka.json` exists, read it as CLI-managed identity state and confirm its `projectId` matches `toloka project current` before any plan or apply. It maps the project, pipeline source directories, and dataset names to live IDs. Do not hand-edit it.
+- If it is absent and the user is adopting an existing project, run `toloka project add <alias> <projectId>`, then run `toloka import <projectId>` in the intended source root before `toloka init`. Import refuses an existing `pipelines/` directory unless you pass `--force`.
+- After importing an existing project, run `toloka plan` before editing and require `No changes.`. Resolve importer or live-state drift separately so it cannot be mistaken for your change.
+- If it is absent and the user is authoring from scratch, run `toloka project create <alias>` before `toloka init`. Confirm `toloka project current` and the generated `toloka.json` name the new project before authoring.
+
+If `toloka project current` reports `from toloka.json` for a project you did not select in this checkout, stop: project create/add/switch does not rebind an existing checkout. A newly generated state file with empty `pipelines` and `datasets` can be removed before selecting the intended project and rerunning `toloka init`; any state file with live bindings may be someone else's checkout and must not be deleted without user approval.
 
 Never assume a project ID from conversation context. Resolve it from `--project-id`, `TOLOKA_PROJECT_ID` / `POTATO_PROJECT_ID`, `toloka.json`, or `toloka project current`.
 
+`project create`, `project add`, and `project switch` also change the machine-level current-project registry used outside a source root. For temporary or evaluation projects, record the previous alias and restore it before finishing. If create requires `--team-id`, use the team from `toloka status --project-id <authorized-project>` only when that project is known to share the intended owner; state the assumption and confirm the new project's team in `toloka project url`. With no such project, ask the user for the team ID.
+
 ## Author with the typed graph API
 
 Import authoring helpers from `@toloka-platform/sdk`.
 
 - Declare every data contract once with `field(name, jsonSchema)`.
+- Do not invent enum, length, range, format, label-precedence, tie-break, default, exact-phrase, or conditional-requiredness rules absent from the request or observed data. Before apply, list every authored rule the request did not fix—including criteria, quiz answers, and UI validation—as an assumption; choose the least surprising option and carry that list into the final report.
 - Use exactly these constructors: `root`, `code`, `generation`, `match`, and `quorum`.
 - Connect typed ports with `connect(from, to)`: `started`, `completed`, `input`, `output`, `matchNode.matched(0)`, and `default`.
 - Export a default `definePipeline({ dataset, fields, nodes, connections })` from every `pipelines/**/pipeline.ts`.
@@ -54,19 +66,24 @@ These are server rules that `definePipeline` does not check. Each one costs an a
 
 - **Do not pair `projectType: 'general'` with `verifiedExperts: false`.** The server answers `General projects require an ID-verified audience`. Specializations also require a verified audience.
 - **Training is part of the node, not extra.** A quorum node requires `onboarding`, and while it is enabled the platform wants at least three steps and at least one quiz block. Preserve an explicit `enabled: false` that a user or `toloka import` put there; never switch Training on to satisfy your own sense of completeness.
+- **Do not author placeholder optional settings.** Omit `exam`, non-default QA, audience reuse, and smart-search blocks unless the user requested them or imported source already controls them. An empty disabled block is still authored state.
 - **Run scope belongs to the platform.** `itemFilter` and `itemLimit` on the root node are set from the platform, and apply preserves whatever is live unless source declares its own value. Do not add an item limit to source to "restore" one you saw in the UI.
 
 ## Know the validation boundary
 
 `definePipeline` and typed ports check local declaration and connection invariants. The published JSON contract is still available as `validate(graph)` for importer and fixture tests; it makes no server call.
 
-`toloka validate` posts each bound pipeline graph to `POST /pipelines/:pipelineId/graph/validate`. That is the platform's spec validation plus the latest matching check jobs. It does not write the graph. Pipelines that have not been applied yet are skipped until `toloka apply` creates them.
+`toloka check` is the required local gate. It runs the project TypeScript compiler, typechecks every authored Task UI against declarations bundled with this SDK version, runs Vitest, and requires passing typed `test.code`, `test.ui`, and `test.pipeline` evidence for every checkable node and pipeline. Use `toloka check <pipeline> --node <name-or-id>` while iterating, then run the unfiltered command before plan or run. Status `missing` means required test evidence does not exist; `failed` means a check ran and failed; `partial` means hardware-backed behavior remains unverified; `infrastructure_error` means the checker could not run. All four block apply.
 
-A successful `toloka validate` is necessary, not proof the pipeline can be launched. The labeler UI on a human-work node still needs a fresh successful validation receipt after every UI edit, and some per-node checks must be started separately. When apply succeeds but deployment is refused, stop and hand off to the platform UI for that node instead of editing source in circles.
+`toloka validate` posts each bound graph to the platform. Treat source/spec errors as blocking and warnings as informational. `not_ran_node_check` concerns a separate Remote Node Check and does not invalidate a passing Local Check Gate. A pipeline not yet on the platform is skipped until `toloka apply` creates it. 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 for a missing Remote Node Check.
+
+Before choosing Task UI components, call `ui.componentDocumentation()` from a local `@toloka-platform/sdk/testing` scenario. A component's usable contract is the returned `propsType` plus its returned `valueType` and `example`; shared `Field` props such as `path`, `label`, `hint`, and `validation` can be confirmed from any current `Field.*` example, but do not invent any other prop. For structured or array-valued Fields, derive the dataset field schema from `valueType`, then feed the documented example value through `setValue`, `getValue`, and `submit` in the UI scenario so upstream contract drift fails locally. Never translate undocumented property names or replace missing values with defaults. Every identifier in `ui.code` must be a returned component or documented `actions` API, and JSX must have one root element. Register each required UI scenario with `test.ui(pipeline, node, name, callback)` and submit through its bound `render` helper. Run `toloka check <pipeline> --node <name-or-id>` after every Task UI edit; require passing UI types, empty browser validation errors, valid postprocessed entity output, and visual inspection where relevant. Never weaken authored validation merely to make a test pass.
+
+Register code behavior with `test.code(pipeline, node, name, callback)` and execute the bound `run` helper. Add at least one `test.pipeline(pipeline, name, callback)` scenario. When a local dataset file is available, use its first row as the initial item state; redact sensitive values while preserving field names, nesting, optionality, and media/value shapes. Use synthetic input only when no local row exists. Treat the fixture as `root.started` item state, execute connected nodes in order with the callback's bound code and UI helpers, merge only each node's declared outputs, and assert the final `root.completed` fields. One scenario is appropriate for a linear happy path; use separate scenarios for different match branches, optional paths, and failures.
 
 ## Keep data and credentials out of source
 
-- Never put dataset items in pipeline source or `toloka.json`. After apply has created or resolved the dataset, upload JSONL objects with `toloka dataset upload <dataset> <file>`. If a later upload fails as schema-incompatible, run `toloka dataset fields <dataset>` and copy the printed `field()` declarations into source.
+- Never put dataset items in pipeline source or `toloka.json`. After apply has created or resolved the dataset, upload `.json`, `.jsonl`, or `.csv` rows with `toloka dataset upload <dataset> <file>`. If a later upload fails as schema-incompatible, inspect `toloka dataset fields <dataset>` for stored names and base types, but preserve stricter authored constraints; the printed inference can omit enum, length, range, and format constraints.
 - Put secret references in node settings, but never secret values. Set values through stdin with `toloka secret set <name>`, or use `toloka secret set <name> --from-env <variable>`.
 
 ## Credentials
@@ -82,13 +99,18 @@ Anonymous command telemetry is on by default; set `TOLOKA_TELEMETRY=0` or `DO_NO
 - **Dataset field schema conflict:** Stop trying to edit the field. Dataset fields are immutable after creation: they can be added, never altered or removed. Declare a new column name with the wanted schema, or bind the pipeline to a new dataset, then plan again.
 - **Missing secret:** Set every name listed by plan with `toloka secret set <name>`, keep the value out of files and shell arguments, then rerun plan and apply.
 - **409 stale version:** Another writer changed the graph after it was read. Do not retry blindly. Run `toloka plan` to re-read live state, review the new diff, preserve intentional remote changes in source when needed, then run `toloka apply` again.
+- **Server 400 after partial apply:** Dataset and field writes can land before pipeline import is rejected. Fix the source and run `toloka plan` again. Continue from the remaining diff; do not recreate resources that remain valid. If the rejection means a newly created field schema is wrong, that field is already immutable: apply the field-conflict rule by choosing a new column name or a new dataset, prefer the option that preserves names fixed by the request, and report the orphan instead of deleting it.
 
 ## Run a deployed pipeline
 
+Before starting a run, require a passing `toloka check` and no blocking source/spec error from `toloka validate`. Do not block on `not_ran_node_check`, which concerns separate Remote Node Checks. Run `toloka pipeline cost <name>` when pricing evidence is needed; if it skips a billed node, report the authored rate and a labeled labor floor instead of presenting `$0.00` as the price.
+
 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.
 
 Always bound the wait. A queue with no one working it stays in progress indefinitely, so an unbounded poll loop ends with you killed and reporting nothing. On exit `2`, stop waiting and report what you observed: item counts, current states, and that the run had not finished. A bounded honest report beats an unbounded silent wait. 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
+
 Deliver that report in the same reply that does the work. There is no later turn and no background poller that will speak for you: if you end by promising to report once a window closes, the observation is lost and the work counts for nothing. Poll in the foreground, then state what you saw before you finish.
 
-Read [workflow and CLI recipes](references/workflow-and-cli.md) for source layout, configuration precedence, adoption, scratch authoring, upload, secret, run, multi-project, and recovery details.
+For an autonomous or audited platform change, save stdout, stderr, and exit status for skill discovery and every networked mutation, check, and project-registry change outside authored source, then cite those records for counts, exit codes, and convergence claims. If skill installation fails, record the failure and identify the exact skill path and version or digest followed instead. Every reported defect or guidance gap must cite a saved record or be labeled `unrecorded`; mark recurrences from earlier work. Classify each as a skill rule, a rule present but not followed, a documentation gap, or a CLI/platform defect; use the bundled `toloka-report-issue` skill for product defects instead of teaching a workaround as normal workflow. Report every authored rule not fixed by the request as an assumption. For visual evidence, list every saved screenshot as inspected or uninspected and limit appearance claims to the inspected set.

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

@@ -20,21 +20,21 @@ Choose by behavior, not by the data format:
 
 Use the typed node properties; never write handle strings yourself:
 
-| Node | Input | Output |
-| --- | --- | --- |
-| `root` | `collection.completed` | `collection.started` |
-| `code` | `transform.input` | `transform.output` |
-| `generation` | `annotate.input` | `annotate.output` |
-| `quorum` | `rate.input` | `rate.output` |
-| `match` | `route.input` | `route.matched(0)`, `route.matched(1)`, …, `route.default` |
+| Node         | Input                  | Output                                                     |
+| ------------ | ---------------------- | ---------------------------------------------------------- |
+| `root`       | `collection.completed` | `collection.started`                                       |
+| `code`       | `transform.input`      | `transform.output`                                         |
+| `generation` | `annotate.input`       | `annotate.output`                                          |
+| `quorum`     | `rate.input`           | `rate.output`                                              |
+| `match`      | `route.input`          | `route.matched(0)`, `route.matched(1)`, …, `route.default` |
 
 Connect them in the direction of data flow:
 
 ```ts
-connect(collection.started, transform.input)
-connect(transform.output, route.input)
-connect(route.matched(0), annotate.input)
-connect(annotate.output, collection.completed)
+connect(collection.started, transform.input);
+connect(transform.output, route.input);
+connect(route.matched(0), annotate.input);
+connect(annotate.output, collection.completed);
 ```
 
 `match.matched(index)` corresponds by index to `settings.conditions[index]`. The first matching condition wins; `default` receives items that match none.
@@ -52,14 +52,13 @@ The public authoring shape is `RootAuthoringSettings`:
 - Each entry can be a `Field` or `{ field, optional }`; a bare `Field` is required.
 - `itemLimit` exists in both `RootNodeSettings` and `RootAuthoringSettings`. Do not invent a limit; author one only when the user explicitly requests a bounded test or batch. Apply preserves a live `itemLimit` unless source declares its own.
 
-
 The dataset name belongs in `definePipeline({ dataset: 'name', ... })`, not in the root settings. `toloka apply` resolves or creates the named dataset and supplies its ID.
 
 ### Traps
 
 - Do not author `datasetId` or `itemFilter`; `RootAuthoringSettings` omits both. `toloka apply` binds the dataset and preserves the live `itemFilter` and `itemLimit` unless source declares its own `itemLimit`. Do not add a limit to source to restore one you saw in the UI.
 
-- Do not put a field in `completed` unless the final connected branch actually produces it.
+- `completed` may contain any declared field carried on the incoming branch, whether it originated at root input or an upstream output. Never list a field no upstream node provides. Until a run produces results, write-back of a pass-through input is unobserved and must be reported that way.
 - Declare every referenced `Field` in `definePipeline({ fields })`.
 - Dataset fields are immutable after creation. You may add a column, never alter or remove one. On a schema conflict, use a new column name or a new dataset.
 
@@ -143,16 +142,18 @@ An authored entity uses `field`, not `fieldProxyId`. Set `entityType`, `optional
 - `dynamic: false` means one value in one annotation; use a path without `[*]` and omit `maxEntities`.
 - `dynamic: true` means repeated values inside one annotation; use exactly one `[*]` in `jsonPath` and set `maxEntities` from 1 through 50.
 - Use `allowedLabels: [{ label, value }]` for fixed choices. Use `SINGLE_LABEL` for exactly one stored value and `MULTI_LABEL` for multiple values.
-- Set both `minDurationSeconds` and `maxDurationSeconds` on `VIDEO` entities.
+- Set media duration bounds only when the expert produces the media through an upload or recording output. Input media used for annotation does not require duration bounds.
 - Give every output entity at least one relation to the input it uses: `{ field, rel_type: 'context' | 'references' | 'depends_on' | 'evaluates' }`, or a conditional relation supported by the public type.
 
+`entityType` is a closed platform vocabulary even where a generated TypeScript shape is currently broad. Use `CONTEXT` for any non-media input the expert reads, including text, numbers, and objects. Use `SHORT_ANSWER` for short produced text, `RESPONSE` for long produced text, and `EXPLANATION` only for reasoning about another value. Use `SINGLE_LABEL` or `MULTI_LABEL` for fixed choices and the matching media or annotation type for those values. Never invent `TEXT` or another natural-language type name; consult the documented vocabulary when these categories do not fit.
+
 Entities enforce format, not meaning. Put types, ranges, cardinality, requiredness, and labels in the field schema and entity. Put accuracy, correctness, completeness, and clarity in quality criteria.
 
-For video `data_collection`, the upload or recorder returns an array even when one video is requested. Use an output `VIDEO` entity with `dynamic: true`, `maxEntities: 1`, and a `jsonPath` ending in `[*]`; align its duration bounds with the UI component.
+For any single-item upload or recording control, the component value is still an array. Declare the output field as a top-level array with `minItems: 1` and `maxItems: 1`, the output entity as `dynamic: true` with `maxEntities: 1` and a `jsonPath` ending in `[*]`, and use the matching media or document entity type. Map the component's documented completed-value link field in `postprocess`. For video, also set both entity duration bounds and align them with the UI component.
 
 #### Quality and instructions
 
-Write at least one criterion for every output entity. Each criterion needs an authored UUID `id`, `qualityElement`, mutually exclusive and exhaustive `thresholds.pass` and `thresholds.fail`, and `targetEntity: outputField`. Invert the task into an observable check: “tag every car” becomes “every visible car has exactly one tag.” Keep format validation out of criteria.
+Write at least one criterion for every output entity. Each criterion needs an authored UUID `id`, `qualityElement`, mutually exclusive and exhaustive `thresholds.pass` and `thresholds.fail`, and `targetEntity: outputField`. Every criterion must resolve to pass or fail for every item; express edge cases as conditional clauses inside an always-applicable criterion. Criteria judge meaning, not an exact phrase you authored unless the request fixes that phrase. Before apply, walk every sample row through the instruction and all criteria: each criterion must yield one verdict, and no two authored rules may demand different values for the same row. Invert the task into an observable check: “tag every car” becomes “every visible car has exactly one tag.” Keep format validation out of criteria.
 
 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.
 
@@ -162,7 +163,7 @@ Keep `instruction` actionable and in English. Include the workflow, concepts, qu
 
 #### Audience and pricing
 
-For humans, set `audienceType: 'human'`, `verifiedExperts`, all three audience filters, `pricePerTask`, and `timeForTask`. The public shapes differ by filter: languages use `{ type: 'and' | 'or', values: [{ value: 'English' }] }`; specializations use `{ type: 'and' | 'or', values: [{ value, qualificationId }] }`; countries use `{ type: 'or', values: ['United States'] }`. Start unspecified filters with English, no specializations, and no countries. Do not put specializations on an unverified audience. A specialization's `qualificationId` is platform identity: preserve an imported value, and do not invent one when the SDK cannot discover it.
+For humans, set `audienceType: 'human'`, `verifiedExperts`, all three audience filters, `pricePerTask`, and `timeForTask`. The public shapes differ by filter: languages use `{ type: 'and' | 'or', values: [{ value: 'English' }] }`; specializations use `{ type: 'and' | 'or', values: [{ value, qualificationId }] }`; countries use ISO 3166-1 alpha-2 codes, for example `{ type: 'or', values: ['US'] }`. Verify every country value matches `/^[A-Z]{2}$/`; apply currently accepts arbitrary strings that can match no experts. Start unspecified filters with English, no specializations, and no countries. Do not put specializations on an unverified audience. A specialization's `qualificationId` is platform identity: preserve an imported value, and do not invent one when the SDK cannot discover it.
 
 Start with `$0.20` and 120 seconds when the task gives no stronger signal, then change them only for an explicit rate or clearly longer work. The per-expert cap is normally off. For `data_collection`, use a cap of 50 by default; use 1 for one-response-per-expert collection.
 
@@ -185,10 +186,10 @@ Use `reuseAudienceWithNodeId` only with real imported `{ pipelineId, nodeId }` v
 - Do not add fields, explanations, comments, or labor the task does not require.
 - Do not choose synthetic generation merely because a model could do the task; require an explicit request.
 - Do not treat the constructor's generated placeholder Training or blank UI as production-ready configuration.
-- Do not pair `projectType: 'general'` with `verifiedExperts: false`. General projects require an ID-verified audience, and the server rejects the graph with `General projects require an ID-verified audience`. `data_collection` supports both modes but requires a media upload component (`VideoUpload`, `VideoRecord`, or `FileUpload`) in the `ui` code. An annotation task with an unverified audience therefore cannot be expressed: `general` demands verified experts and `data_collection` demands an upload widget the task has no use for. When a request asks for one, say so and let the requester choose, rather than quietly flipping a setting.
+- Do not pair `projectType: 'general'` with `verifiedExperts: false`. General projects require an ID-verified audience, and the server rejects the graph with `General projects require an ID-verified audience`. `data_collection` supports both modes but requires a hardware upload or recording component supported by the current UI catalog. An annotation task with an unverified audience therefore cannot be expressed: `general` demands verified experts and `data_collection` demands an upload control the task has no use for. When a request asks for one, say so and let the requester choose, rather than quietly flipping a setting.
 - Do not omit `ui.constants`. It is required alongside `code`, `data`, `preprocess`, and `postprocess`; `'{}'` is the right value when there is nothing to pass. Omitting it fails validation with `must have required property 'constants'`, usually reported together with a misleading `type must be equal to constant` from the failed node discrimination.
 - Do not ship a generation node without Training. `onboarding` is mandatory: at least three `steps`, of which at least one carries a `quiz` block. The server rejects fewer with `Onboarding must have at least 3 steps` and `Onboarding must include at least one quiz block`.
-- Do not treat the server's materialized defaults as your configuration. A deployed node reports `qualityAssurance`, `exam`, `reuseAudienceWithNodeId`, and `smartSearch` even when source never set them. Leave them out of source unless you mean to control them; `plan` compares only what source declares.
+- Do not treat the server's materialized defaults as your configuration. A deployed node reports `qualityAssurance`, `exam`, `reuseAudienceWithNodeId`, and `smartSearch` even when source never set them. Leave them out unless you mean to control them. Omitted top-level object keys are preserved, but defaults materialized inside list elements can still cause drift; use the generic import-and-diff recovery flow.
 
 ## `quorum`
 
@@ -213,6 +214,8 @@ Quorum is human-only in the current public shape; its `audienceAndPricing.audien
 
 Configure entities for one labeler's contribution, not for the outer array. A single label per person therefore uses `dynamic: false` and `jsonPath: '$.label'`, while the declared output field is `{ type: 'array', items: { type: 'string' } }`. `dynamic: true` means an array inside each labeler's contribution and therefore produces an array of arrays. Build the UI to submit one value at `$.label`, never `$.label[0]`; the platform assembles the outer array.
 
+When a quorum output entity is `optional: true`, its outer field's `items` schema must also accept `null`, for example `{ type: 'array', items: { type: ['string', 'null'] } }`. The platform reserves a null annotation slot when that labeler omits the value and rejects an optional entity backed by non-nullable items.
+
 Quorum does not aggregate. It writes all raw annotations back, including rejected ones. Add a downstream `code` node only when the user asks for one consensus value, and make it tolerate arrays longer than `overlap`.
 
 #### Explanation-driven quality
@@ -257,7 +260,7 @@ Set `MatchAuthoringSettings`, derived from `MatchNodeSettings`, through `match(n
 
 - `about`: `name`, optional `description`, optional `projectType`.
 - `fieldProxies.input`: every declared `Field` referenced by a predicate, each with `optional`.
-- `conditions`: ordered branches. Each has `name`, optional `logic: 'and' | 'or'`, and `predicates`.
+- `conditions`: ordered branches with optional `logic: 'and' | 'or'` and required `predicates`.
 - Each authored predicate uses `field`, `jsonPath`, `operator`, and scalar `value`.
 
 The current public type accepts only `operator: 'text_eq' | 'text_neq'` and `value: string | number | boolean | null`. Do not copy broader internal operator lists into source. Use `jsonPath: '$'` for the whole scalar or a restricted path into an object.
@@ -278,14 +281,14 @@ When the requirement depends on one of these capabilities, state the gap instead
 - Audience discovery and validation helpers have no SDK or CLI path: valid-language/country/specialization suggestions, audience-size statistics, and recommended-rate calculation.
 - Audience-reuse candidate discovery has no SDK or CLI path. Source can store a known cross-pipeline pointer, but cannot search candidates.
 - Smart Search rendering, source-fingerprint computation, and stale-profile diagnosis have no SDK or CLI path. Source can carry the public profile; it cannot generate the server-owned fingerprint or preview rendered sourcing documents.
-- The interactive task-interface toolkit has no SDK/CLI testing path for component discovery, component documentation, rendered tree/value inspection, screenshots, TypeScript reports, or submission validation. Source can set `ui`; final UI verification remains server/UI work.
+- The `@toloka-platform/sdk/testing` entry point provides typed `test.code`, `test.ui`, and `test.pipeline` wrappers. `toloka check` runs their evidence with project TypeScript and automatic Task UI typechecking. Missing Remote Node Checks remain separate from this local gate.
 - Training's examples playbooks and automatic course authoring have no SDK/CLI path. Source can set `onboarding`, but cannot request geometry/numeric check templates or validate hands-on examples locally beyond the public graph schema.
 - Exam golden-dataset discovery, creation by symbolic dataset name, dataset lint execution, and generated-golden confirmation flow have no high-level SDK authoring path. `exam.goldenDatasetId` requires a real ID.
-- Per-node strict validation is not exposed separately. `definePipeline` and offline `validate(graph)` check the public contract; `toloka validate` runs platform spec validation and reports the latest matching check jobs without writing the graph.
-- Stored checks can be represented in settings and the low-level client can list/start pipeline checks, but `toloka` has no command that discovers check contracts, configures check cases, starts each required lint/test, waits, and explains reports.
+- Per-node platform validation is not exposed separately. `definePipeline` and `toloka check` enforce local contracts; `toloka validate` runs platform spec validation and reports the latest matching Remote Node Check jobs without writing the graph.
+- Stored Remote Node Checks can be represented in settings and the low-level client can list/start them. `toloka check` deliberately runs local source and authored tests; it does not configure or start platform check jobs.
 - Project rename and runtime item-filter authoring have no `toloka` source path. The CLI preserves the live item filter and a live `itemLimit` unless source declares its own limit.
 
 - Generation's platform-controlled redo cap, appeal behavior, payment retry, and exact terminal handling are intentionally not configurable SDK settings.
 - Dynamic quorum and per-item overlap are unsupported by both surfaces; this is a platform limitation, not missing TypeScript syntax.
 
-For every representable change above, edit the node's source file, run `toloka validate`, inspect `toloka plan`, and apply with `toloka apply`.
+For every representable change above, edit the node's source file, run `toloka validate`, inspect `toloka plan`, and apply with `toloka apply`.