@uipath/skills 1.199.0 → 1.200.0

package/skills/uipath-solution/references/pack-and-deploy.md

@@ -68,7 +68,7 @@ uip solution pack ./MySolution ./output --name "MySolution" --version "2.0.0" --
 | `--version <version>` | Set the package version | `1.0.0` |
 | `--nuget-sources-config-path <path>` | Local `NuGet.config` that sets the package sources used for resolution | -- |
 
-The output is a `.zip` file named `<name>.<version>.zip` written under `<output-path>/` (e.g., `MySolution.2.0.0.zip`). Run `solution resources refresh` first (from inside the solution dir, or with `--solution-folder <path>`) to ensure the solution's artefact files and debug overwrites are up to date — they're bundled into the package.
+The output is a `.zip` file named `<name>_<version>.zip` — **underscore between name and version, not a dot** — written under `<output-path>/` (e.g., `MySolution_2.0.0.zip`). Don't guess the filename: read it from the command's `Data.Packages` field, or list `<output-path>/`. Run `solution resources refresh` first (from inside the solution dir, or with `--solution-folder <path>`) to ensure the solution's artefact files and debug overwrites are up to date — they're bundled into the package.
 
 **Controlling package sources.** In offline or air-gapped environments, or when packages must be resolved from specific feeds, pass `--nuget-sources-config-path <path>` pointing at a local `NuGet.config`. Both `pack` and `restore` accept the flag; the sources declared in that file determine where each project's dependencies are resolved from, giving you precise control over feed selection.
 
@@ -77,10 +77,10 @@ The output is a `.zip` file named `<name>.<version>.zip` written under `<output-
 Upload the packed .zip so it appears in the UiPath solution feed:
 
 ```bash
-uip solution publish ./output/MySolution.2.0.0.zip --output json
+uip solution publish ./output/MySolution_2.0.0.zip --output json
 
 # Target a specific tenant
-uip solution publish ./output/MySolution.2.0.0.zip --tenant "Production" --output json
+uip solution publish ./output/MySolution_2.0.0.zip --tenant "Production" --output json
 ```
 
 After publishing, the package is visible via `uip solution packages list` and available for deployment.
@@ -122,7 +122,7 @@ Key options:
 | `-n, --name <name>` | Deployment name (required) | -- |
 | `--package-name <name>` | Published solution package name (required) | -- |
 | `--package-version <version>` | Package version to deploy (required) | -- |
-| `--folder-name <name>` | New Orchestrator folder to create (required) | -- |
+| `--folder-name <name>` | New Orchestrator folder to create (required). Always creates; a taken name is collision-renamed, never reused — see [`deploy run` Always Creates a New Folder](#deploy-run-always-creates-a-new-folder) | -- |
 | `--parent-folder-path <path>` | Parent folder under which the new folder is created | -- |
 | `--parent-folder-key <key>` | Parent folder key (GUID, alternative to `--parent-folder-path`) | -- |
 | `--config-file <path>` | Configuration file from `deploy config get` | -- |
@@ -270,7 +270,7 @@ jobs:
       - run: uip login --client-id "${{ secrets.UIPATH_CLIENT_ID }}" --client-secret "${{ secrets.UIPATH_CLIENT_SECRET }}" --tenant "${{ secrets.UIPATH_TENANT }}" --output json
       - run: uip solution restore ./MySolution --output json   # optional: fail fast on a missing feed before pack
       - run: uip solution pack ./MySolution ./output --version "1.0.${{ github.run_number }}" --output json
-      - run: uip solution publish ./output/MySolution.*.zip --output json
+      - run: uip solution publish ./output/MySolution_*.zip --output json
       - run: uip solution deploy run -n "MySolution-${{ github.run_number }}" --package-name "MySolution" --package-version "1.0.${{ github.run_number }}" --folder-name "MySolution" --config-file deploy-config.json --output json
 ```
 
@@ -285,13 +285,13 @@ uip solution pack ./MySolution ./output --version "1.2.0" --output json
 
 # Staging
 uip login tenant set "Staging" --output json
-uip solution publish ./output/MySolution.1.2.0.zip --output json
+uip solution publish ./output/MySolution_1.2.0.zip --output json
 uip solution deploy run -n "MySolution-Staging" --package-name "MySolution" --package-version "1.2.0" \
   --folder-name "MySolution" --config-file staging-config.json --output json
 
 # Production (after validation)
 uip login tenant set "Production" --output json
-uip solution publish ./output/MySolution.1.2.0.zip --output json
+uip solution publish ./output/MySolution_1.2.0.zip --output json
 uip solution deploy run -n "MySolution-Prod" --package-name "MySolution" --package-version "1.2.0" \
   --folder-name "MySolution" --config-file production-config.json --output json
 ```
@@ -315,9 +315,43 @@ These are different commands with different destinations:
 | `solution publish` | Solution feed | For deployment via `deploy run` |
 | `solution upload` | Studio Web | For browser-based editing |
 
-### `deploy run` Creates a New Folder
+### `deploy run` Always Creates a New Folder
 
-`--folder-name` specifies a folder to **create**, not an existing folder to deploy into. If the folder already exists, deployment will fail. Use `--parent-folder-path` to set the parent folder where the new folder is created.
+`--folder-name` specifies a folder to **create**, not an existing folder to deploy into. Use `--parent-folder-path` to set the parent folder where the new folder is created.
+
+**Re-running with a name that is already taken does not fail and does not reuse the folder** — Orchestrator collision-renames the new one (`MySolution` → `MySolution 1`) and the deployment lands there. Repeated deploys therefore accumulate `MySolution 1`, `MySolution 2`, …
+
+The CLI resolves the real folder and says so when it differs from what you asked for:
+
+```json
+{
+  "FolderName": "MySolution 4",
+  "FolderPath": "MySolution 4",
+  "RequestedFolderName": "MySolution",
+  "FolderNote": "Requested folder 'MySolution' already existed, so Orchestrator created 'MySolution 4' instead. ..."
+}
+```
+
+`RequestedFolderName` and `FolderNote` appear **only** on a rename, so their presence is the signal to check. Always provision against `Data.FolderPath`, never against the name you passed.
+
+**There is no way to deploy into a pre-existing folder.** The install API takes `solutionRootFolderName` — a name, not a folder key — so the target cannot be addressed. This matters when the folder you want already holds hand-provisioned assets, an IXP folder-deployment, or an assigned robot: the deployment will land somewhere else and runtime resolution then fails on the missing resources.
+
+Two ways around it:
+
+```bash
+# A. Let deploy create the folder FIRST, then provision into it.
+uip solution deploy run --name my-deployment --package-name my-package \
+  --package-version 1.0.0 --folder-name MySolution --output json
+# → read Data.FolderPath / Data.FolderKey from the response, then create the
+#   assets, folder-deploy IXP, and assign the robot into THAT folder.
+
+# B. Skip solution deploy and bind each piece into the existing folder.
+uip or packages upload ./piece.nupkg --output json
+uip or processes create --package-key <id> --package-version <ver> \
+  --folder-key <existing-folder-key> --output json
+```
+
+Option A is preferred — it keeps the solution deployment intact. Option B loses the solution grouping, so use it only when the folder's existing contents cannot be recreated.
 
 ### `--parent-folder-path` is the Parent
 

package/skills/uipath-test/SKILL.md

@@ -70,7 +70,7 @@ Common `uip tm` commands organized by resource type.
 | Command | Purpose |
 |---|---|
 | `uip tm testcases create --project-key <PROJECT_KEY> --name <TEST_CASE_NAME>` | Create a new test case in a Test Manager project. |
-| `uip tm testcases list --project-key <PROJECT_KEY>` | List all test cases in a Test Manager project. Optional `--filter <text>` to search by name/key. |
+| `uip tm testcases list --project-key <PROJECT_KEY>` | List all test cases in a Test Manager project. Optional `--filter <text>` — matches name or key by PREFIX, not substring. |
 | `uip tm testcases update --project-key <PROJECT_KEY> --test-case-key <TEST_CASE_KEY> --name <TEST_CASE_NAME>` | Update a test case name, description, precondition, or postcondition (at least one field required). |
 | `uip tm testcases delete --project-key <PROJECT_KEY> --test-case-key <TEST_CASE_KEY>` | Delete a test case by its key. |
 | `uip tm testcases link-automation --project-key <PROJECT_KEY> --test-case-key <TEST_CASE_KEY> --folder-key <FOLDER_KEY> --package-name <PACKAGE_NAME> --test-name <TEST_NAME>` | Link an Orchestrator package automation to a test case. |
@@ -85,7 +85,7 @@ Common `uip tm` commands organized by resource type.
 | `uip tm testcases steps move --project-key <PROJECT_KEY> --step-id <UUID> --target-position <n>` | Move a step to a new 0-based position. |
 | `uip tm testcases steps delete --project-key <PROJECT_KEY> --step-id <UUID> --yes` | Delete a step. |
 | `uip tm testcases list-result-history --project-key <PROJECT_KEY> --test-case-id <TEST_CASE_ID>` | List test case log result history for a specific test case. Optional `--only-failed`, `--filter`, `--limit`, `--offset`. |
-| `uip tm testcases run --project-key <PROJECT_KEY> --test-case-id <TEST_CASE_ID>` | Start a new execution for one or more test cases. **Uses `--test-case-id <UUID>` (space-separated for multiple).** Optional `--async`, `--name`, `--folder-key`, `--robot-user-key`, `--machine-key`. |
+| `uip tm testcases run --project-key <PROJECT_KEY> --test-case-id <TEST_CASE_ID> --name <EXECUTION_NAME> --execution-type <manual\|automated\|none\|mixed>` | Start a new execution for one or more test cases. **Uses `--test-case-id <UUID>` (space-separated for multiple).** Optional `--async`, `--folder-key`, `--robot-user-key`, `--machine-key`. |
 | `uip tm testcases add --test-set-key <TEST_SET_KEY> (--test-case-keys <KEY1> <KEY2> … \| --labels <Label1> <Label2> …)` | Add test cases to a test set — by explicit keys, OR every test case carrying at least one of the given labels. Both selectors are variadic and **space-separated**: `--test-case-keys DEMO:1 DEMO:2`, `--labels PW_Tag_smoke "PW_Suite_Checkout flow"` (quote names containing spaces). Keys additionally accept the comma form (`DEMO:1,DEMO:2`); **labels do not** — `--labels A,B` is read as one label named `A,B` and matches nothing. Label matching is OR, exact and case-sensitive. The two selectors are mutually exclusive. |
 | `uip tm testcases remove --test-set-key <TEST_SET_KEY> --test-case-keys <KEY1,KEY2,...>` | Remove test cases from a test set (comma-separated keys). |
 
@@ -233,11 +233,11 @@ Object labels are tag-style metadata applied to Requirement, TestCase, TestSet,
 2. **Probe the CLI surface once per session, before the first `uip tm` command.** Run `uip tm testcases --help --output json` (any flags accepted). Result `Success` → post-rename CLI; use the command tables above as-is. `unknown command` / non-zero exit → pre-rename CLI; translate via the [Pre-rename fallbacks](#pre-rename-fallbacks) table before each call. Re-probe on any later `unknown command` error.
 3. **Always pass `--output json`** to every `uip` command — no exceptions. Structured JSON output is what you need to reason about results reliably, even when you only plan to summarize them back to the user.
 4. **Cap retries at 3** for any failing `uip` CLI command. After 3 failures, stop and report the error to the user (see Rule — never fall back to direct REST APIs).
-5. **Handle empty results** — if a list command returns an empty array, stop and inform the user rather than proceeding with a null key.
+5. **Handle empty results** — if a list command returns an empty array, stop and inform the user rather than proceeding with a null key. Exception: a zero-result `tm testcases list --filter` call may be a prefix miss rather than a truly empty dataset — apply Rule 9's prefix fallback to disambiguate; stop only when the fallback also finds nothing. Filtered lookups on other resources (project, customfield) returning empty are real empty results — stop as usual.
 6. **Confirm before delete** — always confirm the target resource key with the user before running any `delete` command. All delete commands require `--yes` (or `-y`) to proceed; omitting it exits without deleting.
 7. **For operations requiring folder key** — use `uip or folders list -n <folder-name> --all --output json` when the user named a folder; when picking one yourself, list without `--all` so you only get folders you are a member of (run `/uipath-platform` for folder management details).
 8. **Discover before assuming** — never guess automation names, folder keys, project IDs, or test case keys. Always run the matching `list` command first (e.g., `uip tm testcases list-automations`, `uip or folders list -n <folder-name> --all`).
-9. **Narrow `list` calls server-side when the user names an entity.** When the user provides a name, key, label, or tag, check `uip tm <resource> list --help` (or `uip or <resource> list --help`) for the narrowing flag the command exposes and pass it on the `list` call. Never list all results and filter client-side — it wastes tokens and misses paginated entries. Applies to every entity across `uip tm` and `uip or`.
+9. **Narrow `list` calls server-side when the user names an entity.** When the user provides a name, key, label, or tag, check `uip tm <resource> list --help` (or `uip or <resource> list --help`) for the narrowing flag the command exposes and pass it on the `list` call. Never list all results and filter client-side — it wastes tokens and misses paginated entries. Applies to every entity across `uip tm` and `uip or`. Exception: `tm testcases list --filter` matches by prefix. A mid-name term returns zero — retry `--filter` with a broader name prefix from context; re-list without `--filter` only when no workable prefix exists, paging through ALL results (`--limit`/`--offset`) before concluding the target is absent.
 10. **Set default folder before any `run` command** — `uip tm testcases run` and `uip tm testsets run` both require a default Orchestrator folder on the project. Run `uip tm project set-default-folder --project-key <PROJECT_KEY> --folder-key <FOLDER_KEY> --output json` first. Get folder keys with `uip or folders list -n <folder-name> --all --output json`.
 11. **On any `uip` command failure or ambiguity, STOP and ask the user — do NOT fall back to direct REST API calls.** When a `uip` command errors, returns malformed output, or the right flag/value is unclear (e.g., multiple matching entities, missing identifier, unexpected schema), interrupt and ask the user before proceeding. This overrides any instinct to "try the underlying API instead."
 

package/skills/uipath-test/references/playwright-first-mile-guide.md

@@ -24,7 +24,7 @@ The key difference from the RPA pipeline: there is **no link step**. Uploading t
 
 > **Do NOT run `uip tm testcases link-automation` on Playwright test cases.** They are linked by ingestion; manual linking is the RPA pipeline and will corrupt the association.
 
-> **Reading command output.** `--output json` prints a JSON envelope, but not on its own line: auto-updater chatter (including `Update completed with failures.`, which is unrelated to your command), `Resolved project …` progress lines and trailing telemetry warnings share the same stream. Judge a command by the `Result` field inside the envelope, never by surrounding text, and extract from the first `{` before parsing.
+> **Reading command output.** `--output json` prints a JSON envelope, but not on its own line: auto-updater chatter (including `Update completed with failures.`, which is unrelated to your command), `Resolved project …` progress lines and trailing telemetry warnings share the same stream. Judge a command by the `Result` field inside the envelope, never by surrounding text. Noise appears on **both sides** of the JSON, so taking everything from the first `{` is not enough — slice from the first `{` to the **matching final `}`** (or read the last balanced JSON object) before parsing, or a trailing telemetry line will break the parse.
 
 > **If a command is missing.** Two commands in this pipeline are hidden from `--help`, so `--help` is not a reliable way to tell whether a build has them: `testsets playwright-context` (Step 5) and `run --playwright-projects` (Step 6). Older CLIs answer `unknown command` / `unknown option` for them. Treat them differently:
 >
@@ -59,7 +59,7 @@ uip tm pack --project-path <dir> --type playwright \
 uip or packages upload "<out-dir>/<PackageName>.1.0.0.nupkg" --output json
 ```
 
-`--package-version` is a NuGet/SemVer-style version: three numeric parts with an optional prerelease suffix (`1.0.0`, `1.0.1-beta.1`) — `1.0` is rejected. Each upload needs a version the feed does not already have, so before re-packing check what is published and go above it:
+`--package-version` is a NuGet/SemVer-style version: **three or four** numeric parts with an optional prerelease/build suffix (`1.0.0`, `1.0.0.0`, `1.0.1-beta.1`) — `1.0` is rejected. Each upload needs a version the feed does not already have, so before re-packing check what is published and go above it:
 
 ```bash
 uip or packages list --search <PackageName> --output json
@@ -75,7 +75,7 @@ Ingestion is asynchronous and automatic. Poll until the auto-created test cases
 uip tm testcases list --project-key <PROJECT_KEY> --output json
 ```
 
-- Poll **unfiltered**. Do NOT pass `--filter <PackageName>` — `--filter` matches a test case's name or key by **prefix**, and an ingested test case is named `"<suite> > <test title>"`, so a package name never matches: the call stays empty forever and reads as a false "ingestion never happened".
+- Poll **unfiltered**. Do NOT pass `--filter <PackageName>` — `--filter` matches a test case's name or key by **prefix** (see SKILL.md Rule 9), and an ingested test case is named `"<suite> > <test title>"`, so a package name never matches: the call stays empty forever and reads as a false "ingestion never happened".
 - The rows carry `TestCaseKey` (e.g. `SHIP:1`) plus `Id` (the UUID) and `Name` — count `TestCaseKey`, not `Id`, when polling.
 - Ingestion is done when `TestCount` new test cases from Step 1 are present, each named `"<suite> > <test title>"`. A plain `pack` prints only `Package`, `Output` and `TestCount` — if you want the exact expected names up front, run `--dry-run` first or read `testCases.json` inside the `.nupkg`; otherwise match on the count plus that name shape.
 - `TestCount` from Step 1 is one test case per Playwright **test** — it is not multiplied by the number of Playwright projects (2 tests × 2 projects → 2 test cases).
@@ -135,7 +135,8 @@ uip tm testsets playwright-context --test-set-key <TEST_SET_KEY> --output json
 Read the fields off the JSON response rather than relying on the names below staying current — this list describes today's shape, and `--output json` always carries whatever the API returns.
 
 - `Data.IsPlaywright: true` → the set resolves to one Playwright package; `AvailablePlaywrightProjects` holds the only valid `--playwright-projects` values, and `SelectedPlaywrightProjects` shows any selection already stored on the test set. Both are **comma-joined strings** (`"chromium, firefox"`), not arrays — split on `", "` when scripting; no stored selection is `""`.
-- `Data.IsPlaywright: false` → RPA, mixed, manual, or multi-package test set — run it **without** `--playwright-projects`.
+- `Data.IsPlaywright: false` → the set does **not** resolve to exactly one synced Playwright package (RPA, multi-package, or no package at all) — run it **without** `--playwright-projects`.
+- **`true` does not mean "only Playwright".** The check is *one* Playwright package, not *only* Playwright tests: a set holding Playwright tests from one package plus manual test cases still reports `true`, because manual cases resolve to no package. Treat the flag as "project selection is available here", not as a purity test.
 - The server never errors on type here, so this is the safe discriminator for automation: probe first, branch on `IsPlaywright`.
 - **False negative without a folder:** the probe resolves the package through the project's default folder — if that isn't set (Step 4), a genuine Playwright test set reports `IsPlaywright: false`. Set the default folder before trusting a `false`.
 

package/skills/uipath-test/references/publish-and-link-guide.md

@@ -27,7 +27,7 @@ uip tm wait              → block until terminal
 uip rpa pack "<PROJECT_DIR>" "<OUTPUT_DIR>" --output json
 ```
 
-Both arguments are positional — there is no `--project-dir` / `--project-path` flag here. See [/uipath:uipath-rpa § publishing-guide.md](../../uipath-rpa/references/publishing-guide.md) for full pack flags. Capture `OutputPath` from the JSON output — that's the `.nupkg` to upload.
+Both arguments are positional — there is no `--project-dir` / `--project-path` flag here. See [/uipath:uipath-rpa § cli-reference.md § Pack & Publish to Orchestrator](../../uipath-rpa/references/cli-reference.md#pack--publish-to-orchestrator) for full pack flags. Capture `OutputPath` from the JSON output — that's the `.nupkg` to upload.
 
 ## Step 2 — Upload to Orchestrator
 
@@ -80,7 +80,7 @@ Two run modes — pick one:
 **Single test case** — uses `--test-case-id <UUID>`, NOT `--test-case-key`. Get the UUID from `uip tm testcases list --output json` (`Id` field):
 
 ```bash
-uip tm testcases run --project-key <PROJECT_KEY> --test-case-id <TEST_CASE_UUID> --execution-type automated --output json
+uip tm testcases run --project-key <PROJECT_KEY> --test-case-id <TEST_CASE_UUID> --name <EXECUTION_NAME> --execution-type automated --output json
 ```
 
 **Whole test set** — uses `--test-set-key`:

package/skills/uipath-troubleshoot/references/activity-packages/classic-activities/playbooks/click-silent-no-op.md

@@ -26,7 +26,7 @@ What this looks like:
 
 What can cause it:
 
-- **Input method not honored by the target technology.** Classic Click exposes two mutually-exclusive booleans: `SimulateClick` and `SendWindowMessages`; both unset = **Default** (hardware events). **`SimulateClick` and `SendWindowMessages` are not supported for Java, SAP, and some legacy Win32 / Citrix targets** — the event is posted, the activity reports success, and the control never reacts. Primary cause when the target app is Java/SAP. (Both booleans unset — hardware events — does drive these technologies.)
+- **Input method did not actuate the control.** Classic Click exposes two mutually-exclusive booleans: `SimulateClick` and `SendWindowMessages`; both unset = **Default** (hardware events). `SimulateClick` acts through the element's control/accessibility API and IS supported for browsers, Java and SAP - but only when the specific control implements the action. A control that accepts the API call without acting produces a silent miss. This is **per-element, not per-technology**: do NOT conclude it from `app='java.exe'` (or SAP) alone. A node that cannot take the control API at all fails loudly with `Cannot use UI_CONTROL_API on this UI node. Please use UI_HARDWARE_EVENTS method.` - that is an Error log, so it belongs to the exception paths above, not here. Two Simulate limits independent of technology: only a **single left click with no key modifiers** is honored (double + right/middle raises `Simulate input method is not supported for Double Right/Middle Click` at validation), and a click **offset** is honored only on Java targets.
 - **Click intercepted by a covering element** — an overlay, modal, tooltip, or another window sat over the target; the event hit the cover.
 - **Wrong target resolved** — a loose/positional selector matched a duplicate / off-screen / inert element that looks right.
 - **`ClippingRegion` / `CursorPosition` offset** places the click at a point outside the element or on empty space.
@@ -34,7 +34,7 @@ What can cause it:
 
 What to look for:
 
-- The classic Click's `SimulateClick` / `SendWindowMessages` flags and the target **technology** (from the full selector). Source-required.
+- The classic Click's `SimulateClick` / `SendWindowMessages` flags, the click shape (`ClickType`, `MouseButton`, `KeyModifiers`), and the target **technology** (from the full selector). Source-required. Technology alone does not confirm or eliminate the input-method branch.
 - Runtime proof of no-effect in Info-level logs or business output — needed to separate "silently did nothing" from "did the right thing and the user is mistaken".
 
 ## Investigation
@@ -48,7 +48,7 @@ Source-required — resolve the project per SKILL.md §5.4 before concluding.
    - `SimulateClick` (`True`/`False`) and `SendWindowMessages` (`True`/`False`). Both `False` = Default / hardware events.
    - `ClippingRegion` / `CursorPosition` / `OffsetX` / `OffsetY` if set.
 5. Read the activity's full `Selector` and identify the **target technology**: `app='java.exe'` / a `javastate`/`java` attribute = Java; `app='saplogon.exe'` / `sapwnd` = SAP; a browser or plain `wnd`/`ctrl` for Win32/WPF.
-6. Cross-check the input-method × target-technology support with docs when the pairing looks unsupported: `uip docsai ask "Is the SimulateClick / SendWindowMessages input method supported for Java (or SAP) applications in UiPath UI Automation?" --source docs`.
+6. Do NOT ask docs whether the input method is supported for the target technology - `SimulateClick` is documented as supported (and recommended) for browsers, Java and SAP, so a technology-level answer neither confirms nor eliminates branch **(A)**. What decides it is element-level: runtime proof of no-effect (step 3) plus a re-run on Default hardware events.
 
 ## Resolution
 
@@ -56,7 +56,7 @@ Source-required — resolve the project per SKILL.md §5.4 before concluding.
 
 Walk from the top; stop at the first branch that matches.
 
-1. **Is `SimulateClick=True` or `SendWindowMessages=True` AND the target technology is Java, SAP, or legacy Win32/Citrix?** → branch **(A)**. Documented-unsupported pairing — the event is never processed.
+1. **Is `SimulateClick=True` or `SendWindowMessages=True`, with runtime proof the control never acted and no `UI_CONTROL_API` Error log?** → branch **(A)**. The control accepted the API-level event without performing the action. Report it as the *likely* cause, confirmed only by a re-run on Default hardware events - the target technology is not evidence either way.
 2. **Was a covering element present** (overlay / modal / another window over the target)? → branch **(B)**.
 3. **Did the selector resolve a duplicate / off-screen / inert element** (loose/positional `idx=`)? → branch **(C)**.
 4. **Is a `ClippingRegion` / `CursorPosition` offset set** that lands off the element? → branch **(D)**.
@@ -66,7 +66,7 @@ In every branch, **also** add explicit outcome detection (branch **(F)**) — cl
 
 ### Branches
 
-- **(A) Input method unsupported for the target technology.** Set `SimulateClick=False` AND `SendWindowMessages=False` so the Click uses **Default (hardware events)**, which drives Java/SAP/legacy Win32 (requires an interactive session with the target in the foreground). Do NOT set both flags together — that is a separate config error. Re-run and confirm the effect lands.
+- **(A) Control did not act on the API-level event.** Set `SimulateClick=False` AND `SendWindowMessages=False` so the Click uses **Default (hardware events)**, which drives the physical cursor and works regardless of the UI framework (requires an interactive session with the target in the foreground). This is the same remedy the driver itself names when a node rejects the control API. Do NOT set both flags together — that is a separate config error. Re-run and confirm the effect lands; if it still misses, the cause is elsewhere (B)-(E).
 - **(B) Covering element intercepted the event.** Add a deterministic dismiss/wait step before the Click (close the banner/modal; `Wait UI Element Appear`/`Element Exists` on the blocker's absence).
 - **(C) Wrong element resolved.** Tighten the `Selector` to a stable, unique attribute; remove positional `idx=`.
 - **(D) Offset lands off the element.** Clear or correct `ClippingRegion` / `CursorPosition` (`OffsetX`/`OffsetY`) so the click point falls inside the target.

package/skills/uipath-troubleshoot/references/activity-packages/classic-activities/playbooks/queue-operation-failed.md

@@ -63,12 +63,23 @@ What to look for:
    not found, and timeout.
 5. Confirm the robot account is authenticated and has the queue permission required by that operation
    in the folder.
-6. When runtime evidence proves the queue name was unavailable but does not explain why that name was
+6. **Enumerate queues in the other folders the identity can see**, not just the job's folder. This is
+   what closes the wrong-execution-folder branch: if the queue exists elsewhere, the process is running
+   in the wrong folder and that is the fix; if no folder holds it, the branch is excluded and only
+   wrong-name and missing-queue remain. Report the result either way — "the job's folder has no queues"
+   leaves the branch open, "no visible folder holds this queue" closes it.
+7. When runtime evidence proves the queue name was unavailable but does not explain why that name was
    used, check the working-directory source boundary from `SKILL.md` §5: inspect the named workflow and
    `project.json` if present. If source is unavailable, leave wrong name, deleted/missing queue, and
    wrong execution folder as explicit conditional branches; do not pick one from the activity display
    name or a suggestive suffix.
 
+**State the evidence boundary as two separate claims.** Keep what the runtime response proves apart from
+what it cannot: the correlated 404 / error 1002 establishes that the name was unavailable **at run
+time** — that part is settled, not a hypothesis. Whether the name is wrong, the queue was deleted, or
+the process ran in the wrong folder is what remains open, and only source or folder inventory closes it.
+Blurring the two into one hedge understates a conclusion you have actually established.
+
 ## Resolution
 
 - **If the queue name is empty:** set `QueueName` (ensure the upstream variable/argument that feeds it
@@ -79,9 +90,14 @@ What to look for:
   intended schema and settings.
 - **If the intended queue exists in another folder:** run/deploy the process in that folder, or define
   the intended queue in the current job folder.
-- **If evidence cannot choose among those three branches:** lead with the source/configuration check
-  that discriminates them, then present all three as conditional fixes. Do not create a queue merely
-  because a not-found response occurred.
+- **If evidence cannot choose among the wrong-name, missing/deleted, and wrong-folder branches:** lead
+  with the source/configuration check that discriminates them, then present each as a labelled
+  conditional fix — **either** create/recreate the queue under the exact name the activity references,
+  **or** correct the activity's `QueueName` to an existing queue and republish, **or** run the process
+  in the folder that holds the intended queue. Naming only one of them is an incomplete answer: without
+  the project source you cannot tell whether the name is wrong or the queue is gone, so the user needs
+  every branch that the evidence still allows. Do not create a queue merely because a not-found response
+  occurred.
 - **If keys contain reserved characters:** rename the Add item's information keys to remove `.`, `#`,
   `@`, `:`.
 - **If a key is duplicated across the two collections:** remove the duplicate so each Add item key

package/skills/uipath-troubleshoot/references/activity-packages/classic-activities/summary.md

@@ -13,7 +13,7 @@ see the **system-activities** package.
 | UI Activity Timeout | Medium | A classic UI activity threw `ActivityTimeoutException` ("Activity timeout exceeded") — the element or state was never reached. Includes `Wait UI Element Appear` (element never appeared) and `Wait Image Vanish` (image still present after the timeout). | [ui-activity-timeout.md](./playbooks/ui-activity-timeout.md) |
 | UI Element Interaction Failed | Medium | `ElementOperationException` from `Click` / `Type Into` / `Send Hotkey` / `Take Screenshot` — the element was located but the action could not be performed (disabled, occluded, off-screen, or focus lost between find and act). | [ui-element-interaction-failed.md](./playbooks/ui-element-interaction-failed.md) |
 | Type Into — Wrong, Incomplete, or Appended Text | Medium | **No signature** (no exception, job `Successful`, zero Error logs). A classic `Type Into` found its field and posted keystrokes, but the **resulting value is wrong** — new text appended because the field was not cleared (`EmptyField` unset), characters dropped/garbled by the input method (`SimulateType`/`SendWindowMessages` on Java/SAP/Citrix), literal text interpreted as key commands (`[k(...)]`, `+^%(){}`), or a mask/autocomplete rewrite. The text landed, just wrong — distinct from a pure no-op (nothing landed → click-silent-no-op.md). Route here via the no-signature table. | [type-into-wrong-or-incomplete-text.md](./playbooks/type-into-wrong-or-incomplete-text.md) |
-| Click Silent No-Op — Reported Success But Did Nothing | Medium | **No signature** (no exception, job `Successful`, zero Error logs). A classic input activity (`Click`, `Type Into`, `Send Hotkey`) posted its event and reported success, but the effect never landed. Causes: input method unsupported by the target tech (`SimulateClick`/`SendWindowMessages` on Java/SAP/legacy Win32), covering overlay, wrong/duplicate element, `ClippingRegion`/`CursorPosition` offset, lost focus. Classic Click has NO Verify Execution, so the miss is silent by design. Distinct from `ElementOperationException` (ui-element-interaction-failed.md, which throws). Route here via the no-signature table. | [click-silent-no-op.md](./playbooks/click-silent-no-op.md) |
+| Click Silent No-Op — Reported Success But Did Nothing | Medium | **No signature** (no exception, job `Successful`, zero Error logs). A classic input activity (`Click`, `Type Into`, `Send Hotkey`) posted its event and reported success, but the effect never landed. Causes: control did not act on the API-level event under `SimulateClick`/`SendWindowMessages` (per-element, NOT a Java/SAP technology rule - Simulate is supported there), covering overlay, wrong/duplicate element, `ClippingRegion`/`CursorPosition` offset, lost focus. Classic Click has NO Verify Execution, so the miss is silent by design. Distinct from `ElementOperationException` (ui-element-interaction-failed.md, which throws). Route here via the no-signature table. | [click-silent-no-op.md](./playbooks/click-silent-no-op.md) |
 | Browser Could Not Open or Attach | Medium | `BrowserOperationException` / invalid-browser error from `Open Browser`, `Close Tab`, or `Attach Browser` (Browser Scope) — browser not installed/launchable, extension missing/disabled, browser crashed, or wrong browser type for the communication method. | [browser-open-or-attach-failed.md](./playbooks/browser-open-or-attach-failed.md) |
 | BrowserScope (Attach Browser) Errors | Medium | Classic `UiPath.Core.Activities.BrowserScope` (Attach Browser) failures, owning the **COM / environmental** family — `System.Runtime.InteropServices.COMException`, `HRESULT E_FAIL` (`0x80004005`), "Invalid access to memory location" — from display-scaling mismatch, privilege/integrity-level mismatch, or non-interactive/Session-0 runs (works on dev, fails on the prod robot). Also covers the BrowserScope-specific `TimeoutMS`-fallback-after-package-migration tell. Routes "cannot communicate" (extension/comms) → browser-open-or-attach-failed.md and selector/timeout signatures → ui-element-not-found.md / ui-activity-timeout.md. Recommends migrating to modern Use Application/Browser. | [browser-scope-errors.md](./playbooks/browser-scope-errors.md) |
 | Application Could Not Launch | Medium | `Open Application` / `Open Browser` failed to start the target. File/executable path not found, bad arguments, or "Both FileName and Arguments arguments are null" validation. The app never produced a window for the scope to attach to. | [application-launch-failed.md](./playbooks/application-launch-failed.md) |

package/skills/uipath-troubleshoot/references/activity-packages/csv-activities/playbooks/read-csv-file-not-found.md

@@ -20,11 +20,23 @@ What to look for:
 - The `FilePath` expression in the `.xaml`: is the variable quoted as a literal string? Is the path relative? Does the folder portion exist?
 - Whether the failure is intermittent (points at a timing race) or every run (points at a wrong/quoted path).
 
+**Discriminator — the file's presence afterward decides the branch.** If the file is sitting at the
+*exact path from the error message* when someone checks later, the path was correct all along: a
+quoted-literal or drifted relative path resolves somewhere the file never appears, so it could not
+produce the file at that path. That single observation **excludes** the quoted-path and
+working-directory branches and confirms timing. Combined with an intermittent failure pattern (fails
+most runs, occasionally works) it is conclusive — lead with the race, do not report a path problem as
+the primary cause and the race as a secondary possibility.
+
+The converse also holds: if the file is genuinely not at that path afterward, timing is excluded and
+the cause is the path expression itself.
+
 ## Investigation
 
 1. Read the error and the resolved path from job evidence; confirm it is `Could not find file` / `Could not find a part of the path` at `Read CSV`.
 2. Read the `Read CSV` `FilePath` expression from the `.xaml`: is it a bare variable, a quoted literal, a relative path? Does the directory portion exist on the host?
 3. Check what runs immediately before the read — a download/export/sync — and whether failures are intermittent (race) vs every run (bad path).
+4. Establish whether the file is present at the error's exact path after the fault, and apply the discriminator above. Ask the user if it is not already in evidence — it is the cheapest decisive fact available, and it settles the branch on its own.
 
 ## Resolution
 

package/skills/uipath-troubleshoot/references/activity-packages/mail-activities/playbooks/send-outlook-mail-failures.md

@@ -43,7 +43,17 @@ Go in this order — cheaper checks first.
 
 3. **Confirm branch 1 (COM cast / library not registered).** Confirm the desktop Outlook is installed on the **Robot host** (not only the developer machine) and note its **bitness** against the Robot process. A 64-bit process with a 32-bit-only Outlook (or a corrupted type library after an Office update) produces the cast / not-registered error. Check for a stray `OUTLOOK.EXE` left running with no window from a prior job.
 
-4. **Confirm branch 2 (timeout / hang).** Determine whether the run is **unattended** (no interactive desktop). Check whether the Outlook **security prompt** could be firing (antivirus state / programmatic-access policy), whether Outlook is in **Work Offline** mode, and whether the Robot's Windows user has a configured profile. Read `TimeoutMS` and compare against a realistic profile-load + send time. A hang on an unattended Robot with no visible Outlook is the prototypical case.
+4. **Confirm branch 2 (timeout / hang), then pick the sub-cause.** Determine whether the run is **unattended** (no interactive desktop). Read `TimeoutMS` and compare against a realistic profile-load + send time. A hang on an unattended Robot with no visible Outlook is the prototypical case.
+
+   Branch 2 has three sub-causes and they are **separable — do not report them as equally likely.** The job log discriminates them:
+
+   | Log / test evidence | Sub-cause | Why |
+   |---|---|---|
+   | Item reaches the **Outbox** and stays there; connectivity reports Disconnected; **no dialog or prompt raised** | **Work Offline** | The message was accepted and queued — the Object Model Guard never lets it get that far. Offline means there is nothing to transmit against, so the call blocks to `TimeoutMS`. |
+   | A modal is **awaiting input**; the item was never queued; an attended re-run on the host **shows the popup** | **Object Model Guard / security prompt** | The Guard blocks at compose/send time, before the item is created. |
+   | Item sends, but only after a long first profile load; duration near but under a raised `TimeoutMS` | **Slow profile load** | Genuinely slow, not blocked. |
+
+   An attended re-run on the same host is the decisive test: **a popup appearing** confirms the Guard; **no popup plus mail left sitting in the Outbox** confirms Work Offline and eliminates the Guard. Eliminate the sub-causes the evidence excludes rather than listing them as parallel checks — registering antivirus or setting the programmatic-access GPO does nothing for an offline mailbox.
 
 5. **Confirm branch 3 (uninitialized input).** In the workflow source, trace the variables bound to `To`, `Subject`, `Body`, and each attachment path back to their producers. A variable left `Nothing` (upstream step skipped, or declared in an inner scope) or an empty attachment path confirms the branch. Reproduce by hardcoding literal values into the activity fields — if the error disappears, an input was null.
 
@@ -63,6 +73,7 @@ Map the branch identified in Investigation to the fix:
   - Make sure Outlook is **running, signed in, and Online** (turn off `Send/Receive > Work Offline`) under the Robot's Windows user before the activity runs.
   - Resolve the **security prompt** at its source rather than waiting on it: keep antivirus up to date and registered with Windows Security Center (this is what normally suppresses the Object Model Guard prompt), or set the Outlook programmatic-access / Trust Center policy via Group Policy for the Robot's user. Do **not** rely on a human dismissing the prompt on an unattended Robot.
   - If the send is **legitimately** slow (first profile load), raise `TimeoutMS` above the worst observed duration (it is in **milliseconds**: `60000` = 60 s). Raising the timeout does **not** fix a blocking security prompt or Work Offline state — only branch-2 *slowness*.
+  - **When the run is unattended, pair the immediate fix with the durable one.** Clearing Work Offline or the prompt fixes this run, but the desktop-Outlook dependency will keep producing branch-1 and branch-2 faults on a host with no interactive session — online/offline state, profile health and modal prompts are all things an unattended Robot cannot manage. Recommend migrating the activity to **Send SMTP Mail Message** or the Graph **o365-activities** (see the alternative below) as part of the same answer, not as a footnote.
 
 - **Branch 3 — Uninitialized input:**
   - Initialize every variable bound to `To`, `Subject`, and `Body` before the activity, and guard against null/empty (a null `To` is the most common). Validate it by hardcoding literal values into the fields first.

package/skills/uipath-troubleshoot/references/activity-packages/system-activities/playbooks/get-asset-activity-bug-silent-failure.md

@@ -6,7 +6,7 @@ confidence: medium
 
 ## Context
 
-A `Get Asset` or `Get Orchestrator Asset` activity completes without throwing an exception, but the output variable is null, zero, or empty.
+A `Get Asset`, `Get Orchestrator Asset`, or `Get Credential` (`GetRobotCredential`) activity completes without throwing an exception, but the output variable is null, zero, or empty. The defect is in the shared output-binding path of the `UiPath.System.Activities` asset family, so it covers `Get Credential` exactly as it covers `Get Asset`: its `Username` / `Password` outputs stay null. Do NOT exclude this cause because the failing activity is `Get Credential` rather than `Get Asset`.
 
 What this looks like:
 - Activity completes successfully (no exception in job traces)
@@ -28,6 +28,7 @@ What to look for:
 1. Check whether the activity was copy-pasted from another sequence — copy-paste retains internal state from the original.
 2. Check the Studio and `UiPath.System.Activities` package version — version 22.10.x has a bug where variables created with `Ctrl+K` do not receive output values.
 3. Verify the output variable was created before the activity (not via `Ctrl+K` during activity configuration in the affected version).
+4. Neither authoring gesture is recorded in the workflow source. A `Ctrl+K` variable and a Variables-panel variable both serialize as a plain `<Variable>` in the enclosing scope's `Variables` collection, and a copy-pasted activity is indistinguishable from a freshly dragged one. Confirm the creation path with the developer. If that is unavailable, treat the package version as the deciding signal. Do NOT exclude this cause because the XAML shows the variables pre-declared.
 
 ## Resolution
 

package/skills/uipath-troubleshoot/references/activity-packages/terminal-activities/playbooks/terminal-session-connection-failed.md

@@ -44,7 +44,9 @@ What can cause it:
 2. **Map the message to the failing step:** `Error initiating connection` → open failed (reachability/provider); `Error waiting for connection` → ready-timeout; `Terminal host process path not found` / `Error initializing EHLLL library` / `Error attaching to session` → provider runtime missing/misconfigured on the robot; `The specified existing connection is disconnected` → stale reused connection; `No connection specified` → no input.
 3. **Capture the connection config** from the connection string or workflow source: provider type, terminal type, host, port, and the configured `TimeoutMS`.
 4. **Check host reachability from the robot machine** (not the developer machine) — host/port open, and the emulator/provider runtime installed there.
-5. **For reused connections,** confirm the upstream `TerminalSession` that produced the `ExistingConnection` kept it alive (output connection / `CloseConnection` unchecked) and that it didn't already close.
+5. **For reused connections only,** confirm the upstream `TerminalSession` that produced the `ExistingConnection` kept it alive (output connection / `CloseConnection` unchecked) and that it didn't already close.
+
+The `ExistingConnection` branches apply **only** when the message is `The specified existing connection is disconnected` or `No connection specified`. A session that opens a new connection from a `ConnectionString` cannot fail this way — do not raise `ExistingConnection` as a candidate for it, and do not offer it as a "check this too" step. Likewise, once the message maps to a single failing step in step 2, name that cause; listing the full cause table back to the user as undifferentiated possibilities is not a diagnosis.
 
 ## Resolution
 
@@ -55,4 +57,6 @@ What can cause it:
 - **If `No connection specified`:** provide a non-empty `ConnectionString` or a valid `ExistingConnection`.
 - **If `Service unavailable`:** restore/restart the terminal service the provider depends on, then re-run.
 
+When the fault arrived wrapped in `System.AggregateException`, say so explicitly in the answer: the aggregate is only the async wrapper around the connect task, and the inner `TerminalConnectionException` (with its `ResultCode` / `ConnectionStatus` trailer) is the root cause. An answer that stops at "one or more errors occurred" has not diagnosed anything.
+
 If the host is demonstrably reachable, the provider runtime is installed, and the connection string is correct yet the open still fails, the cause is outside the activity — escalate to the terminal host / emulator administrator.

package/skills/uipath-troubleshoot/references/activity-packages/ui-automation/playbooks/click-silent-no-op.md

@@ -26,7 +26,7 @@ What this looks like:
 
 What can cause it:
 
-- **Input method not honored by the target technology.** `InteractionMode = Simulate` (a.k.a. SimulateClick) or `SendWindowMessages` posts a message-level event that the target UI framework never processes. **`Simulate` / `SendWindowMessages` are not supported for Java, SAP, and some legacy Win32 / Citrix targets** — the event is posted, the activity reports success, and the control never reacts. Primary cause when the target app is Java/SAP.
+- **Input method did not actuate the control.** `InteractionMode = Simulate` acts through the element's control/accessibility API and IS supported for browsers, Java and SAP - it is the product's *recommended* mode for those technologies, and `Background` resolves to it - but only when the specific control implements the action. A control that accepts the API call without acting produces a silent miss. This is **per-element, not per-technology**: do NOT conclude it from `app='java.exe'` (or SAP) alone. A node that cannot take the control API at all fails loudly with `Cannot use UI_CONTROL_API on this UI node. Please use UI_HARDWARE_EVENTS method.` - that is an Error log, so it is not this family. Two Simulate limits independent of technology: only a **single left click with no key modifiers** is honored, and a click **offset** is honored only on Java targets (silently ignored elsewhere under Simulate, which is its own miss cause).
 - **Click intercepted by a covering element** — a transparent overlay, cookie/consent banner, modal, or tooltip sat on top of the target at action time; the event hit the overlay, not the control.
 - **Wrong target resolved** — the selector matched a duplicate / off-screen / ARIA-hidden / shadow-DOM element that looks right but is inert.
 - **Focus / activation lost** between activities — a prior step left focus on another window/tab, so the posted input went nowhere.
@@ -35,7 +35,7 @@ What can cause it:
 
 What to look for:
 
-- The activity's `InteractionMode` and the enclosing scope's **target technology** — these live only in the workflow source. Source-required.
+- The activity's `InteractionMode`, the click shape (`ClickType`, `MouseButton`, `KeyModifiers`, `PointOffset`), and the enclosing scope's **target technology** — these live only in the workflow source. Source-required. Technology alone does not confirm or eliminate the input-method branch.
 - Whether Verify Execution is configured with a **real verification target** (not just a `Mode`).
 - Runtime proof of no-effect in the Info-level logs or business output — needed to separate "silently did nothing" from "did the right thing and the user is mistaken".
 
@@ -50,7 +50,7 @@ Source-required — resolve the project per SKILL.md §5.4 before concluding.
    - `InteractionMode` (`Simulate` / `SendWindowMessages` / `HardwareEvents` / `ChromiumAPI` / `Background`).
    - `VerifyOptions` — is a verification `Target` set, or is it inert (`Mode` only, empty `Retry`/`Timeout`)?
 5. Open the enclosing scope (`NApplicationCard` / Use Application/Browser) and read its `TargetApp` **technology**: `app='java.exe'` / a `javastate` selector = Java; `app='saplogon.exe'` / `sapwnd` = SAP; a Chromium `app='chrome.exe'`/`'msedge.exe'` with an HTML selector = browser.
-6. Cross-check the input-method × target-technology support with docs when the pairing looks unsupported: `uip docsai ask "Is the Simulate / SendWindowMessages input method supported for Java (or SAP) applications in UiPath UI Automation?" --source docs`.
+6. Do NOT ask docs whether the input method is supported for the target technology - `Simulate` is documented as supported and recommended for browsers, Java and SAP, so a technology-level answer neither confirms nor eliminates branch **(A)**. What decides it is element-level: runtime proof of no-effect (step 3) plus a re-run on `HardwareEvents`.
 7. If HA was enabled, confirm the empty recovery archive — it is the expected "no fault, no trigger" state, not a separate defect to fix.
 
 ## Resolution
@@ -59,7 +59,7 @@ Source-required — resolve the project per SKILL.md §5.4 before concluding.
 
 Walk from the top; stop at the first branch that matches.
 
-1. **Is `InteractionMode = Simulate` or `SendWindowMessages` AND the target technology is Java, SAP, or legacy Win32/Citrix?** → branch **(A)**. Documented-unsupported pairing — the message-level event is never processed.
+1. **Is `InteractionMode = Simulate` / `SendWindowMessages` / `Background`, with runtime proof the control never acted and no `UI_CONTROL_API` Error log?** → branch **(A)**. The control accepted the API-level event without performing the action. Report it as the *likely* cause, confirmed only by a re-run on `HardwareEvents` - the target technology is not evidence either way.
 2. **Was a covering element present** (overlay / banner / modal detected in HA data or visible in the informative screenshot)? → branch **(B)**.
 3. **Did the selector resolve a duplicate / off-screen / hidden element** (multiple matches, `idx=`-positional, shadow/iframe)? → branch **(C)**.
 4. **Was focus/activation on the wrong window** at action time (prior activity left another app foreground; `ActivateBefore` not set)? → branch **(D)**.
@@ -69,7 +69,7 @@ In every branch, **also** close the detection gap (branch **(F)**) so a future m
 
 ### Branches
 
-- **(A) Input method unsupported for the target technology.** Change `InteractionMode` to one the target supports: for **Java / SAP / legacy Win32**, use **`HardwareEvents`** (drives the physical cursor/keyboard — works regardless of framework; requires an interactive session and the foreground). `ChromiumAPI` is browser-only; `Simulate`/`SendWindowMessages` stay valid for HTML and many WPF/WinForms targets but not Java/SAP. Fix at the acting activity's `InteractionMode`. Re-run and confirm the effect lands.
+- **(A) Control did not act on the API-level event.** Set the acting activity's `InteractionMode` to **`HardwareEvents`** (drives the physical cursor/keyboard — works regardless of framework; requires an interactive session and the foreground). This is the same remedy the driver itself names when a node rejects the control API. `ChromiumAPI` is browser-only. Re-run and confirm the effect lands; if it still misses, the cause is elsewhere (B)-(E). Note `HardwareEvents` gives up Simulate's background/out-of-focus execution, so state that trade-off when proposing it.
 - **(B) Covering element intercepted the event.** Add a deterministic dismiss/wait step before the action (close the banner, dismiss the modal, Check App State for the overlay to disappear). Inspect HA data / the informative screenshot for the intercepting element. See [interpretations/healing-agent-data.md](../interpretations/healing-agent-data.md).
 - **(C) Wrong element resolved.** Tighten the activity's `Target` selector to a stable, unique attribute; remove positional `idx=`; for shadow-DOM/iframe, scope to the correct frame. Do not loosen — the current selector matched something inert.
 - **(D) Focus/activation lost.** Set `ActivateBefore = True` on the activity, or add a Use Application / Activate step before it so the target window is foreground when the input is posted.

package/skills/uipath-troubleshoot/references/activity-packages/ui-automation/playbooks/dependency-version-conflict.md

@@ -15,7 +15,15 @@ Two signatures, two root causes, two fixes. Discriminate first.
 - Message: `Method not found: 'Void UiPath.UIAutomationNext.Activities…'` (or `System.MissingMethodException` naming a UIAutomationNext type/member).
 - The assembly **loaded**, but a member the caller was compiled against is absent.
 - Surfaces at project **open / validation** in Studio, or at first activity execution.
-- Root cause: **version mismatch inside the project's own dependency set.** The package set in `project.json` pins versions whose bundled `UiPath.UIAutomationNext` / `UiPath.UIAutomationNext.Activities` disagree. Most common triggers:
+Two different skews produce this same exception. **Split them on whether the failure is environment-dependent** — this decides the fix, and the two fixes are not interchangeable.
+
+**A1 — same package, different version per environment** (check this first when a robot is involved). The project pins one `UiPath.UIAutomation.Activities` version, but the machine that *runs* the workflow restored a different build of that same package. The assembly loads (so there is no `FileLoadException`), yet the member the compiled `.xaml` was built against is absent from the restored build.
+
+- Tell: **works in Studio / Debug on the authoring machine, faults on the robot or Assistant.** Same project, same `.xaml`, different outcome per environment.
+- The pinned version in `project.json` alone does not confirm agreement — it states what the project asks for, not what each environment actually restored.
+- This is *not* a disagreement between two different packages. Do not attribute it to `UiPath.System.Activities` (or any sibling) merely because its version also differs; that difference is incidental unless the missing member belongs to that package's assembly.
+
+**A2 — version mismatch inside the project's own dependency set.** The package set in `project.json` pins versions whose bundled `UiPath.UIAutomationNext` / `UiPath.UIAutomationNext.Activities` disagree. Fails everywhere, including Studio. Most common triggers:
   - `UiPath.UIAutomation.Activities` bumped in isolation while `UiPath.System.Activities` (or a dependent package) stayed on an older, incompatible line — or vice versa.
   - A sibling package (`UiPath.Testing.Activities`, `UiPath.MicrosoftOffice365.Activities`, a shared **library**) compiled against a different UIAutomationNext version than the one the project resolves; the older `.dll` wins at load and the newer caller's method is missing.
 
@@ -29,8 +37,9 @@ Two signatures, two root causes, two fixes. Discriminate first.
 ## Investigation
 
 1. Capture the **exception type** and full message. `MissingMethodException` / "Method not found" → Signature A. `FileNotFoundException` / `FileLoadException` / "Could not load file or assembly" → Signature B. This single fact selects the branch — do not proceed without it.
+1b. For Signature A, split A1 from A2 on **environment dependence**: does the same project run in Studio/Debug and fail only on the robot or Assistant? Yes → **A1** (same package, different restored build per environment). Fails everywhere including Studio → **A2** (the project's own package set disagrees). Note which package owns the member named in the message — that is the package to realign, and a version difference in an unrelated sibling is not the cause.
 2. Read `project.json` `dependencies` and `studioVersion`. Record every package that carries UI Automation: `UiPath.UIAutomation.Activities`, and any of `UiPath.Testing.Activities`, `UiPath.MicrosoftOffice365.Activities`, plus referenced libraries. Note whether one was bumped out of step with `UiPath.System.Activities`.
-3. Note **where** it fails: design-time (open/validate) vs runtime, and **which environment** (Studio vs Assistant/robot). Studio-only-passes + robot-fails is strong evidence for Signature B.
+3. Note **where** it fails: design-time (open/validate) vs runtime, and **which environment** (Studio vs Assistant/robot). Studio-only-passes + robot-fails means the two environments resolved different packages — but the exception type decides which branch that is: a load failure → Signature B, `MissingMethodException` → Signature A1. The environment tell alone does not select B.
 4. For Signature B: identify the pinned `UiPath.UIAutomation*` version and confirm whether that exact version exists on the Orchestrator/tenant feed and in the robot's `%userprofile%\.nuget\packages`.
 5. Confirm the assembly named is `UiPath.UIAutomationNext.Activities` (or its transitive `UiPath.UIAutomationNext` / `UiPath.UIAutomationCore`). A different assembly name → a different package's conflict; apply the same reasoning to that package.
 
@@ -38,16 +47,28 @@ Two signatures, two root causes, two fixes. Discriminate first.
 
 Walk from the signature you confirmed in Investigation step 1.
 
-### Signature A — align the project's dependency set (Manage Packages)
+### Signature A1 — pin one exact version across every environment
+
+Use this when the failure is environment-dependent (runs in Studio/Debug, faults on the robot).
+
+1. Open **Manage Packages** → Project Dependencies and read the installed `UiPath.UIAutomation.Activities` version.
+2. Choose **one stable version and make it identical everywhere** the project runs — authoring Studio, the robot, and any other execution machine. Upgrade or downgrade so they match.
+3. **Pin that exact version in `project.json` — not a floating range.** A range is what let the two environments resolve different builds; re-pinning is the fix, not a precaution.
+4. Restore/rebuild and **republish** so the robot picks up the aligned dependency.
+5. Re-run on the robot. `Method not found` clears once the restored assembly exposes the signature the `.xaml` was built against.
+
+Keep the recommendation scoped to the package that owns the missing member. Bumping the whole foundational set here is broader than the defect and changes packages that were never implicated.
+
+### Signature A2 — align the project's dependency set (Manage Packages)
 
-The fix lives in `project.json` / **Manage Packages**, not on the robot.
+Use this when the failure reproduces everywhere, Studio included. The fix lives in `project.json` / **Manage Packages**, not on the robot.
 
 1. Open **Manage Packages** in Studio.
 2. Update **all foundational packages together** to a mutually compatible, latest-stable line: `UiPath.System.Activities`, `UiPath.UIAutomation.Activities`, and every package that brings `UiPath.UIAutomationNext` (Testing, Office365, referenced libraries). Do **not** bump one in isolation — that is what produced the mismatch.
 3. If a referenced **library** pins the conflicting UIAutomationNext version, rebuild/republish that library against the aligned version first, then update the consuming project to it.
 4. Reopen / revalidate the workflow. `MissingMethodException` clears once the loaded UIAutomationNext assembly exposes the member the caller expects.
 
-> Do NOT clean the NuGet cache or republish for Signature A — the assembly loaded fine; the versions disagree. Cache work does not change which versions `project.json` resolves.
+> Do NOT clean the NuGet cache to fix Signature A — the assembly loaded fine; the versions disagree, and cache work does not change which versions `project.json` resolves. Republishing is likewise pointless for A2 (nothing about the robot's environment is wrong) but **is** required for A1, so the robot restores the newly pinned version.
 
 ### Signature B — make the runtime resolve the pinned version (cache + feed + republish)
 
@@ -58,7 +79,7 @@ The fix is on the robot's package resolution, not in the activity properties.
 3. **Republish with deterministic resolution:** set dependency resolution to **Lowest Applicable Version** (or **Strict**) and republish, so the resolved version is one the feed can serve rather than a floating range the robot cannot satisfy.
 4. Re-run on the robot. `Could not load file or assembly` clears once the pinned version is restorable in the robot's environment.
 
-> "Works in Studio, fails in Assistant" is Signature B by default — Studio restored the version locally; the robot could not. Fix the robot-side resolution, not the workflow.
+> "Works in Studio, fails in Assistant" with a **load failure** is Signature B — Studio restored the version locally; the robot could not. Fix the robot-side resolution, not the workflow. The same environment tell with a `MissingMethodException` is Signature A1 instead: there the assembly loaded, so the fix is version alignment across environments, not cache/feed repair.
 
 ## Not this playbook
 

package/skills/uipath-troubleshoot/references/activity-packages/ui-automation/playbooks/napplicationcard-view-generation-failed.md

@@ -59,6 +59,12 @@ What to look for:
 4. Confirm the `.xaml` itself is structurally intact (the `NApplicationCard` node is present and
    well-formed) — a rendering failure with valid source points at cache/version skew, not corrupt XAML.
 
+The three causes are **cumulative, not alternatives**. Finding one does not rule out the others, and a
+stale `obj/project.assets.json` is the easiest to spot — do not stop there. Run steps 2 and 3 in full
+every time and report every cause the evidence supports. In particular, always compare the package pin
+against `studioVersion` even after a stale project cache is already confirmed: a project-cache clear
+alone leaves a version skew in place and the view fails to regenerate on reopen.
+
 ## Resolution
 
 - **Version skew (most common):** align the automation activity package with the Studio version and
@@ -74,5 +80,9 @@ What to look for:
 - After clearing caches / aligning versions, reopen the workflow — the `NApplicationCard` view
   regenerates once Studio loads a consistent activity assembly.
 
+When the evidence shows both a version skew and a drifted cache, deliver both fixes together: align the
+package/Studio versions **and** clear `%LOCALAPPDATA%\UiPath\.cache` plus the project's
+`.local`/`bin`/`obj`. Either one on its own leaves the card unrenderable.
+
 Do not attempt to fix this by editing the `.xaml` by hand — the source is intact; the fault is in the
 Studio-side view factory / cache, and hand-edits risk corrupting a valid file.

package/skills/uipath-troubleshoot/references/activity-packages/ui-automation/playbooks/scope-container-wrong-page.md

@@ -13,7 +13,7 @@ What this looks like:
 - The runtime "closest matches" in the exception belong to a completely different page, locale, or site than the inner selector expects.
 - The scope container has a permissive attach configuration that allows reuse of an unintended existing window/tab.
 
-**Silent variant (no exception).** For the general silent-no-op family (input-method/target-tech mismatch such as `Simulate`/`SendWindowMessages` on Java/SAP, overlay intercept, wrong/duplicate element, lost focus, DOM race), the dedicated home is [click-silent-no-op.md](./click-silent-no-op.md); use THIS playbook when the specific miss cause is a wrong-page scope attach. The wrong-page attach can also produce **no fault at all**: the inner activity runs against the wrong page, its target never matches, yet the job ends `Successful` and the action never happened. This is the "the job succeeded but the button was never clicked" report. It occurs when the miss cannot surface as an exception — e.g. `Simulate` input plus an **absent or target-less Verify Execution** (a `VerifyOptions` with a Mode set but no verification target is inert — "nothing to check" — so the no-op passes silently). There is no exception and no "closest matches" to read; diagnose from source — the scope shape plus the inner activity's Verify Execution config — not from logs. On a silent run the **inert Verify is the confirmed cause of the silent success** (and, when HA was enabled, of why HA never engaged); the **wrong-page attach is only the *likely, unproven* miss cause** — with no exception/closest-matches there is no runtime evidence of which page attached, so do NOT report the scope as a confirmed root cause.
+**Silent variant (no exception).** For the general silent-no-op family (a control that does not act on the API-level `Simulate`/`SendWindowMessages` event, overlay intercept, wrong/duplicate element, lost focus, DOM race), the dedicated home is [click-silent-no-op.md](./click-silent-no-op.md); use THIS playbook when the specific miss cause is a wrong-page scope attach. The wrong-page attach can also produce **no fault at all**: the inner activity runs against the wrong page, its target never matches, yet the job ends `Successful` and the action never happened. This is the "the job succeeded but the button was never clicked" report. It occurs when the miss cannot surface as an exception — e.g. `Simulate` input plus an **absent or target-less Verify Execution** (a `VerifyOptions` with a Mode set but no verification target is inert — "nothing to check" — so the no-op passes silently). There is no exception and no "closest matches" to read; diagnose from source — the scope shape plus the inner activity's Verify Execution config — not from logs. On a silent run the **inert Verify is the confirmed cause of the silent success** (and, when HA was enabled, of why HA never engaged); the **wrong-page attach is only the *likely, unproven* miss cause** — with no exception/closest-matches there is no runtime evidence of which page attached, so do NOT report the scope as a confirmed root cause.
 
 What can cause it:
 - `AttachMode=ByInstance` + default `OpenMode=IfNotOpen`: the container reuses any existing window of the configured app instead of opening the intended URL.