uipath-solution git:20260907.bf65a37C

Immutable. This exact content is served forever at /api/v1/blob/29f4e7ee17a7e44e.

<!--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.

> **Pass the deployment's `Key`, not its `InstallDeploymentKey`.** Read the key from `uip solution deploy list` at the time you upgrade: after any version change the record's `Key` changes while `InstallDeploymentKey` keeps pointing at the original install. Reusing a key cached from an earlier `deploy run` fails with `HTTP 400` / errorCode `4005` "Another upgrade has already started for this deployment" — which reads like a stuck upgrade but really means the wrong key.

> **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`. If activation fails the deployment still exists — fix the config and run `uip solution deploy activate <name>` rather than redeploying. 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>`, 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`; `projects add/import/remove` and `resources refresh/remove` are Node-CLI-only); field-tested gotchas |
<!--skill-flavor:develop-solution-row:end-->