@uipath/skills 1.201.0-preview.621 → 1.202.0-preview.635

package/skills/uipath-solution/references/develop-solution.md

@@ -12,7 +12,7 @@ Create a solution, add automation projects, and sync resource declarations.
 
 ## Prerequisites
 
-- 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)
+- Authenticated — verify with `uip login status` (required for remote resource lookup during `resources 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
@@ -44,7 +44,7 @@ Creates `InvoiceAutomation/InvoiceAutomation.uipx`. All projects must live insid
 
 ## Step 2: Add Existing Projects
 
-> **Prerequisite for Coded Function and Coded Agent projects:** before running `uip solution projects add`, run `uip function init` (Coded Functions) or `uip codedagent init` (LangGraph/LlamaIndex/OpenAI Agents) inside the project directory to generate `entry-points.json`. Registration without it creates an incomplete solution entry.
+> **Prerequisite for Coded Function and Coded Agent projects:** before running `uip solution projects add`, run `uip function init` (Python Coded Functions) or `uip codedagent init` (LangGraph/LlamaIndex/OpenAI Agents) inside the project directory to generate `entry-points.json`. JS/TS Coded Functions have no `init` — their `uipath.json` functions map is the registration marker (`entry-points.json` is generated at pack). Registration without these creates an incomplete solution entry.
 
 Register a project that already lives inside the solution directory.
 
@@ -64,12 +64,12 @@ The `.uipx` is auto-discovered by walking up from the project path if not specif
 Copy a project from outside the solution tree into the solution directory and register it.
 
 ```bash
-uip solution projects import --source /path/to/ExternalProject --output json
+uip solution projects import /path/to/ExternalProject --output json
 ```
 
 Unlike `add`, `import` copies source files into the solution directory first, then registers the copy.
 
-> **Three names can diverge after `import`.** The destination folder name is the basename of `--source`. The `ProjectRelativePath` in `.uipx` matches the folder. The auto-generated package resource name is taken from the project metadata (e.g., `pyproject.toml [project].name` for Python coded agents) — which may differ from the folder. Rename the source directory to the intended project name **before** importing, or trace the relationship via the `projectKey` UUID inside the resource files.
+> **Three names can diverge after `import`.** The destination folder name is the basename of the source path. The `ProjectRelativePath` in `.uipx` matches the folder. The auto-generated package resource name is taken from the project metadata (e.g., `pyproject.toml [project].name` for Python coded agents) — which may differ from the folder. Rename the source directory to the intended project name **before** importing, or trace the relationship via the `projectKey` UUID inside the resource files.
 
 ## Step 4: Remove a Project
 
@@ -331,8 +331,8 @@ An *already-imported* key is not an error — the idempotency check runs first,
 
 | Mechanism | When to use | Behavior |
 |---|---|---|
-| `resource refresh` | A `bindings_v2.json` was edited (by Studio Web, Maestro Flow/Case scaffolds, `maestro flow new`) and you need to reconcile all projects | Scans every project's bindings, creates / imports for everything new, suffixes name collisions across folders |
-| `resource add` | One specific resource that's not driven by a binding (CI provisioning a queue, an agent that knows exactly what it wants to import) | Single resource, idempotent, no project scan |
+| `resources refresh` | A `bindings_v2.json` was edited (by Studio Web, Maestro Flow/Case scaffolds, `maestro flow new`) and you need to reconcile all projects | Scans every project's bindings, creates / imports for everything new, suffixes name collisions across folders |
+| `resources add` | One specific resource that's not driven by a binding (CI provisioning a queue, an agent that knows exactly what it wants to import) | Single resource, idempotent, no project scan |
 
 `add` does **not** mutate any `bindings_v2.json`. If a binding references this resource, you still need the binding file to be present — `add` just creates the solution-level artefact so deploy validation passes.
 
@@ -347,7 +347,7 @@ uip solution resources remove 8f3a1b2c-1234-4abc-9def-0123456789ab --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.
+`<resource-key>` is positional and required, validated as a GUID. Use `resources list --source local` to discover keys.
 
 | Option | Values | Default |
 |--------|--------|---------|
@@ -368,9 +368,9 @@ uip solution resources remove 8f3a1b2c-... --solution-folder ./InvoiceAutomation
 }
 ```
 
-If the key isn't in the local solution, the command exits with `Failure` and `Resource not found in solution` — there's no fallback to remote (unlike `resource get`). Use `resource list --source local` to confirm what's actually tracked.
+If the key isn't in the local solution, the command exits with `Failure` and `Resource not found in solution` — there's no fallback to remote (unlike `resources get`). Use `resources list --source local` to confirm what's actually tracked.
 
-> Removing a resource does **not** delete the binding in any `bindings_v2.json` that still references it. The next `resource refresh` will re-import it. To make a removal stick, either fix the binding through the owning product (Maestro Flow / Case, Studio Web, agent code) or remove the project from the solution first.
+> Removing a resource does **not** delete the binding in any `bindings_v2.json` that still references it. The next `resources refresh` will re-import it. To make a removal stick, either fix the binding through the owning product (Maestro Flow / Case, Studio Web, agent code) or remove the project from the solution first.
 
 ## Step 11: Edit a Resource
 
@@ -389,7 +389,7 @@ echo '{"slaInHours":"4"}' | uip solution resources edit <resource-key> --patch -
 
 | Option | Values | Default |
 |--------|--------|---------|
-| `<resource-key>` | Solution resource key (GUID, positional) — discover via `resource list --source local` | **required** |
+| `<resource-key>` | Solution resource key (GUID, positional) — discover via `resources list --source local` | **required** |
 | `--patch <json\|->` | JSON object of spec property → value; `-` reads the JSON from stdin | **required** |
 | `--solution-folder <path>` | Path to solution root (must directly contain a `.uipx`) | Current working directory |
 
@@ -420,7 +420,7 @@ echo '{"slaInHours":"4"}' | uip solution resources edit <resource-key> --patch -
 }
 ```
 
-`Data` is the SDK's `ResourceConfiguration` — the **same shape `resource get` returns**, so `get`↔`edit` round-trips cleanly: `resource get <key> --output json`, mutate the JSON, feed it back via `--patch`. If you need a before/after diff, run `get` first.
+`Data` is the SDK's `ResourceConfiguration` — the **same shape `resources get` returns**, so `get`↔`edit` round-trips cleanly: `resources get <key> --output json`, mutate the JSON, feed it back via `--patch`. If you need a before/after diff, run `get` first.
 
 ## Step 12: Upload to Studio Web
 
@@ -430,7 +430,13 @@ 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 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.
+The CLI probes Studio Web for the bundled `SolutionId` and picks the operation itself, so the same command serves the first upload and every one after it. `Data.Action` reports which ran — `"Imported"` or `"Overwritten"`. See [`upload` decides import or overwrite from what the cloud holds](#upload-decides-import-or-overwrite-from-what-the-cloud-holds) for the decision rules, snapshot recording, and failure modes.
+
+| Flag | Purpose | Default |
+|------|---------|---------|
+| `--no-snapshot` | Skip recording the restorable pre-overwrite version. Overwrite only | Version recorded |
+| `--force` | Assert the solution exists and overwrite it without the probe. Not normally needed; fails `not_found` when the cloud solution is gone | Probe runs |
+| `--login-validity <minutes>` | Minimum minutes left on token before refresh | `10` |
 
 > 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.
 
@@ -493,7 +499,7 @@ ls -1 ./MySolution/resources/solution_folder/process/
 # 3. The two sets MUST agree by name. If not, the solution is corrupt.
 ```
 
-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:
+Steps 1–3 verify *project* mutations (`projects add`/`remove`, `refresh`). For *resource* mutations (`resources 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 resources list --source local --output json
@@ -508,13 +514,13 @@ If `.uipx` and `resources/solution_folder/` disagree, follow the recovery proced
 | `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 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.
+Copying `bindings.json` → `bindings_v2.json` does **not** work — the schemas differ, and `resources 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 `resources refresh` to reconcile.
 
-### `resource refresh` reports false success on schema errors
+### `resources refresh` reports false success on schema errors
 
 See [Step 7](#step-7-refresh-resources). Always capture stderr and grep for `ERROR`. The `Warnings` field stays empty even when the underlying parser throws.
 
-### `project remove` leaves orphan package resources
+### `projects remove` leaves orphan package resources
 
 See [Step 4](#step-4-remove-a-project). After `remove`, manually delete `resources/solution_folder/package/<name>.json` if you plan to re-add with the same name. To fully delete a project, also remove the project folder — `remove` does not touch source files.
 
@@ -524,7 +530,7 @@ See [Step 4](#step-4-remove-a-project). After `remove`, manually delete `resourc
 
 ### `add` vs `import`
 
-| | `project add` | `project import` |
+| | `projects add` | `projects import` |
 |-|----------------|-------------------|
 | Project location | Must already be inside the solution directory | Can be anywhere on disk |
 | File handling | Registers only (no file copy) | Copies into solution tree, then registers |
@@ -532,9 +538,9 @@ See [Step 4](#step-4-remove-a-project). After `remove`, manually delete `resourc
 
 ### `remove` does not delete files
 
-`project remove` unregisters from `.uipx` but leaves the project directory intact. Delete files manually if needed.
+`projects remove` unregisters from `.uipx` but leaves the project directory intact. Delete files manually if needed.
 
-### `resource refresh` is the sync mechanism
+### `resources refresh` is the sync mechanism
 
 Adding a project does not automatically sync its resources. The refresh scans all registered projects for `bindings_v2.json`, creates solution resources for untracked bindings, imports from Orchestrator when a match exists, and skips already-tracked bindings.
 
@@ -559,15 +565,20 @@ 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` refuses to overwrite without `--force`
+### `upload` decides import or overwrite from what the cloud holds
 
 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).
+- **Cloud has no solution with that id** → imported as new. This is the freshly `solution init`-ed flow. Studio Web assigns its own `SolutionId` — it never honors the one in the archive — so the CLI repoints the local `.uipx` to the assigned id and reports the rewrite under `Data.LocalSolutionIdUpdated` (`Path`, `From`, `To`). That link is what makes the next upload an update rather than a second cloud solution. The file is written only when the id actually changed.
+- **Cloud already has that id** → overwritten in place under the same id. The solution's Studio Web version history is **kept** — history rows key on the solution id, which does not change. The contents being replaced are recorded first as a restorable version (`Data.SnapshotCreated: true`), so an overwrite is recoverable. The local `.uipx` is not touched.
+
+`--no-snapshot` suppresses that recording. Anything edited **in Studio Web** since the last upload is then lost with no way back; local files are never affected.
+
+`--force` asserts that the solution exists — it is not a request to replace history. Not normally needed: a plain upload overwrites an existing cloud solution on its own. Use it when the probe cannot run, since the probe needs read access to the solution. When that solution is gone, the upload fails with `ErrorCode: not_found` (exit 1, `Retry: RetryWillNotFix`) rather than importing a duplicate. With no `SolutionId` bundled it changes nothing: the upload imports as new.
+
+A direct `.uis` upload has no local `.uipx` to read, so the CLI takes the `SolutionId` out of the archive (`SolutionStorage.json`, root `.uipx` as fallback, GUID-shaped values only). Re-uploading a `.uis` produced by `uip solution download` therefore updates the solution it came from instead of minting a `"<name> 1"` copy each time. An archive carrying no usable id imports as new.
 
-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`.
+To upload as an unrelated new cloud solution rather than overwriting, scaffold a fresh solution with `uip solution init`, or replace the `SolutionId` in the local `.uipx` with a fresh GUID and re-run `upload` — removing the field entirely fails `.uipx` validation.
 
 ### `delete` uses the solution UUID, not the name
 
@@ -579,13 +590,13 @@ 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 resources list`) or pass `--solution-folder <path>` explicitly.
+`resources 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
 
-Unlike `resource get` and `list` (which fall back to RCS when local state is missing), the write commands refuse to operate on a directory that doesn't directly contain a `.uipx`. This prevents `--solution-folder /tmp` from silently writing stray resource files anywhere on disk. If you see `<path> is not a UiPath solution (no .uipx manifest found)`, you're pointed at the wrong directory.
+Unlike `resources get` and `list` (which fall back to RCS when local state is missing), the write commands refuse to operate on a directory that doesn't directly contain a `.uipx`. This prevents `--solution-folder /tmp` from silently writing stray resource files anywhere on disk. If you see `<path> is not a UiPath solution (no .uipx manifest found)`, you're pointed at the wrong directory.
 
-### `resource get` for cross-folder inspection
+### `resources 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 resources list --kind <kind> --source remote` to discover keys.
 
@@ -597,7 +608,7 @@ Because `get` falls back to RCS + FPS export when the key isn't local, it works
 |---|---|---|
 | Create a fresh solution | `uip solution init <name>` | Accepts an existing empty directory; drops `.uipx` inside |
 | Add a project already in the solution dir | `uip solution projects add ./<dir>` | Transactional — `.uipx` and `resources/solution_folder/{package,process}/` agree on success |
-| Pull in an external project | `uip solution projects import --source <path>` | Rename source folder first to avoid 3-name divergence |
+| Pull in an external project | `uip solution projects import <path>` | Rename source folder first to avoid 3-name divergence |
 | Remove a project | `uip solution projects remove ./<dir>` | Manually delete `resources/.../package/<name>.json` afterwards |
 | 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"`) |

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

@@ -85,6 +85,54 @@ uip solution publish ./output/MySolution_2.0.0.zip --tenant "Production" --outpu
 
 After publishing, the package is visible via `uip solution packages list` and available for deployment.
 
+### Publishing to a non-tenant feed
+
+By default everything targets the **tenant** feed. A package can instead go to your
+Personal Workspace or to a specific **folder feed**. Start by listing what you can
+actually target — a raw folder key is not necessarily a publishable feed:
+
+```bash
+uip solution feeds list --output json
+```
+
+`Data` is a list of `{ Name, Key, Type, IsMyPersonalWorkspace }` where `Type` is
+`Tenant`, `PersonalWorkspace`, or `Folder`. Only feeds in this list can be
+targeted; passing anything else fails with *"is not an available publish
+location"*. Personal Workspaces belonging to other users are filtered out even
+when you can browse them.
+
+Then target a feed with `--feed <name-or-key>` (accepts either the feed's name or
+its folder key) or `--personal-workspace`:
+
+```bash
+# Publish into a folder feed
+uip solution publish ./output/MySolution_2.0.0.zip --feed "Finance" --output json
+
+# Publish into your own Personal Workspace
+uip solution publish ./output/MySolution_2.0.0.zip --personal-workspace --output json
+```
+
+The same two flags scope the rest of the lifecycle, and they are **mutually
+exclusive** everywhere:
+
+| Command | What the flag scopes |
+|---|---|
+| `uip solution publish --feed / --personal-workspace` | Which feed the package is uploaded to |
+| `uip solution deploy run --feed / --personal-workspace` | Which feed the package is deployed **from** |
+| `uip solution deploy list --feed / --personal-workspace` | Which feed's deployments are listed |
+| `uip solution packages list --feed / --personal-workspace` | Which feed's packages are listed |
+| `uip solution packages delete --feed / --personal-workspace` | Which feed the version is deleted from |
+
+**Deploy from the feed you published to.** A package published to a folder feed or
+Personal Workspace is not in the tenant feed, so a plain `deploy run` cannot see
+it — pass the same `--feed` / `--personal-workspace` there too. Likewise, omitting
+the flag on `packages list` shows only tenant packages, which is the usual reason
+a freshly published feed package looks missing.
+
+`deploy run --feed` also accepts `--parent-folder-path` / `--parent-folder-key` to
+pick **where inside** the feed's folder the deployment lands; without them it goes
+to the feed folder itself.
+
 ## Step 3 (Alternative): Upload to Studio Web
 
 If the goal is browser-based editing rather than deployment, use `upload` instead of `publish`:
@@ -93,7 +141,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`. 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).
+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` overwrites that solution in place; otherwise it imports as new — see [develop-solution.md § `upload` decides import or overwrite from what the cloud holds](develop-solution.md#upload-decides-import-or-overwrite-from-what-the-cloud-holds) for the decision rules and snapshot recording.
 
 `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 init` 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/scenarios/failure-modes.md

@@ -7,7 +7,7 @@ Symptoms that don't fit a single scenario but bite often enough to call out. Use
 | `[1009] <kind> <name>: Invalid argument 'Value'` at deploy | Virtual resource without `value` set ([virtual-resource](virtual-resource.md)) | `deploy config set <file> <name> value <val>` or `deploy config link <file> <name> --name <existing>` |
 | `Folder already exists` at deploy | `--folder-name` collides with an existing folder under `--parent-folder-path` | Pick a different `--folder-name`, or `solution deploy uninstall <existing>` first |
 | Suffix `_N` keeps growing on re-refresh (`_1`, `_2`, `_3`...) | Old CLI version (pre-suffix-amplification fix) | Upgrade `@uipath/cli` to a build that ships the SDK bump (`resource-builder-sdk` ≥ `2025.11.0-alpha3780`); the current refresh is idempotent on cloud key |
-| Tool dialog in Studio Web doesn't open for one of two same-name tools | SW UI bug — affects pure-SW solutions too ([same-name-across-folders](same-name-across-folders.md)) | Verified at deploy/runtime — ignore the UI symptom; check the tool resolves correctly via `resource list --source remote` after deploy |
+| Tool dialog in Studio Web doesn't open for one of two same-name tools | SW UI bug — affects pure-SW solutions too ([same-name-across-folders](same-name-across-folders.md)) | Verified at deploy/runtime — ignore the UI symptom; check the tool resolves correctly via `resources list --source remote` after deploy |
 | Refresh imports 0 of N bindings, no warnings | `bindings_v2.json` not at expected path (project root, not nested) | Move file to `<ProjectName>/bindings_v2.json`; `agent validate` regenerates it for agent projects |
 | `processKey` collision on `solution publish` | Republishing same name+version | Bump version (`solution pack --version 1.0.1 …`); the feed rejects duplicate `name+version` pairs |
 

package/skills/uipath-solution/references/scenarios/intra-solution-references.md

@@ -29,7 +29,7 @@ The right `referenceKey` for the Worker tool is the **solution-resource key** of
   "name": "WorkerTool",
   "type": "agent",
   "location": "solution",                              // ← intra-solution, not "external"
-  "referenceKey": "<solution-resource-key-of-Worker>", // from `resource list --kind Process --source local`
+  "referenceKey": "<solution-resource-key-of-Worker>", // from `resources list --kind Process --source local`
   "properties": {
     "processName": "Worker",
     "folderPath": "solution_folder"
@@ -40,13 +40,13 @@ The right `referenceKey` for the Worker tool is the **solution-resource key** of
 ## What happens at refresh + pack
 
 - `solution projects add` writes `Worker.json` and `Coordinator.json` under `resources/solution_folder/process/agent/` with stable solution-resource keys (UUIDs minted by the SDK at add time).
-- `resource refresh` doesn't re-mint those keys — they're stable for the life of the solution.
+- `resources refresh` doesn't re-mint those keys — they're stable for the life of the solution.
 - At pack, the Coordinator's `runtimeDependencies` entry for the Worker tool carries the same solution-resource key as `referenceKey`. Orchestrator's deploy pipeline resolves intra-solution links by matching this key to a sibling resource in the deployment.
 
 ## Gotchas
 
 - **Don't put the cloud key of a different (already-published) Worker** if you intend to ship Worker as part of this solution. `referenceKey` to a cloud key skips the intra-solution link and points the runtime at the cloud copy — which may or may not exist in the target tenant at deploy time.
-- **The solution-resource key is stable across refreshes within an instance** but **regenerates if you delete and re-create the solution** (`solution init` → mint fresh UUIDs). Hard-coding the key in `resource.json` survives normal refresh cycles but breaks if anyone wipes-and-recreates. If that's a risk, rebuild the file from `resource list --kind Process --source local` output as part of CI.
+- **The solution-resource key is stable across refreshes within an instance** but **regenerates if you delete and re-create the solution** (`solution init` → mint fresh UUIDs). Hard-coding the key in `resource.json` survives normal refresh cycles but breaks if anyone wipes-and-recreates. If that's a risk, rebuild the file from `resources list --kind Process --source local` output as part of CI.
 - **`location` must be `"solution"`, not `"external"`** for intra-solution tools. SW UI shows external-tool dialogs differently and won't render the link state correctly.
 - **Worker → Coordinator cycles**: nothing prevents you from declaring a tool in Worker that points back at Coordinator. The runtime supports it; if the agent prompts loop, that's an authoring issue, not a deploy one.
 

package/skills/uipath-solution/references/scenarios/manual-edits.md

@@ -89,7 +89,7 @@ After any solution-level edit, run a sanity check:
 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.
+The list should show your resource with the new spec. If `resources 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.
 
 ## Deploy config files (`deploy-config.json`)
 

package/skills/uipath-solution/references/scenarios.md

@@ -23,8 +23,8 @@ Land here from a grep on an error message? Pick the matching row.
 | 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 |
+| I edited a spec field but `refresh` didn't pick it up | Expected — `refresh` never overwrites a resource already in the solution. Use `resources edit` to mutate spec. |
+| `resources 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) |
 | Other deploy / refresh failures (folder collision, suffix amplification, missing bindings, version collision) | [failure-modes](scenarios/failure-modes.md) |
 

package/skills/uipath-solution/references/solution-overview.md

@@ -62,10 +62,10 @@ MySolution/
 │   └── source/dist/                      <- Build output (bundlePath: "source/dist").
 ├── resources/                            <- Auto-generated on add/import. NEVER hand-edit.
 │   └── solution_folder/
-│       ├── package/<name>.json           <- Auto-created on add. NOT cleaned by `project remove`.
+│       ├── package/<name>.json           <- Auto-created on add. NOT cleaned by `projects remove`.
 │       ├── process/{process,flow}/<name>.json   <- Auto-created on add. Auto-cleaned on remove.
 │       └── app/{Coded,CodedAction}/<name>.json  <- AppV2 apps only. `kind: "app"`, `apiVersion: apps.uipath.com/v1`.
-└── userProfile/<user-uuid>/              <- Appears after first `project remove`.
+└── userProfile/<user-uuid>/              <- Appears after first `projects remove`.
 ```
 
 > `.uipx` and `resources/solution_folder/` must always agree on the set of projects. Diffing them is the fastest way to detect a corrupted state — see [develop-solution.md - Field-tested gotchas](develop-solution.md#field-tested-gotchas).
@@ -110,12 +110,14 @@ uip solution
   ├── restore <solution>                  Resolve NuGet deps in place before pack (needs login; no package produced)
   ├── pack <solution> <output>            Pack into a deployable .zip package
   ├── publish <package>                   Upload packed solution to UiPath
-  ├── project
+  ├── projects                              (`project` still works as a hidden, deprecated alias)
   │     ├── add <project-path> [solutionFile]   Register an existing subfolder in .uipx
   │     ├── remove <project-path> [solutionFile] Unregister a project from .uipx
-  │     ├── import --source <path>              Copy external project into solution and register
-  │     └── list                                List projects registered in the local .uipx (no backend call)
-  ├── resource
+  │     ├── import <path>                       Copy external project into solution and register
+  │     ├── list                                List projects registered in the local .uipx (no backend call)
+  │     ├── publish                             Publish a cloud solution project as a package (--project-name, --package-name, --package-version)
+  │     └── resync [project-name]               Sync or reset a cloud solution project (--sync-option Sync|Reset)
+  ├── resources
   │     ├── list                          List local, remote, or all resources (--solution-folder, default cwd)
   │     ├── refresh                       Sync resource declarations from project bindings (--solution-folder, default cwd)
   │     ├── get <resource-key>            Get full configuration for a single resource — local or remote (--solution-folder, default cwd)
@@ -127,18 +129,25 @@ uip solution
   │     ├── status <id>                   Check deployment status
   │     ├── list                          List deployments
   │     ├── activate <name>               Activate a deployment (only needed after --skip-activate or to retry a failed auto-activation)
+  │     ├── upgrade <deployment-key>      Move a deployment to a newer package version in place, keeping its existing configuration
   │     ├── uninstall <name>              Uninstall a deployment
   │     └── config
   │           ├── get <package-name>      Fetch default deploy config
   │           ├── set <file> ...          Set a resource property in config
   │           ├── link <file> <resource>  Link to an existing Orchestrator resource
   │           └── unlink <file> <resource> Remove a resource link
+  ├── feeds
+  │     └── list                          List the feeds you can publish or deploy to (tenant, your Personal Workspace, folder feeds)
   └── packages
         ├── list                          List published solution packages
         ├── download <name> [version]      Download a published solution package .zip
         └── delete <name> <version>       Delete a specific package version
 ```
 
+`publish`, `deploy run`, `deploy list`, `packages list` and `packages delete` all take
+`--feed <name-or-key>` or `--personal-workspace` to target a feed other than the
+tenant's. See [Pack and Deploy — Publishing to a non-tenant feed](pack-and-deploy.md#publishing-to-a-non-tenant-feed).
+
 ---
 
 ## Workflow References

package/skills/uipath-tasks/SKILL.md

@@ -124,25 +124,25 @@ uip tasks complete <task-id> --type ExternalTask --folder-id <folder-id> --outpu
 
 2. **Task IDs are numeric.** Unlike other UiPath services that use GUIDs, Action Center uses numeric task IDs. Use `tasks list` to discover task IDs.
 
-3. **Folder ID is required for complete.** Tasks are scoped to folders. Use `--folder-id` when completing tasks.
+3. **Folder scope comes in three interchangeable forms.** Folder-scoped commands accept `--folder-id <numeric-id>`, `--folder-path <path>`, or `--folder-key <guid>` (mutually exclusive). Path and key are exactly what `uip or folders list` prints (it has no numeric ID column), so prefer them when the folder came from folder discovery; the numeric id still works when a task row gave you `folderId`.
 
 4. **Complete requires `--type`.** The API routes to different endpoints per task type. Always include `--type` when completing a task. Use `tasks get` to check the task type first.
 
 5. **FormTask and AppTask require `--action` and `--data` for completion.** Other task types allow optional action and data.
 
-6. **Assign accepts `--user-id` or `--user` (email).** Use `tasks users <folder-id>` to discover assignable users and their IDs.
+6. **Assign accepts `--user-id` or `--user` (email).** Use `tasks users <folder-id>` (or `tasks users --folder-path <path>` / `--folder-key <guid>`) to discover assignable users and their IDs.
 
 7. **Always discover before acting.** Use `tasks list` or `tasks get` to inspect task state before performing assign/complete operations.
 
 8. **Do not complete already-completed tasks.** Check the task `status` field — if it is `Completed`, inform the user.
 
-9. **Folder ID for catalogs/comments/labels/metadata/data.** These commands are folder-scoped. Pass `--folder-id`, or omit it on an interactive terminal to pick from a list. It is required in non-interactive runs (agents, CI) — always pass it explicitly there.
+9. **Folder scope for complete/catalogs/comments/labels/metadata/data.** These commands need a folder. Pass one of `--folder-id`/`--folder-path`/`--folder-key`, or omit all three on an interactive terminal to pick from a list. A folder option is required in non-interactive runs (agents, CI) — the command fails with `A folder is required` otherwise, so always pass one explicitly there.
 
 10. **Retention actions are `Delete` or `Archive`.** `Archive` also needs `--retention-bucket-id`. `--encrypted` is create-only and cannot be changed on update.
 
 11. **Labels replace the full set.** `tasks labels --labels` overwrites all labels on the task — include every label to keep, and pass `[]` to clear them all.
 
-12. **`data save` takes no type flag.** The command resolves the task type itself; pass the task ID, `--folder-id`, and `--data` (a JSON object).
+12. **`data save` takes no type flag.** The command resolves the task type itself; pass the task ID, a folder option (`--folder-id`/`--folder-path`/`--folder-key`), and `--data` (a JSON object).
 
 ---
 
@@ -152,6 +152,7 @@ uip tasks complete <task-id> --type ExternalTask --folder-id <folder-id> --outpu
 |------|----------------|
 | List all tasks | `tasks list` |
 | List tasks in a folder | `tasks list --folder-id <id>` |
+| List tasks in a folder by path/key | `tasks list --folder-path "<path>"` or `tasks list --folder-key <guid>` |
 | List tasks as admin | `tasks list --as-admin` |
 | Get task details | `tasks get <task-id>` |
 | Get task with type hint | `tasks get <task-id> --task-type FormTask --folder-id <id>` |
@@ -161,14 +162,14 @@ uip tasks complete <task-id> --type ExternalTask --folder-id <folder-id> --outpu
 | Unassign a task | `tasks unassign <task-id>` |
 | Complete a task | `tasks complete <task-id> --type <type> --folder-id <id>` |
 | Complete with action | `tasks complete <task-id> --type FormTask --folder-id <id> --action "Approve" --data '{...}'` |
-| List assignable users | `tasks users <folder-id>` |
+| List assignable users | `tasks users <folder-id>`, `tasks users --folder-path "<path>"`, or `tasks users --folder-key <guid>` |
 | List task catalogs | `tasks catalogs list --folder-id <id>` |
 | Get a catalog | `tasks catalogs get <catalog-id> --folder-id <id>` |
 | Create a catalog | `tasks catalogs create --name <name> --folder-id <id>` |
 | Update a catalog | `tasks catalogs update <catalog-id> --folder-id <id>` |
 | List task comments | `tasks comments list <task-id> --folder-id <id>` |
 | Add a comment | `tasks comments add <task-id> --text <text> --folder-id <id>` |
-| Set task labels | `tasks labels <task-id> --labels '[{"name":"urgent"}]' --folder-id <id>` |
+| Set task labels | `tasks labels <task-id> --labels '[{"name":"region","displayName":"Region","displayValue":"EMEA"}]' --folder-id <id>` |
 | Edit task metadata | `tasks metadata <task-id> --folder-id <id> [--title --priority --catalog-id]` |
 | Get task data | `tasks data get <task-id> --folder-id <id>` |
 | Save task data | `tasks data save <task-id> --data '{...}' --folder-id <id>` |
@@ -216,6 +217,10 @@ uip tasks get <task-id> --output json
 | Completion fails | Wrong `--type` | Use `tasks get` to check the actual task type |
 | Completion fails for FormTask | Missing `--action` or `--data` | FormTask and AppTask require both `--action` and `--data` |
 | Cannot assign | User lacks permissions in folder | Run `tasks users <folder-id>` to list eligible users |
+| `A folder is required` | Non-interactive run without a folder option | Pass `--folder-id`, `--folder-path`, or `--folder-key` |
+| `Folder not found: '<value>'.` | The path/key doesn't match a folder this login can access | Run `uip or folders list` and use a listed `Path` or `Key` |
+| `Invalid --folder-key: <value>` | The key is not a UUID | Use the GUID from the `Key` column of `uip or folders list` |
+| `Error resolving folder path/key '<value>'` | The folder lookup itself failed (permissions or network) | Check the error detail in `Instructions`; verify access with `uip or folders list` |
 
 ---
 

package/skills/uipath-tasks/references/task-assignment.md

@@ -6,6 +6,11 @@ Before assigning a task, discover which users have task permissions in the folde
 
 ```bash
 uip tasks users <folder-id> --output json
+
+# Or by folder path/key — the values `uip or folders list` prints.
+# Quote the path: folder paths may contain spaces.
+uip tasks users --folder-path "<folder-path>" --output json
+uip tasks users --folder-key <folder-key> --output json
 ```
 
 Response includes user details:

package/skills/uipath-tasks/references/task-catalogs.md

@@ -10,10 +10,13 @@ another, and catalog IDs are numeric. See the
 
 ## Folder scoping
 
-Every catalog command needs a folder. In an interactive terminal you can omit
-`--folder-id` and pick a folder from a list. In a non-interactive run (a coding
-agent or CI, where no picker can be shown) you must pass `--folder-id <id>`
-explicitly, otherwise the command fails.
+Every catalog command needs a folder, given one of three mutually exclusive
+ways: `--folder-id <numeric-id>`, `--folder-path <path>`, or
+`--folder-key <guid>` (path and key are what `uip or folders list` prints). In
+an interactive terminal you can omit all three and pick a folder from a list.
+In a non-interactive run (a coding agent or CI, where no picker can be shown)
+you must pass one explicitly, otherwise the command fails with
+`A folder is required`.
 
 ## List
 

package/skills/uipath-tasks/references/task-completion.md

@@ -88,7 +88,9 @@ Before completing a task, always verify:
 
 3. **Folder ID matches:**
    ```bash
-   # The "folderId" field in the response gives you the --folder-id value
+   # The "folderId" field in the response gives you the --folder-id value.
+   # If you only know the folder from `uip or folders list`, pass its Path or
+   # Key instead: --folder-path <path> / --folder-key <guid>.
    ```
 
 ## SLA Tracking

package/skills/uipath-tasks/references/task-data.md

@@ -2,9 +2,9 @@
 
 Task data is the business/form field payload attached to a task: a JSON object of
 key/value pairs whose keys are the task's schema fields (the values an approver
-reviews). Folder-scoped: pass `--folder-id <id>`, or omit it in an interactive
-terminal to pick a folder (in a non-interactive run you must pass `--folder-id`).
-Task IDs are numeric.
+reviews). Folder-scoped: pass `--folder-id <id>` (or `--folder-path <path>` /
+`--folder-key <guid>`), or omit them in an interactive terminal to pick a folder
+(in a non-interactive run you must pass one). Task IDs are numeric.
 
 ## Get data
 

package/skills/uipath-tasks/references/task-lifecycle.md

@@ -9,10 +9,19 @@ uip tasks list --output json
 # List tasks in a specific folder
 uip tasks list --folder-id <folder-id> --output json
 
+# Same, by folder path or key — the values `uip or folders list` prints.
+# Quote the path: folder paths may contain spaces.
+uip tasks list --folder-path "<folder-path>" --output json
+uip tasks list --folder-key <folder-key> --output json
+
 # List tasks as admin (elevated access)
 uip tasks list --as-admin --output json
 ```
 
+`--folder-id`, `--folder-path`, and `--folder-key` are mutually exclusive. Path
+and key are resolved to the numeric folder id before the task query runs, so
+all three scope the same way.
+
 ## Getting Task Details
 
 ```bash
@@ -38,6 +47,8 @@ Type-specific endpoints are faster because they avoid the generic OData lookup:
 # 1. List tasks and discover folder users
 uip tasks list --output json
 uip tasks users <folder-id> --output json
+# (or by path/key when the folder came from `uip or folders list`:
+#  uip tasks users --folder-path "<folder-path>" --output json)
 
 # 2. Assign to a user
 uip tasks assign <task-id> --user alice@company.com --output json

package/skills/uipath-tasks/references/task-metadata.md

@@ -1,8 +1,9 @@
 # Task Metadata, Comments & Labels Reference
 
 Operations that annotate or reorganize an existing task. All are folder-scoped:
-pass `--folder-id <id>`, or omit it on an interactive terminal to pick a folder
-(required when stdout is not a TTY). Task IDs are numeric.
+pass `--folder-id <id>` (or `--folder-path <path>` / `--folder-key <guid>`), or
+omit them on an interactive terminal to pick a folder (a folder option is
+required when stdout is not a TTY). Task IDs are numeric.
 
 ## Edit metadata
 
@@ -60,7 +61,7 @@ keep. Use `[]` to clear all labels.
 
 ```bash
 # Set labels
-uip tasks labels <task-id> --folder-id <folder-id> --labels '[{"name":"urgent"}]' --output json
+uip tasks labels <task-id> --folder-id <folder-id> --labels '[{"name":"region","displayName":"Region","displayValue":"EMEA"}]' --output json
 
 # Clear all labels
 uip tasks labels <task-id> --folder-id <folder-id> --labels '[]' --output json