@uipath/skills 1.195.0 → 1.196.0

package/skills/uipath-maestro-flow/references/author/references/planning-arch.md

@@ -9,6 +9,36 @@ Discover available capabilities, then design the flow topology — select node t
 
 ---
 
+## Before You Build: Is Maestro the Right Home?
+
+Run this gate **before** designing the topology. Maestro is the right tool for a *long-running case* — but not every automation is one, and reaching for a flow by default leads to orchestration overhead that a simpler design would avoid. If the answer below is "queue + Action Center," stop here and hand the work to [/uipath:uipath-rpa](/uipath:uipath-rpa) + [/uipath:uipath-platform](/uipath:uipath-platform) instead of authoring a flow.
+
+### The one question
+
+> **Where does the case live right now — and where should it live between steps?**
+
+A business case (an invoice being approved, a claim being recovered, an onboarding in progress) needs a home for its state while it waits. There are two legitimate homes:
+
+- **One durable instance — Maestro.** A single orchestrated process holds the whole case, survives every wait, and shows you exactly where each case is at any moment.
+- **Scattered across infrastructure — a queue + Action Center state machine.** The case's state lives spread across queue items, asset values, and Action Center tasks; whichever robot picks the work up next reassembles it. RPA does the steps, a queue carries the work between them, Action Center holds the human-wait, and the "state" is implicit in which queue/task the item currently sits in.
+
+### Decision table
+
+| Factor | Lean **Maestro flow** | Lean **queue + Action Center state machine** |
+|---|---|---|
+| Number of distinct waits in the lifecycle | Several waits / branches / parallel paths | A **single** human-wait or external-wait |
+| Per-case visibility | You need to see "where is case #1234 right now" | Per-item queue status is enough |
+| Branching & parallelism | Real branching, fan-out/merge, SLAs | Mostly linear: do work → wait → finish |
+| Who maintains it | Team comfortable with orchestration as a first-class artifact | RPA-only team, existing queue infrastructure |
+| Cross-product composition | Coordinates RPA + Agents + connectors + humans | Pure RPA + Action Center, no agent reasoning |
+| Cost of the orchestration layer | Justified by the above | Overhead you won't repay for a one-shot process |
+
+**Rule of thumb:** a **single-wait** lifecycle (do work → wait for one approval → finish) is a legitimate and *simpler* job for a queue + Action Center state machine. **Multi-wait, branched, or visibility-critical** lifecycles are where Maestro earns its keep. Both are valid — choose deliberately, not by habit.
+
+> **Converting an existing RPA project to Maestro?** You don't rewrite the project into a flow — you keep the executors and lift only the orchestration. See [brownfield.md — Converting an existing project to Maestro](brownfield.md#converting-an-existing-project-to-maestro).
+
+---
+
 ## Process
 
 1. Analyze the user's requirements
@@ -49,8 +79,9 @@ uip maestro flow registry get core.action.script --output json  # script node in
 **In-solution discovery (no login required):**
 ```bash
 uip maestro flow registry list --local --output json     # discover sibling projects in the same .uipx solution
+uip maestro flow registry search "<keyword>" --local --output json  # keyword search across in-solution nodes only
 ```
-Run from inside the flow project directory. If the resource (RPA, agent, flow, API workflow) exists as a sibling project in the same solution, it appears here without needing to be published. Prefer in-solution resources over mock placeholders.
+Run from inside the flow project directory. If the resource (RPA, agent, flow, API workflow) exists as a sibling project in the same solution, it appears here without needing to be published. Prefer in-solution resources over mock placeholders. `--local` results omit `AvailableOnTenant` (no tenant lookup). Empty `search --local` is not authoritative — confirm with `list --local` before treating a resource as absent.
 
 ### Check Connector Connections
 
@@ -71,7 +102,7 @@ uip is connections list "<connector-key>" --all-folders --output json
 
 **What to record from discovery:**
 - **Connectors:** Whether a connector exists for each external service, available operations (from node type names), and whether a healthy connection exists. Field details require `registry get --connection-id` in Phase 2.
-- **Resources:** Whether a published or in-solution node exists for each RPA process, agent, or flow referenced in the requirements. Check in-solution first (`registry list --local`), then the tenant registry. Input/output schemas require `registry get` (with `--local` for in-solution) in Phase 2.
+- **Resources:** Whether a published or in-solution node exists for each RPA process, agent, or flow referenced in the requirements. Check in-solution first (`registry list --local`, or `registry search "<keyword>" --local` for keyword match), then the tenant registry. Input/output schemas require `registry get` (with `--local` for in-solution) in Phase 2.
 - **Gaps:** Services with no connector -> fall back to `core.action.http.v2` (manual mode). Resources in the same solution but unpublished -> use `--local` discovery (no mock needed). Resources not in the solution and not yet published -> use `core.logic.mock` placeholder. Connectors with no connection -> flag in Open Questions for the user to create.
 
 Use these findings to select the right node types from the [Plugin Index](#plugin-index). If a connector doesn't exist, fall back to `core.action.http.v2` (manual mode) or note it as a gap in Open Questions.
@@ -293,12 +324,27 @@ Use a downstream Decision/Switch only for **content-based routing on a successfu
 
 ### Orchestration (Mixed Resources)
 
+The canonical composition when more than one product is in play. Default division of labor — most "where does this step go?" questions resolve against it:
+
+> **RPA = hands. Maestro = conductor. Agents = brain. Humans approve.**
+
+- **Maestro orchestrates** — owns the case, the waits, the branching, the SLA, the long-running state (this flow).
+- **RPA executes** — mechanical work against systems with no clean API (desktop apps, terminals, legacy web) — a `uipath.core.rpa-workflow.*` resource node. See [rpa/planning.md](plugins/rpa/planning.md).
+- **Agents reason** — judgment calls: classify, summarize, decide which branch a fuzzy input belongs to — an agent node. See [agent/planning.md](plugins/agent/planning.md) / [inline-agent/planning.md](plugins/inline-agent/planning.md).
+- **Humans approve** — a HITL / human-task node wraps the point where a person must look before the case continues. See [hitl/planning.md](plugins/hitl/planning.md).
+
+Worked example — extract, classify, and route with one human approval branch:
+
 ```
-Trigger -> Script (prepare) -> RPA Process (extract) -> Agent (classify) -> Decision
-  |-- approved -> Script (format) -> End
-  |-- rejected -> Human Task (review) -> End
+Trigger -> Script (prepare) -> RPA Process (extract from legacy app) -> Agent (classify) -> Decision (confidence high)
+  |-- true  -> Script (format) -> End (auto-approved)
+  |-- false -> HITL (human approves or rejects) -> Decision (approved)
+                 |-- true  -> Script (format) -> End (approved)
+                 |-- false -> Script (log rejection) -> End (rejected)
 ```
 
+Here Maestro holds the case across the agent call and the human wait; RPA does the extraction the source app gives no API for; the agent makes the confidence call; the human is the gate only when the agent is unsure. Each non-Maestro piece is a separate published (or in-solution) artifact the flow references as a node — you do **not** rebuild them inside the flow.
+
 ### Scheduled Batch Processing
 
 ```
@@ -307,6 +353,30 @@ Scheduled Trigger -> HTTP (fetch batch) -> Loop
   |-- success -> Script (summary) -> End
 ```
 
+### No-API Source (RPA Feeder Bridge)
+
+When the source application has **no API and no connector** (legacy desktop app, terminal, mainframe screen), the flow cannot be triggered by the source directly. Bridge it: a **scheduled RPA bot scrapes the source and drops the result onto something Maestro can watch** — a Queue or a Storage Bucket — and the flow triggers off that.
+
+```
+[Scheduled RPA bot]  (outside the flow — uipath-rpa + a time trigger)
+   scrape legacy app -> push item to Queue (or file to Bucket)
+        |
+        v
+Queue/Bucket item created
+        |
+        v
+Maestro flow trigger -> Process item -> ... -> End
+```
+
+Two ways to wire the Maestro side:
+
+- **Queue → flow:** the RPA bot calls `Add Queue Item`; the flow is started by a queue trigger (configured in Orchestrator — see [/uipath:uipath-platform](/uipath:uipath-platform)) or polls/consumes the queue. Best when each scraped row is a separate case.
+- **Bucket → flow:** the RPA bot uploads a file; a scheduled flow picks it up. Best for batch drops.
+
+> **Tradeoff — polling latency equals the scraper schedule.** The case starts no sooner than the next RPA run. A bot scheduled every 15 minutes means up to 15 minutes of trigger latency. There is no event from a no-API source, so "real-time" is not achievable this way — tighten the RPA schedule to lower latency, at the cost of more bot runs. If the source *does* expose an event/webhook or has a connector, prefer a connector trigger ([connector-trigger/planning.md](plugins/connector-trigger/planning.md)) over this bridge.
+
+The scraper bot itself is an RPA project ([/uipath:uipath-rpa](/uipath:uipath-rpa)) with a time trigger ([/uipath:uipath-platform](/uipath:uipath-platform)); only the consuming flow belongs to this skill.
+
 ---
 
 ## Output Format

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

@@ -91,6 +91,7 @@ If Phase 1 flagged a resource as not found, check two sources:
 **1. In-solution discovery (preferred — no login required):**
 ```bash
 uip maestro flow registry list --local --output json
+uip maestro flow registry search "<resource-name>" --local --output json   # keyword match when the list is long
 ```
 Run from the flow project directory. If the resource exists as a sibling project in the same `.uipx` solution, it appears here — use `registry get "<node-type>" --local --output json` to get the full manifest.
 
@@ -115,7 +116,7 @@ IxP extraction nodes (`uipath.ixp.*`) skip binding resolution. Design-time confi
 
 For each `core.logic.mock` node in the architectural plan:
 
-1. Check in-solution discovery first: `uip maestro flow registry list --local --output json`
+1. Check in-solution discovery first: `uip maestro flow registry list --local --output json` (or `registry search "<name>" --local --output json` for keyword match)
 2. If found locally: replace the mock with the in-solution resource node type, update inputs/outputs
 3. If not found locally, check tenant registry: `uip maestro flow registry search "<name>" --output json`
 4. If published: replace the mock with the real resource node type, update inputs/outputs

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

@@ -118,8 +118,12 @@ uip is resources list "<connector-key>" --connection-id "<connection-id>" --outp
 
 Run `is resources describe` to fetch and cache the full operation metadata, then **read the cached metadata file** for complete field details including descriptions, types, references, and query/path parameters. The describe summary omits some of this.
 
+**Read `<objectName>` from the node definition in `definitions[]` (written by `node add`) — do not guess it from the node-type suffix.**
+
 ```bash
-# 1. Describe to trigger fetch + cache (extract the objectName from the connector node type)
+# 1. Describe to trigger fetch + cache (objectName = the activity's API object, NOT the node-type suffix)
+#    Read <objectName> from the node definition FIRST (see note below) — do not batch this
+#    call with `node add` / `registry get`; those calls PRODUCE the objectName this one consumes.
 uip is resources describe "<connector-key>" "<objectName>" \
   --connection-id "<id>" --operation Create --output json
 # -> response includes metadataFile path
@@ -128,6 +132,10 @@ uip is resources describe "<connector-key>" "<objectName>" \
 cat <metadataFile path from response>
 ```
 
+> **`<objectName>` is the activity's API object name, not the node-type's trailing segment — and NOT a case-conversion of it.** Read it from the node definition copied into `definitions[]` by `node add`: `model.context[]` entry `{name:"objectName", value:"…"}` (or the `objectName` field inside the `configuration` `=jsonString:` blob). Never derive it by transforming the node-type suffix — kebab→snake (`send-email` → `send_email`) and kebab→Pascal are both guesses and both 404. Example: node type `…google-gmail.send-email` has objectName `SendEmail` (not `send_email`); `…teams.send-bot-direct-message` has objectName `bot_direct_messages` (not `send-bot-direct-message`). A 404 means wrong objectName — re-read it from the definition and retry; do NOT treat the 404 as "describe unavailable" and skip the step. Skipping describe loses `requestFields[].reference.filterPattern` and other IS-level metadata that `registry get` does not carry (see Step 4).
+>
+> **Sequence, don't parallelize, the objectName-dependent calls.** `<objectName>` is an OUTPUT of `node add` (it lands in `definitions[]`). Read that value before calling `is resources describe` — do not place `describe` in the same parallel Bash batch as `node add` or `registry get`, or you'll have nothing to pass but a guess. This is the failure mode behind the snake-case 404 above.
+
 The full metadata contains:
 - **`availableOperations[].method`** and **`availableOperations[].path`** — HTTP method and API endpoint path. Same value as `connectorMethodInfo.method` / `.path` from `registry get`.
 - **`parameters`** — query and path parameters (may include required params not in `requestFields`, e.g. `send_as` for Slack)
@@ -157,9 +165,11 @@ uip is resources run list "uipath-salesforce-slack" "curated_channels?types=publ
 # -> { "id": "C1234567890", "name": "test-slack" }
 ```
 
-The `<id>` in `--connection-id "<id>"` MUST be the connection bound to **this** flow (the one picked in Step 1), not any other connection you've used in another flow. Use the resolved IDs (not display names) — from this very `run list` call — in the flow's node `inputs`. When multiple matches exist, present them via `AskUserQuestion` with one option per match plus **"Something else"** as the last option (see the AskUserQuestion dropdown rule in [SKILL.md](../../../../../SKILL.md)).
+The `<id>` in `--connection-id "<id>"` MUST be the connection bound to **this** flow (the one picked in Step 1), not any other connection you've used in another flow. Use the resolved IDs (not display names) — from this very `run list` call — in the flow's node `inputs`. When multiple matches exist, ask the user, with one option per match plus **"Something else"** as the last option (see the dropdown question rule in [SKILL.md](../../../../../SKILL.md)).
+
+> **Filter server-side before paginating.** If the field's `reference` carries a `filterPattern` (e.g. Teams `userId`: `"$filter=startswith(userPrincipalName,'{filter}')"`), substitute the search term for `{filter}` and pass the result as `--query` — one targeted call instead of walking a large directory. `filterPattern` appears only in `is resources describe` output; the flow `registry get` reference object strips it (keeps only `objectName`/`lookupValue`/`lookupNames`/`path`/`childPath`), so read it from the Step 3 describe metadata. Guessed params (`searchTerm=`/`where=`/`filter=`) are silently ignored. See [reference-resolution.md — Search References (filterPattern)](../../../../../../uipath-platform/references/integration-service/reference-resolution.md#search-references-filterpattern).
 
-> **Paginate when looking up by name.** Use `Data.Pagination.HasMore` / `NextPageToken` with `--query "nextPage=<token>"`. Short-circuit on match. Do NOT conclude "not found" until `HasMore` is `"false"`. See [resources.md#pagination](../../../../../../uipath-platform/references/integration-service/resources.md#pagination).
+> **Paginate only when there is no `filterPattern`.** Use `Data.Pagination.HasMore` / `NextPageToken` with `--query "nextPage=<token>"`. Short-circuit on match. Do NOT conclude "not found" until `HasMore` is `"false"`. See [resources.md#pagination](../../../../../../uipath-platform/references/integration-service/resources.md#pagination).
 
 **Read [/uipath:uipath-platform — Integration Service — resources.md](../../../../../../uipath-platform/references/integration-service/resources.md) for the full reference-resolution workflow** (pagination, describe failures, fallbacks).
 
@@ -169,7 +179,7 @@ The `<id>` in `--connection-id "<id>"` MUST be the connection bound to **this**
 
 1. Collect all required fields from the metadata (`requestFields` + `parameters`)
 2. For each required field, check if the user's prompt contains a value
-3. If any required field is missing and has no `defaultValue`, **ask the user** before proceeding — list the missing fields with their `displayName` and what kind of value is expected. Free-form input is appropriate when the value space is open-ended (channel names, message bodies, IDs); when a finite set of sensible values exists, present them via `AskUserQuestion` per the dropdown rule in [SKILL.md](../../../../../SKILL.md).
+3. If any required field is missing and has no `defaultValue`, **ask the user** before proceeding — list the missing fields with their `displayName` and what kind of value is expected. Free-form input is appropriate when the value space is open-ended (channel names, message bodies, IDs); when a finite set of sensible values exists, present them as options per the dropdown question rule in [SKILL.md](../../../../../SKILL.md).
 4. Only after all required fields are accounted for, proceed to building
 
 > **Do NOT guess or skip missing required fields.** A missing required field will cause a runtime error. It is always better to ask than to assume.

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

@@ -65,6 +65,20 @@ Each entry is one input field the user supplies when configuring the trigger (e.
 
 > **Source of truth:** `parameters[]` is populated for every connector. `flow registry get`'s `eventParameters.fields` derives from `triggers describe`'s `events.<operation>.required`/`.optional`, which several connectors do not emit. Full field semantics: [/uipath:uipath-platform — triggers.md — `parameters[]`](../../../../../../uipath-platform/references/integration-service/triggers.md#parameters--canonical-event-parameter-input-fields).
 
+**1b-2. Resolve the object name and fetch field metadata** — **mandatory** for every trigger node.
+
+> **MUST READ before this step:** [/uipath:uipath-platform — triggers.md](../../../../../../uipath-platform/references/integration-service/triggers.md). Single source of truth for fetching trigger parameters and fields — object name resolution, describe call, source-of-truth contract.
+
+1. Resolve `<objectName>` from the Step 1b `triggers objects` response per [/uipath:uipath-platform — triggers.md — Object Name Resolution](../../../../../../uipath-platform/references/integration-service/triggers.md#object-name-resolution). If the object name is not recognizable from the user's prompt, **ask the user** — present candidates by `displayName`. Do NOT guess.
+2. Fetch field metadata:
+
+```bash
+uip is triggers describe "<connector-key>" "<OPERATION>" "<objectName>" \
+  --connection-id "<id>" --output json
+```
+
+> **Source of truth for node configuration:** event-parameter inputs come from `triggers objects` → `parameters[]` (Step 1b); field metadata comes from `triggers describe` (this step). Follow these two responses exclusively — do not invent parameters or fields.
+
 ### Step 1c — Select the final connection
 
 **If `byoaConnection: true`** — the Step 1a connection is not usable. Follow the BYOA selection workflow in [/uipath:uipath-platform — connections.md — For BYOA Connections](../../../../../../uipath-platform/references/integration-service/connections.md#for-byoa-connections-webhook-triggers) (filter with `--byoa`, `--refresh` retry, stop-and-ask if none exist).
@@ -162,7 +176,7 @@ Check every entry in `parameters[]` (Step 1b) where `required: true`. All requir
 
 1. Collect all required entries from `parameters[]`
 2. For each, check if the user's prompt provides a value
-3. If any required field is missing, **ask the user** — list the missing fields with their `displayName` (and `description` if useful). Free-form input is appropriate when the value space is open-ended; when a finite set of sensible values exists, present them via `AskUserQuestion` per the dropdown rule in [SKILL.md](../../../../../SKILL.md).
+3. If any required field is missing, **ask the user** — list the missing fields with their `displayName` (and `description` if useful). Free-form input is appropriate when the value space is open-ended; when a finite set of sensible values exists, present them as options per the dropdown question rule in [SKILL.md](../../../../../SKILL.md).
 4. Only proceed after all required event parameters are resolved
 
 > Step 6 buckets each resolved value into `eventParameters`, `queryParameters`, or `pathParameters` based on the entry's `type` — see Step 6's `--detail` table.
@@ -179,6 +193,8 @@ Follow the [CLI: Replace manual trigger with connector trigger](../../editing-op
 
 ### Step 6 — Configure the trigger node
 
+> **MUST READ before `node configure`:** [/uipath:uipath-platform — triggers.md](../../../../../../uipath-platform/references/integration-service/triggers.md). The parameters fetched there (`triggers objects` → `parameters[]`, Step 1b) and fields (`triggers describe`, Step 1b-2) are the source of truth for everything in `--detail`. If you have not run both calls, go back to Step 1b.
+
 **Read the `--detail` field table below before calling `node configure`.** The fields and types are strict — unknown keys or wrong types cause validation errors. Do not guess field names from other node types (e.g., activity nodes use `method`/`endpoint`/`bodyParameters`; triggers use `eventMode`/`eventParameters`/`filter`).
 
 Use `node configure` with trigger-specific `--detail` fields:
@@ -400,9 +416,9 @@ uip maestro flow node remove <PROJECT>.flow start --output json       # remove m
 uip maestro flow node add <PROJECT>.flow <trigger-node-type> --label "<LABEL>" --position 200,144 --output json
 uip maestro flow node configure <PROJECT>.flow <nodeId> --detail '<TRIGGER_DETAIL_JSON>' --output json
 
-# Trigger object metadata (MANDATORY — Step 1b)
-uip is triggers objects "<connector-key>" "<operation>" --connection-id "<id>" --output json
-uip is triggers describe "<connector-key>" "<operation>" "<objectName>" --connection-id "<id>" --output json
+# Trigger object metadata (MANDATORY — Steps 1b and 1b-2)
+uip is triggers objects "<connector-key>" "<operation>" --connection-id "<id>" --output json   # Step 1b: objects + parameters[]
+uip is triggers describe "<connector-key>" "<operation>" "<objectName>" --connection-id "<id>" --output json  # Step 1b-2: fields
 
 # Connections — see /uipath:uipath-platform — connections.md for selection rules (Native, BYOA, --refresh)
 uip is connections list "<connector-key>" --all-folders --output json         # discover connections (--all-folders is mandatory)

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

@@ -15,7 +15,7 @@ This is the preferred option. No registry pull, no app publishing, no tenant dep
 
 ### 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 `completed` port after adding the node.
+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
 
@@ -77,7 +77,7 @@ For add, delete, and wiring procedures, see [editing-operations.md](../../editin
 
 **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) → `completed` (source)
+**Ports:** `input` (target) → `outcome-completed` (source, label: Completed)
 
 **Output variables:**
 - `$vars.{nodeId}.output` — object with all `output` / `inOut` field values, keyed by **field `id`**
@@ -96,13 +96,13 @@ Use when there is an existing deployed Action Center app that should serve as th
 **CLI (primary path):**
 
 ```bash
-uip solution resource list --kind App --output json
+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 resource get <key> --output json
+uip solution resources get <key> --output json
 ```
 
 **Direct API fallback (if CLI unavailable):**
@@ -201,4 +201,4 @@ Manual Trigger -> RPA Process (extract) -> HITL (review) -> Decision (approved?)
 | 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 |
-| `completed` port unwired (Option 1) | Missing edge on output handle | Wire the `completed` output handle — an unwired `completed` blocks the flow indefinitely |
+| `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/hitl/planning.md

@@ -35,9 +35,9 @@ Available: always — no `uip login` or registry pull required.
 
 | Input port | Output port |
 | --- | --- |
-| `input` | `completed` |
+| `input` | `outcome-completed` |
 
-**The output port must be wired.** A node with no edge on `completed` blocks the flow indefinitely.
+**The output port must be wired.** A node with no edge on `outcome-completed` blocks the flow indefinitely.
 
 ### Output Variables
 
@@ -72,14 +72,14 @@ Full JSON format and conversion examples: see [`uipath-human-in-the-loop` skill]
 ### Wiring Pattern
 
 ```
-[Upstream] -> [HITL] ->|completed| [Continue]
+[Upstream] -> [HITL] ->|outcome-completed| [Continue]
 ```
 
 ### Common Topology Patterns
 
 **Approval gate:**
 ```
-Trigger -> Fetch Data -> HITL (review) ->|completed| Decision (approved?) ->
+Trigger -> Fetch Data -> HITL (review) ->|outcome-completed| Decision (approved?) ->
   true: Script (process) -> End
   false: Script (log rejection) -> End
 ```
@@ -88,7 +88,7 @@ Trigger -> Fetch Data -> HITL (review) ->|completed| Decision (approved?) ->
 ```
 Trigger -> Process -> Decision (confidence ok?) ->
   true: Continue -> End
-  false: HITL (exception review) ->|completed| Script (retry with human input) -> End
+  false: HITL (exception review) ->|outcome-completed| Script (retry with human input) -> End
 ```
 
 ### Planning Annotation

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

@@ -0,0 +1,81 @@
+# HTTP Request Node — Connector Mode
+
+Use this walkthrough when the target service has an IS connector and you want managed auth (OAuth / API key) handled by an existing IS connection.
+
+**Prerequisite:** a healthy IS connection for the target connector. Step 2 verifies this. If none exists, propose manual mode as the fallback and confirm the switch with the user before finalizing — do not switch modes without that confirmation.
+
+Before starting, read [impl.md](impl.md) for the node type, registry validation, and the "always use `node configure`" rule. Follow Steps 1–5 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
+```
+
+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>` — Steps 2 and 3 reuse it. Leave `inputs` empty; Step 3 populates `inputs.detail`. Do not hand-author the definition — see [impl.md — Add the node](impl.md#add-the-node).
+
+## Step 2 — Identify target connection
+
+**Connector mode only works if the connector supports the HTTP request activity** — verify by running `uip is connectors get "<target-connector-key>"` and checking the `HasHttpRequest` flag. If the flag is false, **STOP** — a connection cannot help. Use the recovery question below (switch to manual mode / skip / something else; the create-a-connection option does not apply) and do not switch modes without confirmation.
+
+```bash
+uip is connections list "<target-connector-key>" --all-folders --output json
+```
+
+`--all-folders` is mandatory for discovery. Selection rules, empty-result recovery, and ping verification live in the platform skill — do not duplicate them here.
+
+> **MUST READ before any `uip is connections ...` call:** [/uipath:uipath-platform — connections.md](../../../../../../uipath-platform/references/integration-service/connections.md).
+
+Record the chosen connection's `Id` and `FolderKey` — Step 3 needs both.
+
+> **HTTP-specific recovery — no usable connection.** If platform-skill recovery yields nothing (empty after `--all-folders` + `--refresh`, user declines to create one), the HTTP node has unique fallback options. Ask the user to confirm the path — **manual mode is the recommended auto-fallback**, pre-selected, since it unblocks the node without a connection:
+>
+> - **Switch this node to manual mode** *(recommended)* — abandon this walkthrough and follow [impl-manual.md](impl-manual.md). Manual changes the auth model (you supply auth yourself), so this needs explicit confirmation.
+> - **Create a new connection now** — `uip is connections create "<target-connector-key>"` starts the OAuth flow. User completes browser auth themselves, then re-run `uip is connections list` to pick up the new connection.
+> - **Skip this node**.
+> - **Something else**.
+>
+> Auto-try the fallback, but do not finalize a mode switch without the user's confirmation; do not invent a placeholder ID; do not skip the node without explicit selection. See the dropdown question rule in [SKILL.md](../../../../../SKILL.md).
+
+## Step 3 — 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": "connector",
+    "targetConnector": "<target-connector-key>",
+    "connectionId": "<target-connection-id>",
+    "folderKey": "<folder-key>",
+    "method": "GET",
+    "url": "/api/endpoint",
+    "query": {"param1": "value1"}
+  }' --output json
+```
+
+> **Connector mode supports `application/json` request and response bodies only.**
+
+The CLI:
+
+- Builds the full `inputs.detail` (connector, connectionId, bodyParameters, essentialConfiguration)
+- Auto-fills both `bodyParameters.path` and `bodyParameters.url` from the single `url` value you pass
+- Generates `bindings_v2.json`
+- Creates a connection resource file under `resources/solution_folder/connection/`
+
+**Dynamic values:** connector 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 4 — (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 5 instead. Full syntax and rules: [impl.md — Conditional branches](impl.md#conditional-branches).
+
+## Step 5 — Wire edges
+
+The HTTP node's target port is `input`. Source ports: `default` (success), `error` (network/non-2xx), `branch-{id}` (one per Step 4 entry). Wire `default` to the next node and `error` to a handler — without an `error` edge, a failed call faults the flow.
+
+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 connector mode, the most common errors are `not_authed` / 401/403 (expired connection — ping it) and `Connection not found` (wrong connector key or connection ID — re-list).

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

@@ -0,0 +1,63 @@
+# 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
+```
+
+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 and `error` to a handler — without an `error` edge, a failed call faults the flow.
+
+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.