diff --git a/skills/uipath-rpa/SKILL.md b/skills/uipath-rpa/SKILL.md index f6255e1f09..bb5312d287 100644 --- a/skills/uipath-rpa/SKILL.md +++ b/skills/uipath-rpa/SKILL.md @@ -193,7 +193,7 @@ On Windows PowerShell, `&` doesn't background — use `Start-Process powershell. ### Execution Maps (Both Modes) -**Follow the journey map in [execution-maps-guide.md](references/execution-maps-guide.md) for every build or edit** — it fixes which tool calls batch into which assistant turn (greenfield ≤5 turns, brownfield ≤4). Within a turn: chain dependent `uip` calls with `&&` in one `Bash`; emit independent `Bash`/`Read`/`Edit` calls as parallel tool uses. Split turns only where a call needs an earlier call's stdout or a file mutation. Rule 21 discovery for off-card activities fans out inside T1/T2 — all K `find`s parallel, then all K doc `Read`s, then all K `get-default-xaml`s — never one activity at a time. +**Follow the journey map in [execution-maps-guide.md](references/execution-maps-guide.md) for every build or edit** — it fixes which tool calls batch into which assistant turn (greenfield ≤5 turns, brownfield ≤5 — the pitfalls vet turn is inside both). Within a turn: chain dependent `uip` calls with `&&` in one `Bash`; emit independent `Bash`/`Read`/`Edit` calls as parallel tool uses. Split turns only where a call needs an earlier call's stdout or a file mutation. Rule 21 discovery for off-card activities fans out inside T1/T2 — all K `find`s parallel, then all K doc `Read`s, then all K `get-default-xaml`s — never one activity at a time. **Sequential by design — never batch across:** `templates search` → `init` (Rule 2 decision gate); any `AskUserQuestion` or consent gate; UIA state advances and indication (the UIA journey in the guide encodes its per-screen gating). @@ -204,7 +204,7 @@ On Windows PowerShell, `&` doesn't background — use `Start-Process powershell. ### XAML-Specific Rules 16–21a, 24. **[XAML] The XAML critical rules live in [xaml/xaml-basics-and-rules.md § Critical Rules — XAML](references/xaml/xaml-basics-and-rules.md)** — Rule 22's read-in-full mandate below covers them; they arrive with the file you must already read before any XAML work. The same file carries the XAML task navigation and quick reference. -22. **[XAML] MUST read [references/xaml/xaml-basics-and-rules.md](references/xaml/xaml-basics-and-rules.md) before generating or editing any XAML — via this two-step read, never a plain full Read:** (1) Grep `^## Catalogs` on the file with line numbers, (2) Read the file with `limit` set to that line. Everything above the marker (including § Critical Rules — XAML) is the mandatory read; the catalog sections below it (editing operations, reference examples) load per-entry only — Grep `^###`, Read the entries matching the operation/activity at hand, unsure → read it. **Then vet the plan against [references/xaml/common-pitfalls.md](references/xaml/common-pitfalls.md).** common-pitfalls.md is a catalog of independent gotcha sections — do NOT read it end-to-end: list its headings (Grep `^##` on the file), then Read every section whose heading matches an activity, property, or feature in the workflow you are about to author. Unsure whether a section applies → read it. This is an authoring-time gate, not only a troubleshooting resource — consulting it first is cheaper than debugging a gotcha `validate` cannot see. +22. **[XAML] MUST read [references/xaml/xaml-basics-and-rules.md](references/xaml/xaml-basics-and-rules.md) in full before generating or editing any XAML — a plain full Read, emitted in the journey's first turn alongside the card reads (no lookup precedes it; the file holds only the mandatory content).** The per-operation / per-activity catalogs (editing operations, reference examples) live in [references/xaml/xaml-editing-catalog.md](references/xaml/xaml-editing-catalog.md) and load per entry only — Grep `^###`, Read the entries matching the operation/activity at hand, unsure → read it. **Then vet the plan against [references/xaml/common-pitfalls.md](references/xaml/common-pitfalls.md) before the first `Write`/`Edit`.** common-pitfalls.md is a catalog of independent gotcha sections — do NOT read it end-to-end: list its headings (Grep `^##` on the file — emit this in the first turn too, it needs no prior output), then in the next turn Read every section whose heading matches an activity, property, or feature in the workflow you are about to author. Unsure whether a section applies → read it. This is an authoring-time gate, not only a troubleshooting resource — consulting it first is cheaper than debugging a gotcha `validate` cannot see. The turn placement is fixed by [execution-maps-guide.md](references/execution-maps-guide.md): the heading list rides in T1, the section Reads are T2, so the gate costs one turn, never a grep→Read pair per file. 23. **[XAML] NEVER change `expressionLanguage` or `targetFramework` on an existing project.** Decide both proactively at init time (Common Rule 2a); this rule covers the immutability afterward. Both fields are fixed at creation and apply to every XAML file — flipping either invalidates expressions or package references project-wide. **Do not attempt in-place conversion.** If the user wants to convert an existing project, confirm with them and follow [environment-setup.md § Project Conversion](references/environment-setup.md) — copy aside, `init` fresh with the target settings, recreate every workflow, delete the copy only after the user agrees. ## Task Navigation @@ -241,7 +241,7 @@ On Windows PowerShell, `&` doesn't background — use `Start-Process powershell. Each authoring mode's critical rules, quick reference, and task navigation live with the mode's primary reference — read per the gates above (Rule 22 for XAML; Coded Rules 13–19 gate for coded): -- **XAML:** [xaml/xaml-basics-and-rules.md](references/xaml/xaml-basics-and-rules.md) — § Critical Rules — XAML, § XAML Task Navigation & Quick Reference, authoring workflow, anatomy, editing operations +- **XAML:** [xaml/xaml-basics-and-rules.md](references/xaml/xaml-basics-and-rules.md) — § Critical Rules — XAML, § XAML Task Navigation & Quick Reference, authoring workflow, anatomy; editing operations and reference examples are the per-entry [xaml/xaml-editing-catalog.md](references/xaml/xaml-editing-catalog.md) - **Coded:** [coded/codedworkflow-reference.md](references/coded/codedworkflow-reference.md) — § Critical Rules — Coded, § Coded Quick Reference (file types, service-to-package mapping, templates), § Task Navigation — Coded, base-class reference ## Resolving Packages & Activity Docs diff --git a/skills/uipath-rpa/references/execution-maps-guide.md b/skills/uipath-rpa/references/execution-maps-guide.md index 8ea80ec8e6..aaa00425a4 100644 --- a/skills/uipath-rpa/references/execution-maps-guide.md +++ b/skills/uipath-rpa/references/execution-maps-guide.md @@ -1,6 +1,6 @@ # Execution Maps — Turn-Budgeted Build Journeys -One dense file, read once per build. Fixes which tool calls go in which assistant turn. Budgets (happy path, incl. final report): **greenfield ≤5 turns, brownfield ≤4**. One repair cycle adds ≤2. Each T-row = ONE assistant message: N tool calls in one message cost 1 turn, one call per message costs N. +One dense file, read once per build. Fixes which tool calls go in which assistant turn. Budgets (happy path, incl. final report): **greenfield ≤5 turns, brownfield ≤5**. One repair cycle adds ≤2. Each T-row = ONE assistant message: N tool calls in one message cost 1 turn, one call per message costs N. > **Tool vocabulary.** Tool names use Claude Code conventions: `Edit` = in-place string replacement, `Write` = full-file write, `Read`/`Glob`/`Grep` = file read/search, `Bash` = shell. On another harness, map each to its equivalent. Harness cannot emit parallel tool calls → keep the same per-turn grouping as consecutive calls; the CLI chains still collapse round-trips. @@ -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 --skip-build` 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 T4/T5 rows below. ## Sequential gates — never batch across these @@ -25,30 +25,32 @@ 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 ([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. +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). The emptiness check itself (`ls` of the parent dir) is the first link of the T1 `Bash` chain, not its own turn. Write `project-context.md` + `AGENTS.md` yourself at T5. | Turn | Emit in ONE assistant message | |---|---| -| **T1 — Scaffold + context** | ONE `Bash` chain: `uip rpa init --name "" --location "" --template-id BlankTemplate --expression-language --target-framework --output json` (Rule 2a — both flags explicit) `&&` `uip rpa analyzer-rules list --project-dir "" --output json` `&&` one `uip rpa packages versions --package-id --include-prerelease --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 "" --project-dir "" --output json` per file `&&` `uip rpa build "" --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 — Scaffold + context** | ONE `Bash` chain: `uip rpa init --name "" --location "" --template-id BlankTemplate --expression-language --target-framework --output json` (Rule 2a — both flags explicit) `&&` `uip rpa analyzer-rules list --project-dir "" --output json` `&&` one `uip rpa packages versions --package-id --include-prerelease --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 — plain full Read, nothing to look up first) ∥ `Grep` `^## ` on [xaml/common-pitfalls.md](xaml/common-pitfalls.md) for its heading list (Rule 22 gate, step 1 — needs no prior output, so it rides here) ∥ memory recall (harness has memory) ∥ Rule 21 `activities find` fan-out for off-card activities | +| **T2 — Vet** | `Read` every [xaml/common-pitfalls.md](xaml/common-pitfalls.md) section whose T1 heading matches an activity, property, or feature of the planned workflow — all in parallel; unsure → read it (Rule 22 gate, step 2) ∥ `Read` `project.json` (anchors for the T3/T4 edits; skip re-reading scaffolded `Main.xaml` — the `Write` replaces it) ∥ per-entry `Read`s from [xaml/xaml-editing-catalog.md](xaml/xaml-editing-catalog.md) when the workflow needs an editing operation beyond the cards (arguments, imports, resource types) ∥ Rule 21 doc `Read`s + `get-default-xaml` for off-card activities. This is the only turn the pitfalls gate costs: the heading list already arrived in T1, so no grep→Read pair is paid per file. | +| **T3 — 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) ∥ `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` | +| **T4 — Gate** | ONE `Bash`: `uip rpa validate --file-path "" --project-dir "" --output json` per file `&&` `uip rpa build "" --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)) | +| **T5 — Report** | Check the T4 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. +- **T1 is ONE message — `init` plus every read.** Both cards and [xaml/xaml-basics-and-rules.md](xaml/xaml-basics-and-rules.md) are plain full `Read`s with nothing to look up first, so they all ride in T1 alongside the [xaml/common-pitfalls.md](xaml/common-pitfalls.md) heading `Grep`; only that `Grep`'s section `Read`s wait for T2. `init` reads none of them, so it never waits on a read, and the pitfalls gate is paid before authoring — never after it. Open no other reference before T3, `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`. -**Repair cycle (validate/build failure):** one turn — `Edit` fixes by error category (Rule 19 — Package first: a skipped `packages install` fails the gate before any activity issue); a gate failure on a card-covered activity does NOT reopen discovery (`activities find`/`get-default-xaml`) — recheck the card entry; next turn — re-run the T3 chain. >2 errors with ambiguous origin → bisect: stub out half the new activities, re-validate. Caps: 5 attempts per loop (Rule 3). +**Repair cycle (validate/build failure):** one turn — `Edit` fixes by error category (Rule 19 — Package first: a skipped `packages install` fails the gate before any activity issue); a gate failure on a card-covered activity does NOT reopen discovery (`activities find`/`get-default-xaml`) — recheck the card entry; next turn — re-run the T4 chain. >2 errors with ambiguous origin → bisect: stub out half the new activities, re-validate. Caps: 5 attempts per loop (Rule 3). ## Journey: Brownfield XAML edit | Turn | Emit in ONE assistant message | |---|---| -| **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 "" --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 --skip-build` per § Gate ≠ runtime proof | -| **T4 — Report** | Output check (if T3 ran) + § Completion Output + memory save | +| **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 + [xaml/xaml-basics-and-rules.md](xaml/xaml-basics-and-rules.md) (Rule 22, plain full Read) ∥ `Grep` `^## ` on [xaml/common-pitfalls.md](xaml/common-pitfalls.md) for its heading list ∥ ONE `Bash`: `analyzer-rules list --project-dir "" --output json` ∥ memory recall ∥ off-card `activities find` fan-out | +| **T2 — Vet** | `Read` the [xaml/common-pitfalls.md](xaml/common-pitfalls.md) sections matching the planned edit (Rule 22 gate) ∥ per-entry [xaml/xaml-editing-catalog.md](xaml/xaml-editing-catalog.md) `Read`s for the editing operations involved ∥ off-card Rule 21 doc `Read`s | +| **T3 — Edit** | Batched `Edit`s (anchor each on its own target block — same-file Edits serialize; overlapping anchors fail) ∥ `packages install` `Bash` if new dependencies | +| **T4 — Gate** | ONE `Bash`: per-file `validate` (relative `--file-path`) `&&` `build` `&&` optional `run --skip-build` per § Gate ≠ runtime proof | +| **T5 — Report** | Output check (if T4 ran) + § Completion Output + memory save | ## Journey: Greenfield coded @@ -63,7 +65,7 @@ Skip the project-discovery subagent — nothing to discover yet ([environment-se ## Journey: Brownfield coded edit -Brownfield XAML journey with coded reads: T1 `Read` target `.cs` + `.local/docs/.../coded/coded-api.md` for touched services; T2 `Edit`s ∥ install; T3 gate; T4 report. +Brownfield XAML journey with coded reads and no pitfalls vet turn: T1 `Read` target `.cs` + `.local/docs/.../coded/coded-api.md` for touched services; T2 `Edit`s ∥ install; T3 gate; T4 report. ## Journey: UIA capture + build (XAML) @@ -100,7 +102,7 @@ Harness-conditional: engage only when the harness provides persistent memory; ot **Recall — T1 of every journey.** Match saved entries by activity class + package `major.minor`. Hit ⇒ that activity skips the Rule 21 triple. `validate`/`build` still gate. -**Save — after project `build` is clean (T4).** Save only: +**Save — after project `build` is clean (the report turn).** Save only: 1. Validated XAML snippet per off-card activity — key: activity class + package `major.minor` + date. 2. Error→root-cause→fix triples that cost >1 validate attempt. diff --git a/skills/uipath-rpa/references/testing-guide.md b/skills/uipath-rpa/references/testing-guide.md index 6b3789aac0..2609aa459d 100644 --- a/skills/uipath-rpa/references/testing-guide.md +++ b/skills/uipath-rpa/references/testing-guide.md @@ -63,7 +63,7 @@ xmlns:ui="http://schemas.uipath.com/workflow/activities" ### Default Values for Test-Case Arguments -A test case authored with an `` argument should generally bake in a default so `uip rpa run --file-path .xaml` is runnable without `--input-arguments`. Use the canonical root-attribute syntax — see [xaml/xaml-basics-and-rules.md § Setting Default Values for Arguments](xaml/xaml-basics-and-rules.md#setting-default-values-for-arguments). The wrong forms (bare attribute, ``, `` child of ``) all produce confusing `member not supported` errors — the doc explicitly lists them so you don't waste time trying. +A test case authored with an `` argument should generally bake in a default so `uip rpa run --file-path .xaml` is runnable without `--input-arguments`. Use the canonical root-attribute syntax — see [xaml/xaml-editing-catalog.md § Setting Default Values for Arguments](xaml/xaml-editing-catalog.md#setting-default-values-for-arguments). The wrong forms (bare attribute, ``, `` child of ``) all produce confusing `member not supported` errors — the doc explicitly lists them so you don't waste time trying. ### XAML Structure — Standalone Test Case (with Placeholder) diff --git a/skills/uipath-rpa/references/xaml/xaml-basics-and-rules.md b/skills/uipath-rpa/references/xaml/xaml-basics-and-rules.md index 6e3e7f2f33..f0ddaab667 100644 --- a/skills/uipath-rpa/references/xaml/xaml-basics-and-rules.md +++ b/skills/uipath-rpa/references/xaml/xaml-basics-and-rules.md @@ -2,7 +2,7 @@ Core concepts for UiPath workflow XAML files, the authoring workflow (Discovery → Generate/Edit → Validate & Fix → Response), and rules for generating and/or editing XAML content. -**Read contract (Rule 22) — mechanical:** Grep `^## Catalogs` on this file for its line number, then Read this file with `limit` set to that line — everything ABOVE the marker is the mandatory full read. The two catalog sections below the marker (§ Common Editing Operations, § XAML Reference Examples) load per-entry only: Grep `^###`, Read the entries matching the operation or activity at hand; unsure → read it. A full-file Read that includes the catalogs means this contract was skipped. +**Read contract (Rule 22) — plain full Read, no prior lookup:** this file is the mandatory read in its entirety and holds nothing else — emit the Read in the same assistant turn as the other T1 reads (cards, pitfalls heading list). The per-operation and per-activity catalogs (§ Common Editing Operations, § XAML Reference Examples) live in [xaml-editing-catalog.md](xaml-editing-catalog.md) and load per entry only: Grep `^###` on that file, Read the entries matching the operation or activity at hand; unsure → read it. ## Critical Rules — XAML (Rules 16–21a, 24) @@ -75,6 +75,7 @@ Check `expressionLanguage` in `project.json`. VB.NET uses `[brackets]` for expre ### Related XAML References +- [xaml-editing-catalog.md](xaml-editing-catalog.md) — Per-entry catalog: adding arguments/variables/imports/assembly references, C#/VB expressions, resource types, complete reference workflows (Rule 22 lookup procedure — Grep `^###`, Read matching entries) - [common-pitfalls.md](common-pitfalls.md) — Activity gotchas, scope requirements, property conflicts (Rule 22 lookup procedure) - [csharp-activity-binding-guide.md](csharp-activity-binding-guide.md) — Canonical C# binding forms per common activity property + § C# Expression Pitfalls - [canvas-layout-guide.md](canvas-layout-guide.md) — Flowchart node vocabulary, structure & wiring, forbidden nested-chain pattern + Flowchart/State Machine/LRW canvas layout with ViewState @@ -223,7 +224,7 @@ For end-to-end authoring of `ConnectorActivity` XAML (connection + type ID + Con **UI Automation — Target Configuration Gate (MANDATORY).** Before writing any XAML with UI activities: 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). Every UI element target MUST be configured through the `uia-configure-target` skill flow — the guide mandates the target-capture orchestration reference to read IN FULL first. **NEVER** manually call low-level `uip rpa uia` CLI commands outside of the skill flow. -**For CREATE requests:** author the workflow complete in one `Write` (SKILL.md Rule 18 — every activity sourced card → memory → discovery triple), then gate in Phase 3. Use the `Write` tool to create the `.xaml` file per [§ XAML File Anatomy](#xaml-file-anatomy). Infer the file path from folder conventions; use descriptive filenames. +**For CREATE requests:** do not `Read` the scaffolded `Main.xaml` first — the `Write` replaces it wholesale, and the data files the workflow needs (`mkdir` + sample inputs) go in the same assistant message as that `Write`. Author the workflow complete in one `Write` (SKILL.md Rule 18 — every activity sourced card → memory → discovery triple), then gate in Phase 3. Use the `Write` tool to create the `.xaml` file per [§ XAML File Anatomy](#xaml-file-anatomy). Infer the file path from folder conventions; use descriptive filenames. **For EDIT requests:** always `Read` current content before editing; use `Edit` with exact, unique `old_string` matches. @@ -231,12 +232,14 @@ For end-to-end authoring of `ConnectorActivity` XAML (connection + type ID + Con **MUST** repeat until 0-error state from **both** `validate` and `build`, or max 5 fix attempts per loop. After 5 attempts, stop and present remaining errors to the user. The canonical two-phase loop (per-file `validate` → project-level `build`), what each phase covers, and the smoke-test procedure: [../cli-reference.md § Validation Iteration Loop](../cli-reference.md#validation-iteration-loop) — read it before your first fix iteration. +One `Bash` call for the whole gate — chain the phases with `&&` so a `validate` failure stops before `build` and the pass path costs one turn, never one turn per command (the journey map's gate row in [execution-maps-guide.md](../execution-maps-guide.md)): + ```bash -uip rpa validate --file-path "Workflows/MyWorkflow.xaml" --output json -uip rpa build "" --log-level Warn --output json +uip rpa validate --file-path "Workflows/MyWorkflow.xaml" --project-dir "" --output json \ + && uip rpa build "" --log-level Warn --output json ``` -`--file-path` must be **relative to the project directory**. Treat `validate` clean as half-done — `build` clean is the signal to exit the loop. A clean gate is still not runtime proof: for observable-output workflows, end with one `uip rpa run` and check the outputs ([execution-maps-guide.md § Gate ≠ runtime proof](../execution-maps-guide.md#gate--runtime-proof)). +`--file-path` must be **relative to the project directory**. Treat `validate` clean as half-done — `build` clean is the signal to exit the loop. A clean gate is still not runtime proof: for observable-output workflows, end with one `uip rpa run --skip-build` and check the outputs ([execution-maps-guide.md § Gate ≠ runtime proof](../execution-maps-guide.md#gate--runtime-proof)). **Fix order:** Package → Structure → Type → Activity Properties → Logic. @@ -481,7 +484,7 @@ Container activities have body or branch slots typed `Activity` or `ActivityActi **Cheapest enforcement.** For card-listed containers (`If`, `Switch`, `TryCatch`, `While`, `DoWhile`, `ForEach`), copy the wrapped shape from the common-activity card. For off-card containers (`Pick`, `Parallel`, `ParallelForEach`, package-specific body activities), run `uip rpa activities get-default-xaml --activity-class-name ""` after the Rule 21 doc read and copy the wrapped shape from the starter. See SKILL.md Rules 21, 21a, 24. -**Worked example.** [§ Example 1: Basic Activities (LogMessage, If/Else, Assign)](#example-1-basic-activities-logmessage-ifelse-assign) below — `If.Then` and `If.Else` each carry a ``. +**Worked example.** [xaml-editing-catalog.md § Example 1: Basic Activities (LogMessage, If/Else, Assign)](xaml-editing-catalog.md#example-1-basic-activities-logmessage-ifelse-assign) — `If.Then` and `If.Else` each carry a ``. **Editing existing files.** When inserting an activity into an empty or bare `If.Then` / `Catch` / `Body` slot, add the `` wrapper in the same edit. @@ -532,340 +535,3 @@ Properties may exist in one package version but not another. If `validate` repor 2. The property may have been renamed between versions — check examples from the same package version 3. Use `uip rpa activities get-default-xaml` output as the authoritative set of properties for the installed version ---- - -## Catalogs — Grep-gated (Rule 22 read contract) - -**Do NOT read past this marker in the initial full read.** The two sections below are per-operation / per-activity catalogs. Lookup procedure: Grep `^###` on this file to list their entries with line numbers, then Read ONLY the entries matching the operation or activity at hand. Unsure whether an entry applies → read it. - -## Common Editing Operations - -Common operations for editing and managing workflow XAML files. - -### Adding Arguments (In/Out/InOut) - -Add `x:Property` elements inside the `` block: - -```xml - - - - - - - - -``` - -Argument naming convention: `in_`, `out_`, `io_` prefixes. - -#### Setting Default Values for Arguments - -Defaults go on the root `` element using the canonical .NET Workflow Foundation self-namespace syntax: - -```xml - - - - - -``` - -Two parts are mandatory: - -1. **`xmlns:this="clr-namespace:"`** — the empty `clr-namespace:` is what makes `this:` resolve to the class declared by `x:Class`. -2. **`this:.=""`** — the attribute name MUST be qualified with `this:` AND the class name; bare `=""` is rejected. - -The default is baked into the compiled assembly at build time as a `Literal` expression in the generated class's constructor. At runtime, when the workflow is invoked without that argument supplied (e.g. `uip rpa run` without `--input-arguments`), the literal is used. - -**Three default-value forms that DO NOT work** — every one of them is rejected by the XAML loader. Authoring agents have repeatedly tried these and lost time to confusing errors — don't: - -| Bad form | Error | -|---|---| -| `` (no `xmlns:this`, no class qualifier) | `member (in_FileName) is not supported by DynamicActivity` | -| `...` | `DynamicActivityProperty does not have a content property` | -| `...` | `x:Property member (Value) is not supported by DynamicActivityProperty` | - -If you must accept an empty string as a sentinel ("user didn't provide one") and substitute a literal anyway, use a ternary inside each `CSharpValue`/`VisualBasicValue` consumer of the argument: - -```xml -string.IsNullOrEmpty(in_FileName) ? "report.pdf" : in_FileName -``` - -But the root-attribute default above is the cleaner answer — use it first. - -### Adding Variables - -Add `Variable` elements inside the workflow container's `.Variables` block: - -```xml - - - - - -``` - -Variables are scoped to their containing activity (Sequence, Flowchart, etc.). - -**IMPORTANT — `x:` and `s:` are XML namespace aliases, not separate type systems.** -`x:String` and `s:String` both refer to `System.String`; the prefix only determines which namespace schema resolves the name. The `x:` XAML language schema registers a small fixed set of types (`x:String`, `x:Int32`, `x:Int64`, `x:Double`, `x:Boolean`, `x:Byte`, `x:Single`, `x:Decimal`, `x:Char`, `x:Object`, `x:TimeSpan`). Any other CLR type — including `DateTime`, `DateTimeOffset`, `Guid`, etc. — is not registered in that schema and must be reached through `s:` (`xmlns:s="clr-namespace:System;assembly=System.Private.CoreLib"`). -Using `x:DateTime` or `x:DateTimeOffset` produces `Cannot create unknown type` at load time. -See `common-pitfalls.md` → *"Invalid Use of `x:` Prefix for Non-Builtin CLR Types"* for the full list and examples. - -### Adding Namespace Imports - -Add `` entries: - -```xml -System.Data -System.IO -UiPath.Excel -``` - -### Adding Assembly References - -Add `` entries: - -```xml -System.Data -UiPath.Excel.Activities -``` - -### Expressions - -#### C# Expressions (`expressionLanguage: CSharp`) - -Applies to XAML workflow files in projects whose `project.json` has `expressionLanguage: CSharp`. These rules govern expressions inside XAML — they are unrelated to coded workflows (`.cs` files), which are plain C# and do not use `CSharpValue` / `CSharpReference` elements. - -Expressions use explicit `` (for read/evaluate) or `` (for write/lvalue) elements inside `` / ``: -```xml - - - - fullName - - - - - firstName + " " + lastName - - - -``` - -**Important**: Do NOT use `[bracket]` shorthand for expressions. Brackets create `VisualBasicValue` nodes at deserialization time, causing validation failures for C#-only syntax (`null`, `?.`, `??`, `typeof()`, etc.). - -**Expression-tree limits**: each C# expression compiles as a lambda expression tree — no statements, no `out var` (`TryParse`), no optional-argument overloads (`CS0854`), and no calls into the project's coded source file types ([common-pitfalls.md § C# XAML Expressions Compile as Expression Trees](common-pitfalls.md)). When a transform outgrows single expressions, escalate per [data-manipulation-guide.md § Exception](../data-manipulation-guide.md) — Invoke Code, or a coded workflow via Invoke Workflow File. - -**Stronger rule for attribute-form bindings on `InArgument` / `OutArgument`:** in XAML projects with `expressionLanguage: CSharp`, any **non-literal** attribute value (`Message="variableName"`, `Text=""Hello " + name"`) is not evaluated as an expression. Where the property type accepts a string the text survives as a literal and the workflow validates, builds, and runs with the wrong value and no error; where it does not, the file fails to deserialize. Use `` / `` child elements for anything that isn't a plain literal. See [csharp-activity-binding-guide.md](csharp-activity-binding-guide.md) (includes § C# Expression Pitfalls). - -**Safe attribute-form values** (no expression evaluator involved, type converter handles them directly): -- Literal strings on `InArgument`: `Text="Book trip"`, `DisplayName="Open file"` -- Enums: `Level="Info"`, `ClickType="Single"`, `MouseButton="Left"` -- Numbers, booleans, `{x:Null}` -- `TimeSpan` literals: `Duration="00:00:02"` - -**For activity-specific recipes** (`LogMessage.Message` as `InArgument`, `NGetText.TextString` as `OutArgument`, `StartProcess.FileName` with composed paths, `Assign`, `If.Condition`, etc.), see [csharp-activity-binding-guide.md](csharp-activity-binding-guide.md). That file is the canonical lookup for the binding form per common activity property. - -#### VB Expressions (`expressionLanguage: VisualBasic`) -Expressions use VB syntax with `[bracket]` shorthand (VB is the default deserialization target for brackets): -```xml -[firstName & " " & lastName] -``` - -**Check `project.json` `expressionLanguage` field to determine which syntax to use.** - -### Resource Types (IResource / ILocalResource) - -Some activity properties accept `IResource` or `ILocalResource` types instead of plain strings for file inputs. These are part of UiPath's resource abstraction model: - -| Type | Description | When Used | -|------|-------------|-----------| -| `IResource` | Generic resource (local file, remote file, cloud attachment) | Activities that accept any file source | -| `ILocalResource` | Local file on disk (has `LocalPath` property) | Activities that need a file on the local filesystem | -| `IRemoteResource` | Remote resource with a URI and a local copy | Cloud/API-sourced files | - -**In XAML**, resource-typed properties are set via expressions that create the resource — `LocalResource.FromPath(filePath)` or the Path Exists activity. Both approaches, the XAML forms, and the required `UiPath.Platform.ResourceHandling` namespace: [common-pitfalls.md § IResource / ILocalResource](common-pitfalls.md#iresource--ilocalresource--string-path-conversion). - -**Activity Storage**: Some activities use a bucket-based storage system (`.storage/` folder in the project). Resources stored at design-time in `.storage/.runtime//` are packed into the published NuPkg and available at runtime. This is managed automatically — you don't need to edit storage resources directly in XAML. - -## XAML Reference Examples - -Complete workflow examples demonstrating proper XAML structure and patterns. - -### Example 1: Basic Activities (LogMessage, If/Else, Assign) - -VB project with core workflow activities. Shows If/Then/Else branching and Assign pattern. - -```xml - - - - - - - - ActivityBuilder_1 - - - - System - System.Collections.Generic - System.Linq - UiPath.Core - UiPath.Core.Activities - - - - - - System - System.Activities - UiPath.System.Activities - - - - - - - - - - - - - - - - [isWeekend] - - - [True] - - - - - - - - - [isWeekend] - - - [False] - - - - - - - -``` - -**Key patterns:** -- `ui:LogMessage` uses `xmlns:ui="http://schemas.uipath.com/workflow/activities"` -- VB expressions: `OrElse` instead of `||`, no brackets on simple values -- `If.Then` and `If.Else` each wrap content in a `Sequence` — required, not optional. See [§ Container Activity Bodies — Wrap in Sequence](#container-activity-bodies--wrap-in-sequence) for the full slot list -- `Assign` uses `Assign.To` (OutArgument) and `Assign.Value` (InArgument) with explicit `x:TypeArguments` - -### Example 2: Package Connector Activity (Office 365 Get Newest Email) - -Shows a package-based activity with `ConnectionId` for Integration Service. - -```xml - - xmlns:umam="clr-namespace:UiPath.MicrosoftOffice365.Activities.Mail;assembly=UiPath.MicrosoftOffice365.Activities" - xmlns:umame="clr-namespace:UiPath.MicrosoftOffice365.Activities.Mail.Enums;assembly=UiPath.MicrosoftOffice365.Activities" - xmlns:umamm="clr-namespace:UiPath.MicrosoftOffice365.Activities.Mail.Models;assembly=UiPath.MicrosoftOffice365.Activities" - xmlns:usau="clr-namespace:UiPath.Shared.Activities.Utils;assembly=UiPath.MicrosoftOffice365.Activities" - xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"> - - - - - UiPath.MicrosoftOffice365.Activities.Mail.Enums - UiPath.MicrosoftOffice365.Models - UiPath.Shared.Services.Graph.Mail.Models - UiPath.MicrosoftOffice365.Activities.Mail.Filters - UiPath.MicrosoftOffice365.Activities.Mail.Models - UiPath.MicrosoftOffice365.Activities.Mail - UiPath.Shared.Activities - - - - - - - UiPath.MicrosoftOffice365.Activities - UiPath.MicrosoftOffice365 - - - - - - - - - - - - - - - - - - - - - - -``` - -**Key patterns:** -- `ConnectionId` attribute holds the Integration Service connection GUID -- Nullable properties use `{x:Null}` explicitly -- Complex sub-objects (MailFolderArgument, MailboxArgument) with `BackupSlot` pattern -- `x:Reference` / `x:Name` for cross-referencing objects within the XAML -- Multiple package-specific xmlns prefixes (`umam`, `umame`, `umamm`, `usau`) - -### Example 3: Integration Service `ConnectorActivity` - -The generic IS `ConnectorActivity` pattern — activity shape, worked example, editing rules, JIT-generated assemblies: [../is-connector-xaml-guide.md](../is-connector-xaml-guide.md). - diff --git a/skills/uipath-rpa/references/xaml/xaml-editing-catalog.md b/skills/uipath-rpa/references/xaml/xaml-editing-catalog.md new file mode 100644 index 0000000000..c1880cb8f9 --- /dev/null +++ b/skills/uipath-rpa/references/xaml/xaml-editing-catalog.md @@ -0,0 +1,337 @@ +# XAML Editing Catalog + +Per-operation and per-activity catalogs for XAML authoring: editing operations (arguments, variables, imports, assembly references, expressions, resource types) and complete reference workflows. Split out of [xaml-basics-and-rules.md](xaml-basics-and-rules.md) so that file is a plain full read (Rule 22) with no marker to locate first. + +**Read contract — per entry, never end-to-end:** Grep `^###` on this file to list the entries with line numbers, then Read ONLY the entries matching the operation or activity at hand. Unsure whether an entry applies → read it. Reading this file top to bottom is the mistake the split removed. + +## Common Editing Operations + +Common operations for editing and managing workflow XAML files. + +### Adding Arguments (In/Out/InOut) + +Add `x:Property` elements inside the `` block: + +```xml + + + + + + + + +``` + +Argument naming convention: `in_`, `out_`, `io_` prefixes. + +#### Setting Default Values for Arguments + +Defaults go on the root `` element using the canonical .NET Workflow Foundation self-namespace syntax: + +```xml + + + + + +``` + +Two parts are mandatory: + +1. **`xmlns:this="clr-namespace:"`** — the empty `clr-namespace:` is what makes `this:` resolve to the class declared by `x:Class`. +2. **`this:.=""`** — the attribute name MUST be qualified with `this:` AND the class name; bare `=""` is rejected. + +The default is baked into the compiled assembly at build time as a `Literal` expression in the generated class's constructor. At runtime, when the workflow is invoked without that argument supplied (e.g. `uip rpa run` without `--input-arguments`), the literal is used. + +**Three default-value forms that DO NOT work** — every one of them is rejected by the XAML loader. Authoring agents have repeatedly tried these and lost time to confusing errors — don't: + +| Bad form | Error | +|---|---| +| `` (no `xmlns:this`, no class qualifier) | `member (in_FileName) is not supported by DynamicActivity` | +| `...` | `DynamicActivityProperty does not have a content property` | +| `...` | `x:Property member (Value) is not supported by DynamicActivityProperty` | + +If you must accept an empty string as a sentinel ("user didn't provide one") and substitute a literal anyway, use a ternary inside each `CSharpValue`/`VisualBasicValue` consumer of the argument: + +```xml +string.IsNullOrEmpty(in_FileName) ? "report.pdf" : in_FileName +``` + +But the root-attribute default above is the cleaner answer — use it first. + +### Adding Variables + +Add `Variable` elements inside the workflow container's `.Variables` block: + +```xml + + + + + +``` + +Variables are scoped to their containing activity (Sequence, Flowchart, etc.). + +**IMPORTANT — `x:` and `s:` are XML namespace aliases, not separate type systems.** +`x:String` and `s:String` both refer to `System.String`; the prefix only determines which namespace schema resolves the name. The `x:` XAML language schema registers a small fixed set of types (`x:String`, `x:Int32`, `x:Int64`, `x:Double`, `x:Boolean`, `x:Byte`, `x:Single`, `x:Decimal`, `x:Char`, `x:Object`, `x:TimeSpan`). Any other CLR type — including `DateTime`, `DateTimeOffset`, `Guid`, etc. — is not registered in that schema and must be reached through `s:` (`xmlns:s="clr-namespace:System;assembly=System.Private.CoreLib"`). +Using `x:DateTime` or `x:DateTimeOffset` produces `Cannot create unknown type` at load time. +See `common-pitfalls.md` → *"Invalid Use of `x:` Prefix for Non-Builtin CLR Types"* for the full list and examples. + +### Adding Namespace Imports + +Add `` entries: + +```xml +System.Data +System.IO +UiPath.Excel +``` + +### Adding Assembly References + +Add `` entries: + +```xml +System.Data +UiPath.Excel.Activities +``` + +### Expressions + +#### C# Expressions (`expressionLanguage: CSharp`) + +Applies to XAML workflow files in projects whose `project.json` has `expressionLanguage: CSharp`. These rules govern expressions inside XAML — they are unrelated to coded workflows (`.cs` files), which are plain C# and do not use `CSharpValue` / `CSharpReference` elements. + +Expressions use explicit `` (for read/evaluate) or `` (for write/lvalue) elements inside `` / ``: +```xml + + + + fullName + + + + + firstName + " " + lastName + + + +``` + +**Important**: Do NOT use `[bracket]` shorthand for expressions. Brackets create `VisualBasicValue` nodes at deserialization time, causing validation failures for C#-only syntax (`null`, `?.`, `??`, `typeof()`, etc.). + +**Expression-tree limits**: each C# expression compiles as a lambda expression tree — no statements, no `out var` (`TryParse`), no optional-argument overloads (`CS0854`), and no calls into the project's coded source file types ([common-pitfalls.md § C# XAML Expressions Compile as Expression Trees](common-pitfalls.md)). When a transform outgrows single expressions, escalate per [data-manipulation-guide.md § Exception](../data-manipulation-guide.md) — Invoke Code, or a coded workflow via Invoke Workflow File. + +**Stronger rule for attribute-form bindings on `InArgument` / `OutArgument`:** in XAML projects with `expressionLanguage: CSharp`, any **non-literal** attribute value (`Message="variableName"`, `Text=""Hello " + name"`) is not evaluated as an expression. Where the property type accepts a string the text survives as a literal and the workflow validates, builds, and runs with the wrong value and no error; where it does not, the file fails to deserialize. Use `` / `` child elements for anything that isn't a plain literal. See [csharp-activity-binding-guide.md](csharp-activity-binding-guide.md) (includes § C# Expression Pitfalls). + +**Safe attribute-form values** (no expression evaluator involved, type converter handles them directly): +- Literal strings on `InArgument`: `Text="Book trip"`, `DisplayName="Open file"` +- Enums: `Level="Info"`, `ClickType="Single"`, `MouseButton="Left"` +- Numbers, booleans, `{x:Null}` +- `TimeSpan` literals: `Duration="00:00:02"` + +**For activity-specific recipes** (`LogMessage.Message` as `InArgument`, `NGetText.TextString` as `OutArgument`, `StartProcess.FileName` with composed paths, `Assign`, `If.Condition`, etc.), see [csharp-activity-binding-guide.md](csharp-activity-binding-guide.md). That file is the canonical lookup for the binding form per common activity property. + +#### VB Expressions (`expressionLanguage: VisualBasic`) +Expressions use VB syntax with `[bracket]` shorthand (VB is the default deserialization target for brackets): +```xml +[firstName & " " & lastName] +``` + +**Check `project.json` `expressionLanguage` field to determine which syntax to use.** + +### Resource Types (IResource / ILocalResource) + +Some activity properties accept `IResource` or `ILocalResource` types instead of plain strings for file inputs. These are part of UiPath's resource abstraction model: + +| Type | Description | When Used | +|------|-------------|-----------| +| `IResource` | Generic resource (local file, remote file, cloud attachment) | Activities that accept any file source | +| `ILocalResource` | Local file on disk (has `LocalPath` property) | Activities that need a file on the local filesystem | +| `IRemoteResource` | Remote resource with a URI and a local copy | Cloud/API-sourced files | + +**In XAML**, resource-typed properties are set via expressions that create the resource — `LocalResource.FromPath(filePath)` or the Path Exists activity. Both approaches, the XAML forms, and the required `UiPath.Platform.ResourceHandling` namespace: [common-pitfalls.md § IResource / ILocalResource](common-pitfalls.md#iresource--ilocalresource--string-path-conversion). + +**Activity Storage**: Some activities use a bucket-based storage system (`.storage/` folder in the project). Resources stored at design-time in `.storage/.runtime//` are packed into the published NuPkg and available at runtime. This is managed automatically — you don't need to edit storage resources directly in XAML. + +## XAML Reference Examples + +Complete workflow examples demonstrating proper XAML structure and patterns. + +### Example 1: Basic Activities (LogMessage, If/Else, Assign) + +VB project with core workflow activities. Shows If/Then/Else branching and Assign pattern. + +```xml + + + + + + + + ActivityBuilder_1 + + + + System + System.Collections.Generic + System.Linq + UiPath.Core + UiPath.Core.Activities + + + + + + System + System.Activities + UiPath.System.Activities + + + + + + + + + + + + + + + + [isWeekend] + + + [True] + + + + + + + + + [isWeekend] + + + [False] + + + + + + + +``` + +**Key patterns:** +- `ui:LogMessage` uses `xmlns:ui="http://schemas.uipath.com/workflow/activities"` +- VB expressions: `OrElse` instead of `||`, no brackets on simple values +- `If.Then` and `If.Else` each wrap content in a `Sequence` — required, not optional. See [xaml-basics-and-rules.md § Container Activity Bodies — Wrap in Sequence](xaml-basics-and-rules.md#container-activity-bodies--wrap-in-sequence) for the full slot list +- `Assign` uses `Assign.To` (OutArgument) and `Assign.Value` (InArgument) with explicit `x:TypeArguments` + +### Example 2: Package Connector Activity (Office 365 Get Newest Email) + +Shows a package-based activity with `ConnectionId` for Integration Service. + +```xml + + xmlns:umam="clr-namespace:UiPath.MicrosoftOffice365.Activities.Mail;assembly=UiPath.MicrosoftOffice365.Activities" + xmlns:umame="clr-namespace:UiPath.MicrosoftOffice365.Activities.Mail.Enums;assembly=UiPath.MicrosoftOffice365.Activities" + xmlns:umamm="clr-namespace:UiPath.MicrosoftOffice365.Activities.Mail.Models;assembly=UiPath.MicrosoftOffice365.Activities" + xmlns:usau="clr-namespace:UiPath.Shared.Activities.Utils;assembly=UiPath.MicrosoftOffice365.Activities" + xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"> + + + + + UiPath.MicrosoftOffice365.Activities.Mail.Enums + UiPath.MicrosoftOffice365.Models + UiPath.Shared.Services.Graph.Mail.Models + UiPath.MicrosoftOffice365.Activities.Mail.Filters + UiPath.MicrosoftOffice365.Activities.Mail.Models + UiPath.MicrosoftOffice365.Activities.Mail + UiPath.Shared.Activities + + + + + + + UiPath.MicrosoftOffice365.Activities + UiPath.MicrosoftOffice365 + + + + + + + + + + + + + + + + + + + + + + +``` + +**Key patterns:** +- `ConnectionId` attribute holds the Integration Service connection GUID +- Nullable properties use `{x:Null}` explicitly +- Complex sub-objects (MailFolderArgument, MailboxArgument) with `BackupSlot` pattern +- `x:Reference` / `x:Name` for cross-referencing objects within the XAML +- Multiple package-specific xmlns prefixes (`umam`, `umame`, `umamm`, `usau`) + +### Example 3: Integration Service `ConnectorActivity` + +The generic IS `ConnectorActivity` pattern — activity shape, worked example, editing rules, JIT-generated assemblies: [../is-connector-xaml-guide.md](../is-connector-xaml-guide.md). +