@uipath/skills 1.195.0 → 1.196.0

package/skills/uipath-maestro-case/references/plugins/conditions/task-entry-conditions/impl-json.md

@@ -71,13 +71,13 @@ Rules use DNF — outer array is OR, inner array is AND.
 ]]
 ```
 
-`conditionExpression` uses bare `=js:<expr>` (no outer parens) — per FE convention for conditions. Operators (`>`, `<`, `===`, etc.) and function calls go inline. For combined boolean expressions, wrap each sub-clause in parens before joining: `=js:(vars.X === 'foo') && (vars.Y > 5)`. Full per-sink rule: [bindings-and-expressions.md § Canonical form per sink](../../../bindings-and-expressions.md#canonical-form-per-sink).
+`conditionExpression` uses bare `=js:<expr>` (no outer parens) — per FE convention for conditions. Operators (`>`, `<`, `===`, etc.) and function calls go inline. Use strict `===` / `!==`, never loose `==` / `!=` — normalize SDD shorthand like `approved == true` to `=js:vars.approved === true` (do not transcribe `==` verbatim). For combined boolean expressions, wrap each sub-clause in parens before joining: `=js:(vars.X === 'foo') && (vars.Y > 5)`. Full per-sink rule: [bindings-and-expressions.md § Canonical form per sink](../../../bindings-and-expressions.md#canonical-form-per-sink).
 
 ### wait-for-connector — bind a connector event
 
-Write `rule.uipath` per [connector-trigger-common.md § Target: connector-bound condition rule](../../../connector-trigger-common.md#target-connector-bound-condition-rule) (canonical rule JSON + procedure there) — a bare rule (no `uipath`) is rejected by Studio Web. **Stage-scoped: `elementId = <stageId>-<ruleId>`.** `conditionExpression` optional. If `type-id` / `connection-id` / `connector-key` is `<UNRESOLVED>`, omit `uipath` (rule emitted without its connector configuration; see [connector-trigger-common.md § Placeholder fallback](../../../connector-trigger-common.md#placeholder-fallback)).
+Write `rule.uipath` per [connector-trigger-common.md § Target: connector-bound condition rule](../../../connector-trigger-common.md#target-connector-bound-condition-rule) (canonical rule JSON + procedure there) — a bare rule (no `uipath`) is rejected by Studio Web. **Stage-scoped: `elementId = <stageId>-<ruleId>`.** `conditionExpression` optional. If `type-id` / `connection-id` / `connector-key` is `<UNRESOLVED>`, emit the **stub `uipath` placeholder** (2 `"placeholder"` context fields: `connectorKey` + `operation` — see [connector-trigger-common.md § Placeholder fallback](../../../connector-trigger-common.md#placeholder-fallback)).
 
-**Rule output binding.** If the T-entry has `outputs:`, dispatch `rule.uipath.outputs[]` per [io-binding/impl-json.md § Output Binding Shapes for Connector Condition Rules](../../variables/io-binding/impl-json.md#output-binding-shapes-for-connector-condition-rules) **as the last step — after rule write, before root bindings**. `elementId` stays `<stageId>-<ruleId>` on every output entry. Skip when `uipath` is absent.
+**Rule output binding.** If the T-entry has `outputs:`, dispatch `rule.uipath.outputs[]` per [io-binding/impl-json.md § Output Binding Shapes for Connector Condition Rules](../../variables/io-binding/impl-json.md#output-binding-shapes-for-connector-condition-rules) **as the last step — after rule write, before root bindings**. `elementId` stays `<stageId>-<ruleId>` on every output entry. Skip when the rule has no `uipath.outputs[]` (stub placeholder).
 
 ### runs-sequentially — sequential group with optional parallel siblings
 
@@ -101,4 +101,4 @@ Write `rule.uipath` per [connector-trigger-common.md § Target: connector-bound
 
 ## Post-Write Verification
 
-Confirm target task's `entryConditions[]` length equals the number of task-entry T-tasks tasks.md wrote for this task. Each entry carries `id` (prefix `c`), non-empty `displayName` (SDD value or `Entry Rule {N}` default), and `rules` with the expected `rule` value plus any required side field. For `wait-for-connector`: verify `rule.uipath.serviceType` is `"Intsvc.WaitForEvent"`, `rule.uipath.context[]` is populated, inputs/outputs `elementId` is `<stageId>-<ruleId>`, and ConnectionId + FolderKey root bindings exist. CLI `validate` does NOT check `rule.uipath` — confirm via Studio Web.
+Confirm target task's `entryConditions[]` length equals the number of task-entry T-tasks tasks.md wrote for this task. Each entry carries `id` (prefix `c`), non-empty `displayName` (SDD value or `Entry Rule {N}` default), and `rules` with the expected `rule` value plus any required side field. For `wait-for-connector`: verify `rule.uipath.serviceType` is `"Intsvc.WaitForEvent"`, `rule.uipath.context[]` is populated, inputs/outputs `elementId` is `<stageId>-<ruleId>`, and ConnectionId + FolderKey root bindings exist. Full `validate` flags a missing `rule.uipath`/`context` (`connector activity missing`) but not its internals (a wrong `serviceType` passes) — confirm the connector resolves in Studio Web.

package/skills/uipath-maestro-case/references/plugins/logging/impl-json.md

@@ -2,6 +2,8 @@
 
 Unified issue log for the implementation phase. Initialized by `implementation.md`, written to by any plugin, dumped to markdown after build.
 
+> **No `planning.md`** — logging is an implementation-only utility (not a planned node type), so it has no planning doc. Intentional, not a gap.
+
 > **Pseudocode only.** The snippets below are data-shape specifications, not runnable code. The agent holds the issue list in its own reasoning during a run and emits `tasks/build-issues.md` with the Write tool at dump time. Do NOT create a `.py` script or shell out to Python — per [`case-editing-operations.md § Tool usage`](../../case-editing-operations.md#tool-usage--mandatory), Read/Write/Edit are the only I/O primitives.
 
 ## Setup
@@ -59,6 +61,14 @@ After Step 12 (validate), group issues by `plugin` and write to `tasks/build-iss
 | Step | Task | Reason |
 |---|---|---|
 | 9 | Run Compliance Check | No inputs — placeholder task |
+
+## global-vars
+
+### Errors
+
+| Step | Issue |
+|---|---|
+| 6 | Variable `caseStatus` declared twice |
 ```
 
 - Omit severity subsections with zero entries

package/skills/uipath-maestro-case/references/plugins/sla/impl-json.md

@@ -29,28 +29,16 @@ Record every `T<n> → esc_xxxxxx` in `id-map.json` under `{kind: "escalation",
 
 ## Target resolution
 
-Read the `Schema:` header from `tasks.md` to pick the root-target path. Stage-target path is identical across schemas.
-
-### v19
-
-- `target: "root"` → `root.data.slaRules` (**inside `root.data`** — sibling of `intsvcActivityConfig` and `uipath`, NOT a top-level key and NOT a direct child of `root`)
-- `target: "<stage-name>"` → locate node by `data.label === <stage-name>`; write to `node.data.slaRules` (inside the stage node's `data`)
-
-### v20
-
-- `target: "root"` → **`metadata.slaRules`** (top-level `metadata` block, NOT `root.data.slaRules` — there is no `root` in v20)
-- `target: "<stage-name>"` → locate node by `data.label === <stage-name>`; write to `node.data.slaRules` (unchanged from v19 — node internals are identical)
-
-### Common
-
+- `target: "root"` → **`metadata.slaRules`** (top-level `metadata` block — there is no `root` key on disk)
+- `target: "<stage-name>"` → locate node by `data.label === <stage-name>`; write to `node.data.slaRules`
 - Accepted node types: `case-management:Stage` and `case-management:ExceptionStage`.
 - If the stage node isn't found, halt and AskUserQuestion with candidate stage labels + "Something else".
 
 ## Recipe — one target
 
-After grouping T-entries by target, compose the `slaRules` array and write it into the target's location per the table above. The composed array shape is **identical** across v19 and v20 — only the destination path differs.
+After grouping T-entries by target, compose the `slaRules` array and write it into the target's location per the rules above.
 
-### Composed array (both schemas)
+### Composed array
 
 ```json
 [
@@ -68,30 +56,12 @@ After grouping T-entries by target, compose the `slaRules` array and write it in
 ]
 ```
 
-### v19 root-target shape
-
-```json
-{
-  "root": {
-    "id": "root",
-    "name": "<name>",
-    "type": "case-management:root",
-    "...": "...",
-    "data": {
-      "intsvcActivityConfig": "v2",
-      "uipath": { "...": "..." },
-      "slaRules": [ <composed array above> ]
-    }
-  }
-}
-```
-
-### v20 root-target shape
+### Root-target shape
 
 ```json
 {
   "id": "case-aBcDeFgHiJ",
-  "version": "20.0.0",
+  "version": "23.0.0",
   "metadata": {
     "caseIdentifier": "<...>",
     "caseUnifiedSchemaEnabled": true,
@@ -102,12 +72,11 @@ After grouping T-entries by target, compose the `slaRules` array and write it in
 }
 ```
 
-For a stage target (both schemas), the same `slaRules` array is written under `node.data.slaRules` (sibling of `label`, `tasks`, `parentElement`).
+For a stage target, the same `slaRules` array is written under `node.data.slaRules` (sibling of `label`, `tasks`, `parentElement`).
 
 > **Common failures:**
-> - **v19:** emitting `slaRules` at the caseplan top level or directly on `root` (sibling of `data`). Both wrong — must nest inside `data`.
-> - **v20:** emitting `slaRules` under a non-existent `root` key, or under `root.data.slaRules`. Both wrong — must nest under top-level `metadata`. There is no `root` key in v20.
-> - **Either:** writing `slaRules` to a stage's top level (sibling of `id`/`type`). Stage SLA always lives under `node.data.slaRules` regardless of schema.
+> - Emitting `slaRules` under a non-existent `root` key. Wrong — must nest under top-level `metadata`. There is no `root` key on disk.
+> - Writing `slaRules` to a stage's top level (sibling of `id`/`type`). Stage SLA always lives under `node.data.slaRules`.
 
 Emission rules:
 
@@ -156,8 +125,7 @@ List every unresolved recipient in the completion report (per SKILL.md § Comple
 
 ## Post-write validation
 
-- **v19:** confirm `root.data.slaRules` or `node.data.slaRules` exists with the expected entries. Verify the key is nested under `data`.
-- **v20:** confirm `metadata.slaRules` (top-level) or `node.data.slaRules` (stage) exists. Verify v20's root-target uses `metadata` — not `root.data` (which doesn't exist in v20).
+- Confirm `metadata.slaRules` (root) or `node.data.slaRules` (stage) exists with the expected entries. Verify the root-target uses `metadata` — not `root.data` (which doesn't exist on disk).
 - Confirm the trailing entry's `expression === "=js:true"` when any SLA T-entry targeted this node.
 - Confirm every generated `esc_` ID appears in `id-map.json`.
 - Run `uip maestro case validate <file> --output json` after all SLA targets have been written (not per-target).

package/skills/uipath-maestro-case/references/plugins/sla/planning.md

@@ -15,18 +15,18 @@ Pick this plugin whenever the sdd.md mentions deadlines, service-level agreement
 
 | Sub-op | Purpose |
 |--------|---------|
-| **Default SLA** | The time-based catch-all SLA. One per target (root or stage). Written into the SLA rules array with `expression: "=js:true"`. Path schema-dependent — see [impl-json.md § Target resolution](impl-json.md). |
+| **Default SLA** | The time-based catch-all SLA. One per target (root or stage). Written into the SLA rules array with `expression: "=js:true"`. See [impl-json.md § Target resolution](impl-json.md) for the destination paths. |
 | **Conditional SLA rules** | Expression-driven SLA overrides. Root-only. Prepended to the root SLA rules array ahead of the default. |
 | **Escalation rules** | Notifications triggered at-risk or on breach. Attached to a specific rule via `escalationRule[]`. |
 
 ## Applying SLA at Root vs Stage
 
-- **Root** — the default SLA for the whole case. Target `"root"`; written to the root SLA rules array (v19: `root.data.slaRules[]`; v20: `metadata.slaRules[]` — see Rule 18).
-- **Stage** — stage-specific SLA. Target `"<stage-name>"`; written to the stage node's `data.slaRules[]` (unchanged across schemas). Overrides the root default while the stage is active.
+- **Root** — the default SLA for the whole case. Target `"root"`; written to `metadata.slaRules[]`.
+- **Stage** — stage-specific SLA. Target `"<stage-name>"`; written to the stage node's `data.slaRules[]`. Overrides the root default while the stage is active.
 
 Set root SLA first, then stage SLAs. This mirrors the schema precedence: stage > root.
 
-> **Conditional SLA rules are root-only.** They live in the root SLA rules array (v19: `root.data.slaRules[]`; v20: `metadata.slaRules[]`); per-stage conditional SLA is not supported. If the sdd.md describes one, flag to the user.
+> **Conditional SLA rules are root-only.** They live in `metadata.slaRules[]`; per-stage conditional SLA is not supported. If the sdd.md describes one, flag to the user.
 
 > **ExceptionStage SLA is supported.** Author it the same way as a regular Stage SLA — write `data.slaRules[]` on the `case-management:ExceptionStage` node. See [`impl-json.md`](impl-json.md).
 
@@ -182,7 +182,7 @@ SLA is the **last** category in `tasks.md` (§4.8), after conditions. For each t
 ## Anti-Patterns
 
 - **Do not fabricate expression syntax.** Describe conditional SLA rules in natural language during planning; the execution phase handles the exact syntax.
-- **Do not put conditional SLA rules on stages.** Conditional SLA rules live in the root SLA rules array only (v19: `root.data.slaRules[]`; v20: `metadata.slaRules[]`). Flag to the user if the sdd.md describes a per-stage conditional SLA.
+- **Do not put conditional SLA rules on stages.** Conditional SLA rules live in `metadata.slaRules[]` only. Flag to the user if the sdd.md describes a per-stage conditional SLA.
 - **Do not invert rule order.** Conditional rules are evaluated in insertion order — insert them in the priority order the sdd.md specifies.
 - **Do not skip the resolver to save a CLI call.** Email / group-name recipients MUST go through [§ Identity Resolution](#identity-resolution). Writing `<UNRESOLVED: ...>` directly without attempting `uip admin users/groups list` is a planning bug.
 - **Do not fabricate UUIDs.** When the resolver returns 0 / multi / partial matches, AskUserQuestion or keep `<UNRESOLVED>` — never guess a UUID, never auto-pick the first candidate without the exact-email / exact-name gate.

package/skills/uipath-maestro-case/references/plugins/stages/impl-json.md

@@ -23,29 +23,11 @@ Cross-cutting direct-JSON rules live in [`case-editing-operations.md`](../../cas
 
 Record `T<n> → Stage_xxxxxx` in `id-map.json` for downstream cross-reference.
 
-## Position (stateful, v19 only)
+## Layout fields
 
-**v19 mode only.** v20 mode skips position math entirely (Rule 19) — see § Recipe (v20) below.
+Do NOT emit node-level `position`, `style`, `measured`, `width`, `height`, `zIndex` (Rule 18 layout-strip). FE auto-layouts on canvas load.
 
-**Before writing (v19)**, count existing stages:
-
-```text
-existingStageCount = schema.nodes.filter(n =>
-  n.type === "case-management:Stage" ||
-  n.type === "case-management:ExceptionStage"
-).length
-```
-
-Then compute:
-
-```text
-position.x = 100 + existingStageCount * 500
-position.y = 200
-```
-
-Trigger nodes are NOT counted.
-
-## Recipe — Regular Stage (v19)
+## Recipe — Regular Stage
 
 Append (or prepend) this object to `nodes` — both orderings are valid for the frontend:
 
@@ -53,11 +35,6 @@ Append (or prepend) this object to `nodes` — both orderings are valid for the
 {
   "id": "<Stage_xxxxxx>",
   "type": "case-management:Stage",
-  "position": { "x": <computed>, "y": 200 },
-  "style": { "width": 304, "opacity": 0.8 },
-  "measured": { "width": 304, "height": 128 },
-  "width": 304,
-  "zIndex": 1001,
   "data": {
     "label": "<displayName>",
     "description": "<description from sdd.md>",
@@ -70,60 +47,13 @@ Append (or prepend) this object to `nodes` — both orderings are valid for the
 }
 ```
 
-**Do not initialize `entryConditions` or `exitConditions` on a regular Stage at creation time.** Regular stages acquire those keys later when the condition plugins (stage-entry-conditions / stage-exit-conditions) write them — do not create the keys here.
-
-## Recipe — Regular Stage (v20)
+> **`parentElement.id` stays `"root"`** even though there is no `"root"` node on disk. The literal `"root"` is canvas-side — `transformCaseInMemoryJsonToDiskJson` keeps the reference intact.
 
-**Strip all node-level layout fields per Rule 19.** No `position`, `style`, `measured`, `width`, `height`, `zIndex`. No position math. FE auto-layouts on canvas load.
-
-```json
-{
-  "id": "<Stage_xxxxxx>",
-  "type": "case-management:Stage",
-  "data": {
-    "label": "<displayName>",
-    "description": "<description from sdd.md>",
-    "isRequired": <true|false from sdd.md; false if unspecified>,
-    "parentElement": { "id": "root", "type": "case-management:root" },
-    "isInvalidDropTarget": false,
-    "isPendingParent": false,
-    "tasks": []
-  }
-}
-```
-
-> **`parentElement.id` stays `"root"`** even though there is no `"root"` node in v20 disk JSON. The literal `"root"` is canvas-side — `transformCaseInMemoryJsonToDiskJson` keeps the reference intact.
-
-## Recipe — Exception Stage (v19)
-
-Same as regular v19, with `type: "case-management:ExceptionStage"` and two additional `data` fields initialized empty:
-
-```json
-{
-  "id": "<Stage_xxxxxx>",
-  "type": "case-management:ExceptionStage",
-  "position": { "x": <computed>, "y": 200 },
-  "style": { "width": 304, "opacity": 0.8 },
-  "measured": { "width": 304, "height": 128 },
-  "width": 304,
-  "zIndex": 1001,
-  "data": {
-    "label": "<displayName>",
-    "description": "<description from sdd.md>",
-    "isRequired": <true|false from sdd.md; false if unspecified>,
-    "parentElement": { "id": "root", "type": "case-management:root" },
-    "isInvalidDropTarget": false,
-    "isPendingParent": false,
-    "tasks": [],
-    "entryConditions": [],
-    "exitConditions": []
-  }
-}
-```
+**Do not initialize `entryConditions` or `exitConditions` on a regular Stage at creation time.** Regular stages acquire those keys later when the condition plugins (stage-entry-conditions / stage-exit-conditions) write them — do not create the keys here.
 
-## Recipe — Exception Stage (v20)
+## Recipe — Exception Stage
 
-Same as regular v20 (no layout fields), with `type: "case-management:ExceptionStage"` and two additional `data` fields initialized empty:
+Same as regular Stage, with `type: "case-management:ExceptionStage"` and two additional `data` fields initialized empty:
 
 ```json
 {
@@ -155,8 +85,7 @@ After writing, confirm:
 - `nodes[].type` is `case-management:Stage` or `case-management:ExceptionStage` per the intended kind
 - `nodes[].data.label` matches the T-entry's displayName
 - `nodes[].data.isRequired` is present and boolean
-- **v19 only:** all render fields (`position`, `style`, `measured`, `width`, `zIndex`, `data.parentElement`, `data.isInvalidDropTarget`, `data.isPendingParent`) are present
-- **v20 only:** NO `position`, `style`, `measured`, `width`, `height`, `zIndex` at the node level (Rule 19). Only `data.parentElement`, `data.isInvalidDropTarget`, `data.isPendingParent` remain
+- NO `position`, `style`, `measured`, `width`, `height`, `zIndex` at the node level (Rule 18). Only `data.parentElement`, `data.isInvalidDropTarget`, `data.isPendingParent` remain
 - For ExceptionStage: `data.entryConditions: []` and `data.exitConditions: []` are present (initialized as empty arrays at creation time)
 - For regular Stage at creation time: `data.entryConditions` / `data.exitConditions` are absent — the conditions plugins will create and populate them later if the sdd.md calls for it
 

package/skills/uipath-maestro-case/references/plugins/stages/planning.md

@@ -1,6 +1,6 @@
 # stages — Planning
 
-A stage node inside the case. Stages contain tasks and connect via edges. Two variants (`stage` and `exception`) share the same plugin.
+A stage node inside the case. Stages contain tasks and connect via entry/exit conditions (edges are retired). Two variants (`stage` and `exception`) share the same plugin.
 
 ## Terminology
 
@@ -26,21 +26,14 @@ Otherwise default to a regular stage.
 
 When ambiguous, use **AskUserQuestion** with both options + "Something else".
 
-### Wiring constraints for exception / secondary stages
+### Wiring constraints (reachability — edges retired)
 
-Exception stages **have no edges** — neither inbound nor outbound. They are fully detached from the edge graph:
+No stage of either variant has edges. Reachability is expressed entirely through stage entry/exit conditions:
 
-- ❌ No edge into an exception stage (not from Triggers, not from regular stages, not from other exception stages).
-- ❌ No edge out of an exception stage to any stage.
-- ✅ **Reached via an interrupting entry condition** on the exception stage itself (fires based on case state, not by traversing an edge). See [stage-entry-conditions plugin](../conditions/stage-entry-conditions/planning.md).
-- ✅ **Exits via a `return-to-origin` exit condition** — routes the case back to the stage it came from, through the exit condition rule, not a new edge. See [stage-exit-conditions plugin](../conditions/stage-exit-conditions/planning.md).
+- **Regular stage** — reached via a **non-interrupting** entry condition: `case-entered` for the first stage, or `selected-stage-completed` / `selected-stage-exited` naming a predecessor. Every regular stage MUST have ≥1 entry condition, or it is orphaned and unreachable. See [stage-entry-conditions plugin](../conditions/stage-entry-conditions/planning.md).
+- **Exception / secondary stage** — reached via an **interrupting** entry condition (fires on case state), and exits via a `return-to-origin` exit condition back to the stage it came from. See [stage-exit-conditions plugin](../conditions/stage-exit-conditions/planning.md).
 
-If the sdd.md describes an exception stage that is connected to other stages via edges, or that flows onward to another stage, flag this to the user. Options:
-
-- Re-model the node as a regular stage (so edges are allowed).
-- Use a `return-to-origin` exit and let the origin stage's existing edges handle the onward flow.
-
-This constraint is also documented in the [edges plugin](../edges/planning.md).
+Do NOT create edges for any stage. If the sdd.md describes a stage "connected via an arrow / edge" to another, model it as the target stage's entry condition (plus a source-stage exit condition when the source diverges). Onward flow from an exception stage uses `return-to-origin`, letting the origin stage's own entry/exit conditions carry the case forward.
 
 ## Required Fields from sdd.md
 
@@ -71,7 +64,7 @@ Stage position is auto-computed by the impl-json recipe: `x = 100 + (existingSta
 
 ## Ordering
 
-Stages are created **after** the root case (T01) and **before** any edges, tasks, or conditions reference them. Each stage write produces a `StageId` — capture it in the planning/execution capture map. Downstream T-entries (edges, tasks, conditions, SLA) use the stage **name** in `tasks.md`; the implementation phase resolves the name to the captured `StageId`.
+Stages are created **after** the root case (T01) and **before** any tasks or conditions reference them. Each stage write produces a `StageId` — capture it in the planning/execution capture map. Downstream T-entries (tasks, conditions, SLA) use the stage **name** in `tasks.md`; the implementation phase resolves the name to the captured `StageId`.
 
 ## tasks.md Entry Format
 

package/skills/uipath-maestro-case/references/plugins/tasks/agent/impl-json.md

@@ -42,7 +42,7 @@ Read [bindings/impl-json.md § Full binding shape — non-connector tasks](../..
 
 - `resource`: `"process"`
 - `resourceSubType`: `"Agent"`
-- `name` / `folderPath` defaults: from `tasks.md` `name` / `folder-path` fields
+- `name` / `folderPath` defaults: from `tasks.md` `name` / `folder-path` fields. `folder-path` is the resolved registry `folders[0].fullyQualifiedName` (per [planning.md § Registry Resolution](planning.md#registry-resolution)) — never the raw sdd.md "Folder", which may be a parent path and faults the job at runtime.
 
 Dedup per [§ Deduplication](../../variables/bindings/impl-json.md).
 

package/skills/uipath-maestro-case/references/plugins/tasks/agent/planning.md

@@ -12,7 +12,7 @@ Pick this plugin when the sdd.md describes a task as `AGENT` — an AI agent tha
 |-------|--------|-------|
 | `display-name` | Agent Reference "Name" | Shown in the UI |
 | `name` | Agent Reference "Name" |  |
-| `folder-path` | Agent Reference "Folder" |  |
+| `folder-path` | Resolved registry `folders[0].fullyQualifiedName` (NOT the sdd.md "Folder") | Binds to `data.folderPath`; Orchestrator starts the agent here at runtime. The sdd.md "Folder" only seeds the lookup and may be a parent/truncated path. See [§ Registry Resolution](#registry-resolution). |
 | `task-type-id` | Registry resolution (below) | Enables auto-enrichment via `tasks describe` |
 | `element-id` | (optional) | Required only when the agent has multiple element bindings |
 | `inputs` | sdd.md task data mapping | See [bindings-and-expressions.md](../../../bindings-and-expressions.md) |
@@ -26,7 +26,8 @@ Pick this plugin when the sdd.md describes a task as `AGENT` — an AI agent tha
 2. **Identifier field:** `entityKey`.
 3. **Cross-type fallback.** Agents are occasionally registered in `processOrchestration-index.json` when wrapped in an agentic process — search both if the primary yields no match.
 4. **Match priority:** exact name + exact folder > exact name only.
-5. **Discover inputs/outputs** via `tasks describe` — see [bindings-and-expressions.md § Discovering output names](../../../bindings-and-expressions.md). For agents with multiple elements, also pass `--element-id` when invoking describe (see [case-commands.md § uip maestro case tasks](../../../case-commands.md)).
+5. **`folder-path` = the SELECTED entry's `folders[0].fullyQualifiedName`** (not the sdd.md "Folder" — see the field table above). Fall back to the sdd.md folder only when there is no registry match (Unresolved path).
+6. **Discover inputs/outputs** via `tasks describe` — see [bindings-and-expressions.md § Discovering output names](../../../bindings-and-expressions.md). For agents with multiple elements, also pass `--element-id` when invoking describe (see [case-commands.md § uip maestro case tasks](../../../case-commands.md)).
 
 ## Unresolved Fallback
 

package/skills/uipath-maestro-case/references/plugins/tasks/api-workflow/impl-json.md

@@ -40,7 +40,7 @@ Read [bindings/impl-json.md § Full binding shape — non-connector tasks](../..
 
 - `resource`: `"process"`
 - `resourceSubType`: `"Api"`
-- `name` / `folderPath` defaults: from `tasks.md` `name` / `folder-path` fields
+- `name` / `folderPath` defaults: from `tasks.md` `name` / `folder-path` fields. `folder-path` is the resolved registry `folders[0].fullyQualifiedName` (per [planning.md § Registry Resolution](planning.md#registry-resolution)) — never the raw sdd.md "Folder", which may be a parent path and faults the job at runtime.
 
 Dedup per [§ Deduplication](../../variables/bindings/impl-json.md).
 

package/skills/uipath-maestro-case/references/plugins/tasks/api-workflow/planning.md

@@ -12,7 +12,7 @@ Pick this plugin when the sdd.md labels a task as `API_WORKFLOW` — typically a
 |-------|--------|-------|
 | `display-name` | API Workflow Reference "Name" | |
 | `name` | API Workflow Reference "Name" |  |
-| `folder-path` | API Workflow Reference "Folder" |  |
+| `folder-path` | Resolved registry `folders[0].fullyQualifiedName` (NOT the sdd.md "Folder") | Binds to `data.folderPath`; Orchestrator starts the workflow here at runtime. The sdd.md "Folder" only seeds the lookup and may be a parent/truncated path. See [§ Registry Resolution](#registry-resolution). |
 | `task-type-id` | Registry resolution (below) | `entityKey` in `api-index.json` |
 | `inputs` | sdd.md task data mapping | See [bindings-and-expressions.md](../../../bindings-and-expressions.md) |
 | `outputs` | Discovered via `tasks describe` | |
@@ -24,7 +24,8 @@ Pick this plugin when the sdd.md labels a task as `API_WORKFLOW` — typically a
 1. **Primary cache file:** `api-index.json`.
 2. **Identifier field:** `entityKey`.
 3. Match by exact name + folder.
-4. Discover inputs/outputs via `tasks describe` — see [bindings-and-expressions.md § Discovering output names](../../../bindings-and-expressions.md).
+4. **`folder-path` = the SELECTED entry's `folders[0].fullyQualifiedName`** (not the sdd.md "Folder" — see the field table above). Fall back to the sdd.md folder only when there is no registry match (Unresolved path).
+5. Discover inputs/outputs via `tasks describe` — see [bindings-and-expressions.md § Discovering output names](../../../bindings-and-expressions.md).
 
 ## Unresolved Fallback
 

package/skills/uipath-maestro-case/references/plugins/tasks/case-management/impl-json.md

@@ -40,7 +40,7 @@ Read [bindings/impl-json.md § Full binding shape — non-connector tasks](../..
 
 - `resource`: `"process"`
 - `resourceSubType`: `"CaseManagement"`
-- `name` / `folderPath` defaults: from `tasks.md` `name` / `folder-path` fields
+- `name` / `folderPath` defaults: from `tasks.md` `name` / `folder-path` fields. `folder-path` is the resolved registry `folders[0].fullyQualifiedName` (per [planning.md § Registry Resolution](planning.md#registry-resolution)) — never the raw sdd.md "Folder", which may be a parent path and faults the job at runtime.
 
 Dedup per [§ Deduplication](../../variables/bindings/impl-json.md).
 

package/skills/uipath-maestro-case/references/plugins/tasks/case-management/planning.md

@@ -9,7 +9,7 @@ Pick this plugin when the sdd.md describes a task that spawns or delegates to an
 - Parent case orchestrates multiple sub-cases
 - Long-running sub-workflow packaged as its own case
 
-If sdd.md describes a simple stage-to-stage flow within the same case, do not use this — use regular stages and edges.
+If sdd.md describes a simple stage-to-stage flow within the same case, do not use this — use regular stages wired by entry/exit conditions.
 
 ## Required Fields from sdd.md
 
@@ -17,7 +17,7 @@ If sdd.md describes a simple stage-to-stage flow within the same case, do not us
 |-------|--------|-------|
 | `display-name` | Case Reference "Name" | |
 | `name` | Case Reference "Name" | |
-| `folder-path` | Case Reference "Folder" | |
+| `folder-path` | Resolved registry `folders[0].fullyQualifiedName` (NOT the sdd.md "Folder") | Binds to `data.folderPath`; Orchestrator starts the sub-case here at runtime. The sdd.md "Folder" only seeds the lookup and may be a parent/truncated path. See [§ Registry Resolution](#registry-resolution). |
 | `task-type-id` | Registry resolution (below) | `entityKey` in `caseManagement-index.json` |
 | `inputs` | sdd.md task data mapping | Passed as case-instance inputs to the sub-case |
 | `outputs` | Discovered via `tasks describe` | Returned when the sub-case completes |
@@ -29,7 +29,8 @@ If sdd.md describes a simple stage-to-stage flow within the same case, do not us
 1. **Primary cache file:** `caseManagement-index.json`.
 2. **Identifier field:** `entityKey`.
 3. Match by exact name + folder.
-4. Discover inputs/outputs via `tasks describe` — see [bindings-and-expressions.md § Discovering output names](../../../bindings-and-expressions.md).
+4. **`folder-path` = the SELECTED entry's `folders[0].fullyQualifiedName`** (not the sdd.md "Folder" — see the field table above). Fall back to the sdd.md folder only when there is no registry match (Unresolved path).
+5. Discover inputs/outputs via `tasks describe` — see [bindings-and-expressions.md § Discovering output names](../../../bindings-and-expressions.md).
 
 ## Unresolved Fallback
 

package/skills/uipath-maestro-case/references/plugins/tasks/connector-activity/impl-json.md

@@ -247,7 +247,7 @@ All issues appended to the shared issue list per [logging/impl-json.md](../../lo
 7. Root bindings exist for ConnectionId + folderKey with the minted ids
 8. `data.bindings[]` is empty `[]`
 9. Each entry in `data.inputs[]` and `data.outputs[]` has `var` / `id` / `elementId` minted (uniqueness rule applied for outputs)
-10. `bindings_v2.json` `resources` array matches the schema-appropriate bindings array (v19: `root.data.uipath.bindings[]`; v20: top-level `bindings[]`) after the deferred sync
+10. `bindings_v2.json` `resources` array matches top-level `bindings[]` after the deferred sync
 11. **No literal `[*]` keys in `data.inputs[name="body"].body` (or any input body).** Scan recursively (JSON.stringify + regex `"[^"]*\\[\\*\\][^"]*"\\s*:`). If any key contains literal `[*]`, halt — Step 1.b translation was skipped or incomplete. The body MUST use real arrays under parent names (e.g., `"toRecipients": [{...}]`), never `"toRecipients[*]": {...}`. Validate passes regardless; runtime APIs reject with HTTP 400.
 
 ## What NOT to Do
@@ -268,4 +268,4 @@ All issues appended to the shared issue list per [logging/impl-json.md](../../lo
 
 ## Known Limitations
 
-- The CLI-produced `essentialConfiguration` uses `essentialConfiguration` only (not `optionalConfiguration`). Tasks work at runtime (debug/publish) but the FE editor may not render certain fields until the user re-configures the task in the UI. DAP repopulates these on form open. Documented in `~/Documents/knowledge/Skill_CLI/connector/case-spec-fe-discrepancies.md` (CLI-side).
+- The CLI-produced `essentialConfiguration` uses `essentialConfiguration` only (not `optionalConfiguration`). Tasks work at runtime (debug/publish) but the FE editor may not render certain fields until the user re-configures the task in the UI. DAP repopulates these on form open.

package/skills/uipath-maestro-case/references/plugins/tasks/connector-activity/planning.md

@@ -22,6 +22,8 @@ If `~/.uip/case-resources/typecache-activities-index.json` does not exist, run `
 
 Read `~/.uip/case-resources/typecache-activities-index.json` directly. Match on `displayName` or `connectorKey` + operation description from sdd.md. Record `uiPathActivityTypeId`.
 
+**No match (Scenario A — connector not found).** A 0-match inside the existing cache is gated by Rule 17 — run the [registry-discovery.md § MUST Confirm Before Placeholder Fallback](../../../registry-discovery.md#must-confirm-before-placeholder-fallback) AskUserQuestion (`Force pull` / `Skip and use placeholders`) for the lookup batch before any fallback. Only after the user picks `Skip`: mark `type-id` `<UNRESOLVED: no typecache activity for <query>>`, skip § 2 (no `activity-type-id` to pass to `get-connection`), and fall through to § Unresolved Fallback (placeholder task, `data: {}`). Continue planning — do not halt ([planning.md § 3.4](../../../planning.md)).
+
 ### 2. Resolve the connection
 
 ```bash
@@ -30,15 +32,16 @@ uip maestro case registry get-connection \
   --activity-type-id "<uiPathActivityTypeId>" --output json
 ```
 
-Returns `Entry`, `Config`, and `Connections`.
+Returns `Entry`, `Config`, and `Connections`. If the sdd.md names a connection, match it by `name` and use it directly. Otherwise **always present the choice via AskUserQuestion — do not auto-select**, even when one connection exists:
 
-- **Single connection** → use it.
-- **Multiple connections** → **AskUserQuestion** with connection names + "Something else".
-- **Empty `Connections`** → mark `<UNRESOLVED: no IS connection for <connectorKey>>` and omit `input-values:`. Execution creates a placeholder task — see [placeholder-tasks.md](../../../placeholder-tasks.md).
+- **`Connections` non-empty** → list connections by `name` **plus a "Create a new connection" option**.
+- **`Connections` empty** → offer **Create a new connection** / **Skip (defer)**.
+- **Create chosen** → create it (background `is connections create`, capture `ConnectionId`), then continue with the new id. Procedure: [connector-integration.md § Creating a Connection](../../../connector-integration.md#creating-a-connection).
+- **Skip / create fails** → mark `<UNRESOLVED: no IS connection for <connectorKey>>` and omit `input-values:` ([§ Unresolved Fallback](#unresolved-fallback)).
 
-Record `connection-id`, `connector-key`, `object-name` from the response.
+Record `connection-id`, `connector-key`, `object-name` from the response (or from the create output).
 
-Connection selection rules (default-preference, `--refresh` retry, multi-connection disambiguation, ping verification, BYOA workflow): see [/uipath:uipath-platform — connections.md](../../../../../uipath-platform/references/integration-service/connections.md).
+Connection selection mechanics (`--refresh` retry, ping verification, BYOA workflow, connection creation): see [/uipath:uipath-platform — connections.md](../../../../../uipath-platform/references/integration-service/connections.md).
 
 ### 3. Discover the operation contract via `case spec`
 
@@ -116,7 +119,7 @@ Values can be:
 - **Pre-wrapped operator expressions** — `=js:(vars.amount > 5000)` (already canonical — pass-through)
 - **Cross-task refs** — `<- "Stage"."Task".output` (impl resolves to `=vars.<outputVar>` then wraps)
 
-> **tasks.md carries SDD-natural form.** The implementation step (Step 9.7 of connector-activity impl) rewrites every reference to its canonical sink form when constructing `--input-details`. Connector body sinks use `=js:(<expr>)`. Full rule: [bindings-and-expressions.md § Canonical form per sink](../../../../bindings-and-expressions.md#canonical-form-per-sink).
+> **tasks.md carries SDD-natural form.** The implementation step (Step 9.7 of connector-activity impl) rewrites every reference to its canonical sink form when constructing `--input-details`. Connector body sinks use `=js:(<expr>)`. Full rule: [bindings-and-expressions.md § Canonical form per sink](../../../bindings-and-expressions.md#canonical-form-per-sink).
 
 ### 7. Optional — author a server-side filter
 
@@ -194,6 +197,8 @@ Planner emits to `tasks.md input-values.bodyParameters`:
 
 ## Unresolved Fallback
 
+Two entry paths: **Scenario A** — connector not found in TypeCache ([§ 1 No-match](#1-find-the-connector-in-typecache), after the Rule 17 gate); **Scenario B** — connector found but connection unresolved, only after the Step 2 create offer is **declined** or fails (or the run is non-interactive). When `Connections` is empty, offer to create one first (Step 2) — do not jump straight here.
+
 > **Rule 17 exception.** Empty `Connections` from `get-connection` (the connector activity exists in typecache but no IS connection is registered) does NOT require the Rule 17 gate — proceed directly to placeholder.
 
 If the connector or connection cannot be resolved:

package/skills/uipath-maestro-case/references/plugins/tasks/connector-trigger/impl-json.md

@@ -128,4 +128,4 @@ All issues appended to the shared issue list per [logging/impl-json.md](../../lo
 4. When the trigger has event parameters: `data.context[name="metadata"].body.bindings[Property].metadata.ParentResourceKey` is `EventTrigger.<eventTriggerKey>` (substituted from `EventTrigger.{{TRIGGER_REGISTRATION_KEY}}`)
 5. Root bindings exist for ConnectionId + folderKey with the minted ids; `data.bindings[]` is empty `[]`
 6. Each entry in `data.inputs[]` / `data.outputs[]` has `var` / `id` / `elementId` minted; uniqueness rule applied for outputs
-7. `bindings_v2.json` `resources` array matches the schema-appropriate bindings array (v19: `root.data.uipath.bindings[]`; v20: top-level `bindings[]`) after the deferred sync
+7. `bindings_v2.json` `resources` array matches top-level `bindings[]` after the deferred sync

package/skills/uipath-maestro-case/references/plugins/tasks/connector-trigger/planning.md

@@ -43,6 +43,8 @@ Follow the pipeline in [connector-trigger-common.md § Planning Pipeline](../../
 
 ## Unresolved Fallback
 
+Two entry paths: **Scenario A** — connector not found in TypeCache ([connector-trigger-common.md § 1 No-match](../../../connector-trigger-common.md#1-find-the-trigger-in-typecache), after the Rule 17 gate); **Scenario B** — connector found but connection unresolved, only after the create offer ([connector-trigger-common.md § Resolve the connection](../../../connector-trigger-common.md#2-resolve-the-connection)) is **declined** or fails. When `Connections` is empty, offer to create one first — do not jump straight here.
+
 > **Rule 17 exception.** Empty `Connections` from `get-connection` (the connector trigger exists in typecache but no IS connection is registered) does NOT require the Rule 17 gate — proceed directly to placeholder.
 
 If the connector or connection cannot be resolved:

package/skills/uipath-maestro-case/references/plugins/tasks/process/impl-json.md

@@ -40,7 +40,7 @@ Read [bindings/impl-json.md § Full binding shape — non-connector tasks](../..
 
 - `resource`: `"process"`
 - `resourceSubType`: `"ProcessOrchestration"`
-- `name` / `folderPath` defaults: from `tasks.md` `name` / `folder-path` fields
+- `name` / `folderPath` defaults: from `tasks.md` `name` / `folder-path` fields. `folder-path` is the resolved registry `folders[0].fullyQualifiedName` (per [planning.md § Registry Resolution](planning.md#registry-resolution)) — never the raw sdd.md "Folder", which may be a parent path and faults the job at runtime.
 
 Dedup per [§ Deduplication](../../variables/bindings/impl-json.md).
 

package/skills/uipath-maestro-case/references/plugins/tasks/process/planning.md

@@ -18,7 +18,7 @@ For RPA robot tasks specifically, prefer [rpa](../rpa/planning.md). For Coded wo
 |-------|--------|-------|
 | `display-name` | Process Reference "Name" | Shown in the UI |
 | `name` | Process Reference "Name" |  |
-| `folder-path` | Process Reference "Folder" | Required for disambiguation. |
+| `folder-path` | Resolved registry `folders[0].fullyQualifiedName` (NOT the sdd.md "Folder") | This is the binding's `folderPath` default — Orchestrator starts the job here at runtime. The sdd.md "Folder" only seeds the registry lookup; it may be a parent/truncated path. See [§ Registry Resolution](#registry-resolution). |
 | `task-type-id` | Registry resolution (see below) | Enables auto-enrichment via `tasks describe`. |
 | `inputs` | sdd.md task data mapping | See [bindings-and-expressions.md](../../../bindings-and-expressions.md) |
 | `outputs` | Discovered via `tasks describe` | Listed for downstream cross-task references |
@@ -31,7 +31,8 @@ For RPA robot tasks specifically, prefer [rpa](../rpa/planning.md). For Coded wo
 2. **Identifier field:** `entityKey`.
 3. **Cross-type fallback.** If the primary cache file has no match, search both files — the sdd.md label is not authoritative. A process registered as `process` may be mislabeled `AGENTIC_PROCESS` in sdd.md and vice versa.
 4. **Match priority:** exact name + exact folder > exact name, multiple folders (pick matching) > exact name only > no match.
-5. **Discover inputs/outputs:** after resolving the `entityKey`, fetch the input/output schema via `tasks describe` — see [bindings-and-expressions.md § Discovering output names](../../../bindings-and-expressions.md). Record input names, types, and output names. Unrecognized inputs in sdd.md → ask the user (**AskUserQuestion** with matching field names + "Something else").
+5. **`folder-path` = the SELECTED entry's `folders[0].fullyQualifiedName`** (not the sdd.md "Folder" — see the field table above). Fall back to the sdd.md folder only when there is no registry match (Unresolved path).
+6. **Discover inputs/outputs:** after resolving the `entityKey`, fetch the input/output schema via `tasks describe` — see [bindings-and-expressions.md § Discovering output names](../../../bindings-and-expressions.md). Record input names, types, and output names. Unrecognized inputs in sdd.md → ask the user (**AskUserQuestion** with matching field names + "Something else").
 
 ## Unresolved Fallback
 
@@ -40,7 +41,7 @@ If no match is found across both cache files after `registry pull`:
 - Mark the task line: `<UNRESOLVED: process "<name>" in folder "<folder>" not found in registry>`
 - Omit `inputs:` and `outputs:`; capture intended wiring in a fenced ```` ```text ```` code block (not `#` prefixed — it renders as markdown H1).
 - Continue planning for remaining tasks.
-- Execution creates a placeholder task (no `data.context.taskTypeId`, no bindings). See [placeholder-tasks.md](../../../placeholder-tasks.md).
+- Execution creates a placeholder task (empty `data: {}`, no bindings). See [placeholder-tasks.md](../../../placeholder-tasks.md).
 
 ## tasks.md Entry Format
 

package/skills/uipath-maestro-case/references/plugins/tasks/rpa/impl-json.md

@@ -41,7 +41,7 @@ Read [bindings/impl-json.md § Full binding shape — non-connector tasks](../..
 
 - `resource`: `"process"`
 - `resourceSubType`: omit (no resourceSubType for rpa tasks)
-- `name` / `folderPath` defaults: from `tasks.md` `name` / `folder-path` fields
+- `name` / `folderPath` defaults: from `tasks.md` `name` / `folder-path` fields. `folder-path` is the resolved registry `folders[0].fullyQualifiedName` (per [planning.md § Registry Resolution](planning.md#registry-resolution)) — never the raw sdd.md "Folder", which may be a parent path and faults the job at runtime.
 
 Dedup per [§ Deduplication](../../variables/bindings/impl-json.md).