@uipath/skills 1.201.0-preview.591 → 1.201.0-preview.602

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uipath/skills",
-  "version": "1.201.0-preview.591",
+  "version": "1.201.0-preview.602",
   "description": "UiPath agent skills for Claude Code, Codex, Cursor, Copilot, Gemini and OpenCode — RPA, UI automation, UI testing, coded agents/apps/workflows, and troubleshooting. Distributed as the UiPath Claude Code plugin.",
   "author": {
     "name": "UiPath"

package/skills/uipath-maestro-case/references/evals/evals.json

@@ -92,7 +92,7 @@
         "The confirmation includes a complete Decisions I Made table with a plain-language provenance per assumption",
         "A manually triggered task is presented as optional adhoc worker-launched work without exposing schema mechanics",
         "The confirmation carries the build continuation choice (build straight through vs pause at the build preview) so it is never asked mid-build",
-        "On a Build answer the lane writes sdd.md (write-early cadence), then the build starts (solution init + planning); the design doc is mentioned in one line as a reference artifact — never presented for review, and never written before the Build answer"
+        "On a Build answer the lane writes sdd.md, then the build starts (solution init + planning); the design doc is mentioned in one line as a reference artifact — never presented for review, and never written before the Build answer"
       ]
     },
     {

package/skills/uipath-planner/SKILL.md

@@ -16,7 +16,7 @@ Never execute the work. Outputs are SDD markdown, plan/tasks markdown, and live
 
 The skill has three paths, decided by the **Entry Guard**:
 
-- **Phase D — Design.** Input is a PDD, or an explicit "design / architect this" request. Author the SDD; the SDD write ends the turn, and Lane A continues on the next turn. See [sdd-generation-guide.md](references/sdd-generation-guide.md). **Case Management designs run through Phase D's Case Design Lane** ([case-design-lane-guide.md](references/case-design-lane-guide.md)): a conversational design that ends in one Case Review confirmation. The lane defines its own entry modes — direct design, build handoff from `uipath-maestro-case`, and draft finalization.
+- **Phase D — Design.** Input is a PDD, or an explicit "design / architect this" request. Author the SDD; the SDD write ends the turn, and Lane A continues on the next turn. See [sdd-generation-guide.md](references/sdd-generation-guide.md). **Case Management designs run through Phase D's Case Design Lane** ([case-design-lane-guide.md](references/case-design-lane-guide.md)) — a conversational design ending in ONE Case Review confirmation.
 - **Lane A — PDD-driven.** Input is an SDD with the `## Planner Handoff` marker (written by Phase D, or hand-written). Read it, derive tasks, emit live tasks. Zero to two user prompts. See [pdd-driven-lane-guide.md](references/pdd-driven-lane-guide.md).
 - **Lane B — Non-PDD.** No SDD; a non-PDD multi-project request. Elicit preferences, detect project type, write a plan, emit live tasks. 0–3 prompts (5-call cap). See [non-pdd-lane-guide.md](references/non-pdd-lane-guide.md).
 
@@ -25,8 +25,6 @@ The skill has three paths, decided by the **Entry Guard**:
 - User provides a **PDD or any process-knowledge source** — a PDD, Confluence page, BPMN model, meeting/Zoom transcript, SOP, or requirements doc (as PDF / Word / Markdown / `.txt` / `.bpmn` / pasted) — and asks to design or build from it → Phase D
 - User asks to **design / architect / generate an SDD** for a UiPath automation → Phase D
 - User provides an **SDD path** → Lane A
-- User asks to **design / generate a Case Management SDD** conversationally (no PDD), asks for a reviewable case design draft, or asks to **finalize a case `sdd.draft.md`** → Phase D — Design (Case Design Lane)
-- **`uipath-maestro-case` handed a case build request off to this skill** (no `sdd.md` exists yet; same conversation) → Phase D — Design (Case Design Lane, Build handoff: design with the user, Build-option confirmation, write `sdd.md` at the working root, the build continues immediately)
 - The request is **non-trivial** — spans **separate buildable projects** that each need their own specialist (a Flow orchestrating standalone RPA processes or agents that must themselves be built) → Lane B
 - The request is **ambiguous** — no single specialist clearly matches, or "what can I build?"
 
@@ -46,7 +44,7 @@ The skill has three paths, decided by the **Entry Guard**:
 10. **Fill gaps with `[DEFAULT]` or `[SME REVIEW]` — never silently invent business rules.** `[DEFAULT]` for industry-standard patterns (retry counts, timeouts); `[SME REVIEW]` for business-knowledge gaps. Resolve `[SME REVIEW]` items with the user before writing. For Agent/Coded App gaps, use `AskUserQuestion` (proceed-with-gap-filling vs different product) — never auto-fallback.
 11. **The terminal artefact of a Solution build is a packed `.uipx`.** The SDD's `## Next Steps` section points the user at the `uipath-solution` skill (`uip solution init` → `project add` per project → `resources refresh` → `pack`). A bare project folder is not the deliverable. Exception: when the Constraint Gate blocks Solutions for the delivery model — standalone, Automation Suite older than 2.2510, or a user exclusion — rewrite Next Steps to per-package Orchestrator publish routed via `uipath-platform`.
 12. **Never copy SDD architecture into the plan, and never invent selectors or UI targets.** The plan references SDD section paths in skill prompts; it does not duplicate architecture content. Selectors require application inspection at development time — leave them for the specialist.
-13. **This skill is the sole author of Case Management SDDs — it always writes the SDD file.** Every case design path (conversational, build handoff from `uipath-maestro-case`, draft finalization, PDD-driven) runs through the Case Design Lane ([case-design-lane-guide.md](references/case-design-lane-guide.md)) — flow, write-early cadence, and the never-overwrite guard on `sdd.md` — with the content contract in [references/case/](references/case/) (design-time tenant resolution + its ONE batched gate: [case/grounding.md](references/case/grounding.md)). Design time never runs schema discovery, scaffolds projects, or executes create-on-missing — those are build-skill concerns recorded as gate decisions.
+13. **Sole author of Case Management SDDs.** Every case design path — conversational, build handoff from `uipath-maestro-case`, draft finalization, PDD-driven — runs the Case Design Lane ([case-design-lane-guide.md](references/case-design-lane-guide.md)), which owns the conversation, the one confirmation, and the write; the case model and its defaults live in [case-design-layers-guide.md](references/case-design-layers-guide.md) and the render contract in the case SDD template. Design time resolves identities only — never schema discovery, project scaffolding, or create-on-missing; those are build concerns, recorded as gate decisions.
 
 ## Entry Guard
 
@@ -147,7 +145,7 @@ High-level view of what each specialist owns. **Do not describe internal flows o
 | `uipath-functions` | Coded Functions — TypeScript (default), JavaScript, or Python (`uip function new -l ts / js / py`; typed I/O — Pydantic for Python) — atomic deterministic logic: transforms, custom-auth API calls, ERP/IS-connection queries. Runs serverless or on an RPA robot. Invoked from Maestro (Flow/BPMN), agents-as-tools, Orchestrator API. No LLM/agent loop (that → `uipath-agents`) | Yes (`uip login`) | **Yes** — `uip function pack/publish` |
 | `uipath-maestro-flow` | `.flow` files orchestrating RPA, agents, apps | Yes (`uip login`) | **Partial** — Orchestrator deploy of `.uipx`-wrapped solutions → `uipath-solution`; non-solution single package → `uipath-platform` |
 | `uipath-maestro-bpmn` | `.bpmn` files — standards-based BPMN 2.0 process orchestration (gateways, events, boundary timeouts, subprocesses, multi-instance) over RPA, agents, APIs, HITL. Authors its own inline userTask/HITL nodes. | Yes (`uip login`) | **Yes** — packages, uploads, publishes/deploys, and runs via `uip maestro bpmn`; Orchestrator deploy of `.uipx`-wrapped solutions → `uipath-solution` |
-| `uipath-maestro-case` | Case Management authoring (`caseplan.json` + generated BPMN) from an SDD | Yes (`uip login`) | **No** — deploys via `uipath-solution` (`.uipx`) |
+| `uipath-maestro-case` | Case Management authoring — `caseplan.json` from an SDD (`case pack` compiles it to `caseplan.json.bpmn`; authoring `.bpmn` directly is `uipath-maestro-bpmn`) | Yes (`uip login`) | **Partial** — publishes to Studio Web and Orchestrator itself; `.uipx` solution deploy → `uipath-solution` |
 | `uipath-api-workflow` | API Workflows (JSON `document.dsl`): author, run locally (`uip api-workflow run`), connector activities | Yes (`uip login`) | **No** — `uip solution pack/publish` via `uipath-solution` |
 | `uipath-human-in-the-loop` | HITL node authoring — approval gates, escalations, write-back validation inside **Flow** projects. Coded-agent HITL → `uipath-agents`; BPMN / Case / RPA own theirs inline (userTask / task type / Action Center) | No (authoring only) | **No** — ships inside the host project |
 | `uipath-platform` | Auth (`uip login`), Orchestrator (folders, processes, jobs, machines, users, roles), resources (assets, queues, storage buckets + bucket files, libraries, webhooks, triggers), Integration Service (connectors, connections, activities, IS triggers), Data Fabric entities/records/files/choice-sets (`uip df`), traces, licensing | Yes (auth hub) | **Yes** — for non-solution single packages and Orchestrator-side post-deploy ops |
@@ -163,8 +161,8 @@ High-level view of what each specialist owns. **Do not describe internal flows o
 | File | Purpose |
 |------|---------|
 | [SDD Generation Guide](references/sdd-generation-guide.md) | Phase orchestrator — Phase 1, 2, 3 step-by-step instructions |
-| [Case Design Lane Guide](references/case-design-lane-guide.md) | Conversational case authoring — entry modes (Build handoff / direct / draft finalization), Listen/Sketch/Case Review single confirmation, full design-time tenant resolution + the resolution gate, template conformance gate, terminal-step fork |
-| [Case References](references/case/) | Case SDD content contract, one file per concern: [model](references/case/model.md) (node/task types, lifecycle gates, secondary stages, sequencing, naming) · [variables](references/case/variables.md) (data flow, expressions) · [slas](references/case/slas.md) · [principles](references/case/principles.md) (authority, provenance, review items) · [authoring](references/case/authoring.md) (process → model method, task typing) · [render-case-definition](references/case/render-case-definition.md) + [render-stages-tasks](references/case/render-stages-tasks.md) (SDD §1/§2 cell contracts) · [grounding](references/case/grounding.md) (tenant resolution) · [review](references/case/review.md) (Case Review + finalization gate) |
+| [Case Design Lane Guide](references/case-design-lane-guide.md) | The case design conversation — entry, tenant grounding, authoring policy, the one Case Review, and the write |
+| [Case Design Layers Guide](references/case-design-layers-guide.md) | The case model and every design **Default** — skeleton (triggers, stages, the nine task types), gates (lifecycle rules, exits, sequencing, secondary lanes), data (variables, outputs, expressions), time (SLAs, escalations, responses), naming rules, and the closure checklist |
 | [PDD Analysis Guide](references/pdd-analysis-guide.md) | How to extract structured data from PDDs in any format |
 | [Product Selection Guide](references/product-selection-guide.md) | **Constraint Gate** (delivery model + exclusions filter), **Level 1** (primary scope), **Level 1.75** (Solution composition), **Level 2.5 Part B** (cross-product project list merge), **Level 3** (capability add-ons), template mapping |
 | [Platform Availability Guide](references/platform-availability-guide.md) | Product × delivery-model availability matrix (Cloud / Automation Suite / standalone), alternatives for blocked products, verification rule for uncertain cells. Load whenever the Constraint Gate runs — every delivery model: "Cloud is not uniform", variants (GovCloud / Dedicated / Test Cloud) and per-tenant entitlements can block products inside the Cloud column. |
@@ -182,7 +180,6 @@ High-level view of what each specialist owns. **Do not describe internal flows o
 | [Flow Template](assets/templates/flow-sdd-template.md) | SDD template for Maestro Flow |
 | [BPMN Template](assets/templates/bpmn-sdd-template.md) | SDD template for Maestro BPMN |
 | [Case Management Template](assets/templates/case-sdd-template.md) | SDD template for Case Management (downstream Case Definition Blueprint shape) |
-| [Case SDD Worked Examples](assets/templates/case-sdd-examples.md) | Worked case-authoring patterns by use case (variables, outputs operators, file In-args, multi-trigger) |
 | [Agent Template](assets/templates/agent-sdd-template.md) | SDD template for UiPath Agents |
 | [Coded App Template](assets/templates/coded-app-sdd-template.md) | SDD template for Coded Apps (web) |
 | [API Workflow Template](assets/templates/api-workflow-sdd-template.md) | SDD template for API Workflows |

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

@@ -96,6 +96,12 @@ Skip entirely when no review items are open. Blocking = yes keeps Planner Handof
 
 ### Case Metadata
 
+<!-- Required cells never render `—`: Case Name (PascalCase — missing → block, Ask), Identifier prefix
+(missing → derive mechanically from the name + provenance). Case SLA `—` when none — then OMIT the SLA
+Title row entirely. SLA Type: platform persists condition-based whenever ≥1 SLA rule carries a non-empty
+expression; condition-based requires the Variable SLA Rules table. Defaults recorded with provenance:
+Case App Disabled, Task-output passing Direct, SLA Type time-based, SLA Title `SLA Rule 1`. -->
+
 | Property | Value |
 |----------|-------|
 | Case Name | <PascalCase name> |
@@ -115,8 +121,27 @@ Skip entirely when no review items are open. Blocking = yes keeps Planner Handof
 
 | SLA Status | Threshold | Action | Display Name |
 |------------|-----------|--------|--------------|
-| At-Risk | <percentage>% of SLA duration | Notify: <recipient or group> | <non-empty root-unique escalation title, no `:`> |
-| Breached | 100% of SLA duration | Notify: <recipient or group> | <non-empty root-unique escalation title, no `:`> |
+| At-Risk | <percentage>% of SLA duration | Notify: <owner persona's group — never `—`> | <root-unique title, no `:`; `Escalation Rule {N}` only if no sla-status-change row references it> |
+| Breached | 100% of SLA duration | Notify: <one tier up: leadership, or Compliance when regulation-driven — never `—`> | <root-unique title, no `:`; same defaulting rule> |
+
+<!-- Whole section required when Case SLA is set; omit it entirely when there is none. A recipient
+filled from the default tiers rather than the source carries provenance `default applied`. -->
+
+### SLA Response Map
+
+**THE single authored source of SLA responses.** Every per-stage SLA block carries only its title and
+duration and points here; nothing restates a response.
+
+| Scope | SLA | Status | Response | Target | Interrupting | Rationale |
+|-------|-----|--------|----------|--------|--------------|-----------|
+| <case \| stage: <StageName> \| task: <TaskName>> | <that target's SLA Title> | <At-Risk \| Breached> | <notify-only \| start-task \| enter-stage \| exit-stage \| exit-case> | <— for notify-only; else the task name / stage name / produced exit row> | <— for notify-only and for every start-task; else Yes \| No matching the produced stage-entry row> | <why this response fits the source> |
+
+<!-- Section required whenever ANY SLA exists (case, stage, or action task); omit only in a case with no
+SLA at all. One row per (Scope, SLA, Status), at-risk and breached separately. Source states no response
+-> both statuses notify-only with Target and Interrupting `—`; never invent a stage, task, or routing
+change to carry a notification. Legal Response values and the Interrupting value each implies:
+case-design-layers-guide.md § Choosing the response. Two-way closure against the SDD's
+`sla-status-change` rows is enforced by audit_sdd.py — it is not re-checked by hand. -->
 
 ### Variable SLA Rules
 
@@ -129,16 +154,31 @@ Skip entirely when no review items are open. Blocking = yes keeps Planner Handof
 ### Case Triggers
 
 <!-- Trigger mapping into variables is declared in Case Variables with sourceTriggers/sourceFields, not here. T01 is reserved for the case file; number runtime triggers from T02.
-`Manual` is author shorthand — a manual trigger has no serviceType in the generated JSON (the on-disk serviceType enum is `None` / `Intsvc.EventTrigger` / `timer`; the SDD's `Intsvc.TimerTrigger` maps to on-disk `timer`; never write `serviceType: "Manual"`).
-Tenant object starts are still event triggers: a case that starts when a tenant case-entity / data-object record is created authors `Intsvc.EventTrigger` with that object name as Source — never downgrade to `Manual` because the object is not provisioned; unresolved event triggers survive as placeholders. -->
+`Manual` is author shorthand for "no event source" — never a serviceType value. The SDD writes `Manual`, `Intsvc.EventTrigger`, or `Intsvc.TimerTrigger`; the on-disk mapping is the build skill's.
+Tenant object starts are still event triggers: a case that starts when a tenant case-entity / data-object record is created authors `Intsvc.EventTrigger` with that object name as Source — never downgrade to `Manual` because the object is not provisioned; unresolved event triggers survive as placeholders (connectionId/activityTypeId → high review item).
+Configuration cell = user intent in business terms (`Record created`, `Email received in Inbox; filter: subject contains "URGENT"`, `daily at 09:00 UTC`, `N/A`); an event trigger MUST carry a concrete operation phrase. Forbidden here (build-time detail): CLI enum values (`CALENDAR_CREATED`), delivery modes (`polling`/`webhook`), meta notes, activity slugs, HTTP methods. -->
 
 | T# | Trigger Type | Source | Configuration |
 |----|-------------|--------|---------------|
 | T02 | <Manual \| Intsvc.EventTrigger \| Intsvc.TimerTrigger> | <source system, connector, object, or Manual> | <business event, timer cadence, filter intent, or N/A> |
 
+### Trigger Filter
+
+| Field | Operator | Value | Literal? |
+|-------|----------|-------|----------|
+| <payload field> | <one of, PascalCase and case-sensitive: Equals \| NotEquals \| Contains \| NotContains \| StartsWith \| EndsWith \| GreaterThan \| GreaterThanOrEqual \| LessThan \| LessThanOrEqual \| In \| NotIn \| IsNull \| IsNotNull> | <value> | <Yes — prefer a literal; No is a lossy fallback, so pair it with a review item> |
+
+<!-- Section only when ≥1 trigger declares a filter; omit otherwise. AND/OR tree; nested
+{op, clauses} groups flatten into rows. -->
+
 ### Case Exit Conditions
 
-<!-- WHEN + Marks Case Complete pairing is schema-constrained: Marks Case Complete = Yes normally uses `required-stages-completed`; selected-stage rules are for non-completing exits. -->
+<!-- WHEN + Marks Case Complete pairing is schema-constrained: Yes normally uses `required-stages-completed`;
+selected-stage rules are for non-completing exits (alternate dispositions: Withdrawn / Rejected /
+Cancelled — required when the case has ≥1 secondary stage, else high review item `Alt-disposition exits
+missing`). ≥1 Yes row always. Display Name defaulting (every condition table in this SDD): carry the
+author's value verbatim; blank → `Entry Rule {N}` / `Complete Rule {N}` / `Exit Rule {N}` by table kind,
+N 1-based per label kind — never invent a label otherwise. -->
 
 | WHEN | IF | THEN | Marks Case Complete | Display Name |
 |------|-----|------|---------------------|--------------|
@@ -149,16 +189,17 @@ Tenant object starts are still event triggers: a case that starts when a tenant
 <!--
 Only include In/Out arguments, trigger-payload Variables, and true case-level state read by conditions or reused by multiple consumers.
 Do not mint relay variables for one upstream task output consumed once downstream; bind those directly with `<- "Stage"."Task".out` or `vars.$xref('Stage','Task','out')`.
-Every row must have Category.
+Every row must have Category. Name camelCase, no role suffix.
+sourceTriggers/sourceFields grammar — In: optional single T<N> (blank = primary trigger, never CSV), sourceFields always empty (an In-arg selects a trigger, extracts nothing). Variable: single T<N> or CSV; one trigger → bare payload path (`response.subject`); CSV → keyed `T<N>: <path>; T<M>: <path>`, one entry per listed T-number; dot-paths only, no array indexing. Out: both empty; every Out row needs a Default OR a producing task Outputs row.
+Config-as-In: runtime business rules (priority bands, thresholds, taxonomies) ride ONE In variable — string with a JSON Default for opaque rule-sets; jsonSchema + body when downstream picks sub-fields. `json` is not a Type. file = JobAttachment record; a file In-arg triggers the Caller-obligation block in the confirmation.
 -->
 
 | Name | Category | Type | sourceTriggers | sourceFields | Default | Description |
 |------|----------|------|----------------|--------------|---------|-------------|
 | <camelCase name> | <In \| Out \| Variable> | <string \| integer \| float \| double \| boolean \| datetime \| date \| jsonSchema \| file> | <T02, blank, or CSV only for Variable rows> | <payload path or keyed T-number paths> | <default or blank — see below> | <what this variable represents> |
 
-> **`Default` is always a string, for every Type.** The downstream `caseplan.json` field is
-> string-typed, and a non-primitive value there is **silently deleted** when the case is serialized to
-> BPMN — the variable is then null at runtime and the first task that reads it fails. Write a
+> **`Default` is always a string, for every Type.** A non-string default is dropped on the way to
+> runtime, leaving the variable null for the first task that reads it. Write a
 > `jsonSchema` default as string-encoded JSON in the cell:
 > `{"employeeName":"Test Employee","amount":125.5}` becomes
 > `"{\"employeeName\":\"Test Employee\",\"amount\":125.5}"`. Same for numbers and booleans — `"5"`,
@@ -170,10 +211,9 @@ Every row must have Category.
 
 **Purpose:** The case plan. Every stage has entry/exit conditions, optional SLA, and complete task detail blocks. Case has no BPMN-style edges; transitions are expressed by stage entry/exit conditions.
 
-**Authoring rules** (owned by the reference files — block shape and cell grammar:
-[render-stages-tasks.md](../../references/case/render-stages-tasks.md); type enum, gates, sequencing:
-[model.md](../../references/case/model.md); task-level SLA surface: [slas.md](../../references/case/slas.md)).
-During draft finalization, do NOT open these links — the draft is the settled design and this template is
+**Authoring rules** — this template IS the render contract: cell rules live inline at each cell. Design
+semantics (type enum, gates, sequencing, SLA surface): [case-design-layers-guide.md](../../references/case-design-layers-guide.md).
+During draft finalization, do NOT open that link — the draft is the settled design and this template is
 the complete normalization contract; finalization preserves existing display names verbatim.
 Template-local rules:
 - Every stage and task carries a concrete `Design Rationale` and prose `Description`.
@@ -188,7 +228,13 @@ Template-local rules:
 
 ---
 
-### Stage <N>: <STAGE_NAME>
+### Stage <N>: <STAGE_NAME> (`<stage_id>`)
+
+<!-- The trailing code-formatted stage id MUST appear on every stage heading, and every cell that names a
+stage appends it in code-formatted parens — cross-references stay greppable. Required for Case Completion
+is explicit Yes/No (design default: primary Yes, secondary No). Design Rationale is concrete: a
+global-event lane names the event and states that one interrupting entry replaces per-stage duplication;
+an SLA lane names the SLA, the response, and why it interrupts or not. -->
 
 **Type:** Stage
 **Stage Kind:** <primary \| secondary>
@@ -213,11 +259,16 @@ Template-local rules:
 
 **Design Rationale:** <Why this duration, threshold, recipients, and breach behavior fit.>
 **SLA Type:** <time-based \| condition-based>
-**SLA Title:** <non-empty stage-unique SLA rule title, no `:` — this exact title is what a `sla-status-change("<Stage>","<SLA Title>")` entry row references>
+**SLA Title:** <non-empty stage-unique SLA rule title, no `:` — this exact title is what a `sla-status-change("<Stage>","<SLA Title>")` entry row references. Unnamed defaults: `<Stage Name> SLA`, at-risk display `<Stage Name> SLA at risk`, breach `<Stage Name> SLA breached`. Keep SLA Type and SLA Title as two separate lines — a collapsed line hides the title from line-start tooling>
+
+| SLA | Unit | At-Risk | At-Risk Escalation Display Name | Breach Escalation Display Name |
+|-----|------|---------|----------------------------------|---------------------------------|
+| <count> | <min \| h \| d \| w \| m> | <percentage>% | <stage-unique title, no `:`> | <stage-unique title, no `:`> |
 
-| SLA | Unit | At-Risk | At-Risk Action | At-Risk Escalation Display Name | Breach Action | Breach Escalation Display Name |
-|-----|------|---------|----------------|----------------------------------|---------------|---------------------------------|
-| <count> | <min \| h \| d \| w \| m> | <percentage>% | Notify: <recipient> | <stage-unique title, no `:`> | Notify: <recipient> | <stage-unique title, no `:`> |
+<!-- Titles and durations only. What HAPPENS at at-risk and breach is authored once, in
+§ SLA Response Map — this block never carries a Notify/enter-stage response. The display names above
+are load-bearing: they are the third argument of `sla-status-change("<Stage>","<SLA Title>","<display
+name>")`. -->
 
 ##### Stage Variable SLA Rules
 
@@ -229,6 +280,11 @@ Template-local rules:
 
 #### Tasks
 
+<!-- In plan order, ≥1 task per stage; Persona = persona name or `system`. Stage tables above: ≥1 entry
+row per stage; ≥1 completion (Yes) exit row per primary stage. Call forms with complete args appear ONLY
+in table rows; prose uses bare rule names. sla-status-change target is the literal `root` (case scope) or
+the exact stage display name — never the case name. -->
+
 | # | Task Name | Type | Activation Mode | Starts When | Required | Run Only Once | Persona | SLA |
 |---|-----------|------|-----------------|-------------|----------|---------------|---------|-----|
 | 1 | <TASK_NAME> | <action \| process \| agent \| rpa \| api-workflow \| wait-for-timer \| wait-for-connector \| execute-connector-activity \| case-management> | <sequential \| parallel \| parallel-after-predecessor \| event-triggered \| adhoc \| fan-in \| conditional-gate> | <stage enters, sequential group, after tasks, connector event, etc.> | <Yes \| No> | <Yes \| No> | <persona or —> | <count unit or —> |
@@ -258,7 +314,7 @@ Template-local rules:
 **Action App ID:** <actionAppId or <UNRESOLVED>>
 **Deployment Folder:** <folder path or <UNRESOLVED>>
 **actionType:** <dispatch code or —>
-**Recipient:** <Role:name \| User:uuid \| UserGroup:uuid \| Email:addr \| Expression:=vars.id>
+**Recipient:** <Role:name \| User:uuid \| UserGroup:uuid \| Email:addr \| Expression:=vars.id — typed prefix only; none known → drop the cell + high review item>
 **Priority:** <Low \| Medium \| High \| Critical> · **Task Title:** <one-line Action Center prompt> · **Labels:** <csv or —>
 
 **Input Schema:**
@@ -280,16 +336,29 @@ Template-local rules:
 |--------|---------|----------|
 | <button label> | <variable = value> | <Complete task \| Complete task and set variables> |
 
+<!-- Buttons only on a decision task — then ≥2 rows; Maps To LHS = a §1.5 Name, taskOutcome, or this
+task's own output (read downstream via a direct producer reference) — never an identifier occurring
+nowhere else. Input/Output Schema fields MUST be ⊆ the resolved app's schema — a field the app lacks →
+Ask (task-specific app / drop / placeholder), never silently author. Field NAMES are carried verbatim
+from whatever supplied them, never re-cased or convention-converted, and never read off a
+`--output json` envelope's PascalCased keys (layers § External names); unsourced spelling →
+<UNRESOLVED> + review item. Reusing ONE deployed app across
+several action tasks is sanctioned only when each task carries a distinct actionType dispatch value AND
+its fields ⊆ the app schema (code-switched app); otherwise it is the substitute-app defect. -->
+
 ###### Connector Task Detail (type: `wait-for-connector` or `execute-connector-activity`)
 
 **Connector:** <connector name> · **Connector Key:** <connectorKey>
 **Connection:** <connection instance name or Tenant default> · **Connection ID:** <connectionId or <UNRESOLVED>>
-**Activity Type ID:** <activityTypeId or <UNRESOLVED>> · **Service Type:** <Intsvc.WaitForEvent \| Intsvc.ExecuteActivity>
+**Activity Type ID:** <activityTypeId or <UNRESOLVED>>
 **Auth Method:** <OAuth2 \| API Key \| Basic \| Service Account \| ...>
 **Account / Endpoint:** <explicit endpoint or —>
 **Operation:** <display/operation name>
 **Trigger / Event:** <trigger display name for wait-for-connector, or —>
 
+<!-- Missing Connection ID / Activity Type ID → high review item. Inputs `Field` verbatim to the IS
+activity schema. Operation Configuration carries through as =jsonString: only here. -->
+
 **Inputs:**
 
 | Field | Type | Binding |
@@ -305,12 +374,14 @@ Template-local rules:
 
 ###### Timer Task Detail (type: `wait-for-timer`)
 
-**Timer:** <timeDuration \| timeDate \| timeCycle>
-**Value:** <ISO 8601 expression, date expression, or variable expression>
+**Timer:** <timeDuration (relative) \| timeDate (absolute) \| timeCycle>
+**Value:** <ISO 8601 expression, date expression, or variable expression — NEVER <UNRESOLVED>: a timer cannot fire without it; block approval>
+**Business Calendar:** <calendar name or —>
 
 ###### Child Case Task Detail (type: `case-management`)
 
-**Child Case:** <concrete intended child-case resource name; never <UNRESOLVED>>
+**Child Case:** <concrete intended child-case resource name; never <UNRESOLVED>, never the parent task's display name>
+**Child Case Identifier Prefix:** <2-4 char UPPER prefix>
 **Folder Path:** <folder path or <UNRESOLVED>>
 **Resource Identity:** <entityKey or <UNRESOLVED>>
 **Data Passed (parent -> child):**
@@ -321,7 +392,7 @@ Template-local rules:
 
 **Wait for Completion:** <Yes \| No>
 
-**Data Returned (child -> parent):**
+**Data Returned (child -> parent):** <!-- only when Wait for Completion: Yes -->
 
 | Child Variable | Parent Variable |
 |----------------|----------------|
@@ -332,8 +403,15 @@ Template-local rules:
 **Resolved Resource:** <concrete intended resource name; never <UNRESOLVED>>
 **Folder Path:** <resolved exact folder path or <UNRESOLVED>>
 **Resource Identity:** <apiWorkflowId / agentId / processOrchestrationId (+version) or <UNRESOLVED>>
-**Binding Sub-Type:** <Api \| Agent \| ProcessOrchestration \| —>
-**Dispatch / Operation:** <selector and value for shared facades, or —>
+**Dispatch / Operation:** <selector and value for shared facades (`requestSource = "RegisterCaseShell"`) — also an Inputs row; — for single-purpose resources>
+
+<!-- Folder Path = the exact resource folder (never a parent), or <UNRESOLVED> when identity is
+unresolved. When a task resolves to a live resource: every REQUIRED declared input has a non-empty
+Binding (any form incl. a direct upstream-output reference — needs no §1.5 row) or <UNRESOLVED> + high
+review item; every Outputs -> Field exists verbatim in the resolved output contract (phantom field → high
+review item). Unresolved-identity tasks have no contract — skipped; portable names stay concrete. Bare
+field-name input lists are forbidden — table form only. No task-level SLA on any non-action type. Deep
+runtime metadata (agent prompts, package versions, endpoints) stays out of the SDD. -->
 
 **Inputs:**
 
@@ -350,7 +428,7 @@ Template-local rules:
 
 ---
 
-### Secondary Stage: <SECONDARY_STAGE_NAME>
+### Secondary Stage: <SECONDARY_STAGE_NAME> (`<stage_id>`)
 
 **Type:** Stage
 **Stage Kind:** secondary
@@ -395,9 +473,19 @@ Template-local rules:
 
 **Operations:**
 
-| Operation | Activity Type ID | Method | Input Fields | Output Fields |
-|-----------|------------------|--------|-------------|---------------|
-| <operation name> | <activityTypeId or <UNRESOLVED>> | <GET \| POST \| PUT \| DELETE \| PATCH \| EVENT> | <field: type, ...> | <field: type, ...> |
+| Operation | Activity Type ID | Method | Output Fields |
+|-----------|------------------|--------|---------------|
+| <operation name> | <activityTypeId or <UNRESOLVED>> | <GET \| POST \| PUT \| DELETE \| PATCH \| EVENT> | <field: type, ...> |
+
+<!-- No Input Fields column: inputs are authored per task in the task's Input Schema table, and
+Phase 3 re-derives the operation's full input shape from the connector spec — design time never
+transcribes it. Output Fields lists ONLY the fields some Section 2 read path actually consumes, and
+lists them with their SCHEMA SPELLING, byte-for-byte: field names are external lookup keys matched
+exactly at runtime, and the `--output json` envelope of `case spec` / `registry search` PascalCases
+object keys recursively (`request_body` -> `RequestBody`), so a name copied from those keys binds to a
+field the resource does not have. Casing not sourced from the user, the source document, or a build-time
+spec -> render the field as <UNRESOLVED> and pair it with a review item; never guess a convention.
+Rule: case-design-layers-guide.md § Layer 3 (External names). -->
 
 ### API Workflows
 
@@ -496,4 +584,51 @@ Implementation tasks **do not live in this SDD** — they live in the planner's
 
 ---
 
+<!-- ============================ VALIDATION (do not render) ============================
+Markers: <UNRESOLVED> renders as plain text — never backtick-wrapped, never annotated in-cell; allowed
+ONLY on registry identity ids (taskTypeId, connectionId, actionAppId, agentId, processOrchestrationId,
+entityKey) and on a schema FIELD NAME whose exact spelling nothing in the conversation supplied,
+each paired with a review item. A field name is an external lookup key matched byte-for-byte at
+runtime — an unsourced one is <UNRESOLVED>, never a plausible guess (layers § External names). `—` allowed only where a cell above says so (optional cells
+the build defaults safely). Narrative cells never carry skill-internal vocabulary (Pattern C, bridge,
+companion, inputOutputs[], groupOperator, essentialConfiguration-as-prose, savedFilterTrees, dispatcher,
+io-binding, aliased into/from, reassign, originalVar, auto-mint).
+
+FINALIZING a draft (`sdd.draft.md` -> the final SDD): the render obeys this contract IN FULL — the
+document skeleton above, one `##### Task <n>: <Name>` detail block per task the draft inventories (never
+a stage-level Tasks table standing in for them), `**Type:** Stage` on every stage block, the exact
+type-specific detail headings and bold field labels (`**Timer:**` stays `**Timer:**`), Section 3/4 column
+headers verbatim, real newlines. A task the draft left as a summary still gets its full detail block:
+fill concise defaults, keep every concrete value the draft supplied, and set `**Resolved Resource:**` to
+the draft's intended resource name — or, when it names none, the task display name; never <UNRESOLVED>
+there. Pass --draft so the gate also checks inventory parity, verbatim `=js:` preservation, and
+executable threshold encoding. What the DRAFT specifically needs repaired on the way through is the
+lane guide's § Resumption; the shape is here.
+
+Gate: run  <py> "<skill folder>/scripts/audit_sdd.py" <sdd path> [--draft <draft path>]  on the
+on-disk file BEFORE the Status: ready flip — in every mode. `<py>` = the first of `python3`, `python`,
+`py` that runs (Windows usually has no `python3` alias); only if all three are absent verify manually. RUN it, never open the script source —
+its findings are the interface. Minting charset is ADVISORY — it never gates, and a name the user, the
+source, or a draft supplied is kept verbatim (pass --draft so the validator knows). ':' gates always. Repair findings with Edit, re-run to AUDIT OK
+(max 3 rounds, then stop and present findings). Never ship a summary SDD (top-level headings like
+## Source / ## Case Objective / ## Stages / ## Task Plan, or build-mode/path narration) even if a later
+caseplan.json would validate — rewrite from the model and this template.
+
+The validator's checks, by family — RUN it, do not hand-verify this list. Each name is what a finding
+will refer to; the rules themselves live at the cells above and in case-design-layers-guide.md:
+
+ 1. Document skeleton · 2. Closed enums + gate-slot pairing · 3. Names (':' ban + case-wide uniqueness;
+ charset is advisory)
+ 4. SLA references (arity, target, declared title) + stage/task selectors · 5. Data closure + orphan
+ Maps To · 6. Typed recipients, non-empty entry tables, forbidden vocabulary · 7. Structure (case-entered,
+ ≥1 trigger, ≥1 Marks Case Complete, wait-for-user ↔ user-selected-stage, no duplicate case-exit rows)
+ 8. Precedence & liveness (unreachable stage, exit-overrides-completion, self-reference, vacuous
+ required-*, SLA bounds) · 9. Draft parity (--draft: inventory, =js: expressions, thresholds encoded
+ executably)
+
+If no interpreter is available at all, the enforcement detail behind each family is in the cell rules
+above — every one of them must hold.
+
+===================================================================================== -->
+
 **End of Case Definition Blueprint.**