@uipath/skills 1.200.0 → 1.201.0-preview.433

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

@@ -1,87 +1,87 @@
 ---
 name: uipath-maestro-case
-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."
+description: "Always invoke for UiPath Maestro Case Management build work: `caseplan.json`, `sdd.md`, or building/creating a case when no SDD exists yet (the case design is produced first, then confirmed in one review). Produces tasks.md and authors or edits caseplan.json directly with Write/Edit. For .xaml→uipath-rpa, .flow→uipath-maestro-flow, .bpmn→uipath-maestro-bpmn. For standalone case SDD design, case `sdd.draft.md` finalization, PDD→SDD, or cross-product planning→uipath-planner."
 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.
+Build UiPath Case Management definitions from `sdd.md`. Generate `tasks.md`, then write `caseplan.json` directly using the applicable per-plugin JSON recipes.
 
-> **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.
+> **Authoring invariant:** Never use mutating `uip maestro case` commands (`cases|stages|tasks|*-conditions ... add|update|remove`, including `tasks add-connector`) or explore them with `--help`. Use the CLI only for scaffolding, metadata reads, validation/debug, runtime operations, and solution sync/upload. Consult [case-commands.md](references/case-commands.md) only when exact syntax is needed. CLI availability or a final `validate` requirement never overrides this rule.
 
-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.
+When `sdd.md` is absent, case design belongs exclusively to **`uipath-planner`**, which runs its Case Design Lane in this conversation. This skill never designs independently. The lane uses best-assumption design, Listen → Sketch → full design-time tenant resolution, a mandatory other-path sweep, and one decision-first eight-section Case Review. Its Build answer is consent; it writes template-conformant `sdd.md`, then this skill continues immediately with `uip solution init`, Phase 1, and later phases. The same handoff applies to `sdd.draft.md` finalization. Never overwrite an existing `sdd.md`.
 
-**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).
+**Scope:** greenfield builds from `sdd.md` and brownfield targeted edits to an existing `caseplan.json`; see [references/brownfield.md](references/brownfield.md). For Studio Web cases, pull current server state first with `uip solution download` or `solution projects resync` so publishing cannot clobber server changes.
 
 ## When to Use This Skill
 
-- User provides `sdd.md` and wants Case Management project built
-- 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)
+Use for:
 
-**Do not use for:** `.xaml` → `uipath-rpa`. `.flow` → `uipath-maestro-flow`. Standalone agents/APIs/processes outside case context → corresponding UiPath skill.
+- Building a Case Management project from `sdd.md`.
+- Creating a case when no SDD exists; hand design to `uipath-planner` in this conversation.
+- Generating implementation tasks from an SDD.
+- Editing an existing `caseplan.json` by targeted intent: stage/task changes, conditions, or triggers.
+- Questions about case JSON schema, nodes, transitions, tasks, rules, SLA, or runtime case instances.
+
+Do not use for `.xaml` → `uipath-rpa`, `.flow` → `uipath-maestro-flow`, or standalone agents/APIs/processes outside case context.
 
 ## 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` 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. **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. **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.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 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. **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
+1. **Design handoff and SDD authority.** If `sdd.md` is absent, immediately invoke `uipath-planner`’s Case Design Lane in this conversation, before reading references or running tenant commands. Do not improvise interviews, design subagents, generic Build Plan approvals, or design-only behavior here. The lane’s single Case Review has exactly these sections: Case Snapshot; Primary Journey; Other Paths Considered; SLA and Escalations; Rules and Outcomes; Resources and Integrations with design-time resolutions; Decisions I Made; Review Flags. It names every stage/task, type, activation/grouping, required status, routing/outcome, and SLA context; `sdd.md` separately contains the complete data contract, variables, and task inputs/outputs. The Build options incorporate Rule 11, and the Build answer is the sole consent. Corrections re-show only changed review sections. Before approval, every `selected-tasks-completed` selector must resolve to a non-adhoc sibling in the same stage. The lane writes `sdd.md` early, then this skill runs `uip solution init <SolutionName>` and Phase 1 without another prompt unless explicitly requested. If the request asks only for `sdd.md` plus `tasks/tasks.md`, write compact `tasks/tasks.md` after Save/Build, do not read plugin references or run tenant discovery, and stop before `caseplan.json`. If `sdd.draft.md` is to be finalized, use the lane fast path with target basename `sdd.md`. Never overwrite `sdd.md`.
+2. **SDD is the sole post-design input, across sessions.** Trust user-provided or previously written `sdd.md`; do not validate, gap-fill, or silently infer it. In the same conversation as design approval, use the in-memory model that wrote it without rereading. Use AskUserQuestion for build-phase ambiguity. Run a one-Grep receipt spot-check before reading an SDD not watched being written: it must contain `## Section 1: Case Definition` through `## Section 4: Integrations` and at least one `##### Task` block. Freeform/summary SDDs go back through the planner template-conformance gate.
+3. **Phase 1 registry gate.** Run `uip login status --output json`, then `uip maestro case registry pull`, before cache inspection, carryover, resolution, or Phase 1 writes. Pull at most once per session. If the planner lane ran in this session, its pull succeeded, and it wrote the SDD, reuse the cache. With the lane’s in-context resolution outcomes, use verify-only planning: persist them verbatim to `tasks/registry-resolved.json`, spot-check cache entries, execute gate decisions, and re-resolve only stale/missing entries. Otherwise run the full gate. Login/pull failure stops Phase 1. Read `~/.uip/case-resources/<type>-index.json` directly; `registry search` has known gaps, especially action-apps. Before a successful pull, missing cache files are failed refresh preconditions, never zero matches; only after success may empty exact-name matches or absent indexes enter empty-lookup handling. Trust the SDD; the pull refreshes discovery only. The planner lane owns design-time resolution, lazily starting login/pull when tenant-bound work first appears, resolving identities with one batched Case Review gate, and recording SDD cells plus its resolution ledger. No schema discovery occurs there.
+
+   **Plan-only exception:** when explicitly stopping at `sdd.md`, `sdd.draft.md`, or `tasks.md` without `caseplan.json`, solution, or build, do not run tenant registry, connection, schema, or user-discovery commands. Preserve intended names, mark identities `resolve at build`, and report deferred wiring. This exception does not apply when the user requests resource/identity resolution, registry refresh, stale-audit replacement, `tasks/registry-resolved.json`, or `tasks/recipients-resolved.json`; then run the normal gate, resolve identities, emit build-path `tasks.md`, and stop at the Rule 7 plan gate.
+4. **Parsed reads require `--output json`.**
+5. **Use plugin references.** Read the matching plugin `planning.md` during planning and `impl-json.md` during execution; never guess JSON shapes.
+6. **`tasks.md` is declarative and lossless.** No shell commands. Use plain field identifiers, not CLI flags. Create one T-entry for every SDD stage, task, trigger, condition, SLA rule, variable, and argument, including explicit defaults. Preserve every valid explicit rule/selector exactly; reject and repair invalid `selected-tasks-completed` selectors. Preserve stage/task/SLA `Design Rationale` and condition routing/activation rationales as `rationale:`. Preserve every Inputs row, binding mode, and value. Preserve JSON object literals exactly: native object or JSON-encoded string in `input.value`; add `=js:`/`=jsonString:` only when explicitly present in the SDD. Project Outputs through [`plugins/variables/io-binding/planning.md`](references/plugins/variables/io-binding/planning.md#sdd-outputs-table-to-tasksmd-projection-mandatory), preserving operator and operands. SDD output rows require `->` or `=`; schema-discovered bare outputs are not authored SDD rows. Never simplify equal-name `->` rows; `greeting -> greeting` differs from schema-discovered bare `greeting`. `—` placeholders are not operands. AskUserQuestion for unrecognized or ambiguous rows; never omit silently. Regenerate greenfield plans from scratch; brownfield edits preserve IDs. Every §4.6 task entry has its own `activation-mode:` and `entry-rule:` — repeat this per task, never author it once and drop it for later similar tasks; `validate` only warns `Task has no entry rules`, while a miss hangs `case debug` indefinitely. Every task heading is exactly `## T<n>: Add <type> task "<name>" to "<stage>"`. See [references/planning.md §4.0](references/planning.md) and the [Plan-shape gate](references/planning.md#step-5--finalize-tasksmd-auto-proceed-to-phase-2).
+7. **Plan gate.** Phase 1 auto-proceeds to Phase 2 and treats the plan as approved. Stop after `tasks.md` only when the request explicitly says plan-only, Phase 1 only, review first, or not to build. Re-read `tasks.md` before execution.
+8. **Unresolved resources.** Never fabricate IDs. Keep `<UNRESOLVED: ...>` in `tasks.md`. A placeholder task has `type`, `displayName`, structural fields, and `data: {}`; conditions still reference its TaskId. A placeholder event trigger has render fields and only `data.inputs: { serviceType: "Intsvc.EventTrigger" }`; append its `entry-points.json` entry and create no trigger edge. See [references/placeholder-tasks.md](references/placeholder-tasks.md) and [references/plugins/triggers/event/impl-json.md](references/plugins/triggers/event/impl-json.md).
+9. **Resolution audit.** Persist one object per task in `tasks/registry-resolved.json` with exact keys `stage`, `task`, `taskType`, `cacheFile`, `searchQuery`, `matches`, `selected`, and `rationale`, plus resolved I/O/review metadata. Add `gateDecision` only when the user answered the design-time resource gate; default deferrals have none. `matches` is the complete exact-name set from the refreshed cache; `selected` is a match or `null` after a genuine empty lookup. Same-session planner ledgers are persisted verbatim, then verified/extended under Rule 3. The resolution ledger and `registry-resolved.json` are machine-only — never shown to the user, including in the Case Review.
+10. **Cross-task references.** Use `"Stage Name"."Task Name".output_name` and the common output-reference-ID algorithm in [`plugins/variables/io-binding/impl-json.md`](references/plugins/variables/io-binding/impl-json.md#output-reference-id-authoritative). Use the source output’s `.id`; only a custom `=` output without `.id` uses its verified root companion’s `.id`. Never use a reassigned output’s `.var`. Discover names with `uip maestro case spec` for connector tasks or `uip maestro case tasks describe` for non-connectors. In larger `=js:` expressions use `vars.$xref('Stage','Task','output')`, resolved at Step 11.5. See [references/bindings-and-expressions.md](references/bindings-and-expressions.md).
+11. **Build-review preference.** Capture once at journey start. Design handoff folds it into the Case Review Build options (`Build it — straight through` or `Build it — pause at the build preview`); provided SDD asks once after the roadmap. Non-interactive and resumed runs without a preference default to straight-through. At Phase 2→3, try `validate --skeleton-v2`; fall back once to legacy `--skeleton` only when the response explicitly says v2 is unknown/unsupported, typically invalid_argument/exit 3. Exit 3 alone is insufficient; real v2 failures are reported. Validation findings do not halt this advisory gate. Straight-through continues without prompting. Pause-at-preview follows [references/phased-execution.md](references/phased-execution.md): AskUserQuestion `Publish for review` / `Skip publish and continue` / `Abort`; on publish, refresh resources, upload with the required filter, print `DesignerUrl` before the follow-up, then ask `Continue to implementation` / `Abort`. Hard stops always remain at Phase 4 retry exhaustion, Phase 5, Phase 6, and Phase 7.
+12. **Never auto-debug or publish to Orchestrator.** `uip maestro case debug` executes real emails, messages, and API calls. Phase 7 (`case pack` → `solution pack` → `solution publish`) ships to the tenant. Each requires its own AskUserQuestion consent.
+13. **Artifact I/O.** For `caseplan.json`, `sdd.md`, `sdd.draft.md`, `tasks.md`, `tasks/registry-resolved.json`, `tasks/trigger-spec-cache.json`, `tasks/spec-cache.<elementId>.json`, `bindings_v2.json`, `id-map.json`, `entry-points.json`, and `build-issues.md`, use only Read and Write/Edit. No Python, Node, jq, sed, awk, scripts, shell redirection, `tee`, `cp`, `mv`, `install`, or `rsync`; no helper scripts, including under `/tmp`. The `node -e ... fs.*` ban covers all file reads, including `~/.uip/case-resources/`; use Read or `cat ... | python3 -c ...` for cache lookup. If `caseplan.json` exceeds about 30KB, use the preview/detail cadence in [case-editing-operations.md](references/case-editing-operations.md), never a helper. Bash is allowed only for UUID v4 generation without filesystem access, CLI metadata, validate, debug, and solution scaffold/upload. Prefixed IDs are chosen inline.
+14. **Runnable resources and sidecars.** Before Phase 4, run Step 12 Checks 7, 9, 11, and 12 even when publish, debug, or resource refresh is skipped. A non-null `selected` resource must not become a placeholder: retain `data.name` and `data.folderPath` with complete root bindings, project it into `bindings_v2.json.resources[]`, and make its `resourceKey` self-consistent with its own defaults, never a copied tenant identity/UUID. Checks 9/11 exempt connector nodes; Check 12 covers resolved connector tasks, event triggers, and `wait-for-connector` rules, which require spliced `caseShape.context` plus Connection/Folder root bindings, not degraded typeId/connectionId-only data. CLI validate is insufficient. Repair and recheck mismatches; halt before Phase 4 if they remain. Repeat Check 7 before every `resources refresh`. Refresh before every upload or debug. Every upload uses `--output-filter "{Status: Status, SolutionId: SolutionId, DesignerUrl: DesignerUrl}"`; print the returned DesignerUrl.
+15. **Handoff contract.** Invoke `uipath-planner`’s Case Design Lane in this conversation, never as a subagent. It owns design, resolution, review, and SDD writing; this skill resumes at solution initialization. User-facing language presents one continuous flow and never mentions the handoff. If unavailable, say so in one line, request `sdd.md` or an approved pasted design, and stop. Cross-product planning remains a plain-text suggestion to the planner. Apply the Rule 15 receipt spot-check before unobserved SDD reads.
+16. **Closed task types.** `caseplan.json` task `type` must be exactly one of: `process`, `agent`, `rpa`, `action`, `api-workflow`, `case-management`, `execute-connector-activity`, `wait-for-connector`, `wait-for-timer`. Never use plugin folder or CLI names, `external-agent`, `external-workflow`, `document-extraction`, `flow-process`, `wait-for-event`, or other invented values. The unsupported types remain unsupported. See [references/case-schema.md](references/case-schema.md) and the Plugin Index.
+17. **Empty lookup gate.** If the same-session ledger has a user `gateDecision`, execute it without asking again: `resolve-at-build` → placeholder; `create-during-build` → inline create; `pick:<name>` → bind it. A missing decision is a default deferral, not consent; run the full gate. For zero matches, use one batched AskUserQuestion grouped by `(name,type)` with: `Force pull and re-resolve`; `Use placeholders for all`; and, only when creatable resources exist and `registry --local` is supported, `Create missing resources inline`. Create only selected `agent` or `api-workflow` resources, invoking `uipath-agents` or `uipath-api-workflow`; never infer Create from SDD content. Other empty types remain placeholder-only. Selected resources with identical I/O may share one build; differing I/O splits later with the anchor retaining the name, and SDD updates require permission. See [registry-discovery.md § 1c](references/registry-discovery.md#1c--dedup-the-selected-builds-one-resource-per-name-and-type), [Create-on-Missing](references/registry-discovery.md#create-on-missing-build-and-rediscovery), and [§ MUST Confirm](references/registry-discovery.md#must-confirm-before-placeholder-fallback).
+18. **Layout.** Emit top-level `layout: {}` only. Do not emit node `position`, `style`, `measured`, `width`, `height`, `zIndex`, or edge `data.waypoints`; do not compute positions.
+19. **Global output IDs.** Run Step 12 Check 8 once at Phase 3 exit. It is mandatory; do not enter Phase 4 until it passes and do not substitute CLI validate.
+20. **No authored edges.** Keep `schema.edges` as `[]`; never author TriggerEdge/Edge objects. Conditions provide stage flow; the first stage uses `case-entered`. Read-only edge shapes are documented in [case-schema.md Appendix](references/case-schema.md#appendix--edge-shapes-read-only--never-author).
+21. **Global events and SLA responses.** Model a global external event once as an interrupting secondary-stage `wait-for-connector` entry. Choose SLA response explicitly: `notify-only`, `start-task`, `enter-stage`, `exit-stage`, or `exit-case`. A `start-task` response belongs on the follow-up task’s own `sla-status-change` entry, not a stage entry. Interrupting depends on whether active work stops, pauses, or reroutes; parallel oversight uses `Interrupting: No` and remains secondary. `sla-status-change` names `slaId`; add `escalationId` only for at-risk responses. Without a stated response, at-risk and breach are notifications. Do not replicate rules across primary stages. See [references/sla-response-shapes.md](references/sla-response-shapes.md) and the SLA Response Map.
+22. **Formal argument IDs.** `variables.inputs[].id` and `variables.outputs[].id` must be synthetic `v` + 8 characters and distinct from `name`/`var`; never copy companion names. Run Step 12 Check 10 once at Phase 3 exit and non-interactively re-mint violations. CLI validate does not check this. See [global-vars/impl-json.md § Formal-arg slot ID format](references/plugins/variables/global-vars/impl-json.md#formal-arg-slot-id-format).
+23. **Never run `uip maestro case init`.** It may create a second solution and separate manifest. Use `uip solution init <SolutionName>` and the T01 direct-JSON scaffold in [implementation.md § Step 6](references/implementation.md#step-6--create-the-case-project-structure). See [case-commands.md § case init](references/case-commands.md#uip-maestro-case-init).
+24. **Read references to EOF before mutation.** Every `references/*.md` ends with `<!-- END: <filename> -->`. Before the first Write/Edit using a shape, procedure, constraint, or verification rule, Read that exact reference until its exact END marker appears in tool output during this session. Ranges, truncation, search hits, tables of contents, memory, and sibling references do not satisfy this. Reopen after compaction or when the prior read is unavailable. Keep reads modest to avoid output truncation. Tail contracts are normative.
+25. **Unique labels and task names.** Stage `data.label` values are unique case-wide; task `displayName` values are unique across all stages, exact and untrimmed, and contain no `:`. A missing display name binds to the resource name and participates in uniqueness. Assign names in Phase 1; later renaming touches the SDD, plan, ID map, and name-keyed references.
+
+## Routing
 
 | 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.
+| New case, SDD provided, no caseplan, or rebuild from spec | **Greenfield:** handoff if needed, then Phases 1–7 |
+| Existing caseplan and targeted edit intent | **Brownfield:** skip handoff and Phases 1–7; use [brownfield.md](references/brownfield.md) |
 
-## User-facing roadmap — required at skill start
+Brownfield still requires latest-state pull, debug consent, and Orchestrator-publish consent, and reuses Phase 5–7 contracts.
 
-After routing and before detailed questions or build work, print one short roadmap tailored to the selected journey. Use business language; do not expose internal Phase numbers, mode names, filenames, or implementation mechanics.
+## User-Facing Roadmap
 
-| 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 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.` |
+Print once, after routing and before detailed work, in five lines or fewer. Do not expose phases, modes, filenames, or implementation mechanics.
 
-Keep the roadmap to five lines or fewer. Print it once per invocation; do not repeat it at every hard stop.
+- **New case without 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 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:** `1. Pull the latest case. 2. Apply the requested change. 3. Validate the updated case. 4. Ask before running or publishing anything.`
 
 ## Workflow
 
-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).
+Front-load decisions, then run unattended to consent gates:
 
-### Kickoff — set dev expectations first
+**Design handoff when required → Phase 1 Planning → Phase 2 Prototyping → Phase 3 Implementation → Phase 4 Validate → Phase 5 Publish → Phase 6 Debug → Phase 7 Publish to Orchestrator.**
 
-Before any planning or build work, present the flow once so the dev knows the steps and where they'll be asked to decide. Emit the matching block below verbatim in tone (adjust wording to fit context; keep the checkpoint markers). Present ONCE per run — at Phase 0 start if the interview runs, else at Phase 1 start. Allow-listed standalone text block (Anti-patterns token cap); do not repeat it at later phases.
+At invocation start, present once the matching kickoff block below, at handoff start or Phase 1 start. Status text must follow the Anti-patterns limits.
 
-**Greenfield** (building a new case):
+**Greenfield kickoff:**
 
 > 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.
@@ -90,117 +90,106 @@ Before any planning or build work, present the flow once so the dev knows the st
 > - **Validate** — I run validation and fix errors.
 > - **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).
+> - **Publish to Orchestrator** (optional) — **you choose** whether to publish the case to Orchestrator.
 
-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).
+For handoff, prefix: `First I'll design the case from what you've given me — checking your UiPath tenant along the way — and show one decision-first review packet with the case snapshot, primary journey, other paths, SLA responses, business rules, resources, and every decision made — one confirmation, then I build; the full technical design doc (sdd.md) is saved alongside for reference.`
 
-### Phase 0 — Interview (conditional)
+For brownfield, use the short entry flow in [references/brownfield.md](references/brownfield.md).
 
-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:
+### Design handoff
 
-> **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. 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
-- `sdd.draft.md` — only on an explicit draft request; `tasks/registry-resolved.json` is written by Phase 1, not Phase 0
-
-If `sdd.md` already exists: skip Phase 0, hand to Phase 1 unchanged.
+The trigger is binary: if no `.md` whose basename contains `sdd` exists at the resolved path, hand off. If the prompt names another SDD basename, copy it to `./sdd.md` using Read + Write; do not invoke the lane. If no `.md` is named, use `./sdd.md`. Do not read planning/plugin references or run tenant commands before the Case Review. For an explicit no-build design+plan request, write `sdd.md` and compact `tasks/tasks.md` after approval, without plugin references, schema, registry, connection, or user discovery, then stop. Planner-owned drafts and `sdd-viewer.html` stay with the planner. If unavailable, request an SDD and stop.
 
 ### Phase 1 — Planning
 
-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 projects 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).
+Read [references/planning.md](references/planning.md) to produce:
 
-> **`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.
+- `tasks/tasks.md`: T-numbered stages, tasks, conditions, SLA, variables, and arguments.
+- `tasks/registry-resolved.json`: complete resolution audit.
+- If Create is selected at Rule 17: build selected agents/API workflows as in-solution siblings through the permitted sub-agent paths, ensure a solution exists, register them, refresh resources, rediscover, and bind them. See [registry-discovery.md § Create-on-Missing](references/registry-discovery.md#create-on-missing-build-and-rediscovery).
 
-Auto-proceed to Phase 2 (re-read `tasks.md` first) — plan treated as approved. Stop after `tasks.md` only if the request explicitly asked for a plan-only / review-first run (Rule 7).
+`tasks/` is adjacent to `sdd.md`, never inside the solution/project. Auto-proceed to Phase 2 unless the request explicitly asks to stop for plan review. Re-read `tasks.md` first.
 
 ### Phase 2 — Prototyping
 
-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:
+Read [references/implementation.md](references/implementation.md) and [references/phased-execution.md](references/phased-execution.md). Follow Steps 6–11.9:
 
-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 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. 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).
+1. Step 6: `uip solution init`, project, and root case (T01 direct-JSON recipe in [plugins/case/impl-json.md](references/plugins/case/impl-json.md)); never `case init`.
+2. Step 6.1: manual, timer, and event triggers, including Rule 8 placeholders; capture trigger IDs.
+3. Step 6.2: global variables and arguments; In-argument `elementId` references the trigger named by `sourceTriggers`, or the primary trigger when blank.
+4. Step 6.3: synchronize `entry-points.json` from declared In/Out arguments per [entry-points-sync.md](references/entry-points-sync.md). Emit the `job-attachment` `definitions` block byte-for-byte from that reference — reproduce its `MimeType.description` inner quotes exactly (single-`\"` escaping); never re-escape (`\\"`) or rebalance them, or the JSON breaks.
+5. Step 7: stages.
+6. Step 9: task shapes; non-connectors get complete `data.inputs[]` with empty values, connectors only `typeId`/`connectionId`, unresolved resources use placeholders.
+7. Step 11: SLA/escalation objects with stable IDs.
+8. Step 10: all four condition scopes; connector waits use canonical stubs regardless of resolution.
+9. Step 11.9: informational skeleton validation with Rule 11 fallback behavior.
+10. Apply the Phase 2→3 preference. Preview branch uses resource refresh, filtered solution upload, printed DesignerUrl, and the prescribed continuation gate; Abort writes `build-issues.md` and exits.
 
 ### Phase 3 — Implementation
 
-Re-read `tasks.md` AND `caseplan.json` (Step 9.6). Then:
+Re-read `tasks.md` and `caseplan.json` (Step 9.6), then follow Steps 9.7, 9.8, 10.5, and 11.5:
 
-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. 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)
+1. Resolve connector schemas/defaults with `uip maestro case spec`.
+2. Bind I/O for all task classes using [io-binding/impl-json.md](references/plugins/variables/io-binding/impl-json.md).
+3. Upgrade resolved connector-bound condition stubs in place; unresolved connectors retain stubs and are reported.
+4. Resolve in-expression `vars.$xref` markers.
+5. Perform resolved-resource emission, preservation, resourceKey, and connector completeness checks.
 
-No hard stop on Phase 3 exit — proceed directly to Phase 4.
+Proceed directly to Phase 4 after the Phase 3 checks pass.
 
 ### Phase 4 — Validate
 
-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)
+Run Step 12 once at the Phase 3 boundary. It performs Checks 1–15, including Check 7 sidecar parity, Check 8 global output-ID uniqueness, Check 9 resource emission/preservation, Check 10 formal-arg IDs, Check 11 resourceKey consistency, Check 12 connector completeness, and Check 15 every task carrying a non-empty entry rule (`validate` only warns on a missing one). Then run full `uip maestro case validate`. Retry at most three times, with an edit before every retry; on the third failure, hard-stop with AskUserQuestion: `Retry with fix` / `Pause for manual edit` / `Abort`. Summarize `build-issues.md` using Step 12.1.
 
 ### Phase 5 — 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.
+Provide the completion report, then hard-stop AskUserQuestion: `Publish to Studio Web` / `Skip to Debug` (Step 13). On publish, refresh resources and upload with the mandatory output filter, print DesignerUrl, and continue to Phase 6 either way.
 
 ### Phase 6 — Debug
 
-**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`.
+Hard-stop AskUserQuestion (Step 15): `Run debug session` / `Continue to publish`. On Run, refresh resources, run `uip maestro case debug`, and loop after completion until `Continue to publish`. Never run debug automatically.
+
+### Phase 7 — Publish to Orchestrator
+
+Hard-stop AskUserQuestion (Step 16): `Publish to Orchestrator` / `Done`. On publish, run in order:
+
+1. `uip solution resources refresh`
+2. `uip maestro case pack <SolutionDir>/<ProjectName> <SolutionDir>/dist --output json`
+3. `uip solution pack <SolutionDir> <SolutionDir>/dist --output json`
+4. `uip solution publish <packagePath> --wait --output json`
+
+`case pack` is mandatory because it creates `caseplan.json.bpmn`; `validate` does not. Publish the `solution pack` `.zip`, not the case `.nupkg`; read `<packagePath>` from `Data.Packages`, never guess. `Done` exits.
 
 ## Reference Navigation
 
-| I need to... | Read |
+| Need | Reference |
 |---|---|
-| 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) |
-| 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) |
-| Resolve task types from registry | [references/registry-discovery.md](references/registry-discovery.md) |
-| Wire inputs/outputs + cross-task refs + expression prefixes | [references/bindings-and-expressions.md](references/bindings-and-expressions.md) |
-| Configure connector activity / trigger / event | [references/connector-integration.md](references/connector-integration.md) |
-| 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) |
+| Design without SDD | `uipath-planner` Case Design Lane; Rule 15 |
+| Plan from SDD | [references/planning.md](references/planning.md) |
+| Execute plan | [references/implementation.md](references/implementation.md) |
+| Brownfield edit | [references/brownfield.md](references/brownfield.md) |
+| Phase contracts | [references/phased-execution.md](references/phased-execution.md) |
+| Edit mechanics | [references/case-editing-operations.md](references/case-editing-operations.md) |
+| Schema | [references/case-schema.md](references/case-schema.md) |
+| Allowed CLI | [references/case-commands.md](references/case-commands.md) |
+| Troubleshooting | [references/troubleshooting-guide.md](references/troubleshooting-guide.md) |
+| Registry resolution | [references/registry-discovery.md](references/registry-discovery.md) |
+| Bindings/expressions | [references/bindings-and-expressions.md](references/bindings-and-expressions.md) |
+| Connector integration | [references/connector-integration.md](references/connector-integration.md) |
+| Case spec input details | [references/case-spec-input-details.md](references/case-spec-input-details.md) |
+| Placeholders | [references/placeholder-tasks.md](references/placeholder-tasks.md) |
+| Bindings sidecar | [references/bindings-v2-sync.md](references/bindings-v2-sync.md) |
+| Prune orphaned solution resource | [bindings-v2-sync.md § Prune orphaned solution resources](references/bindings-v2-sync.md#prune-orphaned-solution-resources) |
+| Entry points | [references/entry-points-sync.md](references/entry-points-sync.md) |
+| SLA responses | [references/sla-response-shapes.md](references/sla-response-shapes.md) |
 
 ### Plugin Index
 
-**Structural:**
+**Structural:** [case/planning.md](references/plugins/case/planning.md), [stages/planning.md](references/plugins/stages/planning.md), [sla/planning.md](references/plugins/sla/planning.md), [global-vars/planning.md](references/plugins/variables/global-vars/planning.md), [io-binding/planning.md](references/plugins/variables/io-binding/planning.md), and [logging/impl-json.md](references/plugins/logging/impl-json.md).
 
-| Plugin | Scope |
-|--------|-------|
-| [case](references/plugins/case/planning.md) | Root case (T01) |
-| [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 |
-| [logging](references/plugins/logging/impl-json.md) | Shared issue log |
+**Tasks:**
 
-**Tasks** (`references/plugins/tasks/`):
-
-> **Naming asymmetry — read carefully.** Three names exist for connector + timer tasks. Pick the right one by column. Schema-kebab is the only value that goes into `caseplan.json` `type` (Rule 16).
-
-| sdd.md `Type:` value / caseplan.json `type` (schema-kebab) | Plugin folder | CLI `--type` flag (`tasks describe`) |
+| Schema `type` / SDD value | Plugin planning reference | CLI describe type |
 |---|---|---|
 | `process` | [process](references/plugins/tasks/process/planning.md) | `process` |
 | `agent` | [agent](references/plugins/tasks/agent/planning.md) | `agent` |
@@ -210,51 +199,30 @@ Completion report + **HARD STOP** AskUserQuestion (Step 13): `Publish to Studio
 | `case-management` | [case-management](references/plugins/tasks/case-management/planning.md) | `case-management` |
 | `execute-connector-activity` | [connector-activity](references/plugins/tasks/connector-activity/planning.md) | `connector-activity` |
 | `wait-for-connector` | [connector-trigger](references/plugins/tasks/connector-trigger/planning.md) | `connector-trigger` |
-| `wait-for-timer` | [wait-for-timer](references/plugins/tasks/wait-for-timer/planning.md) | `wait-for-timer` (no CLI describe needed) |
-
-**Triggers** (`references/plugins/triggers/`):
+| `wait-for-timer` | [wait-for-timer](references/plugins/tasks/wait-for-timer/planning.md) | `wait-for-timer` |
 
-| Plugin | When |
-|--------|------|
-| [manual](references/plugins/triggers/manual/planning.md) | User-initiated start |
-| [timer](references/plugins/triggers/timer/planning.md) | Scheduled start |
-| [event](references/plugins/triggers/event/planning.md) | External connector event |
+Schema-kebab is the only JSON value; plugin and CLI names are not interchangeable. Unsupported types include `external-agent`, `external-workflow`, `document-extraction`, `flow-process`, and `wait-for-event`.
 
-**Conditions** (`references/plugins/conditions/`):
+**Triggers:** [manual](references/plugins/triggers/manual/planning.md), [timer](references/plugins/triggers/timer/planning.md), and [event](references/plugins/triggers/event/planning.md).
 
-| Plugin | Scope |
-|--------|-------|
-| [stage-entry-conditions](references/plugins/conditions/stage-entry-conditions/planning.md) | Stage entered |
-| [stage-exit-conditions](references/plugins/conditions/stage-exit-conditions/planning.md) | Stage exits |
-| [task-entry-conditions](references/plugins/conditions/task-entry-conditions/planning.md) | Task starts |
-| [case-exit-conditions](references/plugins/conditions/case-exit-conditions/planning.md) | Case completes/exits |
+**Conditions:** [stage-entry-conditions](references/plugins/conditions/stage-entry-conditions/planning.md), [stage-exit-conditions](references/plugins/conditions/stage-exit-conditions/planning.md), [task-entry-conditions](references/plugins/conditions/task-entry-conditions/planning.md), and [case-exit-conditions](references/plugins/conditions/case-exit-conditions/planning.md).
 
-> **Connector-bound rules:** a `wait-for-connector` rule in any condition scope must carry the connector configuration under `rule.uipath` (built from `case spec --type trigger`, like the connector-trigger task) — bare connector rules are invalid in Studio Web and are NOT caught by CLI `validate`. See [connector-trigger-common.md § Target: connector-bound condition rule](references/connector-trigger-common.md#target-connector-bound-condition-rule).
+Connector-bound rules in any condition scope require `rule.uipath` built from `case spec --type trigger`; bare connector rules are invalid in Studio Web even when CLI validate passes. See [connector-trigger-impl.md](references/connector-trigger-impl.md).
 
 ## 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).
-- **Do NOT emit standalone text-only assistant turns between tool calls.** Status/progress text MUST share its turn with the next `tool_use` (text block + tool_use block in the same assistant content array). Standalone narration turns each pay full inference latency + prompt cache replay (~5s + ~250K cache-read tokens per turn) for no incremental progress. Cap inline status to ≤1 sentence / ~20 tokens. Per-T-entry audit lives in TaskUpdate, NOT in narration.
-  - **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. 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. **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.
+- Do not leave a regular stage without an entry condition. The first stage uses `case-entered`; every other regular stage needs a reachable predecessor. Edges are retired.
+- Do not design here, start Phase 1 before Case Review approval, or build from a summary SDD. The planner owns design, other-path analysis, and template conformance.
+- Do not validate after each T-entry or validate twice without an intervening edit. Phase 2 validation is informational; Phase 4 validation is authoritative.
+- Write `tasks.md` with a seeded header and per-section batched Edit-appends: §4.2.1 variables, §4.3 triggers, §4.4 stages, §4.6 tasks, §4.7 conditions, and §4.8 SLA. Never write per T-entry, use a mega-Write, or exceed a 30KB single Edit payload. Recovery re-reads and resumes at the next unapplied entry. See [planning.md §4.0a](references/planning.md).
+- Write `caseplan.json` by section, preserving untouched siblings — never one Write for the whole file. Read once at section entry; use per-entry Edits for fewer than 10 entries, or one Write covering only that section's container (the stages array, or one stage's task array) for 10 or more; gather CLI-gated sections before writing. Cap any single Write at ~15K output tokens / ~40KB; split a case with ≥40 tasks or ≥8 stages across the Phase 2 and Phase 3 writes rather than emitting the fully populated file at once. Re-read both files after interruption. See [case-editing-operations.md § Per-section batch write contract](references/case-editing-operations.md#per-section-batch-write-contract--canonical).
+- Do not emit standalone narration between tool calls. Bundle status with the next tool call; keep ordinary text under 200 tokens and allow-listed kickoff, hard-stop preambles, completion reports, DesignerUrl prints, and validation summaries under 500. Do not announce imminent actions with verbs such as `Building`, `Composing`, `Writing`, `Drafting`, `Generating`, `Now I'll`, `Next`, `Approach`, `Strategy`, `Plan`, `Let me`, or equivalent.
+- Preserve ordered task semantics. Sequential mode uses ordered `data.tasks` sets and one `runs-sequentially` rule per task; do not add `current-stage-entered` alongside it. Use parallel `current-stage-entered` only for independent work and `selected-tasks-completed` only for required fan-in. Event-triggered tasks use event/condition rules; manually triggered/adhoc tasks use one `adhoc` rule, `isRequired: false`, and no additional entry event. `adhoc` is an activation mode, not a task type.
+- Model secondary stages as interrupting exception lanes: `case-management:Stage`, `data.stageType: "secondary"`, `isRequired: false`, and `Interrupting: Yes` on stage and entries. Use `Interrupting: No` only for parallel SLA oversight. Use `return-to-origin`; do not connect secondary stages as normal flow or count them in required completion.
+- Do not replicate global events or SLA rules across primary stages. Case completion requires a root `metadata.caseExitRules[]` rule with `marksCaseComplete: true`; stage completion alone is insufficient. Non-completing outcomes use `marksCaseComplete: false`.
+- Do not edit generated `caseplan.json.bpmn`; do not place `caseplan.json` under `content/`; do not fabricate conditional-SLA expression syntax; describe conditions naturally until execution resolves them.
+- Do not place `tasks/` in the solution/project; it stays beside `sdd.md`.
+- Do not invoke other skills automatically except Rule 15 design handoff and Rule 17’s gate-selected inline creation of agents/API workflows. Do not spawn subagents for design, draft finalization, or plan-only documents.
+- Use `uipath-feedback` for trouble.
+
+> **Trouble?** Use `/uipath-feedback` to send a report.