@uipath/skills 1.199.0 → 1.200.0

package/skills/uipath-rpa/references/project-structure-guide.md

@@ -1,168 +0,0 @@
-# Designing Project Structure
-
-When creating a project, **proactively design the right file structure** based on the task complexity. Do not put everything into a single root workflow file. Use your best judgment to split the project into multiple files following good software engineering practices.
-
-For the coded vs XAML decision, see [coded-vs-xaml-guide.md](coded-vs-xaml-guide.md). For new projects, the default is XAML — examples below lead with XAML and note where the coded equivalent differs.
-
-## Guidelines
-
-- **Single simple task** (e.g. "read a CSV and log it") — one workflow file (`Main.xaml` for XAML projects, `Main.cs` for coded) is fine
-- **Multi-step process** (e.g. "read invoices, validate, post to system") — split into multiple workflow files, each handling one step. The root workflow invokes each step
-- **Shared data structures** — extract into a Coded Source File (e.g. `Models.cs`, `InvoiceData.cs`). XAML cannot define types, so a Coded Source File is the right home even in an otherwise XAML project
-- **Repeated logic** — in XAML projects, extract into a reusable XAML workflow. In coded or hybrid projects, extract into a helper Coded Source File (e.g. `ValidationHelpers.cs`)
-- **Test project** — one test case per scenario. Coded test projects optionally use `partial class CodedWorkflow : IBeforeAfterRun` in `CodedWorkflowHooks.cs` for shared setup. XAML test projects use Test Activities for shared setup
-- **Complex domain logic** — isolate business rules so they can be unit-tested and reused (Coded Source File for typed logic, or a separate workflow for activity-driven logic)
-
-## Designing for Reuse
-
-Structure decisions that keep components extractable later.
-
-### Single responsibility
-
-One workflow file = one meaningful action, named for it (`ProcessInvoice.xaml`, `LoginToApplication.xaml`). Split a workflow when it exceeds ~20-30 activities.
-
-### Standard folder shape
-
-For multi-step processes, organize by layer:
-
-```
-Project/
-├── Main.xaml              # High-level orchestration only
-├── Framework/             # Init, cleanup, error handling, app open/close
-├── BusinessLogic/         # Process-specific rules and transactions
-├── Utilities/             # Process-agnostic helpers (formatters, screenshots)
-└── Data/                  # Config files, templates
-```
-
-### Separate business logic from UI components
-
-UI workflows interact with applications and carry zero business rules; business-logic workflows decide and never touch the UI. Make read and write distinct invocable components — `GetCustomerInfo.xaml` and `ChangeCustomerInfo.xaml`, not one `HandleCustomer.xaml`. When the target application's UI changes, only the UI workflows need fixing; when a business rule changes, the UI workflows are untouched. Process-agnostic UI components are also the ones worth promoting to a shared library later.
-
-### Composition and argument naming
-
-Compose via `Invoke Workflow File` (coded: `workflows.StepName()`). Process workflow arguments use directional prefixes — `in_InvoiceId`, `out_Result`, `io_Browser` — so data flow is visible at every invocation site. Exception: library public workflows drop the prefixes ([library-authoring-guide.md § The Public-Workflow Contract](library-authoring-guide.md)).
-
-### Layout and scale-out
-
-- Sequence vs Flowchart vs State Machine per workflow: Workflow Types table in SKILL.md § XAML Workflows Quick Reference
-- High-volume transactional work: dispatcher/performer split via queues — [reframework-guide.md § Execution Mode: Queue-Driven](reframework-guide.md)
-
-### Promotion ladder
-
-Promote logic only as reuse materializes:
-
-1. **Inline** — used once in one workflow
-2. **Separate workflow file** — reused within the project
-3. **Shared library** — reused across projects ([library-authoring-guide.md](library-authoring-guide.md))
-4. **UI Library** — selectors shared across projects ([uia-starter-guide.md § Object Repository as a Published UI Library](uia-starter-guide.md))
-
-## Example — Invoice Processing Project (XAML)
-
-```
-InvoiceProcessor/
-├── project.json
-├── Main.xaml                  # Root workflow: sequences each step via Invoke Workflow File
-├── ReadInvoices.xaml          # Step 1: reads invoices from Excel
-├── ValidateInvoices.xaml      # Step 2: validates data
-├── PostToERP.xaml             # Step 3: posts to external system
-└── InvoiceData.cs             # Coded source file: typed data model used across XAML steps
-```
-
-`Main.xaml` invokes each step via `Invoke Workflow File`, passing arguments In/Out. `InvoiceData.cs` is included even in this otherwise-XAML project because XAML cannot define types — typed DTOs eliminate `DataTable` column-name guessing.
-
-### Coded equivalent
-
-```
-InvoiceProcessor/
-├── project.json
-├── Main.cs                    # Root workflow: calls each step via workflows.StepName()
-├── ReadInvoices.cs            # Step 1
-├── ValidateInvoices.cs        # Step 2
-├── PostToERP.cs               # Step 3
-├── InvoiceData.cs             # Coded source file: data model
-└── ValidationHelpers.cs       # Coded source file: validation utilities
-```
-
-`Main.cs` uses strongly-typed workflow invocation:
-
-```csharp
-[Workflow]
-public void Execute(string inputFolder)
-{
-    var readResult = workflows.ReadInvoices(folderPath: inputFolder);
-    Log($"Read {readResult.count} invoices");
-
-    var validateResult = workflows.ValidateInvoices(invoices: readResult.invoiceList);
-    Log($"Valid: {validateResult.validCount}, Invalid: {validateResult.invalidCount}");
-
-    var postResult = workflows.PostToERP(validInvoices: validateResult.validInvoices);
-    Log($"Posted {postResult.successCount} invoices to ERP");
-}
-```
-
-## Example — Test Project
-
-```
-InvoiceTests/
-├── project.json
-├── CodedWorkflowHooks.cs      # Coded test projects only: partial class CodedWorkflow with Before/After hooks
-├── TestLoginFlow.cs           # Test case: login scenario (hooks apply automatically via partial class merge)
-├── TestInvoiceCreation.cs     # Test case: create invoice scenario
-├── TestInvoiceValidation.cs   # Test case: validation rules
-└── TestData.cs                # Source file: shared test constants/fixtures
-```
-
-XAML test projects use `.xaml` test cases instead of `.cs` and Test Activities for shared setup; the rest of the layout is the same.
-
-## Example — Hybrid Project (XAML Root + Coded Logic)
-
-```
-OrderProcessing/
-├── project.json
-├── Main.xaml                  # XAML root workflow: sequences steps, handles retries
-├── ScrapeOrderPortal.xaml     # XAML: UI automation with visual selector builder
-├── SendConfirmationEmail.xaml # XAML: Mail activities (straightforward)
-├── ProcessOrder.cs            # Coded workflow: 12 validation rules + LINQ transforms
-├── OrderModels.cs             # Coded source file: Order, LineItem, ValidationResult DTOs
-├── TransformHelpers.cs        # Coded source file: date parsing, currency conversion
-└── TestProcessOrder.cs        # Coded test case: unit tests for ProcessOrder logic
-```
-
-### Why hybrid here
-
-- **ScrapeOrderPortal.xaml** — UI automation benefits from XAML's visual selector builder and recording tools
-- **ProcessOrder.cs** — Order validation has 12 business rules with nested conditions; coded C# is clearer and testable
-- **OrderModels.cs** — Typed DTOs used by both XAML (via typed arguments) and coded workflows, eliminating DataTable column-name guessing
-- **SendConfirmationEmail.xaml** — Simple Mail activity, no logic — XAML is the simpler choice
-- **Main.xaml** — Orchestration is linear (scrape → process → email); XAML Sequence is readable
-
-### Data flow
-
-1. `Main.xaml` invokes `ScrapeOrderPortal.xaml` → returns `DataTable` via Out argument
-2. `Main.xaml` invokes `ProcessOrder.cs` via Invoke Workflow File → passes raw data, returns validated `Order` objects
-3. `Main.xaml` invokes `SendConfirmationEmail.xaml` → passes validated order data
-
-## Project Structure Decision Tree
-
-**First — coded or XAML?** For new projects, default to XAML unless the user explicitly said "coded" or named a coded-specific trigger (custom data models, complex algorithms, unit tests on business logic). See [coded-vs-xaml-guide.md](coded-vs-xaml-guide.md). The root workflow is `Main.xaml` for XAML projects and `Main.cs` for coded projects — substitute accordingly below.
-
-**Is it a single, simple task?**
-- ✅ Yes → Single root workflow
-
-**Is it a multi-step process?**
-- ✅ Yes → A root workflow that invokes each step + separate workflow files for each step
-
-**Does it involve repeated data structures?**
-- ✅ Yes → Extract to Coded Source File (e.g. `Models.cs`, `InvoiceData.cs`). Required even in XAML projects — XAML cannot define types
-
-**Is there shared logic across workflows?**
-- ✅ Yes → Extract to a reusable XAML workflow (XAML projects) or a helper Coded Source File (coded or hybrid projects)
-
-**Is it a test project?**
-- ✅ Yes → One test case file per scenario. Coded test projects optionally use `CodedWorkflowHooks.cs` (partial class CodedWorkflow) for shared setup/teardown
-
-**Does it have complex business rules?**
-- ✅ Yes → Isolate in Coded Source Files for reusability and testability (extract from XAML via `Invoke Workflow File` if needed)
-
-**Does it need both UI automation AND complex non-UI logic?**
-- ✅ Yes → Hybrid: XAML for UI automation + orchestration, Coded for business logic + data models. See [coded-vs-xaml-guide.md](coded-vs-xaml-guide.md)

package/skills/uipath-rpa/references/project-structure.md

@@ -1,135 +0,0 @@
-# UiPath Project Structure
-
-## Directory Layout
-
-```
-MyProject/
-├── project.json          # Project manifest (name, dependencies, settings)
-├── Main.xaml             # Default entry point (XAML mode) ─┐ typically one
-├── Main.cs               # Default entry point (coded mode) ─┘ or the other
-├── *.xaml                # Additional XAML workflow files
-├── *.cs                  # Coded workflows, test cases, and source files
-├── *.cs.json             # Auto-generated by Studio — do not create manually
-├── .codedworkflows/      # Auto-generated coded workflow support files (ConnectionsFactory.cs, ConnectionsManager.cs, ISConnections.cs, etc.)
-├── .entities/            # Data Fabric entity manifest — EntitiesStore.json. Committed; source of truth for which entities are bound to the project. Managed via uip rpa data-fabric-entities install.
-├── .local/               # Local cache (package restore, compiled artifacts)
-│   ├── install/          # Restored NuGet packages
-│   ├── docs/             # Auto-generated activity documentation
-│   │   └── packages/     # Per-package doc folders
-│   ├── .codedworkflows/  # Auto-generated (ObjectRepository.cs, CodedWorkflow.cs, WorkflowRunnerService.cs)
-│   └── .entities/        # Compiled Data Fabric entity assemblies (DataService.<Namespace>.dll) per install signature. Regenerated on demand — do not edit.
-├── .objects/             # Object Repository metadata (UI element selectors)
-├── .project/             # Project metadata
-│   ├── JitCustomTypesSchema.json  # JIT-compiled custom type definitions
-│   └── PackageBindingsMetadata.json
-├── .screenshots/         # Activity screenshots (auto-generated)
-├── .settings/            # Project-level settings
-├── .autopilot/           # Autopilot service specific files
-│   └── skills/           # Project-specific Autopilot skills
-└── .storage/             # Activity resource storage (bucket-organized)
-    ├── .design/          # Design-time only resources (NOT packed into published package)
-    │   └── <bucket>/     # Named bucket to prevent conflicts
-    └── .runtime/         # Runtime resources (packed into published NuPkg)
-        └── <bucket>/     # Named bucket with resource files
-```
-
-### Coded-Only Elements
-
-- `.cs` files with `[Workflow]`/`[TestCase]` attributes — executable coded automations
-- `.cs.json` metadata files — auto-generated by Studio for each coded workflow/test case (do not create manually)
-- `.codedworkflows/` — auto-generated support files (only when project has `.cs` files)
-- `.local/.codedworkflows/` — auto-generated `ObjectRepository.cs`, `CodedWorkflow.cs`, etc.
-- `.variations/` — data-driven test parameters (Tests projects only)
-
-### XAML-Only Elements
-
-- `.xaml` workflow files — visual workflow definitions
-- Expression language configured in `project.json` (`VisualBasic` or `CSharp`)
-
-## project.json Key Fields
-
-```json
-{
-  "name": "MyProject",
-  "description": "",
-  "main": "Main.xaml",
-  "dependencies": {
-    "UiPath.System.Activities": "[24.12.1]"
-  },
-  "schemaVersion": "4.0",
-  "studioVersion": "25.0.0.0",
-  "projectVersion": "1.0.0",
-  "runtimeOptions": {
-    "autoDispose": false,
-    "netFramework": { "targetFramework": "net6.0-windows" },
-    "isPausable": true,
-    "isAttended": false,
-    "requiresUserInteraction": false
-  },
-  "designOptions": {
-    "projectProfile": "Developement",
-    "outputType": "Process",
-    "libraryOptions": {
-      "includeOriginalXaml": false,
-      "privateWorkflows": []
-    }
-  },
-  "expressionLanguage": "VisualBasic",
-  "entryPoints": [
-    {
-      "filePath": "Main.xaml",
-      "uniqueId": "2f510550-3882-4340-9239-53a24d0717f6",
-      "input": [],
-      "output": []
-    }
-  ],
-  "targetFramework": "Windows"
-}
-```
-
-### Important Fields
-
-| Field | Description |
-|-------|-------------|
-| `name` | Project name (used in package output) |
-| `main` | Entry point workflow file (relative path) |
-| `dependencies` | NuGet package dependencies with version constraints |
-| `expressionLanguage` | `CSharp` or `VisualBasic` — determines expression syntax in XAML. Default `VisualBasic`. Immutable after creation (decide at init — SKILL.md Rule 2a) |
-| `designOptions.outputType` | `Process`, `Library`, or `Tests` |
-| `targetFramework` | `Windows` (.NET 6 Windows-only), `Portable` (Cross-platform .NET 6+), or `Legacy` (Windows - Legacy, .NET Framework 4.6.1). Set explicitly at init (Rule 2a); omitting `--target-framework` yields `Windows` |
-| `entryPoints` | Per-workflow metadata: filePath, uniqueId, input/output definitions (**Process projects only** — Tests and Library projects use empty `[]`) |
-
-## Rules
-
-1. **Use CLI for dependencies**: Always use `uip rpa packages install` to add/update dependencies. Do not manually edit `dependencies` in `project.json`.
-2. **Do not edit `.local/` or `.objects/`**: These are cache directories managed by the build system.
-3. **`main` entry point**: The default entrypoint that gets run if not specified otherwise. `entryPoints` array is only populated for **Process** projects — Tests and Library projects leave it empty (`[]`).
-4. **`--project-dir` awareness**: All `uip rpa` commands default to the current working directory. If the CWD is not the project root, pass `--project-dir "{projectRoot}"` explicitly.
-5. **Creating new projects**: Use `uip rpa init`. See [environment-setup.md](environment-setup.md).
-
-## Common Activity Packages
-
-| Package ID | Description | Key Activities |
-|------------|-------------|----------------|
-| `UiPath.System.Activities` | Core system activities | Assign, If, ForEach, While, Invoke Workflow, Log Message, Delay |
-| `UiPath.UIAutomation.Activities` | UI interaction | Click, Type Into, Get Text, Open Browser, Use Application/Browser |
-| `UiPath.Excel.Activities` | Excel automation | Read Range, Write Range, Read Cell, Write Cell, Format Range |
-| `UiPath.Mail.Activities` | Email operations | Send Mail, Get Mail, Save Attachments, Forward Mail |
-| `UiPath.Database.Activities` | Database operations | Execute Query, Execute Non Query, Connect, Disconnect |
-| `UiPath.WebAPI.Activities` | HTTP/REST calls | HTTP Request, Deserialize JSON, Serialize JSON |
-| `UiPath.PDF.Activities` | PDF processing | Read PDF Text, Read PDF with OCR, Extract Data From PDF |
-| `UiPath.Word.Activities` | Word automation | Read Text, Replace Text, Insert Image, Export to PDF |
-| `UiPath.Testing.Activities` | Testing and assertions | Verify Expression, Verify Are Equal, Generate Test Data |
-| `UiPath.Presentations.Activities` | PowerPoint automation | Add Slide, Replace Text, Insert Image |
-| `UiPath.IntegrationService.Activities` | Integration Service connector runtime | Generic connector activities for Salesforce, ServiceNow, HubSpot, etc. |
-| `UiPath.Cryptography.Activities` | Encryption/hashing | Encrypt Text, Decrypt Text, Hash File |
-
-## Version Constraints
-
-Dependencies use NuGet version constraint syntax:
-
-| Syntax | Meaning |
-|--------|---------|
-| `[1.0.0]` | Exact version 1.0.0 |
-| `[1.0.0, )` | Version 1.0.0 or higher |
-| `[1.0.0, 2.0.0)` | Between 1.0.0 (inclusive) and 2.0.0 (exclusive) |

package/skills/uipath-rpa/references/publishing-guide.md

@@ -1,80 +0,0 @@
-# Publishing a UiPath Project
-
-How to take a built `.nupkg` from `uip rpa pack` and get it onto Orchestrator or Studio Web. Covers the standalone-project paths only — solution publish (`.uipx` solutions and `solution publish` deploy lifecycle) lives in [/uipath:uipath-solution](../../uipath-solution/SKILL.md).
-
-## Pick a path
-
-| Goal | Path | Reference |
-|---|---|---|
-| Run the project as an Orchestrator process / link as a Test Manager automation | **Pack → Orchestrator package upload** | This file § Pack → Upload |
-| Edit / visualize in Studio Web | **Solution upload** | [uipath-solution](../../uipath-solution/SKILL.md) (solution upload) |
-| Deploy a packed solution (`.uipx`) to Orchestrator with the deployment lifecycle | **Solution publish** | [uipath-solution](../../uipath-solution/references/pack-and-deploy.md) |
-
-This file documents the first row only — the legacy Orchestrator package feed flow that `uip tm testcases link-automation` requires.
-
-## Pack → Upload (Orchestrator process flow)
-
-The end-to-end is two CLI calls.
-
-### Step 1 — Pack the project
-
-```bash
-uip rpa pack "<PROJECT_DIR>" "<OUTPUT_DIR>" --output json
-```
-
-| Argument | Position | Notes |
-|---|---|---|
-| `<PROJECT_DIR>` | Positional 1 | Path to the project (folder containing `project.json`). |
-| `<OUTPUT_DIR>` | Positional 2 | Directory the `.nupkg` is written to. Must exist. |
-
-Common optional flags (run `uip rpa pack --help` for the full set):
-- `--package-version <SEMVER>` — pin the version. Defaults to the project version.
-- `--skip-analyze` — skip the workflow-analyzer pass. Use only for known-clean builds.
-- `--governance-file-path <PATH>` — apply a governance policy during pack.
-
-Output (JSON) emits `OutputPath` — the full `.nupkg` path. Capture it for Step 2.
-
-> **`uip rpa pack` does NOT accept `--project-path` or `--project-dir`.** Both arguments are positional. The `--project-dir` flag exists on most other `uip rpa` subcommands but not here.
-
-### Step 2 — Upload to Orchestrator
-
-```bash
-uip or packages upload "<NUPKG_PATH>" --output json
-```
-
-| Argument / Flag | Required | Notes |
-|---|---|---|
-| `<NUPKG_PATH>` | Yes (positional) | Path to the `.nupkg` produced by `pack`. |
-| `--feed-id <UUID>` | No | Target a non-default feed. Defaults to the tenant feed. |
-| `--folder-path <PATH>` / `--folder-key <UUID>` | No | Target a specific folder feed. |
-
-Output JSON includes the package `Id` (the package name Orchestrator stores) and `Version`. Hold on to the `Id` — `uip tm testcases link-automation` takes it as `--package-name`; `uip or processes create` takes it as `--package-key` (with `--package-version` separately).
-
-> **There is no `uip or packages publish` or `uip rpa publish`.** Agents that try those names get "unknown command". Pack writes a file; upload pushes that file. Two commands, two domains (`rpa`, `or`).
-
-## Discovery cheatsheet
-
-Folder key (UUID — required by `processes create`, `link-automation`, etc.):
-
-```bash
-uip or folders list --output json
-```
-
-The returned `Key` is the UUID; the `FullyQualifiedName` is the human path. Either is accepted by `--folder-path` / `--folder-key` — most other CLI calls require the UUID.
-
-After upload, list the new package version:
-
-```bash
-uip or packages list --output json
-```
-
-## End-to-end: link a coded test case to Test Manager
-
-For the full Pack → Upload → Link → Execute pipeline targeted at Test Manager (folder-key discovery, picking the right `--test-name`, etc.), see [/uipath:uipath-test § publish-and-link-guide.md](../../uipath-test/references/publish-and-link-guide.md).
-
-## Common pitfalls
-
-- **`uip solution publish` expects a packed `.zip`, not a project directory.** Solutions: run `uip solution pack` first, then `uip solution publish "<ZIP_PATH>"`. Single projects: use `uip or packages upload` instead.
-- **Confusing `solution upload` and `solution publish`.** `upload` pushes to Studio Web (browser editing). `publish` pushes a packed solution `.zip` to the Orchestrator solution feed for `solution deploy`. They are NOT interchangeable. See [uipath-solution](../../uipath-solution/SKILL.md) for the decision tree.
-- **Re-uploading the same version.** Orchestrator rejects duplicate `<id>:<version>` uploads. Bump `--package-version` (or `project.json` `projectVersion`) before re-packing.
-- **`pack` succeeds but `analyze` ran with errors.** A successful pack with errors in the analyzer log usually means warnings only. Re-run `uip rpa analyze "<PROJECT_DIR>"` (project dir is positional) if you need a clean failure / pass signal.

package/skills/uipath-rpa/references/validation-guide.md

@@ -1,170 +0,0 @@
-# Validation & Fixing Guide
-
-Fix-one-thing discipline, the validation iteration loop, smoke test procedure, and RPA-specific fix procedures.
-
-## On demand: List Analyzer Rules
-
-`validate` and `build` already enforce the project's enabled Workflow Analyzer rules — violations come back with the rule ID, severity, and recommendation, so the normal authoring loop needs **no** rule pre-fetch. Do NOT run `analyzer-rules list` as an authoring prerequisite: the unscoped call enumerates every rule across every package and can take a minute or more, and most of its output never affects the code you write.
-
-Run it **only on demand**:
-
-1. The **user asks** about the project's best-practice / analyzer rules ("what rules does this project enforce?", "list the analyzer rules", "why is UI-REL-001 firing?").
-2. **Repeated violations of the same rule family** across `validate`/`build` iterations — reading the full rule set (scoped, see below) lets you author against it instead of fixing violations one by one.
-
-```bash
-uip rpa analyzer-rules list --project-dir "<PROJECT_DIR>" --scope "<Activity|Workflow|Coded Workflow|Project>" --output json
-```
-
-Prefer a `--scope` matching what you're authoring — scoped calls return in seconds; unscoped can take a minute+. Apply `error` and `warning` rules; `info` rules are advisory. If you do consult the rules and then add or update a NuGet package, the package-shipped (`MA-*`) rules may have changed with the dependency set.
-
-For coded (`.cs`) workflow files, the four built-in `Coded Workflow`-scope rules (ST-NMG-017, ST-DBP-010, ST-REL-001, ST-USG-017) are all Error severity and enforced by `analyze`, `build`, and `pack` — triggers and fixes: [coded/coding-guidelines.md § Coded Workflow Analyzer Rules](coded/coding-guidelines.md#coded-workflow-analyzer-rules).
-
-Rule prefixes and full schema: [cli-reference.md § analyzer-rules list](cli-reference.md).
-
-## Fix One Thing at a Time
-
-When an error occurs, identify the root cause, fix **only** that one thing, and re-run.
-
-- Never bundle a speculative improvement with the actual fix.
-- Changing two things at once makes it impossible to verify which change resolved the issue or whether the extra change introduced a new one.
-- One fix per iteration, re-run, verify.
-
-## Validation Iteration Loop
-
-Phase 1 — per-file `validate` after every edit. Phase 2 — one project-level `build` per edit session.
-
-```
-PHASE 1 — validate-clean (per-file):
-  FOR each file created or edited in this session:
-    REPEAT:
-      1. uip rpa validate --file-path "<FILE>" --project-dir "<PROJECT_DIR>" --output json
-      2. IF validate has errors -> fix one root cause, GOTO 1
-      3. EXIT inner loop when validate is clean
-
-PHASE 2 — build-clean (per-project, once per edit session):
-  REPEAT:
-    1. uip rpa build "<PROJECT_DIR>" --log-level Warn --output json
-    2. IF build has errors -> identify offending file from build output
-       a. uip rpa validate --file-path "<OFFENDER>" --project-dir "<PROJECT_DIR>" --output json   # cheap targeted re-check
-       b. fix one root cause, GOTO 1
-    3. EXIT to Smoke Test
-```
-
-**Why both phases.** `validate` is static analysis: catches structural XAML, missing references, analyzer rules, schema violations. `build` is the compiler: catches **unknown member names** (e.g. `NGetText.Value` when the output member is `TextString` (or legacy `Text`)), **invalid enum values** (e.g. `Operator="StartsWith"` when the enum has no such member), **member resolution / CacheMetadata failures**, and attribute-form C# expression JIT failures. `validate` returns "no diagnostics found" for these; `build` flags them at compile time. Per-file `validate` plus one end-of-session `build` covers both error classes — trusting only `validate` ships broken workflows.
-
-**Target the specific file:** `validate --file-path` validates only the file you changed (faster than whole-project). `build` is project-scoped (no `--file-path`); when it errors, the output names the offending file — re-run `validate --file-path` on it as part of Phase 2's fix loop.
-
-**5-attempt cap per loop** — 5 attempts for each file's Phase 1 `validate` loop; a separate 5 attempts for the Phase 2 `build` loop. After a loop exhausts its budget, present the remaining errors to the user. They may require domain knowledge or environment-specific fixes. Each loop's counter resets when you start a new loop (e.g., new file, new user prompt, or resuming after user input).
-
-### Rules
-
-1. DO NOT stop until all errors are resolved (or cannot be resolved automatically).
-2. DO NOT obsess on one error -- if it cannot be resolved, skip it, continue, and defer to the user through an informative, step-by-step message at the end.
-3. DO NOT skip validation steps.
-4. DO NOT assume edits worked without checking.
-5. DO NOT bundle multiple fixes in one iteration. Fix the root cause, re-run, verify. Never add a speculative change alongside the actual fix -- changing two things at once makes it impossible to tell which one resolved the issue or whether the extra change introduced a new problem.
-
-See [cli-reference.md](cli-reference.md) for full `validate` and `run` command documentation.
-
-## Project Build Verification (Required Before Returning a Project)
-
-Every project returned to the user must compile. Phase 2 of the iteration loop above is this gate — when Phase 2 exits clean, the gate is satisfied. The standalone command below also satisfies it (for example, when re-verifying after a small fix outside an iteration loop):
-
-```bash
-uip rpa build "<PROJECT_DIR>" --log-level Warn --output json
-```
-
-`validate` is static analysis and misses compile-time failures: unknown member names, invalid enum values, member resolution / CacheMetadata failures, and JIT failures like `JIT compilation is disabled for non-Legacy projects` — see [xaml/csharp-expression-pitfalls.md](xaml/csharp-expression-pitfalls.md). If `build` fails, apply the Phase 2 fix loop (fix one root cause, re-run, cap at 5 attempts). A successful `run` smoke test substitutes for `build` — `run` compiles internally. Prefer the `run --skip-build` form when `build` has just passed (see Smoke Test below).
-
-### Errors `build` catches that `validate` misses
-
-| Error class | Example | Why `validate` misses it |
-|-------------|---------|----------------------------|
-| Unknown member name | `<uix:NGetText Value="[x]" />` (correct: `TextString`) | `validate` does not resolve property names against activity assemblies |
-| Invalid enum value | `Operator="StartsWith"` on `VerifyExpressionWithOperator` (enum has no such member) | Enum membership is checked at CacheMetadata / compile time, not static parse |
-| CacheMetadata / member resolution | Required-extension misses, type-mismatch on `InArgument<T>` | Surfaces only when the runtime instantiates the activity |
-| Attribute-form C# expressions | `Value="x + y"` in `expressionLanguage: CSharp` projects | JIT compiler needs the expression in element form — see [xaml/csharp-expression-pitfalls.md](xaml/csharp-expression-pitfalls.md) |
-
-When you see "no diagnostics found" from `validate`, you have not validated the file. Run `build` next.
-
-## Smoke Test
-
-`validate` (static analysis) and `run` (runtime compilation) use different validation paths. Some errors -- such as invalid enum values on activity properties -- pass static validation but fail at runtime. Always treat the smoke test as a critical validation step, not just an optional extra.
-
-After reaching 0 validation errors AND a clean project-level build (Phase 2), run the workflow to catch runtime errors (wrong credentials, missing files, logic bugs) that static validation cannot detect. Use `--skip-build` because the project has just been built clean — default `run` re-validates and re-builds internally, repeating ~10s of compilation:
-
-```bash
-# Run with default arguments (post-build, skip the redundant rebuild):
-uip rpa run --file-path "<FILE>" --skip-build --output json
-# Run with input arguments (repeat --input-arguments per key; = string, := raw JSON):
-uip rpa run --file-path "<FILE>" --skip-build --input-arguments key=value --output json
-# Run with verbose logging for debugging:
-uip rpa run --file-path "<FILE>" --skip-build --log-level Verbose --output json
-```
-
-Use bare `run` (without `--skip-build`) whenever the build artifact may be stale: **(a)** no recent project-level `build` has been performed, OR **(b)** any file has been edited between the last successful `build` and this `run`. `--skip-build` executes the existing compiled artifact, so any post-build edit is silently ignored until a fresh `build` runs.
-
-**When to run:**
-1. Workflow has no compilation errors but you want to verify runtime behavior
-2. Workflow involves file I/O, API calls, or data transformations that could fail at runtime
-3. User specifically asks to test the workflow
-
-**When NOT to run:**
-1. Workflow has side effects (sends emails, modifies databases, calls external APIs) -- warn the user first
-2. Workflow requires interactive input (UI automation, attended triggers)
-3. Compilation errors still exist (fix those first)
-
-**If runtime errors occur:** Analyze the output, apply the fix-one-thing rule, and loop back to fix. Stop after 2 failed runtime retry attempts and present the user with error details, a suggested fix, and options:
-
-```
-Workflow execution failed after 2 retry attempts.
-
-**Error Details:** <specific error message and location>
-**Suggested Fix:** <analysis of what went wrong>
-**Next Steps:** Would you like me to:
-A) <recommended fix approach>
-B) <alternative approach>
-C) <user-driven approach>
-```
-
----
-
-## RPA-Specific Fix Procedures
-
-### Package Error Resolution
-
-```
-Read: file_path="{projectRoot}/project.json"     -> check current dependencies
-
-Bash: uip rpa packages install --packages id=UiPath.Excel.Activities```
-
-Omit `version` to automatically resolve the latest compatible version (preferred — gets newest docs and features). Only pin a specific version when you have a reason to (e.g., known compatibility constraint).
-
-**If `packages install` fails:**
-- **Package not found**: Verify the exact package ID — check spelling, use `uip rpa activities find` to discover the correct package name from an activity's assembly
-- **Network/feed error**: The user may need to check their NuGet feed configuration in Studio settings
-
-### Resolving Dynamic Activity Custom Types
-
-Dynamic activities (e.g., Integration Service connectors) retrieved via `uip rpa activities get-default-xaml` (with `--activity-type-id`) may use **JIT-compiled custom types** for their input/output properties. After the activity is added to the workflow, when you need to discover the property names and CLR types of these custom entities (e.g., to populate an `Assign` activity targeting a custom type property, or to create a variable of a custom type), read the JIT custom types schema:
-
-```
-Read: file_path="{projectRoot}/.project/JitCustomTypesSchema.json"
-```
-
-### Focus Activity for Debugging
-
-When `validate` returns an error referencing a specific activity (by IdRef or DisplayName), use `focus-activity` to highlight it in the Studio Desktop designer. This helps the user see the problematic activity in context and verify fixes visually.
-
-> **Studio Desktop required.** `focus-activity` does not run against headless Studio — it manipulates the Studio Desktop designer UI. Before invoking it, ensure Studio Desktop is up via `uip rpa studio start --project-dir "<PROJECT_DIR>"` (see [environment-setup.md § Edge case: requiring Studio Desktop](environment-setup.md#edge-case-requiring-studio-desktop)). Skip this step entirely on headless-only setups — `validate` already includes the IdRef and file:line in its output, which is enough to locate the activity.
-
-```bash
-# Focus a specific activity by its IdRef (from the error output):
-uip rpa focus-activity --activity-id "Assign_1"
-# Focus all activities sequentially (useful for walkthrough):
-uip rpa focus-activity```
-
-This is especially useful when:
-- An error references an activity and you want the user to confirm the context
-- You've made a fix and want to show the user which activity was modified
-- The error is ambiguous and you need to verify which activity instance is affected

package/skills/uipath-rpa/references/xaml/csharp-expression-pitfalls.md

@@ -1,43 +0,0 @@
-# C# Expression Pitfalls
-
-**Scope:** XAML workflow files in projects whose `project.json` has `expressionLanguage: CSharp`. These rules govern how XAML expressions are authored — they do **not** apply to VB XAML projects, and they do **not** apply to coded workflows (`.cs` files with `[Workflow]` / `[TestCase]`). Coded workflows are plain C# — none of the `CSharpValue` / `CSharpReference` / attribute-form rules below are relevant there.
-
-Failure modes in scope: all pass static `validate` validation — they only surface at `CacheMetadata` time under `uip rpa build` or `uip rpa run`.
-
-For the canonical binding form per property, see [csharp-activity-binding-guide.md](csharp-activity-binding-guide.md).
-
-## Attribute-form expressions fail at runtime
-
-Any non-literal attribute value on an `InArgument<T>` / `OutArgument<T>` property (e.g. `Message="logMessage"`, `TextString="statusText"`) is deserialized as `VisualBasicValue<T>` by the XAML attribute parser — regardless of the project's `expressionLanguage`. On non-Legacy projects the VB JIT is disabled, so these fail at runtime:
-
-```
-System.InvalidOperationException: JIT compilation is disabled for non-Legacy projects.
-ExpressionToCompile { Code = "logMessage" ... } should have been compiled by the Studio Compiler.
-```
-
-**Fix:** use `<CSharpValue>` (read) or `<CSharpReference>` (write) child-element form for anything non-literal.
-
-**Attribute form is safe for:** literal strings on `InArgument<String>`, enums, numbers, booleans, `TimeSpan` literals, `{x:Null}` — values with a direct type converter that bypasses the expression parser.
-
-## `OutArgument<T>` attribute form fails at parse time
-
-`<uix:NGetText TextString="statusText"/>` raises `Failed to create a 'TextString' from the text 'statusText'` — `TextString` is `OutArgument<String>`, not a plain property, so the XAML parser has no converter for it. Always use the `<OutArgument>` + `<CSharpReference>` child form for output bindings.
-
-## `ThrowIfNotInTree` at runtime — two causes
-
-Same runtime stack, two distinct root causes:
-
-```
-System.InvalidOperationException: The argument of type 'System.String' cannot be used.
-Make sure that it is declared on an activity.
-  at System.Activities.Argument.ThrowIfNotInTree()
-```
-
-**Cause 1 — variable declared outside the `ActivityAction` scope.** `OutArgument<T>` + `<CSharpReference>` bound to a variable declared on a `Sequence` **outside** the `ActivityAction` body passes validation but throws at runtime.
-
-- **Typical case:** a UI activity inside `<uix:NApplicationCard.Body><ActivityAction><Sequence>` writes an output to a variable declared on the *outer* `Sequence` rather than the inner one.
-- **Fix:** declare the variable on the `Sequence.Variables` immediately inside the `ActivityAction`, not on a parent `Sequence` outside it.
-
-**Cause 2 — UIA activity authored without its `Version` attribute.** A UIA activity missing the `Version` its `activities get-default-xaml` starter emits (e.g. `NGetText` without `Version="V5"`) throws `ThrowIfNotInTree` at runtime on its argument bindings even when variable scoping is correct. This passes BOTH `validate` AND `build` clean — it surfaces only at run.
-
-- **Diagnosis rule:** when scoping is verified correct, diff the authored activity against its `uip rpa activities get-default-xaml` starter and restore any missing attributes — the starter's `Version` in particular. Never strip an attribute the starter emits.