@uipath/skills 1.199.0 → 1.200.0

package/skills/uipath-maestro-bpmn/references/cli-conventions.md

@@ -19,11 +19,19 @@ All commands below are discovery/read-only. None mutate cloud state.
 | `uip maestro bpmn registry get <extensionType> [--connection-id <id>] [--object-name <name>]` | Get the full spec for one extension type: `xmlTemplate`, `contextFields`, `bindingInfo`, input/output patterns. `--connection-id`/`--object-name` add live Integration Service field metadata for `Intsvc.*` connector types. |
 | `uip is connections list --all-folders` | List live Integration Service connections (id + state) across all folders. Always pass `--all-folders`; a folder-scoped list silently misses connections. |
 
-These are the **only** commands the skill verifies against the CLI source
-(`packages/maestro-tool/src/commands/registry.ts`). Do not invent flags. In
-particular, there is **no** `uip maestro bpmn validate` command — see
-[Validation](structural-bpmn.md#validation). Validation is done with the bundled
-offline validator, not a CLI.
+These are the registry/discovery commands the skill verifies against the CLI
+source (`packages/maestro-tool/src/commands/registry.ts`). Do not invent flags.
+Validation uses `uip maestro bpmn validate <file>` — see
+[Validation](structural-bpmn.md#validation).
+
+The `validate` command runs the full PO.Frontend canvas rule set offline (it was
+added to the CLI in UiPath/cli#3135). If your CLI reports `validate` as an
+unknown command, or it clearly runs only the deploy-readiness checks and not the
+structural rules, the installed CLI predates that change — update to the latest:
+
+```bash
+npm install -g @uipath/cli@latest   # or: bun add -g @uipath/cli
+```
 
 > **Don't conclude "it doesn't exist" from truncated discovery output.** A row past a cutoff reads exactly like a missing row. Two cutoffs bite here: `registry list` defaults to **30** — pass `--limit -1` for the full set — and piping `registry search`/`is connections list` through `head`/`tail`/`grep -m`/a pager drops everything past the cap. To check existence, narrow the query (keyword to `registry search`, `--all-folders` to connection lists) rather than capping rows; cap only data already known complete.
 
@@ -35,7 +43,8 @@ manual and tell the user.
 
 ## Login boundary
 
-Local source authoring and the bundled validator work without login. Registry
+Local source authoring and `uip maestro bpmn validate` work without login (the
+validator runs fully offline). Registry
 discovery of **connectors and processes** (and Integration Service field
 enrichment) requires `uip login`. Without login, `registry pull` still returns
 the built-in (OOTB) extension types.

package/skills/uipath-maestro-bpmn/references/structural-bpmn.md

@@ -66,14 +66,14 @@ XML comments must not contain `--` (double-hyphen): it is invalid XML and the
 file will fail to parse. Never paste CLI commands or flags
 (`--output`, `--connection-id`) into `<!-- … -->`. Keep comments minimal.
 
-## A complete minimal file (author from this, not from fixtures)
+## A complete minimal file (author from this, not from examples)
 
 This is the whole shape — variables, an entry point, one node, a branch, and
 the diagram — in one valid file. Author from this skeleton plus the registry
-templates for your nodes. **Do not read the validator's `test/fixtures/` to
-infer the pattern**; those are validator test data, and reading them is the
-main reason authoring runs out of time. Swap the `scriptTask` payload for the
-registry `xmlTemplate` of whatever node you need.
+templates for your nodes. **Do not reverse-engineer the pattern from full
+example BPMN files** — it is the main reason authoring runs out of time. Swap
+the `scriptTask` payload for the registry `xmlTemplate` of whatever node you
+need.
 
 ```xml
 <?xml version="1.0" encoding="UTF-8"?>
@@ -511,23 +511,24 @@ Re-check after any edit:
 
 ## Validation
 
-There is **no** `uip maestro bpmn validate` CLI command. The skill ships its own
-offline validator that reconstructs the PO.Frontend Node/Edge/CanvasState model
-from the parsed BPMN and runs **every** canvas validation rule — run it as the
-primary check:
+Validate with the CLI — it runs the full PO.Frontend canvas rule set offline
+(the same Node/Edge/CanvasState reconstruction and every canvas rule), plus the
+deploy-readiness checks:
 
 ```bash
-cd skills/uipath-maestro-bpmn/validator && npm install --silent
-node validate-bpmn.mjs <file.bpmn>   # prints VALID and exits 0, or prints errors and exits 1
+uip maestro bpmn validate <file.bpmn> --output json
 ```
 
-`VALID` / exit 0 means the document passes all rules. Any other output lists the
-blocking errors (gateway/condition, fake-join, superfluous-gateway, error
-end/boundary event, timer-duration, single-blank-start, variable-reference, and
-IS-connector checks). See [validator/README.md](../validator/README.md).
+Exit 0 means the document passes all rules. Exit 1 lists the blocking errors,
+each with its rule code (gateway/condition, fake-join, superfluous-gateway,
+error end/boundary event, timer-duration/required-field, single-blank-start,
+single-conditional-outgoing-flow, variable-reference, method-parentheses,
+input-type, event-object, and IS-connector checks). Warnings are reported but do
+not block. If `validate` is unknown or runs only deploy-readiness checks, update
+the CLI — see [cli-conventions.md](cli-conventions.md#discovery-commands-read-only-authoring-safe).
 
-If Node is unavailable, fall back to a well-formed-XML parse plus the structural
-checklist below — it mirrors the same blocking rules:
+If the CLI is unavailable, fall back to a well-formed-XML parse plus the
+structural checklist below — it mirrors the same blocking rules:
 
 ```bash
 python3 -c "import xml.etree.ElementTree as ET; ET.parse('<file.bpmn>')"

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

@@ -1,14 +1,16 @@
 ---
 name: uipath-maestro-case
-description: "Always invoke for `caseplan.json` files. UiPath Case Management authoring (caseplan.json) from sdd.md, or via interview if sdd.md absent. Produces tasks.md plan, writes caseplan.json via per-plugin JSON recipes. Edits an existing caseplan.json via targeted operations (skips planning). For .xaml→uipath-rpa, .flow→uipath-maestro-flow, .bpmn→uipath-maestro-bpmn. For PDD→SDD or complex/multi-product→uipath-planner."
+description: "Always invoke for UiPath Maestro Case Management work: `caseplan.json`, `sdd.md`, `sdd.draft.md`, case-management SDD finalization, or greenfield case design when no SDD exists. 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 PDD→SDD or explicit cross-product planning, suggest `uipath-planner` in text only; never auto-invoke it."
 allowed-tools: Bash, Read, Write, Edit, Glob, Grep, AskUserQuestion, TodoWrite, Agent
 ---
 
 # UiPath Case Management Authoring Assistant
 
-Builds UiPath Case Management definitions from `sdd.md`. Generates `tasks.md` plan, then writes `caseplan.json` directly via per-plugin JSON recipes. CLI is reserved for read-only metadata fetches (registry, validate, debug, tasks describe, case spec) and solution boundary operations (`uip solution init` / `project add` / `upload`).
+Builds UiPath Case Management definitions from `sdd.md`. Generates `tasks.md` plan, then writes `caseplan.json` directly via per-plugin JSON recipes.
 
-When `sdd.md` is absent, **Phase 0** designs the case by best assumption from the request and documents, confirms it in ONE summary that discloses every decision taken, then starts the build with `sdd.md` written alongside as a reference artifact. Complex / multi-product cases may still be designed with the same workflow; use `uipath-planner` when the user explicitly requests planning across products.
+> **Authoring invariant:** Never use mutating `uip maestro case` commands (`cases|stages|tasks|*-conditions ... add|update|remove`, including `tasks add-connector`) or explore them via `--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 does not override this rule.
+
+When `sdd.md` is absent, **Phase 0** designs the case by best assumption from the request and documents, sweeps for other paths beyond the primary flow, and confirms it in ONE decision-first Case Review: case snapshot, primary journey, other paths, SLA responses, business rules/outcomes, resources, decisions, and review flags. The approval surface names every stage and task but omits data, variables, and task inputs/outputs; the template-complete `sdd.md` retains that technical detail and is written alongside the build as a reference artifact. When `sdd.draft.md` is present and the user asks to finalize it, stay in this skill: read the draft as the settled case design, normalize it to the Case Management SDD template, and do not hand off to `uipath-planner`. Complex / multi-product cases may still be designed with the same workflow; suggest `uipath-planner` only when the user explicitly requests planning across products.
 
 **Scope:** two journeys — **greenfield** (build a new case from `sdd.md`, user-provided or Phase 0-generated) and **brownfield** (targeted edits to an existing `caseplan.json` — see [references/brownfield.md](references/brownfield.md)). Editing a case that also lives in Studio Web? Brownfield pulls the current server state first (`uip solution download` / `solution projects resync`) so re-publish can't silently clobber server-side changes — see [brownfield.md § Pull latest first](references/brownfield.md#pull-latest-first-before-editing).
 
@@ -26,26 +28,29 @@ When `sdd.md` is absent, **Phase 0** designs the case by best assumption from th
 
 ## Critical Rules
 
-1. **Phase 0 best-assumption design when `sdd.md` absent.** Listen and ground, then decide every open field per the assumption playbook — inform, don't interrogate: every assumption, override, and resource decision is disclosed in the single confirmation's `Decisions I made` block. Question budget: one clarifying call (only for an empty request or contradictory inputs) plus ONE confirmation ([phase-0-interview.md § Confirm](references/phase-0-interview.md#confirm--the-single-checkpoint)). On a Build answer, render `sdd.md` from the in-memory model batched with the first build actions — a reference artifact, never a review gate; the session builds from memory. Explicit sign-off requests add one approval prompt; design-only requests save `sdd.md` and stop; draft requests save `sdd.draft.md` and stop. Never overwrite an existing `sdd.md`.
+1. **Phase 0 best-assumption design when `sdd.md` absent.** Listen and ground, then decide every open field per the assumption playbook — inform, don't interrogate: every assumption, override, and resource decision is disclosed in the single confirmation's `Decisions I Made` table. The confirmation is a decision-first **Case Review** with exactly eight sections: Case Snapshot, Primary Journey, Other Paths Considered, SLA and Escalations, Rules and Outcomes, Resources and Integrations, Decisions I Made, and Review Flags. It names every stage and task with task type, activation/grouping, required status, routing/outcome, and SLA context; it deliberately omits the data contract, variables, and task inputs/outputs, which remain complete in `sdd.md`. It must be complete enough to approve the business behavior without opening `sdd.md`; do not defer a missing business decision by saying it will be in the document. This structured Case Review is the only valid plan-first approval surface for Phase 0; a generic "Build Plan" / "Approve this plan" checkpoint does not count, and a user "Yes" to that checkpoint is not a Build answer. Question budget: one clarifying call (only for an empty request, contradictory inputs, user-requested questions, or no source signal for other paths) plus ONE confirmation ([phase-0-interview.md § Confirm](references/phase-0-interview.md#confirm--the-single-checkpoint)). If `sdd.draft.md` exists and the user asks to finalize it, use the direct draft-resumption path in this skill: read the draft and SDD template, render the final `sdd.md` from the Case Management template, do not spawn subagents, do not preload planning/plugin references, and never delegate to `uipath-planner`. **Direct finalization repairs schema-required companion rules as row replacements, not extra routes: for an authored `user-selected-stage`, replace each eligible origin's existing `required-tasks-completed | exit-only | Yes` row with the single row `required-tasks-completed | wait-for-user | Yes`; never retain the old completion row or add a `Marks Stage Complete: No` duplicate.** `wait-for-user` exposes the picker; it does not add automatic event/SLA/decision routing. On a Build answer, render `sdd.md` from the in-memory model batched with the first build actions — the file MUST pass the template-conformance gate in `phase-0-interview.md`; a summary SDD is invalid even if `caseplan.json` later validates. Explicit sign-off requests add one approval prompt; design-only requests save `sdd.md` and stop; draft requests save `sdd.draft.md` and stop. When the prompt explicitly says to get/save a draft and stop, that request is already the save instruction: show the Case Review, write `sdd.draft.md`, and stop without asking for another approval. When the prompt explicitly asks to produce `sdd.md` plus `tasks/tasks.md` and stop before `caseplan.json`, use the bounded no-build fast path in `phase-0-interview.md`: after the Case Review, write the full-template `sdd.md`, create `tasks/`, write compact `tasks/tasks.md`, and stop; do not read planning/plugin references, tenant discovery sources, or the full SDD finalization checklist. Never overwrite an existing `sdd.md`.
 2. **sdd.md is sole input post-Phase-0 — across sessions.** When user-provided, or in any later session, re-run, or staleness recovery (context compaction), trust `sdd.md` as written; the skill does not validate or gap-fill it. Within the session that just confirmed the design, the in-memory model that rendered `sdd.md` is the same content and drives the build directly ([phase-0-interview.md § Build start](references/phase-0-interview.md#build-start--sdd-written-alongside-the-build)) — do not re-read the just-written file. If a build-phase ambiguity arises, use AskUserQuestion — never infer silently.
-3. **PHASE 1 HARD GATE — fresh registry before planning, pulled at most once per session.** Run `uip login status --output json`, then `uip maestro case registry pull`, before cache inspection, carryover reuse, resource resolution, or any Phase 1 artifact write — **same-session fast path:** when Phase 0's pull already succeeded in THIS session and `sdd.md` was just rendered from the confirmed in-memory model, reuse that cache and skip the re-pull. Any doubt runs the gate in full: user-provided SDD, cross-session resume, context compaction, a Phase 0 pull that failed or never ran, or missing cache files. Trust the SDD as written; the pull refreshes the local discovery cache and does not validate or override the SDD. **Cache-state rule:** before a successful pull (this session), a missing cache directory/file is a failed refresh precondition — never a zero-match result. Only after a successful pull may an empty exact-name match set (or a still-absent type index) enter the normal empty-lookup flow. Login/pull failure → surface it and stop Phase 1. Discovery reads `~/.uip/case-resources/<type>-index.json` directly because `registry search` has known gaps (esp. action-apps). Phase 0 pulls lazily: the same login/pull chain starts in the background only when the case first shows tenant-bound work, followed by one light name-match pass — no schema discovery, no resource prompts; unclear items defer to this gate as `resolve at build`. See [references/registry-discovery.md](references/registry-discovery.md).
+3. **PHASE 1 HARD GATE — fresh registry before planning, pulled at most once per session.** Run `uip login status --output json`, then `uip maestro case registry pull`, before cache inspection, carryover reuse, resource resolution, or any Phase 1 artifact write — **same-session fast path:** when Phase 0's pull already succeeded in THIS session and `sdd.md` was just rendered from the confirmed in-memory model, reuse that cache and skip the re-pull. Any doubt runs the gate in full: user-provided SDD, cross-session resume, context compaction, a Phase 0 pull that failed or never ran, or missing cache files. **Plan-only exception:** if the user explicitly asks to stop at `sdd.md`/`sdd.draft.md`/`tasks.md` and not create `caseplan.json`, do not run tenant registry, connection, schema, or user-discovery commands; preserve concrete intended resource/system names, mark identities `resolve at build`, and report that resource wiring is deferred to the later build run. Trust the SDD as written; the pull refreshes the local discovery cache and does not validate or override the SDD. **Cache-state rule:** before a successful pull (this session), a missing cache directory/file is a failed refresh precondition — never a zero-match result. Only after a successful pull may an empty exact-name match set (or a still-absent type index) enter the normal empty-lookup flow. Login/pull failure → surface it and stop Phase 1. Discovery reads `~/.uip/case-resources/<type>-index.json` directly because `registry search` has known gaps (esp. action-apps). Phase 0 pulls lazily only for build runs: the same login/pull chain starts in the background only when the case first shows tenant-bound work and a later build may need identities, followed by one light name-match pass — no schema discovery, no resource prompts; unclear items defer to this gate as `resolve at build`. See [references/registry-discovery.md](references/registry-discovery.md).
 4. **`--output json` on every parsed read.**
 5. **Follow plugin per node type.** Open matching `planning.md` during planning + `impl-json.md` during execution. Never guess JSON shapes from memory.
-6. **`tasks.md` declarative and lossless only.** No shell commands inside. Field names use plain identifiers (e.g., `type:`, `displayName:`, `lane:`), not CLI flag syntax. One T-entry per sdd.md declaration — every stage, task, trigger, condition, SLA rule, **variable, and argument** gets own T-number, even when value looks like default (`current-stage-entered`, `case-entered`, `exit-only`, `is-interrupting: false`, `runOnlyOnce: true`, `marks-stage-complete: true`). Never group, never silently omit. Preserve every SDD Inputs row with its declared binding mode and value. A JSON object literal stays literal through both handoffs: record the exact JSON in `tasks.md`, then write either the native object or its JSON-encoded string to `input.value`; never add `=js:` or `=jsonString:` unless the SDD itself explicitly uses that prefix. Project every task/rule Outputs table row through the common grammar in [`plugins/variables/io-binding/planning.md`](references/plugins/variables/io-binding/planning.md#sdd-table-to-tasksmd-projection-mandatory), then preserve each resulting `outputs:` item **with its operator and both operands unchanged**. SDD Outputs rows require `->` or `=`; a bare `tasks.md` output is generated only from resolved-schema discovery and is never authored as an SDD row. SDD table placeholders such as a `—` Field are not operands and never appear in `tasks.md`. In particular, `greeting -> greeting` is NOT equivalent to schema-discovered bare `greeting`: the former extracts into the predeclared case variable and requires `originalVar`; the latter auto-mints a task-local output. Never simplify an equal-name `->` row. **When an sdd.md row's format is unrecognized, ambiguous, or cannot be categorized — invoke AskUserQuestion before skipping. Silent omission is forbidden.** Always regenerate from scratch (greenfield/planning only — brownfield targeted edits mutate in place and preserve IDs; see [references/brownfield.md](references/brownfield.md)). See [`references/planning.md` §4.0](references/planning.md).
+6. **`tasks.md` declarative and lossless only.** No shell commands inside. Field names use plain identifiers (e.g., `type:`, `displayName:`, `lane:`), not CLI flag syntax. One T-entry per sdd.md declaration — every stage, task, trigger, condition, SLA rule, **variable, and argument** gets own T-number, even when value looks like default (`current-stage-entered`, `case-entered`, `exit-only`, `is-interrupting: false`, `runOnlyOnce: true`, `marks-stage-complete: true`). Never group, never silently omit. **An explicit stage/task entry or exit rule in a supplied or approved SDD is authoritative: planning and implementation preserve that exact rule and its selectors, even when a different rule would normally be inferred from task proximity or list order.** Preserve every stage/task/SLA `Design Rationale` and condition routing/activation rationale as `rationale:` on the matching T-entry; rationale is reviewer/audit context and never changes the executable JSON shape. Preserve every SDD Inputs row with its declared binding mode and value. A JSON object literal stays literal through both handoffs: record the exact JSON in `tasks.md`, then write either the native object or its JSON-encoded string to `input.value`; never add `=js:` or `=jsonString:` unless the SDD itself explicitly uses that prefix. Project every task/rule Outputs table row through the common grammar in [`plugins/variables/io-binding/planning.md`](references/plugins/variables/io-binding/planning.md#sdd-outputs-table-to-tasksmd-projection-mandatory), then preserve each resulting `outputs:` item **with its operator and both operands unchanged**. SDD Outputs rows require `->` or `=`; a bare `tasks.md` output is generated only from resolved-schema discovery and is never authored as an SDD row. SDD table placeholders such as a `—` Field are not operands and never appear in `tasks.md`. In particular, `greeting -> greeting` is NOT equivalent to schema-discovered bare `greeting`: the former extracts into the predeclared case variable and requires `originalVar`; the latter auto-mints a task-local output. Never simplify an equal-name `->` row. **When an sdd.md row's format is unrecognized, ambiguous, or cannot be categorized — invoke AskUserQuestion before skipping. Silent omission is forbidden.** Always regenerate from scratch (greenfield/planning only — brownfield targeted edits mutate in place and preserve IDs; see [references/brownfield.md](references/brownfield.md)). **Every §4.6 task T-entry carries its own `activation-mode:` and `entry-rule:` lines — a separate §4.7 `rule-type:` entry does not satisfy this.** **Every task T-entry heading quotes the task's display name** in the exact form `## T<n>: Add <type> task "<name>" to "<stage>"` (e.g. `## T08: Add wait-for-timer task "First Step" to "Process"`) — an unquoted or reworded heading (e.g. `## T08: Task First Step`) breaks plan addressability and fails plan validators even when `caseplan.json` itself is correct. 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. **`tasks.md` gate — auto-approved by default, opt-in stop.** Phase 1 auto-proceeds into Phase 2 Prototyping with no AskUserQuestion sign-off; treat the plan as approved. **Stop after `tasks.md` only when the request explicitly asked for a plan-only / review-first run** (e.g. "just the plan", "Phase 1 only", "stop after tasks.md for review", "don't build the case yet") — then report the plan and do NOT proceed to Phase 2. Re-read `tasks.md` before executing.
-8. **Unresolved resource → placeholder, never fabricate IDs.** Keep `<UNRESOLVED: ...>` markers in `tasks.md`. Placeholder **task**: node with `type` + `displayName` + structural fields, `data: {}`; conditions still reference the TaskId. Placeholder **event trigger**: node with render fields + `data.uipath: { serviceType: "Intsvc.EventTrigger" }` only (no other `data.uipath` keys); `entry-points.json` entry appended. No trigger-edge is created (Rule 20). See [references/placeholder-tasks.md](references/placeholder-tasks.md) and [references/plugins/triggers/event/impl-json.md § Placeholder fallback](references/plugins/triggers/event/impl-json.md).
+8. **Unresolved resource → placeholder, never fabricate IDs.** Keep `<UNRESOLVED: ...>` markers in `tasks.md`. Placeholder **task**: node with `type` + `displayName` + structural fields, `data: {}`; conditions still reference the TaskId. Placeholder **event trigger**: node with render fields + `data.inputs: { serviceType: "Intsvc.EventTrigger" }` only (no other `data.inputs` keys); `entry-points.json` entry appended. No trigger-edge is created (Rule 20). See [references/placeholder-tasks.md](references/placeholder-tasks.md) and [references/plugins/triggers/event/impl-json.md § Placeholder fallback](references/plugins/triggers/event/impl-json.md).
 9. **Persist every registry resolution to `registry-resolved.json`** — one object per task with exact keys `stage`, `task`, `taskType`, `cacheFile`, `searchQuery`, `matches`, `selected`, and `rationale` (plus resolved I/O/review metadata when applicable). `stage` + `task` associate the audit entry to one SDD declaration; `cacheFile` is the basename actually searched; `matches` is the full exact-name match set from the cache refreshed in Rule 3, not a summary. Use the authoritative SDD fields as the search and selection contract; record `selected` from that match set, or `null` after a genuine empty lookup.
 10. **Cross-task refs:** plan as `"Stage Name"."Task Name".output_name`. Resolve both whole-value `<-` and in-expression `$xref` through 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, which intentionally has no `.id`, resolves through its verified root companion's `.id`. Never use a reassigned output's `.var` as the source reference ID — it points at the target Case variable and can differ from the collision-safe source `.id`. Discover output names via `uip maestro case spec` (connector tasks) or `uip maestro case tasks describe` (non-connector tasks) — never fabricate. **Inside** a larger `=js:` expression (composite payload, condition, SLA), use the in-expression marker `vars.$xref('Stage','Task','output')` instead — resolved at Step 11.5. See [references/bindings-and-expressions.md](references/bindings-and-expressions.md) and [`plugins/variables/io-binding/impl-json.md`](references/plugins/variables/io-binding/impl-json.md).
-11. **Build-review preference decides the Phase 2 → Phase 3 boundary — captured ONCE, up front, never asked mid-build.** Capture it at journey start: greenfield-with-interview folds it into the single confirmation's Build options (`Build it — straight through` / `Build it — pause at the build preview` — [phase-0-interview.md § Confirm](references/phase-0-interview.md#confirm--the-single-checkpoint)); greenfield-with-provided-SDD asks it once right after the roadmap; non-interactive runs and resumed runs with no recorded preference default to **straight-through** (no mid-build publish — Phase 6 stays the only publish point and stays gated). At the boundary, always run `validate --skeleton` (structural checks only) and print the counts summary — advisory, never halt on its errors. Then: **straight-through** → continue into Phase 3 with no prompt, the summary line doubling as the milestone narration; **pause-at-preview** → follow the publish-for-review contract in [`references/phased-execution.md`](references/phased-execution.md) (AskUserQuestion `Publish for review` / `Skip publish and continue` / `Abort`; on publish, print `DesignerUrl` as plain text BEFORE the follow-up prompt — never only inside the question body). Hard stops that are NEVER bypassed regardless of preference: Phase 4 retry exhaustion (`Retry with fix` / `Pause for manual edit` / `Abort`), Phase 5 entry (`Run debug session` / `Skip to Publish`), and Phase 6 entry (`Publish to Studio Web` / `Done`). Full contract in [`references/phased-execution.md`](references/phased-execution.md).
+11. **Build-review preference decides the Phase 2 → Phase 3 boundary — captured ONCE, up front, never asked mid-build.** Capture it at journey start: greenfield-with-interview folds it into the single confirmation's Build options (`Build it — straight through` / `Build it — pause at the build preview` — [phase-0-interview.md § Confirm](references/phase-0-interview.md#confirm--the-single-checkpoint)); greenfield-with-provided-SDD asks it once right after the roadmap; non-interactive runs and resumed runs with no recorded preference default to **straight-through** (no mid-build publish — Phase 5 stays the only publish point and stays gated). At the boundary, try `validate --skeleton-v2` first; fall back once to legacy `--skeleton` **only** when the parser response names `--skeleton-v2` as unknown or unsupported (typically `ErrorCode: invalid_argument` and exit 3). Exit 3 alone is not enough. A genuine validation failure means v2 ran — report it and do not hide it with a fallback. Name the selected profile in the counts summary; the gate is advisory and never halts on validation findings. Then: **straight-through** → continue into Phase 3 with no prompt, the summary line doubling as the milestone narration; **pause-at-preview** → follow the publish-for-review contract in [`references/phased-execution.md`](references/phased-execution.md) (AskUserQuestion `Publish for review` / `Skip publish and continue` / `Abort`; on publish, print `DesignerUrl` as plain text BEFORE the follow-up prompt — never only inside the question body). Hard stops that are NEVER bypassed regardless of preference: Phase 4 retry exhaustion (`Retry with fix` / `Pause for manual edit` / `Abort`), Phase 5 entry (`Publish to Studio Web` / `Skip to Debug`), and Phase 6 entry (`Run debug session` / `Done`). Full contract in [`references/phased-execution.md`](references/phased-execution.md).
 12. **Never run `uip maestro case debug` automatically.** Executes case for real — emails, messages, API calls. Explicit user consent only.
-13. **All skill artifacts: Read + Write/Edit only.** Applies to `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`, `build-issues.md`. No `python`, `node`, `jq`, `sed`, `awk`, or scripts that open/parse/modify/save these files. **Specifically forbidden** (common slip): `node -e "...fs.writeFileSync..."`, `node -e "...fs.readFileSync..."`, `node -e "..." > <artifact>`, `jq '...' <artifact> > <artifact>`, `python -c "...open(...,'w')..."`, `sed -i`, `awk -i inplace`, or any shell redirection (`>`, `>>`, `| tee`) onto a skill artifact regardless of interpreter. **Writing a helper script under `/tmp` or anywhere else to assemble a skill artifact is also forbidden** — the build-assembler pattern (`/tmp/build-caseplan.js`, `/tmp/gen-tasks.py`, etc.) is the same Rule 13 violation as inline `node -e`, regardless of "mechanical copy" or "avoid Read+Write churn" framing. If `caseplan.json` exceeds ~30KB and a single Write feels too large, split into the Phase-2-skeleton-then-Phase-3-fill cadence (per [case-editing-operations.md § Per-section batch write contract](references/case-editing-operations.md#per-section-batch-write-contract--canonical)) — never via helper script. **The `node -e ... fs.*` ban is not scoped to the artifact list — it applies to ALL file reads in this skill, including resource cache reads from `~/.uip/case-resources/`. Use `cat ... | python3 -c "..."` or the `Read` tool for cache lookups.** Bash subprocesses OK ONLY for UUID v4 generation (`node -e "console.log(crypto.randomUUID())"` for `operate.json.projectId` and `entry-points.json` `uniqueId` — subprocess MUST NOT `require('fs')` or use redirection), CLI metadata fetches, validate, debug, and solution scaffold/upload. **Prefixed IDs (`Stage_`, `t`, `Rule_`, etc.) are picked inline by the agent — no subprocess.** See [references/case-editing-operations.md § Tool usage](references/case-editing-operations.md#tool-usage--mandatory).
-14. **Bindings sidecar parity is an unconditional Phase 3 exit check.** Before Phase 4, run Step 12 Check 7 even when publish, debug, and `uip solution resources refresh` are skipped. Compare `bindings_v2.json.resources[]` with the complete projection of top-level `caseplan.json.bindings[]`; on mismatch, regenerate once and re-check, then halt if it still differs. Repeat Check 7 before every `resources refresh`. Always run `resources refresh` before `uip solution upload` or `uip maestro case debug` so Studio Web can resolve dependencies.
+13. **All skill artifacts: Read + Write/Edit only.** Applies to `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`, `build-issues.md`. No `python`, `node`, `jq`, `sed`, `awk`, or scripts that open/parse/modify/save these files. **Shell filesystem commands may not create, replace, rename, or relocate an artifact** — `cp`, `mv`, `install`, and `rsync` are forbidden for these files, including copying or renaming `sdd.draft.md` to `sdd.md`. **Specifically forbidden** (common slip): `node -e "...fs.writeFileSync..."`, `node -e "...fs.readFileSync..."`, `node -e "..." > <artifact>`, `jq '...' <artifact> > <artifact>`, `python -c "...open(...,'w')..."`, `sed -i`, `awk -i inplace`, or any shell redirection (`>`, `>>`, `| tee`) onto a skill artifact regardless of interpreter. **Writing a helper script under `/tmp` or anywhere else to assemble a skill artifact is also forbidden** — the build-assembler pattern (`/tmp/build-caseplan.js`, `/tmp/gen-tasks.py`, etc.) is the same Rule 13 violation as inline `node -e`, regardless of "mechanical copy" or "avoid Read+Write churn" framing. If `caseplan.json` exceeds ~30KB and a single Write feels too large, split into the Phase-2-preview-then-Phase-3-detail cadence (per [case-editing-operations.md § Per-section batch write contract](references/case-editing-operations.md#per-section-batch-write-contract--canonical)) — never via helper script. **The `node -e ... fs.*` ban is not scoped to the artifact list — it applies to ALL file reads in this skill, including resource cache reads from `~/.uip/case-resources/`. Use `cat ... | python3 -c "..."` or the `Read` tool for cache lookups.** Bash subprocesses OK ONLY for UUID v4 generation (`node -e "console.log(crypto.randomUUID())"` for `operate.json.projectId` and `entry-points.json` `uniqueId` — subprocess MUST NOT `require('fs')` or use redirection), CLI metadata fetches, validate, debug, and solution scaffold/upload. **Prefixed IDs (`Stage_`, `t`, `Rule_`, etc.) are picked inline by the agent — no subprocess.** See [references/case-editing-operations.md § Tool usage](references/case-editing-operations.md#tool-usage--mandatory).
+14. **Resolved resources must be runnable, and sidecar parity is an unconditional Phase 3 exit check.** Before Phase 4, run Step 12 Checks 7, 9, and 11 even when publish, debug, and `uip solution resources refresh` are skipped. A task with a non-null `selected` entry in `tasks/registry-resolved.json` MUST NOT be emitted as a placeholder: it must remain present with `data.name` and `data.folderPath` bound to complete root bindings, its resource must project into `bindings_v2.json.resources[]`, and its binding pair's `resourceKey` must be self-consistent with its own `name`/`folderPath` defaults (Check 11) — never a copied tenant identity/UUID. `uip maestro case validate` success does not substitute for these checks. On a mismatch, repair the named task/binding or regenerate the sidecar once as applicable, then re-check; halt before Phase 4 if any of these checks still fails. Repeat Check 7 before every `resources refresh`. Always run `resources refresh` before `uip solution upload` or `uip maestro case debug` so Studio Web can resolve dependencies. Every `uip solution upload` call MUST carry `--output-filter "{Status: Status, SolutionId: SolutionId, DesignerUrl: DesignerUrl}"` — the unfiltered response gets truncated and `DesignerUrl` is lost.
 15. **Never auto-invoke `uipath-planner`.** If the user asks for planning across products, print a plain-text suggestion of the skill name; the user re-invokes it manually. No tool-call cross-skill handoff.
 16. **Caseplan task `type` enum is closed — 9 values, schema-kebab.** Any task node written into `caseplan.json` MUST have `type` exactly one of: `process` | `agent` | `rpa` | `action` | `api-workflow` | `case-management` | `execute-connector-activity` | `wait-for-connector` | `wait-for-timer`. **Never** write the plugin folder name (`connector-activity`, `connector-trigger`) or the CLI `--type` flag value into the JSON node — those name the planning artifacts, not the schema. Never write `external-agent`, `external-workflow`, `document-extraction`, `flow-process`, `wait-for-event`, or any hallucinated value — there is no plugin to back them. `external-agent`, `external-workflow`, `document-extraction`, and `flow-process` are **not supported yet**. See [references/case-schema.md § Task type](references/case-schema.md) and the Plugin Index naming-asymmetry table below.
 17. **Empty registry lookup → AskUserQuestion BEFORE any placeholder fallback.** When a planning-phase lookup returns 0 matches, present AskUserQuestion per lookup-batch (one prompt, not per-task) BEFORE any placeholder T-entry or per-plugin Unresolved Fallback, with options: (a) `Force pull and re-resolve` — loops back for still-empty; (b) `Use placeholders for all`; (c) `Create missing resources inline` — shown ONLY when ≥1 still-empty is creatable (an `agent` or an `api-workflow`) AND the CLI supports `registry --local`. **Create covers agents and API workflows only, gate-selected only** (never from SDD content alone; agent → `uipath-agents`, api-workflow → `uipath-api-workflow`); unselected + non-creatable empties (regular RPA process, action, case-management, connectors, agentic processes) → placeholder; the option is suppressed when `--local` is absent. Do NOT pre-judge via resource-name heuristics — the user's call. The gate and Select **group empties by `(name, type)`** (one row per resource, usages listed — non-creatable ones show only at the gate, annotated `placeholder only`); create-selected resources merge or split at [registry-discovery § 1c](references/registry-discovery.md#1c--dedup-the-selected-builds-one-resource-per-name-and-type) by I/O (identical-I/O usages → one build; differing → later renamed, anchor keeps the name; the SDD cell is updated only with user permission — never non-interactively). Placeholder fallback is valid only after `Use placeholders for all`. Build/register/verify mechanics live in [references/registry-discovery.md § Create-on-Missing](references/registry-discovery.md#create-on-missing-build-and-rediscovery) (gate detail: [§ MUST Confirm](references/registry-discovery.md#must-confirm-before-placeholder-fallback)).
 18. **Layout state lives in top-level `layout`, not on the node/edge.** Do NOT emit node-level `position`, `style`, `measured`, `width`, `height`, `zIndex`. Do NOT compute stage `position.x = 100 + count * 500`. Do NOT emit edge `data.waypoints`. Emit top-level `layout: {}` (empty object) — FE auto-layouts on canvas load. The frontend's `transformCaseInMemoryJsonToDiskJson` strips these fields anyway when round-tripping through canvas; emitting them is harmless on read but wastes tokens. See [`references/case-editing-operations.md`](references/case-editing-operations.md).
 19. **Generated output IDs use one global namespace.** Run [Step 12 Check 8](references/implementation.md#step-12--end-of-phase-3-validator-pass) once at Phase 3 exit; it is the mandatory uniqueness check. Do not enter Phase 4 until it passes, and do not substitute `uip maestro case validate` for it.
 20. **Edges retired — `schema.edges` stays `[]`.** Never author a `TriggerEdge`/`Edge` object, for any node. Stage-to-stage flow is condition-driven (target stage's `entryConditions`, plus source `exitConditions` when it diverges); case start is the first stage's `case-entered` entry condition, not a Trigger→stage edge. FE auto-derives canvas connectors from conditions. Edge shapes exist only as a read-only appendix in [references/case-schema.md § Appendix](references/case-schema.md#appendix--edge-shapes-read-only--never-author) for reading canvas-round-tripped files.
+21. **Global events are modeled once; SLA responses are chosen, not assumed.** An external event that may happen during any active stage and requires case work/routing belongs on the destination secondary stage as one interrupting `wait-for-connector` entry rule. For SLA, pick the response from the source: `notify-only` (escalation action, no stage/task), `start-task` (a follow-up task inside the breached stage carries `sla-status-change` on **its own task entry**, against that stage's own SLA — never a stage-entry row, which would re-enter the stage and re-run its other tasks), `enter-stage` (a separate stage carries the entry), `exit-stage`, or `exit-case`. A case-level graph response enters a separate stage; a stage-level response may start a task in the breached stage or route to another. Interrupting is set by whether the response stops, pauses, or reroutes active work — not by the SLA's scope; a `start-task` task entry interrupts nothing. `sla-status-change` always names the SLA (→ `slaId`); it names an at-risk escalation (→ `escalationId`) **only** for an at-risk response — a breach references the SLA alone, and adding an escalation silently converts it to at-risk. Absent a stated response, at-risk and breached are notifications. Do not duplicate a task or exit rule on every primary stage. Full contract — response choice, persisted status shapes, where the rule lives, interrupting, and the four defects `validate` cannot see — in [references/sla-response-shapes.md](references/sla-response-shapes.md); SDD rendering in the SLA Response Map.
+22. **Formal-arg slot ids are minted, never copied from the companion name.** `variables.inputs[].id` / `variables.outputs[].id` MUST be a synthetic `v`+8-chars id (e.g. `vK3mNp9Qx`), distinct from the human-readable `name`/`var` — copying the companion's readable name into the formal slot (e.g. `id: "applicantName"`) passes `uip maestro case validate` but is wrong. Run [Step 12 Check 10](references/implementation.md#step-12--end-of-phase-3-validator-pass) once at Phase 3 exit; it is the mandatory format check and non-interactively re-mints any violation. Do not enter Phase 4 until it passes, and do not substitute `uip maestro case validate` for it — validate does not check this format. 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 forks the solution.** It scaffolds the same 5 files as the T01 direct-JSON recipe, but run anywhere outside an already-existing `<SolutionDir>` (the common case — no solution exists yet) it auto-creates a **second, separate solution** named `<ProjectName>Solution` (`<ProjectName>Solution/<ProjectName>Solution.uipx`), nesting the project at `<ProjectName>Solution/<ProjectName>/` instead of inside the one `<SolutionDir>` the SDD/Step 6.0 already established (`<SolutionDir>/<ProjectName>/`). The case project and any Phase-1-created sibling resources (e.g. an inline-built agent) then register in two different `.uipx` manifests instead of one, so the case cannot resolve its own sibling at runtime — the resulting `File not found` only surfaces later, at validate. Always use Step 6 instead: `uip solution init <SolutionName>` (CLI) then the T01 direct-JSON scaffold. See [implementation.md § Step 6](references/implementation.md#step-6--create-the-case-project-structure) and [case-commands.md § uip maestro case init](references/case-commands.md#uip-maestro-case-init).
 
 ## Routing — greenfield vs brownfield
 
@@ -62,7 +67,7 @@ After routing and before detailed questions or build work, print one short roadm
 
 | Journey | Roadmap shown to the user |
 |---|---|
-| New case without an SDD | `1. I read your request and make the design calls, checking your UiPath tenant along the way. 2. One summary: the whole case plus every decision I made — you confirm or correct. 3. Build and validate without interruptions; the design doc is saved alongside for reference. 4. Pause for your call before any run or publish.` |
+| New case without an SDD | `1. I read your request and make the design calls, checking your UiPath tenant along the way. 2. One review packet: case snapshot, primary journey, other paths, SLA responses, business rules, resources, and every decision I made — you confirm or correct. 3. Build and validate without interruptions; the full technical design doc is saved alongside for reference. 4. Pause for your call before any run or publish.` |
 | New case with an SDD | `1. Read the design and verify available UiPath resources. 2. One question: build straight through, or pause at a mid-build preview. 3. Plan, build, and validate without further interruptions. 4. Pause for your call before any run or publish.` |
 | Targeted edit to an existing case | `1. Pull the latest case. 2. Apply the requested change. 3. Validate the updated case. 4. Ask before running or publishing anything.` |
 
@@ -70,7 +75,7 @@ Keep the roadmap to five lines or fewer. Print it once per invocation; do not re
 
 ## Workflow
 
-Decisions are front-loaded; the build runs unattended to the debug gate. **Phase 0** (best-assumption design → one confirmation, only when sdd.md absent; the Build answer is the consent — `sdd.md` renders alongside the first build actions, and an extra approval prompt exists only for explicit sign-off requests) → **Phase 1 Planning** (auto-proceed from the in-memory model; stop for review only when the request asks) → **Phase 2 Prototyping** (placeholder; Phase 2 → 3 pauses only when the up-front build-review preference chose the preview — Rule 11) → **Phase 3 Implementation** (no stop) → **Phase 4 Validate** (retry-cap stop on 3rd failure) → **Phase 5 Debug** (Run vs Skip-to-Publish stop — never bypassed) → **Phase 6 Publish** (Publish vs Done stop — never bypassed).
+Decisions are front-loaded; the build runs unattended to the publish gate. **Phase 0** (best-assumption design → one confirmation, only when sdd.md absent; the Build answer is the consent — `sdd.md` renders alongside the first build actions, and an extra approval prompt exists only for explicit sign-off requests) → **Phase 1 Planning** (auto-proceed from the in-memory model; stop for review only when the request asks) → **Phase 2 Prototyping** (reviewable flow + SLA preview; Phase 2 → 3 pauses only when the up-front build-review preference chose the preview — Rule 11) → **Phase 3 Implementation** (no stop) → **Phase 4 Validate** (retry-cap stop on 3rd failure) → **Phase 5 Publish** (Publish vs Skip-to-Debug stop — never bypassed) → **Phase 6 Debug** (Run vs Done stop — never bypassed).
 
 ### Kickoff — set dev expectations first
 
@@ -80,23 +85,23 @@ Before any planning or build work, present the flow once so the dev knows the st
 
 > Here's how I'll build this case, and where I'll stop for your call:
 > - **Planning** — I draft a task plan from the spec and continue; ask up front if you want to review it first.
-> - **Prototyping** — I build the case skeleton (stages, tasks, triggers — no wiring yet). Whether I pause here for a Studio Web preview is **your up-front call** — asked once at the start, never mid-build.
-> - **Implementation** — I wire task inputs/outputs, conditions, and SLAs.
+> - **Prototyping** — I build the reviewable case flow (stages, tasks, triggers, rules, SLA/escalation; connector rules use stubs). Whether I pause here for a Studio Web preview is **your up-front call** — asked once at the start, never mid-build.
+> - **Implementation** — I wire task inputs/outputs, connector schemas, and resolved connector-rule details.
 > - **Validate** — I run validation and fix errors.
-> - **Debug** (optional) — **you choose** whether to run the case for real (live emails / API calls).
 > - **Publish** (optional) — **you choose** whether to upload to Studio Web.
+> - **Debug** (optional) — **you choose** whether to run the case for real (live emails / API calls).
 
-When Phase 0 runs, prefix one line: "First I'll design the case from what you've given me and show you the whole thing with every decision I made — one confirmation, then I build; the design doc (`sdd.md`) is saved alongside for reference."
+When Phase 0 runs, prefix one line: "First I'll design the case from what you've given me and show one decision-first review packet with the case snapshot, primary journey, other paths, SLA responses, business rules, resources, and every decision I made — one confirmation, then I build; the full technical design doc (`sdd.md`) is saved alongside for reference."
 
 **Brownfield** (editing an existing case): present the short version at entry — see [references/brownfield.md](references/brownfield.md).
 
 ### Phase 0 — Interview (conditional)
 
-Triggered when `sdd.md` absent at resolved path. Read [references/phase-0-interview.md](references/phase-0-interview.md) for the flow (listen and ground → best-assumption sketch → single confirmation with every decision disclosed → build start with `sdd.md` written alongside), resumption, and the on-request HTML preview. Produces:
+Triggered when `sdd.md` absent at resolved path. Read [references/phase-0-interview.md](references/phase-0-interview.md) for the flow (listen and ground → best-assumption sketch with mandatory other-path sweep → single decision-first Case Review with the primary journey, other paths, SLA responses, business rules/outcomes, resources, and every decision disclosed, while data and variables stay out of the approval surface → build start with a template-complete `sdd.md` written alongside), resumption, and the on-request HTML preview. Produces:
 
-> **Read budget for Phase 0.** Read `phase-0-interview.md`, `references/sdd-generation-rules.md` (the mental model + task-type reasoning the assumptions rely on), and `assets/templates/sdd-template.md` to begin. Read these independent references in parallel. Do NOT preload plugin `impl-json.md` files — those are needed only in Phase 2/3 and pulled in just-in-time per T-entry.
+> **Read budget for Phase 0.** Read `phase-0-interview.md`, `references/sdd-generation-rules.md` (the mental model + task-type reasoning the assumptions rely on), and `assets/templates/sdd-template.md` to begin. Read these independent references in parallel. Do NOT read `references/planning.md` or plugin planning/implementation references before the Phase 0 Case Review is approved, even when the user also requested `tasks.md`; planning starts after approval. Do NOT preload plugin `impl-json.md` files — those are needed only in Phase 2/3 and pulled in just-in-time per T-entry. **No-build design+plan budget:** when the same request explicitly asks for `sdd.md` plus `tasks/tasks.md` and says to stop before `caseplan.json`, use the compact no-build plan contract in `phase-0-interview.md`; if the request already says to produce those artifacts and stop, write them right after the Case Review without a second approval prompt. Do not open `planning.md`, plugin planning docs, schemas, registry, connections, or user lookup in that run. **Draft finalization budget:** when `sdd.draft.md` exists and the user asks to finalize it without building, read only the draft, `phase-0-interview.md` resumption/gate text, and `assets/templates/sdd-template.md`; write `sdd.md` directly after the gate.
 
-> **Light tenant grounding — requirement-driven.** No tenant work up front. Start the background login + registry chain only when the case first shows tenant-bound work, per [phase-0-interview.md § Tenant grounding](references/phase-0-interview.md#tenant-grounding--requirement-driven-one-light-pass-no-questions); then ONE parallel name-match pass at confirmation time (parallel read-only lookups when ≥ 4 items), joining the chain without ever delaying the confirmation. Single confident matches adopt silently; everything else is `resolve at build` — no schema discovery, no resource prompts in Phase 0. Phase 1 resolves authoritatively, reusing this session's successful pull (Rule 3 fast path).
+> **Light tenant grounding — requirement-driven.** No tenant work up front. For build runs, start the background login + registry chain only when the case first shows tenant-bound work, per [phase-0-interview.md § Tenant grounding](references/phase-0-interview.md#tenant-grounding--requirement-driven-one-light-pass-no-questions); then ONE parallel name-match pass at confirmation time (parallel read-only lookups when ≥ 4 items), joining the chain without ever delaying the confirmation. Single confident matches adopt silently; everything else is `resolve at build` — no schema discovery, no resource prompts in Phase 0. Explicit plan-only/no-build runs skip tenant grounding entirely and defer identities to the later build run. Phase 1 resolves authoritatively, reusing this session's successful pull (Rule 3 fast path).
 
 - `sdd.md` — rendered from the confirmed in-memory model against `assets/templates/sdd-template.md`, batched with the first build actions (design-only requests save it and stop)
 - `sdd-viewer.html` — optional, rendered from `assets/templates/sdd-viewer.html` on explicit request only; Phase 1 ignores it
@@ -118,7 +123,7 @@ Auto-proceed to Phase 2 (re-read `tasks.md` first) — plan treated as approved.
 
 ### Phase 2 — Prototyping
 
-Read [references/implementation.md](references/implementation.md) + [references/phased-execution.md](references/phased-execution.md). Builds structural shape only:
+Read [references/implementation.md](references/implementation.md) + [references/phased-execution.md](references/phased-execution.md). Builds a reviewable preview with structure, rules, and SLA; task values and connector schemas remain deferred:
 
 1. Solution + project + root case (Step 6)
 2. Triggers — manual / timer / event, including placeholder event triggers per Rule 8 (Step 6.1)
@@ -126,34 +131,36 @@ Read [references/implementation.md](references/implementation.md) + [references/
 4. Refresh entry-points.json input/output from the declared In/Out args (Step 6.3) — per [`references/entry-points-sync.md`](references/entry-points-sync.md)
 5. Stages (Step 7)
 6. Tasks — shape only (Step 9): non-connector with full `data.inputs[]` schema + empty values; connector with `typeId` + `connectionId` only (no `case spec`); unresolved as placeholders per Rule 8
-7. Informational validate (Step 9.5.1) — do NOT halt on errors/warnings
-8. **Phase 2 → 3 boundary per Rule 11** (Step 9.5.2–9.5.5): print the counts summary, then branch on the up-front build-review preference. Straight-through → continue with no prompt. Pause-at-preview → `Publish for review` / `Skip publish and continue` / `Abort`; on `Publish`: `uip solution resources refresh --solution-folder <SolutionDir> --output json` then `uip solution upload`, print DesignerUrl, AskUserQuestion: `Continue to implementation` / `Abort`. On `Abort`: dump `build-issues.md`, exit (no cleanup).
+7. SLA + escalation objects (Step 11) — mint stable `sla_*` / `esc_*` IDs while writing the objects; no separate preallocation pass
+8. Conditions in all 4 scopes (Step 10) — `wait-for-connector` rules use the canonical stub in Phase 2, regardless of resolution state
+9. Informational validate (Step 11.9) — try `--skeleton-v2`; fall back to `--skeleton` only when the v2 flag is unsupported; do NOT halt on errors/warnings
+10. **Phase 2 → 3 boundary per Rule 11** (Step 11.9): print the counts summary, then branch on the up-front build-review preference. Straight-through → continue with no prompt. Pause-at-preview → `Publish for review` / `Skip publish and continue` / `Abort`; on `Publish`: `uip solution resources refresh --solution-folder <SolutionDir> --output json` then `uip solution upload <SolutionDir> --output json --output-filter "{Status: Status, SolutionId: SolutionId, DesignerUrl: DesignerUrl}"`, print DesignerUrl, AskUserQuestion: `Continue to implementation` / `Abort`. On `Abort`: dump `build-issues.md`, exit (no cleanup).
 
 ### Phase 3 — Implementation
 
 Re-read `tasks.md` AND `caseplan.json` (Step 9.6). Then:
 
-1. Connector schema + defaults (Step 9.7) — `is resources/triggers describe`
+1. Connector schema + defaults (Step 9.7) — `uip maestro case spec`
 2. I/O binding all task classes (Step 9.8) — per [`plugins/variables/io-binding/impl-json.md`](references/plugins/variables/io-binding/impl-json.md)
-3. Conditions all 4 scopes (Step 10)
-4. SLA + escalation (Step 11)
-5. In-expression `vars.$xref` marker resolution (Step 11.5) — per [`plugins/variables/io-binding/impl-json.md`](references/plugins/variables/io-binding/impl-json.md)
+3. Upgrade resolved connector-bound condition stubs in place (Step 10.5) — replace only `rule.uipath`; unresolved connectors keep the stub and are reported
+4. In-expression `vars.$xref` marker resolution (Step 11.5) — per [`plugins/variables/io-binding/impl-json.md`](references/plugins/variables/io-binding/impl-json.md)
+5. Resolved-resource emission and repair-preservation check (Step 12 Check 9), plus resourceKey self-consistency (Step 12 Check 11)
 
 No hard stop on Phase 3 exit — proceed directly to Phase 4.
 
 ### Phase 4 — Validate
 
-1. Run Step 12 once at the Phase 3 → Phase 4 boundary. It performs Checks 1–8, including bindings sidecar parity (Check 7) and global output-ID uniqueness (Check 8).
+1. Run Step 12 once at the Phase 3 → Phase 4 boundary. It performs Checks 1–11, including bindings sidecar parity (Check 7), global output-ID uniqueness (Check 8), resolved-resource emission/preservation (Check 9), formal-arg slot ID format (Check 10), and resourceKey self-consistency (Check 11).
 2. After all Step 12 checks pass, run full `uip maestro case validate`. Retry up to 3×; on 3rd failure **HARD STOP** AskUserQuestion: `Retry with fix` / `Pause for manual edit` / `Abort`
 3. Dump `build-issues.md` (Step 12.1)
 
-### Phase 5 — Debug
+### Phase 5 — Publish
 
-Completion report + **HARD STOP** AskUserQuestion (Step 13): `Run debug session` / `Skip to Publish`. On `Run`: `uip solution resources refresh` then `uip maestro case debug` (never auto-run — Rule 12). Loop on completion until `Skip to Publish`.
+Completion report + **HARD STOP** AskUserQuestion (Step 13): `Publish to Studio Web` / `Skip to Debug`. On `Publish`: `uip solution resources refresh` then `uip solution upload <SolutionDir> --output json --output-filter "{Status: Status, SolutionId: SolutionId, DesignerUrl: DesignerUrl}"`, print DesignerUrl (Step 14). Proceed to Phase 6 on either choice.
 
-### Phase 6 — Publish
+### Phase 6 — Debug
 
-**HARD STOP** AskUserQuestion (Step 14): `Publish to Studio Web` / `Done`. On `Publish`: `uip solution resources refresh` then `uip solution upload`, print DesignerUrl (Step 15). Exit on either choice.
+**HARD STOP** AskUserQuestion (Step 15): `Run debug session` / `Done`. On `Run`: `uip solution resources refresh` then `uip maestro case debug` (never auto-run — Rule 12). Loop on completion until `Done`.
 
 ## Reference Navigation
 
@@ -227,6 +234,10 @@ Completion report + **HARD STOP** AskUserQuestion (Step 13): `Run debug session`
 ## Anti-patterns
 
 - **Do NOT leave a regular stage without an entry condition.** With edges retired (Rule 20), stage entry conditions are the sole reachability contract. Every regular stage needs ≥1 `stage-entry-conditions` rule naming a reachable predecessor; the first stage carries `case-entered`. A stage with no entry condition is orphaned and unreachable.
+- **Do NOT substitute a generic build plan for Phase 0 confirmation.** For a new case without an SDD, project/workspace "plan first" rules are satisfied by the decision-first Case Review: Case Snapshot, Primary Journey, **Other Paths Considered**, SLA and Escalations, Rules and Outcomes, Resources and Integrations, Decisions I Made, and Review Flags. Tasks use product-facing activation labels (`Sequential`, `Parallel`, `Parallel after predecessor`, `Event-triggered`, `Manually triggered`, `Fan-in`, `Conditional gate`). Do not add data/variable tables or duplicate stage/task cards. A "Build Plan" / "Approve this plan" list of stages, artifact names, registry steps, output folders, validation commands, or placeholder caveats must not be used as the approval gate, and a user "Yes" to it must not create files.
+- **Do NOT start Phase 1 planning before Phase 0 approval.** If the user asks for both a new design and `tasks.md`, the first stop is still the decision-first Case Review. Read planning/plugin references and write `tasks.md` only after the Case Review is approved.
+- **Do NOT ship a summary `sdd.md`.** The written SDD must preserve the template's title, table of contents, Section 1/2/3/4 headings, case metadata/triggers/variables, one full stage block per stage, one full task block per task, personas/app views, and integrations. A valid `caseplan.json` does not prove the SDD followed the template.
+- **Do NOT plan only the primary flow.** Phase 0 must sweep for **Other Paths Considered** before confirmation: rework, rejection, withdrawal/cancellation, SLA escalation, external-system failure, manual override, optional side work, and alternate terminal outcomes. Model clear signals by assumption; ask one bounded question only when the source has no signal at all.
 - **Do NOT validate after each T-entry.** Intermediate states expected invalid. Run `validate` once at end of Phase 2 (informational) and once in Phase 4 (authoritative).
 - **`tasks.md` (Phase 1) uses per-section batched Edit-append — NOT per-T-entry, NOT one mega-Write.** One Read + N Edit-appends per section (§4.2.1 vars, §4.3 triggers, §4.4 stages, §4.6 tasks, §4.7 conditions, §4.8 SLA). No re-Read between sibling Edits. **HARD CAP:** after §4.0a Step 1 Seed Write (<1KB header), single Write of whole `tasks.md` is FORBIDDEN regardless of size. Single Edit-append payload >30KB also FORBIDDEN — split per section even if cumulative payload exceeds 30KB. A 96KB tasks.md Write costs ~360s in one turn (20% of session); section-batched Edit-appends spread across ~7 turns of ~50s. TaskUpdate per T-entry preserves audit trail. Recovery on interruption: re-Read `tasks.md`, resume from next un-applied T-entry. See [planning.md § 4.0a](references/planning.md).
 - **`caseplan.json` (Phase 2 + 3) uses per-section batched writes — NOT per-T-entry.** One Read at section entry + one validate at section end. Tool primitive scales with section size: **<10 T-entries** → N Edits (one per T-entry, no re-Read between siblings); **≥10 T-entries** → may use single whole-section Write covering the section's nodes array at once, AFTER composing complete section state in reasoning. Untouched siblings (other sections, root fields) MUST be preserved verbatim from the Read — drop nothing. TaskUpdate per T-entry preserves audit trail regardless of write granularity. CLI-gated sections (Phase 2 §4.6 non-connector `tasks describe`, Phase 3 §9.7 connector `case spec`) use gather-then-write. Recovery on interruption: re-Read both files, resume from next un-applied T-entry. Full contract in [case-editing-operations.md § Per-section batch write contract](references/case-editing-operations.md#per-section-batch-write-contract--canonical) and [implementation.md § Per-plugin execution](references/implementation.md).
@@ -234,14 +245,16 @@ Completion report + **HARD STOP** AskUserQuestion (Step 13): `Run debug session`
   - **HARD TOKEN CAP on any single text block: 200 tokens, no exceptions outside the allow-list below.** Allow-listed text blocks (the once-per-run kickoff flow overview, hard-stop AskUserQuestion preambles, Phase 5/6 completion reports, `Publish for review` DesignerUrl print, post-validate result summaries) get a higher ceiling of **500 tokens** — never higher. A text block >200 tokens outside the allow-list, or >500 tokens inside it, is a planning monologue, regardless of content or framing.
   - **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. The tool_use input shows what is being built — restating it in prose is pure cost. If the agent feels the urge to write `Composing Phase 2 caseplan.json — trigger + 64 variables + 10 stages`, it must instead invoke the Write directly with that content as the file body.
   - **Allow-listed exceptions** (may stand alone, capped at 500 tokens): the once-per-run kickoff flow overview, hard-stop AskUserQuestion preambles, final completion reports (Phase 5/6 exit), Phase 2 `Publish for review` DesignerUrl print (Rule 11), and post-validate result summaries (`N errors, M warnings — fixing X` is fine; `Composing fix for ...` is not). Everything else bundles or omits.
-- **Sequential task toggle matches the frontend.** `runs-sequentially` is a task entry rule, not a stage flag and not a lane marker. Preserve the ordered tasks in the stage's `data.tasks` structure and write one `entryConditions` entry containing only `rules: [[{ "rule": "runs-sequentially" }]]` for every task selected as sequential. The first task's rule means current-stage-entered; each later task's rule means the preceding task completes. Do not add `current-stage-entered` alongside the sequential rule. `data.tasks` grouping is structural/layout state; never use lane-sharing to express sequence.
+- **Sequential task toggle matches the frontend.** `runs-sequentially` is a task entry rule, not a stage flag and not a lane marker. When the requirement says `then`, `after`, `before`, `in order`, or otherwise declares a dependency/order, preserve the ordered task-set structure in `data.tasks` and write one `entryConditions` entry containing only `rules: [[{ "rule": "runs-sequentially" }]]` for every task in that ordered run. A strict chain uses consecutive single-task sets: `data.tasks: [[A], [B], [C]]`. Independent siblings after the same predecessor share the same later set: `[[A], [B, C], [D]]`; each sibling still carries `runs-sequentially` so it starts after the prior task set. The first task set's rule means current-stage-entered; each later task set's rule means the preceding task set completed. Do not let the absence of a data binding turn an explicitly ordered run into parallel stage-start tasks. Do not add `current-stage-entered` alongside the sequential rule. Use parallel `current-stage-entered` tasks only for independent stage-start work; add `selected-tasks-completed` fan-in only when downstream work requires all branches.
 - **Task mode is a semantic choice, not a visual layout choice.** Map the frontend task selector as follows: `sequential` → one `runs-sequentially` entry rule per task in declaration order; `event-triggered` → an event/condition-driven task (use `wait-for-connector` for an external connector event, or the explicitly authored condition; never infer sequentiality); `manually-triggered` / `adhoc` → one `adhoc` entry rule, `isRequired: false`, started by a user from the Case App, with no additional entry events. `adhoc` is an activation mode, not a task type; a manually triggered task can still be `action`, `agent`, `api-workflow`, `process`, etc. Never model an adhoc task as event-triggered or sequential, and never add `adhoc` to a stage-entry condition.
-- **Secondary stages are interrupting exception lanes, not inline primary stages.** Use the same `case-management:Stage` node with `data.stageType: "secondary"`; set `isRequired: false`, set `Interrupting: Yes` on the stage and every secondary-stage entry row, and use it for exception, rework, terminal, or special handling that interrupts the active case path. If the work is optional but does not interrupt the active path, model it as an `adhoc` task or regular parallel path instead. Secondary stages cannot be connected to other stages as a normal flow edge; a returning lane completes with `return-to-origin`. Do not count a secondary stage in the happy-path `required-stages-completed` completion set.
+- **Secondary stages are interrupting exception lanes, not inline primary stages.** Use the same `case-management:Stage` node with `data.stageType: "secondary"`; set `isRequired: false`, set `Interrupting: Yes` on the stage and every secondary-stage entry row, and use it for exception, rework, terminal, or special handling that interrupts the active case path. If the work is optional but does not interrupt the active path, model it as an `adhoc` task or regular parallel path instead. **One carve-out:** an `sla-status-change` entry row whose response is parallel oversight (the breached work keeps running — nothing paused, taken over, or rerouted) carries `Interrupting: No` while the lane stays `secondary` and `isRequired: false`; never promote it to a regular stage, which would make it required for case completion. Secondary stages cannot be connected to other stages as a normal flow edge; a returning lane completes with `return-to-origin`. Do not count a secondary stage in the happy-path `required-stages-completed` completion set.
+- **Do NOT replicate global-event handling across primary stages.** Withdrawal/cancellation events from external systems use one interrupting secondary-stage `wait-for-connector` entry. An SLA response that enters a stage uses one scoped `sla-status-change` entry. Repeating the same event task or exit rule on every possible origin stage creates drift and conflicting transitions.
 - **Case completion is a root rule, separate from stage completion.** The case must have at least one `metadata.caseExitRules[]` entry with `marksCaseComplete: true` (normally `required-stages-completed`). A stage exit with `marksStageComplete: true` only completes that stage; it does not close the case. Non-completing outcomes such as rejection or withdrawal use separate case-exit rules with `marksCaseComplete: false`.
 - **Do NOT edit the auto-generated `caseplan.json.bpmn`.** Regenerated by validate/pack, will be overwritten. Author only `caseplan.json`.
 - **Case file is flat at `<Solution>/<Project>/caseplan.json` — never under `content/`.** `content/` is the packed `.nupkg` layout (`package-descriptor.json`), not on-disk. Never `mkdir content` or author the root caseplan via `uip maestro case cases add` — write `caseplan.json` directly ([impl-json.md](references/plugins/case/impl-json.md)).
 - **Do NOT fabricate expression syntax for conditional SLA rules.** Describe condition in natural language; execution phase determines exact form.
 - **Do NOT place `tasks/` inside the solution or project directory.** `tasks/` (and its `tasks.md`, `registry-resolved.json`) lives next to `sdd.md` at the working root — NOT inside `<Solution>/` or `<Solution>/<Project>/`. The case file path (`<Solution>/<Project>/caseplan.json`) does NOT root the planning artifacts; they track `sdd.md`, not `caseplan.json`.
 - **Do NOT invoke other skills automatically — except the inline-create path.** If case needs a regular RPA process / action / child case / connector / agentic process that doesn't exist, emit placeholder task (Rule 8) and list missing resources in completion report; on-demand creation of those kinds is a future milestone. **Exception (agent + API workflow):** when the user picks `Create` at the Rule 17 gate, the skill builds the missing agent / API workflow inline by spawning a sub-agent that invokes `uipath-agents` (agent) or `uipath-api-workflow` (API workflow) — gate-selected only, never from SDD content alone. The `uipath-planner` handoff stays plain-text (Rule 15).
+- **Do NOT spawn subagents for draft finalization or plan-only document generation.** Subagents are allowed only for the explicit inline-create build path after the Rule 17 gate.
 
 > **Trouble?** Use `/uipath-feedback` to send report.