@uipath/skills 1.199.0 → 1.200.0

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

@@ -1,8 +1,8 @@
 # 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).
+> **Phase split.** Phase 2 writes the condition. A `wait-for-connector` rule gets the canonical stub; Phase 3 Step 10.5 upgrades only its `uipath` when resolved. See [`../../../phased-execution.md`](../../../phased-execution.md).
 
-Write the task-entry condition directly to the target task's `entryConditions[]`. No CLI command needed.
+Write the Phase 2 task-entry condition directly to the target task's `entryConditions[]`; this initial write needs no CLI call. Step 10.5 handles the separate connector-rule upgrade.
 
 ## Condition JSON Shape
 
@@ -57,7 +57,7 @@ Rules use DNF — outer array is OR, inner array is AND.
 ]]
 ```
 
-`selectedTasksIds` is a JSON string array.
+`selectedTasksIds` is a JSON string array. Resolve only tasks in the same stage whose entry conditions are not `adhoc`. If a selected task is ad-hoc/manual, stop and repair the plan: required downstream flow cannot depend on optional user-launched work.
 
 ### adhoc — expression gate
 
@@ -75,9 +75,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>`.** `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)).
+In Phase 2, always write the canonical stub from [connector-trigger-common.md § Condition-rule phase contract](../../../connector-trigger-common.md#condition-rule-phase-contract), regardless of connector resolution. In Phase 3 Step 10.5, a resolved connector replaces only `rule.uipath`; final inputs/outputs use the owning stage's `elementId = <stageId>-<ruleId>` (not the task ID). Preserve the optional `conditionExpression`.
 
-**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 output binding.** Defer it with the stub. After the Phase 3 upgrade produces real outputs, dispatch them 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), before root bindings. `elementId` stays `<stageId>-<ruleId>`.
 
 ### runs-sequentially — sequential task chain
 
@@ -85,7 +85,19 @@ Write `rule.uipath` per [connector-trigger-common.md § Target: connector-bound
 "rules": [[ { "id": "rxxxxxxxx", "rule": "runs-sequentially" } ]]
 ```
 
-**Frontend toggle semantics:** The sequential toggle writes this rule as the task's only entry condition. Preserve the task's order in the stage's `data.tasks` structure. On the first task in the chain, `runs-sequentially` means the current stage was entered; on subsequent tasks, it means the preceding task completed. Do not use lane-sharing, `selected-tasks-completed`, or an additional `current-stage-entered` rule to express this sequence.
+**Frontend toggle semantics:** The sequential/ordered-task-set rule is the task's only entry condition for strict sequences and for parallel siblings that start after an immediate predecessor. Preserve the task's order in the stage's `data.tasks` structure. A strict chain uses consecutive single-task inner arrays (`[[A], [B], [C]]`); explicitly parallel siblings after the same predecessor share one later inner array (`[[A], [B, C], [D]]`) and each sibling carries `runs-sequentially`. On the first task set, `runs-sequentially` means the current stage was entered; on subsequent task sets, it means the preceding task set completed. Do not use `selected-tasks-completed` or an additional `current-stage-entered` rule to express immediate-predecessor sequencing.
+
+### sla-status-change — the `start-task` SLA response
+
+```json
+"rules": [[ { "id": "rxxxxxxxx", "rule": "sla-status-change", "slaId": "sla_aB3kL9Qx" } ]]
+```
+
+The task fires when the referenced SLA changes status — the direct shape for a `start-task` response ([sla-response-shapes.md](../../../sla-response-shapes.md)): the follow-up task lives in the breached stage and activates on the SLA event itself, so no stage re-entry is involved and the stage's other tasks do not re-run. Resolve `slaId` (and an at-risk `escalationId`) against the objects already written in Phase 2 Step 11. Reference the stage's **own** SLA for a stage-scoped response, or `root`'s for a case-scoped one.
+
+`slaId` alone is a **breach** rule; add a concrete at-risk `escalationId` declared on that same SLA for an at-risk rule. Never the `"any"` sentinel. Verified valid on uip 1.198.0-preview.102 for both stage-owned and root SLAs.
+
+When a *stage* should take the case instead, the rule goes on the stage's `entryConditions` ([stage-entry-conditions/impl-json.md](../stage-entry-conditions/impl-json.md)) — that is `enter-stage`, not `start-task`.
 
 ## Rule-Type Catalog
 
@@ -96,9 +108,10 @@ Write `rule.uipath` per [connector-trigger-common.md § Target: connector-bound
 | `wait-for-connector` | `uipath` connector configuration (see [common](../../../connector-trigger-common.md#target-connector-bound-condition-rule)) |
 | `adhoc` | — |
 | `runs-sequentially` | — |
+| `sla-status-change` | `slaId`; optional at-risk `escalationId` on that same SLA |
 
 `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. 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.
+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`, Phase 2 expects the exact stub; after Phase 3, a resolved rule must have no `"placeholder"` values, use the owning stage's `<stageId>-<ruleId>` on inputs/outputs, and carry root bindings. A remaining stub must map to a reported unresolved connector.

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

@@ -17,9 +17,13 @@ Every task in sdd.md that declares an **Entry Condition** row gets its own task-
 | Field | Source | Notes |
 |-------|--------|-------|
 | `<stage-id>`, `<task-id>` | Captured from prior steps | |
+| `rationale` | sdd.md task Design Rationale | Required reviewer context for the activation/sequencing choice. Not emitted into caseplan JSON. |
 | `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 |
+| `sla-target` | `sla-status-change` arg 1 | `"root"` (case-level SLA) or the SLA-owning stage name — normally the stage containing this task. Scopes the lookups below to that one SLA table. Required for `sla-status-change` |
+| `sla-display-name` | `sla-status-change` arg 2 — the target's SDD `SLA Title` (or a Variable SLA Rules `Display Name`) | Target-unique SLA rule title; resolves to the SLA rule ID emitted from §4.8 during Phase 2. Required |
+| `escalation-display-name` | `sla-status-change` arg 3 — a `Display Name` from that target's SDD escalation table | Target-unique **at-risk** escalation title; resolves to its escalation ID. **At-risk only** — omit for a breach response, which references the SLA alone ([sla-response-shapes.md § Status](../../../sla-response-shapes.md)) |
 | `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). |
@@ -29,10 +33,11 @@ Every task in sdd.md that declares an **Entry Condition** row gets its own task-
 | 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` |
+| `selected-tasks-completed` | Fires when specific non-adhoc 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. This controls task activation only; choose the task type separately from what the task does. | `conditionExpression` (optional) |
 | `runs-sequentially` | Sequential tasks run in the order they appear in the stage from top to bottom. The frontend toggle writes this rule as the task's entry condition. | `conditionExpression` (optional) |
+| `sla-status-change` | Fires when a referenced case/stage SLA changes status — the `start-task` SLA response ([sla-response-shapes.md](../../../sla-response-shapes.md)) | `sla-target`, `sla-display-name`, and (at-risk only) `escalation-display-name` |
 
 ### Frontend task-mode mapping
 
@@ -40,19 +45,45 @@ The Case App selector has three distinct modes:
 
 | UI mode | JSON/task-entry meaning | Required behavior |
 |---|---|---|
-| Sequential | `runs-sequentially` only | Preserve the frontend's ordered `data.tasks` structure. Parallel task sets remain allowed; the first sequential task starts when the stage is entered, and later sequential tasks use the upstream-task completion trigger represented by the preserved task-set/order structure. |
+| Sequential | `runs-sequentially` only | Preserve the frontend's ordered `data.tasks` structure. A strict chain is consecutive single-task sets (`[[A], [B], [C]]`); explicit parallel siblings after the same predecessor share one later set (`[[A], [B, C], [D]]`) and each member of that set also uses `runs-sequentially` so it starts when the previous task set completes. The first sequential task starts when the stage is entered, and later sequential tasks use the upstream-task-set completion trigger represented by the preserved task-set/order structure. |
 | Event-triggered | An authored event/condition, normally `wait-for-connector` for an external event | Do not add `runs-sequentially`. A stage-entered task is not automatically an event-triggered task; retain the explicit event rule and its connector configuration. |
 | Manually-triggered (adhoc) | `adhoc` only | Set `isRequired: false`; the user launches it from the Case App. Do not add another entry event or treat it as sequential. Do not change the task type merely because it is manual. |
 
+> **`event-triggered` classifies the entry rule, not the task type.** `wait-for-connector` is both a task type and a rule type. A task whose **entry rule** is the connector event is `event-triggered` and must not carry `runs-sequentially`. A task **typed** `wait-for-connector` (or `execute-connector-activity`) whose entry is positional keeps its connector event in its own `data`, and its entry rule follows its activation mode: `current-stage-entered` when it arms on stage entry, or `runs-sequentially` when it must arm only after a predecessor creates the obligation (`activation-mode: parallel-after-predecessor`). Arm listeners and clocks when the obligation is created, not after the response is expected.
+
 `adhoc` is task-entry-only. It is never a stage entry rule, never a case trigger, never a substitute for `wait-for-connector`, and never the way to model a user-selected interrupting lane. Use a secondary stage with `user-selected-stage` for that.
 
-For generated SDDs, a plain immediate-predecessor chain should already be authored as `runs-sequentially`. If a task row says `selected-tasks-completed("<previous task>")`, preserve it only when the SDD is intentionally expressing a condition/event-driven sibling gate, branch convergence, or non-immediate dependency.
+While authoring a new SDD, any requirement that says `then`, `after`, `before`, `in order`, or otherwise declares an immediate dependency should be authored as `runs-sequentially` on every task in that run. Do not convert it to parallel `current-stage-entered` tasks merely because no data binding links them. Use parallel mode only when the rationale says the tasks are independent. **Phase 1 does not re-author a supplied or approved SDD:** if its task row explicitly says `selected-tasks-completed("<previous task>")`, preserve that exact rule and selector even when the selected task is immediately previous.
+
+## Phase 1 Plan Presentation Contract
+
+The task T-entry in `tasks.md §4.6` must already expose the task mode before this condition T-entry is created:
+
+```markdown
+- activation-mode: sequential
+- entry-rule: runs-sequentially
+```
+
+This pair lives on the task's own §4.6 T-entry, not on this condition T-entry. This file's own entry format below uses `rule-type:`, not `entry-rule:` — the two fields are not interchangeable and belong to two different T-entries. Writing `rule-type:` here does NOT retroactively satisfy the §4.6 requirement; if the task's own T-entry is missing `entry-rule:`, go back and add it there.
+
+For every task-entry-condition T-entry, verify the task's `activation-mode` and this condition's `rule-type` agree:
+
+| activation-mode | Allowed rule-type |
+|---|---|
+| `sequential` | `runs-sequentially` |
+| `parallel` | `current-stage-entered` |
+| `event-triggered` | `wait-for-connector` or another explicitly authored event/condition rule |
+| `adhoc` | `adhoc` |
+| `fan-in` | `selected-tasks-completed` with multiple selected tasks or an explicit convergence rationale |
+| `conditional-gate` | `selected-tasks-completed` with a branch/non-immediate dependency rationale, or the explicitly authored gate rule |
+
+During Phase 0 authoring, a plain immediate ordered run with no fan-in, branch, event, or non-immediate dependency rationale should be modeled as `activation-mode: sequential` with `rule-type: runs-sequentially`. During Phase 1, never use that heuristic to rewrite an explicit supplied/approved SDD row: preserve `selected-tasks-completed` and its selector as `conditional-gate` or `fan-in`, including when all tasks are placeholders.
 
 ## Ordering
 
 Task entry conditions are created **after** all tasks in the stage have been added (so `selected-tasks-ids` can resolve).
 
-For sequential tasks, preserve the frontend's ordered `data.tasks` structure, including any parallel task sets; do not flatten the stage into one global chain. Add one `runs-sequentially` entry condition to each sequential task. The first task uses the rule as its stage-entry trigger; later tasks use it as the upstream-task-completed trigger. Do not add a separate `current-stage-entered` condition to the first sequential task. Lane or task-set placement is structural; the entry rule carries the sequential intent.
+For sequential tasks, preserve the frontend's ordered `data.tasks` structure, including any explicitly parallel sibling sets; do not flatten the stage into one global chain and do not group a strict chain into one inner array. Add one `runs-sequentially` entry condition to each sequential task. The first task uses the rule as its stage-entry trigger; later tasks use it as the upstream-task-set-completed trigger. Do not add a separate `current-stage-entered` condition to the first sequential task. Lane or task-set placement is structural; the entry rule carries the sequential intent.
 
 ## tasks.md Entry Format
 
@@ -60,6 +91,8 @@ For sequential tasks, preserve the frontend's ordered `data.tasks` structure, in
 ## T<n>: Add task-entry condition for "<task>" in "<stage>" — <summary>
 - target-stage: "<stage-name>"
 - target-task: "<task-name>"
+- activation-mode: sequential | parallel | event-triggered | adhoc | fan-in | conditional-gate
+- rationale: "<why this activation/sequencing mode fits>"
 - 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>"

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

@@ -4,7 +4,7 @@ direct-json: supported
 
 # sla — JSON Implementation
 
-> **Phase split.** Phase 3 only. Phase 2 does not write SLA or escalation rules. See [`../../phased-execution.md`](../../phased-execution.md).
+> **Phase split.** Phase 2 Step 11 writes SLA and escalation objects before conditions. Phase 3 does not revisit them except for whole-file `$xref` resolution. See [`../../phased-execution.md`](../../phased-execution.md).
 
 Cross-cutting direct-JSON rules live in [`case-editing-operations.md`](../../case-editing-operations.md).
 
@@ -22,10 +22,10 @@ Compose the `slaRules[]` array for each target (root or stage) in one write. Gro
 
 ## ID generation
 
+- SLA rule (default and conditional): `sla_` + 8 chars. **Required** on every entry.
 - Escalation: `esc_` + 6 chars. Per [`case-editing-operations.md § ID Generation`](../../case-editing-operations.md#id-generation).
-- Conditional SlaRuleEntry: **no `id` field**. Removal is by array index.
 
-Record every `T<n> → esc_xxxxxx` in `id-map.json` under `{kind: "escalation", ruleExpression: "<parent rule expression>", target: "root" | "<stageId>"}`.
+Mint these IDs while composing the Phase 2 objects, check them against existing caseplan/id-map IDs, and record them immediately: every SLA T-entry under `{kind: "sla-rule", displayName: "<title>", target: "root" | "<stageId>"}` and every escalation under `{kind: "escalation", displayName: "<title>", parentSlaTask: "T<m>", target: "root" | "<stageId>"}`. Write the object and its `id-map.json` entry in the same section. There is no preallocation-only pass.
 
 ## Target resolution
 
@@ -45,6 +45,7 @@ After grouping T-entries by target, compose the `slaRules` array and write it in
 ```json
 [
   {
+    "id": "sla_aB3kL9Qx",
     "displayName": "SLA Rule 1",
     "expression": "=js:<translated-condition-1>",
     "count": <n>, "unit": "<min|h|d|w|m>",
@@ -52,6 +53,7 @@ After grouping T-entries by target, compose the `slaRules` array and write it in
   },
   { "...additional conditional rules in sdd order..." },
   {
+    "id": "sla_Np4rT7Vz",
     "displayName": "SLA Rule 2",
     "expression": "=js:true",
     "count": <default.count>, "unit": "<default.unit>",
@@ -65,7 +67,7 @@ After grouping T-entries by target, compose the `slaRules` array and write it in
 ```json
 {
   "id": "case-aBcDeFgHiJ",
-  "version": "23.0.0",
+  "version": "27.0.0",
   "metadata": {
     "caseIdentifier": "<...>",
     "caseUnifiedSchemaEnabled": true,
@@ -86,16 +88,17 @@ Emission rules:
 
 1. **Conditional rules first, in T-entry order.** Priority = sdd order (top-most wins).
 2. **Default rule (`=js:true`) last.** Always emitted when any SLA T-entry targets this node — even escalation-only cases.
-3. **Escalation-only default rule is legal, but it still needs a title.** If a target has escalations but no default SLA T-entry, emit `{displayName:"SLA Rule 1", expression:"=js:true", escalationRule:[…]}` with no `count` / `unit`.
+3. **Escalation-only default rule is legal, but it still needs an ID and title.** If a target has escalations but no default SLA T-entry, Step 11 directly emits `{id:"sla_...", displayName:"SLA Rule 1", expression:"=js:true", escalationRule:[…]}` with no `count` / `unit`, and records that synthetic ID.
 4. **Always emit `escalationRule` on every rule.** Use `"escalationRule": []` when a rule has no attached escalations. Never omit the key.
 5. **Omit `slaRules` key entirely** on targets with no SLA T-entries.
+6. **Emit a unique `id` on every SlaRuleEntry.** `sla_` + 8 chars — **required** (schema v26). `displayName` is optional (`"Default"` for the trailing `=js:true` entry).
 
 ## Recipe — one escalation entry
 
 ```json
 {
   "id": "esc_xxxxxx",
-  "displayName": "<from T-entry or deterministic fallback>",
+  "displayName": "<from T-entry, or generated: Escalation rule <N> - <parent SLA displayName>>",
   "action": {
     "type": "notification",
     "recipients": [
@@ -109,9 +112,7 @@ Emission rules:
 }
 ```
 
-- `displayName` is required for every SLA rule and escalation in the current Case App contract. Use the authored value or deterministic fallback; never emit blank/undefined. It must be unique within the target and MUST NOT contain `:`; reject the T-entry before writing JSON if it does.
-- Reject a non-positive `count`; for `unit: "min"`, reject values below 15 or above 1000.
-- Reject a non-default rule with an empty expression, an escalation with no recipients, or an `at-risk` escalation without `atRiskPercentage`.
+- `displayName` is **required** (schema v27). Use the T-entry's `display-name` when supplied; otherwise generate `Escalation rule <N> - <parent SLA displayName>` (N = 1-based index within the parent rule's `escalationRule[]`).
 - `atRiskPercentage` included only when `triggerInfo.type === "at-risk"`.
 - `recipients` is an array — **one entry per sdd-declared recipient**.
 
@@ -123,15 +124,25 @@ Phase 1 runs the identity resolver (see [`planning.md` § Identity Resolution](p
 { "scope": "User", "target": "<UNRESOLVED: user-uuid for manager@corp.com>", "value": "manager@corp.com" }
 ```
 
-List every unresolved recipient in the completion report (per SKILL.md § Completion Output step 4) so the user can patch externally. Do not call an identity service from the JSON path — resolution is Phase 1's responsibility; Phase 3 just transcribes whatever `tasks.md` carries.
+List every unresolved recipient in the completion report (per SKILL.md § Completion Output step 4) so the user can patch externally. Do not call an identity service from the JSON path — resolution is Phase 1's responsibility; Phase 2 just transcribes whatever `tasks.md` carries.
 
 ## Expression translation
 
-`tasks.md` entries carry natural-language conditions. Translate at execution using the expression prefixes documented in [`bindings-and-expressions.md`](../../bindings-and-expressions.md). SLA rule `expression` is a boolean-condition sink — use bare `=js:<expr>` (no outer parens) per [§ Canonical form per sink](../../bindings-and-expressions.md#canonical-form-per-sink). Common patterns: `=js:vars.<id> === "<literal>"` for variable comparison, `=js:metadata.<field> === "<literal>"` for case metadata comparison, `=js:true` for the default rule, `=js:(vars.X === 'foo') && (vars.Y > 5)` for combined boolean (each sub-clause parenthesized for operator precedence). If ambiguous, AskUserQuestion with 2–3 candidates + "Something else" per SKILL.md Rule 2.
+`tasks.md` entries carry natural-language conditions. Translate at execution using the expression prefixes documented in [`bindings-and-expressions.md`](../../bindings-and-expressions.md). SLA rule `expression` is a boolean-condition sink — use bare `=js:<expr>` (no outer parens) per [§ Canonical form per sink](../../bindings-and-expressions.md#canonical-form-per-sink). Common patterns: `=js:vars.<id> === "<literal>"` for a case-variable comparison — this covers any SDD-declared field, including ones the SDD's "Case Metadata" table lists for readability (e.g. `Priority`: `=js:vars.priority === 'Urgent'`); `=js:true` for the default rule; `=js:(vars.X === 'foo') && (vars.Y > 5)` for combined boolean (each sub-clause parenthesized for operator precedence). Reserve `=js:metadata.<field>` for the closed set of structural fields in [case-schema.md § 1](../../case-schema.md#1-top-level--metadata) (e.g. `metadata.caseAppEnabled`) — it is NOT a namespace for arbitrary business data. If ambiguous, AskUserQuestion with 2–3 candidates + "Something else" per SKILL.md Rule 2.
+
+## The clock is not the response
+
+This file writes the SLA **clock** and its escalation notifications. The **response** to an at-risk / breach event is a separate decision, read off the requirement and never off the SLA's scope:
+
+- **notify-only** — an escalation entry here, and nothing else. Absent a stated response, both at-risk and breached are notify-only. Do NOT mint a stage, task, or condition for a requirement that only asks to notify someone.
+- **start-task / enter-stage** — the escalation (if any) still lives here; the behavior change is an `sla-status-change` rule on the follow-up **task** (`start-task`) or on the destination **stage** (`enter-stage`). Shapes, interrupting semantics, and the four defects `validate` cannot see: [sla-response-shapes.md](../../sla-response-shapes.md).
+- **exit-stage / exit-case** — a stage-exit or `metadata.caseExitRules[]` row.
+
+A breach rule references the SLA alone (`slaId`, no `escalationId`), so a breach response does **not** require an escalation to exist here. An at-risk response does: it needs a concrete at-risk escalation on that same SLA.
 
 ## Post-write validation
 
 - Confirm `metadata.slaRules` (root) or `node.data.slaRules` (stage) exists with the expected entries. Verify the root-target uses `metadata` — not `root.data` (which doesn't exist on disk).
 - Confirm the trailing entry's `expression === "=js:true"` when any SLA T-entry targeted this node.
-- Confirm every generated `esc_` ID appears in `id-map.json`.
-- Run `uip maestro case validate <file> --output json` after all SLA targets have been written (not per-target).
+- Confirm every emitted `sla_` and `esc_` ID appears in `id-map.json`. Step 10 must resolve every `sla-status-change` rule against IDs already emitted on the declared target.
+- Run the section-boundary validation after all SLA targets have been written (not per-target); the Phase 2 preview profile runs later after conditions.

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

@@ -17,7 +17,7 @@ Pick this plugin whenever the sdd.md mentions deadlines, service-level agreement
 |--------|---------|
 | **Default SLA** | The time-based catch-all SLA. One per target (root or stage). Written into the SLA rules array with `expression: "=js:true"`. See [impl-json.md § Target resolution](impl-json.md) for the destination paths. |
 | **Conditional SLA rules** | Expression-driven SLA overrides. Supported on root and stage targets. Prepended to the target's SLA rules array ahead of the default. |
-| **Escalation rules** | Notifications triggered at-risk or on breach. Attached to a specific rule via `escalationRule[]`. |
+| **Escalation rules** | Status markers and notifications triggered at-risk or on breach. Attached to a specific rule via `escalationRule[]`; their IDs may also drive an interrupting secondary-stage `sla-status-change` entry. |
 
 ## Applying SLA at Root vs Stage
 
@@ -41,7 +41,8 @@ Set root SLA first, then stage SLAs. This mirrors the schema precedence: stage >
 | `count` | sdd.md duration number | Positive integer |
 | `unit` | sdd.md duration unit | `min` \| `h` \| `d` \| `w` \| `m` |
 | `target` | sdd.md target (root vs stage) | `"root"` or `"<stage-name>"` |
-| `display-name` | sdd.md or generated fallback | Required non-empty SLA title, unique within the target, and MUST NOT contain `:`. If the SDD has no title, ask for one or use the deterministic fallback `SLA Rule {N}` and record it. |
+| `display-name` | sdd.md `SLA Title` (§1 Case Metadata for root; `**SLA Title:**` under `#### Stage SLA`) or generated fallback | Required non-empty SLA title, unique within the target, and MUST NOT contain `:`. Carry the SDD title verbatim. If the SDD has no title, ask for one or use the deterministic fallback `SLA Rule {N}` and record it. |
+| `rationale` | sdd.md case/stage SLA Design Rationale | Required reviewer context for the target, duration, threshold, and escalation behavior. |
 
 ### Conditional SLA rule
 
@@ -51,6 +52,7 @@ Set root SLA first, then stage SLAs. This mirrors the schema precedence: stage >
 | `expression` | sdd.md condition | Natural-language in planning; the execution phase translates. **Do not fabricate syntax during planning.** |
 | `count`, `unit` | sdd.md duration for this condition | Same units as default |
 | `display-name` | sdd.md or generated fallback | Required non-empty unique title, no `:`; use `SLA Rule {N}` only when the author supplied no title. |
+| `rationale` | sdd.md case/stage SLA Design Rationale | Required reviewer context; not emitted into JSON. |
 
 Rules are evaluated in insertion order — first truthy expression wins. The default SLA acts as the fallback.
 
@@ -63,9 +65,10 @@ Rules are evaluated in insertion order — first truthy expression wins. The def
 | `recipient-scope` | sdd.md | `User` \| `UserGroup` |
 | `recipient-target` | sdd.md → resolver | Recipient UUID. When sdd gives an email or group name, run [§ Identity Resolution](#identity-resolution) — resolved UUID written inline. On resolver failure or user decline, mark `<UNRESOLVED: user-uuid for <email>>` / `<UNRESOLVED: group-uuid for <name>>`. |
 | `recipient-value` | sdd.md | Display value (typically the email for User, group name for UserGroup). |
-| `display-name` | sdd.md or generated fallback | Required non-empty escalation title, unique across the target, and MUST NOT contain `:`. If omitted, use `Escalation Rule {N}` and record the fallback. |
+| `display-name` | sdd.md escalation-table `Display Name` cell | Required non-empty escalation title, unique across the target, and MUST NOT contain `:`. Carry the SDD title verbatim. If omitted, use `Escalation Rule {N}` and record the fallback. |
 | `target` | sdd.md target (root vs stage) | `"root"` or `"<stage-name>"` |
 | `attach-to` | sdd.md | `default` (attach to the `=js:true` rule) or `T<m>` pointing to the conditional-rule T-entry the escalation fires under. |
+| `rationale` | sdd.md case/stage SLA Design Rationale | Required reviewer context. If this escalation enters a secondary stage, name that lane and why it is global/interrupting. |
 
 ## Identity Resolution
 
@@ -146,6 +149,7 @@ SLA is the **last** category in `tasks.md` (§4.8), after conditions. For each t
 ## T<n>: Set default SLA for "<target>" to <duration>
 - target: "<root>" | "<stage-name>"
 - display-name: "SLA Rule 1"              # required; use authored title or SLA Rule {N}
+- rationale: "<why this SLA target and duration fit>"
 - count: 5
 - unit: d
 - order: after T<m>
@@ -158,6 +162,7 @@ SLA is the **last** category in `tasks.md` (§4.8), after conditions. For each t
 ## T<n>: Add conditional SLA rule for "<target>" — <condition summary>
 - target: "root" | "<stage-name>"
 - display-name: "Urgent SLA"              # required; target-unique, no ':'
+- rationale: "<why this condition changes the SLA>"
 - condition: "<natural-language condition from sdd.md>"
 - count: 30
 - unit: min
@@ -171,6 +176,7 @@ SLA is the **last** category in `tasks.md` (§4.8), after conditions. For each t
 ## T<n>: Add escalation rule for "<target>" — <trigger summary>
 - target: "<root>" | "<stage-name>"
 - attach-to: default | T<m>
+- rationale: "<why this threshold/recipient/action fits; name any interrupting secondary stage>"
 - trigger-type: at-risk
 - at-risk-percentage: 80
 - recipients:

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

@@ -4,6 +4,8 @@ direct-json: supported
 
 # stages — JSON Implementation
 
+> **Node `type` value: `case-management:Stage`** — use this exact string for both primary and secondary stages. Never write `uipath.case.stage`, `uipath.stage`, or any other variant.
+
 Cross-cutting direct-JSON rules live in [`case-editing-operations.md`](../../case-editing-operations.md).
 
 ## Input spec (from `tasks.md`)
@@ -55,6 +57,8 @@ Append (or prepend) this object to `nodes` — both orderings are valid for the
 
 ## Recipe — Secondary Stage
 
+> **A non-interrupting SLA lane is still a secondary stage.** When the lane's only entry is an `sla-status-change` response the requirement describes as parallel oversight (`is-interrupting: false`), keep `stageType: "secondary"` with `isRequired: false`. Do NOT emit it as a regular stage instead: a regular stage joins the main flow and, when required, gates case completion. `validate` accepts either shape, so this one is on you.
+
 Same as a primary Stage, with `data.stageType: "secondary"` and two additional `data` fields initialized empty:
 
 ```json

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

@@ -33,7 +33,7 @@ When ambiguous, use **AskUserQuestion** with both options + "Something else".
 No stage of either variant has edges. Reachability is expressed entirely through stage entry/exit conditions:
 
 - **Regular stage** — reached via a **non-interrupting** entry condition: `case-entered` for the first stage, or `selected-stage-completed` / `selected-stage-exited` naming a predecessor. Every regular stage MUST have ≥1 entry condition, or it is orphaned and unreachable. See [stage-entry-conditions plugin](../conditions/stage-entry-conditions/planning.md).
-- **Secondary stage** — reached via an **interrupting** entry condition (fires on case state). Returning lanes exit via `return-to-origin`; terminal lanes exit via `exit-only` plus a case-exit row. See [stage-exit-conditions plugin](../conditions/stage-exit-conditions/planning.md).
+- **Secondary stage** — reached via an **interrupting** entry condition. Global external events use one `wait-for-connector` entry; global case/stage SLA events that require case work use one `sla-status-change` entry (warning-only escalation stays a notification). Neither needs duplicated exit rules on every possible origin stage. Returning lanes exit via `return-to-origin`; terminal lanes exit via `exit-only` plus a case-exit row. See [stage-entry-conditions](../conditions/stage-entry-conditions/planning.md) and [stage-exit-conditions](../conditions/stage-exit-conditions/planning.md).
 
 Do NOT create edges for any stage. If the sdd.md describes a stage "connected via an arrow / edge" to another, model it as the target stage's entry condition (plus a source-stage exit condition when the source diverges). Onward flow from a secondary stage uses `return-to-origin`, letting the origin stage's own entry/exit conditions carry the case forward.
 
@@ -43,6 +43,7 @@ Do NOT create edges for any stage. If the sdd.md describes a stage "connected vi
 |-------|--------|-------|
 | `label` | sdd.md stage name | Shown in the UI. |
 | `type` | sdd.md intent | `stage` (default) or `secondary` — see above |
+| `rationale` | sdd.md Design Rationale | Required reviewer context explaining the stage-kind and routing choice. A global-event secondary stage states why one interrupting entry replaces per-stage duplication. Not emitted into caseplan JSON. |
 | `description` | sdd.md stage description | Optional. |
 | `isRequired` | sdd.md (default `true` for regular, `false` for secondary) | **Planning-only metadata.** See note below. |
 
@@ -73,6 +74,7 @@ Stages are created **after** the root case (T01) and **before** any tasks or con
 ```markdown
 ## T<n>: Create stage "<label>"
 - type: stage
+- rationale: "<why this is a primary stage and how it is reached/exited>"
 - description: "<description from sdd.md>"
 - isRequired: <true|false from sdd.md; false if unspecified>
 - order: after T<m>
@@ -84,6 +86,7 @@ Secondary variant:
 ```markdown
 ## T<n>: Create secondary stage "<label>"
 - type: secondary
+- rationale: "<why this is interrupting and which global/conditional event it handles>"
 - description: "<description from sdd.md>"
 - isRequired: <true|false from sdd.md; false if unspecified>
 - order: after T<m>

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

@@ -26,6 +26,7 @@
 ```
 
 - `id`: `t` + 8 alphanumeric chars. `elementId`: `${stageId}-${taskId}`.
+- `isRequired` and `shouldRunOnlyOnce` come from the SDD task envelope via `tasks.md`; default `shouldRunOnlyOnce` to `false` when omitted. Do not infer run-once from task type.
 - `data.name` / `data.folderPath` MUST be `=bindings.<id>` references — never literals.
 
 ## Action-Specific Fields
@@ -70,7 +71,7 @@ Dedup per [§ Deduplication](../../variables/bindings/impl-json.md).
 4. Write `data.inputs[]` / `data.outputs[]` from Step 0 schema. Each input: `{ name, type, id, var, elementId, value: "" }`. Each output: `{ name, type, id, var, value, source, target, elementId }`.
 
    **Output binding.** Apply [io-binding/impl-json.md § Output Binding Shapes](../../variables/io-binding/impl-json.md#output-binding-shapes). The Step 0 schema for this plugin is the `tasks describe` output (Step 0 above).
-5. Append to target stage's `tasks[laneIndex][]`
+5. Append to the target stage's `data.tasks` structure using `activation-mode` + `entry-rule`, not `lane` alone. Strict `sequential` tasks append as new single-task inner arrays in planned order. `parallel-after-predecessor` siblings share the planned same next inner array even though their entry rule is `runs-sequentially`. Adhoc, event-driven, fan-in, conditional-gate, and standalone tasks get their own single-task inner array. Only `activation-mode: parallel` or `parallel-after-predecessor` tasks with explicit same-lane intent and rationale may share `tasks[laneIndex][]`; if `lane` conflicts with mode, mode wins.
 
 > Entry conditions added in Step 10. Only `data.inputs[].value` is deferred to Phase 3 per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md); the scalar `data.*` fields above are final at Step 2.
 
@@ -82,6 +83,7 @@ Dedup per [§ Deduplication](../../variables/bindings/impl-json.md).
 - the bindings array has 2 entries: `resource: "app"`, no `resourceSubType`, `propertyAttribute` = `name` / `folderPath`
 - `data.inputs` and `data.outputs` populated (unless placeholder)
 - `data.recipient` is an **object** `{ Type, Value }`, never a bare string — present whenever tasks.md recorded a `recipient:` line (omitted only for group/role, Skip, or no-Type-maps)
+- `entryConditions` is present and non-empty — a task with no entry condition is never triggered, and `validate` does NOT catch it (it accepts an empty array and a missing key). Use the activation the T-entry declares (`current-stage-entered`, `runs-sequentially`, `adhoc`, `sla-status-change` for an SLA `start-task` response — see [sla-response-shapes.md](../../../sla-response-shapes.md))
 - `id` captured in `id-map.json`
 
 ## Anti-patterns

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

@@ -84,6 +84,8 @@ Resolved action task. For the unresolved placeholder shape, see [placeholder-tas
 - outputs:
   - <SDD output row, copied verbatim>
 - isRequired: true
+- activation-mode: <sequential|parallel|event-triggered|adhoc|fan-in|conditional-gate>   # required
+- entry-rule: <runs-sequentially|current-stage-entered|wait-for-connector|adhoc|selected-tasks-completed>   # required; must pair with activation-mode — see ../../conditions/task-entry-conditions/planning.md
 - order: after T<m>
 - lane: <n>  # structural/layout position only; sequencing is the task entry rule plus data.tasks order.
 - verify: Confirm Result: Success, capture TaskId

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

@@ -11,7 +11,7 @@
   "displayName": "Classify Purchase Order",
   "elementId": "Stage_aB3kL9-tH3kLmNp9",
   "isRequired": true,
-  "shouldRunOnlyOnce": true,
+  "shouldRunOnlyOnce": false,
   "data": {
     "name": "=bindings.bG0SraLpg",
     "folderPath": "=bindings.bH1iJK2lm",
@@ -22,6 +22,7 @@
 ```
 
 - `id`: `t` + 8 alphanumeric chars. `elementId`: `${stageId}-${taskId}`.
+- `isRequired` and `shouldRunOnlyOnce` come from the SDD task envelope via `tasks.md`; default `shouldRunOnlyOnce` to `false` when omitted. Do not infer run-once from task type.
 - `data.name` / `data.folderPath` MUST be `=bindings.<id>` references — never literals.
 
 ## Procedure
@@ -55,7 +56,7 @@ Dedup per [§ Deduplication](../../variables/bindings/impl-json.md).
 3. Write `data.inputs[]` / `data.outputs[]` from Step 0 schema. Each input: `{ name, type, id, var, elementId, value: "" }`. Each output: `{ name, type, id, var, value, source, target, elementId }`.
 
    **Output binding.** Apply [io-binding/impl-json.md § Output Binding Shapes](../../variables/io-binding/impl-json.md#output-binding-shapes). The Step 0 schema for this plugin is the `tasks describe` output (Step 0 above).
-4. Append to target stage's `tasks[laneIndex][]`
+4. Append to the target stage's `data.tasks` structure using `activation-mode` + `entry-rule`, not `lane` alone. Strict `sequential` tasks append as new single-task inner arrays in planned order. `parallel-after-predecessor` siblings share the planned same next inner array even though their entry rule is `runs-sequentially`. Adhoc, event-driven, fan-in, conditional-gate, and standalone tasks get their own single-task inner array. Only `activation-mode: parallel` or `parallel-after-predecessor` tasks with explicit same-lane intent and rationale may share `tasks[laneIndex][]`; if `lane` conflicts with mode, mode wins.
 
 > Entry conditions added in Step 10. Input value bindings in Phase 3 per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md).
 

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

@@ -17,7 +17,7 @@ Pick this plugin when the sdd.md describes a task as `AGENT` — an AI agent tha
 | `element-id` | (optional) | Required only when the agent has multiple element bindings |
 | `inputs` | sdd.md task data mapping | See [bindings-and-expressions.md](../../../bindings-and-expressions.md) |
 | `outputs` | sdd.md task Outputs + resolved schema | Follow the shared [I/O-binding output-list contract](../../variables/io-binding/planning.md#canonical-tasksmd-output-list). |
-| `runOnlyOnce` | sdd.md (default `true`) |  |
+| `runOnlyOnce` | sdd.md (default `false`) | Re-entry behavior comes from the SDD, not the task type.  |
 | `isRequired` | sdd.md (default `true`) |  |
 
 ## Registry Resolution
@@ -114,8 +114,10 @@ Shared contract — [create-inline-common.md § Failure](../create-inline-common
   - <input_name> <- "<Stage>"."<Task>".<output>
 - outputs:
   - <SDD output row, copied verbatim>
-- runOnlyOnce: true
+- runOnlyOnce: false
 - isRequired: true
+- activation-mode: <sequential|parallel|event-triggered|adhoc|fan-in|conditional-gate>   # required
+- entry-rule: <runs-sequentially|current-stage-entered|wait-for-connector|adhoc|selected-tasks-completed>   # required; must pair with activation-mode — see ../../conditions/task-entry-conditions/planning.md
 - order: after T<m>
 - lane: <n>  # structural/layout position only; sequencing is the task entry rule plus data.tasks order.
 - verify: Confirm Result: Success, capture TaskId

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

@@ -11,7 +11,7 @@
   "displayName": "Monitor Order Inbox",
   "elementId": "Stage_aB3kL9-tK7nRs3Wp",
   "isRequired": true,
-  "shouldRunOnlyOnce": true,
+  "shouldRunOnlyOnce": false,
   "data": {
     "name": "=bindings.bG0SraLpg",
     "folderPath": "=bindings.bH1iJK2lm",
@@ -22,6 +22,7 @@
 ```
 
 - `id`: `t` + 8 alphanumeric chars. `elementId`: `${stageId}-${taskId}`.
+- `isRequired` and `shouldRunOnlyOnce` come from the SDD task envelope via `tasks.md`; default `shouldRunOnlyOnce` to `false` when omitted. Do not infer run-once from task type.
 - `data.name` / `data.folderPath` MUST be `=bindings.<id>` references — never literals.
 
 ## Procedure
@@ -53,7 +54,7 @@ Dedup per [§ Deduplication](../../variables/bindings/impl-json.md).
 3. Write `data.inputs[]` / `data.outputs[]` from Step 0 schema. Each input: `{ name, type, id, var, elementId, value: "" }`. Each output: `{ name, type, id, var, value, source, target, elementId }`.
 
    **Output binding.** Apply [io-binding/impl-json.md § Output Binding Shapes](../../variables/io-binding/impl-json.md#output-binding-shapes). The Step 0 schema for this plugin is the `tasks describe` output (Step 0 above).
-4. Append to target stage's `tasks[laneIndex][]`
+4. Append to the target stage's `data.tasks` structure using `activation-mode` + `entry-rule`, not `lane` alone. Strict `sequential` tasks append as new single-task inner arrays in planned order. `parallel-after-predecessor` siblings share the planned same next inner array even though their entry rule is `runs-sequentially`. Adhoc, event-driven, fan-in, conditional-gate, and standalone tasks get their own single-task inner array. Only `activation-mode: parallel` or `parallel-after-predecessor` tasks with explicit same-lane intent and rationale may share `tasks[laneIndex][]`; if `lane` conflicts with mode, mode wins.
 
 > Entry conditions added in Step 10. Input value bindings in Phase 3 per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md).
 

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

@@ -16,7 +16,7 @@ Pick this plugin when the sdd.md labels a task as `API_WORKFLOW` — typically a
 | `task-type-id` | Registry resolution (below) | `entityKey` in `api-index.json` |
 | `inputs` | sdd.md task data mapping | See [bindings-and-expressions.md](../../../bindings-and-expressions.md) |
 | `outputs` | sdd.md task Outputs + resolved schema | Follow the shared [I/O-binding output-list contract](../../variables/io-binding/planning.md#canonical-tasksmd-output-list). |
-| `runOnlyOnce` | sdd.md (default `true`) | |
+| `runOnlyOnce` | sdd.md (default `false`) | Re-entry behavior comes from the SDD, not the task type. |
 | `isRequired` | sdd.md (default `true`) | |
 
 ## Registry Resolution
@@ -127,8 +127,10 @@ Shared contract — [create-inline-common.md § Failure](../create-inline-common
   - <input_name> = "<value>"
 - outputs:
   - <SDD output row, copied verbatim>
-- runOnlyOnce: true
+- runOnlyOnce: false
 - isRequired: true
+- activation-mode: <sequential|parallel|event-triggered|adhoc|fan-in|conditional-gate>   # required
+- entry-rule: <runs-sequentially|current-stage-entered|wait-for-connector|adhoc|selected-tasks-completed>   # required; must pair with activation-mode — see ../../conditions/task-entry-conditions/planning.md
 - order: after T<m>
 - lane: <n>  # structural/layout position only; sequencing is the task entry rule plus data.tasks order.
 - verify: Confirm Result: Success, capture TaskId

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

@@ -11,7 +11,7 @@
   "displayName": "Run Vendor Onboarding Sub-Case",
   "elementId": "Stage_aB3kL9-tZ8rMn4Vp",
   "isRequired": true,
-  "shouldRunOnlyOnce": true,
+  "shouldRunOnlyOnce": false,
   "data": {
     "name": "=bindings.bG0SraLpg",
     "folderPath": "=bindings.bH1iJK2lm",
@@ -22,6 +22,7 @@
 ```
 
 - `id`: `t` + 8 alphanumeric chars. `elementId`: `${stageId}-${taskId}`.
+- `isRequired` and `shouldRunOnlyOnce` come from the SDD task envelope via `tasks.md`; default `shouldRunOnlyOnce` to `false` when omitted. Do not infer run-once from task type.
 - `data.name` / `data.folderPath` MUST be `=bindings.<id>` references — never literals.
 
 ## Procedure
@@ -52,7 +53,7 @@ Dedup per [§ Deduplication](../../variables/bindings/impl-json.md).
 4. Write `data.inputs[]` / `data.outputs[]` from Step 0 schema. Each input: `{ name, type, id, var, elementId, value: "" }`. Each output: `{ name, type, id, var, value, source, target, elementId }`.
 
    **Output binding.** Apply [io-binding/impl-json.md § Output Binding Shapes](../../variables/io-binding/impl-json.md#output-binding-shapes). The Step 0 schema for this plugin is the `tasks describe` output (Step 0 above).
-5. Append to target stage's `tasks[laneIndex][]`
+5. Append to the target stage's `data.tasks` structure using `activation-mode` + `entry-rule`, not `lane` alone. Strict `sequential` tasks append as new single-task inner arrays in planned order. `parallel-after-predecessor` siblings share the planned same next inner array even though their entry rule is `runs-sequentially`. Adhoc, event-driven, fan-in, conditional-gate, and standalone tasks get their own single-task inner array. Only `activation-mode: parallel` or `parallel-after-predecessor` tasks with explicit same-lane intent and rationale may share `tasks[laneIndex][]`; if `lane` conflicts with mode, mode wins.
 
 > Entry conditions added in Step 10. Input value bindings in Phase 3 per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md).
 

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

@@ -21,7 +21,7 @@ If sdd.md describes a simple stage-to-stage flow within the same case, do not us
 | `task-type-id` | Registry resolution (below) | `entityKey` in `caseManagement-index.json`; mirrors sdd.md `Resource Identity` when already resolved. |
 | `inputs` | sdd.md task data mapping | Passed as case-instance inputs to the sub-case |
 | `outputs` | sdd.md task Outputs + `tasks describe` schema | Follow the shared [I/O-binding output-list contract](../../variables/io-binding/planning.md#canonical-tasksmd-output-list). |
-| `runOnlyOnce` | sdd.md (default `true`) | |
+| `runOnlyOnce` | sdd.md (default `false`) | Re-entry behavior comes from the SDD, not the task type. |
 | `isRequired` | sdd.md (default `true`) | |
 
 ## Registry Resolution
@@ -49,8 +49,10 @@ Mark `<UNRESOLVED: case "<name>" in folder "<folder>" not found in caseManagemen
   - <input_name> = "<value>"
 - outputs:
   - <SDD output row, copied verbatim>
-- runOnlyOnce: true
+- runOnlyOnce: false
 - isRequired: true
+- activation-mode: <sequential|parallel|event-triggered|adhoc|fan-in|conditional-gate>   # required
+- entry-rule: <runs-sequentially|current-stage-entered|wait-for-connector|adhoc|selected-tasks-completed>   # required; must pair with activation-mode — see ../../conditions/task-entry-conditions/planning.md
 - order: after T<m>
 - lane: <n>  # structural/layout position only; sequencing is the task entry rule plus data.tasks order.
 - verify: Confirm Result: Success, capture TaskId

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

@@ -205,7 +205,7 @@ Generate the task skeleton:
 }
 ```
 
-Append the task to the target stage's `data.tasks` structure in its planned order. Lane placement is structural/layout state; it does not express sequencing. Add `runs-sequentially` to the task's entry conditions when the frontend toggle is selected.
+Append the task to the target stage's `data.tasks` structure using `activation-mode` + `entry-rule`, not `lane` alone. Strict `sequential` tasks append as new single-task inner arrays in planned order. `parallel-after-predecessor` siblings share the planned same next inner array even though their entry rule is `runs-sequentially`. Adhoc, event-driven, fan-in, conditional-gate, and standalone tasks get their own single-task inner array. Only `activation-mode: parallel` or `parallel-after-predecessor` tasks with explicit same-lane intent and rationale may share an inner array. Add `runs-sequentially` to the task's entry conditions when the frontend toggle or ordered task-set rule is selected; if `lane` conflicts with mode, mode wins.
 
 ### Step 9 — Append root-level bindings
 

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

@@ -194,6 +194,8 @@ Populate `outputs:` using the shared [I/O-binding output-list contract](../../va
   - <SDD output row, copied verbatim>
 - isRequired: true
 - runOnlyOnce: false
+- activation-mode: <sequential|parallel|event-triggered|adhoc|fan-in|conditional-gate>   # required
+- entry-rule: <runs-sequentially|current-stage-entered|wait-for-connector|adhoc|selected-tasks-completed>   # required; must pair with activation-mode — see ../../conditions/task-entry-conditions/planning.md
 - order: after T<m>
 - lane: <n>
 - verify: tasks.md `input-values` covers every `inputs.*[?required]` from the lean spec across `bodyFields`, `queryParameters`, `pathParameters` — see Step 5 above.