@uipath/skills 1.197.2 → 1.198.0-preview.21

package/skills/uipath-platform/references/integration-service/triggers.md

@@ -10,7 +10,7 @@ Triggers are event-based activities that fire when something happens in an exter
 - [Trigger Discovery Flow](#trigger-discovery-flow)
 - [List Trigger Activities](#list-trigger-activities)
 - [Trigger Objects](#trigger-objects)
-  - [`parameters[]` — canonical event-parameter input fields](#parameters--canonical-event-parameter-input-fields)
+  - [`parameters[]` — event-parameter input fields](#parameters--event-parameter-input-fields)
 - [Object Name Resolution](#object-name-resolution)
 - [Trigger Metadata (Describe)](#trigger-metadata-describe)
 - [CRUD vs Non-CRUD Triggers](#crud-vs-non-crud-triggers)
@@ -31,7 +31,7 @@ Triggers are event-based activities that fire when something happens in an exter
 
 **Decision point at step 2**: CREATED, UPDATED, and DELETED operations require an intermediate "objects" step. For other trigger operations, skip to step 3 using the activity's **ObjectName**.
 
-> **Source of truth:** Event-parameter inputs come from `triggers objects` → `parameters[]`. Field metadata comes from `triggers describe`. Configure trigger nodes exclusively from these two responses — do not invent parameters or fields, and do not substitute metadata from other commands.
+> **Source of truth — UNION of both calls.** Event-parameter inputs = `triggers objects → parameters[]` **∪** `triggers describe → EventParameters`. A required field can appear in `describe → EventParameters` while absent from `parameters[]`, so configure every field either source marks `required` — never read inputs from one call alone. `triggers describe` also supplies `FilterFields` (filter tree) and `OutputFields` (downstream `$vars`). Run **both** calls; do not invent parameters or fields, and do not substitute metadata from other commands.
 
 ---
 
@@ -124,11 +124,11 @@ Array of objects — each has a **name** to use in the describe command. Also in
 | `byoaConnection` | `true` if this event requires a BYOA connection |
 | `isWebhookUrlVisible` | `true` if the webhook URL should be shown to the user |
 | `eventMode` | `"webhooks"` or `"polling"` — how the trigger receives events |
-| **`parameters[]`** | **Canonical** event-parameter input fields for this trigger — see below |
+| **`parameters[]`** | Object/query/path-scoped input fields for this trigger — see below. **Merge with `triggers describe → EventParameters`** for the complete set. |
 
-#### `parameters[]` — canonical event-parameter input fields
+#### `parameters[]` — event-parameter input fields
 
-One entry per configure-time input field (repo, mailbox folder, channel). Canonical across all connectors. `triggers describe` exposes the same set under `events.<operation>.required`/`.optional`, but that block is empty for several connectors — always read `parameters[]` here.
+One entry per configure-time input field (repo, channel, shared mailbox). **Not complete on its own** — `triggers objects → parameters[]` carries object/query/path-scoped inputs, while event-config inputs come from `triggers describe → EventParameters`. The full input set is the **union**; a field is required if either source marks it `required`. Never read inputs from `parameters[]` alone.
 
 | Field | Description |
 |---|---|
@@ -143,17 +143,18 @@ One entry per configure-time input field (repo, mailbox folder, channel). Canoni
 
 ### Trigger Metadata (from `triggers describe`)
 
-Object with field definitions. Structure varies by connector but typically includes field names, types, display names, and descriptions.
-
-Additional fields:
+Object with field definitions. Structure varies by connector but typically returns three arrays plus mode flags:
 
 | Field | Description |
 |---|---|
+| `EventParameters` | Event-config input fields. **First-class event parameters** — merge with `triggers objects → parameters[]`; configure every entry marked `required`. Resolve `reference` fields via `uip is resources run list` before configure. |
+| `FilterFields` | Fields usable in the optional `filter` tree |
+| `OutputFields` | Event payload schema — field names for downstream `$vars.{triggerId}.output.*` |
 | `eventMode` | `"webhooks"` or `"polling"` |
 | `byoaConnection` | `true` if this trigger requires a BYOA connection |
 | `isWebhookUrlVisible` | `true` if the webhook URL should be shown |
 
-> **`events.<operation>.required` from `triggers describe` is connector-dependent and often empty.** Downstream commands that derive `eventParameters.fields` from it inherit the gap. Read input fields from [`parameters[]`](#parameters--canonical-event-parameter-input-fields) instead. `triggers describe` remains the source for **output** field metadata.
+> **`triggers describe → EventParameters` is NOT "output-only" metadata.** It carries required *input* parameters that `triggers objects → parameters[]` frequently omits. Always merge both responses and configure the union — see the Source-of-truth note above. `flow registry get`'s `eventParameters.fields` mirrors `describe` and is the offline fallback.
 
 ---
 

package/skills/uipath-platform/references/orchestrator/setup-environment.md

@@ -100,6 +100,8 @@ The `--all` flag enables filtering options (`--type`, `--name`, `--path`, `--top
 
 Roles group permissions and are scoped to either the tenant or a folder. Create the role first (it starts with zero permissions), then add permissions to it.
 
+> **⚠️ `uip or roles` is the Orchestrator RBAC catalog — a different store from Identity/organization authorization roles (`uip admin authorization roles`, see [uipath-admin](/uipath:uipath-admin)). The two are disjoint: a role created with `admin authorization roles` does NOT appear in `uip or roles list`, and vice versa.** Both have Tenant-scoped roles, so "a tenant-level role" alone doesn't tell you which one. For any Orchestrator role/permission lifecycle — create, add/remove permissions, assign to users/folders — use `uip or roles`. Reach for `admin authorization roles` only for org-level Identity roles that span services.
+
 ```bash
 # Create a folder-scoped role
 uip or roles create --name "FinanceOperator" --type Folder --output json

package/skills/uipath-review/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: uipath-review
 description: "UiPath read-only reviewer — audit structure, quality, best practices for RPA (.xaml/.cs), agents (.py/agent.json), flows (.flow), BPMN (.bpmn), coded apps, solutions (.uipx). Does NOT edit files. For building/editing→domain skills."
-allowed-tools: Bash, Read, Glob, Grep, AskUserQuestion
+allowed-tools: Bash, Read, Glob, Grep, WebFetch, AskUserQuestion
 user-invocable: true
 ---
 
@@ -28,7 +28,7 @@ Review UiPath solutions and individual artifacts for structural validity, qualit
 6. **Use `--output json`** on all CLI validation commands for programmatic parsing.
 7. **Do not duplicate what validation commands catch.** Reference the validation output by rule ID and message — do not manually re-describe the same issue. But DO include every validation result (Error, Warning, Info) in the report.
 8. **Cap the review at 30 minutes of analysis.** For very large solutions (10+ projects), provide a summary review with deep dives on the 3 highest-risk projects. Offer to review remaining projects if the user wants.
-9. **Run the review CLI first, then apply the judgment catalog, for every agent encountered.** First run `uip agent review` (low-code) or `uip codedagent review` (coded) with `--output json` — it returns the deterministic findings (Step 2.5a). Then load the judgment catalog: `references/agents/agents-common-rules.md` plus the format-specific file (`agents-lowcode-rules.md` or `agents-coded-rules.md`); for the agent-builder coded layout (both `agent.json` and `main.py`), load all three and run both CLI commands. Future phases add catalogs for RPA, flows, coded apps.
+9. **Run the review CLI first, then apply the judgment catalog, for every agent encountered.** First run `uip agent review` (low-code) or `uip codedagent review` (coded) with `--output json` — it returns the deterministic findings (Step 2.5a). Then load the judgment catalog: `references/agents/agents-common-rules.md` plus the format-specific file (`agents-lowcode-rules.md` or `agents-coded-rules.md`); for the agent-builder coded layout (both `agent.json` and `main.py`), load all three and run both CLI commands. Future phases add catalogs for RPA, flows, coded apps. This holds even when the skill loads mid-task: if review work already started before this skill loaded (e.g., a generic code-review pass produced findings), Step 2.5a and the guardrail Step 0 catalog fetch are still mandatory — run them, then merge the earlier findings into this skill's report format. Prior review output is never a substitute for the review CLI or the live catalog.
 10. **Rule findings are authoritative as emitted.** Carry review-CLI findings (`Data.Issues[]`) into the report verbatim — `RuleId`, `Severity`, `Description`, `File`, `SuggestedFix` unchanged. For the judgment catalog, use its `rule_id`, `severity`, `trigger`, and `suggested_fix` verbatim. Map severity to the report's bands: `error` → Critical, `warning` → Warning, `info` → Info. `judgment` severity rows default to Warning; the agent may escalate or de-escalate with reasoning logged in the finding's `description`. Do not re-rank otherwise.
 11. **Report rules that could not be applied** (missing tooling, missing file, review CLI unavailable, `status: deferred`) in a dedicated "Rules Skipped" subsection of the report — never silently skip.
 12. **Never invent `rule_id` values.** Every `rule_id` cited in the report MUST appear verbatim in EITHER a loaded judgment-catalog file (`references/agents/agents-*-rules.md`) OR the `uip agent review` / `uip codedagent review` JSON output. `rule_id` is a stable contract identifier — consumers grep for it, dashboards aggregate by it, audits trace it. An invented identifier looks authoritative but cannot be looked up, doesn't aggregate, and produces a different name for the same observation on the next run. If you observe a real issue covered by neither source, the finding is still valid — report it as a normal Critical / Warning / Info finding **without** a `rule_id` (no `` `RULE_ID` `` backtick token in the line). **Before emitting the report, scan every cited `rule_id` and confirm it appears verbatim in a loaded catalog file or the review-CLI output; demote any that don't to `rule_id`-less findings.**
@@ -243,6 +243,8 @@ For the review report, create a validation summary:
 
 After Step 2 validation and before manual checklist review, produce rule-ID-level findings in two passes: **first** the `uip agent review` / `uip codedagent review` CLI for the deterministic static checks, **then** the skill's judgment-only catalog for what code cannot decide reliably.
 
+> **Late invocation:** if a review was already performed or started before this skill loaded, do NOT skip 2.5a/2.5b as "already covered" — no other review flow runs the review CLI or fetches the live guardrail catalog. Run both passes, then fold prior findings into Step 5's report.
+
 #### 2.5a — Run the review CLI first (deterministic findings)
 
 Run the review command for the agent type, once, capturing JSON:
@@ -272,7 +274,10 @@ The CLI runs every deterministic static check — structural/schema, placeholder
 | `.uipath/` or `app.config.json` | Coded App | *(phase 2)* |
 
 2. **Read each catalog file in full.** Every rule is judgment-form.
-3. **Guardrails (low-code) — apply the structured guardrail workflow.** When `agent.json` has a non-empty `guardrails[]` or the agent matches a guardrail use case, apply [`references/agents/guardrails/guardrails-review.md`](references/agents/guardrails/guardrails-review.md) (Step 0 fetch of the live `uip agent guardrails catalog` + `list`, 30-min cache → **Audit Mode** for existing guardrails + **Recommend Mode** for missing ones). It emits `LC_GUARDRAIL_ACTION_INEFFECTIVE` / `LC_GUARDRAIL_MISAPPLIED` (defects, `judgment` band) and `LC_GUARDRAIL_RECOMMENDED` (Info, one finding per missing guardrail with the validator / scope / action and the block-escalate-vs-log signal in the message). If the guardrail catalog is unavailable, record the Audit-Mode rules under "Rules Skipped" and keep Recommend Mode's `agent.json`-only detection.
+3. **Guardrails — apply the structured guardrail workflow** (project-type specific; Step 0 fetches the authored `uip agent guardrails catalog` — 30-min cache — plus the never-cached tenant-availability `uip agent guardrails list` → **Audit Mode** for existing guardrails + **Recommend Mode** for missing ones):
+   - **Low-code** (`agent.json`): when `guardrails[]` is non-empty or the agent matches a guardrail use case, apply [`references/agents/guardrails/guardrails-review.md`](references/agents/guardrails/guardrails-review.md). Emits `LC_GUARDRAIL_ACTION_INEFFECTIVE` / `LC_GUARDRAIL_MISAPPLIED` (defects, `judgment` band) and `LC_GUARDRAIL_RECOMMENDED` (Info, one per missing guardrail).
+   - **Coded** (SDK middleware / `@guardrail` decorators wired in the entry `.py`): when the entry source wires guardrails or the agent matches a use case, apply [`references/agents/guardrails/coded-guardrails-review.md`](references/agents/guardrails/coded-guardrails-review.md) (its Step 0 also fetches the public Python SDK docs that map a `validator_id` to its Python class/scope/enums). Emits `CODED_GUARDRAIL_ACTION_INEFFECTIVE` / `CODED_GUARDRAIL_MISAPPLIED` (defects, `judgment` band) and `CODED_GUARDRAIL_RECOMMENDED` (Info). The CLI's deterministic `CODED_GUARDRAIL_WRONG_IMPORT` / `CODED_GUARDRAIL_TOOL_SCOPE_NO_TOOLS` / `CODED_GUARDRAIL_INVALID_CONTRACT` (Step 2.5a) are carried verbatim and **not** re-flagged here.
+   - Either way, if the guardrail catalog is unavailable, record the Audit-Mode rules under "Rules Skipped" and keep Recommend Mode's source-only detection.
 4. **Apply each rule's `detection_method`:** read the named source material (system prompt, tool descriptions, eval datapoints, schemas) and reason about it. Emit a finding when the criteria hold; log the reasoning in the finding's `description`.
 5. **Track skipped rules** with their reason (`status: deferred`, missing optional file, review CLI unavailable). Never silently skip.
 6. **Verify rule_id provenance.** Before merging, confirm each cited `rule_id` appears **verbatim** in EITHER a loaded catalog file OR the `uip agent review` / `uip codedagent review` JSON output. Any finding whose `rule_id` matches neither is **demoted** to a `rule_id`-less Critical / Warning / Info finding (the observation stays; the false citation goes). This enforces Critical Rule 12.
@@ -550,7 +555,6 @@ Output a structured report in chat (do NOT create a file):
 
 **Rules Skipped (and why):**
 - `uip codedagent review` — CLI not available in environment (deterministic checks not run)
-- `LC_GUARDRAIL_EVALS_CONSISTENCY` — no eval set present to assess against
 
 > The Rule Findings section is required for every agent project (low-code or coded). It is omitted for project types whose catalog has not yet been authored (RPA, flows, coded apps as of phase 1).
 

package/skills/uipath-review/references/agents/agent-review-checklist.md

@@ -99,31 +99,10 @@ Before reviewing implementation details, verify the right agent type was chosen:
 |---|---|---|
 | Recommended guardrails present for the agent's use cases — e.g. PII detection when it handles personal data, injection protection for free-text input, content-safety for generated content, a tool audit-log for sensitive tools | Info | Compare agent context vs catalog use cases; the finding names the recommended scope and action (a blocking/escalating action for protection, a log action for audit) *(rule: `LC_GUARDRAIL_RECOMMENDED`)* |
 | No guardrail misapplied to an agent that shouldn't have it (e.g. PII on a generate-only agent) | Warning | Compare guardrail vs agent purpose / catalog `when_not_to_use` *(rule: `LC_GUARDRAIL_MISAPPLIED`)* |
-| Each guardrail has `name` and `description` | Warning | Walk guardrails *(rule: `GUARDRAIL_NO_NAME`, `GUARDRAIL_NO_DESCRIPTION`)* |
-| Tool resources have `guardrail.policies` array (Studio Web rejects without it) | Critical | Walk tool resources *(rule: `LOWCODE_TOOL_GUARDRAIL_FIELD_MISSING`)* |
-| Tool-scoped guardrails reference existing tools | Critical | Walk Tool-scope guardrails *(rule: `LOWCODE_GUARDRAIL_TOOL_REF_NONEXISTENT`, `GUARDRAIL_TOOL_SCOPE_NO_MATCHNAMES`)* |
 | Custom tool guardrails for destructive operations | Info | Check tool guardrail rules |
 | Guardrail action fits its scope — a blocking/escalating action at scopes meant to prevent a violation (Agent, Llm), a log action only for an audit trail (e.g. on a tool that legitimately needs the data). A log action at a prevention scope (Agent or Llm) is ineffective: it records the violation but does not stop it. | Warning | Review action vs scope vs catalog `when_not_to_use` *(rule: `LC_GUARDRAIL_ACTION_INEFFECTIVE`)* |
 
-**Guardrail format (built-in validators).** These run in `uip agent review`, which fetches the live validator catalog (`uip agent guardrails list`) when a built-in guardrail is present and validates each one against it. They are skipped (not failed) when the catalog can't be fetched (offline / not authed) — note that in "Rules Skipped" if relevant.
-
-| Check | Severity | How to Verify |
-|---|---|---|
-| `validatorType` is a real validator in the catalog | Critical | *(rule: `GUARDRAIL_UNKNOWN_VALIDATOR`)* |
-| Scope is one the validator allows | Critical | *(rule: `GUARDRAIL_SCOPE_NOT_ALLOWED`)* |
-| Required `validatorParameters` are present | Critical | *(rule: `GUARDRAIL_MISSING_REQUIRED_PARAM`)* |
-| No unknown parameters (incl. params on a validator that takes none) | Warning | *(rule: `GUARDRAIL_UNKNOWN_PARAM`)* |
-| Parameter `$parameterType` matches the validator's type | Critical | *(rule: `GUARDRAIL_PARAM_TYPE_MISMATCH`)* |
-| Parameter values are legal (enum options / map keys / number range) | Critical | *(rule: `GUARDRAIL_PARAM_VALUE_INVALID`)* |
-
-**Guardrail format (custom guardrails).** Pure static — validated against the fixed custom-rule schema, no catalog needed.
-
-| Check | Severity | How to Verify |
-|---|---|---|
-| Discriminators present (`$ruleType`, `$selectorType`, `$actionType`) | Critical | *(rule: `GUARDRAIL_CUSTOM_BAD_DISCRIMINATOR`)* |
-| Operator valid for the rule type | Critical | *(rule: `GUARDRAIL_CUSTOM_BAD_OPERATOR`)* |
-| Value type matches the rule type | Critical | *(rule: `GUARDRAIL_CUSTOM_BAD_VALUE`)* |
-| `Tool` scope only, with exactly one tool in `matchNames` | Critical | *(rule: `GUARDRAIL_CUSTOM_SCOPE_INVALID`)* |
+> **Guardrail format — CLI-owned (Step 2.5a), never eyeballed.** All format / schema / set-membership checks run in `uip agent review` and are carried verbatim from its output: `GUARDRAIL_*` (validator existence, allowed scope, parameter presence / type / value, name/description), `GUARDRAIL_CUSTOM_*` (discriminators, operator, value, Tool-scope + single `matchNames`), `LOWCODE_*GUARDRAIL*` (`guardrail.policies` field, tool-ref existence). Do not re-verify by eye (SKILL.md Step 2.5a). Built-in-validator checks are skipped (not failed) when the CLI can't fetch the authored validator catalog (offline / not authed) — record in "Rules Skipped"; custom-rule checks are pure static, no catalog needed.
 
 ### Memory Management
 

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

@@ -92,16 +92,33 @@ LLM-judge-only is acceptable when the agent has no tools, no classification outp
 
 ## GuardrailsChecker
 
-> **Agent-builder coded layout** (`agent.json` + `main.py`): the low-code semantic guardrail rules
-> (`LC_GUARDRAIL_RECOMMENDED` / `LC_GUARDRAIL_ACTION_INEFFECTIVE` / `LC_GUARDRAIL_MISAPPLIED`) apply against
-> `agent.json`'s `guardrails[]` via the low-code catalog + [`guardrails/guardrails-review.md`](guardrails/guardrails-review.md)
-> (this layout loads all three catalogs — see the detection table). Guardrail effectiveness/recommendation for
-> **pure-coded** agents (SDK decorators/middleware in `main.py`, no `agent.json`) is future work; use the bucket
-> below for any coded guardrail/policy observation a specific rule doesn't cover.
+> **Agent-builder coded layout** (`agent.json` + `main.py`): `agent.json`'s `guardrails[]` are reviewed by the
+> low-code semantic rules (`LC_GUARDRAIL_*`) via the low-code catalog + [`guardrails/guardrails-review.md`](guardrails/guardrails-review.md)
+> (this layout loads all three catalogs — see the detection table). The rules below cover **pure-coded** guardrails —
+> SDK middleware / `@guardrail` decorators wired in the entry `.py` (LangChain/LangGraph today), no `agent.json`.
+
+> **Validator-name authority.** Same caution as low-code: do NOT name a platform-documented validator
+> (`harmful_content` / `intellectual_property` / `user_prompt_attacks`) unless it is already present in the agent's
+> code — phrase generically (e.g. "an appropriate content-safety guardrail"). `pii_detection` / `prompt_injection`
+> are SDK-confirmed and may be named.
+
+> **Apply these via the structured workflow.** The guardrail rules below are applied through
+> [`guardrails/coded-guardrails-review.md`](guardrails/coded-guardrails-review.md) — Step 0 (fetch the live
+> `uip agent guardrails catalog` + `list`, 30-min cache, **plus** the public Python SDK docs that map a `validator_id`
+> to its Python class / scope / entity enums) → **Audit Mode** (effectiveness / relevance / wiring of existing
+> guardrails) + **Recommend Mode** (missing-guardrail recommendations), modeled on the `uipath-agents` coded
+> guardrail recommend/validate capability and driven by the same live catalog. **Boundary:** `uip codedagent review`
+> (Step 2.5a) owns every deterministic coded guardrail check and emits `CODED_GUARDRAIL_WRONG_IMPORT` /
+> `CODED_GUARDRAIL_TOOL_SCOPE_NO_TOOLS` / `CODED_GUARDRAIL_INVALID_CONTRACT`; the rules below fire **only** on
+> guardrails the CLI did not flag and **never** re-emit a CLI finding. If the catalog is unavailable, defer the
+> Audit-Mode rows (Rules Skipped) — see the workflow's Step 0.
 
 | rule_id | severity | category | trigger | detection_method | suggested_fix |
 |---|---|---|---|---|---|
-| `CODED_GUARDRAILS_ISSUE` | warning | guardrails | Guardrails / safety / PII observation that no specific rule fits | Use ONLY when no specific rule fits. Coded agents have most safety concerns covered under `## SecurityChecker` (`CODED_PROMPT_USER_INPUT_UNSANITIZED`, `CODED_PII_IN_TRACES`) and the deterministic secret/`.env` checks in the review CLI. Reach here only for guardrail / policy observations none of those cover. | (Defined per finding.) |
+| `CODED_GUARDRAIL_RECOMMENDED` | info | guardrails | A guardrail is recommended for a use case the coded agent matches but doesn't wire (one finding per missing guardrail; specifics in the message) | Apply `guardrails/coded-guardrails-review.md` **Recommend Mode**: fetch the live catalog + SDK docs (Step 0); read the entry `.py` (system prompt, Pydantic input/output schemas, `@tool` docstrings); for each catalog entry whose `when_to_use` / `use_cases` / `security_risk_addressed` match the agent and which is not already wired (no matching middleware / `@guardrail`), emit one finding. The message names the guardrail / `security_category`, the matched use case, the recommended scope, and the recommended **action** — **block/escalate** when protection is needed (PII that must not enter, injection, harmful content) or **log** for audit only. De-dup by `security_category`. Do NOT name a platform-documented validator unless already present. file = entry `.py`. | Wire the named guardrail at the catalog-recommended scope/action (middleware or `@guardrail`; cite `examples[].config`) — see the `uipath-agents` coded guardrails-recommend capability. |
+| `CODED_GUARDRAIL_ACTION_INEFFECTIVE` | judgment | guardrails | A guardrail's action is ineffective or counterproductive for its scope | Apply `guardrails/coded-guardrails-review.md` **Audit Mode → Actionability**: for each guardrail the CLI did not flag, compare its validator + scope (`GuardrailScope.*` or decorator target) + action class (`BlockAction` / `LogAction` / `EscalateAction` / custom) against the catalog entry's `when_not_to_use` / `examples[].config` action for that scope. Emit when counterproductive — a security-critical guardrail using `LogAction` where the example blocks; PII `Block`/filter at Tool scope on a tool that legitimately needs the data; PII `Log` at Agent/Llm. Name the recommended action. file = entry `.py`, element = guardrail name. | Use the action the catalog recommends for that scope, or move the guardrail to a scope where the action is effective. |
+| `CODED_GUARDRAIL_MISAPPLIED` | judgment | guardrails | A guardrail is present but doesn't belong on this agent, or is wired where it won't guard as intended | Apply `guardrails/coded-guardrails-review.md` **Audit Mode → Relevance + Wiring**: (a) Relevance — establish the agent's context (system prompt, schemas, tool docstrings), read the catalog entry's `when_not_to_use` / `NOT_recommended_for`, emit when the agent matches a disqualifying condition (e.g. a generate-only agent carrying a PII guardrail). (b) Wiring — a `@guardrail` LLM/Agent-scope decorator on a function that does **not** return `UiPathChat(...)` / `create_agent(...)` (or on a non-factory) silently no-ops; emit when the decorated target won't be wrapped as intended. Wrong import module / Tool-scope-without-`tools=` / contract violations are the CLI's deterministic rules — do not re-flag. Cite the matched clause or the mis-wiring. file = entry `.py`, element = guardrail name. | Remove the misapplied guardrail, or move the decorator onto the correct factory / `@tool` so it actually wraps the target. |
+| `CODED_GUARDRAILS_ISSUE` | warning | guardrails | Guardrails / safety / PII observation that no specific rule fits | Use ONLY when no specific rule fits. Coded agents have most safety concerns covered under `## SecurityChecker` (`CODED_PROMPT_USER_INPUT_UNSANITIZED`, `CODED_PII_IN_TRACES`), the three rules above, and the deterministic CLI guardrail/secret checks. Reach here only for guardrail / policy observations none of those cover. | (Defined per finding.) |
 
 ---
 

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

@@ -97,7 +97,6 @@ One H2 section per checker class (`EvalsChecker`, `SchemaChecker`, `ToolsChecker
 | `LC_GUARDRAIL_RECOMMENDED` | info | guardrails | A guardrail is recommended for a use case the agent matches but doesn't cover (one finding per missing guardrail; specifics in the message) | Apply `guardrails/guardrails-review.md` **Recommend Mode**: fetch the live catalog (Step 0); for each catalog entry whose `when_to_use` / `use_cases` / `security_risk_addressed` match the agent (system prompt, schemas, tools) and which is absent from `.guardrails[]`, emit one finding. The message names the guardrail / `security_category`, the matched use case, the recommended scope, and the recommended **action** — **block/escalate** when protection is really needed (PII that must not enter, injection, harmful content) or **log** for audit only (a tool legitimately handles sensitive data). De-dup by `security_category`. Do NOT name a platform-documented validator unless already present (see note above). file = `agent.json` (or normalized JSON). | Add the named guardrail at the catalog-recommended scope/action (cite `examples[].config`): block/escalate for protection, log for audit. |
 | `LC_GUARDRAIL_ACTION_INEFFECTIVE` | judgment | guardrails | A format-valid guardrail's action is ineffective or counterproductive for its scope | Apply `guardrails/guardrails-review.md` **Audit Mode → Actionability**: for each format-valid guardrail (skip ones the review CLI flagged), compare `validator` + `selector.scopes` + action `$actionType` against the catalog entry's `when_not_to_use` / `examples[].config` action for that scope. Emit when counterproductive — a security-critical guardrail at `log` where the example uses `block`; `pii_detection` `Block`/`Filter` at Tool on a tool that needs the PII; `pii_detection` `Log` at Agent/Llm. Name the recommended action. file = `agent.json`, element = guardrail name. | Set the action the catalog recommends for that scope, or move the guardrail to a scope where the action is effective. |
 | `LC_GUARDRAIL_MISAPPLIED` | judgment | guardrails | A guardrail is present but the agent matches the validator's `when_not_to_use` | Apply `guardrails/guardrails-review.md` **Audit Mode → Relevance**: establish the agent's context (system prompt, schemas, tools); for each format-valid guardrail read the catalog entry's `when_not_to_use` / `NOT_recommended_for`. Emit when the agent matches a disqualifying condition (e.g. a generate-only agent with no user input carrying a PII guardrail). Cite the matched clause. file = `agent.json`, element = guardrail name. | Remove the misapplied guardrail, or document why the agent's context differs from the `when_not_to_use` condition. |
-| `LC_GUARDRAIL_EVALS_CONSISTENCY` | judgment | guardrails | `enabledForEvals: true` may interfere with the eval set's intent | Read guardrails. For each with `enabledForEvals: true`, read the eval set. Assess: is the eval set testing guardrail behavior (intentional) or testing agent behavior (where guardrails may interfere)? Emit when intent unclear; reason in the description. file = guardrail source, element = guardrail name. | Set `enabledForEvals: false` for agent-behavior tests, or document that the eval set is specifically testing guardrail behavior. |
 
 ---
 

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

@@ -0,0 +1,231 @@
+# Coded Guardrail Review — LLM-as-judge (audit + recommend)
+
+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`
+(Step 2.5a). Two modes:
+
+- **Audit Mode** — the agent already wires guardrails → are they *effective, appropriate, and actually wired*?
+  (emits **defects**)
+- **Recommend Mode** — the agent is missing guardrails for use cases it matches → which should it add? (emits
+  **Info recommendations**)
+
+This is **review only** — never write, fix, or run `uip codedagent` mutating commands. The reviewer emits
+findings; the user (or the `uipath-agents` skill) applies them.
+
+> **Boundary with `uip codedagent review` — do not double-flag.** The review CLI owns every **deterministic**
+> coded guardrail check and emits them as rule IDs: `CODED_GUARDRAIL_WRONG_IMPORT` (LangChain agent imports
+> guardrails from `uipath.platform.guardrails` and never from `uipath_langchain.guardrails`, so the adapter never
+> registers and the guardrail silently no-ops), `CODED_GUARDRAIL_TOOL_SCOPE_NO_TOOLS` (a Tool-scope middleware with
+> no `tools=`), and `CODED_GUARDRAIL_INVALID_CONTRACT` (a local custom `action=`/`validator=` that doesn't subclass
+> the SDK base). The rules here fire **only on guardrails the CLI did not flag**, and judge only what code cannot
+> decide: whether a valid action actually protects at its scope, whether a valid guardrail belongs on this agent at
+> all, whether a decorator is wired where it will actually wrap the target, and whether a guardrail the agent should
+> have is missing. Never re-describe a CLI deterministic finding here.
+
+Like the recommend capability, this is **live-catalog driven** — the catalog's authored fields (`when_to_use`,
+`use_cases`, `security_risk_addressed`, `when_not_to_use`, `security_category`, `examples[].config`) drive every
+decision. The coded vocabulary (Python class names, scopes, entity enums) comes from the SDK docs. Do not hardcode
+which guardrail fits which agent, or which Python class implements which validator.
+
+---
+
+## Step 0 — Fetch Catalog, Available Validators, and SDK Docs
+
+Run this once when the coded agent's entry source wires guardrails (any `*UiPath…Middleware(...)` inside
+`create_agent(middleware=[...])` or any `@guardrail(...)` decorator) **or** the agent matches a catalog use case
+(so Recommend Mode can run). This is the read-only review counterpart of the guardrail recommend capability — it
+runs the same Step 0 fetches (specified in full below) but emits findings instead of writing code.
+
+### Catalog (cacheable — 30-minute TTL)
+
+```bash
+python3 -c "
+import os, time
+cache = '.guardrails-catalog-cache.json'
+if os.path.exists(cache) and (time.time() - os.path.getmtime(cache)) < 1800:
+    print('CACHE_HIT')
+else:
+    print('CACHE_MISS')
+"
+```
+
+- **CACHE_HIT**: read `.guardrails-catalog-cache.json` directly.
+- **CACHE_MISS**: fetch and save: `uip agent guardrails catalog --output json > .guardrails-catalog-cache.json`
+  (the CLI writes both success and error JSON to stdout — do not add `2>&1`).
+
+### Guardrails List (NEVER cached — tenant-specific)
+
+```bash
+uip agent guardrails list --output json
+```
+
+Build a `{ validatorId: status }` lookup from the `Data` array (use only `Status == "Available"`).
+
+### SDK Docs (NEVER skipped — Python class names)
+
+Coded agents reference guardrails by **Python class name** (`UiPathPIIDetectionMiddleware`, `PIIValidator`), not by
+`validator_id`. Fetch the SDK doc pages via `WebFetch` to map the two:
+
+- `https://uipath.github.io/uipath-python/core/guardrails/` — always (validators, entity enums, `GuardrailScope` /
+  `GuardrailExecutionStage`, action classes).
+- `https://uipath.github.io/uipath-python/langchain/guardrails/` — when the agent is LangChain/LangGraph
+  (`uipath-langchain` in `pyproject.toml` or `from langchain…` / `from langgraph…` imports): middleware classes,
+  their supported scopes/stages, and the `uipath_langchain.guardrails` import paths.
+
+Build a `{ validator_id → { middleware_class, validator_class, entity_enum, allowed_scopes, allowed_stages,
+import_path } }` lookup by joining catalog entries with the SDK class names. Use the fetched content as the sole
+source of truth for class/enum/import names — never memory.
+
+**If `WebFetch` is unavailable or denied**, fall back in order; stop at the first source that yields the
+class/scope/enum names:
+
+1. `curl -fsSL <URL>` via Bash (same two URLs).
+2. Read the installed SDK sources. Locate the packages
+   (`python3 -c "import uipath; print(uipath.__file__)"`, same for `uipath_langchain`) and read the guardrail
+   modules (`uipath/platform/guardrails/`, `uipath_langchain/guardrails/`) for middleware/validator/action classes,
+   scopes, stages, and entity enums.
+3. Neither reachable → SDK-docs skip path in the next section.
+
+### If the catalog (or SDK docs) is unavailable
+
+Do **not** guess:
+- **Audit Mode** (`CODED_GUARDRAIL_ACTION_INEFFECTIVE`, `CODED_GUARDRAIL_MISAPPLIED` relevance check) depends on the
+  catalog → record these under the report's "Rules Skipped" subsection with reason
+  `"guardrails catalog unavailable"`. (The **wiring** half of `CODED_GUARDRAIL_MISAPPLIED` — a decorator that won't
+  wrap its target — is code-only and still applies.)
+- **Recommend Mode** (`CODED_GUARDRAIL_RECOMMENDED`) can still detect a missing guardrail from the entry source
+  alone (prompt / schema / tool inference); phrase the recommended scope/action generically and note
+  "catalog-limited" in the message.
+- **SDK docs unreachable by every fallback** (WebFetch, curl, installed sources) → the
+  `validator_id ↔ Python class` mapping is unverified. Checks that need only the catalog still run; record
+  mapping-dependent checks (scope/stage validity, import paths, class names) under "Rules Skipped" with reason
+  `"SDK docs unavailable"`.
+
+---
+
+## Read the agent first
+
+Resolve the entry `.py` (the `langgraph.json` `graphs` value's file, else `main.py`) and read:
+- **System prompt** — what the agent does, its domain and behaviors.
+- **Input / output schemas** (Pydantic `BaseModel` / function signatures) — the data it receives and produces.
+- **`@tool` functions** — name, docstring, signature (the targets of Tool-scope guardrails).
+- **Wired guardrails** — `*UiPath…Middleware(...)` inside `create_agent(middleware=[...])` and `@guardrail(...)`
+  decorators, plus what each decorates (a `@tool`, an LLM factory `def create_llm(): return UiPathChat(...)`, an
+  agent factory, or something else).
+
+---
+
+## Audit Mode — existing guardrails (findings are defects)
+
+For each wired guardrail the review CLI did **not** flag, run the checks below.
+
+### Actionability Check → `CODED_GUARDRAIL_ACTION_INEFFECTIVE`
+
+Compare the guardrail's action class against the catalog entry's `when_not_to_use` and its representative
+`examples[].config` action for the chosen scope. Emit when the action is ineffective/counterproductive. Canonical
+cases:
+
+- A **security-critical** guardrail (`security_category` `adversarial_input` / `content_safety`) using
+  `LogAction` where the catalog example uses block — it looks protected but isn't.
+- `pii_detection` with `BlockAction` / a filtering action at **Tool** scope on a tool that legitimately needs the
+  PII (e.g. a SendEmail tool needs the recipient address) — blocking breaks the tool.
+- `pii_detection` with `LogAction` at **Agent** / **Llm** scope — log there does not prevent PII from entering or
+  reaching the LLM.
+
+Name the catalog-recommended action for that scope in the description. Severity `judgment` — a guardrail that breaks
+the agent or leaves a security gap can be Critical; a milder ineffectiveness is Warning/Info.
+
+### Relevance + Wiring Check → `CODED_GUARDRAIL_MISAPPLIED`
+
+Two ways a format-valid guardrail can be misapplied:
+
+- **Relevance** — establish the agent's real context (system prompt, schemas, tool docstrings); read the catalog
+  entry's `when_not_to_use` / `NOT_recommended_for`; emit when the agent matches a disqualifying condition (e.g. a
+  generate-only agent with no user input carrying a PII guardrail — the PII output is the intended product). Cite
+  the matched clause.
+- **Wiring** — a `@guardrail` decorator at LLM or Agent scope only wraps its target if the decorated function
+  returns `UiPathChat(...)` (LLM factory) or `create_agent(...)` (agent factory). A decorator on a plain helper, a
+  non-factory, or a module-level value silently no-ops at runtime. Emit when the decorated target won't be wrapped
+  as intended. (This is the non-deterministic placement case; the CLI's `CODED_GUARDRAIL_WRONG_IMPORT` /
+  `CODED_GUARDRAIL_TOOL_SCOPE_NO_TOOLS` / `CODED_GUARDRAIL_INVALID_CONTRACT` are separate — do not re-flag them.)
+
+---
+
+## Recommend Mode — missing guardrails (findings are Info recommendations)
+
+Reuse the `uipath-agents` recommend capability's catalog-driven reasoning, but emit findings instead of writing
+code. **All missing-guardrail recommendations use one rule_id — `CODED_GUARDRAIL_RECOMMENDED` (Info)** — one per
+missing guardrail, specifics in the message.
+
+1. **Read agent context** (done above): system prompt, schemas, `@tool` docstrings, and the already-wired
+   guardrails (to avoid recommending what's there).
+2. **Catalog-driven analysis** — for each catalog entry read `when_to_use`, `use_cases`, `description`,
+   `security_risk_addressed`; does the agent's purpose / data / threat model match? Read `when_not_to_use` and skip
+   if the agent matches a disqualifying condition. Cross-reference the Step 0 status lookup — only recommend
+   `Available` validators (mention `Unauthorised` ones; skip ones absent from the list).
+3. **De-duplicate by `security_category`** — group matched candidates by `security_category` + scope + stage; drop
+   catalog-deprecated entries; keep the best fit; mention the alternative.
+4. **Recommended scope (block as early as possible)** — the outermost PRE scope the validator's `allowed_scopes`
+   permits for input protection (**Agent** > Llm > Tool), Agent · POST for output protection, Tool scope only for a
+   genuinely tool-specific concern. In coded terms: Agent scope → `GuardrailScope.AGENT` middleware or `@guardrail`
+   on the agent factory; Llm → `GuardrailScope.LLM` or `@guardrail` on the LLM factory; Tool →
+   `GuardrailScope.TOOL` with `tools=[…]` or `@guardrail` on the `@tool`.
+5. **Recommended action (the protection-vs-audit signal)** — default to the catalog example's `action_type`; state
+   which it is: **block / escalate** (protection really needed) vs **log** (audit only). Never silently downgrade
+   block → log.
+
+### Emit the finding
+
+One `CODED_GUARDRAIL_RECOMMENDED` (Info) per missing guardrail. The message carries: which guardrail /
+`security_category`, why (the matched `when_to_use` / `use_cases` item or data flow), the recommended scope, and the
+recommended action with the protection-vs-audit signal. Examples:
+
+- *"Recommend a PII-detection guardrail at Agent scope with a **block** action — the input schema carries
+  `customer_email` / `ssn`; blocking at `GuardrailScope.AGENT` · PRE stops unexpected PII before the LLM. Protection
+  needed: block."*
+- *"Recommend a Tool-scope **log** guardrail on `send_customer_email` for an audit trail — the tool legitimately
+  handles the recipient email; use log (not block) so the tool keeps working. Audit only."*
+
+**Validator-name caution:** do NOT name a platform-documented validator (`harmful_content`,
+`intellectual_property`, `user_prompt_attacks`) unless already present in the code — phrase generically.
+`pii_detection` / `prompt_injection` are SDK-confirmed and may be named.
+
+---
+
+## Report
+
+Merge findings into the Step 5 "Rule Findings" subsection (SKILL.md Step 2.5b), canonical line format:
+
+```
+[<prefix><n>] `<rule_id>` — <file> — <message>. Fix: <suggested_fix>.
+```
+
+- Recommendations (`CODED_GUARDRAIL_RECOMMENDED`) → **`I-D-` (Info)** — improvements, not failures. The action
+  signal lives in the message, not the severity.
+- Defects (`CODED_GUARDRAIL_ACTION_INEFFECTIVE`, `CODED_GUARDRAIL_MISAPPLIED`) → the `judgment` band; pick
+  Critical/Warning/Info by impact and show the reasoning.
+- `file` = the entry `.py`; `element` = the guardrail name.
+
+---
+
+## Critical Rules
+
+1. **Run after `uip codedagent review` (Step 2.5a)** and only on guardrails the CLI did not flag — never
+   double-flag a `CODED_GUARDRAIL_WRONG_IMPORT` / `CODED_GUARDRAIL_TOOL_SCOPE_NO_TOOLS` /
+   `CODED_GUARDRAIL_INVALID_CONTRACT` deterministic finding.
+2. **Catalog-driven, not hardcoded** — every audit verdict and recommendation cites a catalog field
+   (`when_not_to_use`, `when_to_use` / `use_cases`, `examples[].config.action_type`). Class/enum/import names come
+   from the SDK docs, never memory.
+3. **Catalog unavailable → defer Audit Mode** (Rules Skipped), keep Recommend Mode's source-only detection with
+   generic wording and the code-only wiring half of `CODED_GUARDRAIL_MISAPPLIED`. Never guess
+   effectiveness/relevance without the catalog.
+4. **Recommendations are one Info rule** (`CODED_GUARDRAIL_RECOMMENDED`), one finding per missing guardrail, details
+   in the message; signal **block/escalate** (protection) vs **log** (audit).
+5. **Never silently downgrade block → log** — a security-critical guardrail at `log` is a defect
+   (`CODED_GUARDRAIL_ACTION_INEFFECTIVE`), not an acceptable choice, unless the catalog/agent shows a stated reason.
+6. **Do not name platform-documented validators** (`harmful_content` / `intellectual_property` /
+   `user_prompt_attacks`) unless already present — phrase generically. `pii_detection` / `prompt_injection` may be
+   named.
+7. **Review only** — emit findings; never write guardrails, edit the entry `.py`, or run mutating `uip codedagent`
+   commands.

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

@@ -9,6 +9,8 @@ Step 2.5 of the review workflow. Runs **after** Step 2 (`uip agent validate` and
 
 ### 2.5a — Run the review CLI first
 
+Mandatory even when the skill loads after another review pass already produced findings (SKILL.md Critical Rule 9).
+
 Run the review command for the agent type, once, capturing JSON:
 
 | Agent type | Command |
@@ -54,9 +56,9 @@ Maps project signals to the judgment catalog files that must be loaded. Extend t
 | Signals present | Project type | Catalog files |
 |---|---|---|
 | `agent.json` AND no `main.py` AND no `pyproject.toml` | Agent (low-code) | `agents/agents-common-rules.md` + `agents/agents-lowcode-rules.md` (+ `agents/guardrails/guardrails-review.md` when `guardrails[]` is present or a guardrail use case matches — see Step 2.5b item 3) |
-| `pyproject.toml` + `main.py` + any framework config (`langgraph.json` / `llama_index.json` / `openai_agents.json` / `google_adk.json` / `pydantic_ai.json` / `agent_framework.json`) | Agent (coded) | `agents/agents-common-rules.md` + `agents/agents-coded-rules.md` |
+| `pyproject.toml` + `main.py` + any framework config (`langgraph.json` / `llama_index.json` / `openai_agents.json` / `google_adk.json` / `pydantic_ai.json` / `agent_framework.json`) | Agent (coded) | `agents/agents-common-rules.md` + `agents/agents-coded-rules.md` (+ `agents/guardrails/coded-guardrails-review.md` when the entry source wires SDK guardrails or a guardrail use case matches — see Step 2.5b item 3) |
 | `pyproject.toml` + `main.py` + `uipath.json[functions]` only (no framework config) | Agent (coded — Simple Function) | same as Agent (coded) |
-| `agent.json` + `pyproject.toml` + `main.py` (agent-builder coded layout) | Agent (low-code + coded) | all three: common + lowcode + coded; tag each finding with its source file; also `agents/guardrails/guardrails-review.md` for the `agent.json` guardrails |
+| `agent.json` + `pyproject.toml` + `main.py` (agent-builder coded layout) | Agent (low-code + coded) | all three: common + lowcode + coded; tag each finding with its source file; also `agents/guardrails/guardrails-review.md` for the `agent.json` guardrails and `agents/guardrails/coded-guardrails-review.md` for SDK guardrails wired in the entry `.py` |
 | `project.json` + `.xaml` / `.cs` | RPA | *(phase 2 — catalog not yet authored)* |
 | `*.flow` + `project.uiproj` with `ProjectType: "Flow"` | Flow | *(phase 2)* |
 | `.uipath/` or `app.config.json` | Coded App | *(phase 2)* |

package/skills/uipath-rpa/SKILL.md

@@ -164,7 +164,7 @@ uip rpa activities find --query log --output json > /dev/null 2>&1 &
    - **Removing a dependency** — grep the project for usages before deleting an entry. A package may be the sole supplier of an activity used elsewhere (`MergePDFs` lives in the IntelligentOCR.StudioWeb family).
    - **Writing a new activity tag** — confirm via `uip rpa activities find --query "<verb>" --output json` and use the returned `ClassName`. Do not derive tag names from Studio display names. See [common-pitfalls.md § Common Activity Name Confusions](references/xaml/common-pitfalls.md).
 7. **[UIA] Before writing ANY UIA activity (XAML `<uix:N*>` or coded `uiAutomation.*` / `Descriptors.*`), MUST read [references/ui-automation-guide.md](references/ui-automation-guide.md) IN FULL** — including the mode-specific section (For Coded Workflows or For XAML Workflows) and Running UI Automation Workflows. No exceptions for "simple" UIs. Skipping this rule is the most common cause of hallucinated selectors, wrong target XML, and missing OR descriptors. NEVER hand-write selectors — use `uia-configure-target` exclusively (the guide explains how). This guide is the single entry point for UIA work: it routes you to [uia-configure-target-workflows.md](references/uia-configure-target-workflows.md), [uia-prerequisites.md](references/uia-prerequisites.md), and the package docs in order — the other UIA sections in this file point back here rather than restating the read mandate.
-7a. **[UIA] Verify UIA prerequisites before invoking `uia-configure-target`.** The minimum version and the prerequisite check live in [uia-prerequisites.md](references/uia-prerequisites.md) — read it and run that check first (do not hardcode the version from memory; that file is the only source of truth). If `UiPath.UIAutomation.Activities` is below the minimum or `{PROJECT_DIR}/.local/docs/packages/UiPath.UIAutomation.Activities/skills/uia-configure-target/SKILL.md` is absent, the `uip rpa uia` CLI is unavailable — and **both** target capture and indication depend on it, so indication is *not* a fallback when the package itself is missing. Ask the user to install/upgrade per uia-prerequisites.md. If they decline or the package cannot be installed, fall back to the **Placeholder-Selector Stub Pattern** (§ above) — real activities with `TODO Indicate` markers need no CLI. Never silently route to a non-existent skill path. Use indication capture only when a compatible UIA package *is* installed but `uia-configure-target` cannot see the element; record `UI capture: indication-only` in the plan header to skip `uia-configure-target` in that case.
+7a. **[UIA] Verify UIA prerequisites before invoking `uia-configure-target`.** The minimum version and the prerequisite check live in [uia-prerequisites.md](references/uia-prerequisites.md) — read it and run that check first (do not hardcode the version from memory; that file is the only source of truth). If `UiPath.UIAutomation.Activities` is below the minimum or `{PROJECT_DIR}/.local/docs/packages/UiPath.UIAutomation.Activities/skills/uia-configure-target/SKILL.md` is absent, the `uip rpa uia` CLI is unavailable — and **both** target capture and indication depend on it, so indication is *not* a fallback when the package itself is missing. Ask the user to install/upgrade per uia-prerequisites.md. If they decline or the package cannot be installed, fall back to the **Placeholder-Selector Stub Pattern** (§ above) — real activities with `TODO Indicate` markers need no CLI. Never silently route to a non-existent skill path. Use indication capture only when a compatible UIA package *is* installed but `uia-configure-target` cannot see the element; record `UI capture: indication-only` in the plan header to skip `uia-configure-target` in that case. **Runtime failure counts too:** when the package is present but the UIA snapshot CLI's live scans fail persistently (driver/COM errors on every scan), first rule out a locked or non-interactive Windows session (`LogonUI` running = lock screen) — that needs an unlock, not a fallback. Only if scans still fail on an unlocked interactive session, treat capture as unavailable and use the Placeholder-Selector Stub Pattern.
 8. **Use `--output json`** on all CLI commands whose output is parsed programmatically.
 8a. **`run` / `debug start` success/failure verdict comes from the outer `Result` (and equivalently the inner `HasErrors`), NEVER from any log entry's `Level`.** A successful workflow may emit `Log Message` activities at `Error` or `Warning` level as observability — those are workflow-emitted data, not CLI failures. Compile failures, validation failures, and unhandled runtime exceptions all flip `HasErrors` and propagate to the outer `Result`. Treating log-entry levels as a failure signal flips green runs to "failed" and burns retries on healthy workflows. In a debug session, check `DebugState` first — a `Suspended` response means an exception awaits your decision (continue / retry / ignore / cancel) while `HasErrors` is still `false`. See [cli-reference.md § run](references/cli-reference.md) and [debugging.md § Reading Debug Output Effectively](references/debugging.md).
 9. **For "leverage / reuse / find shared libraries" requests, search the tenant feed — not the local filesystem, NuGet.org, or keyword-permutation loops.** Run `uip or libraries list --limit 500 --output-filter "<JMESPath>" --output json`. On zero results from the filtered call, take the fallback branch — do not re-keyword. Skip when an SDD already records §16 "Shared libraries referenced" or the user has said "no shared libraries" earlier in the session. See [tenant-library-search-guide.md](references/tenant-library-search-guide.md) for the full procedure.
@@ -243,7 +243,7 @@ uip rpa activities find --query log --output json > /dev/null 2>&1 &
     - **All other activities:** (1) `activities find` → class name, (2) **read `<Activity>.md` first** and extract a property checklist (required + use-case-relevant), (3) `activities get-default-xaml` → starter element, (4) **diff your checklist against the starter and add what's missing** — an empty checklist means you skipped step 2, go back.
     - **Doc lookup order:** primary `{PROJECT_DIR}/.local/docs/packages/<PackageId>/activities/<Activity>.md`; fallback `references/activity-docs/<PackageId>/<closest-version>/<Activity>.md` for older package versions where `.local/docs` is empty. **Exception — `UiPath.UIAutomation.Activities` has no bundled fallback:** `.local/docs` (present only after the package is installed) is its sole activity-doc source. If it is absent, do not hunt for a bundled copy — follow Rule 7a (install with consent per [uia-prerequisites.md](references/uia-prerequisites.md), or use the Placeholder-Selector Stub Pattern).
     - **Trigger activities are special — read BOTH docs.** When the class name ends in `Trigger`, the namespace contains `.Triggers`, or the description mentions "starts a job" / "Monitor Events" / "Trigger Scope", also read the bundled `references/activity-docs/<PackageId>/<closest-version>/activities/<Activity>.md` **and** the package's bundled `overview.md`. The auto-generated `.local/docs` version is sparse for triggers; the bundled hand-written docs carry placement guidance (entry-point vs. `ui:TriggerScope`), deployment context, and cross-cutting namespace/assembly gotchas that the extractor does not capture. See Common Rule 12 and [trigger-pattern-guide.md](references/trigger-pattern-guide.md).
-    - **Skip-tax — concrete:** `activities get-default-xaml` omits any property whose value equals the type default. For `NGetText` the starter is literally `<uix:NGetText HealingAgentBehavior="SameAsCard" />` with **zero** output properties — authoring from this alone produces `NGetText.Value="..."` (does not exist; the property is `Text`), which `validate` accepts and `build` rejects. For `NTypeInto` that's 2 of 20 properties hidden.
+    - **Skip-tax — concrete:** `activities get-default-xaml` omits any property whose value equals the type default. For `NGetText` the starter is literally `<uix:NGetText HealingAgentBehavior="SameAsCard" />` with **zero** output properties — authoring from this alone produces `NGetText.Value="..."` (does not exist; the output member is `TextString`), which `validate` accepts and `build` rejects. For `NTypeInto` that's 2 of 20 properties hidden.
     - **Self-extending the card — "this activity feels simple, I'll add it to the card mentally" — is the failure mode.** The card is the only allowlist; for non-card activities the MD read is the only check.
     - Full procedure: [xaml/xaml-basics-and-rules.md § Activity Property Surface](references/xaml/xaml-basics-and-rules.md).
 21a. **[XAML] Built-in workflow activities: use the card only for this allowlist.** Fast-path card activities are: `Sequence`, `If`, `Switch<T>`, `TryCatch`, `While`, `DoWhile`, `ForEach<T>`, `Assign`, `LogMessage`, `WriteLine`, `Delay`, `Throw`, `Rethrow`. If the activity is on this list, open [references/common-activity-card.md](references/common-activity-card.md) and author from the card. If it is not on this list, follow full Rule 21. `InvokeWorkflowFile`, `Pick`, `Parallel`, and `ParallelForEach<T>` are intentionally off-card; use full Rule 21. Studio's "While" / "Do While" / "For Each" toolbox items emit UiPath wraps (`UiPath.Core.Activities.InterruptibleWhile` / `InterruptibleDoWhile` / `UiPath.Core.Activities.ForEach<T>`), not the framework `System.Activities.Statements.While`/`DoWhile`/`ForEach<T>`.

package/skills/uipath-rpa/references/activity-docs/UiPath.DataService.Activities/guides/data-service-filter-builder-guide.md

@@ -60,7 +60,7 @@ xmlns:s="clr-namespace:System;assembly=System.Private.CoreLib"
 The `x:` prefix covers: `x:String`, `x:Int32`, `x:Int64`, `x:Double`, `x:Boolean`, `x:Decimal`.
 The `s:` prefix is required for: `s:DateTimeOffset`, `s:Guid`, `s:String[]`, `s:DateTime`.
 
-See [xaml-basics-and-rules.md § x: and s: namespace aliases](uipath-rpa/references/xaml/xaml-basics-and-rules.md) for the full type mapping.
+See [xaml-basics-and-rules.md § x: and s: namespace aliases](../../../xaml/xaml-basics-and-rules.md) for the full type mapping.
 
 ## Operator Reference by Field Type
 

package/skills/uipath-rpa/references/activity-docs/UiPath.Web.Activities/2.5/coded/coded-api.md

@@ -488,7 +488,7 @@ Used by `ResponseOptions.FileOverwrite`.
 ## Related Activity Mappings
 
 - `Deserialize JSON` activity is not exposed as a dedicated coded API service method; use `Newtonsoft.Json.JsonConvert.DeserializeObject<T>(...)` in coded workflows.
-- `HTTP Request (Legacy)` is not exposed in coded workflows; use the `http` service (`IHttpService`) with `SendRequestAsync` instead. For behavioral differences versus the legacy activity, see [docs/activities/NetHttpRequest.md](UiPath.Web.Activities.Package.Design/docs/activities/NetHttpRequest.md).
+- `HTTP Request (Legacy)` is not exposed in coded workflows; use the `http` service (`IHttpService`) with `SendRequestAsync` instead. For behavioral differences versus the legacy activity, see [NetHttpRequest Activity](../activities/NetHttpRequest.md).
 - `Deserialize JSON Array` activity is not exposed as a dedicated coded API service method; use `Newtonsoft.Json.Linq.JArray.Parse(...)` in coded workflows.
 - `Serialize JSON` activity is not exposed as a dedicated coded API service method; use `Newtonsoft.Json.JsonConvert.SerializeObject(...)` in coded workflows.
 - `Deserialize XML` activity is not exposed as a dedicated coded API service method; use `System.Xml.Linq.XDocument.Parse(...)` in coded workflows.

package/skills/uipath-rpa/references/activity-docs/UiPath.Web.Activities/2.5/coded/curl-import.md

@@ -12,7 +12,7 @@ Read this file completely before generating code. The workflow is: **import ? ac
 
 ### Scope of this skill
 
-This skill is concerned **only** with producing a correct `HttpRequestOptions` from a cURL command. Once the object is ready, hand it off to `http.SendRequestAsync()`. Diagnosing HTTP responses, iterating on failures, and processing response content are handled by [NetHttpRequest.md](../../UiPath.Web.Activities.Package.Design/docs/activities/NetHttpRequest.md) and [service-discovery.md](service-discovery.md).
+This skill is concerned **only** with producing a correct `HttpRequestOptions` from a cURL command. Once the object is ready, hand it off to `http.SendRequestAsync()`. Diagnosing HTTP responses, iterating on failures, and processing response content are handled by [NetHttpRequest.md](../activities/NetHttpRequest.md) and [service-discovery.md](service-discovery.md).
 
 ## When to use
 
@@ -201,7 +201,7 @@ var response = await http.SendRequestAsync(imported.Options);
 
 ## See Also
 
-- [NetHttpRequest Activity](../../UiPath.Web.Activities.Package.Design/docs/activities/NetHttpRequest.md) — modern HTTP activity behavior spec, inputs, outputs, and defaults
-- [HttpClient Activity (Legacy)](../../UiPath.Web.Activities.Package.Design/docs/activities/HttpClient.md) — legacy HTTP activity reference
+- [NetHttpRequest Activity](../activities/NetHttpRequest.md) — modern HTTP activity behavior spec, inputs, outputs, and defaults
+- [HttpClient Activity (Legacy)](../activities/HttpClient.md) — legacy HTTP activity reference
 - [Service Discovery](service-discovery.md) — discovering unknown service endpoints and generating working requests
 - [HTTP Request Upgrade](http-request-upgrade.md) — migrating from the legacy HTTP Request activity

package/skills/uipath-rpa/references/activity-docs/UiPath.Web.Activities/2.5/coded/http-request-upgrade.md

@@ -1,4 +1,4 @@
-# HTTP Request Upgrade — Legacy to Modern Migration
+# HTTP Request Upgrade — Legacy to Modern Migration
 
 An agent skill for migrating workflows from the legacy HTTP Request activity (RestSharp-based) to the modern NetHttpRequest activity (.NET HttpClient-based).
 
@@ -680,7 +680,7 @@ Rules:
 
 ## See Also
 
-- [NetHttpRequest Activity](../../UiPath.Web.Activities.Package.Design/docs/activities/NetHttpRequest.md) — modern HTTP activity behavior spec, inputs, outputs, and defaults
-- [HttpClient Activity (Legacy)](../../UiPath.Web.Activities.Package.Design/docs/activities/HttpClient.md) — legacy HTTP activity reference
+- [NetHttpRequest Activity](../activities/NetHttpRequest.md) — modern HTTP activity behavior spec, inputs, outputs, and defaults
+- [HttpClient Activity (Legacy)](../activities/HttpClient.md) — legacy HTTP activity reference
 - [cURL Import Skills](curl-import.md) — converting raw cURL commands to HttpRequestOptions
 - [Service Discovery](service-discovery.md) — discovering unknown service endpoints and generating working requests

package/skills/uipath-rpa/references/activity-docs/UiPath.Web.Activities/2.5/coded/service-discovery.md

@@ -1,4 +1,4 @@
-# Service Discovery
+# Service Discovery
 
 An agent skill for progressively exploring an unknown service URL and producing a working coded workflow.
 
@@ -501,6 +501,6 @@ User provides URL
 
 ## See Also
 
-- [NetHttpRequest Activity](../../UiPath.Web.Activities.Package.Design/docs/activities/NetHttpRequest.md) — HTTP activity behavior spec, inputs, outputs, and defaults
+- [NetHttpRequest Activity](../activities/NetHttpRequest.md) — HTTP activity behavior spec, inputs, outputs, and defaults
 - [cURL Import](curl-import.md) — converting raw cURL commands to HttpRequestOptions
 - [HTTP Request Upgrade](http-request-upgrade.md) — migrating from legacy HTTP Request activity