@uipath/solution-tool 1.204.0-preview.225 → 1.204.0-preview.227

package/dist/templates/AGENTS.md

@@ -66,14 +66,14 @@ 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 — 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. | `uip rules init <name>` | none |
+| `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) |
 | `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 |
 
 Install the skills with `uip skills install`. The general-purpose `uipath-platform` skill covers what isn't in a type-specific skill, and `uipath-solution` covers the solution lifecycle itself.
 
-A `BusinessRules` project gets its `businessRule` resource when it is added to the solution; `Library` and `Tests` projects declare no solution resources. `uip solution resources refresh` skips all three.
+A `BusinessRules` project gets its `businessRule` resource when it is added to the solution, and `uip solution resources refresh` regenerates it if it goes missing. `Library` and `Tests` projects declare no solution resources, and refresh skips them.
 
 **`Library` is not a project type here.** A library is a reusable `.nupkg` consumed as a NuGet dependency, so `projects add` / `import` reject it and auto-registration returns `SolutionRegistration.Status: "Skipped"`. Publish it on its own (`uip rpa pack <project-dir> <output-path>`, then `uip or libraries upload --file <nupkg-path>`) and either reference it from a project's dependencies or attach it to this solution as a resource: `uip solution resources add --source remote --kind Library --name <library-name>`.
 
@@ -213,25 +213,32 @@ That last flag is strict on purpose, and that is what makes it easy to get wrong
 
 ## Workflow Analyzer and Governance
 
-`solution pack` runs the workflow analyzer over every RPA project. Two things control it:
+`solution pack` runs the workflow analyzer over every RPA project. These flags control it:
 
 ```bash
 uip solution pack . ./out --skip-analyze                             # don't run the analyzer at all
+uip solution pack . ./out --ignored-rules ST-USG-034,ST-MRD-002      # run it, but drop these rules' findings
 uip solution pack . ./out --governance-file-path ./policy.json       # analyze against a local policy file
 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.
 
+`--ignored-rules` keeps the analyzer on but drops the findings of the rules it names, for every RPA project in the solution: they are not reported and cannot fail the pack. It is the per-run escape hatch the legacy `uipcli --ignoredRules` was — use it for violations a pipeline has deliberately accepted, rather than editing a policy other people share. The value is a comma-separated list of rule IDs; repeat the flag to add more; IDs are trimmed and matched case-insensitively. Which rules it can lift depends on where the rules come from:
+
+- **The signed-in tenant publishes an AutomationOps policy.** The list is not applied, even with a `--governance-file-path`: the organisation's policy stays enforced in full, and a warning names the rules that were not ignored. The pack does not fail because of the flag.
+- **A `--governance-file-path` is used** (the tenant publishes nothing, could not be asked, or there is no signed-in tenant). The list applies on top of the file, even to rules the file raises to `Error`.
+- **No policy at all.** The list applies on top of the rules shipped with the WorkflowCompiler.
+
 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.
+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` or `--ignored-rules` without `--governance-product` and the tenant is still asked, about `StudioWeb`, so a governed tenant's policy can win over them — those are the only cases 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, whatever else you passed. A `--governance-file-path` alongside it is not used; you get a warning and the pack carries on — a flag in your own pipeline does not lift the organisation's policy.
+- **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.
 

package/dist/tool.js

@@ -1,32 +1,32 @@
 import {
   metadata,
   registerCommands
-} from "./packager-tool-h48m9htp.js";
-import"./packager-tool-3enm2h28.js";
-import"./packager-tool-c34hyfag.js";
-import"./packager-tool-c10w3gb4.js";
-import"./packager-tool-e9gd9vj7.js";
-import"./packager-tool-dnceqejz.js";
-import"./packager-tool-tjy6kene.js";
-import"./packager-tool-2cntqvdv.js";
-import"./packager-tool-y94hgr33.js";
-import"./packager-tool-9vvdgbay.js";
-import"./packager-tool-vh4ng74p.js";
-import"./packager-tool-5dzjsw5q.js";
+} from "./packager-tool-d04rhvpr.js";
+import"./packager-tool-v8bkkqdb.js";
+import"./packager-tool-6qnzwhkx.js";
+import"./packager-tool-61kk26cq.js";
+import"./packager-tool-f7zpwjem.js";
+import"./packager-tool-5ycnrx5p.js";
+import"./packager-tool-47jwfqx7.js";
+import"./packager-tool-px1j9kre.js";
+import"./packager-tool-3455w9d9.js";
+import"./packager-tool-gab9y5ct.js";
+import"./packager-tool-1rzssy0x.js";
+import"./packager-tool-e2rtr49j.js";
 import"./packager-tool-zns6n8zp.js";
-import"./packager-tool-7getfd53.js";
-import"./packager-tool-qgaqqq41.js";
-import"./packager-tool-wq18a9fw.js";
-import"./packager-tool-fwt2myg8.js";
+import"./packager-tool-gjk95q61.js";
+import"./packager-tool-7gr2nphb.js";
+import"./packager-tool-rf7x0a05.js";
+import"./packager-tool-fsmvencw.js";
 import"./packager-tool-bqre28m1.js";
-import"./packager-tool-83rzavkx.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-3fv6zc86.js";
-import"./packager-tool-vmsxq1pc.js";
-import"./packager-tool-5fjp60dk.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";

package/package.json

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