@uipath/skills 1.204.0 → 1.204.1

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

@@ -1,77 +0,0 @@
-# Conversational
-
-*Exact signatures, fields, and defaults: `conversationTrigger()`, `waitForMessage()`, `sendMessage()`, `conversationContext()`, `conversationalAgent()`.*
-
-A chat-driven flow. A person opens a conversation; the flow waits for their
-message, answers it, and can post messages of its own. Every step is keyed by a
-`conversationId`, which the conversation TRIGGER publishes as
-`out('start', 'conversationId')`.
-
-```ts
-export default flow('support-chat')
-  .trigger(conversationTrigger())
-  .step('listen', waitForMessage({ conversationId: out('start', 'conversationId') }))
-  .step('reply', conversationalAgent({
-    model: 'gpt-5.4',
-    systemPrompt: 'You are a support agent. Be brief.',
-    settings: { context: out('listen', 'conversationContext') },
-  }))
-  .step('closing', sendMessage({
-    conversationId: out('start', 'conversationId'),
-    exchangeId: out('listen', 'conversationContext.latestExchangeId'),
-    content: 'Anything else I can help with?',
-  }))
-  .build();
-```
-
-## Conversations, exchanges, and messages
-
-Three nested things, and the field names follow them:
-
-- a **conversation** is the whole thread (`conversationId`);
-- an **exchange** is one user turn plus the answers to it (`exchangeId`);
-- a **message** is one utterance inside an exchange.
-
-`waitForMessage` returns the conversation CONTEXT, so the exchange to answer is
-a path inside it: `out('<waitStep>', 'conversationContext.latestExchangeId')`,
-and the transcript is `…conversationContext.messages`. (`out(step, path)`
-already inserts `.output` — do not write it again.)
-
-## Waiting versus reading
-
-`waitForMessage` **suspends** the flow — it is a `bpmn:IntermediateCatchEvent`
-on `Maestro.ReceiveMessageEvent`, the same mechanism as `waitForEvent`, so the
-run parks until the person speaks. `conversationContext` does NOT wait: it reads
-the transcript so far and continues. Reach for the first when the flow's next
-step depends on what the person says next, the second when it only needs
-history. Both cap how much history they return (`numExchanges` /
-`exchangeLimit`, 1–40, platform default 20).
-
-## Saying something: agent or flow
-
-`sendMessage` posts a message the FLOW composed — the role is always
-`assistant` and the content is Markdown (the node's only supported type), so
-neither is authored. `conversationalAgent` posts what a MODEL composed, reading
-the turn from `settings`:
-
-- `'simple'` mode (the default) takes ONE binding, `context`, and the platform
-  derives the conversation id, exchange id, transcript and user settings from
-  it. This is what you want almost always.
-- `'custom'` mode binds each field yourself, for a turn assembled from more
-  than one source; `conversationId` is then required.
-
-Either way the four derived fields are what the runtime reads — the platform's
-own editor calls them the source of truth and its validator rejects a node
-without `conversationId`, so the SDK emits them from your `context` binding
-rather than leaving them out. The agent's reply is
-`out('<step>', 'uipath__agent_response_messages')`, and compile writes a stable
-`<source>/agent.json` sidecar beside the `.flow` as it does for `inlineAgent`.
-
-## Evidence boundary
-
-The whole family is `AvailableOnTenant: false` today — the definitions are
-bundled from the workbench manifests, so a flow compiles and `validate`s
-offline, but nothing local starts a conversation or delivers a message. A green
-ladder proves the node types, the conversation/exchange wiring and the derived
-turn settings. A real thread, a real reply, and the agent's answer quality are
-platform evidence.

package/skills/uipath-maestro-flow/references/data-fabric.md

@@ -1,268 +0,0 @@
-# Data Fabric
-
-*Exact signatures, fields, and defaults: `dataFabricRead()`, `dataFabricCreate()`, `dataFabricUpdate()` and `dataFabricDelete()` for native CRUD, and `connector()` for the operations the native family still does not cover.*
-
-## One product, two surfaces
-
-"Data Fabric" and "Data Service" are **the same product under two names**: the
-tenant lists connector key `uipath-uipath-dataservice` with the display name
-**UiPath Data Fabric**, and `uip df entities` manages the entities both surfaces
-read.
-
-The native `core.datafabric.*` family covers all four CRUD verbs, so **CRUD on
-one entity is native work** — one surface, no connection binding, no `prepare`
-step.
-Reach for the connector when the flow needs something the family does not have.
-
-| Operation | Surface |
-| --- | --- |
-| Query records, with filters, limit, paging and sort | `dataFabricRead({ entity, filters, resultMode, limit, skip, sort, fields })` |
-| Create a record | `dataFabricCreate({ entity, values })` |
-| Update a record | `dataFabricUpdate({ entity, record, set })` |
-| Delete a record | `dataFabricDelete({ entity, record })` |
-| Get a record by id | `dataFabricRead({ entity, filters: [{ field: 'Id', value: … }] })` |
-| Upload / download / delete a file record field | `connector('uipath-uipath-dataservice', '…-file-…-record-field', …)` |
-| Record Created / Record Updated events | `onEvent(…)` on the same connector |
-
-Only the bottom two are connector work. A flow that needs one of them straddles
-both surfaces — a connection binding, a second payload shape, two things to
-debug — so when that is the shape of the work, route the whole entity through
-the connector instead of mixing.
-
-Data Fabric **events** (Record Created / Record Updated on an entity) are
-Integration Service connector events on `uipath-uipath-dataservice`, not this
-node family: `onEvent(RecordCreated, { object: '<Entity>', … })`, with the
-entity named through `object`. See
-[`event-trigger.md`](event-trigger.md#generic-events-name-the-object).
-
-## The four verbs
-
-```ts
-.step('lookup', dataFabricRead({ entity: 'Invoices',
-  filters: [
-    { field: 'InvoiceId', value: input('invoiceId') },
-    { field: 'Status', operator: '!=', value: 'Paid', or: true },
-  ] }))
-.step('markPaid', dataFabricUpdate({ entity: 'Invoices',
-  record: { fromRead: 'lookup' },
-  set: { Status: 'Paid', PaidBy: js`$vars.lookup.output.Approver` } }))
-.step('logIt', dataFabricCreate({ entity: 'PaymentLog',
-  values: { InvoiceId: input('invoiceId'), PaidOn: js`new Date().toISOString()` } }))
-.step('purge', dataFabricDelete({ entity: 'Drafts', record: { byId: input('draftId') } }))
-```
-
-## Filters and targeting
-
-A filter row is `{ field, operator?, value, or? }`. `operator` defaults to `'='`
-and is one of exactly ten spellings — `=` `!=` `>` `>=` `<` `<=` `contains`
-`starts with` `ends with` `in`. There is deliberately no `not in`, no
-`not contains`, and no null check: the serializer cannot emit them, and a filter
-it cannot emit takes the WHOLE query down rather than dropping one row.
-`in` is honoured only when `resultMode` is `'multiple'`.
-
-**The query model is disjunctive**, so `or: true` SPLITS the list rather than
-joining one row to the one before it. The whole query is `alt1 OR alt2 OR …`,
-and each alternative is an AND of its own rows; `or: true` opens a new
-alternative (and is ignored on the first row, which has nothing to split from):
-
-```ts
-filters: [
-  { field: 'Status', value: 'Open' },
-  { field: 'Priority', value: 'High', or: true },   // Status
-  { field: 'Region', value: 'EU' },                 //   OR (Priority AND Region)
-]
-```
-
-To express `(A OR B) AND C`, write it out as `(A AND C) OR (B AND C)` — the
-model has no other way to say it.
-
-A filter value must not be blank and must not reference `$self`: either one makes
-the serializer refuse the entire query, which leaves the step publishing nothing
-and strands every downstream `$vars` read of it. `check` rejects both.
-
-A filter on a choice-set column compares against the choice's numeric
-`numberId`, never its label — a label matches nothing, silently.
-
-`record` names the target row on **update and delete alike**, and takes exactly
-ONE of:
-
-- `{ byId: '<record id>' }` — a known record id, literal or expression;
-- `{ fromRead: '<step name>' }` — the record a preceding `dataFabricRead`
-  step returned. It must be a genuinely SINGLE-record read: a multi-record query
-  is refused as a write target, and the refusal is a no-op task, not an error —
-  the flow validates, runs green, and writes nothing. `check` rejects a
-  `fromRead` that names no read step (`DATAFABRIC_FROMREAD_UNKNOWN`) or names a
-  `resultMode: 'multiple'` one (`DATAFABRIC_FROMREAD_MULTIPLE`).
-
-`set` (update) and `values` (create) map field names to values, literals or
-expressions.
-Both are rejected when empty, and `values` is rejected when every value is BLANK:
-a blank is omitted from an insert so the column default applies, so an all-blank
-create writes nothing and runs green. Fix that with a real value, never a
-placeholder to satisfy the rule.
-
-**Type each flow input by the field it fills.** `uip df entities get <id>
---output json` gives each field's type at `Data.Fields[].FieldDataType.Name`; a
-value that arrives as a flow input takes the Flow type below, and reaches the
-step as `input('<name>')`:
-
-| Field type | Flow input |
-| --- | --- |
-| `STRING`, `MULTILINE_TEXT`, `UUID`, `DATE`, `DATETIME` | `types.string` |
-| `DECIMAL`, `INTEGER` | `types.number` |
-| `BOOLEAN` | `types.boolean` |
-| `FILE` | none — a file is not a create value; upload it with the connector's file-record-field operation (table above) |
-
-**System columns are never writable.** `Id`, `CreateTime`, `CreatedBy`,
-`UpdateTime`, `UpdatedBy` are assigned by Data Fabric; a write to one is rejected
-and the rejection is only logged, so the row comes back unchanged and the run
-goes green. `check` refuses them (`DATAFABRIC_SYSTEM_COLUMN`).
-
-A blank value means different things by verb: on create it is omitted so the
-default applies; on update it writes an explicit `null`, which a non-nullable
-column rejects. Check nullability with `uip df entities get`.
-
-## Query-many needs `resultMode`, and `resultMode` needs 1.4
-
-`core.datafabric.read` started as read-ONE ("Read entity") and became
-read-one-or-query-many at **1.4** ("Query entity records").
-`resultMode: 'single'` publishes one record as the step's `output`;
-`resultMode: 'multiple'` publishes the matching records under `output.results`.
-
-The SDK still pins **1.0** as the version a plain `dataFabricRead()` emits, the
-same way every family here keeps its older default — so passing `resultMode` is
-what selects 1.4, exactly as a Quartz `every` selects the scheduled trigger's
-1.2. Nothing else changes, and a read that wants one record can ignore all of
-this.
-
-```ts
-.step('open', dataFabricRead({ entity: 'Invoices',
-  filters: [{ field: 'Status', value: 'Open' }],
-  resultMode: 'multiple' }))          // → core.datafabric.read@1.4
-.loop('each', js`$vars.open.output.results`, (b) => b./* … */)
-```
-
-`dataFabricRead({ resultMode }, { version: '1.0' })` is refused at compile time
-rather than emitting an input the 1.0 definition does not declare.
-
-## Paging a list query
-
-`limit` is always applied — omitting it resolves to **100** — and **1000 is a
-hard ceiling**: a larger value truncates silently rather than erroring. Cover a
-bigger entity by paging with `skip`, and pair any limit with `sort` or the slice
-is arbitrary.
-
-```ts
-.step('page1', dataFabricRead({ entity: 'Invoices', resultMode: 'multiple',
-  limit: 1000, skip: 0, sort: { field: 'CreateTime', direction: 'desc' },
-  fields: ['Id', 'Status'] }))
-```
-
-The real audit columns are `Id`, `CreateTime`, `CreatedBy`, `UpdateTime`,
-`UpdatedBy` — there is no `CreatedAt`, and a sort on a column that does not exist
-is not caught by `validate`.
-`limit`, `skip`, `sort` and `fields` are list-query options: `check` refuses them
-on a single-record read.
-
-## A folder-scoped entity needs its bindings
-
-A **tenant-scoped** entity needs nothing but `entity` — it serializes as a dotted
-literal.
-
-A **folder-scoped** one needs `folderKey` AND `resourceKey` together. With only
-the folder key the entity serializes as a source-org literal: it validates, it
-runs in this org, and it breaks on deploy to another. `check` refuses either half
-alone (`DATAFABRIC_FOLDER_NO_RESOURCE_KEY`).
-
-```ts
-.step('read', dataFabricRead({ entity: 'Orders',
-  folderKey: '<the entity\'s folderId>', resourceKey: '<solution resource key>' }))
-```
-
-Supplying both emits the two `resource: 'Entity'` binding rows the platform
-matches on `propertyAttribute` (`name` and `folderKey` — never `folderPath`).
-Resolve the keys from the tenant:
-
-```bash
-uip df entities list --include-folders --output json   # folderId per entity
-uip solution resources list --kind Entity --output json # the resource key
-```
-
-Nothing mints a resource key for a hand-authored flow. If you cannot resolve one,
-keep the entity tenant-scoped and omit both — a half-authored folder scope is
-worse than none.
-
-## A delete publishes nothing
-
-`core.datafabric.delete` is the one verb of the family whose definition declares
-no outputs — the record is gone, so there is nothing to hand downstream.
-`$vars.<delete>.output` is undefined at run time, and `check` rejects the read
-(`DATAFABRIC_DELETE_HAS_NO_OUTPUT`).
-Take what the flow needs off the `dataFabricRead` step that FOUND the record,
-before the delete runs.
-
-## The connector path, end to end
-
-For the operations still on the connector, an entity operation's body fields come
-from the entity, so the static library cannot carry them — `compile` refuses them
-as unknown inputs until you resolve the schema once:
-
-```bash
-uip maestro registry prepare uipath-uipath-dataservice get-entity-record-by-id \
-  -f entityName=ContractRegistry
-# → .flow-sdk/connectors-local/ + .flow-sdk/bindings.json, with the entity's own fields as inputs
-```
-
-```ts
-.step('byId', connector('uipath-uipath-dataservice', 'get-entity-record-by-id',
-  { entityName: 'ContractRegistry', recordId: input('id') },
-  { connection: 'dataservice', folder: 'shared' }))
-```
-
-Full rules, including the parent-field (`GenerateSchema` over `entityName`)
-shape these operations use: [`connector-params.md`](connector-params.md).
-
-**Read the operation's own doc before guessing anything.** The connector library
-ships a Markdown page per operation, and an environment that stages a library
-points `$FLOW_SDK_LIBRARY_MD` at it (`uip maestro registry path --library-md --output plain`
-otherwise):
-
-```bash
-sed -n '1,60p' "$FLOW_SDK_LIBRARY_MD/uipath-uipath-dataservice/create-entity-record@1.0.0.md"
-```
-
-That page names the connector *UiPath Data Fabric*, gives the HTTP route
-(`POST /v2/{entityName}/CreateEntityRecord`), and prints the exact
-`prepare-connector … -f entityName=<value>` line to run — before any of it has to
-be inferred.
-
-## Evidence boundary
-
-The entity name and field names are tenant data — copy them from the scenario
-or the tenant, never invent them.
-
-**Entity and column names are case-sensitive, and an unmatched column is dropped
-rather than rejected** — a wrong name yields a node that validates green and
-writes nothing. Nothing offline can tell a real column from a typo, so resolve
-them first:
-
-```bash
-uip df entities list --native-only --include-folders --output json  # writes need a NATIVE entity
-uip df entities get <entity-id> --output json                       # exact column names and types
-```
-
-Two query options are documented by the platform but not applied by the
-converter the local engine runs: `limit`/`skip`/`sort` reach the file as
-`_recordLimit`/`_skip`/`_sort` and are read at run time, so `flow-debug` is not
-evidence either way for them.
-
-Offline `validate` proves only the emitted `entityConfig` SHAPE. It does not
-check whether a column exists, is writable, or has the type the value implies;
-whether the entity is native or federated; or whether a `byId` id matches
-anything. Every one of those validates clean and fails silently at run time, so
-green is not evidence here — the tenant is.
-
-A typed column also needs the canvas's `_outputSchema` snapshot to coerce
-values, and a dotted related path needs `_entityFields`. The SDK authors neither,
-so keep from-scratch nodes on the entity's own columns with string or expression
-values, and let the designer fill the snapshots in on first open.

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

@@ -1,26 +0,0 @@
-# Delay
-
-*Exact signatures, fields, and defaults: `delay()`.*
-
-Delay pauses the current path for a duration.
-
-Signature: `delay({ duration: string })` or `delay({ until: string })` —
-exactly one of the two arms.
-
-```ts
-.step('cooldown', delay({ duration: 'PT30S' }))
-.step('embargo', delay({ until: '2026-09-01T09:00:00Z' }))
-.step('resumedAt', script({ code: 'return new Date().toISOString();' }))
-```
-
-When the scenario needs a resume timestamp, compute it after the wait as shown.
-`until` is an ISO-8601 date-time and emits the node's absolute-date arm
-(`timerType: 'timeDate'`); an `until` in the past resumes immediately at run
-time, so compute future dates from the scenario, not from authoring day.
-
-Normal replay may skip real elapsed time. When timing is itself part of the
-requirement, use the real-time wait rung with a deliberately short fixture
-duration and measure before/after timestamps; product scheduling behavior still
-requires platform evidence.
-
-The duration is ISO-8601: `PT30S`, `PT15M`, `PT2H`, `P1D`, `P1W`.

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

@@ -1,141 +0,0 @@
-# Diagnose — why a run failed
-
-Triage order matters. Each step is cheaper and more specific than the next, and
-starting at the wrong end is how a diagnosis turns into twenty tool calls.
-
-1. **The debug response you already have.** A faulted run carries its own cause.
-2. **Incidents** on the instance.
-3. **Runtime variables** at the point of failure.
-4. **The deployed artifact** — what is actually on the tenant, not what is on disk.
-5. **Traces**, last. They are the whole execution timeline.
-
-Never start at traces, and never re-run `flow debug` to "get a better look" — a
-re-run executes the flow again for real and returns the same information the
-first one did.
-
-## Step 0 — read the cause in the output you already have
-
-`Data.finalStatus: "Faulted"` means the response in hand holds the reason. On a
-faulted run the CLI ignores `--output-filter` and prints the whole envelope, so
-redirect it and search the file rather than re-running:
-
-```bash
-UIP_LOG_LEVEL=info uip maestro flow debug <project-dir> --output json > /tmp/flow-debug.json
-```
-
-Look for the faulted element and its message. The node id in the fault maps
-back to the `.step('<id>', …)` that produced it, so the fix is usually a source
-edit rather than a platform question.
-
-## Incidents, variables, and the deployed artifact
-
-```bash
-# what went wrong
-uip maestro flow instance incidents <INSTANCE_ID> -f <FOLDER_KEY> --output json
-uip maestro flow incident get <INCIDENT_ID> -f <FOLDER_KEY> --output json
-uip maestro flow incident summary --output json          # across instances
-
-# state at the point of failure
-uip maestro flow instance variables <INSTANCE_ID> -f <FOLDER_KEY> --output json
-uip maestro flow instance variables <INSTANCE_ID> -f <FOLDER_KEY> \
-  --parent-element-id <ELEMENT_ID> --output json         # scoped to one element
-uip maestro flow instance element-executions <INSTANCE_ID> -f <FOLDER_KEY> --output json
-uip maestro flow instance cursors <INSTANCE_ID> -f <FOLDER_KEY> --output json
-
-# what is deployed, and which instances exist
-uip maestro flow instance asset <INSTANCE_ID> -f <FOLDER_KEY> --output json
-uip maestro flow instance list -f <FOLDER_KEY> --output json
-uip maestro flow instance get <INSTANCE_ID> -f <FOLDER_KEY> --output json
-
-# last resort
-uip maestro flow job status <job-key> --output json
-uip maestro flow job traces <job-key> --output json
-```
-
-All of these need `uip login`. Every `instance` command and `incident get` also
-needs `--folder-key` (`-f`) or it is rejected before reaching the API. Get the key from
-`uip or folders list --output json`, or from the job or process context.
-
-**Use these commands, never the underlying APIs.** The CLI applies the tenant
-and folder resolution the raw endpoints do not, so a direct call that appears to
-work is reading a different scope from the one the run used.
-
-When local and deployed disagree, the deployed artifact is the one that ran.
-A flow edited but not re-uploaded is the most common explanation for "I fixed
-that already".
-
-## Failure modes that survive the SDK path
-
-The builder makes several classic `.flow` defects unreachable — see the next
-section. These are the ones it does NOT:
-
-**An expression that is really a literal.** The builder does not force a `$vars`
-reference through `js\`…\`` or `out()`. A plain string containing
-`$vars.step.output` compiles to a bare literal with no `=js:` prefix, `check`
-reports no issues, and the node receives the text `"$vars.step.output"` at run
-time instead of the value. Symptom: a downstream node acting on a string that
-looks like an expression. Fix: `out('step')` or `` js`${out('step')}` ``.
-
-**A HITL outcome with no route.** More than one outcome routes per outcome by
-default, and an outcome with no arm leaves the run stalled when a reviewer picks
-it. `check` warns `HITL_OUTCOME_UNROUTED`; the warning is the diagnosis. Fix:
-`.stepSwitch` with an arm per outcome.
-
-**`Completed` with the work not done.** A node with error handling enabled and
-no handler, or an error edge routed back into the happy path, lets a failed step
-report success upward. Symptom: green run, absent side effect. Read the node's
-own status, not the run's.
-
-**A reused connection or resource key.** A key copied from another flow is
-well formed, so `check` and `validate` both accept it and the node faults at run
-time against a connection this tenant does not have. Read keys from
-`registry list --local` or the generated resource file, never from another
-project.
-
-**A single-nested project that upload rejects.** `uip maestro flow init` with
-`--skip-solution-registration` opts out of auto-scaffold and registration and
-leaves `<Project>/<Project>.flow` where `<Solution>/<Project>/<Project>.flow` is
-required; `Data.SolutionRegistration.Status` comes back `OptedOut` or
-`NotInSolution`, and upload and packaging both fail on structure. Without the
-flag, `flow init` outside a solution scaffolds and registers on its own, so this
-is opt-in rather than accidental. Fix by deleting the partial scaffold and
-running `uip solution init` then `flow init` from inside the solution; add
-`uip solution projects add` only if `Status` is not `Registered`. Carry
-`--automate` on the rebuild if the original was a Maestro Automate project — a
-`.maestro_automate` file in the project root says it was, and rebuilding without
-the flag silently returns a plain Flow.
-
-**Misshapen nodes on the canvas.** `compile` writes a placeholder
-`ui.position` on each node — all of them on one row — and no top-level `layout`
-block, which is what the canvas renders from. Symptom: the flow behaves
-correctly and is unreadable, a switch's arms strung out in a line instead of
-side by side. This is not a run-time fault and no check reports it — `validate`
-passes, because layout is not an authoring concern. Fix:
-`uip maestro flow format <Name>.flow`, which is owed before an upload, a debug,
-or anyone opening the project in a designer — see
-[`operate.md`](operate.md#lay-out-the-emitted-flow-first).
-
-**Green `validate`, faulted `debug`.** Structural correctness and runtime
-correctness are different claims. `validate` proves the emitted `.flow` is well
-formed; only a run proves the tenant resolves what it references. Start at
-step 0.
-
-## Failure modes the builder removes
-
-Do not spend triage on these — the compiler emits the structure that used to be
-missing. Verified against the SDK rather than assumed:
-
-| Classic `.flow` defect | Why it cannot happen here |
-| --- | --- |
-| `variables.nodes[]` missing, so `$vars.X.output` is undefined downstream | `compile` emits the node variable declarations unasked — a four-step flow gets eight entries |
-| `bindings[]` missing on a resource node, giving "Folder does not exist or the user does not have access" | `compile` derives the bindings from the node spec — an `agent(…)` step emits its `name` and `folderPath` bindings on its own |
-
-A defect in this table showing up in a real run means the artifact was
-hand-edited after `compile`, which is its own answer.
-
-## Evidence boundary
-
-A diagnosis is only as good as what was read. Name the artifact the conclusion
-came from — the debug envelope, the incident, the deployed flow — and say when a
-cause is inferred rather than observed. "The connector is misconfigured" read
-off a timeout is a guess; the same claim read off an incident's message is not.

package/skills/uipath-maestro-flow/references/document-pipeline.md

@@ -1,47 +0,0 @@
-# Document classify and Dynamic Extract
-
-*Exact signatures, fields, and defaults: `documentClassify()` and `dynamicExtract()`.*
-
-Two document steps that need no published IxP project: classification
-(`uipath.document.classify`) labels a document, and Dynamic Extract
-(`uipath.ixp.extract-document-builder`) pulls fields against a schema you
-author INLINE. For a published project's trained fields, use `ixpExtract`
-([ixp.md](ixp.md)) instead.
-
-Signatures: `documentClassify({ fileRef, pageRange?, splitPages?, modelConfig? })`;
-`dynamicExtract({ fileRef, schema, model, pageRange?, modelConfig? })`.
-
-```ts
-.input({ file: types.file })
-.step('classify', documentClassify({ fileRef: input('file'), splitPages: true }))
-.step('extract', dynamicExtract({
-  fileRef: input('file'),
-  schema: { type: 'object', properties: {
-    invoiceTotal: { type: 'string', description: 'Grand total' } } },
-  model: { modelName: 'invoiceixp-cef0d447-ixp',
-    folderKey: 'c4359cde-55f0-4f0e-9322-c6cdce74ab4c' },
-}))
-.step('total', script({ code: 'return $vars.extract.output.ExtractionResult;' }))
-```
-
-## The model identity
-
-Dynamic Extract authors its SCHEMA inline, but execution still runs against a
-model deployment: `model.modelName` and `model.folderKey` are REQUIRED (the
-platform validator rejects the node without them), with optional `projectId`,
-`projectName`, `folderName`, and `versionTag`. Copy them from the tenant —
-never construct them.
-
-## Schema and outputs
-
-`schema` is a JSON-Schema object (`type: 'object'` with `properties`, each
-usually carrying a `description` the model reads). It is emitted as the node's
-`schemaDocument`. Classification lands at `out('classify', ...)`; extraction
-results at `out('extract', 'ExtractionResult')`.
-
-## Evidence boundary
-
-Both calls hit real document-understanding services — no local rung runs a
-model. Offline `validate` proves the emitted shape (fileRef wiring, schema,
-model identity, the classify `success` port); classification quality and
-extraction values are platform evidence.

package/skills/uipath-maestro-flow/references/error-handling.md

@@ -1,75 +0,0 @@
-# Error Handling
-
-An error handler is a separate path from the immediately preceding action.
-
-Signature: `.step(name, action).onError(handler => ...)`.
-Read the failure with `h.err(field)` — or `err(step, field)` if you prefer to name the step — where field is one of `code`, `message`, `detail`, `category`, `status` (plus `response` and `element`, present at run time though undeclared).
-A handler may `.return(...)`, `.terminate(...)`, or `.stepToRef(target)`.
-
-```ts
-.step('fetch', http({ url, managed: true }))
-.onError((h) => h.step('recover', script({ code: 'return "cached";' }))
-  .stepToRef('useValue'))
-.step('useValue', script({ code: 'return "done";' }))
-```
-
-## Reading the failure
-
-`err()` writes ONE shape — `$vars.<step>.error.<field>` — and the compiler resolves where that family actually publishes the envelope.
-Do not hand-write either prefix, and do not read the failed step's `out(...)` inside its own handler: that path runs because the step failed, so its success output was never written (`ERROR_ENVELOPE_VIA_OUTPUT`).
-
-Which variable holds the envelope is a per-node-family runtime fact, measured one debug run per family (2026-09-10):
-
-| family | envelope in | `<step>.error` is |
-| --- | --- | --- |
-| connector (every one) | `<step>.error` | the envelope |
-| `core.action.script` | `<step>.error` | the envelope |
-| `uipath.pattern.deep-rag` | `<step>.error` | the envelope |
-| `core.subflow` | `<step>.error` | the envelope |
-| `core.action.queue.create` | `<step>.error` | the envelope |
-| `core.action.http.v2` (`managed: true`) | `<step>.output` | the boolean `true` |
-| `core.action.http` (`managed: false`) | nowhere | the boolean `true` |
-
-`serialize` rewrites the read for the exception families, so authored source stays uniform and a family moving is a table edit rather than a fleet-wide rewrite.
-A bare `err(step)` is the did-this-fail test and is never rewritten: it reads truthy on every family, the envelope object included.
-
-Plain `http({ managed: false })` publishes no envelope in any version — 1.0.0 and the 1.3 `uip maestro flow migrate` upgrades it to both leave `<step>.output` null — so `check` refuses a handler there (`HTTP_ONERROR_V1`) instead of emitting a read that resolves to nothing.
-That node is also gone from the tenant registry, which serves only `core.action.http.v2`; `check` says so (`HTTP_V1_RETIRED`).
-Moving to the managed node is a behaviour change, not a rename: a non-2xx stops arriving on the success path with `statusCode` and fails the step instead, so a status branch becomes a handler reading `err(step, 'status')`.
-
-A `.loop()` container CAN carry a handler: `.onError()` after `.loop(...)` wires the container's own error port, and a body step's failure routes to it — measured, the container's envelope carries the body's message in `detail` and the failing body step's id in `element`, and the instance completes instead of faulting. Read it the usual way, `h.err('detail')`.
-
-A `.doWhile()` cannot, and the reason is the handle rather than the variable: `core.logic.dowhile@1.0` declares an error variable but its handles are input, success, start, continue and break, so an edge would leave a handle the node does not have — the shape that fails product validate with "the current manifest does not declare that handle". Handle the failure inside the body, on the step that can fail. The builder refuses it by name.
-
-`.onError(...)` is the `error` port case of `.stepToList(port, handler)`, which
-runs a path from any named port. When the failure needs no work of its own, name
-the target directly — `.stepToRef('error', 'refund')` — which is a SIDE EXIT: the
-success path continues, so chaining carries on after it.
-
-A `.stepToRef(target)` with no port leaves the default `output` port and HANDS THE
-PATH OFF, so nothing may follow it in that list. The target may sit anywhere in the
-same scope, including BACKWARD of the step that names it — Flow JSON can express
-that, so this can author it.
-
-## Choosing the path
-
-Do not add recovery merely because an error port exists. Decide whether the
-business operation should fail loud, return an alternate answer, stop all work,
-or compensate and rejoin. An exhausted handler ends separately; use
-`.stepToRef(...)` only when the failure path should deliberately resume shared
-success-path work.
-
-Two limits `check` enforces on a ref, and one it only warns about. It refuses an
-unknown target, a target inside another port's path, and a target inside a LOOP
-BODY — a loop reads `currentItem` / `currentIteration` per iteration, and an edge
-arriving from outside carries no iteration. It WARNS when a ref leaves a loop body
-(a break, which Flow has no node for) or crosses a parallel arm boundary (the Merge
-waits for every branch it forked). Those are best effort: verify them with
-`uip maestro flow validate`.
-
-## Evidence
-
-Test both sides. The failure case should prove the handler receives the expected
-service error and reaches its intended terminal or ref behavior. The success
-case should prove normal continuation still bypasses the handler. A single green
-case cannot establish both paths.