@uipath/skills 1.195.0

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

@@ -0,0 +1,90 @@
+# stage-entry-conditions — Implementation (Direct JSON Write)
+
+> **Phase split.** Phase 3 only. Phase 2 does not write conditions. See [`../../../phased-execution.md`](../../../phased-execution.md).
+
+Write the stage-entry condition directly to the target stage's `data.entryConditions[]`. No CLI command needed.
+
+## Condition JSON Shape
+
+> **ID format.** Condition `id` is `Condition_` + 6 random chars. Rule `id` is `Rule_` + 6 random chars.
+
+```json
+{
+  "id": "Condition_xC1XyX",
+  "displayName": "After Triage",
+  "isInterrupting": false,
+  "rules": [
+    [
+      {
+        "id": "Rule_jdBFrJ",
+        "rule": "selected-stage-exited",
+        "selectedStageId": "Stage_aB3kL9"
+      }
+    ]
+  ]
+}
+```
+
+Rules use DNF — outer array is OR, inner array is AND.
+
+## Procedure
+
+1. Generate condition ID: `Condition_` + 6 alphanumeric chars
+2. Generate rule ID: `Rule_` + 6 alphanumeric chars
+3. Locate the target stage in `schema.nodes` by ID
+4. Initialize `stageNode.data.entryConditions = []` if absent (regular Stage is created without this key — see [`../../stages/impl-json.md`](../../stages/impl-json.md))
+5. Read `rule-type` and `is-interrupting` from tasks.md; pick the recipe below
+6. Set `displayName`: use tasks.md `display-name` if present; else default to `Entry Rule {N}`, where `N` = the 1-based index this condition takes in `stageNode.data.entryConditions[]` (i.e. `entryConditions.length + 1` at append time). Never emit a blank or omitted `displayName`.
+7. Append the condition object to `stageNode.data.entryConditions[]`
+
+## Rule Types
+
+### case-entered — first-stage entry
+
+```json
+"rules": [[ { "id": "Rule_xxxxxx", "rule": "case-entered" } ]]
+```
+
+### selected-stage-completed / selected-stage-exited — upstream stage trigger
+
+```json
+"rules": [[
+  {
+    "id": "Rule_xxxxxx",
+    "rule": "selected-stage-exited",
+    "selectedStageId": "Stage_aB3kL9"
+  }
+]]
+```
+
+Swap `rule` to `selected-stage-completed` when completion semantics are required.
+
+### user-selected-stage — target of a `wait-for-user` exit
+
+```json
+"rules": [[ { "id": "Rule_xxxxxx", "rule": "user-selected-stage" } ]]
+```
+
+Fires when an upstream stage exits via a `wait-for-user` exit condition and the user picks this stage as the next one. The stage must opt in by declaring this rule — only stages with `user-selected-stage` are presented in the picker.
+
+### 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` is optional — an extra `=js:` gate on **case state** (`vars.X`), NOT the event payload (no `event` namespace); set `isInterrupting: true` on the condition for exception/fraud/escalation flows. 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)).
+
+**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-Type Catalog
+
+| `rule` | Required extra field |
+|---|---|
+| `case-entered` | — |
+| `selected-stage-completed` | `selectedStageId` |
+| `selected-stage-exited` | `selectedStageId` |
+| `user-selected-stage` | — |
+| `wait-for-connector` | `uipath` connector configuration (see [common](../../../connector-trigger-common.md#target-connector-bound-condition-rule)) |
+
+`conditionExpression` is optional on every rule — add it to any rule to further gate when it fires.
+
+## Post-Write Verification
+
+Confirm target stage's `data.entryConditions[]` contains the new object with `id`, non-empty `displayName` (SDD value or `Entry Rule {N}` default), `isInterrupting` matching the T-entry, and `rules` carrying 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 (placeholders substituted), inputs/outputs `elementId` is `<stageId>-<ruleId>`, and the ConnectionId + FolderKey root bindings exist. CLI `validate` does NOT check `rule.uipath` — confirm via Studio Web.

package/skills/uipath-maestro-case/references/plugins/conditions/stage-entry-conditions/planning.md

@@ -0,0 +1,60 @@
+# stage-entry-conditions — Planning
+
+Conditions that control **when a stage is entered**. Attach to a stage; fire when the inbound rule is satisfied.
+
+## When to Use
+
+Pick this plugin when the sdd.md **literally uses the phrase "stage entry condition"** (or close variants: "stage entry conditions", "entry rule on stage", "entry gate on <stage>").
+
+For when a stage **exits**, use [stage-exit-conditions](../stage-exit-conditions/planning.md). For when a specific **task** starts, use [task-entry-conditions](../task-entry-conditions/planning.md).
+
+## No omission — one T-task per sdd.md Entry Condition row
+
+Every stage with an **Entry Condition** declared in sdd.md gets its own stage-entry-condition T-task — **including rule-type `case-entered`** and stages with `is-interrupting: false`. Never skip a condition because the rule-type or field values look like defaults. If sdd.md wrote the row, `tasks.md` emits the T-task.
+
+## Required Fields from sdd.md
+
+| Field | Source | Notes |
+|-------|--------|-------|
+| `<stage-id>` | previously captured from the stages plugin | Target stage |
+| `display-name` | sdd.md Display Name column (optional) | Carry the SDD value verbatim. Omit when the SDD cell is blank / `—` — do NOT invent one; impl defaults it to `Entry Rule {N}`. e.g., "Pre-check", "Interrupt on Fraud" |
+| `is-interrupting` | sdd.md (default `false`) | `true` if the condition interrupts the current stage |
+| `rule-type` | Pick from the catalog below | See §Rule-type catalog |
+| `selected-stage-id` | Required for `selected-stage-*` rule-types | ID of the referenced stage |
+| `connector fields` | SDD **Connector Rule Detail** block | `type-id` (activity-type-id), `connector-key`, `connection-id`, `object-name`, `event-operation`, `event-mode`, `input-values`, optional `filter` — resolved via [connector-trigger-common.md § Planning Pipeline](../../../connector-trigger-common.md#planning-pipeline) |
+| `condition-expression` | Optional on any rule-type | Extra `=js:` gate on **case state** (`=js:vars.X ...`) — NOT the event payload (no `event` namespace) |
+| `outputs` | SDD **Connector Rule Outputs** block | Optional. `->` (extract field → case var) or `=` (assign expression → case var). See [connector-trigger-common.md § tasks.md fields (planning)](../../../connector-trigger-common.md#tasksmd-fields-planning). |
+
+## Rule-Type Catalog (stage-entry scope)
+
+Allowed `ruleType` values and when to pick each:
+
+| Rule type | Meaning | Extra fields |
+|-----------|---------|--------------|
+| `case-entered` | Fires the moment the case is entered (first stage pattern) | — |
+| `selected-stage-completed` | Fires when a specific upstream stage completes | `selectedStageId` |
+| `selected-stage-exited` | Fires when a specific upstream stage exits (even without completing) | `selectedStageId` |
+| `user-selected-stage` | Fires when an upstream stage exits via a `wait-for-user` exit condition and the user selects this stage as the next one. Only stages carrying this rule appear in the picker. | — |
+| `wait-for-connector` | Waits for a connector event (binds an IS connector trigger under `uipath`) | connector fields (above); `conditionExpression` optional |
+
+`is-interrupting: true` means the condition can fire **while another stage is active** and will interrupt it. Use for exception/interrupt flows.
+
+## Ordering
+
+Stage entry conditions are created **after** all stages exist (Step 7 in implementation.md). Source/target stage IDs must both be captured by then.
+
+## tasks.md Entry Format
+
+```markdown
+## T<n>: Add stage-entry condition for "<stage>" — <summary>
+- target-stage: "<stage-name>"
+- display-name: "<name>"   # optional — omit when SDD Display Name cell is blank; impl defaults to "Entry Rule {N}"
+- is-interrupting: false
+- rule-type: selected-stage-completed
+- selected-stage: "<upstream-stage-name>"
+- condition-expression: "=js:vars.X..."   # optional gate on case state, NOT the event payload
+- order: after T<m>
+- verify: Confirm Result: Success, capture ConditionId
+```
+
+> `rule-type: wait-for-connector` also needs the connector fields — see [connector-trigger-common.md § tasks.md fields (planning)](../../../connector-trigger-common.md#tasksmd-fields-planning).

package/skills/uipath-maestro-case/references/plugins/conditions/stage-exit-conditions/impl-json.md

@@ -0,0 +1,110 @@
+# stage-exit-conditions — Implementation (Direct JSON Write)
+
+> **Phase split.** Phase 3 only. Phase 2 does not write conditions. See [`../../../phased-execution.md`](../../../phased-execution.md).
+
+Write the stage-exit condition directly to the target stage's `data.exitConditions[]`. No CLI command needed.
+
+## Condition JSON Shape
+
+> **ID format.** Condition `id` is `Condition_` + 6 random chars. Rule `id` is `Rule_` + 6 random chars.
+
+```json
+{
+  "id": "Condition_xC1XyX",
+  "displayName": "All tasks done",
+  "type": "exit-only",
+  "marksStageComplete": true,
+  "rules": [
+    [
+      { "id": "Rule_jdBFrJ", "rule": "required-tasks-completed" }
+    ]
+  ]
+}
+```
+
+Rules use DNF — outer array is OR, inner array is AND.
+
+## Procedure
+
+1. Generate condition ID: `Condition_` + 6 alphanumeric chars
+2. Generate rule ID: `Rule_` + 6 alphanumeric chars
+3. Locate the target stage in `schema.nodes` by ID
+4. Initialize `stageNode.data.exitConditions = []` if absent (regular Stage is created without this key — see [`../../stages/impl-json.md`](../../stages/impl-json.md))
+5. Read `type`, `exit-to-stage`, `marks-stage-complete`, and `rule-type` from tasks.md; pick the recipe below
+6. Set `displayName`: use tasks.md `display-name` if present; else default by `marks-stage-complete`: `true` → `Complete Rule {N}`, `false` → `Exit Rule {N}`. `N` = 1-based index **within the same label kind** — at append time, count existing entries in `stageNode.data.exitConditions[]` whose `marksStageComplete` equals this condition's value, then `N = count + 1`. FE numbers complete and exit rules with independent counters — do NOT use the array's overall length. Never emit a blank or omitted `displayName`.
+7. Append the condition object to `stageNode.data.exitConditions[]`
+
+## Exit Types
+
+| `type` | When to pick |
+|---|---|
+| `exit-only` | Default — stage exits normally along configured edges |
+| `wait-for-user` | Manual user decision required |
+| `return-to-origin` | Rework / exception loop — sends the case back to the previous stage |
+
+## Rule Types
+
+### required-tasks-completed — default completion
+
+```json
+"type": "exit-only",
+"marksStageComplete": true,
+"rules": [[ { "id": "Rule_xxxxxx", "rule": "required-tasks-completed" } ]]
+```
+
+### selected-tasks-completed — routing on specific tasks
+
+```json
+"type": "exit-only",
+"marksStageComplete": false,
+"rules": [[
+  {
+    "id": "Rule_xxxxxx",
+    "rule": "selected-tasks-completed",
+    "selectedTasksIds": ["t8GQTYo8O", "tWm4Vx9Tp"]
+  }
+]]
+```
+
+`selectedTasksIds` is a JSON string array, not a comma-separated string.
+
+### 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>`.** Place it in the exit condition with `type` / `marksStageComplete` like the other exit rules above. `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)).
+
+**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.
+
+### wait-for-user — manual decision gate
+
+```json
+"type": "wait-for-user",
+"marksStageComplete": true,
+"rules": [[ { "id": "Rule_xxxxxx", "rule": "required-tasks-completed" } ]]
+```
+
+The case pauses after the rule fires; the user picks the next stage from candidates that carry a `user-selected-stage` entry rule.
+
+### return-to-origin — rework loop
+
+```json
+"type": "return-to-origin",
+"marksStageComplete": true,
+"rules": [[ { "id": "Rule_xxxxxx", "rule": "required-tasks-completed" } ]]
+```
+
+Routes the case back to the originating stage.
+
+## Rule-Type × marksStageComplete Matrix
+
+| `marksStageComplete` | `rule` | Required extra field |
+|---|---|---|
+| `true` | `required-tasks-completed` | — |
+| `true` | `wait-for-connector` | `uipath` connector configuration |
+| `false` | `selected-tasks-completed` | `selectedTasksIds` (array) |
+| `false` | `wait-for-connector` | `uipath` connector configuration |
+
+`conditionExpression` is optional on every rule — add it to any rule to further gate when it fires. Use bare `=js:<expr>` (no outer parens); for combined boolean expressions wrap each sub-clause in parens: `=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).
+
+## Post-Write Verification
+
+Confirm target stage's `data.exitConditions[]` contains the new object with `id`, non-empty `displayName` (SDD value or `Complete Rule {N}` / `Exit Rule {N}` default keyed to `marksStageComplete`), `type`, `exitToStageId` (if set), `marksStageComplete` matching the T-entry, and `rules` carrying the expected `rule` value plus any required side field.

package/skills/uipath-maestro-case/references/plugins/conditions/stage-exit-conditions/planning.md

@@ -0,0 +1,74 @@
+# stage-exit-conditions — Planning
+
+Conditions that control **when and how a stage exits**. Attach to a stage; fire when the inbound rule is satisfied.
+
+## When to Use
+
+Pick this plugin when the sdd.md **literally uses the phrase "stage exit condition"** (or close variants: "stage exit conditions", "stage completion condition", "exit rule on <stage>").
+
+For when a stage **enters**, use [stage-entry-conditions](../stage-entry-conditions/planning.md).
+
+## No omission — one T-task per sdd.md Exit Condition row
+
+Every stage with an **Exit Condition** declared in sdd.md gets its own stage-exit-condition T-task — **including type `exit-only`, rule-type `required-tasks-completed`, and `marks-stage-complete: true`**. Never skip a condition because it looks like "the obvious default completion." If sdd.md wrote the row, `tasks.md` emits the T-task.
+
+## Required Fields from sdd.md
+
+| Field | Source | Notes |
+|-------|--------|-------|
+| `<stage-id>` | Captured from the stages plugin | Target stage |
+| `display-name` | sdd.md Display Name column (optional) | Carry the SDD value verbatim. Omit when the SDD cell is blank / `—` — do NOT invent one; impl defaults it to `Complete Rule {N}` (marks-stage-complete `true`) / `Exit Rule {N}` (`false`). |
+| `type` | sdd.md exit style | `exit-only` / `wait-for-user` / `return-to-origin` |
+| `exit-to-stage-id` | sdd.md routing target (optional) | Required when routing to a specific stage |
+| `marks-stage-complete` | sdd.md (default depends on type) | `true` for completion exits, `false` for diverging routes |
+| `rule-type` | From catalog below | |
+| `selected-tasks-ids` | Required for `selected-tasks-completed` | Comma-separated task IDs |
+| `connector fields` | SDD **Connector Rule Detail** block | `type-id` (activity-type-id), `connector-key`, `connection-id`, `object-name`, `event-operation`, `event-mode`, `input-values`, optional `filter` — see [connector-trigger-common.md § Planning Pipeline](../../../connector-trigger-common.md#planning-pipeline) |
+| `condition-expression` | Optional on any rule-type | Extra `=js:` gate on **case state** (`=js:vars.X ...`) — NOT the event payload (no `event` namespace) |
+| `outputs` | SDD **Connector Rule Outputs** block | Optional. `->` (extract field → case var) or `=` (assign expression → case var). See [connector-trigger-common.md § tasks.md fields (planning)](../../../connector-trigger-common.md#tasksmd-fields-planning). |
+
+## Exit Type Catalog
+
+| Exit `type` | When to pick |
+|-------------|--------------|
+| `exit-only` | **Default.** Stage exits normally along configured edges. |
+| `wait-for-user` | Exit requires manual user decision or approval. |
+| `return-to-origin` | Rework / exception loop — sends the case back to the previous stage. |
+
+## Rule-Type Catalog (stage-exit scope)
+
+Allowed `ruleType` values depend on `marks-stage-complete`:
+
+**When `marks-stage-complete: true`:**
+| Rule type | Extra fields |
+|-----------|--------------|
+| `required-tasks-completed` | — |
+| `wait-for-connector` | connector fields (fills `uipath`); `conditionExpression` optional |
+
+**When `marks-stage-complete: false` (exit-only, routing):**
+| Rule type | Extra fields |
+|-----------|--------------|
+| `selected-tasks-completed` | `selectedTasksIds` (comma-separated) |
+| `wait-for-connector` | connector fields (fills `uipath`); `conditionExpression` optional |
+
+## Ordering
+
+Stage exit conditions are created **after** all tasks in the stage have been added (so `selected-tasks-ids` can resolve). Planning records task names; implementation looks up captured IDs.
+
+## tasks.md Entry Format
+
+```markdown
+## T<n>: Add stage-exit condition for "<stage>" — <summary>
+- target-stage: "<stage-name>"
+- display-name: "<name>"                        # optional — omit when blank; impl defaults to "Complete Rule {N}"/"Exit Rule {N}" per marks-stage-complete
+- type: exit-only
+- exit-to-stage: "<target-stage-name>"          # optional
+- marks-stage-complete: true
+- rule-type: required-tasks-completed
+- selected-tasks: "<Task A>, <Task B>"          # only if rule-type requires
+- condition-expression: "=js:vars.X..."         # optional gate on case state, NOT the event payload
+- order: after T<m>
+- verify: Confirm Result: Success, capture ConditionId
+```
+
+> `rule-type: wait-for-connector` also needs the connector fields — see [connector-trigger-common.md § tasks.md fields (planning)](../../../connector-trigger-common.md#tasksmd-fields-planning).

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

@@ -0,0 +1,104 @@
+# task-entry-conditions — Implementation (Direct JSON Write)
+
+> **Phase split.** Phase 3 only. Phase 2 does not write conditions. See [`../../../phased-execution.md`](../../../phased-execution.md).
+
+Write the task-entry condition directly to the target task's `entryConditions[]`. No CLI command needed.
+
+## Condition JSON Shape
+
+> **ID format.** Task-level condition `id` is `c` + 8 random chars. Rule `id` is `r` + 8 random chars. These differ from stage/case-level conditions (`Condition_`/`Rule_`).
+
+```json
+{
+  "id": "c4fGhJ2Mn",
+  "displayName": "After Approval",
+  "rules": [
+    [
+      {
+        "id": "rK9xQw3Lp",
+        "rule": "selected-tasks-completed",
+        "selectedTasksIds": ["t8GQTYo8O"]
+      }
+    ]
+  ]
+}
+```
+
+Rules use DNF — outer array is OR, inner array is AND.
+
+## Procedure
+
+1. Generate condition ID: `c` + 8 alphanumeric chars
+2. Generate rule ID: `r` + 8 alphanumeric chars
+3. Locate the target stage in `schema.nodes` by ID
+4. Locate the target task inside `stageNode.data.tasks[lane][index]` (search every lane until the task ID is found)
+5. Initialize `task.entryConditions = []` if absent
+6. Read `rule-type` from tasks.md; pick the recipe below
+7. Set `displayName`: use tasks.md `display-name` if present; else default to `Entry Rule {N}`, where `N` = the 1-based index this condition takes in `task.entryConditions[]` (i.e. `entryConditions.length + 1` at append time). Never emit a blank or omitted `displayName`.
+8. Append the condition object to `task.entryConditions[]`
+
+## Rule Types
+
+### current-stage-entered
+
+```json
+"rules": [[ { "id": "rxxxxxxxx", "rule": "current-stage-entered" } ]]
+```
+
+### selected-tasks-completed — sibling task gating
+
+```json
+"rules": [[
+  {
+    "id": "rxxxxxxxx",
+    "rule": "selected-tasks-completed",
+    "selectedTasksIds": ["t8GQTYo8O", "tWm4Vx9Tp"]
+  }
+]]
+```
+
+`selectedTasksIds` is a JSON string array.
+
+### adhoc — expression gate
+
+```json
+"rules": [[
+  {
+    "id": "rxxxxxxxx",
+    "rule": "adhoc",
+    "conditionExpression": "=js:vars.riskScore > 700"
+  }
+]]
+```
+
+`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).
+
+### 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)).
+
+**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.
+
+### runs-sequentially — sequential group with optional parallel siblings
+
+```json
+"rules": [[ { "id": "rxxxxxxxx", "rule": "runs-sequentially" } ]]
+```
+
+**Lane semantics for this rule type:** Among tasks sharing a `runs-sequentially` task-entry condition, group members meant to run in **parallel** with each other MUST share the same `lane` in `stageNode.data.tasks[lane][index]` (shared lane = parallel siblings inside the sequential group, semantic — not just FE layout). Solo members of the group get their own lane. Tasks outside any `runs-sequentially` group still follow the default one-task-per-lane rule with layout-only semantics.
+
+## Rule-Type Catalog
+
+| `rule` | Required extra field |
+|---|---|
+| `current-stage-entered` | — |
+| `selected-tasks-completed` | `selectedTasksIds` (array) |
+| `wait-for-connector` | `uipath` connector configuration (see [common](../../../connector-trigger-common.md#target-connector-bound-condition-rule)) |
+| `adhoc` | — |
+| `runs-sequentially` | — |
+
+`conditionExpression` is optional on every rule — add it to any rule to further gate when it fires.
+
+## 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.

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

@@ -0,0 +1,55 @@
+# task-entry-conditions — Planning
+
+Conditions that control **when a specific task within a stage starts**. Attach to a task.
+
+## When to Use
+
+Pick this plugin when the sdd.md **literally uses the phrase "task entry condition"** (or close variants: "task entry conditions", "entry rule on task", "task gate", "task precondition").
+
+For **stage-level** conditions (entire stage enters/exits), use [stage-entry-conditions](../stage-entry-conditions/planning.md) / [stage-exit-conditions](../stage-exit-conditions/planning.md).
+
+## No omission — one T-task per sdd.md Entry Condition row
+
+Every task in sdd.md that declares an **Entry Condition** row gets its own task-entry-condition T-task — **including rule-type `current-stage-entered`**. Do NOT skip, collapse, or omit a condition because the rule-type looks like a default. If sdd.md wrote the row, `tasks.md` emits the T-task. "The default behavior would already cover it" is not a valid reason to omit.
+
+## Required Fields from sdd.md
+
+| Field | Source | Notes |
+|-------|--------|-------|
+| `<stage-id>`, `<task-id>` | Captured from prior steps | |
+| `display-name` | sdd.md Display Name column (optional) | Carry the SDD value verbatim. Omit when the SDD cell is blank / `—` — do NOT invent one; impl defaults it to `Entry Rule {N}`. |
+| `rule-type` | From catalog below | |
+| `selected-tasks-ids` | Required for `selected-tasks-completed` | Comma-separated task IDs |
+| `connector fields` | SDD **Connector Rule Detail** block | `type-id` (activity-type-id), `connector-key`, `connection-id`, `object-name`, `event-operation`, `event-mode`, `input-values`, optional `filter` — see [connector-trigger-common.md § Planning Pipeline](../../../connector-trigger-common.md#planning-pipeline) |
+| `condition-expression` | Optional | Extra `=js:` gate on **case state** (`=js:vars.X ...`) — NOT the event payload (no `event` namespace) |
+| `outputs` | SDD **Connector Rule Outputs** block | Optional. `->` (extract field → case var) or `=` (assign expression → case var). See [connector-trigger-common.md § tasks.md fields (planning)](../../../connector-trigger-common.md#tasksmd-fields-planning). |
+
+## Rule-Type Catalog (task-entry scope)
+
+| Rule type | Meaning | Extra fields |
+|-----------|---------|--------------|
+| `current-stage-entered` | Fires when the containing stage is entered | — |
+| `selected-tasks-completed` | Fires when specific sibling tasks in the same stage complete | `selectedTasksIds` |
+| `wait-for-connector` | Waits for a connector event (binds an IS connector trigger under `uipath`) | connector fields; `conditionExpression` optional |
+| `adhoc` | Ad hoc tasks run only when a user triggers them from the case app. | `conditionExpression` (optional) |
+| `runs-sequentially` | Sequential tasks run in the order they appear in the stage from top to bottom. Parallel members of the group share a `lane`; solo members get own lane. | `conditionExpression` (optional) |
+
+## Ordering
+
+Task entry conditions are created **after** all tasks in the stage have been added (so `selected-tasks-ids` can resolve).
+
+## tasks.md Entry Format
+
+```markdown
+## T<n>: Add task-entry condition for "<task>" in "<stage>" — <summary>
+- target-stage: "<stage-name>"
+- target-task: "<task-name>"
+- display-name: "<name>"                  # optional — omit when SDD Display Name cell is blank; impl defaults to "Entry Rule {N}"
+- rule-type: selected-tasks-completed
+- selected-tasks: "<Task A>, <Task B>"
+- condition-expression: "=js:vars.X..."   # optional gate on case state, NOT the event payload
+- order: after T<m>
+- verify: Confirm Result: Success, capture ConditionId
+```
+
+> `rule-type: wait-for-connector` also needs the connector fields — see [connector-trigger-common.md § tasks.md fields (planning)](../../../connector-trigger-common.md#tasksmd-fields-planning).

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

@@ -0,0 +1,152 @@
+---
+direct-json: supported
+---
+
+# edges — JSON Implementation
+
+Cross-cutting direct-JSON rules live in [`case-editing-operations.md`](../../case-editing-operations.md).
+
+## Purpose
+
+Connect two nodes (Trigger → Stage or Stage → Stage) by appending an edge object to `edges`. Edge type is **inferred from the source node** — never specified explicitly.
+
+The same recipe covers add / edit / remove — direct JSON writes state declaratively: "make `edges` match the desired set."
+
+> **Schema neutrality.** Edge shape is **identical across v19 and v20** — both use the top-level `edges[]` array, same per-edge fields. Per Rule 19 in v20, do NOT emit `data.waypoints` (lifted to top-level `layout.edges[<edgeId>].waypoints`); skill never authored waypoints anyway, so this is a no-op. `zIndex` is NOT in the layout-strip list; edge-level `zIndex` (when sdd.md requests one) stays at the edge level in both schemas.
+
+## Input spec (from `tasks.md`)
+
+| Field | Required | Notes |
+|---|---|---|
+| `source` | yes | Trigger ID (e.g., `trigger_1`) or Stage ID. Resolved from `id-map.json`. |
+| `target` | yes | Stage ID. Resolved from `id-map.json`. Never an ExceptionStage — see Guardrails. |
+| `label` | no | Display label on the connector (Studio Web "Name"). Optional — emit when sdd.md states one or planning's inference rules apply; otherwise emit `data.label: ""`. See [`planning.md` § Labels](planning.md#labels). |
+| `sourceHandle` direction | no | `right` (default) \| `left` \| `top` \| `bottom` |
+| `targetHandle` direction | no | `left` (default) \| `right` \| `top` \| `bottom` |
+| `zIndex` | no | Integer. Omit the key entirely when unset. |
+
+## Guardrails (enforce before writing)
+
+1. **Both endpoints exist in `schema.nodes`.** If either `source` or `target` is missing, halt — do not write a dangling edge.
+2. **Neither endpoint is an `case-management:ExceptionStage`.** Exception stages have no edges (see [`planning.md` § Wiring Constraints](planning.md#wiring-constraints)). They are reached via an interrupting `stage-entry-conditions` rule and exited via a `return-to-origin` `stage-exit-conditions` rule. Reject the write and flag to the user.
+3. **`target` is not a Trigger.** Edges always flow into a Stage (regular Stage only).
+4. **No duplicate edge with the same `source`+`target` pair** unless the sdd.md explicitly declares parallel edges. Warn if one already exists.
+
+## ID generation
+
+- Prefix: `edge_`
+- Suffix length: 6
+- Algorithm: per [`case-editing-operations.md § ID Generation`](../../case-editing-operations.md#id-generation)
+
+Record `T<n> → edge_xxxxxx` in `id-map.json` for the audit trail, even though no downstream node references edges by ID.
+
+## Edge-type inference
+
+```text
+sourceNode = schema.nodes.find(n => n.id === source)
+edgeType   = sourceNode.type === "case-management:Trigger"
+             ? "case-management:TriggerEdge"
+             : "case-management:Edge"
+```
+
+Do NOT accept a caller-supplied `type` — always derive it from the source node.
+
+## Handle strings
+
+Exactly **four underscores** each side:
+
+```text
+sourceHandle = `${source}____source____${sourceDir}`   # sourceDir default: "right"
+targetHandle = `${target}____target____${targetDir}`   # targetDir default: "left"
+```
+
+## Recipe — Add
+
+Append this object to `schema.edges` — always append, never prepend.
+
+### TriggerEdge (source is a Trigger)
+
+```json
+{
+  "id": "<edge_xxxxxx>",
+  "source": "<triggerId>",
+  "target": "<stageId>",
+  "sourceHandle": "<triggerId>____source____<sourceDir>",
+  "targetHandle": "<stageId>____target____<targetDir>",
+  "data": { "label": "<label>" },
+  "type": "case-management:TriggerEdge"
+}
+```
+
+### Edge (source is a Stage)
+
+```json
+{
+  "id": "<edge_xxxxxx>",
+  "source": "<sourceStageId>",
+  "target": "<targetStageId>",
+  "sourceHandle": "<sourceStageId>____source____<sourceDir>",
+  "targetHandle": "<targetStageId>____target____<targetDir>",
+  "data": { "label": "<label>" },
+  "type": "case-management:Edge"
+}
+```
+
+### Optional-field emission rules
+
+Omitted inputs yield absent keys (matches `JSON.stringify`'s drop-undefined behavior):
+
+| Input | Emission |
+|---|---|
+| `zIndex` unset | Omit the `zIndex` key entirely |
+| `sourceHandle` direction unset | Still emit the key with default `right` |
+| `targetHandle` direction unset | Still emit the key with default `left` |
+
+Key insertion order (cosmetic — frontends accept any order):
+
+```text
+id, source, target, sourceHandle, targetHandle, [zIndex], data, type
+```
+
+## Recipe — Edit
+
+Find the edge by `id` in `schema.edges` and mutate in place:
+
+| Field | Mutable | Notes |
+|---|---|---|
+| `id` | no | Immutable. |
+| `source` | no | Immutable. To rewire, remove + re-add. |
+| `target` | no | Immutable. To rewire, remove + re-add. |
+| `type` | no | Derived from `source`. Immutable. |
+| `data.label` | yes | Mutable; may be `""` when no rule applies. Always emit the key so the JSON shape stays consistent — write `""` to clear. |
+| `sourceHandle` | yes | Re-construct with new direction, keep same `source` ID. |
+| `targetHandle` | yes | Re-construct with new direction, keep same `target` ID. |
+| `zIndex` | yes | Set or `delete` to clear. |
+
+> To re-wire an edge (change `source` or `target`), **remove and re-add**. This preserves the invariant that `sourceHandle`/`targetHandle` always reference the current endpoints.
+
+## Recipe — Remove
+
+```text
+schema.edges = schema.edges.filter(e => e.id !== edgeId)
+```
+
+Nothing references edges by ID in `caseplan.json`, so no cascade cleanup is needed. A stage removal still cascades to its edges — that logic lives in the stages JSON recipe (`Delete a node` in [`case-editing-operations.md`](../../case-editing-operations.md#delete-a-node)), not here.
+
+## Semantic position
+
+Edges live in the top-level `schema.edges` array. Always append new edges to the end.
+
+## Post-write validation
+
+After writing, confirm:
+
+- `schema.edges` contains the new edge with the generated ID
+- `edges[].type` matches the inference (`TriggerEdge` iff source is a Trigger)
+- `edges[].sourceHandle` and `edges[].targetHandle` use exactly 4 underscores each side
+- `edges[].source` and `edges[].target` resolve to existing `schema.nodes` entries
+- `edges[].data.label` key is present (value may be `""` when no rule applies — see [`planning.md` § Labels](planning.md#labels))
+- `edges[].zIndex` is present iff the T-entry declared one
+
+Run `uip maestro case validate <file> --output json` after all edges for this plugin's batch are added.
+