@uipath/solution-tool 1.204.0 → 1.205.0-preview.258

package/dist/templates/AGENTS.md

@@ -67,7 +67,7 @@ A solution can contain multiple projects of different types. The table below lis
 | `Function` | UiPath Function (JS / TS / Python) | `uip function new [name]` | `uipath-functions` |
 | `Api` | API Workflow project | `uip api-workflow init <name>` | `uipath-api-workflow` |
 | `BusinessRules` | Business rule — one or more DMN decisions. Packs to a `.uirule` (its `.dmn` files plus `entry-points.json`), not a `.nupkg` | `uip rules init <name>` | `uipath-rules` |
-| `Entity` | Data Fabric entity project — one folder per project, one `.entity` pointer file per entity; the schema itself lives in `resources/solution_folder/entity/native/<Name>.json`. Emits no package: the entity resources are the deployable payload, so `solution pack` validates the project instead of building it. | no CLI scaffolding — entity projects are modelled in the UiPath VS Code extension. Do not hand-write the `.entity` file or its resource: the pointer and the schema must stay in step, and `solution pack` fails if they do not. | `uipath-platform` (covers `uip df` entities, records and choice sets) |
+| `Entity` | Data Fabric entity project — one folder per project, one `.entity` pointer file per entity; the schema itself lives in `resources/solution_folder/entity/native/<Name>.json`. Emits no package: the entity resources are the deployable payload, so `solution pack` validates the project instead of building it. | `uip df entities create <Name> --local` — scaffolds the project when it does not exist (named after the entity unless `--project-name` says otherwise), and adds a further entity when it does; `entities list`/`get`/`update`/`validate`/`delete` with `--local` work on them afterwards. Prefer these to hand-writing the `.entity` file or its resource — the pointer and the schema must stay in step, and `solution pack` fails if they do not. Entities are also modelled in the UiPath VS Code extension. | `uipath-platform` (covers `uip df` entities, records and choice sets) |
 | `Connector` | Integration Service connector | no CLI scaffolding — use `uip is connectors` to list / get / export existing connectors | `uipath-connector-builder` |
 | `WebApp` | Legacy low-code UiPath App (the coded variant is `AppV2`) | no CLI scaffolding | none |
 
@@ -81,12 +81,14 @@ The type lives in either `project.uiproj` (top-level `ProjectType`) or `project.
 
 The `init` scaffolders above auto-register when run inside a solution directory (unless `--skip-solution-registration` is passed). For other scaffolders, register the project with the solution after scaffolding: use `uip solution projects add <project-path> [<solution-file>]` when the project already lives inside the solution directory (registers in place, no copy), or `uip solution projects import <path>` to copy a project from outside the solution dir into it and register it. If you pass an unknown type to those commands, they reject with the exhaustive accepted list — trust that error over this table. `uip solution pack` rejects the same way: a `Projects[]` entry whose `Type` no packager handles fails with `ErrorCode: invalid_argument`, naming the project, the accepted types, and how to drop the entry, rather than attempting the pack.
 
+`projects add` and `projects remove` take **either** the project folder or its manifest file: `uip solution projects remove my-app` and `uip solution projects remove my-app/project.uiproj` do the same thing. That matters because the `.uipx` records a project by its manifest file (`ProjectRelativePath: "my-app/project.uiproj"`), so the path `pack` quotes back when it refuses an entry can be pasted straight into `remove`. `projects import` is the exception — its argument is an external folder to copy, so give it a directory.
+
 **Member package ids come from folder names, and pack refuses the ones a feed cannot store.** Each member is published under `<solution>.<project-type>.<member-folder>` — the solution's own `.uipx` name, the short type (`Rpa`, `Case`, `Flow`, …) and the member's folder inside the solution. The name a project declares for itself is not used, and `--name` renames the archive only. Two limits ride on that, both checked before anything is packed and both reported as `ErrorCode: invalid_argument` / `Retry: RetryWillNotFix`:
 
 - **Unique.** Two members whose folders compose the same id fail the pack, naming the shared id and every folder that produced it. Spaces and dots both collapse to a single dot and NuGet ids are case-insensitive, so `collide me`, `collide.me` and `Collide.Me` are one id.
 - **100 characters.** A composed id longer than that fails the pack, naming the member folder that blew the limit.
 
-The fix for either is a rename — the member folder, or the `.uipx` — since members take no `--package-id`.
+The fix for either is a rename — the member folder, or the `.uipx`. A whole-solution pack takes no `--package-id`; only a single-project pack (`--project`, below) can override the id.
 
 ## End-to-End Lifecycle
 
@@ -102,13 +104,13 @@ uip login --client-id env.UIPATH_CLIENT_ID --client-secret env.UIPATH_CLIENT_SEC
 
 # 1a. (Optional) Restore project dependencies before packing. Resolves NuGet
 #     deps (including authenticated Orchestrator feeds) so pack can compile.
-#     Useful in CI: login -> restore -> pack. Takes <solutionPath> as its only
+#     Useful in CI: login -> restore -> pack. Takes <solution-path> as its only
 #     positional arg and does not produce a package. Pack also restores
 #     internally, so this is an optimization, not a requirement.
 uip solution restore .
 
 # 2. Pack the solution into a .zip. Two positional args:
-#    <solutionPath>  — solution dir (containing .uipx) or a .uis file
+#    <solution-path> — solution dir (containing .uipx) or a .uis file
 #    <output-path>   — directory where the .zip is written (required unless --dry-run)
 uip solution pack . ./out
 
@@ -116,6 +118,17 @@ uip solution pack . ./out
 #     pipeline without producing a package — useful as a CI gate.
 uip solution pack . --dry-run
 
+# 2b. (Optional) Pack ONE project into its own .nupkg instead of the .zip.
+#     It packs as a stand-alone project: no solution resources go into it, so
+#     a project that uses one is published without it.
+#     --project takes the project's Id from the .uipx or its path relative to
+#     the solution folder. The package id defaults to the one the solution
+#     pack gives the project; --package-id (only with --project) overrides
+#     it, and --name is refused with it. Data.Packages is the absolute path of
+#     the .nupkg. An unknown --project fails with invalid_argument and lists
+#     the valid Ids and paths.
+uip solution pack . ./out --project <project-id-or-path> [--package-id <id>]
+
 # 3. Publish the packed .zip to Orchestrator
 uip solution publish ./out/<package>.zip
 
@@ -154,6 +167,8 @@ uip solution deploy list
 
 **A rejected attempt leaves a pending draft.** When a `deploy run` or `deploy upgrade` stops at `ValidationFailed` (or a conflict or scheduling error), nothing is installed and the live version keeps running, but the attempt stays behind as a *draft* — its key is the `deploymentKey` in the failure's `Instructions`. While the draft exists it owns the deployment, as in the Orchestrator UI (which offers only "continue editing" and "delete draft"): re-running the same `deploy run` with a corrected `--config-file` and the **draft's** version re-validates it with the new file (settings and resource links the file does not name keep the rejected values). Any other version is refused before anything is sent (`ErrorCode: invalid_argument`) — including the version that is live now, which the server would otherwise answer by installing the draft's version instead. Under an external app that check only warns and the deploy goes ahead — and the server then runs the draft, installing the draft's version — so from CI/CD ask only for the draft's version, or discard the draft first. `deploy upgrade` sends no configuration, so it refuses a deployment with a pending draft (`ErrorCode: invalid_argument`, naming the draft's key and version) rather than re-run the rejected attempt; once the cause is fixed, `uip solution deploy upgrade <draft-or-deployment-key> --discard-draft` deletes the draft and upgrades the live version with its own configuration, and reports the deleted key as `DiscardedDraftKey`. Address the deployment by key for this from CI/CD — on an older server the name form can only find the draft with a user session. A draft still being validated cannot be discarded yet (`Retry: RetryLater`). A Setup activation started in Orchestrator and left unfinished is a draft too, of the live version: both commands refuse while it exists and name it as such — finish it in Orchestrator, or discard it the same way. A deployment whose *first* install never completed has nothing to upgrade: fix and re-run its `deploy run`, or delete the draft in Orchestrator.
 
+**Replacing an installed resource with a link deletes it.** When a `deploy run` config file (or the new version in a `deploy upgrade`) links a resource that the deployment already installed, the server deletes the installed copy and its data — and asks for confirmation first. Without `--acknowledge-permanent-deletion` the command stops (`ErrorCode: invalid_argument`), lists the resources in `Message` and in `Data.PermanentDeletionResources`, and installs nothing; the attempt is kept as a pending draft. Re-run the same command with `--acknowledge-permanent-deletion` to confirm — for `deploy upgrade` do **not** add `--discard-draft`, which would drop the links being confirmed (the command refuses the two together on such a draft); the flag lets the same-version draft through: each listed resource is acknowledged, the same install runs once more, and the success output names them in `PermanentlyDeletedResources`. If that re-run is refused before it runs (e.g. a `429`), nothing was deleted but the acknowledgement stays on the draft: the next run of the same command deletes them without asking. To keep the installed copies, remove the links instead (`deploy config unlink` for `deploy run`; for `deploy upgrade`, `--discard-draft` without the flag, or remove them in Orchestrator). The flag is independent of `--yes`, and nothing ever prompts.
+
 **One deployment per package.** `deploy run` always creates a *new* deployment in a *new* Orchestrator folder — it never updates an existing one, and it cannot deploy into a folder that already exists (Orchestrator renames the folder instead, `MySolution` -> `MySolution 1`). So if the package is already deployed, the command stops and lists the existing deployments rather than quietly adding another folder. That check is best-effort, not a guarantee: a failed lookup only logs a warning, and a CI job signed in with an application (client-credentials) account is never stopped by it — an existing deployment is reported as a warning and the deploy goes ahead (on servers without the Pipelines deployment search the check is skipped, with a warning). In automation, track what you have already deployed instead of relying on the stop. To ship a new version, upgrade the existing deployment in place with `uip solution deploy upgrade <deployment-key>`; to start over, `deploy uninstall`, then `deploy delete` to clear the record it leaves in `deploy list` (that record does not block a redeploy — `blocksRedeploy` lets an uninstalled deployment through — so the delete is housekeeping, not a prerequisite). Pass `--yes` only when you really do want a second, independent copy, and give it a different `--name`: the install is keyed on the deployment name, so re-using an existing one updates that deployment in place instead. While you are still iterating, validate locally (`solution pack --dry-run`) instead of deploying each attempt.
 
 **Activation lifecycle.** `deploy run` activates by default. To split the steps:
@@ -162,14 +177,15 @@ uip solution deploy list
 uip solution deploy run --skip-activate ...                      # leaves "Inactive (Ready to activate)"
 uip solution deploy activate <deployment-name>     # activate later
 uip solution deploy uninstall <deployment-name> --yes   # remove the deployment + its resources (--yes required; the CLI never prompts)
+uip solution deploy uninstall <deployment-name> --force # same, past uncompleted jobs and the permanent deletion of resources replaced by links (implies --yes)
 uip solution deploy delete <deployment-name> --yes      # remove what uninstall leaves behind (--yes required)
 ```
 
-`deploy run` reports `ActivationStatus: SuccessfulActivate` when the deployment runs. When the install landed but a resource needs "Setup activation" in Orchestrator first, it is still `Result: Success`, with `ActivationStatus: NeedsSetupToActivate`, `PendingResources` and `NextSteps` — the deployment exists, so do **not** run the deploy again; complete the setup, then `deploy activate`. `ReadyToActivate` in the same place means the install landed and the command could not activate it: run `deploy activate`.
+`deploy run` reports `ActivationStatus: SuccessfulActivate` when the deployment runs. When the install landed but a resource needs "Setup activation" in Orchestrator first, it is still `Result: Success`, with `ActivationStatus: NeedsSetupToActivate`, `PendingResources` and `NextSteps` — the deployment exists, so do **not** run the deploy again; complete the setup, then `deploy activate`. When the server already reports that state after the install, `deploy run` does not try to activate (the service would refuse it). `ReadyToActivate` in the same place means the install landed and the command could not activate it: run `deploy activate`.
 
 `uninstall`, `delete`, `activate` and `status` take the deployment **name** as a positional argument (no `--name` flag). `status` also accepts a **deployment key** (from `deploy list` or `deploy upgrade` — the form that diagnoses a stale key) or the **pipeline deployment ID** from `deploy run` (that run's progress and errors, `Code: SolutionDeployStatus`); by name or key it answers `Code: SolutionDeployment` and reports the record's `Operation`, `OperationStatus`, `ActivationStatus`, `Actions`, and `NextSteps` when it is not live. A name is found across feeds; a key outside the tenant feed needs `--personal-workspace` or `--feed <name-or-key>`, as with `deploy list`. `Superseded: null` means the CLI could not tell — the chain search failed or holds no row for the key — and the fields are the requested record's own; take the current key from `deploy list`.
 
-**Two status axes.** `OperationStatus: Successful` means the last operation's content landed. `ActivationStatus: Active` means the deployment runs. An upgrade can land `Successful` *and* `NeedsSetupToActivate`: the new version is installed but does not run until "Setup activation" is completed in Orchestrator (Tenant > Solutions > Deployments); the previous version keeps running meanwhile. The UI words the same states differently: `NeedsSetupToActivate` shows as **Inactive (Needs setup)**, `Operation: VersionChange` as **Change version**, `Operation: ActivationSetup` as **Activation setup** — and the UI lists every record of a deployment, where `deploy list` shows only the newest. `deploy upgrade` reports both axes; when not `Active` it adds `PendingResources` (the resources the service flags as needing configuration — Integration Service connections, typically — each with the `Reason` the activation validation gives, such as a connection that needs authenticating) and `NextSteps`. "Setup activation" has no CLI command **on an existing deployment**: `deploy config link` maps a resource to an existing one only in the config file a new `deploy run` consumes, `deploy upgrade` takes no config file, and the `resource`/`resources` verbs edit the solution project, not a deployment. `deploy activate` is refused (`4007 … cannot be activated`) until the setup is done in Orchestrator.
+**Two status axes.** `OperationStatus: Successful` means the last operation's content landed. `ActivationStatus: Active` means the deployment runs. An upgrade can land `Successful` *and* `NeedsSetupToActivate`: the new version is installed but does not run until "Setup activation" is completed in Orchestrator (Tenant > Solutions > Deployments); the previous version keeps running meanwhile. The UI words the same states differently: `NeedsSetupToActivate` shows as **Inactive (Needs setup)**, `Operation: VersionChange` as **Change version**, `Operation: ActivationSetup` as **Activation setup** — and the UI lists every record of a deployment, where `deploy list` shows only the newest. `deploy upgrade` reports both axes; when not `Active` it adds `PendingResources` (the resources the service flags as needing configuration — Integration Service connections, typically — each with the `Reason` the activation validation gives, such as a connection that needs authenticating, and the Orchestrator `FolderPaths` it lives in when the server reports them) and `NextSteps`. On current servers this works the same for an external app (CI/CD) as for a user session; on older servers an external app may see `ActivationStatus` without `PendingResources`, and `NextSteps` say the resources could not be read. "Setup activation" has no CLI command **on an existing deployment**: `deploy config link` maps a resource to an existing one only in the config file a new `deploy run` consumes, `deploy upgrade` takes no config file, and the `resource`/`resources` verbs edit the solution project, not a deployment. `deploy activate` is refused (`4007 … cannot be activated`) until the setup is done in Orchestrator.
 
 **A key is one record, not the deployment.** Every operation creates a new deployment record with its own key: `deploy run` the Install record, `deploy upgrade` a VersionChange one (`DeploymentKey` in its output; `InstallDeploymentKey` is the one that never changes). `deploy list` shows the newest per deployment. A key from before an upgrade is *superseded*: the Solutions record still answers as it was — old version, `Active`, `Upgrade` offered — but `deploy upgrade <key>` resolves it to the deployment's current generation through the Pipelines lookup and upgrades that, and `deploy status <key>` reports `Superseded: true` with `CurrentDeploymentKey`. Store `InstallDeploymentKey`, or take the current key from `deploy list`.
 
@@ -183,11 +199,13 @@ uip solution deploy delete <deployment-name> --yes      # remove what uninstall
 
 So a full clean-up of a live deployment is two commands: `uninstall` removes its resources and folder, `delete` then removes the deployment itself. `delete` reads the action list first, and when the record lists actions but not `Delete` it says so and names the command to run instead — it never sends a request the state forbids. A record that lists **no** actions is the exception: nothing is known about it, so the request goes out and the server answers.
 
+`delete` works from CI/CD: an external app (client-credentials) login deletes tenant-feed records on servers with the Pipelines delete route. On an older server a user session still deletes, while an external app is refused (`ErrorCode: permission_denied`, `Retry: RetryWillNotFix`) with nothing deleted — run that delete with a user session. A draft still being validated cannot be deleted yet (`Retry: RetryLater`): wait for its run to finish, then retry.
+
 `uninstall` waits out an operation that blocks it: when Orchestrator refuses because the deployment still has something running, the CLI polls until that finishes and then sends the request again, all inside `--timeout` (which covers the whole command, the status poll included). If it is still busy when the timeout expires you get exit `2` with `ErrorCode: timeout` and `Retry: RetryLater` — retry later, do not treat it as permanent. A refusal for any other reason (superseded, inactive, unknown name) still fails immediately with exit `1`.
 
-Neither `uninstall` nor `activate` takes a feed flag, and neither needs one: they find the deployment themselves — tenant feed first, then your Personal Workspace, then the folder feeds you can reach — and scope their requests to whatever feed holds it. So the `deploy activate <name>` that `--skip-activate` points you at works the same on a `--personal-workspace` or `--feed` deployment as on a tenant one. The cost is one extra lookup per call, and a name that exists in no feed you can see is reported as not found rather than as a blocked uninstall.
+`uninstall` and `activate` do not need a feed flag: without one they find the deployment themselves — tenant feed first, then your Personal Workspace, then the folder feeds you can reach — and scope their requests to whatever feed holds it. So the `deploy activate <name>` that `--skip-activate` points you at works the same on a `--personal-workspace` or `--feed` deployment as on a tenant one. The cost is a lookup per feed until the name is found, and a name that exists in no feed you can see is reported as not found rather than as a blocked uninstall. When you know the feed, pass it: `uninstall`, `activate` and `delete` take `--personal-workspace` or `--feed <name-or-key>` and then search that feed alone. The commands the CLI prints as next steps already carry the flag for the feed the deployment was found in. With either flag, an external-app (client-credentials) login is refused for any feed but the tenant's, because the server ignores the feed header for it.
 
-`deploy delete` and `deploy status <name>` (without a feed flag) find a name the same way. All four say "not found" only when every feed answered — with one exception: under an external-app login, `deploy status <guid>` for a GUID that is no deployment key still says "not found" when only the feeds after the tenant could not be searched, or when the tenant search refused the login (401/403), because an app login cannot read those feeds at all. When a feed cannot be searched — the feed service is down or refuses the session, the list of feeds cannot be read or gives a feed no key, or the tenant search itself fails — and no other feed has the name, they fail with a message that names the feeds they could not search instead of calling the name unknown. `ErrorCode` then comes from that failure (`server_error`, `network_error`, `authentication_required`, `permission_denied`, …, or `unknown_error` when it has no known class) and is never `not_found`; `Retry` follows it — `RetryLater` for an outage, `RetryWillNotFix` for a 401 or 403, and also `RetryWillNotFix` when every feed that could not be searched is one the list gives no key, since a retry gets the same list. Do not treat the name as wrong: do what `Instructions` say (log in again, fix the session's access, or retry later). To check one feed yourself, pass `--personal-workspace` or `--feed <name-or-key>` to `deploy status` or `deploy list` — but `--feed` is resolved through the same list of feeds, so when that list is what failed only `--personal-workspace` helps, and `--feed` cannot pick a feed the list gives no key. When the tenant feed refuses an `activate` or `uninstall` for its own reason (401, 403, 409, 422, 429, a 5xx), that failure is reported as it is.
+`deploy delete` and `deploy status <name>` (without a feed flag) find a name the same way. All four say "not found" only when every feed answered — with one exception: under an external-app login, `deploy status <guid>` for a GUID that is no deployment key still says "not found" when only the feeds after the tenant could not be searched, or when the tenant search refused the login (401/403), because an app login cannot read those feeds at all. When a feed cannot be searched — the feed service is down or refuses the session, the list of feeds cannot be read or gives a feed no key, or the tenant search itself fails — and no other feed has the name, they fail with a message that names the feeds they could not search instead of calling the name unknown. `ErrorCode` then comes from that failure (`server_error`, `network_error`, `authentication_required`, `permission_denied`, …, or `unknown_error` when it has no known class) and is never `not_found`; `Retry` follows it — `RetryLater` for an outage, `RetryWillNotFix` for a 401 or 403, and also `RetryWillNotFix` when every feed that could not be searched is one the list gives no key, since a retry gets the same list. Do not treat the name as wrong: do what `Instructions` say (log in again, fix the session's access, or retry later). To check one feed yourself, pass `--personal-workspace` or `--feed <name-or-key>` to `deploy status` or `deploy list`, or to the `activate`, `uninstall` or `delete` you meant to run — but `--feed` is resolved through the same list of feeds, so when that list is what failed only `--personal-workspace` helps, and `--feed` cannot pick a feed the list gives no key. When the tenant feed refuses an `activate` or `uninstall` for its own reason (401, 403, 409, 422, 429, a 5xx), that failure is reported as it is.
 
 ## Dependency Feeds
 
@@ -236,15 +254,17 @@ The analyzer rule configuration comes from whichever governance flag you use. `-
 
 `--automation-ops-profile` is the old name for `--governance-product`. It still works and still parses, but it is hidden from help and warns; passing both is rejected rather than resolved. Use `--governance-product` in anything new.
 
-Whenever you are signed in, the tenant is asked first — including when you pass `--governance-file-path`. There are three possible answers and each does something different:
+Whenever you are signed in as a user, the tenant is asked first — including when you pass `--governance-file-path`. There are three possible answers and each does something different:
 
 - **The tenant publishes a policy.** That policy is what the analyzer uses, whatever else you passed. A `--governance-file-path` alongside it is not used, and `--ignored-rules` is not applied; each gets a warning and the pack carries on — a flag in your own pipeline does not lift the organisation's policy.
 - **The tenant publishes nothing.** The analyzer uses your `--governance-file-path` if you passed one, otherwise the rules shipped with the WorkflowCompiler.
-- **The question could not be answered** (expired token, no route, the service is down). The pack still succeeds and nothing fails: you get a warning naming the reason (`unauthorized`, `notFound`, `serverError`, `timedOut`, …), shown only at `--log-level warn` or lower (see below), and the analyzer uses your `--governance-file-path` if you passed one, otherwise the shipped rules. Not knowing whether you are governed is not a reason to break a build.
+- **The question could not be answered** (expired token, no route, the service is down). The pack still succeeds and nothing fails: you get a warning naming the reason (`unauthorized`, `notFound`, `serverError`, `timedOut`, …), shown at the default `--log-level warn` (see below), and the analyzer uses your `--governance-file-path` if you passed one, otherwise the shipped rules. Not knowing whether you are governed is not a reason to break a build.
 
 With no signed-in tenant there is nothing to ask, so a `--governance-file-path` is simply used and an offline pack keeps working.
 
-Note what this means for CI: a pack that could not reach AutomationOps still returns `Result: Success` and exit `0`, so a stage using `--governance-product` as a governance gate goes green while having enforced the shipped defaults. The warning in the log is what tells you which happened — `uip solution pack` reports on governance, it does not enforce it. That warning is a `warn`-level log line, and the default `--log-level` is `error`, which hides it. A stage that needs to know passes `--log-level warn` and reads stderr. To read it from a file instead, pass `--log-file <path>` together with `--log-level warn`: the level filter runs before a line is sent to the file, so `--log-file` alone still drops the warning. Strict, fail-closed behaviour belongs to design-time hosts, not to this command.
+When you are signed in as an external application, the tenant is not asked: AutomationOps does not accept external-application tokens yet. The pack behaves as when the question could not be answered — your `--governance-file-path` if you passed one, otherwise the shipped rules — and the warning names the reason `applicationLogin`.
+
+Note what this means for CI: a pack that could not reach AutomationOps still returns `Result: Success` and exit `0`, so a stage using `--governance-product` as a governance gate goes green while having enforced the shipped defaults. The warning in the log is what tells you which happened — `uip solution pack` reports on governance, it does not enforce it. That warning is a `warn`-level log line. It shows on stderr at the default `--log-level`, which is `warn`; `--log-level error` hides it. A stage that needs to know reads stderr, or passes `--log-file <path>` to read it from a file. Do not combine `--log-file` with `--log-level error`: the level filter runs before a line is sent to the file, so the warning is dropped. Strict, fail-closed behaviour belongs to design-time hosts, not to this command.
 
 ## Dependency Feeds
 
@@ -343,6 +363,12 @@ uip solution projects resync <cloud-project-name> --sync-option Reset
 
 Each project declares the resources it needs (assets, queues, buckets, processes, …) in a `bindings_v2.json` file at the project root. These declarations drive the solution's resource inventory.
 
+A Flow project is the exception: its bindings live in its `.flow` file, including bindings used only by subflow nodes. `uip maestro flow nodes create`, `delete` and `configure` also maintain a derived `bindings_v2.json` beside the `.flow`. `resources refresh`, `pack` and `upload` read the `.flow` and ignore that derived file, even after a hand edit. To change what a Flow binds, edit the `.flow` or use `uip maestro flow nodes configure`. The sync also builds inline agents and includes their bindings in the solution resources. The solution-root `bindings_v2.json` is shared across projects and is always read once, even when a Flow project lives at the solution root. For a root-level Flow without a `.flow`, shared bindings stay with the solution and out of the Flow package; only its own inline-agent bindings belong to the Flow. A sibling Agent project is packed separately.
+
+The source is selected by `project.uiproj`'s `MainFile`, then the project name, then the usual `.flow` search in the root, `content/` and `flow_files/`. An unreadable `.flow` never falls back to a stale binding file; it produces a refresh warning and stops pack/upload, so fix the named `.flow` before retrying. A Flow project with no `.flow` may instead author `bindings_v2.json`; refresh reads it because packaging preserves it. An inline agent build failure names the agent files rather than blaming the `.flow`. A Flow's selected source and every `$ref` chunk must resolve inside that Flow's project directory, including through symlinks. Refresh warns and contributes no bindings for an outside source or chunk; pack and upload stop. Move shared chunks into the project before retrying.
+
+Packaging stages the selected source after copying other files and inlines its `$ref` chunks from their original paths, so a same-named file or a moved source cannot change the bindings it reads.
+
 `projects add` and `projects import` do not always create the project's resources. Some project types (a coded app, for example) pick their resource template from a file only their own tool can read, so these commands register the project and stop. They report `Data.ResourcesPending: true` and warn when that happens, naming the tool to install (`uip tools install codedapp` for a coded app) — the resources arrive at the next `resources refresh`, `pack` or `upload`.
 
 After editing a project's bindings, or after `solution projects import` (which doesn't auto-sync resources), reconcile the solution-level inventory:
@@ -353,8 +379,14 @@ uip solution resources refresh     # re-scan every project, sync new / removed r
 
 `solution resources refresh` creates new resources for bindings not yet in the solution and imports from Orchestrator when a matching resource already exists.
 
+It also generates or regenerates each project's own resources (its `package` and `process`, for example) — on the first run, and again after a project rename or type change. The output counts these apart from the binding counts: `Data.Created`, `Data.Imported` and `Data.Skipped` count bindings only, and `Data.ProjectResourcesCreated` counts the project resources this run generated or regenerated; resources the regeneration removes are not counted. A rerun with nothing new reports `0`. `Status` names this count too (`, N project resources generated`) when it is above `0`.
+
 **Refresh is import-only for cloud resources. It never overwrites an imported resource** — that is what keeps your local edits (a renamed resource, a patched retry count) from being wiped on every re-scan. So if you change an entity, queue or asset **in the cloud** after importing it, `refresh` will not pick the change up: it reports the resource under `Skipped` and leaves it alone. To pull the new cloud definition, use `resources edit --source remote` (below).
 
+**A failed Resource Catalog call is not a "not found".** `resources refresh`, `pack`, `upload`, `projects add` and `projects import` look each binding up in the Resource Catalog. When that lookup fails — the catalog refuses the login with 401/403, it is unreachable, or (for `pack`, which runs without a login) there is no login — nothing is created for the binding, because a local stub would deploy as a new, empty resource instead of the one in the cloud. The same goes for a resource the catalog found but whose import was refused. A binding the solution already holds keeps that resource as it is. Refresh reports what it could not check in `Data.Warnings` and exits `0`; `projects add` / `import` log it as a warning. `pack` and `upload` fail when a binding the solution does **not** hold could not be resolved: `ErrorCode: permission_denied` for a refused login (`Retry: RetryWillNotFix`), `server_error` or `rate_limited` (`Retry: RetryLater`) when the catalog is down or throttling, and — `pack` only — `authentication_required` with no login. `resources refresh` and `upload` check the login before they start, so with no login they fail on that check instead, as before. After no login or a 401/403 the rest of the bindings are not looked up. From CI/CD, run `uip solution resources refresh` under a login the catalog accepts (a user login), commit the solution's resources, and the pipeline's `pack` then uses them as they are. An import that fails for any other reason still falls back to a local resource, and says so in the warnings.
+
+`pack` and `upload` also stop if a project's contributed bindings are invalid. Fix the project's source file or inline agent and retry; these commands do not ship a solution with missing resources.
+
 Each project's own tool also reports what its authored files add to the solution
 resources — for a Coded Action app, its `action-schema.json` lands on the app
 resource's `spec.actionSchema`. Two things follow:
@@ -370,10 +402,85 @@ resource's `spec.actionSchema`. Two things follow:
   `ErrorCode: invalid_argument`.
   Nothing is written before that check passes, so fix the file and re-run the command.
 
+For project types whose resources do not depend on a tool contribution, refresh
+does not warn when the installed tool has nothing to contribute. Use
+`--log-level debug` to see that diagnostic. An `AppV2` coded app does require its
+tool's contribution: if it is missing, refresh warns and pack/upload fail with
+`contribution_unavailable`. Run `uip tools install codedapp`, then try again.
+
 An `action-schema.json` edited without a following `refresh` or `pack` still
 shows the previous schema in `uip solution resources get`; the next pack or
 refresh rewrites it, so the packed solution is never stale.
 
+`uip codedapp init <path> --type Action` writes a valid starter
+`action-schema.json`, so a freshly scaffolded Coded Action packs without being
+edited first. It is never overwritten on a re-run — your own schema is the one
+that matters.
+
+### A coded app's build output
+
+A coded app's packed payload is a **folder that is already built**: nothing in
+`uip solution pack` runs the app's build, so a CI pipeline has to run its
+`npm run build` (or equivalent) first. Which folder gets packed is
+`config.bundlePath` in the app's `webAppManifest.json`, relative to the project
+directory — `source/dist` for an app `uip codedapp init` scaffolded inside a
+solution, `dist` for a standalone one.
+
+Pack **fails** when that folder holds no HTML entry point (`index.html`,
+`main.html` or `app.html`, unless `config.mainFile` selects another HTML file),
+naming the path and both ways out. That used to
+succeed and ship an app that could not start, so if you see this failure the
+answer is to build the app or repoint `config.bundlePath` — not to retry.
+
+Coded app entry points declared in `config.mainFile` must be HTML files inside
+the bundle; absolute paths and parent segments are refused by the shared packager.
+When adopting an app with `codedapp init --force`, `config.bundlePath` must name
+a child build folder, never the project root or a parent. Standalone
+`codedapp pack <dist>` uses that selected folder for preview and packaging,
+and preserves the project identity written by the packager. Its bundle and entry
+selection stays in memory and in the package. Only a missing project ID is
+persisted to the project manifest. `config.mainFile`, when present, must be a string.
+When a coded app has an authored `entry-points.json`, pack updates its primary
+entry's `filePath` in the archive to match the selected HTML file, preserving
+the other metadata and leaving the project file unchanged.
+Child bundle paths are checked after aliases resolve during adoption and again
+at pack time. They cannot point to the project root or outside it. An explicitly
+selected external positional folder in `codedapp pack` remains supported.
+
+### Bringing an app you already have into a solution
+
+To register a web app that already exists — one with its own sources and build
+at the project root, not the `source/` layout `init` writes — run
+`uip codedapp init <path> --force` on it. With an app already there (an
+`index.html`, or a `package.json` declaring a build script), init **adopts** it
+instead of writing a starter: it writes only `project.uiproj` and
+`webAppManifest.json`, leaves every other file alone, and sets
+`config.bundlePath` to the app's own build output. The result's
+`Data.AdoptedApp` reports the path it chose and where it came from —
+`build-output` (a folder it found), `existing-manifest` (a value already
+declared, which wins) or `default` (nothing is built yet, so the value is a
+guess and `NextSteps` says so — check it before you pack; for an app with no
+build script it also says the folder will not appear on its own, so set
+`config.bundlePath` yourself).
+
+One exception to a declared value winning: if an earlier `init --force` on
+an older CLI wrote a starter into `source/` over your app and pointed
+`config.bundlePath` at it, that value is ignored and the probe runs instead,
+with `NextSteps` saying so. It is recognised by the starter page's own
+markup, so an app that genuinely builds into `source/dist` — or one where
+you have since built over the starter — keeps its declared path. Without it the solution would keep packing
+`Result: Success` while shipping the starter, because the starter has an
+`index.html` of its own. Delete the leftover `source/` once a pack looks
+right.
+
+Re-running `init` over a project that already has a `webAppManifest.json`
+merges into it rather than rewriting it: `config.bundlePath` is applied and
+everything else — including the `projectId` a pack writes to keep the
+packaged app's identity stable — is carried through. Omitting `--type` on a
+re-run means "leave the variant alone": an existing Coded Action stays one,
+schema and artefact subtype included. Passing `--type Action` over a plain
+coded app still upgrades it.
+
 ### Adding a resource by hand
 
 A resource is either **virtual** — declared locally now, provisioned when the solution deploys — or **imported**, pointing at something that already exists in Orchestrator. `--source` picks which:
@@ -432,6 +539,8 @@ uip solution resources edit <resource-key> --source remote --force   # apply it
 uip solution resources remove <resource-key>
 ```
 
+`get` reads the solution first. Only a key the solution does not declare is read from the tenant instead (the resource catalog, then an export). Any other local failure is reported as it is and exits `1`; it is never answered with a tenant copy of the same key, so fix the solution rather than retrying.
+
 ### Picking up a cloud change: `edit --source remote`
 
 Use this when the resource changed **in Orchestrator or Data Fabric** after you imported it — a new field on an entity, a changed queue setting — and `refresh` reported it under `Skipped`.
@@ -566,17 +675,21 @@ Adjacent groups commonly used alongside solutions:
 |---|---|
 | `Not authenticated` / 401 | `uip login`, then re-run |
 | `upload` fails with 401/403 and `ErrorCode: permission_denied` | Not a login problem — the token was valid when the call went out, so `uip login` mints the same one. Read `Instructions`: for a session on an external application, check that the app has the Studio Web (`StudioWebS2S`) grants, not only the Orchestrator and Solutions ones; for a user, check Studio Web access in the tenant. Then confirm the `SolutionId` in the `.uipx` belongs to the tenant you are logged into — one from another tenant is refused, not reported missing |
-| `packages list` or `deploy list` fails with `ErrorCode: permission_denied` from a CI/CD pipeline | `packages list` reads the Solutions search, which accepts user sessions only, so an external app's client-credentials token is refused (the message says so). `deploy list` reads the deployment search, which accepts an external app on servers that serve `POST /v1/pipelines/deployments/search`; it is refused only on an older server, or with `--personal-workspace` or a folder `--feed`, whose feed the server ignores for an app. `uip login` with the same app mints the same kind of token; run the listing under a user session. The same goes for `--personal-workspace` on any command: an external app has no Personal Workspace. |
+| `packages list` or `deploy list` fails with `ErrorCode: permission_denied` from a CI/CD pipeline | Both accept an external app on servers that serve their Pipelines search (`POST /v1/pipelines/packages/search`, `POST /v1/pipelines/deployments/search`). An app is refused only on an older server, which has just the user-only search (the message says so), or with `--personal-workspace` or a folder `--feed`, whose feed the server ignores for an app (a `--feed` naming the tenant feed works). A `--feed` is checked against the Studio Web publish locations, so an app needs a `StudioWebS2S` grant for it; the message names it when that lookup is refused. `uip login` with the same app mints the same kind of token; run the listing under a user session, or drop the feed flag to list the tenant feed. The same goes for `--personal-workspace` on any command: an external app has no Personal Workspace. |
+| `pack` or `upload` fails with `ErrorCode: permission_denied` (or `pack` with `authentication_required`) and a message naming the Resource Catalog | The catalog refused the login (or there was none), so bindings the solution does not hold yet could not be resolved, and the command will not pack them as empty stubs. Run `uip solution resources refresh` under a user login, commit the solution's resources, then re-run. Bindings already in the solution are fine as they are |
 | Command targets the wrong tenant | `uip login tenant set <tenant>`; verify with `uip login status` |
 | Pack succeeds but publish 409s | Version conflict — bump the version (`uip solution pack . ./out -v <new-version>`) or delete the colliding version with `uip solution packages delete <package-name> <version> --yes` (only if intentional; `--yes` required) |
 | `deploy run` stops because the package is already deployed | Upgrade it in place with `uip solution deploy upgrade <deployment-key>` (running `deploy run` again does not upgrade it), or `uip solution deploy uninstall <name> --yes` then `uip solution deploy delete <name> --yes` first, or pass `--yes` with a different `--name` to create a second, separate deployment (re-using the name updates the existing one in place) |
 | `HTTP 400 … cannot be uninstalled` (error `4007`) | The deployment is not uninstallable in its state — superseded, already uninstalled, or left by a failed install. Read `Instructions`: when its `Actions` list offers `Delete`, remove the record with `uip solution deploy delete <name> --yes`. An operation still running is the other cause, and that one clears by itself (`Retry: RetryLater`) |
+| `deploy uninstall` fails with `Message` "Uninstall failed with status: FailedUninstall: this deployment has uncompleted jobs…" or "…permanently deletes these resources and their data: …", or "Deployment '<name>' was not uninstalled: …" | Orchestrator wants explicit consent: the deployment has uncompleted jobs (`Data.JobsNotInFinalState: true`), or uninstalling it permanently deletes resources that were replaced by links (`Data.PermanentDeletionResources`; the "was not uninstalled" form is the synchronous HTTP 409, error `4026`). Re-run with `--force` only if that is acceptable; otherwise let the jobs finish first. Retrying without `--force` does not help (`Retry: RetryWillNotFix`) |
+| `deploy uninstall` fails with `Message` "Deployment '<name>' was not uninstalled: its Uninstall validation reports errors that --force cannot get past: …" | The deployment also awaits the permanent-deletion confirmation, but its validation holds an error `--force` does not skip (named after the colon, with its code). Resolve that in Orchestrator and run the uninstall again without `--force` (`Retry: RetryLater`); it then asks for the confirmation on its own |
 | `deploy upgrade` reported `Status: DeploymentSucceeded` but the old version still runs | Read `DeploymentStatus` and `ActivationStatus` in the same output. `SuccessfulInstall` / `NeedsSetupToActivate` means the new version is installed and waits for "Setup activation" in Orchestrator; `PendingResources` names what needs configuring and why (`Reason`, from the activation validation, e.g. `[CNS1072] You will need to authenticate this connection before proceeding further`) and `NextSteps` the step. `ReadyToActivate` means `uip solution deploy activate <name>` is all that is left. Do not run the upgrade again — the content is already there |
 | `Another upgrade has already started for this deployment` (error `4005`) | The key you passed is superseded by a later record; nothing is running. The CLI names the current record — use that key (`uip solution deploy list` shows it). If the current record is already at the version you want, there is nothing to upgrade |
 | `deploy run` succeeded with `ActivationStatus: NeedsSetupToActivate` and the deployment does not run | Expected: the install landed, and a resource needs "Setup activation" in Orchestrator before activation. `PendingResources` names what needs configuring and why (`Reason`, from the activation validation, e.g. `[CNS1072] You will need to authenticate this connection before proceeding further`) and `NextSteps` the step. `Status` may read `ValidationFailed` there: that is the pipeline's word for the activation validation it ran after the install, and `NextSteps` open with its errors. Do not deploy again (the deployment exists); complete the setup, then `uip solution deploy activate <name>` |
 | `deploy activate` refused with `cannot be activated` (error `4007`) on an installed deployment | The deployment needs "Setup activation" first (`ActivationStatus: NeedsSetupToActivate`); `Instructions` list the resources that need configuration. Complete the setup in Orchestrator, then activate. `deploy status <key>` shows the same state |
 | `deploy run` fails on a resource conflict | `uip solution deploy config link config.json <resource> --name <existing> --folder-path <path>` to map to the existing one, or change `conflictFixingAction` via `config set` |
 | The deployment is stuck in `Draft` and `deploy activate` won't take it | Read `Operation` first. `ActivationSetup` + `Draft` is a "Setup activation" someone started in Orchestrator and did not finish — complete it there (the UI lists it as `Activation setup · Draft`); `deploy status <key>` names the resources it waits for. To discard it instead, `uip solution deploy delete <name> --yes` removes the draft alone and the deployment returns to its previous record (still needing setup). `VersionChange` + `Draft` is an upgrade queued and never installed. An `Install` `Draft` is a deploy whose install never completed — validation rejected something. It never advances on its own (a deployment passes through `Draft` for a moment right after you fire the command, but not once the command has returned). The reasons are in the failure's `Instructions` (`Validation:` / `Conflicts:`) on every feed, next to the draft's key; fix them with `uip solution deploy config set` / `deploy config link`, then run your original `uip solution deploy run …` again with `--config-file config.json` added and the **same** `--name` and `--package-version` — it still needs `--package-name` and `--folder-name`. A `Draft` left by an install does not block that rerun; one left by an update of a live deployment needs `--yes`, because the package is already deployed. While a draft exists any other version is refused, `deploy upgrade` included — to drop it instead, run `uip solution deploy upgrade <draft-key> --discard-draft`, or Delete draft in Orchestrator. To look at it, `uip solution deploy list` needs the same `--personal-workspace` / `--feed <name-or-key>` flag the deploy used — plain `deploy list` is tenant-scoped and shows no row for those deployments at all |
+| `Resource key <key> is used by: <file>, <file>` (or `Node already added to the graph` from an older CLI) | Two resource files carry one key. Keep the file whose `name` other resource files and the projects' bindings reference, delete the rest, then run `uip solution resources refresh`. For `(missing)` or `""`, the files are different resources: give each its own unique `key` instead of deleting |
 | `Resource not found` after deploy | `uip solution resources refresh` to re-sync from each project's `bindings_v2.json`; if still missing, the resource was never declared in any project |
 | A cloud change (new entity field, changed queue setting) never reaches the solution | Expected: `refresh` is import-only and reports the resource under `Skipped`. Pull it with `uip solution resources edit <resource-key> --source remote --force` |
 | Output looks empty | You may have redirected stderr — confirmations and errors go there. Re-run without `2>` |

package/dist/tool.js

@@ -1,34 +1,32 @@
 import {
   metadata,
   registerCommands
-} from "./packager-tool-fehvgd51.js";
-import"./packager-tool-v8bkkqdb.js";
-import"./packager-tool-9ex75r32.js";
-import"./packager-tool-kdwsw2x7.js";
-import"./packager-tool-ds45xby2.js";
-import"./packager-tool-gfhdpkp3.js";
-import"./packager-tool-4gs8y6pr.js";
-import"./packager-tool-px1j9kre.js";
-import"./packager-tool-wfkv9v8b.js";
-import"./packager-tool-gab9y5ct.js";
-import"./packager-tool-1rzssy0x.js";
-import"./packager-tool-e2rtr49j.js";
-import"./packager-tool-zns6n8zp.js";
-import"./packager-tool-g8kjzrg7.js";
-import"./packager-tool-7gr2nphb.js";
-import"./packager-tool-stsnbewn.js";
-import"./packager-tool-j3520gxw.js";
-import"./packager-tool-bqre28m1.js";
-import"./packager-tool-yrz4mwfn.js";
-import"./packager-tool-gdtpsdn7.js";
-import"./packager-tool-53w8skv5.js";
-import"./packager-tool-fv7xyzg2.js";
-import"./packager-tool-f5gq77m5.js";
-import"./packager-tool-zdfn32bc.js";
-import"./packager-tool-f2e9rzxk.js";
-import"./packager-tool-kswwd3hp.js";
-import"./packager-tool-gb35b4qs.js";
-import"./packager-tool-zf3929se.js";
+} from "./packager-tool-e7vczxa8.js";
+import"./packager-tool-kkfb5kgn.js";
+import"./packager-tool-amhyxzz6.js";
+import"./packager-tool-gmwva4yv.js";
+import"./packager-tool-8q4tvv8d.js";
+import"./packager-tool-q5j6k3fy.js";
+import"./packager-tool-y2k2f6yg.js";
+import"./packager-tool-4bq36bf5.js";
+import"./packager-tool-qk21gk5m.js";
+import"./packager-tool-m74zqwmh.js";
+import"./packager-tool-act5r386.js";
+import"./packager-tool-dwxswyv4.js";
+import"./packager-tool-3bwnkjdq.js";
+import"./packager-tool-gs3f3tf7.js";
+import"./packager-tool-wknfv4p5.js";
+import"./packager-tool-6x35kvbx.js";
+import"./packager-tool-97rcgwvv.js";
+import"./packager-tool-an5bpbwe.js";
+import"./packager-tool-qw47eyw7.js";
+import"./packager-tool-61pwb567.js";
+import"./packager-tool-8ptbmmmp.js";
+import"./packager-tool-5edvzz80.js";
+import"./packager-tool-43ahv5mn.js";
+import"./packager-tool-tx834spe.js";
+import"./packager-tool-6ybywxxn.js";
+import"./packager-tool-v1f5e8t9.js";
 import"./packager-tool-dfrk01gn.js";
 import"./packager-tool-1de529jm.js";
 export {
@@ -36,4 +34,4 @@ export {
   registerCommands
 };
 
-//# debugId=A619C849012DC6F164756E2164756E21
+//# debugId=B0CD5F2BE1565ADD64756E2164756E21

package/dist/utils/deployment-errors.d.ts

@@ -1,4 +1,4 @@
-import type { PipelineDeploymentResult, WorkflowError } from "@uipath/pipelines-sdk";
+import type { DeploymentRunServiceStatus, PipelineDeploymentResult, WorkflowError } from "@uipath/pipelines-sdk";
 /**
  * Normalize the SDK's `DeploymentRunStatus.errorMessage` field into a
  * `WorkflowError[]` regardless of the runtime shape returned by the API.
@@ -36,6 +36,8 @@ export declare function extractDeploymentErrors(result: PipelineDeploymentResult
  *   Schedule: [SCHED_001] Cron expression invalid
  */
 export declare function formatDeploymentErrorsAsText(summary: DeploymentErrorSummary): string;
+/** The per-service lines for a run's `services`, empty when there are none. */
+export declare function formatServiceErrors(services: DeploymentRunServiceStatus[] | null | undefined): string[];
 export declare function formatDeploymentFailureDetails(pipelineDeploymentId: string, status: PipelineDeploymentResult): string;
 /**
  * The errors a pipeline attached to its terminal status, one line per
@@ -66,6 +68,12 @@ export declare function isBareResponse(details: string): boolean;
  * built for another version: a pending attempt stands in the way.
  */
 export declare const DRAFT_VERSION_MISMATCH_CODE = "DraftDeploymentHasDifferentPackageVersion";
+/**
+ * `ErrorCodes.Deployments.ValidationConfirmationRequired`: the run was refused
+ * because replacing installed resources with links permanently deletes them,
+ * and nobody acknowledged that. Reported as a schedule error's `errorCode`.
+ */
+export declare const VALIDATION_CONFIRMATION_REQUIRED_CODE = "4026";
 /**
  * Terminal statuses the pipeline reaches before it schedules the install. The
  * attempt's generation is then never promoted: it stays behind as a Draft,

package/package.json

@@ -2,7 +2,7 @@
     "name": "@uipath/solution-tool",
     "author": "UiPath",
     "license": "SEE LICENSE IN LICENSE.txt",
-    "version": "1.204.0",
+    "version": "1.205.0-preview.258",
     "description": "Create, pack, publish, and deploy UiPath Automation Solutions.",
     "repository": {
         "type": "git",
@@ -48,5 +48,5 @@
         "dist"
     ],
     "private": false,
-    "gitHead": "699c58dabb59414557755a8933bcbe40aa420df3"
+    "gitHead": "8f629ee9fa89abf94f197436a60cb3b9620f8b27"
 }

package/dist/deploy-delete-service-1zydyyhj.js

@@ -1,22 +0,0 @@
-import {
-  deleteDeploymentAsync
-} from "./packager-tool-nfmygm61.js";
-import"./packager-tool-gfhdpkp3.js";
-import"./packager-tool-4gs8y6pr.js";
-import"./packager-tool-7gr2nphb.js";
-import"./packager-tool-stsnbewn.js";
-import"./packager-tool-j3520gxw.js";
-import"./packager-tool-bqre28m1.js";
-import"./packager-tool-f5gq77m5.js";
-import"./packager-tool-zdfn32bc.js";
-import"./packager-tool-f2e9rzxk.js";
-import"./packager-tool-kswwd3hp.js";
-import"./packager-tool-gb35b4qs.js";
-import"./packager-tool-zf3929se.js";
-import"./packager-tool-dfrk01gn.js";
-import"./packager-tool-1de529jm.js";
-export {
-  deleteDeploymentAsync
-};
-
-//# debugId=BCFE0E491B8154C164756E2164756E21

package/dist/feed-scope-failure-2kndwpf6.js

@@ -1,18 +0,0 @@
-import {
-  resolveFeedScopeOrFailureAsync
-} from "./packager-tool-9ex75r32.js";
-import"./packager-tool-stsnbewn.js";
-import"./packager-tool-j3520gxw.js";
-import"./packager-tool-bqre28m1.js";
-import"./packager-tool-zdfn32bc.js";
-import"./packager-tool-f2e9rzxk.js";
-import"./packager-tool-kswwd3hp.js";
-import"./packager-tool-gb35b4qs.js";
-import"./packager-tool-zf3929se.js";
-import"./packager-tool-dfrk01gn.js";
-import"./packager-tool-1de529jm.js";
-export {
-  resolveFeedScopeOrFailureAsync
-};
-
-//# debugId=A12986041C239A2364756E2164756E21

package/dist/packager-tool-f2e9rzxk.js

@@ -1,104 +0,0 @@
-import {
-  catchError,
-  logger
-} from "./packager-tool-kswwd3hp.js";
-
-// ../solution-sdk/src/solution-file.ts
-var STUDIO_WEB_PROJECT_TYPE_OVERRIDES = {
-  ProcessOrchestration: "processOrchestration"
-};
-function normalizeProjectType(projectType) {
-  return STUDIO_WEB_PROJECT_TYPE_OVERRIDES[projectType] ?? projectType;
-}
-function toPortableRelativePath(relativePath) {
-  return relativePath.replace(/\\/g, "/");
-}
-async function readUipxFile(fs, solutionDir) {
-  const dirEntries = await fs.readdir(solutionDir);
-  const uipxFileName = dirEntries.find((f) => f.endsWith(".uipx"));
-  if (!uipxFileName) {
-    throw new Error(`No .uipx file found in ${solutionDir}. Run 'uip solution init' first.`);
-  }
-  const uipxContent = await fs.readFile(fs.path.join(solutionDir, uipxFileName), "utf-8");
-  if (!uipxContent) {
-    throw new Error(`Could not read .uipx file: ${uipxFileName} is empty or missing.`);
-  }
-  const [parseError, parsed] = catchError(() => JSON.parse(uipxContent));
-  if (parseError) {
-    throw new Error(`Invalid .uipx file: could not parse JSON in ${uipxFileName}.`);
-  }
-  const uipx = validateUipxFile(parsed, uipxFileName);
-  return { uipx, uipxFileName };
-}
-function validateUipxFile(parsed, uipxFileName) {
-  if (!isRecord(parsed)) {
-    throw new Error(`Invalid .uipx file: ${uipxFileName} must contain a JSON object.`);
-  }
-  if (typeof parsed.SolutionId !== "string" || !parsed.SolutionId.trim()) {
-    throw new Error("Invalid .uipx file: missing SolutionId.");
-  }
-  if (!Array.isArray(parsed.Projects) || parsed.Projects.length === 0) {
-    throw new Error("Invalid .uipx file: missing Projects.");
-  }
-  for (const [index, project] of parsed.Projects.entries()) {
-    if (!isRecord(project)) {
-      throw new Error(`Invalid .uipx file: Projects[${index}] must be an object.`);
-    }
-    if (typeof project.ProjectRelativePath !== "string" || !project.ProjectRelativePath.trim()) {
-      const pathHint = typeof project.Path === "string" ? " Found Path, but .uipx uses ProjectRelativePath." : "";
-      throw new Error(`Invalid .uipx file: Projects[${index}] is missing ProjectRelativePath.${pathHint} Use 'uip solution projects add' to add projects, or set ProjectRelativePath to the project file path, for example "Foo/project.uiproj".`);
-    }
-  }
-  return parsed;
-}
-function isRecord(value) {
-  return typeof value === "object" && value !== null && !Array.isArray(value);
-}
-function resolveSolutionDir(fs, inputPath) {
-  const resolved = fs.path.resolve(inputPath);
-  if (resolved.endsWith(".uipx")) {
-    return fs.path.dirname(resolved);
-  }
-  return resolved;
-}
-async function updateUipxSolutionId(fs, uipxPath, newSolutionId) {
-  const [readError, content] = await catchError(fs.readFile(uipxPath, "utf-8"));
-  if (readError || !content) {
-    logger.error(`Could not read .uipx file for update: ${readError?.message ?? "empty file"}`);
-    return;
-  }
-  const [parseError, parsed] = catchError(() => JSON.parse(content));
-  if (parseError) {
-    logger.error(`Could not parse .uipx file for update: ${parseError.message}`);
-    return;
-  }
-  parsed.SolutionId = newSolutionId;
-  const [writeError] = await catchError(fs.writeFile(uipxPath, JSON.stringify(parsed, null, 4)));
-  if (writeError) {
-    logger.error(`Could not update .uipx with new SolutionId: ${writeError.message}`);
-  } else {
-    logger.info(`Updated .uipx with Studio Web SolutionId: ${newSolutionId}`);
-  }
-}
-async function findSolutionFileUpward(fs, startDir) {
-  let dir = startDir;
-  while (true) {
-    const entries = await fs.readdir(dir);
-    const files = entries.filter((f) => f.endsWith(".uipx"));
-    if (files.length === 1) {
-      return fs.path.join(dir, files[0]);
-    }
-    if (files.length > 1) {
-      throw new Error(`Multiple .uipx files found in ${dir}. Please specify which solution file to use.`);
-    }
-    const parent = fs.path.dirname(dir);
-    if (parent === dir) {
-      throw new Error(`No .uipx solution file found (searched from ${startDir} to filesystem root)`);
-    }
-    dir = parent;
-  }
-}
-
-export { normalizeProjectType, toPortableRelativePath, readUipxFile, resolveSolutionDir, updateUipxSolutionId, findSolutionFileUpward };
-
-//# debugId=FD084AD2795A138064756E2164756E21

package/dist/packager-tool-resolver-6zwhec62.js

@@ -1,20 +0,0 @@
-import {
-  UnpackableProjectTypeError,
-  ensurePackagerTools,
-  isUnpackableProjectTypeError,
-  toolVerbForProjectType
-} from "./packager-tool-e2rtr49j.js";
-import"./packager-tool-zns6n8zp.js";
-import"./packager-tool-fv7xyzg2.js";
-import"./packager-tool-kswwd3hp.js";
-import"./packager-tool-zf3929se.js";
-import"./packager-tool-dfrk01gn.js";
-import"./packager-tool-1de529jm.js";
-export {
-  UnpackableProjectTypeError,
-  ensurePackagerTools,
-  isUnpackableProjectTypeError,
-  toolVerbForProjectType
-};
-
-//# debugId=C6DDCB8627A7967264756E2164756E21