@uipath/skills 1.202.0 → 1.202.1-preview.864

package/.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
       "name": "uipath",
       "source": "./",
       "description": "UiPath plugin for Claude Code — custom skills, agents, hooks, and MCP servers for UiPath workflows, UI automation, UI testing and UiPath troubleshoot",
-      "version": "1.202.0",
+      "version": "1.202.1",
       "author": {
         "name": "UiPath"
       },

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "uipath",
-  "version": "1.202.0",
+  "version": "1.202.1",
   "description": "UiPath plugin for Claude Code — custom skills, agents, hooks, and MCP servers for UiPath RPA workflows, UI automation, UI testing, Python coded agents and UiPath troubleshoot",
   "author": {
     "name": "UiPath"

package/.cursor-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "uipath",
   "displayName": "UiPath",
-  "version": "1.202.0",
+  "version": "1.202.1",
   "description": "UiPath plugin for Cursor — skills for building, running, testing, and deploying UiPath automations, agents, coded apps, and platform operations.",
   "author": {
     "name": "UiPath",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uipath/skills",
-  "version": "1.202.0",
+  "version": "1.202.1-preview.864",
   "description": "UiPath agent skills for Claude Code, Codex, Cursor, Copilot, Gemini and OpenCode — RPA, UI automation, UI testing, coded agents/apps/workflows, and troubleshooting. Distributed as the UiPath Claude Code plugin.",
   "author": {
     "name": "UiPath"

package/skills/uipath-maestro-flow/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: uipath-maestro-flow
-description: "TRIGGER for `.flow` files, UiPath Flow / Maestro Flow build/edit requests, and adding or listing IXP model/document-extraction nodes for a Flow. Build, edit, run, debug, fix, evaluate a Maestro Flow (.flow): create/connect nodes (connector, approval, script, subflow, ixp, data fabric entity), triggers, schedules, validate; build conversational flows (chat, chatbot, voice, phone calls); upload, publish, manage runs/instances; diagnose errors, incidents, traces; design eval sets, evaluators, run Studio Web evals. `uip maestro flow` CLI. DO NOT TRIGGER for raw IXP project labelling/prediction review/prompt tuning outside Flow→uipath-ixp; C#/XAML→uipath-rpa; standalone agents→uipath-agents."
+description: "TRIGGER for `.flow` files, UiPath Flow / Maestro Flow / Maestro Automate build/edit requests, and adding or listing IXP model/document-extraction nodes for a Flow. Build, edit, run, debug, fix, evaluate a Maestro Flow (.flow): create/connect nodes (connector, approval, script, subflow, ixp, data fabric entity), triggers, schedules, validate; build conversational flows (chat, chatbot, voice, phone calls); upload, publish, manage runs/instances; diagnose errors, incidents, traces; design eval sets, evaluators, run Studio Web evals. `uip maestro flow` CLI. DO NOT TRIGGER for raw IXP project labelling/prediction review/prompt tuning outside Flow→uipath-ixp; C#/XAML→uipath-rpa; standalone agents→uipath-agents."
 allowed-tools: Bash, Read, Write, Edit, Glob, Grep, AskUserQuestion
 ---
 
@@ -71,6 +71,8 @@ Guide for creating, editing, validating, debugging, publishing, diagnosing, and
 6. **Discover the target solution before scaffolding.** A Flow project must use double nesting: `<Solution>/<Project>/<Project>.flow`. Before any new `uip solution init` or `uip maestro flow init`, run `find . -maxdepth 2 -type f -name '*.uipx' -print`. If a solution exists, stop and ask which to use: one option per solution, "Create a new solution", then "Something else". Do not silently adopt, initialize, delete, or repair an existing solution, even if a new one was requested. If creating one, ask for its name rather than defaulting to the Flow name.
 
    If none exists, create one automatically, defaulting its name to the Flow name unless specified. Prefer solution-first: `uip solution init "<SolutionName>" --output json && cd "<SolutionName>" && uip maestro flow init "<FlowName>" --output json`, producing `<SolutionName>/<FlowName>/<FlowName>.flow` and registering it in the parent `.uipx` (`Data.SolutionRegistration.Status: "Registered"`). Names are independent. A current CLI may auto-scaffold outside a solution as `<FlowName>Solution/<FlowName>Solution.uipx` with `Data.AutoCreatedSolution`; use that only when the solution name does not matter. `--skip-solution-registration` creates a bare single-nested project that fails Studio Web upload and packaging. If the target directory is non-empty, init leaves it untouched. Never omit `cd`, or it auto-scaffolds a duplicate solution. Finish with one `project.uiproj`; remove strays. See [author/greenfield.md](references/author/greenfield.md) Step 2.
+
+   **Maestro Automate is `--automate` on the same command.** When the request names **Maestro Automate** as the product, pass `uip maestro flow init "<Name>" --automate --output json`; otherwise omit the flag. The bare verb is not the signal — "automate invoice intake" asks for a Flow. `--output json` stays either way — Step 2c reads `Data.SolutionRegistration` from it. Do not ask which — the words decide. Everything downstream is identical: same `.flow`, same authoring, same `pack` / `publish` / `debug` / `eval`. The flag only writes `runtimeOptions.profile` into the packaged `operate.json` and drops a `.maestro_automate` marker in the project root, which is how Orchestrator and Studio Web tell the two apart.
 7. **Narrate progress only when requested or clearly opted into.** Otherwise work silently and surface decisions, failures, consent gates, and the final result. When engaged, use one short plain-English line per logical step across CLI calls, shell builtins, edits, and searches; do not narrate flags or JSON structure. See [shared/ux-narration-and-todos.md](references/shared/ux-narration-and-todos.md) §When to engage.
 8. **Maintain a user-facing progress list only when tracking or verbosity is requested.** In silent mode there is no user-facing todo list (the agent MAY track privately). When engaged, journeys above trivial complexity get granular step-level todos; counts follow actual work, not a target. Hide registry lookups, parsing, and file reads inside their logical step. See [shared/ux-narration-and-todos.md](references/shared/ux-narration-and-todos.md) for triggers, granularity, thresholds, and pivots.
 9. **Each node has exactly one author: Edit/Write or CLI, never both.** CLI-owned nodes are connector activities (`uipath.connector.<key>.<op>`), connector triggers (`uipath.connector.trigger.<key>.<trigger>`), wait-for-events (`uipath.connector.event.<key>.<event>`, configured like triggers), and managed HTTP (`core.action.http.v2`); add/configure them with `uip maestro flow node add` and `node configure`. All others—triggers, control flow, logic, HITL, patterns, agents, resource nodes, and queues—are user-owned and should be authored directly with `Edit` or `Write`. Never full-file `Write` a flow containing CLI-owned nodes because it can clobber CLI-set `bindings[]` and `inputs.detail`; use `Edit` or configure CLI-owned nodes last. Their `inputs.detail` is a `=jsonString:essentialConfiguration` envelope rejected when hand-authored. Inline-agent CLI is limited to `uip agent init / refresh / validate --inline-in-flow`; the `uipath.agent.autonomous` node is user-owned. Scripting (`python`, `node`, `jq`, `sed`, `awk`, or shell heredocs) is a last resort for user-owned edits and requires explicit approval after explaining state bypass, opaque diffs, and lack of interruption points. See [author/CAPABILITY.md — Node ownership](references/author/CAPABILITY.md#node-ownership--who-authors-the-node) and [author/editing-operations.md — Tool Selection Ladder](references/author/editing-operations.md#tool-selection-ladder).

package/skills/uipath-maestro-flow/references/author/CAPABILITY.md

@@ -8,7 +8,7 @@ Capability index for building new flows (greenfield) and editing existing flows
 
 ## When to use this capability
 
-- Create a new Flow project with `uip maestro flow init`
+- Create a new Flow project with `uip maestro flow init`, or a Maestro Automate one with `uip maestro flow init --automate`
 - Edit a `.flow` file — adding nodes, edges, or logic
 - Explore available node types via the registry
 - Validate a Flow file locally
@@ -112,12 +112,12 @@ If you find yourself hand-writing `inputs.detail`, a `=jsonString:` blob, or `bi
 | **List IxP models / runtime projects available in flow** | [plugins/ixp/impl.md — Listing Published Models](plugins/ixp/impl.md#listing-published-models) — read-only registry search, no `.flow` scaffold or edits |
 | **Create a resource that doesn't exist yet** | Use `core.logic.mock` placeholder — see [Edit/Write: Replace a mock](editing-operations-json.md#replace-a-mock-with-a-real-resource-node), then the `impl.md` of the plugin for the node that *replaces* the mock (`core.logic.mock` has no plugin of its own) |
 | **Add data transform nodes** | [plugins/transform/impl.md](plugins/transform/impl.md) |
-| **Add an LLM batch transform over CSV rows** | [plugins/batch-transform/impl.md](plugins/batch-transform/impl.md) — `uipath.pattern.batch-transform`, gated by tenant flag `canvas.nodes.batch-transform` |
-| **Summarize / synthesize one document with optional citations** | [plugins/summarize/impl.md](plugins/summarize/impl.md) — `uipath.pattern.deep-rag`, gated by tenant flag `canvas.nodes.summarize` |
+| **Add an LLM batch transform over CSV rows** | [plugins/batch-transform/impl.md](plugins/batch-transform/impl.md) — `uipath.pattern.batch-transform` |
+| **Summarize / synthesize one document with optional citations** | [plugins/summarize/impl.md](plugins/summarize/impl.md) — `uipath.pattern.deep-rag` |
 | **Create a subflow** | [plugins/subflow/impl.md](plugins/subflow/impl.md) + [Edit/Write: Create a subflow](editing-operations-json.md#create-a-subflow) |
 | **Add a delay or scheduled trigger** | [plugins/delay/](plugins/delay/) or [plugins/scheduled-trigger/](plugins/scheduled-trigger/) |
 | **Use queue nodes** | [plugins/queue/impl.md](plugins/queue/impl.md) |
-| **Read or write Data Fabric entity records** | [plugins/data-fabric/impl.md](plugins/data-fabric/impl.md) — `core.datafabric.read` / `create` / `update` / `delete`, each gated by its own `canvas.nodes.*-entity` tenant flag |
+| **Read or write Data Fabric entity records** | [plugins/data-fabric/impl.md](plugins/data-fabric/impl.md) — `core.datafabric.read` / `create` / `update` / `delete`, the default for record CRUD. Any other Data Service operation, or an explicit request for the connector, goes to [plugins/connector/impl.md](plugins/connector/impl.md) |
 
 ## Anti-patterns
 
@@ -158,7 +158,7 @@ If you find yourself hand-writing `inputs.detail`, a `=jsonString:` blob, or `bi
 - [planning-arch.md](planning-arch.md) — capability discovery, plugin index, topology design
 - [planning-impl.md](planning-impl.md) — registry lookups, connection binding, wiring rules
 - [plugins/](plugins/) — per-node-type planning + impl docs:
-  - [connector](plugins/connector/) — IS connector nodes (incl. the `uipath-uipath-dataservice` entity activities; see [data-fabric](plugins/data-fabric/))
+  - [connector](plugins/connector/) — IS connector nodes, and the path for every Data Service operation that is not record CRUD, or when the user names the connector (the `uipath-uipath-dataservice` entity activities; see [data-fabric](plugins/data-fabric/))
   - [connector-trigger](plugins/connector-trigger/)
   - [script](plugins/script/) — Jint ES2020 JavaScript
   - [http](plugins/http/) — `core.action.http.v2` (Managed HTTP Request)
@@ -185,7 +185,7 @@ If you find yourself hand-writing `inputs.detail`, a `=jsonString:` blob, or `bi
   - [inline-voice-agent](plugins/inline-voice-agent/) — voice agent on a live phone call (inbound/outbound) + the trigger, create-call, and end-call nodes
   - [ixp](plugins/ixp/) — published IxP document-extraction models (PDFs, scanned forms, receipts, invoices, contracts)
   - [queue](plugins/queue/) — Orchestrator queue item creation
-  - [data-fabric](plugins/data-fabric/) — native Data Fabric entity record CRUD (`core.datafabric.*`); tenant flags default to off
+  - [data-fabric](plugins/data-fabric/) — native Data Fabric entity record CRUD (`core.datafabric.*`); the default path for those four operations
 
 ### Cross-capability (shared)
 

package/skills/uipath-maestro-flow/references/author/greenfield.md

@@ -97,6 +97,14 @@ uip solution init "<SolutionName>" --output json \
 
 > **One creation path — never drop the `cd`.** `uip solution init "<SolutionName>"` → `cd "<SolutionName>"` → `uip maestro flow init "<ProjectName>"`, one chain. Without the `cd`, `flow init` runs in the old directory and auto-scaffolds a duplicate `<ProjectName>Solution/` (1-node husk). Never let auto-scaffold create the solution. Finish with exactly one `project.uiproj` — delete strays.
 
+> **Building a Maestro Automate?** Add `--automate` to the `flow init` segment and change nothing else:
+>
+> ```bash
+> && uip maestro flow init "<ProjectName>" --automate --output json \
+> ```
+>
+> Only when the request names **Maestro Automate** as the product. The bare verb does not count — "automate invoice intake with a Flow" asks for a Flow. Anything else, including no signal, leaves the flag off. Steps 3-6 are identical either way — the flag changes the packaged `runtimeOptions.profile`, not how you author the `.flow`. See [SKILL.md rule #6](../../SKILL.md#critical-rules-universal).
+
 Tail-append one `node add` per CLI-owned node (`uipath.connector.*`, `uipath.connector.trigger.*`, `core.action.http.v2`). Each `node add` returns the new node `id` in `Data` — capture it from the chained output for T2/T3. Drop the trailing `node add` segment when the flow is OOTB-only.
 
 In the SAME assistant message (parallel to this chain): emit one `Bash` per OOTB `registry get <NODE_TYPE>` you'll need in T2 (always `core.control.end` — see Step 4), and parallel `Read` calls for any plugin `impl.md`s you'll consult.
@@ -121,6 +129,8 @@ Creates `<cwd>/<SolutionName>/<SolutionName>.uipx`. **`cd` into the new solution
 cd <directory>/<SolutionName> && uip maestro flow init <ProjectName> --output json
 ```
 
+Append `--automate` for a Maestro Automate project (SKILL.md rule #6). The rest of this step, and Steps 3-6, are unchanged.
+
 The `cd` puts the project inside the solution you just created. Skip it and `flow init` won't find that solution (discovery walks **up**, not down into `<SolutionName>/`) — it auto-scaffolds a **second, separate** `<ProjectName>Solution/` beside your empty `<SolutionName>/`, leaving two solutions. The project no longer single-nests, but `cd` first to land in the right one.
 
 > **Bash session state persists across tool calls.** This `cd` is **not scoped to one Bash invocation** — your cwd remains inside `<SolutionName>/` for every subsequent `Bash` call until you `cd` somewhere else. Plan the rest of Step 2 (and Steps 3–6) accordingly: either keep using paths relative to the solution dir, or anchor with `$(pwd)` / the absolute `Data.Path` returned by `flow init`. Do NOT prefix later commands with the original `<directory>/<SolutionName>/...` — that would resolve as `<SolutionName>/<directory>/<SolutionName>/...` and look like a layout bug when it isn't.

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

@@ -105,15 +105,15 @@ Every flow has exactly one trigger, first in topology. IS connector triggers rep
 | `core.action.http.v2` | [http](plugins/http/planning.md) | REST API; connector or manual mode; replaces deprecated `core.action.http` |
 | `core.action.transform` | [transform](plugins/transform/planning.md) | Declarative map, filter, or group-by |
 | Wait for events | [connector-trigger](plugins/connector-trigger/planning.md) | Mid-flow external event; type `uipath.connector.event.<key>.<event>` with `input` |
-| `uipath.pattern.batch-transform` | [batch-transform](plugins/batch-transform/planning.md) | Append LLM-generated columns to CSV rows; gated by `canvas.nodes.batch-transform` |
-| `uipath.pattern.deep-rag` (Summarize) | [summarize](plugins/summarize/planning.md) | Synthesis/Q&A over one document with optional citations; gated by `canvas.nodes.summarize` |
+| `uipath.pattern.batch-transform` | [batch-transform](plugins/batch-transform/planning.md) | Append LLM-generated columns to CSV rows |
+| `uipath.pattern.deep-rag` (Summarize) | [summarize](plugins/summarize/planning.md) | Synthesis/Q&A over one document with optional citations |
 | `core.logic.delay` | [delay](plugins/delay/planning.md) | Duration or date wait |
 | `core.action.queue.create` | [queue](plugins/queue/planning.md) | Fire-and-forget robot work |
 | `core.action.queue.create-and-wait` | [queue](plugins/queue/planning.md) | Robot work with result wait |
-| `core.datafabric.read` | [data-fabric](plugins/data-fabric/planning.md) | Read one record or a filtered list from a Data Fabric entity; gated by `canvas.nodes.read-entity` |
-| `core.datafabric.create` | [data-fabric](plugins/data-fabric/planning.md) | Insert a record and return the stored row; gated by `canvas.nodes.create-entity` |
-| `core.datafabric.update` | [data-fabric](plugins/data-fabric/planning.md) | Patch named columns on one record; gated by `canvas.nodes.update-entity` |
-| `core.datafabric.delete` | [data-fabric](plugins/data-fabric/planning.md) | Delete one record; gated by `canvas.nodes.delete-entity` |
+| `core.datafabric.read` | [data-fabric](plugins/data-fabric/planning.md) | Read one record or a filtered list from a Data Fabric entity |
+| `core.datafabric.create` | [data-fabric](plugins/data-fabric/planning.md) | Insert a record and return the stored row |
+| `core.datafabric.update` | [data-fabric](plugins/data-fabric/planning.md) | Patch named columns on one record |
+| `core.datafabric.delete` | [data-fabric](plugins/data-fabric/planning.md) | Delete one record |
 | `uipath.human-in-the-loop.quick-form` | [hitl](plugins/hitl/planning.md) | Inline human review, approval, or data entry |
 | `uipath.conversational.wait-for-message` | [conversational-agent](plugins/conversational-agent/planning.md) | Pause until the user sends a chat message (initiates an exchange); returns the conversation context |
 | `uipath.conversational.send-message` | [conversational-agent](plugins/conversational-agent/planning.md) | Write a message the flow composes itself into the chat |
@@ -174,7 +174,13 @@ Prefer, in order:
 2. `core.action.http.v2` connector mode when the connector lacks the activity, or manual mode for APIs without connectors ([http](plugins/http/planning.md)).
 3. An RPA workflow only when there is no API, such as a desktop app or terminal ([rpa](plugins/rpa/planning.md)).
 
-**Data Fabric is not on this ladder.** Entity records have two paths — the `uipath-uipath-dataservice` connector activities and the native `core.datafabric.*` nodes — and availability decides, not preference. The native flags default to off, so **when `registry get core.datafabric.<op>` answers "Node not found", or search reports `AvailableOnTenant: false`, build with the connector activities**: do not retry, do not `uip tools update`, and never hand-write a `definitions[]` entry for a node the registry will not return. Rationale and the federated-entity case in [data-fabric/planning.md — Native node vs Data Service connector](plugins/data-fabric/planning.md#native-node-vs-data-service-connector--availability-decides).
+**Data Fabric entity records are the one exception, and the split is by operation.** Record CRUD has two paths — the native `core.datafabric.*` nodes and the `uipath-uipath-dataservice` connector activities:
+
+- **Record CRUD (read / create / update / delete) — default to the native node** wherever Flow carries it natively. It needs no Integration Service connection.
+- **Every other Data Service operation — use the connector activities.** Only the four CRUD operations exist natively; attachments, file fields, entity metadata and everything else have no native node, so the connector is not a fallback there, it is the only path.
+- **An explicit request for connector activities wins over both.** If the user asks for the Data Service connector by name, build it with the connector as long as that activity exists — do not override them with the native node.
+
+Confirm the native node with the probe and recovery in [data-fabric/impl.md — Registry validation](plugins/data-fabric/impl.md#registry-validation), the single procedure for this error; on its final "use the connector" outcome, build with the connector activities. Never hand-write a `definitions[]` entry for a node the registry will not return. Rationale and the federated-entity case in [data-fabric/planning.md — Native node vs Data Service connector](plugins/data-fabric/planning.md#native-node-vs-data-service-connector--the-operation-decides).
 
 ## Standard Port Reference
 

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

@@ -21,7 +21,7 @@ Confirm:
 - `outputDefinition.output.source`: `"=response"` (the BPMN engine wraps the result under that key, as for every ServiceTask).
 - `outputDefinition.error.schema.required`: `code`, `message`, `detail`, `category`, `status`.
 
-If the command reports **"Node type not found: uipath.pattern.batch-transform"**, run `uip tools update` and `uip maestro flow registry pull --force`. If it still fails, confirm with the UiPath admin that the tenant's `canvas.nodes.batch-transform` server flag is enabled.
+If the command reports **"Node type not found: uipath.pattern.batch-transform"**, run `uip tools update` and `uip maestro flow registry pull --force`. If it still fails, this CLI build does not carry the node — there is no tenant setting behind it and no admin to escalate to.
 
 ## Add or edit the node
 
@@ -153,7 +153,7 @@ The validator checks that `attachment`, `prompt`, and `outputColumns` are presen
 
 | Error | Cause | Fix |
 | --- | --- | --- |
-| `Node type not found: uipath.pattern.batch-transform` | CLI predates Batch Transform support, or tenant flag `canvas.nodes.batch-transform` is off | Run `uip tools update`, then `uip maestro flow registry pull --force`; if still missing, check with the admin that `canvas.nodes.batch-transform` is enabled |
+| `Node type not found: uipath.pattern.batch-transform` | This CLI build predates Batch Transform support | Run `uip tools update`, then `uip maestro flow registry pull --force`; no tenant setting governs this, so there is no admin to escalate to |
 | Validate rejects `outputColumns` | Wrong shape, such as a map `{ name: description }` or string array | Use `[{ "name": "...", "description": "..." }, ...]` |
 | Runtime error `exceeded maxColumns` | More than 10 output columns | Reduce to ≤10 or split across two Batch Transform nodes chained on the output file |
 | All rows produce blank values for a column | `description` is vague or references fields absent from the source CSV | Name the source column(s) in the description and test with a small sample |

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

@@ -6,7 +6,7 @@ The Batch Transform node runs an LLM over every row of an attached CSV (or simil
 
 `uipath.pattern.batch-transform`
 
-This is a fixed OOTB node type — no registry suffix, one version. It does not appear in `uip maestro flow registry list` unless the tenant has the platform-side `canvas.nodes.batch-transform` feature flag enabled. The uip CLI unconditionally requests this flag in its manifest fetch, so the node will appear once the server rolls the flag out to your tenant.
+This is a fixed OOTB node type — no registry suffix, one version. Whether it appears in `uip maestro flow registry list` is a property of the CLI build, not of the tenant: the CLI asks for a fixed set of OOTB node manifests, and the server only adds dynamic nodes on top — it never withholds an OOTB one. If the node is missing, upgrade the CLI.
 
 ## When to Use
 

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

@@ -266,7 +266,11 @@ Illustrative supported activities (confirm against `registry get` for the specif
 | `uipath-sap-s4hanacloud` | `Entity` | Create Entity | POST | method |
 | `uipath-google-bigquery` | `projects::table` | List All Records | GET | method |
 
-> **Data Fabric also has native nodes — check whether they exist before choosing.** `core.datafabric.read` / `create` / `update` / `delete` ([data-fabric/planning.md](../data-fabric/planning.md)) need no Integration Service connection and are authored with `Edit`/`Write` instead of `node configure`, so they are the lighter path **when the tenant has them**. Their flags default to off, so confirm with `uip maestro flow registry get core.datafabric.read` first. If that answers "Node not found" — or search reports `AvailableOnTenant: false` — these `uipath-uipath-dataservice` activities are the correct path; stay here. Stay here too when the entity is federated, since the native writes require a native entity.
+> **Data Fabric record CRUD has native nodes — they are the default; everything else on this connector is not.** `core.datafabric.read` / `create` / `update` / `delete` ([data-fabric/planning.md](../data-fabric/planning.md)) need no Integration Service connection and are authored with `Edit`/`Write` instead of `node configure`, so for those four operations go native: confirm with `uip maestro flow registry get core.datafabric.read`, and on `NodeGetSuccess` leave this doc. Stay here when **any** of these hold — and they are common:
+>
+> - the operation is **not** one of those four (attachments, file-field downloads, entity metadata, bulk work) — no native node exists, so these activities are the only path, not a fallback; **these activities target the tenant scope only — folder-scoped entities are not supported, so require a tenant-scoped entity**;
+> - the **user asked for the connector by name** — an explicit request outranks the native default, so build it here as long as the activity exists;
+> - `registry get` ends at "Node not found" after [data-fabric/impl.md — Registry validation](../data-fabric/impl.md#registry-validation).
 
 Run Step 3a and use the matched action's `name` and `apiConfiguration.{url,body}` tokens. Match `source: field` or `source: method` according to metadata; for operation-scoped lookup use the node definition's `model.context[].method`.
 

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

@@ -29,18 +29,18 @@ Confirm on `Data.Node`:
 - `runtimeConstraints.exclude` — contains `api-function`.
 - `version` — copy it verbatim into the instance's `typeVersion`. The four are versioned independently; do not assume one version across the family.
 
-If `registry get` reports **"Node not found"**, the node is not available to you. Run `uip tools update`, then `uip maestro flow registry pull --force`, and retry. If it still fails, that node's tenant feature flag is off:
+If `registry get` reports **"Node not found"**, this CLI build does not carry the node. **This is the single recovery procedure for that error** — the planning docs defer here, so do not improvise a different one:
 
-| Node type | Flag to ask the admin about |
-| --- | --- |
-| `core.datafabric.read` | `canvas.nodes.read-entity` |
-| `core.datafabric.create` | `canvas.nodes.create-entity` |
-| `core.datafabric.update` | `canvas.nodes.update-entity` |
-| `core.datafabric.delete` | `canvas.nodes.delete-entity` |
+1. Run `uip tools update`.
+2. Run `uip maestro flow registry pull --force`.
+3. Retry `registry get` **once**.
+4. Still "Node not found" → build with the connector (see below). Do not loop.
+
+No tenant setting governs **whether the registry serves this node**, so there is no administrator to escalate to for step 4: the CLI decides which node manifests it asks for, and older builds did not ask for these four. (That scoping matters — the *runtime* engine version is a separate axis, and it does have a platform-side failure mode. See the engine-fallback row in [Debug](#debug).)
 
-`registry search` is not a substitute for `registry get` here. A flag-gated node can still appear in search with `AvailableOnTenant: false` while `registry get` refuses it — and without `registry get` you cannot source the `definitions[]` entry, which must never be hand-written ([Author capability, rule 6](../../CAPABILITY.md#critical-rules)).
+`registry search` is not a substitute for `registry get` here. A node can appear in search with `AvailableOnTenant: false` while `registry get` refuses it — and without `registry get` you cannot source the `definitions[]` entry, which must never be hand-written ([Author capability, rule 6](../../CAPABILITY.md#critical-rules)).
 
-**When the node is unavailable, switch to the connector and stop.** `AvailableOnTenant: false` is a decision, not an obstacle: build the flow with the `uipath-uipath-dataservice` activities ([connector/impl.md](../connector/impl.md)) and say in the final report that the native nodes were unavailable. Do not retry `registry get`, do not run `uip tools update` hoping for a newer manifest, and above all **do not hand-author a `definitions[]` entry from this doc's field list to stand in for the missing one** — a hand-written definition carries the wrong port schema, passes `flow validate`, and fails at runtime.
+**If the retry still fails, switch to the connector and stop.** Build the flow with the `uipath-uipath-dataservice` activities ([connector/impl.md](../connector/impl.md)) and say in the final report that this CLI could not serve the native nodes. Above all, **do not hand-author a `definitions[]` entry from this doc's field list to stand in for the missing one** — a hand-written definition carries the wrong port schema, passes `flow validate`, and fails at runtime.
 
 ## Add or edit the node
 
@@ -400,9 +400,10 @@ Use `uip df entities get` and `uip df records list` to close that gap before shi
 
 | Symptom | Cause | Fix |
 | --- | --- | --- |
-| `Node not found: core.datafabric.*` on `registry get` | Tenant flag off, or CLI predates the node | `uip tools update`, then `uip maestro flow registry pull --force`; then confirm that node's flag with the admin (see the table above) |
+| `Node not found: core.datafabric.*` on `registry get` | This CLI build does not carry the node | `uip tools update`, then `uip maestro flow registry pull --force`; if it still fails, use the connector — no tenant setting governs this |
 | Node validates clean, runs green, nothing written | Most often a **selector** problem, not a binding one: `readEntityNodeId` names a missing node or a multi-record read, the read's filters do not compile, or the `fromRead` read matched more than one record at runtime | Check the Read node's `id` matches exactly and its `resultMode` is `single`; confirm the filter identifies exactly one record with `uip df records list` |
 | Write runs green, row unchanged | The body was rejected and the rejection swallowed — a federated entity, a system or attachment column, a choice-set label instead of its numeric id, an uncoercible value, or a null into a non-nullable column | Re-check the entity is native and each column against `uip df entities get` |
+| Create runs green, no row inserted | Platform-side, not authoring: the BPMN engine predates the create postprocessor, so `GetDataFabricAction()` falls back to `"update"`. The registry served the node correctly — the *runtime* is the older half | Confirm against a newer engine, or build the insert with the connector's Create Entity Record ([connector/impl.md](../connector/impl.md)) |
 | Downstream `$vars.<id>.output` is `undefined` | `variables.nodes[]` missing, or the read matched nothing | Run `uip maestro flow format`; if it persists, verify the filter matches a real record |
 | A Loop over a multi-record read iterates nothing | Wired `output` instead of `output.results` | Use `=js:$vars.<readId>.output.results` |
 | Multi-record read returns only some rows | The limit is always explicit and capped at 1000 | Page with `_skip`; raising `_recordLimit` past 1000 truncates silently |
@@ -412,14 +413,14 @@ Use `uip df entities get` and `uip df records list` to close that gap before shi
 
 ## What not to do
 
-- **Do not hand-write `definitions[]`** — copy verbatim from `registry get`. A flag-gated node you cannot `registry get` is a node you cannot author.
+- **Do not hand-write `definitions[]`** — copy verbatim from `registry get`. A node you cannot `registry get` is a node you cannot author.
 - **Do not put a `model` block on the instance.** `bpmn:Task` and the debug runtime live in the definition.
 - **Do not add an instance `outputs` block.** The canvas writes none for these nodes; the manifest `outputDefinition` plus `flow format`'s `variables.nodes[]` carry the contract.
 - **Do not wire an `error` edge or set `errorHandlingEnabled`** — these four nodes have no error port. See [No error port](#no-error-port).
 - **Do not write to a federated entity.** Create, Update and Delete require a native entity; the rejection is swallowed, so the run looks successful.
 - **Do not write a system column** (`Id`, `CreateTime`, `CreatedBy`, `UpdateTime`, `UpdatedBy`) or an attachment column.
 - **Do not put a choice-set label in a value or a filter** — use the numeric `numberId`.
-- **Do not treat `AvailableOnTenant: false` as usable** because search returned the node.
+- **Do not treat a search hit as proof you can author the node** — only `registry get` returning `NodeGetSuccess` is.
 - **Do not use a Data Fabric node in an API workflow** — all four exclude the `api-function` runtime.
 - **Do not reference `$self` in a filter value,** and do not leave a filter expression blank — either refuses the whole query and strands every downstream reference.
 - **Do not add a placeholder value to satisfy Create's "at least one value" rule.** The rule exists because a blank-only insert writes nothing; a junk value writes junk.

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

@@ -13,16 +13,15 @@ Use them whenever the flow's own data lives in Data Fabric: a case record, a loo
 | `core.datafabric.update` | Update entity record | Patch named columns on one record |
 | `core.datafabric.delete` | Delete entity record | Delete one record (no output) |
 
-These are fixed OOTB node types — no registry suffix, no connector key. Each is gated by its own tenant feature flag, so a tenant can have Read without Create:
+These are fixed OOTB node types — no registry suffix, no connector key.
 
-| Node Type | Tenant flag |
-| --- | --- |
-| `core.datafabric.read` | `canvas.nodes.read-entity` |
-| `core.datafabric.create` | `canvas.nodes.create-entity` |
-| `core.datafabric.update` | `canvas.nodes.update-entity` |
-| `core.datafabric.delete` | `canvas.nodes.delete-entity` |
+Whether your CLI can serve them is a property of the CLI build, not of the tenant, and `registry get <type>` is the only way to find out. Probe it once before planning around a node:
+
+```bash
+uip maestro flow registry get core.datafabric.read --output json
+```
 
-A node whose flag is off is filtered out of the manifest entirely: `registry search` may still list it with `AvailableOnTenant: false`, but `registry get` answers **"Node not found"** and you cannot source its `definitions[]` entry. Confirm availability before planning around one — see [impl.md — Registry validation](impl.md#registry-validation).
+`Code: NodeGetSuccess` means you can author the node and source its `definitions[]` entry. **"Node not found"** means this CLI does not carry it. Do not ask an administrator to change a tenant setting — no tenant setting governs whether the registry serves this node. Follow [impl.md — Registry validation](impl.md#registry-validation) for the recovery steps and the point at which to give up and use the [connector](../connector/planning.md); it is the single procedure for this error, so do not improvise a different one here.
 
 ## Writes require a native entity
 
@@ -45,19 +44,23 @@ Use these nodes when the record lives in **Data Fabric** and the flow itself is
 | Advance a status, stamp a result, write back an outcome | Yes — Update (native entity) |
 | Append a new row (case, audit entry, request) | Yes — Create (native entity) |
 | Remove a row the flow has finished with | Yes — Delete (native entity) |
-| Write to a federated entity | No — these nodes cannot; use [connector](../connector/planning.md) or [http](../http/planning.md) |
+| Write to a federated entity | No — and the connector is not a way round it; writing a federated entity is blocked. Write to the source system instead, via its own connector or [http](../http/planning.md) |
 | React to a record being created/updated **elsewhere** | No — that is a trigger; use [connector-trigger](../connector-trigger/planning.md) (`uipath.connector.trigger.uipath-uipath-dataservice.record-created` / `record-updated`) |
 | Aggregate, group, or reshape rows already in memory | No — use [Transform](../transform/planning.md) |
 | Bulk-load a CSV into an entity | No — that is a data-loading job, not a flow step; use `uip df records import` out of band |
 | Read a record from a non-UiPath system | No — use [connector](../connector/planning.md) or [http](../http/planning.md) |
 
-### Native node vs Data Service connector — availability decides
+### Native node vs Data Service connector — the operation decides
+
+The `uipath-uipath-dataservice` Integration Service connector also exposes entity operations (`query-entity-records`, `create-entity-record`, `update-entity-record`, `get-entity-record-by-id`, `delete-entity-record`, …), and `registry search` surfaces both families. Route by the operation, in this order:
 
-The `uipath-uipath-dataservice` Integration Service connector also exposes entity operations (`query-entity-records`, `create-entity-record`, `update-entity-record`, `get-entity-record-by-id`, `delete-entity-record`, …), and `registry search` surfaces both families.
+1. **The user named the connector.** Build the connector activity, provided it exists for that operation. An explicit instruction outranks the default — do not silently substitute the native node.
+2. **Record CRUD (read / create / update / delete) → default to the native node.** Confirm it with one `registry get core.datafabric.<op>`; on `NodeGetSuccess` build native. On "Node not found", follow [impl.md — Registry validation](impl.md#registry-validation) and take the connector at the end of it.
+3. **Any other entity operation → the connector.** Only those four operations have a native node. Attachments, file-field downloads, entity metadata and bulk operations do not, so the connector is the only path rather than a fallback.
 
-**Check availability before you choose — do not default to the native node.** All four tenant flags default to off, so the connector is the working path until `registry get core.datafabric.<op>` proves otherwise. On "Node not found" or `AvailableOnTenant: false`, build with the [connector](../connector/planning.md) and stop pursuing the native path — as you should when the entity is federated, since the native writes require a native entity.
+A **federated** entity is not a routing question: writing one is blocked, so the connector is not an alternative path for it. See [Writes require a native entity](#writes-require-a-native-entity).
 
-Where the tenant *does* have them, the native node is the better build, because it:
+Where the native node applies and the probe succeeds, it is the better build, because it:
 
 - needs **no Integration Service connection** — nothing to create, bind, or keep healthy, and no `bindings[]` connection row;
 - is **user-owned** — author it with `Edit`/`Write` instead of the CLI's `node add` + `node configure` envelope (see [Author capability — Node ownership](../../CAPABILITY.md#node-ownership--who-authors-the-node));

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

@@ -19,7 +19,7 @@ Confirm:
 - `outputDefinition.output.schema`: top-level `id` (string) and `content` (object|null), with `content.Text` (string) and `content.Citations` (array|null) containing `{ Ordinal: integer, PageNumber: integer, Source: string, Reference: string }`.
 - `outputDefinition.error.schema.required`: `code`, `message`, `detail`, `category`, `status`.
 
-If the command returns **"Node type not found: uipath.pattern.deep-rag"**, run `uip tools update` and `uip maestro flow registry pull --force`. If it still fails, confirm with a UiPath admin that the tenant's `canvas.nodes.summarize` server flag is enabled.
+If the command returns **"Node type not found: uipath.pattern.deep-rag"**, run `uip tools update` and `uip maestro flow registry pull --force`. If it still fails, this CLI build does not carry the node — there is no tenant setting behind it and no admin to escalate to.
 
 ## Authoring and attachment wiring
 
@@ -170,7 +170,7 @@ The validator checks that required inputs (`attachment`, `prompt`) are present a
 
 | Error | Cause | Fix |
 | --- | --- | --- |
-| `Node type not found: uipath.pattern.deep-rag` | CLI predates Summarize support, or tenant flag `canvas.nodes.summarize` is off | Run `uip tools update` and `uip maestro flow registry pull --force`; if still missing, check with an admin that `canvas.nodes.summarize` is enabled |
+| `Node type not found: uipath.pattern.deep-rag` | This CLI build predates Summarize support | Run `uip tools update` and `uip maestro flow registry pull --force`; no tenant setting governs this, so there is no admin to escalate to |
 | Runtime: synthesis returns empty `content.Text` | Prompt is vague, or attachment is unreadable, such as an image-only PDF with no OCR or a corrupted file | Tighten the prompt; confirm the attachment type is supported and has selectable text |
 | `content.Citations` missing despite `returnCitations: true` | A downstream consumer read `inputDefaults` before runtime output existed | Reference `$vars.{nodeId}.output.content.Citations` only in nodes downstream of Summarize; do not precompute |
 | Downstream `result.content.text` / `result.content.citations` is `undefined` | Lowercase field names were used | Use `result.content.Text` / `result.content.Citations` |

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

@@ -6,7 +6,7 @@ The Summarize node comprehensively synthesizes one attached document (PDF, Word,
 
 `uipath.pattern.deep-rag`
 
-The wire type remains `deep-rag` although the canvas name is "Summarize"; this is contractual with the runtime serializer. This fixed OOTB type has no registry suffix and one version. It appears only when the platform-side `canvas.nodes.summarize` feature flag is enabled. The uip CLI requests this flag unconditionally in its manifest fetch, so the node appears after server rollout to the tenant. It does not appear in `uip maestro flow registry list` before then.
+The wire type remains `deep-rag` although the canvas name is "Summarize"; this is contractual with the runtime serializer. This fixed OOTB type has no registry suffix and one version. Whether it appears in `uip maestro flow registry list` is a property of the CLI build, not of the tenant: the CLI asks for a fixed set of OOTB node manifests, and the server only adds dynamic nodes on top — it never withholds an OOTB one. If the node is missing, upgrade the CLI.
 
 ## When to Use
 

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

@@ -268,6 +268,8 @@ uip maestro flow init <ProjectName> --output json
 #   uip solution projects add <SolutionName>/<ProjectName> <SolutionName>/<SolutionName>.uipx
 ```
 
+> **Was the broken project a Maestro Automate one?** This recipe rebuilds it, so carry `--automate` on the `flow init` above. Check before deleting: a `.maestro_automate` file in the project root means it was. Rebuilding without the flag returns a plain Flow, and nothing downstream reports the change.
+
 After running, verify the file exists at the double-nested path. The `cd <SolutionName>` above persists across Bash calls, so anchor the check with `$(pwd)` instead of repeating `<SolutionName>/`:
 
 ```bash

package/skills/uipath-maestro-flow/references/shared/cli-commands.md

@@ -13,6 +13,8 @@ uip solution init "<SolutionName>" --output json
 cd <directory>/<SolutionName> && uip maestro flow init <ProjectName> --output json
 ```
 
+Add `--automate` to create a Maestro Automate project instead of a Flow. Nothing else changes — same scaffold, same authoring, same `pack` / `publish` / `debug` / `eval`; the flag writes `runtimeOptions.profile` into the packaged `operate.json` and a `.maestro_automate` marker into the project root.
+
 Confirm `Data.SolutionRegistration.Status`: `Registered`, `AlreadyRegistered`, `OptedOut`, `Skipped`, `Failed`, or `NotInSolution`. Inside a solution, `flow init` auto-registers the project with the parent `.uipx`. Outside one, it creates `<ProjectName>Solution/<ProjectName>Solution.uipx`, nests the project, and adds `Data.AutoCreatedSolution`. `--skip-solution-registration` opts out with status `OptedOut`; do not manually wire an intentionally opted-out project. Manually wire `Skipped`, `Failed`, or the rare `NotInSolution`:
 
 ```bash
@@ -250,7 +252,9 @@ The cache expires after 30 minutes. `registry search` returns a flat `Data` arra
 { "Data": [{ "NodeType": "uipath.connector.uipath-salesforce-sfdc.list-records", "Category": "connector.196536", "DisplayName": "List Records", "Description": "(Salesforce) List records in Salesforce", "Version": "1.0.0", "Tags": "connector, activity", "AvailableOnTenant": true }] }
 ```
 
-Treat `AvailableOnTenant` as a usability gate: `true` permits `registry get <NodeType>` or `node add <NodeType>`; `false` means the node is not enabled or available for the tenant. Do not use unsupported flags such as `--include-unavailable`; choose an enabled alternative, use `--local` for in-solution resources, or report unavailability.
+Treat `AvailableOnTenant` as a usability gate: `true` permits `registry get <NodeType>` or `node add <NodeType>`; `false` means the type is missing from the manifest this CLI pulled. Despite the name it is not a tenant entitlement — the CLI asks for a fixed set of node manifests decided by its own build, so `false` usually means this CLI does not carry the node rather than that an administrator withheld it.
+
+Do not use unsupported flags such as `--include-unavailable`, and do not loop on the upgrade: try `uip tools update` **once**, and if the type is still absent treat it as absent by design for this build — choose an available alternative, use `--local` for in-solution resources, or report it as unavailable. Around ten of the node families the manifest knows about are deliberately outside the set this CLI requests (`agent-memory`, `queue-operations`, `form-trigger`, `http-standalone`, `agent-tool-http-request`, `classify-document`, `do-while`, `hitl-document`, …), so no upgrade will ever surface them and each extra `tools update` + `registry pull` is wasted work.
 
 `registry get` returns `Data.Node` verbatim for the `.flow` `definitions` array. Preserve its manifest casing, predominantly camelCase (`nodeType`, `inputDefinition`, `supportsErrorHandling`, `form`); filter with `--output-filter "Node.inputDefinition"`, not `Node.InputDefinition`.
 

package/version-manifest.json

@@ -1,5 +1,5 @@
 {
   "schemaVersion": 2,
-  "skillsVersion": "1.202.0",
+  "skillsVersion": "1.202.1-preview.864",
   "targetCli": "^1.202.0"
 }