@uipath/skills 1.199.0 → 1.200.0

package/skills/uipath-maestro-case/references/sdd-generation-rules.md

@@ -1,12 +1,12 @@
 # SDD Generation Rules
 
-Content-quality contract for Phase 0's `sdd.md`. The interview in [phase-0-interview.md](phase-0-interview.md) owns the **conversation flow** (Listen / Sketch / Confirm / Build start). This file owns the **content rules** the in-memory case model must satisfy before the confirmation is presented — and therefore before `sdd.md` renders from it. Where older wording says "Approve" or "the Approve summary", read the §Confirm checkpoint and its `Decisions I made` block.
+Content-quality contract for Phase 0's `sdd.md`. The interview in [phase-0-interview.md](phase-0-interview.md) owns the **conversation flow** (Listen / Sketch / Confirm / Build start). This file owns the **content rules** the in-memory case model must satisfy before the confirmation is presented — and therefore before `sdd.md` renders from it. Where older wording says "Approve" or "the Approve summary", read the §Confirm checkpoint and its `Decisions I Made` table.
 
 Phase 1 trusts `sdd.md` as written (SKILL.md Rule 2). These rules make that trust safe.
 
 ## Mental model: stages, secondary stages, tasks
 
-Reason the case shape from the process the user describes — **do not reach for the template first.** The template renders a shape you already decided; it does not decide it for you. Build the model in this order: stages → tasks → types → pull exceptions out. Each concept below is a question to ask of the user's process, not a slot to fill.
+Reason the case shape from the process the user describes — **do not reach for the template first.** The template renders a shape you already decided; it does not decide it for you. Build the model in this order: stages → tasks → types → sweep other paths. Each concept below is a question to ask of the user's process, not a slot to fill.
 
 **Stage** — a phase the case works through: a bounded milestone with an *entry* (when it starts), *tasks* (the work done inside it), and a *completion/exit* (when it's done and where the case goes next). Stages are the backbone; they run in sequence (or parallel), wired by **entry/exit conditions** (the case has no edges — transitions are condition-driven). Derive one stage per milestone the user names ("intake", "underwriting", "funding"). Ask: *what is the case working toward right now, and what makes that done?* A stage that "marks the case complete" is on the main flow (`isRequired: true`).
 
@@ -16,11 +16,56 @@ Reason the case shape from the process the user describes — **do not reach for
 - **Entered by its own condition**, never by an edge — but the entry shape depends on the lane's trigger:
   - **(a) Mid-stage interrupt** — user-launched (`user-selected-stage`, paired with a `wait-for-user` exit) or external (`wait-for-connector`). Fires *while the origin is still active* and genuinely interrupts it.
   - **(b) Decision/signal divert** — the **origin** stage carries a **gated diverting exit** (`Marks Stage Complete: No`, `IF` on the decision/signal, `exitToStageId` → this lane), and this lane's `selected-stage-exited(origin) + IF` entry **matches** it. Fires when the origin *exits* — a divert-and-return, NOT a true mid-stage interrupt. The secondary lane still carries `Interrupting: Yes`; a variable-driven mid-stage interrupt is not expressible without a connector, so a decision- or signal-gated lane MUST use shape (b). See [§ Logical integrity step 5](#logical-integrity--stage-graph).
-- **Every secondary-stage entry is interrupting** — set the stage-level `Interrupting` field to `Yes` and set every Stage Entry Conditions row for that secondary stage to `Interrupting: Yes`. A secondary stage with `Interrupting: No` is misclassified; make it a regular parallel stage or an `adhoc` task instead.
-- **Exits by intent** — returning/rework lanes use `return-to-origin` to route back to the origin stage; terminal lanes use `exit-only` plus a root case-exit row. Neither shape uses a new edge. Since secondary stages are interrupting lanes, both shapes still require `Interrupting: Yes` on the stage and every entry row.
+  - **(c) SLA status response (`enter-stage` only)** — `sla-status-change` references the target SLA rule, plus one of its at-risk escalation rules when the status is at-risk. It can fire while any stage in that SLA's scope is active. Interrupting or not depends on what the response does to active work — see § SLA response model. The other SLA response that creates work, `start-task`, is **not** a secondary-stage shape at all: it is a task-entry rule inside the breached stage, so it never reaches this list.
+- **Every secondary-stage entry is interrupting — one carve-out.** Set the stage-level `Interrupting` field to `Yes` and set every Stage Entry Conditions row for that secondary stage to `Interrupting: Yes`. A secondary stage with `Interrupting: No` is misclassified; make it a regular parallel stage or an `adhoc` task instead. **Carve-out:** when an `sla-status-change` response is *parallel oversight* — the breached work keeps running, nothing is paused, taken over, or rerouted — the stage-level `Interrupting` field **and** that entry row both read `No` (§ SLA response model). Never render `Interrupting: Yes` on the stage while its only entry row reads `No`; that contradiction is a blocking render error. The lane stays `stageType: secondary`, `isRequired: false`, and out of the happy-path completion set; do NOT promote it to a regular stage, which would make it required for case completion. This carve-out is scoped to `sla-status-change` only: `wait-for-connector`, `user-selected-stage`, and diverting `selected-stage-exited` rows are always `Yes`.
+- **Exits by intent** — returning/rework lanes use `return-to-origin` to route back to the origin stage; terminal lanes use `exit-only` plus a root case-exit row. Neither shape uses a new edge. Both shapes require `Interrupting: Yes` on the stage and every entry row, except the non-diverting `sla-status-change` oversight row carved out above.
 
 Ask: *does this work belong at one fixed point (regular stage), or could it happen at several points / only on a condition (secondary stage)?* "Handle rejected application", "escalate on SLA breach", "rework loop" → secondary. Returning work uses `return-to-origin`; terminal rejection/withdrawal/cancel work uses `exit-only` plus a case-exit row. Pull these out of the main flow; do not string them inline as ordinary stages.
 
+**Global-event normalization.** When an external status event (for example, a withdrawal received from a portal) or an SLA status change may happen at any point **and requires case work/routing**, define it once on the destination response, not once per primary stage. Use `wait-for-connector` for the external event and `sla-status-change` for a case/stage SLA response that enters a stage. Do **not** add the same task or exit rule to every primary stage: a true interrupting secondary-stage entry exits whichever stage is active. A recoverable lane returns with `return-to-origin`; a terminal lane uses `exit-only` plus a root case-exit rule.
+
+**SLA response model.** Two SLA scopes exist: **case** and **stage**. Separate the clock from the response, and pick the response from the source — not from the scope. Emit-side contract (rule JSON, task-vs-stage entry, CLI-verified shapes): [sla-response-shapes.md](sla-response-shapes.md).
+
+| Response | Choose when the source says | Shape | Interrupting |
+|---|---|---|---|
+| `notify-only` | notify / alert / email / page a person or group | SLA escalation notification only — no stage, no task | n/a |
+| `start-task` | local work inside the **same** breached stage: reminder, reassignment, manager check, extra approval, follow-up | the follow-up task lives in the breached stage and carries the `sla-status-change` rule on **its own task-entry** row, referencing that stage's own SLA. **No stage-entry row, no new stage** — a stage-entry rule would re-enter the stage and re-run its other tasks | `—` (a task entry interrupts nothing) |
+| `enter-stage` | ownership change, escalation lane, recovery, or a visible lifecycle step | a separate stage carries the `sla-status-change` entry | `Yes` when the response takes over, pauses, exits, or reroutes active work; `No` for parallel oversight while work continues |
+| `exit-stage` | the current stage should end, fail, or route away | stage-exit row | per exit semantics |
+| `exit-case` | the whole case should close, cancel, fail, or reach an alternate terminal outcome | §1.4a case-exit row | per exit semantics |
+
+A **case**-level SLA response that changes the graph enters a separate stage. A **stage**-level SLA response may either start a task in the breached stage (`start-task`, a task-entry rule) or route to a separate stage (`enter-stage`, a stage-entry rule that may interrupt or not).
+
+**`start-task` vs `enter-stage` is decided by WHERE the work lives — not by whether it interrupts.** `enter-stage` can itself be non-interrupting, so "the team keeps working" does not point to either one. Ask instead: does the source put the follow-up **inside the breached stage's own work**, or does it hand the case to a **separate lane**?
+
+| Source wording | Response | What you author |
+|---|---|---|
+| "as part of the assessment", "inside the review", "the assessor/reviewer keeps working and also does X", a named task for a manager or peer | `start-task` | one task in the breached stage, carrying `sla-status-change` as its **task-entry** row against that stage's own SLA. **No new stage, and no stage-entry row.** |
+| "hand it to", "a lane/team takes it over", "escalate into <Lane>", "a director tracks it", a named *stage* or lane | `enter-stage` | a separate stage carrying the `sla-status-change` entry row |
+
+A named **task** ("raise a Senior Assessor Check approval") is never a reason to mint a stage. If the `Target` you are about to write is the name of a task rather than a stage that the source describes as its own lane, the response is `start-task`, the `Target` cell holds that task name, and the task goes in the breached stage.
+
+**Status rides on the escalation reference.** A breach response references the SLA alone — an absent escalation reference *is* how a breach rule is stored. An at-risk response also names one concrete at-risk escalation on that SLA, which must exist: an SLA with no at-risk escalation cannot carry an at-risk response. Never author the Case Designer's `any`-escalation shorthand — released `validate` rejects it as a missing escalation.
+
+**Action-task SLA** is not a case/stage `slaRules[]` entry: configure the action task's own timer/SLA fields, and add `sla-status-change` case behavior only when the missed task must change the case graph.
+
+**No stated response → default:** at-risk `notify-only` to the owning persona/group; breached `notify-only` to the next escalation tier. Do not invent a stage, task, or routing change unless the source says the breach creates work or changes routing.
+
+Expose every choice in the **SLA Response Map** (`Scope | SLA | Status | Response | Target | Interrupting | Rationale`). Never hide breach behavior inside SLA duration text.
+
+**Other-path sweep.** Before Phase 0 confirmation, actively look beyond the primary flow. Consider rework / needs-info loops; rejection, withdrawal, and cancellation; SLA escalation; external-system failure; manual override or worker-selected side work; optional side work; and terminal outcomes that differ from successful completion. Do not force every item into a secondary stage: choose the smallest faithful model, such as a secondary stage, terminal case exit, non-completing case exit, task-level branch, `adhoc` task, or SLA notification-only row. Clear source signals are modeled by best assumption and disclosed in the confirmation's **Other Paths Considered** table. When the source has no signal at all, Phase 0 asks one bounded question before confirmation; if the user chooses primary-flow-only, record that as an intentional decision and do not invent a path.
+
+**Case execution patterns.** Classify these before choosing rule types:
+
+| Pattern | Signal | Case model |
+|---|---|---|
+| Strict sequence | "then", "after", "before", direct prerequisite | consecutive single-task sets; every task uses `runs-sequentially` |
+| Parallel after predecessor | "after A, do B and C", both independent | one next task set containing B and C; do not create duplicate `selected-tasks-completed("A")` task entries |
+| Race | confirmation vs timeout/cancellation/withdrawal | listener and clock active while the obligation is pending; downstream work gated by the winning fact |
+| Optional side work | "may", "can manually", "if needed" and no required downstream dependency | `adhoc`, `Required: No`, not selected by required/fan-in rules |
+
+For any non-start stage/task entry, identify its concrete producer before the Case Review: source stage exit/completion, source task completion, connector event detail, paired `wait-for-user`, or SLA scope/display name/status/escalation intent. A rule without a producer is a design defect, even if the rule name is schema-valid.
+
 **Task** — one unit of work inside a stage, owned by a *persona* (a human role) or by the *system* (automation / AI / API). It has an entry condition (when it runs within the stage), inputs, outputs, and a **type** that says *how* the work gets done. One verb in the user's description ≈ one task. Ask: *who or what performs this, and how?* The "how" answer is the task type — see [§ Choosing the task type](#choosing-the-task-type).
 
 Once stages, secondary stages, and tasks are reasoned, the [§ Render contract](#render-contract) below turns each decision into exact cells. Reason first; render second.
@@ -32,10 +77,10 @@ The case, each stage, and each task move through a lifecycle gated by **rules**
 | Gate | What it answers | Legal rule types (CLI) |
 |---|---|---|
 | **Case entry** | how does a case instance begin? | No case-entry condition object — a **trigger** starts the case; the root stage carries `case-entered`. |
-| **Stage entry** | when does this stage activate? | `case-entered` (root only) · `selected-stage-completed` · `selected-stage-exited` · `wait-for-connector` · `user-selected-stage` |
+| **Stage entry** | when does this stage activate? | `case-entered` (root only) · `selected-stage-completed` · `selected-stage-exited` · `wait-for-connector` · `user-selected-stage` · `sla-status-change` |
 | **Stage completion** (`Marks Stage Complete: Yes`) | when is the stage done, on the main flow, a returning lane, or a terminal secondary lane? | `required-tasks-completed` · `wait-for-connector`; exit `type`: `exit-only` / `wait-for-user` / `return-to-origin` |
 | **Stage exit** (`Marks Stage Complete: No`) | early hand-off / route without completing | `selected-tasks-completed` · `wait-for-connector`; exit `type`: `exit-only` / `wait-for-user` |
-| **Task entry** | when does this task start inside its stage? | `current-stage-entered` (stage-started/default tasks) · `selected-tasks-completed` · `wait-for-connector` · `adhoc` · `runs-sequentially` |
+| **Task entry** | when does this task start inside its stage? | `current-stage-entered` (stage-started/default tasks) · `selected-tasks-completed` · `wait-for-connector` · `sla-status-change` (the `start-task` SLA response) · `adhoc` · `runs-sequentially` |
 | **Task completion / exit** | — | A task has **no** exit/completion condition. It completes when its own work finishes; downstream stages/tasks key off that via `required-tasks-completed` / `selected-tasks-completed`. |
 | **Case completion** (`Marks Case Complete: Yes`) | when does the case close successfully? | `required-stages-completed` · `wait-for-connector` |
 | **Case exit** (`Marks Case Complete: No`) | alternate disposition (cancel / route out) | `selected-stage-completed` · `selected-stage-exited` · `wait-for-connector` |
@@ -43,20 +88,21 @@ The case, each stage, and each task move through a lifecycle gated by **rules**
 How to reason with these:
 
 - **`required-*` vs `selected-*`.** `required-tasks-completed` / `required-stages-completed` = "all items flagged required are done" (the `isRequired` flow). `selected-tasks-completed` / `selected-stage-completed` / `selected-stage-exited` = "these *specific named* items." Pairing rule (Key Rule 4): `Marks Complete: Yes` pairs only with `required-*`; `selected-*` is for `No` (routing / early exit / alternate disposition). A `Yes` + `selected-*` pair is a schema error.
-- **Secondary stage** uses **stage-entry + stage-exit rules only, never edges** (true of every stage — edges retired). Its entry rules are always interrupting (`isInterrupting: true`). Returning exits use the canonical completion shape `return-to-origin` + `Marks Stage Complete: Yes` + `required-tasks-completed` to rejoin the flow they left; terminal exits use `exit-only` + `Marks Stage Complete: Yes` plus a root case-exit row. **For a decision/signal-routed lane, the routing lives on the *origin* stage:** a gated diverting exit (`Marks Stage Complete: No`, `IF` on the decision/signal, `exitToStageId` → the lane), with the origin's completion exit gated by the inverse `IF` so the two paths are mutually exclusive — see [§ Logical integrity step 5](#logical-integrity--stage-graph).
-- **Task-entry mode is exclusive.** Use `current-stage-entered` only for stage-started/default tasks. Event-triggered tasks carry the explicit event rule (`wait-for-connector` with connector configuration), adhoc tasks carry only `adhoc`, and sequential tasks carry only `runs-sequentially`; do not add `current-stage-entered` to those tasks just because they are first in a stage. For sequential chains, the first task's `runs-sequentially` means current-stage-entered, and later tasks use it as the preceding-task-completed trigger. `wait-for-connector` makes a gate pause for an inbound connector callback — its `conditionExpression` gates on **case state** only (no `event` payload; in-rule extract-then-gate is unsupported at runtime — gate a downstream condition instead); `adhoc` lets a *task* fire manually from the case app (task-entry only — never a stage-entry rule).
+- **Secondary stage** uses **stage-entry + stage-exit rules only, never edges** (true of every stage — edges retired). Its entry rules are always interrupting (`isInterrupting: true`). Returning exits use the canonical completion shape `return-to-origin` + `Marks Stage Complete: Yes` + `required-tasks-completed` to rejoin the flow they left; terminal exits use `exit-only` + `Marks Stage Complete: Yes` plus a root case-exit row. **For a decision/signal-routed lane, the routing lives on the *origin* stage:** a gated diverting exit (`Marks Stage Complete: No`, `IF` on the decision/signal, `exitToStageId` → the lane), with the origin's completion exit gated by the inverse `IF` so the two paths are mutually exclusive. **For a global connector/SLA event, routing lives only on the destination secondary stage:** no per-origin exit rule is needed. See [§ Logical integrity step 5](#logical-integrity--stage-graph).
+- **Task-entry mode is exclusive.** Use `current-stage-entered` only for stage-started/default tasks. Event-triggered tasks carry the explicit event rule (`wait-for-connector` with connector configuration), adhoc tasks carry only `adhoc`, and sequential tasks carry only `runs-sequentially`; do not add `current-stage-entered` to those tasks just because they are first in a stage. For sequential chains, the first task's `runs-sequentially` means current-stage-entered, and later tasks use it as the preceding-task-completed trigger. `wait-for-connector` makes a gate pause for an inbound connector callback — its `conditionExpression` gates on **case state** only (no `event` payload; in-rule extract-then-gate is unsupported at runtime — gate a downstream condition instead); `adhoc` lets a *task* fire manually from the case app (task-entry only — never a stage-entry rule). A `start-task` SLA response is event-triggered: the task carries `sla-status-change` as its only entry rule, never alongside `current-stage-entered`.
+- **Thresholded role / work gates are executable, not descriptive.** A source rule like "Credit Analyst only over $5M; otherwise Underwriter" must produce a rule, task-entry condition, recipient expression, or computed owner field that references both the threshold and the gated actor/work. Preserve the reviewer-facing phrase close to the expression in the SDD, for example `Credit Analyst route when loanAmount > 5000000`. A persona row alone, or a generic note that does not tie `Credit Analyst` to `>$5M`, is not a modeled gate.
 
-**Frontend task-mode mapping.** The UI's `sequential`, `event-triggered`, and `manually-triggered` choices are not interchangeable: sequential means the task-only `runs-sequentially` rule; event-triggered means an explicit event/condition rule (use `wait-for-connector` for an external connector callback); manually-triggered means an `adhoc`-only task with `isRequired: false`. `adhoc` decides how the task starts; it does not decide the task type. A manually triggered task may still be `action`, `agent`, `api-workflow`, `process`, etc. Do not infer one mode from `data.tasks` lanes, and do not add a second entry rule that changes the selected mode.
+**Frontend task-mode mapping.** The UI's `sequential`, `event-triggered`, and `manually-triggered` choices are not interchangeable: sequential means the task-only `runs-sequentially` rule; event-triggered means an explicit event/condition rule (use `wait-for-connector` for an external connector callback); manually-triggered means an `adhoc`-only task with `isRequired: false`. `adhoc` decides how the task starts; it does not decide the task type. A manually triggered task may still be `action`, `agent`, `api-workflow`, `process`, etc. Do not infer one mode from `data.tasks` lanes, and do not add a second entry rule that changes the selected mode. Downstream plans preserve the confirmed SDD mode and rule exactly: a singleton `parallel` + `current-stage-entered` task stays that way, while `sequential` + `runs-sequentially` requires an explicit order or dependency in the source.
 - **`user-selected-stage`** (stage entry) starts a stage on demand by a user rather than by flow. The CLI validator requires it to pair with a `wait-for-user` stage exit elsewhere: a `wait-for-user` exit with no `user-selected-stage` entry — or a `user-selected-stage` entry with no `wait-for-user` exit — fails `validate`.
 
 Exact cell formats live in [§ Stage content rules](#stage-content-rules) and [§ Task content rules](#task-content-rules) — this table is the conceptual map of *which rule belongs where*.
 
 ### Triggers, connectors, variables — how the case meets the world
 
-**Trigger** — how a case instance is *born* (`TriggerNode`, `case-management:Trigger`, field `data.uipath.serviceType`):
+**Trigger** — how a case instance is *born* (`TriggerNode`, `uipath.case.trigger`, field `data.inputs.serviceType`):
 
 - `None` → **Manual**: a user or API call starts the case.
-- `Intsvc.TimerTrigger` → **Timer**: a schedule starts it.
+- `timer` → **Timer**: a schedule starts it. (SDD author token: `Intsvc.TimerTrigger`.)
 - `Intsvc.EventTrigger` → **Connector Event**: an external system fires it.
 
 One trigger is the root; additional triggers are secondary. Reason: *what makes a new case appear?* A portal signup, inbound form, or schedule is NEVER Manual — assume the event/timer trigger per the playbook and disclose the decision the moment such a source is named.
@@ -113,7 +159,7 @@ When signals conflict, apply this priority — top wins:
 6. **Inferred defaults** per the assumption playbook in [phase-0-interview.md § Sketch](phase-0-interview.md#sketch--best-assumption-every-field).
 7. **General-practice fallback.**
 
-When a higher tier overrides a lower one, apply it and surface it in the confirmation's `Decisions I made` block with provenance `(source: <higher-tier>-override)`.
+When a higher tier overrides a lower one, apply it and surface it in the confirmation's `Decisions I Made` table with provenance `(source: <higher-tier>-override)`.
 
 ## Choosing the task type
 
@@ -173,6 +219,8 @@ Reason the shape first — [§ Mental model](#mental-model-stages-secondary-stag
 
 Phase 1 reads `sdd.md` as written (Rule 2). The following three sections define **what each case / stage / task element MUST contain** before the model may render to `sdd.md`. Every block specifies required vs optional cells, allowed values, source of truth, and the fallback when a value is missing — in Phase 0, "Ask" fallbacks are settled by playbook assumption first and the one clarifying call only when no assumption is defensible.
 
+**Template shape is part of the render contract.** A valid model is not enough if the written file collapses into a prose summary. The rendered `sdd.md` must preserve the structure in `assets/templates/sdd-template.md`: title, table of contents, Section 1/2/3/4 headings, case metadata/triggers/variables, the SLA Response Map when any SLA is configured (§1.2b), one full stage block per modeled stage, one full task detail block per modeled task, personas/app views, and integration/resource inventory. The compact Phase 0 confirmation is not an SDD substitute.
+
 **Allowed `—`** (cells the user did not touch and Phase 1 can default safely): case-level Description, variable defaults, persona scope notes, app-view detail, secondary-stage description, optional `IF` conditionExpressions, business calendars on timers.
 
 **Allowed `<UNRESOLVED>`** (gaps Phase 1 / post-build can resolve): registry IDs (`taskTypeId`, `connectionId`, `actionAppId`, `agentId`, `processOrchestrationId`) when Resolve was skipped or returned 0 matches. Pair every `<UNRESOLVED>` with a review item (§Review items).
@@ -190,34 +238,41 @@ Defines what `sdd.md` Section 1 (Case Definition) must contain.
 | Case Name | yes | PascalCase identifier (e.g., `MortgageLoanOrigination`) | Block Approve. Ask. |
 | Description | optional | One prose sentence | `—` |
 | Identifier prefix | yes | UPPER, 2-4 chars (e.g., `MLO`) | Default mechanically from PascalCase first letters; record in source ledger. |
-| Priority | optional | `Low` / `Medium` / `High` / `Critical` | Default `Medium`; record in source ledger. |
 | Case SLA | conditional | Duration (e.g., `5 business days`) | `—` when case has no SLA; otherwise block Approve. |
 | SLA Type | conditional | `time-based` (single unconditional duration) / `condition-based` (one or more conditionExpression-keyed overrides + a default time-based row) | Default `time-based` when Case SLA set with no per-condition overrides. The FE persists `condition-based` whenever ≥ 1 `slaRules[]` entry carries a non-empty `conditionExpression` (see PO.Frontend `CaseManagementSlaProperties.tsx:27-30`). `condition-based` requires populating the §Variable SLA Rules table; `time-based` omits it. |
+| SLA Title | conditional | Non-empty root-unique SLA rule title, no `:` | Omit the row when Case SLA is `—` (never render `—` here). Else default `SLA Rule 1` and record in source ledger; a title a `sla-status-change` references must be concrete (§ Logical integrity step 6). |
 | Case App | optional | `Enabled` / `Disabled` — whether the in-product Case App UI is on (`metadata.caseAppEnabled`). | Default `Disabled`; record in source ledger. |
 | Task-output passing | optional | `Direct` / `Shared` — `metadata.caseDirectlyPassTaskOutputs`. `Direct` passes a task's outputs straight to downstream tasks (default). | Default `Direct`. |
 
-**PO.Frontend validation parity.** Before Approve, apply the same name and SLA checks that the Case App applies:
+**PO.Frontend validation parity plus safe generated names.** Before Approve, apply the same name and SLA checks that the Case App applies, then apply the skill's stricter safe-display-name contract to anything the skill generates or carries into Case Designer display/title fields.
 
 | Surface | Required checks |
 |---|---|
-| Stage label | Non-empty; unique across stages; no `:`. A non-Case-Manager stage also cannot reuse the reserved default Case Manager stage label when a Case Manager stage exists. |
-| Task display name | No `:` for materialized tasks. |
-| SLA rule title (`displayName`) | Non-empty; unique within the root or stage target; no `:`. |
-| Escalation title (`displayName`) | Non-empty; unique across escalations on the target; no `:`. |
+| Stage label | Non-empty; unique across stages; safe display characters only. A non-Case-Manager stage also cannot reuse the reserved default Case Manager stage label when a Case Manager stage exists. |
+| Task display name | Safe display characters only for materialized tasks. |
+| Rule display name | Safe display characters only for entry, exit, task-entry, and case-exit condition display names. |
+| SLA rule title (`displayName`) | Non-empty; unique within the root or stage target; safe display characters only. |
+| Escalation title (`displayName`) | Non-empty; unique across escalations on the target; safe display characters only. |
 | SLA duration | `count > 0`; when `unit: min`, `15 ≤ count ≤ 1000`. Supported units are `min`, `h`, `d`, `w`, and `m`. |
 | Conditional SLA | Every non-default SLA rule has a non-empty expression/condition. |
 | Escalation payload | Every escalation has at least one recipient; an `at-risk` escalation has an `atRiskPercentage` value. |
 
-These are blocking authoring errors, not optional style warnings. Preserve the user's wording when repairing a name, but ask for a replacement when uniqueness or a reserved delimiter is violated; never silently suffix or truncate it.
+Safe display characters are letters, numbers, spaces, hyphen (`-`), and underscore (`_`) only. Do not generate colons (`:`), periods (`.`), slashes, backslashes, quotes, parentheses, ampersands, commas, semicolons, emoji, or other symbols in stage/task/rule/SLA/escalation display names. Repair unsafe generated or user-carried display names mechanically by replacing runs of disallowed characters with one space, collapsing spaces, and trimming. Preserve words and casing. If the result is empty or collides, pick a safe qualifier or numeric suffix and disclose it in the Case Review.
+
+These are blocking authoring errors, not optional style warnings. Do not normalize external registry or tenant lookup names (Action App titles, process names, connector names, API names, queue/bucket names); those are matching keys. Keep separate safe Case Designer display names when a lookup name contains punctuation.
+
+The same rule governs **numeric** violations: never silently clamp, round, or substitute an out-of-range value to satisfy validation. A minute-based SLA authored below 15 or above 1000 is not repaired to the nearest legal bound — surface the violation and Ask for a replacement duration (or a different `unit`), naming the original value. This applies whether the value came from the interview or from an SDD supplied on disk: rewriting a user-authored duration to pass validation is a silent requirements change, not a fix.
 
 ### 1.2 Case-level SLA escalation
 
 Required when Case SLA is set. Always renders with both rows; no `—` allowed in any cell.
 
-| Threshold | Trigger | Recipient |
-|---|---|---|
-| At-risk | `<pct>%` of case SLA (defaults below) | `UserGroup: <owner-group>` or `User: <name>` |
-| Breached | 100% of case SLA | One tier up — leadership group; Compliance for regulation-driven cases |
+| Threshold | Trigger | Recipient | Display Name |
+|---|---|---|---|
+| At-risk | `<pct>%` of case SLA (defaults below) | `UserGroup: <owner-group>` or `User: <name>` | Non-empty root-unique escalation title, no `:` |
+| Breached | 100% of case SLA | One tier up — leadership group; Compliance for regulation-driven cases | Non-empty root-unique escalation title, no `:` |
+
+`Display Name` defaults to `Escalation Rule {N}` only when no `sla-status-change` entry references that escalation.
 
 **Default thresholds** when user did not name them:
 
@@ -227,6 +282,24 @@ Required when Case SLA is set. Always renders with both rows; no `—` allowed i
 
 **Default recipients:** at-risk → stage/case owner persona's user group; breached → leadership group. Record substitutions in source ledger with reason `default applied — user did not name recipient`.
 
+### 1.2b SLA Response Map
+
+Required whenever **any** SLA is configured — case, stage, or `action` task. One row per `(Scope, SLA, Status)`; render the table per [`sdd-template.md` § SLA Response Map](../assets/templates/sdd-template.md). Columns: `Scope | SLA | Status | Response | Target | Interrupting | Rationale`.
+
+| Field | Required? | Value |
+|---|---|---|
+| Scope | yes | `case`, `stage: <StageName>`, or `task: <TaskName>` |
+| SLA | yes | the target's `SLA Title` (or a Variable SLA Rules `Display Name`) |
+| Status | yes | `At-Risk` or `Breached` — one row each |
+| Response | yes | `notify-only` \| `start-task` \| `enter-stage` \| `exit-stage` \| `exit-case` (§ SLA response model) |
+| Target | yes | `—` for `notify-only`; the **task name** for `start-task` (the task lives in the breached stage); the stage name for `enter-stage`; the exit row it produces for `exit-stage` / `exit-case` |
+| Interrupting | yes | `—` for `notify-only` and for every `start-task` (it is a task-entry rule, and a task entry interrupts nothing); otherwise `Yes`/`No`, matching the `Interrupting` cell of the stage-entry row it produces. `start-task` is never `Yes` or `No`. |
+| Rationale | yes | why this response fits the source |
+
+**Closure both ways (blocking):** every non-`notify-only` row has its matching rule elsewhere in the SDD (an `sla-status-change` **task-entry** row for `start-task`, an `sla-status-change` **stage-entry** row for `enter-stage`, a stage-exit row, or a §1.4a case-exit row), and every `sla-status-change` entry row in the SDD — task or stage scope — has a row here. A mismatch between this map's `Interrupting` cell and the produced entry row's `Interrupting` cell is a blocking error.
+
+**Default:** no stated response → both statuses `notify-only`, `Target` and `Interrupting` `—`. Never invent a stage, task, or routing change to fill this table.
+
 ### 1.3 Triggers
 
 ≥ 1 trigger required. One row per triggering event. Number triggers sequentially starting at **T02** (T01 reserved for the case file). The T-number is the reference key used by Case Variables rows whose value comes from this trigger's payload (§1.5).
@@ -238,7 +311,7 @@ Required when Case SLA is set. Always renders with both rows; no `—` allowed i
 | Source | conditional | Connector or system for `Intsvc.EventTrigger`; schedule expression for `Intsvc.TimerTrigger`; `Manual` literal for `Manual` |
 | Configuration | conditional | User-stated intent only — see Configuration rules below. `Intsvc.EventTrigger` MUST have a concrete operation phrase. |
 
-> **`Manual` is not a `serviceType`.** The CLI serviceType enum is `None` / `Intsvc.EventTrigger` / `Intsvc.TimerTrigger`. A manual trigger carries **no** `serviceType` in `caseplan.json` (absence = manual — see [`plugins/triggers/manual/impl-json.md`](plugins/triggers/manual/impl-json.md)). Author `Manual` in the SDD; never emit `serviceType: "Manual"`.
+> **`Manual` is not a `serviceType`.** The on-disk serviceType enum (`data.inputs.serviceType`) is `None` / `Intsvc.EventTrigger` / `timer` — the SDD's `Intsvc.TimerTrigger` author token maps to on-disk `serviceType: "timer"`. A manual trigger carries **no** `serviceType` in `caseplan.json` (absence = manual — see [`plugins/triggers/manual/impl-json.md`](plugins/triggers/manual/impl-json.md)). Author `Manual` in the SDD; never emit `serviceType: "Manual"`.
 
 **Configuration cell — what to write (user intent only, business terms):**
 
@@ -257,12 +330,7 @@ Required when Case SLA is set. Always renders with both rows; no `—` allowed i
 
 > Variable mapping (which trigger payload field populates which case variable) is declared in **§1.5 Case Variables** via the `sourceTriggers` / `sourceFields` columns — NOT in this table. The Triggers table only identifies and configures each trigger; payload extraction is owned by Case Variables.
 
-> **Tenant object starts are not Manual.** If the user says a case starts when a
-> tenant case-entity / data-object record is created, record an
-> `Intsvc.EventTrigger` row with the object name as Source. Missing tenant
-> provisioning, absent local registry data, or unresolved connection details
-> become an unresolved event trigger / placeholder later; they are never a reason
-> to change the SDD trigger type to `Manual`.
+> **Tenant object starts are not Manual.** If the user says a case starts when a tenant case-entity / data-object record is created, record an `Intsvc.EventTrigger` row with the object name as Source. Missing tenant provisioning, absent local registry data, or unresolved connection details become an unresolved event trigger / placeholder later; they are never a reason to change the SDD trigger type to `Manual`.
 
 Unresolved `Intsvc.EventTrigger` resolution (`connectionId` / `activityTypeId` missing) → `high`-severity review item.
 
@@ -365,10 +433,13 @@ The trailing `` `{stage_id}` `` (e.g., `` `stage-intake` ``) MUST appear so read
 |---|---|---|
 | Type | yes | `Stage` |
 | Stage Kind | optional | `primary` (default — omit the line) / `secondary` (emits `data.stageType: "secondary"`; replaces the old `ExceptionStage` type) |
+| Design Rationale | yes | One concrete sentence explaining why this is primary/secondary and why its entry/exit behavior fits the requirement. For global-event lanes, name the event and state that one interrupting entry replaces per-stage duplication. For an SLA-entered lane, name the SLA, the chosen response, and why it interrupts or does not. |
 | Description | yes (primary) / optional (secondary) | One prose sentence |
 | Required for case completion | yes | `Yes` (primary, default) / `No` (secondary stages always `No`) |
-| Interrupting | secondary stages only | `Yes` — secondary stages are interrupting lanes. If the work should not interrupt, model it as a regular stage/parallel path or an `adhoc` task. |
-| Stage SLA | yes when stage has SLA | Default duration + `time-based` or `condition-based`, plus conditional-rule and escalation tables |
+| Interrupting | secondary stages only | `Yes` — secondary stages are interrupting lanes. `No` only on an `sla-status-change` parallel-oversight row (§ mental model carve-out). Otherwise, if the work should not interrupt, model it as a regular stage/parallel path or an `adhoc` task. |
+| Stage SLA | yes when stage has SLA | Default duration + `time-based` or `condition-based` + `SLA Title` (non-empty, stage-unique, no `:`), plus conditional-rule and escalation tables |
+
+When the source says every primary phase/stage has an SLA target, every named primary stage MUST render its own `#### Stage SLA` block. Use deterministic titles when the user did not supply names: `**SLA Title:** <Stage Name> SLA`, at-risk display name `<Stage Name> SLA at risk`, and breach display name `<Stage Name> SLA breached`. Any `sla-status-change("<Stage Name>",...)` row for that stage must use those exact strings; a title declared on another stage or only in prose does not resolve.
 
 ### Stage Entry Conditions table
 
@@ -376,7 +447,11 @@ The trailing `` `{stage_id}` `` (e.g., `` `stage-intake` ``) MUST appear so read
 
 | WHEN | IF | Interrupting | Display Name |
 |---|---|---|---|
-| `case-entered` (root only) / `selected-stage-completed("<Stage>")` / `selected-stage-exited("<Stage>")` / `wait-for-connector` / `user-selected-stage` | optional `conditionExpression` | `Yes` for every secondary-stage entry row; `No` for regular-stage entry | optional |
+| `case-entered` (root only) / `selected-stage-completed("<Stage>")` / `selected-stage-exited("<Stage>")` / `wait-for-connector` / `user-selected-stage` / `sla-status-change("<SLA target>","<SLA Title>")` (breach) / `sla-status-change("<SLA target>","<SLA Title>","<At-Risk Escalation Display Name>")` (at-risk) | optional `conditionExpression` | `Yes` for every secondary-stage entry row, except an `sla-status-change` parallel-oversight row (`No`); `No` for regular-stage entry | optional |
+
+`sla-status-change` args are specified in [sdd-template.md](../assets/templates/sdd-template.md) § Stage Entry Conditions; closure is enforced by § Logical integrity step 6.
+
+`user-selected-stage` is valid only when another stage has a `wait-for-user` exit that exposes this target to the user. It is not the rule for deterministic rejection, approval, send-back, or SLA routing. Use decision facts plus guarded stage entry/exit rows for deterministic routes.
 
 ### Stage Completion Conditions table (`Marks Stage Complete: Yes`)
 
@@ -413,10 +488,10 @@ Render when the Stage SLA type is `condition-based`. Each expression-keyed overr
 
 Always rendered when Stage SLA is set. Concrete cells in both rows; never `—`.
 
-| Threshold | Trigger | Recipient |
-|---|---|---|
-| At-risk | `<pct>%` of stage SLA (defaults below) | `UserGroup: <owner-group>` / `User: <name>` |
-| Breached | 100% of stage SLA | Leadership group; Compliance for regulation-driven stages |
+| Threshold | Trigger | Recipient | Display Name |
+|---|---|---|---|
+| At-risk | `<pct>%` of stage SLA (defaults below) | `UserGroup: <owner-group>` / `User: <name>` | Non-empty stage-unique escalation title, no `:` |
+| Breached | 100% of stage SLA | Leadership group; Compliance for regulation-driven stages | Non-empty stage-unique escalation title, no `:` |
 
 **Defaults** when user did not name them (mirror §1.2):
 
@@ -451,12 +526,22 @@ When a stage's real work is split across **mutually-exclusive conditional tasks*
 
 The convergence task is the stage's only `Required: Yes` task, so `required-tasks-completed` resolves deterministically whichever branch ran — including the no-branch case. (Worked example from a shipping SDD: an Exception-Resolution stage with per-reason-code action tasks + a `Persist exception resolution` api-workflow convergence task carrying exactly the three rows above.)
 
-**Re-entry safety (`return-to-origin` loops).** A task in a stage that an exception lane returns to via `return-to-origin` **re-runs on re-entry** unless flagged `Run Only Once: Yes`. Set `Run Only Once: Yes` on any such task whose re-execution would clobber a decision made during the exception (e.g. an AP-review task whose decision variable the escalation lane just overwrote) — the returning stage then re-evaluates its exit against the lane's decision without re-prompting the original actor. This is the one case where `Run Only Once` is load-bearing rather than cosmetic.
+**Re-entry safety (`return-to-origin` loops).** A task in a stage that an exception lane returns to via `return-to-origin` re-runs on re-entry unless flagged `Run Only Once: Yes`. Classify the loop before setting that flag:
+
+| Re-entry type | Signal | `Run Only Once` default | State handling |
+|---|---|---|---|
+| New attempt / resubmission | corrected, revised, fixed, resubmitted, retry, re-review, revalidate, appeal, counter-proposal | `No` for request/review/decision/validation producer tasks that must produce a fresh result | Reset live routing variables to a neutral value before the attempt, or write results to attempt-scoped/latest variables |
+| Re-evaluate existing fact | exception lane changes a fact and returns only so the origin can continue routing | `Yes` only on producer tasks whose prior output must be preserved | Preserve the fact deliberately and document which downstream rule re-reads it |
+| Optional repeat work | user may repeat work, but required flow does not depend on it | Usually `adhoc` or non-required | Do not let required flow depend on the optional task |
+
+If the requirement says corrected work is resubmitted through a review or decision, the review/request/decision producer tasks must run again on stage re-entry. Do not mark all of them `Run Only Once: Yes`. A stale terminal value such as `SendBack`, `Rejected`, or `NeedsCorrection` must not remain live at re-entry unless the design intentionally re-evaluates that existing fact.
 
 ## Task content rules
 
 Defines per-task detail blocks. Every task opens with an **Entry Condition** block. Additional blocks depend on task type.
 
+Every task also declares **Design Rationale**: one concrete sentence explaining why the selected task type fits the actor/work and why the selected activation mode fits the timing. For sequential tasks, name the ordering/dependency evidence; for parallel tasks, state that the work is independent. This rationale is persisted into the matching task and task-entry T-entries in `tasks.md`.
+
 ### Entry Condition block (every task)
 
 ```
@@ -470,14 +555,17 @@ Defines per-task detail blocks. Every task opens with an **Entry Condition** blo
 | Rule | When to use |
 |---|---|
 | `current-stage-entered` | Ungated stage-started task that should start when its stage is entered. Do not add this row to event-triggered (`wait-for-connector`), manually triggered (`adhoc`), or sequential (`runs-sequentially`) tasks. When a task intentionally has multiple entry rows and one is stage-started, render this row first. |
-| `selected-tasks-completed("<Task>")` | Explicit sibling gate, fan-in, branch convergence, or conditional handoff where this task should start only after named sibling task(s) complete. Multiple tasks comma-separated inside the parens. Do not use it merely to express the next step in a simple top-to-bottom task list; use `runs-sequentially` for that UI mode. |
+| `selected-tasks-completed("<Task>")` | Explicit sibling gate, fan-in, branch convergence, or conditional handoff where this task should start only after named non-adhoc sibling task(s) complete. Multiple tasks comma-separated inside the parens. Do not use it merely to express the next step in a simple top-to-bottom task list; use `runs-sequentially` for that UI mode. Never select a task whose entry rule is `adhoc`, and never select a task from another stage. |
 | `wait-for-connector` | Async connector callback. Pair with `conditionExpression` to gate on **case state** (`vars.X`); the event payload is not accessible (no `event` namespace). **In-rule extract-then-gate (extract + same-rule `=js:vars.caseVar` gate) does NOT work at runtime** — case-backend evaluates the gate before the extract populates the case var. To condition on payload content: extract `response.field -> caseVar` on the connector rule and place the case-state gate on a DOWNSTREAM stage-entry / task-entry condition. |
+| `sla-status-change("<SLA target>","<SLA Title>")` (breach) / `sla-status-change("<SLA target>","<SLA Title>","<At-Risk Escalation Display Name>")` (at-risk) | The **`start-task` SLA response**: this task fires when the referenced SLA changes status. Reference the containing stage's own SLA for a stage-scoped response, or `"root"` for a case-scoped one. This is the canonical `start-task` shape — the task activates on the SLA event directly, so the stage is not re-entered and its other tasks do not re-run. Never author the equivalent as a stage-entry row. See [sla-response-shapes.md](sla-response-shapes.md). |
 | `adhoc` | Manual fire from the case app. Optional gating expression. Task-entry only; set `Required: No`. It is an activation mode, not a task type. |
 | `runs-sequentially` | Tasks that should run top-to-bottom in their stage declaration order. The frontend toggle writes this as the task's only entry rule; it is not represented by a lane. |
 
 Multiple entry conditions render as multiple rows (DNF outer-OR). When `current-stage-entered` is among them, render it first.
 
-**Sequential normalization rule.** When a contiguous set of tasks in one stage is described as a plain ordered workflow with no branch condition, fan-in, alternate trigger, or manually launched task between them, author **each task in that run** with exactly one `runs-sequentially` Entry Condition row. This includes the first task: do not write `current-stage-entered` for the first item and `selected-tasks-completed("<previous>")` for later items. That explicit chain is valid backend logic, but Studio Web classifies it as condition/event-driven rather than Sequential. Break the run at tasks that are `adhoc`, `wait-for-connector` entry-triggered by an external event, condition-gated, or intentionally dependent on non-immediate sibling task(s).
+**Sequential normalization rule.** When the requirement states order/dependency (`then`, `after`, `before`, `in order`, an upstream output prerequisite) for a contiguous set of tasks in one stage, author **each task in that ordered task-set run** with exactly one `runs-sequentially` Entry Condition row. This includes the first task set: do not write `current-stage-entered` for the first item and `selected-tasks-completed("<previous>")` for later items. A strict chain uses consecutive single-task sets; independent siblings after the same predecessor share the same later task set and also use `runs-sequentially`. A missing data binding does not erase stated ordering. Use parallel `current-stage-entered` tasks only when the work is explicitly independent and starts with the stage; use `selected-tasks-completed` for fan-in/non-immediate dependencies. Break an ordered run at tasks that are `adhoc`, condition-gated, intentionally dependent on non-immediate sibling task(s), or whose **entry rule** is `wait-for-connector`. A task merely **typed** `wait-for-connector` does not break the run: when it must arm only after a predecessor creates the obligation, it stays in the ordered task set with `runs-sequentially` and keeps its connector event in its own `data`.
+
+**Parallel-after-predecessor rule.** When two or more independent tasks start after the same immediate predecessor task or predecessor task set, put them in the same next task set, mark each `Activation Mode: parallel-after-predecessor`, and give each the `runs-sequentially` entry rule. Do not author duplicate event-driven task entries with identical `selected-tasks-completed("<previous>")` rules. Use `selected-tasks-completed` only for true fan-in, branch convergence, condition-result routing, non-immediate dependencies, or explicit authored gates. For race patterns such as payment confirmation vs payment deadline, start the listener and clock while the payment obligation is pending, then gate downstream success work on the confirmation fact rather than on completion of the whole parallel set.
 
 ### `action` task — required cells
 
@@ -584,9 +672,9 @@ These four runnable types share a single render block. The SDD surfaces both por
 
 | Task type | Registry source | Identity field in `registry-resolved.json` |
 |---|---|---|
-| `process` | `process-index.json` | `processOrchestrationId` |
+| `process` | `processOrchestration-index.json` | `processOrchestrationId` |
 | `agent` | `agent-index.json` | `agentId` (+ version) |
-| `rpa` | (registry per RPA convention) | `processOrchestrationId` for RPA processes |
+| `rpa` | `process-index.json` | `processOrchestrationId` for RPA processes |
 | `api-workflow` | `api-index.json` | `apiWorkflowId` (+ endpoint) |
 
 Unresolved registry identity → `high`-severity review item (§Review items). The SDD shows the runnable name + In/Out bindings; the identity flows through the audit trail.
@@ -738,11 +826,11 @@ Pattern X1 is preferred unless an actual connector emits the close event. When t
 8. **Forbidden body vocabulary.** No occurrence in any narrative cell of: `Pattern C`, `bridge`, `companion`, `inputOutputs[]`, `=jsonString:` (outside connector `Operation Configuration` cells), `groupOperator`, `essentialConfiguration` (as prose), `savedFilterTrees`, `dispatcher`, `Phase 2 validator`, `Phase 3 dispatcher`, `Q10 II`, `Finding #N`, `io-binding`, `aliased into / from / back into`, `reassign`, `originalVar`, `auto-mint`. These are skill-internal terms — see [sdd-template.md § Output Rules](../assets/templates/sdd-template.md).
 9. **Resolved-resource I/O completeness** (§Resolved-resource I/O completeness). For each task resolved to a live resource (contract present in `tasks/registry-resolved.json`): every **required** declared input has a non-empty `Binding` row OR `<UNRESOLVED>` + a paired `high` review item; every Outputs `-> caseVar` row's `Field` exists verbatim in the resolved output contract. An upstream-output-fed input (whole-value `<-` or `vars.$xref(...)`) satisfies coverage with NO §1.5 row — do not flag it as a missing variable. Skip tasks whose type-specific identity (`Resource Identity` or `Action App ID`) is `<UNRESOLVED>` (no contract).
 
-Any failure → fix in the model before presenting the confirmation (lineage defects are the agent's, not the user's); a genuinely unfixable item becomes a ⚠ flagged line in the confirmation's `Decisions I made` block.
+Any failure → fix in the model before presenting the confirmation (lineage defects are the agent's, not the user's); a genuinely unfixable item becomes a row in the confirmation's `Review Flags` table.
 
 ## Review items
 
-A review item is a structured gap escalation. Phase 0 emits one whenever a field could not be fully resolved but Phase 1 needs the context. In Phase 0 they live in the in-memory model and surface as ⚠ lines in the confirmation's `Decisions I made` block — never in the `sdd.md` body (per [sdd-template.md § Output Rules](../assets/templates/sdd-template.md)); Phase 1 persists them into `tasks/registry-resolved.json` under the matching task's `review_items[]` array when it writes that file.
+A review item is a structured gap escalation. Phase 0 emits one whenever a field could not be fully resolved but Phase 1 needs the context. In Phase 0 they live in the in-memory model and surface as rows in the confirmation's `Review Flags` table — never in the `sdd.md` body (per [sdd-template.md § Output Rules](../assets/templates/sdd-template.md)); Phase 1 persists them into `tasks/registry-resolved.json` under the matching task's `review_items[]` array when it writes that file.
 
 Shape:
 
@@ -764,7 +852,7 @@ Severity:
 | **medium** | Phase 1 can default with a prompt. | Missing SLA escalation recipient (default = owner group); missing variable default; ambiguous recipient (persona name without group resolution). |
 | **low** | Cosmetic. | Missing case-level description; missing secondary-stage description; stylistic placeholder. |
 
-**Confirmation gate behavior.** When any `high` review items exist, they appear as ⚠ lines in the confirmation's `Decisions I made` block and the Build option is relabeled `Build despite N flagged items` (count populated). User must pick it — silently building past `high` items is forbidden. Medium and low items surface as advisory lines and need no acknowledgment.
+**Confirmation gate behavior.** When any `high` review items exist, they appear in the confirmation's `Review Flags` table and the Build option is relabeled `Build despite N flagged items` (count populated). User must pick it — silently building past `high` items is forbidden. Medium and low items surface in the same table as advisory rows and need no acknowledgment.
 
 ## Domain fidelity
 
@@ -792,12 +880,13 @@ Phase 0's narrative cells (Description, persona names, stage names, task names,
 
 Beyond schema-pairing checks (§Finalization step 1), the case must be a connected graph. **Edges are retired — these condition-based checks are the SOLE reachability guard; there is no edge graph to fall back on.** A malformed or missing entry condition is the only thing that can orphan a stage, so this walk is load-bearing.
 
-1. **Every stage reachable from a trigger.** Walk forward from each trigger row through Stage Entry Conditions (`case-entered` from root, `selected-stage-completed`, `selected-stage-exited`, `wait-for-connector`) — condition-only, no edges. Every primary stage's id must be reached. Unreachable stage → blocking error (orphan stage).
+1. **Every stage reachable from a trigger.** Walk forward from each trigger/SLA source through Stage Entry Conditions (`case-entered` from root, `selected-stage-completed`, `selected-stage-exited`, `wait-for-connector`, `sla-status-change`) — condition-only, no edges. Every primary stage's id must be reached. Unreachable stage → blocking error (orphan stage).
 2. **Every stage exits.** Every primary stage must have either (a) a completion row (`Marks Stage Complete: Yes`) whose completion is consumed by a downstream stage's Entry Condition or a case-exit, OR (b) another primary stage whose Entry Condition references it (`selected-stage-completed`/`selected-stage-exited`), OR (c) feed a secondary stage. A stage no other stage (or case-exit) keys off → blocking error (terminal-loop stage).
 3. **Every case-exit row references a stage that exists.** No dangling `Required Stages` references.
 4. **Every `Required Stages` cell in §1.4 names ≥ 1 primary stage with `Required for case completion: Yes`.** Otherwise the case can never complete.
-5. **Secondary stages must have ≥1 interrupting entry condition, each DISTINCT, chosen by trigger source.** Map the lane's *trigger* to the rule: a gate decision → `selected-stage-completed` / `selected-stage-exited` (+ `IF` on the decision var); a person launches it → `user-selected-stage`; an external event → `wait-for-connector`. `adhoc` is task-entry only — never a stage entry. Every secondary-stage entry row carries `Interrupting: Yes`. Two secondary stages whose entry rules are identical (same rule type + `selectedStageId` + `conditionExpression`) fail `validate` (`CASE_MGMT_SECONDARY_STAGE_ENTRY_RULES_DUPLICATE`) — give each a distinct `selectedStageId` or `conditionExpression` guard. Terminal lanes (Rejected / Withdrawn) exit `exit-only` and declare a §1.4a case-exit (`marks-case-complete: false`); return lanes (Escalation / Customer Comms) exit `return-to-origin`. **Decision-reachable lanes:** when any decision button's Behavior (or the user's stated intent) names a secondary stage as a destination ("route to / send to / escalate via the X lane"), that lane's entry conditions MUST include a `selected-stage-completed` / `selected-stage-exited` rule with an `IF` on the deciding variable's value. A lane described as decision-reachable but entered ONLY via `wait-for-connector` (no decision-keyed entry) is unreachable from its stated source → blocking error. A `wait-for-connector` entry may coexist as a separate trigger, but cannot be the lane's only entry when a decision is supposed to reach it. **A `selected-stage-completed`/`selected-stage-exited` lane entry REQUIRES a matching origin diverting exit — the entry alone is not enough.** On the *origin* stage add a **gated diverting exit** (`Marks Stage Complete: No`, WHEN `selected-tasks-completed("<decider task>")`, `IF =js:(<signal> === <exception-value>)`, `exit-only`, `exitToStageId` → the lane) **and** gate the origin's completion exit with the inverse `IF` (`=js:(<signal> !== <exception-value>)`) so the two are mutually exclusive. Without the diverting exit the decision path either **dual-fires** (ungated completion → the next stage *and* the lane both enter) or **deadlocks** (gated completion with no alternative exit). `selected-stage-exited` fires *after* the origin exits, so this is a **divert-and-return, not a true mid-stage interrupt** — a genuine mid-stage interrupt needs `user-selected-stage` or `wait-for-connector` (mental-model shape (a)). Missing origin diverting exit, or a completion exit not mutually exclusive with it → blocking error.
-6. **Every secondary stage is interrupting.** Set the stage-level `Interrupting` field and every secondary-stage entry row to `Yes`. If the user describes work that can run alongside the main flow without interrupting it, do not mark it secondary; model it as a regular parallel stage/path or as an `adhoc` task in the active stage. A secondary stage with `Interrupting: No` is a blocking classification error.
+5. **Secondary stages must have ≥1 interrupting entry condition, each DISTINCT, chosen by trigger source.** Map the lane's *trigger* to the rule: a gate decision → `selected-stage-completed` / `selected-stage-exited` (+ `IF` on the decision var); a person launches it → `user-selected-stage` paired with an upstream `wait-for-user` exit; an external event → `wait-for-connector`; an SLA response that enters this lane → `sla-status-change` referencing the SLA (plus an at-risk escalation only for an at-risk response; a breach references the SLA alone). Warning-only SLA escalation stays a notification. `adhoc` is task-entry only — never a stage entry. Every secondary-stage entry row carries `Interrupting: Yes`. Two secondary stages whose entry rules are identical (same rule type + selector fields + `conditionExpression`) fail `validate` (`CASE_MGMT_SECONDARY_STAGE_ENTRY_RULES_DUPLICATE`) — give each a distinct event/SLA selector or expression guard. Terminal lanes (Rejected / Withdrawn) exit `exit-only` and declare a §1.4a case-exit (`marks-case-complete: false`); return lanes (Escalation / Customer Comms) exit `return-to-origin`. **Global events:** one `wait-for-connector` or `sla-status-change` entry on the destination secondary stage covers every active origin; do not repeat a task or exit rule across primary stages. **Decision-reachable lanes:** when any decision button's Behavior (or the user's stated intent) names a secondary stage as a destination ("route to / send to / escalate via the X lane"), that lane's entry conditions MUST include a `selected-stage-completed` / `selected-stage-exited` rule with an `IF` on the deciding variable's value. A lane described as decision-reachable but entered ONLY via `wait-for-connector` (no decision-keyed entry) is unreachable from its stated source → blocking error. A `wait-for-connector` entry may coexist as a separate trigger, but cannot be the lane's only entry when a decision is supposed to reach it. **Only a `selected-stage-completed`/`selected-stage-exited` lane entry requires a matching origin diverting exit.** On the *origin* stage add a **gated diverting exit** (`Marks Stage Complete: No`, WHEN `selected-tasks-completed("<decider task>")`, `IF =js:(<signal> === <exception-value>)`, `exit-only`, `exitToStageId` → the lane) **and** gate the origin's completion exit with the inverse `IF` (`=js:(<signal> !== <exception-value>)`) so the two are mutually exclusive. Without the diverting exit the decision path either **dual-fires** (ungated completion → the next stage *and* the lane both enter) or **deadlocks** (gated completion with no alternative exit). `selected-stage-exited` fires *after* the origin exits, so this is a **divert-and-return, not a true mid-stage interrupt** — a genuine mid-stage interrupt needs `user-selected-stage`, `wait-for-connector`, or `sla-status-change` (mental-model shapes (a)/(c)). Missing origin diverting exit, or a completion exit not mutually exclusive with it → blocking error.
+6. **Every `sla-status-change` entry resolves.** For each row: the target is `root` or an existing stage, that target has an SLA configured (§1.1 + §1.2, or its `#### Stage SLA` block), and every title the row actually supplies matches a row declared on **that** target. A two-arg breach row supplies only the SLA title and is complete as written — its missing escalation is not a miss. Any real miss — SLA absent, title left `—`/defaulted, typo, or an at-risk escalation borrowed from another target — cannot resolve to `slaId` (or, for at-risk, `escalationId`), leaves the lane unreachable, and is a **blocking error**. A notification-only escalation needs no entry rule.
+7. **Every secondary stage is interrupting, except a non-diverting SLA oversight row.** Set the stage-level `Interrupting` field and every secondary-stage entry row to `Yes`. If the user describes work that can run alongside the main flow without interrupting it, do not mark it secondary; model it as a regular parallel stage/path or as an `adhoc` task in the active stage. A secondary stage with `Interrupting: No` is a blocking classification error **unless** that row is an `sla-status-change` response the source describes as parallel oversight (the breached work continues; nothing is paused, taken over, or rerouted) — then `No` is correct on that row and the lane still stays `isRequired: No` and out of the completion set. Do not promote such a lane to a regular stage: that would make it required for case completion. Every non-SLA secondary entry row stays `Yes`.
 
 **Worked example — decision/signal-routed return exception (AP Review → SLA Escalation).** The origin "AP Review" routes to the exception lane "SLA Escalation" on a `requiresEscalation` decision, then returns:
 
@@ -837,7 +926,9 @@ Phase 0's job is to surface execution-readiness gaps, not just schema validity.
 When Phase 0 defaults or infers a value, record provenance so Phase 1 and downstream auditors can trace it. The ledger has two surfaces:
 
 1. **Inline in `sdd.md`** — italic source attribution after the value: `Manual _(source: user-stated)_`. Omit attribution when the kind is `user-stated`.
-2. **Confirmation `Decisions I made` block** — see [phase-0-interview.md § Confirm](phase-0-interview.md#confirm--the-single-checkpoint).
+2. **Confirmation `Decisions I Made` table** — see [phase-0-interview.md § Confirm](phase-0-interview.md#confirm--the-single-checkpoint).
+
+**Design rationale is durable, not chat-only.** Provenance says *where a value came from*; rationale says *why the design choice fits*. Persist the latter in each stage/task `Design Rationale` field and in each case/stage SLA rationale field. The confirmation may summarize those reasons, but it is not their sole storage. Phase 1 copies the rationale to each matching `tasks.md` T-entry so an implementer can review the choice without the original conversation.
 
 Provenance kinds:
 
@@ -862,6 +953,8 @@ Phase 0 runs these checks **once, against the in-memory case model, before prese
    - Case-exit `Yes` + `selected-stage-*` → error
    - Stage-exit `Yes` + `selected-tasks-completed` → error
 2. **Render-contract check.** Every required cell in §Case content rules, §Stage content rules, §Task content rules has a concrete value (no banned `—` / `<UNRESOLVED>`).
+2a. **Template-shape check.** The exact rendered `sdd.md` text must pass [phase-0-interview.md § Template conformance gate](phase-0-interview.md#template-conformance-gate--before-sddmd-is-written): `# SDD — {Case Name}`, `## Table of Contents`, `## Section 1: Case Definition`, `## Section 2: Stages & Tasks`, `## Section 3: Personas & App Views`, `## Section 4: Integrations`, required Section 1 subsections, one complete stage block per stage, one complete task block per task, personas/app views, and integrations. Each task block must contain the exact marker `**Task envelope**` before the Required / Run Only Once / Skip Condition table; `**Task envelope:**` with a colon is a render failure. Secondary-stage task headings must use numeric `Task S{K}.{M}` form, never lettered prefixes such as `Task R.1`, `Task W.1`, `Task CC.1`, or `Task ESC.1`. Missing headings, missing full detail blocks, or top-level summary replacements (`## Source`, `## Case Objective`, `## Stages`, `## Task Plan`, etc.) are blocking render failures. This check runs before Write; if it fails after Write is observed, stop and repair before Phase 1.
+2b. **Safe display-name check.** Every generated or carried Case Designer display/title field for stages, tasks, rule names, SLA rules, and escalation rules uses only letters, numbers, spaces, hyphen, and underscore. Repair unsafe punctuation mechanically and disclose changed names in the Case Review. Do not normalize external resource lookup names.
 3. **Decision-task button check.** Every `action` task with `is_decision: Yes` has ≥ 2 buttons; every button's `Maps To` LHS references a declared §1.5 variable (by `Name`) or `taskOutcome`.
 4. **Recipient encoding check.** Every `action` task recipient uses one of the five typed prefixes (`Email:` / `User:` / `UserGroup:` / `Role:` / `Expression:`) — no bare strings.
 5. **Connector-id check.** Every `wait-for-connector` / `execute-connector-activity` **task** has concrete `Connection ID` AND `Activity Type ID`. Every `wait-for-connector` **condition rule** (in any scope — stage-entry / stage-exit / case-exit / task-entry) has a `Connector Rule Detail` block resolving to a concrete `Connector Key` AND `Event Operation` (and `Connection ID` when not a tenant-default). Missing identity → paired `high`-severity review item.
@@ -870,6 +963,8 @@ Phase 0 runs these checks **once, against the in-memory case model, before prese
 8. **Alt-disposition coverage.** If ≥ 1 secondary stage exists, Section 1.4a is non-empty OR a `high`-severity review item is open.
 9. **Review-items high-severity acknowledgment.** Approve adds the explicit follow-up when `high` items exist.
 10. **Source-ledger check.** Every non-`user-stated` and non-`verbatim` field has provenance.
+10a. **Design-rationale check.** Every stage explains its kind and routing choice; every task explains its type and activation/sequencing choice; every configured case/stage SLA explains its thresholds, recipients, and any notify-only or graph-changing response. Missing rationale is a blocking render-contract error because Phase 1 must preserve it.
+10b. **SLA Response Map closure** (§1.2b). If any SLA is configured, the map exists with one row per `(Scope, SLA, Status)` and every `Response` drawn from the closed set. Every non-`notify-only` row has its matching `sla-status-change` entry / stage-exit / case-exit rule in the model, every `sla-status-change` entry has a map row, and each pair's `Interrupting` values agree. A `notify-only` row that minted a stage or task, or a bare SLA with no map row, is a blocking error.
 11. **File-In-arg caller-obligation surfacing.** When ≥ 1 §1.5 row has `Category: In` AND `Type: file`, the Approve summary MUST include a `Caller obligation` block:
 
     ```
@@ -883,7 +978,8 @@ Phase 0 runs these checks **once, against the in-memory case model, before prese
 
     This is informational, not blocking. But missing it suppresses a known integration gotcha.
 
-12. **Stage-graph connectivity check.** Run the §Logical integrity stage-graph checks (every stage reachable, every stage exits, every Required Stages cell points to existing primary stages, every secondary stage has ≥ 1 entry condition, and every secondary stage / secondary-stage entry row has `Interrupting: Yes`). Any failure → blocking error.
+12. **Stage-graph connectivity check.** Run the §Logical integrity stage-graph checks (every stage reachable, every stage exits, every Required Stages cell points to existing primary stages, every secondary stage has ≥ 1 entry condition, every `sla-status-change` entry names an SLA rule declared on the target it points at — plus an at-risk escalation on that same target only when the row is at-risk — and every secondary stage / secondary-stage entry row has `Interrupting: Yes`). Any failure → blocking error.
+12a. **Entry-producer/reference check.** Every non-start stage/task entry names a concrete producer/reference: `selected-stage-*` names an existing upstream stage whose exit/completion can occur; `user-selected-stage` has a matching upstream `wait-for-user` exit; `wait-for-connector` has connector rule detail; `sla-status-change` names SLA target scope, SLA display name, and status — plus an at-risk escalation display name **when and only when the status is at-risk** (a breach rule references the SLA alone; a missing escalation on a breach row is correct, not a gap). A rule without a producer/reference is a blocking error.
 13. **Domain-fidelity scan.** Run a single pass over every narrative cell (Description, persona name, stage name, task name, button label, app-view purpose). For each customer-named entity surfaced in §Source ledger as `verbatim:"..."`, confirm the rendered cell still uses the verbatim phrase (no synonym drift). Mismatch → list and offer `Re-edit` with the verbatim phrase pre-filled.
 14. **Architect's-lens advisory pass.** Run the §Architect's lens checks. Emit `medium` review items for each trigger (the `high` variants — `rev_substitute_app`, and `rev_no_failure_path` at the ≥ 2-connector threshold — emit `high` and gate via the opt-in). `medium` is non-blocking; Approve summary surfaces the count.
 15. **Decision-routing closure.** For every `action` task with `is_decision: Yes`, each button's `Maps To` variable+value MUST be consumed by ≥ 1 downstream rule (stage-entry `IF`, task-entry `IF`, stage-exit, or case-exit) OR the button's Behavior MUST declare it terminal (no routing claim). When a button's Behavior names a destination stage / lane ("route to / send to / via the X lane") and no entry condition keys off that variable+value, the branch is dead → **blocking error**. Pair with §Logical integrity step 5 (lane reachability). A fully-orphaned decision variable (produced by a button, read by nothing) on an `is_decision: Yes` task is blocking; the `medium` `rev_orphan_decision` variant in §Architect's lens applies only when the variable IS read but not for branching.
@@ -891,8 +987,9 @@ Phase 0 runs these checks **once, against the in-memory case model, before prese
 17. **Required-task presence.** Every primary stage whose completion exit uses `required-tasks-completed` MUST contain ≥ 1 task with `Required: Yes`. A `required-tasks-completed` exit over a stage where no task is required is vacuous — the runtime resolves it without gating on real work (and the CLI flags it as `CASE_MGMT_..._NO_REQUIRED_TASK` at `validate`). Catch it at the Approve gate: zero `Required: Yes` tasks in such a stage → blocking error (offer `Re-edit` to mark the stage's terminal/primary task required). Tasks default to `Required: Yes` unless the SDD says otherwise, so this fires only when the author explicitly cleared every task's Required flag.
 18. **Resolved-resource presence (standalone replicability).** Every process/agent/rpa/api-workflow task has a concrete `Resolved Resource`; every action has a concrete Action App title in `HITL Implementation`; every case-management task has a concrete `Child Case`. These portable names are never `<UNRESOLVED>`. Each task also has its required type-specific identity + folder pair (`Resource Identity` + `Folder Path`, or `Action App ID` + `Deployment Folder`): a concrete identity requires the exact concrete folder; an unresolved identity permits an unresolved folder and requires a paired `high` review item. Every connector task has `Connection ID` + `Activity Type ID`. Missing portable intent, or unresolved identity with no review item, is a blocking error.
 19. **Resolved-resource I/O completeness** (§Resolved-resource I/O completeness; audit-checklist item 9). For every task resolved to a live resource (contract in `tasks/registry-resolved.json`): every **required** declared input is bound (any §Binding cell form, incl. an upstream-output ref — which needs NO §1.5 row) OR `<UNRESOLVED>` + a paired `high` review item (`rev_unbound_input_<task>_<field>`); every Outputs `-> caseVar` row's `Field` exists verbatim in the resolved output contract (a phantom field → `high` `rev_phantom_output_<task>_<field>`). Unbound required input with no review item → blocking error. Step 16 is the `action`-app instance of the output-fidelity direction; this step extends both directions to all runnable/connector types. Tasks whose type-specific identity (`Resource Identity` or `Action App ID`) is `<UNRESOLVED>` (no contract) are skipped.
+20. **Re-entry attempt check.** For each `return-to-origin`, rework, correction, or resubmission loop, classify the loop as new attempt, re-evaluate existing fact, or optional repeat work. New-attempt loops must leave request/review/decision producer tasks rerunnable (`Run Only Once: No`) and reset or attempt-scope the routing variables they produce. Re-evaluate-only loops must document which existing fact the origin re-reads.
 
-On pass: present the §Confirm checkpoint (whole-case tables + complete `Decisions I made` block + Caller obligation block when applicable + ⚠ flags). A Build answer is the consent — `sdd.md` renders from the confirmed model batched with the first build actions ([phase-0-interview.md § Build start](phase-0-interview.md#build-start--sdd-written-alongside-the-build)); an explicit sign-off request adds one approval prompt before any file is created; design-only/draft requests save and stop. Corrections update the model and re-run only the affected checks.
+On pass: present the §Confirm checkpoint (decision-first Case Review with Case Snapshot, Primary Journey, Other Paths Considered, SLA and Escalations, Rules and Outcomes, Resources and Integrations, a complete `Decisions I Made` table, Review Flags, and Caller obligation when applicable). The review names every stage and task but omits data, variables, and task inputs/outputs. A Build answer is the consent — `sdd.md` renders from the confirmed model batched with the first build actions ([phase-0-interview.md § Build start](phase-0-interview.md#build-start--sdd-written-alongside-the-build)); an explicit sign-off request adds one approval prompt before any file is created; design-only/draft requests save and stop. Corrections update the model and re-run only the affected checks.
 
 On fail: fix the model and re-run the failed checks (plus any whose inputs changed) — not the full suite. Do not present the confirmation, and never render `sdd.md`, while a fixable check is failing; surface only the unfixable as ⚠ flags.
 
@@ -900,9 +997,14 @@ On fail: fix the model and re-run the failed checks (plus any whose inputs chang
 
 - **Do NOT silently accept a user-proposed type when a compliance trigger phrase is in the transcript.** Tier 2 of the authority hierarchy overrides user preference; Ask before recording.
 - **Do NOT create `sdd.md` before the confirmation's Build (or save) answer.** Finalization validates the in-memory model before the confirmation; the file renders only after consent — batched with the first build actions, or alone for design-only/draft requests. Never render with a failing fixable check or an undisclosed decision, and never build past a `high` item without the `Build despite N flagged items` pick.
+- **Do NOT leave design rationale only in chat.** The confirmation's `Decisions I Made` table is transient; stage kind/routing, task type/activation/sequencing, and SLA/escalation reasons must also live in the SDD's `Design Rationale` fields so Phase 1 can preserve them.
+- **Do NOT treat a validating case as proof the SDD followed the template.** `caseplan.json` validation checks executable JSON, not whether `sdd.md` preserved the template. A summary-style `sdd.md` with top-level `Source`, `Case Objective`, `Task Plan`, or `Acceptance Scenarios` sections is a render defect even when the built case validates.
+- **Do NOT repeat a global event on every primary stage.** External withdrawn/cancel events belong on one interrupting secondary-stage entry rule. An SLA response that enters a stage belongs on one scoped `sla-status-change` entry, with interrupting set by whether it diverts active work. Per-stage task/exit duplication is a modeling defect.
+- **Do NOT invent a stage, task, or routing change for an SLA the source only asks to notify about.** Absent a stated response, at-risk and breached are `notify-only` (§ SLA response model).
 - **Do NOT ship `sdd.md` with a banned `—` or `<UNRESOLVED>` on a render-required field.** Emit a placeholder + review item, or Ask.
 - **Do NOT pair `Marks Stage Complete: Yes` with `selected-tasks-completed` or `Marks Case Complete: Yes` with `selected-stage-*`.** Both are schema-pairing errors (Key Rule 4).
 - **Do NOT emit an `action` task without typed recipient prefix.** Bare strings (`"the underwriter"`) force Phase 1 to guess.
+- **Do NOT let required flow depend on `adhoc` tasks.** `selected-tasks-completed` and required-task rules must select only non-adhoc tasks in the same stage.
 - **Do NOT emit a decision `action` task with fewer than 2 buttons.** `is_decision: Yes` requires ≥ 2 buttons; downgrade to `is_decision: No` if the task does not fork the case path.
 - **Do NOT emit a `wait-for-timer` task with `<UNRESOLVED>` duration.** Timer cannot fire — block Approve.
 - **Do NOT emit SLA cells on `process` / `agent` / `rpa` / `api-workflow` / timer / connector / `case-management` tasks.** SLA supports case, stage, and `action` tasks ONLY (sdd-template Key Rule 1).
@@ -917,6 +1019,8 @@ On fail: fix the model and re-run the failed checks (plus any whose inputs chang
 - **Do NOT omit provenance on inferred values.** Silent inference reaches Phase 1 under Rule 2 trust — provenance is the audit trail.
 - **Do NOT alias a task output into an unrelated existing variable to satisfy lineage.** If a task produces a new datum, declare a §1.5 variable for it. Aliasing (`complianceStatus -> titleReviewStatus` with no `complianceStatus` row) closes lineage mechanically but corrupts meaning — see §Variable lineage closure output-naming rule.
 - **Do NOT emit a decision `action` button whose Behavior names a destination lane the case graph cannot reach.** Every routing button's variable+value must be keyed by a downstream entry / exit condition (§Finalization step 15, §Logical integrity step 5). A button that "routes to the X lane" while X is entered only by an external connector event is a dead branch.
+- **Do NOT use `user-selected-stage` without an upstream `wait-for-user` exit.** Deterministic rejection, approval, send-back, cancellation, and SLA routing use decision facts and guarded exits/entries instead.
+- **Do NOT mark correction/resubmission review or decision tasks `Run Only Once: Yes`.** New attempts need fresh producer tasks and neutral or attempt-scoped decision state.
 - **Do NOT author an `action` Input Schema field the resolved app does not expose.** Fields outside the app's `tasks describe` schema cannot bind (§Finalization step 16). Reusing one app across many tasks is correct **when it is code-switched** (distinct `actionType` per task, fields ⊆ the app schema — the normalized-action-app pattern a full case relies on); it is the substitute anti-pattern (`rev_substitute_app`) only without a distinct `actionType` or with non-bindable fields.
 - **Do NOT leave a resolved resource's required input unbound, and do NOT bind an output the resource never emits.** Once a task resolves to a live resource, every required declared input needs a `Binding` row (or `<UNRESOLVED>` + `high` review item) and every `-> caseVar` extract `Field` must exist in the resolved contract (§Resolved-resource I/O completeness, §Finalization step 19). A silently-missing required input faults the job at runtime.
 - **Do NOT declare a §1.5 Case Variable for an input that is just an upstream task's output.** Reference it directly — whole-value `<- "Stage"."Task".out` or in-expression `vars.$xref('Stage','Task','out')`. The emitting task is its own producer; a §1.5 row is only for renaming, custom `Default` / `Type`, or case-level state (§Variable lineage closure → Task-output direct reference).