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

package/skills/uipath-maestro-flow/references/shared/ux-narration-and-todos.md

@@ -1,73 +1,57 @@
 # UX — Narration and Todos
 
-Two **opt-in** rules govern how this skill communicates with the user during work. They are **off by default** — the agent works quietly. Engage them only when the user requests narration / progress tracking or signals a preference for verbosity. When engaged, they apply across every capability (Author, Operate, Diagnose, Evaluate), every journey, and every action type (`uip` CLI, shell builtins, Read/Write/Edit, Glob/Grep).
+Two **opt-in** rules govern communication during work. They are **off by default**. Engage them when the user requests narration/progress tracking or signals a verbosity preference. Once engaged, they apply across every capability (Author, Operate, Diagnose, Evaluate), journey, and action type (`uip` CLI, shell builtins, Read/Write/Edit, Glob/Grep).
 
-> Inherits from [SKILL.md](../../SKILL.md). The rules below are the canonical source — capability indexes and journey docs reference this file.
+> Inherits from [SKILL.md](../../SKILL.md). These rules are canonical; capability indexes and journey docs reference this file.
 
 ## When to engage
 
-Engage narration + todos when **any** of these hold:
+Engage narration and todos if any condition holds:
 
-- User explicitly asks: "narrate", "walk me through it", "show your steps", "keep a todo list", "track progress", "tell me what you're doing", "verbose", "be detailed", "explain as you go".
-- User expresses a standing preference for verbosity (in-session, or via a recalled memory / preference).
-- User asks a question that only makes sense with running commentary ("what are you doing right now?", "where are we?").
+- The user explicitly asks to narrate, show steps, keep a todo list, track progress, explain as work proceeds, be verbose, or be detailed.
+- The user has a standing verbosity preference in-session or in recalled memory.
+- The user asks a question requiring running commentary, such as what is happening or where work stands.
 
-**Default — silent mode.** When none of the above hold, do the work quietly. Surface only: decisions (user questions), failures, consent gates (`flow debug`), and the final result. No per-step narration line; no user-facing todo list. The agent MAY still keep todos privately on large journeys for its own tracking, but it is not required and is not a user-facing contract.
+Otherwise use **silent mode**: work quietly and surface only decisions, failures, consent gates (`flow debug`), and the final result. Do not provide per-step narration or a user-facing todo list. Private todos remain optional for large journeys.
 
 ## The two rules
 
-These apply **only once engaged** (see When to engage):
+Once engaged:
 
-1. **Narrate every logical step in plain English** — one short line before each step explaining what the agent is doing and why, in terms of the user's request. The user should never need to know `bash`, `uip` flags, or `.flow` JSON internals to follow along.
-2. **Maintain a granular progress list** for any journey above the trivial threshold — one todo per logical step, kept current as work proceeds. Standard journeys typically land at 10+ items; complex flows go higher. The count emerges from the journey's actual logical steps — do not target a number.
+1. **Narrate every logical step in plain English.** Give one short line before each step explaining what is being done and why in user terms; do not require knowledge of `bash`, `uip` flags, or `.flow` JSON.
+2. **Maintain a granular progress list** for every journey above the trivial threshold: one todo per logical step, kept current. Standard journeys usually have 10+ items; complex flows have more. Do not target a count; derive it from the actual steps.
 
-## What is a "logical step"
+### Logical steps
 
-A logical step is the smallest user-meaningful **outcome** — usually 1–5 actions across any mix of tools grouped under one intent.
-
-| Step intent | Actions inside |
-| --- | --- |
-| Discover and add the Slack node | `registry search` + `registry get` + `flow node add` + Edit to wire outputs |
-| Confirm project layout | `ls` + `cat <project>.flow` + `Glob` for nested files |
-| Update a script body | `Read` of `.flow` + `Edit` on the script node's `inputs.code` |
-| Validate the flow | `flow validate` (one call, but still a step) |
-| Triage a fault | `instance asset` + `incident list` + `incident get` |
-
-Bash plumbing inside a step is invisible to the user — the step's narration line covers it.
+A logical step is the smallest user-meaningful outcome, usually 1–5 actions grouped by intent across tools. Examples include discovering and adding a node, confirming project layout, updating a script body, validating a flow, or triaging a fault. Bash plumbing inside a step is covered by its narration.
 
 ## Narration cadence
 
 | Situation | Rule |
-| --- | --- |
-| Start of a logical step | **Narrate.** One short line, plain English, user terms. |
-| Multiple actions within the same step | No additional narration — the step's opening line covers them |
-| Step transitions (one outcome done, next starting) | Narrate the next step |
-| Decision point | Brief one-liner before asking the user ("This decision affects which connection binding I generate — choose one:") |
-| Failure / retry | Always narrate — explain what failed and what's being tried next. Failures surface even in silent mode. |
-| Trivial probe (`uip --version`, repeated `login status` in same minute) | Skip |
-| Non-`uip` shell commands (`ls`, `cat`, `mkdir`, `cd`) used as plumbing inside a step | Skip — covered by the step's opening narration |
-| File reads/edits inside a step | Skip — covered by the step's opening narration |
-
-## Narration line format
-
-- **Length:** ≤ ~15 words. Single sentence or fragment.
-- **Voice:** system voice. Not first person ("I'm checking…" → "Checking…").
-- **Terms:** user terms. "looking up the Slack node schema" — not "running `registry get core.action.slack.send`".
-- **Carry information:** every line tells the user something they couldn't have inferred from the prior line. No ceremony, no recap of flags or JSON paths.
-- **Reference user intent when scope is non-obvious.** "Adding the Slack node" beats "Adding a node"; "Editing the flow JSON to wire the new variable" beats "Editing the file".
-
-## Phrasing register
-
-Reference table — adapt to context. Add subject (what's being acted on) when scope is ambiguous.
-
-| Logical step | Narration |
-| --- | --- |
+|---|---|
+| Start of logical step | Narrate one short line in plain English. |
+| Multiple actions within a step | Do not add narration. |
+| Step transition | Narrate the next step. |
+| Decision point | Give a brief line before asking the user; explain the decision's consequence. |
+| Failure/retry | Always narrate what failed and what will be tried next, even in silent mode. |
+| Trivial probe (`uip --version`, repeated `login status` in the same minute) | Skip. |
+| Non-`uip` shell plumbing (`ls`, `cat`, `mkdir`, `cd`) | Skip; the step line covers it. |
+| File reads/edits inside a step | Skip; the step line covers them. |
+
+## Narration lines
+
+Keep each line to approximately 15 words or fewer, as one sentence or fragment. Use system voice, not first person. Use user terms rather than commands, flags, or JSON internals. State the actual subject when scope is ambiguous, convey new information, and avoid ceremony, recaps, and repetition.
+
+Use or adapt these patterns:
+
+| Step | Narration |
+|---|---|
 | Login probe | "Checking whether you're logged in to the UiPath tenant…" |
 | Solution scaffold | "Scaffolding a new solution at `<path>` so the Flow project has a parent." |
 | Flow init | "Initializing the Flow project. This creates the `.flow` file you'll edit." |
 | Verify project layout | "Confirming the solution/project layout is correct before continuing." |
 | Registry discovery | "Looking up `<node-type>` in the registry so I can wire its inputs correctly…" |
-| Node add (multi-step) | "Adding the `<node-type>` node and copying its registry definition into the file…" |
+| Node add | "Adding the `<node-type>` node and copying its registry definition into the file…" |
 | Edit flow JSON | "Editing the flow JSON to add the `<thing>`." |
 | Edge wiring | "Wiring `<from>` → `<to>` so data flows in the right order." |
 | Variable mapping | "Mapping output variables on the End node — every reachable End needs them." |
@@ -89,62 +73,41 @@ Reference table — adapt to context. Add subject (what's being acted on) when s
 | Incident fetch | "Fetching the incident record — this is the structured error report from the failed run." |
 | Variable inspection | "Reading the runtime variable state at the moment of failure…" |
 | Flow correlation | "Mapping the faulting element ID back to a node in your `.flow` file…" |
-| Traces (last resort) | "Pulling traces. Last resort — the previous steps weren't enough." |
-
-## Threshold for the progress list
-
-This table applies only once narration/todos are engaged (see [When to engage](#when-to-engage)). In silent mode there is no user-facing narration or todo list regardless of journey size.
-
-| Journey size | Narration | Progress list |
-| --- | --- | --- |
-| Single edit (1–2 actions, no decisions) | Yes — 1 line | No |
-| Small edit (3–5 actions or 1 decision) | Yes — line per logical step | Optional, agent's call |
-| Standard journey (greenfield, brownfield with multiple nodes, ship, run, full diagnose) | Yes — line per logical step | **Required** — granular |
-| Complex flow (10+ nodes, multiple resource bindings, planning phase) | Yes — denser cadence | **Required** — granular, with sub-todos |
-
-## Todo granularity
-
-A todo is a **state-changing outcome the user cares about**. One logical step ≈ one todo. Multiple actions across multiple tools can map to one todo.
-
-**Counts as a todo:**
-- Solution scaffolded
-- Flow project created
-- Node added and wired
-- Edges connected
-- Variables defined and mapped
-- Validate green
-- Format applied
-- Resources refreshed
-- Uploaded to Studio Web
-- Incident fetched and read
-- Root cause classified
-
-**Does NOT count as a todo (invisible plumbing):**
-- Single `registry get` for schema lookup
-- `ls` / `cat` / `Glob` to confirm a path
-- Reading a file before editing it
-- Re-running the same `validate` after a one-character fix (same todo, just not yet checked)
-- Parsing JSON output
-
-## Pivot rules
-
-If the user redirects scope mid-journey ("skip the connector — use HTTP instead"):
-
-1. Narrate the pivot — "Switching from connector to HTTP node. Updating todos."
-2. Update the progress list:
-   - Mark obsolete in-flight todos as cancelled and drop them from the list.
-   - Insert new todos for the new direction at the right spot.
-   - Leave completed todos in place — they're history, not work.
-3. Continue from the new in-progress todo.
+| Traces, last resort | "Pulling traces. Last resort — the previous steps weren't enough." |
+
+## Progress-list threshold
+
+This applies only when narration/todos are engaged. In silent mode, journey size never creates a user-facing list.
+
+| Journey | Narration | Progress list |
+|---|---|---|
+| Single edit: 1–2 actions, no decisions | One line | None |
+| Small edit: 3–5 actions or one decision | One line per step | Optional |
+| Standard: greenfield, multi-node brownfield, ship, or full diagnose | One line per step | Required and granular |
+| Complex: 10+ nodes, multiple resource bindings, or planning phase | Denser cadence | Required, granular, with sub-todos |
+
+## Todo rules
+
+A todo represents a state-changing outcome the user cares about; roughly one logical step. Multiple tool actions may form one todo.
+
+Valid todos include: solution scaffolded; Flow project created; node added and wired; edges connected; variables defined and mapped; validate green; format applied; resources refreshed; uploaded to Studio Web; incident fetched and read; root cause classified.
+
+Do not create todos for registry lookup, `ls`/`cat`/`Glob` path checks, pre-edit reads, parsing JSON, or rerunning the same `validate` after a one-character fix. Keep such plumbing invisible.
+
+## Pivots
+
+When scope changes:
+
+1. Narrate the pivot, for example: "Switching from connector to HTTP node. Updating todos."
+2. Mark obsolete in-flight todos cancelled and remove them; insert todos for the new direction in the correct position; retain completed todos as history.
+3. Continue with the new in-progress todo.
 
 ## Anti-patterns
 
-- **Never narrate every command.** "Running `registry search`… running `registry get`… running `flow node add`…" — three lines for one logical step is noise. One step, one line.
-- **Never narrate every Read/Edit.** Reading the `.flow` before editing it is plumbing. The step's opening line covers it.
-- **Never recap flag-level or JSON-structure-level detail.** The user does not care that you used `--output json` or that `inputs.detail.bodyParameters` is the field name. Speak in user terms.
-- **Never narrate or spin up a user-facing todo list when the user hasn't asked for verbosity.** Silent by default. Surfacing every step unprompted is noise.
-- **When engaged, never skip narration on a step transition.** Silent transitions leave the user lost.
-- **Never create a todo per bash call.** Todos are user-meaningful outcomes, not the agent's internal action log.
-- **When engaged, never skip the progress list on a standard journey.** Above the trivial threshold, the granular list is mandatory.
-- **Never use first-person filler.** "Let me…", "I'll go ahead and…", "I'm going to…" — drop. Lead with the verb.
-- **Never repeat the prior line's content.** If the previous narration said "Adding the Slack node and wiring its inputs", the next line is *not* "Adding the Slack node now" — it's the next step.
+- Never narrate every command, Read, Edit, or shell action; narrate logical outcomes.
+- Never recap flags or JSON structure.
+- Never show narration or a user-facing todo list without an engagement trigger.
+- When engaged, never omit narration at a step transition or the required list for a standard journey.
+- Never create a todo per bash call.
+- Never use first-person filler such as "Let me", "I'll go ahead", or "I'm going to".
+- Never repeat the previous narration; move to the next logical step.

package/skills/uipath-maestro-flow/references/shared/variables-and-expressions.md

@@ -6,7 +6,7 @@ Complete reference for declaring variables, writing expressions, and managing da
 >
 > `flow validate` catches the structural expression-reference errors:
 >
-> - Missing `=js:` prefix on `$vars`/`$metadata`/`$self` (MST-9107)
+> - Missing `=js:` prefix on `$vars`/`$metadata`/`$self`
 > - Invented `nodes.<id>.output` syntax
 > - References to unknown variables or node IDs
 > - Output-path walks that descend into declared primitives or schemas closed with `additionalProperties: false`
@@ -417,7 +417,7 @@ Every `$vars` / `$metadata` / `$self` reference inside `inputs.detail.bodyParame
 | `"recordId": "{vars.createEntityRecord1.output.Id}"` | `"recordId": "=js:$vars.createEntityRecord1.output.Id"` |
 | `"recordId": "=js:createEntityRecord1.output.Id"` | `"recordId": "=js:$vars.createEntityRecord1.output.Id"` |
 
-The serializer rewrites `$vars` → `vars` whether or not `=js:` is present, so a missing prefix yields a confusing failure: the runtime field is bound to the literal string `"vars.X.output.Id"` (which looks like an unevaluated expression). The last row above is the opposite mistake — `=js:` is present but the `$vars.` prefix on the node reference is missing, so the expression evaluates a bare (undefined) identifier instead of the node's output. `flow validate` catches this (cli-side `expression-prefix-validator`, error with remediation hint) — older cli versions without the validator still let it through to `flow debug`. See [node-output-wiring.md](node-output-wiring.md) for the full per-node-type field reference (MST-9107).
+The serializer rewrites `$vars` → `vars` whether or not `=js:` is present, so a missing prefix yields a confusing failure: the runtime field is bound to the literal string `"vars.X.output.Id"` (which looks like an unevaluated expression). The last row above is the opposite mistake — `=js:` is present but the `$vars.` prefix on the node reference is missing, so the expression evaluates a bare (undefined) identifier instead of the node's output. `flow validate` catches this (cli-side `expression-prefix-validator`, error with remediation hint) — older cli versions without the validator still let it through to `flow debug`. See [node-output-wiring.md](node-output-wiring.md) for the full per-node-type field reference.
 
 ### Comparison
 
@@ -598,7 +598,7 @@ Where `<loopId>` is the loop node's `id` (e.g., `$vars.loop1.currentItem`).
 
 > **Important:** Loop body nodes must have `"parentId": "<loopId>"` set in their JSON. Without this, the runtime does not know the node is inside the loop and `$vars.<loopId>.currentItem` will be undefined.
 
-After loop completion, `$vars.<loopId>.output` holds one entry per iteration — **each entry keyed by body node id, with that node's outputs nested underneath**, NOT the body node's bare return value. See [loop/impl.md § Aggregated loop output](../author/references/plugins/loop/impl.md#aggregated-loop-output-varsloopidoutput).
+After loop completion, `$vars.<loopId>.output` holds one entry per iteration — **each entry keyed by body node id, with that node's outputs nested underneath**, NOT the body node's bare return value. See [loop/impl.md § Aggregated loop output](../author/plugins/loop/impl.md#aggregated-loop-output-varsloopidoutput).
 
 ### Subflow Scope
 
@@ -618,7 +618,7 @@ Subflows have their own variable scope. Parent variables are **not** automatical
 | `uip maestro flow variable list <flow> --output json` | Check what the flow already declares |
 | `uip maestro flow variable remove <flow> <id>` | Drop a declared global |
 
-See [evaluate/references/eval-sets-guide.md](../evaluate/references/eval-sets-guide.md).
+See [evaluate/eval-sets-guide.md](../evaluate/eval-sets-guide.md).
 
 > **`variable add --direction in` binds the variable to a trigger** by writing `triggerNodeId`. That binding is what puts the input in the packed entry point's contract — without it `flow pack` emits an empty `input.properties` while `validate` and `format` stay green. The CLI infers the flow's single trigger; if a flow has more than one, it fails and asks for `--trigger-node-id <nodeId>` to say which entry point the input belongs to. Hand-authored globals need the same field — see [Workflow Variables](#workflow-variables).
 

package/skills/uipath-planner/SKILL.md

@@ -145,7 +145,7 @@ High-level view of what each specialist owns. **Do not describe internal flows o
 | `uipath-rpa` | RPA workflows (XAML and C# coded): create, edit, build, run, debug. Owns **all** UI automation authoring end-to-end, including live-app exploration and probing. | No (relies on Studio) | **No** — defer to `uipath-solution` for `.uipx` multi-project, `uipath-platform` for single non-solution packages |
 | `uipath-agents` | AI agents — code-based (LangGraph / LlamaIndex / OpenAI Agents) and low-code (`agent.json`) | Yes (`uip login`) | **Yes** — end-to-end |
 | `uipath-coded-apps` | Web apps (`.uipath/` dir): build, sync, package, publish, deploy | Yes (`uip login`) | **Yes** — end-to-end |
-| `uipath-functions` | Coded Functions — TypeScript (default), JavaScript, or Python (`uip function new -l ts / js / py`; typed I/O — Pydantic for Python) — atomic deterministic logic: transforms, custom-auth API calls, ERP/IS-connection queries. Runs serverless or on an RPA robot. Invoked from Maestro (Flow/BPMN), agents-as-tools, Orchestrator API. No LLM/agent loop (that → `uipath-agents`) | Yes (`uip login`) | **Yes** — `uip function pack/publish` |
+| `uipath-functions` | Coded Functions — Python (`uip function new -l py`; Pydantic typed I/O) or TypeScript/JavaScript (`-l ts / js`, TypeScript default; `defineFunction` + schema-first typed I/O) — atomic deterministic logic: transforms, custom-auth API calls, ERP/IS-connection queries. Runs serverless or on an RPA robot; a JS/TS function is delivered as a run-as-job function or an HTTP endpoint (Coded App backends) — one calling mode per function. Invoked from Maestro (Flow/BPMN), agents-as-tools, Orchestrator API, or its HTTP trigger. No LLM/agent loop (that → `uipath-agents`) | Yes (`uip login`) | **Yes** — `uip function pack/publish` |
 | `uipath-maestro-flow` | `.flow` files orchestrating RPA, agents, apps | Yes (`uip login`) | **Partial** — Orchestrator deploy of `.uipx`-wrapped solutions → `uipath-solution`; non-solution single package → `uipath-platform` |
 | `uipath-maestro-bpmn` | `.bpmn` files — standards-based BPMN 2.0 process orchestration (gateways, events, boundary timeouts, subprocesses, multi-instance) over RPA, agents, APIs, HITL. Authors its own inline userTask/HITL nodes. | Yes (`uip login`) | **Yes** — packages, uploads, publishes/deploys, and runs via `uip maestro bpmn`; Orchestrator deploy of `.uipx`-wrapped solutions → `uipath-solution` |
 | `uipath-maestro-case` | Case Management authoring — `caseplan.json` from an SDD (`case pack` compiles it to `caseplan.json.bpmn`; authoring `.bpmn` directly is `uipath-maestro-bpmn`) | Yes (`uip login`) | **Partial** — publishes to Studio Web and Orchestrator itself; `.uipx` solution deploy → `uipath-solution` |

package/skills/uipath-planner/assets/templates/case/case-sdd-template.md

@@ -29,7 +29,7 @@
 | **Project SDD role** | child |
 | **Independently executable** | no — Lane A derives tasks only via the Solution root |
 | **Project list section** | §2: Stages & Tasks + §4: Integrations |
-| **Tasks file** | `tasks/tasks.md` — the build skill's contract; planner Lane A task derivation writes its own `<CASE_NAME_KEBAB>-tasks.md` per §Next Steps |
+| **Build handoff** | this SDD is the build skill's contract — `uipath-maestro-case` resolves resources into `tasks/registry-resolved.json` and writes `caseplan.json` directly; the case build has no tasks file |
 | **Generated by** | uipath-planner |
 | **Generation date** | <YYYY-MM-DD> |
 | **Template validation** | <pending \| passed — set to passed with the ready flip> |
@@ -137,7 +137,9 @@ duration and points here; nothing restates a response.
 | <case \| stage: <StageName> \| task: <TaskName>> | <that target's SLA Title> | <At-Risk \| Breached> | <notify-only \| start-task \| enter-stage \| exit-stage \| exit-case> | <— for notify-only; else the task name / stage name / produced exit row> | <— for notify-only and for every start-task; else Yes \| No matching the produced stage-entry row> | <why this response fits the source> |
 
 <!-- Section required whenever ANY SLA exists (case, stage, or action task); omit only in a case with no
-SLA at all. One row per (Scope, SLA, Status), at-risk and breached separately. Source states no response
+SLA at all. The case-level Scope cell is the bare word `case` — not `case: root` and not the case
+name; only the stage and task scopes take a `: <name>` qualifier. One row per (Scope, SLA, Status),
+at-risk and breached separately. Source states no response
 -> both statuses notify-only with Target and Interrupting `—`; never invent a stage, task, or routing
 change to carry a notification. Legal Response values and the Interrupting value each implies:
 case-design-layers-guide.md § Choosing the response. Two-way closure against the SDD's
@@ -578,7 +580,7 @@ Load `uipath-planner` with this SDD path to derive the task list:
 
 > Load `uipath-planner`. SDD path: `<this-file>`.
 
-The planner detects the `## Planner Handoff` header, parses Section 2: Stages & Tasks and Section 4: Integrations, derives the per-skill task list, writes `<CASE_NAME_KEBAB>-tasks.md` alongside this SDD, and emits live `TaskCreate` calls. If `Execution autonomy: interactive`, it enters plan mode for task review before execution.
+The planner detects the `## Planner Handoff` header, parses Section 2: Stages & Tasks and Section 4: Integrations, derives the per-skill task list, and emits live `TaskCreate` calls. If `Execution autonomy: interactive`, it enters plan mode for task review before execution.
 
 Implementation tasks **do not live in this SDD** — they live in the planner's output.
 

package/skills/uipath-planner/references/case/case-design-lane-guide.md

@@ -10,7 +10,7 @@ Case knowledge is split three ways. Read all three to begin, in parallel, **at m
 | [case-design-layers-guide.md](case-design-layers-guide.md) | the case model and every design **Default** — skeleton, gates, data, SLAs, naming, the closure checklist |
 | [`case-sdd-template.md`](../../assets/templates/case/case-sdd-template.md) | the render contract — skeleton, cell rules inline, validation footer |
 
-That is the COMPLETE design reading set. NEVER read `scripts/case/audit_sdd.py` — scripts are RUN, and their findings are the interface. Do NOT read the generic Phase D references (pdd-analysis, product-selection beyond the Constraint Gate): scope is already decided. Reference paths resolve against this skill's base directory, given at invocation — never hunt with `find` / global `ls`. Everything after the SDD (tasks.md, caseplan.json, validate, publish) belongs to `uipath-maestro-case`.
+That is the COMPLETE design reading set. NEVER read `scripts/case/audit_sdd.py` — scripts are RUN, and their findings are the interface. Do NOT read the generic Phase D references (pdd-analysis, product-selection beyond the Constraint Gate): scope is already decided. Reference paths resolve against this skill's base directory, given at invocation — never hunt with `find` / global `ls`. Everything after the SDD (caseplan.json, validate, publish) belongs to `uipath-maestro-case`.
 
 **Draft finalization reads less (hard):** this file's §Resumption + §Terminal step, `sdd.draft.md`, and the template (its validation footer is the gate) — once each. NOT the layers guide: finalization normalizes structure, it does not redesign. No subagents, no background tasks, no tenant discovery unless identities are needed and a session exists.
 

package/skills/uipath-planner/references/case/case-design-layers-guide.md

@@ -427,12 +427,12 @@ Comparison exact — case-sensitive, untrimmed. Never normalize external lookup
 
 ## Layer closure — the design checklist
 
-ONE checklist. Settle every item by assumption during Sketch; re-walk at Confirm (fix failures silently — authoring defects, not user decisions; unfixable → Review Flags). Mechanical shape/contract checks are NOT here — `scripts/case/audit_sdd.py` owns them (enforcement list: template § Validation); run it on the written file.
+ONE checklist. Settle every item by assumption during Sketch; re-walk at Confirm — and when the request is save-a-draft-and-stop there IS no Confirm, so re-walk it immediately BEFORE the write instead; a draft skips the confirmation, never the closure walk (fix failures silently — authoring defects, not user decisions; unfixable → Review Flags). Mechanical shape/contract checks are NOT here — `scripts/case/audit_sdd.py` owns them (enforcement list: template § Validation); run it on the written file.
 
 **Blocking — the design is unbuildable or unreviewable until fixed:**
 
 1. **Other-path trigger source** — every modeled path's entry shape matches its trigger source (§ Secondary-lane entry shapes); interrupting flags set on the stage AND on every entry row; terminal `exit-only` vs returning `return-to-origin` chosen; a warning-only escalation stays a notification; an SLA response needing case work carries ONE `sla-status-change` entry with declared target + titles; never duplicate a global-event entry or exit across primary stages.
-2. **Reachability walk** — every stage reachable from a trigger or SLA source (walk entries forward); every primary stage's completion consumed downstream, referenced by another entry, or feeding a lane; ≥ 1 primary stage `Required: Yes`; `adhoc` never a stage entry. Decision-reachable lanes and duplicate-entry ambiguity per § Secondary-lane entry shapes.
+2. **Reachability walk** — every stage reachable from a trigger or SLA source: walk entries forward, and walk every conditional entry's FALSE branch too. A stage that does not enter never completes, so a downstream stage keying solely off its completion is unreachable on that branch — when a rule SKIPS a stage and the case continues, the bypass is an explicit extra entry row on the downstream stage (its own condition, negated); when the rule ENDS the case, that branch needs a terminal lane. Never write that a skipped stage "auto-completes" or "counts as complete" — that is an assertion, not a route, and the path stays dead. Every primary stage's completion consumed downstream, referenced by another entry, or feeding a lane; ≥ 1 primary stage `Required: Yes`; `adhoc` never a stage entry. Decision-reachable lanes and duplicate-entry ambiguity per § Secondary-lane entry shapes.
 3. **Entry producer** — every non-start entry names its concrete producer (source stage/task, connector event, paired `wait-for-user` exit, declared SLA reference); at-risk rows name the escalation, breach rows the SLA alone.
 4. **Decision-routing closure** — every decision outcome routes somewhere: no dead-end status values; an outcome targeting a lane keys that lane's entry; every routing button's variable+value is consumed downstream or a declared terminal; a fully-orphaned decision variable on a decision task is blocking.
 5. **Gate reads the producer** — no condition whose WHEN names a task reads a case variable that task writes (§ Gate on the producer).

package/skills/uipath-planner/references/non-pdd-lane-guide.md

@@ -13,7 +13,7 @@ All sub-steps are non-interactive. Run them first; their outputs drive the Step
 1. **Provided context document** — if the entry guard classified a document as "Other context", read it now. Any question its content answers counts as resolved; its content feeds the plan.
 
 2. **Filesystem detection** — use `Glob` / `Read` / `Grep` (cross-platform) in current directory, then in the parent, NEVER shell-specific pipelines (`ls` globs, `grep` over pipes, `/dev/null` fail on native PowerShell):
-   - `Glob`: `project.json`, `*.xaml`, `*.cs`, `*.flow`, `flow_files/*.flow`, `*.bpmn`, `caseplan.json`, `agent.json`, `pyproject.toml`, `.uipath/*`, `app.config.json`, `*.uipx`, `element.json`, `*.py`.
+   - `Glob`: `project.json`, `*.xaml`, `*.cs`, `*.flow`, `flow_files/*.flow`, `*.bpmn`, `caseplan.json`, `agent.json`, `pyproject.toml`, `uipath.json`, `package.json`, `.uipath/*`, `app.config.json`, `*.uipx`, `element.json`, `*.py`.
    - `project.json` found → `Read` it and check `targetFramework` and dependencies structurally (no regex-over-cat).
    - `pyproject.toml` found → `Read` it and disambiguate: an agent-framework dependency (`langgraph`, `llamaindex`, `openai-agents`) or a sibling `agent.json` → **Agents**; a sibling `uipath.json` with a `functions` map (or `entry-points.json` from `uip function init`) → **Functions**; a bare `uipath` dependency with neither → inspect further or ask (a `.venv/` directory is NOT required and proves nothing).
    - Root-level `*.json` with none of the above → `Grep` for `"document.dsl"` (API Workflow project).
@@ -27,6 +27,7 @@ All sub-steps are non-interactive. Run them first; their outputs drive the Step
    | `agent.json` | `uipath-agents` (low-code) |
    | `pyproject.toml` + agent-framework dependency (langgraph / llamaindex / openai-agents) | `uipath-agents` (coded) |
    | `pyproject.toml` + `uipath.json` with a `functions` map | `uipath-functions` |
+   | `package.json` + `uipath.json` with a `functions` map | `uipath-functions` |
    | JSON containing `document.dsl` | `uipath-api-workflow` |
    | `.uipath/` or `app.config.json` | `uipath-coded-apps` |
    | `element.json` (+ `element-metadata.json`) | `uipath-connector-builder` |

package/skills/uipath-planner/references/pdd-driven-lane-guide.md

@@ -23,10 +23,11 @@ Read these fields:
 | **SDD scope** | `single-product` → one SDD file owns one task list. `solution` → one solution-overview SDD plus one per-project SDD; tasks span all projects. |
 | **Project list section** | Tells the planner where to find the unified project list (e.g., `§10` for RPA, `§3 + §7` for Flow, `Project Inventory` for solution overview). |
 | **Tasks file** | Where to write `<process>-tasks.md`. Phase D proposes a path; Lane A respects it. |
+| **Build handoff** | Case SDDs carry this prose row INSTEAD of `Tasks file` — the case build writes `caseplan.json` directly and has no tasks file. Informational only; Lane A parses it for provenance and never resolves it to a path. |
 | **Generated by** | `uipath-planner`. Used in the summary output to tell the user the SDD's provenance. |
 | **Generation date** | `YYYY-MM-DD`. Shown to the user in the summary. |
 
-**Missing or malformed fields:** default `Execution autonomy` to `interactive` (safer), default `Delivery model` to `unspecified` (no constraint propagated — pre-existing SDDs lack the field), default `SDD scope` to `single-product`, infer `Project list section` from the template type, default `Tasks file` to `<sdd-basename-without-sdd>-tasks.md`. **Track each defaulted field** in a session-local list — Step 8 surfaces them in the user-facing summary so the human reviewer can correct the SDD before tasks are emitted. Do not silently swallow the defaults.
+**Missing or malformed fields:** default `Execution autonomy` to `interactive` (safer), default `Delivery model` to `unspecified` (no constraint propagated — pre-existing SDDs lack the field), default `SDD scope` to `single-product`, infer `Project list section` from the template type, default `Tasks file` to `<sdd-basename-without-sdd>-tasks.md` (EXCEPT when the header carries `Build handoff` — that is a Case SDD, where `Tasks file` is absent by design: default it silently and do NOT report it as a defaulted field). **Track each defaulted field** in a session-local list — Step 8 surfaces them in the user-facing summary so the human reviewer can correct the SDD before tasks are emitted. Do not silently swallow the defaults.
 
 **Autonomy override on resume:** if the user's resume message explicitly requests review or interactive handling, honour the message over the header's `Execution autonomy` value (do not re-ask).
 
@@ -99,7 +100,7 @@ Based on the project list, pick the matching pattern from [multi-skill-patterns-
 | Case Management with §4 integrations that reference unbuilt resources | Build external components first, then `uipath-maestro-case`; inline `action`, connector, timer, and child-case task details stay with the Case specialist |
 | Case Management whose §4 integrations are pre-existing or unresolved portable intent | `uipath-maestro-case` build task first; unresolved IDs/folders travel as review items for the Case specialist's registry discovery |
 | Any SDD with a filled "IXP / Document Understanding Models" table | Add an IXP model build + validation task via `uipath-ixp` per model, ordered before its consumer's build tasks |
-| Any SDD with a filled "Coded Functions" table | Add a Function build + validation task via `uipath-functions` per function, ordered before its consumer's build tasks |
+| Any SDD with a filled "Coded Functions" table | Add a Function build + validation task per function via `uipath-functions`, ordered before its consumer's build tasks |
 | Agent with RPA tools in §3 Tools | Pattern 5 |
 | Coded App | Coded App build + `uipath-solution` deploy + testing (when wrapped in `.uipx`); otherwise `uipath-coded-apps` self-deploys |
 | API Workflow | API Workflow build + `uipath-solution` publish + testing |

package/skills/uipath-planner/references/sdd-generation-guide.md

@@ -471,6 +471,7 @@ This step runs in BOTH Autonomous and Interactive modes — it is a hard blocker
    | **Independently executable** | no                              ← children only; Lane A refuses to derive tasks from a child directly
    | **Project list section** | §11 / §10 + §11 / Project Inventory ← template-specific (RPA single: §11; RPA Master: §10 + §11; Flow: §3 + §7; BPMN: §4 + §9; Case: §2 + §4; etc.)
    | **Tasks file** | `<PROCESS_NAME_KEBAB>-tasks.md`             ← planner writes here on first run. Solution scope: root AND every child carry the SAME canonical `<SOLUTION_NAME_KEBAB>-tasks.md` — exactly one tasks file per solution, never one per project
+   | **Build handoff** | <prose — Case template ONLY>         ← the Case template emits this row INSTEAD of `Tasks file`: the case build writes `caseplan.json` directly and has no tasks file, so there is no path to carry. Every other template emits `Tasks file`; never emit both
    | **Generated by** | uipath-planner
    | **Generation date** | <YYYY-MM-DD>
    | **Template validation** | pending → passed                   ← set to `passed` together with the `ready` flip (item 8)

package/skills/uipath-planner/scripts/case/audit_sdd.py

@@ -353,13 +353,37 @@ def model_findings(text: str, facts: dict, carried_names: frozenset[str] = froze
     return findings
 
 
-
 EXIT_TYPES_YES = {"exit-only", "return-to-origin", "wait-for-user"}
 EXIT_TYPES_NO = {"exit-only", "wait-for-user"}
 RECIPIENT_PREFIX = re.compile(r"^(Role|User|UserGroup|Email|Expression):")
 FORBIDDEN_VOCAB = ["groupOperator", "savedFilterTrees", "io-binding", "auto-mint", "originalVar", "inputOutputs["]
 
 
+def decision_routed_behaviors(text: str) -> list[str]:
+    """`Behavior` prose from decision buttons that map a variable to a value.
+
+    A decision task's `**Actions:**` table routes outcomes:
+
+        | Button | Maps To                   | Behavior                       |
+        | Reject | reviewDecision = "Reject" | ... the Application Rejected lane |
+
+    A row whose `Maps To` carries an assignment is a deterministic route, so the
+    lane it names cannot be keyed on `user-selected-stage` (a picker is for a lane
+    a PERSON launches). Kept in code rather than in the template: the design
+    lane's reading budget is saturated, and prose that was long enough to land
+    this repair cost a passing task while prose short enough to be safe left the
+    agent churning without producing an SDD.
+    """
+    out: list[str] = []
+    for chunk in re.split(r"(?=\*\*Actions:\*\*)", text):
+        if not chunk.startswith("**Actions:**"):
+            continue
+        for _, cells in table_rows(chunk):
+            if len(cells) >= 3 and "=" in cells[1]:
+                out.append(cells[2])
+    return out
+
+
 def section_slice(text: str, heading: str) -> str:
     """Body of a `### {heading}` section up to the next heading of any level."""
     match = re.search(rf"^### {re.escape(heading)}\s*$(.*?)(?=^#{{1,5}} |\Z)", text, re.M | re.S)
@@ -414,6 +438,37 @@ def declared_sla_titles(text: str) -> dict[str, set[str]]:
     return titles
 
 
+AMBIGUOUS_PERSONA = re.compile(r"^[A-Z][A-Za-z/ ]{2,40}\s+or\s+[A-Za-z][A-Za-z/ ]{2,40}$")
+PERSONA_HEADER = re.compile(r"^(assignee|owner|performer|responsible|persona|role)s?$", re.I)
+
+
+def ambiguous_personas(text: str) -> list[str]:
+    """Persona cells naming two roles — an unresolved conditional, not an owner.
+
+    A task runs as exactly one persona. "Underwriter or Credit Analyst" is a
+    routing rule the author stated but never modelled: the reader cannot tell
+    who owns the task, and no guard picks between them at run time.
+    """
+    found: list[str] = []
+    cols: list[int] | None = None
+    for line in text.splitlines():
+        stripped = line.strip()
+        if not stripped.startswith("|"):
+            cols = None
+            continue
+        if re.match(r"^[\s\-:|]+$", stripped.strip("|")):
+            continue
+        cells = [c.strip() for c in stripped.strip("|").split("|")]
+        header = [i for i, c in enumerate(cells) if PERSONA_HEADER.match(c)]
+        if header:
+            cols = header
+            continue
+        if cols:
+            for i in cols:
+                if i < len(cells) and AMBIGUOUS_PERSONA.match(cells[i]):
+                    found.append(cells[i])
+    return sorted(dict.fromkeys(found))
+
 def contract_findings(text: str, facts: dict) -> list[str]:
     """Deterministic contract checks beyond template shape: gate-slot WHEN legality,
     exit-type pairing, SLA title closure, uniqueness, recipients, buttons, Out producers,
@@ -436,6 +491,27 @@ def contract_findings(text: str, facts: dict) -> list[str]:
     if has_uss_entry and not has_wfu_exit:
         findings.append("user-selected-stage entry with no wait-for-user exit anywhere — validate fails with 'will never be met'")
 
+    for persona in ambiguous_personas(text):
+        findings.append(
+            f"task persona {persona!r} names two roles — a task runs as exactly one "
+            "persona, so an either/or cell is a routing rule stated but not modelled: "
+            "assign the role the case actually uses and put the condition in a guard, "
+            "or split it into two guarded task variants"
+        )
+
+    routed = " || ".join(decision_routed_behaviors(text)).casefold()
+    if routed:
+        for kind, name, block in stage_blocks(text):
+            if kind != "Secondary Stage" or "user-selected-stage" not in block:
+                continue
+            if name.casefold() in routed:
+                findings.append(
+                    f"stage {name!r} is entered by user-selected-stage but a decision button routes to it "
+                    "— a picker rule cannot carry a deterministic route: key the entry on the decision "
+                    '(selected-stage-completed("<origin>") + IF on the fact) and give the origin the '
+                    "matching Marks Stage Complete: No diverting exit"
+                )
+
     # Case Exit Conditions: >= 1 completing row
     case_exit = section_slice(text, "Case Exit Conditions")
     if case_exit and not any("Yes" in cells for _, cells in table_rows(case_exit)):

package/skills/uipath-platform/SKILL.md

@@ -107,10 +107,11 @@ If the user names a profile, check that profile explicitly:
 uip login status --profile dev --output json
 ```
 
-**Interactive login (browser OAuth2):** `uip login` opens a browser window on the user's machine and blocks until they complete it. In a non-interactive or automated session, do NOT run it yourself — tell the user to run it and wait.
-```bash
-uip login --output json
+**Interactive login (browser OAuth2):** `uip login` opens a browser window on the user's machine and blocks until they complete it. **Never run an interactive login through your own shell tool — with or without `--no-browser`.** Run by an agent, the person who must sign in sees only a spinner: the printed URL and the blocking wait live in your tool output, not in front of them. `--no-browser` does not make the command agent-runnable — it exists for automation that opens the URL *itself*; it still blocks until the sign-in callback arrives, and relaying the printed URL by copy/paste is fragile (a line-wrapped or truncated copy is rejected by the identity server with an opaque browser-side error). Instead, ask the user to run the command directly in their own terminal — in Claude Code, prefixing it with `!` runs it inside the session:
+```text
+! uip login
 ```
+Then confirm with `uip login status --output json` once they say it's done. If a retry fails with `EADDRINUSE` / "Port 8104 is already in use", an abandoned earlier attempt is still holding the callback port — it releases itself within 5 minutes, or the user can end the stale `uip login` process.
 
 For a named interactive login:
 ```bash
@@ -181,6 +182,7 @@ Choose the appropriate operation from the Task Navigation table below. For `uip
 | **Assign user/group license bundles** | [references/licensing/user-licenses-allocations.md](references/licensing/user-licenses-allocations.md) |
 | **Report on license consumption** | [references/licensing/consumables-report.md](references/licensing/consumables-report.md) |
 | **Understand licensing concepts** | [references/licensing/licensing.md](references/licensing/licensing.md) |
+| **Diagnose a licensing symptom** | [references/licensing/diagnose/CAPABILITY.md](references/licensing/diagnose/CAPABILITY.md) |
 | **Full CLI command reference** | [references/uip-commands.md](references/uip-commands.md) |
 | **Build/run/validate coded workflows** | [/uipath:uipath-rpa](/uipath:uipath-rpa) |
 
@@ -313,7 +315,7 @@ Every `uip` command accepts:
 - **[Data Fabric](references/data-fabric/data-fabric.md)** — Entity schemas, records CRUD, query filters and aggregates, choice sets, file attachments, CSV bulk import, folder scoping
 - **[LLM Gateway — BYO Connections](references/llmgateway/byo-connections.md)** — Register tenant-owned LLM keys against UiPath products
 - **[Guardrails — BYOG Configurations](references/guardrails/byo-configurations.md)** — Manage tenant-registered bring-your-own guardrail (BYOG) configurations and diagnose their underlying Integration Service connections
-- **[Licensing](references/licensing/licensing.md)** — Tenant allocations, user/group bundles, consumables reporting
+- **[Licensing](references/licensing/licensing.md)** — Tenant allocations, user/group bundles, consumables reporting, [diagnose](references/licensing/diagnose/CAPABILITY.md)
 - **[Coded Workflows](/uipath:uipath-rpa)** — Building coded automation projects
 
 > **Trouble?** If something didn't work as expected, use `/uipath-feedback` to send a report.

package/skills/uipath-platform/references/integration-service/activities.md

@@ -66,6 +66,8 @@ The **Operation** field on trigger activities indicates the trigger type:
 
 Some IS activities — most notably **List All Records** and other list/query operations — accept a server-side filter expressed in **CEQL** (Connector Expression Query Language). As with trigger filters (which compile to JMESPath), CEQL filters are authored as a **structured filter tree** and the CLI compiles them to a CEQL string. Authoring as a tree keeps the CLI and Studio Web in lockstep so the activity round-trips cleanly when re-opened in SW.
 
+**Never hand-write the CEQL string.** The tree is the only authored form; the grammar below describes what the compiler emits, so you can read a compiled query and recognize a malformed one. For a connector node in a Maestro flow, follow the filter-tree step in [uipath-maestro-flow — connector/impl.md Step 6a](../../../uipath-maestro-flow/references/author/plugins/connector/impl.md), which discovers the FilterBuilder parameter name from the node registry.
+
 ### Contract — three signals from IS metadata
 
 The CLI reads the live IS metadata response and uses three signals to wire the filter:
@@ -96,7 +98,7 @@ Identical to the trigger filter tree — the same `FilterTree` / `Filter` / `Wor
       "value": {
         "value": <typed value>,   // string / number / boolean / ISO-8601 date-time / array
         "rawString": "\"...\"",   // verbatim user-entered text (with quotes for strings)
-        "isLiteral": true         // literals only — expression values are not yet supported
+        "isLiteral": true         // false for a runtime expression operand
       }
     }
   ],
@@ -190,7 +192,7 @@ Logical operators between siblings:
 4. For each leaf, pick an operator from the field's `searchableOperators` list (when present). Date-time fields take ISO-8601 strings; enums take the literal enum value.
 5. Use the field's `name` as the leaf `id`. The CLI rewrites it to `searchableNames[0]` when emitting CEQL if the connector declares one — you don't need to use the alias yourself.
 6. Build one leaf per condition; place multiple conditions under the same `groupOperator` (0 for AND, 1 for OR). Use nested `groups` for mixed AND/OR.
-7. Wrap values in a `WorkflowValue` object with `value`, `rawString`, `isLiteral`. Strings, numbers, booleans, dates, and arrays are all valid `value` types; only `isLiteral: true` is currently supported by activity-side compilation.
+7. Wrap values in a `WorkflowValue` object with `value`, `rawString`, `isLiteral`. Strings, numbers, booleans, dates, and arrays are all valid `value` types. Set `isLiteral: false` for a runtime operand — the compiler emits a placeholder for it, so a runtime value never needs a hand-written query string.
 
 ### What NOT to generate
 
@@ -202,14 +204,15 @@ Logical operators between siblings:
 | `{ "value": "Active" }` on a leaf | Bare string — must be wrapped in the `WorkflowValue` object. | `{ "value": { "value": "Active", "rawString": "\"Active\"", "isLiteral": true } }` |
 | `{ "id": "fields.Status", ... }` | `fields.` prefix — use the bare field name from `is resources describe`. | `{ "id": "Status", ... }` |
 | `{ "id": "<field without searchable: true>", ... }` | The CLI checks `searchable` on the IS metadata entry; non-searchable fields are rejected even if their type looks filterable. | Pick a field where `searchable: true`. |
-| `"queryParameters": { "where": "..." }` alongside `filter` | Hardcoding `where` assumes that's the FilterBuilder param name — it isn't always (Salesforce uses `q`, etc.). | Pass `filter` only; the CLI discovers the right param name from `design.component === "FilterBuilder"`. |
+| `"queryParameters": { "where": "..." }` alongside `filter` | Hardcoding `where` assumes that's the FilterBuilder param name — it isn't always (Salesforce uses `q`, Data Service uses `queryExpression`). | Pass `filter` only; the CLI discovers the right param name from `design.component === "FilterBuilder"`. |
+| `"queryParameters": { "<filterParam>": "=js:\"Name = '\" + …" }` | A hand-written CEQL string. Validation cannot read it, and the design-time tree stays empty. | Structured tree under `filter`, with `isLiteral: false` on any runtime operand. |
 | `In` operator with a single value not in a list | `In` expects an array `value`. | Use `Equals`, or pass `value: ["one"]`. |
 
 ## Custom Fields (`objectActions[ActionType=Api]`)
 
 Connectors with extensible/custom fields (Jira project+issuetype → custom Jira fields, Mailchimp list_id → audience merge fields, Salesforce custom objects) expose `Api`-type entries under `objectActions[]`. Each entry's `apiConfiguration.url`/`body` carries `{token}` placeholders naming the parent fields. The runtime replays the ObjectAction with cached parent values to fetch the connector-specific custom-field schema.
 
-**For Maestro flows**, this lives on the activity node as `essentialConfiguration.customFieldsRequestDetails`. Authoring contract → [uipath-maestro-flow connector/impl.md Step 6c](../../../uipath-maestro-flow/references/author/references/plugins/connector/impl.md).
+**For Maestro flows**, this lives on the activity node as `essentialConfiguration.customFieldsRequestDetails`. Authoring contract → [uipath-maestro-flow connector/impl.md Step 6c](../../../uipath-maestro-flow/references/author/plugins/connector/impl.md).
 
 Shape: