@uipath/skills 1.201.0-preview.621 → 1.202.0-preview.635

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

@@ -85,7 +85,7 @@ When a package is installed, its activity docs land under `{PROJECT_DIR}/.local/
 | **Read coded API doc** | `Read` `…/{PackageId}/coded/coded-api.md` — service API signatures for coded workflows |
 | **Read package overview** | `Read` `…/{PackageId}/overview.md` |
 | **List documented packages / activities** | `Bash`: `ls …/.local/docs/packages/` then `ls …/{PackageId}/activities/` |
-| **Search activity docs** | `Glob` `**/*.md` under `…/.local/docs/packages/`, then `Read` matches. **Not `Grep`** — `.local/` is gitignored and `Grep` skips it. |
+| **Search activity docs** | `ls` the exact package directory via Bash (`…/.local/docs/packages/<PackageId>/activities/`), then `Read` the matching file by path. **NOT `Glob` or `Grep`** — both skip gitignored `.local/`; a miss from either proves nothing. |
 
 ---
 
@@ -93,17 +93,32 @@ 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:
+Both wrap the result in `{Result, Code, Data}`. **`Data`'s inner shape varies by CLI build and run state — read it by key presence, never by assumed schema.** A completed run returns the fields flat (`output`, `errors`, `logEntries` — the workflow's own `Log Message` output arrives in `logEntries`); suspended and stepping debug sessions, and older builds, nest a JSON-encoded string on `Data.runResult` (`HasErrors`, `ErrorMessage`, `DebugState`, `DebugDetails`, `Profiling`). Field-by-field meaning for both shapes: [debugging.md § Output Format](debugging.md#output-format).
 
-- `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).
+> **A completed run passed only when `Data.errors` is empty AND `Data.output` is `"Session ended"`.** The outer `Result` qualifies the CLI invocation, not the workflow — it stays `Success` through unhandled exceptions, compile failures, and a missing entry point, so **never read `Result: "Success"` as a passing run**. Both conditions are required, because `errors` stays empty for a missing entry point and for a debug session suspended on an exception. **DO NOT infer failure from a log entry's `level`** — a clean run that logs at `Error` still returns `errors: []` and `output: "Session ended"`; treating log levels as a verdict flips green runs to "failed" and burns retries. Field-by-field behavior per scenario: [debugging.md § Output Format](debugging.md#output-format).
 
-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.
+### Capturing the verdict
 
-> **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`.
+**Always pass `--output-filter` on `run` / `debug start`.** It applies a JMESPath expression to `Data` server-side, so one call returns the verdict and the workflow's own `Log Message` output in ~14 lines:
+
+```bash
+uip rpa debug start --file-path "<FILE>" --project-dir "<PROJECT_DIR>" --output json \
+  --output-filter "{output: output, errorCount: length(errors), errors: errors, runtimeLog: logEntries[?source=='Debug' && level!='Trace'].message | [-8:]}"
+```
+
+```json
+{ "Result": "Success", "Code": "ToolResult", "Data": {
+    "output": "Session ended", "errorCount": 0, "errors": [],
+    "runtimeLog": ["... execution started", "5 + 5 = 10", "... execution ended in: 00:00:08"] } }
+```
+
+Adjudicate straight off `output` and `errorCount` per the rule above; `runtimeLog` carries the workflow's own messages. The `source=='Debug'` term drops compile-phase noise (`Compiling files`, `Registering activities metadata`, dozens of `Unregistered service requested`); widen the slice past `[-8:]` for a chattier workflow.
+
+**Never `| tail -N` (or `| head`) the unfiltered payload.** `logEntries` runs to hundreds of trace lines, so tailing is the reflex — but `output` and `errors` are emitted *above* it, so tailing keeps the noise and drops the verdict. Recovering them means re-running, which re-drives the application; a workflow that is not re-run-safe behaves differently the second time.
+
+When a failure needs more than the filter shows (compile-phase error, root cause older than the slice), redirect the full payload — `> run.json` — and query the file. `jq` is absent on a standard Windows agent host; use PowerShell: `(Get-Content run.json -Raw | ConvertFrom-Json).Data.logEntries | Where-Object level -ne Trace`.
+
+> **A style diagnostic can fail the verdict.** `Data.errors` carries analyzer/IDE diagnostics, not just runtime faults — `IDE0063` ("'using' statement can be simplified") sets `output` to `"Execution aborted. See attached errors for more information"` though the body ran and logged normally. When `errors` holds a diagnostic ID rather than an exception, fix the code style and re-run; do not hunt for a runtime failure that did not happen.
 
 ---
 
@@ -132,13 +147,13 @@ Rules:
 
 `uip rpa validate` returns diagnostics for a file or the whole project, re-validating first by default (`--skip-validation` reads cached, possibly stale, results; `--min-severity` filters). Confirm flags via `uip rpa validate --help`.
 
-> **Known issue: an absolute `--file-path` with an absolute `--project-dir` falsely fails** with `The targeted project file <X> is not in the project folder <Y>`. The CLI normalizes `--file-path` to forward slashes but leaves `--project-dir` with backslashes, then string-compares — same path, different separators. Pass `--file-path` **relative** to the project directory (e.g. `--file-path "Main.xaml"`) to sidestep it. For a project-level compile gate without this quirk, use `build`.
+`--file-path` accepts a path relative to the project directory (`--file-path "Main.xaml"`) or an absolute one, with either separator style; forward-slash, backslash, and mixed forms all resolve. Prefer the relative form — it is shorter and keeps commands portable across machines.
 
 ---
 
 ## build
 
-`uip rpa build` compiles the project — catching runtime-compile failures `validate` misses (including attribute-form expression failures like `JIT compilation is disabled for non-Legacy projects` in C#-expression XAML projects). Required before returning a project to the user (see [§ Project Build Verification](#project-build-verification-required-before-returning-a-project)). Takes the project directory as a **positional** argument and runs independently of Studio IPC. Discover flags (log level, skip-analyze, governance, NuGet sources) via `uip rpa build --help`.
+`uip rpa build` compiles the whole project — every workflow, not only the files a per-file `validate` was pointed at (§ What each phase covers). Required before returning a project to the user (see [§ Project Build Verification](#project-build-verification-required-before-returning-a-project)). Takes the project directory as a **positional** argument and runs independently of Studio IPC. Discover flags (log level, skip-analyze, governance, NuGet sources) via `uip rpa build --help`.
 
 `run` and `debug start` compile internally, so a successful smoke test implies `build` would pass. When no smoke test runs (side effects, interactive workflow, no test input), `build` is the required compilability check.
 
@@ -168,13 +183,17 @@ Rules with scope `Coded Workflow` run as Roslyn analyzers over the project's `.c
 
 Read the project's UI **Object Repository** — the saved hierarchy of applications, screens, and elements (selectors/targets) that UI Automation activities bind to. Two read commands cover the project's own entries and those exposed by referenced libraries; both require an open project.
 
-- **Project Object Repository** — `uip rpa object-repository get` returns the project's *own* Object Repository as a JSON tree of applications → screens → elements. Entries inherited from referenced libraries are **excluded** (use the library command below for those). Takes no arguments beyond the standard `--project-dir`.
+> **Both verbs are top-level and hyphenated.** There is no `uip rpa object-repository` group — it returns `Unknown command: object-repository`, Studio running or not. Distinct from the UIA OR CLI, which writes entries and has no `get`.
+
+- **Project Object Repository** — `uip rpa get-object-repository` returns the project's *own* Object Repository as a JSON tree of applications → screens → elements, each entry carrying `name`, `description`, `type`, and `reference`. Entries inherited from referenced libraries are **excluded** (use the library command below for those). Takes no arguments beyond the standard `--project-dir`.
 
   ```bash
-  uip rpa object-repository get --project-dir "<PROJECT_DIR>" --output json
+  uip rpa get-object-repository --project-dir "<PROJECT_DIR>" --output json
   ```
 
-- **Library Object Repository** — `uip rpa object-repository get-library` reads the Object Repository out of one or more library `.nupkg` files and returns the applications, screens, and elements grouped by library. Pass the absolute path(s) to the library packages; packages without an Object Repository are omitted from the result.
+  The `name` values are **Object Repository names, not C# members** — `Result Display` here is `Result_Display` in `Descriptors.*`. Convert per the coded authoring guide's § Descriptor Naming, routed from `ui-automation-guide.md` § Documentation.
+
+- **Library Object Repository** — `uip rpa get-library-object-repository` reads the Object Repository out of one or more library `.nupkg` files and returns the applications, screens, and elements grouped by library. Pass the absolute path(s) to the library packages; packages without an Object Repository are omitted from the result.
 
   | Parameter | Required | Description |
   |-----------|----------|-------------|
@@ -182,13 +201,13 @@ Read the project's UI **Object Repository** — the saved hierarchy of applicati
 
   ```bash
   # multiple libraries: one --library-paths flag, comma-separated
-  uip rpa object-repository get-library \
+  uip rpa get-library-object-repository \
     --project-dir "<PROJECT_DIR>" \
     --library-paths "C:\libs\Acme.UiLib.1.2.0.nupkg,C:\libs\Other.UiLib.2.0.0.nupkg" \
     --output json
   ```
 
-Read the project repository before authoring UI Automation activities to discover existing screens/elements to reuse instead of re-indicating them; read the library repository to discover targets a referenced UI library already exposes. Confirm the live verb names and flags with `uip rpa object-repository --help`.
+Read the project repository before authoring UI Automation activities to discover existing screens/elements to reuse instead of re-indicating them; read the library repository to discover targets a referenced UI library already exposes. Confirm the live flags with `uip rpa get-object-repository --help` / `uip rpa get-library-object-repository --help`.
 
 ---
 
@@ -274,7 +293,7 @@ PHASE 2 — build-clean (per-project, once per edit session):
     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.
+**Why both phases.** Per-file `validate` covers one file deeply — structural XAML, missing references, analyzer rules, schema violations, unknown members, invalid enums, and expression compilation. `build` covers the project broadly — every workflow including untouched ones, project-scope analyzer rules, and packaging. Validating each edited file does not establish that the project compiles, and building does not tell you which file to fix without re-running `validate` on the offender. Neither replaces the other, and neither detects an attribute-form expression that silently resolves to a literal (§ What each phase covers).
 
 **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.
 
@@ -299,22 +318,37 @@ Every project returned to the user must compile. Phase 2 of the iteration loop a
 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-activity-binding-guide.md § C# Expression Pitfalls](xaml/csharp-activity-binding-guide.md#c-expression-pitfalls). 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).
+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.
+
+### What each phase covers
+
+Per-file `validate` loads the target file through the workflow designer **and** compiles its expressions, so it reports these on the file it was pointed at:
+
+| Error class | Example | Reported as |
+|-------------|---------|-------------|
+| Unknown member name | `<uix:NGetText Value="[x]" />` (correct: `TextString`) | `Could not load <file>: 'Cannot set unknown member '<Class>.<Prop>''` |
+| Invalid enum value | `ClickType="BogusValue"` | `Could not load <file>: 'Failed to create a '<Prop>' from the text '<value>''` |
+| Broken expression | `undefinedSymbol + 1` inside a `CSharpValue` | `CS0103: The name '<symbol>' does not exist in the current context` |
 
-### Errors `build` catches that `validate` misses
+**`build` is still required, because its scope is the whole project, not the file you validated.** It compiles every workflow — including ones you never touched or never validated — and applies project-scope analyzer rules and packaging. A project whose every edited file validates clean still fails `build` when an unrelated file is broken, which is exactly the state a partial edit session leaves behind.
 
-| 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-activity-binding-guide.md § C# Expression Pitfalls](xaml/csharp-activity-binding-guide.md#c-expression-pitfalls) |
+**Neither phase catches an attribute-form expression on an `InArgument<Object>`.** `Message="calcResult"` deserializes as a literal string, so `validate` reports no diagnostics, `build` succeeds, the run succeeds — and the activity logs the text `calcResult` instead of the variable's value. There is no error anywhere; the only signal is wrong output. This is why the gate ends with a smoke test whose **output is inspected**, not merely a run that exits clean — see [§ Smoke Test](#smoke-test) and [xaml/csharp-activity-binding-guide.md § C# Expression Pitfalls](xaml/csharp-activity-binding-guide.md#c-expression-pitfalls).
+
+### Expected non-defect warnings
+
+`build` prints `[WARN]` lines for enabled analyzer rules. These are **not** build failures and do not gate delivery (§ Validation Iteration Loop, Rule 6). Recurring ones that are correct-by-design and must not be "fixed":
+
+| Warning | Rule | Why it is expected |
+|---|---|---|
+| `<activity> does not have the verification feature enabled` | — (matches no rule in the enabled `analyzer-rules list` output) | `VerifyOptions` is deliberately off by default; add only when the user asks. Observed once per `NClick` on a clean UIA build. Policy: the UIA package guide's § Execution Verification Policy. |
+| `Your organization requires your project to have an Automation Hub URL defined` | `ST-USG-034` | Org governance setting, not a workflow property. Resolved in Project Settings by the project owner. |
+| `<name> display name is defined many times. Current allowed threshold is 1` | `ST-NMG-004` | Real but cosmetic. Fix only while authoring the activity — repeated identical steps (two clicks on the same button) need disambiguating names anyway. |
 
-When you see "no diagnostics found" from `validate`, you have not validated the file. Run `build` next.
+Warnings naming a rule ID you do not recognize: look it up with `analyzer-rules list --scope <scope>` (§ analyzer-rules list) rather than guessing, and only when a warning actually blocks an acceptance criterion.
 
 ## 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.
+A clean `validate` + `build` gate is not runtime proof. Some defects produce no diagnostic in either phase — an attribute-form expression that silently became a literal (§ What each phase covers), activity CacheMetadata failures that surface only when the runtime instantiates the activity, and plain logic bugs. Always treat the smoke test as a critical validation step whose output is inspected, 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:
 
@@ -327,7 +361,7 @@ uip rpa run --file-path "<FILE>" --skip-build --input-arguments key=value --outp
 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.
+`--skip-build` executes the existing compiled artifact — any edit since the last successful `build` is silently ignored. Use bare `run` after edits.
 
 **When to run:**
 1. Workflow has no compilation errors but you want to verify runtime behavior
@@ -490,7 +524,7 @@ Diagnose by error category, apply the recovery, retry **once** — do not loop t
 |--------|-----|
 | **Explore project files** | `Glob` `**/*.xaml` |
 | **Search XAML content** | `Grep` regex across `.xaml` |
-| **Explore Object Repository** | `uip rpa object-repository get` for the project's apps/screens/elements as JSON, `uip rpa object-repository get-library` for a referenced library's (see [object-repository](#object-repository)); or `Glob` `**/*` under `{PROJECT_DIR}/.objects/` + `Read` metadata for raw files |
+| **Explore Object Repository** | `uip rpa get-object-repository` for the project's apps/screens/elements as JSON, `uip rpa get-library-object-repository` for a referenced library's (see [object-repository](#object-repository)); or `Glob` `**/*` under `{PROJECT_DIR}/.objects/` + `Read` metadata for raw files |
 | **Get JIT type definitions** | `Read` `{PROJECT_DIR}/.project/JitCustomTypesSchema.json` |
 | **Activity docs** | See [Installed package activity documentation](#installed-package-activity-documentation) above |
 | **Inspect a NuGet package's API** | `uip rpa packages inspect` — see [coded/codedworkflow-reference.md § Inspect NuGet Package Tool](coded/codedworkflow-reference.md) |

package/skills/uipath-rpa/references/coded/codedworkflow-reference.md

@@ -2,6 +2,64 @@
 
 All workflow and test case files inherit from `CodedWorkflow`, which provides built-in methods and service access. The `CodedWorkflow` class is a **partial class** — you can extend it in a Coded Source File (see "Extending CodedWorkflow with Before/After Hooks" below).
 
+## Critical Rules — Coded (Rules 13–19)
+
+Mandatory for every coded workflow, test case, and source file. Cited as "Rule N" across this skill; Common Rules 1–12 are in SKILL.md.
+
+13. **[Coded] ALWAYS inherit from `CodedWorkflow`** base class for workflow and test case classes (NOT for Coded Source Files).
+14. **[Coded] ALWAYS use `[Workflow]` or `[TestCase]` attribute** on the `Execute` method.
+15. **[Coded] Update `project.json` → `entryPoints`** when adding/removing workflow files in **Process** projects. **Tests and Library projects do NOT use `entryPoints`** — skip this step for those project types. For `fileInfoCollection` (required for every test case in every project type — XAML and coded alike), see Common Rule 10 (SKILL.md).
+16. **[Coded] One workflow/test case class per file**, class name must match file name.
+17. **[Coded] Namespace = sanitized project name** from `project.json` → `name`, **not the folder name**. Sanitize: remove spaces (`find all tabs` → `findalltabs`), replace hyphens with `_`, ensure valid C# identifier. **A `.` survives as a namespace separator, and the digit-leading segment it creates takes an `_` prefix** — `TokenOptim_Calc_V3.4_Coded` → `TokenOptim_Calc_V3._4_Coded`, *not* `TokenOptim_Calc_V3_4_Coded`. Dotted or digit-adjacent names: **confirm, don't derive** — read the `namespace` line of the generated `.local/.codedworkflows/ObjectRepository.cs`. A wrong namespace makes the file's own `Descriptors.*` references unresolvable.
+18. **[Coded] Entry method is always named `Execute`**.
+19. **[Coded] Use Coded Source Files** for reusable code — plain `.cs` files without `CodedWorkflow` inheritance, no entry point.
+
+## Coded Quick Reference
+
+Coded workflows use standard C# development: create file → write code → validate → run. Activity discovery (`activities find`, `activities get-default-xaml`) is XAML-specific — for coded mode, check `{projectRoot}/.local/docs/packages/{PackageId}/coded/coded-api.md` first for service API docs, then fall back to `packages inspect`, then to the bundled per-package coded docs at `../activity-docs/<PackageId>/<closest-version>/coded/`. See [§ Inspect NuGet Package Tool](#inspect-nuget-package-tool-on-demand-api-discovery).
+
+### Three Types of .cs Files
+
+| Type | Base Class | Attribute | Entry Point | Purpose |
+|------|-----------|-----------|-------------|---------|
+| **Coded Workflow** | `CodedWorkflow` | `[Workflow]` | Process only | Executable automation logic |
+| **Coded Test Case** | `CodedWorkflow` | `[TestCase]` | Process only | Automated test with assertions |
+| **Coded Source File** | None (plain C#) | None | No | Reusable models, helpers, utilities, hooks |
+
+### Service-to-Package Mapping
+
+Each service on `CodedWorkflow` requires its NuGet package in `project.json`. Without it: `CS0103`.
+
+| Service Property | Required Package |
+|-----------------|------------------|
+| `system` | `UiPath.System.Activities` |
+| `testing` | `UiPath.Testing.Activities` |
+| `uiAutomation` | `UiPath.UIAutomation.Activities` |
+| `excel` | `UiPath.Excel.Activities` |
+| `word` | `UiPath.Word.Activities` |
+| `powerpoint` | `UiPath.Presentations.Activities` |
+| `mail` | `UiPath.Mail.Activities` |
+| `office365` | `UiPath.MicrosoftOffice365.Activities` |
+| `google` | `UiPath.GSuite.Activities` |
+
+For infrastructure/cloud packages (azure, gcp, aws, azureAD, citrix, hyperv, etc.), see [§ Service Properties](#service-properties-injected-based-on-installed-packages) and the sections below. For IS connectors from coded workflows via `ConnectorConnection.ExecuteAsync`: `UiPath.IntegrationService.Activities` — see [integration-service-guide.md](integration-service-guide.md).
+
+### Templates
+
+- [codedworkflow-template.md](../../assets/codedworkflow-template.md) — Workflow, test case, helper-class, and Before/After-hooks boilerplate (all coded templates)
+- [json-template.md](../../assets/json-template.md) — `entryPoints` and `fileInfoCollection` snippets
+
+### Task Navigation — Coded
+
+| I need to... | Read |
+|-------------|------|
+| **Add/edit a coded workflow** | [operations-guide.md](operations-guide.md) — a per-operation catalog, do NOT read end-to-end: Grep `^## ` for its sections, Read the §§ for the operations in the plan; § Coding Guidelines ALWAYS |
+| **Add a coded test case** | [operations-guide.md](operations-guide.md) — same per-operation lookup; remember: register in `fileInfoCollection` (Common Rule 10) |
+| **Call an IS connector (coded)** | [integration-service-guide.md](integration-service-guide.md) |
+| **Add a NuGet package** | [operations-guide.md § Add Dependency](operations-guide.md) → [§ Third-Party NuGet Packages](#third-party-nuget-packages) |
+| **Discover activity APIs** | [§ Inspect NuGet Package Tool](#inspect-nuget-package-tool-on-demand-api-discovery) |
+| **Troubleshoot coded errors** | [operations-guide.md § Common Issues and Fixes](operations-guide.md#common-issues-and-fixes) |
+
 ## Built-in Methods (available in any workflow/test case via `this`)
 
 | Method | Description |
@@ -60,7 +118,7 @@ var result = RunWorkflow(workflowPath, new Dictionary<string, object>
 
 ## Service Properties (injected based on installed packages)
 
-Services are accessed as properties on `this`: `system.GetAsset(...)`, `excel.ReadRange(...)`, `testing.VerifyExpression(...)`, etc. See the Service-to-Package mapping in SKILL.md.
+Services are accessed as properties on `this`: `system.GetAsset(...)`, `excel.ReadRange(...)`, `testing.VerifyExpression(...)`, etc. See [§ Service-to-Package Mapping](#service-to-package-mapping) above.
 
 ## Integration Service Connections
 

package/skills/uipath-rpa/references/coded/operations-guide.md

@@ -552,7 +552,7 @@ Four built-in Workflow Analyzer rules with scope `Coded Workflow` run as Roslyn
 - **ALWAYS search for existing .cs files BEFORE generating new code** — Learn from existing patterns
 - Read at least 5 existing workflow files (or all if fewer) to understand project conventions
 - **When writing UI automation code** — the UIA package guide (`{PROJECT_DIR}/.local/docs/packages/UiPath.UIAutomation.Activities/ui-automation-guide.md`) MUST be read IN FULL first (SKILL.md Rule 7). Follow its **Finding Descriptors** hierarchy in strict order. Do NOT write any UI code until descriptors are resolved:
-  1. Read `ObjectRepository.cs` — use existing descriptors if present
+  1. Read `ObjectRepository.cs` — use existing descriptors if present. An empty `public static class Descriptors { }` does NOT mean "nothing registered"; it means Studio has not generated yet. Generation fires on an Object Repository write, and only when a Studio Desktop **window** is open on the project and a `[Workflow]`/`[TestCase]` `.cs` is already on disk; `validate`/`build` never trigger it. Write the coded stub before capture to avoid this; if already stuck, re-issue any write via the OR CLI. Member names are not the OR names verbatim, and the app segment is not always the app name — re-read the file before concluding a descriptor is missing or guessing its identifier. Preconditions, recovery, and naming transforms: the package guide's § Step 1 and § Descriptor Naming
   2. Inspect UILibrary/descriptor NuGet packages in `project.json` (e.g. `*.Descriptors`, `*.UILibrary`) using `uip rpa packages inspect`. The tool checks the local NuGet cache automatically. If the package is still not found, read `.metadata` files manually at `~/.nuget/packages/<package-name>/<version>/contentFiles/any/any/.objects/` to discover App/Screen/Element hierarchy
   3. If descriptors are still missing — use the `uia-configure-target` skill flow (found in the UIA activity-docs) to create targets. This handles capturing the application, discovering elements, generating selectors, improving them, and registering them in the OR. Do NOT manually call the internal `uip rpa uia` CLIs outside of the skill flow. Fallback: the indication commands (see UIA docs) when elements appear only after user interaction (e.g., a compose form that opens after clicking a button)
   4. UITask (ScreenPlay) is ONLY for when selectors are genuinely brittle/unreliable — NEVER as a first approach
@@ -684,4 +684,5 @@ C) <user-driven approach>
 | **`CS0103` on an Execute default parameter value** | Default values are copied verbatim into the generated `*+Activity.cs` wrapper, where class consts/fields are out of scope | Use self-contained compile-time literals as defaults (`"output"`, `2`, `null`) — never a reference to a const, static, or member |
 | **Argument default ignored — empty string arrives instead** | `--input-arguments key=` (empty value) passes `""`, which OVERRIDES the declared default | Omit the flag entirely to use the method's default value |
 | **Runs invoke stale code after a signature change** | Generated wrapper (`*+Activity.cs` / WorkflowRunnerService) not regenerated | Re-run `uip rpa build` after changing an Execute signature; never hand-patch generated files under `.local/` |
+| **First `validate` on a never-built project fails: `CodedWorkflow` / `WorkflowRunnerService` types missing** | The generated partials under `.local\.codedworkflows\` are created by `build`, not by `validate` — before the first build they do not exist | Benign cold-start order, not a project defect: run `uip rpa build` once, then re-run `validate` — both pass. Do NOT investigate the SDK or package layout, hunt the base class in NuGet caches, or compare against other projects. On a project that has never been built, run `build` before the first `validate`. |
 | **Nondeterministic errors confined to `.local/` generated files** (`WorkflowRunnerService.cs` missing/stale, CS errors in `.local/install/<Class>+<Method>Activity.cs`; project `validate` or `run` flips between clean and failing with unchanged sources) | CLI codegen destroys/regenerates the coded-workflow wrappers unreliably; a cached headless Studio instance holds stale state | Errors that live only under `.local/` are cache corruption, NOT source defects — judge project health by `build` + per-file `validate` on authored sources. Recover surgically, in order: (1) delete only the stale generated wrappers under `.local/install/` (and a corrupt `WorkflowRunnerService.cs` if present); (2) kill the headless Studio host process — it relaunches on the next command; (3) run `uip rpa build` ONCE to regenerate; (4) execute with `uip rpa run --skip-build` per workflow/test from then on. Do NOT `rm -rf .local/` wholesale — a full cold restore destabilizes codegen further and re-pays the 30–90 s NuGet restore per run. Do NOT add `[TestCase]` files to `entryPoints` while debugging this (Rule 15 forbids it regardless). Resilience option when tests keep tripping the flaky proxy: keep pure logic in a Coded Source File (Rule 19) and assert on the shared function directly — the trade-off is losing integration coverage of the workflow proxy itself. |

package/skills/uipath-rpa/references/debugging.md

@@ -178,19 +178,31 @@ For `debug test-activity` and `debug start-from-here`, both `--input-arguments`
 
 ## Output Format
 
-`run` and `debug start` return a JSON envelope with `Data.runResult` as a JSON-encoded string. Parse `runResult` separately:
+`run` and `debug start` both return `{Result, Code, Data}`. **`Data`'s inner shape varies by CLI build and run state — read it by key presence, never by assumed schema.**
+
+A completed run on the current CLI returns the fields flat, with the workflow's own log output included:
 
 ```json
 {
   "Result": "Success",
   "Code": "ToolResult",
   "Data": {
-    "runResult": "{\"output\":\"...\",\"hasErrors\":false,\"errorMessage\":null,\"debugState\":\"Completed\",\"debugDetails\":null}"
+    "output": "Session ended",
+    "errors": [],
+    "logEntries": [ { "source": "Debug", "level": "Information", "message": "5 + 5 = 10" } ]
   }
 }
 ```
 
-Inside `runResult`:
+| Field | Type | Meaning |
+|-------|------|---------|
+| `output` | `string` or `array` | Terminal status when the run ended: `"Session ended"` on clean completion, `"Execution aborted. See attached errors for more information"` on failure, `"Failed to open the file <path>"` when the entry point does not exist. A JSON array of `{category, type, name, value}` locals when a debug session is suspended on an exception. **Never the workflow's output arguments.** |
+| `errors` | `array` | `{errorName, errorMessage, lineNumber}` per entry. Populated for an unhandled exception (`errorName` is the exception type) and for a compile failure (`errorName: "ERROR"`). **Empty does not mean success** — a missing entry point and a suspended session both report `[]`. |
+| `logEntries` | `array` | `{source, level, message}` per entry, `source` one of `Compile` / `Debug`. **The workflow's `Log Message` output lands here** — this is where a logged value is read back to confirm runtime behavior. Compile failures also land here at `Error` level with the root cause (e.g. `Cannot set unknown member ...`), which `errors` reports only as `This activity is missing or could not be loaded.` |
+
+**Output arguments are not in the envelope.** A workflow that assigns its `out_*` arguments still returns `output: "Session ended"`; the values appear nowhere in `Data`. Read them from the workflow's own `Log Message` output in `logEntries`, or from artifacts the workflow wrote.
+
+Older builds nest the same information as a JSON-encoded string on `Data.runResult`. When that key is present, parse it and read these fields instead:
 
 | Field | Type | Meaning |
 |-------|------|---------|
@@ -201,9 +213,13 @@ Inside `runResult`:
 | `DebugDetails` | `string?` | Debug sessions only: JSON snapshot for the state — current activity + locals when `Paused`; exception type/message/activity + locals when `Suspended`; `null` otherwise. |
 | `Profiling` | `object?` | Present only when `--profiling` was passed on a start command and collection succeeded. Single field `OutputDirectory` — absolute path to the run's `*.uistat` and screenshot folder (verifies UI automation correctness and workflow performance). `null` / omitted otherwise. See [Profiling Workflow Performance](#profiling-workflow-performance). |
 
-Workflow log output (`Log Message` activity, system traces) is **streamed in real time** during execution on a separate channel. It is NOT embedded in `runResult`.
+Workflow log output (`Log Message` activity, system traces) arrives on `Data.logEntries` when that key is present; when the response nests `runResult` instead, the logs are streamed live on a separate channel and are not embedded in `runResult`. Either way the logs are diagnostic data, never the verdict.
 
-> **For completed runs, `Result` (outer) — equivalently `HasErrors` (inner) — is the only success/failure signal.** `Result: "Success"` already accounts for compile failures, validation failures, and unhandled runtime exceptions. **Do NOT use streamed log entries' `Level` as a failure signal** — workflow `Log Message` activities emit at any level, and successful runs commonly include `Error` / `Warning` entries from the workflow's own logging. Treating log levels as a verdict flips green runs to "failed". In an active debug session, check `DebugState` first: `Suspended` means an exception is waiting for your decision even though `HasErrors` is still `false`.
+> **The outer `Result` reports the CLI invocation, NOT the workflow.** It is `ValidationError` for an unknown flag and `Failure` for an unopenable project directory, but `Success` as soon as the runtime was invoked — including when the workflow threw an unhandled exception, failed to compile, or the entry point did not exist. **Never treat `Result: "Success"` as a passing run.**
+>
+> **A completed run passed only when `Data.errors` is empty AND `Data.output` is `"Session ended"`.** Both conditions are required: `errors` is populated for exceptions and compile failures, while a missing entry point and a suspended debug session leave it empty and report the failure in `output` instead.
+>
+> **Do NOT use log entries' `level` as a failure signal** — workflow `Log Message` activities emit at any level, and a clean run that logs at `Error` still returns `errors: []` with `output: "Session ended"`. Treating log levels as a verdict flips green runs to "failed". Conversely, when a run has failed, `logEntries` at `Error` level carry the most specific diagnosis — read them for the root cause after the verdict is already established.
 
 Examples:
 
@@ -361,7 +377,8 @@ uip rpa debug start --file-path "MyWorkflow.xaml" --output json
 uip rpa debug continue --output json
 
 # 4. Check the response for:
-#    - Outer Result is "Success" (HasErrors: false) — the canonical pass/fail signal
+#    - Data.errors empty AND Data.output == "Session ended" (nested shape: HasErrors false) —
+#      the pass/fail signal; the outer Result stays "Success" even through failures
 #    - Output (workflow's serialized output args) carries the expected values
 #    - Streamed log entries during the run are diagnostic context, NOT a failure signal —
 #      Error/Warning levels there are workflow-emitted observability, not CLI failures
@@ -388,7 +405,7 @@ uip rpa debug start --file-path "ProcessOrder.xaml" \
 
 ## Profiling Workflow Performance
 
-Use `--profiling` on a start verb to collect per-activity timings **and runtime screenshots** — the same data Studio's **Profile Execution** tool surfaces. Profiling serves two purposes that can be addressed in a single run: **verifying UI automation correctness** (via the captured screenshots — confirm clicks landed on the right element, forms filled as expected, screens transitioned correctly) **and verifying workflow performance** (via the per-activity timings). The executor writes `*.uistat` files plus screenshots into `%LOCALAPPDATA%\UiPath\ProfiledRuns\HHmmss_yyyy-MM-dd_<entryPoint>_<projectName>\` and the response carries the absolute path on `runResult.Profiling.OutputDirectory`.
+Use `--profiling` on a start verb to collect per-activity timings **and runtime screenshots** — the same data Studio's **Profile Execution** tool surfaces. Profiling serves two purposes that can be addressed in a single run: **verifying UI automation correctness** (via the captured screenshots — confirm clicks landed on the right element, forms filled as expected, screens transitioned correctly) **and verifying workflow performance** (via the per-activity timings). The executor writes `*.uistat` files plus screenshots into `%LOCALAPPDATA%\UiPath\ProfiledRuns\HHmmss_yyyy-MM-dd_<entryPoint>_<projectName>\` and the response carries the absolute path on `Profiling.OutputDirectory` — flat on `Data`, or inside the parsed string when the response nests `runResult` (§ Output Format).
 
 ### When to enable profiling
 
@@ -421,7 +438,7 @@ Only start verbs collect profiling — `--profiling` is silently ignored on step
 uip rpa run --file-path "ProcessOrders.xaml" --profiling --output json
 ```
 
-Parse `Data.runResult` then inspect:
+Read `Data.Profiling.OutputDirectory` — flat on `Data` when the response is flat, inside the parsed string when the response nests `runResult` (§ Output Format):
 
 ```jsonc
 {
@@ -455,12 +472,12 @@ The directory contains `*.uistat` files — one per workflow file executed in th
 
 ## Reading Debug Output Effectively
 
-Read `runResult` fields in this order. **Verdict comes from the outer `Result` envelope (equivalently inner `HasErrors`) — never from log-entry levels.**
+Read the response in this order, resolving each field by key presence per § Output Format. **Verdict comes from `Data.errors` and `Data.output` together (nested shape: `HasErrors`) — never from the outer `Result`, and never from log-entry levels.**
 
-1. **Outer `Result` / inner `HasErrors`** — the only success/failure signal. Compile failures, validation failures, and unhandled runtime exceptions all flip these. If `Result: "Success"` (`HasErrors: false`), the run succeeded — even if log entries streamed during the run contain `Error` / `Warning` levels.
+1. **`Data.errors` and `Data.output` together** — the success/failure signal. Passed only when `errors` is empty AND `output` is `"Session ended"`. The outer `Result` qualifies the CLI call, not the run, and stays `Success` through exceptions, compile failures, and a missing entry point.
 2. **`ErrorMessage` (when `HasErrors: true`)** — formatted chain with the source activity, exception type, message, and stack trace. This is the canonical failure diagnostic.
-3. **`Output` (when `HasErrors: false`)** — workflow's serialized output arguments JSON for `run` / `debug start` completions. Empty string `""` for debug-command responses (step / continue / cancel) and on failure.
-4. **Streamed log entries** — diagnostic context emitted live during execution on a separate channel. Use them to read variable values logged by the workflow, trace ordering, or correlate context with an `ErrorMessage` that already failed the run. **Do NOT use log-entry `Level` as a failure signal.**
+3. **`Output` (when `HasErrors: false`)** — workflow's serialized output arguments JSON for `run` / `debug start` completions. Empty string `""` for debug-command responses (step / continue / cancel) and on failure. The flat shape's `output` is a status string instead, so read output arguments from the workflow's own logging or its written artifacts when `runResult` is absent.
+4. **Log entries** — diagnostic context, on `Data.logEntries` when present, otherwise streamed live on a separate channel. Use them to read variable values the workflow logged, trace ordering, or correlate context with an `ErrorMessage` that already failed the run. **Do NOT use log-entry `Level` as a failure signal.**
 
 ### Identifying the Root Cause from Debug Output
 

package/skills/uipath-rpa/references/environment-setup.md

@@ -378,7 +378,7 @@ Compose via `Invoke Workflow File` (coded: `workflows.StepName()`). Process work
 
 #### Layout and scale-out
 
-- Sequence vs Flowchart vs State Machine per workflow: Workflow Types table in SKILL.md § XAML Workflows Quick Reference
+- Sequence vs Flowchart vs State Machine per workflow: [xaml/xaml-basics-and-rules.md § Workflow Types](xaml/xaml-basics-and-rules.md)
 - High-volume transactional work: dispatcher/performer split via queues — [reframework-guide.md § Execution Mode: Queue-Driven](reframework-guide.md)
 
 #### Promotion ladder
@@ -500,3 +500,56 @@ OrderProcessing/
 
 **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)
+
+## Project Conversion (expressionLanguage / targetFramework)
+
+Rule 23 (SKILL.md) forbids changing either field on an existing project — both are fixed at creation and apply to every XAML file: flipping `expressionLanguage` (VisualBasic ↔ CSharp) invalidates every expression; flipping `targetFramework` (Windows ↔ Portable, or Legacy) invalidates package references and activity compatibility.
+
+**Do not attempt in-place conversion.** When the user wants to convert an existing project:
+
+1. Confirm the conversion with the user.
+2. Copy the project to a temporary folder.
+3. Create a new project via `uip rpa init --expression-language <VisualBasic|CSharp> --target-framework <Windows|Portable>`. For a target of Windows - Legacy, create it in Legacy mode instead — modern `init` is not the legacy creation path.
+4. Recreate every workflow defined in the old project as an equivalent in the new project.
+5. Delete the temporary copy only after the new project is generated successfully and the user agrees with the changes.
+
+## Project Context Discovery
+
+Before doing any work in a project, check if `.claude/rules/project-context.md` exists in the project directory.
+
+**If the file exists** → check for staleness:
+
+1. Read the first line to extract the metadata comment: `<!-- discovery-metadata: cs=N xaml=N deps=N -->`
+2. Count current files: Glob `**/*.cs` (excluding `.local/` and `.codedworkflows/`) and `**/*.xaml` in the project directory
+3. Count current dependencies: read `project.json` and count keys in the `.dependencies` object
+4. For each count (cs, xaml, deps), compute the percentage difference: `abs(current - stored) / max(stored, 1) * 100`
+5. If **any individual count differs by 60–70% or more** → run the discovery flow below
+6. If all counts are within the threshold → context is fresh, proceed with the skill workflow
+
+**If the file does NOT exist** → run the skip gate below; if it does not trip, run the discovery flow.
+
+### Skip gate: nothing to discover yet
+
+Discovery on a project with no authored content returns empty tables and costs a subagent round-trip. **Do NOT spawn the discovery agent** when any row matches:
+
+| Condition | How to check |
+|-----------|--------------|
+| Greenfield — no `project.json` (you are about to create the project) | SKILL.md Step 0 found no `project.json` |
+| Empty project — 0 authored workflow files | Glob `**/*.xaml` + `**/*.cs`, excluding dot-directories and `obj/`, `bin/` → count 0 |
+| Freshly scaffolded — only the untouched entry point | Count 1; file is a scaffold entry point (`Main.xaml` process/template, `NewActivity*.xaml` library, `TestCase.xaml` test, `Main.cs` coded); no authored logic — root `Sequence` empty or only `Comment` activities (XAML) / empty `Execute` body (coded) |
+
+Gate tripped: write no context files now, proceed with the skill workflow. **After the build**, write both context files yourself from what you just created — same paths and `AGENTS.md` marker logic as discovery-flow step 3.
+
+### Discovery flow
+
+Used for both missing and stale context:
+
+1. Spawn the project discovery agent and wait for it to complete. Its definition lives inside this skill at [`../agents/uipath-project-discovery-agent.md`](../agents/uipath-project-discovery-agent.md). Use whichever spawn mechanism your host supports:
+   - **Host registers plugin agents by name** (e.g., Claude Code) → trigger the registered `uipath-project-discovery-agent` agent.
+   - **Host only spawns its own predefined subagents** (e.g., UiPath Autopilot) → spawn a subagent and pass it that file (relative to this skill) as its instructions / custom skill. Grant it write access so it can produce the context files itself; a read-only subagent still works via step 3.
+2. The agent writes the context files itself and returns a `context-files:` status line followed by the context document. Use the returned document as this session's project context — do NOT re-read the files it just wrote, and do NOT rewrite them.
+3. **Only when the agent reports `context-files: not-written`** (read-only subagent host, or a write error) → write the returned content to **both**:
+   - `.claude/rules/project-context.md` (create `.claude/rules/` directory if needed) — auto-loaded by Claude Code in future sessions
+   - `AGENTS.md` at project root — the shared cross-agent context convention (read by UiPath Autopilot in Studio Desktop and other AGENTS.md-aware hosts). If `AGENTS.md` already exists, look for `<!-- PROJECT-CONTEXT:START -->` / `<!-- PROJECT-CONTEXT:END -->` markers and replace only between them; if no markers exist, append the fenced block at the end
+4. If the agent returns `SKIP: <reason>` instead of a document, treat it as a gate trip: no context files now, write them yourself after the build.
+5. Then proceed with the skill workflow

package/skills/uipath-rpa/references/execution-maps-guide.md

@@ -14,7 +14,7 @@ One dense file, read once per build. Fixes which tool calls go in which assistan
 
 ## Gate ≠ runtime proof
 
-A clean `validate` + `build` does NOT prove runtime behavior. Known silent failures pass BOTH: `InvokeCode` `Code` in child/CDATA form no-ops, `WriteTextFile` with explicit `Encoding` emits a BOM, a stripped UIA `N*` `Version` fails only at runtime ([xaml/common-pitfalls.md](xaml/common-pitfalls.md)). When the deliverable has observable outputs (files written, entry-point out-arguments) and runs without external systems or UI, the gate turn ends with ONE `uip rpa run` and the report turn checks the actual outputs — see the T3/T4 rows below.
+A clean `validate` + `build` does NOT prove runtime behavior. Known silent failures pass BOTH: `InvokeCode` `Code` in child/CDATA form no-ops, `WriteTextFile` with explicit `Encoding` emits a BOM, a stripped UIA `N*` `Version` fails only at runtime ([xaml/common-pitfalls.md](xaml/common-pitfalls.md)). When the deliverable has observable outputs (files written, entry-point out-arguments) and runs without external systems or UI, the gate turn ends with ONE `uip rpa run --skip-build` and the report turn checks the actual outputs — see the T3/T4 rows below.
 
 ## Sequential gates — never batch across these
 
@@ -25,15 +25,16 @@ A clean `validate` + `build` does NOT prove runtime behavior. Known silent failu
 
 ## Journey: Greenfield XAML (no UIA)
 
-Skip the project-discovery subagent — nothing to discover yet (SKILL.md § Skip gate: no `project.json` before T1, only the untouched scaffold after it). Write `project-context.md` + `AGENTS.md` yourself at T4.
+Skip the project-discovery subagent — nothing to discover yet ([environment-setup.md § Skip gate](environment-setup.md): no `project.json` before T1, only the untouched scaffold after it). Write `project-context.md` + `AGENTS.md` yourself at T4.
 
 | Turn | Emit in ONE assistant message |
 |---|---|
 | **T1 — Scaffold + context** | ONE `Bash` chain: `uip rpa init --name "<NAME>" --location "<PARENT_DIR>" --template-id BlankTemplate --expression-language <VisualBasic\|CSharp> --target-framework <Windows\|Portable> --output json` (Rule 2a — both flags explicit) `&&` `uip rpa analyzer-rules list --project-dir "<PROJECT_DIR>" --output json` `&&` one `uip rpa packages versions --package-id <PackageId> --include-prerelease --project-dir "<PROJECT_DIR>" --output json` per request-known package ∥ parallel `Read` — ALL THREE, never a subset (skipping the pattern card re-opens per-activity discovery): [common-activity-card.md](common-activity-card.md), [common-pattern-card.md](common-pattern-card.md), [xaml/xaml-basics-and-rules.md](xaml/xaml-basics-and-rules.md) (Rule 22) ∥ memory recall (harness has memory) ∥ Rule 21 `activities find` fan-out for off-card activities |
 | **T2 — Author + install** | Design fork FIRST for row-processing tasks: complex bulk row processing (per-row parse + validate + branch + accumulate) escalates to code per [data-manipulation-guide.md § Code vs activity chains](data-manipulation-guide.md) — the pattern card's `ForEach` shapes cover only the simple one-`If`/`Switch` case. Then: one `Write` per workflow file — complete, all activities (Rule 18) ∥ `Read` `project.json` (anchors for the T2/T3 edits; skip re-reading scaffolded `Main.xaml` — the `Write` replaces it) ∥ `Edit` `project.json` (`fileInfoCollection` for test cases, Rule 10; `dependencies` stays CLI-owned via `packages install`) ∥ ONE `Bash`: `uip rpa packages install` for all needed packages at the T1-chosen versions — flag shape per [cli-reference.md § packages install](cli-reference.md#packages-install); it drifts across CLI builds, so on `Invalid packages input` re-check `uip rpa packages install --help` ∥ Rule 21 doc `Read`s + `get-default-xaml` for off-card activities |
-| **T3 — Gate** | ONE `Bash`: `uip rpa validate --file-path "<RELATIVE_FILE>" --project-dir "<PROJECT_DIR>" --output json` per file `&&` `uip rpa build "<PROJECT_DIR>" --output json` `&&` — when outputs are observable and no external system/UI is needed — `uip rpa run` on the entry point (§ Gate ≠ runtime proof). `--file-path` RELATIVE to project dir — absolute paths falsely fail (separator bug, [cli-reference.md § validate](cli-reference.md#validate)) |
+| **T3 — Gate** | ONE `Bash`: `uip rpa validate --file-path "<RELATIVE_FILE>" --project-dir "<PROJECT_DIR>" --output json` per file `&&` `uip rpa build "<PROJECT_DIR>" --output json` `&&` — when outputs are observable and no external system/UI is needed — `uip rpa run --skip-build` on the entry point (§ Gate ≠ runtime proof). `--file-path` RELATIVE to project dir — absolute paths falsely fail (separator bug, [cli-reference.md § validate](cli-reference.md#validate)) |
 | **T4 — Report** | Check the T3 run's actual outputs against the request (files, out-arguments) BEFORE reporting — wrong/empty output with a clean gate is a silent-failure signature (§ Failure exits) + § Completion Output + write `project-context.md`/`AGENTS.md` + memory save ([§ Cross-session memory](#cross-session-memory)) |
 
+- **T1 is ONE message — `init` plus every read.** Both cards, [xaml/xaml-basics-and-rules.md](xaml/xaml-basics-and-rules.md) (Rule 22 two-step) and the matching [xaml/common-pitfalls.md](xaml/common-pitfalls.md) sections are all T1 reads: batch their `Grep`s in this turn and their `Read`s in the next. `init` reads none of them, so it never waits on a read, and common-pitfalls is a T1 read — not a post-authoring one. Open no other reference before T2, `environment-setup.md` included.
 - First chain call pays the cold Helm restore (30–90 s) — the chain hides it behind one turn; do not split to "check progress".
 - `init` can return `success: false` yet create files (partial success) — before retrying, check `project.json` exists ([environment-setup.md](environment-setup.md)).
 - Dependencies land via `packages install` only — never hand-edit `project.json` `dependencies`.
@@ -44,9 +45,9 @@ Skip the project-discovery subagent — nothing to discover yet (SKILL.md § Ski
 
 | Turn | Emit in ONE assistant message |
 |---|---|
-| **T1 — Context** | § Precondition context check — § Skip gate first, then the discovery subagent, which writes `project-context.md` + `AGENTS.md` itself ∥ `Read` `project.json` + target `.xaml` + cards ∥ ONE `Bash`: `analyzer-rules list --project-dir "<PROJECT_DIR>" --output json` ∥ memory recall ∥ off-card `activities find` fan-out |
+| **T1 — Context** | SKILL.md § Precondition context check — the skip gate first, then the discovery subagent, which writes `project-context.md` + `AGENTS.md` itself ([environment-setup.md § Project Context Discovery](environment-setup.md)) ∥ `Read` `project.json` + target `.xaml` + cards ∥ ONE `Bash`: `analyzer-rules list --project-dir "<PROJECT_DIR>" --output json` ∥ memory recall ∥ off-card `activities find` fan-out |
 | **T2 — Edit** | Batched `Edit`s (anchor each on its own target block — same-file Edits serialize; overlapping anchors fail) ∥ `packages install` `Bash` if new dependencies |
-| **T3 — Gate** | ONE `Bash`: per-file `validate` (relative `--file-path`) `&&` `build` `&&` optional `run` per § Gate ≠ runtime proof |
+| **T3 — Gate** | ONE `Bash`: per-file `validate` (relative `--file-path`) `&&` `build` `&&` optional `run --skip-build` per § Gate ≠ runtime proof |
 | **T4 — Report** | Output check (if T3 ran) + § Completion Output + memory save |
 
 ## Journey: Greenfield coded
@@ -57,7 +58,7 @@ Skip the project-discovery subagent — nothing to discover yet (SKILL.md § Ski
 |---|---|
 | **T1 — Scaffold + context** | ONE `Bash` chain: `init` (flags as XAML journey) `&&` `analyzer-rules list` `&&` `packages versions` per known package ∥ `Read` [assets/codedworkflow-template.md](../assets/codedworkflow-template.md) + [coded/operations-guide.md § Coding Guidelines](coded/operations-guide.md#coding-guidelines) ∥ memory recall |
 | **T2 — Author + install** | `Write` each `.cs` (Rules 13–19) ∥ `Read` `project.json` ∥ `Edit` `project.json` (`entryPoints` Rule 15, `fileInfoCollection` Rule 10) ∥ `packages install` `Bash` ∥ `Read` `.local/docs/packages/<PackageId>/coded/coded-api.md` for installed services |
-| **T3 — Gate** | ONE `Bash`: per-file `validate` (relative `--file-path`) `&&` `build` `&&` optional `run` per § Gate ≠ runtime proof |
+| **T3 — Gate** | ONE `Bash`: per-file `validate` (relative `--file-path`) `&&` `build` `&&` optional `run --skip-build` per § Gate ≠ runtime proof |
 | **T4 — Report** | Output check (if T3 ran) + § Completion Output + memory save |
 
 ## Journey: Brownfield coded edit
@@ -70,7 +71,7 @@ Budget shape: **~3 fixed turns + ~3 turns per capture-screen + 2-turn debug cycl
 
 | Turn | Emit in ONE assistant message |
 |---|---|
-| **T0 — Reads + pre-flight** | Parallel `Read`: [uia-starter-guide.md](uia-starter-guide.md) + the UIA package guide (Rule 7, both in full) + the target-capture orchestration reference it mandates ∥ prerequisites check (SKILL.md § UIA Prerequisites, Rule 7a) ∥ ONE `Bash`: window baseline via the UIA snapshot CLI ∥ build the element inventory/checklist from the user's manual steps |
+| **T0 — Reads + pre-flight** | Parallel `Read`: [uia-starter-guide.md](uia-starter-guide.md) + the UIA package's core guide (Rule 7, both in full) + the target-capture orchestration reference it mandates ∥ prerequisites check ([uia-starter-guide.md § UIA Prerequisites](uia-starter-guide.md), Rule 7a) ∥ ONE `Bash`: window baseline via the UIA snapshot CLI ∥ build the element inventory/checklist from the user's manual steps |
 | **Per capture-screen** | (a) capture bundle — run the `uia-configure-target` flow for ALL of this screen's checklist elements in one pass, through OR registration; (b) ONE state advance via the interact CLI — only to reach the next screen, never to test behavior |
 | **T-author — after ALL screens captured** | Scaffold/authoring prerequisites (Capture-First Fast Path order) ∥ batch-author every screen's activities in one pass (Rule 18), embed path for OR target attachment |
 | **T-gate** | ONE `Bash`: per-file `validate` (relative `--file-path`) `&&` `build` |
@@ -79,7 +80,7 @@ Budget shape: **~3 fixed turns + ~3 turns per capture-screen + 2-turn debug cycl
 - Default is author-once-after-capture — all OR refs are already in conversation. Fall back to per-screen authoring interleave only on long captures (5+ screens) where context pressure is real; the `validate`/`build` gate still runs ONCE at the end either way.
 - Screens after the first (same window): carry the OR screen reference from the previous capture into the next `uia-configure-target` invocation — it skips the OR screen lookup. Invocation shape and argument: the package's `uia-configure-target` invocation guide (routed from the package guide § Documentation).
 - Indication fallback (user physically clicks) and every interact advance are sequential gates — never batched, never parallel.
-- Selector failures at debug time → the `uia-improve-selector` flow (never hand-edit selectors).
+- Selector failures at debug time → the recover selector flow (never hand-edit selectors).
 
 ## Failure exits
 
@@ -91,7 +92,7 @@ Budget shape: **~3 fixed turns + ~3 turns per capture-screen + 2-turn debug cycl
 | Coded `CS*` errors | [coded/operations-guide.md § Common Issues and Fixes](coded/operations-guide.md#common-issues-and-fixes) |
 | CLI error (`timeout`, `EPIPE`, `401`, `not in the project folder`) | [cli-reference.md § CLI Error Recovery](cli-reference.md#cli-error-recovery) |
 | Card snippet rejected by validate/build | Fall back to Rule 21 triple for that activity; report stale entry via `/uipath-feedback` |
-| UIA selector fails at debug time | `uia-improve-selector` flow per [uia-starter-guide.md § Runtime Selector Failure Recovery](uia-starter-guide.md#runtime-selector-failure-recovery) — never hand-edit |
+| UIA selector fails at debug time | Recover selector flow per [uia-starter-guide.md § Runtime Selector Failure Recovery](uia-starter-guide.md#runtime-selector-failure-recovery) — never hand-edit |
 
 ## Cross-session memory
 

package/skills/uipath-rpa/references/legacy/activity-docs/_INVOKE-CODE.md

@@ -298,7 +298,7 @@ for (int i = 0; i < keys.Length; i++) {
 14. **Avoid modifying code dynamically** in loops — each unique code string triggers new compilation
 
 ### Namespace Conflicts
-15. **C# `System` namespace conflict** — using `HttpClient` may fail because `System` is both a namespace and a member. Use `global::System.Net.Http.HttpClient` instead. (Bug fix: STUD-77435)
+15. **C# `System` namespace conflict** — using `HttpClient` may fail because `System` is both a namespace and a member. Use `global::System.Net.Http.HttpClient` instead.
 16. **Workflow imports filter** — only namespaces that exist in loaded assemblies are passed to compiler. If you need `System.Net.Http`, ensure the assembly is loaded.
 
 ### Assemblies