@uipath/skills 1.204.0 → 1.204.1

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

@@ -1,132 +0,0 @@
-# Inline Agent
-
-*Exact signatures, fields, and defaults: `inlineAgent()`.*
-
-An inline agent is defined inside this Flow project and may be connected to
-tenant context, callable tools, and human escalation resources.
-
-Signature:
-`inlineAgent({ model, systemPrompt, userPrompt, inputs?, returns?, source?, temperature?, maxTokenPerResponse?, modelMaxTokens?, maxIterations?, mode?, guardrails?, context?, tools?, escalation? })`.
-
-```ts
-.step('triage', inlineAgent({ model: 'gpt-5.4',
-  systemPrompt: 'Return a result conforming to the output schema. category: billing | technical | account.',
-  userPrompt: 'Classify {{input.body}}', inputs: { body: input('body') },
-  returns: { category: 'string' } }))
-```
-
-## Model and answer judgment
-
-Select a model currently available to the tenant (`uip agent model list`) and
-write prompts that make the requested decision and answer contract explicit.
-Static checks can establish wiring and output shape, never the semantic quality
-of the model's answer.
-
-`returns` is the answer contract: the agent runtime returns those fields as a
-typed object, so describe what each field holds ("Return a result conforming to
-the output schema. `<field>`: `<how to fill it>`.") and never ask for JSON text,
-which makes the model pack its whole answer into one string field.
-
-## Context grounding
-
-Context signature:
-`{ name, id, folderPath?, folderKey?, query?, retrievalMode?, resultCount?, threshold?, fileExtension? }`.
-
-Resolve the index from the tenant.
-Know the name: use `solution resources list` below.
-Discovering what exists: use the `uip context-grounding` bridge, which reports every index with its folder.
-Not `uip maestro flow registry` (node manifests), not `uip maestro registry` (the connector library), not `uip or folders list`.
-
-```bash
-uip solution resources list --kind Index --source remote --search "<index-name>" --output json
-```
-
-Maps onto the signature as `Key` → `id`, `Name` → `name`, `Folder` → `folderPath`, `FolderKey` → `folderKey`.
-Give `folderPath`: the emitted resource carries no index id, so the folder is half of how the runtime finds the index.
-
-Local execution has no semantic retrieval service, so an inline-agent answer is ungrounded even when the resource wiring is present.
-Platform evidence must establish that the intended index was used and that its retrieved knowledge influenced the answer.
-
-The `uip context-grounding` bridge runs in the project's Python environment.
-Activate the existing environment and run setup once before list/search; setup
-is the command itself, not a `setup --help` probe:
-
-```bash
-source .venv/bin/activate
-uip context-grounding setup
-uip context-grounding list --folder-path "<folder-path>" --format json
-uip context-grounding search \
-  --index-name "<index-name>" --query "<one bounded evidence query>" \
-  --folder-path "<folder-path>" --limit 5 --format json
-```
-
-Use `--folder-key` instead of `--folder-path` when that is the known identity.
-The delegated command uses `--format json`; it does not use the outer CLI's
-`--output json` spelling. One search that answers the stated grounding claim is
-enough; do not repeat paraphrases solely for confidence.
-
-## Tools
-
-Tool signatures:
-
-- `{ kind: 'builtin', tool: 'analyzefiles' | 'summarize' | 'batchtransform', ... }`
-- `{ kind: 'connector', connector, operation, connection, folder, version?, object?, name?, description? }`
-- `{ kind: 'process' | 'agent' | 'api' | 'flow' | 'maestro', key, name, folderPath, inputs?, returns? }`
-- `{ kind: 'ixp', projectId, name, description?, versionTag?, attachment? }`
-
-A connector tool needs `connection` and `folder`, `bindings.json` labels
-resolved like `connector()`'s (see [bindings.md](bindings.md)). Missing either
-is `INLINE_AGENT_TOOL_CONNECTOR_NO_CONNECTION` from `check`. `prepare` does not
-read a tool's labels from the source, so pass them:
-`uip maestro registry prepare <connector-key> --action <operation> --bind-connection <connection> --bind-folder <folder>`
-finds the connection and writes both entries under the tool's labels.
-`description` overrides the text the model is told the tool does; it defaults
-to the library's operation description.
-
-```ts
-tools: [{
-  kind: 'connector', connector: 'uipath-uipath-airdk', operation: 'web-search',
-  connection: 'genai', folder: 'shared',   // bindings.json labels
-}]
-```
-
-A tool is invoked by the model, not by a control-flow edge. Local execution
-skips tool resources, so it proves their wiring but not that the model called
-them. A live test needs a tool-specific side effect or returned witness.
-
-## Human escalation
-
-Escalation signature:
-`{ name, description?, app: { key, name, folderPath?, inputs?, outputs? }, recipients?, outcomes?, taskTitle?, priority?, labels? }`.
-
-Whether and when to escalate is model judgment, and completion additionally
-depends on a deployed app and a human. Local execution proves only resource and
-contract wiring; live evidence must show the task, reviewer outcome, and resumed
-agent behavior.
-
-## Live-evidence limit
-
-Headless local live mode calls a real model but substitutes a reachable model
-and remains ungrounded; it has no tenant tool loop or human escalation. Treat it
-as evidence that a real prompt produced the declared shape. Product debug is
-the evidence for the actual configured model and cloud resources.
-
-Compile emits the node plus a stable `<source>/agent.json` sidecar. Prompt variables
-use `{{input.<name>}}`; `inputs` binds those names to flow references and `returns`
-declares what the agent hands back.
-
-## Guardrails and harness mode
-
-`guardrails` is Agent Builder's own array, carried on the node and in the
-sidecar. Each rail is `$guardrailType: 'custom'` (with `rules`) or
-`'builtInValidator'` (with `validatorType` + `validatorParameters`), plus
-`id`, `name`, `selector: { scopes: ['Agent'|'Llm'|'Tool'] }`, an `action`
-(`block` with a reason, `filter` over fields, or `log` with a severity), and
-`enabledForEvals`. Custom rules are `$ruleType: 'word' | 'number' | 'boolean'`
-over a field selector, or `'always'`. A rail with no scopes or an empty rules
-array can never fire — `check` rejects both.
-
-`mode: 'standard' | 'advanced'` picks the harness; naming it selects the
-node's 1.3 definition (omitting it keeps 1.2 byte-identically) and lands on
-the sidecar's `settings.mode`. Guardrail/harness behavior is runtime-side:
-offline rungs prove the emitted shape only.

package/skills/uipath-maestro-flow/references/ixp.md

@@ -1,167 +0,0 @@
-# IxP Extraction
-
-*Exact signatures, fields, and defaults: `ixpExtract()`.*
-
-IxP extraction runs a published Intelligent eXtraction Platform project on a
-Flow attachment.
-
-Signature:
-`ixpExtract({ project, modelName, name, folderName, fileRef, pageRange?, versionTag?, folderPath?, description? })`.
-
-```ts
-.step('extract', ixpExtract({ project: ixpNodeType,
-  modelName: 'invoice-model', name: 'Invoice Extractor',
-  folderName: 'Shared', fileRef: out('start', 'invoiceFile') }))
-```
-
-## Listing published models
-
-"What document extractors can I add to this flow?", "what IxP models can I use here?", "list published extractors", "what extraction nodes are in the registry?" — these ask what the tenant publishes.
-They are not build requests.
-One search answers them:
-
-```bash
-uip login status --output json      # without login, tenant IxP nodes are hidden
-uip maestro flow registry pull --force
-uip maestro flow registry search 'uipath.ixp' -f 'type:startsWith=uipath.ixp' --output json
-```
-
-Each `Data[]` entry is one published model (a.k.a. runtime project) visible to the flow registry on this tenant.
-Present `DisplayName`, `NodeType` and `Version` as a table, and stop.
-
-Rules for the listing path:
-
-- **Do NOT call `registry get` on the search hits.** The search result already carries every field the answer needs. `registry get` resolves ONE node's authoring identity, so running it per hit turns a one-second answer into a call per published model — measured at 80 calls and 127 seconds on a tenant with 40 of them. Fan it out only when authoring a specific node, and then for that node alone.
-- **Do NOT scaffold a solution, run `uip maestro flow init`, or write a `.flow.ts` or `.flow` file.** Listing is read-only Q&A.
-- **Do NOT mock.** If `Data: []`, answer directly that no IxP models are published on this tenant. The `mock()` fallback is for build-time planning, not for listing-time Q&A.
-- **Do NOT log in for the user.** If `uip login status` shows logged-out, tell the user to run `uip login` and stop — listing without auth returns OOTB-only results and is misleading.
-- **Do NOT search by `runtime`, `document extractor`, `extractor`, or `IXP` (uppercase).** These return empty results or agent-tool variants, not extraction nodes. Use `uipath.ixp` (lowercase) only.
-- **Do NOT switch to the `uipath-ixp` skill.** `uip ixp projects ...` lists IxP-product projects, not what is wired up for Maestro.
-- **Do NOT use `uip maestro flow process list` or any Orchestrator folder iteration.** `flow process list` enumerates deployed flow process instances, not published models.
-- **Do NOT guess `uip maestro flow list-*` or `uip maestro ixp list-*` subcommands.** None exist; the CLI returns `unknown command` and there is no fallback path to pursue.
-
-A `uipath.agent.resource.tool.ixp.*` hit on a broader `ixp` search is the agent-tool variant, not a flow extraction node.
-Treat it as "no extraction model published", and stop searching after that one broader check — do not iterate on registry searches.
-
-## Resource identity
-
-This is the AUTHORING path, for the one model a step will run.
-To answer "which models exist", see [Listing published models](#listing-published-models) instead — the search alone answers that, and `registry get` must not be fanned out across its hits.
-
-Refresh the registry first, then copy the complete node type and its companion
-defaults. The node type is tenant/version identity, not a string to reconstruct:
-
-```bash
-uip maestro flow registry pull --force
-uip maestro flow registry search '<project hint>' \
-  -f 'type:startsWith=uipath.ixp' \
-  --output-filter '[?AvailableOnTenant].NodeType' --output json
-uip maestro flow registry get '<node-type>' \
-  --output-filter '{project:Node.nodeType,modelName:Node.inputDefaults.modelName,folderName:Node.inputDefaults.folderName,folderPath:Node.inputDefaults.model.folderPath,versionTag:Node.inputDefaults.versionTag,taxonomyProject:Node.inputDefaults.projectName}' \
-  --output json
-```
-
-`registry get` is the authoring source of truth for ONE node. Copy `project`, `modelName`,
-`folderName`, `folderPath`, and `versionTag` from that response; do not switch to
-`uip ixp projects ...` or reconstruct the deployment through other IxP APIs.
-`--output-filter` runs against the response's `Data` field, so registry-get paths
-start at `Node`. The compact projection avoids materializing the full schema.
-
-When code must read selected extraction fields, inspect only the two result-item
-schemas:
-
-```bash
-uip maestro flow registry get '<node-type>' \
-  --output-filter '{scalarResultMembers:keys(Node.outputDefinition.output.schema.properties.ExtractionResult.properties.ResultsDocument.properties.Fields.items.properties),tableResultMembers:keys(Node.outputDefinition.output.schema.properties.ExtractionResult.properties.ResultsDocument.properties.Tables.items.properties)}' \
-  --output json
-```
-
-Scalar results are under `ExtractionResult.ResultsDocument.Fields[]`; table
-results are under `ExtractionResult.ResultsDocument.Tables[]`. In both arrays,
-`FieldName` identifies the model field and `Values` carries its extracted values.
-
-If the registry has no suitable published extractor, the requested acceptance
-bar determines the next step. For a runtime or published-model requirement,
-report the missing capability and stop. For a validate-only topology whose
-purpose is to show where extraction belongs, put `mock()` in the extraction
-position, complete and validate the surrounding flow, and report the placeholder
-as the capability gap. Do not block a validate-only topology on an unavailable
-extractor or downstream endpoint when placeholders preserve the requested graph.
-`pageRange` is a product string; examples such as `1-5` are illustrative because
-no local grammar is published.
-
-## File input from a connector event
-
-Read the trigger's `outputResponseDefinition` and pass the exact file-reference
-field to `fileRef`. For example, a SharePoint-backed event that declares
-`ReferenceID` is wired as `fileRef: out('start', 'ReferenceID')`. This direct
-connector-event-to-IxP shape passes product validation; do not add a download
-action merely to change the shape for a validate-only flow.
-
-The SDK emits that `out(...)` handoff in the one envelope the IxP validator
-accepts — a plain expression string:
-
-```json
-"fileRef": "=js:$vars.start.output.ReferenceID"
-```
-
-Do not replace it with a `{ "type": "jsExpression", ... }` envelope or a
-hand-built attachment object. Add a download action only when the discovered
-trigger contract has no file-reference field and requested runtime behavior
-requires the file bytes.
-
-## Joined document-event recipe
-
-`documentCreated` is the event subscription resolved from its live connection;
-`extractor` is the identity object copied from `registry get` as described above.
-The trigger field flows straight into extraction, and the whole result flows
-straight into delivery:
-
-```ts
-const documentCreated = {
-  connector: 'uipath-microsoft-onedrive', event: 'file-created',
-  connection: 'documents', folder: 'documentsFolder',
-};
-
-export default flow('archive-card-intake')
-  .trigger(onEvent(documentCreated))
-  .step('extract', ixpExtract({
-    ...extractor,
-    fileRef: out('start', 'ReferenceID'),
-  }))
-  .step('deliver', http({
-    method: 'POST', url: 'https://catalog.example.test/cards', managed: false,
-    body: out('extract'), contentType: 'application/json',
-  }))
-  .build();
-```
-
-## Downstream output
-
-`out('<ixp-step>')` is the extraction result object and can be forwarded as a
-whole, including as an HTTP request body. Pass the expression directly; no
-serializer inspection or taxonomy lookup is needed for that shape. The joined
-recipe above shows the complete handoff.
-
-A model taxonomy is needed only when the flow must select named extracted
-fields. If the trained model version is already known, run
-`uip ixp deployments get-taxonomy '<taxonomyProject>' --version <number>` once.
-Retry the same command at most once, and only when the response says
-`RetryLater` or reports a transient 5xx failure. Do not retry validation errors
-or `RetryWillNotFix`, and do not explore `uip ixp projects ...` to reconstruct
-the deployment. If the one retry also fails, use defensive reads from the
-`Fields[]` or `Tables[]` paths above, state the assumed field names, and finish
-the compile/validation loop. This is interim guidance for
-[UiPath/cli#3512](https://github.com/UiPath/cli/issues/3512).
-
-## Recovery and evidence
-
-Wire `.onError(...)` when unreadable documents or no-match results should follow
-a recovery path; otherwise failing loud may be the correct scenario behavior.
-Local execution uses an extraction fixture and proves wiring only. Product
-debug is required only when the acceptance bar asks for proof that the chosen
-model processed a real file or returned semantically correct fields. For a
-validate-only bar, green product validation plus the intended emitted wiring is
-complete.
-
-The compiler also emits the project's `ixpDeployment` bindings.

package/skills/uipath-maestro-flow/references/loops.md

@@ -1,77 +0,0 @@
-# Loops
-
-Loop runs a body for every member of a collection.
-
-Signature: `.loop(name, collection, bodyFn, options?)`.
-
-```ts
-.loop('eachOrder', input('orders'), (body) => body
-  .step('handle', script({ code:
-    'return { id: $vars.eachOrder.currentItem.id };' })))
-```
-
-The SDK does not expose mutation of a Flow variable on each iteration. Keep
-per-item dispatch and decisions in the body. If work after the loop needs a
-summary, compute it from data already available outside the loop or use a
-dedicated step whose contract supplies that aggregate.
-
-Use a one-armed branch to skip the rest of one iteration without terminating
-the run. When the condition is false, that iteration completes and the loop
-advances:
-
-```ts
-.loop('eachRepo', input('repos'), (body) => body
-  .step('fetch', http({ managed: false, url: 'https://example.test',
-    returns: { name: 'string' } }))
-  .branch('found', js`$vars.fetch.output.statusCode !== 404`,
-    (yes) => yes.step('notify', script({
-      code: 'return $vars.fetch.output.body.name;' }))))
-```
-
-The loop runs sequentially (`parallel: false`). Inside the body, read
-`$vars.<loop>.currentItem` and `$vars.<loop>.currentIteration` — or
-`v('eachOrder.currentItem')` from the builder.
-
-`currentIndex` is the field name of the legacy loop 1.0.0. On the default 2.4
-loop it reads `undefined`, so `check` refuses it (`UNKNOWN_LOOP_FIELD`) and
-suggests `currentIteration - 1` for a 0-based index. Do not rely on the exact
-base of `currentIteration` yet: the 2.4 definition documents it as 1-based,
-but the local engine (`flow-debug`) currently reads 0 for the first item, and
-the cloud runtime is not yet verified
-([flow-builder-sdk#874](https://github.com/UiPath/flow-builder-sdk/issues/874)).
-If a flow's result depends on the number, confirm it with a live
-`uip maestro flow debug` run.
-
-The item is named after the LOOP, not after the collection and not by a
-convention: **there is no `$vars.item`, `$vars.currentItem` or `$vars.<collection>`.**
-A branch or step that decides on the item has to name the loop, so a loop called
-`eachIssue` reads `$vars.eachIssue.currentItem.priority` — never
-`$vars.item.priority`, which resolves to nothing and takes the false arm on every
-iteration without erroring.
-
-## Loop options
-
-Every `.loop()` emits the loop's 2.4 definition (inner `start`/`continue`/`break`
-handles), the version the registry serves and the designer authors. The legacy
-1.0.0 shape (body from `output`, back-edge into `loopBack`, `currentIndex`) is
-emitted only for an explicit `{ version: '1.0.0' }`, which accepts none of the
-options below.
-
-- `parallel: true` — run iterations concurrently instead of sequentially.
-- `completionCondition` — an expression checked after each iteration; the loop
-  stops early when it is true.
-- `body.break()` — exit the whole loop from inside an arm. Terminal on its
-  path, like `.terminate()` but scoped to the loop; using it shows the loop's
-  break handle automatically (`breakEnabled`).
-
-```ts
-.var('found', types.string, '')
-.loop('scan', input('items'), (body) => body
-  .step('probe', script({ code: 'return $vars.scan.currentItem;', returns: 'object' }),
-    { updates: { found: js`$vars.probe.output.id` } })
-  .branch('hit', js`$vars.probe.output.score > 90`, (t) => t.break()),
-  { completionCondition: js`$vars.found !== ""` })
-```
-
-Per-iteration flow-variable writes go through `{ updates }` on a body step —
-`{ updates: { seen: js`$vars.seen + 1` } }` — never through a mutation node.

package/skills/uipath-maestro-flow/references/manual-trigger.md

@@ -1,39 +0,0 @@
-# Manual Trigger
-
-The manual trigger is the default start node. It represents an on-demand call
-from a person, test, API, or parent automation; there is no factory call.
-
-Signature: omit `.trigger(...)` and declare caller values with `.input(...)`.
-
-```ts
-export default flow('lookup').input({ id: types.string }).output({ value: types.string })
-  .step('read', script({ code: 'return $vars.start.output.id;' }))
-  .return({ value: out('read') }).build();
-```
-
-Choose this trigger only when something will supply each run's inputs. A local
-run is a valid execution of that contract, but it does not prove that any
-external caller or deployment integration exists.
-
-A flow's declared inputs are published as the trigger node's OUTPUT, so
-`input('name')` reads `$vars.start.output.name` — `out('start', 'name')` is the
-same reference spelled the long way. Both spellings run: the bare `$vars.name`
-resolves identically on the real runtime. Prefer the trigger form anyway — it is
-what the designer TYPES the expression scope as, so a bare read is the one the
-canvas reports as "Property 'name' does not exist".
-
-This holds for EVERY trigger kind, not just the manual one. A declared input is
-bound to whichever node starts the flow (that binding is the `triggerNodeId` on
-the emitted variable), so an `onEvent(...)` flow reads its inputs through its
-trigger too. The difference is only in what ELSE is there: an event trigger's
-output carries the connector's payload alongside the declared inputs, so
-`$vars.start.output.subject` and `$vars.start.output.queueName` can both be
-live references on the same node.
-
-The node's id is `start` by default and is addressable. Rename it with
-`.triggerId('intake')` and every input reference follows
-(`$vars.intake.output.name`).
-
-Inside a `subflow` body the same form addresses the CHILD's own start node,
-which the compiler names `<callerStepId>Start` — `input()` renders it for you,
-so this matters only if you hand-write a `$vars.…` string in a child script.

package/skills/uipath-maestro-flow/references/operate.md

@@ -1,204 +0,0 @@
-# Operate — ship, run, and manage a deployed flow
-
-Everything that touches the cloud: upload, deploy, debug, trigger, inspect, and
-instance lifecycle. All of it needs `uip login`; check with
-`uip login status --output json`.
-
-Authoring is upstream. Do not ship a flow whose source has not been through the
-loop in [`CLI-LOOP.md`](CLI-LOOP.md) — `check` on the source, `compile` to emit,
-`validate` on the emitted `.flow`.
-
-## Lay out the emitted flow first
-
-```bash
-uip maestro flow format <Name>.flow --output json
-```
-
-Layout is not an authoring concern — nothing upstream needs it, and `validate`
-passes without it. It becomes one here, the moment the emitted file is opened
-by something that draws it: `solution upload`, `flow debug`, or a person
-opening the project in a designer. Run `format` before any of those, on the
-artifact as last emitted.
-
-`compile` writes a placeholder `ui.position` on each node and no top-level
-`layout` block at all — and the canvas renders from `layout`. The placeholders
-are one flat row, so a four-armed switch arrives as a single 3,000px line with
-the arms in sequence rather than side by side. `format` builds `layout`, fans
-the arms onto their own rows, sizes each node by its canvas shape, and reports
-`NodesRepositioned`. Skipping it is the most common cause of misshapen nodes in
-Studio Web.
-
-## Refresh solution resources first
-
-```bash
-uip solution resources refresh --solution-folder <SolutionDir> --output json
-```
-
-Run this before `solution upload`, `solution publish` or `flow debug`, every
-time. It syncs connection and process resource declarations from the project's
-`bindings_v2.json` into the solution, and a stale declaration fails at run time
-with a binding error even when the emitted `.flow` is correct — so the symptom
-never points at the cause.
-
-There is no positional solution argument. Omit `--solution-folder` only when the
-shell is already in the solution root.
-
-## Publish
-
-"Publish", with no target named, means **Studio Web**:
-
-```bash
-uip solution upload <SolutionDir> --output json
-```
-
-Pass the solution root — the directory holding the `.uipx` — or `.` from inside
-it. From a nested project folder pass `..` or the absolute path, never the
-solution name again: that resolves to a child path which does not exist. Report
-the Studio Web URL when it succeeds.
-
-Orchestrator is a different path, and only on an explicit request for it,
-because it bypasses Studio Web and the flow cannot be visualised or edited
-there:
-
-```bash
-uip maestro flow pack <project-path> <OutputDir>
-```
-
-then `uip solution publish` — see the `uipath-solution` skill. When the target is
-genuinely ambiguous, ask before packing.
-
-## Debug — a real end-to-end run
-
-```bash
-UIP_LOG_LEVEL=info uip maestro flow debug <project-dir> --output json
-```
-
-The argument is the PROJECT directory, the one holding `project.uiproj`.
-
-`flow debug` executes the flow for real: it sends the emails, posts the
-messages, calls the APIs. It is not a validation step — `validate` is. Run it
-when the request is for a flow that works; ask when the request stops at build
-or validate; and with nobody to ask, report the flow as unverified rather than
-letting a passing `validate` stand as the result. Never debug a solution this
-run did not scaffold: debug overwrites the Studio Web solution whose
-`SolutionId` matches the local `.uipx`.
-
-Operational constraints, each of which has its own failure:
-
-- **Foreground, with a tool timeout of 10 minutes or more.** It takes 1-5
-  minutes and prints its JSON only at exit, so a shell that kills commands after
-  1-2 minutes loses the whole payload.
-- **Poll the same process if the tool reports it still running.** An empty output
-  file means not finished, not failed.
-- **Never start a second debug while one is running.** It re-uploads and
-  re-executes.
-- **Re-run only after changing the flow.** Never to re-read or reshape output the
-  completed run already returned.
-- **`Debug polling timed out after <N>s` is not a failure.** The run continues
-  server-side. Take `instanceId` from stderr and poll
-  `uip maestro flow debug-instance status <INSTANCE_ID> --output json`.
-- **Do not pass `--folder-path` or `--folder-key`.** Debug provisions into your
-  personal workspace; a shared folder fails `HTTP 500` at
-  `Stage: prepare-custom-debug` with no instance started. Shared resources reach
-  the run through `resources refresh`, not through the debug folder. Use the flag
-  only when the account has no personal workspace, or the flow needs
-  folder-scoped assets or queues.
-
-Inputs, for a flow with `.input(...)` parameters:
-
-```bash
-UIP_LOG_LEVEL=info uip maestro flow debug <project-dir> --output json \
-  --inputs '{"numberA": 5, "numberB": 7}'
-```
-
-Build them from real records, never invented values: an invented key matches no
-record, the lookup returns `[]`, and the run faults on empty data. Read an entity
-id from `uip df entities list --output json`, then a live record from
-`uip df records list <ENTITY_ID> --output json`.
-
-A `types.file` input takes a local file instead, repeatable, and the left side is
-the input's own name:
-
-```bash
-  --attachment <inputName>=<localPath>
-```
-
-At run time that variable is an OBJECT, not a path — a script reads the uploaded
-name as `$vars.<triggerNodeId>.output.<inputName>.FullName`.
-
-**A conversational flow cannot be debugged headlessly.** On a flow whose trigger
-is `conversationTrigger()`, debug uploads, returns
-`Code: FlowDebugStudioWebHandoff` with `Data.studioWebUrl`, and starts no run;
-`--timeout` does nothing. Chat from Studio Web (`--open-in-browser` opens it) or
-the Maestro VS Code extension.
-
-### Reporting a debug run
-
-`Data.studioWebUrl` and `Data.instanceId` are the **first two lines** of any
-summary, before status text — they are what someone needs immediately, not after
-scrolling:
-
-```text
-Studio Web URL: <url>
-Instance ID: <instanceId>
-```
-
-Emit the label with `<not returned by CLI>` rather than dropping a line.
-
-`Data.finalStatus: "Faulted"` means the cause is already in that same response.
-Read it there rather than re-running. On a faulted run the CLI ignores
-`--output-filter` and prints the whole envelope, so redirect and search the file:
-
-```bash
-UIP_LOG_LEVEL=info uip maestro flow debug <project-dir> --output json > /tmp/flow-debug.json
-```
-
-## Trigger a deployed process
-
-```bash
-uip maestro flow process list --output json
-uip maestro flow process run <process-key> <folder-key> --output json \
-  --inputs '{"numberA": 5}' --attachment <inputName>=<localPath>
-```
-
-On `process run` only, `--attachment` overrides `--inputs` on a key collision,
-and `--validate` accepts pre-uploaded attachment references for file slots —
-they pass the JSON-schema check even though the slot's nominal type is `string`.
-
-## Inspect a job
-
-```bash
-uip maestro flow job status <job-key> --output json
-uip maestro flow job traces <job-key> --output json
-```
-
-Traces are the full execution timeline and are verbose. They are a last resort,
-not a starting point.
-
-## Instance lifecycle
-
-Every `instance` command needs `--folder-key` (`-f`) or it is rejected before
-reaching the API. Get one from `uip or folders list --output json`, or from the
-job or process context. The instance id comes from a debug run's
-`Data.instanceId`, a `job status` response, or `instance list`.
-
-```bash
-uip maestro flow instance pause  <INSTANCE_ID> -f <FOLDER_KEY> --output json
-uip maestro flow instance resume <INSTANCE_ID> -f <FOLDER_KEY> --output json
-uip maestro flow instance cancel <INSTANCE_ID> -f <FOLDER_KEY> --output json
-uip maestro flow instance retry  <INSTANCE_ID> -f <FOLDER_KEY> --output json
-```
-
-Never `retry` a faulted instance before reading why it faulted — the fault cause
-is in the debug response or the incident, and retrying without it repeats the
-failure. When each takes effect and what is recoverable is Orchestrator's
-lifecycle model, not this skill's; `uip maestro flow instance <sub> --help` has
-the flags.
-
-## Evidence boundary
-
-A green `validate` proves the emitted `.flow` is well formed. Only a run proves
-the flow works, and only against the tenant it ran on: an upload that succeeds
-says nothing about whether the connections resolve, and a debug run that
-completes says nothing about whether the answer was right. Report the instance
-identity and the status the CLI returned, not an inference from either.