@uipath/skills 1.195.0 → 1.196.0

package/skills/uipath-maestro-case/references/case-schema.md

@@ -2,24 +2,12 @@
 
 Structural reference for the case definition JSON. Shared across all node types. Per-task-type and per-condition-type field shapes live in each plugin's `impl-json.md`.
 
-> **Bilingual.** Top-level shape differs between v19 (default) and v20 (opt-in per SKILL.md Rule 18). Per-node and per-edge internal shapes are **identical** across schemas — only the wrapper changes. See § Top-level shape (v19) and § Top-level shape (v20) below.
-
-## Top-level shape (v19 — default)
-
-```json
-{
-  "root": { ... },
-  "nodes": [ ... ],
-  "edges": [ ... ]
-}
-```
-
-## Top-level shape (v20 — opt-in)
+## Top-level shape
 
 ```json
 {
   "id": "case-aBcDeFgHiJ",
-  "version": "20.0.0",
+  "version": "23.0.0",
   "name": "<case name>",
   "description": "<optional>",
   "metadata": {
@@ -28,6 +16,7 @@ Structural reference for the case definition JSON. Shared across all node types.
     "caseAppEnabled": false,
     "publishVersion": 2,
     "caseUnifiedSchemaEnabled": true,
+    "caseDirectlyPassTaskOutputs": true,
     "intsvcActivityConfig": "v2",
     "slaRules": [ ... ],
     "caseExitRules": [ ... ]
@@ -35,44 +24,16 @@ Structural reference for the case definition JSON. Shared across all node types.
   "bindings": [ ... ],
   "variables": { "inputs": [], "outputs": [], "inputOutputs": [] },
   "nodes": [ ... ],
-  "edges": [ ... ],
+  "edges": [],
   "layout": {}
 }
 ```
 
-### v19 → v20 field mapping
-
-| v19 path | v20 path |
-|---|---|
-| `root.id` (literal `"root"`) | top-level `id` (`case-<10>` generated) |
-| `root.name` | top-level `name` |
-| `root.description` | top-level `description` |
-| `root.caseIdentifier` | `metadata.caseIdentifier` |
-| `root.caseIdentifierType` | `metadata.caseIdentifierType` |
-| `root.caseAppEnabled` | `metadata.caseAppEnabled` |
-| `root.publishVersion` | `metadata.publishVersion` |
-| `root.caseUnifiedSchemaEnabled` | `metadata.caseUnifiedSchemaEnabled` |
-| `root.caseAppConfig` | `metadata.caseAppConfig` |
-| `root.allowAdhocOptionalStageTasks` | `metadata.allowAdhocOptionalStageTasks` |
-| `root.caseExecutionIncludesDebugVariables` | `metadata.caseExecutionIncludesDebugVariables` |
-| `root.caseExecutionUsesSyncCaseTasks` | `metadata.caseExecutionUsesSyncCaseTasks` |
-| `root.caseBpmnUseNewGlobalVariables` | `metadata.caseBpmnUseNewGlobalVariables` |
-| `root.waitForHumanSelectNextStageDFConnector` | `metadata.waitForHumanSelectNextStageDFConnector` |
-| `root.version` (`"v19"`) | top-level `version` (`"20.0.0"`) |
-| `root.data.slaRules` | `metadata.slaRules` |
-| `root.data.uipath.bindings` | top-level `bindings` |
-| `root.data.uipath.variables` | top-level `variables` |
-| `root.caseExitConditions` | `metadata.caseExitRules` *(field renamed)* |
-| `root.data.intsvcActivityConfig` | `metadata.intsvcActivityConfig` |
-| `nodes` | `nodes` *(unchanged shape — see § 2 below)* |
-| `edges` | `edges` *(unchanged shape — see § 3 below)* |
-| — | `layout: {}` *(new top-level — see § 7 below)* |
-
-### v20 layout-strip (Rule 19)
-
-In v20, node-level layout fields move to a top-level `layout` block. The frontend transformer `transformCaseInMemoryJsonToDiskJson.ts` does this stripping when round-tripping through canvas; skill emits clean nodes from the start.
-
-**Stripped from each node** (skill MUST NOT emit in v20):
+### Layout-strip (Rule 18)
+
+Node-level layout fields move to a top-level `layout` block. The frontend transformer `transformCaseInMemoryJsonToDiskJson.ts` does this stripping when round-tripping through canvas; skill emits clean nodes from the start.
+
+**Stripped from each node** (skill MUST NOT emit):
 - `position`
 - `style`
 - `measured`
@@ -80,13 +41,11 @@ In v20, node-level layout fields move to a top-level `layout` block. The fronten
 - `height`
 - `zIndex`
 
-**Stripped from each edge** (skill MUST NOT emit in v20):
+**Stripped from each edge** (skill MUST NOT emit):
 - `data.waypoints`
 
 **Lifted to** `layout.nodes[<nodeId>] = { position, style, measured, width, height }` and `layout.edges[<edgeId>] = { waypoints }` — but skill emits empty `layout: {}` because FE auto-layouts on canvas load. Skill is not a layout authority.
 
-**v19 mode preserves all current render-field rules** — see [`case-editing-operations.md`](case-editing-operations.md) Pre-flight Checklist Items 3, 4.
-
 ---
 
 **ID format (cross-cutting).** All generated IDs follow the CLI's `prefixedId(prefix, count)` scheme: a fixed prefix followed by `count` random characters from `[A-Za-z0-9]`. Direct-JSON-write must use the same format — the frontend's `generateNextId(prefix, count)` depends on it.
@@ -95,7 +54,6 @@ In v20, node-level layout fields move to a top-level `layout` block. The fronten
 |---|---|---|---|
 | Stage (regular + exception) | `Stage_` | 6 | `Stage_aB3kL9` |
 | Trigger (added after initial) | `trigger_` | 6 | `trigger_xY2mNp` |
-| Edge | `edge_` | 6 | `edge_Qz7hVr` |
 | Task | `t` | 8 | `t8GQTYo8O` |
 | Task entry condition | `c` | 8 | `c4fGhJ2Mn` |
 | Task entry rule | `r` | 8 | `rK9xQw3Lp` |
@@ -107,57 +65,54 @@ In v20, node-level layout fields move to a top-level `layout` block. The fronten
 
 ---
 
-## 1. root (v19) / top-level + metadata (v20)
+## 1. Top-level + metadata
 
-Metadata and configuration for the case definition. **v19** wraps everything under `root`; **v20** flattens to top-level + `metadata` block per the field-mapping table above. Field semantics are identical — only locations change.
+Metadata and configuration for the case definition. Top-level fields (`id`, `version`, `name`, `description`) sit alongside the `metadata` block.
 
 ```json
 {
-  "id": "<shortId>",
+  "id": "case-aBcDeFgHiJ",
+  "version": "23.0.0",
   "name": "Loan Approval",
-  "type": "case-management:root",
-  "caseIdentifier": "LOAN",
-  "caseAppEnabled": false,
-  "caseIdentifierType": "constant",
-  "version": "v19",
-  "publishVersion": 2,
-  "data": {
+  "description": "case description",
+  "metadata": {
+    "caseIdentifier": "LOAN",
+    "caseIdentifierType": "constant",
+    "caseAppEnabled": false,
+    "publishVersion": 2,
+    "caseUnifiedSchemaEnabled": true,
+    "caseDirectlyPassTaskOutputs": true,
+    "intsvcActivityConfig": "v2",
     "slaRules": [
       { "expression": "=js:true", "count": 5, "unit": "d" }
     ],
-    "intsvcActivityConfig": "v2",
-    "uipath": {
-      "bindings": [],
-      "variables": { "inputs": [], "outputs": [], "inputOutputs": [] }
-    }
-  },
-  "caseExitConditions": [],
-  "description": "case description"
+    "caseExitRules": []
+  }
 }
 ```
 
 | Field | Type | Description |
 |-------|------|-------------|
-| `id` | string | Unique ID (auto-generated) |
+| `id` | string | Unique ID, `case-` + 10 random chars (auto-generated) |
+| `version` | string | Schema version — `"23.0.0"`. Emitted by the `case` plugin at T01. |
 | `name` | string | Human-readable name |
-| `type` | `"case-management:root"` | Literal — do not change |
-| `caseIdentifier` | string | Runtime identifier. `constant` → literal prefix. `external` → `=`-prefixed expression. See § Case identifier below. |
-| `caseIdentifierType` | `"constant"` \| `"external"` | Selects how `caseIdentifier` is read. Default `constant`. |
-| `caseAppEnabled` | boolean | Whether the Case App UI is enabled |
-| `version` | string | Schema version — `"v19"` for current schema. Emitted by the `case` plugin at T01. |
-| `publishVersion` | number? | Publish version — `2` for current schema |
-| `data.slaRules` | SlaRuleEntry[]? | Conditional + default SLA rules for the case. Default SLA lives here as the trailing entry with `expression: "=js:true"`. Escalations attach inside each rule's `escalationRule[]`. See §6. |
-| `data.intsvcActivityConfig` | string? | Integration-service activity configuration payload |
-| `data.uipath` | object? | Variable and binding declarations |
-| `caseExitConditions` | CaseExitCondition[]? | Conditions that mark the case as complete |
 | `description` | string? | Case description |
+| `metadata.caseIdentifier` | string | Runtime identifier. `constant` → literal prefix. `external` → `=`-prefixed expression. See § Case identifier below. |
+| `metadata.caseIdentifierType` | `"constant"` \| `"external"` | Selects how `caseIdentifier` is read. Default `constant`. |
+| `metadata.caseAppEnabled` | boolean | Whether the Case App UI is enabled |
+| `metadata.publishVersion` | number? | Publish version — `2` for current schema |
+| `metadata.caseUnifiedSchemaEnabled` | boolean? | Unified-schema flag (`true`) |
+| `metadata.caseDirectlyPassTaskOutputs` | boolean? | Passes task outputs directly through messages instead of shared variables, fixing race conditions on task outputs in cases with parallel tasks. Schema-optional, defaults `true` when absent; skill emits the T01 `directly-pass-task-outputs` value (`true` unless sdd.md requested `false`). |
+| `metadata.intsvcActivityConfig` | string? | Integration-service activity configuration payload |
+| `metadata.slaRules` | SlaRuleEntry[]? | Conditional + default SLA rules for the case. Default SLA lives here as the trailing entry with `expression: "=js:true"`. Escalations attach inside each rule's `escalationRule[]`. See §6. |
+| `metadata.caseExitRules` | CaseExitCondition[]? | Conditions that mark the case as complete |
 
 ### Case identifier (constant vs external)
 
 `caseIdentifierType` picks how `caseIdentifier` resolves at runtime:
 
 - **`constant`** (default) — `caseIdentifier` is a literal 2-4 char prefix (`"LOAN"`). Runtime emits the case external id as `<prefix>-<generated>`.
-- **`external`** — `caseIdentifier` is a `=`-prefixed expression (bare `=vars.<id>` or `=js:<expr>`). Runtime evaluates it; the result becomes the case external id verbatim (no prefix). Same `=vars.<id>` / `=js:` convention as [bindings-and-expressions.md](bindings-and-expressions.md) — no other engine. v20: field lives under `metadata` (see field-mapping table). Authoring forms + variable eligibility: [`plugins/case/planning.md` § External identifier value](plugins/case/planning.md).
+- **`external`** — `caseIdentifier` is a `=`-prefixed expression (bare `=vars.<id>` or `=js:<expr>`). Runtime evaluates it; the result becomes the case external id verbatim (no prefix). Same `=vars.<id>` / `=js:` convention as [bindings-and-expressions.md](bindings-and-expressions.md) — no other engine. Field lives under `metadata`. Authoring forms + variable eligibility: [`plugins/case/planning.md` § External identifier value](plugins/case/planning.md).
 
 ### CaseExitCondition
 
@@ -184,7 +139,6 @@ Entry point. Written by the triggers plugin at T02. Exactly one per case (single
 {
   "id": "trigger_xY2mNp",
   "type": "case-management:Trigger",
-  "position": { "x": 200, "y": 0 },
   "data": {
     "label": "Start",
     "uipath": { "serviceType": "None" }
@@ -192,9 +146,7 @@ Entry point. Written by the triggers plugin at T02. Exactly one per case (single
 }
 ```
 
-`position` is fixed at `{ x: 200, y: 0 }` — not stateful like Stage.
-
-No `style`, `measured`, `width`, `zIndex`, or `parentElement` on Trigger nodes (unlike Stage).
+No `position`, `style`, `measured`, `width`, `zIndex`, or `parentElement` on Trigger nodes (Rule 18 layout-strip).
 
 `serviceType` values: `"None"`, `"Intsvc.EventTrigger"`, `"Intsvc.TimerTrigger"`. The specific binding/config shape for each trigger kind lives in the corresponding trigger plugin's `impl-json.md`.
 
@@ -208,11 +160,6 @@ Standard workflow stage. Contains tasks.
 {
   "id": "Stage_aB3kL9",
   "type": "case-management:Stage",
-  "position": { "x": 100, "y": 200 },
-  "style": { "width": 304, "opacity": 0.8 },
-  "measured": { "width": 304, "height": 128 },
-  "width": 304,
-  "zIndex": 1001,
   "data": {
     "label": "Review Application",
     "description": "...",
@@ -228,15 +175,7 @@ Standard workflow stage. Contains tasks.
 }
 ```
 
-**Top-level node fields:**
-
-| Field | Type | Description |
-|-------|------|-------------|
-| `position` | `{x,y}` | Auto-computed by CLI as `{ x: 100 + existingStageCount * 500, y: 200 }`. Direct-JSON-write must count existing stages before writing. |
-| `style` | object | Hard-coded `{ width: 304, opacity: 0.8 }`. |
-| `measured` | object | Hard-coded `{ width: 304, height: 128 }`. |
-| `width` | number | Hard-coded `304` (separate from `style.width` and `measured.width`). |
-| `zIndex` | number | Hard-coded `1001`. |
+No `position`, `style`, `measured`, `width`, `height`, or `zIndex` at the node level (Rule 18 layout-strip).
 
 **`StageNodeData` fields:**
 
@@ -245,7 +184,7 @@ Standard workflow stage. Contains tasks.
 | `label` | string? | Display label |
 | `description` | string? | Stage description |
 | `isRequired` | boolean? | Whether the stage must complete before case exit (used by case-exit rule `required-stages-completed`) |
-| `parentElement` | `{id,type}` | Always `{ id: "root", type: schema.root.type }` |
+| `parentElement` | `{id,type}` | Always `{ id: "root", type: "case-management:root" }`. The literal `"root"` is canvas-side — there is no `"root"` node on disk. |
 | `isInvalidDropTarget` | boolean | Always `false` (UI drag-drop flag) |
 | `isPendingParent` | boolean | Always `false` (UI drag-drop flag) |
 | `tasks` | Task[][] | 2D array: `tasks[lane][index]`. Default: one task per lane (`tasks[0][0]`, `tasks[1][0]`, …) so the FE lays them out in separate columns; lane is layout-only, sequencing comes from task-entry conditions. Exception: tasks in a `runs-sequentially` group that should execute in parallel share the same lane — there, shared lane carries execution semantics (parallel siblings inside the sequential group). Empty array `[]` when no tasks yet. |
@@ -254,7 +193,7 @@ Standard workflow stage. Contains tasks.
 | `exitConditions` | ExitCondition[]? | See §3. Not initialized on regular Stage creation — added later by the conditions plugins. |
 | `instanceIdPrefix` | string? | Prefix for instance IDs |
 
-> **Regular `Stage` is created without `entryConditions`/`exitConditions`.** Match this by not emitting empty arrays for those fields when writing a regular stage. They are added later by the condition plugins when entry/exit conditions are written. See §3 for the condition shapes and §2b for how edge transitions reference the source stage's `exitConditions`.
+> **Regular `Stage` is created without `entryConditions`/`exitConditions`.** Match this by not emitting empty arrays for those fields when writing a regular stage. They are added later by the condition plugins when entry/exit conditions are written. See §3 for the condition shapes. Transitions are driven entirely by these conditions — edges are retired and `edges` stays `[]` (§4).
 
 ### c) Exception Stage Node — `"case-management:ExceptionStage"`
 
@@ -328,12 +267,14 @@ All conditions share the same shape but attach at different levels. Per-level fi
 
 ### CaseExitCondition (case-level)
 
-See `root.caseExitConditions` (v19) / `metadata.caseExitRules` (v20) in §1.
+See `metadata.caseExitRules` in §1.
 
 ---
 
 ## 4. edges (two types, discriminated on `type`)
 
+> **The skill does not author edges — `edges` stays `[]`.** Stage transitions derive entirely from `entryConditions` / `exitConditions` (§3); the case start derives from the first stage's `case-entered` entry condition, not a `TriggerEdge`. The structures below are **reference-only** — the empty `edges[]` array remains in the schema for frontend compatibility, and the FE auto-derives canvas connectors from the conditions. The two edge shapes are documented here only so a canvas-round-tripped file (where the FE may have materialized edges) is still readable.
+
 ### a) TriggerEdge — `"case-management:TriggerEdge"`
 
 Connects Trigger → Stage. No rules.
@@ -388,7 +329,7 @@ Rules = Rule[][]
 
 | `rule` | Additional fields | Description |
 |--------|-------------------|-------------|
-| `wait-for-connector` | `id?`, `uipath?` (connector configuration — required for Studio Web validity; bare form is a valid deferred/placeholder state), `conditionExpression?` | Wait for an external connector event — see § Connector-bound rule below |
+| `wait-for-connector` | `id?`, `uipath` (connector config — **required**; absent → `connector activity missing`. Unresolved → **stub** placeholder, not bare — see § Placeholder fallback), `conditionExpression?` | Wait for an external connector event — see § Connector-bound rule below |
 | `case-entered` | `id?`, `conditionExpression?` | Fires when the case is first entered |
 | `selected-stage-completed` | `id?`, `selectedStageId?`, `conditionExpression?` | A specific stage has completed |
 | `selected-stage-exited` | `id?`, `selectedStageId?`, `conditionExpression?` | A specific stage has been exited |
@@ -419,7 +360,7 @@ A `wait-for-connector` rule binds an IS connector trigger under **`uipath`** —
   "id": "<ruleId>",
   "uipath": {
     "serviceType": "Intsvc.WaitForEvent",
-    "context": [ { "name": "connectorKey", "value": "<key>", "type": "string" }, { "name": "connection", "value": "=bindings.<id>", "type": "string" }, { "name": "folderKey", "value": "=bindings.<id>", "type": "string" }, { "name": "resourceKey", "value": "<connection-id>", "type": "string" }, { "name": "objectName", "value": "<object>", "type": "string" }, { "name": "metadata", "type": "json", "body": { } } ],
+    "context": [ { "name": "connectorKey", "value": "<key>", "type": "string" }, { "name": "connection", "value": "=bindings.<id>", "type": "string" }, { "name": "resourceKey", "value": "<connection-id>", "type": "string" }, { "name": "folderKey", "value": "=bindings.<id>", "type": "string" }, { "name": "method", "value": "<httpMethod>", "type": "string" }, { "name": "path", "value": "<path>", "type": "string" }, { "name": "objectName", "value": "<object>", "type": "string" }, { "name": "operation", "value": "<eventOperation>", "type": "string" }, { "name": "metadata", "type": "json", "body": { } } ],
     "inputs": [ ],
     "outputs": [ ],
     "bindings": []
@@ -428,7 +369,7 @@ A `wait-for-connector` rule binds an IS connector trigger under **`uipath`** —
 }
 ```
 
-> CLI `validate` does NOT check `rule.uipath` — the case-tool connector validator is task-only (reads `task.data`). Confirm connector rules via Studio Web.
+> Full `validate` requires `rule.uipath` + `context` (absent → `connector activity missing`); the check is satisfied by `context` entries named `connectorKey` + `operation`, and does not inspect internals (a wrong `serviceType` passes). Confirm the connector resolves via Studio Web. The exact `context` field set is CLI-emitted and varies by connector — splice it verbatim from `case spec`; the 9 fields above are illustrative of an HTTP-event connector, not a fixed schema.
 
 ---
 
@@ -441,7 +382,7 @@ All SLA data on a target (root or stage) lives in a single `slaRules[]` array. T
   {
     "expression": "=js:vars.priority === 'Urgent'",
     "count": 30,
-    "unit": "m",
+    "unit": "min",
     "escalationRule": [
       {
         "id": "esc_aB3kL9",
@@ -506,13 +447,23 @@ All tasks inside a stage share this envelope. Per-type `data` fields live in eac
 | `displayName` | string? | Human-readable label shown in the UI |
 | `type` | string | Task type — see task plugins under `plugins/tasks/` |
 | `data` | object | Type-specific configuration — see corresponding plugin's `impl-json.md`. For connector tasks, `data.bindings` references the root-level bindings array. |
-| `skipCondition` | string? | Expression — skip the task when truthy |
+| `skipCondition` | string? | `=js:` expression — skip the task when truthy. Use strict equality ([`bindings-and-expressions.md`](bindings-and-expressions.md#equality-operators)). |
 | `entryConditions` | TaskEntryCondition[]? | See §3. Written by the task-entry-conditions plugin from the SDD's authored Entry Condition rows — applied uniformly across task types (no auto-injection by task type). |
 | `shouldRunOnlyOnce` | boolean? | Run the task at most once per case, even if the stage is re-entered |
 | `shouldRunOnReEntry` | boolean? | *(deprecated — use `shouldRunOnlyOnce`)* Re-run when stage is re-entered |
 | `isRequired` | boolean? | Whether the task must complete for the stage to complete |
 | `description` | string? | Task description |
 
+> **Envelope fields are top-level, not `data`.** Every field above except `data` lives directly on the task object — `skipCondition`, `entryConditions`, `shouldRunOnlyOnce`, `isRequired`, etc. are siblings of `data`, never nested inside it. `data` holds only the type-specific config defined by the task's plugin. An envelope field misplaced inside `data` passes `validate` silently (extra `data` keys aren't rejected) but is dead config the platform never reads.
+>
+> ```json
+> // WRONG — skipCondition nested in data, never applied:
+> { "displayName": "Hold", "data": { "timerType": "timeDuration", "timeDuration": "PT1H", "skipCondition": "=js:vars.skip === true" } }
+>
+> // RIGHT — skipCondition is a sibling of data:
+> { "displayName": "Hold", "skipCondition": "=js:vars.skip === true", "data": { "timerType": "timeDuration", "timeDuration": "PT1H" } }
+> ```
+
 **Positioning:** tasks have no `x`/`y`. They live in `stageNode.data.tasks[laneIndex][]` — a 2D array where the outer index is the lane (rendering column) and the inner index is the order within the lane. Default convention: one task per lane. Exception: within a `runs-sequentially` group, tasks that should run in parallel share the same lane (shared lane = parallel siblings, carries execution semantics).
 
 **Task type catalog** (full shape in each plugin's `impl-json.md`):
@@ -529,44 +480,37 @@ All tasks inside a stage share this envelope. Per-type `data` fields live in eac
 | `wait-for-connector` | `plugins/tasks/connector-trigger/` |
 | `wait-for-timer` | `plugins/tasks/wait-for-timer/` |
 
+> **Not supported yet — do NOT author.** `external-agent`, `external-workflow`, `document-extraction`, `flow-process`. None of these are valid in `caseplan.json` (SKILL.md Rule 16).
+
 ---
 
 ## 8. Minimal example
 
 ```json
 {
-  "root": {
-    "id": "root",
-    "name": "Simple Case",
-    "type": "case-management:root",
+  "id": "case-aBcDeFgHiJ",
+  "version": "23.0.0",
+  "name": "Simple Case",
+  "metadata": {
     "caseIdentifier": "Simple Case",
-    "caseAppEnabled": false,
     "caseIdentifierType": "constant",
-    "version": "v19",
+    "caseAppEnabled": false,
     "publishVersion": 2,
-    "data": {
-      "intsvcActivityConfig": "v2",
-      "uipath": {
-        "variables": {},
-        "bindings": []
-      }
-    }
+    "caseUnifiedSchemaEnabled": true,
+    "caseDirectlyPassTaskOutputs": true,
+    "intsvcActivityConfig": "v2"
   },
+  "bindings": [],
+  "variables": { "inputs": [], "outputs": [], "inputOutputs": [] },
   "nodes": [
     {
       "id": "trigger_xY2mNp",
       "type": "case-management:Trigger",
-      "position": { "x": 200, "y": 0 },
       "data": { "label": "Start" }
     },
     {
       "id": "Stage_aB3kL9",
       "type": "case-management:Stage",
-      "position": { "x": 100, "y": 200 },
-      "style": { "width": 304, "opacity": 0.8 },
-      "measured": { "width": 304, "height": 128 },
-      "width": 304,
-      "zIndex": 1001,
       "data": {
         "label": "Process",
         "parentElement": { "id": "root", "type": "case-management:root" },
@@ -576,16 +520,8 @@ All tasks inside a stage share this envelope. Per-type `data` fields live in eac
       }
     }
   ],
-  "edges": [
-    {
-      "id": "edge_Qz7hVr",
-      "type": "case-management:TriggerEdge",
-      "source": "trigger_xY2mNp",
-      "target": "Stage_aB3kL9",
-      "sourceHandle": "trigger_xY2mNp____source____right",
-      "targetHandle": "Stage_aB3kL9____target____left",
-      "data": {}
-    }
-  ]
+  "edges": []
 }
 ```
+
+`edges` is empty: the skill authors no edges. The case starts because `Stage_aB3kL9` carries a `case-entered` entry condition (added by the stage-entry-conditions plugin), not because a `TriggerEdge` connects the trigger to it.

package/skills/uipath-maestro-case/references/connector-integration.md

@@ -14,14 +14,16 @@ Consult this reference when planning or implementing any of:
 
 1. `uip login` — tenant-scoped connectors are only visible after authentication.
 2. `uip maestro case registry pull` — populates `typecache-activities-index.json` and `typecache-triggers-index.json` at `~/.uip/case-resources/`.
-3. A healthy Integration Service connection must exist for the connector. If `Connections` is empty after `get-connection`, the user must create one in IS before proceeding.
+3. A healthy Integration Service connection for the connector. If `Connections` is empty after `get-connection`, offer to create one (Step 2) rather than failing — see [§ Creating a Connection](#creating-a-connection).
 
-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).
 
 ## Resolution Pipeline
 
 For every connector task or event trigger, run these CLI metadata fetches in order. Each call feeds the next; the populated `caseShape` from `case spec` is written directly into `caseplan.json` per the plugin's `impl-json.md` — there is no `tasks add-connector` mutation step.
 
+> **Empty `Connections[]` is not terminal.** When `get-connection` returns no connections, Step 2 offers to create one (`uip is connections create`) before falling back to `<UNRESOLVED>` — see [§ Creating a Connection](#creating-a-connection).
+
 ### Step 1 — Find the activity-type-id
 
 Read the relevant TypeCache index file directly (CLI `registry search` has known gaps — see [registry-discovery.md](registry-discovery.md)).
@@ -50,9 +52,34 @@ Output: `{ Entry, Config, Connections }` where:
 **Selection rules (in priority order):**
 
 1. If the sdd.md names a specific connection, match by `name`. Use that `id`.
-2. If the sdd.md is silent and exactly one connection exists, use it.
-3. If multiple connections exist and sdd.md is silent, use **AskUserQuestion** with a bounded list of connection names + "Something else".
-4. If `Connections` is empty, mark the task `<UNRESOLVED: no IS connection for <connectorKey>>` in `tasks.md` and omit `input-values:`. Execution writes a placeholder connector task — `type` + `displayName` + `data: {}`, no `data.typeId` / `data.connectionId` keys. Tell the user in the completion report to create the connection in the IS portal before the task can run. See [placeholder-tasks.md](placeholder-tasks.md).
+2. If the sdd.md is silent, **always present the choice via AskUserQuestion — do not auto-select**, even when exactly one connection exists:
+   - **`Connections` non-empty** → list connections by `name` **plus a "Create a new connection" option** (an existing connection may not fit the intent).
+   - **`Connections` empty** → offer **Create a new connection** / **Skip (defer)**.
+3. **Create chosen** → create the connection, then continue to Step 3 with the returned `ConnectionId`. Procedure — background `is connections create`, capture `ConnectionId`, headless fallback: [§ Creating a Connection](#creating-a-connection).
+4. **Skip / create declined or failed / non-interactive run** → mark the task `<UNRESOLVED: no IS connection for <connectorKey>>` in `tasks.md` and omit `input-values:`. Execution writes a placeholder connector task — `type` + `displayName` + `data: {}`, no `data.typeId` / `data.connectionId` keys. Note it in the completion report. See [placeholder-tasks.md](placeholder-tasks.md). A failed `is connections create` MUST route here after surfacing the error (§ Creating a Connection step 4) — **planning continues to a placeholder, it never stalls.**
+
+#### Creating a Connection
+
+Reached when the user picks "Create a new connection" or no usable connection exists. Create one via the OAuth flow:
+
+```bash
+uip is connections create "<connector-key>" --output json
+# → Data: { ConnectionId, ConnectionName, Connector, State, Owner, Folder, FolderKey }
+```
+
+`<connector-key>` is a positional argument — use `Config.connectorKey` from `get-connection` (present even when `Connections` is empty). The command auto-opens the browser for OAuth and **blocks until the user finishes authorizing**, then returns the new connection.
+
+1. **Run it in the background.** OAuth completion is human-paced and routinely exceeds a foreground command timeout — run detached so it survives across turns; read the result when it exits.
+2. **Capture `Data.ConnectionId`** and use it directly as `--connection-id` for `case spec` (Step 3). **Do NOT re-run `get-connection`** to re-discover it — the IS connection cache may be stale immediately after create, and the create output already carries the authoritative id.
+3. **Ping to verify** (optional): `uip is connections ping "<ConnectionId>" --output json`.
+4. **On failure — surface and re-prompt, never stall.** The create failed if the command **exits non-zero**, the JSON `Result` is `"Failure"`, or no `Data.ConnectionId` is returned (e.g. OAuth denied/failed, browser closed, connector misconfigured). On auth failure the command **exits** (verified: exit 1) — it does not hang. Do NOT silently proceed and do NOT leave planning incomplete:
+   1. Show the user the failure `Message` (and `Instructions` if present) verbatim — do not invent a cause. Example: `{ "Result": "Failure", "Message": "Authentication failed", "Instructions": "Check credentials and try again." }`.
+   2. Re-prompt via **AskUserQuestion**: **Retry create** (re-run `is connections create`) / **Skip (defer)**.
+   3. On **Skip**, or after a repeated failure, fall to Selection rule 4 — mark `<UNRESOLVED>`, emit the placeholder, and **finish writing `tasks.md`** so planning completes.
+
+**Headless / no-browser fallback** (CI, remote sandbox, no display) — the agent cannot complete browser OAuth. Either ask the user to run `! uip is connections create "<connector-key>" --output json` in their own terminal and paste back the `ConnectionId`, or run with `--no-wait` to get the pending authorization URL, surface it, and poll until `State: Enabled`.
+
+> If you must re-discover via `is connections list` after create, pass `--refresh` to bypass the cache — but capturing `ConnectionId` from the create output is preferred.
 
 ### Step 3 — Discover the operation contract via `case spec`
 

package/skills/uipath-maestro-case/references/connector-trigger-common.md

@@ -15,8 +15,12 @@ All three use the same TypeCache (`typecache-triggers-index.json`), same single-
 
 ### 1. Find the trigger in TypeCache
 
+If `~/.uip/case-resources/typecache-triggers-index.json` does not exist, run `uip maestro case registry pull` first (missing file is a precondition failure, not a 0-match — Rule 17 gate does not apply). If still absent after pull, the tenant has no connector triggers — mark `<UNRESOLVED>` and fall through to § Placeholder fallback.
+
 Read `~/.uip/case-resources/typecache-triggers-index.json` directly. Match on `displayName`, `connectorKey`, or `eventOperation` 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` **and** `connector-key` `<UNRESOLVED: no typecache trigger for <query>>` and skip § 2 entirely — with no `activity-type-id` there is nothing to pass to `get-connection`. Fall through to § Placeholder fallback (event trigger → placeholder node; connector-trigger task → `data: {}`; condition rule → stub `uipath`). Continue planning — do not halt ([planning.md § 3.4](planning.md)).
+
 ### 2. Resolve the connection
 
 ```bash
@@ -25,15 +29,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>`. Both plugins emit placeholders at execution time (different shapes per plugin) — see [placeholder-tasks.md](placeholder-tasks.md) for connector-task placeholders and [`plugins/triggers/event/impl-json.md` § Placeholder fallback](plugins/triggers/event/impl-json.md) for event-trigger placeholders.
+- **`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>`. Both plugins emit placeholders at execution time (different shapes per plugin) — see [placeholder-tasks.md](placeholder-tasks.md) for connector-task placeholders and [`plugins/triggers/event/impl-json.md` § Placeholder fallback](plugins/triggers/event/impl-json.md) for event-trigger placeholders.
 
-Record `connection-id`, `connector-key`, `object-name`, `eventOperation` from the response.
+Record `connection-id`, `connector-key`, `object-name`, `eventOperation` 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).
 
 > **Entity-typed Curated triggers** (e.g. UiPath Data Service `Record Created (Preview)`) carry a placeholder `objectName` in the typecache (`{tenantEntityName|folderEntityName}`). Pick a real entity via `uip is triggers objects <connector-key> <eventOperation>` and pass it as `--object-name` on the `case spec` call in Step 3.
 
@@ -336,7 +341,7 @@ Conventions (shared with activity):
 - `id` = same as `var`
 - `elementId` = the task's elementId (in-stage `wait-for-connector` task), the trigger node's id (case-level event trigger), or `<ownerNodeId>-<ruleId>` (connector-bound condition rule — see [§ Target: connector-bound condition rule](#target-connector-bound-condition-rule))
 
-For **outputs** apply the dedup rule: collect existing output `var` values across every task / trigger / **connector-bound condition rule** already in `caseplan.json`; if a `var` already exists (e.g. `response`, `error` collide across multiple connector tasks / triggers / rules), append a counter starting at 2 (`response2`, `error2`). Update `var`, `id`, `value`, `target` (when present); keep `name`, `displayName`, `source` unchanged. **Rule outputs participate in the same global pool** — the dedup must walk condition `rules[][].uipath.outputs[]` across all 4 condition scopes (stage-entry / stage-exit / case-exit / task-entry, plus root `caseExitConditions` v19 / `metadata.caseExitRules` v20) in **both directions**: when a rule mints outputs, dedupe against tasks + triggers + rules; when a task / trigger mints outputs, dedupe against existing rule outputs. See [global-vars/impl-json.md § Uniqueness Rule](plugins/variables/global-vars/impl-json.md#uniqueness-rule) for the full enumeration.
+For **outputs** apply the dedup rule: collect existing output `var` values across every task / trigger / **connector-bound condition rule** already in `caseplan.json`; if a `var` already exists (e.g. `response`, `error` collide across multiple connector tasks / triggers / rules), append a counter starting at 2 (`response2`, `error2`). Update `var`, `id`, `value`, `target` (when present); keep `name`, `displayName`, `source` unchanged. **Rule outputs participate in the same global pool** — the dedup must walk condition `rules[][].uipath.outputs[]` across all 4 condition scopes (stage-entry / stage-exit / case-exit / task-entry, case-exit rules living under `metadata.caseExitRules`) in **both directions**: when a rule mints outputs, dedupe against tasks + triggers + rules; when a task / trigger mints outputs, dedupe against existing rule outputs. See [global-vars/impl-json.md § Uniqueness Rule](plugins/variables/global-vars/impl-json.md#uniqueness-rule) for the full enumeration.
 
 > **Trigger-NODE inputs only:** the case-level event-**trigger node** gets no `elementId` on its inputs (different from in-stage task inputs). This does **NOT** apply to connector-bound **condition rules** — a rule's inputs AND outputs BOTH get `elementId = <ownerNodeId>-<ruleId>` (= `root-<ruleId>` for case-exit). See [§ Target: connector-bound condition rule](#target-connector-bound-condition-rule), and each plugin's `impl-json.md` for the target-specific shape.
 
@@ -395,7 +400,7 @@ A `wait-for-connector` rule inside a condition (`…conditions[].rules[i][j]`) b
 | Task-level fields (`type`, `displayName`, `isRequired`, `shouldRunOnlyOnce`) | yes | none — it's a rule, not a node |
 | `conditionExpression` | n/a | optional extra `=js:` gate on **case state** (`vars.X` / `metadata`) — NOT the event payload (no `event` namespace) |
 
-`<ownerNodeId>` = the **stage id** for stage-entry / stage-exit / task-entry rules (all stage-scoped); **`root`** for case-exit rules (v19 `root.caseExitConditions` / v20 `metadata.caseExitRules`).
+`<ownerNodeId>` = the **stage id** for stage-entry / stage-exit / task-entry rules (all stage-scoped); **`root`** for case-exit rules (which live under `metadata.caseExitRules`).
 
 ### Procedure (Phase 3)
 
@@ -420,7 +425,7 @@ A `wait-for-connector` rule inside a condition (`…conditions[].rules[i][j]`) b
 }
 ```
 
-5b. If the T-entry has `outputs:`, dispatch `rule.uipath.outputs[]` per [io-binding/impl-json.md § Output Binding Shapes for Connector Condition Rules](plugins/variables/io-binding/impl-json.md#output-binding-shapes-for-connector-condition-rules) — rewrite each already-minted output entry per its `->` / `=` operator. Skip when `uipath` is absent.
+5b. If the T-entry has `outputs:`, dispatch `rule.uipath.outputs[]` per [io-binding/impl-json.md § Output Binding Shapes for Connector Condition Rules](plugins/variables/io-binding/impl-json.md#output-binding-shapes-for-connector-condition-rules) — rewrite each already-minted output entry per its `->` / `=` operator. Skip when the rule has no `uipath.outputs[]` (stub placeholder — the stub always emits `uipath`, but with empty `outputs[]`).
 
 6. Append root bindings (ConnectionId + FolderKey) and run the deferred `bindings_v2` sync — identical to the task ([§ Root-level bindings](#root-level-bindings)).
 
@@ -451,11 +456,33 @@ Rule `id`s are opaque to the FE (no format validation on import) — `Rule_xxxxx
 ### Caveats
 
 - **Not a case-start trigger.** A connector rule compiles to an in-flight wait (ReceiveTask / event subprocess), so it gets **no entry-points.json entry** and **no rule-specific registration key** — FE `PackagingUtil` trigger registration is gated on `Intsvc.EventTrigger` start events only, which a rule is not. If the `case spec` caseShape carries a `metadata.body.bindings[Property]` registration entry (event-parameter connectors), substitute it exactly as the task does (Step 3 / Step 4); there is nothing rule-specific.
-- **CLI `validate` does NOT check `rule.uipath`.** The case-tool connector validator is task-only (reads `task.data`). A passing Phase-4 validate does **not** confirm a connector rule is valid — Studio Web (or an FE round-trip) is the real check. Emit the `uipath` block correctly; do not rely on validate to catch omissions.
+- **Full `validate` requires `rule.uipath` + `context`** — absent → `connector activity missing`. It does NOT check the `uipath` *internals* (a wrong `serviceType` passes), so a clean validate confirms the block is *present*, not that the connector *resolves* — confirm in Studio Web. Unresolved → stub placeholder (§ Placeholder fallback). `--skeleton` (Phase 2) skips condition rules.
 
 ### Placeholder fallback
 
-On `case spec` failure or `<UNRESOLVED>` `type-id` / `connection-id` / `connector-key`, emit the rule **without** its `uipath` block — `{ id, rule: "wait-for-connector", conditionExpression? }`. The rule itself is not a placeholder; only the connector configuration (the `uipath` payload) is deferred until the registry resolves, exactly like task connector data deferred via `data:{}`. Absence of `uipath` naturally skips the dependent subsystems: io-binding has no `outputs[]` to wire, root bindings has no Connection/Folder pair to add, IS-cache has no entry to register, global var-id dedup has no outputs to consider, and the Step-10 `bindings_v2` sync has nothing to regenerate for this rule. Stamp the `tasks.md` entry with `<UNRESOLVED>` markers per Rule 8 and log per [logging/impl-json.md](plugins/logging/impl-json.md). Upgrade by re-running the [§ Procedure](#procedure-phase-3) once the connector resolves; same upgrade flow as `placeholder-tasks.md § Upgrade Procedure` for connector tasks.
+Two entry paths reach this fallback: **Scenario A** — connector not found in TypeCache (§ 1 No-match, after the Rule 17 gate); **Scenario B** — connector found but connection unresolved, only after the [§ 2 create offer](#2-resolve-the-connection) is **declined** or fails. When `Connections` is empty, offer to create one first — do not jump straight to the placeholder.
+
+On `case spec` failure or `<UNRESOLVED>` `type-id` / `connection-id` / `connector-key`, emit the rule with a **stub `uipath`**. A *bare* rule (no `uipath`) is NOT a valid placeholder — full `validate` errors `connector activity missing` and Studio Web rejects it. The stub is the **minimum that clears `validate`**: `serviceType` plus the two `context` entries the validator checks for — named `connectorKey` + `operation`, each the literal `"placeholder"` — with empty `inputs` / `outputs` / `bindings`. Do NOT pad it with the other resolved context fields (`connection`, `objectName`, …): Studio Web flags the unresolved connector regardless of how complete the stub is, so extra placeholders buy nothing until the connector is real. The full attach checklist lives in the `tasks.md` `<UNRESOLVED>` markers and the completion report, not in the stub.
+
+```json
+{
+  "id": "<ruleId>",
+  "rule": "wait-for-connector",
+  "uipath": {
+    "serviceType": "Intsvc.WaitForEvent",
+    "context": [
+      { "name": "connectorKey", "value": "placeholder", "type": "string" },
+      { "name": "operation",    "value": "placeholder", "type": "string" }
+    ],
+    "inputs": [],
+    "outputs": [],
+    "bindings": []
+  },
+  "conditionExpression": "<carry from the T-entry if present>"
+}
+```
+
+This stub is a **deliberate mock** — it clears `validate` only. Studio Web flags the unresolved connector, and the rule **fails at debug/run until resolved** (it cannot wait on a `"placeholder"` connector). It still skips the dependent subsystems: io-binding has no real `outputs[]` to wire, no Connection/Folder bindings, no IS-cache entry, no `bindings_v2` regen for this rule. Stamp the `tasks.md` entry with `<UNRESOLVED>` markers per Rule 8, log per [logging/impl-json.md](plugins/logging/impl-json.md), and list it in the completion report as **"replace the `placeholder` connector values before debug / publish-to-run."** Upgrade by re-running the [§ Procedure](#procedure-phase-3) once the connector resolves; same upgrade flow as `placeholder-tasks.md § Upgrade Procedure` for connector tasks.
 
 ---
 
@@ -474,4 +501,4 @@ On `case spec` failure or `<UNRESOLVED>` `type-id` / `connection-id` / `connecto
 
 ## Known Limitation (shared)
 
-The CLI-produced `essentialConfiguration` uses `essentialConfiguration` only (not `optionalConfiguration`). Triggers work at **runtime** but the FE editor may not render certain fields until the user re-configures the trigger 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`). Triggers work at **runtime** but the FE editor may not render certain fields until the user re-configures the trigger in the UI. DAP repopulates these on form open.