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

package/skills/uipath-maestro-case/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: uipath-maestro-case
-description: "Always invoke for UiPath Maestro Case Management build work: `caseplan.json`, `sdd.md`, or building/creating a case when no SDD exists yet (the case design is produced first, then confirmed in one review). Produces tasks.md and authors or edits caseplan.json directly with Write/Edit. For .xaml→uipath-rpa, .flow→uipath-maestro-flow, .bpmn→uipath-maestro-bpmn. For standalone case SDD design, case `sdd.draft.md` finalization, PDD→SDD, or cross-product planning→uipath-planner."
+description: "Always invoke for UiPath Maestro Case Management build work: `caseplan.json`, `sdd.md`, or building/creating a case when no SDD exists yet (the case design is produced first, then confirmed in one review). Resolves tenant resources then authors or edits caseplan.json directly with Write/Edit. For .xaml→uipath-rpa, .flow→uipath-maestro-flow, .bpmn→uipath-maestro-bpmn. For standalone case SDD design, case `sdd.draft.md` finalization, PDD→SDD, or cross-product planning→uipath-planner."
 allowed-tools: Bash, Read, Write, Edit, Glob, Grep, AskUserQuestion, TodoWrite, Agent
 ---
 
 # UiPath Case Management Authoring Assistant
 
-Build UiPath Case Management definitions from `sdd.md`. Generate `tasks.md`, then write `caseplan.json` directly using the applicable per-plugin JSON recipes.
+Build UiPath Case Management definitions from `sdd.md`. Resolve tenant resources into `tasks/registry-resolved.json`, then write `caseplan.json` directly from the SDD using the applicable per-plugin JSON recipes. The SDD is the plan — there is no intermediate plan file.
 
 > **Authoring invariant:** Never use mutating `uip maestro case` commands (`cases|stages|tasks|*-conditions ... add|update|remove`, including `tasks add-connector`) or explore them with `--help`. Use the CLI only for scaffolding, metadata reads, validation/debug, runtime operations, and solution sync/upload. Consult [case-commands.md](references/case-commands.md) only when exact syntax is needed. CLI availability or a final `validate` requirement never overrides this rule.
 
@@ -28,22 +28,22 @@ Do not use for `.xaml` → `uipath-rpa`, `.flow` → `uipath-maestro-flow`, or s
 
 ## Critical Rules
 
-1. **Design handoff and SDD authority.** If `sdd.md` is absent, immediately invoke `uipath-planner`’s Case Design Lane in this conversation, before reading references or running tenant commands. Do not improvise interviews, design subagents, generic Build Plan approvals, or design-only behavior here. The lane’s single Case Review has exactly these sections: Case Snapshot; Primary Journey; Other Paths Considered; SLA and Escalations; Rules and Outcomes; Resources and Integrations with design-time resolutions; Decisions I Made; Review Flags. It names every stage/task, type, activation/grouping, required status, routing/outcome, and SLA context; `sdd.md` separately contains the complete data contract, variables, and task inputs/outputs. The Build options incorporate Rule 11, and the Build answer is the sole consent. Corrections re-show only changed review sections. Before approval, every `selected-tasks-completed` selector must resolve to a non-adhoc sibling in the same stage. The lane writes `sdd.md` early, then this skill runs `uip solution init <SolutionName>` and Phase 1 without another prompt unless explicitly requested. If the request asks only for `sdd.md` plus `tasks/tasks.md`, write compact `tasks/tasks.md` after Save/Build, do not read plugin references or run tenant discovery, and stop before `caseplan.json`. If `sdd.draft.md` is to be finalized, use the lane fast path with target basename `sdd.md`. Never overwrite `sdd.md`.
+1. **Design handoff and SDD authority.** If `sdd.md` is absent, immediately invoke `uipath-planner`’s Case Design Lane in this conversation, before reading references or running tenant commands. Do not improvise interviews, design subagents, generic Build Plan approvals, or design-only behavior here. The lane’s single Case Review has exactly these sections: Case Snapshot; Primary Journey; Other Paths Considered; SLA and Escalations; Rules and Outcomes; Resources and Integrations with design-time resolutions; Decisions I Made; Review Flags. It names every stage/task, type, activation/grouping, required status, routing/outcome, and SLA context; `sdd.md` separately contains the complete data contract, variables, and task inputs/outputs. The Build options incorporate Rule 11, and the Build answer is the sole consent. Corrections re-show only changed review sections. Before approval, every `selected-tasks-completed` selector must resolve to a non-adhoc sibling in the same stage. The lane writes `sdd.md` early, then this skill runs `uip solution init <SolutionName>` and Phase 1 without another prompt unless explicitly requested. If the request asks only for the design, stop after `sdd.md`: do not read plugin references, run tenant discovery, or author a substitute plan file. If `sdd.draft.md` is to be finalized, use the lane fast path with target basename `sdd.md`. Never overwrite `sdd.md`.
 2. **SDD is the sole post-design input, across sessions.** Trust user-provided or previously written `sdd.md`; do not validate, gap-fill, or silently infer it. In the same conversation as design approval, use the in-memory model that wrote it without rereading. Use AskUserQuestion for build-phase ambiguity. Run a one-Grep receipt spot-check before reading an SDD not watched being written: it must contain `## Section 1: Case Definition` through `## Section 4: Integrations` and at least one `##### Task` block. Freeform/summary SDDs go back through the planner template-conformance gate.
 3. **Phase 1 registry gate.** Run `uip login status --output json`, then `uip maestro case registry pull`, before cache inspection, carryover, resolution, or Phase 1 writes. Pull at most once per session. If the planner lane ran in this session, its pull succeeded, and it wrote the SDD, reuse the cache. With the lane’s in-context resolution outcomes, use verify-only planning: persist them verbatim to `tasks/registry-resolved.json`, spot-check cache entries, execute gate decisions, and re-resolve only stale/missing entries. Otherwise run the full gate. Login/pull failure stops Phase 1. Read `~/.uip/case-resources/<type>-index.json` directly; `registry search` has known gaps, especially action-apps. Before a successful pull, missing cache files are failed refresh preconditions, never zero matches; only after success may empty exact-name matches or absent indexes enter empty-lookup handling. Trust the SDD; the pull refreshes discovery only. The planner lane owns design-time resolution, lazily starting login/pull when tenant-bound work first appears, resolving identities with one batched Case Review gate, and recording SDD cells plus its resolution ledger. No schema discovery occurs there.
 
-   **Plan-only exception:** when explicitly stopping at `sdd.md`, `sdd.draft.md`, or `tasks.md` without `caseplan.json`, solution, or build, do not run tenant registry, connection, schema, or user-discovery commands. Preserve intended names, mark identities `resolve at build`, and report deferred wiring. This exception does not apply when the user requests resource/identity resolution, registry refresh, stale-audit replacement, `tasks/registry-resolved.json`, or `tasks/recipients-resolved.json`; then run the normal gate, resolve identities, emit build-path `tasks.md`, and stop at the Rule 7 plan gate.
+   **Design-only exception:** when explicitly stopping at `sdd.md` or `sdd.draft.md` without `caseplan.json`, solution, or build, do not run tenant registry, connection, schema, or user-discovery commands. Preserve intended names, leave identities `<UNRESOLVED>`, and report deferred wiring in the reply — never in a substitute plan file. This exception does not apply when the user requests resource/identity resolution, registry refresh, stale-audit replacement, `tasks/registry-resolved.json`, or `tasks/recipients-resolved.json`; then run the normal gate, resolve identities, write the ledger, and stop before Phase 2.
 4. **Parsed reads require `--output json`.**
-5. **Use plugin references.** Read the matching plugin `planning.md` during planning and `impl-json.md` during execution; never guess JSON shapes.
-6. **`tasks.md` is declarative and lossless.** No shell commands. Use plain field identifiers, not CLI flags. Create one T-entry for every SDD stage, task, trigger, condition, SLA rule, variable, and argument, including explicit defaults. Preserve every valid explicit rule/selector exactly; reject and repair invalid `selected-tasks-completed` selectors. Preserve stage/task/SLA `Design Rationale` and condition routing/activation rationales as `rationale:`. Preserve every Inputs row, binding mode, and value. Preserve JSON object literals exactly: native object or JSON-encoded string in `input.value`; add `=js:`/`=jsonString:` only when explicitly present in the SDD. Project Outputs through [`plugins/variables/io-binding/planning.md`](references/plugins/variables/io-binding/planning.md#sdd-outputs-table-to-tasksmd-projection-mandatory), preserving operator and operands. SDD output rows require `->` or `=`; schema-discovered bare outputs are not authored SDD rows. Never simplify equal-name `->` rows; `greeting -> greeting` differs from schema-discovered bare `greeting`. `—` placeholders are not operands. AskUserQuestion for unrecognized or ambiguous rows; never omit silently. Regenerate greenfield plans from scratch; brownfield edits preserve IDs. Every §4.6 task entry has its own `activation-mode:` and `entry-rule:` — repeat this per task, never author it once and drop it for later similar tasks; `validate` only warns `Task has no entry rules`, while a miss hangs `case debug` indefinitely. Every task heading is exactly `## T<n>: Add <type> task "<name>" to "<stage>"`. See [references/planning.md §4.0](references/planning.md) and the [Plan-shape gate](references/planning.md#step-5--finalize-tasksmd-auto-proceed-to-phase-2).
-7. **Plan gate.** Phase 1 auto-proceeds to Phase 2 and treats the plan as approved. Stop after `tasks.md` only when the request explicitly says plan-only, Phase 1 only, review first, or not to build. Re-read `tasks.md` before execution.
-8. **Unresolved resources.** Never fabricate IDs. Keep `<UNRESOLVED: ...>` in `tasks.md`. A placeholder task has `type`, `displayName`, structural fields, and `data: {}`; conditions still reference its TaskId. A placeholder event trigger has render fields and only `data.inputs: { serviceType: "Intsvc.EventTrigger" }`; append its `entry-points.json` entry and create no trigger edge. See [references/placeholder-tasks.md](references/placeholder-tasks.md) and [references/plugins/triggers/event/impl-json.md](references/plugins/triggers/event/impl-json.md).
+5. **Use plugin references.** `cat` the matching plugin `planning.md` during planning and `impl-json.md` during execution, whole, per Rule 24; never guess JSON shapes.
+6. **The build is lossless against the SDD.** Never author an intermediate plan file: `sdd.md` is the plan, and restating it drifts from it. Write one `caseplan.json` element for every SDD stage, task, trigger, condition, SLA rule, variable, and argument, including explicit defaults. Preserve every valid explicit rule/selector exactly; reject and repair invalid `selected-tasks-completed` selectors. Carry stage/task/SLA `Design Rationale` and condition routing/activation rationales into the element's `description` where the schema has one, and into `build-issues.md` where it does not. Preserve every Inputs row, binding mode, and value. Preserve JSON object literals exactly: native object or JSON-encoded string in `input.value`; add `=js:`/`=jsonString:` only when explicitly present in the SDD. Project Outputs through [`plugins/variables/io-binding/planning.md`](references/plugins/variables/io-binding/planning.md#sdd-outputs-table-to-caseplan-projection-mandatory), preserving operator and operands. SDD output rows require `->` or `=`; schema-discovered bare outputs are not authored SDD rows. Never simplify equal-name `->` rows; `greeting -> greeting` differs from schema-discovered bare `greeting`. `—` placeholders are not operands. AskUserQuestion for unrecognized or ambiguous rows; never omit silently. Regenerate greenfield builds from scratch; brownfield edits preserve IDs. Every task node carries its own `entryConditions` derived from its SDD **Entry Condition** table and **Activation Mode** — write it per task, never once for a group of similar tasks; `validate` only warns `Task has no entry rules`, while a miss hangs `case debug` indefinitely. Step 12 enforces this against the finished artifact with `uip maestro case validate <caseplan.json> --strict --sdd sdd.md` (Rule 14): every stage, task, task type, condition row, SLA, trigger and case variable the SDD declares must be present, and a `STRICT_SDD_*` finding names what is missing. See [references/implementation.md](references/implementation.md).
+7. **Build gate.** Phase 1 auto-proceeds to Phase 2. Stop after resolution only when the request explicitly says design-only, Phase 1 only, review first, or not to build. Re-read `sdd.md` and `tasks/registry-resolved.json` at Phase 2 and Phase 3 entry — context may have compacted.
+8. **Unresolved resources.** Never fabricate IDs. Keep `<UNRESOLVED: ...>` in `tasks/registry-resolved.json`. A placeholder task has `type`, `displayName`, structural fields, and `data: {}`; conditions still reference its TaskId. A placeholder event trigger has render fields and only `data.inputs: { serviceType: "Intsvc.EventTrigger" }`; append its `entry-points.json` entry and create no trigger edge. See [references/placeholder-tasks.md](references/placeholder-tasks.md) and [references/plugins/triggers/event/impl-json.md](references/plugins/triggers/event/impl-json.md).
 9. **Resolution audit.** Persist one object per task in `tasks/registry-resolved.json` with exact keys `stage`, `task`, `taskType`, `cacheFile`, `searchQuery`, `matches`, `selected`, and `rationale`, plus resolved I/O/review metadata. Add `gateDecision` only when the user answered the design-time resource gate; default deferrals have none. `matches` is the complete exact-name set from the refreshed cache; `selected` is a match or `null` after a genuine empty lookup. Same-session planner ledgers are persisted verbatim, then verified/extended under Rule 3. The resolution ledger and `registry-resolved.json` are machine-only — never shown to the user, including in the Case Review.
 10. **Cross-task references.** Use `"Stage Name"."Task Name".output_name` and the common output-reference-ID algorithm in [`plugins/variables/io-binding/impl-json.md`](references/plugins/variables/io-binding/impl-json.md#output-reference-id-authoritative). Use the source output’s `.id`; only a custom `=` output without `.id` uses its verified root companion’s `.id`. Never use a reassigned output’s `.var`. Discover names with `uip maestro case spec` for connector tasks or `uip maestro case tasks describe` for non-connectors. In larger `=js:` expressions use `vars.$xref('Stage','Task','output')`, resolved at Step 11.5. See [references/bindings-and-expressions.md](references/bindings-and-expressions.md).
-11. **Build-review preference.** Capture once at journey start. Design handoff folds it into the Case Review Build options (`Build it — straight through` or `Build it — pause at the build preview`); provided SDD asks once after the roadmap. Non-interactive and resumed runs without a preference default to straight-through. At Phase 2→3, try `validate --skeleton-v2`; fall back once to legacy `--skeleton` only when the response explicitly says v2 is unknown/unsupported, typically invalid_argument/exit 3. Exit 3 alone is insufficient; real v2 failures are reported. Validation findings do not halt this advisory gate. Straight-through continues without prompting. Pause-at-preview follows [references/phased-execution.md](references/phased-execution.md): AskUserQuestion `Publish for review` / `Skip publish and continue` / `Abort`; on publish, refresh resources, upload with the required filter, print `DesignerUrl` before the follow-up, then ask `Continue to implementation` / `Abort`. Hard stops always remain at Phase 4 retry exhaustion, Phase 5, Phase 6, and Phase 7.
+11. **Build-review preference.** Capture once at journey start. Design handoff folds it into the Case Review Build options (`Build it — straight through` or `Build it — pause at the build preview`); provided SDD asks once after the roadmap. Non-interactive and resumed runs without a preference default to straight-through. At Phase 2→3, try `validate --skeleton-v2`; fall back once to legacy `--skeleton` only when the response explicitly says v2 is unknown/unsupported, typically invalid_argument/exit 3. Exit 3 alone is insufficient; real v2 failures are reported. Validation findings do not halt this advisory gate. Straight-through continues without prompting. Pause-at-preview follows [references/phased-execution.md](references/phased-execution.md): AskUserQuestion `Publish for review` / `Skip publish and continue` / `Abort`; on publish, refresh resources, upload with the required filter, print `DesignerUrl` before the follow-up, then ask `Continue to implementation` / `Abort`. Hard stops always remain at Phase 4 retry exhaustion, Phase 5, Phase 6, Phase 7, and any re-publish after a Phase 6 fix.
 12. **Never auto-debug or publish to Orchestrator.** `uip maestro case debug` executes real emails, messages, and API calls. Phase 7 (`case pack` → `solution pack` → `solution publish`) ships to the tenant. Each requires its own AskUserQuestion consent.
-13. **Artifact I/O.** For `caseplan.json`, `sdd.md`, `sdd.draft.md`, `tasks.md`, `tasks/registry-resolved.json`, `tasks/trigger-spec-cache.json`, `tasks/spec-cache.<elementId>.json`, `bindings_v2.json`, `id-map.json`, `entry-points.json`, and `build-issues.md`, use only Read and Write/Edit. No Python, Node, jq, sed, awk, scripts, shell redirection, `tee`, `cp`, `mv`, `install`, or `rsync`; no helper scripts, including under `/tmp`. The `node -e ... fs.*` ban covers all file reads, including `~/.uip/case-resources/`; use Read or `cat ... | python3 -c ...` for cache lookup. If `caseplan.json` exceeds about 30KB, use the preview/detail cadence in [case-editing-operations.md](references/case-editing-operations.md), never a helper. Bash is allowed only for UUID v4 generation without filesystem access, CLI metadata, validate, debug, and solution scaffold/upload. Prefixed IDs are chosen inline.
-14. **Runnable resources and sidecars.** Before Phase 4, run Step 12 Checks 7, 9, 11, and 12 even when publish, debug, or resource refresh is skipped. A non-null `selected` resource must not become a placeholder: retain `data.name` and `data.folderPath` with complete root bindings, project it into `bindings_v2.json.resources[]`, and make its `resourceKey` self-consistent with its own defaults, never a copied tenant identity/UUID. Checks 9/11 exempt connector nodes; Check 12 covers resolved connector tasks, event triggers, and `wait-for-connector` rules, which require spliced `caseShape.context` plus Connection/Folder root bindings, not degraded typeId/connectionId-only data. CLI validate is insufficient. Repair and recheck mismatches; halt before Phase 4 if they remain. Repeat Check 7 before every `resources refresh`. Refresh before every upload or debug. Every upload uses `--output-filter "{Status: Status, SolutionId: SolutionId, DesignerUrl: DesignerUrl}"`; print the returned DesignerUrl.
+13. **Artifact I/O.** For `caseplan.json`, `sdd.md`, `sdd.draft.md`, `tasks/registry-resolved.json`, `tasks/trigger-spec-cache.json`, `tasks/spec-cache.<elementId>.json`, `bindings_v2.json`, `id-map.json`, `entry-points.json`, and `build-issues.md`, use only your harness's file tools: `cat <file>` (or the Read tool, if the harness has one) to read, and Write / Edit (or `apply_patch`) to mutate. No Python, Node, jq, sed, awk, scripts, shell redirection, `tee`, `cp`, `mv`, `install`, or `rsync`; no helper scripts, including under `/tmp`, and no agent-authored script of any kind. **Exception — a read-only audit gate is allowed, not banned:** the planner's `audit_sdd.py` run over `sdd.md` writes nothing and only reports, so running it is always allowed. This rule exists to stop an artifact being AUTHORED or EDITED by script — never to stop it being CHECKED; the caseplan's own check is `uip maestro case validate --strict --sdd` (Rule 14). The `node -e ... fs.*` ban covers all file reads, including `~/.uip/case-resources/`; use `cat` (or Read) for cache lookup. If `caseplan.json` exceeds about 30KB, use the preview/detail cadence in [case-editing-operations.md](references/case-editing-operations.md), never a helper. Bash is allowed only for `cat`, UUID v4 generation without filesystem access, CLI metadata, validate, debug, and solution scaffold/upload. Prefixed IDs are chosen inline.
+14. **Runnable resources and sidecars.** Before Phase 4, run Step 12 Checks 7, 9, 11, and 12 even when publish, debug, or resource refresh is skipped. A non-null `selected` resource must not become a placeholder: retain `data.name` and `data.folderPath` with complete root bindings, project it into `bindings_v2.json.resources[]`, and make its `resourceKey` self-consistent with its own defaults, never a copied tenant identity/UUID. Checks 9/11 exempt connector nodes; Check 12 covers resolved connector tasks, event triggers, and `wait-for-connector` rules, which require spliced `caseShape.context` plus Connection/Folder root bindings, not degraded typeId/connectionId-only data. CLI validate on the default profile is insufficient: the closing validate at Phase 3 exit and in Phase 4 is `uip maestro case validate <caseplan.json> --strict --sdd sdd.md --output json` (`--sdd` implies `--strict` and audits completeness against the SDD; omit it only when no `sdd.md` exists), and a `Valid` without `"Profile": "strict"` does not close the build. **Version guard:** `--strict`/`--sdd` exist from CLI 1.202. Fall back to plain `validate` only when the response is `invalid_argument` naming `--strict` or `--sdd` as an unknown option (exit 3 alone is insufficient; a strict *failure* is never a reason to drop the flags). On fallback, record `strict profile unavailable on CLI <version>` in `build-issues.md` and in the completion report, and run Step 12 Checks 1–15 by hand. Repair and recheck mismatches; halt before Phase 4 if they remain. Repeat Check 7 before every `resources refresh`. Refresh before every upload or debug. Every `solution upload` uses `--output-filter "{Status: Status, Action: Action, SolutionId: SolutionId, DesignerUrl: DesignerUrl}"`; print the returned DesignerUrl and say whether `Action` was `Imported` or `Overwritten`.
 15. **Handoff contract.** Invoke `uipath-planner`’s Case Design Lane in this conversation, never as a subagent. It owns design, resolution, review, and SDD writing; this skill resumes at solution initialization. User-facing language presents one continuous flow and never mentions the handoff. If unavailable, say so in one line, request `sdd.md` or an approved pasted design, and stop. Cross-product planning remains a plain-text suggestion to the planner. Apply the Rule 15 receipt spot-check before unobserved SDD reads.
 16. **Closed task types.** `caseplan.json` task `type` must be exactly one of: `process`, `agent`, `rpa`, `action`, `api-workflow`, `case-management`, `execute-connector-activity`, `wait-for-connector`, `wait-for-timer`. Never use plugin folder or CLI names, `external-agent`, `external-workflow`, `document-extraction`, `flow-process`, `wait-for-event`, or other invented values. The unsupported types remain unsupported. See [references/case-schema.md](references/case-schema.md) and the Plugin Index.
 17. **Empty lookup gate.** If the same-session ledger has a user `gateDecision`, execute it without asking again: `resolve-at-build` → placeholder; `create-during-build` → inline create; `pick:<name>` → bind it. A missing decision is a default deferral, not consent; run the full gate. For zero matches, use one batched AskUserQuestion grouped by `(name,type)` with: `Force pull and re-resolve`; `Use placeholders for all`; and, only when creatable resources exist and `registry --local` is supported, `Create missing resources inline`. Create only selected `agent` or `api-workflow` resources, invoking `uipath-agents` or `uipath-api-workflow`; never infer Create from SDD content. Other empty types remain placeholder-only. Selected resources with identical I/O may share one build; differing I/O splits later with the anchor retaining the name, and SDD updates require permission. See [registry-discovery.md § 1c](references/registry-discovery.md#1c--dedup-the-selected-builds-one-resource-per-name-and-type), [Create-on-Missing](references/registry-discovery.md#create-on-missing-build-and-rediscovery), and [§ MUST Confirm](references/registry-discovery.md#must-confirm-before-placeholder-fallback).
@@ -53,8 +53,8 @@ Do not use for `.xaml` → `uipath-rpa`, `.flow` → `uipath-maestro-flow`, or s
 21. **Global events and SLA responses.** Model a global external event once as an interrupting secondary-stage `wait-for-connector` entry. Choose SLA response explicitly: `notify-only`, `start-task`, `enter-stage`, `exit-stage`, or `exit-case`. A `start-task` response belongs on the follow-up task’s own `sla-status-change` entry, not a stage entry. Interrupting depends on whether active work stops, pauses, or reroutes; parallel oversight uses `Interrupting: No` and remains secondary. `sla-status-change` names `slaId`; add `escalationId` only for at-risk responses. Without a stated response, at-risk and breach are notifications. Do not replicate rules across primary stages. See [references/sla-response-shapes.md](references/sla-response-shapes.md) and the SLA Response Map.
 22. **Formal argument IDs.** `variables.inputs[].id` and `variables.outputs[].id` must be synthetic `v` + 8 characters and distinct from `name`/`var`; never copy companion names. Run Step 12 Check 10 once at Phase 3 exit and non-interactively re-mint violations. CLI validate does not check this. See [global-vars/impl-json.md § Formal-arg slot ID format](references/plugins/variables/global-vars/impl-json.md#formal-arg-slot-id-format).
 23. **Never run `uip maestro case init`.** It may create a second solution and separate manifest. Use `uip solution init <SolutionName>` and the T01 direct-JSON scaffold in [implementation.md § Step 6](references/implementation.md#step-6--create-the-case-project-structure). See [case-commands.md § case init](references/case-commands.md#uip-maestro-case-init).
-24. **Read references to EOF before mutation.** Every `references/*.md` ends with `<!-- END: <filename> -->`. Before the first Write/Edit using a shape, procedure, constraint, or verification rule, Read that exact reference until its exact END marker appears in tool output during this session. Ranges, truncation, search hits, tables of contents, memory, and sibling references do not satisfy this. Reopen after compaction or when the prior read is unavailable. Keep reads modest to avoid output truncation. Tail contracts are normative.
-25. **Unique labels and task names.** Stage `data.label` values are unique case-wide; task `displayName` values are unique across all stages, exact and untrimmed, and contain no `:`. A missing display name binds to the resource name and participates in uniqueness. Assign names in Phase 1; later renaming touches the SDD, plan, ID map, and name-keyed references.
+24. **Read references to EOF before mutation.** Every `references/*.md` ends with `<!-- END: <filename> -->`. Ingest a reference with one `cat <path>` — the preferred way on every harness, and the only way on a Bash-only harness; a harness with a Read tool may Read the whole file instead. Before the first Write/Edit using a shape, procedure, constraint, or verification rule, that file's exact END marker must have appeared in tool output during this session. Windowed reads (`sed -n '1,240p'`, `head`), search hits, tables of contents, memory, and sibling references do not satisfy this, and neither does testing that the marker exists (`wc -l`, `tail -n 2`, `grep END`) — read to the marker, do not probe for it. The largest reference is about 68KB and `cat`s cleanly; do not split a read to keep output short. Reopen after compaction or when the prior read is unavailable. Tail contracts are normative.
+25. **Unique labels and task names.** Stage `data.label` values are unique case-wide; task `displayName` values are unique across all stages, exact and untrimmed, and contain no `:`. A missing display name binds to the resource name and participates in uniqueness. Condition `displayName` values are unique case-wide across all four condition scopes, so number the `Entry Rule {N}` / `Complete Rule {N}` / `Exit Rule {N}` defaults with a case-wide counter, never a per-stage or per-task one ([case-schema.md § Condition name uniqueness](references/case-schema.md#condition-name-uniqueness)). Assign names in Phase 1; later renaming touches the SDD, plan, ID map, and name-keyed references.
 
 ## Routing
 
@@ -98,17 +98,16 @@ For brownfield, use the short entry flow in [references/brownfield.md](reference
 
 ### Design handoff
 
-The trigger is binary: if no `.md` whose basename contains `sdd` exists at the resolved path, hand off. If the prompt names another SDD basename, copy it to `./sdd.md` using Read + Write; do not invoke the lane. If no `.md` is named, use `./sdd.md`. Do not read planning/plugin references or run tenant commands before the Case Review. For an explicit no-build design+plan request, write `sdd.md` and compact `tasks/tasks.md` after approval, without plugin references, schema, registry, connection, or user discovery, then stop. Planner-owned drafts and `sdd-viewer.html` stay with the planner. If unavailable, request an SDD and stop.
+The trigger is binary: if no `.md` whose basename contains `sdd` exists at the resolved path, hand off. If the prompt names another SDD basename, copy it to `./sdd.md` using Read + Write; do not invoke the lane. If no `.md` is named, use `./sdd.md`. Do not read planning/plugin references or run tenant commands before the Case Review. For an explicit no-build design request, write `sdd.md` after approval, without plugin references, schema, registry, connection, or user discovery, then stop — do not author a plan file in place of the build. Planner-owned drafts and `sdd-viewer.html` stay with the planner. If unavailable, request an SDD and stop.
 
-### Phase 1 — Planning
+### Phase 1 — Resolution
 
 Read [references/planning.md](references/planning.md) to produce:
 
-- `tasks/tasks.md`: T-numbered stages, tasks, conditions, SLA, variables, and arguments.
-- `tasks/registry-resolved.json`: complete resolution audit.
+- `tasks/registry-resolved.json`: complete resolution audit — tenant identities only, never a copy of the SDD's structure or contract.
 - If Create is selected at Rule 17: build selected agents/API workflows as in-solution siblings through the permitted sub-agent paths, ensure a solution exists, register them, refresh resources, rediscover, and bind them. See [registry-discovery.md § Create-on-Missing](references/registry-discovery.md#create-on-missing-build-and-rediscovery).
 
-`tasks/` is adjacent to `sdd.md`, never inside the solution/project. Auto-proceed to Phase 2 unless the request explicitly asks to stop for plan review. Re-read `tasks.md` first.
+`tasks/` is adjacent to `sdd.md`, never inside the solution/project. Auto-proceed to Phase 2 unless the request explicitly asks to stop before the build. Re-read `sdd.md` and the ledger first.
 
 ### Phase 2 — Prototyping
 
@@ -127,7 +126,7 @@ Read [references/implementation.md](references/implementation.md) and [reference
 
 ### Phase 3 — Implementation
 
-Re-read `tasks.md` and `caseplan.json` (Step 9.6), then follow Steps 9.7, 9.8, 10.5, and 11.5:
+Re-read the SDD's task detail blocks, `tasks/registry-resolved.json`, and `caseplan.json` (Step 9.6), then follow Steps 9.7, 9.8, 10.5, and 11.5:
 
 1. Resolve connector schemas/defaults with `uip maestro case spec`.
 2. Bind I/O for all task classes using [io-binding/impl-json.md](references/plugins/variables/io-binding/impl-json.md).
@@ -165,8 +164,8 @@ Hard-stop AskUserQuestion (Step 16): `Publish to Orchestrator` / `Done`. On publ
 | Need | Reference |
 |---|---|
 | Design without SDD | `uipath-planner` Case Design Lane; Rule 15 |
-| Plan from SDD | [references/planning.md](references/planning.md) |
-| Execute plan | [references/implementation.md](references/implementation.md) |
+| Resolve resources from SDD | [references/planning.md](references/planning.md) |
+| Build caseplan from SDD | [references/implementation.md](references/implementation.md) |
 | Brownfield edit | [references/brownfield.md](references/brownfield.md) |
 | Phase contracts | [references/phased-execution.md](references/phased-execution.md) |
 | Edit mechanics | [references/case-editing-operations.md](references/case-editing-operations.md) |
@@ -213,9 +212,9 @@ Connector-bound rules in any condition scope require `rule.uipath` built from `c
 
 - Do not leave a regular stage without an entry condition. The first stage uses `case-entered`; every other regular stage needs a reachable predecessor. Edges are retired.
 - Do not design here, start Phase 1 before Case Review approval, or build from a summary SDD. The planner owns design, other-path analysis, and template conformance.
-- Do not validate after each T-entry or validate twice without an intervening edit. Phase 2 validation is informational; Phase 4 validation is authoritative.
-- Write `tasks.md` with a seeded header and per-section batched Edit-appends: §4.2.1 variables, §4.3 triggers, §4.4 stages, §4.6 tasks, §4.7 conditions, and §4.8 SLA. Never write per T-entry, use a mega-Write, or exceed a 30KB single Edit payload. Recovery re-reads and resumes at the next unapplied entry. See [planning.md §4.0a](references/planning.md).
-- Write `caseplan.json` by section, preserving untouched siblings — never one Write for the whole file. Read once at section entry; use per-entry Edits for fewer than 10 entries, or one Write covering only that section's container (the stages array, or one stage's task array) for 10 or more; gather CLI-gated sections before writing. Cap any single Write at ~15K output tokens / ~40KB; split a case with ≥40 tasks or ≥8 stages across the Phase 2 and Phase 3 writes rather than emitting the fully populated file at once. Re-read both files after interruption. See [case-editing-operations.md § Per-section batch write contract](references/case-editing-operations.md#per-section-batch-write-contract--canonical).
+- Do not validate after each element or validate twice without an intervening edit. Phase 2 validation is informational; Phase 4 validation is authoritative and runs `--strict` — do not finish on a default-profile `Valid`.
+- Do not author `tasks/tasks.md`, a T-numbered task list, or any other restatement of the SDD. The SDD is the plan; Phase 2 writes `caseplan.json` from it directly, and Step 12's `validate --strict --sdd sdd.md` audits the artifact against it.
+- Write `caseplan.json` by section, preserving untouched siblings — never one Write for the whole file. Read once at section entry; use per-element Edits for fewer than 10 elements, or one Write covering only that section's container (the stages array, or one stage's task array) for 10 or more; gather CLI-gated sections before writing. Cap any single Write at ~15K output tokens / ~40KB; split a case with ≥40 tasks or ≥8 stages across the Phase 2 and Phase 3 writes rather than emitting the fully populated file at once. Re-read both files after interruption. See [case-editing-operations.md § Per-section batch write contract](references/case-editing-operations.md#per-section-batch-write-contract--canonical).
 - Do not emit standalone narration between tool calls. Bundle status with the next tool call; keep ordinary text under 200 tokens and allow-listed kickoff, hard-stop preambles, completion reports, DesignerUrl prints, and validation summaries under 500. Do not announce imminent actions with verbs such as `Building`, `Composing`, `Writing`, `Drafting`, `Generating`, `Now I'll`, `Next`, `Approach`, `Strategy`, `Plan`, `Let me`, or equivalent.
 - Preserve ordered task semantics. Sequential mode uses ordered `data.tasks` sets and one `runs-sequentially` rule per task; do not add `current-stage-entered` alongside it. Use parallel `current-stage-entered` only for independent work and `selected-tasks-completed` only for required fan-in. Event-triggered tasks use event/condition rules; manually triggered/adhoc tasks use one `adhoc` rule, `isRequired: false`, and no additional entry event. `adhoc` is an activation mode, not a task type.
 - Model secondary stages as interrupting exception lanes: `case-management:Stage`, `data.stageType: "secondary"`, `isRequired: false`, and `Interrupting: Yes` on stage and entries. Use `Interrupting: No` only for parallel SLA oversight. Use `return-to-origin`; do not connect secondary stages as normal flow or count them in required completion.

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

@@ -6,8 +6,8 @@ How to wire values into task inputs — expression prefixes, cross-task output r
 
 Every task input is wired using one of two modes. Pick based on the source of the value.
 
-| Mode | Tasks.md syntax | Implementation |
-|------|-----------------|----------------|
+| Mode | Canonical form | Implementation |
+|------|----------------|----------------|
 | **Literal or expression** | `input = "<value>"` | Write `"<value>"` to `task.data.inputs[i].value` in caseplan.json |
 | **Cross-task reference** | `input <- "Stage"."Task".output` | Resolve the source's output reference ID → write `"=vars.<outputReferenceId>"` to target input's `value` |
 
@@ -70,17 +70,27 @@ Every `=`-prefixed value in `caseplan.json` is dispatched to one of two runtime
 
 In any `=js:` expression use **strict** `===` / `!==`, never loose `==` / `!=`. JS eval coerces types on loose equality (`vars.flag == "true"` is truthy for the string `"true"`), which silently breaks boolean/number routing — and validation passes either way (loose `==` is valid JS), so nothing flags it.
 
-SDD IF columns and `tasks.md` conditions use natural shorthand — `approved == true`, `status != "done"`. When rewriting into a `conditionExpression` (or any `=js:` sink) you MUST upgrade the operator: `approved == true` → `=js:vars.approved === true`. Do NOT transcribe `==` / `!=` verbatim.
+SDD IF columns use natural shorthand — `approved == true`, `status != "done"`. When rewriting into a `conditionExpression` (or any `=js:` sink) you MUST upgrade the operator: `approved == true` → `=js:vars.approved === true`. Do NOT transcribe `==` / `!=` verbatim.
 
 ### Null-safe task-output references
 
-In any `=js:` sink (conditions, SLA, task inputs, connector bodies), null-guard every task-output dereference — guard the object, not the property:
+A task output is `null` until its task runs — and stays null when its task is adhoc, optional, or skipped, so a task input can hit it as easily as a case-start rule. Only the `=js:` form dereferences, so only it needs a guard.
+
+**`=vars.<id>` — lookup.** A single identifier ([§ Form by sink](#form-by-sink-the-table)): nothing to dereference, no guard. (A dotted `=vars.X.Y` is a different sink — see [io-binding/planning.md § `=` operator](plugins/variables/io-binding/planning.md).)
+
+**`=js:<expr>` — JS eval (Jint, ES2020).** Optional-chain every hop. Unguarded, it throws `Cannot read property 'Y' of null` (or `... of undefined`):
 
 ```
-=js:JSON.parse((vars.response4 || {}).RequestBody || '{}').outcome === 'Signed'
+=js:vars.X.Y                       ✗  throws while X is null
+=js:vars.X?.Y                      ✓
+
+=js:vars.X.Y.Z                     ✗  throws while X or X.Y is null
+=js:vars.X?.Y?.Z                   ✓
+
+=js:vars.$xref('Stage','Task','response')?.request_body   ✓  same for a marker
 ```
 
-`(vars.X || {}).Y` — never `vars.X.Y || <default>`. Whole-value `=vars.<id>` needs no guard.
+`?.` short-circuits to `undefined`, so `vars.X?.Y || <default>` is the way to supply a fallback.
 
 ### Conservative rule for `=metadata.X`
 
@@ -90,13 +100,13 @@ The lookup-path resolver has NO `=metadata.` branch — plain `=metadata.X` is N
 
 ### Planner-emit form
 
-The planner emits `tasks.md` using SDD-natural references — `=vars.X`, `=metadata.X`, `=bindings.X`, cross-task `<- "Stage"."Task".out` (verbatim, unresolved). Other `=`-prefixed forms (`=response.X`, `=Error.X`, `=datafabric.X`, `=orchestrator.JobAttachments`) also pass through to impl for per-sink wrap; see [Expression Prefixes](#expression-prefixes) for the full set. The implementation step rewrites to the canonical sink form when constructing `caseplan.json`. Detail: [plugins/variables/io-binding/planning.md](plugins/variables/io-binding/planning.md) and each plugin's `impl-json.md`.
+The SDD uses SDD-natural references — `=vars.X`, `=metadata.X`, `=bindings.X`, cross-task `<- "Stage"."Task".out` (verbatim, unresolved). Other `=`-prefixed forms (`=response.X`, `=Error.X`, `=datafabric.X`, `=orchestrator.JobAttachments`) also pass through to impl for per-sink wrap; see [Expression Prefixes](#expression-prefixes) for the full set. The implementation step rewrites to the canonical sink form when constructing `caseplan.json`. Detail: [plugins/variables/io-binding/planning.md](plugins/variables/io-binding/planning.md) and each plugin's `impl-json.md`.
 
 ## Cross-Task References
 
 Cross-task references wire the output of an earlier task into an input of a later task. The planning syntax uses **names** (human-readable), which the implementation phase resolves to variable IDs via direct JSON lookup.
 
-### Planning syntax (in `tasks.md`)
+### Planning syntax (in `sdd.md`)
 
 ```
 input_name <- "Stage Name"."Task Name".output_name
@@ -115,11 +125,11 @@ uip maestro case tasks describe --type <type> --id "<taskTypeId>" --output json
 uip maestro case tasks describe --type connector-activity --id "<typeId>" --connection-id "<uuid>" --output json
 ```
 
-Output names appear in the response under the output schema. Record them in the source task's `outputs:` field in `tasks.md` so downstream references can be validated.
+Output names appear in the response under the output schema. Record them on the source task's `data.outputs[]` in `caseplan.json` so downstream references can be validated.
 
 ### Validation rule
 
-Every cross-task reference in `tasks.md` MUST point to:
+Every cross-task reference in the SDD MUST point to:
 1. A stage that exists (created by an earlier `Create stage "..."` task).
 2. A task inside that stage that exists (created by an earlier `Add ... task "..." to "<stage>"` task).
 3. An output name listed in that task's `outputs:` field.
@@ -169,10 +179,12 @@ vars.$xref('Stage Name','Task Name','output_name')
 
 ## Examples
 
+The blocks below are the **canonical reasoning form** described in [plugins/variables/io-binding/planning.md](plugins/variables/io-binding/planning.md) — a normalized reading of the SDD Inputs/Outputs rows, never written to disk. `registry-resolved.json` records registry lookups only.
+
 ### Literal and expression inputs
 
-```markdown
-## T10: Add api-workflow task "Fetch Inbox" to "Triage"
+```text
+api-workflow task "Fetch Inbox" in stage "Triage"
 - inputs:
   - inbox_config = "=vars.inbox_config"
   - po_patterns  = "=vars.po_patterns"
@@ -182,8 +194,8 @@ vars.$xref('Stage Name','Task Name','output_name')
 
 ### Cross-task reference
 
-```markdown
-## T11: Add agent task "Classify Emails" to "Triage"
+```text
+agent task "Classify Emails" in stage "Triage"
 - inputs:
   - emails <- "Triage"."Fetch Inbox".emails
   - customer_id <- "Triage"."Fetch Inbox".customer_id
@@ -194,8 +206,8 @@ vars.$xref('Stage Name','Task Name','output_name')
 
 ### Mixed inputs (HITL/action)
 
-```markdown
-## T12: Add action task "Review Classification" to "Triage"
+```text
+action task "Review Classification" in stage "Triage"
 - recipient: approver@corp.com
 - priority: High
 - inputs:
@@ -216,7 +228,8 @@ vars.$xref('Stage Name','Task Name','output_name')
 - **Nesting expressions inside literals.** `"$metadata.amount"` or `"{{ amount }}"` do not work. Use `=metadata.amount` directly as the full value.
 - **Plain `=vars.X` inside connector body JSON.** The runtime does NOT evaluate plain prefix refs in connector body sinks — they arrive at the API as literal strings. Wrap as `=js:(vars.X)`. See [§ Canonical form per sink](#canonical-form-per-sink).
 - **Plain `=metadata.X` anywhere.** The lookup-path resolver has no `=metadata.` branch. Always wrap as `=js:metadata.X` (or `=js:(metadata.X)` for connector body / parens-required sinks).
-- **Dotted access via plain prefix.** `=vars.user.email` looks up a variable with id literally `user.email` and fails. Use `=js:vars.user.email`.
+- **Trailing default instead of a guard.** `vars.X.Y || '{}'` guards nothing — the throw lands on `.Y`, before `||` is reached. Guard the object: `vars.X?.Y`.
+- **Dotted access via plain prefix.** `=vars.user.email` looks up a variable with id literally `user.email` and fails. Use `=js:vars.user?.email`.
 - **`=js:(...)` outer parens on `conditionExpression`.** Conditions use bare `=js:<expr>` per FE convention. Sub-clause parens go inside when combining: `=js:(vars.X) && (vars.Y)` — outer wrap stays bare.
 - **Manually building filter-expression strings.** For filter sinks, author a structured FilterTree with `isLiteral: true` values when possible. Variable-bearing filters use `` =js:`<template>` `` with `${vars.X}` interpolations — see [connector-trigger-planning.md](connector-trigger-planning.md).
 

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

@@ -52,14 +52,14 @@ After writing bindings to top-level `bindings[]`, regenerate `bindings_v2.json`.
   "resource": "Connection",
   "key": "<connectionId>",
   "value": {
-    "connectionId": { "defaultValue": "<connectionId>" },
+    "ConnectionId": { "defaultValue": "<connectionId>" },
     "folderKey": { "defaultValue": "<folderKey>" }
   },
   "metadata": { "connector": "<connectorKey>" }
 }
 ```
 
-> **Known CLI bug:** `syncConnectionResources` reads `value.connectionId` (lowercase c) but `flow-schema` writes `value.ConnectionId` (uppercase C). Use **lowercase `connectionId`** until fixed.
+> **Casing is `ConnectionId` (capital C).** The reader is `@uipath/solution-sdk` `sync-resources-from-bindings.ts`, which looks up `value.ConnectionId.defaultValue` and falls back to the entry's `key`; the api-workflow bindings writer emits the same capital form. The earlier note here about a lowercase reader named `syncConnectionResources` was wrong — no such function exists in the CLI.
 
 File envelope: `{ "version": "2.0", "resources": [ /* one entry per resource */ ] }`
 
@@ -90,9 +90,9 @@ File envelope: `{ "version": "2.0", "resources": [ /* one entry per resource */
 
 | Field | Source | Plugin step |
 |---|---|---|
-| `id` | `connection-id` from `tasks.md` | Planning |
+| `id` | `connection-id` from `registry-resolved.json` | Planning |
 | `name` | `.Data.Connections[selected].name` from `get-connection` | Step 1 |
-| `connectorKey` | `connector-key` from `tasks.md` | Planning |
+| `connectorKey` | `connector-key` from `registry-resolved.json` | Planning |
 | `connectorName` | `.Data.Connections[selected].connector.name` from `get-connection` | Step 1 |
 | `folderKey` | `.Data.Connections[selected].folder.key` from `get-connection` | Step 1 |
 | `folderName` | `.Data.Connections[selected].folder.name` from `get-connection` | Step 1 |
@@ -156,6 +156,6 @@ After regenerating `bindings_v2.json` and running `resources refresh`:
    - **Skip `package` entries** — never target one directly. Removing the owning `process` / `app` cascades to *that resource's own* package declaration (the one its `dependencies[]` names); sibling resources and their packages are untouched.
    - **Never prune the case project's own `process` + `package` pair** (`Name` == the case project) — created by `solution projects add`, never by a binding, so absent from `bindings_v2.json` by design.
 3. Remove each unmatched entry using **that entry's `Key` from step 1's output** — the registry GUID, never the `bindings_v2.json` `key`: `uip solution resources remove <ResourceKey> --solution-folder <SolutionDir> --output json`. Offline, no auth, does not touch `bindings_v2.json`.
-4. Re-run `resources refresh`, then re-publish via Phase 5 (`uip solution upload` — [phased-execution.md § Phase 5](phased-execution.md#phase-5--publish)) so Studio Web drops its copy; a local removal alone does not clear an orphan already uploaded. Re-uploading an existing `SolutionId` is **refused without `--force`**, and `--force` destroys that solution's Studio Web version history — confirm with the user before passing it.
+4. Re-run `resources refresh`, then re-publish via Phase 5 (`uip solution upload` — [phased-execution.md § Phase 5](phased-execution.md#phase-5--publish)) so Studio Web drops its copy; a local removal alone does not clear an orphan already uploaded. The re-upload overwrites the Studio Web solution in place, discarding anything edited there since the last upload (the replaced contents are recorded as a restorable version) — keep it behind the Phase 5 consent gate.
 
 <!-- END: bindings-v2-sync.md -->

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

@@ -6,7 +6,7 @@ Targeted changes to an existing `caseplan.json`. Skips the design handoff and th
 
 ## When this journey applies
 
-`caseplan.json` already exists AND the user wants a targeted edit ("add a stage", "remove task X", "change this condition", "swap the trigger"). No `sdd.md`, no `tasks.md`, no planning phase, no prototyping hard stop. Routing lives in [SKILL.md](../SKILL.md#routing--greenfield-vs-brownfield).
+`caseplan.json` already exists AND the user wants a targeted edit ("add a stage", "remove task X", "change this condition", "swap the trigger"). No `sdd.md`, no resolution phase, no planning phase, no prototyping hard stop. Routing lives in [SKILL.md](../SKILL.md#routing--greenfield-vs-brownfield).
 
 ## Kickoff — set dev expectations first
 
@@ -90,7 +90,7 @@ An SLA clock and its **response** are separate edits. Pick the response, the sta
 
 ## After edits
 
-1. **Validate** — `uip maestro case validate <ProjectName>/caseplan.json --output json`. Authoritative; retry ≤3, fix on failure. On 3rd failure HARD STOP: AskUserQuestion `Retry with fix` / `Pause for manual edit` / `Abort` (same contract as Phase 4).
+1. **Validate** — `uip maestro case validate <ProjectName>/caseplan.json --strict --output json` (fall back to the default profile only if the CLI rejects `--strict`, and say so). Authoritative; retry ≤3, fix on failure. On 3rd failure HARD STOP: AskUserQuestion `Retry with fix` / `Pause for manual edit` / `Abort` (same contract as Phase 4).
 2. **Any edit that adds, removes, or repoints a resource binding — connector OR non-connector** — regenerate `bindings_v2.json` per [bindings-v2-sync.md](bindings-v2-sync.md), then `uip solution resources refresh --solution-folder <SolutionDir> --output json` (Rule 14) before any debug/publish. `bindings_v2.json` holds non-connector bindings too (process/agent/rpa/action/api-workflow/case-management — [bindings-v2-sync.md § What `resource refresh` produces](bindings-v2-sync.md#what-resource-refresh-produces)); a stale file makes `uip solution upload` / `debug` throw "Resource is not configured". A pure schema-only re-sync (same resource, no binding change) needs no refresh. Repoint or removal → also prune the orphan ([bindings-v2-sync.md § Prune orphaned solution resources](bindings-v2-sync.md#prune-orphaned-solution-resources)).
 
 ## Completion Output
@@ -99,7 +99,7 @@ Report: file path edited, what changed (nodes/tasks/conditions added/removed/mod
 
 | Option | What it does |
 |---|---|
-| **Publish to Studio Web** | Phase 5 — `uip solution resources refresh` then `uip solution upload <SolutionDir> --output json --output-filter "{Status: Status, SolutionId: SolutionId, DesignerUrl: DesignerUrl}"` (filter mandatory — see [case-commands.md § uip solution upload](case-commands.md#uip-solution-upload)), print DesignerUrl. |
+| **Publish to Studio Web** | Phase 5 — `uip solution resources refresh` then `uip solution upload <SolutionDir> --output json --output-filter "{Status: Status, Action: Action, SolutionId: SolutionId, DesignerUrl: DesignerUrl}"` (filter mandatory — see [case-commands.md § uip solution upload](case-commands.md#uip-solution-upload)), print DesignerUrl and the `Action` (`Imported`/`Overwritten`). |
 | **Run debug session** | Phase 6 — executes the case for real (consent-gated, Rule 12). |
 | **Publish to Orchestrator** | Phase 7 — `uip maestro case pack` (mandatory BPMN recompile), then `uip solution pack`, then `uip solution publish` to the tenant solution feed (consent-gated, Rule 12). |
 | **Done** (default) | Stop here. |

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

@@ -95,16 +95,16 @@ Upload a solution directly to Studio Web. **Requires `uip login`.**
 
 ```bash
 uip solution resources refresh --solution-folder <SolutionDir> --output json
-uip solution upload <SolutionDir> --output json --output-filter "{Status: Status, SolutionId: SolutionId, DesignerUrl: DesignerUrl}"
+uip solution upload <SolutionDir> --output json --output-filter "{Status: Status, Action: Action, SolutionId: SolutionId, DesignerUrl: DesignerUrl}"
 ```
 
 `uip solution upload` accepts the solution directory (the folder containing the `.uipx` file) directly — no intermediate bundling step. Uploads to Studio Web where the user can visualize, inspect, edit, and publish the case from the browser.
 
-> **`--output-filter` is mandatory on upload.** The raw upload response is large enough that the agent truncates it and loses `DesignerUrl`. The JMESPath projection `{Status: Status, SolutionId: SolutionId, DesignerUrl: DesignerUrl}` (applied to the response envelope's `Data` field) reduces the response to the three fields the skill actually reads, so `DesignerUrl` always survives.
+> **`--output-filter` is mandatory on upload.** The raw upload response is large enough that the agent truncates it and loses `DesignerUrl`. The JMESPath projection `{Status: Status, Action: Action, SolutionId: SolutionId, DesignerUrl: DesignerUrl}` (applied to the response envelope's `Data` field) reduces the response to the four fields the skill actually reads, so `DesignerUrl` always survives. `Action` is `Imported` or `Overwritten` — say which one when reporting the upload, since an overwrite replaced whatever was on Studio Web.
 
-> **On a missing `DesignerUrl`**, re-run the upload once **without** `--output-filter` and dump the unfiltered response to `tasks/upload-response.json` — the filter hides any error/diagnostic fields that explain why the URL is absent.
+> **On a missing `DesignerUrl`**, re-run the upload once **without** `--output-filter` and dump the unfiltered response to `tasks/upload-response.json` — the filter hides any error/diagnostic fields that explain why the URL is absent. The re-run is itself a second upload (another overwrite, another recorded version) — at most once, within the consent already given for this publish.
 
-> **This is the default publish path.** When the user asks to "publish" without specifying where, run `resource refresh` then `uip solution upload <SolutionDir> --output json --output-filter "{Status: Status, SolutionId: SolutionId, DesignerUrl: DesignerUrl}"`. Share the resulting URL with the user.
+> **This is the default publish path.** When the user asks to "publish" without specifying where, run `resource refresh` then `uip solution upload <SolutionDir> --output json --output-filter "{Status: Status, Action: Action, SolutionId: SolutionId, DesignerUrl: DesignerUrl}"`. Share the resulting URL with the user.
 
 ---
 
@@ -185,6 +185,8 @@ uip solution publish <packagePath> --wait --output json
 Validate a case management JSON file against case management rules.
 
 ```bash
+uip maestro case validate <file> --strict --sdd sdd.md --output json
+uip maestro case validate <file> --strict --output json
 uip maestro case validate <file> --output json
 uip maestro case validate <file> --skeleton-v2 --output json
 uip maestro case validate <file> --skeleton --output json
@@ -193,6 +195,8 @@ uip maestro case validate <file> --skeleton --output json
 | Flag | Description |
 |------|-------------|
 | `<file>` | **(required)** Path to the case management JSON file |
+| `--strict` | Authoritative Phase 3-exit and Phase 4 profile: the default checks plus case-wide completeness rules (empty stage, surviving `$xref(`, hoisted `conditionExpression`, incomplete connector context, empty task `data`, output-shape and input-reference form). Failures carry `STRICT_*` codes in `Data.Issues[]`. Mutually exclusive with `--skeleton` / `--skeleton-v2`. |
+| `--sdd <path>` | Audit completeness against the SDD that specifies the case: every stage, task, task type, condition row, SLA, trigger and case variable the SDD declares must be present. Implies `--strict`; findings are `STRICT_SDD_*`. Use whenever an `sdd.md` exists. |
 | `--skeleton-v2` | Preferred Phase 2 preview profile: structure plus entry/exit rules, SLA, and escalation, while task values and connector schemas are still incomplete. Availability depends on the installed CLI. |
 | `--skeleton` | Legacy structural profile. Skips tasks, SLAs, escalations, and entry/exit rules. Used only as the Phase 2 fallback when `--skeleton-v2` is unavailable. |
 

package/skills/uipath-maestro-case/references/case-editing-operations.md

@@ -66,7 +66,7 @@ Before every write to `caseplan.json`, confirm each item. These are the failure
 
 11. **Cross-task bindings reference existing IDs.** Before writing a `var bind` entry, confirm the source stage ID and source task ID both exist in `caseplan.json`.
 
-12. **Validate after every section's batch — with exceptions.** Run `uip maestro case validate <file> --output json` after each `tasks.md` section batch completes (per § Per-section batch write contract below). One validate per section, not one per T-entry. Fixing errors at the section boundary is cheaper than chasing a cascade.
+12. **Validate after every section's batch — with exceptions.** Run `uip maestro case validate <file> --output json` after each element-class section batch completes (the closing validate at Phase 3 exit and in Phase 4 adds `--strict`; section boundaries use the default profile because mid-build state is legitimately incomplete) (per § Per-section batch write contract below). One validate per section, not one per element. Fixing errors at the section boundary is cheaper than chasing a cascade.
     - **Exception — case plugin (T01):** A case-only caseplan is known-invalid by design (no stage nodes, so the case cannot be entered). Skip `uip maestro case validate` after T01; a cheap `JSON.parse` + root/trigger shape check is the substitute — see [plugins/case/impl-json.md § Post-write validation](plugins/case/impl-json.md#post-write-validation).
     - **Exception — stages plugin (pilot):** A stages-only caseplan is also known-invalid (stages have no entry conditions yet). The plugin's validation parity is captured in the fixture instead.
 
@@ -123,7 +123,7 @@ Every skill run generates fresh IDs — no determinism.
 2. **Downstream plugins** read the file, append entries for generated IDs (stage, task, condition, etc.), write back. Each plugin writes the map before handing off to the next so cross-plugin references can resolve via the on-disk file.
 3. **End of run:** the file is complete and lives alongside `caseplan.json`.
 
-Mapping T-entries from `tasks.md` to generated IDs:
+Mapping build steps to generated IDs (`T<n>` is the execution-order label, not a file reference):
 
 ```json
 {
@@ -157,8 +157,8 @@ Full sink-to-form table, the lookup-vs-JS-eval dispatch, and connector-trigger f
 All mutations to `caseplan.json` (and sibling files like `entry-points.json`, `id-map.json`) MUST go through Claude's built-in tools only:
 
 - **Read** to load the file.
-- **Edit** for narrowly-scoped, unambiguous in-place replacements — default for all mutations after T01, and required for sections with <10 T-entries.
-- **Write** for the T01 scaffold (initial empty-file creation by the `case` plugin) and for whole-section batched writes when a section has ≥10 T-entries — see § Per-section batch write contract for the bounded conditions under which whole-section Write replaces N sibling Edits.
+- **Edit** for narrowly-scoped, unambiguous in-place replacements — default for all mutations after T01, and required for sections with <10 elements.
+- **Write** for the T01 scaffold (initial empty-file creation by the `case` plugin) and for whole-section batched writes when a section has ≥10 elements — see § Per-section batch write contract for the bounded conditions under which whole-section Write replaces N sibling Edits.
 
 **Do NOT** shell out to `python`, `node`, `jq`, `sed`, `awk`, or any other process to read, parse, transform, or write the JSON. No helper scripts, no inline one-liners that modify files, no `python3 -c '... json.load ... json.dump ...'`, no `node -e "...fs.writeFileSync...".` The agent holds the parsed object in its own reasoning; the file system is touched only via Read/Write/Edit.
 
@@ -180,14 +180,14 @@ Pseudocode blocks in this document and in per-plugin `impl-json.md` files (`issu
 
 ### Per-section batch write contract — canonical
 
-`caseplan.json` mutations follow a **per-section batched Edit** contract. The unit is one `tasks.md` section (e.g., §4.4 stages, §4.6 task-shapes, §4.7 conditions, §4.8 SLA), not one T-entry.
+`caseplan.json` mutations follow a **per-section batched Edit** contract. The unit is one SDD element class (variables, triggers, stages, task-shapes, conditions, SLA), not one element.
 
 Procedure per section:
 
 1. **One Read** of `caseplan.json` at section entry — authoritative state.
-2. **Section-sized writes** — pick by T-entry count:
-   - **Small sections (<10 T-entries)** — N Edits in sequence, one per T-entry. Edit targets the smallest unambiguous slice of JSON the T-entry mutates (one node, one array field, one task's `data.inputs`).
-   - **Large sections (≥10 T-entries)** — single whole-section write replacing the section's container (e.g., entire `schema.nodes` array for stages, a stage's full `data.tasks` array for tasks within that stage). Compose the complete post-section state in reasoning from the Read snapshot, then emit via one Edit (replacing the container slice) or one Write (whole-file rewrite) — Write only when the per-section Edit slice is too large to express as a single unambiguous `old_string`/`new_string` pair.
+2. **Section-sized writes** — pick by element count:
+   - **Small sections (<10 elements)** — N Edits in sequence, one per element. Edit targets the smallest unambiguous slice of JSON the element mutates (one node, one array field, one task's `data.inputs`).
+   - **Large sections (≥10 elements)** — single whole-section write replacing the section's container (e.g., entire `schema.nodes` array for stages, a stage's full `data.tasks` array for tasks within that stage). Compose the complete post-section state in reasoning from the Read snapshot, then emit via one Edit (replacing the container slice) or one Write (whole-file rewrite) — Write only when the per-section Edit slice is too large to express as a single unambiguous `old_string`/`new_string` pair.
 3. **Skip the re-Read between sibling Edits** — Edit's tool result confirms applied state in context; explicit re-Read is redundant for in-memory correctness.
 4. **One `validate`** at section boundary (Pre-flight Item 12 above).
 5. **Repair preservation.** Before a whole-file Write used to repair a validation error, record from the section-entry Read the stage IDs, task IDs, root binding IDs, and selected-resource task IDs that are outside the repair target. Immediately re-Read after the Write and verify that every recorded item remains. A repair may not remove or replace unrelated topology, bindings, or a resolved task merely to make `validate` pass; use a targeted Edit when the reported error identifies an individual binding or task.
@@ -198,9 +198,9 @@ Procedure per section:
 - **Extend until the match is unique within the whole file**, not just within the intended node.
 - An `old_string` that overlaps text a prior Edit in the same turn removed or shifted fails with "string not found" — order Edits so each targets an untouched slice, or re-Read if a later Edit depends on an earlier one's output.
 
-**Tool primitive choice.** Edit is the default — it preserves untouched fields automatically. Whole-file Write rebuilds the file from agent reasoning and risks silently dropping fields the agent forgot; use it only when (a) the section has ≥10 T-entries AND (b) the agent has the complete file state in context from the Read at step 1 AND (c) every untouched root-level field, sibling section, and node not mutated by this section will be copied verbatim. When in doubt, fall back to N Edits — the 12-item Pre-flight Checklist exists because field drops have happened, and Edit is the structural defense.
+**Tool primitive choice.** Edit is the default — it preserves untouched fields automatically. Whole-file Write rebuilds the file from agent reasoning and risks silently dropping fields the agent forgot; use it only when (a) the section has ≥10 elements AND (b) the agent has the complete file state in context from the Read at step 1 AND (c) every untouched root-level field, sibling section, and node not mutated by this section will be copied verbatim. When in doubt, fall back to N Edits — the 12-item Pre-flight Checklist exists because field drops have happened, and Edit is the structural defense.
 
-**Status text bundling.** Any progress text the agent emits before a section's first Edit/Write MUST share the same assistant turn as the tool_use (text block + tool_use block in one content array). Standalone text-only turns between Edits are forbidden — they each cost ~5s inference latency + full prompt cache replay for no work. Cap inline status to ≤1 sentence / ~20 tokens. Per-T-entry audit lives in TaskUpdate, NOT in narration.
+**Status text bundling.** Any progress text the agent emits before a section's first Edit/Write MUST share the same assistant turn as the tool_use (text block + tool_use block in one content array). Standalone text-only turns between Edits are forbidden — they each cost ~5s inference latency + full prompt cache replay for no work. Cap inline status to ≤1 sentence / ~20 tokens. Per-element audit lives in TaskUpdate, NOT in narration.
 
 **Planning monologues forbidden.** Pre-Write/pre-Edit text turns that announce intent ("Caveman push:", "Approach:", "Strategy:", "Big single Write:", "Writing full caseplan.json structurally", "Now I'll batch all stages") are forbidden, whether bundled or standalone. The tool call itself IS the announcement — TaskUpdate carries the T-by-T narrative, the Edit/Write tool input is self-describing. If the status text the agent wants to emit exceeds one short sentence, the correct action is to cut it, not to bundle it. Multi-paragraph status text is always a violation.
 
@@ -208,15 +208,15 @@ Procedure per section:
 
 **Forbidden announcement verbs.** Text blocks (bundled or standalone) starting with `Building`, `Composing`, `Writing`, `Drafting`, `Generating`, `Now I'll`, `Next:`, `Next step:`, `Approach:`, `Strategy:`, `Plan:`, `Caveman push:`, `Big single Write:`, `Let me`, or any other narration of the imminent tool call are FORBIDDEN regardless of length. Restating the upcoming tool_use in prose is pure cost. Allowed exceptions remain: the once-per-run kickoff flow overview, AskUserQuestion preambles, completion reports (Phase 5/6 exit), `Publish for review` DesignerUrl print, and post-validate result summaries (`N errors, M warnings — fixing X` is fine; `Composing fix for ...` is not).
 
-**Audit trail via TaskUpdate.** Reviewers see T-by-T progress in the todo log, not in the file diff. Each plugin seeds TaskCreate items keyed by T-number; mark each `in_progress` before composing the entry's mutation in reasoning, `completed` after the Edit/Write returns success. The transcript shows one or N writes per section — what changes is the dropped re-Read between siblings and the dropped standalone narration turns.
+**Audit trail via TaskUpdate.** Reviewers see element-by-element progress in the todo log, not in the file diff. Each plugin seeds TaskCreate items keyed by T-number; mark each `in_progress` before composing the entry's mutation in reasoning, `completed` after the Edit/Write returns success. The transcript shows one or N writes per section — what changes is the dropped re-Read between siblings and the dropped standalone narration turns.
 
-**CLI-gated sections — gather-then-write.** Where each T-entry needs its own CLI call before its JSON shape is known (Phase 2 §4.6 non-connector `tasks describe`; Phase 3 §9.7 connector `case spec`): run all CLI calls first, collect results in reasoning, then enter the Read → N-Edits → validate batch.
+**CLI-gated sections — gather-then-write.** Where each element needs its own CLI call before its JSON shape is known (Phase 2 non-connector `tasks describe`; Phase 3 Step 9.7 connector `case spec`): run all CLI calls first, collect results in reasoning, then enter the Read → N-Edits → validate batch.
 
-**Recovery.** On any mid-batch interruption (Edit failure, context compact, abort): re-Read `caseplan.json` + `tasks.md`, scan for next un-applied T-entry, resume from there. No sidecar checkpoint file. For CLI-gated sections, re-run the CLI calls for un-applied entries — typically cheap.
+**Recovery.** On any mid-batch interruption (Edit failure, context compact, abort): re-Read `caseplan.json` + `sdd.md`, then resume at the first element of the in-progress class that has no matching `displayName` (stage `data.label`, task `displayName`, variable `name`) in `caseplan.json`. No sidecar checkpoint file. For CLI-gated sections, re-run the CLI calls for un-applied entries — typically cheap.
 
-**Scope.** This contract applies to **`caseplan.json`**. `tasks.md` (Phase 1) and `registry-resolved.json` follow the mirror section-batched contract in [planning.md §4.0a](planning.md) — same one-Read-per-section + N-Edit-appends shape, with markdown Edit-append as the primitive (no whole-section Write needed; markdown appends are cheap regardless of count).
+**Scope.** This contract applies to **`caseplan.json`**. Phase 1's `registry-resolved.json` follows the mirror section-batched contract in [planning.md Step 4](planning.md) — same one-Read-per-section + N-Edit-appends shape, with a single Edit splicing each entry object into the ledger array as the primitive (no whole-section Write needed; one-object appends are cheap regardless of count).
 
-**Whole-file Write outside T01.** Permitted only at section boundaries for sections with ≥10 T-entries, per the procedure above. Forbidden mid-section (between T-entries within the same section) — that bypasses the Read snapshot and risks field drops.
+**Whole-file Write outside the initial scaffold.** Permitted only at section boundaries for sections with ≥10 elements, per the procedure above. Forbidden mid-section (between elements within the same section) — that bypasses the Read snapshot and risks field drops.
 
 **Cap single Write output at ~15K tokens / ~40KB.** When a section's combined output would exceed this, do NOT collapse into one Write — preserve the per-section cadence: Phase 2 writes root, nodes, variables, task shapes, SLA/escalations, and conditions (connector-backed rules use the canonical stub); Phase 3 fills connector context/input/output and other task values, then upgrades resolved connector-rule stubs. A single Write turn beyond ~15K out tok pays ~150s inference latency and concentrates field-drop risk. For a case with ≥40 tasks or ≥8 stages, never emit the fully populated `caseplan.json` in one Write — use the Phase 2 sections followed by Phase 3 detail Edits.
 
@@ -484,7 +484,7 @@ Transitions are not edges. To change where a stage flows, edit the relevant stag
 
 ## Validation Cadence
 
-Run `uip maestro case validate <file> --output json` after each `tasks.md` section's batch completes — not after every Edit. Intermediate states can be invalid (e.g., a stage whose entry condition references a stage that will be added next); validate is authoritative at the section boundary.
+Run `uip maestro case validate <file> --output json` after each element-class section's batch completes — not after every Edit. The closing validate at Phase 3 exit and in Phase 4 adds `--strict`. Intermediate states can be invalid (e.g., a stage whose entry condition references a stage that will be added next); validate is authoritative at the section boundary.
 
 On failure: fix the reported issue (usually a missing field, malformed ID, or orphan reference) and re-validate. Up to 3 retries per section; if still failing, halt and AskUserQuestion the user with the remaining errors and options to retry, pause, or abort.
 
@@ -499,9 +499,9 @@ On failure: fix the reported issue (usually a missing field, malformed ID, or or
 - **Do NOT initialize empty `entryConditions`/`exitConditions` arrays on primary Stages.** The condition plugins add authored arrays in Step 10; secondary stages (`data.stageType: "secondary"`) initialize both arrays when created.
 - **Do NOT auto-inject a task `entryCondition` at task-creation time based on task type.** Entry conditions come from the SDD via the task-entry-conditions plugin (Step 10), uniformly across task types. Injecting one early duplicates the Step 10 write and corrupts `displayName` indexing.
 - **Do NOT write partial JSON with Edit tool regex.** Round-trip through Read → reason → Edit per the per-section batch contract.
-- **Do NOT run validation after every single Edit.** Validate at section boundaries, not per-T-entry.
-- **Do NOT use whole-file Write mid-section.** Whole-file Write between sibling T-entries inside a section bypasses the section-entry Read snapshot and risks silently dropping fields. Use Edit per T-entry, OR collapse the entire section into one whole-section Write at section boundary when T-entry count ≥10 (per § Per-section batch write contract).
-- **Do NOT skip TaskUpdate per T-entry.** TaskUpdate is the audit trail under the per-section batched contract — reviewers track T-by-T progress there, not in per-T-entry file diffs. The audit trail must remain T-by-T even when the file diff collapses to one whole-section write.
+- **Do NOT run validation after every single Edit.** Validate at section boundaries, not per element.
+- **Do NOT use whole-file Write mid-section.** Whole-file Write between sibling elements inside a section bypasses the section-entry Read snapshot and risks silently dropping fields. Use Edit per element, OR collapse the entire section into one whole-section Write at section boundary when element count ≥10 (per § Per-section batch write contract).
+- **Do NOT skip TaskUpdate per element.** TaskUpdate is the audit trail under the per-section batched contract — reviewers track T-by-T progress there, not in per-element file diffs. The audit trail must remain T-by-T even when the file diff collapses to one whole-section write.
 - **Do NOT emit standalone text-only assistant turns between Edits.** Each costs ~5s inference + ~250K cache replay for zero work. Bundle status text into the same turn as the next tool_use (text block + tool_use block in one content array), or omit entirely — TaskUpdate already shows progress.
 
 ---

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

@@ -268,12 +268,26 @@ Free-floating annotation node. Ignored at execution time; surfaced only in the a
 
 All conditions share the same shape but attach at different levels. Per-level field tables and `--rule-type` semantics live in the corresponding condition plugin's `impl-json.md`.
 
+<a id="condition-name-uniqueness"></a>
+
+### Condition name uniqueness
+
+Every condition `displayName` must be unique across the **whole case**. One flat pool of literal strings spans all four scopes at once — stage `data.entryConditions[]`, stage `data.exitConditions[]`, task `entryConditions[]`, `metadata.caseExitRules[]` — so conditions in different stages, or different scopes, collide exactly like two in one array.
+
+`validate` enforces it as a hard **error**: `Rule name '<displayName>' is not unique`, reported once per node holding the name (`nodes[<stageId>]`, or `nodes[root]` for a case-exit rule). A name repeated in two stages errors on each, so a stage holding only one instance is still reported.
+
+The plugin defaults `Entry Rule {N}` / `Complete Rule {N}` / `Exit Rule {N}` share this pool with SDD-authored names. **Number them with a case-wide counter per label kind — highest existing number in the pool + 1 — never a per-array counter.** A per-array counter restarts at `1` in every stage and on every task, which is the usual cause of a collision.
+
+An SDD `Display Name` cell holding the default pattern (`Entry Rule <n>` etc.) is the SDD echoing the default: renumber it case-wide, which is not a divergence from the SDD. Only a **semantic** name repeated across stages is a planning defect — rename it in the SDD and re-emit.
+
+> **Never repair a collision by deleting a condition.** `validate` downgrades a task left with no entry rules to a warning (`CASE_MGMT_STAGE_TASK_ENTRY_CONDITION_MISSING`), so emptying `entryConditions[]` turns the build green while destroying authored behaviour — an `adhoc` task becomes unreachable, a gated task ungated. Always rename; never remove.
+
 ### EntryCondition (stage-level)
 
 | Field | Type | Description |
 |-------|------|-------------|
 | `id` | string? | Unique ID |
-| `displayName` | string? | Human-readable label |
+| `displayName` | string? | Human-readable label; unique across the **whole case** — see [Condition name uniqueness](#condition-name-uniqueness) |
 | `rules` | Rules | DNF rule set — see §4 |
 | `isInterrupting` | boolean? | Whether the condition interrupts the current stage |
 
@@ -282,7 +296,7 @@ All conditions share the same shape but attach at different levels. Per-level fi
 | Field | Type | Description |
 |-------|------|-------------|
 | `id` | string? | Unique ID |
-| `displayName` | string? | Human-readable label |
+| `displayName` | string? | Human-readable label; unique across the **whole case** — see [Condition name uniqueness](#condition-name-uniqueness) |
 | `rules` | Rules | DNF rule set — see §4 |
 | `type` | string? | `"exit-only"` \| `"wait-for-user"` \| `"return-to-origin"` |
 | `exitToStageId` | string? | Target stage ID when routing to a specific stage |
@@ -293,7 +307,7 @@ All conditions share the same shape but attach at different levels. Per-level fi
 | Field | Type | Description |
 |-------|------|-------------|
 | `id` | string? | Unique ID |
-| `displayName` | string? | Human-readable label |
+| `displayName` | string? | Human-readable label; unique across the **whole case** — see [Condition name uniqueness](#condition-name-uniqueness) |
 | `rules` | Rules | DNF rule set — see §4 |
 
 ### CaseExitCondition (case-level)