@uipath/skills 1.204.0 → 1.204.1

package/skills/uipath-maestro-flow/examples/TideTableConverter.flow.ts

@@ -1,35 +0,0 @@
-/**
- * CAPABILITY: run a deployed Orchestrator FUNCTION as one step.
- *
- * A function is a small unit of code published as its own resource. `key`
- * becomes part of the node type (`uipath.core.function.<key>`); `name` and
- * `folderPath` locate the deployment. `returns` declares the fields the
- * function hands back so downstream steps can read them.
- *
- * A function is usually deployed into a folder of its OWN name, and the
- * binding's `resourceKey` is `<folderPath>.<name>` — read the folder from the
- * tenant rather than assuming `'Shared'`.
- *
- * Generic scenario: convert a tide height between measurement systems.
- */
-import { flow, publishedFunction, script, input, out, types } from '@uipath/maestro-builder-sdk';
-
-export default flow('tide-table-converter')
-  .name('TideTableConverter')
-  .version('1.0.0')
-  .input({ heightFeet: types.number })
-  .output({ reading: types.string })
-  .step('toMetres', publishedFunction({
-    key: 'd41f60c8-27b5-4e19-8a3d-6f0be9147c52',
-    name: 'tide-convert',
-    folderPath: 'Shared/tide-convert',
-    inputs: { feet: input('heightFeet') },
-    returns: { metres: 'number' },
-  }))
-  .step('formatReading', script({
-    code:
-      'return String($vars.start.output.heightFeet) + " ft = "'
-      + ' + String($vars.toMetres.output.metres) + " m";',
-  }))
-  .return({ reading: out('formatReading') })
-  .build();

package/skills/uipath-maestro-flow/examples/TrailLogSummary.flow.ts

@@ -1,75 +0,0 @@
-/**
- * CAPABILITY: the three `transform` VARIANTS — filter, map, group-by — chained.
- *
- *   Filter  → keep the rows you want
- *   Map     → reshape each row (`keepOriginalFields: false` drops the rest)
- *   Group by→ one row per key, with aggregations
- *
- * Each variant node carries EXACTLY ONE operation of the matching type
- * (`variant: 'group-by'` ⇢ `type: 'groupBy'` — node type hyphenated, operation
- * camelCase). Each step's `collection` is the previous step's `out(...)`, which
- * is a path — which is what `collection` wants.
- *
- * Generic scenario: a season of hiking-trail logs → miles walked per difficulty
- * band. Static data lives in a variable default because `collection` is a path.
- */
-import { flow, transform, v, out, types } from '@uipath/maestro-builder-sdk';
-
-export default flow('trail-log-summary')
-  .name('TrailLogSummary')
-  .version('1.0.0')
-  .output({ perBand: types.array })
-
-  .var('logs', types.array, [
-    { trail: 'Cedar Ridge', band: 'moderate', status: 'open', miles: 7 },
-    { trail: 'Fern Gully', band: 'easy', status: 'open', miles: 3 },
-    { trail: 'Granite Spine', band: 'hard', status: 'closed', miles: 11 },
-    { trail: 'Otter Creek', band: 'easy', status: 'open', miles: 4 },
-    { trail: 'Storm Pass', band: 'hard', status: 'open', miles: 9 },
-    { trail: 'Willow Bend', band: 'moderate', status: 'open', miles: 5 },
-  ])
-
-  // 1. Filter — one rule, so the node IS a filter.
-  .step('walkable', transform({
-    variant: 'filter',
-    collection: v('logs'),
-    operations: [
-      { type: 'filter', operation: 'and', filters: [{ field: 'status', condition: 'equals', value: 'open' }] },
-    ],
-  }))
-
-  // 2. Map — keep only what step 3 needs. `keepOriginalFields: false` drops the rest.
-  .step('summaryFields', transform({
-    variant: 'map',
-    collection: out('walkable'),
-    operations: [
-      {
-        type: 'map',
-        keepOriginalFields: false,
-        mappings: [
-          { field: 'band', transformation: 'uppercase', renameTo: 'grade' },
-          { field: 'miles' },
-        ],
-      },
-    ],
-  }))
-
-  // 3. Group by — one row per grade. `count` is the only aggregation with no `field`.
-  .step('perBand', transform({
-    variant: 'group-by',
-    collection: out('summaryFields'),
-    operations: [
-      {
-        type: 'groupBy',
-        groupByField: 'grade',
-        aggregations: [
-          { operation: 'count', alias: 'trails' },
-          { operation: 'sum', field: 'miles', alias: 'totalMiles' },
-        ],
-      },
-    ],
-  }))
-
-  .return({ perBand: out('perBand') })
-
-  .build();

package/skills/uipath-maestro-flow/examples/WorkshopInventory.flow.ts

@@ -1,27 +0,0 @@
-/**
- * CAPABILITY: invoke a deployed RPA workflow and declare its returned fields.
- *
- * The process key selects the node type; name and folder locate the deployed
- * automation. `returns` makes the robot's output readable downstream.
- *
- * Generic scenario: ask a robot to count missing tools in a shared workshop.
- */
-import { flow, rpaWorkflow, script, input, out, types } from '@uipath/maestro-builder-sdk';
-
-export default flow('workshop-inventory')
-  .name('WorkshopInventory')
-  .version('1.0.0')
-  .input({ zone: types.string })
-  .output({ report: types.string })
-  .step('countTools', rpaWorkflow({
-    key: 'bb67ae85-84ca-4b2c-9f37-ac52c57f9d18',
-    name: 'Workshop Tool Count',
-    folderPath: 'Shared/community-workshop',
-    inputs: { zone: input('zone') },
-    returns: { missingTools: 'integer' },
-  }))
-  .step('formatCount', script({
-    code: 'return "missing tools: " + String($vars.countTools.output.missingTools);',
-  }))
-  .return({ report: out('formatCount') })
-  .build();

package/skills/uipath-maestro-flow/examples/bindings.json

@@ -1,85 +0,0 @@
-{
-  "schemaVersion": "1",
-  "bindings": [
-    {
-      "id": "slack",
-      "name": "slack",
-      "resource": "Connection",
-      "resourceKey": "<slack-connection-id from `uip is connections list --output json`>",
-      "default": "00000000-0000-0000-0000-000000000001",
-      "propertyAttribute": "ConnectionId"
-    },
-    {
-      "id": "jira",
-      "name": "jira",
-      "resource": "Connection",
-      "resourceKey": "<jira-connection-id from `uip is connections list --output json`>",
-      "default": "00000000-0000-0000-0000-000000000005",
-      "propertyAttribute": "ConnectionId"
-    },
-    {
-      "id": "shared",
-      "name": "shared",
-      "resource": "Connection",
-      "resourceKey": "<folder-key from `uip is connections list --output json`>",
-      "default": "00000000-0000-0000-0000-000000000002",
-      "propertyAttribute": "FolderKey"
-    },
-    {
-      "id": "bWebhook",
-      "name": "uipath-http-webhook connection",
-      "resource": "Connection",
-      "resourceKey": "<http-webhook-connection-id from `uip is connections list --output json`>",
-      "default": "00000000-0000-0000-0000-000000000003",
-      "propertyAttribute": "ConnectionId"
-    },
-    {
-      "id": "bWebhookFolder",
-      "name": "uipath-http-webhook folder",
-      "resource": "Connection",
-      "resourceKey": "<folder-key of that connection, same command>",
-      "default": "00000000-0000-0000-0000-000000000004",
-      "propertyAttribute": "FolderKey"
-    },
-    {
-      "id": "dataService",
-      "name": "dataService",
-      "resource": "Connection",
-      "resourceKey": "<dataservice-connection-id from `uip is connections list --output json`>",
-      "default": "00000000-0000-0000-0000-000000000006",
-      "propertyAttribute": "ConnectionId"
-    },
-    {
-      "id": "entra",
-      "name": "entra",
-      "resource": "Connection",
-      "resourceKey": "<entra-connection-id from `uip is connections list --output json`>",
-      "default": "00000000-0000-0000-0000-000000000009",
-      "propertyAttribute": "ConnectionId"
-    },
-    {
-      "id": "bOneDrive",
-      "name": "uipath-microsoft-onedrive connection",
-      "resource": "Connection",
-      "resourceKey": "<onedrive-connection-id from `uip is connections list --all-folders --output json`>",
-      "default": "00000000-0000-0000-0000-000000000007",
-      "propertyAttribute": "ConnectionId"
-    },
-    {
-      "id": "bOneDriveFolder",
-      "name": "uipath-microsoft-onedrive folder",
-      "resource": "Connection",
-      "resourceKey": "<folder-key of that connection, same command>",
-      "default": "00000000-0000-0000-0000-000000000008",
-      "propertyAttribute": "FolderKey"
-    },
-    {
-      "id": "outlook",
-      "name": "outlook",
-      "resource": "Connection",
-      "resourceKey": "<outlook365-connection-id from `uip is connections list --output json`>",
-      "default": "00000000-0000-0000-0000-000000000010",
-      "propertyAttribute": "ConnectionId"
-    }
-  ]
-}

package/skills/uipath-maestro-flow/references/CLI-LOOP.md

@@ -1,309 +0,0 @@
-# Authoring and product-CLI loops
-
-Choose one loop before running any build command:
-
-- if the task requests product-CLI validation/debug, or the workspace enables
-  `flowSdk.emitOnly`/`FLOW_SDK_EMIT_ONLY=1`, use only the eval/product-CLI loop;
-- otherwise use the packaged-SDK local gates.
-
-In eval/product mode, create the solution/project scaffold immediately after
-choosing the loop, before authoring the source. Once the source first
-compiles, emit it into that nested project artifact—not `/tmp`—and keep the
-artifact current after every source edit.
-
-Tenant discovery is not a phase of either loop. The one step before authoring
-is choosing the node ([SKILL.md, "Choose the node before writing it"](../SKILL.md)):
-`check` cannot flag a node you never wrote, so a script or `mock()` written in
-its place goes unflagged.
-After that, author the source from the task's own words; the source `check`
-names every tenant call you owe —
-each unresolved lookup, unmaterialized object, and out-of-snapshot field, with
-the exact `registry prepare` command — so the one expensive call is spent
-once, after the cheap pass has found everything else that is wrong.
-
-Do not mix the two loops in one workspace or use one mode as a probe for the
-other. Their output layouts and evidence contracts are different.
-
-## Source-model and brownfield judgment
-
-TypeScript executes while the graph is constructed. Use Flow Branch, Switch,
-Loop, and action nodes for decisions or work that must happen at runtime; a
-native `if` or `for` is appropriate only for deliberate author-time graph
-generation.
-
-When editing an existing Flow, change the supplied `.flow.ts`, preserve existing
-step names and unaffected wiring, and move an edge through an inserted step
-rather than leaving the old bypass in place. If the input is only raw `.flow`
-JSON, reconstruct source, compile once to compare the emitted baseline, and
-then make the requested edit. Those are before/after judgments no final
-artifact can establish.
-
-## Installing the package
-
-Skip this when the SDK is already installed: `npm ls -g @uipath/maestro-builder-sdk` lists it, or a prepared workspace has `node_modules/@uipath/maestro-builder-sdk` (a workspace copy is used before a global one).
-Every `uip maestro flow` authoring verb — `check`, `compile`, `decompile` — runs from the installed package, so all of them refuse until it is installed; the package cannot bootstrap itself.
-Install it once per machine, globally, so the workspace needs no `package.json` or `node_modules/`:
-
-```bash
-npm install -g @uipath/maestro-builder-sdk
-```
-
-The package is public on npmjs.com, so this needs no token and follows whatever registry or mirror the machine's npm config names.
-Only if it fails with E401 or E404 **and** `npm config get @uipath:registry` names GitHub Packages, retry once with `--@uipath:registry=https://registry.npmjs.org` appended.
-If it fails with EACCES (npm's global folder is not writable), do not use `sudo`; install into the workspace instead with `npm install --save-dev @uipath/maestro-builder-sdk`, which `uip` also finds.
-Any other failure (a timeout, a mirror refusing the package) is the user's network or registry to fix, so report it rather than routing around it.
-When `uip` reports the SDK is below its minimum version, run the command its `Instructions` give: it names `-g` or `--save-dev` depending on which copy it found.
-
-## Local authoring hard gates
-
-Use this section only when emit-only mode is disabled. Use the source check as
-the fast no-output inner loop (with a library and `.flow-sdk/bindings.json` beside the
-source it reports every connector-input and binding refusal `compile` would
-raise), compile to emit, then run the product's static check on the artifact.
-There is no compiled-artifact `check`; `validate` is that rung.
-
-The full sequence, in order — `registry prepare` appears only where `check`
-names it, never before the source exists:
-
-```bash
-uip maestro flow check .flow-sdk/<Name>.flow.ts --source
-# run each prepare the check names, with the exact command it prints:
-uip maestro registry prepare <key> <action> [--object <name>] [--resolve <field>:<by>=<value>] [-f <parent>=<value>]
-uip maestro flow check .flow-sdk/<Name>.flow.ts --source    # re-check until clean
-uip maestro flow compile .flow-sdk/<Name>.flow.ts -o <Name>.flow
-uip maestro flow validate <Name>.flow --output json
-```
-
-Warnings require deliberate review; whether one blocks a release comes from the
-surrounding task or release policy.
-
-Layout is deliberately absent from this sequence. `uip maestro flow format`
-is not an authoring gate — `validate` passes without it and nothing upstream
-reads a position. It is required before the emitted file reaches anything that
-draws it: `solution upload`, `flow debug`, or a person opening the project in a
-designer. See [`operate.md`](operate.md#lay-out-the-emitted-flow-first).
-
-These authoring verbs require a prerelease of `@uipath/cli` that exposes them.
-
-## Product-CLI scaffold
-
-Product debug needs a solution containing a Flow project. Keep the authored
-source in the project's own `.flow-sdk/` (`<Solution>/<Name>/.flow-sdk/`), run the
-SDK verbs from the project folder, and create the nested scaffold once:
-
-```bash
-uip solution init <Solution>
-( cd <Solution> && uip maestro flow init <Name> --sdk-source )
-```
-
-`--sdk-source` seeds `<Solution>/<Name>/.flow-sdk/<Name>.flow.ts` from the stub `flow init` just wrote (and creates the folder), so the flow's id and name come from the product instead of being invented, and the stub is overwritten in place by the first `compile -o`.
-Drop `--sdk-source` when the source already exists (`init` refuses to overwrite it without `--force`), and skip the whole block for an existing project.
-For a **Maestro Automate** project (the request names that product, not just the verb "automate"), add `--automate` to the `flow init` line; nothing else in either loop changes.
-
-`<Solution>` and `<Name>` are the request's own names, used verbatim: a request
-that gives one name for both ("inside a solution of the same name") uses it for
-both, and a request that names only the Flow uses `<Name>` for both. The result
-has three related names: `.flow-sdk/<Name>.flow.ts`, the `<Name>` project directory, and
-`<Name>.flow` inside that project. Keep them aligned for this scaffold so each
-command addresses the intended project; `compile -o` remains the authority over
-where the emitted file is written.
-
-## Eval/product-CLI packaging: emit-only
-
-The product-runtime eval sets `flowSdk.emitOnly` in `package.json` (with
-`FLOW_SDK_EMIT_ONLY=1` retained as an environment override). Emit-only is a
-property of the **project**, not of the directory you run from: the mode is the
-nearest `package.json` up the tree that actually declares `flowSdk.emitOnly`, so
-compiling from a scaffolded solution subdirectory behaves exactly as it does
-from the project root. A nested `package.json` that says nothing about `flowSdk`
-inherits; one that sets `emitOnly: false` opts out. In that mode
-`uip maestro flow compile` only serializes source, and `uip maestro flow check`
-refuses, because product validation owns structural verification. The required
-base pass is emit, any required artifact bindings, then validate. Add resource
-refresh and debug only when the stated acceptance bar requires product-runtime
-behavior evidence:
-
-```bash
-( cd <Solution>/<Name> && uip maestro flow compile .flow-sdk/<Name>.flow.ts -o <Name>.flow )
-uip maestro flow validate <Solution>/<Name>/<Name>.flow --output json
-# Before anything opens the emitted file — upload, debug, or a designer:
-uip maestro flow format <Solution>/<Name>/<Name>.flow --output json
-# Only for a stated runtime-behavior claim:
-( cd <Solution> && uip solution resources refresh --solution-folder . --output json )
-( cd <Solution> && uip maestro flow debug <Name> --log-level error \
-  --output-filter "{status:finalStatus,instance:instanceId,url:studioWebUrl,failed:elementExecutions[?status!='Completed'].{id:elementId,status:status},globals:variables.globals}" \
-  --output json )
-```
-
-This loop has exactly one emitted artifact:
-`<Solution>/<Name>/<Name>.flow`. Never emit a second root-level `<Name>.flow`;
-validators and evidence collectors cannot choose safely between duplicates.
-Re-run the whole sequence after the final source or binding edit.
-
-## Product validation and conditional bindings
-
-### Reading product validation
-
-The JSON envelope has top-level `Result`; a successful validation also reports
-`Data.Status: "Valid"` and may carry `Data.Warnings`. Treat warnings as failures
-except for the reviewed shared-connection advisory. Preserve any exception's
-exact code/text and rationale instead of broadening an allowlist.
-
-### Bounded completion
-
-Match the final evidence to the stated acceptance bar after the last edit:
-
-- For a validate-only bar, `Data.Status: "Valid"` plus the required structural
-  self-check is completion. Stop there; do not run debug only for confidence.
-- For each distinct behavior claim named by the bar, plan at most one bounded
-  debug with the inputs and attachments that exercise it. One run may cover
-  compatible claims; do not repeat equivalent inputs.
-- If one unknown still blocks the final wiring, run one bounded experiment that
-  distinguishes the choices, apply its answer, and return to the final
-  emit/validate pass. Do not create a scratch-solution family.
-
-If the requested evidence cannot be obtained inside that bound, report the
-evidence boundary instead of replacing it with repeated debug launches.
-
-### Managed HTTP: authored connection bindings
-
-`http({ managed: true, ... })` needs real connection and folder bindings for
-connector-authenticated product debug. Select an enabled HTTP connection:
-
-```bash
-uip is connections list --all-folders \
-  --output-filter "[?ConnectorKey=='uipath-uipath-http'].{Id:Id,FolderKey:FolderKey,Name:Name}"
-```
-
-Declare symbolic entries in `bindings.json`, then pass both names to the node:
-
-```ts
-http({ managed: true, method: 'GET', url: '/me',
-  connection: 'spotifyHttp', folder: 'shared' })
-```
-
-Compilation resolves those names and writes both the connector-authenticated
-node detail and the required product bindings into the emitted `.flow`. Do not
-patch them into the artifact after emission; that edit would be lost on the next
-compile. Omit both options only when manual/implicit authentication is intended.
-
-## Refresh, debug, and preserve evidence
-
-`flow debug` takes the project directory, not the `.flow` file, and resource
-refresh must run first. From the solution directory, `<Name>` names that project.
-These are the common flags; use only the ones the behavior claim needs:
-
-| Need | Exact form |
-|---|---|
-| JSON inputs | `-i '{"name":"value"}'` or `--inputs @inputs.json` |
-| File input | `--attachment <input-name>=<path>`; repeat for multiple files |
-| Folder | one of `--folder-id`, `--folder-key`, or `--folder-path`; omit to auto-detect |
-| Poll bound | `--timeout <seconds> --poll-interval <milliseconds>`; keep the stated task bound |
-| Compact read-back | `--output-filter "<JMESPath>" --output json` |
-| Quiet logs | `--log-level error`, or `--log-file <path>` to move them off the stream entirely |
-
-### `--output-filter` is JMESPath, and three things about it are worth knowing
-
-**A string literal is `'single-quoted'`, not `` `backticked` ``.** Backticks
-delimit a JSON literal, so `` `Completed` `` is a syntax error — bare words are
-not JSON. Both forms below work; prefer the first, because its failure is loud.
-Wrap the whole expression in DOUBLE quotes so the inner `'…'` survives the shell:
-
-```bash
---output-filter "elementExecutions[?status!='Completed']"     # raw string literal
---output-filter 'elementExecutions[?status!=`"Completed"`]'   # JSON literal
-```
-
-**The projection selects from `Data`, not from the envelope.** `Result` and
-`Code` stay at the top level and are still printed, so a filter naming
-`finalStatus` reads `Data.finalStatus`.
-
-**Filter, do not post-process.** `--output-filter` is cheaper and less brittle
-than piping the whole envelope through `jq`, and much cheaper than hunting for
-the JSON inside interleaved log lines. If a filter is rejected, fix the
-expression rather than falling back to `--output json | jq` — a rejected filter
-exits non-zero with the parse error, so the fix is usually one edit.
-
-### Ready-made projections — copy one, do not compose your own
-
-These are verified against a real `flow debug` envelope. Pick the narrowest one
-that answers the claim; composing a projection from scratch is what turns a
-read-back into seven tool calls.
-
-```bash
-# Did it finish? The cheapest possible check.
---output-filter "{status:finalStatus,instance:instanceId}"
-
-# The standard read-back: status, where to look, what did NOT complete, all globals.
---output-filter "{status:finalStatus,instance:instanceId,url:studioWebUrl,\
-failed:elementExecutions[?status!='Completed'].{id:elementId,status:status},\
-globals:variables.globals}"
-
-# Just the values the flow produced.
---output-filter "variables.globals"
-
-# Every element's status, when you need the path the run actually took.
---output-filter "elementExecutions[].{id:elementId,status:status}"
-```
-
-**`variables.globals` is a FLAT map, and its keys contain dots.** A step output is
-`"<step>.output.<field>"`, alongside the bare name of every declared global:
-
-```jsonc
-{ "product": 42, "start.output.a": 6, "multiply.output": 42, "multiply.error": null }
-```
-
-So a bare global reads as `variables.globals.product`, and a dotted key needs
-quoting — which flips the shell quoting, because the expression now contains
-double quotes instead of single ones:
-
-```bash
---output-filter '{status:finalStatus,raw:variables.globals."multiply.output"}'
-```
-
-**There is no `incidents` in this envelope.** `Data` carries exactly
-`finalStatus`, `instanceId`, `studioWebUrl`, `jobKey`, `runId`, `folderKey`,
-`solutionId`, `variables` and `elementExecutions` — an `incidents:incidents`
-projection silently yields `null`. Incidents come from the separate
-`debug-instance incidents` call below, keyed by the `instanceId` you just read.
-
-For example, a direct-input claim can keep the useful status, outputs, and
-diagnostics in one read-back instead of printing the full execution envelope:
-
-```bash
-( cd <Solution> && uip solution resources refresh --solution-folder . --output json )
-( cd <Solution> && uip maestro flow debug <Name> --log-level error \
-  --inputs @inputs.json \
-  --output-filter "{status:finalStatus,instance:instanceId,url:studioWebUrl,failed:elementExecutions[?status!='Completed'].{id:elementId,status:status},globals:variables.globals}" \
-  --output json )
-```
-
-The top-level envelope still carries `Result`; the projection above selects
-from `Data`. Read and retain `Result`, the projected status/instance/URL, the
-`failed` element executions, and the globals the claim needs.
-`Completed` with the expected globals and an empty `failed` is evidence for the
-product-runtime path; a bare process exit code is not. Omit the filter only when
-diagnosing a field the projection did not retain.
-
-Incidents are **not** in this envelope — fetch them by the `instance` you just
-read, and only when something actually failed.
-
-For a fault, query the backend incident payload with the returned instance id:
-
-```bash
-uip maestro flow debug-instance incidents <instanceId> \
-  --output-filter "[*].{E:ElementId,C:ErrorCode,M:ErrorMessage,D:ErrorDetails}"
-```
-
-`ErrorDetails` commonly contains the service response or unresolved-resource
-value that the summary message omits.
-
-## CLI output conventions
-
-Use `--output json`, not `--format json`. Use `--output-filter '<JMESPath>'` to
-select fields from `Data`. Some successful commands print update/progress text
-to stderr, so judge success from the structured `Result`, status, outputs, and
-incidents rather than from the presence of stderr.
-
-Product debug creates real side effects. Use sandbox resources and serialize
-runs that share queues, issues, mailboxes, or other mutable tenant state.

package/skills/uipath-maestro-flow/references/agent-resources.md

@@ -1,74 +0,0 @@
-# Agent resource families
-
-*Exact signatures, fields, and defaults: `inlineAgent()`. Prompting, inputs and the sidecar: [inline-agent.md](inline-agent.md).*
-
-An inline agent's capabilities are ARTIFACT nodes hanging off its own handles — tools on `tool`, a context index on `context`, an escalation on `escalation`, a memory on `memory` — not steps in the control flow.
-Each is authored as an entry on `inlineAgent`, and the compiler emits the node and the edge.
-Context index: [inline-agent.md](inline-agent.md#context-grounding).
-
-```ts
-.step('triage', inlineAgent({
-  model: 'gpt-5.4', systemPrompt: '…', userPrompt: '…',
-  tools: [
-    { kind: 'mcp', name: 'Ticket MCP', key: '<guid>', slug: 'ticket-mcp', folderPath: 'Shared' },
-    { kind: 'a2a', name: 'Research Agent', key: '<guid>', slug: 'research-agent' },
-    { kind: 'clientside', name: 'pickFile', inputs: { prompt: 'string' }, returns: { path: 'string' } },
-    { kind: 'httpRequest', url: 'https://api.example.test/items', method: 'GET' },
-    { kind: 'function', key: '<guid>', name: 'acme-echo', folderPath: 'Shared/acme-echo' },
-  ],
-  memory: { name: 'Support History', id: '<guid>' },
-  escalation: [{ variant: 'quick-form', name: 'Confirm', outcomes: ['Approve', 'Reject'],
-    fields: [{ id: 'approved', type: 'boolean', direction: 'output' }] }],
-}))
-```
-
-## Tool kinds
-
-| Kind | What it is | Identity you must supply |
-| --- | --- | --- |
-| `builtin` | A platform tool (`summarize`, `analyzefiles`, `batchtransform`) | the tool name |
-| `connector` | An Integration Service operation | `connector` + `operation` (needs a library), plus `connection` + `folder` (`bindings.json` labels) — see [inline-agent.md](inline-agent.md#tools) |
-| `process` / `api` / `flow` / `maestro` / `agent` / `function` | A deployed resource | `key` (GUID) + `name` + `folderPath` |
-| `ixp` | A published IxP project | `projectId` + `name` |
-| `mcp` | An MCP server's tools | `name` + `key`; `slug` is what the runtime resolves |
-| `a2a` | A remote agent to delegate to | `name` + `key` + `slug` (required) |
-| `clientside` | The CALLING application runs it | `name`, plus the `inputs`/`returns` contract |
-| `httpRequest` | The built-in HTTP tool | nothing — see below |
-
-For `mcp`, `a2a`, `memory` and the per-instance resource kinds, the node TYPE is
-minted from the identity you give (`…tool.mcp.<name-slug>.<key-slug>`), so a
-wrong key emits a node the tenant cannot resolve. Read them from the tenant.
-
-**The HTTP tool's fields are three-way.** Each of `url`, `method`, `headers`,
-`params`, `body`, `timeout` is either FIXED (give it a value) or left for the
-MODEL to fill at call time (omit it, which keeps the definition's prompt-mode
-default and its field description). Fixing everything defeats the point of
-giving an agent a tool; fixing nothing gives the model no constraints. Fix what
-the scenario pins and leave the rest.
-
-**A client-side tool declares only a CONTRACT.** The flow says what the tool is
-called and what it takes and returns; the calling application owns the
-implementation and dispatches on the name. Nothing local runs it.
-
-## Escalation
-
-The default variant is app-backed: `app: { key, name, folderPath }` names a
-deployed Action Center app that owns the form. `variant: 'quick-form'` puts the
-form INLINE instead — `fields` (the same rows a human task takes) and no `app`.
-`check` refuses the two mixed, in either direction.
-
-## Memory
-
-`memory: { name, id }` attaches an episodic memory so the agent learns from past
-runs, with optional retrieval tuning (`dynamicFewShotLearning`,
-`semanticSimilarity`, `kValue`, `searchMode`). Naming one selects the agent's
-**1.4** definition — the version that declares the `memory` handle. Omitting it
-leaves the agent on 1.2 exactly as before.
-
-## Evidence boundary
-
-Every resource here is tenant data, runtime behaviour, or both: no local rung
-calls an MCP server, delegates to a remote agent, retrieves a memory, or asks a
-client application to run a tool. Offline `validate` proves the minted node
-types, the wiring to the right handle, and the declared contracts. Whether the
-resources exist and what they return is platform evidence.