@uipath/skills 1.201.0-preview.621 → 1.202.0-preview.635

package/skills/uipath-maestro-flow/references/author/references/plugins/delay/impl.md

@@ -1,75 +0,0 @@
-# Delay Node — Implementation
-
-## Node Type
-
-`core.logic.delay`
-
-## Registry Validation
-
-```bash
-uip maestro flow registry get core.logic.delay --output json
-```
-
-Confirm: input port `input`, output port `output`, required inputs `timerType` and `timerPreset`. Set the node instance `typeVersion` to the `version` field from this response — do not hardcode it.
-
-## JSON Structure
-
-### Duration-Based (Preset)
-
-```json
-{
-  "id": "wait15min",
-  "type": "core.logic.delay",
-  "typeVersion": "<DEFINITION_VERSION>",
-  "display": { "label": "Wait 15 Minutes" },
-  "inputs": {
-    "timerType": "timeDuration",
-    "timerPreset": "PT15M"
-  }
-}
-```
-
-### Duration-Based (Custom ISO 8601)
-
-```json
-{
-  "id": "waitCustom",
-  "type": "core.logic.delay",
-  "typeVersion": "<DEFINITION_VERSION>",
-  "display": { "label": "Wait 1 Day 5 Hours" },
-  "inputs": {
-    "timerType": "timeDuration",
-    "timerPreset": "custom",
-    "timerValue": "P1DT5H30M"
-  }
-}
-```
-
-### Date-Based (Wait Until)
-
-```json
-{
-  "id": "waitUntil",
-  "type": "core.logic.delay",
-  "typeVersion": "<DEFINITION_VERSION>",
-  "display": { "label": "Wait Until April 15" },
-  "inputs": {
-    "timerType": "timeDate",
-    "timerPreset": "custom",
-    "timerDate": "=js:$vars.scheduledDate"
-  }
-}
-```
-
-## Adding / Editing
-
-For step-by-step add, delete, and wiring procedures, see [editing-operations.md](../../editing-operations.md). Use the JSON structure above for the node-specific `inputs`. BPMN type and event definition come from the definition in `definitions[]`.
-
-## Debug
-
-| Error | Cause | Fix |
-| --- | --- | --- |
-| Invalid timer value | Malformed ISO 8601 string | Check format: `P[n]Y[n]M[n]W[n]DT[n]H[n]M[n]S` |
-| Missing `timerValue` | `timerPreset: "custom"` but no `timerValue` | Add `timerValue` with ISO 8601 duration |
-| Missing `timerDate` | `timerType: "timeDate"` but no `timerDate` | Add `timerDate` with ISO 8601 datetime or `=js:` expression |
-| BPMN timer event not emitted | Wrong `core.logic.delay` definition in `definitions[]` | Re-copy from `uip maestro flow registry get core.logic.delay --output json` — the definition carries `model.eventDefinition: "bpmn:TimerEventDefinition"` |

package/skills/uipath-maestro-flow/references/author/references/plugins/end/impl.md

@@ -1,65 +0,0 @@
-# End Node — Implementation
-
-## Node Type
-
-`core.control.end`
-
-## Registry Validation
-
-```bash
-uip maestro flow registry get core.control.end --output json
-```
-
-Confirm: input port `input`, no output ports. Set the node instance `typeVersion` to the `version` field from this response — do not hardcode it.
-
-## JSON Structure
-
-### Without Output Mapping
-
-```json
-{
-  "id": "doneSuccess",
-  "type": "core.control.end",
-  "typeVersion": "<DEFINITION_VERSION>",
-  "display": { "label": "Done" },
-  "inputs": {}
-}
-```
-
-### With Output Mapping
-
-When the workflow declares `out` variables, every End node must map all of them:
-
-```json
-{
-  "id": "doneSuccess",
-  "type": "core.control.end",
-  "typeVersion": "<DEFINITION_VERSION>",
-  "display": { "label": "Done" },
-  "inputs": {},
-  "outputs": {
-    "processedCount": {
-      "source": "=js:$vars.processData.output.count"
-    },
-    "resultSummary": {
-      "source": "=js:$vars.formatOutput.output.summary"
-    }
-  }
-}
-```
-
-Each key in `outputs` must match a variable `id` from `variables.globals` where `direction: "out"`.
-
-## Adding / Editing
-
-For step-by-step add, delete, and wiring procedures, see [editing-operations.md](../../editing-operations.md). Use the JSON structure above for the node-specific `inputs` and `outputs`.
-
-Output mapping must be added with `Edit` against the `.flow` file — see [Edit/Write: Add output mapping](../../editing-operations-json.md#add-output-mapping-on-an-end-node).
-
-## Debug
-
-| Error | Cause | Fix |
-| --- | --- | --- |
-| Missing output mapping | `out` variable not mapped on this End node | Add `outputs.{varId}.source` expression for every `out` variable |
-| Output expression unresolvable | `$vars` reference points to unreachable node | Ensure the node is upstream and connected via edges |
-| Runtime silent failure | Output mapping missing on one reachable End node | Check **all** End nodes, not just the primary path |

package/skills/uipath-maestro-flow/references/author/references/plugins/hitl/impl.md

@@ -1,204 +0,0 @@
-# HITL Node — Implementation
-
-Two node types implement human-in-the-loop checkpoints. Choose based on whether you need an inline form or an existing deployed app.
-
----
-
-## Option 1 — `uipath.human-in-the-loop.quick-form` (Inline Schema — OOTB)
-
-This is the preferred option. No registry pull, no app publishing, no tenant dependency. Write the node directly into the `.flow` file as JSON.
-
-**Full implementation guide, JSON examples, and schema conversion rules:**
-→ [`uipath-human-in-the-loop` skill — hitl-node-quickform.md](../../../../../../uipath-human-in-the-loop/references/hitl-node-quickform.md)
-
-> **Note:** Skills are self-contained. This cross-skill reference is for documentation context only. The agent uses the `uipath-human-in-the-loop` skill to implement HITL nodes. This implementation guide is for implementation-phase topology resolution only — not for schema design or node writing.
-
-### Adding / Editing
-
-For add, delete, and wiring procedures, see [editing-operations.md](../../editing-operations.md). **Use `Edit` / `Write` for HITL node authoring.** Do not use the dedicated HITL CLI for this non-carve-out structural edit. Wire the `outcome-completed` port after adding the node.
-
-### Quick Reference
-
-**Node JSON (minimum viable):**
-
-```json
-{
-  "id": "hitlReview1",
-  "type": "uipath.human-in-the-loop.quick-form",
-  "typeVersion": "1.0",
-  "display": { "label": "Invoice Review" },
-  "inputs": {
-    "schema": {
-      "schemaId": "<uuid>",
-      "fields": [
-        { "id": "invoiceid", "label": "Invoice ID", "type": "text",   "direction": "input", "binding": "vars.fetchInvoice.output.invoiceId" },
-        { "id": "amount",    "label": "Amount",     "type": "number", "direction": "input", "binding": "vars.fetchInvoice.output.amount" },
-        { "id": "decision",  "label": "Decision",   "type": "text",   "direction": "output", "variable": "vars.decision" }
-      ],
-      "outcomes": [
-        { "id": "approve", "name": "Approve", "type": "string", "isPrimary": true,  "action": "Continue" },
-        { "id": "reject",  "name": "Reject",  "type": "string", "isPrimary": false, "action": "End" }
-      ]
-    },
-    "recipient": { "channels": ["Email", "ActionCenter"], "connections": {}, "assignee": { "type": "group" } },
-    "priority": "Low"
-  },
-  "outputs": {
-    "output": {
-      "type": "object",
-      "description": "Task result data",
-      "source": "=result",
-      "var": "output",
-      "properties": {
-        "decision": { "type": "string" },
-        "Action":   { "type": "string", "enum": ["Approve", "Reject"], "default": "Approve" }
-      }
-    },
-    "status": {
-      "type": "string",
-      "description": "Task completion status",
-      "source": "=result.Action",
-      "var": "status",
-      "enum": ["Approve", "Reject"],
-      "default": "Approve"
-    }
-  }
-}
-```
-
-**Field format rules:**
-- **Input fields**: `binding: "vars.<nodeId>.output.<field>"` (raw path, no `=js:$` prefix). No `variable` property on input fields.
-- **Output fields**: `variable: "vars.<globalName>"` (`vars.` prefix required). No `binding`.
-- **InOut fields**: both `binding` and `variable`, same formats as above.
-- `schemaId` (not `id`) at the schema level — generate a fresh UUID.
-- `typeVersion` — always `"1.0"` for `uipath.human-in-the-loop.quick-form`. **Do not run `registry get` to derive this value; do not use `"1.1"` or any other version.** The OOTB HITL node version is stable at `1.0`.
-- No `model` block on node instances — only the definition carries it.
-
-**outputs block**: only `output` (with `properties` for output/inOut fields + `Action` outcome) and `status` (with `enum`/`default` from outcomes). No per-field `custom: true` entries.
-
-**Ports:** `input` (target) → `outcome-completed` (source, label: Completed)
-
-**Output variables:**
-- `$vars.{nodeId}.output` — object with all `output` / `inOut` field values, keyed by **field `id`**
-- `$vars.{nodeId}.output.{fieldId}` — individual field value (e.g. `$vars.hitlReview1.output.decision`)
-- `$vars.{nodeId}.status` — selected outcome name (e.g. `"Approve"`, `"Reject"`)
-- `$vars.{globalId}` — workflow-global alias; `globalId` is `field.variable` with `vars.` stripped. **Do not use this in scripts — always use `$vars.{nodeId}.output.{fieldId}` instead.**
-
----
-
-## Option 2 — App-Based HITL (`uipath.human-in-the-loop.coded-action-app`)
-
-Use when there is an existing deployed Action Center app that should serve as the task form.
-
-### Discovery
-
-**CLI (primary path):**
-
-```bash
-uip solution resources list --kind App --output json
-```
-
-Returns all Action Center app types (`vB Action`, `workflow Action`, `Coded Action`, `JS Action`). Filter by app name. Then retrieve the configuration:
-
-```bash
-uip solution resources get <key> --output json
-```
-
-**Direct API fallback (if CLI unavailable):**
-
-```
-GET {BASE_URL}/{ORG}/studio_/backend/api/resourcebuilder/solutions/{SOLUTION_ID}/resources/search
-  ?kind=app&pageSize=25&projectKey={PROJECT_KEY}&includeSolutionResources=true
-  &types=VB%20Action&types=Workflow%20Action&types=Coded%20Action&types=CodedAction&types=JS%20Action
-```
-
-Full step-by-step (app search → retrieve-configuration → resource files → reference registration → debug overwrites) → **[hitl-node-apptask.md](../../../../../../uipath-human-in-the-loop/references/hitl-node-apptask.md)**
-
-### Node JSON (Quick Reference)
-
-```json
-{
-  "id": "invoiceReview1",
-  "type": "uipath.human-in-the-loop.coded-action-app",
-  "typeVersion": "<DEFINITION_VERSION>",
-  "display": { "label": "Invoice Review" },
-  "inputs": {
-    "recipient": { "channels": ["ActionCenter"], "connections": {}, "assignee": { "type": "group" } },
-    "app": {
-      "displayName": "Invoice Approval",
-      "name": "Invoice Approval",
-      "key": "<app.key>",
-      "folderPath": "Shared",
-      "inputSchema": {
-        "type": "object",
-        "properties": {
-          "<paramName>": { "type": "string" }
-        }
-      },
-      "outputSchema": {
-        "type": "object",
-        "properties": {
-          "<outputName>": { "type": "string" }
-        }
-      }
-    },
-    "appInputBindings": {
-      "<inputParamName>": "=vars.<nodeId>.output.<field>",
-      "<inputParamName2>": "=metadata.InstanceId"
-    },
-    "schema": {
-      "fields": [],
-      "outcomes": [{ "id": "submit", "name": "Submit", "type": "string", "isPrimary": true, "action": "Continue" }]
-    },
-    "priority": "Medium"
-  },
-  "outputs": {
-    "output": {
-      "type": "object",
-      "description": "Task result data",
-      "source": "=result",
-      "var": "output",
-      "properties": {
-        "Action": { "type": "string", "enum": ["Submit"], "default": "Submit" }
-      }
-    },
-    "status": {
-      "type": "string",
-      "description": "Task completion status",
-      "source": "=result.Action",
-      "var": "status",
-      "enum": ["Submit"],
-      "default": "Submit"
-    }
-  }
-}
-```
-
-**`typeVersion`** — fill in the version returned by `uip maestro flow registry get <appKey>` for the specific deployed app. Unlike QuickForm (always `"1.0"`), AppTask version varies per app definition.
-
-**`inputs.app`**: `inputSchema` and `outputSchema` are JSON Schema objects (`{ "type": "object", "properties": { ... } }`), **not arrays**.
-
-**`inputs.appInputBindings`** — maps app input parameter names to binding expressions. Format: `"=vars.<path>"` (with `=` prefix, no `js:`). Key = parameter name from `inputSchema.properties`. Without this, all input fields appear blank.
-
-### If the app does not exist yet
-
-Note as `[CREATE NEW] <description>` in the node table and use `core.logic.mock` as a placeholder. The app itself is out of scope for this skill — use the `uipath-coded-apps` skill to build it.
-
----
-
-## Common Pattern — Human-in-the-Loop
-
-```text
-Manual Trigger -> RPA Process (extract) -> HITL (review) -> Decision (approved?) ->
-  true: Script (submit) -> End
-  false: End
-```
-
-## Debug
-
-| Error | Cause | Fix |
-| --- | --- | --- |
-| Node type not found in registry (Option 2) | App not published or registry stale | If in same solution: `uip maestro flow registry list --local`. Otherwise: `uip login` then `uip maestro flow registry pull --force` |
-| Task never completes | Human hasn't submitted the form | Check task assignment in Orchestrator |
-| Output missing expected fields | App form doesn't match expected schema | Verify app form fields match what the flow expects |
-| `outcome-completed` port unwired (Option 1) | Missing edge on output handle | Wire the `outcome-completed` output handle — an unwired `outcome-completed` blocks the flow indefinitely |

package/skills/uipath-maestro-flow/references/author/references/plugins/http/impl-manual.md

@@ -1,65 +0,0 @@
-# HTTP Request Node — Manual Mode
-
-Use this walkthrough when there is no IS connector for the target service, the API needs no auth (or auth you pass yourself in headers), or you are prototyping against an arbitrary REST endpoint. For connector-managed auth, use [impl-connector.md](impl-connector.md) instead.
-
-**No connection lookup required.** Manual mode uses `ImplicitConnection` — there are no IS bindings.
-
-Before starting, read [impl.md](impl.md) for the node type, registry validation, and the "always use `node configure`" rule. Follow Steps 1–4 in order.
-
-## Step 1 — Add the node
-
-```bash
-uip maestro flow node add <ProjectName>.flow core.action.http.v2 \
-  --label "<HTTP node label>" --output json
-```
-
-> **Inside a loop body?** Add `--parent <LOOP_NODE_ID>` to set `parentId`. Without it, the node runs outside the loop context and outputs are null. See [loop/impl.md](../loop/impl.md).
-
-The CLI copies the manifest into `definitions[]`, adds the node instance, registers `variables.nodes`, and inserts a `layout.nodes` placeholder — byte-for-byte from the registry. Save the returned `<nodeId>` — Step 2 reuses it. Leave `inputs` empty; Step 2 populates `inputs.detail`. Do not hand-author the definition — see [impl.md — Add the node](impl.md#add-the-node).
-
-## Step 2 — Configure the node
-
-> **Find missing values first.** Before composing `url` / `query` / `body`, resolve any values the agent doesn't have (IDs from names, required body fields, response shape, …). See [/uipath:uipath-platform — http-request.md](../../../../../../uipath-platform/references/integration-service/http-request.md).
-
-```bash
-uip maestro flow node configure <ProjectName>.flow <nodeId> \
-  --detail '{
-    "authentication": "manual",
-    "method": "GET",
-    "url": "https://api.example.com/endpoint",
-    "query": {"param1": "value1"}
-  }' --output json
-```
-
-The CLI:
-
-- Builds the full `inputs.detail` (manual auth, `ImplicitConnection`, bodyParameters, essentialConfiguration)
-- Does **not** generate `bindings_v2.json` or a connection resource file — manual mode needs neither
-
-`url` must be a full URL (scheme + host + path). For auth headers you control, pass them under `headers`:
-
-```bash
-uip maestro flow node configure <ProjectName>.flow <nodeId> \
-  --detail '{
-    "authentication": "manual",
-    "method": "GET",
-    "url": "https://api.example.com/me",
-    "headers": {"Authorization": "=js:`Bearer ${$vars.apiToken}`"}
-  }' --output json
-```
-
-**Dynamic values:** HTTP input fields do not resolve `{$vars.x}` brace-templates — use `=js:` expressions for any dynamic `url` / `headers` / `body` / `query`. Pass the `=js:` string verbatim in `--detail`. Full rationale and examples: [impl.md — Dynamic values](impl.md#dynamic-values-in-url--headers--body--query).
-
-## Step 3 — (Optional) Response branches
-
-Skip unless you need to route downstream paths based on response content (e.g., `items.length > 0` vs empty). For generic call-failure handling use the `error` port in Step 4 instead. Full syntax and rules: [impl.md — Conditional branches](impl.md#conditional-branches).
-
-## Step 4 — Wire edges
-
-The HTTP node's target port is `input`. Source ports: `default` (success), `error` (network/non-2xx), `branch-{id}` (one per Step 3 entry). Wire `default` to the next node. Wire `error` to a handler **only when the requirements say what a failed call should do** — with no `error` edge the call faults the flow, which is the correct default, and setting `inputs.errorHandlingEnabled: true` without the edge swallows the failure into a run that reports success. See [file-format.md — Default: off](../../../../shared/file-format.md#default-off--enable-only-for-a-failure-the-flow-actually-handles).
-
-Edge JSON shapes and all four examples (upstream→node, default→downstream, error→handler, branch→downstream): [impl.md — Wire edges](impl.md#wire-edges).
-
-## Debug
-
-See [impl.md — Debug](impl.md#debug). For manual mode, watch for `ImplicitConnection` errors — they signal a missing `authentication: "manual"` flag or a non-URL `url` value.

package/skills/uipath-maestro-flow/references/author/references/plugins/http/impl.md

@@ -1,201 +0,0 @@
-# HTTP Request Node — Implementation
-
-This page is the entry point for implementing a managed HTTP node. Pick your auth mode below, then follow the matching walkthrough end-to-end. The "Shared Reference" section is an appendix — the mode walkthroughs already inline what you need to act, and link here only for full rationale and extended examples.
-
-## Node Type
-
-`core.action.http.v2` (Managed HTTP Request)
-
-> **Always use `core.action.http.v2`** for all HTTP requests. The older `core.action.http` (v1) is deprecated.
-
-## Pick a Mode
-
-| Mode | Use when | Walkthrough |
-| --- | --- | --- |
-| **Connector** | Target system has an IS connector — auth via an existing IS connection (OAuth/API key) | [impl-connector.md](impl-connector.md) |
-| **Manual** | No connector exists, public/no-auth API, or quick prototyping | [impl-manual.md](impl-manual.md) |
-
-> **Mode fallback — auto-try, then confirm.** Prefer a curated connector activity first; if none, use connector mode; if connector mode cannot be configured (connector lacks HTTP request support — `HasHttpRequest` false — or no usable IS connection), fall through to manual mode automatically. Manual changes the auth model (you supply auth yourself), so confirm the switched mode with the user before finalizing. See [impl-connector.md — Step 2](impl-connector.md#step-2--identify-target-connection).
-
-The `--detail` payload differs in two places between modes: `authentication` (`"connector"` vs `"manual"`), and the connector-binding fields `targetConnector` / `connectionId` / `folderKey` (connector mode only; `url` is then relative to the connector base, vs. an absolute URL in manual mode). Everything else (node add, dynamic values, branches, edges, debug) is shared.
-
-## Critical: Use `node configure`
-
-> **Do not hand-write `inputs.detail`, `bindings_v2.json`, or connection resource files.** Run `uip maestro flow node configure` — it builds everything from a simple `--detail` JSON. Hand-written configurations miss the `essentialConfiguration` block and fail at runtime. `core.action.http.v2` is CLI-owned per [Author capability — Node ownership](../../../CAPABILITY.md#node-ownership--who-authors-the-node) (same envelope rules as connector activities).
-
-## Registry validation
-
-```bash
-uip maestro flow registry get core.action.http.v2 --output json
-```
-
-Confirm in `Data.Node.handleConfiguration`: target port `input`, source ports `branch-{item.id}` (dynamic, `repeat: inputs.branches`) and `default`. Also confirm `Data.Node.supportsErrorHandling: true` — HTTP v2 participates in the implicit `error` port pattern shared by every action node (see [Action Node Structure](../../../../shared/action-nodes.md)). Model `serviceType` is `Intsvc.UnifiedHttpRequest`.
-
----
-
-## Shared Reference (appendix)
-
-The mode walkthroughs link into the sections below for full rationale and extended examples. You do not need to read this section in order — jump directly from the walkthrough link that brought you here.
-
-### Add the node
-
-```bash
-uip maestro flow node add <ProjectName>.flow core.action.http.v2 \
-  --label "<HTTP node label>" --output json
-```
-
-The CLI copies the manifest into `definitions[]`, adds the node instance to `nodes[]`, registers the `variables.nodes` entries, and inserts a placeholder in `layout.nodes` — all in code, byte-for-byte from the registry (including `typeVersion`, which the CLI pulls from the manifest's `version` field; do not hardcode it). Save the returned node ID — both walkthroughs reuse it.
-
-The CLI initializes `inputs` from the manifest's `inputDefaults`:
-
-```json
-"inputs": {
-  "branches": [],
-  "timeout": "PT15M",
-  "retryCount": 0,
-  "swaggerDefinition": null,
-  "detail": {}
-}
-```
-
-`inputs.detail` is populated by the configure step (next). The inputs-level siblings — `branches`, `timeout`, `retryCount` — are set at `node add` time via `--input`:
-
-```bash
-uip maestro flow node add <ProjectName>.flow core.action.http.v2 \
-  --label "<HTTP node label>" \
-  --input '{
-    "timeout": "PT30M",
-    "retryCount": 3,
-    "branches": [
-      { "id": "hasItems", "name": "Has Items", "conditionExpression": "$self.output.body.items.length > 0" },
-      { "id": "empty",    "name": "Empty",    "conditionExpression": "$self.output.body.items.length == 0" }
-    ]
-  }' --output json
-```
-
-- `timeout` — ISO 8601 duration (e.g. `PT15M`, `PT1H`, `P1D`). Default `PT15M`.
-- `retryCount` — integer. Default `0`.
-- `branches` — see [Conditional branches](#conditional-branches) below.
-
-> **Do not hand-author the `core.action.http.v2` definition, and do not `Edit` `inputs.*` after the fact.** Use `uip maestro flow node add` (with `--input` for branches/timeout/retryCount) and `uip maestro flow node configure` (for `inputs.detail`). These are the only supported authoring paths.
-
-### Dynamic values in URL / headers / body / query
-
-**IS activity input fields do not resolve `{$vars.x}` brace-templates.** The flow runtime's `{...}` template interpolation only applies to native flow fields (end-node output `source`, variable updates, decision `expression`, script body, etc.) — **not** to fields under `inputs.detail.bodyParameters` on HTTP v2 or on any `uipath.connector.*` activity. Evidence: `"url": "https://.../user/{$vars.article}/..."` ships to the service as literal `{vars.article}` (the `$` is stripped, braces remain), producing a 400 Bad Request.
-
-**Use `=js:` expressions for any dynamic value in IS activity inputs.** The runtime evaluates `=js:` before handing the value to the connector:
-
-```json
-"bodyParameters": {
-  "url": "=js:`https://api.example.com/users/${$vars.userId}/orders`",
-  "headers": {
-    "Authorization": "=js:'Bearer ' + $vars.apiToken",
-    "X-Request-ID": "=js:$metadata.instanceId"
-  },
-  "query": {
-    "since": "=js:$vars.startDate"
-  }
-}
-```
-
-Template literals with `${...}` interpolation work because the whole expression is evaluated as JavaScript — `$vars` is a global in the `=js:` context. Plain string concatenation (`'Bearer ' + $vars.token`) works the same way.
-
-When calling `uip maestro flow node configure --detail`, pass the `=js:` string verbatim — the CLI stores it in `inputs.detail.bodyParameters` unchanged:
-
-```bash
-uip maestro flow node configure <Project>.flow <nodeId> \
-  --detail '{
-    "authentication": "manual",
-    "method": "GET",
-    "url": "=js:`https://api.example.com/users/${$vars.userId}`"
-  }' --output json
-```
-
-### Conditional branches
-
-Skip this section unless you need to route downstream paths based on the *response content* (e.g., `items.length > 0` vs empty). Do **not** use `branches` just to handle call failures — for that, use the `error` port (see [Wire edges](#wire-edges)).
-
-Each branch entry creates a `branch-{id}` source port. `$self` refers to the current HTTP node's output inside the condition.
-
-Set `branches` at `node add` time via `--input` (see [Add the node](#add-the-node)) — `branches` lives at `inputs.branches`, not `inputs.detail.branches`, and `node configure --detail` does not accept it.
-
-```bash
-uip maestro flow node add <ProjectName>.flow core.action.http.v2 \
-  --label "<HTTP node label>" \
-  --input '{
-    "branches": [
-      { "id": "hasItems", "name": "Has Items", "conditionExpression": "$self.output.body.items.length > 0" },
-      { "id": "empty",    "name": "Empty",    "conditionExpression": "$self.output.body.items.length == 0" }
-    ]
-  }' --output json
-```
-
-> **Do not prefix `conditionExpression` with `=js:`** — HTTP branch conditions are auto-evaluated as JS (same rule as decision/switch expressions).
-
-### Wire edges
-
-The managed HTTP node's target port is `input`. Its source ports are:
-
-- `default` — primary success output (or fallback when configured branches don't match)
-- `error` — fires when the HTTP call fails (network error, timeout, non-2xx not caught by a branch); wire this to an error handler to keep the flow from faulting
-- `branch-{id}` — one per entry in `inputs.branches` ([Conditional branches](#conditional-branches)); use the exact `id` you set
-
-Use `Edit` to add edge objects to `edges[]`; do not use `uip maestro flow edge add` for this structural wiring. Examples:
-
-```json
-{
-  "id": "e-<upstreamNodeId>-<nodeId>",
-  "sourceNodeId": "<upstreamNodeId>",
-  "sourcePort": "<port>",
-  "targetNodeId": "<nodeId>",
-  "targetPort": "input"
-}
-```
-
-```json
-{
-  "id": "e-<nodeId>-<downstreamNodeId>",
-  "sourceNodeId": "<nodeId>",
-  "sourcePort": "default",
-  "targetNodeId": "<downstreamNodeId>",
-  "targetPort": "input"
-}
-```
-
-```json
-{
-  "id": "e-<nodeId>-<errorHandlerId>",
-  "sourceNodeId": "<nodeId>",
-  "sourcePort": "error",
-  "targetNodeId": "<errorHandlerId>",
-  "targetPort": "input"
-}
-```
-
-Add the `error` edge above **only when the requirements say what should happen if the call fails.** With no error edge, a failed call faults the flow — the correct, visible default.
-
-When an HTTP node does have an outgoing `error` edge, the HTTP node instance must also include `inputs.errorHandlingEnabled: true`. `uip maestro flow edge add --source-port error` and `uip maestro flow format` set this automatically; direct JSON edits must set it explicitly. Never set the flag on an HTTP node with no error edge — it suppresses the fault, so a failed call flows on and the run reports success. See [file-format.md — Default: off](../../../../shared/file-format.md#default-off--enable-only-for-a-failure-the-flow-actually-handles).
-
-```json
-{
-  "id": "e-<nodeId>-<hasItemsDownstream>",
-  "sourceNodeId": "<nodeId>",
-  "sourcePort": "branch-hasItems",
-  "targetNodeId": "<hasItemsDownstream>",
-  "targetPort": "input"
-}
-```
-
-### Debug
-
-| Error | Cause | Fix |
-| --- | --- | --- |
-| `not_authed` or 401/403 | Wrong node type (v1 instead of v2), missing bindings, or expired connection | Verify node type is `core.action.http.v2`, check `bindings_v2.json` exists, ping the connection |
-| `configuration` field missing | Node not configured via CLI | Run `uip maestro flow node configure` — do not hand-write `inputs.detail` |
-| `flow validate` errors with `uiPathActivityTypeId` missing on `core.action.http.v2` | Node was hand-authored in `definitions[]` instead of via `uip maestro flow node add` | Remove the node, re-add it via `uip maestro flow node add <file> core.action.http.v2 ...`, then re-run `node configure`. |
-| Connection not found | Wrong connection ID or connector key | Re-run `uip is connections list` for the target connector |
-| Wrong API response | Incorrect `url` or `query` | Check the target service's API documentation |
-| `ImplicitConnection` errors | Manual mode misconfigured | Verify `authentication: "manual"` and `url` is a full URL |
-| Flow faults on 4xx/5xx response | No `error` edge wired from the HTTP node | Expected when the requirements specify no fallback. If they do, add an edge with `sourcePort: "error"` to an error-handler node. See [Implicit error port on action nodes](../../../../shared/file-format.md#implicit-error-port-on-action-nodes) — same mechanism applies to all action nodes |
-| Flow reports `Completed` but the API call failed | `inputs.errorHandlingEnabled: true` with no handler, or an `error` edge routed into the happy path / the success End node | Remove the flag when there is no error edge; otherwise repoint the error edge at a distinct End node with an error/status output, or at `core.logic.terminate`. See [Do not swallow the failure](../../../../shared/file-format.md#do-not-swallow-the-failure) |
-| Edge `source-port output` rejected | Referencing the variable namespace as a port name | HTTP source ports are `default`, `error`, and `branch-{id}` — not `output`. The `output` name is only a variable namespace (`$vars.{nodeId}.output`) |

package/skills/uipath-maestro-flow/references/author/references/plugins/merge/impl.md

@@ -1,43 +0,0 @@
-# Merge Node — Implementation
-
-## Node Type
-
-`core.logic.merge`
-
-## Registry Validation
-
-```bash
-uip maestro flow registry get core.logic.merge --output json
-```
-
-Confirm: input port `input` (accepts multiple connections), output port `output`. Set the node instance `typeVersion` to the `version` field from this response — do not hardcode it.
-
-## JSON Structure
-
-```json
-{
-  "id": "joinBranches",
-  "type": "core.logic.merge",
-  "typeVersion": "<DEFINITION_VERSION>",
-  "display": { "label": "Join Branches" },
-  "inputs": {}
-}
-```
-
-## Adding / Editing
-
-For step-by-step add, delete, and wiring procedures, see [editing-operations.md](../../editing-operations.md). Use the JSON structure above for the node-specific `inputs`.
-
-## Wiring
-
-- `input` — accepts multiple incoming edges (one per parallel branch). All branches must reach the merge before it continues.
-- `output` — single outgoing edge to the next downstream node.
-
-See [editing-operations.md](../../editing-operations.md) for edge add procedures.
-
-## Debug
-
-| Error | Cause | Fix |
-| --- | --- | --- |
-| Merge never completes | One parallel branch has no path to the merge node | Ensure all forked branches reach the merge |
-| Unexpected execution order | Branches assumed to complete in order | Merge waits for all — don't depend on arrival order |