uipath-solution git:20261005.e579718C

Immutable. This exact content never changes and is served at /api/v1/blob/8edc6596465cc6a4.

<!--skill-flavor:solution-lifecycle-steps:start-->
```
1. Create projects   → CreateProjects tool / New Project UI
2. resources refresh → Sync bundled artefacts with cloud state (if needed)
3. publish           → uip solution publish (packaging and auth handled by Studio Web)
4. deploy run        → uip solution deploy run (installs the published package into a folder)
```

> **No `pack`, `restore`, `login`, or `upload` steps in Studio Web.** The packager is Node-only and excluded from the browser bundle, authentication is injected by the host, and `/solution` already IS the open project so there is nothing to upload. `publish` and `deploy` both work here.

> **Publish destination — the user's choice.** Run `uip solution publish` with no destination flags first. With one destination it publishes there. With several it publishes nothing and lists them: ask the user in chat which destination to use — personal workspace (visible only to them) vs shared location (visible to others with access) — then rerun with `--location "<key or name>"` (or `--personal-workspace`). Skip the question when the user already named a destination; remember their answer for the rest of the conversation. Unknown flags fail the command — the destination flag is `--location`.

> **Publish is asynchronous.** Success means Unified Build accepted the request and packaging continues in the background — submitted is not shipped. Report destination, version, and request id; verify the terminal state in Studio Web's Publish history.

> **Publishing puts a package in a feed; deploying installs it into a folder.** A feed is a versioned package store, so a published-only package runs nowhere and does not appear in Orchestrator's solutions list. Publishing to the personal workspace auto-deploys, so it needs no deploy step. Publishing to a shared location never auto-deploys — finish it with `uip solution deploy run`, or leave it as a package deliberately.

> **`deploy run` creates a NEW Orchestrator folder every time.** `--folder-name` is required and is never reused: an existing name is collision-renamed, so repeated deploys leave `MyFolder`, `MyFolder_1`, `MyFolder_2` behind in a tenant other people share. It cannot deploy *into* an existing folder — the closest thing is `--parent-folder-path "<path>"` (or `--parent-folder-key`), which nests the new folder under that one; without it the folder is created at the tenant root. Publishing to the shared/tenant location does NOT put anything in the Orchestrator folder named `Shared` — that folder and the shared publish destination are different things, so deploying under it needs `--parent-folder-path "Shared"` explicitly. Confirm the deployment name, the folder name, and the parent path with the user before the first `deploy run`. Deploy from the feed you published to: a package on a personal-workspace feed is invisible to a plain `deploy run`, so pass `--personal-workspace` there too.

> **To ship a later version of a deployed solution, upgrade it — do not `deploy run` again.** Publish the new version, then `uip solution deploy upgrade <deployment-key>` moves the existing deployment in place, keeping its folder and configured values. It defaults to the newest published version; `--version` selects another, and `--personal-workspace` targets a personal-workspace deployment. A second `deploy run` would instead create yet another folder.

> **Any key of the deployment reaches it.** `uip solution deploy upgrade <key>` resolves the key through the Pipelines by-key lookup to the deployment's current generation, so the `Key` from `uip solution deploy list` and a stored `InstallDeploymentKey` both work; store `InstallDeploymentKey`, the one that never changes across upgrades. `uip solution deploy status <key>` answers `Superseded: true` and names the current key when the one you hold is stale.

> **Deploy is asynchronous in two phases.** `deploy run` installs, polls to a terminal status, then activates unless `--skip-activate`; success is `Status: DeploymentSucceeded` with `ActivationStatus: SuccessfulActivate`. Read `ActivationStatus` when it is anything else: `NeedsSetupToActivate` means a resource needs "Setup activation" in Orchestrator first and `deploy activate` is refused with `4007` until then (the run is still a success; `PendingResources` names the resource and why); `ReadyToActivate` or a failed activation means fix the cause and run `uip solution deploy activate <name>`. The deployment exists either way — never redeploy. Check state with `uip solution deploy status` / `deploy list`.
<!--skill-flavor:solution-lifecycle-steps:end-->

<!--skill-flavor:when-to-use-uipx:start-->
- User wants to publish the open Studio Web solution (`uip solution publish`; `pack`/`upload`/`deploy` are unavailable in the browser — publishing to the personal workspace auto-deploys)
<!--skill-flavor:when-to-use-uipx:end-->

<!--skill-flavor:when-to-use-detected-uipx:start-->
<!--skill-flavor:when-to-use-detected-uipx:end-->

<!--skill-flavor:when-to-use-create:start-->
- User wants to inspect or edit the open Studio Web solution's resources (`uip solution resources list / get / add / edit`). Studio Web works on one open solution — projects are created inside it with `uip <family> init <Name>` (families: flow, case, agent, api-workflow, bpmn, rpa — Studio Web cannot create function or coded-app projects), never with `solution init` or `projects add`
<!--skill-flavor:when-to-use-create:end-->

<!--skill-flavor:cli-surface-probe:start-->
Studio Web runs the post-rename CLI — use the commands and flags as documented in the references, with no probe.
<!--skill-flavor:cli-surface-probe:end-->
<!--skill-flavor:cli-unavailable:start-->
- `unknown command` / `command not found` on a documented verb → the host did not expose it. Do NOT `npm install` (the CLI is bundled by the host, not globally installed) and do not fall back to a pre-rename spelling. Report the exact command and error to the user and stop.
<!--skill-flavor:cli-unavailable:end-->

<!--skill-flavor:rename-table:start-->
<!--skill-flavor:rename-table:end-->

<!--skill-flavor:probe-rule:start-->
1. **Studio Web runs the post-rename CLI.** Use the documented commands directly; there is no pre-rename fallback.
<!--skill-flavor:probe-rule:end-->

<!--skill-flavor:develop-solution-row:start-->
| [Develop a Solution](references/develop-solution.md) | `uip solution resources list / get / add / edit` on the open solution (projects are created with `uip <family> init` — flow, case, agent, api-workflow, bpmn, rpa only; `projects add/import/remove` and `resources refresh/remove` are Node-CLI-only); field-tested gotchas |
<!--skill-flavor:develop-solution-row:end-->