@uipath/skills 1.199.0 → 1.200.0

package/skills/uipath-maestro-case/assets/templates/sdd-template.md

@@ -6,10 +6,7 @@
 
 ## Instructions for SDD Generation
 
-You are generating an **SDD — a case definition blueprint** (NOT a traditional
-solution design document). Every section maps directly to what the UiPath Case
-Designer actually consumes. A developer reading this document should be able to
-build the case in the Case Designer without guessing.
+You are generating an **SDD — a case definition blueprint** (NOT a traditional solution design document). Every section maps directly to what the UiPath Case Designer actually consumes. A developer reading this document should be able to build the case in the Case Designer without guessing.
 
 **Inputs:**
 - Phase 0 interview answers (free-text + AskUserQuestion picks) — primary source
@@ -24,7 +21,7 @@ build the case in the Case Designer without guessing.
 
 ### Key Rules
 
-1. **SLA placement:** SLA is supported on the **case**, on **stages**, and on **`action` tasks only**. Do NOT put SLA on `process`, `agent`, `rpa`, `api-workflow`, `wait-for-timer`, `wait-for-connector`, `execute-connector-activity`, or `case-management` tasks.
+1. **SLA placement and response:** SLA is supported on the **case**, on **stages**, and on **`action` tasks only**. Do NOT put SLA on `process`, `agent`, `rpa`, `api-workflow`, `wait-for-timer`, `wait-for-connector`, `execute-connector-activity`, or `case-management` tasks. Separate the SLA clock from its response: notify-only stays in escalation actions; every other response (`start-task`, `enter-stage`, `exit-stage`, `exit-case`) is explicit in the SLA Response Map, with its own interrupting decision.
 
 2. **No skip conditions:** Stage skip conditions are NOT supported in the schema. Do not generate them. Use task-level `shouldRunOnlyOnce` for re-entry behavior.
 
@@ -40,6 +37,7 @@ build the case in the Case Designer without guessing.
    - `adhoc` — ad-hoc / manually triggered task entry
    - `runs-sequentially` — runs sequentially
    - `user-selected-stage` - target of an upstream `wait-for-user` exit
+   - `sla-status-change` — a referenced case/stage SLA changed status (stage entry for an `enter-stage` response, task entry for `start-task`; 2 args for a breach, 3 for at-risk — see the reference contract under Stage Entry Conditions)
 
 4. **Exit conditions:** Every exit condition MUST specify:
    - **Exit Type:** `exit-only` | `return-to-origin` | `wait-for-user`
@@ -53,12 +51,13 @@ build the case in the Case Designer without guessing.
    - `Marks Stage Complete: No` (routing / divergent exits) → WHEN may be `selected-tasks-completed("TaskA")`, `wait-for-connector`, etc.
    - Same stage may carry one completion exit (`Yes` + `required-tasks-completed` / `wait-for-connector`) plus zero or more routing exits (`No` + `selected-tasks-completed` / `wait-for-connector`).
    - `return-to-origin` is a completion exit: use `Marks Stage Complete: Yes` with `required-tasks-completed` (or `wait-for-connector`). Never pair it with `No` + `selected-tasks-completed`.
+   - **Stage-picker repair is a replacement, never a duplicate:** when `user-selected-stage` requires picker exposure from an origin, replace that origin's `required-tasks-completed | exit-only | Yes` completion row with `required-tasks-completed | wait-for-user | Yes`. Keep exactly one `required-tasks-completed` row; never add a second `Marks Stage Complete: No` row.
 
    *Case exit (preferred pattern: one row, `Yes` + `required-stages-completed`):*
    - `Marks Case Complete: Yes` → WHEN MUST be `required-stages-completed` or `wait-for-connector`. **NEVER** `selected-stage-completed(...)` / `selected-stage-exited(...)`.
    - `Marks Case Complete: No` (case exits without closing — rare) → WHEN may be `selected-stage-completed(...)`, `selected-stage-exited(...)`, or `wait-for-connector`.
 
-5. **Descriptions are mandatory:** Every case, stage, and task MUST have a prose description. No empty or placeholder descriptions.
+5. **Descriptions and rationale are mandatory:** Every case, stage, and task MUST have a prose description. Every stage/task and configured case/stage SLA MUST also preserve a concrete Design Rationale explaining the selected kind/type, activation/sequencing, and routing/threshold choices. No empty or placeholder descriptions/rationales.
 
 6. **Entry/exit conditions use WHEN + IF format:**
    - **WHEN** = the rule type (event that triggers evaluation, e.g., `selected-stage-completed("Intake")`)
@@ -106,9 +105,13 @@ build the case in the Case Designer without guessing.
 - **Workflows/Processes:** PascalCase (e.g., `ValidateEligibility`)
 - **Entity names:** PascalCase (e.g., `LoanApplication`)
 - **Entity fields:** camelCase (e.g., `applicantName`)
+- **Case Designer display names:** stages, tasks, condition rule names, SLA rule titles, and escalation titles use only letters, numbers, spaces, hyphen (`-`), and underscore (`_`). Do not generate colons, periods, slashes, backslashes, quotes, parentheses, ampersands, commas, semicolons, emoji, or other symbols. Normalize unsafe display punctuation to spaces, collapse spaces, and disclose any changed display names in the Case Review.
+- **External lookup names:** do not normalize deployed resource names, connector names, Action App titles, API/process/agent names, queue names, or bucket names used for tenant lookup. Keep a separate safe Case Designer display name when an external lookup name contains punctuation.
 
 ### Output Structure
 
+The rendered `sdd.md` must preserve this structure. Do not replace it with a summary, build plan, source trace, or abbreviated stage/task list; every section and every modeled stage/task detail block below is part of the authoring contract.
+
 The generated SDD must start with:
 
 1. **Title** — `# SDD — {Case Name}`
@@ -160,29 +163,59 @@ The generated SDD must start with:
 | Case Name | {PascalCase name} |
 | Case Description | {2-3 sentence description of what the case manages} |
 | Case Identifier | Type: {constant \| external}. Constant → Prefix: {2-4 char UPPER prefix}. External → Source: {=vars.<In/InOut variable> \| =js:`expression`} |
-| Priority | Choiceset: {comma-separated values} — Default: {value} |
-| Case-Level SLA | {count} {unit: h/d/w/m} |
+| Case-Level SLA | {count} {unit: min/h/d/w/m} |
 | SLA Type | {time-based \| condition-based} |
+| SLA Title | {non-empty title, no `:`; omit this row when `Case-Level SLA` is `—`} |
 | Case App | {Enabled \| Disabled} — whether the in-product Case App UI is on (`caseAppEnabled`; default Disabled) |
 | Task-output passing | {Direct \| Shared} — `caseDirectlyPassTaskOutputs` (Direct = a task's outputs flow straight to downstream tasks; default Direct) |
 | Case Identifier source | {`=metadata.ExternalId` (platform-generated — the default) \| custom} — what every `caseId` task input binds to |
 
-> **Case App validation contract:** Stage names must be non-empty, unique, and contain no `:`. Task names must contain no `:`. Every SLA rule and escalation needs a non-empty, target-unique title/display name with no `:`. SLA durations must be positive; minute-based SLAs must be 15–1000 minutes. Non-default SLA rows need an expression; escalations need a recipient, and at-risk escalations need a percentage.
+> **Case App validation contract:** Stage names must be non-empty, unique, and safe for Case Designer display. Task names and condition display names must be safe. Every SLA rule and escalation needs a non-empty, target-unique safe title/display name. Safe display characters are letters, numbers, spaces, hyphen, and underscore. SLA durations must be positive; minute-based SLAs must be 15–1000 minutes. Non-default SLA rows need an expression; escalations need a recipient, and at-risk escalations need a percentage.
 
 ### Case-Level SLA Escalation Rules
 
-| SLA Status | Threshold | Action |
-|------------|-----------|--------|
-| At-Risk | {percentage}% of SLA duration | {Notify: recipient or group} |
-| Breached | 100% of SLA duration | {Notify: recipient or group} |
+**Design Rationale:** {Why this target, at-risk threshold, recipients, and breach behavior fit the case requirement; name any stage entered through `sla-status-change` and whether that response interrupts active work.}
+
+| SLA Status | Threshold | Action | Display Name |
+|------------|-----------|--------|--------------|
+| At-Risk | {percentage}% of SLA duration | {Notify: recipient or group} | {escalation title, root-unique, no `:`} |
+| Breached | 100% of SLA duration | {Notify: recipient or group} | {escalation title, root-unique, no `:`} |
+
+> `Display Name` is what a `sla-status-change` entry references. `—` → `Escalation Rule {N}`, valid only when nothing references that escalation.
+
+### SLA Response Map
+
+> **Required whenever any SLA is configured** (case, stage, or `action` task) — one row per `(Scope, SLA, Status)`. This table is the single place breach and at-risk behavior is decided; never leave the response implied by SLA duration text or by an escalation's wording. Omit the whole section only when no SLA exists anywhere in the case.
+
+| Scope | SLA | Status | Response | Target | Interrupting | Rationale |
+|-------|-----|--------|----------|--------|--------------|-----------|
+| {case \| stage: `<StageName>` \| task: `<TaskName>`} | {SLA Title} | {At-Risk \| Breached} | {notify-only \| start-task \| enter-stage \| exit-stage \| exit-case} | {`—` for notify-only; task name for start-task; stage name for enter-stage; exit row ref for exit-stage/exit-case} | {`—` for notify-only and for every start-task; Yes \| No otherwise} | {why this response fits the source} |
+
+> **Choosing the `Response`** — read it off the source, never off the SLA's scope:
+>
+> | Response | Source says | Where it lands |
+> |---|---|---|
+> | `notify-only` | notify / alert / email / page someone | escalation `Action` row above — no stage, no task, no entry condition |
+> | `start-task` | follow-up work inside the **same** breached stage (reminder, reassignment, manager check, extra approval) — "as part of the review", "the reviewer keeps working and also does X" | the follow-up task in that stage, carrying `sla-status-change` in its own **`Entry Condition:`** block against that stage's own SLA. **No new stage, and no Stage Entry Conditions row** — a stage-entry rule re-enters the stage and re-runs its other tasks. |
+> | `enter-stage` | a separate lane owns it — ownership change, "hand it to", "escalate into `<Lane>`", recovery, visible lifecycle step | the destination stage's Stage Entry Conditions row |
+> | `exit-stage` | the breached stage should end, fail, or route away | that stage's Stage Exit Conditions row |
+> | `exit-case` | the case should close, cancel, fail, or reach an alternate terminal outcome | a §1.4a Case Exit Conditions row |
+>
+> **`start-task` vs `enter-stage` turns on WHERE the work lives, not on whether it interrupts** — `enter-stage` can itself be `Interrupting: No`, so "the team keeps working" does not choose between them. A named **task** ("raise a Senior Assessor Check approval") never justifies a new stage: if the `Target` you are about to write is a task name rather than a lane the source describes in its own right, the response is `start-task`, and the task goes in the breached stage.
+>
+> **Default:** absent a stated response, both statuses are `notify-only` — `Target` and `Interrupting` are `—`. Do NOT invent a stage, task, or routing change for an SLA the source only asks to notify about.
+>
+> **`Interrupting` is a separate decision from scope.** `Yes` when the response stops, pauses, takes over, or reroutes the active work; `No` when the response runs alongside it (parallel oversight). A case-scope SLA does not imply `Yes`. When the response produces a **Stage** Entry Conditions row (`enter-stage`), the value here MUST match that row's `Interrupting` cell. A **`start-task`** response is always `—`: the rule lives in the follow-up task's own `Entry Condition:` block, which has no `Interrupting` column because a task entry interrupts nothing.
+>
+> **A row whose `Response` is not `notify-only` MUST have a matching rule elsewhere in this SDD** — a `sla-status-change` row in a task's **`Entry Condition:`** block for `start-task`, a `sla-status-change` **Stage Entry Conditions** row for `enter-stage`, a stage-exit row, or a §1.4a case-exit row. A `start-task`/`enter-stage` row with no `sla-status-change` entry anywhere is a blocking render error, and so is an `sla-status-change` entry — task or stage scope — with no row here.
 
 ### Variable SLA Rules
 
 > Include this table only if SLA Type is `condition-based`. Each row defines an expression-keyed SLA override; the time-based default lives in the Case Metadata `Case-Level SLA` cell above. FE persists `slaRules[]` with non-empty `conditionExpression` per row (PO.Frontend `CaseManagementSlaProperties.tsx`).
 
-| Expression | SLA | Unit |
-|------------|-----|------|
-| {conditionExpression evaluated against case variables} | {count} | {h \| d \| w \| m} |
+| Expression | SLA | Unit | Display Name |
+|------------|-----|------|--------------|
+| {conditionExpression evaluated against case variables} | {count} | {h \| d \| w \| m} | {non-empty root-unique title without `:`} |
 
 ### Case Triggers
 
@@ -194,7 +227,7 @@ The generated SDD must start with:
 
 > Number triggers sequentially starting at T02 (T01 is reserved for the case file). The T-number is referenced by Case Variables rows whose value comes from this trigger's payload.
 >
-> `Manual` is author shorthand — a manual trigger has **no** `serviceType` in the generated JSON (the CLI serviceType enum is `None` / `Intsvc.EventTrigger` / `Intsvc.TimerTrigger`; never write `serviceType: "Manual"`).
+> `Manual` is author shorthand — a manual trigger has **no** `serviceType` in the generated JSON (the on-disk serviceType enum is `None` / `Intsvc.EventTrigger` / `timer`; the SDD's `Intsvc.TimerTrigger` maps to on-disk `timer`; never write `serviceType: "Manual"`).
 
 **Configuration column — write user-specified intent only:**
 
@@ -210,12 +243,7 @@ DO NOT include in Configuration:
 - Meta notes like `No required event parameters` or `No user filter` (absence is the default; the skill discovers required params at `case spec` time).
 - Connector activity slug, HTTP method, or any spec-discovered detail.
 
-> **Tenant object starts are still event triggers.** If the user says a case starts
-> when a tenant case-entity / data-object record is created, author
-> `Intsvc.EventTrigger` with that object name as Source. Do NOT downgrade to
-> `Manual` just because the eval sandbox or current tenant may not have the
-> object provisioned. Planning/implementation preserve unresolved event triggers
-> as placeholders.
+> **Tenant object starts are still event triggers.** If the user says a case starts when a tenant case-entity / data-object record is created, author `Intsvc.EventTrigger` with that object name as Source. Do NOT downgrade to `Manual` just because the eval sandbox or current tenant may not have the object provisioned. Planning/implementation preserve unresolved event triggers as placeholders.
 
 ### Case Exit Conditions
 
@@ -317,23 +345,28 @@ The runtime engine resolves the binding when the task completes, writing the res
 
 **Type:** Stage
 **Stage Kind:** {primary \| secondary} _(secondary stages use the `### Secondary Stage:` heading AND set `secondary`; primary stages use `### Stage {N}:` and OMIT this line — default = primary)_
+**Design Rationale:** {Why this stage is primary/secondary and why its entry/exit behavior fits. For a global-event secondary stage, name the event and explain that one interrupting entry replaces per-primary-stage tasks/exits.}
 **Description:** {Prose description of what this stage accomplishes in the case lifecycle}
 **Required for Case Completion:** {Yes \| No}
 **Interrupting:** Yes _(secondary stages only — i.e. Stage Kind: secondary; omit for primary)_
 
 #### Stage Entry Conditions
 
-> **Valid WHEN rule types for stage entry (strict subset of Key Rule 3):** `case-entered` (first stage of the case — no target), `selected-stage-completed("StageName")`, `selected-stage-exited("StageName")`, `user-selected-stage` (target of an upstream `wait-for-user` exit — no target; stage opts into the picker by declaring this rule), `wait-for-connector` (event-driven entry / interrupt). Other rule types from Key Rule 3 are NOT valid here.
+> **Valid WHEN rule types for stage entry (strict subset of Key Rule 3):** `case-entered` (first stage of the case — no target), `selected-stage-completed("StageName")`, `selected-stage-exited("StageName")`, `user-selected-stage` (target of an upstream `wait-for-user` exit — no target; stage opts into the picker by declaring this rule), `wait-for-connector` (external/global event interrupt), `sla-status-change("<SLA target>","<SLA Title>")` for a breach / `sla-status-change("<SLA target>","<SLA Title>","<At-Risk Escalation Display Name>")` for at-risk (the **`enter-stage`** SLA response — see the reference contract below). Other rule types from Key Rule 3 are NOT valid here. A `start-task` response does NOT belong in this table: it is a Task Entry Condition on the follow-up task.
 >
-> **Interrupting column:** `Yes` lets the condition fire while another stage is active and interrupt it. Use `Yes` on every secondary-stage entry row. Use `No` only for normal entry on regular stages; if the work should not interrupt, it is not a secondary stage.
+> **Interrupting column:** `Yes` lets the condition fire while another stage is active and interrupt it. Use `Yes` on every secondary-stage entry row, with one carve-out: an `sla-status-change` row whose response is parallel oversight (the breached work keeps running) is `No`, and its lane still stays secondary with `Required for case completion: No`. Otherwise use `No` only for normal entry on regular stages; if the work should not interrupt and is not that SLA carve-out, it is not a secondary stage.
 >
 > Each row is a separate entry condition. List multiple rows when a stage can be entered through more than one path (e.g., normal completion of an upstream stage AND an interrupting connector event).
 
 | WHEN | IF | Interrupting | Display Name |
 |------|-----|-------------|--------------|
-| {one of: `case-entered` \| `selected-stage-completed("StageName")` \| `selected-stage-exited("StageName")` \| `user-selected-stage` \| `wait-for-connector`} | {conditionExpression, or "—" if none} | {Yes \| No} | {optional label, or "—" → defaults to `Entry Rule {N}`} |
+| {one of: `case-entered` \| `selected-stage-completed("StageName")` \| `selected-stage-exited("StageName")` \| `user-selected-stage` \| `wait-for-connector` \| `sla-status-change("<SLA target>","<SLA Title>")` \| `sla-status-change("<SLA target>","<SLA Title>","<At-Risk Escalation Display Name>")`} | {conditionExpression, or "—" if none} | {Yes \| No} | {optional label, or "—" → defaults to `Entry Rule {N}`} |
 
 > If `WHEN` is `wait-for-connector`, add a **Connector Rule Detail** block under this table (see Key Rule 6).
+>
+> A global `wait-for-connector` / graph-changing `sla-status-change` entry on an interrupting secondary stage applies regardless of which primary stage is active. Do not repeat the event as a task or exit rule on every primary stage. An `sla-status-change` row here is always the `enter-stage` response — it routes the case to *this* stage; a non-interrupting (parallel oversight) response uses `Interrupting: No`. A `start-task` response never appears here.
+>
+> **`sla-status-change` reference contract.** Every arg used must be declared in this SDD — the rule has no duration of its own. `<SLA target>` is `root` (case-level SLA; reserved token) or the SLA-owning stage name, and scopes the lookups to that target's tables: `<SLA Title>` is its `SLA Title` cell (or a Variable SLA Rules `Display Name`). **Arg count carries the status:** two args is a **Breached** rule — a breach references the SLA alone and needs no escalation to exist; three args is an **At-Risk** rule, where `<At-Risk Escalation Display Name>` is one of that same SLA's escalation `Display Name`s with At-Risk status. Use one row per status. Phase 1 resolves the SLA to `slaId`, and the escalation (at-risk only) to `escalationId`; a reference that does not resolve is a blocking error. Adding an escalation to a breach row silently converts it to at-risk — never do it to make a reference "complete". Examples: `sla-status-change("root","Application SLA")` (breach), `sla-status-change("root","Application SLA","Application SLA at risk")` (at-risk).
 
 #### Stage Exit Conditions
 
@@ -352,11 +385,13 @@ The runtime engine resolves the binding when the task completes, writing the res
 
 > Stage SLA supports the same conditional + default `slaRules[]` model as the case root. For `condition-based`, keep the default row below and add one or more Stage Variable SLA Rules before it.
 
+**Design Rationale:** {Why this target, duration, at-risk threshold, recipients, and breach behavior fit the stage requirement; name any escalation stage entered through `sla-status-change`. If the response is local to this stage (`start-task`), say so and name the follow-up task that carries the rule — a task entry has no interrupting decision.}
 **SLA Type:** {time-based | condition-based}
+**SLA Title:** {non-empty stage-unique title, no `:`}
 
-| SLA | Unit | At-Risk | At-Risk Action | Breach Action |
-|-----|------|---------|----------------|---------------|
-| {count} | {min \| h \| d \| w \| m} | {percentage}% | {Notify: recipient or specific action} | {Notify: recipient or specific action} |
+| SLA | Unit | At-Risk | At-Risk Action | At-Risk Display Name | Breach Action | Breach Display Name |
+|-----|------|---------|----------------|----------------------|---------------|---------------------|
+| {count} | {min \| h \| d \| w \| m} | {percentage}% | {Notify: recipient or specific action} | {escalation title, stage-unique, no `:`} | {Notify: recipient or specific action} | {escalation title, stage-unique, no `:`} |
 
 ##### Stage Variable SLA Rules
 
@@ -370,40 +405,45 @@ The runtime engine resolves the binding when the task completes, writing the res
 
 > Tasks are listed in the order provided by the source spec / interview answers. Do not add, split, merge, or rename tasks; do not infer new tasks from context.
 
-| # | Task Name | Type | Required | Run Only Once | Persona | SLA |
-|---|-----------|------|----------|---------------|---------|-----|
-| 1 | {task name} | {action \| process \| agent \| rpa \| api-workflow \| wait-for-timer \| wait-for-connector \| execute-connector-activity \| case-management} | {Yes \| No} | {Yes \| No} | {persona name or "—"} | {count unit or "—" (only for action tasks)} |
+| # | Task Name | Type | Activation Mode | Starts When | Required | Run Only Once | Persona | SLA |
+|---|-----------|------|-----------------|-------------|----------|---------------|---------|-----|
+| 1 | {task name} | {action \| process \| agent \| rpa \| api-workflow \| wait-for-timer \| wait-for-connector \| execute-connector-activity \| case-management} | {sequential \| parallel \| parallel-after-predecessor \| event-triggered \| adhoc \| fan-in \| conditional-gate} | {e.g. "sequential group: A → B → C", "stage enters", "after A+B", "connector event"} | {Yes \| No} | {Yes \| No} | {persona name or "—"} | {count unit or "—" (only for action tasks)} |
 
 > After the summary table, provide a detailed subsection for each task.
+> Primary-stage task headings use `##### Task {N}.{M}: {Task Name}`. Secondary-stage task headings use `##### Task S{K}.{M}: {Task Name}` where `K` is the secondary-stage order. Do not use lettered prefixes such as `R.1`, `W.1`, `CC.1`, or `ESC.1`.
 
 ---
 
 ##### Task {N}.{M}: {Task Name}
 
 **Type:** {exact task type from schema}
+**Activation Mode:** {sequential | parallel | parallel-after-predecessor | event-triggered | adhoc | fan-in | conditional-gate}
+**Design Rationale:** {Why this task type fits the actor/work and why this activation mode fits. For a sequential task, name the stated order/dependency; for a parallel task, state why it is independent.}
 **Description:** {What this task does and why it exists in the case plan}
 
 **Entry Condition:**
 
-> **Valid WHEN rule types for task entry (strict subset of Key Rule 3):** `current-stage-entered` (fires when the containing stage is entered; use for ungated event/condition-driven tasks, not for the first task in a sequential run), `selected-tasks-completed("TaskA", "TaskB")` (explicit sibling gate, fan-in, branch convergence, or non-immediate dependency), `wait-for-connector` (waits for a connector event), `adhoc` (user-triggered from the case app — task does not auto-start; task-entry only; set `Required: No`; does not determine task type), `runs-sequentially` (sequential ordering within the stage; parallel task sets remain allowed, and the entry rule—not lane placement—carries the sequencing intent). Other rule types from Key Rule 3 are NOT valid here.
+> **Valid WHEN rule types for task entry (strict subset of Key Rule 3):** `current-stage-entered` (fires when the containing stage is entered; use for ungated event/condition-driven tasks, not for the first task in a sequential run), `selected-tasks-completed("TaskA", "TaskB")` (explicit sibling gate, fan-in, branch convergence, or non-immediate dependency), `wait-for-connector` (waits for a connector event), `adhoc` (user-triggered from the case app — task does not auto-start; task-entry only; set `Required: No`; does not determine task type), `runs-sequentially` (sequential ordering within the stage; parallel task sets remain allowed, and the entry rule—not lane placement—carries the sequencing intent), `sla-status-change("<SLA target>","<SLA Title>")` for a breach / `sla-status-change("<SLA target>","<SLA Title>","<At-Risk Escalation Display Name>")` for at-risk (the **`start-task` SLA response** — this task fires on the SLA event itself; reference the containing stage's own SLA, or `root` for a case-scoped response). Other rule types from Key Rule 3 are NOT valid here.
 >
 > Each row is a separate entry condition. List multiple rows when a task can be entered through more than one path. Author a `current-stage-entered` row for any ungated task — including connector tasks (`execute-connector-activity`, `wait-for-connector`) — that should start when its stage is entered.
 >
-> **Sequential normalization:** for a plain top-to-bottom task run, write `runs-sequentially` as the only Entry Condition row on every task in that run, including the first task. Do not model the run as `current-stage-entered` plus `selected-tasks-completed("<previous>")`; Studio Web classifies that as condition/event-driven, not Sequential.
+> **Sequential normalization:** when the requirement states order/dependency (`then`, `after`, `before`, `in order`, or an upstream prerequisite), write `runs-sequentially` as the only Entry Condition row on every task in that ordered task-set run, including the first task. Do not turn an explicitly ordered run into parallel stage-start tasks merely because no data binding is present. Use `current-stage-entered` in parallel only for explicitly independent stage-start work. When multiple independent tasks start after the same immediate predecessor, place them in the same next task set, mark `Activation Mode: parallel-after-predecessor`, and give each `runs-sequentially` instead of duplicate `selected-tasks-completed("<previous>")` entries. Use `selected-tasks-completed` only for fan-in, branch convergence, condition-result routing, or a non-immediate dependency. It must select only non-adhoc sibling tasks in the same stage.
 
 | WHEN | IF | Display Name |
 |------|-----|--------------|
-| {one of: `current-stage-entered` \| `selected-tasks-completed("TaskA", "TaskB")` \| `wait-for-connector` \| `adhoc` \| `runs-sequentially`} | {conditionExpression, or "—" if none} | {optional label, or "—" → defaults to `Entry Rule {N}`} |
+| {one of: `current-stage-entered` \| `selected-tasks-completed("TaskA", "TaskB")` \| `wait-for-connector` \| `adhoc` \| `runs-sequentially` \| `sla-status-change("<SLA target>","<SLA Title>")` \| `sla-status-change("<SLA target>","<SLA Title>","<At-Risk Escalation Display Name>")`} | {conditionExpression, or "—" if none} | {optional label, or "—" → defaults to `Entry Rule {N}`} |
 
 > If `WHEN` is `wait-for-connector`, add a **Connector Rule Detail** block under this table (see Key Rule 6).
 
-**Task envelope** (every task — render after the Entry Condition table):
+**Task envelope**
+
+> Render the heading above exactly, with no colon. Every task includes this block after the Entry Condition table.
 
 | Required | Run Only Once | Skip Condition |
 |----------|---------------|----------------|
 | {Yes \| No} | {Yes \| No} | {`=js:` expression that skips the task when truthy, or `—`} |
 
-> `Required: Yes` means the task counts toward the stage's `required-tasks-completed` exit — **at least one task per stage MUST be `Required: Yes`**, or the stage can never complete. `Skip Condition` is the task-level `skipCondition` envelope field (sibling of `data`); use it for "run this task only when X" gating that is not expressible as a task-entry `IF`.
+> `Required: Yes` means the task counts toward the stage's `required-tasks-completed` exit — **at least one task per stage MUST be `Required: Yes`**, or the stage can never complete. `Run Only Once` is a re-entry decision, not a task-type default: use `No` for request/review/decision/validation tasks that must rerun after corrections or resubmission; use `Yes` only for immutable setup or a documented re-evaluate-existing-fact return. `Skip Condition` is the task-level `skipCondition` envelope field (sibling of `data`); use it for "run this task only when X" gating that is not expressible as a task-entry `IF`.
 
 ---
 

package/skills/uipath-maestro-case/assets/templates/sdd-viewer.html

@@ -500,7 +500,6 @@
         "prefix": string,                     // 2-4 UPPER (constant only)
         "identifierType": "constant" | "external",
         "identifierExpression": string | null, // external only: =vars.<id> or =js:`...`
-        "priority": { "values": string[], "default": string } | null,
         "sla": { "count": number, "unit": "h"|"d"|"w"|"m", "type": "Static"|"Variable" } | null,
         "slaEscalation": [{ "status": "At-Risk"|"Breached", "threshold": string, "action": string }],
         "variableSla": [{ "expression": string, "sla": number, "unit": string }],
@@ -684,7 +683,6 @@
         ["Identifier", c.identifierType === "external"
           ? `${c.identifierExpression || "—"} (external)`
           : (c.prefix ? `${c.prefix} (${c.identifierType || "constant"})` : null)],
-        ["Priority", c.priority ? `${(c.priority.values || []).join(", ")} — default ${c.priority.default || "—"}` : null],
         ["Case-Level SLA", c.sla ? `${c.sla.count} ${c.sla.unit} — ${c.sla.type || "Static"}` : null]
       ];
       const tbl = el("table");

package/skills/uipath-maestro-case/references/bindings-and-expressions.md

@@ -21,7 +21,7 @@ When using the literal/expression mode, the `--value` string can start with one
 
 | Prefix | Meaning | Example |
 |--------|---------|---------|
-| `=metadata.` | Case metadata field | `=metadata.amount` |
+| `=metadata.` | Case metadata field — closed schema, see [case-schema.md § 1](case-schema.md#1-top-level--metadata). NOT for arbitrary SDD "Case Metadata" business fields (e.g. Priority) — those are case variables, use `=vars.<id>` | `=metadata.ExternalId` |
 | `=js:` | Inline JavaScript expression | `=js:new Date().toISOString()` |
 | `=vars.` | Case-level variable | `=vars.inbox_config` |
 | `=bindings.` | Resource binding (connection, queue, trigger) | `=bindings.slackConnection` |
@@ -76,6 +76,8 @@ SDD IF columns and `tasks.md` conditions use natural shorthand — `approved ==
 
 The lookup-path resolver has NO `=metadata.` branch — plain `=metadata.X` is NOT resolved at runtime. **Always wrap as `=js:metadata.X`** (or `=js:(metadata.X)` if the sink requires parens). The FE design-time picker may classify `=metadata.X` as "variable" type, but that's a UI hint, not a runtime contract.
 
+`metadata.X` is a **closed field set** — see [case-schema.md § 1](case-schema.md#1-top-level--metadata) for the full list (`caseIdentifier`, `slaRules`, `caseExitRules`, …) plus the platform-only runtime field `metadata.ExternalId`. It is NOT a namespace for arbitrary business data. A field the SDD's "Case Metadata" table lists for human-readability (e.g. `Priority`) is authored as a **case variable**, not a `metadata` key — reference it as `=js:vars.priority`, never `=js:metadata.priority` (which resolves to `undefined`).
+
 ### Planner-emit form
 
 The planner emits `tasks.md` using SDD-natural references — `=vars.X`, `=metadata.X`, `=bindings.X`, cross-task `<- "Stage"."Task".out` (verbatim, unresolved). Other `=`-prefixed forms (`=response.X`, `=Error.X`, `=datafabric.X`, `=orchestrator.JobAttachments`) also pass through to impl for per-sink wrap; see [Expression Prefixes](#expression-prefixes) for the full set. The implementation step rewrites to the canonical sink form when constructing `caseplan.json`. Detail: [plugins/variables/io-binding/planning.md](plugins/variables/io-binding/planning.md) and each plugin's `impl-json.md`.

package/skills/uipath-maestro-case/references/bindings-v2-sync.md

@@ -12,7 +12,7 @@ Run at these three points only:
 
 1. **End of Phase 2 Step 9** (after all non-connector tasks written) — covers all process/agent/rpa/action/api-workflow/case-management bindings
 2. **End of Phase 3 Step 9.7** (after all connector tasks populated) — adds Connection bindings + populates IS cache for tasks
-3. **End of Phase 3 Step 10** (after all connector condition RULES written across the 4 scopes — stage-entry, stage-exit, case-exit, task-entry) — adds Connection bindings + populates IS cache for rules. Required because connector rules are written in Step 10 (conditions), not Step 9.7 (tasks); without this third sync point, rule-introduced Connection/Folder bindings + IS-cache entries wouldn't land until the post-Phase-3 catch-all, and `resource refresh` would miss them.
+3. **End of Phase 3 Step 10.5** (after Phase 2 connector-rule stubs are upgraded across the 4 scopes — stage-entry, stage-exit, case-exit, task-entry) — adds Connection bindings + populates IS cache for resolved rules. Phase 2 stubs add no bindings; without this sync, rule-introduced Connection/Folder bindings + IS-cache entries would be absent when `resource refresh` runs.
 
 Individual task / rule plugins write bindings to `caseplan.json` per-target as normal (top-level `bindings[]`). The batch regeneration reads the full bindings array once and converts everything in one pass.
 
@@ -67,7 +67,7 @@ File envelope: `{ "version": "2.0", "resources": [ /* one entry per resource */
 
 ## § Populate IS connection cache
 
-`uip solution resources refresh` reads a local IS cache that connector plugins must populate after `get-connection`. Applies to all three connector-resolving paths: connector **tasks** (Step 9.7), connector **triggers** (Step 6.1), and connector **condition rules** in any of the 4 scopes (Step 10).
+`uip solution resources refresh` reads a local IS cache that connector plugins must populate after `get-connection`. Applies to all three connector-resolving paths: connector **tasks** (Step 9.7), connector **triggers** (Step 6.1), and connector **condition-rule upgrades** in any of the 4 scopes (Step 10.5).
 
 **Path:** `~/.uipath/cache/integrationservice/<connectorKey>/connections.json`
 

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

@@ -1,6 +1,6 @@
 # Brownfield — Edit an Existing Case
 
-Targeted changes to an existing `caseplan.json`. Skips the Phase 0–6 build pipeline. Terminates at `validate`, then hands off to Phase 5 (debug) / Phase 6 (publish).
+Targeted changes to an existing `caseplan.json`. Skips the Phase 0–6 build pipeline. Terminates at `validate`, then hands off to Phase 5 (publish) / Phase 6 (debug).
 
 > **Greenfield (new case from `sdd.md`) uses a different journey.** If `caseplan.json` does not yet exist, or the user wants to (re)build from a spec, see [planning.md](planning.md) → [implementation.md](implementation.md) → [phased-execution.md](phased-execution.md) instead.
 
@@ -20,7 +20,7 @@ Before the first edit, present the flow once so the dev knows the steps and wher
 
 ## Pull latest first (before editing)
 
-Most "edit an existing case" requests mean a case **deployed in Studio Web**, not just a local file. Editing the local `caseplan.json` and re-publishing (Phase 6 `uip solution upload`) **overwrites server state** — if the case changed in Studio Web after the local copy was made, the upload silently clobbers those changes, with no diff and no conflict check. Reconcile **before** the first edit.
+Most "edit an existing case" requests mean a case **deployed in Studio Web**, not just a local file. Editing the local `caseplan.json` and re-publishing (Phase 5 `uip solution upload`) **overwrites server state** — if the case changed in Studio Web after the local copy was made, the upload silently clobbers those changes, with no diff and no conflict check. Reconcile **before** the first edit.
 
 1. **Determine where the case lives.** If not already known, AskUserQuestion: `Edit my Studio Web case (pull latest first)` (default) / `Edit a local-only project (no pull)`.
 2. **Lives in Studio Web (has a SolutionId)** → pull current server state into the working dir before editing:
@@ -76,6 +76,16 @@ When an edit touches many nodes or reads like "rebuild this case", confirm scope
 | Add a global variable / argument | [plugins/variables/global-vars/impl-json.md](plugins/variables/global-vars/impl-json.md) |
 | Rename / delete a global variable or argument | [case-editing-operations.md § Rename or delete a global variable or argument](case-editing-operations.md#rename-or-delete-a-global-variable-or-argument) + [plugins/variables/global-vars/impl-json.md](plugins/variables/global-vars/impl-json.md) |
 | Change a variable's type or default | [case-editing-operations.md § Change a variable's type or default](case-editing-operations.md#change-a-variables-type-or-default) + [plugins/variables/global-vars/impl-json.md](plugins/variables/global-vars/impl-json.md) |
+| Add or repair a response to an SLA at-risk / breach event | [§ SLA responses in a brownfield edit](#sla-responses-in-a-brownfield-edit) below, then [plugins/conditions/stage-entry-conditions/impl-json.md](plugins/conditions/stage-entry-conditions/impl-json.md) |
+
+## SLA responses in a brownfield edit
+
+An SLA clock and its **response** are separate edits. Pick the response, the status shape, and the interrupting value per [sla-response-shapes.md](sla-response-shapes.md) — that file is the contract; this section only says what it means for an edit.
+
+- **Do not widen the edit.** A requirement that only asks to notify someone is `notify-only`: add an escalation to the target's `slaRules[].escalationRule` ([plugins/sla/impl-json.md](plugins/sla/impl-json.md)) and stop. No stage, no task, no condition.
+- **`start-task` adds a task, not a lane** ([sla-response-shapes.md § 1](sla-response-shapes.md#1-pick-the-response)): the follow-up task goes in the breached stage with the `sla-status-change` rule as its **own task-entry** condition — never as a stage-entry row on the breached stage, which re-runs that stage's other tasks.
+- **Four defects `validate` accepts** — re-read [§ 5](sla-response-shapes.md#5-four-defects-validate-cannot-see) before you finish: a task with no entry condition, a non-interrupting lane demoted to a regular stage, an `escalationId: "any"` "repaired" by repointing instead of deleting, and a `start-task` authored as stage re-entry.
+- **`validate` passing is not evidence the response is right.** Every defect above validates clean.
 
 ## After edits
 
@@ -84,12 +94,12 @@ When an edit touches many nodes or reads like "rebuild this case", confirm scope
 
 ## Completion Output
 
-Report: file path edited, what changed (nodes/tasks/conditions added/removed/modified), validation status, any placeholder tasks still unresolved, any connector connections the user must create, and a **freshness note** — whether the local copy was pulled from Studio Web first (so re-publish reflects current server state) or is a local-only project not synced from SW (re-publish overwrites whatever is on the server). Then AskUserQuestion "What's next":
+Report: file path edited, what changed (nodes/tasks/conditions added/removed/modified), validation status, any placeholder tasks still unresolved, any connector connections the user must create, and a **freshness note** — whether the local copy was pulled from Studio Web first (so re-publish reflects current server state) or is a local-only project not synced from SW (re-publish overwrites whatever is on the server). Then include `Suggested next steps` in one short line before AskUserQuestion "What's next": publish when ready to update Studio Web, run debug if the edit changes runtime behavior, or stop and inspect the local diff.
 
 | Option | What it does |
 |---|---|
-| **Run debug session** | Phase 5 — executes the case for real (consent-gated, Rule 12). |
-| **Publish to Studio Web** | Phase 6 — `uip solution resources refresh` then `uip solution upload`, print DesignerUrl. |
+| **Publish to Studio Web** | Phase 5 — `uip solution resources refresh` then `uip solution upload <SolutionDir> --output json --output-filter "{Status: Status, SolutionId: SolutionId, DesignerUrl: DesignerUrl}"` (filter mandatory — see [case-commands.md § uip solution upload](case-commands.md#uip-solution-upload)), print DesignerUrl. |
+| **Run debug session** | Phase 6 — executes the case for real (consent-gated, Rule 12). |
 | **Done** (default) | Stop here. |
 | **Something else** | Free-form. |
 

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

@@ -46,6 +46,8 @@ cd <SolutionDir> && uip maestro case init <ProjectName>
 |------|-------------|
 | `<ProjectName>` | **(required)** Project directory name. Created inside the current directory |
 
+> **The `cd <SolutionDir>` is mandatory; `&&`-chaining after `uip solution init` does NOT satisfy it.** `solution init` makes `<SolutionDir>` a *child* of cwd, so `uip solution init X && uip maestro case init X` still runs `case init` outside the new solution — with the auto-scaffold consequences described below.
+
 `case init` always lands the project inside a solution. Run **from inside the solution directory** so the layout is `<SolutionDir>/<ProjectName>/` — it then auto-registers the project with the parent `.uipx` (`Data.SolutionRegistration.Status`: `Registered` or `AlreadyRegistered`). Run **outside any solution** and `case init` auto-scaffolds one: it creates `<ProjectName>Solution/<ProjectName>Solution.uipx`, nests the project at `<ProjectName>Solution/<ProjectName>/`, adds `Data.AutoCreatedSolution` (`{ Name, Path, SolutionFile }`), and reports `Status: Registered`. Pass `--skip-solution-registration` to opt out of **both** auto-scaffold and registration — the project lands at the bare `<ProjectName>/` path with `Status: OptedOut`. If a **non-empty** directory already exists at the path you typed, init warns and leaves it untouched — the project still lands in `<ProjectName>Solution/<ProjectName>/`, not the existing directory. Use `uip solution projects add ./<ProjectName>` as a fallback only when `Status` is `Skipped` (ambiguous discovery) or `Failed` (`.uipx` write error). Note: the SKILL's standard JSON-authoring path (see `plugins/case/impl-json.md`) does not invoke `case init` and still requires the explicit `solution projects add` step — see `implementation.md` § Step 6.
 
 ---
@@ -92,12 +94,16 @@ Upload a solution directly to Studio Web. **Requires `uip login`.**
 
 ```bash
 uip solution resources refresh --solution-folder <SolutionDir> --output json
-uip solution upload <SolutionDir> --output json
+uip solution upload <SolutionDir> --output json --output-filter "{Status: Status, SolutionId: SolutionId, DesignerUrl: DesignerUrl}"
 ```
 
 `uip solution upload` accepts the solution directory (the folder containing the `.uipx` file) directly — no intermediate bundling step. Uploads to Studio Web where the user can visualize, inspect, edit, and publish the case from the browser.
 
-> **This is the default publish path.** When the user asks to "publish" without specifying where, run `resource refresh` then `uip solution upload <SolutionDir>`. Share the resulting URL with the user.
+> **`--output-filter` is mandatory on upload.** The raw upload response is large enough that the agent truncates it and loses `DesignerUrl`. The JMESPath projection `{Status: Status, SolutionId: SolutionId, DesignerUrl: DesignerUrl}` (applied to the response envelope's `Data` field) reduces the response to the three fields the skill actually reads, so `DesignerUrl` always survives.
+
+> **On a missing `DesignerUrl`**, re-run the upload once **without** `--output-filter` and dump the unfiltered response to `tasks/upload-response.json` — the filter hides any error/diagnostic fields that explain why the URL is absent.
+
+> **This is the default publish path.** When the user asks to "publish" without specifying where, run `resource refresh` then `uip solution upload <SolutionDir> --output json --output-filter "{Status: Status, SolutionId: SolutionId, DesignerUrl: DesignerUrl}"`. Share the resulting URL with the user.
 
 ---
 
@@ -127,16 +133,26 @@ Validate a case management JSON file against case management rules.
 
 ```bash
 uip maestro case validate <file> --output json
+uip maestro case validate <file> --skeleton-v2 --output json
 uip maestro case validate <file> --skeleton --output json
 ```
 
 | Flag | Description |
 |------|-------------|
 | `<file>` | **(required)** Path to the case management JSON file |
-| `--skeleton` | Skeleton profile — runs structural checks only (nodes, edges, identity, types, topology). Skips tasks, SLAs, escalations, and entry/exit rules. Use during skeleton-phase authoring before tasks/conditions/SLA are wired. |
+| `--skeleton-v2` | Preferred Phase 2 preview profile: structure plus entry/exit rules, SLA, and escalation, while task values and connector schemas are still incomplete. Availability depends on the installed CLI. |
+| `--skeleton` | Legacy structural profile. Skips tasks, SLAs, escalations, and entry/exit rules. Used only as the Phase 2 fallback when `--skeleton-v2` is unavailable. |
 
 Output: `{ File, Status: "Valid" }` on success. Errors and warnings are reported inline.
 
+### Phase 2 profile probe
+
+1. Run `validate ... --skeleton-v2 --output json`.
+2. Only when the parser response names `--skeleton-v2` as unknown or unsupported (typically `ErrorCode: "invalid_argument"` and exit code 3), re-run once with `--skeleton`. Exit code 3 without that flag-specific message is not sufficient.
+3. Any genuine v2 validation result, including case validation errors, proves the profile ran. Report those findings; do not mask them with the legacy fallback.
+
+Always name the selected profile in the Phase 2 summary. A legacy `--skeleton` fallback checks structure only, so conditions/SLA remain covered by authoritative full validation in Phase 4.
+
 ---
 
 ## uip maestro case debug