@uipath/skills 1.201.0-preview.621 → 1.202.0-preview.635

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

@@ -8,21 +8,21 @@ Pick this plugin when the sdd.md **literally uses the phrase "case exit conditio
 
 For stage-level conditions, use [stage-entry-conditions](../stage-entry-conditions/planning.md) / [stage-exit-conditions](../stage-exit-conditions/planning.md). For task-level, use [task-entry-conditions](../task-entry-conditions/planning.md).
 
-## No omission — one T-task per sdd.md case-exit row
+## No omission — one caseplan element per sdd.md case-exit row
 
-Every case-exit condition declared in sdd.md gets its own T-task — **including rule-type `required-stages-completed` with `marks-case-complete: true`** (the "preferred pattern"). Never skip a condition because it's the default completion shape. If sdd.md wrote the row, `tasks.md` emits the T-task.
+Every case-exit condition declared in sdd.md gets its own caseplan element — **including rule-type `required-stages-completed` with `marks-case-complete: true`** (the "preferred pattern"). Never skip a condition because it's the default completion shape. If sdd.md wrote the row, the build emits the element.
 
 ## Required Fields from sdd.md
 
 | Field | Source | Notes |
 |-------|--------|-------|
-| `display-name` | sdd.md Display Name column (optional) | Carry the SDD value verbatim. Omit when the SDD cell is blank / `—` — do NOT invent one; impl defaults it to `Complete Rule {N}` (marks-case-complete `true`) / `Exit Rule {N}` (`false`). e.g., "Case resolved", "Closed — escalation path" |
+| `display-name` | sdd.md Display Name column (optional) | Carry a semantic SDD value verbatim, e.g. "Case resolved", "Closed — escalation path". Omit when the cell is blank / `—` — do NOT invent one; impl defaults it to `Complete Rule {N}` (marks-case-complete `true`) / `Exit Rule {N}` (`false`). A cell already holding that default pattern is the SDD echoing the default, so impl renumbers it case-wide ([case-schema.md § Condition name uniqueness](../../../case-schema.md#condition-name-uniqueness)). |
 | `marks-case-complete` | sdd.md | `true` for normal completion, `false` for non-completing exits |
 | `rule-type` | From catalog below | See §Rule-type catalog |
 | `selected-stage-id` | Required for `selected-stage-*` rule-types | Resolved from stage capture map |
 | `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-planning.md § Planning Pipeline](../../../connector-trigger-planning.md#planning-pipeline) |
 | `condition-expression` | Optional on any rule-type | Extra `=js:` gate on **case state** (`=js:vars.X ...`) — NOT the event payload (no `event` namespace) |
-| `outputs` | SDD **Connector Rule Outputs** block | Optional. `->` (extract field → case var) or `=` (assign expression → case var). See [connector-trigger-planning.md § tasks.md fields (planning)](../../../connector-trigger-planning.md#tasksmd-fields-planning). |
+| `outputs` | SDD **Connector Rule Outputs** block | Optional. `->` (extract field → case var) or `=` (assign expression → case var). See [connector-trigger-planning.md § registry-resolved.json fields (resolution)](../../../connector-trigger-planning.md#registry-resolvedjson-fields-resolution). |
 
 ## Rule-Type Catalog (case-exit scope)
 
@@ -53,21 +53,22 @@ Add non-completing exit conditions only when the sdd.md explicitly describes an
 
 ## Ordering
 
-Case exit conditions are created **after** all stages exist (so `selectedStageId` can resolve via the stage capture map). In `tasks.md`, place these between stage conditions and SLA.
+Case exit conditions are created **after** all stages exist (so `selectedStageId` can resolve via the stage capture map). In execution order, place these between stage conditions and SLA.
 
-## tasks.md Entry Format
+## Fields to Resolve
 
-```markdown
-## T<n>: Add case-exit condition — <summary>
+A condition produces **no `tasks/registry-resolved.json` entry** unless its `rule-type` is `wait-for-connector`. These are reasoning fields only — Phase 2 reads them from `sdd.md` ([planning.md § Step 4](../../../planning.md)).
+
+```text
+case-exit condition — <summary>
 - display-name: "<name>"                 # optional — omit when blank; impl defaults to "Complete Rule {N}"/"Exit Rule {N}" per marks-case-complete
 - marks-case-complete: true
 - rule-type: required-stages-completed
 - selected-stage: "<stage-name>"        # only for selected-stage-* rule-types
 - condition-expression: "=js:vars.X..."  # optional gate on case state, NOT the event payload
-- order: after T<m>
 - verify: Confirm Result: Success, capture ConditionId
 ```
 
-> `rule-type: wait-for-connector` also needs the connector fields — see [connector-trigger-planning.md § tasks.md fields (planning)](../../../connector-trigger-planning.md#tasksmd-fields-planning).
+> `rule-type: wait-for-connector` also needs the connector fields — see [connector-trigger-planning.md § registry-resolved.json fields (resolution)](../../../connector-trigger-planning.md#registry-resolvedjson-fields-resolution).
 
 <!-- END: planning.md -->

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

@@ -27,7 +27,7 @@ Write the Phase 2 stage-entry condition directly to the target stage's `data.ent
 
 Rules use DNF — outer array is OR, inner array is AND.
 
-> **One row = one condition object.** Each entry-condition row in tasks.md/SDD maps to a **separate** object in `entryConditions[]`. Never merge multiple rows into a single condition's `rules` AND group.
+> **One row = one condition object.** Each entry-condition row in the SDD maps to a **separate** object in `entryConditions[]`. Never merge multiple rows into a single condition's `rules` AND group.
 
 ## Procedure
 
@@ -35,8 +35,8 @@ Rules use DNF — outer array is OR, inner array is AND.
 2. Generate rule ID: `Rule_` + 6 alphanumeric chars
 3. Locate the target stage in `schema.nodes` by ID
 4. Initialize `stageNode.data.entryConditions = []` if absent (regular Stage is created without this key — see [`../../stages/impl-json.md`](../../stages/impl-json.md))
-5. Read `rule-type` and `is-interrupting` from tasks.md; pick the recipe below
-6. Set `displayName`: use tasks.md `display-name` if present; else default to `Entry Rule {N}`, where `N` = the 1-based index this condition takes in `stageNode.data.entryConditions[]` (i.e. `entryConditions.length + 1` at append time). Never emit a blank or omitted `displayName`.
+5. Read the rule type and interrupting flag from the SDD's Stage Entry Conditions row; pick the recipe below
+6. Set `displayName`: use the SDD row's `Display Name` if present; else default to `Entry Rule {N}`. `N` counts **case-wide**, not within this stage: scan the whole `caseplan.json` for existing `Entry Rule <number>` names across every stage's `data.entryConditions[]` and every task's `entryConditions[]`, then `N` = highest + 1 (`1` when none). A per-stage counter collides with the identically-defaulted task entry conditions — [case-schema.md § Condition name uniqueness](../../../case-schema.md#condition-name-uniqueness). Never emit a blank or omitted `displayName`.
 7. Append the condition object to `stageNode.data.entryConditions[]`. **When the table has multiple rows, repeat steps 1–7 once per row** — append one condition object per row. Never fold multiple rows into a single condition's `rules` group.
 
 ## Rule Types
@@ -71,7 +71,7 @@ Fires when an upstream stage exits via a `wait-for-user` exit condition and the
 
 ### sla-status-change — case/stage SLA at-risk or breach
 
-Resolve the T-entry's `(sla-target, sla-display-name)` against the SLA object already written in Phase 2 Step 11, then cross-check the same ID in `id-map.json`. `slaId` is always required; never match by array index. Resolve `(sla-target, escalation-display-name)` **only when the T-entry carries one** — an at-risk response. A breach T-entry has no escalation field, and none is invented.
+Resolve the element's `(sla-target, sla-display-name)` against the SLA object already written in Phase 2 Step 11, then cross-check the same ID in `id-map.json`. `slaId` is always required; never match by array index. Resolve `(sla-target, escalation-display-name)` **only when the row carries one** — an at-risk response. A breach element has no escalation field, and none is invented.
 
 Breach — `slaId` alone:
 
@@ -98,7 +98,7 @@ At-risk — adds a concrete escalation declared on that same SLA:
 ]]
 ```
 
-Escalation presence carries the status: `slaId` alone is a **breach** rule (an absent `escalationId` is the persisted representation of Breached); `slaId` plus a concrete **at-risk** `escalationId` on that SLA is an at-risk rule. Never emit the Case Designer's `"any"` escalation sentinel — released `validate` rejects it as a missing escalation. Use separate entry-condition rows when the same stage handles both statuses. Set the containing condition's `isInterrupting` from the T-entry, not from the SLA's scope. The referenced SLA may live on `root` or on any stage; `validate` passes with `isInterrupting` either value.
+Escalation presence carries the status: `slaId` alone is a **breach** rule (an absent `escalationId` is the persisted representation of Breached); `slaId` plus a concrete **at-risk** `escalationId` on that SLA is an at-risk rule. Never emit the Case Designer's `"any"` escalation sentinel — released `validate` rejects it as a missing escalation. Use separate entry-condition rows when the same stage handles both statuses. Set the containing condition's `isInterrupting` from the SDD row, not from the SLA's scope. The referenced SLA may live on `root` or on any stage; `validate` passes with `isInterrupting` either value.
 
 **This scope is the `enter-stage` response — a stage takes the case.** A `start-task` response puts the same rule on the follow-up **task's** `entryConditions` instead ([task-entry-conditions/impl-json.md](../task-entry-conditions/impl-json.md)). Do **not** author `start-task` as a stage-entry rule on the breached stage: `validate` accepts it, but re-entering the stage re-runs every task in it whose `shouldRunOnlyOnce` is `false` (the default), not just the intended follow-up. Response choice, status shape, interrupting semantics, and the defects `validate` cannot see: [sla-response-shapes.md](../../../sla-response-shapes.md). Non-interrupting lanes keep `data.stageType: "secondary"` and `isRequired: false` — never demote them to a regular stage.
 
@@ -125,6 +125,6 @@ In Phase 2, always write the canonical stub from [connector-trigger-impl.md § C
 
 ## Post-Write Verification
 
-Confirm target stage's `data.entryConditions[]` contains the new object with `id`, non-empty `displayName` (SDD value or `Entry Rule {N}` default), `isInterrupting` matching the T-entry, and `rules` carrying the expected `rule` value plus any required side field. For `sla-status-change`, verify `slaId` resolves to an object on the declared SLA target and `isInterrupting` matches the declared response. Check `escalationId` **against the T-entry's status, not for its presence**: an at-risk T-entry must carry one that resolves on that same SLA; a breach T-entry must carry **none**. A missing `escalationId` on a breach rule is correct and complete — do **not** "repair" it by adding one, which silently converts the rule to at-risk ([sla-response-shapes.md § defects `validate` cannot see](../../../sla-response-shapes.md)). For `wait-for-connector`, Phase 2 expects the exact stub; after Phase 3, a resolved rule must have no `"placeholder"` values, use `<stageId>-<ruleId>` on inputs/outputs, and carry root bindings. A remaining stub must map to a reported unresolved connector.
+Confirm target stage's `data.entryConditions[]` contains the new object with `id`, non-empty `displayName` (SDD value or `Entry Rule {N}` default), `isInterrupting` matching the SDD row, and `rules` carrying the expected `rule` value plus any required side field. For `sla-status-change`, verify `slaId` resolves to an object on the declared SLA target and `isInterrupting` matches the declared response. Check `escalationId` **against the row's status, not for its presence**: an at-risk element must carry one that resolves on that same SLA; a breach row must carry **none**. A missing `escalationId` on a breach rule is correct and complete — do **not** "repair" it by adding one, which silently converts the rule to at-risk ([sla-response-shapes.md § defects `validate` cannot see](../../../sla-response-shapes.md)). For `wait-for-connector`, Phase 2 expects the exact stub; after Phase 3, a resolved rule must have no `"placeholder"` values, use `<stageId>-<ruleId>` on inputs/outputs, and carry root bindings. A remaining stub must map to a reported unresolved connector.
 
 <!-- END: impl-json.md -->

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

@@ -8,16 +8,16 @@ Pick this plugin when the sdd.md declares a stage entry condition or a global ev
 
 For when a stage **exits**, use [stage-exit-conditions](../stage-exit-conditions/planning.md). For when a specific **task** starts, use [task-entry-conditions](../task-entry-conditions/planning.md).
 
-## No omission — one T-task per sdd.md Entry Condition row
+## No omission — one caseplan element per sdd.md Entry Condition row
 
-Every stage with an **Entry Condition** declared in sdd.md gets its own stage-entry-condition T-task — **including rule-type `case-entered`** and stages with `is-interrupting: false`. Never skip a condition because the rule-type or field values look like defaults. If sdd.md wrote the row, `tasks.md` emits the T-task.
+Every stage with an **Entry Condition** declared in sdd.md gets its own stage-entry condition — **including rule-type `case-entered`** and stages with `is-interrupting: false`. Never skip a condition because the rule-type or field values look like defaults. If sdd.md wrote the row, the build emits the element.
 
 ## Required Fields from sdd.md
 
 | Field | Source | Notes |
 |-------|--------|-------|
 | `<stage-id>` | previously captured from the stages plugin | Target stage |
-| `display-name` | sdd.md Display Name column (optional) | Carry the SDD value verbatim. Omit when the SDD cell is blank / `—` — do NOT invent one; impl defaults it to `Entry Rule {N}`. e.g., "Pre-check", "Interrupt on Fraud" |
+| `display-name` | sdd.md Display Name column (optional) | Carry a semantic SDD value verbatim, e.g. "Pre-check", "Interrupt on Fraud". Omit when the cell is blank / `—` — do NOT invent one; impl defaults it to `Entry Rule {N}`. A cell already holding that default pattern is the SDD echoing the default, so impl renumbers it case-wide ([case-schema.md § Condition name uniqueness](../../../case-schema.md#condition-name-uniqueness)). |
 | `is-interrupting` | sdd.md (default `false`) | `true` if the condition interrupts the current stage. Required for every secondary-stage entry row, except an `sla-status-change` parallel-oversight row; otherwise `false` is for regular-stage entry only. Carry the sdd.md value — never override it from the rule type or the SLA's scope. |
 | `rationale` | sdd.md Design Rationale | Required reviewer context for why this rule/interrupt is used. Not emitted into caseplan JSON. |
 | `rule-type` | Pick from the catalog below | See §Rule-type catalog |
@@ -27,7 +27,7 @@ Every stage with an **Entry Condition** declared in sdd.md gets its own stage-en
 | `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. A breach rule references the SLA alone; supplying an escalation converts it into an at-risk rule ([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` — resolved via [connector-trigger-planning.md § Planning Pipeline](../../../connector-trigger-planning.md#planning-pipeline) |
 | `condition-expression` | Optional on any rule-type | Extra `=js:` gate on **case state** (`=js:vars.X ...`) — NOT the event payload (no `event` namespace) |
-| `outputs` | SDD **Connector Rule Outputs** block | Optional. `->` (extract field → case var) or `=` (assign expression → case var). See [connector-trigger-planning.md § tasks.md fields (planning)](../../../connector-trigger-planning.md#tasksmd-fields-planning). |
+| `outputs` | SDD **Connector Rule Outputs** block | Optional. `->` (extract field → case var) or `=` (assign expression → case var). See [connector-trigger-planning.md § registry-resolved.json fields (resolution)](../../../connector-trigger-planning.md#registry-resolvedjson-fields-resolution). |
 
 ## Rule-Type Catalog (stage-entry scope)
 
@@ -52,10 +52,12 @@ Allowed `ruleType` values and when to pick each:
 
 Stage entry conditions are created **after** all stages exist (Step 7 in implementation.md). Source/target stage IDs must both be captured by then.
 
-## tasks.md Entry Format
+## Fields to Resolve
 
-```markdown
-## T<n>: Add stage-entry condition for "<stage>" — <summary>
+A condition produces **no `tasks/registry-resolved.json` entry** unless its `rule-type` is `wait-for-connector` (see the note below the block). These are reasoning fields only — Phase 2 reads them from `sdd.md` ([planning.md § Step 4](../../../planning.md)).
+
+```text
+stage-entry condition on "<stage>" — <summary>
 - target-stage: "<stage-name>"
 - rationale: "<why this entry rule belongs on this stage>"
 - display-name: "<name>"   # optional — omit when SDD Display Name cell is blank; impl defaults to "Entry Rule {N}"
@@ -63,23 +65,21 @@ Stage entry conditions are created **after** all stages exist (Step 7 in impleme
 - rule-type: selected-stage-completed
 - selected-stage: "<upstream-stage-name>"
 - condition-expression: "=js:vars.X..."   # optional gate on case state, NOT the event payload
-- order: after T<m>
 - verify: Confirm Result: Success, capture ConditionId
 ```
 
-> `rule-type: wait-for-connector` also needs the connector fields — see [connector-trigger-planning.md § tasks.md fields (planning)](../../../connector-trigger-planning.md#tasksmd-fields-planning).
+> `rule-type: wait-for-connector` also needs the connector fields — see [connector-trigger-planning.md § registry-resolved.json fields (resolution)](../../../connector-trigger-planning.md#registry-resolvedjson-fields-resolution).
 
 `sla-status-change` example:
 
-```markdown
-## T<n>: Add stage-entry condition for "SLA Escalation" — case SLA breached
+```text
+stage-entry condition on "SLA Escalation" — case SLA breached
 - target-stage: "SLA Escalation"
 - rationale: "The case SLA can breach during any active stage, so one interrupting entry replaces per-stage exits."
 - is-interrupting: true
 - rule-type: sla-status-change
 - sla-target: "root"
 - sla-display-name: "Supplier Application SLA"
-- order: after T<m>
 - verify: Confirm Result: Success, capture ConditionId
 ```
 

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

@@ -30,8 +30,8 @@ Rules use DNF — outer array is OR, inner array is AND.
 2. Generate rule ID: `Rule_` + 6 alphanumeric chars
 3. Locate the target stage in `schema.nodes` by ID
 4. Initialize `stageNode.data.exitConditions = []` if absent (regular Stage is created without this key — see [`../../stages/impl-json.md`](../../stages/impl-json.md))
-5. Read `type`, `exit-to-stage`, `marks-stage-complete`, and `rule-type` from tasks.md; pick the recipe below. `exit-to-stage` is a stage **name** — resolve it to `exitToStageId` through `tasks/id-map.json`; never derive the id from the label (`Stage_<name>`).
-6. Set `displayName`: use tasks.md `display-name` if present; else default by `marks-stage-complete`: `true` → `Complete Rule {N}`, `false` → `Exit Rule {N}`. `N` = 1-based index **within the same label kind** — at append time, count existing entries in `stageNode.data.exitConditions[]` whose `marksStageComplete` equals this condition's value, then `N = count + 1`. FE numbers complete and exit rules with independent counters — do NOT use the array's overall length. Never emit a blank or omitted `displayName`.
+5. Read the exit type, exit-to-stage, marks-stage-complete, and rule type from the SDD's Stage Exit Conditions row; pick the recipe below. `exit-to-stage` is a stage **name** — resolve it to `exitToStageId` through `tasks/id-map.json`; never derive the id from the label (`Stage_<name>`).
+6. Set `displayName`: use the SDD row's `Display Name` if present; else default by `marks-stage-complete`: `true` → `Complete Rule {N}`, `false` → `Exit Rule {N}`. FE keeps the two kinds on independent counters, but each counts **case-wide**, not within this stage: scan the whole `caseplan.json` for that kind's pattern across `metadata.caseExitRules[]` and every stage's `data.exitConditions[]`, then `N` = highest + 1 (`1` when none). A per-stage counter restarts at `1` in each stage and fails `validate` — [case-schema.md § Condition name uniqueness](../../../case-schema.md#condition-name-uniqueness). Never emit a blank or omitted `displayName`.
 7. Append the condition object to `stageNode.data.exitConditions[]`
 
 ## Exit Types
@@ -66,7 +66,7 @@ Rules use DNF — outer array is OR, inner array is AND.
 ]]
 ```
 
-`selectedTasksIds` is a JSON string array, not a comma-separated string. Resolve each planned selector to its taskId via `tasks/id-map.json` using the task's EXACT `tasks.md` display name — never a paraphrase or shortened form (a rule labeled `Determine sign-off level` does not match a task named `Confirm funds and determine sign-off level`; the selector carries the task's exact name). 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 routing cannot depend on optional user-launched work. **Never write a `selected-tasks-completed` rule with an empty or partially resolved `selectedTasksIds`** — an unresolvable name is a stop-and-ask (AskUserQuestion: name the intended task, or repair the plan), never an empty emit. `uip maestro case validate`'s `has no task(s) selected` finding must never be the discovery mechanism (Step 12 Check 13 catches it first).
+`selectedTasksIds` is a JSON string array, not a comma-separated string. Resolve each planned selector to its taskId via `tasks/id-map.json` using the task's EXACT SDD display name — never a paraphrase or shortened form (a rule labeled `Determine sign-off level` does not match a task named `Confirm funds and determine sign-off level`; the selector carries the task's exact name). 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 routing cannot depend on optional user-launched work. **Never write a `selected-tasks-completed` rule with an empty or partially resolved `selectedTasksIds`** — an unresolvable name is a stop-and-ask (AskUserQuestion: name the intended task, or repair the plan), never an empty emit. `uip maestro case validate`'s `has no task(s) selected` finding must never be the discovery mechanism (Step 12 Check 13 catches it first).
 
 ### wait-for-connector — bind a connector event
 
@@ -130,6 +130,6 @@ The exception lane's entry is `selected-stage-exited("<origin>") + IF =js:(vars.
 
 ## Post-Write Verification
 
-Confirm target stage's `data.exitConditions[]` contains the new object with `id`, non-empty `displayName` (SDD value or `Complete Rule {N}` / `Exit Rule {N}` default keyed to `marksStageComplete`), `type`, `exitToStageId` (if set), `marksStageComplete` matching the T-entry, and `rules` carrying the expected `rule` value plus any required side field. For `wait-for-connector`, Phase 2 expects the exact stub; after Phase 3, a resolved rule must have no `"placeholder"` values, use `<stageId>-<ruleId>` on inputs/outputs, and carry root bindings. A remaining stub must map to a reported unresolved connector.
+Confirm target stage's `data.exitConditions[]` contains the new object with `id`, non-empty `displayName` (SDD value or `Complete Rule {N}` / `Exit Rule {N}` default keyed to `marksStageComplete`), `type`, `exitToStageId` (if set), `marksStageComplete` matching the SDD row, and `rules` carrying 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 `<stageId>-<ruleId>` on inputs/outputs, and carry root bindings. A remaining stub must map to a reported unresolved connector.
 
 <!-- END: impl-json.md -->

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

@@ -8,16 +8,16 @@ Pick this plugin when the sdd.md **literally uses the phrase "stage exit conditi
 
 For when a stage **enters**, use [stage-entry-conditions](../stage-entry-conditions/planning.md).
 
-## No omission — one T-task per sdd.md Exit Condition row
+## No omission — one caseplan element per sdd.md Exit Condition row
 
-Every stage with an **Exit Condition** declared in sdd.md gets its own stage-exit-condition T-task — **including type `exit-only`, rule-type `required-tasks-completed`, and `marks-stage-complete: true`**. Never skip a condition because it looks like "the obvious default completion." If sdd.md wrote the row, `tasks.md` emits the T-task.
+Every stage with an **Exit Condition** declared in sdd.md gets its own stage-exit condition — **including type `exit-only`, rule-type `required-tasks-completed`, and `marks-stage-complete: true`**. Never skip a condition because it looks like "the obvious default completion." If sdd.md wrote the row, the build emits the element.
 
 ## Required Fields from sdd.md
 
 | Field | Source | Notes |
 |-------|--------|-------|
 | `<stage-id>` | Captured from the stages plugin | Target stage |
-| `display-name` | sdd.md Display Name column (optional) | Carry the SDD value verbatim. Omit when the SDD cell is blank / `—` — do NOT invent one; impl defaults it to `Complete Rule {N}` (marks-stage-complete `true`) / `Exit Rule {N}` (`false`). |
+| `display-name` | sdd.md Display Name column (optional) | Carry a semantic SDD value verbatim. Omit when the cell is blank / `—` — do NOT invent one; impl defaults it to `Complete Rule {N}` (marks-stage-complete `true`) / `Exit Rule {N}` (`false`). A cell already holding that default pattern is the SDD echoing the default, so impl renumbers it case-wide ([case-schema.md § Condition name uniqueness](../../../case-schema.md#condition-name-uniqueness)). |
 | `type` | sdd.md exit style | `exit-only` / `wait-for-user` / `return-to-origin` |
 | `exit-to-stage-id` | sdd.md routing target (optional) | Required when routing to a specific stage |
 | `marks-stage-complete` | sdd.md (default depends on type) | `true` for completion exits, `false` for diverging routes |
@@ -25,7 +25,7 @@ Every stage with an **Exit Condition** declared in sdd.md gets its own stage-exi
 | `selected-tasks-ids` | Required for `selected-tasks-completed` | Comma-separated task IDs. Selected tasks must be non-adhoc siblings in the same stage. |
 | `connector fields` | SDD **Connector Rule Detail** block | `type-id` (activity-type-id), `connector-key`, `connection-id`, `object-name`, `event-operation`, `event-mode`, `input-values`, optional `filter` — see [connector-trigger-planning.md § Planning Pipeline](../../../connector-trigger-planning.md#planning-pipeline) |
 | `condition-expression` | Optional on any rule-type | Extra `=js:` gate on **case state** (`=js:vars.X ...`) — NOT the event payload (no `event` namespace) |
-| `outputs` | SDD **Connector Rule Outputs** block | Optional. `->` (extract field → case var) or `=` (assign expression → case var). See [connector-trigger-planning.md § tasks.md fields (planning)](../../../connector-trigger-planning.md#tasksmd-fields-planning). |
+| `outputs` | SDD **Connector Rule Outputs** block | Optional. `->` (extract field → case var) or `=` (assign expression → case var). See [connector-trigger-planning.md § registry-resolved.json fields (resolution)](../../../connector-trigger-planning.md#registry-resolvedjson-fields-resolution). |
 
 ## Exit Type Catalog
 
@@ -61,10 +61,12 @@ Before planning `selected-tasks-completed`, verify the selected tasks are not ad
 
 Stage exit conditions are created **after** all tasks in the stage have been added (so `selected-tasks-ids` can resolve). Planning records task names; implementation looks up captured IDs.
 
-## tasks.md Entry Format
+## Fields to Resolve
 
-```markdown
-## T<n>: Add stage-exit condition for "<stage>" — <summary>
+A condition produces **no `tasks/registry-resolved.json` entry** unless its `rule-type` is `wait-for-connector` (see the note below the block). These are reasoning fields only — Phase 2 reads them from `sdd.md` ([planning.md § Step 4](../../../planning.md)).
+
+```text
+stage-exit condition on "<stage>" — <summary>
 - target-stage: "<stage-name>"
 - display-name: "<name>"                        # optional — omit when blank; impl defaults to "Complete Rule {N}"/"Exit Rule {N}" per marks-stage-complete
 - type: exit-only
@@ -73,10 +75,9 @@ Stage exit conditions are created **after** all tasks in the stage have been add
 - rule-type: required-tasks-completed
 - selected-tasks: "<Task A>, <Task B>"          # only if rule-type requires
 - condition-expression: "=js:vars.X..."         # optional gate on case state, NOT the event payload
-- order: after T<m>
 - verify: Confirm Result: Success, capture ConditionId
 ```
 
-> `rule-type: wait-for-connector` also needs the connector fields — see [connector-trigger-planning.md § tasks.md fields (planning)](../../../connector-trigger-planning.md#tasksmd-fields-planning).
+> `rule-type: wait-for-connector` also needs the connector fields — see [connector-trigger-planning.md § registry-resolved.json fields (resolution)](../../../connector-trigger-planning.md#registry-resolvedjson-fields-resolution).
 
 <!-- END: planning.md -->

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

@@ -33,8 +33,8 @@ Rules use DNF — outer array is OR, inner array is AND.
 3. Locate the target stage in `schema.nodes` by ID
 4. Locate the target task inside `stageNode.data.tasks[lane][index]` (search every lane until the task ID is found)
 5. Initialize `task.entryConditions = []` if absent
-6. Read `rule-type` from tasks.md; pick the recipe below
-7. Set `displayName`: use tasks.md `display-name` if present; else default to `Entry Rule {N}`, where `N` = the 1-based index this condition takes in `task.entryConditions[]` (i.e. `entryConditions.length + 1` at append time). Never emit a blank or omitted `displayName`.
+6. Read the rule type from the SDD's Entry Condition table; pick the recipe below
+7. Set `displayName`: use the SDD row's `Display Name` if present; else default to `Entry Rule {N}`. `N` counts **case-wide**, not within this task: scan the whole `caseplan.json` for existing `Entry Rule <number>` names across every stage's `data.entryConditions[]` and every task's `entryConditions[]`, then `N` = highest + 1 (`1` when none). A per-task counter names every unnamed first condition `Entry Rule 1` and fails `validate` — [case-schema.md § Condition name uniqueness](../../../case-schema.md#condition-name-uniqueness). Never emit a blank or omitted `displayName`.
 8. Append the condition object to `task.entryConditions[]`
 
 ## Rule Types
@@ -57,7 +57,7 @@ Rules use DNF — outer array is OR, inner array is AND.
 ]]
 ```
 
-`selectedTasksIds` is a JSON string array. Resolve each planned selector to its taskId via `tasks/id-map.json` using the task's EXACT `tasks.md` display name — never a paraphrase or shortened form. 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. **Never write a `selected-tasks-completed` rule with an empty or partially resolved `selectedTasksIds`** — an unresolvable name is a stop-and-ask (AskUserQuestion: name the intended task, or repair the plan), never an empty emit. `uip maestro case validate`'s `has no task(s) selected` finding must never be the discovery mechanism (Step 12 Check 13 catches it first).
+`selectedTasksIds` is a JSON string array. Resolve each planned selector to its taskId via `tasks/id-map.json` using the task's EXACT SDD display name — never a paraphrase or shortened form. 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. **Never write a `selected-tasks-completed` rule with an empty or partially resolved `selectedTasksIds`** — an unresolvable name is a stop-and-ask (AskUserQuestion: name the intended task, or repair the plan), never an empty emit. `uip maestro case validate`'s `has no task(s) selected` finding must never be the discovery mechanism (Step 12 Check 13 catches it first).
 
 ### adhoc — expression gate
 
@@ -149,8 +149,8 @@ When a *stage* should take the case instead, the rule goes on the stage's `entry
 
 ## 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`, 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.
+Confirm target task's `entryConditions[]` length equals the number of Entry Condition rows the SDD declares 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.
 
-**This count-parity check is not a safety net on its own** — it only confirms Step 10 wrote what `tasks.md §4.7` asked for; if `tasks.md` never recorded a task-entry T-entry (a Phase 1 planning gap), parity holds at zero and the task silently ends up with no entry rule, which hangs `case debug` indefinitely instead of failing any build-time check. [`implementation.md § Step 12 Check 15`](../../../implementation.md#step-12--end-of-phase-3-validator-pass) is the mandatory backstop that re-derives the expected rule from `tasks.md`/the source SDD independent of whether Step 10 ran.
+**This count-parity check is not a safety net on its own** — it only confirms Step 10 wrote what the SDD's condition rows asked for; if the write was skipped entirely (a Phase 1 planning gap), parity holds at zero and the task silently ends up with no entry rule, which hangs `case debug` indefinitely instead of failing any build-time check. [`implementation.md § Step 12 Check 15`](../../../implementation.md#step-12--end-of-phase-3-validator-pass) is the mandatory backstop that re-derives the expected rule from the source SDD independent of whether Step 10 ran.
 
 <!-- END: impl-json.md -->

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

@@ -8,9 +8,9 @@ Pick this plugin when the sdd.md **literally uses the phrase "task entry conditi
 
 For **stage-level** conditions (entire stage enters/exits), use [stage-entry-conditions](../stage-entry-conditions/planning.md) / [stage-exit-conditions](../stage-exit-conditions/planning.md).
 
-## No omission — one T-task per sdd.md Entry Condition row
+## No omission — one caseplan element per sdd.md Entry Condition row
 
-Every task in sdd.md that declares an **Entry Condition** row gets its own task-entry-condition T-task — **including rule-type `current-stage-entered`**. Do NOT skip, collapse, or omit a condition because the rule-type looks like a default. If sdd.md wrote the row, `tasks.md` emits the T-task. "The default behavior would already cover it" is not a valid reason to omit.
+Every task in sdd.md that declares an **Entry Condition** row gets its own task-entry condition — **including rule-type `current-stage-entered`**. Do NOT skip, collapse, or omit a condition because the rule-type looks like a default. If sdd.md wrote the row, the build emits the element. "The default behavior would already cover it" is not a valid reason to omit.
 
 ## Required Fields from sdd.md
 
@@ -18,7 +18,7 @@ Every task in sdd.md that declares an **Entry Condition** row gets its own task-
 |-------|--------|-------|
 | `<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}`. |
+| `display-name` | sdd.md Display Name column (optional) | Carry a semantic SDD value verbatim. Omit when the cell is blank / `—` — do NOT invent one; impl defaults it to `Entry Rule {N}`. A cell already holding that default pattern is the SDD echoing the default, so impl renumbers it case-wide ([case-schema.md § Condition name uniqueness](../../../case-schema.md#condition-name-uniqueness)). |
 | `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` |
@@ -26,7 +26,7 @@ Every task in sdd.md that declares an **Entry Condition** row gets its own task-
 | `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-planning.md § Planning Pipeline](../../../connector-trigger-planning.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-planning.md § tasks.md fields (planning)](../../../connector-trigger-planning.md#tasksmd-fields-planning). |
+| `outputs` | SDD **Connector Rule Outputs** block | Optional. `->` (extract field → case var) or `=` (assign expression → case var). See [connector-trigger-planning.md § registry-resolved.json fields (resolution)](../../../connector-trigger-planning.md#registry-resolvedjson-fields-resolution). |
 
 ## Rule-Type Catalog (task-entry scope)
 
@@ -53,25 +53,26 @@ The Case App selector has three distinct modes:
 
 `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.
 
-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.
+During design-lane authoring (`uipath-planner`), 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:
+The task's **Activation Mode** in the SDD must already be settled before its entry condition is written:
 
 ```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.
+This pair lives on the task's own SDD row, not on this condition. This file's own entry format below uses `rule-type:`, not `entry-rule:` — the two fields are not interchangeable and belong to two different rows. Writing `rule-type:` here does NOT retroactively satisfy the per-task requirement; if the task's own SDD row 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:
+For every task-entry-condition element, 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` |
+| `parallel-after-predecessor` | `runs-sequentially`, with the siblings sharing the next task set after one predecessor |
 | `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 |
@@ -85,22 +86,23 @@ Task entry conditions are created **after** all tasks in the stage have been add
 
 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
+## Fields to Resolve
 
-```markdown
-## T<n>: Add task-entry condition for "<task>" in "<stage>" — <summary>
+A condition produces **no `tasks/registry-resolved.json` entry** unless its `rule-type` is `wait-for-connector`. These are reasoning fields only — Phase 2 reads them from `sdd.md` ([planning.md § Step 4](../../../planning.md)).
+
+```text
+task-entry condition on task "<task>" in stage "<stage>" — <summary>
 - target-stage: "<stage-name>"
 - target-task: "<task-name>"
-- activation-mode: sequential | parallel | event-triggered | adhoc | fan-in | conditional-gate
+- activation-mode: sequential | parallel | parallel-after-predecessor | 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>"
 - condition-expression: "=js:vars.X..."   # optional gate on case state, NOT the event payload
-- order: after T<m>
 - verify: Confirm Result: Success, capture ConditionId
 ```
 
-> `rule-type: wait-for-connector` also needs the connector fields — see [connector-trigger-planning.md § tasks.md fields (planning)](../../../connector-trigger-planning.md#tasksmd-fields-planning).
+> `rule-type: wait-for-connector` also needs the connector fields — see [connector-trigger-planning.md § registry-resolved.json fields (resolution)](../../../connector-trigger-planning.md#registry-resolvedjson-fields-resolution).
 
 <!-- END: planning.md -->

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

@@ -35,13 +35,13 @@ issues.append({                 # pseudocode — not executed
 
 ## Flush — at every section boundary (MANDATORY)
 
-Flush alongside the section's validate, then clear the buffer. Sections are the ones named in [`implementation.md` § Per-section batched writes](../../implementation.md): Phase 2 §4.2.1 vars, §4.3 triggers, §4.4 stages, §4.6 task shapes, §4.8 SLA, §4.7 conditions; Phase 3 §9.7 connector schema, §9.8 I/O binding, §10.5 connector-rule upgrades.
+Flush alongside the section's validate, then clear the buffer. Sections are the ones named in [`implementation.md` § Per-section batched writes](../../implementation.md): Phase 2 vars, triggers, stages, task shapes, SLA, conditions; Phase 3 Step 9.7 connector schema, Step 9.8 I/O binding, §10.5 connector-rule upgrades.
 
 **Flush even when the section produced zero issues** — the file's existence after the first section is what proves the log survived.
 
 ### First flush — create the file (Write)
 
-```markdown
+```text
 # Build Issues — <CaseName>
 
 **Case file:** caseplan.json | **Build started:** <ISO>
@@ -84,7 +84,7 @@ Read the journal back, group by `plugin`, and replace **only** the block between
 
 ## Recovery — journal missing at Step 12.1
 
-If `tasks/build-issues.md` does not exist when Step 12.1 runs, the incremental flush was skipped. Reconstruct what the artifacts prove — `<UNRESOLVED>` markers in `tasks.md`, placeholder tasks (`data: {}`) in `caseplan.json`, `selected: null` entries in `tasks/registry-resolved.json`, and any surviving connector stub — and stamp the file:
+If `tasks/build-issues.md` does not exist when Step 12.1 runs, the incremental flush was skipped. Reconstruct what the artifacts prove — `<UNRESOLVED>` markers in `registry-resolved.json`, placeholder tasks (`data: {}`) in `caseplan.json`, `selected: null` entries in `tasks/registry-resolved.json`, and any surviving connector stub — and stamp the file:
 
 ```
 NOTE: reconstructed at Step 12.1 from on-disk artifacts — the incremental journal was not written. Severity and step attribution are approximate.

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

@@ -6,11 +6,11 @@ Cross-cutting direct-JSON rules live in [`case-editing-operations.md`](../../cas
 
 ## Purpose
 
-Compose the `slaRules[]` array for each target (root or stage) in one write. Group all SLA T-entries by target and emit the full array in a single mutation.
+Compose the `slaRules[]` array for each target (root or stage) in one write. Group all SLA rows by target and emit the full array in a single mutation.
 
-## Input spec (from `tasks.md §4.8`)
+## Input spec (from the SDD's SLA tables)
 
-| T-entry kind | Required fields | Notes |
+| element kind | Required fields | Notes |
 |---|---|---|
 | Default SLA | `target`, `count`, `unit`, `display-name` | One per target. Emitted as the `=js:true` entry, always last. |
 | Conditional rule | `target: "root"` \| `"<stage-name>"`, `condition` (natural-language), `count`, `unit`, `display-name` | Translated to `=js:<expr>` at execution and prepended to the target's default; see Expression Translation below. |
@@ -21,7 +21,7 @@ Compose the `slaRules[]` array for each target (root or stage) in one write. Gro
 - 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).
 
-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.
+Mint these IDs while composing the Phase 2 objects, check them against existing caseplan/id-map IDs, and record them immediately: every SLA element 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
 
@@ -34,7 +34,7 @@ Mint these IDs while composing the Phase 2 objects, check them against existing
 
 ## Recipe — one target
 
-After grouping T-entries by target, compose the `slaRules` array and write it into the target's location per the rules above.
+After grouping elements by target, compose the `slaRules` array and write it into the target's location per the rules above.
 
 ### Composed array
 
@@ -82,11 +82,11 @@ For a stage target, the same `slaRules` array is written under `node.data.slaRul
 
 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 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.
+1. **Conditional rules first, in element order.** Priority = sdd order (top-most wins).
+2. **Default rule (`=js:true`) last.** Always emitted when any SLA element targets this node — even escalation-only cases.
+3. **Escalation-only default rule is legal, but it still needs an ID and title.** If a target has escalations but no default SLA row, 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.
+5. **Omit `slaRules` key entirely** on targets with no SLA elements.
 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
@@ -94,7 +94,7 @@ Emission rules:
 ```json
 {
   "id": "esc_xxxxxx",
-  "displayName": "<from T-entry, or generated: Escalation rule <N> - <parent SLA displayName>>",
+  "displayName": "<from element, or generated: Escalation rule <N> - <parent SLA displayName>>",
   "action": {
     "type": "notification",
     "recipients": [
@@ -108,23 +108,23 @@ Emission rules:
 }
 ```
 
-- `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[]`).
+- `displayName` is **required** (schema v27). Use the SDD row'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**.
 
 ## Unresolved recipients (placeholder-style)
 
-Phase 1 runs the identity resolver (see [`planning.md` § Identity Resolution](planning.md#identity-resolution)) and normally writes a UUID into `tasks.md`. When `tasks.md` still carries an `<UNRESOLVED: ...>` sentinel for a recipient (resolver failed, user declined, or sdd input was unresolvable), emit the recipient with a sentinel `target`:
+Phase 1 runs the identity resolver (see [`planning.md` § Identity Resolution](planning.md#identity-resolution)) and normally writes a UUID into `registry-resolved.json`. When it still carries an `<UNRESOLVED: ...>` sentinel for a recipient (resolver failed, user declined, or sdd input was unresolvable), emit the recipient with a sentinel `target`:
 
 ```json
 { "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 2 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 the SDD 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 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.
+SDD SLA rows 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
 
@@ -139,7 +139,7 @@ A breach rule references the SLA alone (`slaId`, no `escalationId`), so a breach
 ## 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 the trailing entry's `expression === "=js:true"` when any SLA element targeted this node.
 - 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.