@uipath/skills 1.195.0

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

@@ -0,0 +1,204 @@
+# 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` (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 `completed` port after adding the node.
+
+### Quick Reference
+
+**Node JSON (minimum viable):**
+
+```json
+{
+  "id": "hitlReview1",
+  "type": "uipath.human-in-the-loop",
+  "typeVersion": "1.0",
+  "display": { "label": "Invoice Review" },
+  "inputs": {
+    "type": "quick",
+    "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": "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: "<globalName>"` (plain name, **no** `vars.` prefix). 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`. **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) → `completed` (source)
+
+**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 variable for output/inOut fields; `globalId` is derived from `field.variable` (strip `vars.` prefix)
+
+---
+
+## Option 2 — App-Based HITL (`uipath.human-in-the-loop` with `inputs.type = "custom"`)
+
+Use when there is an existing deployed Action Center app that should serve as the task form. Same node type as Option 1 — only `inputs.type`, `inputs.app`, and `inputs.appInputBindings` differ.
+
+### Discovery
+
+**CLI (primary path):**
+
+```bash
+uip solution resource 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
+```
+
+**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",
+  "typeVersion": "<DEFINITION_VERSION>",
+  "display": { "label": "Invoice Review" },
+  "inputs": {
+    "type": "custom",
+    "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"
+    }
+  }
+}
+```
+
+**`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 |
+| `completed` port unwired (Option 1) | Missing edge on output handle | Wire the `completed` output handle — an unwired `completed` blocks the flow indefinitely |

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

@@ -0,0 +1,144 @@
+# HITL Node — Planning
+
+The flow needs to pause for a human to review, approve, or fill in data. Two node types serve this need — choose based on form complexity and whether an app already exists.
+
+---
+
+## Which HITL Node to Use
+
+| Use case | Node type | Form source |
+| --- | --- | --- |
+| Inline form designed right now (fields + outcomes defined in the flow) | `uipath.human-in-the-loop` | Schema embedded in node inputs — no app needed |
+| Existing coded app or Action Center app | `uipath.core.human-task.{key}` | Deployed app from Orchestrator |
+
+**Prefer `uipath.human-in-the-loop`** for new flows. It is an OOTB node — no registry discovery, no app publishing, no tenant dependency.
+
+---
+
+## Option 1 — `uipath.human-in-the-loop` (Inline Schema — OOTB)
+
+Node type: `uipath.human-in-the-loop`
+Available: always — no `uip login` or registry pull required.
+
+### When to Select
+
+| Situation | Select? |
+| --- | --- |
+| Manager approval before processing | Yes |
+| Human reviews extracted data before submission | Yes |
+| Human resolves exceptions the automation cannot handle | Yes |
+| Need a quick form with specific fields and outcomes | Yes |
+| Existing coded/Action Center app should be used | No — use Option 2 |
+| Fully automated processing, no human involvement | No |
+
+### Ports
+
+| Input port | Output port |
+| --- | --- |
+| `input` | `completed` |
+
+**The output port must be wired.** A node with no edge on `completed` blocks the flow indefinitely.
+
+### Output Variables
+
+- `$vars.{nodeId}.output` — object containing all output and inOut fields the human filled in
+- `$vars.{nodeId}.output.{fieldName}` — individual field value
+- `$vars.{nodeId}.status` — selected outcome's action value (`"Continue"` or `"End"`)
+
+### Schema Design
+
+The schema defines what the human sees and provides. Three field categories:
+
+| Category | Human can… | Use for |
+| --- | --- | --- |
+| `inputs` | Read only | Context the human needs to decide |
+| `outputs` | Write | Data the automation needs back |
+| `inOuts` | Read + modify | Fields the human can see and optionally correct |
+
+Outcomes are the action buttons (e.g., Approve/Reject). First outcome is primary.
+
+**In the architectural plan**, describe the schema:
+```
+inputs:   [invoiceId (string), amount (number)]
+outputs:  [decision (string, required)]
+outcomes: [Approve, Reject]
+priority: Low
+```
+
+Full JSON format and conversion examples: see [`uipath-human-in-the-loop` skill](../../../../../../uipath-human-in-the-loop/references/hitl-node-quickform.md).
+
+> **Note:** Skills are self-contained — cross-skill references are for documentation context only. The agent uses the `uipath-human-in-the-loop` skill to implement HITL nodes; this planning guide is for topology selection only.
+
+### Wiring Pattern
+
+```
+[Upstream] -> [HITL] ->|completed| [Continue]
+```
+
+### Common Topology Patterns
+
+**Approval gate:**
+```
+Trigger -> Fetch Data -> HITL (review) ->|completed| Decision (approved?) ->
+  true: Script (process) -> End
+  false: Script (log rejection) -> End
+```
+
+**Exception escalation:**
+```
+Trigger -> Process -> Decision (confidence ok?) ->
+  true: Continue -> End
+  false: HITL (exception review) ->|completed| Script (retry with human input) -> End
+```
+
+### Planning Annotation
+
+In the node table:
+```
+| hitlReview | Invoice Review | human-task | uipath.human-in-the-loop | inputs: [invoiceId, amount] outputs: [decision] outcomes: [Approve, Reject] | result, status |
+```
+
+---
+
+## Option 2 — `uipath.core.human-task.{key}` (App-Based)
+
+Node type: `uipath.core.human-task.{key}`
+Available: tenant-specific resource — requires `uip login` + `uip maestro flow registry pull`.
+
+### When to Select
+
+Use when there is an existing coded app or Action Center app that should be the task form.
+
+### Ports
+
+| Input port | Output port |
+| --- | --- |
+| `input` | `output` |
+
+### Output Variables
+
+- `$vars.{nodeId}.output` — form data submitted by the user
+- `$vars.{nodeId}.error` — error details if execution fails
+
+### Discovery
+
+**Published (tenant registry):**
+
+```bash
+uip maestro flow registry pull --force
+uip maestro flow registry search "uipath.core.human-task" --output json
+```
+
+**In-solution (local, no login required):**
+
+```bash
+uip maestro flow registry list --local --output json
+uip maestro flow registry get "<node-type>" --local --output json
+```
+
+Run from inside the flow project directory. Discovers sibling projects in the same `.uipx` solution.
+
+### Planning Annotation
+
+- If the app exists: note as `resource: <name> (human-task)`
+- If it does not exist: note as `[CREATE NEW] <description>` with skill `uipath-coded-apps`, use `core.logic.mock` placeholder

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

@@ -0,0 +1,196 @@
+# HTTP Request Node — Implementation
+
+## 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.
+
+## 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`.
+
+## 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).
+
+## Configuration Workflow
+
+### Step 1 — Add the node
+
+Use `Edit` / `Write` to add the `core.action.http.v2` node directly to the `.flow` file. Follow [Edit/Write: Add a node](../../editing-operations-json.md#add-a-node): copy the registry definition into `definitions[]`, add the node instance to `nodes[]`, add `variables.nodes`, and add a placeholder `layout.nodes` entry. Save the node ID for Step 3.
+
+For the node instance shape, follow the [Action Node Structure — Standard JSON skeleton](../../../../shared/action-nodes.md#standard-json-skeleton) with `type: "core.action.http.v2"` and `typeVersion` set to the `version` field from the `registry get core.action.http.v2` response above (do not hardcode it — this node has advanced past `2.0`). Leave `inputs` empty at this stage — Step 3 populates `inputs.detail` via `uip maestro flow node configure`.
+
+### Step 2 — Identify target connector and connection (connector mode only)
+
+Skip this step for manual mode.
+
+Discovery call is **always**:
+
+```bash
+uip is connections list "<target-connector-key>" --all-folders --output json
+```
+
+`--all-folders` is mandatory. Without it the CLI returns the active folder only and hides connections in other folders the user can see. Plain `uip is connections list "<target-connector-key>"` is forbidden for discovery.
+
+> **MUST READ before any `uip is connections ...` call:** [/uipath:uipath-platform — connections.md](../../../../../../uipath-platform/references/integration-service/connections.md). Single source of truth for selection rules, empty-result recovery, ping verification.
+
+Record the chosen connection's `Id` and `FolderKey` for Step 3.
+
+> **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. **STOP** and use `AskUserQuestion`: **Create a new connection now** (`uip is connections create "<target-connector-key>"` starts the OAuth flow — user completes browser auth, then re-run list) / **Switch this node to manual mode** / **Skip this node** / **Something else**. Do not fall back to manual mode silently, do not invent a placeholder ID, do not skip the node without explicit user selection. See the AskUserQuestion dropdown 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).
+
+**Connector mode** (IS connection auth):
+
+```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
+```
+
+**Manual mode** (no connector auth):
+
+```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
+```
+
+**What the CLI handles automatically:**
+
+- Builds the full `inputs.detail` structure (connector, connectionId, bodyParameters, essentialConfiguration)
+- For connector mode: generates `bindings_v2.json` and creates a connection resource file under `resources/solution_folder/connection/`
+- For manual mode: uses `ImplicitConnection` (no bindings needed)
+
+### Step 3b — 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
+```
+
+### Step 4 — (Optional) Configure response branches for content-based routing
+
+Skip this step 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 (Step 5).
+
+Each branch entry creates a `branch-{id}` source port. `$self` refers to the current HTTP node's output inside the condition.
+
+```bash
+uip maestro flow node configure <ProjectName>.flow <nodeId> \
+  --detail '{
+    "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).
+
+### Step 5 — 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` (Step 4); 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"
+}
+```
+
+When an HTTP node has 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.
+
+```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` |
+| 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 | 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 |
+| 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/http/planning.md

@@ -0,0 +1,102 @@
+# HTTP Request Node — Planning
+
+> **MUST READ FIRST:** [/uipath:uipath-platform — http-request.md](../../../../../../uipath-platform/references/integration-service/http-request.md). This file is the flow-specific authoring layer on top.
+
+## Node Type
+
+`core.action.http.v2` (Managed HTTP Request)
+
+> **Always use `core.action.http.v2`** for all HTTP requests — both connector-authenticated and manual. The older `core.action.http` (v1) is deprecated and does not pass IS credentials at runtime.
+
+## When to Use a Managed HTTP Request Node
+
+| Situation | Use Managed HTTP? |
+| --- | --- |
+| Connector exists but lacks the specific curated activity | Yes — connector mode with target connector's connection |
+| No connector exists, but service has a REST API | Yes — manual mode with full URL |
+| Quick prototyping against any REST API | Yes — manual mode |
+| Connector exists and covers the use case | No — use [Connector Activity](../connector/planning.md) |
+| Target system has no API (desktop app) | No — use [RPA Workflow](../rpa/planning.md) |
+
+For the two-mode concept (connector vs. manual) and the `url` / auth rules per mode, see the platform doc linked at the top.
+
+## Ports
+
+| Input Port | Output Port(s) |
+| --- | --- |
+| `input` | `default`, `error`, `branch-{id}` (dynamic, one per `inputs.branches` entry) |
+
+- `default` — primary success output, or fallback when configured branches don't match.
+- `error` — implicit error port; fires when the call fails (network error, timeout, non-2xx not caught by a branch). Shared with all action nodes — see [Implicit error port on action nodes](../../../../shared/file-format.md#implicit-error-port-on-action-nodes).
+- `branch-{id}` — HTTP-specific, configured via `inputs.branches` (response-content routing). See [Conditional Branches](#conditional-branches) below.
+
+## Output Variables
+
+- `$vars.{nodeId}.output` — `{ body, code, method, rawStringBody, request }` on success
+- `$vars.{nodeId}.error` — `{ code, message, detail, category, status }` when the error port fires
+
+## Conditional Branches
+
+Use `inputs.branches` when you need to route downstream paths based on response content (e.g., empty vs non-empty results). For generic call-failure handling, prefer the shared `error` port instead — don't enumerate every bad status code as a branch.
+
+Each branch's `conditionExpression` is a JS expression with `$self` bound to the current HTTP node's output:
+
+```json
+{
+  "inputs": {
+    "branches": [
+      { "id": "hasItems",  "name": "Has Items",  "conditionExpression": "$self.output.body.items.length > 0" },
+      { "id": "empty",     "name": "Empty",      "conditionExpression": "$self.output.body.items.length == 0" }
+    ]
+  }
+}
+```
+
+Wire `branch-hasItems` / `branch-empty` as source ports on outgoing edges. `default` fires when no branch condition matches.
+
+> **Do not use `=js:` on `conditionExpression`** — HTTP branch conditions are evaluated as JS automatically (same rule as decision/switch expressions). See [variables-and-expressions.md](../../../../shared/variables-and-expressions.md#http-branch-condition-inputsbranchesconditionexpression).
+
+## Dynamic values
+
+IS activity input fields (`url`, `headers`, `body`, `query` under `bodyParameters`) do **not** resolve `{$vars.x}` brace-templates — the template runner only applies to native flow fields. Use `=js:` expressions for any dynamic value; template literals with `${...}` interpolation or string concatenation both work. See [Step 3b — Dynamic values](impl.md#step-3b--dynamic-values-in-url--headers--body--query) for the full rationale and examples.
+
+## Key Inputs (`--detail` for `node configure`)
+
+Run `uip maestro flow node configure` with a `--detail` JSON. The CLI builds the full `inputs.detail` payload, `bindings_v2.json`, and connection resource files automatically. **Do not hand-write `inputs.detail`.**
+
+**Connector mode** (IS connection auth):
+
+| `--detail` Key | Required | Description |
+| --- | --- | --- |
+| `authentication` | Yes | `"connector"` |
+| `method` | Yes | HTTP method: GET, POST, PUT, PATCH, DELETE |
+| `targetConnector` | Yes | Target connector key (e.g., `"uipath-salesforce-slack"`) |
+| `connectionId` | Yes | Target connector's IS connection ID (from `uip is connections list --all-folders`) |
+| `folderKey` | Yes | Orchestrator folder key (from `uip is connections list --all-folders`) |
+| `url` | No | API endpoint URL/path (e.g., `"/conversations.replies"`). Auto-fills both `bodyParameters.path` and `bodyParameters.url`. |
+| `query` | No | Query parameters as key-value object |
+| `headers` | No | Additional headers as key-value object |
+| `body` | No | Request body (for POST/PUT/PATCH) |
+
+**Manual mode** (no connector auth):
+
+| `--detail` Key | Required | Description |
+| --- | --- | --- |
+| `authentication` | Yes | `"manual"` |
+| `method` | Yes | HTTP method: GET, POST, PUT, PATCH, DELETE |
+| `url` | Yes | Full target URL |
+| `query` | No | Query parameters as key-value object |
+| `headers` | No | Additional headers as key-value object |
+| `body` | No | Request body (for POST/PUT/PATCH) |
+
+## Prerequisites
+
+- `uip login` required (for both modes — node type comes from registry)
+- For connector mode: a healthy IS connection must exist for the **target connector**. **If none exists, STOP** — surface in **Open Questions**. See [impl.md Step 2](impl.md#step-2--identify-target-connector-and-connection-connector-mode-only) for connection recovery.
+- `uip maestro flow registry pull` to cache the `core.action.http.v2` definition
+
+## Planning Annotation
+
+In the architectural plan, annotate managed HTTP nodes as:
+- Connector mode: `managed-http: <service> — <operation>` (e.g., "managed-http: Slack — GET /conversations.replies")
+- Manual mode: `managed-http: manual — <method> <url>` (e.g., "managed-http: manual — GET https://api.example.com/data")