@uipath/skills 1.195.0 → 1.196.0

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

@@ -9,7 +9,6 @@ Generate reviewable task plan (`tasks.md`) from design document (`sdd.md`). Disc
 > **Per-node-type detail lives in plugins.** This document covers the cross-cutting planning workflow. For how to fill fields for a specific node, consult the relevant plugin:
 > - Root case → `plugins/case/planning.md`
 > - Stages (regular / exception) → `plugins/stages/planning.md`
-> - Edges → `plugins/edges/planning.md`
 > - Tasks → `plugins/tasks/<type>/planning.md`
 > - Triggers → `plugins/triggers/<type>/planning.md`
 > - Conditions → `plugins/conditions/<scope>/planning.md`
@@ -50,74 +49,16 @@ uip maestro case registry pull
 
 If not logged in, prompt the user to log in. The registry pull caches all resources locally at `~/.uip/case-resources/` so subsequent searches are local disk lookups.
 
-**Capture `Data.BaseUrl` from the `login status` JSON for Step 2.1 tenant-override detection.** If `login status` failed or the field is absent, treat tenant override as unavailable and let Step 2.1 fall through to prompt-phrase detection — do not re-run `login status`.
-
 ## Step 2 — Locate and parse the design document
 
 Accept the `sdd.md` file path from the user, or ask if not provided. When the directory contains multiple `.md` files, use **AskUserQuestion** with the candidates + "Something else" to disambiguate.
 
 If the resolved path has **no `sdd.md`**, skill enters Phase 0 (interview mode) before this step. See [phase-0-interview.md](phase-0-interview.md). Phase 1 resumes here only after the Approve hard-stop in Phase 0.
 
-`sdd.md` is the **sole input**. It describes stages, tasks, edges, conditions, SLA, component types, persona information, and provides the search keywords for registry lookups. The skill does not validate or gap-fill sdd.md — trust it as written. (Phase 0 may have generated it; once approved, Rule 2 applies regardless of source.)
+`sdd.md` is the **sole input**. It describes stages, tasks, conditions, SLA, component types, persona information, and provides the search keywords for registry lookups. (It does not describe edges — transitions are expressed as stage entry/exit conditions; edges are retired.) The skill does not validate or gap-fill sdd.md — trust it as written. (Phase 0 may have generated it; once approved, Rule 2 applies regardless of source.)
 
 > **Phase 0 carryover.** When Phase 0 ran, `tasks/registry-resolved.json` already contains user-confirmed registry picks. During Step 3 below, **read the existing file first**: skip re-search for entries already resolved, only run discovery for tasks Phase 0 deferred (`<UNRESOLVED>` markers in `sdd.md`). Append new resolutions to the same file.
 
-### Step 2.1 — Detect schema version (Rule 18)
-
-Resolution order (first match wins):
-
-#### 2.1.a — Tenant override (alpha environment)
-
-Read the `Data.BaseUrl` value captured from Step 1's `uip login status --output json` call. If the value equals `https://alpha.uipath.com` (exact case-sensitive string match, no trailing slash), schema is `v20` regardless of user prompt. Print plain-text confirmation BEFORE Step 3 begins:
-
-```
-> Schema: v20 (alpha tenant override — BaseUrl=https://alpha.uipath.com forces v20 regardless of prompt phrasing). Phase 4 validate authoritative; CLI upload / debug may reject downstream.
-```
-
-Skip Step 2.1.b. The override is **forced** — user prompt phrases cannot downgrade to v19 from an alpha tenant.
-
-If `Data.BaseUrl` is absent (login failed, field missing, different value), proceed to Step 2.1.b. Do NOT halt — login state is independent of schema selection.
-
-#### 2.1.b — User-prompt phrase
-
-Scan **only the user message that activated the skill** (the prompt that matched the skill description). Match case-insensitive substrings:
-
-| Phrase (any one matches) |
-|---|
-| `v20 schema` |
-| `schema v20` |
-| `use v20` |
-| `emit v20` |
-| `generate v20` |
-| `unified schema` |
-| `schema 20.0.0` |
-
-- **Match** → schema is `v20`. Print plain-text confirmation BEFORE Step 3 begins:
-  ```
-  > Schema: v20 (skill-emit-only mode — Phase 4 validate authoritative; CLI upload / debug may reject downstream)
-  ```
-- **No match** → schema is `v19` (default). No confirmation line.
-
-**Never** scan sdd.md content, file paths, registry-resolved.json, Phase 0 transcripts, or any subsequent user message. Detection happens once, at Phase 1 entry. If the user wants to switch schema mid-build, they must re-run the skill from Phase 1 (Rule 6). The tenant override (2.1.a) is also fixed at Phase 1 entry — switching tenants mid-build does not change `tasks.md`'s `Schema:` header.
-
-### Step 2.2 — Persist schema choice in tasks.md header
-
-When `tasks.md` is written at Step 4, the **first non-comment line** is the schema header:
-
-```markdown
-Schema: v19
-```
-
-or
-
-```markdown
-Schema: v20
-```
-
-Place this line above all `T<n>` headings. Re-entry protocol (Phase 3 Step 9.6, Phase 4) re-reads tasks.md per Rule 7 and recovers the schema choice from this header. caseplan.json self-identifies via its top-level `version` literal as a secondary check.
-
-If the schema header in tasks.md conflicts with an already-written caseplan.json's `version` field at re-entry, **halt with explicit error** — never silently re-flip.
-
 ## Step 3 — Resolve resources
 
 Before resource resolution, seed TodoWrite with the items below to track Phase 1 progress through registry lookups and §4 T-entry emit. Mark each `in_progress` on entry, `completed` on exit. One item per emit class — never per T-entry.
@@ -127,11 +68,10 @@ Before resource resolution, seed TodoWrite with the items below to track Phase 1
 3. Write trigger entries T02+ (§4.3)
 4. Write variable / argument entries (§4.2.1)
 5. Write stage entries (§4.4)
-6. Write edge entries (§4.5)
-7. Write task entries (§4.6)
-8. Write condition entries (§4.7)
-9. Write SLA entries (§4.8)
-10. User approves tasks.md (Step 5)
+6. Write task entries (§4.6)
+7. Write condition entries (§4.7)
+8. Write SLA entries (§4.8)
+9. User approves tasks.md (Step 5)
 
 For every task, trigger, and condition in the sdd.md:
 
@@ -177,7 +117,11 @@ For every task, trigger, and condition in the sdd.md:
 
 ### 3.4 Unresolved resources
 
-When a resource cannot be resolved (registry gap and no cache match, or missing connection), **do not fabricate a placeholder or mock**. Instead:
+When a resource cannot be resolved (registry gap and no cache match, or missing connection), **do not fabricate a placeholder or mock**.
+
+> **Missing connection — offer to create first.** A missing/empty IS connection is not immediately "unresolved". The connector pipeline offers to create one via `uip is connections create` ([connector-integration.md § Step 2](connector-integration.md), [connector-trigger-common.md § Resolve the connection](connector-trigger-common.md#2-resolve-the-connection)). Only after the user **declines** or creation fails does the connection become `<UNRESOLVED>` and fall through to the steps below.
+
+Otherwise:
 
 1. Mark the line in `tasks.md` with `<UNRESOLVED: <reason>>` in the `taskTypeId` / `typeId` / `connectionId` slot.
 2. **Omit `inputs:` and `outputs:` entirely** on that task entry — there is no schema to wire against. Any input mapping the sdd.md described becomes a fenced ```` ```text ```` code block under the entry with a `wiring notes (user must attach):` header line. **Do not start lines with `#`** — they would render as markdown headings; use a fenced code block instead. Example shape is in [placeholder-tasks.md § `tasks.md` Planning-Entry Shape](placeholder-tasks.md).
@@ -188,7 +132,7 @@ At execution time, unresolved tasks become **placeholder tasks** in `caseplan.js
 
 ## Step 4 — Generate tasks.md and registry-resolved.json
 
-Create a `tasks/` folder adjacent to the sdd.md file. Generate `tasks.md` using the structure below. The **first non-comment line is the schema header** (`Schema: v19` or `Schema: v20` per Step 2.1–2.2). Each subsequent section is a numbered task (`T01`, `T02`, …) — declarative parameters only. Field names use plain identifiers (e.g., `type:`, `displayName:`, `lane:`), not CLI flag syntax. The implementation phase translates each entry into the matching plugin's JSON writes.
+Create a `tasks/` folder adjacent to the sdd.md file. Generate `tasks.md` using the structure below. Each section is a numbered task (`T01`, `T02`, …) — declarative parameters only. Field names use plain identifiers (e.g., `type:`, `displayName:`, `lane:`), not CLI flag syntax. The implementation phase translates each entry into the matching plugin's JSON writes.
 
 Cross-reference: [case-schema.md](case-schema.md) for JSON shape, [bindings-and-expressions.md](bindings-and-expressions.md) for inputs/outputs wiring.
 
@@ -198,13 +142,13 @@ Also write `registry-resolved.json` — full detail per task: search query, all
 
 Every declaration in `sdd.md` must become a T-task in `tasks.md`. Mapping is 1-to-1:
 
-- **Never filter** declarations on the grounds that the default rule-type, default field value, or "implicit behavior" would cover them. If `sdd.md` lists a task, stage, edge, trigger, condition, SLA row, **variable, or argument**, `tasks.md` emits a T-task for it — regardless of rule-type (`current-stage-entered`, `case-entered`, `exit-only`, `required-tasks-completed`, etc.).
+- **Never filter** declarations on the grounds that the default rule-type, default field value, or "implicit behavior" would cover them. If `sdd.md` lists a task, stage, trigger, condition, SLA row, **variable, or argument**, `tasks.md` emits a T-task for it — regardless of rule-type (`current-stage-entered`, `case-entered`, `exit-only`, `required-tasks-completed`, etc.).
 - **Never merge** two sdd.md items into one T-task "because they're similar."
 - **Never drop** defaults-looking items (e.g., `is-interrupting: false`, `runOnlyOnce: true`, `marks-stage-complete: true`). The explicit declaration is the signal — honor it.
 - **When in doubt, emit.** It is always correct to create a T-task that mirrors an sdd.md row. It is never correct to silently omit one.
 - **When format is ambiguous or unrecognized, ASK — do not skip.** If a row exists but you cannot determine the right plugin, category, or T-entry shape (e.g., trigger "Initial Variable Mapping" uses an aggregate phrase instead of explicit per-field mappings; a variable's category — In / Out / Variable — is unclear; a task type does not match the closed enum), invoke **AskUserQuestion** with the row content + the specific ambiguity + bounded options. Silent omission is a defect. This obligation applies to every sdd.md declaration class above, including variables and arguments.
 
-Before presenting `tasks.md` at Step 5, run a completeness cross-check: for every declared stage / edge / task / trigger / condition / SLA row **and every Case Variables table row (one T-entry each, per §4.2.1)** in sdd.md, verify a corresponding T-task exists. Gaps are a defect — fix before approval.
+Before presenting `tasks.md` at Step 5, run a completeness cross-check: for every declared stage / task / trigger / condition / SLA row **and every Case Variables table row (one T-entry each, per §4.2.1)** in sdd.md, verify a corresponding T-task exists. Gaps are a defect — fix before approval.
 
 **Cross-check inventory.** Before approval, count and report each class:
 
@@ -214,7 +158,6 @@ Before presenting `tasks.md` at Step 5, run a completeness cross-check: for ever
 | Triggers | Case Triggers | §4.3 (T02+) |
 | Variables / arguments | Case Variables | §4.2.1 (after last trigger) |
 | Stages | Section 2 stage headings | §4.4 |
-| Edges | Stage Entry Conditions / Stage Exit Conditions referencing other stages | §4.5 |
 | Tasks | Per-stage Tasks tables | §4.6 |
 | Conditions | Stage Entry / Stage Exit / Task Entry / Case Exit tables | §4.7 |
 | SLA | Case-Level SLA + per-stage Stage SLA + per-action Task SLA | §4.8 |
@@ -227,8 +170,8 @@ Counts that don't match the sdd.md → fix before Step 5 hard stop.
 
 Procedure:
 
-1. **Seed.** Write `tasks.md` with header only — `Schema: v19` (or `Schema: v20`), then a `## Inventory` placeholder section. Single Write.
-2. **Per section.** Sections are §4.2.1 vars → §4.3 triggers → §4.4 stages → §4.5 edges → §4.6 tasks → §4.7 conditions → §4.8 SLA. For each section:
+1. **Seed.** Write `tasks.md` with a `## Inventory` placeholder section only. Single Write.
+2. **Per section.** Sections are §4.2.1 vars → §4.3 triggers → §4.4 stages → §4.6 tasks → §4.7 conditions → §4.8 SLA. For each section:
    - **One Read** of `tasks.md` at section entry.
    - **N Edit-appends** in sequence, one per T-entry in the section. Skip the re-Read between sibling Edits — Edit's tool result confirms applied state in context.
    - TaskUpdate marks each T-entry `in_progress` → `completed` as it goes — that is the per-T-entry audit trail, not the file diff.
@@ -237,7 +180,7 @@ Procedure:
 
 Why: section-batched round-trips keep tool-call transcript reviewable, preserve rollback granularity at section boundary, allow mid-run interruption recovery via re-Read + resume from next un-applied T-entry, and surface omissions before they propagate — without paying a per-T-entry Read tax that inflates inference latency by ~5s per turn.
 
-**Hard cap on tasks.md write size.** After the §4.0a Step 1 Seed Write (header + Inventory placeholder, <1KB), the only legal mutation of `tasks.md` is **Edit-append** per the section-batched contract above. A single Write replacing the whole `tasks.md` is **forbidden** regardless of size. A single Edit-append payload >30KB is also forbidden — split into per-section Edit-appends even when consecutive Edits would total >30KB combined. Rationale: a single 96KB Write of tasks.md emits ~40K output tokens in one turn = ~360s inference latency = ~20% of total session in one tool call. Section-batched Edit-appends spread that cost across ~7 turns of ~50s each, recovers reviewability, and matches the recovery contract (re-Read + resume from next un-applied T-entry).
+**Hard cap on tasks.md write size.** After the §4.0a Step 1 Seed Write (Inventory placeholder, <1KB), the only legal mutation of `tasks.md` is **Edit-append** per the section-batched contract above. A single Write replacing the whole `tasks.md` is **forbidden** regardless of size. A single Edit-append payload >30KB is also forbidden — split into per-section Edit-appends even when consecutive Edits would total >30KB combined. Rationale: a single 96KB Write of tasks.md emits ~40K output tokens in one turn = ~360s inference latency = ~20% of total session in one tool call. Section-batched Edit-appends spread that cost across ~7 turns of ~50s each, recovers reviewability, and matches the recovery contract (re-Read + resume from next un-applied T-entry).
 
 **Recovery on interruption:** re-Read `tasks.md`, scan for next un-applied T-entry (the audit trail in TaskUpdate identifies it), resume from there. No sidecar checkpoint file.
 
@@ -245,7 +188,7 @@ This contract mirrors Phase 3's per-section JSON-write contract (see [implementa
 
 ### 4.1 Task ordering
 
-Always in this order: stages → edges → tasks → conditions → SLA.
+Always in this order: stages → tasks → conditions → SLA.
 
 The task **title IS the action description** — do not add a redundant `what` or `type` field. Absorb type into the title (e.g., `Add api-workflow task "..."` not `Add task` + `type: api-workflow`).
 
@@ -269,7 +212,7 @@ Title format: `Configure <trigger-type> trigger "<name>"`
 
 Consult the corresponding trigger plugin (`plugins/triggers/<type>/planning.md`) for required fields.
 
-**One T-entry per trigger row in sdd.md.** A case with N entry-point rows in its triggers table emits N trigger T-entries (T02, T03, …) — even when several rows would resolve to `<UNRESOLVED>` because the IS connection isn't provisioned. Per §4.0, "value can't be resolved yet" is not a reason to omit a row; it's a reason to mark `<UNRESOLVED: …>` and continue. See [edges/planning.md § Multi-Trigger Cases](plugins/edges/planning.md#multi-trigger-cases) for the matching N edges from triggers to the first stage.
+**One T-entry per trigger row in sdd.md.** A case with N entry-point rows in its triggers table emits N trigger T-entries (T02, T03, …) — even when several rows would resolve to `<UNRESOLVED>` because the IS connection isn't provisioned. Per §4.0, "value can't be resolved yet" is not a reason to omit a row; it's a reason to mark `<UNRESOLVED: …>` and continue. Regardless of how many triggers a case has, no per-trigger edge is created (edges are retired) — the case starts at the first stage's `case-entered` entry condition whenever any trigger fires.
 
 Each trigger row uses its plugin's full field set — see `plugins/triggers/<type>/planning.md` for the per-type entry format. Worked example — sdd.md declares 3 entry-point rows (one manual + two events), one of which is unresolved:
 
@@ -311,11 +254,9 @@ Title format: `Create stage "<name>"` or `Create exception stage "<name>"`
 
 One task per stage. Consult [`plugins/stages/planning.md`](plugins/stages/planning.md) for required fields and the `stage` vs `exception` (a.k.a. secondary) decision. Basic properties only — SLA and escalation come later (§4.7).
 
-### 4.5 Setup edges
-
-Title format: `Add edge "<source>" → "<target>"`
+### 4.5 Edges — not authored (RETIRED)
 
-One task per edge. Consult [`plugins/edges/planning.md`](plugins/edges/planning.md) for required fields (source, target, label, handles) and the orphan check.
+The skill does not author edges. Emit no edge T-entries. Stage transitions derive entirely from stage entry/exit conditions (§4.7); `caseplan.json.edges` stays `[]`. The first stage's `case-entered` entry condition replaces the former Trigger→first-stage edge. See the reachability check in [`sdd-generation-rules.md`](sdd-generation-rules.md).
 
 ### 4.6 Add tasks
 

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

@@ -26,6 +26,7 @@ Solution setup (`uip solution init`) and project registration (`uip solution pro
 | `case-identifier` | no | Defaults to `name`. |
 | `identifier-type` | no | `constant` \| `external`. Defaults to `constant`. |
 | `case-app-enabled` | no | Boolean. Defaults to `false`. |
+| `directly-pass-task-outputs` | no | Boolean. Defaults to `true`. Set `false` only when sdd.md requests it. |
 | `description` | no | Defaults to empty string. Always emitted so downstream consumers read a consistent shape. |
 
 See [`planning.md`](planning.md) for how these fields are sourced from `sdd.md`.
@@ -139,35 +140,10 @@ If any check fails, halt and report.
 1. **Scaffold has run.** The 5 files listed in § Scaffold must exist in `<SolutionDir>/<ProjectName>/`. They were written earlier in this same plugin invocation; if missing, halt (bug — re-run the plugin from the start).
 2. **Collision behavior: overwrite.** If `caseplan.json` already exists, overwrite it. When absent, create it. Skill Phase 2 re-runs regenerate `tasks.md` from scratch per SKILL.md Rule 6, so a collision here means a genuine re-run and overwriting is correct.
 
-## Schema branch — v19 vs v20 (Rule 18)
-
-Read the `Schema:` header from `tasks.md` (first non-comment line, written at planning Step 2.2). One of:
-
-- `Schema: v19` → use § Recipe (v19) below — DEFAULT.
-- `Schema: v20` → use § Recipe (v20) below.
-
-If header missing or malformed, halt with explicit error — never default silently.
-
 ## ID generation
 
-### v19
-
-- `root.id` is the literal string `"root"` — **not** a generated shortId. Divergent from every other plugin.
-- **No trigger ID emitted at T01.** The triggers plugin owns primary-trigger creation at T02.
-
-Record in `id-map.json`:
-
-```json
-{
-  "T01": { "kind": "case", "id": "root" }
-}
-```
-
-### v20
-
 - Top-level `id` is generated: prefix `case-` + 10 chars from `[A-Za-z0-9]` (per `case-editing-operations.md` § ID Generation algorithm). Example: `case-aBcDeFgHiJ`.
-- No `"root"` literal anywhere on disk in v20.
-- **No trigger ID emitted at T01.** Same as v19.
+- **No trigger ID emitted at T01.** The triggers plugin owns primary-trigger creation at T02.
 
 Record in `id-map.json`:
 
@@ -179,73 +155,7 @@ Record in `id-map.json`:
 
 The `id` value mirrors the actual top-level `id` written into `caseplan.json` — debug breadcrumb of reality.
 
-## Recipe (v19) — Skeleton (no trigger)
-
-Pure skeleton: `root` definition, empty `nodes: []`, empty `edges: []`. The primary trigger is the triggers plugin's responsibility at T02.
-
-### Minimal variant (no description)
-
-When `description` is absent in the T01 input, emit `description: ""` (always-emit so downstream consumers read a consistent shape).
-
-```json
-{
-    "root": {
-        "id": "root",
-        "name": "<name>",
-        "type": "case-management:root",
-        "caseIdentifier": "<case-identifier — defaults to <name>>",
-        "caseAppEnabled": <true|false — defaults to false>,
-        "caseIdentifierType": "<constant|external — defaults to constant>",
-        "version": "v19",
-        "publishVersion": 2,
-        "data": {
-            "intsvcActivityConfig": "v2",
-            "uipath": {
-                "variables": {
-                    "inputOutputs": []
-                },
-                "bindings": []
-            }
-        },
-        "description": ""
-    },
-    "nodes": [],
-    "edges": []
-}
-```
-
-### With description
-
-Same as above with `description` value populated from sdd.md:
-
-```json
-{
-    "root": {
-        "id": "root",
-        "name": "<name>",
-        "type": "case-management:root",
-        "caseIdentifier": "<case-identifier>",
-        "caseAppEnabled": <true|false>,
-        "caseIdentifierType": "<constant|external>",
-        "version": "v19",
-        "publishVersion": 2,
-        "data": {
-            "intsvcActivityConfig": "v2",
-            "uipath": {
-                "variables": {
-                    "inputOutputs": []
-                },
-                "bindings": []
-            }
-        },
-        "description": "<description>"
-    },
-    "nodes": [],
-    "edges": []
-}
-```
-
-## Recipe (v20) — Skeleton (no trigger)
+## Recipe — Skeleton (no trigger)
 
 Pure skeleton: top-level fields + `metadata` block + empty `bindings: []` + empty `variables` + empty `nodes: []` + empty `edges: []` + empty `layout: {}`. Primary trigger is the triggers plugin's responsibility at T02.
 
@@ -254,7 +164,7 @@ Pure skeleton: top-level fields + `metadata` block + empty `bindings: []` + empt
 ```json
 {
     "id": "case-aBcDeFgHiJ",
-    "version": "20.0.0",
+    "version": "23.0.0",
     "name": "<name>",
     "metadata": {
         "caseIdentifier": "<case-identifier — defaults to <name>>",
@@ -262,6 +172,7 @@ Pure skeleton: top-level fields + `metadata` block + empty `bindings: []` + empt
         "caseAppEnabled": <true|false — defaults to false>,
         "publishVersion": 2,
         "caseUnifiedSchemaEnabled": true,
+        "caseDirectlyPassTaskOutputs": <true|false — defaults to true>,
         "intsvcActivityConfig": "v2"
     },
     "bindings": [],
@@ -283,7 +194,7 @@ Adds top-level `description` field (NOT inside `metadata`):
 ```json
 {
     "id": "case-aBcDeFgHiJ",
-    "version": "20.0.0",
+    "version": "23.0.0",
     "name": "<name>",
     "description": "<description>",
     "metadata": {
@@ -292,6 +203,7 @@ Adds top-level `description` field (NOT inside `metadata`):
         "caseAppEnabled": <true|false>,
         "publishVersion": 2,
         "caseUnifiedSchemaEnabled": true,
+        "caseDirectlyPassTaskOutputs": <true|false — defaults to true>,
         "intsvcActivityConfig": "v2"
     },
     "bindings": [],
@@ -306,11 +218,13 @@ Adds top-level `description` field (NOT inside `metadata`):
 }
 ```
 
-> **`intsvcActivityConfig` always emitted in v20** — set `metadata.intsvcActivityConfig: "v2"` on every v20 caseplan. Mirrors the v19 `root.data.intsvcActivityConfig` field, relocated under `metadata`.
+> **`intsvcActivityConfig` always emitted** — set `metadata.intsvcActivityConfig: "v2"` on every caseplan.
+>
+> **`caseDirectlyPassTaskOutputs` always emitted** — write `metadata.caseDirectlyPassTaskOutputs` on every caseplan, value from the T01 `directly-pass-task-outputs` field (defaults to `true` when sdd.md is silent). When `true`, task outputs pass directly through messages instead of shared variables, fixing race conditions on task outputs in cases with parallel tasks. Emit `false` only when sdd.md explicitly requests it.
 
 ## caseIdentifier — constant vs external
 
-Set `caseIdentifierType` from the T01 `identifier-type` (default `constant`); same field in v19 (`root.*`) and v20 (`metadata.*`).
+Set `caseIdentifierType` from the T01 `identifier-type` (default `constant`); lives under `metadata.*`.
 
 - **`constant`** — write the literal prefix from sdd.md (`"caseIdentifier": "LOAN"`).
 - **`external`** — copy the T01 `case-identifier` expression **verbatim** into `caseIdentifier` (e.g. `"=vars.poNumber"` or `` "=js:`${metadata.InstanceId}-${vars.region}`" ``). Do NOT transform or `=js:`-wrap it — unlike task-input sinks ([bindings-and-expressions.md](../../bindings-and-expressions.md)), this value is written as authored. Valid forms + variable eligibility: [planning.md § External identifier value](planning.md).
@@ -319,8 +233,7 @@ Set `caseIdentifierType` from the T01 `identifier-type` (default `constant`); sa
 
 - Indent: 4 spaces.
 - Trailing newline: single `\n` at end of file.
-- Key order (v19 root): `id, name, type, caseIdentifier, caseAppEnabled, caseIdentifierType, version, publishVersion, data, description`.
-- Key order (v20 top-level): `id, version, name, description, metadata, bindings, variables, nodes, edges, layout`.
+- Key order: `id, version, name, description, metadata, bindings, variables, nodes, edges, layout`.
 
 Use the Write tool. File did not exist before — Edit does not apply.
 
@@ -328,42 +241,22 @@ Use the Write tool. File did not exist before — Edit does not apply.
 
 Cheap sanity checks only — full validation runs after all plugins are done, per SKILL.md Anti-patterns ("Do NOT validate after each command").
 
-### v19
-
-1. **File parses.** `JSON.parse(readFile('caseplan.json'))` succeeds.
-2. **Root shape.**
-   - `root.id === "root"`
-   - `root.type === "case-management:root"`
-   - `root.version === "v19"`
-   - `root.publishVersion === 2`
-   - `root.data.intsvcActivityConfig === "v2"`
-   - `root.data.uipath.variables.inputOutputs` is an array (empty at T01)
-   - `root.data.uipath.bindings` is an array (empty at T01)
-3. **Empty node/edge arrays.**
-   - `nodes` is an array of length 0
-   - `edges` is an array of length 0
-
-### v20
-
 1. **File parses.** `JSON.parse(readFile('caseplan.json'))` succeeds.
 2. **Top-level shape.**
    - `id` matches `^case-[A-Za-z0-9]{10}$`
-   - `version === "20.0.0"`
+   - `version === "23.0.0"`
    - `metadata.caseUnifiedSchemaEnabled === true`
    - `metadata.publishVersion === 2`
    - `metadata.intsvcActivityConfig === "v2"`
+   - `typeof metadata.caseDirectlyPassTaskOutputs === "boolean"` (present; `true` unless sdd.md requested `false`)
    - `bindings` is an array of length 0
    - `variables.inputs`, `variables.outputs`, `variables.inputOutputs` are all arrays of length 0
 3. **Empty node/edge arrays + layout.**
    - `nodes` is an array of length 0
    - `edges` is an array of length 0
    - `layout` is an object (may be `{}`)
-4. **No v19 leakage.**
-   - No `root` key at top level
-   - No `version === "v19"` anywhere
-   - No `data.intsvcActivityConfig` (v20 emits it under `metadata`, not `data`)
 
 If any check fails, halt and report — do not proceed to downstream plugins.
 
-**Do NOT run `uip maestro case validate` here.** A case-only caseplan will fail validation by design (no stage nodes, trigger has no outgoing edges). Validation runs once after the full build (SKILL.md Anti-patterns — "Do NOT validate after each command"). Pre-build validate is informational only, regardless of schema.
+**Do NOT run `uip maestro case validate` here.** A case-only caseplan will fail validation by design (no stage nodes, so the case cannot be entered). Validation runs once after the full build (SKILL.md Anti-patterns — "Do NOT validate after each command"). Pre-build validate is informational only, regardless of schema.
 

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

@@ -15,6 +15,7 @@ Always. This plugin is invoked for the very first T-entry (`T01`) in every `task
 | `case-identifier` | sdd.md (optional; defaults to `name`) | The runtime identifier. |
 | `identifier-type` | sdd.md (optional; default `constant`) | `constant` \| `external`. Use `external` when sdd.md says the identifier comes from an upstream system. |
 | `case-app-enabled` | sdd.md (default `false`) | `true` if the sdd.md says the case is exposed via the Case App UI. |
+| `directly-pass-task-outputs` | sdd.md (default `true`) | Passes task outputs through messages instead of shared variables, avoiding parallel-task race conditions. `false` only if sdd.md explicitly requests shared-variable passing. |
 | `description` | sdd.md case description |  |
 
 ## identifier-type Guidance
@@ -49,9 +50,10 @@ The case plugin writes a pure skeleton at T01 — no trigger node. The primary t
 - case-identifier: "<identifier>"
 - identifier-type: constant
 - case-app-enabled: false
+- directly-pass-task-outputs: true
 - description: "<one-sentence description>"
 - order: first
-- verify: Confirm caseplan.json written and parses; root.id == "root", nodes == [], edges == []
+- verify: Confirm caseplan.json written and parses; id matches /^case-[A-Za-z0-9]{10}$/, version == "23.0.0", nodes == [], edges == []
 ```
 
 > **External variant.** Replace the two identifier lines with `identifier-type: external` + `case-identifier: "=vars.<varId>"` (or a `=js:` expression). See § External identifier value.

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

@@ -2,13 +2,9 @@
 
 > **Phase split.** Phase 3 only. Phase 2 does not write conditions. See [`../../../phased-execution.md`](../../../phased-execution.md).
 
-Write the case-exit condition directly into the schema-appropriate location in `caseplan.json`. No CLI command needed.
+Write the case-exit condition directly into `metadata.caseExitRules[]` in `caseplan.json`. No CLI command needed.
 
-> **Schema-dependent destination + field name.** Read `Schema:` header from `tasks.md` per Rule 18.
-> - **v19** → array key is `caseExitConditions`, lives under `root.caseExitConditions` (sibling of `data`, `description`, `caseIdentifier`).
-> - **v20** → array key is **`caseExitRules`** (renamed), lives under `metadata.caseExitRules` (top-level `metadata`).
->
-> Plugin folder name `case-exit-conditions` follows the *concept* (case exit conditions), unchanged across schemas. Only the on-disk path and field name change. Do NOT place at the JSON top level under either schema.
+> **Destination + field name.** Array key is `caseExitRules`, lives under `metadata.caseExitRules` (top-level `metadata`). Plugin folder name `case-exit-conditions` follows the *concept*; the on-disk field is `caseExitRules`. Do NOT place at the JSON top level.
 
 ## Condition JSON Shape
 
@@ -33,14 +29,10 @@ Rules use DNF — outer array is OR, inner array is AND.
 
 1. Generate condition ID: `Condition_` + 6 alphanumeric chars
 2. Generate rule ID: `Rule_` + 6 alphanumeric chars
-3. Read `caseplan.json`. Read `Schema:` header from `tasks.md`.
-   - **v19** → locate the `root` object. Initialize `root.caseExitConditions = []` if absent.
-   - **v20** → locate top-level `metadata` object (initialize `metadata: {}` if missing — should already exist from T01). Initialize `metadata.caseExitRules = []` if absent.
+3. Read `caseplan.json`. Locate top-level `metadata` object (initialize `metadata: {}` if missing — should already exist from T01). Initialize `metadata.caseExitRules = []` if absent.
 4. Read `rule-type` and `marks-case-complete` from tasks.md; pick the recipe below
-5. Set `displayName`: use tasks.md `display-name` if present; else default by `marks-case-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 the schema-appropriate array whose `marksCaseComplete` 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`.
-6. Append the condition object to the schema-appropriate array:
-   - **v19** → `root.caseExitConditions[]`
-   - **v20** → `metadata.caseExitRules[]`
+5. Set `displayName`: use tasks.md `display-name` if present; else default by `marks-case-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 `metadata.caseExitRules[]` whose `marksCaseComplete` 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`.
+6. Append the condition object to `metadata.caseExitRules[]`
 
 ## Rule Types
 
@@ -68,9 +60,9 @@ Requires `marksCaseComplete: false`. Swap `rule` to `selected-stage-exited` for
 
 ### 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. **Root-scoped: `elementId = root-<ruleId>` on BOTH `uipath.inputs[]` and `uipath.outputs[]`** (not a stage id; the input `body` gets it too, not only the outputs). Valid for both `marksCaseComplete: true` and `false`. `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. **Root-scoped: `elementId = root-<ruleId>` on BOTH `uipath.inputs[]` and `uipath.outputs[]`** (not a stage id; the input `body` gets it too, not only the outputs). Valid for both `marksCaseComplete: true` and `false`. `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 `root-<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 `root-<ruleId>` on every output entry. Skip when the rule has no `uipath.outputs[]` (stub placeholder).
 
 ## Rule-Type × marksCaseComplete Matrix
 
@@ -82,14 +74,10 @@ Write `rule.uipath` per [connector-trigger-common.md § Target: connector-bound
 | `false` | `selected-stage-exited` | `selectedStageId` |
 | `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); 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).
+`conditionExpression` is optional on every rule — add it to any rule to further gate when it fires. Use bare `=js:<expr>` (no outer parens); combined boolean expressions wrap each sub-clause in parens: `=js:(vars.X === 'foo') && (vars.Y > 5)`. Use strict `===` / `!==`, never loose `==` / `!=` — normalize SDD shorthand like `approved == true` to `=js:vars.approved === true` (do not transcribe `==` verbatim). Full per-sink rule: [bindings-and-expressions.md § Canonical form per sink](../../../bindings-and-expressions.md#canonical-form-per-sink).
 
 ## Post-Write Verification
 
-Confirm the schema-appropriate array contains the new object with `id`, non-empty `displayName` (SDD value or `Complete Rule {N}` / `Exit Rule {N}` default keyed to `marksCaseComplete`), `marksCaseComplete` matching the T-entry, and `rules` carrying the expected `rule` value plus any required side field:
-- **v19** → `root.caseExitConditions[]`
-- **v20** → `metadata.caseExitRules[]`
+Confirm `metadata.caseExitRules[]` contains the new object with `id`, non-empty `displayName` (SDD value or `Complete Rule {N}` / `Exit Rule {N}` default keyed to `marksCaseComplete`), `marksCaseComplete` matching the T-entry, and `rules` carrying the expected `rule` value plus any required side field. Verify no `root` key exists at the top level.
 
-Verify NO leakage: in v19 mode there is no `metadata.caseExitRules`; in v20 mode there is no `root` key at all.
-
-For `wait-for-connector`: verify `rule.uipath.serviceType` is `"Intsvc.WaitForEvent"`, `rule.uipath.context[]` is populated (placeholders substituted), inputs/outputs `elementId` is `root-<ruleId>`, and ConnectionId + FolderKey root bindings exist. CLI `validate` does NOT check `rule.uipath` — confirm via Studio Web.
+For `wait-for-connector`: verify `rule.uipath.serviceType` is `"Intsvc.WaitForEvent"`, `rule.uipath.context[]` is populated (placeholders substituted), inputs/outputs `elementId` is `root-<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/conditions/stage-entry-conditions/impl-json.md

@@ -27,6 +27,8 @@ Write the stage-entry condition directly to the target stage's `data.entryCondit
 
 Rules use DNF — outer array is OR, inner array is AND.
 
+> **One row = one condition object.** Each entry-condition row in tasks.md/SDD maps to a **separate** object in `entryConditions[]`. Never merge multiple rows into a single condition's `rules` AND group.
+
 ## Procedure
 
 1. Generate condition ID: `Condition_` + 6 alphanumeric chars
@@ -35,7 +37,7 @@ Rules use DNF — outer array is OR, inner array is AND.
 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[]`
+7. Append the condition object to `stageNode.data.entryConditions[]`. **When the table has multiple rows, repeat steps 1–7 once per row** — append one condition object per row. Never fold multiple rows into a single condition's `rules` group.
 
 ## Rule Types
 
@@ -69,9 +71,9 @@ Fires when an upstream stage exits via a `wait-for-user` exit condition and the
 
 ### 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)).
+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>`, 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).
 
 ## Rule-Type Catalog
 
@@ -83,8 +85,8 @@ Write `rule.uipath` per [connector-trigger-common.md § Target: connector-bound
 | `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.
+`conditionExpression` is optional on every rule — add it to any rule to further gate when it fires. **Use strict `===` / `!==`, never loose `==` / `!=` — normalize SDD shorthand like `approved == true` to `=js:vars.approved === true` (do not transcribe `==` verbatim).** 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.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.
+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. 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/conditions/stage-entry-conditions/planning.md

@@ -39,6 +39,8 @@ Allowed `ruleType` values and when to pick each:
 
 `is-interrupting: true` means the condition can fire **while another stage is active** and will interrupt it. Use for exception/interrupt flows.
 
+> **First-stage start — `case-entered` is the case-start signal (edges retired).** With edges gone, there is no Trigger→first-stage edge; the case begins at the stage whose entry condition is `case-entered`. **At least one regular stage must carry `case-entered`**, or the case can never start. The sdd.md's first stage normally declares it — emit it verbatim. If NO stage declares `case-entered`, flag to the user via AskUserQuestion; do NOT silently inject one (Rule 2 — trust the sdd.md, no gap-fill). The reachability walk in [`sdd-generation-rules.md` § Logical integrity](../../../sdd-generation-rules.md) treats a case with no `case-entered` stage as a blocking orphan.
+
 ## 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.

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

@@ -38,7 +38,7 @@ Rules use DNF — outer array is OR, inner array is AND.
 
 | `type` | When to pick |
 |---|---|
-| `exit-only` | Default — stage exits normally along configured edges |
+| `exit-only` | Default — stage exits normally; next stage resolves via entry conditions (or `exitToStageId` when set). No edges. |
 | `wait-for-user` | Manual user decision required |
 | `return-to-origin` | Rework / exception loop — sends the case back to the previous stage |
 
@@ -70,9 +70,9 @@ Rules use DNF — outer array is OR, inner array is AND.
 
 ### 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)).
+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>`, 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).
 
 ### wait-for-user — manual decision gate
 
@@ -103,8 +103,8 @@ Routes the case back to the originating stage.
 | `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).
+`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)`. **Use strict `===` / `!==`, never loose `==` / `!=` — normalize SDD shorthand like `approved == true` to `=js:vars.approved === true` (do not transcribe `==` verbatim).** 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.
+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. 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.

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

@@ -31,7 +31,7 @@ Every stage with an **Exit Condition** declared in sdd.md gets its own stage-exi
 
 | Exit `type` | When to pick |
 |-------------|--------------|
-| `exit-only` | **Default.** Stage exits normally along configured edges. |
+| `exit-only` | **Default.** Stage exits normally; the next stage is whichever one's entry condition matches (or `exit-to-stage-id` when set). No edges — routing is condition-driven. |
 | `wait-for-user` | Exit requires manual user decision or approval. |
 | `return-to-origin` | Rework / exception loop — sends the case back to the previous stage. |