@uipath/skills 1.195.1 → 1.196.0

package/skills/uipath-solution/references/{operate/develop-solution.md → develop-solution.md}

@@ -12,7 +12,7 @@ Create a solution, add automation projects, and sync resource declarations.
 
 ## Prerequisites
 
-- Authenticated (`uip login`) -- required for remote resource lookup during `resource refresh` and for `upload`
+- Authenticated — verify with `uip login status` (required for remote resource lookup during `resource refresh` and for `upload`); if not logged in, ask the user to run `uip login` (interactive browser flow)
 - Projects to add must contain `project.uiproj` or `project.json`
 
 ## Flow
@@ -101,12 +101,12 @@ Show resources declared in the solution, available in Orchestrator, or both. Pas
 
 ```bash
 # from inside the solution dir
-uip solution resource list --kind Queue --output json
-uip solution resource list --kind Process --source local --output json
-uip solution resource list --kind Queue --search "Invoice" --output json
+uip solution resources list --kind Queue --output json
+uip solution resources list --kind Process --source local --output json
+uip solution resources list --kind Queue --search "Invoice" --output json
 
 # explicit folder
-uip solution resource list --kind App --solution-folder ./InvoiceAutomation --output json
+uip solution resources list --kind App --solution-folder ./InvoiceAutomation --output json
 ```
 
 | Option | Values | Default |
@@ -123,10 +123,10 @@ Re-scan all projects and sync resource declarations from their `bindings_v2.json
 
 ```bash
 # from inside the solution dir
-uip solution resource refresh --output json
+uip solution resources refresh --output json
 
 # explicit folder
-uip solution resource refresh --solution-folder ./InvoiceAutomation --output json
+uip solution resources refresh --solution-folder ./InvoiceAutomation --output json
 ```
 
 | Field | Meaning |
@@ -176,10 +176,10 @@ Fetch the full configuration (`spec`, `apiVersion`, `isOverridable`, `resourceOv
 
 ```bash
 # from inside the solution dir
-uip solution resource get <resource-key> --output json
+uip solution resources get <resource-key> --output json
 
 # explicit folder + transitive deps
-uip solution resource get <resource-key> --solution-folder ./InvoiceAutomation --include-dependencies --output json
+uip solution resources get <resource-key> --solution-folder ./InvoiceAutomation --include-dependencies --output json
 ```
 
 | Option | Purpose |
@@ -190,7 +190,7 @@ uip solution resource get <resource-key> --solution-folder ./InvoiceAutomation -
 
 ### How resolution works
 
-`get` accepts any key from `solution resource list` — local or remote — and dispatches accordingly:
+`get` accepts any key from `solution resources list` — local or remote — and dispatches accordingly:
 
 1. **Local first** — calls SDK `getConfigurationAsync(key)`, which reads `resources/solution_folder/**/<resource>.json` and returns the design-time spec (plus any debug overwrite). This is what's bundled at pack time. Output is a subset of the cloud spec — good enough for most planning work.
 2. **Fallback to RCS + FPS** — if the key isn't in the local solution, the CLI scans the resource catalog (`searchFolderEntities`) for it. On match, it builds a `ResourceReferenceModel` and calls the SDK's `IImportResourceHelper.exportResourceAsync` (the same workhorse `refresh` uses). The returned `ResourceDefinition` is mapped to the same `ResourceConfiguration` shape, so callers get a uniform output regardless of source.
@@ -210,7 +210,7 @@ The local file is what `refresh` (and `solution project add`) wrote to disk: a d
 
 If you need the full server spec for a resource that's already in the solution (e.g., for a deploy override), `--include-dependencies` paired with manual inspection of the dependency graph is one option; the cleaner path is to delete the local file and let `refresh` re-import it from the cloud.
 
-### Why `solution resource list` and `get` aren't symmetric
+### Why `solution resources list` and `get` aren't symmetric
 
 `list --source remote` returns entities from RCS that are **visible to your user** — including ones not bound to this solution. `get` is solution-context-aware: it considers anything in your `.uipx`'s solution_folder as "local", and falls back to RCS for everything else. A key shown by `list --source remote` that isn't bound to the solution will resolve via the FPS fallback.
 
@@ -225,16 +225,16 @@ Add a single resource to the solution without touching `bindings_v2.json` or re-
 
 ```bash
 # Create a local virtual queue (no auth required)
-uip solution resource add --source local --kind Queue --name InvoiceQueue --output json
+uip solution resources add --source local --kind Queue --name InvoiceQueue --output json
 
 # Local asset with explicit subtype
-uip solution resource add --source local --kind Asset --name ApiKey --type Text --output json
+uip solution resources add --source local --kind Asset --name ApiKey --type Text --output json
 
 # Import an existing remote queue (folder disambiguates same-name resources)
-uip solution resource add --source remote --kind Queue --name InvoiceQueue --folder-path Sales/CRM --output json
+uip solution resources add --source remote --kind Queue --name InvoiceQueue --folder-path Sales/CRM --output json
 
 # Skip RCS lookup if you already know the cloud key
-uip solution resource add --source remote --kind Queue --name InvoiceQueue \
+uip solution resources add --source remote --kind Queue --name InvoiceQueue \
     --cloud-key 8f3a1b2c-1234-4abc-9def-0123456789ab --output json
 ```
 
@@ -298,10 +298,10 @@ Resolve by re-running with `--folder-path <one-of-the-candidates>` or `--cloud-k
 Delete a single resource from the solution by key. Purely local: no auth round-trip, no `bindings_v2.json` mutation.
 
 ```bash
-uip solution resource remove 8f3a1b2c-1234-4abc-9def-0123456789ab --output json
+uip solution resources remove 8f3a1b2c-1234-4abc-9def-0123456789ab --output json
 
 # explicit folder
-uip solution resource remove 8f3a1b2c-... --solution-folder ./InvoiceAutomation --output json
+uip solution resources remove 8f3a1b2c-... --solution-folder ./InvoiceAutomation --output json
 ```
 
 `<resource-key>` is positional and required, validated as a GUID. Use `resource list --source local` to discover keys.
@@ -335,13 +335,13 @@ Change a resource's `spec` properties by key. This is the only command that muta
 
 ```bash
 # Patch a single spec property
-uip solution resource edit <resource-key> --patch '{"maxNumberOfRetries":5}' --output json
+uip solution resources edit <resource-key> --patch '{"maxNumberOfRetries":5}' --output json
 
 # Patch several properties from a JSON object
-uip solution resource edit <resource-key> --patch '{"acceptAutomaticallyRetry":false,"retentionPeriod":14}' --output json
+uip solution resources edit <resource-key> --patch '{"acceptAutomaticallyRetry":false,"retentionPeriod":14}' --output json
 
 # Read the patch from stdin (pipeline-friendly)
-echo '{"slaInHours":"4"}' | uip solution resource edit <resource-key> --patch - --output json
+echo '{"slaInHours":"4"}' | uip solution resources edit <resource-key> --patch - --output json
 ```
 
 | Option | Values | Default |
@@ -387,7 +387,7 @@ Upload the solution for browser-based editing. Accepts a directory, `.uipx` file
 uip solution upload ./InvoiceAutomation --output json
 ```
 
-If the `SolutionId` in `.uipx` matches an existing Studio Web solution, the upload overwrites it.
+If the `SolutionId` in `.uipx` matches an existing Studio Web solution, the upload is **refused** unless `--force` is passed. Forcing replaces the cloud project in place and wipes its Studio Web version history. On a freshly `solution init`-ed project (or any `.uipx` whose `SolutionId` does not yet exist in the cloud) the upload imports as new with no flag. See [`upload` refuses to overwrite without `--force`](#upload-refuses-to-overwrite-without---force) for the recovery path.
 
 > A project's target framework (platform) is fixed at creation and **cannot be mutated** — re-uploading or editing configuration will not change it. To target a different platform (e.g., Windows → Cross-platform), **recreate the project** with the correct target framework and upload that.
 
@@ -419,14 +419,14 @@ uip solution project add ./InvoiceAutomation/Reporter --output json
 cd ./InvoiceAutomation
 
 # 4. Sync resource declarations from project bindings
-uip solution resource refresh --output json
+uip solution resources refresh --output json
 
 # 5. Verify resources are tracked (per kind)
-uip solution resource list --kind Process --source local --output json
-uip solution resource list --kind Queue --source local --output json
+uip solution resources list --kind Process --source local --output json
+uip solution resources list --kind Queue --source local --output json
 
 # 6. Inspect one resource's full configuration (local + RCS fallback)
-uip solution resource get <resource-key> --output json
+uip solution resources get <resource-key> --output json
 ```
 
 ---
@@ -453,7 +453,7 @@ ls -1 ./MySolution/resources/solution_folder/process/
 Steps 1–3 verify *project* mutations (`project add`/`remove`, `refresh`). For *resource* mutations (`resource add`/`remove`) the relevant files live under other `resources/solution_folder/<kind>/` subtrees (`queue/`, `asset/`, `bucket/`, …), so verify at the resource level instead:
 
 ```bash
-uip solution resource list --source local --output json
+uip solution resources list --source local --output json
 ```
 
 If `.uipx` and `resources/solution_folder/` disagree, follow the recovery procedure in the matching gotcha below.
@@ -463,7 +463,7 @@ If `.uipx` and `resources/solution_folder/` disagree, follow the recovery proced
 | File | Created by | Read by |
 |---|---|---|
 | `bindings.json` | `uipath init` (coded agent) | the agent at runtime |
-| `bindings_v2.json` | `uip maestro flow new`, Maestro Case scaffold, Studio Web (mirrors agent bindings up to solution root) | `uip solution resource refresh` |
+| `bindings_v2.json` | `uip maestro flow new`, Maestro Case scaffold, Studio Web (mirrors agent bindings up to solution root) | `uip solution resources refresh` |
 
 Copying `bindings.json` → `bindings_v2.json` does **not** work — the schemas differ, and `resource refresh` will silently fail (see "false success" gotcha above). Naive hand-authoring or copy-paste from `bindings.json` produces the opaque error `TypeError: Cannot read properties of undefined (reading 'toLowerCase')`. When a project's tooling already manages `bindings_v2.json` (Flow / Case / agent solutions), edit through that product's commands rather than the file directly, then run `resource refresh` to reconcile.
 
@@ -516,9 +516,15 @@ Refresh reads both. Don't hand-edit these — they're regenerated whenever Studi
 
 `userProfile/<userId>/debug_overwrites.json` is per-user state (the `userId` is your UiPath user GUID). Refresh writes only your own entries; another user opening the bundled solution would have separate entries. The bundle (`.uis`) carries `userProfile/` for everyone who ran refresh; Studio Web picks the active user's at runtime.
 
-### `upload` overwrites on matching SolutionId
+### `upload` refuses to overwrite without `--force`
 
-The `SolutionId` in `.uipx` determines identity. If a Studio Web solution with the same ID exists, `upload` replaces it. To upload as a new solution, change the `SolutionId`.
+The `SolutionId` in `.uipx` determines identity. Before uploading, the CLI probes Studio Web for that id:
+
+- **Cloud has no solution with that id** → imports as new (no flag needed). This is the freshly `solution init`-ed flow.
+- **Cloud already has that id, no `--force`** → upload is refused with exit code 1 and no `.uipx` mutation. Refusing is the safe default — overwriting destroys the cloud project's Studio Web version history.
+- **`--force` passed** → skips the probe and goes straight through the overwrite path (with the SDK's 404 → import fallback for stale ids).
+
+To upload as an unrelated new cloud solution rather than overwriting, scaffold a fresh solution with `uip solution init` or remove the `SolutionId` from the local `.uipx` before re-running `upload`.
 
 ### `delete` uses the solution UUID, not the name
 
@@ -530,7 +536,7 @@ When `[solutionFile]` is omitted, the CLI walks up from the project path looking
 
 ### `--solution-folder` defaults to cwd
 
-`resource list / refresh / get / add / remove / edit` default `--solution-folder` to the current working directory. Run them from inside the solution dir for the shortest invocation (`uip solution resource list`) or pass `--solution-folder <path>` explicitly.
+`resource list / refresh / get / add / remove / edit` default `--solution-folder` to the current working directory. Run them from inside the solution dir for the shortest invocation (`uip solution resources list`) or pass `--solution-folder <path>` explicitly.
 
 ### `add` / `remove` / `edit` / `refresh` require a `.uipx` manifest in the target folder
 
@@ -538,7 +544,7 @@ Unlike `resource get` and `list` (which fall back to RCS when local state is mis
 
 ### `resource get` for cross-folder inspection
 
-Because `get` falls back to RCS + FPS export when the key isn't local, it works as a quick way to fetch the full server spec for any resource your tenant exposes — even ones that aren't yet bound to this solution. Pair with `solution resource list --kind <kind> --source remote` to discover keys.
+Because `get` falls back to RCS + FPS export when the key isn't local, it works as a quick way to fetch the full server spec for any resource your tenant exposes — even ones that aren't yet bound to this solution. Pair with `solution resources list --kind <kind> --source remote` to discover keys.
 
 ---
 
@@ -550,12 +556,12 @@ Because `get` falls back to RCS + FPS export when the key isn't local, it works
 | Add a project already in the solution dir | `uip solution project add ./<dir>` | Transactional — `.uipx` and `resources/solution_folder/{package,process}/` agree on success |
 | Pull in an external project | `uip solution project import --source <path>` | Rename source folder first to avoid 3-name divergence |
 | Remove a project | `uip solution project remove ./<dir>` | Manually delete `resources/.../package/<name>.json` afterwards |
-| Sync resource bindings | `uip solution resource refresh --solution-folder <solution-dir>` | **Check stderr for ERROR**; `Result: Success` with 0/0/0 counts is suspicious if `bindings_v2.json` exists |
-| Add a virtual queue / asset / bucket | `uip solution resource add --source local --kind <kind> --name <name>` | Offline-friendly; idempotent (re-run returns `Status: "Unchanged"`) |
-| Import an existing remote resource | `uip solution resource add --source remote --kind <kind> --name <name> --folder-path <folder>` | On ambiguous match, the error lists every candidate with its key — pick one and re-call |
-| Remove a single resource | `uip solution resource remove <resource-key>` | Purely local — no auth; doesn't touch `bindings_v2.json`, next `refresh` re-imports if a binding still references it |
-| Edit a resource's spec | `uip solution resource edit <resource-key> --patch '{...}'` | Only command that mutates an existing resource; unknown/reference/read-only props are silently ignored. JSON is the only input — types preserved verbatim |
-| List resources | `uip solution resource list --solution-folder <solution-dir> --source local` | Good sanity check after any mutation; add `--kind <kind>` to narrow to one resource kind |
+| Sync resource bindings | `uip solution resources refresh --solution-folder <solution-dir>` | **Check stderr for ERROR**; `Result: Success` with 0/0/0 counts is suspicious if `bindings_v2.json` exists |
+| Add a virtual queue / asset / bucket | `uip solution resources add --source local --kind <kind> --name <name>` | Offline-friendly; idempotent (re-run returns `Status: "Unchanged"`) |
+| Import an existing remote resource | `uip solution resources add --source remote --kind <kind> --name <name> --folder-path <folder>` | On ambiguous match, the error lists every candidate with its key — pick one and re-call |
+| Remove a single resource | `uip solution resources remove <resource-key>` | Purely local — no auth; doesn't touch `bindings_v2.json`, next `refresh` re-imports if a binding still references it |
+| Edit a resource's spec | `uip solution resources edit <resource-key> --patch '{...}'` | Only command that mutates an existing resource; unknown/reference/read-only props are silently ignored. JSON is the only input — types preserved verbatim |
+| List resources | `uip solution resources list --solution-folder <solution-dir> --source local` | Good sanity check after any mutation; add `--kind <kind>` to narrow to one resource kind |
 | Pack | `uip solution pack <solution-dir> <output-dir>` | See [pack-and-deploy.md](pack-and-deploy.md) for full pack/publish/deploy flow |
 
 ---

package/skills/uipath-solution/references/{operate/pack-and-deploy.md → pack-and-deploy.md}

@@ -12,7 +12,7 @@ Pack a solution into a deployable package, publish to the feed, and deploy to Or
 
 ## Prerequisites
 
-- Authenticated (`uip login`)
+- Authenticated — verify with `uip login status`; if not logged in, ask the user to run `uip login` (it opens an interactive browser flow)
 - Solution developed and ready to pack (see [develop-solution.md](develop-solution.md))
 - Solution state verified — `.uipx` and `resources/solution_folder/` agree on the project set (see [develop-solution.md - Always verify state after every mutation](develop-solution.md#always-verify-state-after-every-mutation))
 
@@ -50,7 +50,7 @@ uip solution pack ./MySolution ./output --name "MySolution" --version "2.0.0" --
 | `--name <name>` | Override the package name | Name from `.uipx` |
 | `--version <version>` | Set the package version | `1.0.0` |
 
-The output is a `.zip` file named `<name>.<version>.zip` written under `<output-path>/` (e.g., `MySolution.2.0.0.zip`). Run `solution resource 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` 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.
 
 ## Step 2: Publish to the Solution Feed
 
@@ -73,7 +73,7 @@ If the goal is browser-based editing rather than deployment, use `upload` instea
 uip solution upload ./MySolution --output json
 ```
 
-This uploads to Studio Web for collaborative editing. It does **not** place the package on the solution feed and cannot be used with `deploy run`.
+This uploads to Studio Web for collaborative editing. It does **not** place the package on the solution feed and cannot be used with `deploy run`. If the `SolutionId` in `.uipx` already exists in Studio Web, `upload` refuses unless `--force` is passed (forcing replaces the cloud project in place and wipes its Studio Web version history).
 
 `upload` always lands the solution in Studio Web's **Cloud workspace** tab, not the Local tab. SW's Local tab is a separate registration for solutions whose source of truth is a tracked local folder — populated by SW-initiated flows (creating a solution from the SW UI, or downloading a cloud solution to local) or by Studio Desktop signing into the same tenant. `uip solution upload` does not address the Local tab. Authoring with `uip solution new` then `upload` produces a Cloud-tab solution; the local folder on disk has no live link to either tab afterward — edits in one place do not propagate to the other without a re-upload (Cloud) or a download (Local).
 

package/skills/uipath-solution/references/{operate/scenarios → scenarios}/intra-solution-references.md

@@ -20,7 +20,7 @@ MySolution/
     └── process/agent/Worker.json         (auto on add)
 ```
 
-The right `referenceKey` for the Worker tool is the **solution-resource key** of `Worker.json` (read from `uip solution resource list --kind Process --source local --output json`), **not** the `projectId` from `.uipx`.
+The right `referenceKey` for the Worker tool is the **solution-resource key** of `Worker.json` (read from `uip solution resources list --kind Process --source local --output json`), **not** the `projectId` from `.uipx`.
 
 ```jsonc
 // Coordinator/resources/WorkerTool/resource.json
@@ -53,7 +53,7 @@ The right `referenceKey` for the Worker tool is the **solution-resource key** of
 ## Verify
 
 ```bash
-uip solution resource list --kind Process --source local --output json
+uip solution resources list --kind Process --source local --output json
 ```
 
 The keys you see here are what `referenceKey` should be in any `location: "solution"` tool resource file.

package/skills/uipath-solution/references/{operate/scenarios → scenarios}/manual-edits.md

@@ -1,8 +1,8 @@
 # Manual edits when the CLI doesn't cover the case
 
-The CLI now covers the full resource CRUD: **create** ([Step 9: `solution resource add`](../develop-solution.md#step-9-add-a-resource-atomically)), **delete** ([Step 10: `solution resource remove`](../develop-solution.md#step-10-remove-a-resource)), and **update** ([Step 11: `solution resource edit`](../develop-solution.md#step-11-edit-a-resource)). `edit` patches an existing resource's `spec` through the SDK — it even renames (with duplicate protection), so the old "rename is Studio-Web-only" rule no longer holds.
+The CLI now covers the full resource CRUD: **create** ([Step 9: `solution resources add`](../develop-solution.md#step-9-add-a-resource-atomically)), **delete** ([Step 10: `solution resources remove`](../develop-solution.md#step-10-remove-a-resource)), and **update** ([Step 11: `solution resources edit`](../develop-solution.md#step-11-edit-a-resource)). `edit` patches an existing resource's `spec` through the SDK — it even renames (with duplicate protection), so the old "rename is Studio-Web-only" rule no longer holds.
 
-**Reach for `solution resource edit` first** for any spec-field change. The SDK validates against kind metadata: it silently skips unknown / reference / read-only properties, and identity fields (`key`, `kind`, `type`, `apiVersion`, `dependencies`, `folders`) live outside `spec` so `edit` can't touch them at all.
+**Reach for `solution resources edit` first** for any spec-field change. The SDK validates against kind metadata: it silently skips unknown / reference / read-only properties, and identity fields (`key`, `kind`, `type`, `apiVersion`, `dependencies`, `folders`) live outside `spec` so `edit` can't touch them at all.
 
 This page is now the **last resort** — for the narrow cases `edit` *won't* cover:
 
@@ -10,7 +10,7 @@ This page is now the **last resort** — for the narrow cases `edit` *won't* cov
 2. **`solution deploy config set` / `link` / `unlink`** — for changes that only need to apply at deploy time (per-environment values, link state). Touches only the deploy config file, not the solution-level resources.
 3. **Hand-edit the JSON directly** — the escape hatch when none of the above fit. Works, but **not ideal** — no validation, the SDK can silently undo your change on the next refresh if it conflicts with what bindings re-derive, and structural mistakes corrupt the solution. Use only when you understand which fields the SDK leaves alone.
 
-This page covers (3) — what's safe to hand-edit and what's not. For everyday spec changes prefer `solution resource edit`; for creating or deleting a whole resource, `solution resource add` / `remove`.
+This page covers (3) — what's safe to hand-edit and what's not. For everyday spec changes prefer `solution resources edit`; for creating or deleting a whole resource, `solution resources add` / `remove`.
 
 ## What the SDK actually compares
 
@@ -86,7 +86,7 @@ Open the file. The shape is roughly:
 After any solution-level edit, run a sanity check:
 
 ```bash
-uip solution resource list --kind <kind> --solution-folder . --source local --output json
+uip solution resources list --kind <kind> --solution-folder . --source local --output json
 ```
 
 The list should show your resource with the new spec. If `resource refresh` reverts the change on the next run, you edited a field the bindings re-derive — back out and use the deploy-config path or SW UI instead.

package/skills/uipath-solution/references/{operate/scenarios → scenarios}/same-name-across-folders.md

@@ -24,7 +24,7 @@ Two bindings in the agent's `bindings_v2.json`, same `value.name.defaultValue`,
 
 Each tool's `resource.json` carries the cloud key in `referenceKey` and the cloud FQN in `properties.folderPath`.
 
-## What happens at `solution resource refresh`
+## What happens at `solution resources refresh`
 
 ```
 Synced 2 resources (0 already in solution)
@@ -49,7 +49,7 @@ The `_1` suffix is **expected and stable** — re-running refresh does not bump
 ## Verify
 
 ```bash
-uip solution resource list --kind Process --solution-folder ./MySolution --source local --output json
+uip solution resources list --kind Process --solution-folder ./MySolution --source local --output json
 ```
 
 You should see two `process`/`api` entries with **different keys** but matching the cloud GUIDs you wanted (compare against `uip maestro flow registry search "API Workflow"`).

package/skills/uipath-solution/references/{operate/scenarios → scenarios}/shared-cloud-resource.md

@@ -26,16 +26,16 @@ Synced 1 resources (0 already in solution)
 ## Gotchas
 
 - **The skip is idempotent across refreshes** for cloud-imported resources. If you ever see two `OrdersQueue.json` entries (without distinct cloud keys), something else is wrong — most likely a binding's `folderPath` placeholder differs (`solution_folder` vs `Shared/Production`) and the second binding falls through the [virtual-creation path](virtual-resource.md) instead of the import path.
-- **Refresh does NOT update the resource's local config** if the cloud-side definition changed (e.g. queue retry count edited in OR after import). Refresh is import-only by design; mutations are reserved for explicit local edits via SW UI or a future `solution resource update` CLI command.
+- **Refresh does NOT update the resource's local config** if the cloud-side definition changed (e.g. queue retry count edited in OR after import). Refresh is import-only by design; mutations are reserved for explicit local edits via SW UI or a future `solution resources update` CLI command.
 - **At deploy, both projects' runtime dependencies point at the same `resourceKey`.** This is correct — they share the cloud resource. The deploy folder gets one queue (or one link to an existing one if you've used `deploy config link`).
 - **At publish/upload time you cannot have two solution-level entries with the same cloud key.** If you accidentally produce that state by hand-editing files, `pack` rejects with a duplicate-key error.
 
 ## Verify
 
 ```bash
-uip solution resource list --source local --kind Queue --output json | jq '.Data[] | select(.Name == "OrdersQueue")'
+uip solution resources list --source local --kind Queue --output json | jq '.Data[] | select(.Name == "OrdersQueue")'
 ```
 
-Exactly one entry, with a key that matches the cloud GUID returned by `uip resource queue get OrdersQueue --folder-path "Shared/Production"`.
+Exactly one entry, with a key that matches the cloud GUID (the `Key` field) returned by `uip or queues list --folder-path "Shared/Production" --name OrdersQueue`.
 
 > See: [develop-solution.md — Step 7: Refresh Resources](../develop-solution.md#step-7-refresh-resources).

package/skills/uipath-solution/references/{operate/scenarios → scenarios}/virtual-resource.md

@@ -4,8 +4,8 @@ You're shipping a **brand-new** asset (or queue, or bucket) as part of the solut
 
 There are two paths to create a virtual resource:
 
-- **From a binding** — write the resource into `bindings_v2.json` (typically via the owning product: Maestro Flow / Case, Studio Web, agent scaffold), then `solution resource refresh` reconciles it into a virtual stub. The flow this page covers.
-- **Atomically, no binding** — `uip solution resource add --source local --kind <kind> --name <name>` (see [develop-solution.md Step 9](../develop-solution.md#step-9-add-a-resource-atomically)). Useful when no project consumes the resource yet (CI provisioning ahead of code), or when an agent is mutating one resource at a time and doesn't want to touch any binding file. Same end state on disk; same deploy behavior. Offline-friendly (no auth round-trip).
+- **From a binding** — write the resource into `bindings_v2.json` (typically via the owning product: Maestro Flow / Case, Studio Web, agent scaffold), then `solution resources refresh` reconciles it into a virtual stub. The flow this page covers.
+- **Atomically, no binding** — `uip solution resources add --source local --kind <kind> --name <name>` (see [develop-solution.md Step 9](../develop-solution.md#step-9-add-a-resource-atomically)). Useful when no project consumes the resource yet (CI provisioning ahead of code), or when an agent is mutating one resource at a time and doesn't want to touch any binding file. Same end state on disk; same deploy behavior. Offline-friendly (no auth round-trip).
 
 ## Setup
 
@@ -36,7 +36,7 @@ The stub has `value: ""` (or the type's placeholder default — `false` for bool
 
 ## Idempotency on re-refresh
 
-Re-running `solution resource refresh` is a no-op for virtuals at the same `(kind, folder, name)` — the second pass detects the existing stub and skips:
+Re-running `solution resources refresh` is a no-op for virtuals at the same `(kind, folder, name)` — the second pass detects the existing stub and skips:
 
 ```
 Synced 0 resources (1 already in solution)
@@ -79,7 +79,7 @@ uip solution deploy run -n MyDeployment --package-name MySolution --package-vers
 
 ```bash
 # Virtual exists locally
-uip solution resource list --source local --kind Asset --output json
+uip solution resources list --source local --kind Asset --output json
 
 # Deploy config has the resource and its `configuration.value`
 uip solution deploy config get MySolution -d deploy-config.json --output json

package/skills/uipath-solution/references/{operate/scenarios.md → scenarios.md}

@@ -1,6 +1,6 @@
 # Solution Scenarios
 
-Real multi-project recipes that the step-by-step files don't cover head-on. Each scenario has the setup, the behavior to expect, the gotcha that bites, and a fix. Read these before starting on a complex solution — most of them surface during `solution resource refresh` or `solution deploy run`.
+Real multi-project recipes that the step-by-step files don't cover head-on. Each scenario has the setup, the behavior to expect, the gotcha that bites, and a fix. Read these before starting on a complex solution — most of them surface during `solution resources refresh` or `solution deploy run`.
 
 > All scenarios assume you've already read [develop-solution.md](develop-solution.md) and [pack-and-deploy.md](pack-and-deploy.md). Each file links back to the relevant step.
 
@@ -19,10 +19,10 @@ Land here from a grep on an error message? Pick the matching row.
 | `[1009] <kind> <name>: Invalid argument 'Value'` at deploy | [virtual-resource](scenarios/virtual-resource.md) |
 | New asset/queue not on cloud — how do I ship it as part of the solution? | [virtual-resource](scenarios/virtual-resource.md) |
 | `Synced 0 resources (1 already in solution)` on re-refresh | [virtual-resource](scenarios/virtual-resource.md) (idempotency section) |
-| I want to add one virtual queue / asset / bucket without going through bindings | `uip solution resource add --source local --kind <kind> --name <name>` — see [develop-solution.md Step 9](develop-solution.md#step-9-add-a-resource-atomically) |
-| I want to import one existing remote resource into the solution | `uip solution resource add --source remote --kind <kind> --name <name> --folder-path <folder>` — see [develop-solution.md Step 9](develop-solution.md#step-9-add-a-resource-atomically) |
-| I want to delete a single resource by key | `uip solution resource remove <resource-key>` — see [develop-solution.md Step 10](develop-solution.md#step-10-remove-a-resource) |
-| I want to change a field on an existing resource's spec | `uip solution resource edit <resource-key> --patch '{...}'` — see [develop-solution.md Step 11](develop-solution.md#step-11-edit-a-resource) |
+| I want to add one virtual queue / asset / bucket without going through bindings | `uip solution resources add --source local --kind <kind> --name <name>` — see [develop-solution.md Step 9](develop-solution.md#step-9-add-a-resource-atomically) |
+| I want to import one existing remote resource into the solution | `uip solution resources add --source remote --kind <kind> --name <name> --folder-path <folder>` — see [develop-solution.md Step 9](develop-solution.md#step-9-add-a-resource-atomically) |
+| I want to delete a single resource by key | `uip solution resources remove <resource-key>` — see [develop-solution.md Step 10](develop-solution.md#step-10-remove-a-resource) |
+| I want to change a field on an existing resource's spec | `uip solution resources edit <resource-key> --patch '{...}'` — see [develop-solution.md Step 11](develop-solution.md#step-11-edit-a-resource) |
 | I edited a spec field but `refresh` didn't pick it up | Expected — `refresh` never overwrites a resource already in the solution. Use `resource edit` to mutate spec. |
 | `resource edit` silently ignored a property I passed | The SDK skips unknown / reference / read-only props by design — see [manual-edits](scenarios/manual-edits.md) for what's editable vs not |
 | My hand-edit got reverted on the next refresh | [manual-edits](scenarios/manual-edits.md) (the SDK re-derives bindings) |

package/skills/uipath-solution/references/{operate/solution-overview.md → solution-overview.md}

@@ -70,7 +70,7 @@ Always run `resource refresh` before either path so the bundled artefact files a
 ```
 uip solution
   ├── init <name>                         Create a new solution directory with .uipx manifest
-  │                                        (pre-rename CLIs expose this as `new`; see SKILL.md Operate-half "CLI Surface Probe")
+  │                                        (pre-rename CLIs expose this as `new`; see SKILL.md "CLI Surface Probe")
   ├── delete <solution-id>                Delete a solution from Studio Web
   ├── upload <path>                       Upload solution to Studio Web
   ├── pack <solution> <output>            Pack into a deployable .zip package
@@ -121,5 +121,5 @@ Each workflow doc covers a multi-command choreography for a specific goal. Load
 
 ## Related
 
-- **Orchestrator** (`uip or`) — folders, processes, jobs, machines → [`uipath-orchestrator`](../orchestrator/orchestrator.md)
-- **Resources** (`uip resource`) — assets, queues, buckets used by solutions → [`uipath-resources`](../resources/resources.md)
+- **Orchestrator** (`uip or`) — folders, processes, jobs, machines → [`uipath-platform`](../../uipath-platform/references/orchestrator/orchestrator.md)
+- **Resources** (`uip or assets` / `queues` / `buckets` / …) — resources used by solutions → [`uipath-platform`](../../uipath-platform/references/orchestrator/resources.md)

package/skills/uipath-tasks/SKILL.md

@@ -7,8 +7,6 @@ user-invocable: true
 
 # UiPath Tasks (Action Center) — Agent Skill
 
-> **Preview** — skill is under active development; surface and behavior may change.
-
 Action Center is UiPath's human-in-the-loop platform. Tasks represent work items
 that require human input — form approvals, document validation, data labeling, and more.
 

package/skills/uipath-test/SKILL.md

@@ -7,8 +7,6 @@ user-invocable: true
 
 # UiPath Test Assistant
 
-> **Preview** — skill is under active development; surface and behavior may change.
-
 Manage UiPath Test Manager resources (projects, test cases, test sets, executions) and generate persona-tailored shareable test reports.
 
 ## When to Use This Skill
@@ -52,28 +50,49 @@ Common `uip tm` commands organized by resource type.
 
 > Get folder keys with `uip or folders list -n <name> --all --output json` — returns all folders visible to the current user.
 
+### Requirements Commands
+
+| Command | Purpose |
+|---|---|
+| `uip tm requirements list --project-key <PROJECT_KEY>` | List requirements in a Test Manager project. |
+| `uip tm requirements list-by-test-execution --project-key <PROJECT_KEY> --execution-id <uuid>` | List requirements covered by a test execution. |
+| `uip tm requirements get --project-key <PROJECT_KEY> (--requirement-id <uuid> \| --requirement-key <key>)` | Get a requirement by UUID or key (mutually exclusive). |
+| `uip tm requirements create --project-key <PROJECT_KEY> --name <name>` | Create a new requirement. |
+| `uip tm requirements update --project-key <PROJECT_KEY> --requirement-id <uuid>` | Update a requirement name or description (at least one of `--name` or `--description` required). |
+| `uip tm requirements delete --project-key <PROJECT_KEY> --requirement-ids <uuid...>` | Delete one or more requirements (variadic). |
+| `uip tm requirements export --project-key <PROJECT_KEY> --output-file <path>` | Export requirements to an .xlsx file. |
+| `uip tm requirements list-testcase-ids --project-key <PROJECT_KEY> --requirement-id <uuid>` | List the test case UUIDs assigned to a requirement. |
+| `uip tm requirements testcases --project-key <PROJECT_KEY> --requirement-id <uuid> (--add-testcase-ids <uuid...> \| --remove-testcase-ids <uuid...>)` | Attach or detach test cases on a requirement (mutually exclusive). |
+
 ### Test Cases Commands
 
 | 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 update --project-key <PROJECT_KEY> --test-case-key <TEST_CASE_KEY> --name <TEST_CASE_NAME>` | Update a test case name or description (at least one of `--name` or `--description` required). |
+| `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. |
 | `uip tm testcases unlink-automation --project-key <PROJECT_KEY> --test-case-key <TEST_CASE_KEY>` | Unlink the automation from a test case. |
 | `uip tm testcases list-automations --project-key <PROJECT_KEY> --folder-key <FOLDER_KEY>` | List test entry points available in an Orchestrator folder (optional: `--package-name <PACKAGE_NAME>` to filter). |
 | `uip tm testcases list-testsets --project-key <PROJECT_KEY> --test-case-key <TEST_CASE_KEY>` | List test sets that contain a given test case. |
-| `uip tm testcases list-steps --project-key <PROJECT_KEY> --test-case-id <TEST_CASE_ID>` | List test steps for a test case. **Uses `--test-case-id <UUID>`, not `--test-case-key`.** |
+| `uip tm testcases steps list --project-key <PROJECT_KEY> --test-case-id <TEST_CASE_ID>` | List manual test steps for a test case. **Uses `--test-case-id <UUID>`, not `--test-case-key`.** `uip tm testcases list-steps` is a supported alias. |
+| `uip tm testcases steps get --project-key <PROJECT_KEY> --step-id <UUID>` | Get a single test step by its UUID. |
+| `uip tm testcases steps add --project-key <PROJECT_KEY> --test-case-id <UUID> --description <text>` | Add a step using flags (`--description` required). |
+| `uip tm testcases steps add --project-key <PROJECT_KEY> --test-case-id <UUID> --step '<json>' [--step '<json>' ...]` | Add multiple steps by repeating `--step '<json>'`. Mutually exclusive with flag mode. **Not atomic** — earlier steps persist if a later one fails. |
+| `uip tm testcases steps update --project-key <PROJECT_KEY> --step-id <UUID>` | Update a step's fields. Only fields you pass change; the rest stay. |
+| `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 add --test-set-key <TEST_SET_KEY> --test-case-keys <KEY1,KEY2,...>` | Add test cases to a test set (comma-separated keys). |
 | `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). |
 
-> **Three flag shapes for test case identifiers — do not interchange:**
-> - `--test-case-id <UUID>` — used by `run`, `list-steps`, `list-result-history`. Get the UUID from `uip tm testcases list --output json` (`Id` field).
+> **Flag shapes for test case and step identifiers — do not interchange:**
+> - `--test-case-id <UUID>` — used by `run`, `steps list`, `steps add`, `list-result-history`. Get the UUID from `uip tm testcases list --output json` (`Id` field).
 > - `--test-case-key <PROJECT_KEY:NUMBER>` — singular, used by `update`, `delete`, `link-automation`, `unlink-automation`, `list-testsets`. Example: `DEMO:1`.
 > - `--test-case-keys <KEY1,KEY2,...>` — **plural**, comma-separated, used by `testcases add` and `testcases remove` for bulk membership changes on a test set.
+> - `--step-id <UUID>` — used by all `steps` subcommands except `list` and `add`. Get the UUID from `steps list` (`Id` field).
 
 ### Test Sets Commands
 
@@ -202,7 +221,7 @@ Object labels are tag-style metadata applied to Requirement, TestCase, TestSet,
 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.
-6. **Confirm before delete** — always confirm the target resource key with the user before running any `delete` command.
+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` (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`.

package/skills/uipath-troubleshoot/agents/triage.md

@@ -41,11 +41,13 @@ Goal: get the error message and match playbooks as fast as possible.
 
    a. **Does this investigation need source?** Read each matched playbook's `## Investigation` section. If it instructs reading XAML / `project.json` / activity arguments / variable bindings / expression text / compiled-expression mapping → source is required. If it only references CLI commands and platform-side fixtures → source is not required.
 
-   b. **Is source already known?** Check `state.json.requirements.source_code_path`. It is "known" if:
-      - The user's problem description named a directory or path (e.g., "the project at C:\…", "the source for X is in cwd", "this folder"), AND you recorded it during step 4 ("Resolve identity"), OR
-      - The current working directory contains a recognisable UiPath project (`project.json`, `agent.json`, or `caseplan.json` at the top level) and you record `source_code_path = "."` here with a note that you auto-discovered it.
+   b. **Is source already known? Actively check — do NOT rely on memory.** Before declaring source unknown, run BOTH of these in order:
+      1. **Check the user's message.** If the problem description named a directory or path (e.g., "the project at C:\…", "the source for X is in cwd", "this folder"), record it as `source_code_path` and continue. This already happens during step 4 ("Resolve identity"); confirm here.
+      2. **Auto-discover the current working directory.** Run `Glob` for `project.json`, `agent.json`, and `caseplan.json` at the cwd top level (NOT recursive — top level only, to avoid false positives from nested sample projects). If any of those files exist at depth 0 of cwd, record `source_code_path = "."` in `state.json.requirements` with a `source_code_path_origin = "auto-discovered-cwd"` field noting which marker file was found, and continue. Do NOT ask the user when the project is already mounted.
 
-   c. **If source is required AND not yet known → STOP and ask the user.** Write `needs_input.json` (see shared.md) requesting the project source path. The question must be specific:
+      Source is "known" only if step (1) or (2) above produced a path. If neither did, treat it as unknown and proceed to (c).
+
+   c. **If source is required AND not yet known (after BOTH active checks in (b) failed) → STOP and ask the user.** Write `needs_input.json` (see shared.md) requesting the project source path. The question must be specific:
       ```
       "To trace the originating cause for <error class / activity name>, I need to inspect the project source (XAML / project.json / .py). Could you share the project's directory path? If you are already in the project directory, just reply `pwd` or `.`."
       ```

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

@@ -0,0 +1,55 @@
+# Classic Activities
+
+The classic UiPath activities — the original (non-"modern", non-"Next") activities that appear in
+Studio under `UiPath.Core.Activities`. They split across two NuGet packages:
+
+- **UI Automation (classic)** — `UiPath.UIAutomation.Activities`. Selector- and image-based desktop
+  and browser automation: `Click`, `Type Into`, `Send Hotkey`, `Open Browser`, `Close Tab`,
+  `Open Application`, `Attach Browser` (Browser Scope), `Attach Window` (Window Scope),
+  `Take Screenshot`, `Wait Image Vanish`, `Wait UI Element Appear`.
+- **System / Core** — `UiPath.System.Activities`. Workflow, file, process, data, and Orchestrator
+  activities: `Invoke Workflow File`, `Invoke Code`, `Add Queue Item`, `Rename File`, `Move File`,
+  `Append Line`, `Log Message`, `Kill Process`, `Start Triggers`, `For Each Row`.
+
+> These are the **classic** activities. The modern UI Automation "Next" activities (`NClick`,
+> `Use Application/Browser`, healing agent) are covered by the **ui-automation** package, and the
+> modern Orchestrator-resource activities (`Get Asset`, `Get Credential`) by the
+> **system-activities** package. `Get Robot Asset` / `Get Robot Credential` failures are covered by
+> the existing **system-activities** `get-asset-*` playbooks — use those, this package does not
+> duplicate them.
+
+## Common Failure Families
+
+**UI Automation (classic):**
+- Target element not found within the timeout (`SelectorNotFoundException`) — selector drift, wrong
+  scope/window, application not open or not ready.
+- Activity timeout (`ActivityTimeoutException`, "Activity timeout exceeded") — element/state never
+  reached; `Wait UI Element Appear` element never appeared; `Wait Image Vanish` image never vanished.
+- Element found but the action failed (`ElementOperationException`) — disabled, occluded,
+  off-screen, or focus lost between find and act.
+- Browser could not be opened or attached (`BrowserOperationException`) — browser not installed,
+  extension missing, browser crashed, wrong browser type for the communication method.
+- Application could not be launched (`Open Application` / `Open Browser`) — file/path not found, bad
+  arguments, app never produced a window.
+- Design-time configuration / validation errors — mutually-exclusive options both set, conflicting
+  scope properties, communication-method incompatibilities.
+- Image automation reliability — `Wait Image Vanish` is sensitive to display scaling, resolution,
+  theme, and rendering differences between design and run time.
+
+**System / Core:**
+- File operations (`Rename File`, `Move File`, `Append Line`) — source not found, destination not a
+  folder, file already exists, path is a directory, access denied, file locked.
+- Workflow invocation (`Invoke Workflow File`, `Start Triggers`) — file not found, argument
+  name/type/direction mismatch, isolated/elevated/session validation, persistence not supported.
+- Code invocation (`Invoke Code`) — compilation failure, unsupported language, or exceptions thrown
+  by the user's own code at run time.
+- Queue operations (`Add Queue Item`) — empty queue name, invalid/duplicate item-information keys,
+  Orchestrator permission/HTTP/timeout errors, queue not found.
+- Process control (`Kill Process`) — process not found, access denied, errors across multiple
+  processes.
+- Data iteration (`For Each Row`) — null DataTable, invalid iterator variable name, or an exception
+  thrown by an activity inside the loop body.
+
+## Packages
+
+NuGet: `UiPath.UIAutomation.Activities`, `UiPath.System.Activities`