npm - @uipath/skills - Versions diffs - 1.202.1 → 1.202.2-preview.911 - Mend

@uipath/skills 1.202.1 → 1.202.2-preview.911

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (34) hide show

package/.claude-plugin/marketplace.json CHANGED Viewed

@@ -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.1",
+      "version": "1.202.2",
       "author": {
         "name": "UiPath"
       },

package/.claude-plugin/plugin.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "uipath",
-  "version": "1.202.1",
+  "version": "1.202.2",
   "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 CHANGED Viewed

@@ -1,7 +1,7 @@
 {
   "name": "uipath",
   "displayName": "UiPath",
-  "version": "1.202.1",
+  "version": "1.202.2",
   "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 CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "@uipath/skills",
-  "version": "1.202.1",
+  "version": "1.202.2-preview.911",
   "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-coded-apps/references/sdk/data-fabric.md CHANGED Viewed

@@ -2,6 +2,8 @@
 Signatures/params/examples: `dist/entities/index.d.ts` (trigger-event behavior differs per method — the JSDoc on each insert/update/delete method documents it). Per-method scopes: shipped `docs/oauth-scopes.md`. This file covers only what neither can express.
+> **Record and attachment methods take an entity ref as their first argument** — `{ id: <entityId> }` or `{ name: <entityName> }` (SDK 1.7.1+). The older `insertRecordById` / `updateRecordById` / `updateRecordsById` / `insertRecordsById` / `queryRecordsById` / `importRecordsById` / `deleteRecordsById` methods still work but are deprecated — prefer `insertRecord` / `updateRecord` / `updateRecords` / `insertRecords` / `queryRecords` / `importRecords` / `deleteRecords` with a ref. Reads stay by-id: `getById`, `getAllRecords`, `getRecordById` (their by-name twins are `getByName` / `getRecordsByName` / `getRecordByName`).
 > **Scope pairing warning:** schema introspection (`entities.getAll()` / `getById()`) and record I/O sit in different scope pairs — `DataFabric.Schema.Read` vs `DataFabric.Data.Read` / `DataFabric.Data.Write`. This file mandates schema introspection before writes and filters, so an app with only Data scopes 403s on the introspection step. Check the shipped table per method.
 > **Building a CRUD grid over one entity?** Embed the DataTable widget instead of hand-wiring ag-Grid + record I/O — [../widgets/datatable.md](../widgets/datatable.md). The traps below still apply to any direct SDK calls the host app makes around it.
@@ -10,22 +12,22 @@ Signatures/params/examples: `dist/entities/index.d.ts` (trigger-event behavior d
 Data Fabric does NOT behave like a typical RDBMS. These server behaviors are invisible to both the types and the JSDoc. Before writing analytics, filters, or update logic, call `entities.getById(id)` and inspect `fields[].name` + `fieldDataType.name`. Pick your data strategy from what's actually there — do NOT assume.
-1. **Choice values come back as `numberId` integers on every read path.** Including ungrouped `getRecordById` / `queryRecordsById` items AND `groupBy` result keys. The SDK does NOT convert to string names. Code like `record.Priority.toLowerCase()` throws or produces `"5"`; `if (record.Status === "Resolved")` is always false because `record.Status` is `5`. Build `numberId → name` maps via `choiceSets.getById(<choiceSetId>)` (get `<choiceSetId>` from `entities.getById(id).fields[].choiceSetId`) and translate every read.
+1. **Choice values come back as `numberId` integers on every read path.** Including ungrouped `getRecordById` / `queryRecords` items AND `groupBy` result keys. The SDK does NOT convert to string names. Code like `record.Priority.toLowerCase()` throws or produces `"5"`; `if (record.Status === "Resolved")` is always false because `record.Status` is `5`. Build `numberId → name` maps via `choiceSets.getById(<choiceSetId>)` (get `<choiceSetId>` from `entities.getById(id).fields[].choiceSetId`) and translate every read.
 2. **Choice-set writes and filters take the integer `numberId`, not the value name.** Writes: sending `status: "Open"` fails with `Single choiceset value Open is not integer`. Filters: `{ fieldName: 'Status', operator: Equals, value: 'Resolved' }` matches nothing — use `value: String(numberIdForResolved)` (applies to **every** operator touching a choice field, including `NotEquals`, `In`, `NotIn`). Failure is silent: 0 rows or all rows depending on operator.
 3. **Record keys must match the schema's exact casing.** The SDK does NOT pascalize keys. If the entity field is `Subject` (PascalCase, the DF UI default), sending `{ subject: … }` fails with `Required field "Subject" is not provided` — DF's required-field check is case-sensitive. Use `field.name` verbatim as the record key.
-4. **Unknown keys on insert/update are silently dropped.** A typo'd field name in `insertRecordsById` does NOT error — the value is discarded without warning. Introspect the schema and validate keys before bulk operations.
+4. **Unknown keys on insert/update are silently dropped.** A typo'd field name in `insertRecords` does NOT error — the value is discarded without warning. Introspect the schema and validate keys before bulk operations.
 5. **DF auto-creates audit fields that look like domain fields but aren't.** Every entity has `CreateTime`, `UpdateTime`, `CreatedBy`, `UpdatedBy`, `Id`, `RecordOwner` — **row metadata** (when DF wrote the row), not the business event the row represents. They appear in the schema but are not writable. Need a domain-level "created at" / "owner"? Look for a custom field with a domain-specific name; if none exists, flag it to the user rather than silently using the audit column. Seeding historical timestamps: add a custom `DATETIME_WITH_TZ` field (e.g., `OriginalCreatedTime`) — do NOT name it `CreateTime` / `CreatedTime`, the audit name conflict causes silent drops or schema rejection.
 6. **No `IsNull` filter operator.** The server can't ask "where field is null" (`QueryFilterOperator` has no such member). Filter client-side after fetching, or design with explicit non-null sentinels.
-7. **Aggregates require server-side `aggregates` + `groupBy`.** Don't fetch raw rows and `.length` / `.reduce` client-side — every list call returns one page (see [pagination.md](pagination.md)), so `result.items.length` after `queryRecordsById({ filter })` returns at most one page's worth, no matter how many rows match. Use `totalCount` for cardinality, `aggregates: [{ function: 'COUNT', field: 'Id' }]` (with `groupBy` for per-bucket counts) for chart data.
-8. **File-type fields (`fieldDisplayType === 'File'`) aren't strings.** The record carries only metadata (`{ id, name, size, contentType }`); stringifying gives `"[object Object]"`. To display, call `entities.downloadAttachment(entityId, recordId, fieldName)` → `Blob` → `URL.createObjectURL` for an `<img src>`. **Neither `contentType` nor filename extension is reliable for detecting kind** — DF often returns `application/octet-stream`, and the stored `name` is frequently a bare UUID with no extension. To decide inline render vs download link, either (a) sniff the blob's magic bytes after download (PNG starts `89 50 4E 47`, JPEG `FF D8 FF`, GIF `47 49 46 38`, PDF `25 50 44 46`), or (b) optimistically attempt `<img src={objectUrl}>` and swap to a download link in `onError`. Writes go through `uploadAttachment(...)`, not `insertRecordById` / `updateRecordById`.
-9. **`MULTILINE_MAX` fields return a size marker on list/query reads.** `getAllRecords` / `queryRecordsById` return a string starting `HasValue=true Length=N` (live form: `"HasValue=true Length=20000 — call Get Entity Record By Id activity to retrieve content"`), never the content — only `getRecordById` returns the full value (SDK 1.5.2+, v2 read endpoint). Never render or persist the marker as data, and never echo it back through `updateRecordById` / `updateRecordsById` — the server accepts it as a normal value and silently destroys the real content; omit the key instead. The type accepts no filters or `sortOptions` (server 400: *"Field '<name>' is of type MULTILINE_MAX and cannot be used in filters."*). `lengthLimit` is a UTF-16 **byte** budget (max 131072 ≈ 65,536 chars).
+7. **Aggregates require server-side `aggregates` + `groupBy`.** Don't fetch raw rows and `.length` / `.reduce` client-side — every list call returns one page (see [pagination.md](pagination.md)), so `result.items.length` after `queryRecords(entityRef, { filterGroup })` returns at most one page's worth, no matter how many rows match. Use `totalCount` for cardinality, `aggregates: [{ function: 'COUNT', field: 'Id' }]` (with `groupBy` for per-bucket counts) for chart data.
+8. **File-type fields (`fieldDisplayType === 'File'`) aren't strings.** The record carries only metadata (`{ id, name, size, contentType }`); stringifying gives `"[object Object]"`. To display, call `entities.downloadAttachment({ id: entityId }, recordId, fieldName)` → `Blob` → `URL.createObjectURL` for an `<img src>`. **Neither `contentType` nor filename extension is reliable for detecting kind** — DF often returns `application/octet-stream`, and the stored `name` is frequently a bare UUID with no extension. To decide inline render vs download link, either (a) sniff the blob's magic bytes after download (PNG starts `89 50 4E 47`, JPEG `FF D8 FF`, GIF `47 49 46 38`, PDF `25 50 44 46`), or (b) optimistically attempt `<img src={objectUrl}>` and swap to a download link in `onError`. Writes go through `uploadAttachment({ id: entityId }, ...)`, not `insertRecord` / `updateRecord`.
+9. **`MULTILINE_MAX` fields return only a preview on list/query reads.** `getAllRecords` / `queryRecords` return either the value truncated to 10,000 characters with a `...[Truncated]` suffix or a size marker starting `HasValue=true Length=N` (sometimes with a trailing hint), depending on the tenant; encrypted fields always return `HasValue=true Encrypted=true`. Only `getRecordById` returns the guaranteed full value (SDK 1.5.2+, v2 read endpoint). Never render or persist a preview as data, and never echo it back through `updateRecord` / `updateRecords` — the server accepts it as a normal value and silently destroys the real content; omit the key instead. The type accepts no filters or `sortOptions` (server 400: *"Field '<name>' is of type MULTILINE_MAX and cannot be used in filters."*). `lengthLimit` is a UTF-16 **byte** budget (max 131072 ≈ 65,536 chars).
 ## Three paths require choice-value translation — don't miss any
 | Path | Direction | What to do |
 |---|---|---|
-| Writes (`insertRecordsById`, `updateRecordById`, `updateRecordsById`) | name → `numberId` | translate before sending |
-| Filter values (any `queryRecordsById` filter on a choice field) | name → `numberId` (as a string) | translate before sending |
+| Writes (`insertRecords`, `updateRecord`, `updateRecords`) | name → `numberId` | translate before sending |
+| Filter values (any `queryRecords` filter on a choice field) | name → `numberId` (as a string) | translate before sending |
 | Read results (`groupBy` keys AND ungrouped record items) | `numberId` → name | translate after receiving |
 Best practice: on app load, fetch each choice set once (`choiceSets.getById` returns values carrying `name` + `numberId`) and build **both** maps (`byName` and `byNumberId`). Reuse across all paths.

package/skills/uipath-ixp/references/cli-reference.md CHANGED Viewed

@@ -15,7 +15,7 @@ All commands use `uip ixp` prefix. Always append `--output json` when parsing ou
 | `uip ixp projects update-title <project-name> "<new-title>" --output json` | Update the display title of a project |
 | `uip ixp projects update-prompt <project-name> --prompt "<text>" --output json` | Update the project's **Overall extraction instructions** — the taxonomy-wide prompt the model sees on every extraction (the field at the top of the IXP UI's Manage Taxonomy page). Distinct from per-field-group prompts (`groups update-prompts`) and per-field prompts (`fields update-prompts`). Replaces the existing value. |
 | `uip ixp projects get-taxonomy <project-name> --output json` | Export the raw IXP taxonomy artifact. Data is `{ status, dataset: { entity_defs, label_groups } }` — read `entity_defs` and `label_groups` under `dataset`. Intended for re-import (see `import-taxonomy`), not a human-readable view. `dataset` also carries `_model_config`, the only read path for the configured extraction model and pre-processing — see [Reading the current model and pre-processing](#reading-the-current-model-and-pre-processing). |
-| `uip ixp projects get-metrics <project-name> [--model-version <N>] --output json` | Get validation metrics. **Validated model →** flat Data: `ProjectScore`, `ProjectScoreQuality`, `ValidatedDocuments`, `ModelVersion`, plus per-group `FieldGroups[]` (`FieldGroup`, `F1`, `Precision`, `Recall`, `ErrorRate`, `Documents`) and per-field `Fields[]` (`FieldGroup`, `FieldId`, `Name`, `F1`, `Precision`, `Recall`, `ErrorRate`, `Documents`, `Annotations`, `Quality`). `Name` is the field's display name resolved from the taxonomy — report on it, but compare on `FieldId`, which is the stable key; it is `null` when the service could not resolve it (e.g. the field was deleted after that version was scored). Display names are unique only within a group, so qualify as `<FieldGroup> / <Name>` when two fields share one. Scores are surfaced at the backend's own precision — long tails like `0.824999988079071` are its float32 arithmetic widened to double, not extra accuracy; round when you display them, and compare the raw values. **Trained but not yet validated →** Data is `{ Metrics: null }` (not an error). **No trained model yet (e.g. a project with no confirmed labellings) →** the call returns a failure envelope `Result: Failure` with `ErrorCode: not_found` (no `Data`), NOT `{ Metrics: null }` — treat it as "no metrics yet". **Defaults to the LATEST TRAINED version, which is NOT necessarily the published/live one** — resolve the version from `list-models` and pass it as `--model-version <N>` whenever you report a score, so the numbers and the version identity match (SKILL.md Critical Rule 21). **Any version the backend ever scored is readable**, including older ones `list-models` no longer lists — that is what makes a version-to-version comparison possible; `not_found` on a version means the backend never scored it, not that it aged out. Field semantics — which values decide and which are derived — are in [Improve Prompts Guide § What get-metrics returns](improve-prompts-guide.md#what-get-metrics-returns-and-which-values-decide). `ErrorRate` is `errors / Annotations` (it counts misses — not `1 - Precision`); the `Quality`/`ProjectScoreQuality` labels use inconsistent scales — never gate on them. |
+| `uip ixp projects get-metrics <project-name> [--model-version <N>] --output json` | Get validation metrics. **Validated model →** flat Data: `ProjectScore`, `ProjectScoreQuality`, `ValidatedDocuments`, `ModelVersion`, plus per-group `FieldGroups[]` (`FieldGroup`, `F1`, `Precision`, `Recall`, `ErrorRate`, `Documents`) and per-field `Fields[]` (`FieldGroup`, `FieldId`, `Name`, `F1`, `Precision`, `Recall`, `ErrorRate`, `Documents`, `Annotations`, `Quality`). `Name` is the field's display name resolved from the taxonomy — report on it, but compare on `FieldId`, which is the stable key; it is `null` when the service could not resolve it (e.g. the field was deleted after that version was scored). Display names are unique only within a group, so qualify as `<FieldGroup> / <Name>` when two fields share one. Scores are surfaced at the backend's own precision — long tails like a score printed as `<SCORE>` with 15 decimal places are its float32 arithmetic widened to double, not extra accuracy; round when you display them, and compare the raw values. **Trained but not yet validated →** Data is `{ Metrics: null }` (not an error). **No trained model yet (e.g. a project with no confirmed labellings) →** the call returns a failure envelope `Result: Failure` with `ErrorCode: not_found` (no `Data`), NOT `{ Metrics: null }` — treat it as "no metrics yet". **Defaults to the LATEST TRAINED version, which is NOT necessarily the published/live one** — resolve the version from `list-models` and pass it as `--model-version <N>` whenever you report a score, so the numbers and the version identity match (SKILL.md Critical Rule 21). **Any version the backend ever scored is readable**, including older ones `list-models` no longer lists — that is what makes a version-to-version comparison possible; `not_found` on a version means the backend never scored it, not that it aged out. Field semantics — which values decide and which are derived — are in [Improve Prompts Guide § What get-metrics returns](improve-prompts-guide.md#what-get-metrics-returns-and-which-values-decide). `ErrorRate` is `errors / Annotations` (it counts misses — not `1 - Precision`); the `Quality`/`ProjectScoreQuality` labels use inconsistent scales — never gate on them. |
 | `uip ixp projects configure-model <project-name> [options] --output json` | Configure extraction model. Options: `--model` (gemini_2_5_flash/gemini_2_5_pro/gpt_4o_2024_05_13) and `--preprocessing` (none/table_mini/table). To read the current settings, see [Reading the current model and pre-processing](#reading-the-current-model-and-pre-processing). |
 | `uip ixp projects list-models <project-name> --output json` | List all model versions and tags. Returns `Models[]` (`Version`, `ModelName`, `Pinned`, `TrainedTime`, `Description`), `Tags[]` (`Name`, `Version`, `UpdatedAt`), and `MaxPublished`. **The only read path for the project's live version** — `Tags[]` entry Name=`live`, else the highest `Models[]` with `Pinned: true`; which version a **folder** serves at runtime is a different question — [Deployments](#deployments). `ModelName` is the trained labeller's **family** (e.g. `gemini_ixp`, `gemini_pro_ixp`) — it is never a `--model` value like `gemini_2_5_flash`, so it does not answer "which extraction model is configured" (see [Reading the current model and pre-processing](#reading-the-current-model-and-pre-processing)). |
 | `uip ixp projects publish <project-name> [--model-version <N>] [--tag <live\|staging>] --output json` | Publish a model version — defaults to the latest; pass `-m, --model-version <N>` to pick a specific one. `-d, --description "<text>"` sets a description; `--tag <live\|staging>` tags the published version. |

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

@@ -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/planning-arch.md CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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 CHANGED Viewed

@@ -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/shared/cli-commands.md CHANGED Viewed

@@ -252,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/skills/uipath-platform/references/data-fabric/data-fabric.md CHANGED Viewed

@@ -111,7 +111,7 @@ Do not change field types, create federated entities, or write federated records
 20. **`records import` supports Basic types only.** `CHOICE_SET_*`, `RELATIONSHIP`, `FILE`, `AUTO_NUMBER` columns are ignored on import — optional columns land as `null`; **`isRequired` columns without a `defaultValue` fail the whole row** (`ErrorFileLink` entry per row). Sequence: (1) `entities get` → list unsupported columns; (2) tell the user which columns will be skipped, and which rows will fail because a required unsupported column has no default; (3) offer `records insert --file <json>` (+ `files upload` for FILE) as the alternative; (4) invoke only after explicit confirmation. See [`bulk-import.md` → Complex Field Types Not Supported](bulk-import.md#complex-field-types-not-supported).
-21. **`MULTILINE_MAX` — marker reads, no filter/sort.** `records list` / `records query` return a size marker (`HasValue=true Length=N`) — full value only via `records get`. Never echo the marker back through `records update` — the server accepts it as a normal value and destroys the real content; omit the key instead. No filter/sort support (400). `lengthLimit` is a UTF-16 byte budget (max 131072 ≈ 65,536 chars). Full contract: [`entity-schema.md` → MULTILINE_MAX](entity-schema.md#multiline_max-fields) + [`records-query.md` → MULTILINE_MAX](records-query.md#multiline_max-fields--marker-vs-full-content).
+21. **`MULTILINE_MAX` — preview reads, no filter/sort.** `records list` / `records query` return a preview, either content truncated to 10,000 characters with a `...[Truncated]` suffix or a size marker (`HasValue=true Length=N`), depending on the tenant; full value only via `records get`. Never echo a preview back through `records update` — the server accepts it as a normal value and destroys the real content; omit the key instead. No filter/sort support (400). `lengthLimit` is a UTF-16 byte budget (max 131072 ≈ 65,536 chars). Full contract: [`entity-schema.md` → MULTILINE_MAX](entity-schema.md#multiline_max-fields) + [`records-query.md` → MULTILINE_MAX](records-query.md#multiline_max-fields--preview-vs-full-content).
 ---

package/skills/uipath-platform/references/data-fabric/entity-schema.md CHANGED Viewed

@@ -32,7 +32,7 @@ Pass the exact `EntityFieldDataType` UPPERCASE string — CLI is case-sensitive.
 |---|---|---|
 | `STRING` | NVARCHAR | Short text (≤4000 chars via `lengthLimit`) |
 | `MULTILINE_TEXT` | NVARCHAR(MAX) | Long text (≤10000 chars via `lengthLimit`) |
-| `MULTILINE_MAX` | NVARCHAR(MAX) | Very large text (`lengthLimit` = UTF-16 byte budget, 1–131072; default 128 KB ≈ 65,536 chars max). No filter/sort; list/query reads return a size marker — see [MULTILINE_MAX fields](#multiline_max-fields) |
+| `MULTILINE_MAX` | NVARCHAR(MAX) | Very large text (`lengthLimit` = UTF-16 byte budget, 1–131072; default 128 KB ≈ 65,536 chars max). No filter/sort; list/query reads return a preview, not the guaranteed full value — see [MULTILINE_MAX fields](#multiline_max-fields) |
 | `DECIMAL` | DECIMAL | All numbers — `decimalPrecision: 0` for whole; `2` for money |
 | `BOOLEAN` | BIT | true/false |
 | `DATE` | DATE | Date only |
@@ -80,7 +80,7 @@ If the CLI rejects a `--body` with *"Cannot read properties of undefined (readin
 Very large text. Contract differs from `MULTILINE_TEXT`:
 1. **Not filterable, not sortable.** Any `queryFilters` or `sortOptions` entry naming a `MULTILINE_MAX` field → 400: *"Field '<name>' is of type MULTILINE_MAX and cannot be used in filters."* / *"Sort field '<name>' is of type MULTILINE_MAX and cannot be used for sorting."* Never offer the field in filter/sort predicates. See [filter contract](filter-platform-contract.md#operator-support-by-field-type).
-2. **List/query reads return a size marker, not content.** `records list` / `records query` return a string starting `HasValue=true Length=N` (live form: `"HasValue=true Length=20000 — call Get Entity Record By Id activity to retrieve content"`); only `records get <entity-id> <record-id>` returns the full value. Read + write-back rules in [records-query.md → MULTILINE_MAX fields](records-query.md#multiline_max-fields--marker-vs-full-content).
+2. **List/query reads return a preview, not the guaranteed full value.** Depending on the tenant, `records list` / `records query` return either the value truncated to 10,000 characters with a `...[Truncated]` suffix, or a size marker starting `HasValue=true Length=N` (sometimes with a trailing hint). Encrypted fields always read back `HasValue=true Encrypted=true`. Only `records get <entity-id> <record-id>` returns the full value. Read + write-back rules in [records-query.md → MULTILINE_MAX fields](records-query.md#multiline_max-fields--preview-vs-full-content).
 3. **On a 400 from `entities create` / `addFields` naming the type**, surface the error verbatim — do NOT retry or silently substitute `MULTILINE_TEXT` (Rule 18).
 ```bash

package/skills/uipath-platform/references/data-fabric/records-query.md CHANGED Viewed

@@ -16,16 +16,21 @@ Response wrapper: `{ Result, Code: "RecordList" | "RecordQuery", Data: { Items,
 - **`Data.NextCursor` is an object `{ "Value": "<base64-string>" }`, not a flat string.** Pass `Data.NextCursor.Value` to `--cursor` on the next call (unwrap one level). Passing the whole `NextCursor` object errors out.
 - Use `Data.HasNextPage` to check if more records exist. Stop when it's `false`.
-## MULTILINE_MAX Fields — Marker vs Full Content
+## MULTILINE_MAX Fields — Preview vs Full Content
-`records list` and `records query` do NOT return `MULTILINE_MAX` content. Each such field comes back as a size marker string starting `HasValue=true Length=N` — live form: `"HasValue=true Length=20000 — call Get Entity Record By Id activity to retrieve content"`. Only single-record read returns the full content:
+`records list` and `records query` do NOT reliably return `MULTILINE_MAX` content. Each such field comes back as a **preview**, and which form you get depends on the tenant:
+- the value truncated to 10,000 characters with a `...[Truncated]` suffix (a value at or under 10,000 characters can come back whole), or
+- a size marker starting `HasValue=true Length=N`, sometimes with a trailing hint such as `"HasValue=true Length=20000 — call Get Entity Record By Id activity to retrieve content"`.
+An encrypted `MULTILINE_MAX` field always reads back as `HasValue=true Encrypted=true` and never returns content. Do not branch on which form you got; treat any of them as a preview. Only the single-record read returns the full value:
 ```bash
 uip df records get <entity-id> <record-id> --output json
 ```
-1. **Never treat the marker as the value.** Don't display, compare, or persist `"HasValue=true Length=N"` as field content — fetch via `records get` first.
-2. **Never write the marker back.** A `records update` body built by echoing a record from `list` / `query` overwrites the real content with the literal marker string — verified: the server accepts it as a normal value, `Result: Success`, content silently destroyed. Omit `MULTILINE_MAX` keys from update bodies unless intentionally replacing the content.
+1. **Never treat a preview as the value.** Don't display, compare, or persist what `list` / `query` returned for the field; fetch via `records get` first. A truncated preview is the more dangerous form because it looks like ordinary content.
+2. **Never write a preview back.** A `records update` body built by echoing a record from `list` / `query` overwrites the real content with the preview — verified: the server accepts it as a normal value, `Result: Success`, content silently destroyed. With a truncated preview the stored value keeps its first 10,000 characters and loses the rest, which is far harder to notice than a marker string. Omit `MULTILINE_MAX` keys from update bodies unless intentionally replacing the content.
 3. **No filter, no sort.** `queryFilters` / `sortOptions` naming a `MULTILINE_MAX` field → 400: *"Field '<name>' is of type MULTILINE_MAX and cannot be used in filters."* / *"Sort field '<name>' is of type MULTILINE_MAX and cannot be used for sorting."* Surface verbatim (data-fabric.md Rule 18); don't retry with other operators. Full type contract: [entity-schema.md → MULTILINE_MAX fields](entity-schema.md#multiline_max-fields).
 ## Pagination

package/skills/uipath-platform/references/integration-service/vendor-docs-registry.json CHANGED Viewed

@@ -153,7 +153,7 @@
     },
     "databricks": {
       "connectorKey": "uipath-databricks-databricks",
-      "docsUrl": "https://docs.databricks.com/api/workspace/servingendpoints/query",
+      "docsUrl": "https://docs.databricks.com/api/model-serving-query/v1/query",
       "dynamic": true,
       "notes": "Workspace-specific host https://<workspace-host>/serving-endpoints/{name}/invocations (POST). Endpoint {name} (agent/model) is workspace-defined -> not knowable from docs. Auth: Bearer PAT/OAuth. Body shape depends on endpoint type: chat/completions/embeddings for foundation/external models (extra_params), dataframe_records/dataframe_split for custom models."
     },

package/skills/uipath-review/SKILL.md CHANGED Viewed

@@ -15,19 +15,15 @@ Use for requests to review, audit, check, evaluate, improve, quality-gate, or un
 ## Critical Rules
-1. **Read-only.** Never manually modify files. The sole exception is mandatory `uip agent refresh` for low-code agents; it may update derived files, which must not be restored or cleaned up. Report fixes and route them to `uipath-rpa`, `uipath-agents`, `uipath-maestro-flow`, `uipath-maestro-bpmn`, `uipath-api-workflow`, `uipath-coded-apps`, `uipath-platform`, or `uipath-solution`.
-2. **Validate first.** Every RPA entry point requires `uip rpa validate`, plus a project-level `uip rpa build` — `build` compiles the whole project, including entry points `validate` was never pointed at, so a clean per-file `validate` can still fail `build`. Low-code agents require `uip agent refresh` then `uip agent validate`; use `uip maestro flow validate`, `uip maestro bpmn validate`, and `uip api-workflow validate` as applicable. Every CLI validation command uses `--output json`. Report each command's Error, Warning, and Info counts; detail every Error and Warning, but add no detail lines for clean results. A review without both RPA `validate` and `build` is incomplete.
+1. **Read-only.** Never manually modify files. The sole exceptions are the CLI-owned writes of an agent review, `uip agent refresh` and `uip agent review-history add` ([agent-review-guide.md](references/agents/agent-review-guide.md)); they are mandatory; never restore or clean up what they change. Report fixes and route them to `uipath-rpa`, `uipath-agents`, `uipath-maestro-flow`, `uipath-maestro-bpmn`, `uipath-api-workflow`, `uipath-coded-apps`, `uipath-platform`, or `uipath-solution`.
+2. **Validate first.** Every RPA entry point requires `uip rpa validate`, plus a project-level `uip rpa build` — `build` compiles the whole project, including entry points `validate` was never pointed at, so a clean per-file `validate` can still fail `build`. Use `uip maestro flow validate`, `uip maestro bpmn validate`, and `uip api-workflow validate` as applicable. Every CLI validation command uses `--output json`. Report each command's Error, Warning, and Info counts; detail every Error and Warning, but add no detail lines for clean results. A review without both RPA `validate` and `build` is incomplete.
 3. Discover and classify every project before reviewing any project.
 4. Classify findings as **Critical** (blocks deployment), **Warning** (should fix), or **Info** (improvement opportunity).
 5. Establish or infer business context before optimization; queues and additional components are not automatically better.
 6. Do not duplicate validation findings. Reference the output rule ID and message rather than restating checks or passes. Counts include all results; Errors and Warnings also receive detail lines.
 7. Limit analysis to 30 minutes. For solutions with 10+ projects, provide a summary and deep dives for the three highest-risk projects, offering the remainder separately.
-8. Every agent requires `uip agent review` or `uip codedagent review` first, followed by the applicable judgment catalog, including when review began before this skill loaded; merge prior findings only after both passes.
-9. Review-CLI findings are authoritative. Preserve `RuleId`, `Severity`, `Description`, `File`, and `SuggestedFix` verbatim. Format `Recommendation` as `<File>: <Description>. <SuggestedFix>`. Judgment findings use the same format. Map `error` to Critical, `warning` to Warning, and `info` to Info; `judgment` defaults to Warning and may change only with reasoning in the finding description.
-10. Put intended but unapplied rules in **Rules Skipped**, including missing tooling/files, unavailable review CLI, and `status: deferred`. Do not list non-applicable rules.
-11. Never invent `rule_id` values. Each cited ID must occur verbatim in a loaded `references/agents/agents-*-rules.md` catalog or review-CLI JSON. Verify every ID before reporting. A real Critical issue covered by neither source is reported without a `rule_id`; unrule'd Warnings and Infos are dropped. This governs agent findings.
-12. Grade agent projects only with `A`, `B`, `C`, `D`, or `F`, with no `+`/`-`, per agent and overall: `min(G_det, G_jud)`. Read `G_det` from review CLI `Data.Grade`; do not recompute it. Compute `G_jud` from judgment findings only. Show the binding constraint for every grade; low-code reports omit the printed derivation as required by the rubric. A security or data-integrity judgment Critical forces F. The skill grade cannot exceed `Data.Grade`; report both. Do not grade RPA, flows, or coded apps. See [references/agents/agent-grading-rubric.md](references/agents/agent-grading-rubric.md).
-13. `uip agent refresh` owns `.agent-builder/`, `.local/build/`, and, for low-code agents, regenerated root `entry-points.json` from `agent.json`. Do not open these contents. Exclude them from classification, authored-file selection, structural metrics, and manual checks. Report a defect only if refresh fails to fix them. Read low-code schemas from `agent.json` `.inputSchema` and `.outputSchema`.
+8. **Agent projects follow [agent-review-guide.md](references/agents/agent-review-guide.md).** Once Step 1 classifies a project as Agent (Low-Code) or Agent (Coded), read that guide and run its Critical Rules and Steps 2–6 for that project; the steps below apply to it only where the guide points back to them.
+9. Put intended but unapplied rules in **Rules Skipped**, including missing tooling/files, unavailable review CLI, and `status: deferred`. Do not list non-applicable rules.
 ## Review Workflow
@@ -80,8 +76,8 @@ For every project, read `project.json.expressionLanguage` for RPA (`VisualBasic`
 | absent `targetFramework` or `Legacy` | RPA (Windows-Legacy) | [rpa-review-checklist.md](references/rpa/rpa-review-checklist.md) §10; recommend `uipath-rpa` Legacy mode |
 | both `.cs` and `.xaml` | RPA (Hybrid) | RPA checklist |
 | DU packages `UiPath.IntelligentOCR.Activities` or `UiPath.DocumentUnderstanding.ML.Activities` | RPA + Document Understanding | RPA + [du-review-checklist.md](references/document-understanding/du-review-checklist.md) |
-| `agent.json.type == lowCode` | Agent (Low-Code) | [agents-lowcode-rules.md](references/agents/agents-lowcode-rules.md) |
-| Python coded-agent signals, including `agent.json.type == coded` | Agent (Coded) | [agents-coded-rules.md](references/agents/agents-coded-rules.md) |
+| `agent.json.type == lowCode` | Agent (Low-Code) | [agent-review-guide.md](references/agents/agent-review-guide.md) |
+| Python coded-agent signals, including `agent.json.type == coded` | Agent (Coded) | [agent-review-guide.md](references/agents/agent-review-guide.md) |
 | `*.flow` + `project.uiproj.ProjectType == Flow` | Flow | [flow-review-checklist.md](references/flows/flow-review-checklist.md) |
 | `*.bpmn` + `ProjectType == ProcessOrchestration` | Maestro BPMN | [bpmn-review-checklist.md](references/bpmn/bpmn-review-checklist.md) |
 | `Workflow.json` with `document.dsl` and `do[]` + `ProjectType == Api` | API Workflow | [api-workflow-review-checklist.md](references/api-workflows/api-workflow-review-checklist.md) |
@@ -122,7 +118,6 @@ If unavailable, use Analyzer results included by `uip rpa validate`. Report ever
 | Type | Command |
 |---|---|
-| Agent (Low-Code) | `uip agent refresh "<PROJECT_DIR>" --output json`; then `uip agent validate "<PROJECT_DIR>" --output json` |
 | Flow | `uip maestro flow validate "<PROJECT_NAME>.flow" --output json` |
 | Maestro BPMN | `uip maestro bpmn validate "<FILE>.bpmn" --output json` |
 | API Workflow | `uip api-workflow validate "<WORKFLOW_JSON>" --output json` |
@@ -149,41 +144,6 @@ Every report includes:
 Include counts for every command. Detail Errors and Warnings only. Do not narrate clean results, passes, zero issues, drift status, scores, regeneration counts, or schema status; the table is sufficient.
-### Step 2.5 — Run the Review CLI, Then Apply the Judgment Catalog
-Apply to every encountered agent, including late-invoked reviews.
-#### 2.5a. Deterministic CLI pass
-Run once and capture JSON:
-| Type | Command |
-|---|---|
-| Low-Code | `uip agent review "<PROJECT_DIR>" --output json` |
-| Coded | `uip codedagent review "<PROJECT_DIR>" --output json` |
-Parse `Data.Issues[]` objects `{RuleId, Category, Severity, Description, File, SuggestedFix}` and carry them verbatim. Guardrail configuration validity is CLI-only: run the review CLI or `--checks guardrails` when appropriate, including every emitted `GUARDRAIL_*` finding verbatim; do not eyeball or re-flag CLI guardrail findings.
-#### 2.5b. Judgment pass
-Load each applicable catalog fully and apply every rule's `detection_method` to its named source material, including prompts, tools, eval datapoints, and schemas. Track intended rules that cannot be applied.
-| Signal | Catalog |
-|---|---|
-| `agent.json.type == lowCode` | `references/agents/agents-lowcode-rules.md` |
-| Python coded-agent or `agent.json.type == coded` | `references/agents/agents-coded-rules.md` |
-| `pyproject.toml` + `main.py` + `uipath.json[functions]` without framework config | coded catalog |
-| `package.json` + `uipath.json[functions]` (no `pyproject.toml`) — Coded Function (JS/TS) | phase 2; no agent catalog |
-| RPA, Flow, Coded App | phase 2; no agent catalog |
-For guardrails, running the guardrail workflow is **mandatory** whenever `guardrails[]` is non-empty or the use case calls for guardrails — do not eyeball `agent.json`:
-- Low-code: **open [guardrails-review.md](references/agents/guardrails/guardrails-review.md) and follow its Step 0 — you MUST run `uip agent guardrails catalog --output json` (30-min cache) and the never-cached tenant `uip agent guardrails list`** before auditing, then apply Audit Mode and Recommend Mode. Emit `LC_GUARDRAIL_ACTION_INEFFECTIVE`, `LC_GUARDRAIL_MISAPPLIED`, and `LC_GUARDRAIL_RECOMMENDED` as applicable.
-- Coded: **open [coded-guardrails-review.md](references/agents/guardrails/coded-guardrails-review.md) and follow it** when middleware/decorators are wired or the use case calls for guardrails. Public Python SDK docs may be fetched only when a finding must name classes not visible in source. Emit `CODED_GUARDRAIL_ACTION_INEFFECTIVE`, `CODED_GUARDRAIL_MISAPPLIED`, and `CODED_GUARDRAIL_RECOMMENDED`; do not duplicate CLI IDs `CODED_GUARDRAIL_WRONG_IMPORT`, `CODED_GUARDRAIL_TOOL_SCOPE_NO_TOOLS`, or `CODED_GUARDRAIL_INVALID_CONTRACT`.
-- If the guardrail catalog is unavailable, put Audit-Mode rules in Rules Skipped and retain source-only Recommend Mode detection.
-Before merging, verify every `rule_id` against a loaded catalog or CLI JSON. Remove absent IDs and retain only a Critical observation; drop unrule'd Warnings and Infos. Merge one row per finding into the Step 5 severity table using `C-D-`, `W-D-`, or `I-D-` prefixes as described in [references/rule-format.md](references/rule-format.md).
 ### Step 3 — Manual Quality Review
 For each project, load its type-specific checklist and inspect only authored files.
@@ -198,8 +158,6 @@ Derive both the declared contract unit and actual execution unit; do not ask the
 | RPA without queue | `Main.xaml` input arguments |
 | Flow | `.flow.variables.globals` entries with `in`/`inout` direction |
 | Maestro BPMN | Start-event payload/process inputs |
-| Low-code agent | `agent.json.inputSchema` |
-| Coded agent | `Input` Pydantic `BaseModel` in `main.py` |
 | API workflow | `Workflow.json` request schema |
 | Coded app | Entry-point schema in `operate.json`/`entry-points.json` |
@@ -240,16 +198,6 @@ Consult as applicable: [rpa-advanced-checklist.md](references/rpa/rpa-advanced-c
 Only after validation and manual review, assess business suitability, architecture, dependencies, queue usage, bulk operations, transaction/error recovery, redundant calls, logging, selectors, files, data handling, configuration consistency, environment separation, and performance. For solutions assess cross-project architecture, pinned libraries, circular dependencies, dispatcher/performer suitability, and shared configuration. For single projects assess queues for more than 50 independent items, batching, REFramework/equivalent retry, resource efficiency, and selector/data patterns. Read [review-workflow-guide.md](references/review-workflow-guide.md) and [architecture-assessment-guide.md](references/architecture-assessment-guide.md).
-### Step 4.5 — Compute Agent Grade
-Agents only:
-```text
-Final grade = min(G_det, G_jud)
-```
-`G_det` is the letter in CLI `Data.Grade`; never recompute it from issue counts. For judgment findings only, calculate `100 − (15 × Criticals) − (4 × Warnings) − (1 × Infos)`, floored at 0; map `85–100 A`, `65–84 B`, `45–64 C`, `25–44 D`, `0–24 F`. Any unmitigated judgment Critical caps at D; a security/data-integrity judgment Critical forces F. Architecture-principle scores do not affect the grade. For multiple agents use the worst grade, never an average. Show the binding constraint, for example `B — gated by G_det = CLI Data.Grade B; judgment clean (G_jud A)`. Use [agent-grading-rubric.md](references/agents/agent-grading-rubric.md) for omissions, edge cases, no-PDD/CLI/no-eval handling, and examples.
 ### Step 5 — Produce the Review Report
 Write the report in chat; **and when the task asks you to save it to a path (e.g. `./_review_report.md`), also write it to that exact path** (≥500 bytes). The read-only rule forbids creating or editing files **inside the project under review** — it does NOT forbid writing the requested report file. Do not use internal labels such as “Path A”, “Path B”, “Step 3a”, or “Step 0c”; do not use “Mismatch”, “Aligned”, “disqualifying criteria”, or “verdict”. Use one-to-one, one-to-many, or unclear. Do not create a Unit of Work Analysis section.
@@ -257,22 +205,24 @@ Write the report in chat; **and when the task asks you to save it to a path (e.g
 Required sections, in order:
 1. `## Review Report: <name>`
-2. `### Summary` — render as a **bullet list, not a table**. Bullets: Overall Quality; **Agent Grade** (agents only — exact form `- **Agent Grade:** <A–F> — <verdict>`, letter only, no `+`/`-`, keep any commentary in a later clause); Business Value; Review Scope; Project Types Found; Validation Status; PDD Available; Transaction Shape per project.
+2. `### Summary` — render as a **bullet list, not a table**. Bullets: Overall Quality; Business Value; Review Scope; Project Types Found; Validation Status; PDD Available; Transaction Shape per project.
 3. `### PDD Alignment` — only when a PDD is available.
 4. `### Automated Validation Results` — counts table and Error/Warning details only.
 5. `### Rules Skipped` — intended but unapplied rules only.
 6. `### Critical Findings`, `### Warnings`, `### Improvement Opportunities` — one row per finding: `| <id> | <rule> | <file>: <issue>. <fix>. |`; use `—` when no `rule_id`; never duplicate or split findings by source.
-7. `### Per-Project Summary` — Grade for agents and `—` otherwise; Quality for all. Report size as structural counts, never lines: `.xaml` activity/nesting/variable/argument counts, `.cs` method/statement counts, `.flow` node/gateway/depth counts, `.py` function/statement/import counts, config entry/nesting counts.
+7. `### Per-Project Summary` — Quality per project. Report size as structural counts, never lines: `.xaml` activity/nesting/variable/argument counts, `.cs` method/statement counts, `.flow` node/gateway/depth counts, `.py` function/statement/import counts, config entry/nesting counts.
 8. `### Recommended Next Steps` — route fixes to the appropriate skill.
 9. `### Optimization Notes` — only when relevant.
-10. `**Final grade: <A–F>**` — agents only, on its own line as the **last line** of the report (nothing after it); the letter **must match** the Summary Agent Grade.
-Legacy validation status must say: `Use uipath-rpa (Legacy mode) for Legacy-specific validation`. Do not say “Could not run” or “Failed”. Legacy is supported indefinitely in Studio LTS and is not a Critical deployment blocker. Recommend migration based on actual needs. Overall Quality is **Good** for 0 Critical and 0–3 Warnings; **Needs Improvement** for 0 Critical and 4+ Warnings or 1 Critical with a clear fix; **Critical Issues** for 2+ Critical or 1 security/data-integrity Critical. For agents, A/B maps to Good, C/D to Needs Improvement, and F to Critical Issues. Never use “Mismatch” or “Aligned”.
+Agent projects add the Summary grade bullet, Grade column, and final-grade line from [agent-review-guide.md § Step 5](references/agents/agent-review-guide.md#step-5--report-additions).
+Legacy validation status must say: `Use uipath-rpa (Legacy mode) for Legacy-specific validation`. Do not say “Could not run” or “Failed”. Legacy is supported indefinitely in Studio LTS and is not a Critical deployment blocker. Recommend migration based on actual needs. Overall Quality is **Good** for 0 Critical and 0–3 Warnings; **Needs Improvement** for 0 Critical and 4+ Warnings or 1 Critical with a clear fix; **Critical Issues** for 2+ Critical or 1 security/data-integrity Critical. Never use “Mismatch” or “Aligned”.
 ## Task Navigation
 | Need | Reference |
 |---|---|
+| Agent review workflow | [agent-review-guide.md](references/agents/agent-review-guide.md) |
 | Agent grade | [agent-grading-rubric.md](references/agents/agent-grading-rubric.md) |
 | Rule schema | [rule-format.md](references/rule-format.md) |
 | Review CLI/catalog workflow | [rule-catalog-workflow.md](references/rule-catalog-workflow.md) |
@@ -300,4 +250,4 @@ Legacy validation status must say: `Use uipath-rpa (Legacy mode) for Legacy-spec
 1. **Never flag Windows-Legacy (absent or `Legacy` `targetFramework`) as a Critical issue** — the Legacy targetFramework itself is never a Critical finding or deployment blocker; it is supported indefinitely in Studio LTS. Flag Warning only when relevant capabilities are missing; otherwise Info. Recommend migration based on actual needs, especially Healing Agent, Unified Target/Modern UIA, Object Repository, ScreenPlay, coded test cases, Autopilot, or Agents/Maestro. Route deep validation to `uipath-rpa` Legacy mode. **On a clean Legacy project, do not let Overall Quality read as "Critical Issues" on account of the Legacy runtime, an incomplete/stubbed integration, or a design gap — those are Warnings unless you have concrete evidence of a shipped security or data-integrity defect. If you do cite a genuine Critical, its recommendation must state plainly that it is unrelated to the Windows-Legacy targetFramework** (never place the Legacy label and a Critical rating together without that disclaimer).
 2. Do not recommend removing a dependency until usages have been searched and no consumers remain.
 3. Do not flag `-preview` package versions; address stability through activity-owner channels rather than the user-facing report.
-4. Do not run scripts or install Python packages. Deterministic checks belong in `uip agent review` or `uip codedagent review`; the skill ships no executable code.
+4. Do not run scripts or install Python packages. Deterministic checks belong in the review CLI; the skill ships no executable code.

package/skills/uipath-review/references/agents/agent-review-guide.md ADDED Viewed

@@ -0,0 +1,96 @@
+# Agent Review Workflow
+Steps for reviewing an agent project: low-code (`agent.json`) or coded (`main.py` plus framework config or `uipath.json`). Enter from SKILL.md once Step 1 classifies the project. Step 0 (discovery, PDD, scope), Step 1, Steps 3b–3c, Step 4, and the Step 5 report skeleton are shared and stay in SKILL.md; step numbers here match SKILL.md. In a mixed solution, apply this guide to each agent project and keep one report.
+> **Important:** a user's read-only or "do not modify the project" instruction covers manual edits only. It never covers `uip agent refresh` (Step 2) or `uip agent review-history add` (Step 6): the CLI owns the files they write. Run both even when the user asked for a read-only review; never move the project to a copy to avoid them.
+## Critical Rules
+1. Every agent requires `uip agent review` or `uip codedagent review` first, followed by the applicable judgment catalog, including when review began before this skill loaded; merge prior findings only after both passes.
+2. Review-CLI findings are authoritative. Preserve `RuleId`, `Severity`, `Description`, `File`, and `SuggestedFix` verbatim. Format `Recommendation` as `<File>: <Description>. <SuggestedFix>`. Judgment findings use the same format. Map `error` to Critical, `warning` to Warning, and `info` to Info; `judgment` defaults to Warning and may change only with reasoning in the finding description.
+3. Never invent `rule_id` values. Each cited ID must occur verbatim in a loaded `agents-*-rules.md` catalog or review-CLI JSON. Verify every ID before reporting. A real Critical issue covered by neither source is reported without a `rule_id`; unrule'd Warnings and Infos are dropped.
+4. Grade agent projects only with `A`, `B`, `C`, `D`, or `F`, with no `+`/`-`, per agent and overall: `min(G_det, G_jud)`. Read `G_det` from review CLI `Data.Grade`; do not recompute it. Compute `G_jud` from judgment findings only. Show the binding constraint for every grade; low-code reports omit the printed derivation as required by the rubric. A security or data-integrity judgment Critical forces F. The skill grade cannot exceed `Data.Grade`; report both. Do not grade RPA, flows, or coded apps. See [agent-grading-rubric.md](agent-grading-rubric.md).
+5. `uip agent refresh` owns `.agent-builder/`, `.local/build/`, and, for low-code agents, regenerated root `entry-points.json` from `agent.json`. Do not open these contents. Exclude them from classification, authored-file selection, structural metrics, and manual checks. Report a defect only if refresh fails to fix them. Read low-code schemas from `agent.json` `.inputSchema` and `.outputSchema`.
+6. The only writes are `uip agent refresh` (Step 2) and `uip agent review-history add` (Step 6); both write CLI-owned files. Everything else stays read-only per SKILL.md Critical Rule 1.
+## Step 2 — Validate
+| Type | Command |
+|---|---|
+| Low-Code | `uip agent refresh "<PROJECT_DIR>" --output json`; then `uip agent validate "<PROJECT_DIR>" --output json` |
+| Coded | No validate verb; the Step 2.5 `uip codedagent review` pass is the first CLI check |
+Record counts in the Automated Validation Results table (SKILL.md Step 2d).
+## Step 2.5 — Run the Review CLI, Then Apply the Judgment Catalog
+Apply to every encountered agent, including late-invoked reviews.
+### 2.5a. Deterministic CLI pass
+Run once and capture JSON:
+| Type | Command |
+|---|---|
+| Low-Code | `uip agent review "<PROJECT_DIR>" --output json` |
+| Coded | `uip codedagent review "<PROJECT_DIR>" --output json` |
+Parse `Data.Issues[]` objects `{RuleId, Category, Severity, Description, File, SuggestedFix}` and carry them verbatim. Guardrail configuration validity is CLI-only: run the review CLI or `--checks guardrails` when appropriate, including every emitted `GUARDRAIL_*` finding verbatim; do not eyeball or re-flag CLI guardrail findings.
+### 2.5b. Judgment pass
+Load each applicable catalog fully and apply every rule's `detection_method` to its named source material, including prompts, tools, eval datapoints, and schemas. Track intended rules that cannot be applied.
+| Signal | Catalog |
+|---|---|
+| `agent.json.type == lowCode` | `agents-lowcode-rules.md` |
+| Python coded-agent or `agent.json.type == coded` | `agents-coded-rules.md` |
+| `pyproject.toml` + `main.py` + `uipath.json[functions]` without framework config | coded catalog |
+| `package.json` + `uipath.json[functions]` (no `pyproject.toml`) — Coded Function (JS/TS) | phase 2; no agent catalog |
+| RPA, Flow, Coded App | phase 2; no agent catalog |
+For guardrails, running the guardrail workflow is **mandatory** whenever `guardrails[]` is non-empty or the use case calls for guardrails — do not eyeball `agent.json`:
+- Low-code: **open [guardrails-review.md](guardrails/guardrails-review.md) and follow its Step 0 — you MUST run `uip agent guardrails catalog --output json` (30-min cache) and the never-cached tenant `uip agent guardrails list`** before auditing, then apply Audit Mode and Recommend Mode. Emit `LC_GUARDRAIL_ACTION_INEFFECTIVE`, `LC_GUARDRAIL_MISAPPLIED`, and `LC_GUARDRAIL_RECOMMENDED` as applicable.
+- Coded: **open [coded-guardrails-review.md](guardrails/coded-guardrails-review.md) and follow it** when middleware/decorators are wired or the use case calls for guardrails. Public Python SDK docs may be fetched only when a finding must name classes not visible in source. Emit `CODED_GUARDRAIL_ACTION_INEFFECTIVE`, `CODED_GUARDRAIL_MISAPPLIED`, and `CODED_GUARDRAIL_RECOMMENDED`; do not duplicate CLI IDs `CODED_GUARDRAIL_WRONG_IMPORT`, `CODED_GUARDRAIL_TOOL_SCOPE_NO_TOOLS`, or `CODED_GUARDRAIL_INVALID_CONTRACT`.
+- If the guardrail catalog is unavailable, put Audit-Mode rules in Rules Skipped and retain source-only Recommend Mode detection.
+Before merging, verify every `rule_id` against a loaded catalog or CLI JSON. Remove absent IDs and retain only a Critical observation; drop unrule'd Warnings and Infos. Merge one row per finding into the Step 5 severity tables using `C-D-`, `W-D-`, or `I-D-` prefixes as described in [rule-format.md](../rule-format.md).
+## Step 3 — Manual Quality Review
+Unit of Work (SKILL.md Step 3a): the declared unit is `agent.json.inputSchema` for low-code and the `Input` Pydantic `BaseModel` in `main.py` for coded; derive the execution unit from `for`/`while` loops and external I/O. PDD alignment and the technical review follow SKILL.md Steps 3b–3c, with the judgment catalog as the checklist and only authored files in scope.
+## Step 4 — Evaluate Optimization
+As SKILL.md Step 4. Architecture-principle scores inform this step and never feed the grade.
+## Step 4.5 — Compute Agent Grade
+Agents only:
+```text
+Final grade = min(G_det, G_jud)
+```
+`G_det` is the letter in CLI `Data.Grade`; never recompute it from issue counts. For judgment findings only, calculate `100 − (15 × Criticals) − (4 × Warnings) − (1 × Infos)`, floored at 0; map `85–100 A`, `65–84 B`, `45–64 C`, `25–44 D`, `0–24 F`. Any unmitigated judgment Critical caps at D; a security/data-integrity judgment Critical forces F. Architecture-principle scores do not affect the grade. For multiple agents use the worst grade, never an average. Show the binding constraint, for example `B — gated by G_det = CLI Data.Grade B; judgment clean (G_jud A)`. Use [agent-grading-rubric.md](agent-grading-rubric.md) for omissions, edge cases, no-PDD/CLI/no-eval handling, and examples.
+## Step 5 — Report Additions
+Produce the report per SKILL.md Step 5 and add:
+1. `### Summary` bullet after Overall Quality, exact form `- **Agent Grade:** <A–F> — <verdict>` — letter only, no `+`/`-`; keep any commentary in a later clause. A/B maps Overall Quality to Good, C/D to Needs Improvement, F to Critical Issues.
+2. `### Per-Project Summary` Grade column: the per-agent grade; `—` for non-agent projects.
+3. `**Final grade: <A–F>**` on its own line as the **last line** of the report (nothing after it); the letter **must match** the Summary Agent Grade.
+Low-code reports omit the sections listed in [agent-grading-rubric.md § Low-code agent reports](agent-grading-rubric.md#low-code-agent-reports--omit-these-sections).
+## Step 6 — Record the Agent Grade
+Low-code agent projects only, after the report. For each low-code agent project, persist its per-agent final grade (Step 4.5) into the project's `review-history.json`:
+```bash
+uip agent review-history add <GRADE> "<PROJECT_DIR>" --errors <CRITICAL_COUNT> --warnings <WARNING_COUNT> --output json
+```
+The CLI owns `review-history.json`: never create, edit, or review the file; exclude it from the authored-file set. If the command fails, state that the grade was not recorded and stop — recording never changes the review outcome.

package/skills/uipath-review/references/agents/agents-coded-rules.md CHANGED Viewed

@@ -2,7 +2,7 @@
 Judgment rules for **coded** agents (Python — `main.py` + framework config). Each rule requires the agent to read source and reason — what a regex/AST-emulation/file-walk cannot decide reliably. Same row schema as elsewhere — see [`../rule-format.md`](../rule-format.md).
-> **This catalog is judgment-only.** Run `uip codedagent review "<PROJECT_DIR>" --output json` **first** (SKILL.md Step 2.5) — it returns the deterministic coded findings (pyproject/dependency/python-version gates, import & secret regex, framework symbol existence, bare-except, eval-run analysis, `.venv` packaging, git-tracked secrets) in the same rule format. Then apply the rules below, which the CLI cannot do.
+> **This catalog is judgment-only.** Run `uip codedagent review "<PROJECT_DIR>" --output json` **first** (agent-review-guide.md Step 2.5) — it returns the deterministic coded findings (pyproject/dependency/python-version gates, import & secret regex, framework symbol existence, bare-except, eval-run analysis, `.venv` packaging, git-tracked secrets) in the same rule format. Then apply the rules below, which the CLI cannot do.
 Read [`../rule-format.md`](../rule-format.md) and [`../rule-catalog-workflow.md`](../rule-catalog-workflow.md) first.

package/skills/uipath-review/references/agents/agents-lowcode-rules.md CHANGED Viewed

@@ -2,7 +2,7 @@
 Judgment rules for **low-code** agents (`agent.json`). Each rule requires reading source and reasoning; regex/count/schema-walk checks are insufficient. Use the row schema in [`../rule-format.md`](../rule-format.md).
-> **Judgment-only catalog.** Run `uip agent review "<PROJECT_DIR>" --output json` **first** (SKILL.md Step 2.5). It returns deterministic low-code findings—structural gates, schema-property presence, placeholder cross-refs, eval-set structure and schema cross-refs, and guardrail configuration validity—in the same rule format. Then apply these rules.
+> **Judgment-only catalog.** Run `uip agent review "<PROJECT_DIR>" --output json` **first** (agent-review-guide.md Step 2.5). It returns deterministic low-code findings—structural gates, schema-property presence, placeholder cross-refs, eval-set structure and schema cross-refs, and guardrail configuration validity—in the same rule format. Then apply these rules.
 Read [`../rule-format.md`](../rule-format.md) and [`../rule-catalog-workflow.md`](../rule-catalog-workflow.md) first.

package/skills/uipath-review/references/agents/guardrails/coded-guardrails-review.md CHANGED Viewed

@@ -2,7 +2,7 @@
 The read-only **review** counterpart of the `uipath-agents` coded guardrail recommend/validate capability. It
 powers the coded guardrail judgment rules in [`../agents-coded-rules.md`](../agents-coded-rules.md)
-§GuardrailsChecker. Run it during a **coded** agent review (SKILL.md Step 2.5b) **after** `uip codedagent review` <!-- uip-check-skip -->
+§GuardrailsChecker. Run it during a **coded** agent review (agent-review-guide.md Step 2.5b) **after** `uip codedagent review` <!-- uip-check-skip -->
 (Step 2.5a). Two modes:
 - **Audit Mode** — the agent already wires guardrails → are they *effective, appropriate, and actually wired*?
@@ -306,7 +306,7 @@ recommended action with the protection-vs-audit signal. Examples:
 ## Report
-Merge findings into the Step 5 Critical / Warning / Info findings tables (SKILL.md Step 2.5b), one row per finding:
+Merge findings into the Step 5 Critical / Warning / Info findings tables (agent-review-guide.md Step 2.5b), one row per finding:
 ```
 | <id> | `<rule_id>` | `<file>`: <message>. <suggested_fix>. |

package/skills/uipath-review/references/agents/guardrails/guardrails-review.md CHANGED Viewed

@@ -1,6 +1,6 @@
 # Guardrail Review — LLM-as-judge (audit + recommend)
-The read-only **review** counterpart of the `uipath-agents` guardrail recommend/validate capability. It powers [`../agents-lowcode-rules.md`](../agents-lowcode-rules.md) §GuardrailsChecker and runs during low-code agent review (SKILL.md Step 2.5b), **after** `uip agent review` (Step 2.5a).
+The read-only **review** counterpart of the `uipath-agents` guardrail recommend/validate capability. It powers [`../agents-lowcode-rules.md`](../agents-lowcode-rules.md) §GuardrailsChecker and runs during low-code agent review (agent-review-guide.md Step 2.5b), **after** `uip agent review` (Step 2.5a).
 Modes:
 - **Audit Mode:** existing guardrails → effective and appropriate? Emit **defects**.
@@ -77,7 +77,7 @@ Build `{ validatorId: status }` from the `Data` array, using only `Status == "Av
 If output contains `"Code": "GuardrailCatalogUnavailable"` or the CLI is unavailable, do not guess:
-- **Audit Mode:** put catalog-dependent `LC_GUARDRAIL_ACTION_INEFFECTIVE` and `LC_GUARDRAIL_MISAPPLIED` under the report's **Rules Skipped** subsection with reason `"guardrails catalog unavailable"` (SKILL.md Critical Rule 10 — Rules Skipped). Emit no catalog-grounded effectiveness/relevance verdict.
+- **Audit Mode:** put catalog-dependent `LC_GUARDRAIL_ACTION_INEFFECTIVE` and `LC_GUARDRAIL_MISAPPLIED` under the report's **Rules Skipped** subsection with reason `"guardrails catalog unavailable"` (SKILL.md Critical Rule 9 — Rules Skipped). Emit no catalog-grounded effectiveness/relevance verdict.
 - **Recommend Mode:** continue `agent.json`-only schema/prompt/tool inference; use generic scope/action wording and note `catalog-limited`.
 ## Audit Mode — existing guardrails (defects)
@@ -133,7 +133,7 @@ Do not name platform-documented validators (`harmful_content`, `intellectual_pro
 ## Report
-Merge findings into the Step 5 Critical / Warning / Info findings tables (SKILL.md Step 2.5b), one row per finding:
+Merge findings into the Step 5 Critical / Warning / Info findings tables (agent-review-guide.md Step 2.5b), one row per finding:
 ```text
 | <id> | `<rule_id>` | `<file>`: <message>. <suggested_fix>. |

package/skills/uipath-review/references/review-workflow-guide.md CHANGED Viewed

@@ -313,7 +313,7 @@ The review report follows a fixed markdown structure. Produce it in chat; **and
 ### Summary
 - **Overall Quality:** Good / Needs Improvement / Critical Issues
-- **Agent Grade:** <A–F> — <verdict label> (<binding constraint>) — *agent projects only; see SKILL.md Step 4.5 + [agent-grading-rubric.md](agents/agent-grading-rubric.md). Omit if no agent projects.*
+- **Agent Grade:** <A–F> — <verdict label> (<binding constraint>) — *agent projects only; see [agent-review-guide.md](agents/agent-review-guide.md) Step 4.5 + [agent-grading-rubric.md](agents/agent-grading-rubric.md). Omit if no agent projects.*
 - **Business Value:** <1-2 sentence description of what this solution does>
 - **Project Types Found:** <list with counts>
 - **Validation Status:** <pass/fail per project>
@@ -368,14 +368,14 @@ The review report follows a fixed markdown structure. Produce it in chat; **and
 **Final grade: <A–F>**
 ```
-> **`Final grade:` is the report's last line — nothing follows it.** No notes, caveats, or commentary, inside the report or after it. It restates the Summary's `Agent Grade` letter (the two must match) so the grade stays visible at the tail. Letter only — no label, no derivation. Agent projects only; omit when the review has no agent projects. See SKILL.md Step 4.5 + [agent-grading-rubric.md](agents/agent-grading-rubric.md).
+> **`Final grade:` is the report's last line — nothing follows it.** No notes, caveats, or commentary, inside the report or after it. It restates the Summary's `Agent Grade` letter (the two must match) so the grade stays visible at the tail. Letter only — no label, no derivation. Agent projects only; omit when the review has no agent projects. See [agent-review-guide.md](agents/agent-review-guide.md) Step 4.5 + [agent-grading-rubric.md](agents/agent-grading-rubric.md).
 **Overall Quality determination** (all project types):
 - **Good** — 0 Critical findings, 0-3 Warnings
 - **Needs Improvement** — 0 Critical findings, 4+ Warnings OR 1 Critical with clear fix
 - **Critical Issues** — 2+ Critical findings OR 1 Critical with security implications
-**Agent Grade** (agent projects only): the A–F letter is `min(G_det, G_jud)` computed in SKILL.md Step 4.5 — full rubric, bands, edge cases, and worked examples in [agent-grading-rubric.md](agents/agent-grading-rubric.md). It maps to the same verdict labels (A/B = Good, C/D = Needs Improvement, F = Critical Issues). Non-agent projects carry the Quality verdict only (grading for RPA / flows / coded apps is a future phase).
+**Agent Grade** (agent projects only): the A–F letter is `min(G_det, G_jud)` computed in [agent-review-guide.md](agents/agent-review-guide.md) Step 4.5 — full rubric, bands, edge cases, and worked examples in [agent-grading-rubric.md](agents/agent-grading-rubric.md). It maps to the same verdict labels (A/B = Good, C/D = Needs Improvement, F = Critical Issues). Non-agent projects carry the Quality verdict only (grading for RPA / flows / coded apps is a future phase).
 ## Optimization Evaluation Framework

package/skills/uipath-review/references/rule-catalog-workflow.md CHANGED Viewed

@@ -1,4 +1,4 @@
-# Rule Catalog — Workflow (SKILL.md Step 2.5)
+# Rule Catalog — Workflow (agent-review-guide.md Step 2.5)
 Step 2.5 runs after Step 2 (`uip agent refresh` then `uip agent validate` for low-code agents, plus related CLI validation) and before Step 3 (manual checklist review). It adds rule-ID findings from the review CLI, then the judgment catalog.
@@ -6,7 +6,7 @@ Step 2.5 runs after Step 2 (`uip agent refresh` then `uip agent validate` for lo
 ### 2.5a — Run the review CLI first
-Run the applicable review command once, even if another review pass already produced findings (SKILL.md Critical Rule 8 — run the review CLI first), and capture JSON:
+Run the applicable review command once, even if another review pass already produced findings (agent-review-guide.md Critical Rule 1 — run the review CLI first), and capture JSON:
 | Agent type | Command |
 |---|---|
@@ -24,7 +24,7 @@ If the CLI is unavailable (not installed or lacking `agent review` / `codedagent
 1. Use the detection table to identify applicable catalog files.
 2. Read every applicable catalog file in full.
 3. Apply each rule's `detection_method` in its judgment form: read the named source, reason about it, and emit a finding when criteria hold. Log the reasoning in the finding's `description`.
-4. Track every intended rule that cannot be applied (`status: deferred`, review CLI unavailable, guardrail catalog unavailable, or required source unreadable) in the report's "Rules Skipped" subsection with `rule_id` and reason. Never silently skip. An empty subject set is not a skip (SKILL.md Critical Rule 10 — Rules Skipped).
+4. Track every intended rule that cannot be applied (`status: deferred`, review CLI unavailable, guardrail catalog unavailable, or required source unreadable) in the report's "Rules Skipped" subsection with `rule_id` and reason. Never silently skip. An empty subject set is not a skip (SKILL.md Critical Rule 9 — Rules Skipped).
 5. Merge findings into the Step 5 report's Critical / Warning / Info tables, one row per finding:
    ```
@@ -63,7 +63,7 @@ Sort findings by `(severity, category, rule_id, file, line)`, never discovery or
 ## Anti-patterns
-1. Do not invent rule IDs. If a real critical issue is covered by neither the CLI nor catalog, report it under Critical Findings as a normal finding, not with a `rule_id`; only critical issues qualify (SKILL.md Critical Rule 11 — never invent `rule_id`).
+1. Do not invent rule IDs. If a real critical issue is covered by neither the CLI nor catalog, report it under Critical Findings as a normal finding, not with a `rule_id`; only critical issues qualify (agent-review-guide.md Critical Rule 3 — never invent `rule_id`).
 2. Do not re-rank severities. CLI `Severity` and catalog `severity` are authoritative for `error` / `warning` / `info`. For `judgment` rows, log the reasoning used to select the report band.
 3. Do not silently skip rules. Record every skip in "Rules Skipped" with its reason.
 4. Do not run the catalog before the CLI. Run `uip agent review` / `uip codedagent review` first (2.5a). For low-code agents, run `uip agent refresh` then `uip agent validate` during Step 2; the catalog handles only reasoning the CLI cannot perform.

package/skills/uipath-review/references/rule-format.md CHANGED Viewed

@@ -2,7 +2,7 @@
 Schema for every row in `agents-*-rules.md` judgment catalogs. The catalog is the contract: reason about each rule and emit findings with its `rule_id`, `severity`, and `suggested_fix`.
-The catalog is **judgment-only**. Read source and reason about prompt quality, tool-selection ambiguity, framework fit, and semantic schema/eval mismatches. Put deterministic checks (file presence, schema walks, counts, regex, and run-artifact analysis) in the `uip agent review` / `uip codedagent review` CLI (SKILL.md Step 2.5a), which emits `RuleId`, `Severity`, `Category`, `Description`, `File`, and `SuggestedFix`.
+The catalog is **judgment-only**. Read source and reason about prompt quality, tool-selection ambiguity, framework fit, and semantic schema/eval mismatches. Put deterministic checks (file presence, schema walks, counts, regex, and run-artifact analysis) in the `uip agent review` / `uip codedagent review` CLI (agent-review-guide.md Step 2.5a), which emits `RuleId`, `Severity`, `Category`, `Description`, `File`, and `SuggestedFix`.
 ## Row schema

package/skills/uipath-rpa/references/activity-docs/UiPath.Terminal.Activities/2.10/activities/TerminalSession.md CHANGED Viewed

@@ -82,7 +82,7 @@ Connection-level timing. Defaults work for typical LAN hosts; raise both when co
 | Name | Display Name | Kind | Type | Default | Description |
 |------|-------------|------|------|---------|-------------|
 | `TimeoutMS` | TimeoutMS | `InArgument` | `int` | `50000` | Milliseconds to wait for the terminal connection to be established. |
-| `DelayMS` | DelayMS | `InArgument` | `int` | `1000` | Milliseconds to wait after the connection is established before scheduling child activities. **Raise to 3000–5000 ms for TLS hosts** to let TN3270/TN5250 protocol negotiation finish before the first child activity runs — otherwise a leading `WaitScreenReady` can throw `ErrorWaitReady` against an otherwise-healthy connection. |
+| `DelayMS` | DelayMS | `InArgument` | `int` | `1000` | Milliseconds to wait after the connection is established before scheduling child activities. **Raise to between 3000 and 5000 ms for TLS hosts** to let TN3270/TN5250 protocol negotiation finish before the first child activity runs — otherwise a leading `WaitScreenReady` can throw `ErrorWaitReady` against an otherwise-healthy connection. |
 ### Output

package/skills/uipath-rpa/references/activity-docs/UiPath.Terminal.Activities/2.10/activities/WaitScreenReady.md CHANGED Viewed

@@ -24,7 +24,7 @@ This activity has only the standard timing/synchronization options — see [_com
 - This activity has `DelayMS = 0` by default (unlike most other activities which default to 300 ms).
 - Commonly placed after a **Send Control Key** (Transmit/Enter) to wait for the host to respond before reading or writing fields.
-- **Flaky in the first few seconds after a fresh TLS connect.** When placed as the very first child activity in a `TerminalSession.Body` (i.e. immediately after the session opens), this activity can intermittently throw `ErrorWaitReady` — identical XAML succeeds on one run and fails on the next. The cause appears to be a race against TN5250 protocol negotiation completing after the TLS handshake. Workarounds: rely on the parent `TerminalSession.DelayMS` (raise it to 3000–5000 ms for TLS hosts) to handle initial settling and omit the leading `WaitScreenReady`, OR retry the activity on failure. After the first interaction with the host, the activity is reliable.
+- **Flaky in the first few seconds after a fresh TLS connect.** When placed as the very first child activity in a `TerminalSession.Body` (i.e. immediately after the session opens), this activity can intermittently throw `ErrorWaitReady` — identical XAML succeeds on one run and fails on the next. The cause appears to be a race against TN5250 protocol negotiation completing after the TLS handshake. Workarounds: rely on the parent `TerminalSession.DelayMS` (raise it to between 3000 and 5000 ms for TLS hosts) to handle initial settling and omit the leading `WaitScreenReady`, OR retry the activity on failure. After the first interaction with the host, the activity is reliable.
 ## XAML Example

package/skills/uipath-rpa/references/legacy/activity-docs/ThirdParty-SharePoint.md CHANGED Viewed

@@ -77,9 +77,9 @@ All activities must be inside this scope. Authentication container.
 ### Authentication (MAJOR ISSUES)
 1. **Microsoft deprecating legacy auth** - App-Only with client secret may stop working for SharePoint Online. Consider Azure AD certificate auth or Microsoft Graph.
-2. **401 Unauthorized common** - [Forum reports](https://forum.uipath.com/t/uipathteam-sharepoint-activities-sharepoint-application-scope-401-unauthorized/515006): check tenant settings, app permissions, and auth mode compatibility
-3. **Windows auth failure on robots** - [Forum](https://forum.uipath.com/t/windows-authentication-failure-uipathteam-sharepoint-activities/332491): service account must have SharePoint access
-4. **"Sign-in name or password does not match"** - [Forum](https://forum.uipath.com/t/uipathteam-sharepoint-activities-authentication-exception/578289): common with MFA-enabled tenants; use WebLogin or AzureApp auth instead
+2. **401 Unauthorized common** - [Forum reports](https://forum.uipath.com/t/515006): check tenant settings, app permissions, and auth mode compatibility
+3. **Windows auth failure on robots** - [Forum](https://forum.uipath.com/t/332491): service account must have SharePoint access
+4. **"Sign-in name or password does not match"** - [Forum](https://forum.uipath.com/t/578289): common with MFA-enabled tenants; use WebLogin or AzureApp auth instead
 5. **WebLogin prompts user** on first run - not suitable for unattended robots
 ### QueryGrouping / Batch Queries

package/skills/uipath-troubleshoot/references/products/maestro/playbooks/foreground-unattended-robot.md CHANGED Viewed

@@ -43,4 +43,4 @@ What to look for:
 ## References
-- [Forum: Error #1230](https://forum.uipath.com/t/foreground-job-requires-an-unattended-robot-to-be-defined-on-your-user-1230/718082)
+- [Forum: Error #1230](https://forum.uipath.com/t/718082)

package/version-manifest.json CHANGED Viewed

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