@uipath/skills 1.197.0 → 1.197.2

package/skills/uipath-review/references/rpa/long-running-workflow-issues.md

@@ -20,7 +20,7 @@ Antipatterns specific to UiPath Orchestration Processes (long-running workflows
 
 **Symptom:** `Delay` or `Retry Scope` activities placed directly in Main.xaml of an Orchestration Process, NOT wrapped in a `No Persist Scope`.
 
-**Impact:** `Delay` causes the workflow to suspend but Orchestrator cannot resume it (no persistence bookmark). `Retry Scope` behaves unpredictably — the workflow suspends instead of retrying, requiring manual resumption per attempt. Long-standing bug (~5 years).
+**Impact:** `Delay` causes the workflow to suspend but Orchestrator cannot resume it (no persistence bookmark). `Retry Scope` behaves unpredictably — the workflow suspends instead of retrying, requiring manual resumption per attempt. Long-standing platform behavior.
 
 **Detection:** If `project.json` has `"projectType": "Orchestration"`, grep Main.xaml for `RetryScope` or `Delay` that are not inside a `NoPersistScope`.
 
@@ -46,7 +46,7 @@ Antipatterns specific to UiPath Orchestration Processes (long-running workflows
 
 **Impact:** Runtime crash during suspend: the workflow state cannot be serialized to storage.
 
-**Detection:** Run Workflow Analyzer rules `ST-DBP-025` (variables) and `ST-DBP-028` (arguments). For coded workflows, check variables in scope of `WaitFor*` calls for serializable types. Serializable-safe types: Text, Boolean, Number, Array of primitives, DateTime, DataTable loaded via Read Range (not `new DataTable()`), GenericValue.
+**Detection:** Run Workflow Analyzer rules `ST-DBP-025` (variables) and `ST-DBP-028` (arguments). For coded workflows, check variables in scope of `WaitFor*` calls for serializable types. Serializable-safe types: Text, Boolean, Number, Array of primitives, DateTime, named DataTable (`TableName` set — Read Range sets it automatically; a bare `new DataTable()` without a name fails serialization), GenericValue.
 
 **Fix:** Replace non-serializable types with serializable alternatives or marshal data to strings/JSON before suspend. Close browser/file handles before suspend; re-open after resume.
 

package/skills/uipath-review/references/rpa/modern-studio-issues.md

@@ -18,7 +18,7 @@ Antipatterns specific to UiPath Studio 2024.10+ (Modern design experience, coded
 
 **Symptom:** Project contains more than one `Single Excel Process Scope` activity across its workflows.
 
-**Impact:** COM object error at runtime. This activity manages a single Excel COM instance — multiple scopes conflict. Documented erratum since June 2025.
+**Impact:** COM object error at runtime. This activity manages a single Excel COM instance — multiple scopes conflict.
 
 **Detection:** Grep all `.xaml` files for `SingleExcelProcessScope`. Flag if count > 1 across the project.
 
@@ -30,7 +30,7 @@ Antipatterns specific to UiPath Studio 2024.10+ (Modern design experience, coded
 
 **Symptom:** Using Modern `Use Excel File` + `Read Range` for large datasets (>10K rows) without mitigation.
 
-**Impact:** ~100x slower than Classic `Excel Application Scope` + `Read Range`. 30K rows: ~5s Classic vs >15 minutes Modern. 17K rows reported at 30 minutes. Affects SAP-exported data with special characters / images especially badly.
+**Impact:** Orders of magnitude slower than Classic `Excel Application Scope` + `Read Range` on large sheets — community reports range from minutes to tens of minutes for 10K+ rows. Affects SAP-exported data with special characters / images especially badly.
 
 **Detection:** Project uses Modern design + `Use Excel File` + `Read Range` on datasets known to exceed 10K rows. `ReadOnly` property not set.
 

package/skills/uipath-review/references/rpa/rpa-common-issues.md

@@ -31,55 +31,19 @@ done
 
 ### Windows-Legacy Compatibility Lock-In
 
-**Symptom:** Project uses Windows-Legacy compatibility (`expressionLanguage: "VisualBasic"` with no/Legacy `targetFramework`).
+**Symptom:** Project uses Windows-Legacy compatibility (`project.json` has no `targetFramework` or `targetFramework: "Legacy"` — the reliable marker; expression language is usually VisualBasic but Legacy C# projects exist).
 
 **Support status:** Legacy is supported **indefinitely** in Studio LTS (2024.10, 2025.10, 2026.10, and all future LTS releases). It is NOT a deployment blocker. It is NOT a mid-term support risk. Deprecation means "no new features in Legacy," not "Legacy will be removed."
 
 **NEVER flag as Critical based on framework alone.** Severity is Warning if blocking desired modern features, Info if Studio LTS is the organizational standard.
 
-**What you lose by staying on Legacy (ranked by developer-impact):**
-
-1. **Healing Agent** — AI-powered selector self-healing at runtime. When selectors drift from app updates, DOM changes, or resolution shifts, Healing Agent recovers automatically. Legacy has no self-healing — every broken selector becomes a ticket + redeploy.
-2. **Unified Target Method** (Strict + Fuzzy + Image + Anchor) — modern multi-strategy UI targeting. Legacy uses single-strategy classic selectors that break on minor UI changes.
-3. **Object Repository + shared UI Libraries** — centralized, hierarchical, versioned UI descriptors. Legacy has limited OR support.
-4. **Coded test cases (C#)** + Test Manager integration — real testing rigor (mocks, assertions, CI-runnable). Legacy testing is Studio Test Activity only.
-5. **Autopilot™** — AI-assisted Studio development (generate, fix, explain workflows).
-6. **ScreenPlay** — modern scripted UI interaction experience.
-7. **AI Agents + Maestro + Agentic Automation** — participate as actors in multi-agent BPMN processes.
-8. **Coded workflows (C#)** — type safety, unit testability, IDE refactoring for complex logic.
-9. **Modern .NET (JIT)** — compiled performance + modern encryption/TLS. Legacy runs on .NET Framework 4.6.1.
-10. **Cross-platform execution** (Linux robots).
-11. **Studio STS** (2-month cadence) — locked to annual LTS on Legacy.
-
 **When recommending migration, lead with the 2-3 features most relevant to the project's actual pain points** — heavy UI maintenance → Healing Agent + Unified Target + Object Repository; weak testing → coded tests + Test Manager; AI use cases → Autopilot + Agents.
 
 **Valid reason to stay on Legacy:** SOAP web services (only supported in Legacy).
 
-**Migration paths:**
-1. **Studio's built-in Converter** — single project, framework-only (W-L → W)
-2. **Activity Migrator Tool** (`UiPath.Upgrade.exe`) — bulk, activity-level. Handles:
-   - W-L → Windows framework
-   - Classic → Modern UI Automation (needed for Unified Target/Healing Agent)
-   - Classic Outlook → Microsoft 365 Mail
-
-For most real-world migrations (projects with Classic UIA), **Activity Migrator is the right tool**.
-
-**Migration blockers** (manual rework required — Activity Migrator cannot convert these):
-- All CV activities, all Trigger activities
-- Anchor Base, Element Scope, Double Click variants
-- Classic OCR engines, Callout, Set Clipping Region
-- `Outlook Desktop Mail Messages Trigger` (no M365 folder-monitoring equivalent)
-- `Get Outlook Desktop Mail Messages` filter options
-
-**Pre-flight order:**
-1. Run `UiPath.Upgrade.exe analyze` first (dry-run) — review SARIF report
-2. Migrate libraries BEFORE consumer projects
-3. Pilot on one project before `bulk`
-4. Prepare ConnectionId config file for M365 mail migration
-
 **Route Legacy-specific deep validation to `uipath-rpa` (Legacy mode).** The standard `uip rpa` tooling targets Windows/Cross-platform projects; Legacy mode in `uipath-rpa` uses the `uip rpa-legacy` CLI internally.
 
-For full severity matrix and post-migration checks, see rpa-review-checklist.md §10 "Windows-Legacy Compatibility".
+Ranked feature list, severity matrix, migration tooling and blockers, pre-flight order, and post-migration checks: [rpa-review-checklist.md §10 "Windows-Legacy Compatibility"](rpa-review-checklist.md).
 
 ### Wrong Expression Language
 
@@ -120,7 +84,7 @@ find . -name "*.xaml" -size +500k -exec ls -lh {} \;
 
 **Symptom:** Automation starts fast (30 sec/item) and progressively slows to minutes per item after 1+ hours. No crash — just gets slower.
 
-**Impact:** Jobs that should take 1 hour take 8. Timeouts, missed SLAs, wasted robot licenses. The most consistently reported performance issue on the UiPath Forum.
+**Impact:** Jobs that should take 1 hour take 8. Timeouts, missed SLAs, wasted robot licenses.
 
 **Root causes:** Excel processes not killed between iterations (dozens of orphaned EXCEL.EXE accumulate), browser DOM growth in web loops, DataTable variables growing with uncleared temp data, Log Message flooding inside tight loops.
 
@@ -304,9 +268,9 @@ grep -ri "apikey\|api_key\|secret\|token" --include="*.xaml" --include="*.cs" --
 
 **Impact:** Business exceptions (data issues) get retried unnecessarily. System exceptions (transient failures) don't get retried.
 
-**Detection:** Check exception handling in REFramework's SetTransactionStatus or equivalent logic.
+**Detection:** Grep all `.xaml` and `.cs` files for `BusinessRuleException` — if absent, the distinction is missing entirely. Also check exception handling in REFramework's SetTransactionStatus or equivalent logic.
 
-**Fix:** Throw `BusinessRuleException` for data/validation issues (no retry). Let `System.Exception` propagate for transient failures (auto-retry).
+**Fix:** Throw `BusinessRuleException` for data/validation issues (e.g., `Throw New BusinessRuleException("Invoice amount is negative")`) — marked Failed-Business, not retried. Let system exceptions propagate for transient failures (auto-retry).
 
 ### ContinueOnError Overuse
 
@@ -456,7 +420,7 @@ Filenames like `CheckIfEmployeeExists.xaml` are one manifestation. Inline checks
 | No | Guards + adequate retry but no per-sub-item progress output | **Info** | "Partial-failure recovery could be improved with per-sub-item progress markers written to queue Output for observability." |
 | Yes | Guards + retry + per-sub-item output | **Info** | "Working with compensation; consider dispatcher/performer if volume grows." |
 
-**When it cannot be split — hardening checklist:**
+#### When it cannot be split — hardening checklist
 
 If the domain forces a one-to-many shape that cannot be decomposed into separate queue items (e.g., SAP multi-step enrollment, carrier portal group submission, bank wire requiring sequential steps in one session), the reviewer MUST verify ALL of these safeguards. Each missing safeguard is a separate finding.
 
@@ -474,8 +438,10 @@ If the domain forces a one-to-many shape that cannot be decomposed into separate
 | 10 | **Timeout per sub-item** | Each sub-item has a reasonable timeout (not relying only on the global job timeout) | Info — one hanging sub-item blocks all remaining items |
 
 Report each missing safeguard as a numbered finding. Example:
-- `[W-005] One-to-many loop in Process.xaml (line 47): no per-sub-item status tracking — partial progress invisible after crash`
-- `[C-003] One-to-many loop in Process.xaml (line 47): no idempotency guard on sub-item write — retry creates duplicate records`
+- `[W-005] One-to-many loop in Process.xaml (For Each 'Process Employees'): no per-sub-item status tracking — partial progress invisible after crash`
+- `[C-003] One-to-many loop in Process.xaml (For Each 'Process Employees'): no idempotency guard on sub-item write — retry creates duplicate records`
+
+Anchor findings on activity display names, never XAML line numbers — line numbers are meaningless in Studio.
 
 **Why this shape is a real problem (when remediation is weak):**
 
@@ -509,7 +475,7 @@ The shape is what the execution body does. Remediation posture and business cons
 
 **Symptom:** Environment-specific values (URLs, paths, queue names) stored in Config.xlsx Settings or Constants sheets instead of the Assets sheet.
 
-**Impact:** Deploying to a new environment requires manually editing Config.xlsx and republishing. Secrets leak into version control. The most debated configuration issue on the UiPath Forum.
+**Impact:** Deploying to a new environment requires manually editing Config.xlsx and republishing. Secrets leak into version control.
 
 **Detection:** Read Config.xlsx — verify: Constants sheet contains only truly constant values (MaxRetryNumber, timeouts). Settings sheet contains only environment-agnostic settings. All environment-specific values (URLs, paths, credentials, queue names) are in the Assets sheet, referencing Orchestrator Asset names.
 
@@ -535,16 +501,6 @@ The shape is what the execution body does. Remediation posture and business cons
 
 **Fix:** Implement CloseAllApplications with graceful Close Application activities for each app. Implement KillAllProcesses with Kill Process for each app process name.
 
-### All Exceptions Treated as System Exceptions
-
-**Symptom:** No `BusinessRuleException` thrown anywhere. All failures trigger retry logic.
-
-**Impact:** Data validation failures (missing fields, invalid formats, duplicate records) get retried and will never succeed. Wastes queue retry capacity and processing time.
-
-**Detection:** Grep for `BusinessRuleException` in all .xaml and .cs files. If not found, business exception handling is likely missing.
-
-**Fix:** Throw `BusinessRuleException` for data issues: `Throw New BusinessRuleException("Invoice amount is negative")`. These get marked as Failed-Business and are not retried.
-
 ### Business Logic in Framework Folder
 
 **Symptom:** Custom code added to files in the `Framework/` folder (InitAllSettings.xaml, framework-level GetTransactionData.xaml, etc.).
@@ -573,7 +529,7 @@ The shape is what the execution body does. Remediation posture and business cons
 
 ### Excel Process Hanging
 
-**Symptom:** Excel Application Scope completes but Excel process stays alive in background. Robot hangs indefinitely waiting for Excel. Occurs in 10-20% of executions.
+**Symptom:** Excel Application Scope completes but Excel process stays alive in background. Robot hangs indefinitely waiting for Excel.
 
 **Detection:** Check for orphaned EXCEL.EXE processes after automation runs. Check for timeout errors in Excel activities.
 
@@ -621,7 +577,7 @@ Issues where the bot reports success but the outcome is wrong. These are the cos
 
 **Symptom:** Bot writes data (Excel, database, web form, API POST) but does not verify the write succeeded. The target system may accept the command but fail to save.
 
-**Impact:** Bot reports success. The next morning someone discovers blank reports, missing records, or duplicate entries. Occurs ~1% of executions but extremely costly.
+**Impact:** Bot reports success. The next morning someone discovers blank reports, missing records, or duplicate entries. Rare but extremely costly.
 
 **Detection:** After every write operation (`Write Range`, `Submit Form`, HTTP POST, database INSERT), check for a verification step — read-back, count check, or status code validation.
 
@@ -669,7 +625,7 @@ Issues specific to coded workflows that differ from XAML patterns.
 
 **Detection:** Check if coded library workflows use service accessors. Test library invocation from an external project.
 
-**Fix:** Ensure library workflows are properly bootstrapped. Use `RunWorkflow` with strongly-typed invocation instead of direct class instantiation.
+**Fix:** Ensure library workflows are properly bootstrapped. Invoke via the generated strongly-typed `workflows.<NAME>()` accessors instead of direct class instantiation.
 
 ## Concurrency Issues
 
@@ -727,7 +683,7 @@ Issues specific to coded workflows that differ from XAML patterns.
 
 **Symptom:** `Get Asset` activity used to retrieve a Credential-type Orchestrator asset (instead of `Get Credential`).
 
-**Impact:** `Get Asset` cannot retrieve credential-type assets — it returns only username as a string, password is null. Automation appears to work but login fails silently downstream.
+**Impact:** `Get Asset` cannot retrieve credential-type assets — depending on Orchestrator version it errors at runtime or yields no usable password. Either way the downstream login fails.
 
 **Detection:** In Config.xlsx Assets sheet, identify credential assets (by name convention or known usage). Grep XAML for `GetAsset` activities retrieving those names — should be `GetCredential`.
 

package/skills/uipath-review/references/rpa/rpa-review-checklist.md

@@ -32,7 +32,7 @@ Comprehensive quality checklist for UiPath RPA projects — coded workflows (C#)
 | Logical folder structure used (Framework/, BusinessLogic/, Utilities/, Data/) | Info | `ls` project root — check for meaningful subdirectories |
 | Main.xaml acts as orchestrator only (no direct UI or business logic) | Warning | Grep Main.xaml for UI activities (`NClick`, `NTypeInto`, `NGetText`, `Click`, `TypeInto`, `GetText`, `SendHotkey`, `NCheckAppState`). If any are found, Main.xaml is doing work it should delegate. Should contain mostly `InvokeWorkflowFile` calls, <30 activities total. |
 | No leftover breakpoints in production code | Warning | Grep `.xaml` for breakpoint metadata |
-| No workflow exceeds 80 activities OR 30 root-scope variables OR 10 nesting levels | Warning | Count activities, Variables elements, and max indentation depth per .xaml. Report these counts in the review (never "lines") |
+| No workflow exceeds 50 activities OR 30 root-scope variables OR 7 nesting levels (ST-MRD-009 default) | Warning | Count activities, Variables elements, and max indentation depth per .xaml. Report these counts in the review (never "lines") |
 
 ### Workflow Dependency Graph
 
@@ -55,7 +55,7 @@ Comprehensive quality checklist for UiPath RPA projects — coded workflows (C#)
 
 | Check | Severity | How to Verify |
 |---|---|---|
-| All referenced packages are installable | Critical | `uip rpa packages install` |
+| All referenced packages resolvable | Critical | `uip rpa build "<PROJECT_DIR>" --output json` fails on unresolvable packages. Do NOT run `uip rpa packages install` — review is read-only |
 | No unused packages | Warning | Workflow Analyzer rule ST-USG-010 |
 | Version constraints use proper syntax (`[1.0.0]`, `[1.0.0, 2.0.0)`) | Warning | Read project.json dependencies |
 | No package version conflicts | Critical | Check for multiple versions of same package family |
@@ -99,11 +99,11 @@ Comprehensive quality checklist for UiPath RPA projects — coded workflows (C#)
 
 | Check | Severity | How to Verify |
 |---|---|---|
-| All `.xaml` files pass validation | Critical | `uip rpa validate --file-path "<FILE>" --project-dir "<DIR>" --output json` |
+| All `.xaml` files pass validation | Critical | `uip rpa validate --file-path "<FILE>" --project-dir "<PROJECT_DIR>" --output json` |
 | Expression language in all XAML files matches `project.json` setting | Critical | Check `expressionLanguage` consistency |
 | No C# syntax in VB.NET projects | Warning | If `expressionLanguage` is `VisualBasic`, grep all `.xaml` for C# patterns: `!=`, `&&`, `\|\|`, `null` (VB uses `Nothing`), `$"` (interpolated strings), `=>` (lambda), `//` (comments), `typeof()` (VB uses `GetType()`). These compile-fail or silently misbehave. |
 | No activities with default display names ("Sequence", "Assign", "If") | Warning | Workflow Analyzer rule ST-MRD-002 |
-| No deeply nested activities (>5 levels) | Warning | Workflow Analyzer rule ST-MRD-009 |
+| No deeply nested activities (>7 levels, ST-MRD-009 default) | Warning | Workflow Analyzer rule ST-MRD-009 |
 | No empty Catch blocks | Warning | Workflow Analyzer rule ST-DBP-003 |
 | No empty Sequences | Info | Workflow Analyzer rule ST-MRD-008 |
 | No unreachable activities | Warning | Workflow Analyzer rule ST-MRD-004 |
@@ -113,7 +113,7 @@ Comprehensive quality checklist for UiPath RPA projects — coded workflows (C#)
 
 | Check | Severity | How to Verify |
 |---|---|---|
-| Variables follow PascalCase/camelCase | Warning | Workflow Analyzer rule ST-NMG-001 (regex: `^(dt_)?([A-Z]\|[a-z])+([0-9])*$`) |
+| Variables follow PascalCase/camelCase | Warning | Workflow Analyzer rule ST-NMG-001 (default regex: `^([A-Z]\|[a-z])+([0-9])*$`; the `dt_` prefix convention is ST-NMG-009, not part of ST-NMG-001) |
 | DataTable variables prefixed with `dt_` | Info | Workflow Analyzer rule ST-NMG-009 |
 | Arguments use directional prefixes (`in_`, `out_`, `io_`) | Warning | Workflow Analyzer rule ST-NMG-002 |
 | No variable-argument name conflicts (shadowing) | Warning | Workflow Analyzer rules ST-NMG-005, ST-NMG-006 |
@@ -195,7 +195,7 @@ Selectors are ranked by attribute stability. When reviewing, assess which tier t
 
 ## 5. REFramework Compliance (Queue-Based Projects)
 
-> **Transaction Granularity:** REFramework correctness requires that the queue item's declared unit of work matches the unit of work `ProcessTransaction.xaml` actually performs. Run Step 3a (Unit of Work Discovery) in SKILL.md before this section — any mismatch is a Granularity Mismatch finding. Strong signal that a mismatch exists: presence of `CheckIf<X>Exists.xaml` or `Verify<X>Exists.xaml` in the project (homegrown idempotency guards compensating for bulk-in-transaction). See [rpa-common-issues.md](rpa-common-issues.md) → "Granularity Mismatch" for the full signals, severity matrix, and fixes.
+> **Transaction Granularity:** REFramework correctness requires that the queue item's declared unit of work matches the unit of work `ProcessTransaction.xaml` actually performs. Run Step 3a (Unit of Work Discovery) in SKILL.md before this section — classify the shape as one-to-one / one-to-many / unclear. Strong signal of a one-to-many shape: presence of `CheckIf<X>Exists.xaml` or `Verify<X>Exists.xaml` in the project (homegrown idempotency guards compensating for bulk-in-transaction). See [rpa-common-issues.md](rpa-common-issues.md) → "Transaction Shape: One-to-Many" for the full signals, severity matrix, fixes, and the "When it cannot be split — hardening checklist" subsection.
 
 
 If the project uses or should use the REFramework pattern:
@@ -205,9 +205,9 @@ If the project uses or should use the REFramework pattern:
 | Check | Severity | How to Verify |
 |---|---|---|
 | State Machine with 4 states: Init, GetTransactionData, ProcessTransaction, EndProcess | Warning | Read Main.xaml structure |
-| All 7 transitions present (Init→GetTx, Init→End, GetTx→ProcessTx, GetTx→End, ProcessTx→GetTx, ProcessTx→Init, Init→Init retry) | Warning | Check transitions |
-| Init state has SystemException → Init self-retry transition (not just Init → End) | Warning | Transient login/app failures should retry, not terminate the process |
-| Init state does NOT fetch transaction data (data fetched in GetTransactionData) | Warning | Check InitAllApplications / InitAllSettings — no Read Range / Get Queue Items / Data Scraping |
+| All 7 stock transitions present (Init→GetTx, Init→End, GetTx→ProcessTx, GetTx→End, ProcessTx→GetTx on Success, ProcessTx→GetTx on BusinessRuleException, ProcessTx→Init on SystemException) | Warning | Check transitions |
+| Init state has SystemException → Init self-retry transition (enhancement — the stock template goes Init → End on failure) | Warning | Transient login/app failures should retry, not terminate the process |
+| Queue-based projects: Init state does NOT fetch transaction data (fetched per-item in GetTransactionData). Non-queue projects load bulk data in Init — see "Non-Queue REFramework" below | Warning | Check InitAllApplications / InitAllSettings — no Read Range / Get Queue Items / Data Scraping in queue-based projects |
 | REFramework not forced onto single-shot / stateless processes | Info | If no real transaction iteration (one execution per run), REFramework is overkill — use a linear workflow |
 | If using non-queue data source: `QueueRetry` flag in SetTransactionStatus properly handled (not left at queue default) | Critical | Grep SetTransactionStatus for `QueueRetry` or `in_TransactionItem.RetryNo` logic that only applies to QueueItems |
 | If using DataTable: `GetTransactionData` uses `dt.Rows(in_TransactionNumber - 1)` (DataTable is 0-indexed; transaction counter is 1-indexed) | Warning | Off-by-one skips first row, errors on last |
@@ -345,8 +345,9 @@ Run Workflow Analyzer and verify no Error-level violations. Key rules to check:
 | No hardcoded environment-specific values (URLs, paths) | Warning | Grep for hardcoded values |
 | No debug artifacts or test data included | Info | Check for leftover files |
 | Global Exception Handler configured | Info | Check project settings |
-| Project builds and validates clean | Critical | `uip rpa validate` returns 0 errors |
-| Smoke test passes | Warning | `uip rpa run` completes successfully |
+| Project validates clean | Critical | `uip rpa validate --file-path "<ENTRY_FILE>" --project-dir "<PROJECT_DIR>" --output json` returns 0 errors for every entry point |
+| Project builds clean | Critical | `uip rpa build "<PROJECT_DIR>" --output json` — catches unknown member names and invalid enum values that `validate` misses (SKILL.md Critical Rule 2) |
+| Recent successful run evidence (job history, test results) | Info | Do NOT run the automation during review — `uip rpa run` executes UI actions and writes. Check existing evidence; runtime verification routes to `uipath-rpa` |
 
 ## 10. Windows-Legacy Compatibility
 
@@ -375,11 +376,11 @@ Ordered by developer-impact for a real production RPA team. **When recommending
 | 2 | UI Automation resilience | **Unified Target Method** (Strict + Fuzzy + Image + Anchor) — modern multi-strategy targeting. Legacy uses only classic single-strategy selectors, which break on minor UI changes. |
 | 3 | Reusable UI management | **Object Repository + UI Libraries** — centralized, hierarchical, versioned UI descriptors. Legacy has limited Object Repository support and no shared UI Library consumption. |
 | 4 | Testing quality | **Coded test cases (C#)** + **Test Manager integration** — write real unit/integration tests for workflows. Legacy testing is Studio Test Activity only — limited assertions, no mocking framework. |
-| 5 | Development velocity | **Autopilot™** — AI-assisted Studio (generate activities from description, fix workflows, explain code). Legacy projects cannot use Autopilot. |
+| 5 | Development velocity | **Autopilot** — AI-assisted Studio (generate activities from description, fix workflows, explain code). Legacy projects cannot use Autopilot. |
 | 6 | ScreenPlay / modern UI orchestration | **ScreenPlay** — modern scripted UI interaction / recording experience. Available only for Modern projects. |
 | 7 | Platform capabilities | **AI Agents + Maestro orchestration + Agentic Automation** — participate as actors in multi-agent/multi-robot BPMN processes. Legacy processes cannot be invoked from / cannot invoke these. |
 | 8 | Code-based logic | **Coded workflows (C#)** alongside XAML — type safety, unit testability, IDE refactoring for complex business logic. |
-| 9 | Performance and security | **JIT-compiled .NET 6+** — faster execution, modern GC, modern encryption/TLS. Legacy runs on .NET Framework 4.6.1 with incremental performance and EOL security libraries. |
+| 9 | Performance and security | **Modern .NET (6+)** — faster execution, modern GC, current TLS/crypto stack. Legacy runs on .NET Framework 4.6.1 with aging security libraries. |
 | 10 | Platform reach | **Cross-platform execution** (Linux robots) — deployment flexibility for cloud-native environments. |
 | 11 | Studio cadence | **Studio STS** (2-month release cycle) — access to new activities and features as they ship. Legacy locks the team to Studio LTS (annual). |
 | 12 | Developer ergonomics | New design experience, Data Manager globals/constants, customizable library activity layouts. |
@@ -451,10 +452,10 @@ When Legacy is detected and migration is on the table, scan for **activities tha
 
 | Check | Severity |
 |---|---|
-| If planning migration: `UiPath.UIAutomation.Activities` target >= 25.10.21 | Warning |
-| If planning migration: `UiPath.MicrosoftOffice365.Activities` target >= 3.6.10 (if Mail migration needed) | Warning |
+| If planning migration: `UiPath.UIAutomation.Activities` at an Activity-Migrator-supported version (check current UiPath docs) | Warning |
+| If planning migration: `UiPath.MicrosoftOffice365.Activities` at a Migrator-supported version (if Mail migration needed) | Warning |
 | Studio 2024.10+ available to open migrated project | Warning |
-| For ST-AMG-001 post-migration rule: Studio 2025.10.8 LTS or 2026.0.189+ STS | Info |
+| Studio version supports the ST-AMG-001 post-migration rule (recent LTS/STS — check current docs) | Info |
 
 ### Migration Pre-Flight Checklist
 

package/skills/uipath-review/references/solution-review-guide.md

@@ -2,7 +2,7 @@
 
 Review guide for UiPath solutions (`.uipx`) — multi-project packages deployed as a single unit.
 
-> **Windows-Legacy compatibility guard:** `.uipx` solutions are NOT supported for Legacy projects. If any detected executable in the repo is Windows-Legacy (`expressionLanguage: "VisualBasic"` with no or `Legacy` `targetFramework`), **do NOT flag missing `.uipx` and do NOT recommend creating one**. Recommend migration to Modern compatibility (Windows / Cross-platform) if solution bundling is desired — that is the prerequisite, not the finding. Review each Legacy project independently.
+> **Windows-Legacy compatibility guard:** `.uipx` solutions are NOT supported for Legacy projects. If any detected executable in the repo is Windows-Legacy (`project.json` has no `targetFramework` or `targetFramework: "Legacy"`), **do NOT flag missing `.uipx` and do NOT recommend creating one**. Recommend migration to Modern compatibility (Windows / Cross-platform) if solution bundling is desired — that is the prerequisite, not the finding. Review each Legacy project independently.
 
 ## Solution Structure Validation
 

package/skills/uipath-rpa/SKILL.md

@@ -113,14 +113,14 @@ For the full decision flowchart, InvokeCode extraction rules, and detailed hybri
 
 ## Capture-First Fast Path
 
-When the request is "automate this dialog/form" or "build a UI test from these manual steps" — i.e. the bulk of the work is target capture, not coding — **defer authoring-phase prerequisites until target capture is complete**. The capture surface is interactive, app-state-sensitive, and time-bound; project-context discovery and analyzer rules add nothing during capture and steal time from it.
+When the request is "automate this dialog/form" or "build a UI test from these manual steps" — i.e. the bulk of the work is target capture, not coding — **defer authoring-phase prerequisites until target capture is complete**. The capture surface is interactive, app-state-sensitive, and time-bound; project-context discovery adds nothing during capture and steals time from it.
 
 **Fast-path order for capture-first tasks.** Read [ui-automation-guide.md](references/ui-automation-guide.md) and [uia-configure-target-workflows.md](references/uia-configure-target-workflows.md) in full first (Rule 7; the second is used in step 3). Then:
 
 1. **Pre-flight Window Baseline** — list top-level windows once; decide whether to launch the app ([§ Pre-flight: Window Baseline](references/ui-automation-guide.md)).
 2. **Inventory targets from manual steps** (Test Manager test case, PDD, or written script). Each "Click X" / "Enter Y" / "Select Z" / "Verify W" step maps to one OR element. Group by screen state ([§ Capturing from Manual Test Steps](references/ui-automation-guide.md)).
 3. **Capture all targets** screen by screen via `uia-configure-target` and screen advancement ([§ Multi-Step UI Flows](references/uia-configure-target-workflows.md)).
-4. **Then enter authoring phase:** project-context discovery (the precondition above), analyzer rules (Critical Rule 3 — Authoring-phase start), write code, validate.
+4. **Then enter authoring phase:** project-context discovery (the precondition above), write code, validate.
 
 Skip this path when the task has no UI surface (data transforms, IS connector calls, headless file/email automation). Also skip it when the task HAS a UI surface but **no live app to capture against** (app not installed, no GUI, capture deferred to a developer) — there is nothing to capture, so use the § Placeholder-Selector Stub Pattern above instead. The Window Baseline does not tell you if the app is installed and has a GUI — validate that separately (e.g. look for the executable on disk) or ask the user.
 
@@ -149,12 +149,12 @@ uip rpa activities find --query log --output json > /dev/null 2>&1 &
      - **No matches** → fall back to a built-in `--template-id` and tell the user nothing was found.
    - Built-in `--template-id` keywords map without a search: `library` → `LibraryProcessTemplate`, `test automation` / `test project` → `TestAutomationProjectTemplate`, otherwise `BlankTemplate`. When `--template-package-id` is set, `--template-id` is ignored. Full decision flow: [environment-setup.md § Template selection](references/environment-setup.md).
 2a. **Pass `--target-framework` AND `--expression-language` explicitly on every `uip rpa init` — never omit them.** Both are immutable after creation (Rule 23); omitting `--target-framework` silently yields a **Windows** project. Choose framework by where the automation runs: cross-platform / non-Windows runtime (Linux, container, serverless) or Studio Web editing → **`Portable`** (Cross-platform); Windows runtime using Windows-only capabilities (Excel COM, classic Office, WPF / `PresentationFramework`, Windows-only UIA) or Studio Desktop as the edit surface → **`Windows`** (not editable in Studio Web). A request needing *both* a cross-platform runtime and a Windows-only capability is contradictory — surface it, don't silently pick. **Windows - Legacy is a last resort** (explicit ask or hard .NET 4.6.1 need; never inferred from VB.NET or non-"X" classic activities) — create it in Legacy mode, not modern `init`. No signal → `AskUserQuestion` (Windows vs Cross-platform), framed around the runtime host. `--expression-language`: default `VisualBasic`, `CSharp` only on explicit request.
-3. **Phase-gated validation: analyzer rules run at AUTHORING-phase start, not session start.** Three-phase validation:
-   - **Authoring-phase start** (immediately before creating or editing any workflow file — `.cs` with `[Workflow]`/`[TestCase]`, or `.xaml`): `uip rpa analyzer-rules list --project-dir "<PROJECT_DIR>" --output json` to list the enabled Workflow Analyzer rules. Apply every `error` and `warning` rule during authoring so generated code passes `analyze` and `build` on the first attempt. Run once at this point; re-run only when project dependencies change. **DO NOT run at session start** — the call can take a minute or more (use `--scope <Activity|Workflow|Coded Workflow|Project>` to narrow if it times out, see [cli-reference.md § analyzer-rules list](references/cli-reference.md)). For capture-first tasks (target capture from manual test steps, dialog automation), this prerequisite is deferred until capture is complete — see § Capture-First Fast Path below.
-   - **Per-file** (after every create or edit): `uip rpa validate --file-path "<FILE>" --project-dir "<PROJECT_DIR>" --output json` until 0 errors. Catches structural XAML, missing references, analyzer rules, schema violations. Fix one thing per iteration.
+3. **Phase-gated validation.** Two-phase validation:
+   - **Per-file** (after every create or edit): `uip rpa validate --file-path "<FILE>" --project-dir "<PROJECT_DIR>" --output json` until 0 errors. Catches structural XAML, missing references, analyzer-rule violations, schema violations. Fix one thing per iteration.
    - **Project-level build** (after per-file `validate` is clean across all files in the edit session, and before declaring done): `uip rpa build "<PROJECT_DIR>" --output json` until clean. Catches what `validate` misses (unknown members, invalid enums, CacheMetadata / member resolution, attribute-form C# JIT) — full list at [validation-guide.md § Errors `build` catches that `validate` misses](references/validation-guide.md). If `build` errors, identify the offending file from the output and re-run `validate --file-path` on it.
    - **5-attempt cap per loop** — 5 attempts for each file's per-file `validate` loop; a separate 5 attempts for the project-level `build` loop. Fix one root cause per iteration.
    - **Smoke-test shortcut:** A successful `uip rpa run` substitutes for the standalone end-of-session `build` — `run` compiles internally. Prefer `run --skip-build` when `build` has just passed; see [validation-guide.md § Smoke Test](references/validation-guide.md).
+   - **Do NOT run `uip rpa analyzer-rules list` as an authoring prerequisite.** `validate` and `build` already enforce the enabled analyzer rules and report violations with rule IDs and recommendations — pre-fetching the rule list is speculative cost (the unscoped call can take a minute or more). It is an **on-demand** command: run it when the user asks about the project's best-practice/analyzer rules, or when repeated violations of the same rule family suggest authoring against the full rule set. See [validation-guide.md § On demand: List Analyzer Rules](references/validation-guide.md) and [cli-reference.md § analyzer-rules list](references/cli-reference.md).
 
    See [references/validation-guide.md](references/validation-guide.md).
 4. **ALWAYS validate files as you go AND verify the project builds before declaring done.** After every create or edit: per-file `validate` to clean. Project-level `build` runs once at the end of the edit session (or at any compile-verification gate) — not after every Edit, because `build` is project-scoped and rebuilds the entire project regardless of which file changed. `validate` clean alone is not "validated"; it cannot see member or enum errors — the project-level `build` is mandatory before declaring done. See [references/validation-guide.md](references/validation-guide.md).
@@ -166,7 +166,7 @@ uip rpa activities find --query log --output json > /dev/null 2>&1 &
 7. **[UIA] Before writing ANY UIA activity (XAML `<uix:N*>` or coded `uiAutomation.*` / `Descriptors.*`), MUST read [references/ui-automation-guide.md](references/ui-automation-guide.md) IN FULL** — including the mode-specific section (For Coded Workflows or For XAML Workflows) and Running UI Automation Workflows. No exceptions for "simple" UIs. Skipping this rule is the most common cause of hallucinated selectors, wrong target XML, and missing OR descriptors. NEVER hand-write selectors — use `uia-configure-target` exclusively (the guide explains how). This guide is the single entry point for UIA work: it routes you to [uia-configure-target-workflows.md](references/uia-configure-target-workflows.md), [uia-prerequisites.md](references/uia-prerequisites.md), and the package docs in order — the other UIA sections in this file point back here rather than restating the read mandate.
 7a. **[UIA] Verify UIA prerequisites before invoking `uia-configure-target`.** The minimum version and the prerequisite check live in [uia-prerequisites.md](references/uia-prerequisites.md) — read it and run that check first (do not hardcode the version from memory; that file is the only source of truth). If `UiPath.UIAutomation.Activities` is below the minimum or `{PROJECT_DIR}/.local/docs/packages/UiPath.UIAutomation.Activities/skills/uia-configure-target/SKILL.md` is absent, the `uip rpa uia` CLI is unavailable — and **both** target capture and indication depend on it, so indication is *not* a fallback when the package itself is missing. Ask the user to install/upgrade per uia-prerequisites.md. If they decline or the package cannot be installed, fall back to the **Placeholder-Selector Stub Pattern** (§ above) — real activities with `TODO Indicate` markers need no CLI. Never silently route to a non-existent skill path. Use indication capture only when a compatible UIA package *is* installed but `uia-configure-target` cannot see the element; record `UI capture: indication-only` in the plan header to skip `uia-configure-target` in that case.
 8. **Use `--output json`** on all CLI commands whose output is parsed programmatically.
-8a. **`run` / `debug start` success/failure verdict comes from the outer `Result` (and equivalently the inner `HasErrors`), NEVER from any log entry's `Level`.** A successful workflow may emit `Log Message` activities at `Error` or `Warning` level as observability — those are workflow-emitted data, not CLI failures. Compile failures, validation failures, and unhandled runtime exceptions all flip `HasErrors` and propagate to the outer `Result`. Treating log-entry levels as a failure signal flips green runs to "failed" and burns retries on healthy workflows. See [cli-reference.md § run](references/cli-reference.md) and [debugging.md § Reading Debug Output Effectively](references/debugging.md).
+8a. **`run` / `debug start` success/failure verdict comes from the outer `Result` (and equivalently the inner `HasErrors`), NEVER from any log entry's `Level`.** A successful workflow may emit `Log Message` activities at `Error` or `Warning` level as observability — those are workflow-emitted data, not CLI failures. Compile failures, validation failures, and unhandled runtime exceptions all flip `HasErrors` and propagate to the outer `Result`. Treating log-entry levels as a failure signal flips green runs to "failed" and burns retries on healthy workflows. In a debug session, check `DebugState` first — a `Suspended` response means an exception awaits your decision (continue / retry / ignore / cancel) while `HasErrors` is still `false`. See [cli-reference.md § run](references/cli-reference.md) and [debugging.md § Reading Debug Output Effectively](references/debugging.md).
 9. **For "leverage / reuse / find shared libraries" requests, search the tenant feed — not the local filesystem, NuGet.org, or keyword-permutation loops.** Run `uip or libraries list --limit 500 --output-filter "<JMESPath>" --output json`. On zero results from the filtered call, take the fallback branch — do not re-keyword. Skip when an SDD already records §16 "Shared libraries referenced" or the user has said "no shared libraries" earlier in the session. See [tenant-library-search-guide.md](references/tenant-library-search-guide.md) for the full procedure.
 10. **Register every test case file in `project.json` → `designOptions.fileInfoCollection`.** Applies to both XAML and coded test cases. Required keys, GUID format, JSON snippet, and full schema (including `dataVariationFilePath` for data-driven and `publishAsTestCase` for coded): [references/testing-guide.md § project.json Registration](references/testing-guide.md) and [assets/json-template.md](assets/json-template.md).
 
@@ -209,7 +209,6 @@ uip rpa activities find --query log --output json > /dev/null 2>&1 &
 
 1. **Post-`init` prerequisite batch.** After `uip rpa init` returns, these depend only on the project existing — NOT on each other. Emit them in ONE message:
    - `Read` `project.json` + the scaffolded `Main.xaml`
-   - `uip rpa analyzer-rules list` (Rule 3 authoring-phase prerequisite)
    - `uip rpa packages install` for packages already known from the request
    - `uip rpa activities find` for activities you'll author
 
@@ -372,7 +371,7 @@ Check `expressionLanguage` in `project.json`. VB.NET uses `[brackets]` for expre
 |---------|---------|
 | `activities find --query "<keyword>"` | Discover activities by keyword |
 | `activities get-default-xaml --activity-class-name "<class>"` | Get starter XAML for an activity |
-| `analyzer-rules list --project-dir "<dir>"` | List enabled Workflow Analyzer rules — run before generating |
+| `analyzer-rules list --project-dir "<dir>"` | List enabled Workflow Analyzer rules — on demand only (user asks about project rules, or repeated violations of one rule family); `validate`/`build` enforce the rules without it |
 | `validate --file-path "<file>"` | Per-file static validation (structure, references, analyzer rules) |
 | `build "<PROJECT_DIR>"` | Compile-time validation (member names, enum values, JIT expressions) — run after `validate` is clean |
 

package/skills/uipath-rpa/references/cli-reference.md

@@ -93,16 +93,17 @@ When a package is installed, its activity docs land under `{PROJECT_DIR}/.local/
 
 `uip rpa run` runs a workflow with no debugging; the `debug` group drives breakpoints, stepping, and exception handling (see [debugging.md](debugging.md)). For UI automation, prefer `debug start` over `run` so the app is preserved for selector repair on error. Cancel an active run or session with `uip rpa execution cancel`. Pass workflow inputs as repeatable `--input-arguments key=value` pairs (see [Passing structured inputs](#passing-structured-inputs)); discover the remaining flags (log level, skip-build, profiling) via `--help`.
 
-Both `run` and `debug start` return the same envelope: `{Result, Code, Data: {runResult: "<json-string>"}, ...}`. `Data.runResult` is a **JSON string** — parse it separately. It has three fields (plus optional `Profiling`):
+Both `run` and `debug start` return the same envelope: `{Result, Code, Data: {runResult: "<json-string>"}, ...}`. `Data.runResult` is a **JSON string** — parse it separately:
 
-- `Output` — the workflow's own serialized output arguments JSON (`""` for non-`Start*` commands). **Carries the workflow's data, not a verdict.**
-- `HasErrors` — `true` iff execution did not complete successfully (compile/validation failure, unhandled exception, cancellation, or timeout); `false` otherwise.
-- `ErrorMessage` — formatted error chain when `HasErrors: true`; `null` otherwise.
+- `Output` — the workflow's own serialized output arguments JSON, populated when the run completes. **Carries the workflow's data, not a verdict.**
+- `HasErrors` — `true` iff execution finished unsuccessfully (compile/validation failure, unhandled exception that ended the run, cancellation, or timeout); `false` otherwise — including while a debug session is `Suspended` on an exception, since the outcome is not decided yet.
+- `ErrorMessage` — formatted error chain when `HasErrors: true`; on debug responses it may instead carry guidance with `HasErrors: false`; `null` otherwise.
+- `DebugState` / `DebugDetails` — debug sessions only (`null` on plain `run`). Every debug command returns at the next stable state — `Paused` (activity + locals in `DebugDetails`), `Suspended` (exception + locals), `Running` (wait timed out), or `Completed`. See [debugging.md § The stable-state debug loop](debugging.md#the-stable-state-debug-loop-headless).
 - `Profiling.OutputDirectory` — present only when `--profiling` was passed on a start verb and collection succeeded; absolute path to the per-run `*.uistat` files and runtime screenshots. See [debugging.md § Profiling Workflow Performance](debugging.md#profiling-workflow-performance).
 
-Workflow log output (`Log Message`, system traces) does **not** appear in `runResult` — logs stream in real time on a separate channel; the envelope carries only the verdict and output data.
+Workflow log output (`Log Message`, system traces) does **not** appear in `runResult` — logs stream in real time on a separate channel; the envelope carries only the verdict, debug state, and output data.
 
-> **Single source of truth for success/failure: outer `Result` (equivalently `HasErrors` inside `runResult`).** `Result: "Success"` already accounts for compile failures, validation failures, and unhandled exceptions — the CLI propagates them. **DO NOT infer failure from a streamed log entry's `Level`.** A successful workflow may emit `Log Message` at `Error`/`Warning` level as observability — that is workflow data, not a CLI failure. Treating log levels as a verdict flips green runs to "failed" and burns retries.
+> **Single source of truth for success/failure of a completed run: outer `Result` (equivalently `HasErrors` inside `runResult`).** `Result: "Success"` already accounts for compile failures, validation failures, and unhandled exceptions — the CLI propagates them. **DO NOT infer failure from a streamed log entry's `Level`.** A successful workflow may emit `Log Message` at `Error`/`Warning` level as observability — that is workflow data, not a CLI failure. Treating log levels as a verdict flips green runs to "failed" and burns retries. In a debug session, check `DebugState` before `HasErrors` — `Suspended` means an exception awaits your decision while `HasErrors` is still `false`.
 
 ---