@uipath/skills 1.197.2 → 1.198.0-preview.21

package/skills/uipath-maestro-bpmn/validator/README.md

@@ -8,6 +8,14 @@ PO.Frontend `Node[] / Edge[] / CanvasState` model from the parse tree, and runs
 (`VARIABLE_DOES_NOT_EXIST`, including element-local `result.X`, and the
 flow-order `VARIABLE_NOT_SET` warning) and an optional connection-liveness ping.
 
+> **Authoring scope:** everything under `test/fixtures/` is validator test data,
+> not authoring material. **Do not read the fixtures to infer the BPMN pattern**
+> — it is the top reason authoring runs out of time. Author from the complete
+> minimal file in
+> [../references/structural-bpmn.md](../references/structural-bpmn.md#a-complete-minimal-file-author-from-this-not-from-fixtures)
+> instead. This README documents the validator and its test suite; run the
+> validator (below) as your check, and leave the corpus to CI.
+
 ## Usage
 
 ```bash
@@ -50,8 +58,10 @@ npm test   # runs all three suites below; green = no drift from the frontend
 3. **Integration over real `.bpmn` files** (`test/integration.test.mjs`): every
    file in `test/fixtures/` is a real, externally-validated artifact (backend
    BpmnParser/Worker/Athena/V2-E2E TestData, and PO.Frontend editor mocks),
-   bundled so the suite is self-contained in CI. `fixtures/known-good/` must
-   produce **zero** ERROR-severity findings; `fixtures/expected-findings/` assert
+   bundled so the suite is self-contained in CI. These files exist to exercise
+   the rule engine — they are **not** authoring templates; see the authoring-scope
+   note at the top before reaching for one as an example. `fixtures/known-good/`
+   must produce **zero** ERROR-severity findings; `fixtures/expected-findings/` assert
    the exact ERROR codes the frontend would also raise (each verified by reading
    the file). Set `MAESTRO_BPMN_TESTDATA` / `MAESTRO_BPMN_FRONTEND_MOCKS` to also
    sweep a live corpus during development.

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

@@ -1,7 +1,7 @@
 ---
 name: uipath-maestro-case
-description: "Always invoke for `caseplan.json` files. UiPath Case Management authoring (caseplan.json) from sdd.md, or via lightweight interview if sdd.md absent. Produces tasks.md plan, writes caseplan.json via per-plugin JSON recipes. For .xaml→uipath-rpa, .flow→uipath-maestro-flow, .bpmn→uipath-maestro-bpmn. For PDD→SDD or complex/multi-product→uipath-planner."
-allowed-tools: Bash, Read, Write, Edit, Glob, Grep, AskUserQuestion, TodoWrite
+description: "Always invoke for `caseplan.json` files. UiPath Case Management authoring (caseplan.json) from sdd.md, or via lightweight 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."
+allowed-tools: Bash, Read, Write, Edit, Glob, Grep, AskUserQuestion, TodoWrite, Agent
 ---
 
 # UiPath Case Management Authoring Assistant
@@ -10,7 +10,7 @@ Builds UiPath Case Management definitions from `sdd.md`. Generates `tasks.md` pl
 
 When `sdd.md` is absent, **Phase 0 interview** generates one interactively (listen → sketch → progressive ask-walk → resolve → approve, with optional HTML preview before handing off). Complex / multi-product cases redirect to `uipath-planner` — see [references/phase-0-interview.md § Thresholds](references/phase-0-interview.md#thresholds) for caps.
 
-**Scope:** new case from `sdd.md` (user-provided or Phase 0-generated). Modifying existing case not supported (no remote fetch tooling).
+**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 project 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).
 
 ## When to Use This Skill
 
@@ -18,6 +18,7 @@ When `sdd.md` is absent, **Phase 0 interview** generates one interactively (list
 - User asks to create new case management project but has no `sdd.md` (Phase 0 interview generates one)
 - User asks to create new case management project or definition
 - User asks to generate implementation tasks from `sdd.md` or convert spec to plan
+- User asks to edit, modify, or update an existing `caseplan.json` (add/remove a stage or task, change a condition, swap a trigger) — targeted edits skip planning; see [references/brownfield.md](references/brownfield.md)
 - User asks about case management JSON schema — nodes, transitions, tasks, rules, SLA
 - User wants to manage runtime case instances (list, pause, resume, cancel) — see [references/case-commands.md](references/case-commands.md)
 
@@ -30,7 +31,7 @@ When `sdd.md` is absent, **Phase 0 interview** generates one interactively (list
 3. **Run `uip maestro case registry pull` before planning.** Discovery reads cache files at `~/.uip/case-resources/<type>-index.json` directly. `registry search` has known gaps (esp. action-apps). 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 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. **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. See [`references/planning.md` §4.0](references/planning.md).
+6. **`tasks.md` declarative 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. **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).
 7. **HARD STOP after `tasks.md`.** AskUserQuestion: `Approve and proceed` / `Request changes`. 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 (edges retired) — the first stage's `case-entered` entry condition starts the case. 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`** — search query, all matches, selected result, rationale.
@@ -41,9 +42,18 @@ When `sdd.md` is absent, **Phase 0 interview** generates one interactively (list
 14. **Always run `uip solution resources refresh` before `uip solution upload` or `uip maestro case debug`** — syncs resources from `bindings_v2.json` so Studio Web can resolve connector dependencies.
 15. **Never auto-invoke `uipath-planner`.** On Phase 0 threshold breach or stuck-round detection, print plain-text suggestion of the skill name. User re-invokes 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 for force pull BEFORE any placeholder fallback.** When a planning-phase lookup returns 0 matches across all relevant cache files, present AskUserQuestion `Force pull and re-resolve` / `Skip and use placeholders` BEFORE writing any placeholder T-entries or invoking per-plugin Unresolved Fallback paths. Apply per lookup-batch (one prompt covers all empties in the batch — do not prompt per-task). Do NOT pre-judge based on resource-name heuristics ("looks vendor-specific, won't match anyway") — that is the user's call. Placeholder fallback is only valid AFTER the user explicitly picks `Skip`. See [references/registry-discovery.md § MUST: Confirm Before Placeholder Fallback](references/registry-discovery.md#must-confirm-before-placeholder-fallback).
+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) `Skip and use placeholders`; (c) `Create the missing resource(s) 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, connectors, agentic processes) → placeholder; the option is suppressed when `--local` is absent. Do NOT pre-judge via resource-name heuristics — the user's call. Placeholder fallback is valid only after `Skip`. 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).
 
+## Routing — greenfield vs brownfield
+
+| Condition | Journey |
+|---|---|
+| New case, or `sdd.md` provided, or no `caseplan.json` yet, or user asks to (re)build from a spec | **Greenfield** — Phase 0→6 below |
+| `caseplan.json` exists AND intent is a targeted edit ("add a stage", "remove task X", "change a condition", "swap the trigger") | **Brownfield** — skip Phase 0→6, go to [references/brownfield.md](references/brownfield.md) |
+
+Brownfield bypasses planning, prototyping, and their hard stops; it still honors the debug-consent gate (Rule 12) and reuses the Phase 5 / Phase 6 contracts.
+
 ## Workflow
 
 Up to seven hard stops (Phase 0 + Phase 2 second prompt + Phase 4 conditional): **Phase 0** (interview → sdd.md, only when sdd.md absent) → approve → **Phase 1 Planning** (sdd.md → tasks.md) → approve → **Phase 2 Prototyping** (placeholder) → publish-for-review stop → continue-after-publish stop (publish branch only) → **Phase 3 Implementation** (detail) → **Phase 4 Validate** (retry-cap stop on 3rd failure) → **Phase 5 Debug** (Run vs Skip-to-Publish stop) → **Phase 6 Publish** (Publish vs Done stop).
@@ -67,6 +77,7 @@ Read [references/planning.md](references/planning.md). Produces:
 
 - `tasks/tasks.md` — T-numbered entries (stages → tasks → conditions → SLA)
 - `tasks/registry-resolved.json` — audit trail
+- When the user picks **Create** at the Rule 17 gate, Phase 1 also builds the selected agent(s) / API workflow(s) as in-solution siblings (one sub-agent per resource — `uipath-agents` for agents, `uipath-api-workflow` for API workflows), registers them (`uip solution project add` + `resources refresh`), and binds them as resolved tasks. Registration and `--local` rediscovery need an enclosing solution `.uipx`, so the Create flow **first ensures the solution exists** (`uip solution init` if absent — Phase 2 Step 6.0 then skips its own `init`). See [references/registry-discovery.md § Create-on-Missing](references/registry-discovery.md#create-on-missing-build-and-rediscovery).
 
 > **`tasks/` is created at the working root, adjacent to `sdd.md` — NEVER inside the solution/project folder (`<Solution>/`).** This holds regardless of where the case file lives: `caseplan.json` sits at `<Solution>/<Project>/caseplan.json`, but the planning artifacts (`tasks.md`, `registry-resolved.json`) stay next to `sdd.md` at the root.
 
@@ -78,11 +89,12 @@ Read [references/implementation.md](references/implementation.md) + [references/
 
 1. Solution + project + root case (Step 6)
 2. Triggers — manual / timer / event, including placeholder event triggers per Rule 8 (Step 6.1)
-3. Global variables + arguments (Step 6.2) — including In arguments whose `elementId` references a `TriggerId` captured in Step 6.1
-4. Stages (Step 7)
-5. 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
-6. Informational validate (Step 9.5.1) — do NOT halt on errors/warnings
-7. **HARD STOP** (Step 9.5.2–9.5.5): `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 phase 3` / `Abort`. On `Abort`: dump `build-issues.md`, exit (no cleanup).
+3. Global variables + arguments (Step 6.2) — including In arguments whose `elementId` references the `TriggerId` (captured in Step 6.1) of the trigger named by the row's `sourceTriggers`, or the primary trigger when blank
+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. **HARD STOP** (Step 9.5.2–9.5.5): `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 phase 3` / `Abort`. On `Abort`: dump `build-issues.md`, exit (no cleanup).
 
 ### Phase 3 — Implementation
 
@@ -116,8 +128,9 @@ Completion report + **HARD STOP** AskUserQuestion (Step 13): `Run debug session`
 | Generate sdd.md interactively when none provided | [references/phase-0-interview.md](references/phase-0-interview.md) |
 | Plan tasks from sdd.md | [references/planning.md](references/planning.md) |
 | Execute tasks.md into a case | [references/implementation.md](references/implementation.md) |
+| Edit an existing caseplan.json (targeted edits) | [references/brownfield.md](references/brownfield.md) |
 | Phase 2 → 3 → 4 → 5 → 6 split + hard stop contracts | [references/phased-execution.md](references/phased-execution.md) |
-| Edit caseplan.json directly | [references/case-editing-operations.md](references/case-editing-operations.md) |
+| Cross-cutting edit mechanics (IDs, anchoring, batch contract) | [references/case-editing-operations.md](references/case-editing-operations.md) |
 | Case JSON schema | [references/case-schema.md](references/case-schema.md) |
 | Surviving CLI commands (registry, validate, debug, runtime) | [references/case-commands.md](references/case-commands.md) |
 | Troubleshoot a failed case | [references/troubleshooting-guide.md](references/troubleshooting-guide.md) |
@@ -127,6 +140,7 @@ Completion report + **HARD STOP** AskUserQuestion (Step 13): `Run debug session`
 | Construct `case spec --input-details` JSON | [references/case-spec-input-details.md](references/case-spec-input-details.md) |
 | Placeholder tasks for unresolved resources | [references/placeholder-tasks.md](references/placeholder-tasks.md) |
 | Sync bindings_v2.json + connection resources | [references/bindings-v2-sync.md](references/bindings-v2-sync.md) |
+| Refresh entry-points.json input/output from In/Out args | [references/entry-points-sync.md](references/entry-points-sync.md) |
 
 ### Plugin Index
 
@@ -135,7 +149,7 @@ Completion report + **HARD STOP** AskUserQuestion (Step 13): `Run debug session`
 | Plugin | Scope |
 |--------|-------|
 | [case](references/plugins/case/planning.md) | Root case (T01) |
-| [stages](references/plugins/stages/planning.md) | Regular and exception stages |
+| [stages](references/plugins/stages/planning.md) | Regular (primary) and secondary stages |
 | [sla](references/plugins/sla/planning.md) | Default SLA, conditional rules, escalation |
 | [global-vars](references/plugins/variables/global-vars/planning.md) | Case variables and arguments |
 | [io-binding](references/plugins/variables/io-binding/planning.md) | Task I/O wiring, cross-task refs |
@@ -190,6 +204,6 @@ Completion report + **HARD STOP** AskUserQuestion (Step 13): `Run debug session`
 - **Do NOT edit `content/*.bpmn`.** Auto-generated, will be overwritten. Edit `content/*.json` only.
 - **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.** If case needs process/agent/action that doesn't exist, emit placeholder task (Rule 8) and list missing resources in completion report. On-demand resource creation is future milestone.
+- **Do NOT invoke other skills automatically — except the inline-create path.** If case needs a regular RPA process / action / 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).
 
 > **Trouble?** Use `/uipath-feedback` to send report.

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

@@ -2,7 +2,7 @@
 
 Companion to [`sdd-template.md`](sdd-template.md). Each section shows the SDD authoring snippets for a common pattern an author will encounter. Use as a reference when writing a new `sdd.md`.
 
-Thirteen v1-supported patterns. Two intentionally-dropped patterns documented at the end with workarounds.
+Fourteen v1-supported patterns. Two intentionally-dropped patterns documented at the end with workarounds.
 
 ## Quick lookup
 
@@ -13,6 +13,7 @@ Thirteen v1-supported patterns. Two intentionally-dropped patterns documented at
 | 2b | Multi-trigger Variable (same slot from N triggers) | `Variable` | Case Variables + Triggers tables | — |
 | 2c | Trigger-sourced file Variable (event payload carries an attachment) | `Variable` (file) | Case Variables + Triggers tables | — |
 | 3 | Caller-supplied / Default-initialized input | `In` | Case Variables table | — |
+| 3b | In-arg bound to a specific trigger | `In` | Case Variables + Triggers tables | — |
 | 4 | Returned output to caller | `Out` | Case Variables + producer task's Outputs | `->` |
 | 5 | Task extracts response field → case var | (any) | Task's Outputs table | `->` |
 | 6 | Task writes literal/computed value to existing var | (any) | Task's Outputs table | `=` |
@@ -98,6 +99,7 @@ In Case Variables — one row with CSV + keyed format:
 - Each T-number in `sourceTriggers` MUST have a matching keyed entry in `sourceFields`. Mismatch → Phase 2 validation error.
 - Order of T-numbers doesn't matter — the keyed format disambiguates per-trigger.
 - Same Type and same Default apply across all listed triggers.
+- CSV `sourceTriggers` is a `Variable`-only construct. An `In`-arg binds to exactly ONE trigger — a single `sourceTriggers` T-number with **empty** `sourceFields` (see Use Case 3b).
 
 **When to use Use Case 2b vs declaring per-trigger Variables:**
 - **Use Case 2b** when the value is *semantically the same thing* across triggers (e.g., "the initiator", "the customer ID"). One variable, one downstream reference.
@@ -163,7 +165,38 @@ In Case Variables:
 
 **Runtime behavior:** caller submits `{applicantId: "ALC-123", requestedAmount: 50000}` via API. Engine routes these to `vars.applicantId` and `vars.requestedAmount` at case start. Downstream tasks read them via `=vars.applicantId` etc.
 
-**Trigger type:** `In` works with any trigger type — manual, timer, or event. For event triggers, the In-arg's `Default` value propagates through to the case variable at trigger fire (no caller-override path, since events don't have an API caller). Use `In` when authoring a value that *could* be caller-supplied; use `Variable` + `sourceTriggers` + `sourceFields` (Use Case 2) when the value is *extracted from* the trigger's payload directly.
+**Trigger type:** `In` works with any trigger type — manual, timer, or event. For event triggers, the In-arg's `Default` value propagates through to the case variable at trigger fire (no caller-override path, since events don't have an API caller). Use `In` when authoring a value that *could* be caller-supplied; use `Variable` + `sourceTriggers` + `sourceFields` (Use Case 2) when the value is *extracted from* the trigger's payload directly. In a multi-trigger case, bind an In-arg to a specific (non-primary) trigger via a single `sourceTriggers` T-number — see Use Case 3b.
+
+---
+
+## Use Case 3b — In-arg bound to a specific trigger
+
+**Scenario:** A case starts from more than one trigger. By default an In-arg binds to the **primary trigger** (T02). To bind a caller-supplied value to a *different* trigger, name that trigger in `sourceTriggers`.
+
+**SDD authoring:**
+
+In Case Triggers (two triggers):
+```markdown
+| T# | Trigger Type        | Source | Configuration             |
+|----|---------------------|--------|---------------------------|
+| T02 | Manual              | API    | N/A                       |
+| T03 | Intsvc.EventTrigger | Slack  | Message posted in #intake |
+```
+
+In Case Variables:
+```markdown
+| Name       | Category | Type   | sourceTriggers | sourceFields | Default      | Description                                       |
+|------------|----------|--------|----------------|--------------|--------------|---------------------------------------------------|
+| caseId     | In       | string |                |              |              | Bound to the primary trigger (T02) — blank sourceTriggers |
+| approverId | In       | string | T03            |              | "unassigned" | Bound to the T03 event trigger; events have no caller, so it initializes from Default at trigger fire |
+```
+
+**Rules:**
+- `sourceTriggers` on an `In` row is a SINGLE T-number — never a CSV. A CSV is the multi-trigger `Variable` form (Use Case 2b).
+- `sourceFields` stays EMPTY on `In` rows. An In-arg *selects* a trigger; it does not *extract* a payload field — that's the `Variable` operation (Use Case 2).
+- Blank `sourceTriggers` = bind to the primary trigger (T02) — backward compatible with the single-trigger case.
+
+**Runtime behavior:** `caseId` is supplied by the API caller at case start via the primary manual trigger (T02). `approverId` is bound to the T03 event trigger, which has no API caller — so it initializes from its `Default` (`"unassigned"`) when that trigger fires. Downstream tasks read each via `=vars.caseId` / `=vars.approverId`.
 
 ---
 
@@ -491,8 +524,8 @@ When writing a new SDD, run through this list:
 
 - [ ] Every variable referenced via `=vars.X` somewhere (input bindings, conditions, SLA expressions) — declared in Case Variables OR is a task's auto-emitted schema field
 - [ ] Every `Out` Category row has either a `Default` value OR a producer task with a matching binding row
-- [ ] Every `In` Category row has `sourceTriggers` empty (trigger ownership is implicit — case is assumed to have one start-path trigger that owns all `In` args)
-- [ ] Every `Variable` with `sourceTriggers` set has matching entries in `sourceFields` — single path for one trigger; keyed `T<N>: <path>` format for CSV multi-trigger
+- [ ] Every `In` Category row has `sourceFields` empty, and `sourceTriggers` either blank (binds the primary trigger) or a single `T<N>` (binds that trigger) — never a CSV
+- [ ] Every `Variable` with `sourceTriggers` set has matching entries in `sourceFields` — single path for one trigger; keyed `T<N>: <path>` format for CSV multi-trigger (an `In` row is the exception: a single `sourceTriggers` T-number with **no** `sourceFields`)
 - [ ] Every `sourceFields` is a valid dot-path (no `[0]` indexing)
 - [ ] In each task's Outputs table: each target case variable appears in ≤1 row
 - [ ] In each task's Outputs table: `->` rows have a non-empty Field column; `=` rows have `Field` as `—`

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

@@ -197,7 +197,7 @@ The generated SDD must start with:
 
 | Trigger type | What to write |
 |---|---|
-| Event trigger | The operation in business terms (e.g., `Calendar created`, `Email received`). Append a filter expression if the user wants filtering (e.g., `Email received in Inbox; filter: subject contains "URGENT"`). Append a required event-param value only when the user supplies it explicitly (e.g., `Email received in folder "<folder name>"`). |
+| Event trigger | The operation in business terms (e.g., `Calendar created`, `Email received`, `Record created`). For tenant case-entity / business data-object starts, preserve the object name in Source (e.g., `expense_requests`) and write the business event in Configuration (e.g., `Record created`). Append a filter expression if the user wants filtering (e.g., `Email received in Inbox; filter: subject contains "URGENT"`). Append a required event-param value only when the user supplies it explicitly (e.g., `Email received in folder "<folder name>"`). |
 | Timer trigger | Cycle or duration (e.g., `every 24 hours`, `daily at 09:00 UTC`). |
 | Manual | `N/A` or omit. |
 
@@ -207,6 +207,13 @@ DO NOT include in Configuration:
 - Meta notes like `No required event parameters` or `No user filter` (absence is the default; the skill discovers required params at `case spec` time).
 - Connector activity slug, HTTP method, or any spec-discovered detail.
 
+> **Tenant object starts are still event triggers.** If the user says a case starts
+> when a tenant case-entity / data-object record is created, author
+> `Intsvc.EventTrigger` with that object name as Source. Do NOT downgrade to
+> `Manual` just because the eval sandbox or current tenant may not have the
+> object provisioned. Planning/implementation preserve unresolved event triggers
+> as placeholders.
+
 ### Case Exit Conditions
 
 > **WHEN ↔ Marks Case Complete pairing is a schema constraint (see Key Rule 4):** `Yes` row MUST use `required-stages-completed` (preferred) or `wait-for-connector`; `No` row MAY use `selected-stage-completed(...)` / `selected-stage-exited(...)` / `wait-for-connector`. Mixing `Yes` with a `selected-*` rule is invalid.
@@ -225,11 +232,11 @@ DO NOT include in Configuration:
 
 | Name | Category | Type | sourceTriggers | sourceFields | Default | Description |
 |------|----------|------|----------------|--------------|---------|-------------|
-| {camelCase name} | {In \| Out \| Variable} | {string \| integer \| float \| double \| boolean \| datetime \| date \| jsonSchema \| file} | {T-number(s) — single `T<N>` or comma-separated CSV when multiple triggers feed the same Variable; empty for pure state / Out-args / In-args} | {single payload path when one trigger; keyed `T<N>: <path>; T<M>: <path>` format when multiple triggers} | {default value or empty} | {what this variable represents} |
+| {camelCase name} | {In \| Out \| Variable} | {string \| integer \| float \| double \| boolean \| datetime \| date \| jsonSchema \| file} | {`Variable`: single `T<N>` or CSV when multiple triggers feed the same slot. `In`: optional single `T<N>` selecting the bound trigger (blank = primary trigger; never CSV). Empty for pure state / Out-args} | {single payload path when one trigger; keyed `T<N>: <path>; T<M>: <path>` when multiple triggers; empty on `In` rows} | {default value or empty} | {what this variable represents} |
 
 **Category semantics (author-facing summary; canonical definition in [`global-vars/impl-json.md` § Pattern shapes by category](../../references/plugins/variables/global-vars/impl-json.md)):**
 
-- **`In`** — formal case argument supplied at case start by an external caller (manual trigger via API) OR initialized from `Default` (event / timer triggers, which have no caller). Works with any trigger type. For event-trigger-payload-extraction (where the value comes from the event's payload), use `Variable` with `sourceTriggers` + `sourceFields` (Use Case 2) instead — that's a different operation. **File-type In-args:** the runtime caller must pre-create the JobAttachment (`POST /odata/Attachments`, then `PUT` the bytes to the returned blob URI) and pass the resulting `{ID, FullName, MimeType, Metadata}` record as the In-arg value plus the attachment ID in `StartProcessDto.Attachments[]`. The Maestro Studio Web "Start case" dialog handles this automatically when the user picks a file; programmatic callers must do it themselves.
+- **`In`** — formal case argument supplied at case start by an external caller (manual trigger via API) OR initialized from `Default` (event / timer triggers, which have no caller). Works with any trigger type. By default an In-arg binds to the primary trigger (T02); to bind it to a specific trigger, put that trigger's single `T<N>` in `sourceTriggers` (one only, never a CSV). `sourceFields` stays empty for `In` rows. For event-trigger-payload-extraction (where the value comes from the event's payload), use `Variable` with `sourceTriggers` + `sourceFields` (Use Case 2) instead — that's a different operation. **File-type In-args:** the runtime caller must pre-create the JobAttachment (`POST /odata/Attachments`, then `PUT` the bytes to the returned blob URI) and pass the resulting `{ID, FullName, MimeType, Metadata}` record as the In-arg value plus the attachment ID in `StartProcessDto.Attachments[]`. The Maestro Studio Web "Start case" dialog handles this automatically when the user picks a file; programmatic callers must do it themselves.
 - **`Out`** — formal case argument returned to the caller at case end. Value comes from a task's Outputs row that targets this Name (the producer) OR from a `Default` value if no task fires. `sourceTriggers` MUST be empty (direction mismatch — values flow case→caller, not trigger→case).
 - **`Variable`** — case-internal state. May be populated by one trigger's payload (single T-number in `sourceTriggers` + single path in `sourceFields`), by multiple triggers' payloads sharing the same slot (CSV in `sourceTriggers` + keyed `T<N>: <path>` format in `sourceFields`), by a task output (use `->` operator in that task's Outputs table — same Name on both sides drives the wiring), or initialized via `Default` only.
 
@@ -255,7 +262,8 @@ If neither holds, the io-binding validator surfaces the misalignment.
 | caseStatus | Variable | string | | | "Open" | Pure case state, initialized at case start |
 | subject | Variable | string | T02 | response.subject | | Populated by event trigger payload at trigger fire |
 | caseStarter | Variable | string | T02, T03 | T02: response.user; T03: response.initiator | | Shared slot — whichever trigger fires populates it |
-| applicantName | In | string | | | | Formal In-arg supplied by API caller (manual trigger) |
+| applicantName | In | string | | | | Formal In-arg supplied by API caller; blank sourceTriggers → bound to primary trigger |
+| reviewerNote | In | string | T03 | | | In-arg bound to the T03 trigger (single T-number; sourceFields stays empty) |
 | finalDecision | Out | string | | | "Pending" | Out-arg; producer is "Approve Decision" task; "Pending" returned if no task fires |
 | reviewCount | Variable | integer | | | 0 | Counter incremented by tasks via `=` operator |
 
@@ -263,7 +271,7 @@ If neither holds, the io-binding validator surfaces the misalignment.
 
 ## Section 2: Stages & Tasks
 
-**Purpose:** The case plan — every stage as a self-contained subsection with its own entry/exit conditions, SLA, and task definitions with inline I/O bindings. Stages use correct node types from the schema (`case-management:Stage` or `case-management:ExceptionStage`).
+**Purpose:** The case plan — every stage as a self-contained subsection with its own entry/exit conditions, SLA, and task definitions with inline I/O bindings. Stages use the single node type `case-management:Stage`; a secondary stage is distinguished by `data.stageType: "secondary"` (a primary stage omits `stageType`).
 
 **I/O bindings — how the Inputs / Outputs tables drive task wiring:**
 
@@ -302,16 +310,19 @@ The runtime engine resolves the binding when the task completes, writing the res
 
 ### Stage {N}: {Stage Name}
 
-**Type:** {Stage \| ExceptionStage}
+> **Heading form:** a **primary** stage uses `### Stage {N}: {Stage Name}` (N = main-flow sequence number); a **secondary** stage uses `### Secondary Stage: {Stage Name}` instead (no number). Both render a `case-management:Stage` node — the kind is set by the `**Stage Kind:**` field below.
+
+**Type:** Stage
+**Stage Kind:** {primary \| secondary} _(secondary stages use the `### Secondary Stage:` heading AND set `secondary`; primary stages use `### Stage {N}:` and OMIT this line — default = primary)_
 **Description:** {Prose description of what this stage accomplishes in the case lifecycle}
 **Required for Case Completion:** {Yes \| No}
-**Interrupting:** {Yes \| No} _(ExceptionStage only — omit for regular stages)_
+**Interrupting:** {Yes \| No} _(secondary stages only — i.e. Stage Kind: secondary; omit for primary)_
 
 #### Stage Entry Conditions
 
 > **Valid WHEN rule types for stage entry (strict subset of Key Rule 3):** `case-entered` (first stage of the case — no target), `selected-stage-completed("StageName")`, `selected-stage-exited("StageName")`, `user-selected-stage` (target of an upstream `wait-for-user` exit — no target; stage opts into the picker by declaring this rule), `wait-for-connector` (event-driven entry / interrupt — typically pairs with `Interrupting: Yes`). Other rule types from Key Rule 3 are NOT valid here.
 >
-> **Interrupting column:** `Yes` lets the condition fire while another stage is active and interrupt it — used for exception / fraud / escalation flows on `ExceptionStage`. `No` for normal sequential entry on regular stages.
+> **Interrupting column:** `Yes` lets the condition fire while another stage is active and interrupt it — used for exception / fraud / escalation flows on a secondary stage (Stage Kind: secondary). `No` for normal sequential entry on regular stages.
 >
 > Each row is a separate entry condition. List multiple rows when a stage can be entered through more than one path (e.g., normal completion of an upstream stage AND an interrupting connector event).
 
@@ -325,7 +336,7 @@ The runtime engine resolves the binding when the task completes, writing the res
 
 > **WHEN ↔ Marks Stage Complete pairing is a schema constraint (see Key Rule 4):** `Yes` row MUST use `required-tasks-completed` (or `required-stages-completed`); `No` row MAY use `selected-tasks-completed(...)`. Mixing is invalid.
 > Completion (`Yes`) and routing (`No`) rows share this one table. **Regular stage-to-stage routing is expressed by the destination stages' Entry Conditions** (`selected-stage-completed("This Stage")` / `selected-stage-exited("This Stage")`) — one stage can fan out to N stages, each declaring it as their entry trigger. `return-to-origin` returns to the origin stage automatically.
-> **Exception carve-out:** to route this stage INTO a decision/signal-routed exception lane, add a gated divert row here — `Marks Stage Complete: No`, `selected-tasks-completed("<decider>")`, `IF =js:(<signal> === <exception-value>)`, `exit-only`, with `exitToStageId` → the exception stage — AND gate this stage's `Yes` completion row with the inverse `IF`. The lane returns via `return-to-origin`. Omitting the divert row → dual-fire or deadlock. See sdd-generation-rules § Logical integrity step 5.
+> **Exception carve-out:** to route this stage INTO a decision/signal-routed exception lane, add a gated divert row here — `Marks Stage Complete: No`, `selected-tasks-completed("<decider>")`, `IF =js:(<signal> === <exception-value>)`, `exit-only`, with `exitToStageId` → the secondary stage — AND gate this stage's `Yes` completion row with the inverse `IF`. The lane returns via `return-to-origin`. Omitting the divert row → dual-fire or deadlock. See sdd-generation-rules § Logical integrity step 5.
 
 | WHEN | IF | Exit Type | Marks Stage Complete | Display Name |
 |------|-----|-----------|---------------------|--------------|

package/skills/uipath-maestro-case/assets/templates/sdd-viewer.html

@@ -511,10 +511,11 @@
       "stages": [
         {
           "name": string,
-          "type": "Stage" | "ExceptionStage",
+          "type": "Stage",
+          "stageType": "primary" | "secondary" | null,   // omit/null = primary, "secondary" = secondary/exception stage
           "description": string,
           "requiredForCompletion": boolean,
-          "interrupting": boolean | null,     // ExceptionStage only
+          "interrupting": boolean | null,     // secondary stages only (stageType === "secondary")
           "entryConditions": [{ "when": string, "if": string, "interrupting": "Yes"|"No", "displayName": string }],
           "exitConditions":  [{ "when": string, "if": string, "exitType": string, "marksComplete": "Yes"|"No", "displayName": string }],
           "sla": { "count": number, "unit": string, "atRiskPct": string, "atRiskAction": string, "breachAction": string } | null,
@@ -827,7 +828,7 @@
       }));
       const stageNodes = stages.map((s, i) => ({
         id: "s-" + i,
-        kind: s.type === "ExceptionStage" ? "exception" : "stage",
+        kind: (s.stageType === "secondary" || s.type === "ExceptionStage") ? "exception" : "stage",
         label: s.name || "(unnamed)",
         sub: pluralize((s.tasks || []).length, "task") + (s.sla ? ` · SLA ${s.sla.count}${s.sla.unit}` : ""),
         stageIdx: i,
@@ -1007,7 +1008,7 @@
         glyph.setAttribute("fill", stroke);
         glyph.setAttribute("font-weight", "600");
         glyph.setAttribute("text-transform", "uppercase");
-        glyph.textContent = n.kind === "trigger" ? "TRIGGER" : (n.kind === "exception" ? "EXCEPTION" : "STAGE");
+        glyph.textContent = n.kind === "trigger" ? "TRIGGER" : (n.kind === "exception" ? "SECONDARY" : "STAGE");
         g.appendChild(glyph);
 
         // label
@@ -1053,7 +1054,7 @@
       legend.innerHTML =
         '<span><span class="swatch" style="background:#fff1ea;border-color:#fa4616"></span>Trigger</span>' +
         '<span><span class="swatch" style="background:#ffffff;border-color:#cdd2d9"></span>Stage</span>' +
-        '<span><span class="swatch" style="background:#fef2f2;border-color:#ef4444"></span>Exception stage</span>' +
+        '<span><span class="swatch" style="background:#fef2f2;border-color:#ef4444"></span>Secondary stage</span>' +
         '<span><span class="swatch" style="background:transparent;border-color:transparent;border-bottom:2px dashed #ef4444"></span>Interrupting edge</span>' +
         '<span style="color:var(--text-subtle)">· Click a stage to jump to its detail card.</span>';
       wrap.appendChild(legend);
@@ -1070,7 +1071,7 @@
 
     function renderStage(stage, idx) {
       const id = "stage-" + slug(stage.name) || "stage-" + idx;
-      const isException = stage.type === "ExceptionStage";
+      const isException = stage.stageType === "secondary" || stage.type === "ExceptionStage";
       const collapsed = state.collapsedStages.has(idx);
       const root = el("div", {
         class: "stage" + (isException ? " exception" : "") + (collapsed ? " collapsed" : ""),
@@ -1085,7 +1086,7 @@
       const title = el("div", { class: "stage-title" }, [
         el("span", { class: "seq" }, "Stage " + (idx + 1) + " ·"),
         document.createTextNode(stage.name || "(unnamed)"),
-        el("span", { class: "stage-type" }, isException ? "Exception" : "Stage")
+        el("span", { class: "stage-type" }, isException ? "Secondary" : "Stage")
       ]);
       titleWrap.appendChild(title);
       const summary = el("div", { class: "stage-summary" });

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

@@ -43,6 +43,8 @@ After writing bindings to top-level `bindings[]`, regenerate `bindings_v2.json`.
 }
 ```
 
+> **Inline-built sibling exception (agent / api-workflow) — the one case where the shape's `<folderPath binding default>` placeholder does NOT take the caseplan default.** `value.folderPath.defaultValue` is **`"solution_folder"`** (resource identity), NOT the caseplan `folderPath` binding `default` (which is `""` for an inline sibling). `bindings_v2.json` keeps the `solution_folder` sentinel while the caseplan runtime `folderPath` stays `""` — they are intentionally decoupled. `value.name.defaultValue` and `metadata.subType` (`"Agent"` / `"Api"` per kind) follow the caseplan binding as usual. Full rationale: the inline-built-sibling decoupling blockquote later in this file.
+
 ### Connector resource entry
 
 ```json
@@ -124,10 +126,12 @@ With `bindings_v2.json` and IS cache in place, `uip solution resources refresh`
 
 All three required for `uip solution upload` and `uip maestro case debug` to work without "Resource is not configured" warnings.
 
+> **Inline-built siblings (agent / api-workflow) — `bindings_v2` identity and the caseplan runtime `folderPath` are DECOUPLED.** This is the one case where `bindings_v2.json` does NOT mirror the caseplan binding's `folderPath`. Keep the **resource identity** at the `solution_folder` sentinel everywhere it belongs — `bindings_v2.json` `key` (`"solution_folder.<name>"`) and `value.folderPath.defaultValue` (`"solution_folder"`), plus the caseplan `resourceKey` and the `resources/solution_folder/…` path. **BUT the caseplan task's `folderPath` binding `default` MUST be `""`** (co-located runtime folder), NOT the sentinel — `"solution_folder"` there fails at invocation with `folder not exist`. Prerequisite for deploy/debug: the sibling registered in the `.uipx`. Full rationale (deploy provisioning, runtime invocation): [agent/planning.md § Creating an Agent inline → Step 3 Binding](plugins/tasks/agent/planning.md#creating-an-agent-inline) / [api-workflow/planning.md § Step 3 Binding](plugins/tasks/api-workflow/planning.md#creating-an-api-workflow-inline).
+
 ---
 
 ## Cleanup on task or rule removal
 
-When any task or connector condition rule is removed and its root bindings are pruned (per [case-editing-operations.md](case-editing-operations.md) § Delete a node / § Delete a connector condition rule):
+When any task or connector condition rule is removed and its root bindings are pruned (per [case-editing-operations.md](case-editing-operations.md) § Delete a node / § Delete a condition rule / § Delete a task):
 
 1. After pruning root bindings, regenerate `bindings_v2.json` from the updated array.

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

@@ -0,0 +1,86 @@
+# Brownfield — Edit an Existing Case
+
+Targeted changes to an existing `caseplan.json`. Skips the Phase 0–6 build pipeline. Terminates at `validate`, then hands off to Phase 5 (debug) / Phase 6 (publish).
+
+> **Greenfield (new case from `sdd.md`) uses a different journey.** If `caseplan.json` does not yet exist, or the user wants to (re)build from a spec, see [planning.md](planning.md) → [implementation.md](implementation.md) → [phased-execution.md](phased-execution.md) instead.
+
+## 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 approval, no prototyping hard stop. Routing lives in [SKILL.md](../SKILL.md#routing--greenfield-vs-brownfield).
+
+## Pull latest first (before editing)
+
+Most "edit an existing case" requests mean a case **deployed in Studio Web**, not just a local file. Editing the local `caseplan.json` and re-publishing (Phase 6 `uip solution upload`) **overwrites server state** — if the case changed in Studio Web after the local copy was made, the upload silently clobbers those changes, with no diff and no conflict check. Reconcile **before** the first edit.
+
+1. **Determine where the case lives.** If not already known, AskUserQuestion: `Edit my Studio Web case (pull latest first)` (default) / `Edit a local-only project (no pull)`.
+2. **Lives in Studio Web (has a SolutionId)** → pull current server state into the working dir before editing:
+   - Standalone export: `uip solution download <SolutionId> -d <WorkingDir> --extract --output json` — exports the `.uis` archive and unpacks it; edit the extracted project.
+   - Already-linked local solution project: `uip solution project resync --project-name <ProjectName> --sync-option Sync --output json`.
+   - SolutionId unknown → ask the user for it; never guess.
+   - `--extract` / `resync` **overwrite the destination**. Run before any edit. If you have already edited the local copy this session, pulling discards those edits — confirm with the user first.
+3. **Local-only project (no SolutionId)** → proceed as today, no pull.
+4. The pull is a CLI boundary operation (like `uip solution upload`), not a Rule 13 artifact mutation — it runs once, before editing. After it, all edits resume via Read/Write/Edit only.
+
+Record the outcome (pulled from SW at `<SolutionId>`, or local-only) for the freshness note in [Completion Output](#completion-output).
+
+> **Do NOT regenerate from scratch.** SKILL.md Rule 6 ("always regenerate from scratch") is a greenfield/planning rule. Brownfield edits the file in place and preserves every node `id` / `elementId` — re-minting IDs breaks `=vars.*` references, conditions, and `entry-points.json`.
+
+## Large or sweeping edits
+
+Edit size never changes the journey — many edits still stay brownfield (in-place, IDs preserved). No complexity threshold escalates to greenfield. Batch multi-edit passes per [case-editing-operations.md § Per-section batch write contract](case-editing-operations.md#per-section-batch-write-contract--canonical): one `validate` at the end, not per edit.
+
+When an edit touches many nodes or reads like "rebuild this case", confirm scope first via AskUserQuestion — `Edit in place` (default) vs `Rebuild from an updated spec` (greenfield via [planning.md](planning.md), re-mints IDs). Only an explicit rebuild choice or a new/updated `sdd.md` escalates to greenfield.
+
+## Read this first
+
+- **All mutations via Read/Write/Edit only** (Rule 13). CLI never mutates the case file in place: metadata fetches (`uip maestro case tasks describe`, `uip maestro case spec`, `is resources/triggers describe`), `uip maestro case validate`, the pre-edit pull (`uip solution download` / `solution project resync` — see [§ Pull latest first](#pull-latest-first-before-editing)), and (on handoff) `uip solution resources refresh` / `uip solution upload` / `uip maestro case debug`. No `python`/`node`/`jq`/`sed`/`awk`/helper scripts touching the file.
+- **`id-map.json` may be absent.** When editing a `caseplan.json` not built in this session, the `id-map.json` sidecar may not exist. Read node IDs directly from `caseplan.json`; do not assume the sidecar is present. If absent, do not synthesize one.
+- **Connector edits need a metadata fetch first.** Adding/altering a connector-activity task or connector-bound rule requires `uip maestro case spec --type ...` (or `tasks describe`) before authoring the shape — never hand-author connector schemas. See [connector-integration.md](connector-integration.md).
+- **Cross-cutting mechanics** (ID generation, Pre-flight Checklist, expression prefixes, per-section batch contract) live in [case-editing-operations.md](case-editing-operations.md). This doc routes; that doc supplies the recipe.
+
+## Common edits
+
+| Edit | Operation + recipe |
+|---|---|
+| Add / insert a stage | [case-editing-operations.md § Add a node](case-editing-operations.md#add-a-node-trigger--stage) + [plugins/stages/impl-json.md](plugins/stages/impl-json.md). Every regular stage needs ≥1 entry condition (Step 10). |
+| Insert a stage between two existing stages | [case-editing-operations.md § Insert a stage between two existing stages](case-editing-operations.md#insert-a-stage-between-two-existing-stages) |
+| Add a task to a stage | [case-editing-operations.md § Add a task to a stage](case-editing-operations.md#add-a-task-to-a-stage) + the task type's [plugins/tasks/<type>/impl-json.md](plugins/tasks/) |
+| Bind / change a task input | [case-editing-operations.md § Bind an input](case-editing-operations.md#bind-an-input) + [bindings-and-expressions.md](bindings-and-expressions.md) |
+| Move a task to a different stage or lane | [case-editing-operations.md § Move a task to a different stage or lane](case-editing-operations.md#move-a-task-to-a-different-stage-or-lane) |
+| Remove / delete a task | [case-editing-operations.md § Delete a task](case-editing-operations.md#delete-a-task) |
+| Add / change a condition (4 scopes) | the matching [plugins/conditions/<scope>/impl-json.md](plugins/conditions/) |
+| Modify a condition rule in place (operator / expression / type) | [case-editing-operations.md § Modify a condition rule in place](case-editing-operations.md#modify-a-condition-rule-in-place) |
+| Delete a condition rule (plain or connector, any scope) | [case-editing-operations.md § Delete a condition rule](case-editing-operations.md#delete-a-condition-rule) |
+| Remove a case-exit completion / exit rule | [case-editing-operations.md § Delete a case-exit completion rule](case-editing-operations.md#delete-a-case-exit-completion-rule) |
+| Replace a placeholder task with a real one | [case-editing-operations.md § Replace a placeholder task with an enriched task](case-editing-operations.md#replace-a-placeholder-task-with-an-enriched-task) + [placeholder-tasks.md](placeholder-tasks.md) |
+| Re-sync a task whose source schema changed | [case-editing-operations.md § Re-sync a task after its source schema changed](case-editing-operations.md#re-sync-a-task-after-its-source-schema-changed) + the task type's [plugins/tasks/<type>/impl-json.md](plugins/tasks/) |
+| Repoint a non-connector task at a different resource (swap which process/agent it runs) | [case-editing-operations.md § Repoint a non-connector task at a different resource](case-editing-operations.md#repoint-a-non-connector-task-at-a-different-resource) + the task type's [plugins/tasks/<type>/impl-json.md](plugins/tasks/) |
+| Replace a trigger with a different type | [case-editing-operations.md § Replace a trigger with a different type](case-editing-operations.md#replace-a-trigger-with-a-different-type) |
+| Re-target an event trigger (same type, different event) | [case-editing-operations.md § Re-target an event trigger](case-editing-operations.md#re-target-an-event-trigger-same-type-different-event) |
+| Convert a Stage to/from an Exception Stage | [case-editing-operations.md § Convert a Stage to/from an Exception Stage](case-editing-operations.md#convert-a-stage-tofrom-an-exception-stage) |
+| Delete a node (incl. a stage with successors — repoint their entry conditions) | [case-editing-operations.md § Delete a node](case-editing-operations.md#delete-a-node) |
+| Delete a trigger (prune `entry-points.json` + In-arg variable cascade) | [case-editing-operations.md § Delete a node](case-editing-operations.md#delete-a-node) (Trigger branch, steps 5–6) |
+| Delete a connector condition rule | [case-editing-operations.md § Delete a condition rule](case-editing-operations.md#delete-a-condition-rule) (connector cascade, steps 4–6) |
+| Add SLA / escalation | [plugins/sla/impl-json.md](plugins/sla/impl-json.md) |
+| Modify / remove an SLA or escalation | [case-editing-operations.md § Modify or remove an SLA or escalation](case-editing-operations.md#modify-or-remove-an-sla-or-escalation) |
+| Add a global variable / argument | [plugins/variables/global-vars/impl-json.md](plugins/variables/global-vars/impl-json.md) |
+| Rename / delete a global variable or argument | [case-editing-operations.md § Rename or delete a global variable or argument](case-editing-operations.md#rename-or-delete-a-global-variable-or-argument) + [plugins/variables/global-vars/impl-json.md](plugins/variables/global-vars/impl-json.md) |
+| Change a variable's type or default | [case-editing-operations.md § Change a variable's type or default](case-editing-operations.md#change-a-variables-type-or-default) + [plugins/variables/global-vars/impl-json.md](plugins/variables/global-vars/impl-json.md) |
+
+## 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).
+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.
+
+## Completion Output
+
+Report: file path edited, what changed (nodes/tasks/conditions added/removed/modified), validation status, any placeholder tasks still unresolved, any connector connections the user must create, and a **freshness note** — whether the local copy was pulled from Studio Web first (so re-publish reflects current server state) or is a local-only project not synced from SW (re-publish overwrites whatever is on the server). Then AskUserQuestion "What's next":
+
+| Option | What it does |
+|---|---|
+| **Run debug session** | Phase 5 — executes the case for real (consent-gated, Rule 12). |
+| **Publish to Studio Web** | Phase 6 — `uip solution resources refresh` then `uip solution upload`, print DesignerUrl. |
+| **Done** (default) | Stop here. |
+| **Something else** | Free-form. |
+
+Do not run debug or publish without explicit selection. On selection, follow the existing [phased-execution.md](phased-execution.md) Phase 5 / Phase 6 contracts.

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

@@ -237,6 +237,11 @@ uip maestro case registry search <keyword> --filter "name:contains=Foo" --type a
 uip maestro case registry get <identifier>
 uip maestro case registry get <identifier> --type agent
 uip maestro case registry get <uiPathActivityTypeId> --type typecache-activities --connection-id <uuid>
+
+# --local: in-solution (offline) discovery of sibling projects (.uipx in cwd/parent/grandparent), no tenant/login
+uip maestro case registry list --local --output json
+uip maestro case registry search "<Name>" --type <agent|api> --local --output json    # matches by name (keyword); `agent` = agent sibling, `api` = api-workflow sibling
+uip maestro case registry get "<entityKey-or-projectId>" --type <agent|api> --local --output json   # matches by key, NOT name
 ```
 
 Resource types: `agent`, `process`, `api`, `processOrchestration`, `caseManagement`, `typecache-activities`, `typecache-triggers`, `action-apps`, `solution`.
@@ -262,6 +267,9 @@ Options for `get`:
 | `<identifier>` | **(required)** The entityKey (process types), id (action-apps), or uiPathActivityTypeId (typecache) of the resource |
 | `-t, --type <type>` | Limit to a specific resource type |
 | `--connection-id <id>` | Connection UUID for connector-specific IS field metadata. Only applies to `typecache-activities` / `typecache-triggers` results |
+| `--local` | Resolve against in-solution sibling projects (offline; no login). On `list`/`search`/`get`. Local types: `agent`, `process`, `api`, `processOrchestration`, `caseManagement`. |
+
+**`--local` semantics.** Discovers sibling projects from the enclosing solution `.uipx` (walks cwd → parent → grandparent). Keys (`--output json`, PascalCased): `search`/`get` nest each match under `Data.Resources[].Resource.{EntityKey,Name,Category,Folders[].FullyQualifiedName,Inputs,Outputs,Source}`; `list` flattens to `Data.Resources[].{EntityKey,Name,Category,Source}` (no `Resource` wrapper, no I/O). **`get --local` matches the identifier only against `entityKey`/`.uipx` project Id — never the display name; to find a sibling by name use `search "<Name>" --local`.** A freshly-built, unpacked sibling's `EntityKey` equals its `.uipx` project Id. No solution found → `Result:"Failure"`, `Message:"No solution found for --local"`, exit 1.
 
 Output: `{ MatchCount, Resources: [{ ResourceType, Resource }] }`.