@uipath/solution-tool 1.202.0 → 1.203.0-preview.160

package/dist/services/project-contributions.d.ts

@@ -0,0 +1,58 @@
+import { type CliErrorCode } from "@uipath/common";
+import { type IFileSystem } from "@uipath/filesystem";
+import { type ProjectContributionError, type ProjectResourceContribution } from "@uipath/solutionpackager-tool-core";
+export interface ProjectContributions {
+    /** Per project key (the `.uipx` `Id`), what that project's factory returned. */
+    byProject: Map<string, ProjectResourceContribution>;
+    /** Supported types whose registered factory has no `describeResourcesAsync`. */
+    skipped: string[];
+}
+export interface ApplyContributionsResult {
+    /** Number of artefact resources whose spec was rewritten. */
+    updated: number;
+    /** Patches that matched no resource, plus the collect-time skip notices. */
+    warnings: string[];
+}
+/**
+ * Every contributed error from one collect, in one throw. Carries
+ * `instructions` so `carriedInstructions` can lift them into the failure
+ * envelope instead of losing the actionable half.
+ */
+export declare class ProjectContributionsError extends Error {
+    readonly contributionErrors: readonly ProjectContributionError[];
+    readonly instructions?: string;
+    readonly errorCode: CliErrorCode;
+    /** The contributed `code`, when every error in the batch reports the same one. */
+    readonly contributionCode?: string;
+    constructor(errors: readonly ProjectContributionError[]);
+}
+/**
+ * Walk the `.uipx` and ask each project's registered tool factory what it
+ * contributes. One walk, one dispatch round — pack uses the same result for
+ * its gate and its write.
+ *
+ * Reads project files only, which `syncAndLog` never touches, so collecting
+ * before the sync and applying after it cannot see two different states.
+ */
+export declare function collectProjectContributions(solutionDir: string, fs?: IFileSystem): Promise<ProjectContributions>;
+/** Throws once with every collected error. Pack's gate. */
+export declare function assertNoContributionErrors(contributions: ProjectContributions): void;
+/**
+ * Contributed errors as flat strings. Refresh folds these into its
+ * `Warnings[]` — it is a sync command, not a gate, but it must not swallow
+ * them either. Pack remains the gate.
+ */
+export declare function contributionErrorMessages(contributions: ProjectContributions): string[];
+/**
+ * Merge every `specPatch` into the on-disk resources, and write the
+ * entry-point keys while we are here so they persist into the packed solution
+ * instead of existing only at GET.
+ *
+ * Writes go through the resource builder, so a save re-runs
+ * `ArtefactPairBindingProvider` — deliberate: it is what keeps the app+package
+ * linkage intact when this rewrites an app resource. Nothing is saved when
+ * nothing changed, which is what keeps a re-run byte-stable.
+ */
+export declare function applyProjectContributions(solutionDir: string, contributions: ProjectContributions, options?: {
+    failOnUnmatchedPatch?: boolean;
+}, fs?: IFileSystem): Promise<ApplyContributionsResult>;

package/dist/services/project-type-tools.d.ts

@@ -0,0 +1,6 @@
+/**
+ * The CLI verb that owns a project type, or `undefined` for a type nothing
+ * maps. Used to name the tool to install or update in an error or warning.
+ */
+export declare function toolVerbForProjectType(projectType: string): string | undefined;
+export declare function toolOwnedProjectTypes(): string[];

package/dist/templates/AGENTS.md

@@ -66,7 +66,7 @@ A solution can contain multiple projects of different types. The table below lis
 | `AppV2` | Coded App — web application | `uip codedapp init <path>` | `uipath-coded-apps` |
 | `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 — a single DMN decision. Ships as the `.dmn` file itself, not wrapped in a `.nupkg`, and the solution's `businessRule` resource points at it by file name. `restore` and `validate` are no-ops for this type. | no CLI scaffolding — authored in Studio Web | none |
+| `BusinessRules` | Business rule — one or more DMN decisions. Ships as a `.uirule`: an archive holding the project's `.dmn` files and the `entry-points.json` that names which decisions a caller may invoke and with what arguments. Not wrapped in a `.nupkg`, and the solution's `businessRule` resource points at it by file name. A project with no `entry-points.json` still ships as a bare `.dmn`, which exposes no arguments. `restore` and `validate` are no-ops for this type. | no CLI scaffolding — authored in Studio Web | none |
 | `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) |
 | `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,6 +81,13 @@ 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.
 
+**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`.
+
 ## End-to-End Lifecycle
 
 Run `uip login` first — most steps below need an authenticated session, including `solution pack` in some cases.
@@ -142,7 +149,7 @@ Add `--wait` when the next step needs the deployment settled:
 uip solution deploy run ... --personal-workspace --wait --timeout 300
 ```
 
-With `--wait` the command polls the deployment to a terminal state inside `--timeout`, reports `Status: "DeploymentSucceeded"` and drops `NextSteps` (there is nothing left to check). A terminal failure exits `1` and names the operation status; still running when the timeout expires exits `2` with `ErrorCode: timeout` and `Retry: RetryLater` — "may still be running", so retry or check `deploy list` rather than treating it as a failed install. Without `--wait` nothing changes, so poll `uip solution deploy list` yourself if you skip it.
+With `--wait` the command polls the deployment to a terminal state inside `--timeout`, reports `Status: "DeploymentSucceeded"` and drops `NextSteps` (there is nothing left to check). A terminal failure exits `1` as `Deployment '<name>' failed (OperationStatus: Failed): <reason>`, where the reason is the server's validation result (`the server reported no reason.` when it gives none). Still running when the timeout expires exits `2` with `ErrorCode: timeout` and `Retry: RetryLater` — "may still be running", so retry or check `deploy list` rather than treating it as a failed install. Without `--wait` nothing changes, so poll `uip solution deploy list` yourself if you skip it.
 
 **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: it reads the Solutions search, which needs a user session, so a CI job signed in with an application (client-credentials) account deploys without it, and a failed lookup only logs 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` first. Pass `--yes` only when you really do want a second, independent copy. While you are still iterating, validate locally (`solution pack --dry-run`) instead of deploying each attempt.
 
@@ -189,12 +196,26 @@ That last flag is strict on purpose, and that is what makes it easy to get wrong
 ```bash
 uip solution pack . ./out --skip-analyze                             # don't run the analyzer at all
 uip solution pack . ./out --governance-file-path ./policy.json       # analyze against a local policy file
-uip solution pack . ./out --automation-ops-profile StudioWeb         # analyze against the tenant policy
+uip solution pack . ./out --governance-product StudioWeb             # analyze against the tenant policy
 ```
 
 `--skip-analyze` turns off only the analyzer rules — the compiler still restores, compiles, and validates, so a broken project still fails the pack.
 
-The analyzer rule configuration comes from whichever governance flag you use. `--governance-file-path` reads a local policy file. `--automation-ops-profile` downloads the policy published in AutomationOps for the signed-in tenant; its value is the product to fetch (`StudioWeb`, `Development`, `Business`, …). With neither flag the analyzer uses the rules shipped with the WorkflowCompiler. The two are mutually exclusive. If the tenant policy can't be fetched — no session, or nothing published — the pack falls back to the shipped rules instead of failing. Note what that means for CI: the pack still returns `Result: Success` and exit `0`, so a stage using `--automation-ops-profile` as a governance gate goes green while having enforced the shipped defaults, not the tenant policy. Check the logs if the distinction matters.
+A failed pack says which project broke and where. Alongside `Message`, the envelope carries `Data.Projects` — one entry per member project with `Path` (its directory relative to the solution, `.` at the root), `Type`, `Result`, `Message` and `Findings`; each finding carries `Source` (`Analyzer`, `Validator`, `Compiler`, `Other`), `ErrorCode`, `Description`, `FilePath` and `ActivityIdRef` where the compiler reported one. Read `Data.Projects` rather than parsing `Message` — the message flattens every failed project into one sentence and names no file. A failure that belongs to no project at all (not logged in, no packager for a `Type`) has no `Data.Projects`.
+
+The analyzer rule configuration comes from whichever governance flag you use. `--governance-file-path` reads a local policy file — pass an AutomationOps policy **exactly as exported**, envelope and all: the analyzer reads the whole export, so handing it just the inner `data` object is rejected with a message telling you to pass the export instead. A file that cannot be read, or that is not JSON, fails the pack rather than falling back — you asked for a policy, so packing without one would be a silent pass. `--governance-product` downloads the policy published in AutomationOps for the signed-in tenant; its value is the product to fetch (`StudioWeb`, `Development`, `Business`, …). With neither flag the analyzer uses the rules shipped with the WorkflowCompiler. Pass `--governance-file-path` on its own and the tenant is still asked, about `StudioWeb`, so the file's standing can be decided — that is the only case with a product default.
+
+`--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:
+
+- **The tenant publishes a policy.** That policy is what the analyzer uses. A `--governance-file-path` passed alongside it is refused with exit `1`, naming the file and the product whose policy applies — 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`, …), 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. Strict, fail-closed behaviour belongs to design-time hosts, not to this command.
 
 ## Dependency Feeds
 
@@ -267,7 +288,7 @@ uip solution delete <solution-id> --yes    # remove a solution from Studio Web (
 
 `Data.Action` is `Imported` or `Overwritten`, so you can tell which ran. `--force` skips the existence check and overwrites directly; it is not normally needed, it fails rather than importing if that solution is gone, and it has no effect when no `SolutionId` is bundled (the upload imports as new). To upload a copy as an unrelated cloud solution instead of updating, 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).
 
-If Studio Web refuses the upload with 401 or 403, read `Instructions` before you do anything — the answer is one of two, and they are opposites. In almost every case do **not** re-run `uip login`: the CLI checks the session and its token expiry before it calls, so the token was valid and re-authenticating produces the same one. The failure is then about what the acting identity may do in Studio Web (for a CI pipeline: the external application's `StudioWebS2S` grants) or about the tenant the bundled `SolutionId` belongs to, and an application 401 is reported as `ErrorCode: permission_denied` rather than `authentication_required`. The exception is when `Instructions` quote `invalid_token`: that is Studio Web rejecting the credential itself rather than the permissions behind it, so a fresh `uip login` — or a newly minted client-credentials token — is worth trying, and the error code stays `authentication_required`.
+If Studio Web refuses the upload with 401 or 403, do **not** re-run `uip login` — the CLI checks the session and its token expiry before it calls, so the token was valid and re-authenticating produces the same one. The failure is about what the acting identity may do in Studio Web (for a CI pipeline: the external application's `StudioWebS2S` grants) or about the tenant the bundled `SolutionId` belongs to. The envelope's `Instructions` name both, and an application 401 is reported as `ErrorCode: permission_denied` rather than `authentication_required`.
 
 `download` writes the `.uis` archive and nothing else — extraction is opt-in. Pass `--extract` to also unzip it into a sibling directory named after the archive; that directory is a working solution tree, with the `.uipx` manifest at its root. `--extract` also drops `AGENTS.md` and `CLAUDE.md` there so an agent picking the solution up has the same briefing `uip solution init` writes. It only fills gaps: a file the archive already carried is left alone, and the paths actually written come back in `Data.BriefingFiles`. Without `--extract` you get the zip only, and no briefing files — there is no solution directory to put them in.
 
@@ -291,6 +312,8 @@ 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.
 
+`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:
 
 ```bash
@@ -299,6 +322,27 @@ 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.
 
+**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).
+
+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:
+
+- `uip solution resources refresh` reports `Data.ReconciledSpecs` — how many
+  resource specs it rewrote from the projects' authored files. Problems that
+  `pack` would fail on show up in `Data.Warnings` here; refresh still exits `0`.
+- `uip solution pack` and `uip solution upload` both fail when a project
+  reports a problem with its own authored files — a coded app whose
+  `webAppManifest.json` does not parse, or a Coded Action project whose
+  `action-schema.json` is missing or does not parse, for example. The message
+  names the file and the project, and the envelope carries
+  `ErrorCode: invalid_argument`.
+  Nothing is written before that check passes, so fix the file and re-run the command.
+
+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.
+
 ### 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:
@@ -341,10 +385,36 @@ uip solution resources get <resource-key> --include-dependencies
 uip solution resources edit <resource-key> --patch '{"retentionPeriod":14}'
 uip solution resources edit <resource-key> --patch -          # read the JSON from stdin
 
+# Pull the cloud definition over the local one (imported resources only)
+uip solution resources edit <resource-key> --source remote           # report what would change, write nothing
+uip solution resources edit <resource-key> --source remote --force   # apply it
+
 # Drop a resource from the solution (local only, leaves bindings_v2.json alone)
 uip solution resources remove <resource-key>
 ```
 
+### 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`.
+
+Without `--force` it writes nothing: it lists the spec properties that differ and exits `1` with `ErrorCode: invalid_argument`. That exit code is deliberate — a script that forgot `--force` must not read "nothing was written" as "done". Re-run with `--force` to apply.
+
+```bash
+uip solution resources edit <resource-key> --source remote --output json
+# Failure, invalid_argument: "2 properties differ from the cloud definition: description, fields"
+
+uip solution resources edit <resource-key> --source remote --force --output json
+# Success, ResourceEdited: Data.Applied true, Data.Changed ["description","fields"]
+```
+
+**`--force` is destructive.** It replaces the local spec with the cloud one, so any local edit to a listed property is lost — including a rename you made before deployment. Run it once without `--force` first and read the `Changed` list.
+
+Three things it will not do:
+
+- `--patch` and `--source remote` cannot be combined (two sources for the same spec would race), and `--force` is rejected without `--source remote`.
+- A resource with no recorded cloud reference fails with `Resource has no cloud definition to sync from` rather than silently doing nothing. Two causes: it genuinely has no cloud counterpart (a `--source local` stub, or a project's own artefact resource), **or** the reference belongs to someone else. The reference is stored per user and per tenant in `userProfile/<your-user-id>/debug_overwrites.json`, so if a teammate imported the resource — or you imported it against another tenant — you have no reference for it. Re-import it with `uip solution resources add --source remote` to record one for yourself.
+- If the cloud definition cannot be read for the comparison, it fails with `Could not read the cloud definition to compare against` instead of reporting no drift. Check the resource still exists in the cloud, or pass `--force` to overwrite with whatever the cloud returns.
+
 `get` and `edit` use the same shape — **copy the casing `get` returns** (`Value`, not `value`). A patch key whose case does not match is treated as unknown.
 
 Both of `edit`'s failure modes are silent and still report `Result: Success`:
@@ -354,7 +424,7 @@ Both of `edit`'s failure modes are silent and still report `Result: Success`:
 
 So `Result: Success` from `edit` does not mean the value changed. Read it back with `resources get` before relying on it. No CLI verb sets a *reference* property, so a virtual process cannot be pointed at a package this way — link it at deploy time with `deploy config link` instead.
 
-A package resource key can be a composite like `TestRPA.process.TestRPA:1.0.0`; `edit` and `remove` want a plain GUID.
+Keys are GUIDs for imported cloud resources and compound strings such as `MyFunction.api.MyFunction.1:1.0.0` for package resources; pass the `Key` value `uip solution resources list` prints.
 
 ## Deployment Configuration
 
@@ -453,13 +523,13 @@ Adjacent groups commonly used alongside solutions:
 | Symptom | First thing to check |
 |---|---|
 | `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 — an id this session cannot see at all is reported separately, as nothing to overwrite, so a refusal here points at the grants first |
-| `upload` fails with 401 and `Instructions` quote `invalid_token` | The opposite case: Studio Web rejected the credential itself, not the grants behind it. Re-run `uip login`, or mint a fresh client-credentials token in a pipeline. Check too that the token was issued for the organization and tenant being called — one minted against another environment or audience is refused this way. The error code stays `authentication_required` |
+| `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 |
 | 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` first, or pass `--yes` to create a second, separate deployment |
 | `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` |
 | `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,19 +1,25 @@
 import {
   metadata,
   registerCommands
-} from "./packager-tool-w1dzcj31.js";
-import"./packager-tool-pbmpgz04.js";
-import"./packager-tool-mcpzmn0v.js";
-import"./packager-tool-pw7v82j2.js";
-import"./packager-tool-bme8epz8.js";
-import"./packager-tool-3bewrpq4.js";
-import"./packager-tool-pyygbnp2.js";
-import"./packager-tool-5518wy6n.js";
-import"./packager-tool-vfcht7hq.js";
-import"./packager-tool-bt0z25tw.js";
+} from "./packager-tool-cvfbzs9p.js";
+import"./packager-tool-1haahq17.js";
+import"./packager-tool-rc5pcf2n.js";
+import"./packager-tool-vas0xg5h.js";
+import"./packager-tool-n4nfqj99.js";
+import"./packager-tool-7znqtw3f.js";
+import"./packager-tool-znakt6yw.js";
+import"./packager-tool-k4mskzww.js";
+import"./packager-tool-jz2wbfjz.js";
+import"./packager-tool-htag6yh5.js";
+import"./packager-tool-cp07fhx3.js";
+import"./packager-tool-mj5p341c.js";
+import"./packager-tool-bkwnetqn.js";
+import"./packager-tool-gdtpsdn7.js";
+import"./packager-tool-53w8skv5.js";
 import"./packager-tool-nzghfa48.js";
-import"./packager-tool-rbrcxjch.js";
-import"./packager-tool-fjjh5veg.js";
+import"./packager-tool-2syrt51a.js";
+import"./packager-tool-3jrq7smt.js";
+import"./packager-tool-0f0wt9vh.js";
 import"./packager-tool-dfrk01gn.js";
 import"./packager-tool-1de529jm.js";
 export {
@@ -21,4 +27,4 @@ export {
   registerCommands
 };
 
-//# debugId=CF074D6CB03931BC64756E2164756E21
+//# debugId=F50F7343D96D9C2C64756E2164756E21

package/package.json

@@ -1,7 +1,8 @@
 {
     "name": "@uipath/solution-tool",
+    "author": "UiPath",
     "license": "SEE LICENSE IN LICENSE.txt",
-    "version": "1.202.0",
+    "version": "1.203.0-preview.160",
     "description": "Create, pack, publish, and deploy UiPath Automation Solutions.",
     "repository": {
         "type": "git",
@@ -47,5 +48,5 @@
         "dist"
     ],
     "private": false,
-    "gitHead": "23b5a7038ead7264439af18f8b807c7cc99a29d5"
+    "gitHead": "3a42062ba731afca4595ba9aa8a80afc9667528d"
 }

package/dist/services/validate-appv2-action-schemas.d.ts

@@ -1,10 +0,0 @@
-/**
- * Fails the pack early when any AppV2 CodedAction project in the solution is
- * missing its `action-schema.json`. Without the schema the packed resource
- * spec ships an empty `actionSchema`, and downstream flows that reference the
- * action (e.g. a BPMN user task picker) render no inputs / outputs / outcomes.
- *
- * Only checks CodedAction (`webAppManifest.config.isActionApp === true`).
- * Regular Coded apps have no action schema by design.
- */
-export declare function validateAppV2ActionSchemas(solutionDir: string): Promise<void>;