@uipath/skills 1.204.0 → 1.204.1

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

@@ -1,168 +0,0 @@
-# Evaluate — evaluators, eval sets, simulations, runs
-
-Evaluators, eval sets, data points and simulations are project assets managed by
-`uip maestro flow eval`; defining an `inlineAgent(...)` node does not create
-them. Use this when the request asks for evaluation assets, or for a flow to be
-evaluated.
-
-Every `eval` command takes `--path <project-dir>` — the directory holding
-`project.uiproj`.
-
-**Local `add` / `list` / `remove` edit project files and need no login.**
-Starting a run does — `uip login` first, and it needs a matching solution in
-Studio Web.
-
-Probe the installed CLI once, then let it write the JSON formats and generated
-file references rather than hand-authoring them:
-
-```bash
-uip maestro flow eval --help --output json
-```
-
-## Evaluators — how an output is scored
-
-```bash
-uip maestro flow eval evaluator add response-quality \
-  --type llm-judge-output \
-  --model gpt-4.1-2025-04-14 \
-  --description "Score the response against the expected result" \
-  --target-key '*' \
-  --path ./MySolution/MyFlow --output json
-
-uip maestro flow eval evaluator list        --path ./MySolution/MyFlow --output json
-uip maestro flow eval evaluator remove <id> --path ./MySolution/MyFlow --output json
-```
-
-`llm-judge-output` produces
-`evaluatorTypeId: "uipath-llm-judge-output-semantic-similarity"`. Always pin a
-model for an LLM judge. For deterministic values prefer `exact-match`,
-`json-similarity`, or `contains` — a judge on a value that can simply be
-compared is variance for nothing.
-
-## Evals and eval sets
-
-```bash
-uip maestro flow eval set add "Smoke Tests" \
-  --entry-point start \
-  --path ./MySolution/MyFlow --output json
-
-uip maestro flow eval add "basic case" \
-  --set "Smoke Tests" \
-  --inputs '{"request":"hello"}' \
-  --expected '{"reply":"hello"}' \
-  --path ./MySolution/MyFlow --output json
-
-uip maestro flow eval list            --set "Smoke Tests" --path ./MySolution/MyFlow --output json
-uip maestro flow eval remove <id>     --set "Smoke Tests" --path ./MySolution/MyFlow --output json
-uip maestro flow eval set list        --path ./MySolution/MyFlow --output json
-uip maestro flow eval set remove <id> --path ./MySolution/MyFlow --output json
-```
-
-Almost everything is addressed **through its set**. `--set` is required on
-`eval list` and `eval remove`, on all three `simulation` commands, and on every
-`run` verb including `status` and `results`; omitting it fails with
-`required option '--set <name>' not specified` before anything runs. Only the
-`set` commands themselves and the evaluator commands do without it.
-
-Use the generated evaluator id or filename when explicitly passing
-`--evaluators`; a display name alone is not a stable reference. Omitting the
-flag on `eval set add` links all evaluators that currently exist.
-
-A data point's input keys must match the flow's declared inputs. Declare them
-with `.input({ … })` in the source and compile before `eval add`: it reads them
-from the compiled `.flow`, so an input missing there fails with `Input "<name>"
-is not declared as an input variable in the flow`. Do not add inputs with
-`uip maestro flow variable add` — the next `compile -o` rewrites the `.flow`
-from the source, so the CLI edit either disappears or collides with the compiled
-input (`Variable '<name>' already exists`). To confirm what the compiled flow
-declares, pass the `.flow` file itself; `variable` takes no `--path`:
-
-```bash
-uip maestro flow variable list ./MySolution/MyFlow/MyFlow.flow --output json
-```
-
-Build expected outputs from real records rather than invented ones, for the same
-reason a debug run needs real inputs: an invented key matches no record, and the
-eval scores a fault instead of an answer.
-
-## Simulations — stop an eval from really sending
-
-A simulation stands in for a component during a run, keyed by component id: the
-step id from the source, or the tool name for an inline agent's tool. A
-simulation is scoped to one **data point inside one set**, not to the project,
-so all three commands require `--set` and `--data-point`. `add` also requires
-`--strategy`: `Static` returns `--mock-value` verbatim, `Llm` generates a
-response from `--simulation-instructions`. And it requires `--component-type`
-naming what the component is — `connector`, `agent`, `subflow` — unless
-`--parent <agent-id>` adds a child tool simulation, which defaults it to `Node`.
-
-```bash
-uip maestro flow eval simulation add <component-id> \
-  --set "Smoke Tests" --data-point <id> \
-  --strategy Static --component-type connector --mock-value '{"ok":true}' \
-  --path ./MySolution/MyFlow --output json
-
-uip maestro flow eval simulation list \
-  --set "Smoke Tests" --data-point <id> --path ./MySolution/MyFlow --output json
-uip maestro flow eval simulation remove <component-id> \
-  --set "Smoke Tests" --data-point <id> --path ./MySolution/MyFlow --output json
-```
-
-Simulate every side-effecting component before running a set more than once. An
-unsimulated connector step really sends — once per eval, every run.
-
-## Running a set
-
-```bash
-uip maestro flow eval run start   --set "Smoke Tests" --path ./MySolution/MyFlow --output json
-uip maestro flow eval run status  <evalSetRunId> --set "Smoke Tests" --path ./MySolution/MyFlow --output json
-uip maestro flow eval run results <evalSetRunId> --set "Smoke Tests" --path ./MySolution/MyFlow --output json
-uip maestro flow eval run list    --set "Smoke Tests" --path ./MySolution/MyFlow --output json
-uip maestro flow eval run compare <evalSetRunId> --compare-to <evalSetRunId> \
-  --set "Smoke Tests" --path ./MySolution/MyFlow --output json
-```
-
-`run start` returns an `evalSetRunId` and does not block. Poll `run status`
-until it settles, then read `run results`. `run compare` puts a run against a
-previous one — it takes both ids, the subject and `--compare-to` — which is how
-a prompt or guidance change is shown to have helped rather than asserted to
-have.
-
-## Never upload as part of an eval workflow
-
-**Never run `uip solution upload` automatically here. Always ask first.**
-
-`eval run start` needs the solution in Studio Web, and when it cannot resolve
-one it fails with `solution-id could not be resolved` or a variant. That error
-is not licence to upload.
-
-`uip solution upload` writes to Studio Web: it creates, or **overwrites**, the
-solution matching the local `.uipx` `SolutionId`. No flag is needed and no
-prompt is raised. Three ways that costs someone real work:
-
-1. The user is iterating locally and meant to test *before* publishing. Upload
-   pushes work in progress to where teammates and triggers pick it up.
-2. The user pulled the solution with `uip solution download` to change one
-   piece. Upload sends partial local state back over whatever else moved.
-3. Local and Studio Web have diverged. Upload discards the remote side —
-   nothing is merged.
-
-The overwrite is recorded as a restorable version unless `--no-snapshot` was
-passed, but recovery is browser-only, after the fact, by the user, and it does
-not undo case 1. Ask, and offer the two real options: upload now with the user's
-acknowledgement, or pass `--solution-id` and `--project-id` for an existing
-Studio Web solution and plumb them through to `eval run start`.
-
-## Confirm what was written
-
-After authoring, list the evaluator and the eval set and read the generated
-JSON. Confirm the evaluator carries the requested `evaluatorTypeId`, the set
-contains its generated file reference, and the entry point matches the flow.
-
-## Evidence boundary
-
-A score is evidence about this flow's output on these inputs under these
-evaluators. It is not evidence the flow is correct, and an `llm-judge-output`
-score carries a model's variance — one run moving a point or two is noise.
-Compare runs rather than reading one, and name the eval set and the evaluator
-behind any number reported.

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

@@ -1,155 +0,0 @@
-# Connector Events
-
-*Exact signatures, fields, and defaults: `onEvent()`, `waitForEvent()`.*
-
-The same subscription can start a Flow or pause an already-running path.
-
-Signatures:
-
-- `.trigger(onEvent({ connector, event, where?, filters?, connection, folder, version? }))`
-- `.step(name, waitForEvent({ connector, event, where?, filters?, connection, folder, version? }))`
-- both also accept a generated trigger descriptor plus options.
-
-```ts
-.step('reply', waitForEvent({
-  connector: 'uipath-microsoft-outlook365', event: 'email-received',
-  where: { parentFolderId: inboxId },
-  filters: [{ field: 'subject', contains: 'Approval' }],
-  connection: 'outlook', folder: 'shared',
-}))
-```
-
-`connection` and `folder` are bindings.json labels, and both are required: without
-them the node compiles to `connectionId: null`, which `uip maestro flow validate`
-refuses, so `check` reports `BINDING_MISSING` first.
-
-## Tenant discovery — `check` names it, `prepare` does it
-
-Event parameters and their ids are connection-specific. Author the
-subscription first — an id-valued parameter as a `lookup()` token, never a
-pasted id — and one `prepare` discharges everything `check` names:
-
-```ts
-.trigger(onEvent({
-  connector: 'uipath-microsoft-outlook365', event: 'email-received',
-  where: {
-    parentFolderId: lookup({ connector: 'uipath-microsoft-outlook365', event: 'email-received' },
-      'parentFolderId').by('displayName', 'Inbox'),
-  },
-  filters: [{ field: 'subject', contains: 'Approval' }],
-  connection: 'outlook', folder: 'shared',
-}))
-```
-
-```bash
-uip maestro registry prepare uipath-microsoft-outlook365 email-received \
-  --resolve parentFolderId:displayName=Inbox
-```
-
-That one command replaces the old manual sequence end to end: it discovers the
-connection and writes both `bindings.json` entries (connection id AND folder
-key — the same stage a connector-action prepare runs), fetches the event's
-connection-scoped definition, records the object decision for a generic event
-(`--object <name>`, the same matching ladder actions use), stores the
-where/filter vocabulary in `.flow-sdk/connectors-local/` so `check` works offline, and
-records each `--resolve` in `resolutions.json` for `compile` to substitute.
-`check` then validates every `where` key and every `filters[].field` against
-the prepared vocabulary — an unknown filter leaf is an ERROR
-(`EVENT_FILTER_UNKNOWN_FIELD`), because the platform silently drops it and the
-deployed trigger fires on events the filter should exclude.
-
-Two facts prepare surfaces before they can hurt: an event object that requires
-a BYOA (bring-your-own-app) connection is refused with the connections that
-would work, instead of faulting at runtime with an unrelated webhook error;
-and a `webhooks`-mode event prints the URL-registration step — it cannot be
-debugged locally, so deploy to test it.
-
-Do not run `uip is triggers objects` / `triggers describe` /
-`resources run list` by hand and paste ids into `where`: prepare runs the same
-calls deterministically, and a pasted id is meaningless in review and wrong
-after a connection move.
-Before finishing, inspect the emitted node's `inputs.detail.eventParameters`
-and confirm it contains the selected id and the connection/folder bindings refer
-to the same connection used for discovery.
-
-`contains` uses case-sensitive substring matching, so preserve scenario casing.
-If a known tenant event is absent after refreshing the registry/cache, report a
-cache-generation gap instead of inventing a node type, binding, or field. Do
-not patch a prebuilt sample/cache entry to make the missing event appear.
-
-## Generic events: name the object
-
-Most connectors expose their record events generically — `record-created`,
-`record-updated` (Data Fabric, Salesforce, ServiceNow, Jira, Dynamics, …).
-One node type covers every object of the connection, so the subscription must
-say which one with `object`. It is not an event parameter: these operations
-take none, so `where` stays empty and `check` refuses a subscription that
-omits `object` (`EVENT_GENERIC_NO_OBJECT`) or puts the object in `where`.
-
-```ts
-import { RecordCreated, RecordUpdated } from './connectors/uipath-uipath-dataservice.ts';
-
-// Start when a ContractRegistry record is created with dueDate before 2026-08-04.
-.trigger(onEvent(RecordCreated, {
-  object: 'ContractRegistry',
-  filters: [{ field: 'dueDate', lessThan: '2026-08-04' }],
-  connection: 'dataFabric', folder: 'shared',
-}))
-
-// Pause until a FileUploadVerify_20260618 record is updated.
-.step('updated', waitForEvent(RecordUpdated, {
-  object: 'FileUploadVerify_20260618', connection: 'dataFabric', folder: 'shared',
-}))
-```
-
-The objects come from the bound connection, never from a guess:
-
-```bash
-uip is triggers objects uipath-uipath-dataservice CREATED --connection-id <id> --output json
-```
-
-The emitted node carries the object as `inputs.detail.objectName` (and inside
-`configuration`), its event as `eventType`, and the platform-declared
-`eventMode`. A curated event (Outlook `email-received`, OneDrive `file-created`)
-has its object built in — passing `object` there is an error.
-
-## Filter operators
-
-A filter is `{ field, <operator>: value }` with exactly one operator. The
-vocabulary is the designer's, and each form compiles to the same
-`filterExpression` the canvas would write:
-
-| Operator | Value | Emitted expression |
-|---|---|---|
-| `contains`, `startsWith`, `endsWith` | text | `contains(subject,'Invoice')` |
-| `equals`, `notEquals` | text, number or boolean | `status=='open'`, ``priority==`3` `` |
-| `lessThan`, `lessThanOrEqual`, `greaterThan`, `greaterThanOrEqual` | number, or an ISO date string | ``priority>`3` ``, `to_number(dueDate)<to_number('2026-08-04')` |
-
-Ordering a plain string is refused (`EVENT_FILTER_BAD_VALUE`): JMESPath
-compares numbers only, so the subscription would match nothing. Write the
-value as a number or an ISO-8601 date, or use a text operator.
-
-## Evidence boundary
-
-A local start-trigger run injects a payload; it does not fire a subscription.
-For a wait, seed both matching and nonmatching payloads to establish routing.
-Only a platform event occurrence proves the connection, scope, and subscription
-actually receive the intended event.
-
-## Completion contract
-
-Unless the request explicitly requires a live subscription witness, a
-connector-event start is done after the last edit when both of these facts hold:
-
-- `uip maestro flow validate` returns `Valid` for the emitted Flow.
-- The emitted `.flow` carries the intended start-trigger type, scope/filter inputs,
-  bindings, and downstream edges.
-
-At most one bounded direct-input debug may be used to answer a downstream
-behavior question; stop when it answers that question. It is not subscription
-proof. Do not poll or sleep on debug instances, create a scratch solution, or
-upload seed content solely to manufacture a trigger event.
-
-When the stated acceptance bar does require live delivery, cause one real
-platform event and record that witness once. If the environment cannot provide
-it, report that boundary instead of substituting repeated debug launches.

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

@@ -1,41 +0,0 @@
-# Form trigger
-
-*Exact signatures, fields, and defaults: `formTrigger()`.*
-
-A person starts the flow by submitting a form (`core.trigger.form`). The
-submitted values ARE the flow's inputs — read them exactly like any other
-input (`input('name')` / `$vars.start.output.name`).
-
-Signature: `.trigger(formTrigger())` — the factory takes no arguments.
-
-```ts
-export default flow('expense-request')
-  .input({
-    invoiceAmount: types.number,
-    reason: types.string,
-    urgent: { type: types.boolean, default: false },
-  })
-  .trigger(formTrigger())
-  .step('assess', script({ code: 'return $vars.start.output.invoiceAmount > 500;' }))
-  .return({})
-  .build();
-```
-
-## The derived schema
-
-The form's fields are derived from `.input()` at compile time, the same rule
-the designer applies to a flow's arguments: one field per input, the field id
-IS the input's name (so submitted values line up by name), the label is the
-name sentence-cased (`invoiceAmount` → "Invoice amount"), the field type
-follows the input's type, and a field is **required exactly when its input
-declares no default**. There is nothing to author on the trigger itself —
-shape the form by shaping the inputs.
-
-`check` warns (`FORM_TRIGGER_NO_INPUTS`) when the flow declares no inputs: the
-person would get an empty form with only a submit button.
-
-## Evidence boundary
-
-No local rung renders a form — `--input` supplies the values locally, so a
-green ladder proves the trigger type, the derived schema, and that the graph
-runs. A person actually seeing and submitting the form is platform evidence.

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

@@ -1,169 +0,0 @@
-# Human-in-the-Loop
-
-*Exact signatures, fields, and defaults: `hitl()`.*
-
-Pause a Flow for a person using the default inline form, the quick-form node
-type, a deployed Action App, or a document-validation station.
-
-Signature:
-`hitl({ variant?: 'quick-form' | 'action-app' | 'document-validation', app?,
-document?, title?, priority?, labels?, recipient?, fields?, outcomes,
-outcomePorts?, exposeError? })`.
-
-```ts
-.var('status', types.string)
-.stepSwitch('review', hitl({ title: 'Review invoice',
-  fields: [{ id: 'comment', type: 'text', direction: 'output' }],
-  outcomes: ['Approve', 'Reject'] }), [
-  { value: 'Approve', body: (b) => b.step('pay', script({ … }), { updates: { status: lit('approved') } }) },
-  { value: 'Reject', body: (b) => b.step('notify', script({ … }), { updates: { status: lit('rejected') } }) },
-])
-.return({ status: v('status') })
-```
-
-Every outcome is its own exit, `outcome-<slug>`. On the default node, more than
-one outcome routes per outcome by itself — there is no flag to remember and no
-decision node in the middle. On quick-form, with `outcomePorts: false`, or with a
-pinned `{ version }`, a plain `.step()` after the task continues EVERY outcome to
-the next step instead, each on its own edge.
-
-`.stepSwitch` is how you route them: one arm per outcome, none of them the tacit
-next step. It works on the default node, on quick-form and on a pinned task.
-Arms behave like `.switch()`'s — one that ends in `.return()` is terminal, and one
-that does not CONVERGES, so the step after the `.stepSwitch` fans in from every
-arm that reaches it.
-That is what makes the single `.return()` above correct, and what a flow VARIABLE
-is for: each arm assigns it with `{ updates }` and the one return reads it, instead
-of the return having to work out which arm ran.
-
-## Delivery, fields, and routing
-
-- `recipient` is `{ channels?, assignee: { type, value? }, connections? }` —
-  channels are `'Slack' | 'teams' | 'Email' | 'ActionCenter'` (Teams really is
-  the lowercase `'teams'`); assignee types are `user`, `group`, `staticEmail`,
-  `staticGroupName`, `workload`, `roundRobin`, `custom`. Omit the whole object
-  for the platform default (Email + Action Center, assigned to a group).
-- `labels` is one comma-separated string, shown in Action Center.
-- A field's `direction` is `'input'` (shown), `'output'` (asked), or `'inOut'`
-  (pre-filled AND editable — give it a `value`; the reviewed value comes back
-  at the field's own id).
-- **Every outcome is its own exit — the SDK never emits `completed` on a task
-  that has outcomes.** Each outcome gets `outcome-<slug>` (the name lowercased,
-  non-alphanumerics to `-`). This holds on the default node and on quick-form,
-  at every definition version, because it is what the designer draws: it derives
-  one handle per entry in `inputs.schema.outcomes` and shows the manifest's
-  `completed` placeholder only when there are none (flow-workbench,
-  `getEffectiveHitlHandleCustomization`). A `completed` edge on a task with
-  outcomes is stale: Studio Web and the converter remap it to the PRIMARY
-  outcome, so every other outcome loses its path. `check` refuses it
-  (HITL_COMPLETED_PORT_GONE). `exposeError: true` additionally exposes
-  `out('<step>', 'error')` and selects the 1.2 definition (default node only).
-
-  **Every outcome must be wired**, and there are three ways. Prefer the first:
-
-  | | |
-  | --- | --- |
-  | `.stepSwitch(name, hitl({…}), arms)` | one arm per outcome, `value` naming the outcome. No tacit exit, arms converge, and a missing arm is a warning (STEP_SWITCH_EXIT_UNROUTED) rather than a port with no edge. |
-  | `.step()` + `.stepToList('outcome-<slug>', …)`, on a task that routes per outcome | the FIRST outcome continues the main path and the rest are side arms. Those arms do NOT converge — each gets an End of its own. |
-  | `.step()`, on a task that does not route per outcome | every outcome continues to the next step, each on its own edge. The decision reaches the flow as data: `out('<step>', 'Action')`. |
-
-  Do not route the FIRST outcome with `.stepToList`: its port is already taken by
-  the main path (flow-builder-sdk#741). After a task that does not route per
-  outcome EVERY outcome port is taken, so `.stepToList('outcome-…')` there is
-  refused (HITL_OUTCOME_PORTS_OFF) — use `.stepSwitch`, or `outcomePorts: true`.
-
-  **So `.step()` means one of two things.** After a task that routes per outcome,
-  the FIRST outcome continues and the others need routes. After any other task,
-  every outcome continues. For example, `hitl({ variant: 'quick-form', outcomes:
-  ['Approve', 'Reject'] })` followed by `.step('log', …)` emits
-  `outcome-approve → log` and `outcome-reject → log`.
-
-  A default-node task with more than one outcome routes per outcome, on its 1.1
-  definition. Five things make `.step()` continue every outcome instead, and only
-  these:
-
-  | | `.step()` continues every outcome because |
-  | --- | --- |
-  | `outcomePorts: false` | you asked for it: the decision is wanted as data |
-  | `variant: 'quick-form'` | that is quick-form's default. `outcomePorts: true` or `.stepSwitch` route it per outcome, and its version stays 1.0 |
-  | `{ version: '1.0' }` | an explicit pin wins, which keeps `decompile` → `compile` exact on a deployed flow. `outcomePorts: true` with the pin routes per outcome on the 1.0 node |
-  | one outcome | an acknowledgement, not a choice |
-  | every outcome `action: 'End'` | each outcome gets its own End, so nothing may follow the task except a `.return()` (HITL_UNREACHABLE_AFTER) |
-
-  An `action: 'End'` outcome in that fan-out goes to an End node of its own
-  instead of into the next step, or joins the `.return()` when that is the next
-  step. The flow runtime never reads `action`, so only the graph can end the run
-  on that outcome.
-
-  Inside a `.parallel()` arm, such a task must not be the arm's last step, and
-  none of its outcomes may be `action: 'End'`. The join waits for a token on
-  every incoming edge, and only one outcome fires, so the run would never get
-  past it.
-  `check` refuses both (HITL_FAN_OUT_INTO_JOIN, HITL_END_OUTCOME_IN_PARALLEL).
-  Add a step after the task inside the arm, for example
-  `a.step('review', hitl(…)).step('record', …)`: every outcome continues to
-  `record`, and only `record` reaches the join. `.stepSwitch` does not help
-  here, because its arms rejoin at the same join. A `.stepSwitch` on a task
-  inside an arm needs the same step after it: with an empty `Approve` arm and a
-  `Reject` arm that runs `rej`, the arm would end on two paths (the `Approve`
-  outcome edge and `rej`), and `check` refuses that too
-  (HITL_FAN_OUT_INTO_JOIN). Write `a.stepSwitch('review', …).step('record', …)`.
-  That `.stepSwitch` also needs an arm for every outcome, and no arm may end in
-  `.return()`: either one sends that outcome's path to an End inside the arm,
-  so the join waits forever for the arm's other path, and `check` refuses it
-  (HITL_END_OUTCOME_IN_PARALLEL). Put the `.return()` after the `.parallel()`.
-
-  The action-app and document-validation variants are different: their outcomes
-  live in the app, `completed` is the only handle the designer draws for them,
-  and `.step()` leaves on it. Route on `out('<step>', 'Action')` downstream.
-
-  **Why routing is the default.** An approve/reject task whose outcomes all lead
-  to one place compiles and `flow validate` answers `Valid`, so the mistake
-  surfaced at runtime or in a grader (flow-builder-sdk#735). A warning was not
-  enough — #739 measured it firing three times while the unreachable artifact
-  shipped anyway — so the shape changed instead of the advice. `check` still
-  warns `HITL_OUTCOMES_UNREACHABLE` where every outcome continues to one step and
-  nothing reads `out('<step>', 'Action')`.
-
-  **Route EVERY outcome.** With `.stepToList`, an unrouted one deploys and then
-  stalls the run when the reviewer picks it (`check` warns
-  HITL_OUTCOME_UNROUTED). With `.stepSwitch` it compiles to an End instead, so
-  the run finishes rather than hanging — but finishes without the flow's declared
-  outputs, which STEP_SWITCH_EXIT_UNROUTED says out loud. Inside a `.parallel()`
-  arm that End would hang the join instead, so there it is refused
-  (HITL_END_OUTCOME_IN_PARALLEL). `action: 'End'` changes
-  what happens on that outcome (the run ends instead of stalling), not whether
-  its handle needs an edge.
-
-  **What `flow validate` checks.** It holds an `outcome-<id>` edge to the node's
-  declared outcomes: one naming a real outcome passes on every version (so
-  per-outcome wiring passes on 1.0 and on quick-form), and one naming no outcome
-  is refused — *Edge references undeclared source handle "outcome-nope"*. On a
-  1.1/1.2 node it also refuses `completed`. It does NOT refuse `completed` on a
-  1.0 or quick-form node that has outcomes, which is why `check` and the SDK do.
-
-  **The decision as data** — `.step()` then `.switch()` on
-  `out('<step>', 'Action')` — still works: every outcome reaches the switch on
-  its own edge, and the switch routes. Ask for it deliberately (quick-form, or
-  `outcomePorts: false` on the default node); the reason is that the decision is
-  wanted as DATA — recorded in an output, compared in one place. Every outcome
-  continuing to one step with nothing reading `Action` is the unreachable-outcomes
-  case above, not a third shape.
-- `variant: 'document-validation'` takes `document: { extractionResult,
-  storageBucket?, documentId?, render?, taxonomy? }` and no `fields`; bind
-  `extractionResult` to the upstream extract step's `ExtractionResult`.
-  `render: 'custom'` requires `taxonomy` (and takes `app`).
-
-## Variant judgment
-
-Use the node variant explicitly named by the scenario. The default and
-quick-form variants own their fields in the Flow; action-app delegates the form
-to an already-deployed app. For an app task, resolve the app key, name, folder,
-and argument names from the same tenant resource.
-
-## Evidence boundary
-
-Offline execution scripts the selected action and output fields. It proves
-wiring and downstream routing, not that a real task appeared or that a person
-participated. Live evidence should preserve the Action Center task identity,
-the human-selected outcome, supplied answers, and the path that resumed.

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

@@ -1,105 +0,0 @@
-# HTTP
-
-*Exact signatures, fields, and defaults: `http()`.*
-
-The one factory selects two distinct product nodes:
-
-- standalone: `http({ managed: false, ... })`, non-2xx responses stay on the
-  success output with `statusCode`;
-- managed: `http({ managed: true, ... })`, non-2xx responses take the error
-  path.
-
-Signature:
-`http({ method?, url, managed, connection?, folder?, targetConnector?, headers?, query?, body?, contentType?, timeout?, retryCount?, returns? })`.
-
-```ts
-.step('policy', http({ method: 'GET', url: policyUrl,
-  managed: true, returns: { limit: 'number' } }))
-.step('read', script({
-  code: 'return $vars.policy.output.body.limit;' }))
-```
-
-## Choosing the node
-
-Match the product node named by the scenario. “Managed HTTP Request,” “HTTP
-Request node,” and `core.action.http.v2` select managed; “standalone” and
-`core.action.http` select standalone. Authentication needs or the desire for an
-error handler are not substitutes for that intent.
-
-Live product evidence shows that both nodes expose an `application/json` body as
-a parsed value. Declare its top-level fields with `returns` and read them
-directly; do not apply `JSON.parse` to a body declared by `returns`. A non-JSON
-body remains opaque unless its live media type establishes a scalar contract. An
-offline local run is not evidence for the product-CLI contract either way: follow
-the task's named evidence mode and use live debug for product response shape.
-
-The definitions default `timeout` to `PT15M` and `retryCount` to `0`. Override
-them only when the scenario calls for different operational behavior.
-
-## Managed authentication
-
-Managed HTTP has two authentication modes. Omit `connection` and `folder` for
-manual/implicit mode. To reuse an Integration Service HTTP connection, provide
-both symbolic names from `bindings.json`; the compiler resolves them into the
-node detail and the emitted flow's resource bindings:
-
-```ts
-.step('profile', http({
-  managed: true,
-  method: 'GET',
-  url: '/me',
-  connection: 'spotifyHttp',
-  folder: 'shared',
-  returns: { display_name: 'string' },
-}))
-```
-
-```json
-{
-  "bindings": [
-    { "name": "spotifyHttp", "resourceKey": "<uipath-uipath-http connection id>" },
-    { "name": "shared", "resourceKey": "<folder key>" }
-  ]
-}
-```
-
-Connection mode emits `authentication: "connector"`, targets
-`uipath-uipath-http`, and treats `url` as a path relative to the connection's
-configured base URL. Supplying only one of `connection` or `folder` is an error.
-
-For an HTTP fallback authenticated by another connector, set its connector key
-as `targetConnector`. The node remains the managed HTTP wrapper, while the
-proxied request reuses that connector's authentication:
-
-```ts
-.step('emoji', http({
-  managed: true,
-  method: 'GET',
-  url: '/emoji.list',
-  connection: 'slack',
-  folder: 'shared',
-  targetConnector: 'uipath-salesforce-slack',
-}))
-```
-
-`targetConnector` requires both bindings and is not valid on standalone HTTP.
-
-## Response branches
-
-`branches: [{ name, condition }]` declares extra exits evaluated against the
-response — each becomes a `branch-<name>` source port routed with
-`.stepToList('branch-<name>', …)`, while the main path continues from the
-default port. Conditions are expressions (e.g.
-``js`$vars.fetch.output.statusCode === 429` ``), typically reading the step's
-own declared `returns`. Names must be unique and constant conditions are
-rejected by `check`.
-
-## Evidence
-
-An offline replay proves the graph and chosen response shape. A live request is
-the evidence for endpoint reachability, response media type, authentication,
-and the service's actual status/body behavior.
-
-Both HTTP types default to `timeout: 'PT15M'` and `retryCount: 0` when omitted.
-The managed node deserializes the response body, so read `out('fetch', 'body.items')`
-and let `returns` declare the body's top-level fields.